linux-kernel - Re: [RFC PATCH 06/18] signal/kthread: Initial implementation of kthread signal handling

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]

Date:	Tue, 9 Jun 2015 14:15:24 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Tejun Heo <tj@...nel.org>
cc:	Petr Mladek <pmladek@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Richard Weinberger <richard@....at>,
	Steven Rostedt <rostedt@...dmis.org>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-mtd@...ts.infradead.org,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Anna Schumaker <anna.schumaker@...app.com>,
	linux-nfs@...r.kernel.org, Chris Mason <clm@...com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Borislav Petkov <bp@...e.de>, Michal Hocko <mhocko@...e.cz>,
	live-patching@...r.kernel.org, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 06/18] signal/kthread: Initial implementation of
 kthread signal handling

On Tue, 9 Jun 2015, Tejun Heo wrote:

> While I agree that it'd be great to consolidate the existing kthread
> signal users, I feel quite uncomfortable with doing full-fledged
> signal handling for kthreads which try to mimic the userland behavior.
> Most of the default behaviors don't make sense for kthreads and it'd
> be awful to have different kthreads interpreting arbitrary signals for
> differing custom behaviors, which often happens when there's no
> default.

I don't think the ultimate goal is to mimic what userspace does; 
especially when it comes to default actions.

To me, the ultimate goal (*) is to make it possible for kthread to be able 
to decide whether it wants "some kind of default behavior" (however that'd 
be defined), or "ignore all", or "just handle this set of signals with 
these handlers", and make API for this that would avoid every kthread 
implementing its own complete signal handling.

(*) Well, the ultimate goal really is to bring sanity to how kthreads are 
    handling their main loop. Trying to bring some consistency to how 
    kthreads are handling signals is just an (optional) added value on 
    top of that.

> While we do have several kthread signal users, they aren't too many and 
> majority of them use it to allow userland to tell it to shutdown and 

Yeah. Via SIGKILL. Or SIGTERM. Or SIGINT. Or SIGQUIT. Not really 
consistent either.

> there seem to be a couple which use HUP/USR1 to cancel whatever it's 
> processing / waiting on at the moment.  Hmmm... jffs uses STOP/CONT too.

> I don't know how this should be done but let's please try to
> 
> 1. Encourage uniform behaviors across the signals.

Fully agreed.

> 2. Ultimately discourage usage of signals on kthreads as this closely
>    ties implementation detail (use of single kthread) to the userland
>    visible interface in a way where we can't easily get back out of.
>    For example, what if jffs needs its gc workers to be multi-threaded
>    and per-NUMA for high-iops devices later on?

What kind of multi-threading kthreads are you referring to here? Something 
more sophisticated than simply spawning several per-CPU (or 
per-whatever-resource) full-fledged kthreads?

-- 
Jiri Kosina
SUSE Labs
--
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/