linux-kernel - Re: [PATCHv4] procfs: show hierarchy of pid namespace

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:	Wed, 8 Oct 2014 17:13:28 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Chen Hanxiao <chenhanxiao@...fujitsu.com>
Cc:	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	David Howells <dhowells@...hat.com>,
	Richard Weinberger <richard.weinberger@...il.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Vasiliy Kulikov <segooon@...il.com>,
	Mateusz Guzik <mguzik@...hat.com>
Subject: Re: [PATCHv4] procfs: show hierarchy of pid namespace

Sorry if this was already discussed, I have to admit that I ignored
the previous discussion ;) And it is possible I misread this patch
completely.

On 10/08, Chen Hanxiao wrote:
>
> This patch will show the hierarchy of pid namespace
> by /proc/pidns_hierarchy like:
>
> [root@...alhost ~]#cat /proc/pidns_hierarchy
> /proc/18060/ns/pid /proc/18102/ns/pid /proc/1534/ns/pid
> /proc/18060/ns/pid /proc/18102/ns/pid /proc/1600/ns/pid
> /proc/1550/ns/pid

Well, personally I too think that the filenames look a bit strange,
can't it just print the numbers?

And, iiuc what this patch does... perhaps in this case we should
simply add "struct list_head children" into struct pid_namespace?
In this case the patch will be really simple. I dunno.

> +pidns_list_add(struct pid *pid, struct list_head *list_head,
> +		struct pid_namespace *curr_ns)
> +{
> +	struct pidns_list *ent;
> +	struct pid_namespace *ns;
> +
> +	if (is_child_reaper(pid)) {
> +		ent = kmalloc(sizeof(*ent), GFP_KERNEL);

GFP_KERNEL under rcu_read_lock(). This is not safe without
CONFIG_PREEMPT_RCU.

> +		if (!ent)
> +			return -ENOMEM;
> +
> +		ent->pid = pid;
> +		ns = pid->numbers[pid->level].ns;
> +		if (curr_ns) {
> +			/* add pids who is the child of curr_ns */
> +			for (; ns != NULL; ns = ns->parent)
> +				if (ns == curr_ns)
> +					list_add_tail(&ent->list, list_head);

afaics, it doesn't make sense to continue after list_add() ?

> +static int proc_pidns_list_refresh(struct pid_namespace *curr_ns)
> +{
> +	struct pid *pid;
> +	struct task_struct *p;
> +	int rc;
> +
> +	/* collect pid in differet ns */
> +	for_each_process(p) {

Hmm. We only want the tasks from our namespace, yes? Perhaps find_ge_pid()
makes more sense?

> +		pid = task_pid(p);

Well, in theory you need barrier() here. Or perhaps we should add
ACCESS_ONCE() into task_pid()...

And imho it would be better to declare pidns_list/pidns_tree locally
in nslist_proc_show() and pass them to the callees.

Oleg.

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