[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ada9d2bb-d179-4cda-8c5c-bc7a39473e05@kernel.org>
Date: Thu, 18 Apr 2024 13:20:37 -0700
From: David Ahern <dsahern@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>
Cc: Paolo Abeni <pabeni@...hat.com>, "David S . Miller"
<davem@...emloft.net>, netdev@...r.kernel.org,
Neal Cardwell <ncardwell@...gle.com>, Dragos Tatulea <dtatulea@...dia.com>,
eric.dumazet@...il.com, Maciej Żenczykowski
<maze@...gle.com>, Willem de Bruijn <willemb@...gle.com>,
Shachar Kagan <skagan@...dia.com>
Subject: Re: [PATCH net-next 1/2] tcp: conditionally call ip_icmp_error() from
tcp_v4_err()
On 4/18/24 12:09 PM, Jakub Kicinski wrote:
> On Thu, 18 Apr 2024 19:47:51 +0200 Eric Dumazet wrote:
>>> You have a kernel patch that makes a test fail, and your solution is
>>> changing userspace? The tests are examples of userspace applications and
>>> how they can use APIs, so if the patch breaks a test it is by definition
>>> breaking userspace which is not allowed.
>
> Tests are often overly sensitive to kernel behavior, while this is
That test script is a fairly comprehensive sweep of uAPIs and kernel
behavior. Its sole job is to detect user visible changes and breakage
from patches. It has done its job here. Do not shoot or criticize the
messenger because you do not like the message.
> obviously a red flag it's not an automatic nack. The more tests we
> have the more often we'll catch tiny changes. A lot of tests started
> flaking with 6.9 because of the optimizations in the timer subsystem.
> You know where I'm going with this..
>
>> I think the userspace program relied on a bug added in linux in 2020
>>
>> Jakub, I will stop trying to push the patches, this is a lost battle.
>
> If you have the patches ready - please post them.
> I'm happy to take the blame if they actually regress something in
> the wild :(
And because of this test suite you are making a conscious decision to
merge a patch that is making a user visible change. That is part of the
tough decisions a maintainer has to make; I have no problem with that.
Powered by blists - more mailing lists