From: Tejun Heo <tj@kernel.org>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Christian Brauner <christian@brauner.io>,
Meta kernel team <kernel-team@meta.com>,
linux-kselftest@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] kernfs: fix up the unlocked attribute reads on the creation paths
Date: Thu, 3 Sep 2026 10:26:07 -1000 [thread overview]
Message-ID: <apnX34sTUnMngU5k@slm.duckdns.org> (raw)
In-Reply-To: <20260903040253.670020-3-shakeel.butt@linux.dev>
On Wed, Sep 02, 2026 at 09:02:53PM -0700, Shakeel Butt wrote:
> Two creation paths read a live node's attributes without holding
> kernfs_iattr_rwsem, which kernfs_iop_setattr() takes for writing. They
> do not want the same fix.
>
> kernfs_create_link() copies the target's ia_uid and then its ia_gid
> into the new link. A chown of the target between the two reads leaves
> the link with the old uid and the new gid, an owner the target never
> had, when copying the target's owner is the whole point. Read both
> fields under the rwsem.
>
> kernfs_new_node() reads the parent's ia_gid for S_ISGID inheritance,
> and that one does not care which value it gets: the node does not exist
> yet, so nothing orders a racing chown against the creation either way.
> Taking the rwsem there would only serialize creation under a set-gid
> parent against a chown of that parent, to pick between two answers that
> are both right. Mark the field read data_race() instead.
>
> The pointer that leads to it is a different matter: __kernfs_iattrs()
> publishes kernfs_node::iattr with try_cmpxchg(), so there is no
> unmarked write for that read to pair with, and both sides read it with
> READ_ONCE() like the rest of fs/kernfs does.
>
> The Fixes tag is for the symlink half. kernfs_create_link() has read
> the pair without a lock since it started copying the target's owner at
> all; only the name of the lock its writer takes has changed since. The
> data_race() is a marking rather than a fix.
>
> Fixes: 488dee96bb62 ("kernfs: allow creating kernfs objects with arbitrary uid/gid")
> Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Tejun Heo <tj@kernel.org>
> + if (attrs) {
> + /*
> + * Unlocked on purpose: the gid is inherited onto a
> + * node that does not exist yet, so nothing orders a
> + * racing chown against this creation, and either
> + * value is correct. The pointer above needs no such
> + * marking, __kernfs_iattrs() publishes it with
> + * try_cmpxchg().
> + */
> + gid = data_race(attrs->ia_gid);
Nit: READ_ONCE() is likely the better fit as it's an intentional lockless
read whose value is used.
Thanks.
--
tejun
next prev parent reply other threads:[~2026-09-03 20:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 4:02 [PATCH 1/3] kernfs: take kernfs_rename_lock for same-parent renames too Shakeel Butt
2026-09-03 4:02 ` [PATCH 2/3] kernfs: don't lose IN_DELETE_SELF when decoding a file handle Shakeel Butt
2026-09-03 20:23 ` Tejun Heo
2026-09-03 4:02 ` [PATCH 3/3] kernfs: fix up the unlocked attribute reads on the creation paths Shakeel Butt
2026-09-03 20:26 ` Tejun Heo [this message]
2026-09-03 21:15 ` Shakeel Butt
2026-09-03 4:31 ` [PATCH 1/3] kernfs: take kernfs_rename_lock for same-parent renames too Greg Kroah-Hartman
2026-09-03 5:37 ` Shakeel Butt
[not found] ` <6a990797.3e7a366d.3bd849.72d1SMTPIN_ADDED_BROKEN@mx.google.com>
2026-09-03 5:41 ` Greg Kroah-Hartman
2026-09-03 6:15 ` Shakeel Butt
2026-09-03 16:08 ` Shakeel Butt
2026-09-03 20:21 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apnX34sTUnMngU5k@slm.duckdns.org \
--to=tj@kernel.org \
--cc=christian@brauner.io \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox