From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=82.195.75.108 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793883983; b=x4AtBW9T59j2nOtFBtSmUOegOMw0steP21gNzzJJ6ZSkc4GwGw7iGcY+YiJzMOghKZQ7 LNxZ8Le0ZgRwK5tEhKXk9riQhFbCyf0TMANg1qScQCmsQuD1tQKOLZ+AyMsvYaI4QXkhu cJnBSXaCVuy6+vwzoAwjFrnT2gBoAoYdBIoIYHX2xlVw/WeDWmrUuzTIxBsob1tRO8VzM 6gq5P+GNu6mwmPs47Dfu6HcS8LCafqYD3pf3WcyiIbCRzTZVnq6Chh9crMVyW42U24iMU VzckuvZtXHtoFzsX2qHMZohifwnfvKZZZhRgvXsnMjLCEbsHRd6+XLrdzpwtNO1N4rg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793883983; h=DMARC-Filter:DKIM-Signature:Received:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:X-Debian-User; bh=RhwkgWcMfTSbblcb5EByJLqZmOdOM+7mGzL2NSdO9CM=; b=f2iZSGme5z/+QjorGG1IFbNPPbXlkaD33F4Dvtu4DCX7ijEr2nkLxmsTcVLMTZTjG0UQ SbJTRM2IWiXBJWUbB/fc8dW/X/mmhnVrq8IltjyBcqVNnCQtv05y7BULT6rZq4fiaYWQC cfUefQ9QoJOVHPLM2FJGw2hXZ4PY2wyuSJiyIdLQ+vXJusKkO1GyMt48yA4ldXIfayXxt +0Su+0YDy3ZbZP3X3d2KR859+NS7lWe8vlta4aL5RFMdQHGO7kNbSm7owS2Yl9p2zE8lo /xTZxTHeK3oWztuWpIfj5Q4x3E7vzLT+8svMLAh95YPyFSXZlZC7IADSqUhKpD8vTKQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass header.d=debian.org header.i=@debian.org header.a=rsa-sha256 header.s=smtpauto.stravinsky header.b=MbmIKvHu; arc=none smtp.remote-ip=82.195.75.108 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5FB78606A32D for ; Thu, 5 Nov 2026 13:06:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 5FB78606A32D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=debian.org header.i=@debian.org header.a=rsa-sha256 header.s=smtpauto.stravinsky header.b=MbmIKvHu DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=RhwkgWcMfTSbblcb5EByJLqZmOdOM+7mGzL2NSdO9CM=; b=MbmIKvHunezOQS9VvH67/Bp7zZ YuG3l6uCnJc+dP4tYMw24gT0BU9d+op/tMICK+xRI1qTvXo2Xx9Rgeh0iYNbidSGO0fHU5gkwDSOO cwCu2U8VgbB13fJlkbDYo2/L420geXqTpYMF4Sg7DT8FXgOk0tWXQ78aGxkf+No8Hnu8pjnbGGt4f RvWaMg+YkqUjwxKMYWyVRAhGM0kCATiihk+3BGtPR09XUMEDPfnu9vni3bSGWxK7Xj3M5GWU3YQle 0MpwK5YpmjHQKTOLL88RaYMyI7s76v11I12yHebXmxg1AdsFafi71O1KZo2dgVFy/5xPeecUl4R2v S07KHeOA==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1xOxAV-008WBI-2B; Thu, 05 Nov 2026 13:06:15 +0000 Date: Thu, 5 Nov 2026 05:06:11 -0800 From: Breno Leitao To: Edward Adam Davis Cc: syzbot+4fae162886e497f72228@syzkaller.appspotmail.com, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, a.hindborg@kernel.org Subject: Re: [PATCH] configfs: Delay the fop setting to prevent noise generated by open Message-ID: References: <6ad65cac.5a04d468.191e0a.001c.GAE@google.com> <20261021062535.55494-1-eadavis@sina.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261021062535.55494-1-eadavis@sina.com> X-Debian-User: leitao Hello Edward, > The root cause is a race condition between open and mkdir. Add a revalidate > for cached dentries to prevent open from accessing directories that are not > yet ready. Thanks for chasing this one. The analysis matches what I see: a lookup holds the dentry of the half-built group, d_delete() can only unhash it, and the BUG_ON() in create_default_group() fires. The fix has a side effect, though: > + if (flags & LOOKUP_RCU) > + return -ECHILD; > + > + if (!inode) > + return -ECHILD; > + > + if (!configfs_dirent_is_ready(parent_sd)) > + return -ECHILD; -ECHILD only means "retry in ref-walk" when LOOKUP_RCU is set. In ref-walk, lookup_fast() and lookup_dcache() hand it back as is, so it reaches userspace, and mkdir() and open() now fail with ECHILD when they race with a lookup. With the syzbot setup (threads opening ports/1, ports/1/subsystems and ports/1/ana_groups while mkdir(ports/1) runs under fail-nth), mkdir() returned ECHILD in 2 to 11 of ~220 attempts per run, over 11 runs. The hook also takes every configfs lookup out of RCU-walk. Returning 0 instead would not help. The VFS would d_invalidate() the dentry of a default group, and configfs_lookup() cannot recreate pinned dentries. I think the BUG_ON() itself is the bug. It assumes nobody else holds the dentry of a default group while it is built, but a lookup can find it in the dcache. The error path already copes with that: d_delete() unhashes the busy dentry, the inode is S_DEAD, and lookup, open, mkdir and symlink all refuse a group that is not ready. Thanks, --breno