Re: Fix struct siginfo

From: Andreas Jaeger (aj@suse.de)
Date: Wed Jan 19 2000 - 09:21:53 EST


>>>>> 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