linux-kernel - Re: Q: posix_timer_event: can't we kill the "switch to ->group

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 for Android: free password hash cracker in your pocket

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

Date:	Fri,  1 Aug 2008 14:31:02 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Ingo Molnar <mingo@...e.hu>, Mark McLoughlin <markmc@...hat.com>,
	Michael Kerrisk <mtk.manpages@...glemail.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ulrich Drepper <drepper@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Q: posix_timer_event: can't we kill the "switch to ->group_leader on failure" ?

> posix_timer_event() drops SIGEV_THREAD_ID and switches to ->group_leader
> if send_sigqueue() fails.
> 
> Is this really useful? I don't understand the point.

I don't think it's useful.  SIGEV_THREAD_ID is used not really used by
applications directly at all.  It's used by glibc internally to implement
the POSIX feature SIGEV_THREAD.  The target thread is a private service
thread that glibc maintains.  It should never die while there are timers
using it.  If it does, there are no expectations about the abandoned timers
firing usefully at all.

> But more importantly, I think this code gives the false promises, it
> doesn't work reliably.

Userland never relied on any such promise.  All that really needs to be
reliable is that the kernel doesn't keep a dangling pointer or task ref.

> If we can do the above, we can simplify the code further, see the patch
> below (should be 2 patches).

Probably fine, needs a little closer thought.

Thanks,
Roland
--
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/