linux-kernel - Re: [RFC][PATCH] signals: don't copy siginfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Feb 2009 21:19:05 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Vegard Nossum <vegard.nossum@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] signals: don't copy siginfo_t on dequeue

On 02/26, Vegard Nossum wrote:
>
> 2009/2/26 Ingo Molnar <mingo@...e.hu>:
> >
> > I.e. shouldnt we have seen a speedup, due to not having to copy
> > the siginfo structure?

I am puzzled by these numbers too. I can't understand how this patch
can make any difference.

> Actually, no. Because copy_siginfo() does not copy the whole (128
> byte) structure if the signal was generated by the user, just probably
> the first 24 bytes or so. So I would expect the "kernel generated
> signal" path to be faster, but that is not tested by my SIGUSR test.
>
> Besides, I think there is a small overhead in now having an extra
> level of indirection for getting our hands on the signal number.

But this all is nothing compared to the "real work" we have to do
in order to handle the signal? setup_rt_frame, sys_rt_sigreturn...

> But we might able to speed up the user->user case a little bit by
> fixing sys_kill() not to use copy_siginfo() too.

Yes. It would really, really nice to preallocate siginfo in sys_kill/etc
and avoid the GFP_ATOMIC allocation in send_signal().

Unfortunaltely, this is not easy too. Because we can send the signal
to pgrp or to all tasks.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/