On Tue, Jul 18, 2017 at 7:06 AM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
> struct siginfo is a union and the kernel since 2.4 has been hiding a union
> tag in the high 16bits of si_code using the values:
> __SI_KILL
> __SI_TIMER
> __SI_POLL
> __SI_FAULT
> __SI_CHLD
> __SI_RT
> __SI_MESGQ
> __SI_SYS
>
> While this looks plausible on the surface, in practice this situation has
> not worked well.
So on the whole I think we just need to do this, but the part I really
hate about this series is still this the siginfo_layout() part.
I can well believe that it is needed for the compat case. siginfo is a
piece of crap crazy type, and re-ordering fields for compat is
something we are always going to have to do.
But for the native case, the *only* reason we do not just copy the
siginfo as-is seems to be that it's just too big, due to other bad
design decisions in siginfo ("let's make sure it's big enough by
allocating 512 bytes for it).
And afaik, absolutely nobody uses more than about 36 bytes of that
512-byte _sifields union (and that one use is SIGILL with three
pointers and three integers and some padding.
So why don't we just say "screw this idiotic layout crap, and just
unconditionally copy that much smaller maximum of bytes"?
Leave that layout thing purely for compat handling.
Yes, yes, there's a couple of small gotchas's:
- "_sys_private" for posix timers, and it would have to be moved to
the end of the structure so that it doesn't get copied.
- make sure those 36 bytes are cleared when allocating the siginfo
(this should be trivial) so that we don't leak any other memory.
But on the whole, it looks pretty straightforward to just get rid of
those stupid layout things, and make them purely about compat stuff.
Please?
The si_code stuff clearly needs to be done regardless, so much of this
patch series looks good to me. But if we're doign this cleanup, can't
we please go that one extra step and get rid of the crazy "let's treat
the union as different types", and just treat it as a largely opaque
thing.
Pretty please?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
