siginfo & 32 bits compat, what is the story ?

siginfo & 32 bits compat, what is the story ?

[Benjamin Herrenschmidt]

Hi folks !

So I've been playing around the siginfo copy code for 32 bits
processes on ppc64 and found some interesting stuffs that I don't
know how to fix at this point.

So I rewrote the routine copying a siginfo to a 32 bits one in
a way that is similar to s390 (that's part of the ppc64 message
queue patch I sent earlier). However, I just noticed we also do
the opposite conversion for the sys32_rt_sigqueueinfo syscall,
and we do it "the old way" (based on signal number, which is
apparently incorrect).

Now my question: What to copy ? I suppose I need at least to
be consistent between the 2 functions between what is done for
a userland siginfo. Right now, I am not. I followed Stephen
suggestions and I'm copying the whole padding after the first
3 fields in the 64 -> 32 bits copy, but the opposite conversion
function that I just noticed will explicitely copy/convert some
fields (si_pid, si_uid and si_int).

I looked at x86-64, and they always copy/convert those 3 fields,
never copy the rest of the siginfo. I looked at s390 and they do
the opposite: just copy the rest of the structure...

So I suppose I need to choose between those 2 methods and be
consistent between the 32->64 and 64->32 routines, but which one ?

Ben.

Re: siginfo & 32 bits compat, what is the story ?

[Joe Korty]

On Mon, Apr 19, 2004 at 05:35:55PM +1000, Benjamin Herrenschmidt wrote:
> So I've been playing around the siginfo copy code for 32 bits
> processes on ppc64 and found some interesting stuffs that I don't
> know how to fix at this point.
> 
> I looked at x86-64, and they always copy/convert those 3 fields,
> never copy the rest of the siginfo. I looked at s390 and they do
> the opposite: just copy the rest of the structure...

I believe the x86_64 method is correct.

It might be worth moving this compatibility code to a
common place where all architectures could reference it.

Joe

Re: siginfo & 32 bits compat, what is the story ?

[Benjamin Herrenschmidt]

> I believe the x86_64 method is correct.
> 
> It might be worth moving this compatibility code to a
> common place where all architectures could reference it.

Hrm... I just heard the opposite: that is, the x86_64 code allows
some cruft to communicate between 32 and 64 bits, but breaks anything
that uses more than those 3 copied fields, even between 2 32 bits
applications.

I'm lost, I don't know in which way to fix ppc64 at this point...

Ben.

Re: siginfo & 32 bits compat, what is the story ?

[Benjamin Herrenschmidt]

> Note that there are several kinds of x86-64 codes: the original one
> and Joe's rewritten version in recent kernels. I don't know where
> you heard it is broken, but maybe they were describing the older
> code.

Discussing with Stephen, looking at the current code.

> If they were refering to the recent version I assume they 
> would have reported it to the maintainer. But they didn't ...
> 
> Anyways - i guess it's hard to make such a decision on hearsay.  I
> would suggest you start with the x86-64 version and when there are
> really problems you tell us about them and we fix them.
> 
> BTW there was a merged version from some PA-RISC person (with yet
> another rewritten siginfo copy function) discussed, but for some
> reason he dropped the ball. 

So I suppose the decision to actually copy _and_ convert those 3 fields
when moving a userland siginfo around is based on an analysis of what
userland usually does ? What bothers me is that any app that uses a
different siginfo layout will be broken between 32 bits and 32 bits
with this scheme, but maybe that just never happens ?

Ben.

Re: siginfo & 32 bits compat, what is the story ?

[Andi Kleen]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

>> I believe the x86_64 method is correct.
>> 
>> It might be worth moving this compatibility code to a
>> common place where all architectures could reference it.
>
> Hrm... I just heard the opposite: that is, the x86_64 code allows
> some cruft to communicate between 32 and 64 bits, but breaks anything
> that uses more than those 3 copied fields, even between 2 32 bits
> applications.

Note that there are several kinds of x86-64 codes: the original one
and Joe's rewritten version in recent kernels. I don't know where
you heard it is broken, but maybe they were describing the older
code.

If they were refering to the recent version I assume they 
would have reported it to the maintainer. But they didn't ...

Anyways - i guess it's hard to make such a decision on hearsay.  I
would suggest you start with the x86-64 version and when there are
really problems you tell us about them and we fix them.

BTW there was a merged version from some PA-RISC person (with yet
another rewritten siginfo copy function) discussed, but for some
reason he dropped the ball. 

-Andi