On Tue, Nov 05, 2019 at 09:19:20AM -0800, Ben Greear wrote:
> Thanks for adding the counter. Since it us u32, I doubt you need the spin lock
> below?
Ok, I can remove the spin-lock.
Just for clarification though, if I recall correctly then an increment operator
is not guaranteed to work atomically. But you think it's unlikely
to race with a concurrent ++ and therefore it's fine for just a debug counter?
(and if it were racing, it'd just be a missed +1)
Or is there another mechanism that avoids concurrency in the
ath10k RX path?
>
> --Ben
>
> > + if (!(ar->filter_flags & FIF_FCSFAIL) &&
> > + status->flag & RX_FLAG_FAILED_FCS_CRC) {
> > + spin_lock_bh(&ar->data_lock);
> > + ar->stats.rx_crc_err_drop++;
> > + spin_unlock_bh(&ar->data_lock);
> > +
> > + dev_kfree_skb_any(skb);
> > + return;
> > + }
> > +
> > ath10k_dbg(ar, ATH10K_DBG_DATA,
> > "rx skb %pK len %u peer %pM %s %s sn %u %s%s%s%s%s%s %srate_idx %u vht_nss %u freq %u band %u flag 0x%x fcs-err %i mic-err %i amsdu-more %i\n",
> > skb,
> >
>
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>
On 11/07/2019 06:03 AM, Linus Lüssing wrote:
> On Tue, Nov 05, 2019 at 09:19:20AM -0800, Ben Greear wrote:
>> Thanks for adding the counter. Since it us u32, I doubt you need the spin lock
>> below?
>
> Ok, I can remove the spin-lock.
>
> Just for clarification though, if I recall correctly then an increment operator
> is not guaranteed to work atomically. But you think it's unlikely
> to race with a concurrent ++ and therefore it's fine for just a debug counter?
> (and if it were racing, it'd just be a missed +1)
I think it is fine to be off-by-one, and u32 is atomic so you would never read a really
weird number, like you can if u64 is non-atomically being incremented.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com