Messages in this thread | | | Subject | Re: Fix struct siginfo | From | Andreas Jaeger <> | Date | 19 Jan 2000 15:21:53 +0100 |
| |
>>>>> 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/
| |