linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Tejun Heo <tj@kernel.org>
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>,
	Benjamin Beichler <Benjamin.Beichler@uni-rostock.de>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM
Date: Fri, 26 Jan 2018 09:08:02 +0100	[thread overview]
Message-ID: <1516954082.2189.14.camel@sipsolutions.net> (raw)
In-Reply-To: <20180125222650.GJ17457@devbig577.frc2.facebook.com> (sfid-20180125_232655_023577_9D86A131)

On Thu, 2018-01-25 at 14:26 -0800, Tejun Heo wrote:

> Yeah, that came up a couple years ago.  IIRC, there wasn't a definite
> answer but the sentiment seemed that things like nfs over wireless
> should probably considered.  No idea how serious that concern is.

Not that you mention it ... Honestly though, wifi connections break all
the time, so not sure you'd really want that. But anyway, that's what
we have.

> So, anything which can sit in memory reclaim path needs to have that
> flag set and having that flag set automatically means that it can't
> depend on anything which isn't protected the same way as that'd break
> that protection.

Right. I actually misinterpreted this though - the warning comes from:

workqueue: WQ_MEM_RECLAIM hwsim_wq:destroy_radio is  
flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog

and it's flushing something in flush_all_backlogs().

Our workqueue here is only at teardown time (when you remove a netdev)
so it's not sitting in any critical path for reclaim anyway.

So I think this is the right patch, I'll queue it up.

Thanks for the reminder on NFS :-)

johannes

  reply	other threads:[~2018-01-26  8:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-24  7:40 [PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM Johannes Berg
2018-01-24  9:39 ` Benjamin Beichler
2018-01-24 10:46   ` Johannes Berg
     [not found]     ` <CAF7Mx6oASGjDrzVq4_t8Wt-DU7Zap1tcpz5vU7bk-Q5qzg4V=g@mail.gmail.com>
     [not found]       ` <CAF7Mx6o_Y0AeGQfhGKMkSxUHtRNyGaHh3g-TyvusJmsYyckFZg@mail.gmail.com>
     [not found]         ` <CAF7Mx6rg2XOOG0mZxnKiM_1ToB36Yc2A=sKQfN7drLsr3+4crw@mail.gmail.com>
2018-01-25 20:20           ` Arend van Spriel
2018-01-25 21:01             ` Johannes Berg
2018-01-25 22:26               ` Tejun Heo
2018-01-26  8:08                 ` Johannes Berg [this message]
2018-01-26 15:05                   ` Tejun Heo
2018-01-26 15:53                     ` Benjamin Beichler

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=1516954082.2189.14.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=Benjamin.Beichler@uni-rostock.de \
    --cc=arend.vanspriel@broadcom.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=tj@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;
as well as URLs for NNTP newsgroup(s).