[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Jul 2016 11:16:46 +0200
From: Petr Mladek <pmladek@...e.com>
To: Topi Miettinen <toiwoton@...il.com>
Cc: "Serge E. Hallyn" <serge@...lyn.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Tejun Heo <tj@...nel.org>, lkml <linux-kernel@...r.kernel.org>,
luto@...nel.org, Kees Cook <keescook@...omium.org>,
Jonathan Corbet <corbet@....net>,
Li Zefan <lizefan@...wei.com>,
Johannes Weiner <hannes@...xchg.org>,
Serge Hallyn <serge.hallyn@...onical.com>,
James Morris <james.l.morris@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
David Howells <dhowells@...hat.com>,
David Woodhouse <David.Woodhouse@...el.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
"open list:CAPABILITIES" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] capabilities: add capability cgroup controller
On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
> The attached patch would make any uses of capabilities generate audit
> messages. It works for simple tests as you can see from the commit
> message, but unfortunately the call to audit_cgroup_list() deadlocks the
> system when booting a full blown OS. There's no deadlock when the call
> is removed.
>
> I guess that in some cases, cgroup_mutex and/or css_set_lock could be
> already held earlier before entering audit_cgroup_list(). Holding the
> locks is however required by task_cgroup_from_root(). Is there any way
> to avoid this? For example, only print some kind of cgroup ID numbers
> (are there unique and stable IDs, available without locks?) for those
> cgroups where the task is registered in the audit message?
I am not sure if anyone know what really happens here. I suggest to
enable lockdep. It might detect possible deadlock even before it
really happens, see Documentation/locking/lockdep-design.txt
It can be enabled by
CONFIG_PROVE_LOCKING=y
It depends on
CONFIG_DEBUG_KERNEL=y
and maybe some more options, see lib/Kconfig.debug
Best Regards,
Petr
Powered by blists - more mailing lists