Received-SPF: pass (google.com: domain of linux-kernel+bounces-169820-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240506120400.712629-1-horatiu.vultur@microchip.com>
In-Reply-To: <20240506120400.712629-1-horatiu.vultur@microchip.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 6 May 2024 14:35:01 +0200
Message-ID: <CANn89i+SJiOLLy8azt8NqckUkTLqTS3Wu=16vfTrqCFYLKxTPw@mail.gmail.com>
Subject: Re: [PATCH net] net: tcp: Update the type of scaling_ratio
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, soheil@google.com, 
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 6, 2024 at 2:04=E2=80=AFPM Horatiu Vultur
<horatiu.vultur@microchip.com> wrote:
>
> It was noticed the following issue that sometimes the scaling_ratio was
> getting a value of 0, meaning that window space was having a value of 0,
> so then the tcp connection was stopping.
> The reason why the scaling_ratio was getting a value of 0 is because
> when it was calculated, it was truncated from a u64 to a u8. So for
> example if it scaling_ratio was supposed to be 256 it was getting a
> value of 0.
> The fix consists in chaning the type of scaling_ratio from u8 to u16.
>
> Fixes: dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale")
> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
> ---

This is a wrong patch. We need to fix the root cause instead.

By definition, skb->len / skb->truesize must be < 1

If not, a driver is lying to us and this is quite bad.

Please take a look at the following patch for a real fix.

4ce62d5b2f7aecd4900e7d6115588ad7f9acccca net: usb: ax88179_178a: stop
lying about skb->truesize