Re: Fix struct siginfo

[Andreas Jaeger <aj at suse dot de>]

>>>>> Alan Cox writes:

>> The fix for struct siginfo in 2.3.39 was not necessary since uid_t was
>> already aligned on a 32bit boundary for ix86 and arm.  This patch

Alan> The other two bytes don't contain defined values for all 2.2.x/2.3.x kernels.
Alan> The memset to clear the other bits went in during 2.2.x so it isnt
Alan> safe to trust that an old kernel returns 0 for the padding. Earlier 2.2.x
Alan> hands back [Random.W}[uid.w]

And glibc relied on thisall the time, have a look at
<bits/siginfo.h>:
...
	 /* kill().  */
	struct
	  {
	    __pid_t si_pid;	/* Sending process ID.  */
	    __uid_t si_uid;	/* Real user ID of sending process.  */
	  } _kill;

With those older kernel we loose already with glibc :-(.  

Alan> Also the 16bit squashed uid format is important for the old binaries to get
Alan> correct data. You dont want uid 65536 being misinterpreted as uid 0 by
Alan> an old binary. The existing code hands back a plausible token, your change
Alan> appears not to do so.

What kind of old binaries?  glibc 2.1 has externally 32bit uids - and
realtime signals (which use siginfo) are not supported by libc5 AFAIK.

Alan> You are right that the field is big enough on most architectures (not m68k
Alan> I think as that pads to word alignment - a quirk I had much fun with when
Alan> doing mac68k sysv fs support).
m68k pads to 16bit.

Alan> You are wrong that it is safe to use the other bytes.
I'm not convinced.  Could you please check this again?  I don't see
another way to handle it portably.

With my patch programs using struct siginfo continue to work correctly
- and no recompilation is necessary.

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