All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Ganapathi Bhat <gbhat@marvell.com>,
	Nishant Sarmukadam <nishants@marvell.com>,
	Amitkumar Karwar <amitkarwar@gmail.com>,
	Xinming Hu <huxinming820@gmail.com>,
	<linux-kernel@vger.kernel.org>,
	linux-wireless@vger.kernel.org,
	Doug Anderson <dianders@chromium.org>,
	Brian Norris <briannorris@chromium.org>
Subject: Re: [PATCH 1/2] mwifiex: dispatch/rotate from reorder table atomically
Date: Tue, 25 Jun 2019 04:45:25 +0000 (UTC)	[thread overview]
Message-ID: <20190625044525.6A45F60A00@smtp.codeaurora.org> (raw)
In-Reply-To: <20190604205323.200361-2-briannorris@chromium.org>

Brian Norris <briannorris@chromium.org> wrote:

> mwifiex_11n_scan_and_dispatch() and
> mwifiex_11n_dispatch_pkt_until_start_win() share similar patterns, where
> they perform a few different actions on the same table, using the same
> lock, but non-atomically. There have been other attempts to clean up
> this sort of behavior, but they have had problems (incomplete;
> introducing new deadlocks).
> 
> We can improve these functions' atomicity by queueing up our RX packets
> in a list, to dispatch at the end of the function. This avoids problems
> of another operation modifying the table in between our dispatch and
> rotation operations.
> 
> This was inspired by investigations around this:
> 
>   http://lkml.kernel.org/linux-wireless/20181130175957.167031-1-briannorris@chromium.org
>   Subject: [4.20 PATCH] Revert "mwifiex: restructure rx_reorder_tbl_lock usage"
> 
> While the original (now-reverted) patch had good intentions in
> restructuring some of the locking patterns in this driver, it missed an
> important detail: we cannot defer to softirq contexts while already in
> an atomic context. We can help avoid this sort of problem by separating
> the two steps of:
> (1) iterating / clearing the mwifiex reordering table
> (2) dispatching received packets to upper layers
> 
> This makes it much harder to make lock recursion mistakes, as these
> two steps no longer need to hold the same locks.
> 
> Testing: I've played with a variety of stress tests, including download
> stress tests on the same APs which caught regressions with commit
> 5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've
> primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO
> a quick spin as well.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Acked-by: Ganapathi Bhat <gbhat@marvell.com>

New warning:

drivers/net/wireless/marvell/mwifiex/wmm.c: In function 'mwifiex_wmm_process_tx':
drivers/net/wireless/marvell/mwifiex/wmm.c:1438:4: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
    mwifiex_11n_aggregate_pkt(priv, ptr, ptr_index, flags);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/marvell/mwifiex/wmm.c:1406:16: note: 'flags' was declared here
  unsigned long flags;
                ^~~~~

2 patches set to Changes Requested.

10976083 [1/2] mwifiex: dispatch/rotate from reorder table atomically
10976087 [2/2] mwifiex: don't disable hardirqs; just softirqs

-- 
https://patchwork.kernel.org/patch/10976083/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


  parent reply	other threads:[~2019-06-25  4:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-04 20:53 [PATCH 0/2] mwifiex: spinlock usage improvements Brian Norris
2019-06-04 20:53 ` [PATCH 1/2] mwifiex: dispatch/rotate from reorder table atomically Brian Norris
2019-06-05  9:15   ` [EXT] " Ganapathi Bhat
2019-06-25  4:45   ` Kalle Valo [this message]
     [not found]   ` <20190625044525.846A8607DE@smtp.codeaurora.org>
2019-06-25 17:26     ` Brian Norris
2019-06-04 20:53 ` [PATCH 2/2] mwifiex: don't disable hardirqs; just softirqs Brian Norris

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=20190625044525.6A45F60A00@smtp.codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=amitkarwar@gmail.com \
    --cc=briannorris@chromium.org \
    --cc=dianders@chromium.org \
    --cc=gbhat@marvell.com \
    --cc=huxinming820@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nishants@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.