From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (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 4FEAB7E792 for ; Fri, 14 Aug 2026 06:19:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786688386; cv=none; b=QeNpCz7qjq5ByS7SdkAHiKaa/08jfE/jlfirhm3iX45HR8TIPJ2XpiCFkCPLUnb8S2C7c/zUV4LoUJcAXkt3kwGQSelK1n8S17DCIuyUwtRBJt5bj2d2s1AfjycNEerI12xOwod5weY1gl+3LH0Zhplpba0kpa9PWm6gSktb2Fw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786688386; c=relaxed/simple; bh=KFbfKvgkiUh0eoArZY7l15PSg3pn/R5+srLV0KmzU3o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LYnVC21ZljMniqNReLwKbve/Ek4L/ZpvIWmBrVDgUCN8cHGTia84McQRoWjQ/u7J/0FHcVX24hy8zrQDNUSJG4fxaa6lt4D/MgfYq/UGKMa3DEiGrjy2ekZtJ/X52yWMcKl3CcJGOOjRIxDAJhxIVoZF1/3mniIZ+wBXTjOhHl4= 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=G/382O7E; arc=none smtp.client-ip=209.85.216.44 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="G/382O7E" Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-38e69bdb0fcso622546a91.1 for ; Thu, 13 Aug 2026 23:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786688385; x=1787293185; 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=8zzHteahxWER+bHLxgDmoneuuL+9/H/S/HBeqpOauBo=; b=G/382O7EcooFL5A7sPna7WmW3CC42yA8GeFNUeqwRFDT/L8p09FLEV8wgNSz17TFOs Vj1cAzebuX07khJrgrqc/5R+9eHfgAqXaOc9T0g3xybtXh83TW5pI82XIFNREVSudzoR rOLw4nqbdpo+HuDKnE6c03NE8jatvgdLwNhop4an+nsS+pg8pPzG9vViDBCokmdWUEg1 kpvH31t+bqijCEH+5Wkfr4ZbLtrVPcw8EC0XazDkkGh0x5ZkITszjn8IXdy+9oRrIeIX 9S+rBfH2iGRogVuYp+AxVBbH5Lj0dPtl6O1f3fJTSfeIULeuhFEFDy5+HyT/NzgLsu1L CWcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786688385; x=1787293185; 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=8zzHteahxWER+bHLxgDmoneuuL+9/H/S/HBeqpOauBo=; b=pLSDlZ7cgYH1oMHOL4ljNvnhMiT4ISjjOC20NhwMKzbadGKnZ8HMeBuWwZ1d5F0aKi TSmi302RIPq43Zh/2cc4zPhCUgPWJ/NIbwhHPMviAZA4lyd9Q3LDsII+lonuprv5qdhX QcKgExv0Muw20mUaZHaBYY6jmt93TiWHfbV/Boo4JC+2+YOkyYKFqZ/fyvL7ajzVKaVE Fi6DdLTpPXtrtwIwW5RWkJErZ0iUmmmYw+Of83Ewrw9gsLagwUWkY8+4EQz57ahe2eGc UQBBPZXP0Ei9QedvbAWkYLswN+S80km61Qryn9YyzblqKeJgHH98HmVubmK3jxBxu2bB IG7w== X-Forwarded-Encrypted: i=1; AHgh+RqdUiluR4MB4bgj6D0B9CB4ih3w1namfGzHCdxrF3gMafIUNDRD5FO3XfyWH+NGO2oXIBXFxdwKiQeN1Tc=@vger.kernel.org X-Gm-Message-State: AOJu0YwSALSVkLa82ei4f3Jt8yXUzsw4XhJ8ZRIZl3xInOxWr+r6HEd4 +PHPWCBiM2DfDejXSS72H6Ybct3RPHTkQTGXhoMoxn4CBNtaCreFVdaP X-Gm-Gg: AR+sD136BuZwy9BSs8znefdga/lkHJDCPFu1LJTqMgJAThU9/oz4ADZDnetHcQf6Zzs Qo+6G+eTh91W9BsONtQCir8FmBEcCiv7/BMUtSXZN+IMx8AZ5bttUeQGrMReAK1LwbO1/LhmWFX 8Bv2wlzxOct/jHxZhrDiBGf5Xy9CUtaMmYmC1xFjkQJThTCLro2RdxPbq3AaS92oxtFJWw1pdMl KkuGvbgLWtwJbWALH3yzv+QLcN12cgKnbUVhSk0G3FKDdGpRhrG5gRJRHQe+B11raTusN6eH6O4 cFyyV98l8SwX8TfAo5AdVch026y9BYOkfmVhdVf8NjI5KewIgkf48AiLjqABo0cu0wrpzU41xdo L3G9fGdQnomizw0XCwKo14HVIXxfpFYddMU1D5EL90+q1oUagxLziExlxA4MUBmeBIhevw/CyNn tHLoVFPMswXngtElme9Hq9uzs/h5puPgkD9+g4xQNieK58gJH8vTpECnumOlgIEIqLLrRXeK7HK 9gQootdFg== X-Received: by 2002:a17:90b:5450:b0:38d:c74d:29c5 with SMTP id 98e67ed59e1d1-3933ed23db1mr3617266a91.19.1786688384548; Thu, 13 Aug 2026 23:19:44 -0700 (PDT) Received: from [10.22.68.200] ([111.223.92.222]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3933b688035sm667180a91.3.2026.08.13.23.19.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Aug 2026 23:19:44 -0700 (PDT) Message-ID: <1bc066fa-ee8c-426a-9c63-b0ee305de5a5@gmail.com> Date: Fri, 14 Aug 2026 14:19:40 +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 0/2] fuse: fix request lifetime races in the resend path To: Jun Yang , Miklos Szeredi , fuse-devel@lists.linux.dev Cc: Zhao Chen , linux-kernel@vger.kernel.org, Jun Yang , TencentOS Corvus AI References: <20260804091757.503476-1-junvyyang@tencent.com> Content-Language: en-US From: Tang Yizhou In-Reply-To: <20260804091757.503476-1-junvyyang@tencent.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/8/26 5:17 pm, Jun Yang wrote: > Two fixes for races introduced together with FUSE_NOTIFY_RESEND > (760eac73f9f6, v6.9), where fuse_chan_resend() moves in-flight requests > from fpq->processing back onto fiq->pending. > > Both concern the same invariant. FR_PENDING means "queued on fiq->pending, > protected by fiq->lock", and it is what fuse_remove_pending_req() relies on Hi, Currently FR_PENDING doesn't mean the request is protected by fiq->lock. It looks like this is your solution, so you need to clearly explain why you are doing this. > to unlink a request and drop the queue's reference. A request on It is unrelated to the queue's reference. I think you need to check whether the AI's output is correct first. > fiq->pending can therefore be released without going through > fuse_request_end(), so anything that sets FR_PENDING, or that leaves a > request linked elsewhere while FR_PENDING is set, has to be done under > fiq->lock. > > Patch 1 sets FR_PENDING under fiq->lock. fuse_chan_resend() currently > publishes the bit while the requests are reachable only through a > stack-local list, so a concurrent waiter can unlink and release a request > that fuse_chan_resend() is still iterating over. > > Patch 2 re-checks FR_SENT under fiq->lock in fuse_dev_queue_interrupt(). > Its callers sample FR_SENT unlocked and fuse_chan_resend() clears it under > fiq->lock, so a request can end up queued on fiq->pending and linked on > fiq->interrupts at the same time. > > Dependency between the two patches > ================================== > > They are independent and neither supersedes the other, so please apply them > together rather than picking one. Patch 2 does not affect the unlocked > FR_PENDING publish that patch 1 fixes. Patch 1 cannot catch an intr_entry > that is linked after its locked walk has already run, because that link > happens once fuse_chan_resend() has released fiq->lock. Patch 1 on its own > also makes the condition patch 2 fixes easier to hit, since requests that > would previously have been torn out of the resend list now survive to be > re-queued. > > Both were found by code audit and confirmed on v7.2-rc6 (075b74841bd0), > where the series was built and tested; the resend and interrupt paths were > verified to still be exercised with the series applied. > > A KASAN reproducer for this issue is available if requested. Since you have a KASAN reproducer, please first describe how to trigger the issue and what the symptoms are, as a prelude to the solution. -- Best Regards, Yi > > Reported-by: TencentOS Corvus AI > Signed-off-by: Jun Yang > > Jun Yang (2): > fuse: set FR_PENDING under fiq->lock in fuse_chan_resend() > fuse: don't queue an interrupt for a request that is back on > fiq->pending > > fs/fuse/dev.c | 29 +++++++++++++++-------------- > 1 file changed, 15 insertions(+), 14 deletions(-) >