linux-kernel - Re: [PATCH v3 0/3] cgroup: add xattr support

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]

Date:	Wed, 18 Jul 2012 15:10:44 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Aristeu Rozanski <aris@...hat.com>, linux-kernel@...r.kernel.org,
	Li Zefan <lizefan@...wei.com>, Hillf Danton <dhillf@...il.com>
Subject: Re: [PATCH v3 0/3] cgroup: add xattr support

Hello, Hugh.

On Wed, Jul 18, 2012 at 01:02:03PM -0700, Hugh Dickins wrote:
> > I don't know.  I
> > really hope it used anonymous page cache instead of kmem tho.  Hugh,
> > would something like that be difficult?
> 
> Yes, it would be difficult.
> 
> You don't use the word "swappable", but I take that to be implicit
> when you say "anonymous ... instead of kmem": it might as well be
> kmem if it cannot be swapped.

Yeah, I just am not mm-savvy enough to be able to use the correct
term. :)

> So you're wondering whether to introduce a new category of swappable
> memory: not the original anon pages mapped into userspace, not shmem
> use of swappable pages, but xattrs in the cgroup filesystem?

But why do we need something completely new?  Can't we hijack some
inodes used by tmpfs and use them for xattr storage?  ie. Would it be
difficult to use tmpfs as backend storage for on-memory xattr?  With
that, we would already have the mechanism and interface(!) for
limiting the size.

> Or am I misunderstanding, or looking at this from the wrong angle?
> 
> If there's not a reasonable upper bound on what gets stored here
> (did I see the word "icon" earlier in the thread?  which made me
> think people would be loading their photo albums into these xattrs),
> maybe the problem does need turning around.
> 
> Let userspace manage a tmpfs hierarchy parallel to the cgroupfs one?

IIRC xattr for cgroupfs was suggested from systemd which currently is
using tmpfs to manage parallel hierarchy.  It's reportedly cumbersome
to keep in sync and they would much prefer if they can store metadata
right inside cgroup.  If we can have a shared implementation which
doesn't complicate each pseudo filesystem much, I think why not.

Thanks.

-- 
tejun
--
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/