LKML Archive on
help / color / mirror / Atom feed
From: Alexander Duyck <>
To: Pavel Tatashin <>
Cc: Steven Sistare <>,
	Daniel Jordan <>,
	LKML <>,
	Jeff Kirsher <>,
	intel-wired-lan <>,
	Netdev <>,
	Greg KH <>
Subject: Re: [PATCH 1/2] ixgbe: release lock for the duration of ixgbe_suspend_close()
Date: Thu, 3 May 2018 06:46:05 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, May 3, 2018 at 6:30 AM, Pavel Tatashin
<> wrote:
> Hi Alex,

Hi Pavel,

>> I'm not a fan of dropping the mutex while we go through
>> ixgbe_close_suspend. I'm concerned it will result in us having a
>> number of races on shutdown.
> I would agree, but ixgbe_close_suspend() is already called without this
> mutex from ixgbe_close(). This path is executed also during machine
> shutdown but when kexec'ed. So, it is either an existing bug or there are
> no races. But, because ixgbe_close() is called from the userland, and a
> little earlier than ixgbe_shutdown() I think this means there are no races.

All callers of ixgbe_close are supposed to already be holding the RTNL
mutex. That is the whole reason why we need to hold it here as the
shutdown path doesn't have the mutex held otherwise. The mutex was
added here because shutdown was racing with the open/close calls.

>> If anything, I think we would need to find a replacement for the mutex
>> that can operate at the per-netdev level if you are wanting to
>> parallelize this.
> Yes, if lock is necessary, it can be replaced in this place (and added to
> ixgbe_close())  with something scalable.

I wouldn't suggest adding yet another lock for all this. Instead it
might make more sense for us to start looking at breaking up the
locking since most of the networking subsystem uses the rtnl_lock call
it might be time to start looking at doing something like cutting back
on the use of this in cases where all the resources needed are
specific to one device and instead have a per device lock that could
address those kind of cases.

- Alex

  reply	other threads:[~2018-05-03 13:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03  3:59 [PATCH 0/2] multi-threading device shutdown Pavel Tatashin
2018-05-03  3:59 ` [PATCH 1/2] ixgbe: release lock for the duration of ixgbe_suspend_close() Pavel Tatashin
2018-05-03 13:20   ` Alexander Duyck
2018-05-03 13:30     ` Pavel Tatashin
2018-05-03 13:46       ` Alexander Duyck [this message]
2018-05-03 14:01         ` Steven Sistare
2018-05-03 14:23           ` Pavel Tatashin
2018-05-03  3:59 ` [PATCH 2/2] drivers core: multi-threading device shutdown Pavel Tatashin
2018-05-03  5:54   ` Tobin C. Harding
2018-05-03 13:38     ` Pavel Tatashin

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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).