MIPS MSA sigcontext changes in 3.15

MIPS MSA sigcontext changes in 3.15

[Joseph S. Myers]

Reviewing changes in Linux 3.15 for anything for which glibc changes would 
be appropriate, I don't see how the MSA sigcontext changes are supposed to 
work with existing binaries.

The sigcontext structure isn't used on its own - it's part of ucontext, 
which is passed to signal handlers, and it's not at the end of ucontext, 
but followed by the signal mask.  So existing binaries will expect the 
signal mask at a particular offset in the ucontext.  As far as I can see, 
extending sigcontext requires a new sigaction flag that could be used to 
opt in, for a particular signal handler, to receiving the new-layout 
ucontext (so new symbol versions of sigaction in glibc could then pass 
that flag to the kernel, but existing binaries would continue to get 
old-layout ucontext from the kernel), or else putting the new data at the 
end of ucontext rather than in the main sigcontext structure (though I 
don't know if that would have other issues).

-- 
Joseph S. Myers
joseph-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org

Re: MIPS MSA sigcontext changes in 3.15

[Joseph S. Myers]

On Tue, 17 Jun 2014, Joseph S. Myers wrote:

> signal mask at a particular offset in the ucontext.  As far as I can see, 
> extending sigcontext requires a new sigaction flag that could be used to 
> opt in, for a particular signal handler, to receiving the new-layout 
> ucontext (so new symbol versions of sigaction in glibc could then pass 
> that flag to the kernel, but existing binaries would continue to get 
> old-layout ucontext from the kernel), or else putting the new data at the 

And a new flag would itself be problematic - signal handlers would need 
wrapping with userspace code to convert structure layout when new-version 
sigaction is used on an older kernel.  That suggests putting the new data 
at the end of ucontext is to be preferred (but in any case it would be 
best to revert the incompatible changes until something compatible with 
existing userspace can be produced).

-- 
Joseph S. Myers
joseph-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org

Re: MIPS MSA sigcontext changes in 3.15

[Paul Burton]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

On Tue, Jun 17, 2014 at 03:44:36PM +0000, Joseph S. Myers wrote:
> On Tue, 17 Jun 2014, Joseph S. Myers wrote:
> 
> > signal mask at a particular offset in the ucontext.  As far as I can see, 
> > extending sigcontext requires a new sigaction flag that could be used to 
> > opt in, for a particular signal handler, to receiving the new-layout 
> > ucontext (so new symbol versions of sigaction in glibc could then pass 
> > that flag to the kernel, but existing binaries would continue to get 
> > old-layout ucontext from the kernel), or else putting the new data at the 
> 
> And a new flag would itself be problematic - signal handlers would need 
> wrapping with userspace code to convert structure layout when new-version 
> sigaction is used on an older kernel.  That suggests putting the new data 
> at the end of ucontext is to be preferred (but in any case it would be 
> best to revert the incompatible changes until something compatible with 
> existing userspace can be produced).
> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.com
> 

True. Oops. I hadn't realised this...

I wonder if the sensible thing is to switch to sigcontext merely
containing a pointer to another struct holding FP state, much like x86.
Only in response to a flag as you describe of course. That way the
kernel could avoid the games it currently plays with splitting the
vector registers into 64b pieces, and it would probably be more open
to wider vector registers if they appear in the future.

Anyway, I agree with reverting the sigcontext change (eec43a224cf1
"MIPS: Save/restore MSA context around signals") in the meantime.

Given:

 - This issue.

 - A couple of other MSA fixes I have pending cleanup.

 - The fact that the only CPU the kernel supports which has MSA is the
   P5600, and since that is 32b it can't actually make use of MSA
   without the experimental CONFIG_MIPS_O32_FP64_SUPPORT option. Thus
   MSA isn't actually being used yet beyond a few small groups who
   accepted that big shouty experimental warning.

...I wonder if it makes sense to disable MSA support by default for the
moment also.

Thanks,
    Paul

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: MIPS MSA sigcontext changes in 3.15

[Matthew Fortune]

Joseph S. Myers <joseph-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> writes:
> On Tue, 17 Jun 2014, Joseph S. Myers wrote:
> 
> > signal mask at a particular offset in the ucontext.  As far as I can see,
> > extending sigcontext requires a new sigaction flag that could be used to
> > opt in, for a particular signal handler, to receiving the new-layout
> > ucontext (so new symbol versions of sigaction in glibc could then pass
> > that flag to the kernel, but existing binaries would continue to get
> > old-layout ucontext from the kernel), or else putting the new data at the
> 
> And a new flag would itself be problematic - signal handlers would need
> wrapping with userspace code to convert structure layout when new-version
> sigaction is used on an older kernel.  That suggests putting the new data
> at the end of ucontext is to be preferred (but in any case it would be
> best to revert the incompatible changes until something compatible with
> existing userspace can be produced).

An attempt was made to appropriately version the sigcontext structure to
allow readers to determine whether the MSA part of the context was present
or not but this only helps the sigcontext structure and not necessarily
the impact that has on the overall ucontext. On the face of it then it
does seem better to have the extra context at the end of ucontext as it
does indeed look broken for existing glibc versions.

A brief scan of how other architectures have handled extending ucontext
shows a wide variety of solutions although adding to the end of ucontext
seems to be the underlying theme.

Thanks for finding this.

Regards,
Matthew

Re: MIPS MSA sigcontext changes in 3.15

[Paul Burton]

On Tue, Jun 17, 2014 at 03:44:36PM +0000, Joseph S. Myers wrote:
> On Tue, 17 Jun 2014, Joseph S. Myers wrote:
> 
> > signal mask at a particular offset in the ucontext.  As far as I can see, 
> > extending sigcontext requires a new sigaction flag that could be used to 
> > opt in, for a particular signal handler, to receiving the new-layout 
> > ucontext (so new symbol versions of sigaction in glibc could then pass 
> > that flag to the kernel, but existing binaries would continue to get 
> > old-layout ucontext from the kernel), or else putting the new data at the 
> 
> And a new flag would itself be problematic - signal handlers would need 
> wrapping with userspace code to convert structure layout when new-version 
> sigaction is used on an older kernel.  That suggests putting the new data 
> at the end of ucontext is to be preferred (but in any case it would be 
> best to revert the incompatible changes until something compatible with 
> existing userspace can be produced).
> 
> -- 
> Joseph S. Myers
> joseph-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org
> 

True. Oops. I hadn't realised this...

I wonder if the sensible thing is to switch to sigcontext merely
containing a pointer to another struct holding FP state, much like x86.
Only in response to a flag as you describe of course. That way the
kernel could avoid the games it currently plays with splitting the
vector registers into 64b pieces, and it would probably be more open
to wider vector registers if they appear in the future.

Anyway, I agree with reverting the sigcontext change (eec43a224cf1
"MIPS: Save/restore MSA context around signals") in the meantime. I'll
submit a patch as soon as I can.

Given:

 - This issue.

 - A couple of other MSA fixes I have pending cleanup.

 - The fact that the only CPU the kernel supports which has MSA is the
      P5600, and since that is 32b it can't actually make use of MSA
   without the experimental CONFIG_MIPS_O32_FP64_SUPPORT option. Thus
   MSA isn't actually being used yet beyond a few small groups who
   accepted that big shouty experimental warning.

...I wonder if it makes sense to disable MSA support by default for the
moment also.

Thanks,
    Paul