From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E805037BE98 for ; Fri, 15 May 2026 11:57:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.157 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778846243; cv=none; b=H6fLpaKPMdWBVW201VMvk6KDp3xxPqVfnivGnO2GagTbVCT26l5qndfs8n6HNmAw5yRJeTisGKlqaF1+0wsJKnJ2jK0n3uMRF61qNHqgVeWrupGLgbccCfGm1avIDLoG7WK7l5BcC4Gzm/v232gHnd9ryzf5s4F8MQwwDDCQ+vw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778846243; c=relaxed/simple; bh=3suDRmqNdfr744LDzrg/c05qFQkOng9a+k3e1elmJnc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QEtZkjG3li7JCbVaPDCttOYudz2JJiW+VqItRTPjXxCVgms+pYaDc/FFW16cqJ+h/RERskR9moa7jTbGRjTvZbWTJe9xJ52fZaYVROnod2dVi53gB3vA5Eiu2idJncpaDN1Z9iQn4qO/UbYSlei+hgvwA3uUnNiAlYK5HbzyHP8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com; spf=pass smtp.mailfrom=bsbernd.com; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b=esvo7jJs; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=mshSwpLj; arc=none smtp.client-ip=103.168.172.157 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b="esvo7jJs"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="mshSwpLj" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 43E451400108; Fri, 15 May 2026 07:57:21 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Fri, 15 May 2026 07:57:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsbernd.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1778846241; x=1778932641; bh=EiSap4plJUpUq1eNZDj08eIiMZtV5onfuWR7wBIRCcM=; b= esvo7jJsmf3kdYlkQVVKafNmXNDX97GFETjEOPgeQkKxNdXjENd+cxu4G2MCz+QI /aDBVpY1kWoTCkBfna4GSAkAk/9ANyhuz/HNu8U2t5OSddjdmFe0dkIaC1rmyrMf A+VA6b80c4WFz0lDEJxtbRB8xJMYzDi9DbBb7vThjUWst18UJI/N+Kar3U16Ok2W aTCA0jkP/C/hAjjWVa6un6x+PmgbRZtIr5sj6viwQAWgVuVqrPldF7JsOujNjdi5 bCb5Lcg2jj8Y06gG8MlWVfCgLsmJ2NiNO3QFiFMtUxM1/ZBzLPpjWSOumVFpJqGi q2zXj5BuPK+yYpTMPeiV3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1778846241; x= 1778932641; bh=EiSap4plJUpUq1eNZDj08eIiMZtV5onfuWR7wBIRCcM=; b=m shSwpLjpLIxBlkWNMrf64kD5hX54ROOsVuJJlh/Cp1sl3N1SH3HqMaTTUe1H2ZZF rxwHZnVMkCK9I6rHyBuX1xSKdTUP4GwHJ1KYFMuCXQaWTnBcaaLPiEVDye2W+Bcq rMS4WJZu3Rt/1XcXZU9TV8eULiqgd8zOboXJ7S0XPaCFVxK+GjLGEIvuGbwqy0mJ ZmTroxDGUDAjRkTRUQQNZoxz41XGSlL2fNgLE46Vg1AAED/EdWxElbd1WOLNe+il TbC2TIWkHxzI+D8OhCXxZomatEVF/C5O+XnOReM4YCUPCtVJtiWOsSMASI8512kY gZ76Jsaq2QCgo6IzcAIZw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddufedtfeegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeeuvghrnhgu ucfutghhuhgsvghrthcuoegsvghrnhgusegsshgsvghrnhgurdgtohhmqeenucggtffrrg htthgvrhhnpeehhfejueejleehtdehteefvdfgtdelffeuudejhfehgedufedvhfehueev udeugeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gsvghrnhgusegsshgsvghrnhgurdgtohhmpdhnsggprhgtphhtthhopeeipdhmohguvgep shhmthhpohhuthdprhgtphhtthhopehjohgrnhhnvghlkhhoohhnghesghhmrghilhdrtg homhdprhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtohep fhhushgvqdguvghvvghlsehlihhsthhsrdhlihhnuhigrdguvghvpdhrtghpthhtoheprg hlihesuggunhdrtghomhdprhgtphhtthhopehhohhrshhtsegsihhrthhhvghlmhgvrhdr uggvpdhrtghpthhtohepshhtrggslhgvsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i5c2e48a5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 15 May 2026 07:57:20 -0400 (EDT) Message-ID: Date: Fri, 15 May 2026 13:57:19 +0200 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/3] fuse: fix race between ring creation and connection abortion To: Joanne Koong , miklos@szeredi.hu Cc: fuse-devel@lists.linux.dev, ali@ddn.com, horst@birthelmer.de, stable@vger.kernel.org References: <20260515045541.1171335-1-joannelkoong@gmail.com> <20260515045541.1171335-2-joannelkoong@gmail.com> From: Bernd Schubert Content-Language: fr, en-US, de-DE, ru-RU In-Reply-To: <20260515045541.1171335-2-joannelkoong@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/15/26 06:55, Joanne Koong wrote: > This fixes this race: > - thread a: fuse_uring_cmd() gets called, passes fch->connected check > (connection abortion not yet triggered) > - thread b: abort is called, calls fuse_uring_abort(), > fuse_uring_abort() is a no-op since ring == NULL right now > - thread a: creates ring, creates queue, creates entry > > which results in > - leaked ring, queue, ent > - if thread a increments queue_refs before thread b calls > fuse_chan_wait_aborted(), then fuse_chan_wait_aborted() calls > "wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);" > which will hang the abort/unmount thread indefinitely in unkillable > state, as nothing will decrement queue_refs or wake stop_waitq. > > Fix this by checking fch->connected under fch->lock in > fuse_uring_create() before publishing the ring via > smp_store_release(&fch->ring, ring) under the same lock scope. We had this discussion before, I still think it is covered by 2nd patch "fuse: fix race between registration and connection abortion", because fuse_uring_destruct() is called by delayed_release() in inode.c and that is only called when there is nothing accessing /dev/fuse anymore. The follow-up patch also handles ring->queue_refs going to 0. >From my point of view, what this patch really does is to avoid ring and queue creation overhead when the connection is going down anyway, so just the commit message is a bit confusing. > > Fixes: 24fe962c86f5 ("fuse: {io-uring} Handle SQEs - register commands") > Cc: > Signed-off-by: Joanne Koong > --- > fs/fuse/dev_uring.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/fs/fuse/dev_uring.c b/fs/fuse/dev_uring.c > index e467b23e6895..cd75f61018ec 100644 > --- a/fs/fuse/dev_uring.c > +++ b/fs/fuse/dev_uring.c > @@ -244,6 +244,10 @@ static struct fuse_ring *fuse_uring_create(struct fuse_chan *fch) > max_payload_size = max(max_payload_size, fch->max_pages * PAGE_SIZE); > > spin_lock(&fch->lock); > + if (!fch->connected) { > + spin_unlock(&fch->lock); > + goto out_err; > + } > if (fch->ring) { > /* race, another thread created the ring in the meantime */ > spin_unlock(&fch->lock); Reviewed-by: Bernd Schubert