[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191107140149.GB19482@otheros>
Date: Thu, 7 Nov 2019 15:03:31 +0100
From: Linus Lüssing <linus.luessing@...3.blue>
To: Ben Greear <greearb@...delatech.com>
Cc: Linus Lüssing <ll@...onwunderlich.de>,
ath10k@...ts.infradead.org, Kalle Valo <kvalo@...eaurora.org>,
"David S . Miller" <davem@...emloft.net>,
Simon Wunderlich <sw@...onwunderlich.de>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] ath10k: fix RX of frames with broken FCS in
monitor mode
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 <greearb@...delatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
Powered by blists - more mailing lists