[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200426074039.GA31501@lst.de>
Date: Sun, 26 Apr 2020 09:40:39 +0200
From: Christoph Hellwig <hch@....de>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Hellwig <hch@....de>,
Alexander Viro <viro@...iv.linux.org.uk>,
Jeremy Kerr <jk@...abs.org>, Arnd Bergmann <arnd@...db.de>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
linuxppc-dev@...ts.ozlabs.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 2/7] signal: factor copy_siginfo_to_external32 from
copy_siginfo_to_user32
On Sat, Apr 25, 2020 at 09:47:24PM -0700, Andrew Morton wrote:
> I looked at fixing it but surely this sort of thing:
>
>
> int copy_siginfo_to_user32(struct compat_siginfo __user *to,
> const struct kernel_siginfo *from)
> #if defined(CONFIG_X86_X32_ABI) || defined(CONFIG_IA32_EMULATION)
> {
> return __copy_siginfo_to_user32(to, from, in_x32_syscall());
> }
> int __copy_siginfo_to_user32(struct compat_siginfo __user *to,
> const struct kernel_siginfo *from, bool x32_ABI)
> #endif
> {
> ...
>
>
> is too ugly to live?
I fixed it up in my earlier versions, but Eric insisted to keep it,
which is why I switched to his version given that he is the defacto
signal.c maintainer.
Here is what I would have preferred:
https://www.spinics.net/lists/kernel/msg3473847.html
https://www.spinics.net/lists/kernel/msg3473840.html
https://www.spinics.net/lists/kernel/msg3473843.html
Powered by blists - more mailing lists