linux-kernel - Re: [RFC PATCH] sched/fair: Filter by css_is_dying() in the last tg_unthrottle

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:   Mon, 29 Nov 2021 06:39:35 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Michal Koutný <mkoutny@...e.com>
Cc:     linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
        minipli@...ecurity.net, Valentin.Schneider@....com,
        bristot@...hat.com, bsegall@...gle.com, dietmar.eggemann@....com,
        juri.lelli@...hat.com, kevin.tanguy@...p.ovh.com, mgorman@...e.de,
        mingo@...hat.com, odin@...d.al, peterz@...radead.org,
        rostedt@...dmis.org, spender@...ecurity.net,
        vincent.guittot@...aro.org
Subject: Re: [RFC PATCH] sched/fair: Filter by css_is_dying() in the last
 tg_unthrottle_up()

Hello,

On Fri, Nov 26, 2021 at 02:06:19PM +0100, Michal Koutný wrote:
> As explained in the message, this relies on the RCU GP between css_is_dying()
> returning false and the potential .css_offline() call. 
> This is stated in the css_is_dying() documentation:
> 
> > the actual offline operations are RCU delayed and this test returns %true
> > also when @css is scheduled to be offlined.
> 
> On the other hand the documentation of the underlying
> percpu_ref_kill_and_confirm() says (to discourage relying on GP):
> 
> > There are no implied RCU grace periods between kill and release.
> 
> This seems to discord with each other at first thought. (That's why I marked
> this RFC.)
> 
> However, if one takes into account that percpu_refs as used by css are never
> switched to atomic besides the actual killing (and they start in per-cpu mode),
> the GP (inserted in __percpu_ref_switch_to_atomic()) is warranted.

IIRC, one reason why I didn't want to make the implied RCU "official" was
that there were different RCU types and cgroup was using the less common
preempt variant. Now that the RCU types are unified, it may be okay to
guarantee that e.g. percpu ref offlining has a guaranteed GP and then
propagate that guarantee to the users. It may still be a bit brittle tho in
that we may force the percpu ref to atomic mode for e.g. reference leak
debugging. It'd be great if we can trigger a warning if we end up missing a
GP for whatever reason.

Thanks.

-- 
tejun