From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (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 CB6BE34E75A for ; Fri, 14 Aug 2026 08:49:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786697363; cv=none; b=cqJCT19mg41fx4N8g4jZnOWEBVwUkdqSqbrHRjEy5CU92PQsBlcD/J99uHdbZMC/qWGW7LKAzS0Hg4UFRsSHg7jilypzdOJFitRbeZPHT0JW5S6RfWKPNGBILYbtkP26wOV2shGWR1H1kmbdUAirxdkBHSCgVHf+fq94d3wDRUs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786697363; c=relaxed/simple; bh=HAA+mt4ekKMS/6F2UkZ4KJyTnTXXBtPr9zHD+OA8950=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gUhELgBpij12FKFym0RRtHjHBSrUYoNlItpD8RNAg4xpcoqQGtAAW+4QtN2ZU15S/IwOSLYeVCbRnDso+Mec3Iq9ggWGxMhDfO59NF5rNJaNKo7V50fB7ALDcGqB8p3FMc5bDDS0MWK0CVvFd3BfubOPvd93APrmQOxChlGFTwE= 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=dH1s/TgU; arc=none smtp.client-ip=209.85.210.179 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="dH1s/TgU" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-84e507b079dso425190b3a.0 for ; Fri, 14 Aug 2026 01:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786697361; x=1787302161; 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=GG12SPtU6isFgXGa5wHO//MDFN9B9TIMaXwE7epMdro=; b=dH1s/TgU3IGjr6goUgo8yXfWB3XROmlK3CVilp6g5OJ20CwOsraMFMrKZlZrq6CBzS uH/uxkxx3SE+n1fIslK9CnDJEdwLLFYzveELppkzB+9zaOgLWpdLGj/O3ftZvL+5+qDV rYxF0tTQ0Li1KWiw44Tp8HuRu1um8D8Ff2oILby5YEo7KokAyK2CMh5mAdy5EdlXQWXn fzLaX0k2ljXzMYBWxeZC8dmulY9flbp2ZAwiwgZu0Uw15JUkyFd/Ee1LLQ+BuesgNcqv SvbNixGxRszIh2ihNDnoFUL1nyXdU4ahllOALlYbed2cTOjF1yjw/tNQYvuA1hN4j3+/ a+7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786697361; x=1787302161; 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=GG12SPtU6isFgXGa5wHO//MDFN9B9TIMaXwE7epMdro=; b=Dtq9RVjpKRYG8y2AJ9FQgpRqc7OfgzNtWaSqQKn1i8W6Q8zd+Oevk0MS/yMqfZzUL/ 1rOROWdN7RDAt22XHM3eza4lKe2RnTst/R4JQCVvP9SNMW3M2pkdp9bQJZlT4ZomqorK HcnF/xXnuR2PgzXDM2WlO9eEO3sc3m7hvX7lnC0zICiDEMyFo2TLTmsfPhdX2RJYy/Se Ox1pRPkOy2HdbAJFGNoWY4uPsQvNPKZJwSJYaJLtT7DReJdgsAzLb/+zDoFqM3FzCXOv Cr/wrPYQc+oWGmGuUp5sUcE2GlsMtFeGxq3BY+Qu6V9ZxPyY5hHNab3WQRD8QxjwUt5N MSrg== X-Forwarded-Encrypted: i=1; AHgh+Rr4BpDQ/CWd5Cmm8JrP2mFDU2uVdAeTBeHjrX3tzzysloOuc1wLCFMNr6oKMaC8oeLpv3mAYPLDtdiVsxY=@vger.kernel.org X-Gm-Message-State: AOJu0YwB8OUwq/faQqhpwSwP3eMJ1V8Jn1gNFsZO2mfgNPZIW0E72Nlh uBdZsiMxrCfxvx+VbpuslhS+mlUs143wWMTFAbvtmnyD8d5WHOF301vG1N7es4exzZg= X-Gm-Gg: AR+sD115BOrn/3DLs6YQfa04I9XhVLuco9G3F9muKwtaT5eqdqKmnUSQrKMxxkqzpCS eI6cmAEEENtDvLxHu1O9hXZQ01H3Z7lEPHADHMRJQ38A4zQ9i8z0k4oOPYSjAaKZjWWQbjplw2z 5gfugNGARRmW4opzZbdOR2oVlKn77WNKTUO5fA5mYbvnEkaDmBy2ENrAY6MkCAwbnbaAvWvjZdB 1UYMLAKzpe5kxL02BJJnbFRNOZ9OyS9hmwWE/SqJHYmq1VxvlPKY0plZBCfNkCg2wHfXd5QD0nD M59tHmEHF7NgNafVhzHKSNYOutbzh/UQ9UmXl6HhYDC4DM/bwlm64paTsyWlJyPfUq+H+F3MEiQ bW6ZeiL1ZOrgukxsmMIO4v7r3k+p5m6FW/1AoO6KUSM5rN+NNKYIxUpOoKAufReHh4GsFz5EncO vuOAOACLS2TmOjbbyHnpL48gHLFEjPKTbj4m2/BIBzper69FmIuSXozFKyrgrEDetQgyCuD9/nV 9HnZ6T3U7JvVtCWBqeM X-Received: by 2002:a05:6a00:399a:b0:847:9267:2104 with SMTP id d2e1a72fcca58-84fde1cea2bmr4152125b3a.12.1786697361028; Fri, 14 Aug 2026 01:49:21 -0700 (PDT) Received: from [10.22.68.200] ([111.223.92.222]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8517cfeb417sm176997b3a.2.2026.08.14.01.49.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Aug 2026 01:49:20 -0700 (PDT) Message-ID: <4bbdae79-84b3-498a-b9cb-4767b336dcf7@gmail.com> Date: Fri, 14 Aug 2026 16:49:17 +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 2/2] fuse: don't queue an interrupt for a request that is back on fiq->pending 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-3-junvyyang@tencent.com> Content-Language: en-US From: Tang Yizhou In-Reply-To: <20260804091757.503476-3-junvyyang@tencent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/8/26 5:17 pm, Jun Yang wrote: > fuse_dev_queue_interrupt() links a request onto fiq->interrupts based on > an FR_SENT observation its callers make without fiq->lock: in > request_wait_answer(), in fuse_dev_do_read() after setting FR_SENT, and in > fuse_dev_do_write() on an interrupt reply with -EAGAIN. > > fuse_chan_resend() invalidates that observation: under fiq->lock it clears > FR_SENT, sets FR_PENDING and splices the request back onto fiq->pending. A Right. So why did you say 'They (patch 1 and 2) are independent' in the coverletter? -- Best Regards, Yi > caller that sampled FR_SENT just before that happens links the request onto > fiq->interrupts just after, so the request ends up queued on fiq->pending > *and* on fiq->interrupts. > > That combination is a problem, because a request on fiq->pending can be > released without ever going through fuse_request_end(). A waiter whose wait > is interrupted calls fuse_remove_pending_req(), which sees FR_PENDING, > unlinks the request from fiq->pending and drops the queue's reference; > fuse_chan_send() then drops the last one. Unlike fuse_request_end(), that > path has no FR_INTERRUPTED cleanup, so the request can be released while > still linked on fiq->interrupts, and the next fuse_dev_do_read() walks it > in fuse_read_interrupt(). > > Re-check FR_SENT in fuse_dev_queue_interrupt() under fiq->lock, which is > the lock fuse_chan_resend() holds when it clears it. This restores the > invariant "FR_PENDING set => intr_entry not linked", both sides of it now > being taken under fiq->lock. No interrupt is lost: the request is going > back to the daemon, and fuse_dev_do_read() re-queues the interrupt once it > has set FR_SENT again. > > 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 | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c > index e62c7ed8bcf4..c4df1d4abd33 100644 > --- a/fs/fuse/dev.c > +++ b/fs/fuse/dev.c > @@ -240,6 +240,11 @@ void fuse_dev_queue_forget(struct fuse_iqueue *fiq, > void fuse_dev_queue_interrupt(struct fuse_iqueue *fiq, struct fuse_req *req) > { > spin_lock(&fiq->lock); > + /* fuse_chan_resend() may have put the request back on fiq->pending */ > + if (!test_bit(FR_SENT, &req->flags)) { > + spin_unlock(&fiq->lock); > + return; > + } > if (list_empty(&req->intr_entry)) { > list_add_tail(&req->intr_entry, &fiq->interrupts); > /*