[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <80e17b57-6d76-d72a-f8c9-fc0e20a994e5@intel.com>
Date: Mon, 28 Nov 2022 14:07:47 -0800
From: Tony Nguyen <anthony.l.nguyen@...el.com>
To: Akihiko Odaki <akihiko.odaki@...nix.com>,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>
CC: <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<intel-wired-lan@...ts.osuosl.org>,
Paul Menzel <pmenzel@...gen.mpg.de>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Yan Vugenfirer <yan@...nix.com>,
Yuri Benditovich <yuri.benditovich@...nix.com>
Subject: Re: [PATCH v2] igbvf: Regard vf reset nack as success
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
Powered by blists - more mailing lists