This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: siginfo broken in glibc


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.

Okay, I see what you are getting at. Are you saying that due to alignment,
the kernel structure has always had room for 32 bits, and glibc has always
picked up all 32 bits properly?

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

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

Or are you saying that glibc's structure member _uid overlaps the next
field in some of the kernel 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.

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

On the bright side, I don't think that there are many programs that use
real-time signals and pay attention to the uid field, so it may not be too
bad to break it now.

If glibc is broken (fields do not line up with the kernel), we are going
to have to break old applications anyway.

> Please note that ix86 aligns on 32bit but m68k aligns on 16bit so that
> the kernel and glibc declarations are different.

What about all the other architectures?

-Chris

wingc@engin.umich.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]