* [PATCH 0/4] signal_struct->count must die, initial changes
@ 2010-03-17 19:28 Oleg Nesterov
2010-03-17 21:50 ` Roland McGrath
2010-03-18 16:49 ` Veaceslav Falico
0 siblings, 2 replies; 3+ messages in thread
From: Oleg Nesterov @ 2010-03-17 19:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: Roland McGrath, Veaceslav Falico, linux-kernel
signal_struct->count in its current form must die.
- it has no reasons to be atomic_t
- it looks like a reference counter, but it is not
- otoh, we really need to make task->signal refcountable,
just look at the extremely ugly task_rq_unlock_wait()
called from __exit_signals().
- we should change the lifetime rules for task->signal,
it should be pinned to task_struct. We have a lot of
code which can be simplified after that.
- it is not needed! while the code is correct, any usage
of this counter is artificial, except fs/proc uses it
correctly to show the number of threads.
This series removes the usage of sig->count from exit pathes.
Oleg.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 0/4] signal_struct->count must die, initial changes
2010-03-17 19:28 [PATCH 0/4] signal_struct->count must die, initial changes Oleg Nesterov
@ 2010-03-17 21:50 ` Roland McGrath
2010-03-18 16:49 ` Veaceslav Falico
1 sibling, 0 replies; 3+ messages in thread
From: Roland McGrath @ 2010-03-17 21:50 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Andrew Morton, Veaceslav Falico, linux-kernel
> signal_struct->count in its current form must die.
Agreed. This series
Acked-by: Roland McGrath <roland@redhat.com>
> - otoh, we really need to make task->signal refcountable,
> just look at the extremely ugly task_rq_unlock_wait()
> called from __exit_signals().
Another of many good reasons for...
> - we should change the lifetime rules for task->signal,
> it should be pinned to task_struct. We have a lot of
> code which can be simplified after that.
Yes, and sighand too. I think there will be quite a torrent of cleanup we
can do after that.
Remember too that we should really change de_thread() altogether. It has
long-standing signal-losing races that we should fix. Changing the
lifetime rules may complicate that, or not. But they'll tie in together,
and when we do that we'll replace the notify_count again with something
else entirely.
Thanks,
Roland
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 0/4] signal_struct->count must die, initial changes
2010-03-17 19:28 [PATCH 0/4] signal_struct->count must die, initial changes Oleg Nesterov
2010-03-17 21:50 ` Roland McGrath
@ 2010-03-18 16:49 ` Veaceslav Falico
1 sibling, 0 replies; 3+ messages in thread
From: Veaceslav Falico @ 2010-03-18 16:49 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Andrew Morton, Roland McGrath, linux-kernel
On Wed, Mar 17, 2010 at 08:28:47PM +0100, Oleg Nesterov wrote:
> signal_struct->count in its current form must die.
Ack on this series.
Acked-by: Veaceslav Falico <vfalico@redhat.com>
--
Veaceslav
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-03-18 16:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-17 19:28 [PATCH 0/4] signal_struct->count must die, initial changes Oleg Nesterov
2010-03-17 21:50 ` Roland McGrath
2010-03-18 16:49 ` Veaceslav Falico
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox