Re: [PATCH v3 net 1/4] net: bonding: replace dev_trans_start() with the jiffies of the last ARP/NS

[Jay Vosburgh <jay.vosburgh@canonical.com>]

Jakub Kicinski <kuba@kernel.org> wrote:

>On Tue, 02 Aug 2022 11:00:41 -0700 Jay Vosburgh wrote:
>> >> Alternatively, would it be more comfortable to just put this
>> >> patch (1/4) to stable and not backport the others?   
>> >
>> >The above works for me - I thought it was not ok for Jay, but since he
>> >is proposing such sulution, I guess I was wrong.  
>> 
>> 	My original reluctance was that I hadn't had an opportunity to
>> sufficiently review the patch set to think through the potential
>> regressions.  There might be something I haven't thought of, but I think
>> would only manifest in very unusual configurations.
>> 
>> 	I'm ok with applying the series to net-next when it's available,
>> and backporting 1/4 for stable (and 4/4 with it, since that's the
>> documentation update).
>> 
>> Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
>
>One more time, sorry :) If I'm reading things right Vladimir and 
>I would like this to be part of 5.20, Paolo is okay with that,
>Jay would prefer to delay it until 5.21.
>
>Is that right?

	I'm sure there's an Abbott & Costello joke in here somewhere,
but I thought Paolo preferred net-next, and I said I was ok with that.

>My preference for 5.20 is because we do have active users reporting
>problems in stable, and by moving to 5.21 we're delaying things by
>2 weeks. At the same time, 5.20 vs 5.21 doesn't matter as we intend 
>to hit stable users with these change before either of those is out.

	I have no objection to 5.20 if you & Paolo don't object.

	For stable, I believe that 1/4 (and 4/4 for docs) is the minimum
set to resolve the functional issues; is the plan to send all 4 patches
to stable, or just 1 and 4?

	I do think this patch does widen the scope of failures that may
go undetected on the TX side, but most of the time the failure to
receive the ARP on the RX side should cover for that.  Regardless,
that's a concern for later that doesn't need to be hashed out right now.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com