On Fri, Jan 28, 2022 at 3:55 PM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
>
> On Fri, Jan 14, 2022 at 04:47:50PM +0100, Md Haris Iqbal wrote:
>
> > -/**
> > - * list_next_or_null_rr_rcu - get next list element in round-robin fashion.
> > - * @head: the head for the list.
> > - * @ptr: the list head to take the next element from.
> > - * @type: the type of the struct this is embedded in.
> > - * @memb: the name of the list_head within the struct.
> > - *
> > - * Next element returned in round-robin fashion, i.e. head will be skipped,
> > - * but if list is observed as empty, NULL will be returned.
> > - *
> > - * This primitive may safely run concurrently with the _rcu list-mutation
> > - * primitives such as list_add_rcu() as long as it's guarded by rcu_read_lock().
> > - */
> > -#define list_next_or_null_rr_rcu(head, ptr, type, memb) \
> > -({ \
> > - list_next_or_null_rcu(head, ptr, type, memb) ?: \
> > - list_next_or_null_rcu(head, READ_ONCE((ptr)->next), \
> > - type, memb); \
> > -})
>
> Why not put this in a static inline instead of open coding it? Type is
> always the same for both usages, right?
Yes. Makes sense. I will send this change along with the next patchset.
Thanks for the review and comment.
>
> Jason
