[Bug 270283] would like an even safer LIST_FOREACH_SAFE()

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 17 Mar 2023 10:23:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270283

            Bug ID: 270283
           Summary: would like an even safer LIST_FOREACH_SAFE()
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: levon@movementarian.org

We hit the following situation:

 - we have a component with a list of callbacks.
 - those callbacks are themselves allowed to call back in and remove entries
from the list
 - LIST_FOREACH_SAFE() is used to safely protect against removal of the current
item
 - however, a callback is also legitimately allowed to remove any other item on
the list

This falls down when a callback removes the *next* item on the list - the macro
has already saved this in "tvar", so it will then try to use freed memory on
the next iteration.

We have fixed this with LIST_FOREACH_SAFER() / LIST_REMOVE_SAFER() variants:

#define LIST_FOREACH_SAFER(var, head, field, tvarp)     \       
        for ((var) = LIST_FIRST((head));                                       
\
            (var) && ((*tvarp) = LIST_NEXT((var), field), 1);           \
            (var) = (*tvarp))

#define LIST_REMOVE_SAFER(elm, field, elmp) do {                \
        if (elmp == elm) {                                                     
        \
                elmp = LIST_NEXT(elm, field);                           \
        };                                                                     
                \
        LIST_REMOVE(elm, field);                                               
\
} while (0)


Would like thoughts on whether this would be something more widely useful
before I prepare a PR and so on, thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.