[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGM2rea3XXJ7OqGeAdexyOUb1_7W_84t5HAb_hp7Rb=TkTM86Q@mail.gmail.com>
Date: Thu, 03 May 2018 13:30:30 +0000
From: Pavel Tatashin <pasha.tatashin@...cle.com>
To: alexander.duyck@...il.com
Cc: Steven Sistare <steven.sistare@...cle.com>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
LKML <linux-kernel@...r.kernel.org>, jeffrey.t.kirsher@...el.com,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
gregkh@...uxfoundation.org
Subject: Re: [PATCH 1/2] ixgbe: release lock for the duration of ixgbe_suspend_close()
Hi Alex,
> 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.
> 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.
Thank you,
Pavel
Powered by blists - more mailing lists