Messages in this thread | | | Date | Fri, 7 Jun 2013 21:30:16 +0300 | Subject | Re: [PATCH 1/2] list: add list_for_each_entry_del | From | Andy Shevchenko <> |
| |
On Fri, Jun 7, 2013 at 7:36 PM, Jörn Engel <joern@logfs.org> wrote: > On Thu, 6 June 2013 22:49:22 +0300, Andy Shevchenko wrote: >> On Thu, Jun 6, 2013 at 9:12 PM, Jörn Engel <joern@logfs.org> wrote: >> > On Thu, 6 June 2013 22:32:55 +0300, Andy Shevchenko wrote: >> >> What the problem to use list_for_each_safe()? >> > >> > The loop may terminate with elements left on the list. There is more, >> > but I would consider this the main problem. >> >> I didn't quite get what you mean. > > Take two threads, one doing a list_for_each_entry_safe loop and > dropping the lock after list_del, the other doing list_add. Result is > that you finish the list_for_each_entry_safe loop with something > remaining on the list. > > spin_lock > list_for_each_entry_safe > list_del > spin_unlock
Who is doing such thing?
Usually if you unlock, you exit from function, or you already done iteration through the list.
Like lock() list_for_each_safe() { if (condition) { list_del() unlock() return; } } unlock() return;
In case you have to do unlock()/lock() routine inside iteration you always can do an additional check at the end
list_for_each_safe() { unlock(); lock(); } if (!list_empty()) { do_smth() } unlock();
Thus, I don't see how list*del will help.
> If you search for this pattern in the kernel, you won't find too many > examples. Quite likely that is because a) people realized this and > used a while (!list_empty()) loop to begin with or b) they started out > wrong and fixed the bug later. Not sure how many examples of b) there > are.
-- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |