netdev - [PATCH net-next-2.6 06/17] sfc: Fix event based MCDI completion and MC REBOOT/CMDDONE ordering issue

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1291333615.3259.29.camel@bwh-desktop>
Date:	Thu, 02 Dec 2010 23:46:55 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, linux-net-drivers@...arflare.com
Subject: [PATCH net-next-2.6 06/17] sfc: Fix event based MCDI completion
 and MC REBOOT/CMDDONE ordering issue

From: Steve Hodgson <shodgson@...arflare.com>

The mcfw *never* sends CMDDONE when rebooting. Changing this so that it always
sends CMDDONE *before* REBOOT is easy on Siena, but it's not obvious that we
could guarantee to be able to implement this on future hardware.

Given this, I'm less convinced that the protocol should be changed.

To reiterate the failure mode: The driver sees this:

 issue command
 receive REBOOT event

Was that reboot event sent before the command was issued, or in
response to the command? If the former then there will be a subsequent
CMDDONE event, if the latter, then there will be no CMDDONE event.

Options to resolve this are:

 1. REBOOT always completes an outstanding mcdi request, and we set
    the credits count to ignore a subsequent CMDDONE event with
    mismatching seqno.

 2. REBOOT never completes an outstanding mcdi request. If there is
    no CMDDONE event then we rely on the mcdi timeout code to complete
    the outstanding request, incurring a 10s delay.

I'd argue that (2) is tidier, but that incurring a 10s delay is a little
needless. Let's go with (1).

Signed-off-by: Ben Hutchings <bhutchings@...arflare.com>
---
 drivers/net/sfc/mcdi.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/sfc/mcdi.c b/drivers/net/sfc/mcdi.c
index e389ac6..b716e82 100644
--- a/drivers/net/sfc/mcdi.c
+++ b/drivers/net/sfc/mcdi.c
@@ -463,6 +463,7 @@ static void efx_mcdi_ev_death(struct efx_nic *efx, int rc)
 		if (mcdi->mode == MCDI_MODE_EVENTS) {
 			mcdi->resprc = rc;
 			mcdi->resplen = 0;
+			++mcdi->credits;
 		}
 	} else
 		/* Nobody was waiting for an MCDI request, so trigger a reset */
-- 
1.7.3.2



-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html