On 03/17, One Thousand Gnomes wrote:
>
> > and b) permits userspace to produce surprising results in the kernel,
> > which I suspect is what we're seeing here.
>
> There is enough information for kernel side code to decide whether a
> signal came from kernel or userspace.
Not really. SIGKILL can c
On 03/17, Andrew Morton wrote:
>
> On Mon, 17 Mar 2014 21:19:19 +0100 Oleg Nesterov wrote:
>
> > > Root cause time: it's wrong for the oom-killer to use SIGKILL.
> >
> > Not sure... what else?
>
> If we really really have to use userspace IPC in the kernel then I
> suppose we could add a new signa
> Root cause time: it's wrong for the oom-killer to use SIGKILL. In fact
It has to use SIGKILL anything else might be caught and grow the user
stack a page..
> it's basically always wrong to send signals from in-kernel. Signals
> are a userspace IPC mechanism and using them in-kernel a) makes i
Andrew Morton wrote:
> What process is running here? Presumably modprobe.
Yes. It is a worker systemd-udevd process who is acting like 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
On Mon, 17 Mar 2014 21:19:19 +0100 Oleg Nesterov wrote:
> > 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_
On 03/17, Andrew Morton wrote:
>
> On Fri, 14 Mar 2014 16:46:26 -0400 Joseph Salisbury
> 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 786235e
On Fri, 14 Mar 2014 16:46:26 -0400 Joseph Salisbury
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: Tetsu
On 03/17, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> >
> > Personally I really dislike this hack. And btw, why we return -ENOMEM if
> > SIGKILL'ed? Why not EINTR ?
>
> I chose -ENOMEM because -ENOMEM looked better for conveying that current
> thread
> was SIGKILLed by the OOM killer in order t
Oleg Nesterov wrote:
> > @@ -292,6 +292,17 @@ struct task_struct *kthread_create_on_node(int
> > (*threadfn)(void *data),
> > * new kernel thread.
> > */
> > if (unlikely(wait_for_completion_killable(&done))) {
> > + int i = 0;
> > +
> > + /*
> > +* I
On 03/17, Tetsuo Handa wrote:
>
> Therefore, I'd like to propose this patch for 3.14-final
> and 3.13-stable.
Well, I disagree. To me, the patch tries to fix the problem in the wrong
place,
> Commit 786235ee "kthread: make kthread_create() killable" changed to
> leave kthread_create() as soon as
Hello.
Although the process who is sending SIGKILL to systemd-udevd is not
identified yet, adding wait_for_completion_timeout() can solve this
regression. Therefore, I'd like to propose this patch for 3.14-final
and 3.13-stable.
Regards.
--
>From c6562e5d774dd1f36724197dbcb8976cccfaab53 M
Joseph Salisbury wrote:
> A kernel bug report was opened against Ubuntu[0]. We performed a kernel
> bisect, and found that reverting the following commit resolved this bug:
I added a comment to that bug report.
This commit by chance revealed incorrect error handling of mptsas_probe() or
mptscsih
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
Date: Tue Nov 12 15:06:45 2013 -0800
kthread: make kthread_cre
13 matches
Mail list logo
