linux-kernel - Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit

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: <CA+55aFwPM3qWE7F7nwUVKphVTJb7WE7zPF5artdVw7Xq5Z1UgQ@mail.gmail.com>
Date:	Sun, 20 Jan 2013 18:39:09 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit

On Sun, Jan 20, 2013 at 6:30 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Neither do I, to be honest.  It might be saving us a few cycles on
> some architectures, but I'd like to see examples of that.  amd64
> doesn't seem to be one, at least...

I think that the inlining of the body should make it basically be
pretty much free even on architectures that would want to do something
about the casts.

.. and thinking about it, the architectures that do actually generate
code for casting to a narrower type should already have selected that
HAVE_SYSCALL_WRAPPERS option anyway, so the only reason *not* to
select it is for a n architecture that doesn't generate any extra
code.

And right now, that HAVE_SYSCALL_WRAPPERS does make it much harder to
think about the header file changes.

> FWIW, there's another bit of ugliness around that area - all these
> #define __SC_BLAH3, etc., all of the same form.  This stuff begs for
> something like
> #define __MAP1(m,t,a) m(t,a)
> #define __MAP2(m,t,a,...) m(t,a) __MAP1(m,__VA_ARGS__)
> #define __MAP3(m,t,a,...) m(t,a) __MAP2(m,__VA_ARGS__)
> #define __MAP4(m,t,a,...) m(t,a) __MAP3(m,__VA_ARGS__)
> #define __MAP5(m,t,a,...) m(t,a) __MAP4(m,__VA_ARGS__)
> #define __MAP6(m,t,a,...) m(t,a) __MAP5(m,__VA_ARGS__)
> #define __MAP(n,...) __MAP##n(__VA_ARGS__)
> with __MAP(x,__SC_DECL,__VA_ARGS__) instead of __SC_DECL##x(__VA_ARGS__)
> etc. in users...

Well, I can see both sides. The above is the nice and dense
declaration model with less duplication, but christ, it's hard for
people to wrap their minds around unless they've seen it a million
times. It really does take some getting used to, and the long-form can
be easier to understand.

That said, we have so many of those things now when it comes to the
syscall stuff that the dense form seems to be called for just to be
consistent.

So go wild if you have the energy for it. I'm not going to pull that
for 3.8, though.

                 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/