* broken do_each_pid_{thread,task}
@ 2008-12-14 21:59 Jiri Slaby
2008-12-15 1:02 ` Eric W. Biederman
2008-12-15 10:24 ` broken do_each_pid_{thread,task} Oleg Nesterov
0 siblings, 2 replies; 14+ messages in thread
From: Jiri Slaby @ 2008-12-14 21:59 UTC (permalink / raw)
To: oleg; +Cc: kenchen, Linux kernel mailing list, Eric W. Biederman
Hi,
I'm getting
`if (type == PIDTYPE_PID)' is unreachable
warning from kernel/exit.c. The preprocessed code looks like:
do {
struct hlist_node *pos___;
if (pgrp != ((void *)0))
for (LIST ITERATION) {
{
if (!((p->state & 4) != 0))
continue;
retval = 1;
break;
}
if (PIDTYPE_PGID == PIDTYPE_PID)
break;
}
} while (0);
and it's obviously wrong.
After investigating this code usage all around, it's broken on many places
this or similar way.
For do_each_pid_thread(), even this code snippet from fs/ioprio.c is broken
due to double do {} while expansion:
do_each_pid_thread(pgrp, PIDTYPE_PGID, p) {
ret = set_task_ioprio(p, ioprio);
if (ret)
break;
} while_each_pid_thread(pgrp, PIDTYPE_PGID, p);
Any idea how to get rid of this issue?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-14 21:59 broken do_each_pid_{thread,task} Jiri Slaby
@ 2008-12-15 1:02 ` Eric W. Biederman
2008-12-15 10:47 ` Oleg Nesterov
2008-12-15 10:24 ` broken do_each_pid_{thread,task} Oleg Nesterov
1 sibling, 1 reply; 14+ messages in thread
From: Eric W. Biederman @ 2008-12-15 1:02 UTC (permalink / raw)
To: Jiri Slaby; +Cc: oleg, kenchen, Linux kernel mailing list
Jiri Slaby <jirislaby@gmail.com> writes:
> Hi,
>
> I'm getting
> `if (type == PIDTYPE_PID)' is unreachable
> warning from kernel/exit.c. The preprocessed code looks like:
> do {
> struct hlist_node *pos___;
> if (pgrp != ((void *)0))
> for (LIST ITERATION) {
> {
> if (!((p->state & 4) != 0))
> continue;
> retval = 1;
> break;
> }
> if (PIDTYPE_PGID == PIDTYPE_PID)
> break;
> }
> } while (0);
> and it's obviously wrong.
Actually the test:
> if (PIDTYPE_PGID == PIDTYPE_PID)
> break;
Is technically ok. The compiler should optimize it out instead of warning.
Although seeing the unexpected corner case it gets us into I think it would
be good to reconsider this test.
The break statement is also fine because the outer loop is only executed
once so it simply functions as an enclosing block, and the break transfers
control to where it should go.
> After investigating this code usage all around, it's broken on many places
> this or similar way.
>
> For do_each_pid_thread(), even this code snippet from fs/ioprio.c is broken
> due to double do {} while expansion:
> do_each_pid_thread(pgrp, PIDTYPE_PGID, p) {
> ret = set_task_ioprio(p, ioprio);
> if (ret)
> break;
> } while_each_pid_thread(pgrp, PIDTYPE_PGID, p);
>
> Any idea how to get rid of this issue?
The double loop there is certainly an issue. I'm not quite convinced that
the error handling is correct even with the break statement. But the
break statement was written when the code was just a single loop, so the
behavior is definitely not what we intended.
However I also agree with Ken Chen's assessment that we need to loop over
threads and not just the process group leaders in some cases such as
setting the io-priority.
With respect to error handling and IO priorities can we fix the error handling
by doing what we do when we send a signal to a process group? That is note
that there was an error, finish processing all of the other processes and then
return the error?
Eric
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-14 21:59 broken do_each_pid_{thread,task} Jiri Slaby
2008-12-15 1:02 ` Eric W. Biederman
@ 2008-12-15 10:24 ` Oleg Nesterov
2008-12-15 10:50 ` Jiri Slaby
1 sibling, 1 reply; 14+ messages in thread
From: Oleg Nesterov @ 2008-12-15 10:24 UTC (permalink / raw)
To: Jiri Slaby; +Cc: kenchen, Linux kernel mailing list, Eric W. Biederman
On 12/14, Jiri Slaby wrote:
>
> I'm getting
> `if (type == PIDTYPE_PID)' is unreachable
> warning from kernel/exit.c. The preprocessed code looks like:
> do {
> struct hlist_node *pos___;
> if (pgrp != ((void *)0))
> for (LIST ITERATION) {
> {
> if (!((p->state & 4) != 0))
> continue;
> retval = 1;
> break;
> }
> if (PIDTYPE_PGID == PIDTYPE_PID)
> break;
> }
> } while (0);
> and it's obviously wrong.
Why do you think it is wrong? This break stops the "hlist_for_each"
loop, not the enclosing "do while".
Actually, I don't understand why the compiler complains, and I never
saw a warning myself.
But the check is ugly indeed, that is why the patch was named "uglify ...".
> After investigating this code usage all around, it's broken on many places
> this or similar way.
>
> For do_each_pid_thread(), even this code snippet from fs/ioprio.c is broken
> due to double do {} while expansion:
> do_each_pid_thread(pgrp, PIDTYPE_PGID, p) {
> ret = set_task_ioprio(p, ioprio);
> if (ret)
> break;
> } while_each_pid_thread(pgrp, PIDTYPE_PGID, p);
Yes, this is obviously not what was intended. But afaics, this is
the only place which should be fixed?
> Any idea how to get rid of this issue?
We had the similar bug for IOPRIO_WHO_USER case, iirc. Probably
we can fix it the same way:
--- a/fs/ioprio.c
+++ b/fs/ioprio.c
@@ -118,8 +118,9 @@ asmlinkage long sys_ioprio_set(int which
do_each_pid_thread(pgrp, PIDTYPE_PGID, p) {
ret = set_task_ioprio(p, ioprio);
if (ret)
- break;
+ goto end_pgrp;
} while_each_pid_thread(pgrp, PIDTYPE_PGID, p);
+end_pgrp:
break;
case IOPRIO_WHO_USER:
if (!who)
Oleg.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-15 1:02 ` Eric W. Biederman
@ 2008-12-15 10:47 ` Oleg Nesterov
2008-12-15 17:09 ` Oleg Nesterov
0 siblings, 1 reply; 14+ messages in thread
From: Oleg Nesterov @ 2008-12-15 10:47 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Jiri Slaby, kenchen, Linux kernel mailing list
On 12/14, Eric W. Biederman wrote:
>
> Jiri Slaby <jirislaby@gmail.com> writes:
> >
> > I'm getting
> > `if (type == PIDTYPE_PID)' is unreachable
> > warning from kernel/exit.c. The preprocessed code looks like:
> > do {
> > struct hlist_node *pos___;
> > if (pgrp != ((void *)0))
> > for (LIST ITERATION) {
> > {
> > if (!((p->state & 4) != 0))
> > continue;
> > retval = 1;
> > break;
> > }
> > if (PIDTYPE_PGID == PIDTYPE_PID)
> > break;
> > }
> > } while (0);
> > and it's obviously wrong.
>
> Actually the test:
> > if (PIDTYPE_PGID == PIDTYPE_PID)
> > break;
> Is technically ok. The compiler should optimize it out instead of warning.
> Although seeing the unexpected corner case it gets us into I think it would
> be good to reconsider this test.
Agreed. This check uglifies the code to fix the theoretical problem.
But, actually do_each_pid_task() is a bit ugly even without this check.
Lets forget about this check for a moment.
Firstly, all hlist_for_each_entry() helpers should be "fixed", we don't
need the second argument. For example, hlist_for_each_entry_rcu() could
be
#define hlist_for_each_entry_rcu(pos, head, member) \
for (pos = (void*)(head)->first; rcu_dereference(pos) && ({ \
prefetch(((struct hlist_node*)pos)->next); \
pos = hlist_entry((void*)pos, typeof(*pos), member); 1; \
}); pos = (void*)(pos)->member.next)
So we can define
#define for_each_pid_task(pid, type, task)
for (task = pid ? (void*)((pid)->tasks + type)->first : NULL; \
rcu_dereference(task) && ({ \
prefetch(((struct hlist_node*)task)->next); \
task = hlist_entry((void*)task, typeof(*task), pids[type].node); 1; \
}); task = (void*)(task)->pids[type].node.next)
Which can be used just
for_each_pid_task(pid, type, task)
do_something(task);
Not that I think it is worth to do, though ;)
We can even restore the ugly special case for PIDTYPE_PID:
#define for_each_pid_task(pid, type, task)
for (task = pid ? (void*)((pid)->tasks + type)->first : NULL; \
rcu_dereference(task) && ({ \
prefetch(((struct hlist_node*)task)->next); \
task = hlist_entry((void*)task, typeof(*task), pids[type].node); 1; }) \
task = (type != PIDTYPE_PID) ? (void*)(task)->pids[type].node.next : NULL)
> > For do_each_pid_thread(), even this code snippet from fs/ioprio.c is broken
> > due to double do {} while expansion:
> > do_each_pid_thread(pgrp, PIDTYPE_PGID, p) {
> > ret = set_task_ioprio(p, ioprio);
> > if (ret)
> > break;
> > } while_each_pid_thread(pgrp, PIDTYPE_PGID, p);
> >
> > Any idea how to get rid of this issue?
>
> The double loop there is certainly an issue. I'm not quite convinced that
> the error handling is correct even with the break statement. But the
> break statement was written when the code was just a single loop, so the
> behavior is definitely not what we intended.
Yes,
> With respect to error handling and IO priorities can we fix the error handling
> by doing what we do when we send a signal to a process group? That is note
> that there was an error, finish processing all of the other processes and then
> return the error?
Personally, I think you are right. But then we should change IOPRIO_WHO_USER
accordingly, imho.
Oleg.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-15 10:24 ` broken do_each_pid_{thread,task} Oleg Nesterov
@ 2008-12-15 10:50 ` Jiri Slaby
2008-12-15 11:02 ` Oleg Nesterov
0 siblings, 1 reply; 14+ messages in thread
From: Jiri Slaby @ 2008-12-15 10:50 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: kenchen, Linux kernel mailing list, Eric W. Biederman
Oleg Nesterov napsal(a):
> On 12/14, Jiri Slaby wrote:
>> I'm getting
>> `if (type == PIDTYPE_PID)' is unreachable
>> warning from kernel/exit.c. The preprocessed code looks like:
>> do {
>> struct hlist_node *pos___;
>> if (pgrp != ((void *)0))
>> for (LIST ITERATION) {
>> {
>> if (!((p->state & 4) != 0))
>> continue;
>> retval = 1;
>> break;
>> }
>> if (PIDTYPE_PGID == PIDTYPE_PID)
>> break;
>> }
>> } while (0);
>> and it's obviously wrong.
>
> Why do you think it is wrong? This break stops the "hlist_for_each"
> loop, not the enclosing "do while".
The `continue' matters here (and also in other do_each_pid_task cases).
Sorry for not mentioning it explicitly.
> Actually, I don't understand why the compiler complains, and I never
> saw a warning myself.
Because the `if' is not reachable :). (And it's not compiler which complains
here.)
>> After investigating this code usage all around, it's broken on many places
>> this or similar way.
>>
>> For do_each_pid_thread(), even this code snippet from fs/ioprio.c is broken
>> due to double do {} while expansion:
>> do_each_pid_thread(pgrp, PIDTYPE_PGID, p) {
>> ret = set_task_ioprio(p, ioprio);
>> if (ret)
>> break;
>> } while_each_pid_thread(pgrp, PIDTYPE_PGID, p);
>
> Yes, this is obviously not what was intended. But afaics, this is
> the only place which should be fixed?
Actually yes. And add a big warning to the macros or whatever to not get
into it later again.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-15 10:50 ` Jiri Slaby
@ 2008-12-15 11:02 ` Oleg Nesterov
2008-12-15 11:33 ` Jiri Slaby
0 siblings, 1 reply; 14+ messages in thread
From: Oleg Nesterov @ 2008-12-15 11:02 UTC (permalink / raw)
To: Jiri Slaby; +Cc: kenchen, Linux kernel mailing list, Eric W. Biederman
On 12/15, Jiri Slaby wrote:
>
> Oleg Nesterov napsal(a):
> > On 12/14, Jiri Slaby wrote:
> >> I'm getting
> >> `if (type == PIDTYPE_PID)' is unreachable
> >> warning from kernel/exit.c. The preprocessed code looks like:
> >> do {
> >> struct hlist_node *pos___;
> >> if (pgrp != ((void *)0))
> >> for (LIST ITERATION) {
> >> {
> >> if (!((p->state & 4) != 0))
> >> continue;
> >> retval = 1;
> >> break;
> >> }
> >> if (PIDTYPE_PGID == PIDTYPE_PID)
> >> break;
> >> }
> >> } while (0);
> >> and it's obviously wrong.
> >
> > Why do you think it is wrong? This break stops the "hlist_for_each"
> > loop, not the enclosing "do while".
>
> The `continue' matters here (and also in other do_each_pid_task cases).
> Sorry for not mentioning it explicitly.
Still can't understand... OK, I think we misundersood each other.
Do you agree that the code is technically correct? Or I missed
something?
"continue" looks fine to me too, it is also for the inner loop.
> > Actually, I don't understand why the compiler complains, and I never
> > saw a warning myself.
>
> Because the `if' is not reachable :).
Yes, I see it is not reachable, but I don't understand why this
deserves a warning ;)
Look, "if (PIDTYPE_PGID == PIDTYPE_PID)" is not possible too, should
the compiler (or whatever) complain?
> (And it's not compiler which complains
> here.)
Ah, OK, thanks. Just curious, and who does?
> > Yes, this is obviously not what was intended. But afaics, this is
> > the only place which should be fixed?
>
> Actually yes. And add a big warning to the macros or whatever to not get
> into it later again.
Agreed.
Oleg.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-15 11:02 ` Oleg Nesterov
@ 2008-12-15 11:33 ` Jiri Slaby
2008-12-15 11:51 ` Oleg Nesterov
0 siblings, 1 reply; 14+ messages in thread
From: Jiri Slaby @ 2008-12-15 11:33 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: kenchen, Linux kernel mailing list, Eric W. Biederman
Oleg Nesterov napsal(a):
> On 12/15, Jiri Slaby wrote:
>> Oleg Nesterov napsal(a):
>>> On 12/14, Jiri Slaby wrote:
>>>> I'm getting
>>>> `if (type == PIDTYPE_PID)' is unreachable
>>>> warning from kernel/exit.c. The preprocessed code looks like:
>>>> do {
>>>> struct hlist_node *pos___;
>>>> if (pgrp != ((void *)0))
>>>> for (LIST ITERATION) {
>>>> {
>>>> if (!((p->state & 4) != 0))
>>>> continue;
>>>> retval = 1;
>>>> break;
>>>> }
>>>> if (PIDTYPE_PGID == PIDTYPE_PID)
>>>> break;
>>>> }
>>>> } while (0);
>>>> and it's obviously wrong.
>>> Why do you think it is wrong? This break stops the "hlist_for_each"
>>> loop, not the enclosing "do while".
>> The `continue' matters here (and also in other do_each_pid_task cases).
>> Sorry for not mentioning it explicitly.
>
> Still can't understand... OK, I think we misundersood each other.
> Do you agree that the code is technically correct? Or I missed
> something?
>
> "continue" looks fine to me too, it is also for the inner loop.
But it doesn't jump to the `if' (this is what I would expect from the
`continue' here), but to the third statement of the `for'.
Maybe better to ask, is the test expected to be fired after *each*
invocation of the body?
>>> Actually, I don't understand why the compiler complains, and I never
>>> saw a warning myself.
>> Because the `if' is not reachable :).
>
> Yes, I see it is not reachable, but I don't understand why this
> deserves a warning ;)
>
> Look, "if (PIDTYPE_PGID == PIDTYPE_PID)" is not possible too, should
> the compiler (or whatever) complain?
Correct, in this particular case (and I checked that also other users which
uses `continue' inside the loop don't pass PIDTYPE_PID).
>> (And it's not compiler which complains
>> here.)
>
> Ah, OK, thanks. Just curious, and who does?
A static analyzer. Stay tuned, we will announce it later, it's in the state
of development :).
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-15 11:33 ` Jiri Slaby
@ 2008-12-15 11:51 ` Oleg Nesterov
2009-10-12 10:55 ` Jiri Slaby
0 siblings, 1 reply; 14+ messages in thread
From: Oleg Nesterov @ 2008-12-15 11:51 UTC (permalink / raw)
To: Jiri Slaby; +Cc: kenchen, Linux kernel mailing list, Eric W. Biederman
On 12/15, Jiri Slaby wrote:
>
> Oleg Nesterov napsal(a):
> > On 12/15, Jiri Slaby wrote:
> >> Oleg Nesterov napsal(a):
> >>> On 12/14, Jiri Slaby wrote:
> >>>> I'm getting
> >>>> `if (type == PIDTYPE_PID)' is unreachable
> >>>> warning from kernel/exit.c. The preprocessed code looks like:
> >>>> do {
> >>>> struct hlist_node *pos___;
> >>>> if (pgrp != ((void *)0))
> >>>> for (LIST ITERATION) {
> >>>> {
> >>>> if (!((p->state & 4) != 0))
> >>>> continue;
> >>>> retval = 1;
> >>>> break;
> >>>> }
> >>>> if (PIDTYPE_PGID == PIDTYPE_PID)
> >>>> break;
> >>>> }
> >>>> } while (0);
> >>>> and it's obviously wrong.
> >>> Why do you think it is wrong? This break stops the "hlist_for_each"
> >>> loop, not the enclosing "do while".
> >> The `continue' matters here (and also in other do_each_pid_task cases).
> >> Sorry for not mentioning it explicitly.
> >
> > Still can't understand... OK, I think we misundersood each other.
> > Do you agree that the code is technically correct? Or I missed
> > something?
> >
> > "continue" looks fine to me too, it is also for the inner loop.
>
> But it doesn't jump to the `if' (this is what I would expect from the
> `continue' here), but to the third statement of the `for'.
Yes, but this doesn't matter,
> Maybe better to ask, is the test expected to be fired after *each*
> invocation of the body?
Yes, but we need this only when type == PIDTYPE_PID, so the code
is correct.
> > Look, "if (PIDTYPE_PGID == PIDTYPE_PID)" is not possible too, should
> > the compiler (or whatever) complain?
>
> Correct, in this particular case (and I checked that also other users which
> uses `continue' inside the loop don't pass PIDTYPE_PID).
Yes.
Don't get me wrong, I do agree (let me repeat again) this check is
absolutely ugly and may cause the problems.
As I said, it fixes the minor and only theoretical problem. Perhaps we
can move this check to the code which does do_each_pid_task(PIDTYPE_PID).
Or better yet, just introduce for_each_pid_task() (see another email).
> >> (And it's not compiler which complains
> >> here.)
> >
> > Ah, OK, thanks. Just curious, and who does?
>
> A static analyzer. Stay tuned, we will announce it later, it's in the state
> of development :).
Great, thanks ;)
Oleg.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-15 10:47 ` Oleg Nesterov
@ 2008-12-15 17:09 ` Oleg Nesterov
2009-02-24 13:22 ` Jiri Slaby
0 siblings, 1 reply; 14+ messages in thread
From: Oleg Nesterov @ 2008-12-15 17:09 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Jiri Slaby, kenchen, Linux kernel mailing list
On 12/15, Oleg Nesterov wrote:
>
> On 12/14, Eric W. Biederman wrote:
> >
> > Although seeing the unexpected corner case it gets us into I think it would
> > be good to reconsider this test.
So. I can't decide whether this patch is cleanup or the further
uglification, but if anyone likes it I will be happy to send it.
Then we can kill do_each_pid_task/while_each_pid_task completely.
Oleg.
--- linux-2.6.27/include/linux/pid.h~PID_FOR_EACH 2008-10-10 00:13:53.000000000 +0200
+++ linux-2.6.27/include/linux/pid.h 2008-12-15 17:51:50.000000000 +0100
@@ -144,21 +144,25 @@ static inline pid_t pid_nr(struct pid *p
pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns);
pid_t pid_vnr(struct pid *pid);
+/*
+ * Both old and new leaders may be attached to the same pid in the
+ * middle of de_thread(), that is why we do the special check for
+ * PIDTYPE_PID below.
+ */
+#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)
+
#define do_each_pid_task(pid, type, task) \
do { \
- struct hlist_node *pos___; \
- if (pid != NULL) \
- hlist_for_each_entry_rcu((task), pos___, \
- &pid->tasks[type], pids[type].node) {
+ pid_for_each_task(pid, type, task)
- /*
- * Both old and new leaders may be attached to
- * the same pid in the middle of de_thread().
- */
#define while_each_pid_task(pid, type, task) \
- if (type == PIDTYPE_PID) \
- break; \
- } \
} while (0)
#define do_each_pid_thread(pid, type, task) \
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-15 17:09 ` Oleg Nesterov
@ 2009-02-24 13:22 ` Jiri Slaby
2009-02-24 15:49 ` Oleg Nesterov
0 siblings, 1 reply; 14+ messages in thread
From: Jiri Slaby @ 2009-02-24 13:22 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric W. Biederman, kenchen, Linux kernel mailing list
On 15.12.2008 18:09, Oleg Nesterov wrote:
> On 12/15, Oleg Nesterov wrote:
>> On 12/14, Eric W. Biederman wrote:
>>> Although seeing the unexpected corner case it gets us into I think it would
>>> be good to reconsider this test.
>
> So. I can't decide whether this patch is cleanup or the further
> uglification, but if anyone likes it I will be happy to send it.
FWIW I don't like the patch :), but noone else appears to dislike it.
Ideas, comments?
Otherwise I'll add at least a big warning about using break/cont
statements inside the loop.
> Then we can kill do_each_pid_task/while_each_pid_task completely.
>
> Oleg.
>
> --- linux-2.6.27/include/linux/pid.h~PID_FOR_EACH 2008-10-10 00:13:53.000000000 +0200
> +++ linux-2.6.27/include/linux/pid.h 2008-12-15 17:51:50.000000000 +0100
> @@ -144,21 +144,25 @@ static inline pid_t pid_nr(struct pid *p
> pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns);
> pid_t pid_vnr(struct pid *pid);
>
> +/*
> + * Both old and new leaders may be attached to the same pid in the
> + * middle of de_thread(), that is why we do the special check for
> + * PIDTYPE_PID below.
> + */
> +#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)
> +
> #define do_each_pid_task(pid, type, task) \
> do { \
> - struct hlist_node *pos___; \
> - if (pid != NULL) \
> - hlist_for_each_entry_rcu((task), pos___, \
> - &pid->tasks[type], pids[type].node) {
> + pid_for_each_task(pid, type, task)
>
> - /*
> - * Both old and new leaders may be attached to
> - * the same pid in the middle of de_thread().
> - */
> #define while_each_pid_task(pid, type, task) \
> - if (type == PIDTYPE_PID) \
> - break; \
> - } \
> } while (0)
>
> #define do_each_pid_thread(pid, type, task) \
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2009-02-24 13:22 ` Jiri Slaby
@ 2009-02-24 15:49 ` Oleg Nesterov
2009-02-24 16:21 ` Jiri Slaby
0 siblings, 1 reply; 14+ messages in thread
From: Oleg Nesterov @ 2009-02-24 15:49 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Eric W. Biederman, kenchen, Linux kernel mailing list
On 02/24, Jiri Slaby wrote:
>
> On 15.12.2008 18:09, Oleg Nesterov wrote:
>> On 12/15, Oleg Nesterov wrote:
>>> On 12/14, Eric W. Biederman wrote:
>>>> Although seeing the unexpected corner case it gets us into I think it would
>>>> be good to reconsider this test.
>>
>> So. I can't decide whether this patch is cleanup or the further
>> uglification, but if anyone likes it I will be happy to send it.
>
> FWIW I don't like the patch :)
Well, I agree, it is not very nice ;)
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.
> Otherwise I'll add at least a big warning about using break/cont
> statements inside the loop.
Agreed, this would be nice.
>> +#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?
Oleg.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2009-02-24 15:49 ` Oleg Nesterov
@ 2009-02-24 16:21 ` Jiri Slaby
2009-02-24 21:49 ` [RFC, PATCH] introduce pid_for_each_task() to replace do_each_pid_task() Oleg Nesterov
0 siblings, 1 reply; 14+ messages in thread
From: Jiri Slaby @ 2009-02-24 16:21 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric W. Biederman, kenchen, Linux kernel mailing list
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC, PATCH] introduce pid_for_each_task() to replace do_each_pid_task()
2009-02-24 16:21 ` Jiri Slaby
@ 2009-02-24 21:49 ` Oleg Nesterov
0 siblings, 0 replies; 14+ messages in thread
From: Oleg Nesterov @ 2009-02-24 21:49 UTC (permalink / raw)
To: Andrew Morton, Eric W. Biederman, Jiri Slaby, kenchen,
Sukadev Bhattiprolu
Cc: linux-kernel
pid_for_each_task() does the same as
do_each_pid_task() + while_each_pid_task(), so instead of
do_each_pid_task(pid, type, task) {
do_something(task);
} while_each_pid_task(pid, type, task);
we can just do
pid_for_each_task(pid, type, task)
do_something(task);
This looks better, and we can use break/continue safely.
This patch changes do_each_pid_task() to use pid_for_each_task(), once
we convert all users of do_each_pid_task() we can kill this helper.
However. The implementation of pid_for_each_task() itself is anything
but clean/simple, so this patch asks for the explicit acks/nacks.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
--- 6.29-rc3/include/linux/pid.h~FOR_EACH_PID 2009-01-12 23:07:48.000000000 +0100
+++ 6.29-rc3/include/linux/pid.h 2009-02-24 22:07:48.000000000 +0100
@@ -162,21 +162,25 @@ static inline pid_t pid_nr(struct pid *p
pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns);
pid_t pid_vnr(struct pid *pid);
+/*
+ * Both old and new leaders may be attached to the same pid in the
+ * middle of de_thread(), that is why we do the special check for
+ * PIDTYPE_PID below.
+ */
+#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)
+
#define do_each_pid_task(pid, type, task) \
do { \
- struct hlist_node *pos___; \
- if ((pid) != NULL) \
- hlist_for_each_entry_rcu((task), pos___, \
- &(pid)->tasks[type], pids[type].node) {
+ pid_for_each_task(pid, type, task)
- /*
- * Both old and new leaders may be attached to
- * the same pid in the middle of de_thread().
- */
#define while_each_pid_task(pid, type, task) \
- if (type == PIDTYPE_PID) \
- break; \
- } \
} while (0)
#define do_each_pid_thread(pid, type, task) \
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: broken do_each_pid_{thread,task}
2008-12-15 11:51 ` Oleg Nesterov
@ 2009-10-12 10:55 ` Jiri Slaby
0 siblings, 0 replies; 14+ messages in thread
From: Jiri Slaby @ 2009-10-12 10:55 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: kenchen, Linux kernel mailing list, Eric W. Biederman
On 12/15/2008 12:51 PM, Oleg Nesterov wrote:
> On 12/15, Jiri Slaby wrote:
>>
>> Oleg Nesterov napsal(a):
>>> On 12/15, Jiri Slaby wrote:
>>>> (And it's not compiler which complains
>>>> here.)
>>>
>>> Ah, OK, thanks. Just curious, and who does?
>>
>> A static analyzer. Stay tuned, we will announce it later, it's in the state
>> of development :).
>
> Great, thanks ;)
It got released a minute ago. If you are interested:
http://lkml.org/lkml/2009/10/12/133
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-10-12 10:57 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-14 21:59 broken do_each_pid_{thread,task} Jiri Slaby
2008-12-15 1:02 ` Eric W. Biederman
2008-12-15 10:47 ` Oleg Nesterov
2008-12-15 17:09 ` Oleg Nesterov
2009-02-24 13:22 ` Jiri Slaby
2009-02-24 15:49 ` Oleg Nesterov
2009-02-24 16:21 ` Jiri Slaby
2009-02-24 21:49 ` [RFC, PATCH] introduce pid_for_each_task() to replace do_each_pid_task() Oleg Nesterov
2008-12-15 10:24 ` broken do_each_pid_{thread,task} Oleg Nesterov
2008-12-15 10:50 ` Jiri Slaby
2008-12-15 11:02 ` Oleg Nesterov
2008-12-15 11:33 ` Jiri Slaby
2008-12-15 11:51 ` Oleg Nesterov
2009-10-12 10:55 ` Jiri Slaby
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox