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.
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
> 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.
Benjamin Herrenschmidt <[email protected]> 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
> 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.