linux-kernel - Re: [PATCH] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups

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: <f12d0a39-b7ef-39f9-3ff7-412c2d36aaac@suse.cz>
Date:   Mon, 7 Oct 2019 16:57:15 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Roman Gushchin <guro@...com>, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, kernel-team@...com, tj@...nel.org,
        Jan Kara <jack@...e.cz>
Subject: Re: [PATCH] cgroup, blkcg: prevent dirty inodes to pin dying memory
 cgroups

On 10/5/19 12:11 AM, Roman Gushchin wrote:
>
> One possible approach to this problem is to switch inodes associated
> with dying wbs to the root wb. Switching is a best effort operation
> which can fail silently, so unfortunately we can't run once over a
> list of associated inodes (even if we'd have such a list). So we
> really have to scan all inodes.
> 
> In the proposed patch I schedule a work on each memory cgroup
> deletion, which is probably too often. Alternatively, we can do it
> periodically under some conditions (e.g. the number of dying memory
> cgroups is larger than X). So it's basically a gc run.
> 
> I wonder if there are any better ideas?

I don't know this area, so this will be likely easily shown impossible,
but perhaps it's useful to do that explicitly.

What if instead of reparenting each inode, we "reparent" the wb?
But I see it's not a small object either. Could we then add some bias
for inode switching conditions so that anyone else touching the inode
from dead wb would get it immediately?
And what would happen if we reused the reparented wb's for newly created
cgroups? Would it "punish" them for the old inodes?