lkml.org 
[lkml]   [2014]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [v3.13][v3.14][Regression] kthread: make kthread_create() killable
    On 03/17, Andrew Morton wrote:
    >
    > On Fri, 14 Mar 2014 16:46:26 -0400 Joseph Salisbury <joseph.salisbury@canonical.com> wrote:
    >
    > > Hi Tetsuo,
    > >
    > > A kernel bug report was opened against Ubuntu[0]. We performed a kernel
    > > bisect, and found that reverting the following commit resolved this bug:
    > >
    > >
    > > commit 786235eeba0e1e85e5cbbb9f97d1087ad03dfa21
    > > Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    > > Date: Tue Nov 12 15:06:45 2013 -0800
    > >
    > > kthread: make kthread_create() killable
    > >
    > > The regression was introduced as of v3.13-rc1.
    > >
    > > The bug indicates an issue with the SAS controller during
    > > initialization, which prevents the system from booting. Additional
    > > details are available in the bug report or on request.
    > >
    > > I was hoping to get your feedback, since you are the patch author. Do
    > > you think gathering any additional data will help diagnose this issue,
    > > or would it be best to submit a revert request?
    > >
    > > [0] http://pad.lv/1276705
    >
    > What process is running here? Presumably modprobe.
    >
    > A possible explanation is that modprobe has genuinely received a
    > SIGKILL. Can you identify anything in this setup which might send a
    > SIGKILL to the modprobe process?

    See also other discussion in this thread, I thinks the code in drivers/
    is buggy anyway.

    > kthread_create_on_node() thinks that SIGKILL came from the oom-killer
    > and it cheerfully returns -ENOMEM, which is incorrect if that signal
    > came from userspace.

    Yes, I think it should return -EINTR.

    > And I don't _think_ we prevent
    > userspace-originated signals from unblocking
    > wait_for_completion_killable()?

    And we should not.

    > Root cause time: it's wrong for the oom-killer to use SIGKILL.

    Not sure... what else?

    > In fact
    > it's basically always wrong to send signals from in-kernel.

    Well, SIGSEGV, SIGIO...

    > Signals
    > are a userspace IPC mechanism and using them in-kernel a) makes it hard
    > (or impossible) to distinguish them from userspace-originated signals
    > and b) permits userspace to produce surprising results in the kernel,
    > which I suspect is what we're seeing here.

    Well, I think in this case it doesn't matter who/why sends a signal.
    The task is killed, it should react and exit asap. And kthread_create()
    can fail in any case, at least the kernel should not crash.

    Oleg.



    \
     
     \ /
      Last update: 2014-03-17 22:01    [W:2.293 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site