On 2/5/26 8:20 PM, Waiman Long wrote:
On 2/5/26 6:53 PM, Al Viro wrote:
On Wed, Feb 04, 2026 at 11:45:17PM -0500, Waiman Long wrote:
@@ -70,6 +74,8 @@ void chroot_fs_refs(const struct path *old_root,
const
struct>
count++;
path_get(new_root);
}
+ count += fs->pwd_xrefs;
+ fs->pwd_xrefs = 0;
write_sequnlock(&fs->seq);
Nope - you only need that for threads that have ->pwd equal to old_root.
Incidentally, I'd forgotten about that sucker - it kills the idea of
fdget-like tricks dead, more's the pity. Third-party modification of
task->fs->pwd (under task->lock and task->fs->seq), possible even with
task->fs->users == 1.
Yes, I am aware of that when I took a further look at the patch that I
sent out yesterday. I am testing the updated patch now and is trying
to figure out why I get a warning from mntput_no_expire_slowpath()
with a count of -1 when doing an umount. It is off by 1 somewhere. I
will post the patch once I resolve this bug.
I now know why there are warnings. The problem is in the copy_mnt_ns()
function in fs/namespace.c:
__latent_entropy
struct mnt_namespace *copy_mnt_ns(u64 flags, struct mnt_namespace *ns,
struct user_namespace *user_ns, struct fs_struct *new_fs)
{
:
if (new_fs) {
if (&p->mnt == new_fs->root.mnt) {
new_fs->root.mnt = mntget(&q->mnt);
rootmnt = &p->mnt;
}
if (&p->mnt == new_fs->pwd.mnt) {
new_fs->pwd.mnt = mntget(&q->mnt);
pwdmnt = &p->mnt;
}
}
It is replacing the fs->pwd.mnt with a new one while pwd_refs is 1. I
can make this work with the new fs_struct field. I do have one question
though. Do we need to acquire write_seqlock(&new_fs->seq) if we are
changing root or pwd here or if the new_fs are in such a state that it
will never change when this copying operation is in progress?
Thanks in advance for your advice.
Cheers,
Longman
