linux-kernel - Re: [PATCH] sched: Do not re-read h_load_next during hierarchical load calculation

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: <20190319123354.qnsazogerjqa2dmv@techsingularity.net>
Date:   Tue, 19 Mar 2019 12:33:54 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched: Do not re-read h_load_next during hierarchical
 load calculation

On Tue, Mar 19, 2019 at 01:06:09PM +0100, Peter Zijlstra wrote:
> > ---
> >  kernel/sched/fair.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 310d0637fe4b..34aeb40e69d2 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -7726,7 +7726,7 @@ static void update_cfs_rq_h_load(struct cfs_rq *cfs_rq)
> >  		cfs_rq->last_h_load_update = now;
> >  	}
> >  
> > -	while ((se = cfs_rq->h_load_next) != NULL) {
> > +	while ((se = READ_ONCE(cfs_rq->h_load_next)) != NULL) {
> >  		load = cfs_rq->h_load;
> >  		load = div64_ul(load * se->avg.load_avg,
> >  			cfs_rq_load_avg(cfs_rq) + 1);
> 
> Where there is a READ_ONCE there should also be a corresponding
> WRITE_ONCE(). Otherwise the compiler can still screw us over by doing
> store-tearing.
> 
> So something like the below. But looking at this, we probably also want
> ONCE treatment on cfs_rq->h_load itself, but that's another patch.
> 
> And I think we can do something with cfs_rq->last_h_load_update.
> 

Ok, I hadn't taken into account the possibility of store tearing but you're
right, it is a possibility depending on the architecture and your patch
is better. While there are some potential issues around h_load, I had
treated it as data that is approximate and only considered the potential
NULL dereference to be relevant.

I'll send a v2 shortly.