linux-kernel - Re: [PATCH v8 3/4] cgroups: allow a cgroup subsystem to reject a fork

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150407140026.GK10582@htj.duckdns.org>
Date:	Tue, 7 Apr 2015 10:00:26 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Aleksa Sarai <cyphar@...har.com>
Cc:	lizefan@...wei.com, mingo@...hat.com, peterz@...radead.org,
	richard@....at,
	Frédéric Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org
Subject: Re: [PATCH v8 3/4] cgroups: allow a cgroup subsystem to reject a fork

On Tue, Apr 07, 2015 at 11:47:02PM +1000, Aleksa Sarai wrote:
> > [...] I don't
> > think it's a good idea to send the patches as-are because we can't
> > debug and fix them properly, right? [...]
> 
> In what way are they hard to debug?

Some failures can happen before console init and figuring out what's
going on can be tricky.

...
> difference between having an array of CGROUP_SUBSYS_COUNT pointers or
> CGROUP_PREFORK_COUNT is the few bytes of memory you've "saved" (at the expense
> of making the callback code essentially unreadable).

Hmmm?  Just define a marker macro so that the index can be extracted
and loop over the indices and call the callbacks?  Why would this be
any more complex than anything else?

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