From: Ivan Vecera <ivecera@redhat.com> To: netdev@vger.kernel.org Cc: poros@redhat.com, mschmidt@redhat.com, Jesse Brandeburg <jesse.brandeburg@intel.com>, Tony Nguyen <anthony.l.nguyen@intel.com>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Brett Creeley <brett.creeley@intel.com>, intel-wired-lan@lists.osuosl.org (moderated list:INTEL ETHERNET DRIVERS), linux-kernel@vger.kernel.org (open list) Subject: [PATCH net] ice: Fix incorrect locking in ice_vc_process_vf_msg() Date: Thu, 31 Mar 2022 12:50:04 +0200 [thread overview] Message-ID: <20220331105005.2580771-1-ivecera@redhat.com> (raw) 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 mutex is used to prevent races between VF related NDOs and handlers processing request messages from VF and these handlers are running in ice_service_task() context. Fixes: e6ba5273d4ed ("ice: Fix race conditions between virtchnl handling and VF ndo ops") Signed-off-by: Ivan Vecera <ivecera@redhat.com> --- drivers/net/ethernet/intel/ice/ice_virtchnl.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c index 3f1a63815bac..9bf5bb008128 100644 --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c @@ -3660,15 +3660,7 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event) return; } - /* VF is being configured in another context that triggers a VFR, so no - * need to process this message - */ - if (!mutex_trylock(&vf->cfg_lock)) { - dev_info(dev, "VF %u is being configured in another context that will trigger a VFR, so there is no need to handle this message\n", - vf->vf_id); - ice_put_vf(vf); - return; - } + mutex_lock(&vf->cfg_lock); switch (v_opcode) { case VIRTCHNL_OP_VERSION: -- 2.34.1
WARNING: multiple messages have this Message-ID (diff)
From: Ivan Vecera <ivecera@redhat.com> To: intel-wired-lan@osuosl.org Subject: [Intel-wired-lan] [PATCH net] ice: Fix incorrect locking in ice_vc_process_vf_msg() Date: Thu, 31 Mar 2022 12:50:04 +0200 [thread overview] Message-ID: <20220331105005.2580771-1-ivecera@redhat.com> (raw) 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 mutex is used to prevent races between VF related NDOs and handlers processing request messages from VF and these handlers are running in ice_service_task() context. Fixes: e6ba5273d4ed ("ice: Fix race conditions between virtchnl handling and VF ndo ops") Signed-off-by: Ivan Vecera <ivecera@redhat.com> --- drivers/net/ethernet/intel/ice/ice_virtchnl.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c index 3f1a63815bac..9bf5bb008128 100644 --- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c +++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c @@ -3660,15 +3660,7 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event) return; } - /* VF is being configured in another context that triggers a VFR, so no - * need to process this message - */ - if (!mutex_trylock(&vf->cfg_lock)) { - dev_info(dev, "VF %u is being configured in another context that will trigger a VFR, so there is no need to handle this message\n", - vf->vf_id); - ice_put_vf(vf); - return; - } + mutex_lock(&vf->cfg_lock); switch (v_opcode) { case VIRTCHNL_OP_VERSION: -- 2.34.1
next reply other threads:[~2022-03-31 10:50 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-31 10:50 Ivan Vecera [this message] 2022-03-31 10:50 ` [Intel-wired-lan] [PATCH net] ice: Fix incorrect locking in ice_vc_process_vf_msg() Ivan Vecera 2022-03-31 13:14 ` Maciej Fijalkowski 2022-03-31 13:14 ` Maciej Fijalkowski 2022-03-31 13:17 ` Maciej Fijalkowski 2022-03-31 13:17 ` Maciej Fijalkowski 2022-03-31 16:32 ` Brett Creeley 2022-03-31 16:32 ` Brett Creeley 2022-03-31 19:59 ` Keller, Jacob E 2022-03-31 19:59 ` Keller, Jacob E 2022-04-01 8:47 ` Ivan Vecera 2022-04-01 8:47 ` Ivan Vecera 2022-03-31 15:48 ` Ivan Vecera 2022-03-31 15:48 ` Ivan Vecera 2022-03-31 20:02 ` Keller, Jacob E 2022-03-31 20:02 ` Keller, Jacob E
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=20220331105005.2580771-1-ivecera@redhat.com \ --to=ivecera@redhat.com \ --cc=anthony.l.nguyen@intel.com \ --cc=brett.creeley@intel.com \ --cc=davem@davemloft.net \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=jesse.brandeburg@intel.com \ --cc=kuba@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mschmidt@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=poros@redhat.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.