linux-kernel - Re: [GIT] writable

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]

Message-ID: <AANLkTimT6++6MogcBoop-fPEguh-fkOt6SQGfUQrpb5u@mail.gmail.com>
Date:	Tue, 10 Aug 2010 09:24:18 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jiri Slaby <jslaby@...e.cz>, Chris Metcalf <cmetcalf@...era.com>,
	Arnd Bergmann <arnd@...db.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT] writable_limits for 2.6.36

On Tue, Aug 10, 2010 at 9:01 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Ok, so the code looks fine, and I don't have any real objections any
> more. I don't know how much use this will get, but it doesn't appear
> to be "wrong" in any way. So I was going to pull it.
>
> However, in the meantime we have commit 5360bd776f73 ("Fix up the
> "generic" unistd.h ABI to be more useful") that clashes with it. Now,
> the conflict is trivial to resolve, and I could do that easily - it's
> not a technical problem. But that commit code comments say
>
>  + * Architectures may provide up to 16 syscalls of their own
>  + * starting with this value.
>  + */
>  +#define __NR_arch_specific_syscall 244
>
> and the new writable rlimits syscall is obviously 244.

I should have clarified that. The new asm-generic prlimit64 system
call was added at the end (as 244), not in general. Only tilera and
score use that "generic" unistd.h file currently, and score doesn't do
any other system calls, which is why it's really only arch/tile that
is affected by this. Of course, new architectures are likely to use
that model, but we don't care about those yet.

I still think that starting the arch-specific ones at 512 is likely
the right model. I just wanted to clarify in case somebody thought
that x86 put a new system call at 244.

                        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/