Messages in this thread | | | Date | Thu, 5 Jun 2008 20:04:50 +0400 | From | Oleg Nesterov <> | Subject | Re: TASK_WAKEKILL && /sbin/init (was: [PATCH 1/2] schedule: fix TASK_WAKEKILL vs SIGKILL race) |
| |
On 06/05, Matthew Wilcox wrote: > > On Thu, Jun 05, 2008 at 07:23:16PM +0400, Oleg Nesterov wrote: > > > > If lock_page_killable() fails because the task was killed by SIGKILL or > > another fatal signal, do_generic_file_read() returns -EIO. > > > > This seems to be OK, because in fact the userspace won't see this error, the > > task will dequeue SIGKILL and exit. > > > > However, /sbin/init is different, it will dequeue SIGKILL, ignore it, and be > > confused by this bogus -EIO. Please note that while this bug is not likely, > > it is _not_ theoretical. It does happen that user-space sends the unhandled > > fatal signals to init. > > Have you actually tested this?
No I didn't. And I would be happy to be wrong. But,
> I thought it was handled by: > > /* > * Global init gets no signals it doesn't want. > */ > if (unlikely(signal->flags & SIGNAL_UNKILLABLE) && > !signal_group_exit(signal)) > continue; > > in get_signal_to_deliver().
This is what I am talking about. The SIGNAL_UNKILLABLE task (init) dequeues the pending SIGKILL and just ignores it. Then it returns to the user space with -EIO.
But when we send SIGKILL, the sender wakes up the TASK_KILLABLE task, and after that fatal_signal_pending() is true. Once again, it is not hard to fix this problem in kernel/signal.c, but _perhaps_ the change in filemap.c makes sense anyway.
Oleg.
| |