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: <OS0PR01MB59222333D50ADBAD1786DA9A86C8A@OS0PR01MB5922.jpnprd01.prod.outlook.com>
Date:   Sat, 7 Oct 2023 06:26:05 +0000
From:   Biju Das <biju.das.jz@...renesas.com>
To:     Chen Yu <yu.c.chen@...el.com>,
        Peter Zijlstra <peterz@...radead.org>
CC:     Mike Galbraith <efault@....de>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        "bsegall@...gle.com" <bsegall@...gle.com>,
        "bristot@...hat.com" <bristot@...hat.com>,
        "chris.hyser@...cle.com" <chris.hyser@...cle.com>,
        "corbet@....net" <corbet@....net>,
        "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "joel@...lfernandes.org" <joel@...lfernandes.org>,
        "joshdon@...gle.com" <joshdon@...gle.com>,
        "juri.lelli@...hat.com" <juri.lelli@...hat.com>,
        "kprateek.nayak@....com" <kprateek.nayak@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "patrick.bellasi@...bug.net" <patrick.bellasi@...bug.net>,
        Pavel Machek <pavel@....cz>, "pjt@...gle.com" <pjt@...gle.com>,
        "qperret@...gle.com" <qperret@...gle.com>,
        "qyousef@...alina.io" <qyousef@...alina.io>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "timj@....org" <timj@....org>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "youssefesmat@...omium.org" <youssefesmat@...omium.org>,
        "mgorman@...e.de" <mgorman@...e.de>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH] sched/fair: fix pick_eevdf to always find the correct se

Hi Chen Yu,

> Subject: Re: [PATCH] sched/fair: fix pick_eevdf to always find the correct
> se
> 
> On 2023-10-06 at 21:24:45 +0200, Peter Zijlstra wrote:
> > On Fri, Oct 06, 2023 at 05:55:01PM +0200, Peter Zijlstra wrote:
> >
> > > And yeah, min_deadline is hosed somehow.
> > >
> > > migration/28-185     [028] d..2.    70.264274: validate_cfs_rq: --- /
> > > migration/28-185     [028] d..2.    70.264277: __print_se:
> ffff88845cf48080 w: 1024 ve: -58857638 lag: 870381 vd: -55861854 vmd: -
> 66302085 E (11372/tr)
> > > migration/28-185     [028] d..2.    70.264280: __print_se:
> ffff88810d165800 w: 25 ve: -80323686 lag: 22336429 vd: -41496434 vmd: -
> 66302085 E (-1//autogroup-31)
> > > migration/28-185     [028] d..2.    70.264282: __print_se:
> ffff888108379000 w: 25 ve: 0 lag: -57987257 vd: 114632828 vmd: 114632828 N
> (-1//autogroup-33)
> > > migration/28-185     [028] d..2.    70.264283: validate_cfs_rq:
> min_deadline: -55861854 avg_vruntime: -62278313462 / 1074 = -57987256
> > >
> > > I need to go make dinner (kids hungry), but I'll see if I can figure
> > > out how this happens...
> >
> > *sigh*, does the below help?
> >
> > ---
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index
> > 04fbcbda97d5..6a670f119efa 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3632,6 +3747,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq,
> struct sched_entity *se,
> >  		 */
> >  		deadline = div_s64(deadline * old_weight, weight);
> >  		se->deadline = se->vruntime + deadline;
> > +		min_deadline_cb_propagate(&se->run_node, NULL);
> >  	}
> >
> >  #ifdef CONFIG_SMP
> 
> Is it because without this patch, the se->deadline is not always synced
> with se->min_deadline, then in pick_eevdf() the following condition could
> not be met, thus we get a NULL candidate and has to pick the leftmost one?
> 	if (se->deadline == se->min_deadline)
> 
> Regarding the circular locking warning triggered by printk, does it mean we
> should not get a NULL candidate from __pick_eevdf() in theory? And besides,
> we should not use printk with rq lock hold?

Is it not a useful error log? At least from the initial report Marek Szyprowski doesn't see "EEVDF scheduling fail, picking leftmost" but seen only warning triggered by this in the logs.

Cheers,
Biju

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ