From: Johannes Berg <johannes@sipsolutions.net>
To: Jiri Kosina <jikos@kernel.org>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
Luca Coelho <luciano.coelho@intel.com>,
Intel Linux Wireless <linuxwifi@intel.com>,
Kalle Valo <kvalo@codeaurora.org>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5.1-rc] iwlwifi: make locking in iwl_mvm_tx_mpdu() BH-safe
Date: Mon, 15 Apr 2019 13:37:30 +0200 [thread overview]
Message-ID: <01d55c5cf513554d9cbdee0b14f9360a8df859c8.camel@sipsolutions.net> (raw)
In-Reply-To: <nycvar.YFH.7.76.1904151328270.9803@cbobk.fhfr.pm>
On Mon, 2019-04-15 at 13:33 +0200, Jiri Kosina wrote:
> > Yes, here's the fix:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=f5ae2f932e2f8f4f79796f44832ae8fca26f188a
> >
> > It's on the way upstream.
>
> If there are other reasons why disable BH for the whole function (are
> there?), then this bigger hammer works as well of course.
I thought there are, but seeing the commit log here I'm not sure.
In any case, even if not, the function itself is part of the TX fast
path, but the caller from the workqueue is very uncommon (basically only
happens for a handful of packets on each new RA/TID), so I'd say that'd
be a good reason to use the slightly bigger hammer (it's not that much
different really, if you look at how much code is covered by the lock)
and avoid doing it all the time when we know it to be not needed.
> Tested-by: Jiri Kosina <jkosina@suse.cz>
Too late now to add this to the git tree, but thanks for checking! :-)
johannes
next prev parent reply other threads:[~2019-04-15 11:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-15 11:03 [PATCH v5.1-rc] iwlwifi: make locking in iwl_mvm_tx_mpdu() BH-safe Jiri Kosina
2019-04-15 11:10 ` Johannes Berg
2019-04-15 11:33 ` Jiri Kosina
2019-04-15 11:37 ` Johannes Berg [this message]
2019-04-15 12:06 ` Jiri Kosina
2019-04-15 12:08 ` Johannes Berg
2019-09-11 11:42 ` Jiri Kosina
2019-09-11 12:04 ` Jiri Kosina
2019-09-20 21:34 ` Jiri Kosina
2019-10-01 9:46 ` Johannes Berg
2019-10-01 9:52 ` Johannes Berg
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=01d55c5cf513554d9cbdee0b14f9360a8df859c8.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=davem@davemloft.net \
--cc=emmanuel.grumbach@intel.com \
--cc=jikos@kernel.org \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxwifi@intel.com \
--cc=luciano.coelho@intel.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox