linux-kernel - Re: [PATCH] signals: Generate warning when flush_signals() is called from non-kthread context

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: <20150507125453.GN17717@twins.programming.kicks-ass.net>
Date:	Thu, 7 May 2015 14:54:53 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	NeilBrown <neilb@...e.de>, Ingo Molnar <mingo@...nel.org>,
	Evgeniy Polyakov <zbr@...emap.net>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Alex Williamson <alex.williamson@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	kvm <kvm@...r.kernel.org>
Subject: Re: [PATCH] signals: Generate warning when flush_signals() is called
 from non-kthread context

On Sat, May 02, 2015 at 09:27:49AM -0700, Linus Torvalds wrote:
> On Sat, May 2, 2015 at 1:30 AM, NeilBrown <neilb@...e.de> wrote:
> >
> > All the calls in md.c are in a kernel thread so safe, but I'd rather have an
> > explicit "uninterruptible, but no load-average" wait....
> 
> Hmm. Our task state is a bitmask anyway, so we could probably just add a
> 
>     #define __TASK_NOLOAD              16
> 
> (and move the EXIT_xyz defines *away* from the list that is actually
> the task state), and teach our load average thing to not count those
> kinds of waits. Then you could just use
> 
>     TASK_UNINTERRUPTIBLE | __TASK_NOLOAD
> 
> to make processes not count towards the load.
> 
> Or - probably preferably - we could really clean things up, and make
> things much more like the bitmask it *should* be, and have explicit
> bits for
> 
>  - SLEEPING/STOPPED/EXITING ("why not running?")
>  - LOADAVG (accounted towards load)
>  - WAKESIG (ie "interruptible")
>  - WAKEKILL (this we already have)
> 
> and just make the rule be that we use "__TASK_xyz" for the actual
> individual bits, and "TASK_xyz" for the helper combinations. So then
> we'd have
> 
>    #define TASK_UNINTERRUPTIBLE (__TASK_SLEEPING | __TASK_LOADAVG)
>    #define TASK_INTERRUPTIBLE (__TASK_SLEEPING | __TASK_WAKESIG)
>    #define TASK_KILLABLE (__TASK_SLEEPING | __TASK_WAKEKILL)
>    #define TASK_NOLOADAVG (__TASK_SLEEPING)
> 
> which is almost certainly how this *should* have been done, but isn't,
> because of historical use.
> 
> Cleaning up like that *should* be fairly simple, but I'd be a bit
> nervous about getting all the state comparisons right (we have an
> unholy mix of "check this bit" and "check this whole state", and we'd
> need to make sure we get those cases all right).
> 
> Ingo, what do you think? This is mostly a scheduler interface issue..

Hehe, a little something like this:

  https://lkml.org/lkml/2013/11/12/710

Lemme go clean that up and finish it :-)
--
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/