linux-kernel - Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140905173529.GB17986@wotan.suse.de>
Date:	Fri, 5 Sep 2014 19:35:30 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	gregkh@...uxfoundation.org, dmitry.torokhov@...il.com,
	falcon@...zu.com, tiwai@...e.de, tj@...nel.org,
	arjan@...ux.intel.com, linux-kernel@...r.kernel.org, hare@...e.com,
	akpm@...ux-foundation.org, penguin-kernel@...ove.sakura.ne.jp,
	joseph.salisbury@...onical.com, bpoirier@...e.de,
	santosh@...lsio.com, Kay Sievers <kay@...y.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tim Gardner <tim.gardner@...onical.com>,
	Pierre Fersing <pierre-fersing@...rref.org>,
	Nagalakshmi Nandigama <nagalakshmi.nandigama@...gotech.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@...gotech.com>,
	Sreekanth Reddy <sreekanth.reddy@...gotech.com>,
	Abhijit Mahajan <abhijit.mahajan@...gotech.com>,
	Casey Leedom <leedom@...lsio.com>,
	Hariprasad S <hariprasad@...lsio.com>,
	MPT-FusionLinux.pdl@...gotech.com, linux-scsi@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM

On Fri, Sep 05, 2014 at 12:59:49PM +0200, Oleg Nesterov wrote:
> On 09/04, Luis R. Rodriguez wrote:
> >
> > From: "Luis R. Rodriguez" <mcgrof@...e.com>
> >
> > 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,
> 
> > while the original motivation was to enable
> > through the OOM from sending the kill.
> 
> even if the main concern was OOM.
> 
> > 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.

> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/