netdev - Re: [PATCH] net: bcmgenet: Reset RBUF on first open

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc73b1e2-d99d-4ac2-9ae0-a55a8b271747@broadcom.com>
Date: Mon, 26 Feb 2024 09:34:50 -0800
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Maarten Vanraes <maarten@...il.be>, Doug Berger <opendmb@...il.com>
Cc: netdev@...r.kernel.org,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Phil Elwell <phil@...pberrypi.com>
Subject: Re: [PATCH] net: bcmgenet: Reset RBUF on first open

On 2/23/24 15:53, Maarten Vanraes wrote:
> From: Phil Elwell <phil@...pberrypi.com>
> 
> If the RBUF logic is not reset when the kernel starts then there
> may be some data left over from any network boot loader. If the
> 64-byte packet headers are enabled then this can be fatal.
> 
> Extend bcmgenet_dma_disable to do perform the reset, but not when
> called from bcmgenet_resume in order to preserve a wake packet.
> 
> N.B. This different handling of resume is just based on a hunch -
> why else wouldn't one reset the RBUF as well as the TBUF? If this
> isn't the case then it's easy to change the patch to make the RBUF
> reset unconditional.

The real question is why is not the boot loader putting the GENET core 
into a quasi power-on-reset state, since this is what Linux expects, and 
also it seems the most conservative and prudent approach. Assuming the 
RDMA and Unimac RX are disabled, otherwise we would happily continuing 
to accept packets in DRAM, then the question is why is not the RBUF 
flushed too, or is it flushed, but this is insufficient, if so, have we 
determined why?

> 
> See: https://github.com/raspberrypi/linux/issues/3850
> 
> Signed-off-by: Phil Elwell <phil@...pberrypi.com>
> Signed-off-by: Maarten Vanraes <maarten@...il.be>
> ---
>   drivers/net/ethernet/broadcom/genet/bcmgenet.c | 16 ++++++++++++----
>   1 file changed, 12 insertions(+), 4 deletions(-)
> 
> This patch fixes a problem on RPI 4B where in ~2/3 cases (if you're using
> nfsroot), you fail to boot; or at least the boot takes longer than
> 30 minutes.

This makes me wonder whether this also fixes the issues that Maxime 
reported a long time ago, which I can reproduce too, but have not been 
able to track down the source of:

https://lore.kernel.org/linux-kernel/20210706081651.diwks5meyaighx3e@gilmour/

> 
> Doing a simple ping revealed that when the ping starts working again
> (during the boot process), you have ping timings of ~1000ms, 2000ms or
> even 3000ms; while in normal cases it would be around 0.2ms.

I would prefer that we find a way to better qualify whether a RBUF reset 
is needed or not, but I suppose there is not any other way, since there 
is an "RBUF enabled" bit that we can key off.

Doug, what do you think?
-- 
Florian


Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)