linux-kernel - [PATCH 0/2] memcgroup: work better with tmpfs

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

Message-ID: <Pine.LNX.4.64.0712182215460.29209@blonde.wat.veritas.com>
Date:	Tue, 18 Dec 2007 22:19:22 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Balbir Singh <balbir@...ux.vnet.ibm.com>
cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] memcgroup: work better with tmpfs

Here's a couple of patches to get memcgroups working better with tmpfs
and shmem, in conjunction with the tmpfs patches I just posted.  There
will be another to come later on, but I shouldn't wait any longer to get
these out to you.

(The missing patch will want to leave a mem_cgroup associated with a tmpfs
file or shm object, so that if its pages get brought back from swap by
swapoff, they can be associated with that mem_cgroup rather than the one
which happens to be running swapoff.)

 mm/memcontrol.c |   81 ++++++++++++++++++++--------------------------
 mm/shmem.c      |   28 +++++++++++++++
 2 files changed, 63 insertions(+), 46 deletions(-)

But on the way I've noticed a number of issues with memcgroups not dealt
with in these patches.

1. Why is spin_lock_irqsave rather than spin_lock needed on mz->lru_lock?
If it is needed, doesn't mem_cgroup_isolate_pages need to use it too?

2. There's mem_cgroup_charge and mem_cgroup_cache_charge (wouldn't the
former be better called mem_cgroup_charge_mapped? why does the latter
test MEM_CGROUP_TYPE_ALL instead of MEM_CGROUP_TYPE_CACHED? I still don't
understand your enums there).  But there's only mem_cgroup_uncharge.
So when, for example, an add_to_page_cache fails, the uncharge may not
balance the charge?

3. mem_cgroup_charge_common has rcu_read_lock/unlock around its
rcu_dereference; mem_cgroup_cache_charge does not: is that right?

4. That page_assign_page_cgroup in free_hot_cold_page, what case is that
handling?  Wouldn't there be a leak if it ever happens?  I've been running
with a BUG_ON(page->page_cgroup) there and not hit it - should it perhaps
be a "Bad page state" case?

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/