From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD42140A93E for ; Fri, 14 Aug 2026 07:23:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786692224; cv=none; b=NKJhyUtj+ZQAh8JqFRcLgWDYD3DB3/qpIDHmJEszUO7koXZFfcHRDSBz8/S+f2gFBdAJF5rCgfVx+ej20eykrYLMA6qf+rd3OchiAPuvQDvvIUtRDmaTbjxGGL9f3Mvq13ZIm027ZcuZVPL5EdZ9O/wf9aLDRsVU4IsbnlYvrFI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786692224; c=relaxed/simple; bh=eqsKtyKp7QSyLOw68sMVbhvONY489JyIbKn33/jbj44=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=u14kaluqd2k8kW+6vxCjIgItHIu7LGwpJ7Ogv3dWlrxeSdGaq5D+orYFG/aTSZ5P4sxokkvBKdrxCF+xdBv91Nr68TlRMnu2zutRL8rRIUeeLo8csXwvJGdw4s2o1D2Cv41G93fZ9peUUEcUUX5OG5W4imPETuL7Qwy9gaDt0lI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lLCeqZWZ; arc=none smtp.client-ip=209.85.214.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lLCeqZWZ" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2cc97653887so12915025ad.1 for ; Fri, 14 Aug 2026 00:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786692222; x=1787297022; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EUCkmH0oXKN4ykZwwQ3W80SsRpWmXMPCCh2SWN7p2kE=; b=lLCeqZWZs3bpS1WDZmKdR5BDF5pgLYWWYgiAbo4Hh9Qnasp6e49ktGBnn8wHiKOXHo rvLAXH9MZ7KWnz4hQhRYjRRA/YfMZfYZoZ2RYUtTB5YGtCnweOpDbyRpJn8+yxMXsMBT y0mTOpL3tuiX+AHAYn3n36fIbkfKk+OrZr8VgWxoThQXBYAX1VXEQKX9sBY8FT5F8+yp b5+9+v1Ig7HlPBT7xQOulWgV/sBKwBFPmxycZTM03dfIsGt4FeMAV38AUk/Q4ji/QROM O8U4nvjvHTsaj+b/hV1n8L1OhO/rfHfkRIeApw5icEProR4hndE/QYgoNoOHB6Iun9Q6 ToHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786692222; x=1787297022; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=EUCkmH0oXKN4ykZwwQ3W80SsRpWmXMPCCh2SWN7p2kE=; b=j9YyFkRJgHoPe073tbOLz68SykmPH+cQF5e/tvWzntWS1TuojcqCpJ4wfDSmVvu1NJ uLqo6PqqxXHxUi4MJ5LozCSdBTEvQWmVTgbeCIh3Hx41fcZM2cX++ZT7WUwGTG1M0fQh u2WKVQcE6+6F8vUH1FJDo13W9V7WUgVa8YcMOlFHvD3GM2JhzDTy72vaxBsxCPL0+cvf x8Djl1c6Ojp2RF9jRYEC0NI37hgCJmM/SMg9dNvGxkab4HTo68r9z78/FikQqMswDynM 87V135cHyd6t5B+z/tWaHq4ytfpksgqffvg4hIcl0EabhSyn4IryjgDUJolWoSeqHt6H oyxg== X-Forwarded-Encrypted: i=1; AHgh+Rp8OKWDeQzDHaRhTo40RL8+PJssw4xQOj+uv9+jdDDP2zJwU6tOaUqzRnX3Z90p8ieTxEiPhHf+qMR8STE=@vger.kernel.org X-Gm-Message-State: AOJu0YyMuIMdhXMU0xY3OcPFi4yjAx+0DxtXSFeg/2lL1ZkWZ1XqbyGR vxYwF02JBmvPrzyvUIl7HAgMEotXvmDKT4M+4sQxSL5Z8m3nzhoEIs+3 X-Gm-Gg: AR+sD11xHnLx6Cwd65ceLrmlj9UlNItpUxXpCn4uGrv6hXDLr4/qSvP8ggiW61fwy5K p6j/3ughuL3sbrN2PfNLK+FFfSZFiDdIkerSI/qcfWzs9pd3uVAsxSXeMJEmbr0nEzO7mlDo0gD knGM5wsrc0fibW+QVstc0RWols3d4q69IeoVZXxyOeS8fo9WTKPxKsyjnhCLPl1xf4M6bQMfYgl dHkr/7dn3l4f7BAOgf64KuMqFty7T1yWs0B/t2H/qa3nN0D05ZINFgGGnXd0ASdn57eviWrOY8o t/ybn769jsLQxrALZ30FduHwFEHzwtZRtCjgIri8t0CWXbNX4ltJIRdvp5xS+cUG6WXBZGjY/mh m+3eVpOvaexthP+wr+UvfCDf7GSB9jjrwlkCiumgEp0pDy1eJMNxDQeqf7jAWQo65g8Dp23GRgY wp/nQbEOaaJFZTsRSvhHlx8IFTDwV/l6W58BaiuBlzJr1LvHpGLzimSxh1fo8MH42w3/cCPRUch zpvnfwa2g== X-Received: by 2002:a17:903:384c:b0:2ce:7563:70a5 with SMTP id d9443c01a7336-2d3b0d1254emr43666795ad.6.1786692221895; Fri, 14 Aug 2026 00:23:41 -0700 (PDT) Received: from [10.22.68.200] ([111.223.92.222]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d3aeb27e40sm5720085ad.41.2026.08.14.00.23.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Aug 2026 00:23:41 -0700 (PDT) Message-ID: Date: Fri, 14 Aug 2026 15:23:38 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] fuse: set FR_PENDING under fiq->lock in fuse_chan_resend() To: Jun Yang , Miklos Szeredi , fuse-devel@lists.linux.dev Cc: Zhao Chen , linux-kernel@vger.kernel.org, Jun Yang , stable@kernel.org, TencentOS Corvus AI References: <20260804091757.503476-1-junvyyang@tencent.com> <20260804091757.503476-2-junvyyang@tencent.com> Content-Language: en-US From: Tang Yizhou In-Reply-To: <20260804091757.503476-2-junvyyang@tencent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/8/26 5:17 pm, Jun Yang wrote: > FR_PENDING means "queued on fiq->pending, protected by fiq->lock". It is > the sole predicate fuse_remove_pending_req() uses to unlink a request and > drop the queue's reference. > > fuse_chan_resend() breaks that invariant. It splices every fpq->processing > list onto a stack-local to_queue and drops fch->lock, then sets FR_PENDING > on each request while holding no lock at all. From that moment the request > advertises "I am on fiq->pending" while it is in fact reachable only > through the caller's stack. A waiter whose wait is interrupted takes > fiq->lock, sees FR_PENDING, unlinks the request from to_queue and drops its > reference, and fuse_chan_send() then drops the last one -- so the request > can be released while fuse_chan_resend() is still iterating over it. > fiq->lock serialises nothing here, because the request is not on an > fiq-protected list. > > fuse_chan_resend() then walks that same list, and on the !fiq->connected > path it drops fiq->lock and walks it with a non-safe list_for_each_entry(). > > Publish FR_PENDING under fiq->lock, immediately before the splice that > actually puts the requests on fiq->pending, and fold the intr_entry cleanup > into the same locked walk. A waiter that arrives while the requests are > still on the stack now sees FR_PENDING clear, so fuse_remove_pending_req() > returns false and it falls through to wait_event(FR_FINISHED) -- the same > handling a request already handed to userspace gets. The !fiq->connected > path no longer needs to clear the bit, because it was never set. Hi, I understand what you mean, because I found a similar issue during stability testing. I’m not sure whether others can understand such a lengthy textual description. People usually prefer to see a sequence diagram to illustrate the issue. > > Confirmed on v7.2-rc6 (075b74841bd0). > > Fixes: 760eac73f9f6 ("fuse: Introduce a new notification type for resend pending requests") > Cc: stable@kernel.org > Reported-by: TencentOS Corvus AI > Assisted-by: tencentos-corvus-ai:kimi-k3 > Signed-off-by: Jun Yang > --- > A KASAN reproducer for this issue is available if requested. > > fs/fuse/dev.c | 24 ++++++++++-------------- > 1 file changed, 10 insertions(+), 14 deletions(-) > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c > index 5763a7cd3b37..e62c7ed8bcf4 100644 > --- a/fs/fuse/dev.c > +++ b/fs/fuse/dev.c > @@ -1781,26 +1781,22 @@ void fuse_chan_resend(struct fuse_chan *fch) > } > spin_unlock(&fch->lock); > > - list_for_each_entry_safe(req, next, &to_queue, list) { > - set_bit(FR_PENDING, &req->flags); > - clear_bit(FR_SENT, &req->flags); > - /* mark the request as resend request */ > - req->in.h.unique |= FUSE_UNIQUE_RESEND; > - } > - > spin_lock(&fiq->lock); > if (!fiq->connected) { > spin_unlock(&fiq->lock); > - list_for_each_entry(req, &to_queue, list) > - clear_bit(FR_PENDING, &req->flags); > fuse_dev_end_requests(&to_queue); > return; > } > - /* > - * Remove interrupt entries for resent requests to prevent stale > - * intr_entry on fiq->interrupts after the request is re-queued. > - */ > - list_for_each_entry(req, &to_queue, list) { > + list_for_each_entry_safe(req, next, &to_queue, list) { > + /* must be set under fiq->lock, see fuse_remove_pending_req() */ > + set_bit(FR_PENDING, &req->flags); > + clear_bit(FR_SENT, &req->flags); > + /* mark the request as resend request */ > + req->in.h.unique |= FUSE_UNIQUE_RESEND; > + /* > + * Remove interrupt entries for resent requests to prevent stale > + * intr_entry on fiq->interrupts after the request is re-queued. > + */ > if (test_bit(FR_INTERRUPTED, &req->flags)) > list_del_init(&req->intr_entry); > } The solution looks good to me. However, I hope you can truly understand the root cause of the issue and describe it concisely, rather than simply pasting the AI's output, which would actually make it harder for everyone to understand. -- Best Regards, Yi