[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200428074827.GA19846@lst.de>
Date: Tue, 28 Apr 2020 09:48:27 +0200
From: Christoph Hellwig <hch@....de>
To: Christophe Leroy <christophe.leroy@....fr>
Cc: Christoph Hellwig <hch@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Jeremy Kerr <jk@...abs.org>, linux-fsdevel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org,
"Eric W . Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH 2/7] signal: factor copy_siginfo_to_external32 from
copy_siginfo_to_user32
On Tue, Apr 28, 2020 at 09:45:46AM +0200, Christophe Leroy wrote:
>> I guess that might be a worthwhile middle ground. Still not a fan of
>> all these ifdefs..
>>
>
> Can't we move the small X32 specific part out of
> __copy_siginfo_to_user32(), in an arch specific helper that voids for other
> architectures ?
>
> Something like:
>
> if (!arch_special_something(&new, from)) {
> new.si_utime = from->si_utime;
> new.si_stime = from->si_stime;
> }
>
> Then the arch_special_something() does what it wants in x86 and returns 1,
> and for architectures not implementating it, a generic version return 0 all
> the time.
The main issue is that we need an explicit paramter to select x32,
as it can't just be discovered from the calling context otherwise.
The rest is just sugarcoating.
Powered by blists - more mailing lists