lkml.org 
[lkml]   [2020]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] x86/signals: Fix save/restore signal stack to correctly support sigset_t
(Sorry, resending as Gmail decided to ignore "Plaintext mode")

Thanks Al. I want to understand the nuance, so please bear with me as
I reason this out. The cast in stone nature of this is due to both
the need to keep userspace and kernel space in sync (ie, you'd have to
coordinate libc and kernel changes super tightly to pull this off),
and any change in the size of struct rt_sigframe would break backwards
compatibility with older binaries, is that correct?

Thanks, appreciate the help here.
--Walt


On Sat, Nov 28, 2020 at 6:19 PM Walt Drummond <walt@drummond.us> wrote:
>
> Thanks Al. I want to understand the nuance, so please bear with me as I reason this out. The cast in stone nature of this is due to both the need to keep userspace and kernel space in sync (ie, you'd have to coordinate libc and kernel changes super tightly to pull this off), and any change in the size of struct rt_sigframe would break backwards compatibility with older binaries, is that correct?
>
> Thanks, appreciate the help here.
> --Walt
>
>
> On Fri, Nov 27, 2020 at 9:23 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>>
>> On Thu, Nov 19, 2020 at 02:11:33PM -0800, Walt Drummond wrote:
>> > The macro unsafe_put_sigmask() only handles the first 64 bits of the
>> > sigmask_t, which works today. However, if the definition of the
>> > sigset_t structure ever changed,
>>
>> ... existing userland would get fucked over, since sigset_t is
>> present in user-visible data structures. Including the ones
>> we are using that thing for - struct rt_sigframe, for starters.
>>
>> Layout of those suckers is very much cast in stone. We *can't*
>> change it, no matter what we do kernel-side.
>>
>> NAKed-by: Al Viro <viro@zeniv.linux.org.uk>

\
 
 \ /
  Last update: 2020-11-29 03:55    [W:0.065 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site