Re: [RFC][PATCH 2/5] signals: Introduce per-thread siglock andaction rwlock

[Matt Fleming]

[Sorry it's taken me so long to reply to this email]

On Mon, 18 Apr 2011 18:45:13 +0200
Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
 
> Can't understand...
> 
> OK, someone does get_sighand(). Now, what de_thread() should do if it
> wants to change ->sighand?
> 
> And I don't really understand the point. You can read *sighand lockless.
> But you need some per-CLONE_SIGHAND lock if you want to modify it anyway.

I think at this stage the best thing for me to do is to write a patch to
demonstrate what I'm talking about.
 
> > Now, at the moment that suggestion just seems like needless overhead
> > because siglock already provides the features we want. But, my problem
> > with siglock is,
> >
> > 	1. It needs to be acquired to stop a task passing through
> > 	__exit_signal().
> >
> > 	2. It protects bits of signal_struct and that struct is getting
> > 	pretty bloated and siglock is being used to protect lots of
> > 	different things.
> 
> Yes, this is the main problem: it is overused.
> 
> We need the better locking. Honestly, _personally_ I do not really care
> about scalability (but perhaps I should) when it comes to signals, but
> there are other problems. And, apart from the already mentioned problems
> with signals-from-irq, I think the main problem is tasklist_lock in
> do_wait/exit/etc pathes.

Is the tasklist_lock problem that we acquire the write lock for these
paths? Or is it a problem acquiring the read lock too?
 
> And we still have the problems with signals which should be fixed.
> de_thread() can miss a signal, vfork() should be interruptible,
> do_coredump() should be interruptible. But first of all we need to
> define better the behaviour of explicit SIGKILL and what it means
> after exit_signals(). This should be fixed first, I think.

Hmm.. interesting. Does the SIGKILL case cause any bugs? Or is it more
of a theoretical scenario? I must admit that I can't see any problems.

> > Do you have any recollection of the cleanups? signal_struct needs to be
> > put on a diet for sure.
> 
> I was going to remove ->sighand from fs/proc first, probably I should
> try to resend these patches... Then we should remove the "sighand != NULL"
> checks, we need the new helper, and btw it should be used instead of
> pid_alive(). Then something else... boring ;)

Heh. I'd be interested in reviewing these patches if you could find and
submit them.

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/