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: <20120720175959.GA32741@cathedrallabs.org>
Date:	Fri, 20 Jul 2012 13:59:59 -0400
From:	Aristeu Rozanski <aris@...vo.org>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Tejun Heo <tj@...nel.org>, 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

Hugh,
On Wed, Jul 18, 2012 at 06:11:32PM -0700, Hugh Dickins wrote:
> > 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.
> 
> That sounds just like what I was suggesting in my last sentence:
> let userspace manage a tmpfs hierarchy parallel to the cgroupfs one.
> 
> Except, perhaps, where I assume "userspace" should be doing the hard work.

hm, not sure that's what Tejun meant. tmpfs uses anonymous memory for the file
contents, so reuse that infrastructure to allocate space for the extended
attributes the same way, instead of using kmem.

First thing I can think of is to use whole pages for it to prevent further
complexity. Shouldn't make much difference considering the usecases we have
now (systemd and containers), right?

--
Aristeu

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ