linux-kernel - Re: [PATCH 2/2] 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:	Sat, 21 Jan 2012 03:59:46 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Tejun Heo <tj@...nel.org>
Cc:	Kay Sievers <kay.sievers@...y.org>, Li Zefan <lizf@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>
Subject: Re: [PATCH 2/2] cgroup: add xattr support

On Wed, 18.01.12 18:20, Tejun Heo (tj@...nel.org) wrote:

Heya,

> * Probably I'm missing something but isn't the systemd cgroup
>   hierarchy already managed by systemd?  If so, I don't see how
>   managing tmpfs on the side would noticeably make things more
>   fragile.  It would take a bit more care after, for example, restart
>   but it shouldn't be too complex, no?

Well, it becomes more complex, for example, if we miss a cgroups event,
or we go away and come back (i.e. systemd can reexecute itself for
upgrades), and as soon as it isn't just systemd anymore which needs meta
data attached to a cgroup, but we need something shared. For example,
the logic described in
http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups
regarding "persistant" cgroups would be much nicer using xattrs (it
currently misuses the sticky bit as flag instead).

It's just much nicer if meta data doesn't get stale just because the
process owning it goes awol. And if process want to share meta data, too.

> * FS attributes already being used for userland information seems like
>   a good argument, but we shouldn't add separate specialized xattr
>   implementation to different pseudo filesystems.  For it to be
>   acceptable, it should be a libfs thing easily applicable to any
>   pseudo FS and definitely shouldn't be using kmem for storage.

I think the code that was recently added to tmpfs for the same purposes
was supposed to be reusable on other virtual file systems. Might be
worth looking into that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--
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/