Linux-kernel mailing list archive 1999-37,: Re: [PATCH] 2.3.18: siginfo data available for all signals

# Re: [PATCH] 2.3.18: siginfo data available for all signals

Jakub Jelinek (jj@sunsite.ms.mff.cuni.cz)
Wed, 15 Sep 1999 16:05:25 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Byeong-ryeol Kim: "2.3.18ac4 patch about pcmcia module and netfilter"
- Previous message: Mooneer Salem: "[PATCH] extra memory checking in tty_io.c (2.2.12)"
- In reply to: Alan Cox: "Re: [PATCH] 2.3.18: siginfo data available for all signals"

On Wed, Sep 15, 1999 at 02:31:31PM +0100, Alan Cox wrote:
> > > The last few times I have sent in this patch I have received zero
> > > reactions. On the other hand the patch does not seem to make it into
> > > kernels. Something must be wrong, however I don't know what it is.
> >
> > Did you miss Linus' announcement? He is on holiday for 2 weeks starting
> > a couple of days ago. Patches will be discarded during that time.

AFAIK he has sent this exact patch several times before Linus' announcement.

>
> He also missed the fact the security fix part is in 2.3.18ac and 2.2.13pre8

Is it? I can see a single memset(&info, 0, sizeof(info)); there (2.3.18ac4).
There are tens of similar places around the kernel (even in signal.c).
I was planning to fix this once his patch goes in (some weeks ago I've even
sent a patch to l-k).
There are IMHO two approaches how to solve it:
either make sure a 128byte memset is before every siginfo_t setup sequence,
or make the arch signal handlers understand a little bit the siginfo_t
structure and for the well known si_codes they just put_user the fields
related to that si_code as opposed to copy_to_user the whole structure
and only operate with the full 128byte siginfo_t if it came from
sigqueueinfo.
IMHO the latter has advantages in speeding things up (because you will
eliminate most of the 128byte memsets and e.g. copy only 5 32bit words
instead of 128 bytes to userland).

>
> The siginfo stuff seems odd. Its not how non posix rt signals work

As far as I understood rth wanted to do it that way, at least the comment in
signal.c
/* XXX: As an extension, support queueing exactly
one non-rt signal if SA_SIGINFO is set, so that
we can get more detailed information about the
cause of the signal. */
makes me think it.
It makes a lot of sense to use siginfo_t for passing stuff like segfault
address, segfault reason and the like and other Unices do it that way.
What's so odd about that?

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.3.18 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________

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

- Next message: Byeong-ryeol Kim: "2.3.18ac4 patch about pcmcia module and netfilter"
- Previous message: Mooneer Salem: "[PATCH] extra memory checking in tty_io.c (2.2.12)"
- In reply to: Alan Cox: "Re: [PATCH] 2.3.18: siginfo data available for all signals"