linux-kernel - Re: [PATCH v7 2/3] cgroups: add atomic-context per-thread subsystem callbacks

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: <20110124153228.GB24303@ghc17.ghc.andrew.cmu.edu>
Date:	Mon, 24 Jan 2011 10:32:28 -0500
From:	Ben Blum <bblum@...rew.cmu.edu>
To:	Paul Menage <menage@...gle.com>
Cc:	Ben Blum <bblum@...rew.cmu.edu>, linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org, akpm@...ux-foundation.org,
	ebiederm@...ssion.com, lizf@...fujitsu.com, matthltc@...ibm.com,
	oleg@...hat.com, David Rientjes <rientjes@...gle.com>,
	Miao Xie <miaox@...fujitsu.com>
Subject: Re: [PATCH v7 2/3] cgroups: add atomic-context per-thread
 subsystem callbacks

On Mon, Jan 24, 2011 at 12:38:06AM -0800, Paul Menage wrote:
> Hi Ben,
> 
> Finally finding a moment to actually look at these patches. Sorry it's
> been a while. Can you send the patches inline rather than as
> attachments in future?

Whoops, sure thing.

> 
> Reviewed-by: Paul Menage <menage@...gle.com>
> 
> This patch looks fine, although I think that freezer_can_attach_task()
> could be simplified to:
> 
> static int freezer_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk)
> {
>   if (__cgroup_freezing_or_frozen(tsk))
>     return -EBUSY;
>   return 0;
> }
> 
> since we guarantee that rcu_read_lock() is held across this call.

I put a note there that "rcu_read_lock allows recursive locking", to
denote that it's okay to double-lock when it's called from
cgroup_attach_proc. I guess this isn't very clear: the reason the lock
is there is because in cgroup_attach_task, I call it without
rcu_read_lock (not necessary in most cases), but freezer needs RCU there
in either case. I wrote in the documentation: "This may run in
rcu_read-side", which I guess isn't very clear either.

> 
> There appears to be a tiny bit of rot in kernel/cpu.c (due to the
> addition of the exit() callback) and memcontrol.c (due to some changes
> at the start of mem_cgroup_move_task()) but neither impact actual
> code.
> 
> I think that before actually pushing to mainline, we'll need to sort
> out the cpuset mempolicy yielding issue, since that could be a
> user-visible API change.
> 
> 
> Paul

Hmm. The quirks caused by this are specific to using cgroup.procs, and
since cgroup.procs is new, I wouldn't say this is an API "change"?

Thanks,
Ben
--
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/