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: <CA+55aFybD6U8_ZbPYMm3pe6ZuNY8acyvCSFOabJd31my6qakDA@mail.gmail.com>
Date:	Sat, 2 May 2015 09:27:49 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	NeilBrown <neilb@...e.de>
Cc:	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 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..

                       Linus
--
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/