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

[Wei Fang]

> > +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.