linux-kernel - Re: broken do_each_pid

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: <49A41E90.8090304@gmail.com>
Date:	Tue, 24 Feb 2009 17:21:36 +0100
From:	Jiri Slaby <jirislaby@...il.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>, kenchen@...gle.com,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: broken do_each_pid_{thread,task}

On 24.2.2009 16:49, Oleg Nesterov wrote:
> But why do you dislike it? Yes, the implementation of pid_for_each_task()
> is not simple. Partly because hlist_for_each_entry_rcu() is ugly and
> imho should be fixed (see btw http://marc.info/?t=120879441200004).
>
> But with this patch the callers become simpler, we can just do
>
> 	pid_for_each_task(pid, type, task)
> 		do_something(task);
>
> instead of
>
> 	 do_each_pid_task(pid, type, task) {
> 	 	do_something(task);
> 	 } while_each_pid_task(pid, type, task);
>
> and we can use break/continue safely.

I like what it does, not much how. Anyway I was thinking about 
hlist_for_each_entry_rcu_param or alike (which would take additional 
parameters for 3 `for' expressions to add to standard hlist for each 
ones), but I think it would be less readable than this:

>>> +#define pid_for_each_task(pid, type, p)	\
>>> +	for (p = (pid) ? (void*)(pid)->tasks[type].first : NULL;	\
>>> +	     rcu_dereference(p)&&   ({					\
>>> +		prefetch(((struct hlist_node*)p)->next);		\
>>> +		p = hlist_entry((void*)p, typeof(*p), pids[type].node);	\
>>> +		1; });							\
>>> +	     p = ((type) != PIDTYPE_PID) ?				\
>>> +		(void*)(p)->pids[type].node.next : NULL)
>>> +
>
> Really, is this too bad?

Well, it still can be worse :).

Ok, could you repost with commit log and proper CCs or merge anywhere to 
pull from?
--
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/