linux-kernel - Re: [PATCH RT] Revert "memcontrol: Prevent scheduling while atomic in cgroup code"

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, 23 Nov 2017 17:22:54 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Mike Galbraith <efault@....de>
Subject: Re: [PATCH RT] Revert "memcontrol: Prevent scheduling while atomic
 in cgroup code"

On 2017-11-22 07:31:19 [-0500], Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@...dmis.org>
> 
> The commit "memcontrol: Prevent scheduling while atomic in cgroup code"
> fixed this issue:
> 
>        refill_stock()
>           get_cpu_var()
>           drain_stock()
>              res_counter_uncharge()
>                 res_counter_uncharge_until()
>                    spin_lock() <== boom
> 
> But commit 3e32cb2e0a12b ("mm: memcontrol: lockless page counters") replaced
> the calls to res_counter_uncharge() in drain_stock() to the lockless
> function page_counter_uncharge(). There is no more spin lock there and no
> more reason to have that local lock.

as per v4.9+ the reported issue should not have occur due to the
locallocks. I am not sure why those were not used in first place.

The loop in page_counter_uncharge() does not look like it would take
many iterations and in worst case we could have two invocations with
interrupts off. So okay, lets revert that.

That upstream commit appeared in v3.19 and the patch in question in
v3.18.7-rt2 and v3.18 seems still to be maintained. So I guess that
v3.18 would need the locallocks that we are about to remove here. I am
not sure if any earlier versions have the patch backported.

> Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>

Sebastian