TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.

[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]

Hi, this is your Linux kernel regression tracker. CCing the regression
mailing list, as it should be in the loop for all regressions, as
explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

On 04.09.22 16:05, David Laight wrote:

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 change
the behaviour of other process threads.

I don't know how much is broken, but the following fails.

Create a network namespace (eg "test").
Create a 'bond' interface (eg "test0") in the namespace.

Then /proc/net/bonding/test0 only exists inside the namespace.

However if you run a program in the "test" namespace that does:
- create a thread.
- change the main thread to in "init" namespace.
- try to open /proc/net/bonding/test0 in the thread.
then the open fails.

I don't know how much else is affected and haven't tried
to bisect (I can't create bonds on my normal test kernel).

The test program below shows the problem.
Compile and run as:
# ip netns exec test strace -f test_prog /proc/net/bonding/test0

The second open by the child should succeed, but fails.

I can't see any changes to the bonding code, so I suspect
it is something much more fundamental.
It might only affect /proc/net, but it might also affect
which namespace sockets get created in.
IIRC ls -l /proc/n/task/*/ns gives the correct namespaces.

	David


#define _GNU_SOURCE

#include <fcntl.h>
#include <unistd.h>
#include <poll.h>
#include <pthread.h>
#include <sched.h>

#define delay(secs) poll(0,0, (secs) * 1000)

static void *thread_fn(void *file)
{
        delay(2);
        open(file, O_RDONLY);

        delay(5);
        open(file, O_RDONLY);

        return NULL;
}

int main(int argc, char **argv)
{
        pthread_t id;

        pthread_create(&id, NULL, thread_fn, argv[1]);

        delay(1);
        open(argv[1], O_RDONLY);

        delay(2);
        setns(open("/proc/1/ns/net", O_RDONLY), 0);

        delay(1);
        open(argv[1], O_RDONLY);

        delay(4);

        return 0;
}

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:

#regzbot ^introduced v5.10.105..v5.10.132
#regzbot title setns() affecting other threads (also in 6.0-rc)
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/

Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.