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

[Peter Zijlstra]

On Sat, May 02, 2015 at 09:27:49AM -0700, Linus Torvalds wrote:
> On Sat, May 2, 2015 at 1:30 AM, NeilBrown <neilb@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/