>>>>> 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- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:20 EST