| 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
| ||
|
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?
Powered by blists - more mailing lists