[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpU8PjkQgmHRSi144L0LHUXrbOKYaetqUV3ECHzWs2cD-A@mail.gmail.com>
Date: Thu, 7 Jun 2018 17:13:41 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Ben Greear <greearb@...delatech.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
On Thu, Jun 7, 2018 at 4:48 PM, <greearb@...delatech.com> wrote:
> From: Ben Greear <greearb@...delatech.com>
>
> While testing an ath10k firmware that often crashed under load,
> I was seeing kernel crashes as well. One of them appeared to
> be a dereference of a NULL flow object in fq_tin_dequeue.
>
> I have since fixed the firmware flaw, but I think it would be
> worth adding the WARN_ON in case the problem appears again.
>
> BUG: unable to handle kernel NULL pointer dereference at 000000000000003c
> IP: ieee80211_tx_dequeue+0xfb/0xb10 [mac80211]
Instead of adding WARN_ON(), you need to think about
the locking there, it is suspicious:
fq is from struct ieee80211_local:
struct fq *fq = &local->fq;
tin is from struct txq_info:
struct fq_tin *tin = &txqi->tin;
I don't know if fq and tin are supposed to be 1:1, if not there is
a bug in the locking, because ->new_flows and ->old_flows are
both inside tin instead of fq, but they are protected by fq->lock....
Powered by blists - more mailing lists