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:	Mon, 13 Aug 2007 12:26:15 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Roland McGrath <roland@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Davide Libenzi <davidel@...ilserver.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michael Kerrisk <mtk-manpages@....net>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH 3/4] signalfd: fix interaction with posix-timers

On 08/12, Roland McGrath wrote:
>
> This only affects signalfd and so the core change seems ok vs status quo.
> 
> I think it would be better overall not to have anyone like signalfd calling
> dequeue_signal in its current form at all.  (The function is too much an
> internal piece of the core signals code.  The SIGNAL_STOP_DEQUEUED code
> applying for signalfd calls is probably another problem, for example.)

I agree, the "tsk != current" case is not nice. We can forbid fetching
signals from another thread group and remove it, this is very easy.
Until then, we can't avoid it without the code duplication.

But SIGNAL_STOP_DEQUEUED code should be OK, afaics. We only need it to
make sure do_signal_stop() can't miss SIGNAL_STOP_CONTINUED/GROUP_EXIT.

Can't we remove SIGNAL_STOP_DEQUEUED, btw?

	dequeue_signal:

		if (sig_kernel_stop(sig))
			->flags &= ~SIGNAL_STOP_CONTINUED;

	do_signal_stop:

		if (flags & (SIGNAL_STOP_CONTINUED | SIGNAL_GROUP_EXIT))
			return 0;

Possible?

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