From: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
To: Bing Zhao <bzhao@marvell.com>
Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Daniel Mack <daniel@zonque.org>,
"linville@tuxdriver.com" <linville@tuxdriver.com>,
Yogesh Powar <yogeshp@marvell.com>,
Avinash Patil <patila@marvell.com>
Subject: Re: mwifiex: infinite loop in mwifiex_main_process
Date: Tue, 2 Apr 2013 21:35:55 +0200 [thread overview]
Message-ID: <20130402193555.GA14343@blumentopf> (raw)
In-Reply-To: <477F20668A386D41ADCC57781B1F70430D9DDAAFDA@SC-VEXCH1.marvell.com>
On Tue, Apr 02, 2013 at 11:16:26AM -0700, Bing Zhao wrote:
> Hi Andi,
>
> [...]
>
> > + spin_lock_irqsave(&priv_tmp->wmm.ra_list_spinlock, flags);
> > + BUG_ON(atomic_read(&priv_tmp->wmm.tx_pkts_queued));
> > + spin_unlock_irqrestore(&priv_tmp->wmm.ra_list_spinlock, flags);
> > +
> > /* No packet at any TID for this priv. Mark as such
> > * to skip checking TIDs for this priv (until pkt is
> > * added).
> > atomic_set(hqp, NO_PKT_PRIO_TID);
> >
> >
> > Which crashed. Hence searching for queued packets and adding new ones is
> > not synchronized, new packets can be added while searching the WMM
> > queues. If a packet is added right before setting max prio to NO_PKT,
> > that packet is trapped and creates an infinite loop.
> >
> > Because of the new packet tx_pkts_queued is at least 1, indicating wmm
> > lists are not empty. Opposing that max prio is NO_PKT, which means "skip
> > this wmm queue, it has no packets".
> > The infinite loop results, because the main loop checks the wmm lists
> > for not empty (tx_pkts_queued != 0), but then finds no packet since it
> > skips the wmm queue where it is located on. This will never end, unless
> > a new packet is added which will restore max prio.
>
> Thanks for your analysis.
>
> > One possible solution is is to rely on tx_pkts_queued solely for
> > checking wmm queue to be empty, and drop the NO_PKT define.
>
> FYI, Yogesh suggested another fix (attached).
Started with similar patch, but then learned that NO_PKT_PRIO_TID
is not needed at all. It only adds complexity, rely on
tx_pkts_queued!
On top, bss_prio_tbl should be locked as well.
>
> [...]
>
> > seems to be intruduced with this patch:
> > 17e8cec 05-16-2011 mwifiex: CPU mips optimization with NO_PKT_PRIO_TID
> >
> > I was wondering why hasn't happened more frequently. Evtl. if the
> > interface is working in bridge mode, new packets might be added to the
> > WMM queue with the trapped packet. 2c
> >
> > I prepared a few patches, fixing above bug as suggested and plus some
> > cleanup patches I did while trying to get an understanding. Pls review.
>
> Thanks for the patches. We will review them and run some WMM tests.
Thanks, looking forward to that.
Andi
prev parent reply other threads:[~2013-04-02 19:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-19 9:52 mwifiex: infinite loop in mwifiex_main_process Andreas Fenkart
2013-03-19 22:37 ` Bing Zhao
2013-04-02 0:05 ` Andreas Fenkart
2013-04-02 0:08 ` [PATCH 1/6] mwifiex: bug: remove NO_PKT_PRIO_TID Andreas Fenkart
2013-04-02 0:08 ` [PATCH 2/6] mwifiex: bug: wrong list in list_empty check Andreas Fenkart
2013-04-02 0:08 ` [PATCH 3/6] mwifiex: remove unused tid_tbl_lock from mwifiex_tid_tbl Andreas Fenkart
2013-04-02 0:08 ` [PATCH 4/6] mwifiex: replace ra_list_curr by list rotation Andreas Fenkart
2013-04-02 0:08 ` [PATCH 5/6] mwifiex: rework round robin scheduling of bss nodes Andreas Fenkart
2013-04-02 0:08 ` [PATCH 6/6] mwifiex: hold proper locks when accessing ra_list / bss_prio lists Andreas Fenkart
2013-04-03 2:40 ` [PATCH 1/6] mwifiex: bug: remove NO_PKT_PRIO_TID Bing Zhao
2013-04-03 11:35 ` Andreas Fenkart
2013-04-03 18:37 ` Bing Zhao
2013-04-04 20:57 ` Andreas Fenkart
2013-04-04 21:01 ` [PATCH 1/4] mwifiex: bug: wrong list in list_empty check Andreas Fenkart
2013-04-04 21:01 ` [PATCH 2/4] mwifiex: remove unused tid_tbl_lock from mwifiex_tid_tbl Andreas Fenkart
2013-04-04 22:33 ` Bing Zhao
2013-04-04 21:01 ` [PATCH 3/4] mwifiex: bug: remove NO_PKT_PRIO_TID Andreas Fenkart
2013-04-04 22:34 ` Bing Zhao
2013-04-04 21:01 ` [PATCH 4/4] mwifiex: bug: hold proper locks when accessing ra_list / bss_prio lists Andreas Fenkart
2013-04-04 22:38 ` Bing Zhao
2013-04-04 22:29 ` [PATCH 1/4] mwifiex: bug: wrong list in list_empty check Bing Zhao
2013-04-04 21:08 ` [PATCH 1/2] mwifiex: replace ra_list_curr by list rotation Andreas Fenkart
2013-04-04 21:08 ` [PATCH 2/2] mwifiex: rework round robin scheduling of bss nodes Andreas Fenkart
2013-04-04 22:56 ` [PATCH 1/6] mwifiex: bug: remove NO_PKT_PRIO_TID Bing Zhao
2013-04-05 8:27 ` Andreas Fenkart
2013-04-08 18:19 ` Bing Zhao
2013-04-11 11:51 ` [PATCH v3 0/2] wmm queues handling simplificatons Andreas Fenkart
2013-04-11 11:51 ` [PATCH 1/2] mwifiex: replace ra_list_curr by list rotation Andreas Fenkart
2013-04-11 18:42 ` Bing Zhao
2013-04-11 11:51 ` [PATCH 2/2] mwifiex: rework round robin scheduling of bss nodes Andreas Fenkart
2013-04-11 18:43 ` Bing Zhao
2013-04-23 18:33 ` [PATCH v3 0/2] wmm queues handling simplificatons Bing Zhao
2013-04-23 18:48 ` John W. Linville
2013-04-23 18:51 ` Bing Zhao
2013-04-02 18:16 ` mwifiex: infinite loop in mwifiex_main_process Bing Zhao
2013-04-02 19:35 ` Andreas Fenkart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130402193555.GA14343@blumentopf \
--to=andreas.fenkart@streamunlimited.com \
--cc=bzhao@marvell.com \
--cc=daniel@zonque.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=patila@marvell.com \
--cc=yogeshp@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.