linux-kernel - Re: WARNING in enqueue_task

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: <20181119125241.GC9761@hirez.programming.kicks-ass.net>
Date:   Mon, 19 Nov 2018 13:52:41 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     luca abeni <luca.abeni@...tannapisa.it>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        syzbot <syzbot+119ba87189432ead09b4@...kaller.appspotmail.com>,
        Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>, mingo@...hat.com,
        syzkaller-bugs@...glegroups.com, x86@...nel.org,
        Juri Lelli <juri.lelli@...hat.com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>
Subject: Re: WARNING in enqueue_task_dl

On Mon, Nov 19, 2018 at 01:07:18PM +0100, luca abeni wrote:

> > On Sun, 18 Nov 2018, syzbot wrote:

> > > WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628
> > > enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
> 
> Here, it looks like a task is invoking sched_setattr() to become
> SCHED_DEADLINE when dl_boosted is set...
> 
> Is this possible / correct?

Possible, clearly. Correct, only in so far as that it is not a malformed
program, but it is very poor design to actually trigger this (of course
the fuzzer doesn't care about that).

> If this (sched_setattr() with dl_boosted set) should not be possible,
> then we have a bug that we need to investigate...
> 
> Otherwise, I suspect we can just remove the WARN_ON at line 628 of
> deadline.c

I wonder why we put that WARN in there to begin with... git-blame gives
us:

  98b0a8578050 ("sched/deadline: Remove useless parameter from setup_new_dl_entity()")

So the problem seems to be that if we're boosted, we should maybe not be
using our own (newly set) parameters, but those of the donor task.

Specifically, our 'suboptimal' deadline inheritance scheme 'requires' us
to use the inherited deadline, not our own. So in that respect I think
the WARN is valid, although I'm not sure what, apart from actually
finishing that PE patch-set we can do about it just now.