Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2570259pxb; Thu, 3 Feb 2022 09:17:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJzUVMvsL0BO+arl5t9u/W88aDy81HZsuUBwO4/KSdn63roHkdmLvWbcqmMijkMoFu0/tYOc X-Received: by 2002:a17:90b:255:: with SMTP id fz21mr14920493pjb.226.1643908624145; Thu, 03 Feb 2022 09:17:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643908624; cv=none; d=google.com; s=arc-20160816; b=JfbwVSjC29kX0t90ZOg/N7mS3AzgCT37FNxABjjgMmfqs6aOh2YCNTflvu0jGtnvd4 +XOfVv0XnKMLjwy2Gg1Y0KhEHS8eK4+DpYgqIPxE0HG0RJe9/zY9TKQ4tsGJFkZBXIx1 p1CsCasdyrib4I/pORa3wrRs7Y9uHCbk5VcnJUMpAzanvex0b1MO4kWIlTpsUlBuQFuo Xof/3K7Gcw+osuLd8zblDOXAeKWDp9PMEyjZN+6RW9u2eyT5HhpmKQ3DAauIbGVfc94Y fxaQmbkKbgl/JeTrfO4vmDD5CSpsHDd/uu/m4akAuC9nJ3pLL1EoXUHLcAe8FAuEn2L0 b3aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=hnNStLLfw2FHaWSpq9EzzqFXeWS4HqySix/xq3cDScY=; b=enHMLjGByl/x8OVDLQYt2M2nwfq8OUdmRCLQ/5bsunJCrbKH6KusklHe8l3P0haR7N ZVha6ixBZKNKwLMOh8VgqxWfgFtww201nef/VqSh1OBoKpBLwAqewvlOyxg0ZzKnlCKs g+SWPoQnVTATvewJENjJ5xt8Mh9EJi/UphZSqyIVIb7lLfLBCi4WgmxZnj+i/RWfWRIw nTRinfUXyKVmxTkuFglrSdOHTln0+/RvuzU+LKNuJgTqjFoo8heo/kl5uKr0DWfARitF DnahRE3eFcBV1+uxd+nSGdTgQ4H2IjAWdkuVJDXxA47UEvDgXM0bC5SPLqCwckanBrFD PZpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=4j1Iez5J; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l5si27647336plh.261.2022.02.03.09.16.51; Thu, 03 Feb 2022 09:17:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=4j1Iez5J; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352462AbiBCQ7E (ORCPT + 99 others); Thu, 3 Feb 2022 11:59:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233754AbiBCQ7A (ORCPT ); Thu, 3 Feb 2022 11:59:00 -0500 Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC071C06173B for ; Thu, 3 Feb 2022 08:59:00 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id d3so2603698ilr.10 for ; Thu, 03 Feb 2022 08:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hnNStLLfw2FHaWSpq9EzzqFXeWS4HqySix/xq3cDScY=; b=4j1Iez5JQ1Zsf2GFZrvfuEys0VR/h8RdRwkREyilwcCkxUKp7HB0hPuvVlsqqMLqoX zB5NOXdK1Ow5sov9DmbCt05U1OqnOQ+WLPNClqSbb0fEZck+bJYxq0Drp0oZjXIe9mw+ l/JBPjsfHZKn5biUnP/zrjJ2moSK4/k0TkACb2zIaoeb1tfYyOByrT7bdJzzgmlc4YcC e0GCm1vNVQcUtTPTzc1lR2tirQIh/KX21Yl2evZLTqphzEvWHXruLM9jhhQiFI0phlhA j01Ay2SXhYkZydTxWWq2F4MFS2mXGfWW505SENj/ZaTWhT63csc0Bnc0bP90luaangHj 7iHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hnNStLLfw2FHaWSpq9EzzqFXeWS4HqySix/xq3cDScY=; b=dpyEo1LcIC+rNqnIuDZL78Ble/Sz1FE3/RDuL4fxl8YC3qFAL3Tm8WbVrfTGedvcbL rlCKYIvHq8tzwxC59IEWZE5A1g8OvLgE/ew9zSxJ/Ovl0rNy7LFDVjTShJt8sQkeCSBl XEPQiGKMBp+1uYh0ZxVzLbtg+YKDynosk2kmY/+swRgGAn+tZxRDHTuFmtKDrZF+Q7mN G+YUj3yG7wAuINvoGvVjDrHvLCqimB8LztEhhkybLaxJEK/klICWaOY1P6bOFjewdjn5 v/RSS6TXEG0gA04A1CquEZPTZVhtlaSkjgFmHi9BSZX0MjGYVjjN0rePbkRlmrYBqrDg USDw== X-Gm-Message-State: AOAM532v71Riw2Fa/tTj66dljWHsOTPOLq4mAvYulNeW8vQ4ngM17nDw 813LLSmVxZ3arN2iI2wL/Vbcuw== X-Received: by 2002:a05:6e02:b46:: with SMTP id f6mr19730584ilu.235.1643907539828; Thu, 03 Feb 2022 08:58:59 -0800 (PST) Received: from [192.168.1.30] ([207.135.234.126]) by smtp.gmail.com with ESMTPSA id k11sm22816858iob.23.2022.02.03.08.58.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Feb 2022 08:58:59 -0800 (PST) Subject: Re: [PATCH 1/2] io_uring: avoid ring quiesce while registering/unregistering eventfd To: Usama Arif , io-uring@vger.kernel.org, asml.silence@gmail.com, linux-kernel@vger.kernel.org Cc: fam.zheng@bytedance.com References: <20220203151153.574032-1-usama.arif@bytedance.com> <20220203151153.574032-2-usama.arif@bytedance.com> <87fca94e-3378-edbb-a545-a6ed8319a118@kernel.dk> <62f59304-1a0e-1047-f474-94097cb8b13e@bytedance.com> From: Jens Axboe Message-ID: Date: Thu, 3 Feb 2022 09:58:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <62f59304-1a0e-1047-f474-94097cb8b13e@bytedance.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/3/22 9:49 AM, Usama Arif wrote: >> One thing that both mine and your version suffers from is if someone >> does an eventfd unregister, and then immediately does an eventfd >> register. If the rcu grace period hasn't passed, we'll get -EBUSY on >> trying to do that, when I think the right behavior there would be to >> wait for the grace period to pass. >> >> I do think we need to handle that gracefully, spurious -EBUSY is >> impossible for an application to deal with. > > I don't think my version would suffer from this as its protected by > locks? The mutex_unlock on ev_fd_lock in unregister happens only after > the call_rcu. And the mutex is locked in io_eventfd_register at the > start, so wouldnt get the -EBUSY if there is a register immediately > after unregister? The call_rcu() just registers it for getting the callback when the grace period has passed, it doesn't mean it's done by the time it returns. Hence there's definitely a window where you can enter io_uring_register() with the callback still being pending, and you'd get -EBUSY from that. -- Jens Axboe