Re: + aio-completion-signal-notification.patch added to -mm tree

Previous thread: [PATCH 03/10] local_t : i386 extension by Mathieu Desnoyers on Thursday, January 25, 2007 - 9:16 am. (14 messages)

Next thread: Re: maximum of 256 loop devices - not enough for cdrom server by devzero on Thursday, January 25, 2007 - 10:38 am. (1 message)
From: Oleg Nesterov
Date: Thursday, January 25, 2007 - 9:21 am

PF_EXITING check is racy and unneded. In fact, it is wrong. If the main
thread is already died, we can only use SIGEV_THREAD_ID signals, because

We should not use sigqueue_free() here. It takes current->sighand->siglock
to remove sigqueue from "struct sigpending". But current is just a "random"
process here.

Yes, if I understand this patch correctly, it is not possible that this

Oh, this is not nice. Could we change send_sigqueue/send_group_sigqueue
instead ?

-	BUG_ON(!(q->flags & SIGQUEUE_PREALLOC));
+	BUG_ON(!(q->flags & SIGQUEUE_PREALLOC) && q->info.si_code != SI_ASYNCIO);

This way aio can use __sigqueue_alloc/__sigqueue_free directly and forget
about SIGQUEUE_PREALLOC.

On the other hand, imho this patch takes a wrong direction.

The purpose of SIGQUEUE_PREALLOC + send_sigqueue() is to re-use the same
sigqueue while sending a stream of signals. But in aio case we allocate
sigqueue to send only 1 signal, then it freed after the delivery like
the regular sigqueue. So what is the point?

I'd suggest to not use this interface. Just use group_send_sig_info() or
specific_send_sig_info(). Yes, this way we will do GFP_ATOMIC allocation
of sigqueue in interrupt context, but is this so bad in this case?

Oleg.

-

From: Oleg Nesterov
Date: Thursday, January 25, 2007 - 9:34 am

... and it is possible that current->sighand == NULL.

Oleg.

-

From: Sébastien Dugué
Date: Friday, January 26, 2007 - 4:14 am

Yes, in fact the sigqueue is used for a single signal delivery and then
free. In fact I could have used directly __sigqueue_free() instead here
except for the fact that it's private to signal.c and I'm reluctant


  Well, I don't think it's cleaner. The aio error path calls sigqueue_free()
directly whereas in case of success sigqueue_free() is called from the signal

  Well, the thihere is that in the past we used group_send_sig_info()
and specific_send_sig_info() for notification but Zach Brown raised
the question about reliable signal delivery. IOW an aio submission
should not succeed if signal delivery is going to fail. Hence the
use of the preallocated sigqueue.

  Thanks,

  Sébastien.





-

From: Oleg Nesterov
Date: Friday, January 26, 2007 - 4:52 am

My apologies, I was unclear.

This check is racy, the condition could be changed right after the check.

It is unneeded, it is ok to do send_sigqueue(tsk) if if that task is already
dead. (we hold the reference to task_struct).

Now suppose that the main thread (->group_leader) already exited. This is
normal, the thread group is still alive, it should be ok to send a signal to
it via send_group_sigqueue(). But we can't: without SIGEV_THREAD_ID in
->sigev_notify good_event() returns ->group_leader, and it has PF_EXITING.

Yes, kernel/posix-timers.c needs a cleanup too. But please note that it does
this check for another reason (according to the comment). This reason is not
valid now, the callsite for exit_itimers() was moved from __exit_signal() to

I personally think it is better to export __sigqueue_free() even if sigqueue_free()
happens to work. It is to fragile imho to reference current->sighand. At least

Hmm... now I don't understand you. Of course, the aio error path should use
__sigqueue_free() if we don't use SIGQUEUE_PREALLOC (and imho we should not).

And the signal delivery path uses __sigqueue_free() too.


Ok, I see, thanks.

Oleg.

-

From: Sébastien Dugué
Date: Friday, January 26, 2007 - 6:05 am

Previous thread: [PATCH 03/10] local_t : i386 extension by Mathieu Desnoyers on Thursday, January 25, 2007 - 9:16 am. (14 messages)

Next thread: Re: maximum of 256 loop devices - not enough for cdrom server by devzero on Thursday, January 25, 2007 - 10:38 am. (1 message)