Re: [PATCH v2] igbvf: Regard vf reset nack as success

[Tony Nguyen <anthony.l.nguyen@intel.com>]

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