From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=103.168.172.147 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793150521; b=H85kjxV5d1Ge7iuM3tFAexXDHbli702tPhiHDWTQ1W16RsIsj6xvYqr9iwsXU5+MP0cN 7tBqfttdswpWx4PF8faJBCCCACBcUF21O8a6w85+4dXCoDnwHT6XPGM4/Y+JbDPq4OrKJ ntZAh2iLVDtLyAYRhUUeawlRu3eG8jKH40q2qy8dx+f76lbmHrcZVni9KLXrYBUnPHupT bIfUZPr6QNhKw3O6ze49SCz3EZchCr8cGD7uRKWZ6ZYVOKil5KlM3du4UZG2u+OWnlIL+ aJTMkItBkuqdXEnRFCEfe9EgZ2amP4PjeaIp4Ht/NvwMv6Qxv8TdbYiiGGFrRSC7SoA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793150521; h=DMARC-Filter:Received:Received:DKIM-Signature:DKIM-Signature: X-DKIM2-Info:DKIM2-Signature:X-DKIM2-Info:Message-Instance: X-ME-Sender:X-ME-Received:X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID: Received:Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:Content-Transfer-Encoding:User-Agent:MIME-Version; bh=4cR+Jnw2vZTLedug2NT9bT/PNYuUzdhU9pnjK8Gk3b4=; b=okD5YRAnns9NcuAuNdgmy+J64z3uRqBaDe3MNFlcakgDzEVfgvB6EGDZtk+6vy34GuXJ A1ApljX9RQbtRWkSXDBNiCHMk/2EwGkUq1jocsEL3fzT3xql9uszUSclg6FGD3KIEzLCl Z0bs2A0sY9kBZ2WPBezfVrYtxlUna4JqxBa9W9mndxo+PmuD6KaO99dYEFZZPwgeD7hhJ yQbB3V9Rjosj/4aah0mD5VPrjTiNc6xTgDNVd1J004oSI6JISDa6mC5phaXlb7R0Iq3Da Xdp8pOst4C4YOEqBTVQY4nIpNEz+bJlhoFBoec2dsWaGaE+DDWXJxpMYctG8mviHQeg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=themaw.net; spf=pass smtp.mailfrom=themaw.net; dkim=temperror header.d=themaw.net header.i=@themaw.net header.a=rsa-sha256 header.s=fm1 header.b=IuANCG5d; dkim=pass header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=ASgV40z7; arc=none smtp.remote-ip=103.168.172.147 Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00292606A31A for ; Wed, 28 Oct 2026 01:21:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 00292606A31A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=themaw.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=themaw.net Authentication-Results: smtp.subspace.kernel.org; dkim=temperror header.d=themaw.net header.i=@themaw.net header.a=rsa-sha256 header.s=fm1 header.b=IuANCG5d; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=ASgV40z7 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 10196EC01C4 for ; Tue, 27 Oct 2026 21:21:59 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Tue, 27 Oct 2026 21:21:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; 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=fm1; t=1793150518; x=1793236918; bh=4cR+Jnw2vZTLedug2NT9bT/PNYuUzdhU9pnjK8Gk3b4=; b= IuANCG5dx2AuLSzGWT1IlW0LpNdHwVHudaxvydOEnc3KSoJ/qoMeuRTBcuHevylW xUbQw+3IqU+mSDopyXhKpLMSyZdaIQYBWsp91BtQLJ6ivce7R1cuF7LYQVlluKOM 55TmLfhzJ/XgFzpWKbku9XBEEHXvbqRJ5vOSHONPiAFeVL8JucBr1JOA/VFwvjKS w11r6SsVd0monzWXTSSRu9aCd1MnbVsYTMZQxq4e7JYEQg0XE3VlNJOsuLd4+Ahu M2i0unzEJI77CglJFd3yELGpyxcNPO6lBajkV1sZOKnC3Pk/qgxAH53X7FyqVsbo jkTWgUXOP8IFrAx0YIZ2Zg== 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=fm2; t=1793150518; x= 1793236918; bh=4cR+Jnw2vZTLedug2NT9bT/PNYuUzdhU9pnjK8Gk3b4=; b=A SgV40z7r6xfOgnty139gvV4mch5EP3LpzWKZnR0DqUM4+khkf+60HFQqKimBZ41O GpWenOjpJF06vWXJx6ne53P/sdpYna3Yh9kYveLMWrgn873gdVS2BPYroWQPhcxQ j8FQ/TYUcJyq1VEohzGMzcv/D5F9bKLVFzIGeGnwytFhspGcAad8f7oc6bXYjpg3 1KZoPk5Y3HhjR0aN8sdnG6UAFbI98LFbZxfR31UoaDOWQ8AvKGLa+kRa/mXHpIUp RiAUDg4gSiO+zFjhCN9FDe+hrXJ9Cgl3iBmIcbzWpOWfT+LuuadMSvQcN3RGDqus BADMJIzTu3vtT/xhem48w== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-07; repo=github.com/dkim2wg/interop; date=2026-10-18; sw=lmtpprox; action=sign d=themaw.net a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1793150518; d=themaw.net; mf=PHJhdmVuQHRoZW1hdy5uZXQ+; rt=PGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+; s=fm1:rsa-sha256:JlG7/+rVfYjOSBgmCM+ra+XMMWM6T2ucC1WWXxEcheLzXnc 7TZWBCUBaPh/fOi92ZzxHZZv8ylxrCUAeh3Zv9EyUinAzXtbEFxcgDuKWgdU2gbT UjmBzs7BEL48YAxF48XR43AdukkNuBQz7u68V+FcsE2Gzv1xR0u4gXtfH7W7Wjs+ b3z3rPp0Dkxj3LBlAibffGnMaYDLIdsEMQNlEiNvWBGRZoyIUQP3J4d3O0YeZU0V unZA6EO4aGUuODrho8Z6+2hewBwdb3lBA57Ln2Qt03D0PxFR7gtiS2SRvcNFRfFU 7Ig0m2LMdUuidCUOic0uwnaW6pcyQQSYVqGiiyA==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-07; repo=github.com/dkim2wg/interop; date=2026-10-18; sw=lmtpprox; action=mi-m=1; hc=13; hn=cc,content-transfer-encoding,content-type,date,feedback-id, from,in-reply-to,message-id,mime-version,references,subject,to, user-agent; Message-Instance: m=1; h=sha256:bLZaW/+c77h1LhtpnAtMkoSIjWiZ2pBNMO0v3iO12fE=:4cR+Jnw2vZTLedug2NT9bT/PNYuUzdhU9pnjK8Gk3b4=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTExjEu5Z4ShUEEPbIUBi9jvlntQl3xywqhol0VilT1H3riwx+R5F5xJP13Eevy37Q 0i2tM3JNLjjIE4RnafdrKckgTZgF7WVXIi2BOm3qqKixBS/Irug73Tiau0YR/vN5tre4hn maQ7bdbQdERoqsBHTuky/6kPN1uRRdMEQp7qfaGblPSG+4EBzlUBu4KVifRQGZl+JiSvgw 9mSbn8dIqXi2WXNiWFaTJHHZ4Jih2f4J8Zf8XQJs9Or+djBfP7qo+n/CcBwnndgEEsWDvn dde2XKLK1ANi3gu15BOxuI5tGRXcf4I/n59a/Jk8KMuRhC+UWXSiv/46euNQ6JSTIIAimv 7jcAW/tdVBGXJXklC1RRPUglHq4hH5Bc64PIl28tFEzC6NIzPjSltWekhutJo/tT2majGT sswf9kF/mQ7bfD6GGD2BLOWWsUXcYZgnu4j4D7tHPb/zynsKGK6m+AhMOPYjmUzMOzh5dT b4rWxbMHiL5nnjAdO5ldN4zD++TlD1rdyXqAHwBHPTOIS8FN/SKiiEb38SpBdbZorRtZ3g 6HKFrjuDJITZTWSsi/aiCUAXSktyenMIc8kN6yeNsZHz8HdWRAJlXYnV78lUl5wNp4dJzJ K2wtUluCHNuU9Ak5O20DPSdgweZAMliMgfRfP/R4THeQWT2Cq5n/XeaklCLw X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Oct 2026 21:21:52 -0400 (EDT) Message-ID: <5de6de037706e45ba88939e8f36e7dae48005e6c.camel@themaw.net> Subject: Re: [PATCH 0/2] kernfs, autofs: fix pipe lock cycles through sysfs stores From: Ian Kent To: Krystian Kaniewski , Greg Kroah-Hartman Cc: Tejun Heo , "Rafael J . Wysocki" , Danilo Krummrich , Alexander Viro , Christian Brauner , Jan Kara , Ingo Molnar , Peter Zijlstra , Andrew Morton , Jens Axboe , driver-core@lists.linux.dev, autofs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+002fb7b2d0bc53bf7e75@syzkaller.appspotmail.com Date: Wed, 28 Oct 2026 09:21:48 +0800 In-Reply-To: <083c2bb0-85b6-480e-afcb-bd2f386f2ddd@gmail.com> References: <6aa23178.f81106d8.2ab401.0006.GAE@google.com> <4f56c93a9fc5fee152364974773df0a319c84af9.camel@themaw.net> <083c2bb0-85b6-480e-afcb-bd2f386f2ddd@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44app2) X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 On Tue, 2026-10-27 at 01:57 +0100, Krystian Kaniewski wrote: > Hi Ian, >=20 Thanks for replying, ;) > On Tue, 2026-10-27 at 07:11 +0800, Ian Kent wrote: > > Commit 1e8c813b083c ("PM: hibernate: don't use early_lookup_bdev > > in resume_store") looks like it's been around for a while so I > > assume the reproducer should work on 7.2.12? >=20 > Yes. That commit entered v6.5-rc1, so 7.2.12 contains the relevant > code. >=20 > I used the unmodified C reproducer linked from the syzbot report: >=20 > https://syzkaller.appspot.com/text?tag=3DReproC&x=3D11c0f4c9580000 >=20 > I also used the configuration provided with the report: >=20 > https://syzkaller.appspot.com/text?tag=3DKernelConfig&x=3D7d012d9c67977ee= 4 >=20 > > What should I expect, a hang, it doesn't. >=20 > A permanent hang is not expected. The result to look for is this > lockdep warning in dmesg: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WARNING: possible circular loc= king dependency detected > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &pipe->mutex --> &of->mutex --= > &sbi->pipe_mutex >=20 > The reproducer records the first dependency by splicing into the > cgroup v1 devices.deny file. It records the opposite dependencies > through a normal write to /sys/power/resume. These operations use > different lock instances, so the exact reproducer reports a possible > cycle rather than deadlocking. >=20 > The write waits for an autofs daemon that never replies, but the C > wrapper kills the blocked child after five seconds and starts another > iteration. In my test the warning appeared in the first iteration. >=20 > The test needs lockdep and CONFIG_PROVE_LOCKING, the cgroup v1 > devices > controller, autofs, and working hibernation support. It must also run > as root. Without lockdep, the program can appear to do nothing > useful. Ok, I'll check on those, not sure about hibernation support in my VM ... >=20 > > Also it looks to me like the reproducer is trying exploit an > > invalid request similar to what I described earlier >=20 > Whether the string identifies a usable resume device is separate from > the autofs request. resume_store() first passes it to lookup_bdev(), > which performs a pathname lookup before the numeric fallback. >=20 > The reproducer changes its current directory to the root of a > detached > indirect autofs mount. It then opens /sys/power/resume using an > absolute path and writes the relative name > "0x0000000004000921". >=20 > The resulting lookup is therefore: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /0x00000000040009= 21 >=20 > For autofs, this is an ordinary lookup of a new immediate child of > the > indirect mount root, so it is a normal mount trigger. There is no > autofs mount under /sys/power. Right, enabling the autofs pr-debug logging and looking at the reproducer verified the exection flow for me. I didn't see a lockdep splat but my environment is probably not quite right. I'll check what I can and see if I can reproduce. >=20 > In parallel, I am preparing a revised patch following Tejun's > suggestion. It disables splice for writable opens of > /sys/power/resume and gives its of->mutex a separate lockdep class. >=20 > If you send your autofs change, I can run the same reproducer against > it and check both the request and the lockdep warning. >=20 > Thanks, > Krystian