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:   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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ