From: Alan Brady <alan.brady@intel.com>
To: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Alan Brady <alan.brady@intel.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>
Subject: [PATCH v6 06/11 iwl-next] idpf: add async_handler for MAC filter messages
Date: Thu, 22 Feb 2024 11:04:36 -0800 [thread overview]
Message-ID: <20240222190441.2610930-7-alan.brady@intel.com> (raw)
In-Reply-To: <20240222190441.2610930-1-alan.brady@intel.com>
There are situations where the driver needs to add a MAC filter but
we're explicitly not allowed to sleep so we can wait for a virtchnl
message to complete.
This adds an async_handler for asynchronously sent messages for MAC
filters so that we can better handle if there's an error of some kind.
If success we don't need to do anything else, but if we failed to
program the new filter we really should remove it from our list of MAC
filters. If we don't remove bad filters, what I expect to happen is
after a reset of some kind we try to program the MAC filter again and it
fails again. This is clearly wrong and I would expect to be confusing
for the user.
It could also be the failure is for a delete MAC filter message but
those filters get deleted regardless. Not much we can do about a delete
failure.
Tested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Alan Brady <alan.brady@intel.com>
---
.../net/ethernet/intel/idpf/idpf_virtchnl.c | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
index 0f14860efa28..d1107507a98c 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
@@ -3656,6 +3656,75 @@ u32 idpf_get_vport_id(struct idpf_vport *vport)
return le32_to_cpu(vport_msg->vport_id);
}
+/**
+ * idpf_mac_filter_async_handler - Async callback for mac filters
+ * @adapter: private data struct
+ * @xn: transaction for message
+ * @ctlq_msg: received message
+ *
+ * In some scenarios driver can't sleep and wait for a reply (e.g.: stack is
+ * holding rtnl_lock) when adding a new mac filter. It puts us in a difficult
+ * situation to deal with errors returned on the reply. The best we can
+ * ultimately do is remove it from our list of mac filters and report the
+ * error.
+ */
+static int idpf_mac_filter_async_handler(struct idpf_adapter *adapter,
+ struct idpf_vc_xn *xn,
+ const struct idpf_ctlq_msg *ctlq_msg)
+{
+ struct virtchnl2_mac_addr_list *ma_list;
+ struct idpf_vport_config *vport_config;
+ struct virtchnl2_mac_addr *mac_addr;
+ struct idpf_mac_filter *f, *tmp;
+ struct list_head *ma_list_head;
+ struct idpf_vport *vport;
+ u16 num_entries;
+ int i;
+
+ /* if success we're done, we're only here if something bad happened */
+ if (!ctlq_msg->cookie.mbx.chnl_retval)
+ return 0;
+
+ /* make sure at least struct is there */
+ if (xn->reply_sz < sizeof(*ma_list))
+ goto invalid_payload;
+
+ ma_list = ctlq_msg->ctx.indirect.payload->va;
+ mac_addr = ma_list->mac_addr_list;
+ num_entries = le16_to_cpu(ma_list->num_mac_addr);
+ /* we should have received a buffer at least this big */
+ if (xn->reply_sz < struct_size(ma_list, mac_addr_list, num_entries))
+ goto invalid_payload;
+
+ vport = idpf_vid_to_vport(adapter, le32_to_cpu(ma_list->vport_id));
+ if (!vport)
+ goto invalid_payload;
+
+ vport_config = adapter->vport_config[le32_to_cpu(ma_list->vport_id)];
+ ma_list_head = &vport_config->user_config.mac_filter_list;
+
+ /* We can't do much to reconcile bad filters at this point, however we
+ * should at least remove them from our list one way or the other so we
+ * have some idea what good filters we have.
+ */
+ spin_lock_bh(&vport_config->mac_filter_list_lock);
+ list_for_each_entry_safe(f, tmp, ma_list_head, list)
+ for (i = 0; i < num_entries; i++)
+ if (ether_addr_equal(mac_addr[i].addr, f->macaddr))
+ list_del(&f->list);
+ spin_unlock_bh(&vport_config->mac_filter_list_lock);
+ dev_err_ratelimited(&adapter->pdev->dev, "Received error sending MAC filter request (op %d)\n",
+ xn->vc_op);
+
+ return 0;
+
+invalid_payload:
+ dev_err_ratelimited(&adapter->pdev->dev, "Received invalid MAC filter payload (op %d) (len %zd)\n",
+ xn->vc_op, xn->reply_sz);
+
+ return -EINVAL;
+}
+
/**
* idpf_add_del_mac_filters - Add/del mac filters
* @vport: Virtual port data structure
@@ -3683,6 +3752,7 @@ int idpf_add_del_mac_filters(struct idpf_vport *vport,
VIRTCHNL2_OP_DEL_MAC_ADDR;
xn_params.timeout_ms = IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC;
xn_params.async = async;
+ xn_params.async_handler = idpf_mac_filter_async_handler;
vport_config = adapter->vport_config[np->vport_idx];
spin_lock_bh(&vport_config->mac_filter_list_lock);
--
2.43.0
next prev parent reply other threads:[~2024-02-22 19:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 19:04 [PATCH v6 00/11 iwl-next] idpf: refactor virtchnl messages Alan Brady
2024-02-22 19:04 ` [PATCH v6 01/11 iwl-next] idpf: add idpf_virtchnl.h Alan Brady
2024-03-02 4:32 ` Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 02/11 iwl-next] idpf: implement virtchnl transaction manager Alan Brady
2024-03-02 4:33 ` [Intel-wired-lan] " Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 03/11 iwl-next] idpf: refactor vport virtchnl messages Alan Brady
2024-03-02 4:33 ` [Intel-wired-lan] " Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 04/11 iwl-next] idpf: refactor queue related " Alan Brady
2024-03-02 4:34 ` Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 05/11 iwl-next] idpf: refactor remaining " Alan Brady
2024-03-02 4:37 ` Singh, Krishneil K
2024-02-22 19:04 ` Alan Brady [this message]
2024-03-02 4:38 ` [PATCH v6 06/11 iwl-next] idpf: add async_handler for MAC filter messages Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 07/11 iwl-next] idpf: refactor idpf_recv_mb_msg Alan Brady
2024-03-02 4:38 ` Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 08/11 iwl-next] idpf: cleanup virtchnl cruft Alan Brady
2024-03-02 4:39 ` Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 09/11 iwl-next] idpf: prevent deinit uninitialized virtchnl core Alan Brady
2024-03-02 4:39 ` Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 10/11 iwl-next] idpf: fix minor controlq issues Alan Brady
2024-03-02 4:39 ` Singh, Krishneil K
2024-02-22 19:04 ` [PATCH v6 11/11 iwl-next] idpf: remove dealloc vector msg err in idpf_intr_rel Alan Brady
2024-03-02 4:40 ` Singh, Krishneil K
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=20240222190441.2610930-7-alan.brady@intel.com \
--to=alan.brady@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@vger.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).