Luis R. Rodriguez wrote:
Tetsuo bisected and found that commit 786235ee \kthread: make
kthread_create() killable\ modified kthread_create() to bail as
soon as SIGKILL is received.
I just wrote commit 786235ee. It is not Tetsuo who bisected it.
@@ -128,4 +129,38 @@ bool
Greg KH wrote:
Why doesn't it work? Doesn't modprobe come right back and the init
sequence still takes a while to run? What exactly fails?
I guess ...
@@ -5429,9 +5429,19 @@ mptsas_init(void)
return error;
}
+static struct task_struct *init_thread;
+
+static int __init
Luis R. Rodriguez wrote:
On Mon, Jul 28, 2014 at 5:35 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Jul 28, 2014 at 05:26:34PM -0700, Luis R. Rodriguez wrote:
To ignore SIGKILL ?
Sorry, I thought this was a userspace change that caused this.
As it's a kernel change, well,
Luis R. Rodriguez wrote:
Tetsuo is it possible / desirable to allow tasks to not kill unless the
reason is OOM ? Its unclear if this was discussed before, sorry if it was,
have just been a bit busy today to review the archive / discussions on this.
Are we aware that the 10 seconds timeout
a kernel API breakage.
--
From 731f1f6dec7efaa132f751c432079b9b1fdb78d2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Date: Sat, 22 Mar 2014 15:16:50 +0900
Subject: [PATCH] kthread: Handle SIGKILL gracefully in kthread_create().
Commit 786235ee kthread: make
Oleg Nesterov wrote:
On 03/22, Tetsuo Handa wrote:
Oleg Nesterov wrote:
Tetsuo, what do you think?
I don't like blocking SIGKILL while doing operations that depend on memory
allocation by other processes. If the OOM killer is triggered and it chose
the process blocking SIGKILL
Thomas Gleixner wrote:
But then systemd/udev mutters:
You migh be able to work around the timeout with udev rules and
OPTIONS+=event_timeout=120, but that code was maybe never used
or tested, so it might not work correctly. [1]
AFAICT from the ubuntu bug system [2] nobody
Oleg Nesterov wrote:
If we need the urgent hack to fix the regression, then I suggest to change
scsi_host_alloc() temporary until mptsas (or whatever) is fixed.
Device initialization taking longer than 30 seconds is possible and is not a
hang up. It is systemd which needs to be fixed.
Oleg Nesterov wrote:
If we need the urgent hack to fix the regression, then I suggest to change
scsi_host_alloc() temporary until mptsas (or whatever) is fixed.
Device initialization taking longer than 30 seconds is possible and is not a
hang up. It is systemd which needs to be fixed.
---
Khalid Aziz wrote:
Added check for DMA mapping errors for request sense data
buffer. Checking for mapping error can avoid potential wild
writes. This patch was prompted by the warning from
dma_unmap when kernel is compiled with CONFIG_DMA_API_DEBUG.
This patch fixes CONFIG_DMA_API_DEBUG
Khalid Aziz wrote:
Added check for DMA mapping errors for request sense data
buffer. Checking for mapping error can avoid potential wild
writes. This patch was prompted by the warning from
dma_unmap when kernel is compiled with CONFIG_DMA_API_DEBUG.
This patch looks OK and works OK to me.
11 matches
Mail list logo
