Re: siginfo_t fracturing, especially for 64/32-bit compatibility mode

[Joe Korty <joe.korty@ccur.com>]

I decided to do a more systematic search.

The below table summarizes all user-mode si_code values declared
and sent by either the kernel or by glibc.

Method was simple grep.  Therefore tricky uses were not accounted
for.

  code name	value	glibc-2.3.2 send-usage		2.6.1-rc2 send-usage
  ------------	------	----------------------------	--------------------
  SI_ASYNCNL	-6	si_pid, si_uid, si_value	never sent
  SI_TKILL	-6	never sent			si_pid, si_uid
  SI_SIGIO	-5	never sent			never sent
  SI_ASYNCIO	-4	si_pid, si_uid, si_value	si_addr
  SI_MESGQ	-3	never sent			never sent
  SI_QUEUE	-1	si_pid, si_uid, si_value	never sent

Observations:

  glibc only sends siginfo_t's with si_pid, si_uid, and si_value set.
  This makes trivial the conversion of 32bit user-space-originated
  siginfo_t's to the 64-bit form.

  The SI_ASYNCNL and SI_TKILL values collide but this collision is
  conversion-safe, as the fields used are compatible.  However
  applications may on occasion have trouble determining which
  subsystem sent a received siginfo_t of this type.

  SI_ASYNCIO uses are incompatible.  This prevents the kernel from
  being able to determine which fields to convert when a 64-bit
  siginfo_t of this type is to be sent to a 32-bit application.
  
  SI_SIGIO is not used by either the kernel or glibc.  This was
  somewhat suprising given the extensive coverage of SI_SIGIO in the
  man pages.

  The kernel likes to send user siginfo_t's to applications, rather
  the restrict itself to kernel siginfo_t types.  This is a misuse of
  the user-siginfo_t concept, though (so far) largely harmless.

Joe