linux-kernel - Re: [PATCH] ns: Wire up the setns system call for 2.6.40-rc1 or whatever

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 28 May 2011 10:55:55 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	Daniel Lezcano <dlezcano@...ibm.com>
Subject: Re: [PATCH] ns: Wire up the setns system call for 2.6.40-rc1 or whatever

On Fri, May 27, 2011 at 7:28 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
>
> 32bit and 64bit on x86 are tested and working.  The rest I have looked
> at closely and I can't find any problems.

So I really don't think this was even worth it. I applied the patch,
but I think that you should just have done the architecture you
tested, and left it to arch maintainers to add it as they will.

That's how we tend to do this, and it works. It also avoids surprises
when people then invariably end up having clashes due to system calls
being added. Even in just the 15 hours since you sent the email, I had
merged more code from ARM, and the patch no longer applied to my tree.
It's trivial to fix up, so that's not the problem, but the problem is
with different people adding system calls resulting in re-numbering.

In other words, it's simply better to strive to have *one* entity in
charge of picking the system call number, rather than do it like this.
Ergo: leave it to architecture maintainers to minimize the issue of
system call renumbering.

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/