Re: siginfo broken in glibc

[Andreas Jaeger <aj at suse dot de>]

>>>>> Chris Wing writes:

Chris> Andreas:
>> With the 32bit UID patches the siginfo type has been changed.  But it
>> seems that this was always broken :-(.
>> 
>> On ix86 and m68k, we've got the following struct as part of struct siginfo:
>> /* kill().  */
>> struct
>> {
>> __pid_t si_pid;     /* Sending process ID.  */
>> __uid_t si_uid;     /* Real user ID of sending process.  */
>> } _kill;
>> 
>> Please note that __uid_t is 32bit.  This worked before on a little
>> endian machine - by accident, I suppose.

Chris> Okay, I see what you are getting at. Are you saying that due to alignment,
Chris> the kernel structure has always had room for 32 bits, and glibc has always
Chris> picked up all 32 bits properly?
This is AFAIK true for ix86 - a chance for that platform wasn't
necessary.  But it's not true for m68k.

Chris> If so, great, we'll just take out the _uid32 field in the kernel and
Chris> change si_uid to be the full 32 bit UID.

Chris> If not, then we can change the kernel structure to leave room for glibc's
Chris> (erroneous) padding.

Chris> Or are you saying that glibc's structure member _uid overlaps the next
Chris> field in some of the kernel structures?
On m68k it does - but this has never worked before, so just ignore it
- or let's synch those structures.

>> The kernel has now:
>> struct {
>> pid_t _pid;		/* sender's pid */
>> old_uid_t _uid;		/* backwards compatibility */
>> uid_t _uid32;		/* sender's uid */
>> } _kill;
>> 
>> Since the kernel delivers siginfo directly to the process without
>> going through glibc, this will break old programs.  I don't see
>> directly a way to fix this so that a program using struct siginfo can
>> access the uid both under Linux 2.3.39+ and on older kernels.

Chris> That is the main problem. The only thing I can imagine is something
Chris> incredibly ugly like having glibc detect whether it is running on a old
Chris> kernel, and if so, catch all the signals itself and translate the
Chris> structures if it is running on an old kernel.

Chris> On the bright side, I don't think that there are many programs that use
Chris> real-time signals and pay attention to the uid field, so it may not be too
Chris> bad to break it now.
We should do it fast - but we should think good about it.

Chris> If glibc is broken (fields do not line up with the kernel), we are going
Chris> to have to break old applications anyway.
Exactly.
>> Please note that ix86 aligns on 32bit but m68k aligns on 16bit so that
>> the kernel and glibc declarations are different.

Chris> What about all the other architectures?

I'm not sure.  Phil and Jakub: What's the alignment on Sparc32 and
Arm?  Could you check what needs to be done for these architectures?

I'm preparing a patch for the kernel headers now to see if we can
settle the problem.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de