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_
esolved this bug:
> >
> >
> > commit 786235eeba0e1e85e5cbbb9f97d1087ad03dfa21
> > Author: Tetsuo Handa
> > Date: Tue Nov 12 15:06:45 2013 -0800
> >
> > kthread: make kthread_create() killable
> >
> > The regression was introduced as of v3.13
087ad03dfa21
> Author: Tetsuo Handa
> 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 th
gt;
> rather than
>
> return -ENOMEM;
Why complicate the things? Following this logic you can change you
can change almost every user of, say, fatal_signal_pending() to take
TIF_MEMDIE into account. For what? Just return -EINTR.
> > > Commit 786235ee "kthread: make kthre
ey the reason properly if current thread was
SIGKILLed by other than the OOM killer. Maybe
return test_tsk_thread_flag(current, TIF_MEMDIE) ? -ENOMEM : -EINTR;
rather than
return -ENOMEM;
?
> > Commit 786235ee "kthread: make kthread_create() killable" changed to
> > leave
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
> lea
ccfaab53 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 16 Mar 2014 22:44:23 +0900
Subject: [PATCH] kthread: Do not leave kthread_create() immediately upon
SIGKILL.
Commit 786235ee "kthread: make kthread_create() killable" changed to
leave kthread_create() as soon as receiving
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
David Rientjes wrote:
> I thought you had addressed the kthread_create() issue on
> secur...@kernel.org, is it possible to address the others?
I don't know how to call call_usermodehelper_keys(). I need a lot of help
if I write a patch and a testcase for call_usermodehelper_keys().
Thus, I expla
On Tue, 1 Oct 2013, Tetsuo Handa wrote:
> > Or, when the system doesn't respond for a long period of time you do
> > sysrq+T and you find the TIF_MEMDIE bit set on a process that makes no
> > progress exiting.
>
> In enterprise systems, an operator is not always sitting in front of the
> serve
David Rientjes wrote:
> On Sat, 28 Sep 2013, Tetsuo Handa wrote:
>
> > Some of enterprise users might prefer "kernel panic followed by kdump and
> > automatic reboot" to "a system is not responding for unpredictable period",
> > for
> > the panic helps getting information for analyzing what proce
On Sat, 28 Sep 2013, Tetsuo Handa wrote:
> Some of enterprise users might prefer "kernel panic followed by kdump and
> automatic reboot" to "a system is not responding for unpredictable period",
> for
> the panic helps getting information for analyzing what process caused the
> freeze. Well, can
David Rientjes wrote:
> There may not be any eligible processes left and then the machine panics.
Some of enterprise users might prefer "kernel panic followed by kdump and
automatic reboot" to "a system is not responding for unpredictable period", for
the panic helps getting information for anal
the machine panics.
These time-based delays also have caused a complete depletion of memory
reserves if more than one process is chosen and each consumes an
non-neglible amount of memory which would then cause livelock. We used to
have a jiffies-based rekill in 2.6.18 internally and we finally co
oothly
when the chosen process is waiting at kthread_create(). I attach updated patch
description. Did I merge your comments appropriately?
--
[PATCH v3] kthread: Make kthread_create() killable.
Any user process callers of wait_for_completion() except global init process
might be chosen by the
On Wed, 25 Sep 2013, Tetsuo Handa wrote:
> Any users of wait_for_completion() might be chosen by the OOM killer while
> waiting for completion() call by some process which does memory
> allocation. kthread_create() is one of such users.
>
Any user process callers of wait_for_completion() you me
On 09/25, Tetsuo Handa wrote:
>
> Subject: [PATCH] kthread: make kthread_create() killable
The patch looks correct... although I'll try to reread it later ;)
Minor nit, since you are sending the new version anyway...
> + if (unlikely(wait_for_completion_
>From 0fe0c9d09b45cce0f00457755861204d51d7c2c9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 25 Sep 2013 00:00:27 +0900
Subject: [PATCH] kthread: make kthread_create() killable
Any users of wait_for_completion() might be chosen by the OOM killer while
waiting for completion() call by
On Mon, 16 Sep 2013 09:53:59 +0900 Tetsuo Handa
wrote:
> Subject: [PATCH v2] kthread: Make kthread_create() killable.
>
> Any users of wait_for_completion() might be chosen by the OOM killer while
> waiting for completion() call by some process which does memory allocation.
>
-
>From 87373d6938f045abffe8d9b4910bd132036eccaa Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 16 Sep 2013 09:39:17 +0900
Subject: [PATCH v2] kthread: Make kthread_create() killable.
Any users of wait_for_completion() might be chosen by the OOM killer while
waiting for completion() call by some
Hi Tetsuo,
please do not start the off-list discussions ;)
On 09/15, Tetsuo Handa wrote:
>
> I examined do_coredump() case and found similar result.
...
> Do we want to change from call_usermodehelper_exec(UMH_WAIT_EXEC) to
> call_usermodehelper_exec(UMH_WAIT_EXEC | UMH_WAIT_KILLABLE)
To me, t
On 09/15, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> > I am wondering if this can be simplified...
> >
> > At least you can move create->done from kthread_create_info to the
> > stack, and turn create->owner into the pointer to that completion.
>
> Use of DECLARE_COMPLETION_ONSTACK() looks harm
Oleg Nesterov wrote:
> I am wondering if this can be simplified...
>
> At least you can move create->done from kthread_create_info to the
> stack, and turn create->owner into the pointer to that completion.
Use of DECLARE_COMPLETION_ONSTACK() looks harmful to me because current thread
needs to be
Add lkml.
On 09/13, Tetsuo Handa wrote:
>
> This patch makes kthread_create() killable,
Probably makes sense...
> @@ -255,36 +266,59 @@ struct task_struct *kthread_create_on_node(int
> (*threadfn)(void *data),
> const char namefmt[],
>
29 matches
Mail list logo
