Re: siginfo_t fracturing, especially for 64/32-bit compatibility mode
From: Joe Korty
Date: Sat Jan 03 2004 - 15:16:38 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/