linux-kernel - Re: Cgroup memory barrier usage and call frequency from scheduler

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] [day] [month] [year] [list]

Date:   Thu, 9 Apr 2020 15:27:25 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Cgroup memory barrier usage and call frequency from scheduler

Hello,

On Thu, Apr 09, 2020 at 07:20:55PM +0100, Mel Gorman wrote:
> > Given
> > 
> >    A    C
> >   ---  ---
> >    B    D
> > 
> > the code is trying to guarantee that either B sees C or D sees A, so it does
> > need full ordering.
> > 
> 
> Ok, still not particularly clear given where they are used and how
> it's related to updated_children but like you say later it's "kinda
> irrelevant" :)

Hahaha, yeah, just to make sure that I am understanding it correctly:

There are two parties - "updater" updating the local stat and trying to queue
itself on the updated list, "reader" walking the updated list trying to
collect all the numbers which changed since it last walked it.

There are two misbehaviors which can result from lack of interlocking:

1. If the updater puts itself on the list and the reader takes it off the list
   and then reads a stale value, the reader may end up reporting a stale value
   to user possibly breaking synchronity of events. This can be addressed by
   adding matching (data-dependency) barriers - wmb in updater, rmb in reader.

2. If the updater checking whether it's already on the list races against
   reader clearing it from the updated list, while the current on-going read
   is correct, the updater may incorrectly skip adding itself to the updated
   list and the next read may miss the event. This can be addressed by
   interlocking both directions - either the reader sees the new value or the
   updater sees itself cleared off the updated list - mb between stat update
   and "am I already on the updated list?" check in updater, mb between
   clearing the updater off the updated list and reading the stats in reader.

Thanks.

-- 
tejun