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]
Message-ID: <20090226201905.GA8548@redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ