* [PATCH v2] igbvf: Regard vf reset nack as success
@ 2022-11-22 15:26 Akihiko Odaki
2022-11-22 16:22 ` Maciej Fijalkowski
0 siblings, 1 reply; 4+ messages in thread
From: Akihiko Odaki @ 2022-11-22 15:26 UTC (permalink / raw)
Cc: linux-kernel, netdev, intel-wired-lan, Maciej Fijalkowski,
Jesse Brandeburg, Tony Nguyen, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Yan Vugenfirer, Yuri Benditovich,
Akihiko Odaki
vf reset nack actually represents the reset operation itself is
performed but no address is assigned. Therefore, e1000_reset_hw_vf
should fill the "perm_addr" with the zero address and return success on
such an occasion. This prevents its callers in netdev.c from saying PF
still resetting, and instead allows them to correctly report that no
address is assigned.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
drivers/net/ethernet/intel/igbvf/vf.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/vf.c b/drivers/net/ethernet/intel/igbvf/vf.c
index b8ba3f94c363..2691ae2a8002 100644
--- a/drivers/net/ethernet/intel/igbvf/vf.c
+++ b/drivers/net/ethernet/intel/igbvf/vf.c
@@ -1,6 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright(c) 2009 - 2018 Intel Corporation. */
+#include <linux/etherdevice.h>
+
#include "vf.h"
static s32 e1000_check_for_link_vf(struct e1000_hw *hw);
@@ -131,11 +133,18 @@ static s32 e1000_reset_hw_vf(struct e1000_hw *hw)
/* set our "perm_addr" based on info provided by PF */
ret_val = mbx->ops.read_posted(hw, msgbuf, 3);
if (!ret_val) {
- if (msgbuf[0] == (E1000_VF_RESET |
- E1000_VT_MSGTYPE_ACK))
+ switch (msgbuf[0]) {
+ case E1000_VF_RESET | E1000_VT_MSGTYPE_ACK:
memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
- else
+ break;
+
+ case E1000_VF_RESET | E1000_VT_MSGTYPE_NACK:
+ eth_zero_addr(hw->mac.perm_addr);
+ break;
+
+ default:
ret_val = -E1000_ERR_MAC_INIT;
+ }
}
}
--
2.38.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] igbvf: Regard vf reset nack as success
2022-11-22 15:26 [PATCH v2] igbvf: Regard vf reset nack as success Akihiko Odaki
@ 2022-11-22 16:22 ` Maciej Fijalkowski
2022-11-23 1:04 ` Akihiko Odaki
0 siblings, 1 reply; 4+ messages in thread
From: Maciej Fijalkowski @ 2022-11-22 16:22 UTC (permalink / raw)
To: Akihiko Odaki
Cc: linux-kernel, netdev, intel-wired-lan, Jesse Brandeburg,
Tony Nguyen, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Yan Vugenfirer, Yuri Benditovich
On Wed, Nov 23, 2022 at 12:26:30AM +0900, Akihiko Odaki wrote:
> vf reset nack actually represents the reset operation itself is
> performed but no address is assigned. Therefore, e1000_reset_hw_vf
> should fill the "perm_addr" with the zero address and return success on
> such an occasion. This prevents its callers in netdev.c from saying PF
> still resetting, and instead allows them to correctly report that no
> address is assigned.
What's the v1->v2 diff?
Probably route to net and add fixes tag?
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> drivers/net/ethernet/intel/igbvf/vf.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igbvf/vf.c b/drivers/net/ethernet/intel/igbvf/vf.c
> index b8ba3f94c363..2691ae2a8002 100644
> --- a/drivers/net/ethernet/intel/igbvf/vf.c
> +++ b/drivers/net/ethernet/intel/igbvf/vf.c
> @@ -1,6 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> /* Copyright(c) 2009 - 2018 Intel Corporation. */
>
> +#include <linux/etherdevice.h>
> +
> #include "vf.h"
>
> static s32 e1000_check_for_link_vf(struct e1000_hw *hw);
> @@ -131,11 +133,18 @@ static s32 e1000_reset_hw_vf(struct e1000_hw *hw)
> /* set our "perm_addr" based on info provided by PF */
> ret_val = mbx->ops.read_posted(hw, msgbuf, 3);
> if (!ret_val) {
> - if (msgbuf[0] == (E1000_VF_RESET |
> - E1000_VT_MSGTYPE_ACK))
> + switch (msgbuf[0]) {
> + case E1000_VF_RESET | E1000_VT_MSGTYPE_ACK:
> memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
> - else
> + break;
> +
> + case E1000_VF_RESET | E1000_VT_MSGTYPE_NACK:
> + eth_zero_addr(hw->mac.perm_addr);
> + break;
> +
> + default:
> ret_val = -E1000_ERR_MAC_INIT;
> + }
> }
> }
>
> --
> 2.38.1
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] igbvf: Regard vf reset nack as success
2022-11-22 16:22 ` Maciej Fijalkowski
@ 2022-11-23 1:04 ` Akihiko Odaki
2022-11-28 22:07 ` Tony Nguyen
0 siblings, 1 reply; 4+ messages in thread
From: Akihiko Odaki @ 2022-11-23 1:04 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: linux-kernel, netdev, intel-wired-lan, Paul Menzel,
Jesse Brandeburg, Tony Nguyen, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Yan Vugenfirer, Yuri Benditovich
Hi,
On 2022/11/23 1:22, Maciej Fijalkowski wrote:
> On Wed, Nov 23, 2022 at 12:26:30AM +0900, Akihiko Odaki wrote:
>> vf reset nack actually represents the reset operation itself is
>> performed but no address is assigned. Therefore, e1000_reset_hw_vf
>> should fill the "perm_addr" with the zero address and return success on
>> such an occasion. This prevents its callers in netdev.c from saying PF
>> still resetting, and instead allows them to correctly report that no
>> address is assigned.
>
> What's the v1->v2 diff?
Sorry, I mistakenly added you to CC (and didn't tell you the context).
The diff is only in the message. For details, please look at:
https://patchew.org/linux/20221122092707.30981-1-akihiko.odaki@daynix.com/#647a4053-bae0-6c06-3049-274d389c2bdd@daynix.com
> Probably route to net and add fixes tag?
It is hard to determine the cause of the bug because it is about
undocumented ABI. Linux introduced E1000_VF_RESET |
E1000_VT_MSGTYPE_NACK response with commit 6ddbc4cf1f4d ("igb: Indicate
failure on vf reset for empty mac address") so one can say it is the
cause of the bug.
However, the PF may be driven by someone else Linux (Windows in
particular), and if such system have already had E1000_VF_RESET |
E1000_VT_MSGTYPE_NACK response defined, it can be said the bug existed
even before Linux changes how the PF responds to E1000_VF_RESET request.
Regards,
Akihiko Odaki
>
>>
>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>> ---
>> drivers/net/ethernet/intel/igbvf/vf.c | 15 ++++++++++++---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igbvf/vf.c b/drivers/net/ethernet/intel/igbvf/vf.c
>> index b8ba3f94c363..2691ae2a8002 100644
>> --- a/drivers/net/ethernet/intel/igbvf/vf.c
>> +++ b/drivers/net/ethernet/intel/igbvf/vf.c
>> @@ -1,6 +1,8 @@
>> // SPDX-License-Identifier: GPL-2.0
>> /* Copyright(c) 2009 - 2018 Intel Corporation. */
>>
>> +#include <linux/etherdevice.h>
>> +
>> #include "vf.h"
>>
>> static s32 e1000_check_for_link_vf(struct e1000_hw *hw);
>> @@ -131,11 +133,18 @@ static s32 e1000_reset_hw_vf(struct e1000_hw *hw)
>> /* set our "perm_addr" based on info provided by PF */
>> ret_val = mbx->ops.read_posted(hw, msgbuf, 3);
>> if (!ret_val) {
>> - if (msgbuf[0] == (E1000_VF_RESET |
>> - E1000_VT_MSGTYPE_ACK))
>> + switch (msgbuf[0]) {
>> + case E1000_VF_RESET | E1000_VT_MSGTYPE_ACK:
>> memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
>> - else
>> + break;
>> +
>> + case E1000_VF_RESET | E1000_VT_MSGTYPE_NACK:
>> + eth_zero_addr(hw->mac.perm_addr);
>> + break;
>> +
>> + default:
>> ret_val = -E1000_ERR_MAC_INIT;
>> + }
>> }
>> }
>>
>> --
>> 2.38.1
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] igbvf: Regard vf reset nack as success
2022-11-23 1:04 ` Akihiko Odaki
@ 2022-11-28 22:07 ` Tony Nguyen
0 siblings, 0 replies; 4+ messages in thread
From: Tony Nguyen @ 2022-11-28 22:07 UTC (permalink / raw)
To: Akihiko Odaki, Maciej Fijalkowski
Cc: linux-kernel, netdev, intel-wired-lan, Paul Menzel,
Jesse Brandeburg, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Yan Vugenfirer, Yuri Benditovich
On 11/22/2022 5:04 PM, Akihiko Odaki wrote:
> Hi,
>
> On 2022/11/23 1:22, Maciej Fijalkowski wrote:
>> On Wed, Nov 23, 2022 at 12:26:30AM +0900, Akihiko Odaki wrote:
>>> vf reset nack actually represents the reset operation itself is
>>> performed but no address is assigned. Therefore, e1000_reset_hw_vf
>>> should fill the "perm_addr" with the zero address and return success on
>>> such an occasion. This prevents its callers in netdev.c from saying PF
>>> still resetting, and instead allows them to correctly report that no
>>> address is assigned.
>>
>> What's the v1->v2 diff?
>
> Sorry, I mistakenly added you to CC (and didn't tell you the context).
> The diff is only in the message. For details, please look at:
> https://patchew.org/linux/20221122092707.30981-1-akihiko.odaki@daynix.com/#647a4053-bae0-6c06-3049-274d389c2bdd@daynix.com
>
>> Probably route to net and add fixes tag?
> It is hard to determine the cause of the bug because it is about
> undocumented ABI. Linux introduced E1000_VF_RESET |
> E1000_VT_MSGTYPE_NACK response with commit 6ddbc4cf1f4d ("igb: Indicate
> failure on vf reset for empty mac address") so one can say it is the
> cause of the bug.
>
> However, the PF may be driven by someone else Linux (Windows in
> particular), and if such system have already had E1000_VF_RESET |
> E1000_VT_MSGTYPE_NACK response defined, it can be said the bug existed
> even before Linux changes how the PF responds to E1000_VF_RESET request.
As best as you can find is ok; the one you point to seems reasonable. We
can only control this OS so we should point to the responsible patch
within the kernel. It's better to go with a best-effort Fixes and get
applied to some stable kernels then go without one and not (and would
require later effort).
Thanks,
Tony
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-11-28 22:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-22 15:26 [PATCH v2] igbvf: Regard vf reset nack as success Akihiko Odaki
2022-11-22 16:22 ` Maciej Fijalkowski
2022-11-23 1:04 ` Akihiko Odaki
2022-11-28 22:07 ` Tony Nguyen
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).