[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6204a74ef41a4463a790962d0409d0bc@AcuMS.aculab.com>
Date: Tue, 6 Sep 2022 10:48:16 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Alexey Dobriyan' <adobriyan@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Eric Dumazet <edumazet@...gle.com>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: RE: setns() affecting other threads in 5.10.132 and 6.0
From: Alexey Dobriyan
> Sent: 05 September 2022 18:33
> > > -----Original Message-----
> > > From: David Laight <David.Laight@...LAB.COM>
> > > Sent: 04 September 2022 15:05
> > >
> > > Sometime after 5.10.105 (5.10.132 and 6.0) there is a change that
> > > makes setns(open("/proc/1/ns/net")) in the main process changes
> > > the behaviour of other process threads.
>
> Not again...
I've realised what is going on.
It really isn't obvious at all.
Quite possibly the last change did fix it - even though
it broke our code.
/proc/net is a symlink to /proc/self/net.
But that isn't what the code wants to open.
What it needs is /proc/self/task/self/net.
But there isn't a 'self' in /proc/self/task.
Which makes it all a bit tedious (especially without gettid() in glibc).
(This is a busybox/buildroot system, maybe I could add it!)
I'd probably have noticed earlier if the /proc/net
symlink didn't exist.
I guess that is for compatibility with pre-netns kernels.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists