> That would be true if the test were "if > (list_empty(&pool->avail_page_list))". But it is testing the list > pointers in the item rather than the list pointers in the pool. It may > be a bit confusing if you have never seen that usage before, which is > why I added a comment. Basically, if you use list_del_init() instead of > list_del(), then you can use list_empty() on the item itself to test if > the item is present in a list or not. For example, the comments in > list.h warn not to use list_empty() on the entry after just list_del(): > > /** > * list_del - deletes entry from list. > * @entry: the element to delete from the list. > * Note: list_empty() on entry does not return true after this, the entry is > * in an undefined state. > */ Sorry for the crappy line length (fixed above). Should have just used Preformat in Thunderbird like always rather than following Documentation/process/email-clients.rst and changing mailnews.wraplength from 72 to 0. Anyway, I have been using list_del_init() for a long time in various places, but now I can't find where any of its useful features are documented. I will have to submit a separate patch to add more documentation for it. I find it useful for two things. 1) If you use list_del_init(), you can delete an item from a list multiple times without checking if it has already been deleted. So the following is safe: list_add(entry, list); list_del_init(entry); list_del_init(entry); That would not be safe if just using list_del(). 2) If you use list_del_init(), you can test if an item is present in a list using list_empty() on the entry. So: list_add(entry, list); /* list_empty(entry) is false */ list_del_init(entry); /* list_empty(entry) is true */ That would not work if using just list_del(). Since the list_empty() name is unintuitive for this purpose, it might be useful to add a new macro for this use case.
