On Fri, Sep 05, 2014 at 12:59:49PM +0200, Oleg Nesterov wrote:

On 09/04, Luis R. Rodriguez wrote:

quoted

From: "Luis R. Rodriguez" <redacted>

The new umh kill option has allowed kthreads to receive
kill signals but they are generally accepting all sources
of kill signals

And I think this is right,

quoted

while the original motivation was to enable
through the OOM from sending the kill.

even if the main concern was OOM.

quoted

Users can provide a log output and it should be clear on
the trace what probe / driver got the kill signal.

Well, if you need a WARN output, perhaps you could just add
WARN_ON(fatal_signal_pending()) at the end of load_module() ?

We could and that's a good idea, thanks! This however would
at least allow the device to be functional in the case the
kill was received during kthread usage, but it would certainly
also set precedents for doing similar things in the kernel
which I do agree with is hacky. If we had upstream at
least WARN_ON(fatal_signal_pending()) as you note then
I think it would at least be a reasonable compromise.

Not only kthread_create() can fail if systemd sends SIGKILL.

Sure, although its currently the only source found and debugged.

quoted

Although Oleg had rejected a
similar change a while ago

And honestly, I still dislike this change.

Don't blame you. The code is sensitive and hacky.

  Luis