RE: [net-next,08/14] net: enetc: add multiple command BD rings support

Wei Fang
2026-03-19T02:16:36Z

> > +static struct netc_cbdr *netc_select_cbdr(struct ntmp_user *user)
> > +{
> > + int cpu, i;
> > +
> > + for (i = 0; i < user->cbdr_num; i++) {
> > + if (spin_is_locked(&user->ring[i].ring_lock))
> > + continue;
> > +
> > + return &user->ring[i];
> > + }
> > +
> > + /* If all the command BDRs are busy now, we select
> > + * one of them, but need to wait for a while to use.
> > + */
> > + cpu = smp_processor_id();
> > +
> > + return &user->ring[cpu % user->cbdr_num];
> > +}
> > +
>
> Can this trigger a preemption warning? netc_select_cbdr() is called from
> netc_xmit_ntmp_cmd() before spin_lock_bh() is acquired, and the callers
> (ntmp_maft_add_entry, ntmp_fdbt_add_entry, etc.) run in process context
> with preemption enabled.
>
> Using smp_processor_id() in preemptible code triggers a
> "BUG: using smp_processor_id() in preemptible code" warning under
> CONFIG_DEBUG_PREEMPT.
>
> Since the CPU value here is only used as a hint for ring selection and not
> for correctness, would raw_smp_processor_id() be more appropriate?
>

It seems to be a potential issue, raw_smp_processor_id() is more appropriate,
thanks.