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

[Tony Nguyen]

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@xxxxxxxxxx/#647a4053-bae0-6c06-3049-274d389c2bdd@xxxxxxxxxx
>
> > 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