netdev - Re: [PATCH iwl-net v1 2/2] drivers/net/bonding: Added some delay while checking for VFs link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <32200.1684250142@famine>
Date: Tue, 16 May 2023 08:15:42 -0700
From: Jay Vosburgh <jay.vosburgh@...onical.com>
To: Mateusz Palczewski <mateusz.palczewski@...el.com>
cc: andy@...yhouse.net, davem@...emloft.net, edumazet@...gle.com,
    kuba@...nel.org, pabeni@...hat.com, dbanerje@...mai.com,
    netdev@...r.kernel.org,
    Sebastian Basierski <sebastianx.basierski@...el.com>
Subject: Re: [PATCH iwl-net v1 2/2] drivers/net/bonding: Added some delay while checking for VFs link

Mateusz Palczewski <mateusz.palczewski@...el.com> wrote:

>From: Sebastian Basierski <sebastianx.basierski@...el.com>
>
>Right now bonding driver checks if link is ready once.
>VF interface takes a little more time to get ready than PF,
>so driver needs to wait for it to be ready.
>1000ms delay was set, if VF link will not be set within given amount
>of time, for sure problems should be investigated elsewhere.

	Why is the "updelay" mechanism that's already available
insufficient for this purpose?

	Even without updelay, I'd expect the behavior to simply be that
the carrier state flaps once or twice (because the VF is delayed in
asserting carrier up).  This is reflecting reality; I'm unsure why we
would want to hack in an extra delay to cover that up.

	Regardless of whether updelay handles this case or not, adding a
1 second busy wait loop as this patch does is not a reasonable
implementation.  This would cause a 1 second stall in the link state
check for every bond interface that is carrier down.

	-J

>Fixes: b3c898e20b18 ("Revert "bonding: allow carrier and link status to determine link state"")
>Signed-off-by: Sebastian Basierski <sebastianx.basierski@...el.com>
>Signed-off-by: Mateusz Palczewski <mateusz.palczewski@...el.com>
>---
> drivers/net/bonding/bond_main.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 710548dbd0c1..6d49fb25969e 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -736,6 +736,8 @@ const char *bond_slave_link_status(s8 link)
>  * It'd be nice if there was a good way to tell if a driver supports
>  * netif_carrier, but there really isn't.
>  */
>+#define BOND_CARRIER_CHECK_TIMEOUT 1000
>+
> static int bond_check_dev_link(struct bonding *bond,
> 			       struct net_device *slave_dev, int reporting)
> {
>@@ -743,12 +745,22 @@ static int bond_check_dev_link(struct bonding *bond,
> 	int (*ioctl)(struct net_device *, struct ifreq *, int);
> 	struct ifreq ifr;
> 	struct mii_ioctl_data *mii;
>+	int delay;
> 
> 	if (!reporting && !netif_running(slave_dev))
> 		return 0;
> 
>+	for (delay = 0; delay < BOND_CARRIER_CHECK_TIMEOUT; delay++) {
>+		mdelay(1);
>+
>+		if (bond->params.use_carrier &&
>+		    netif_carrier_ok(slave_dev)) {
>+			return BMSR_LSTATUS;
>+		}
>+	}
>+
> 	if (bond->params.use_carrier)
>-		return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0;
>+		return 0;
> 
> 	/* Try to get link status using Ethtool first. */
> 	if (slave_dev->ethtool_ops->get_link)
>-- 
>2.31.1
>
>

---
	-Jay Vosburgh, jay.vosburgh@...onical.com