-----Original Message-----
From: Brett Creeley <redacted>
Sent: Thursday, March 31, 2022 9:33 AM
To: Fijalkowski, Maciej <maciej.fijalkowski@intel.com>
Cc: ivecera <ivecera@redhat.com>; netdev@vger.kernel.org; moderated
list:INTEL ETHERNET DRIVERS [off-list ref]; mschmidt
[off-list ref]; open list [off-list ref]; poros
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni
[off-list ref]; David S. Miller [off-list ref]; Keller, Jacob E
[off-list ref]
Subject: Re: [Intel-wired-lan] [PATCH net] ice: Fix incorrect locking in
ice_vc_process_vf_msg()

On Thu, Mar 31, 2022 at 6:17 AM Maciej Fijalkowski
[off-list ref] wrote:

quoted

On Thu, Mar 31, 2022 at 03:14:32PM +0200, Maciej Fijalkowski wrote:

quoted

On Thu, Mar 31, 2022 at 12:50:04PM +0200, Ivan Vecera wrote:

quoted

Usage of mutex_trylock() in ice_vc_process_vf_msg() is incorrect
because message sent from VF is ignored and never processed.

Use mutex_lock() instead to fix the issue. It is safe because this

We need to know what is *the* issue in the first place.
Could you please provide more context what is being fixed to the readers
that don't have an access to bugzilla?

Specifically, what is the case that ignoring a particular message when
mutex is already held is a broken behavior?

Uh oh, let's
CC: Brett Creeley <redacted>

Thanks for responding, Brett! :)
 

My concern here is that we don't want to handle messages
from the context of the "previous" VF configuration if that
makes sense.

Makes sense. Perhaps we need to do some sort of "clear the existing message queue" when we initiate a reset?

It might be best to grab the cfg_lock before doing any
message/VF validating in ice_vc_process_vf_msg() to
make sure all of the checks are done under the cfg_lock.

Yes that seems like it should be done.

CC'ing Jake so he can provide some input as
well.

Thanks,
Jake