Linus Torvalds <[email protected]> wrote: > Dammit, you should *KNOW* that already from core logic. Not with a > flag, not with a function to ask, but from how things work. The whole > "am I on a list or not" should not be a list issue, it should be > obvious.
The circumstance in question is this: There's a list of outstanding calls attached to the rxrpc network namespace. Calls may hang around on it beyond the life of the socket that created them for a little bit to deal with network protocol cleanup, timer cleanup, work func cleanup. Under normal operation, calls are removed as the last ref is put. However, should the namespace be deleted, rxrpc_destroy_all_calls() trawls the list to report any calls that haven't been cleaned up and the calls are deleted from the list as it reports them so that the spinlock doesn't have to be kept held. It used to do other work here too, IIRC, but that's no longer the case, so perhaps this loop is not needed now, and a warning will suffice if the list is not empty (or I could just report, say, the first 10 calls and not worry about calling cond_resched()). The wait at the bottom of the function should be sufficient to hold up namespace deallocation. If I don't delete entries in rxrpc_destroy_all_calls(), then rxrpc_put_call() only needs list_empty() to guard against the call not having being queued yet. I could have a flag for that, but it would be superfluous. Note that the reason for the RCU walking is because /proc/net/rxrpc/calls walks over the same list, so I still need the next patch which switches to list_del_rcu(). David
