[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c5f209a6263b4f039c5eafcafddf90ca@AcuMS.aculab.com>
Date: Thu, 1 Jun 2023 15:37:32 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Jan Kara' <jack@...e.cz>, Christian Brauner <brauner@...nel.org>
CC: Al Viro <viro@...IV.linux.org.uk>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Miklos Szeredi <miklos@...redi.hu>,
"Darrick J. Wong" <djwong@...nel.org>, Ted Tso <tytso@....edu>,
Jaegeuk Kim <jaegeuk@...nel.org>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
"linux-f2fs-devel@...ts.sourceforge.net"
<linux-f2fs-devel@...ts.sourceforge.net>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH v2 4/6] fs: Establish locking order for unrelated
directories
...
> > > + * Lock any non-NULL argument. The caller must make sure that if he is passing
> > > + * in two directories, one is not ancestor of the other
Not directly relevant to this change but is the 'not an ancestor'
check actually robust?
I found a condition in which the kernel 'pwd' code (which follows
the inode chain) failed to stop at the base of a chroot.
I suspect that the ancestor check would fail the same way.
IIRC the problematic code used unshare() to 'escape' from
a network natespace.
If it was inside a chroot (that wasn't on a mount point) there
ware two copies of the 'chroot /' inode and the match failed.
I might be able to find the test case.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists