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] [day] [month] [year] [list]
Message-ID: <562153bceaef87d0e4eedb7fe3a59df8@rmail.be>
Date: Wed, 03 Apr 2024 15:27:00 +0200
From: Maarten <maarten@...il.be>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: patchwork-bot+netdevbpf@...nel.org, opendmb@...il.com,
 netdev@...r.kernel.org, phil@...pberrypi.com,
 bcm-kernel-feedback-list@...adcom.com, kuba@...nel.org, pabeni@...hat.com
Subject: Re: [PATCH v2] net: bcmgenet: Reset RBUF on first open

Florian Fainelli schreef op 2024-04-03 14:58:
> On 4/3/2024 3:10 AM, patchwork-bot+netdevbpf@...nel.org wrote:
>> Hello:
>> 
>> This patch was applied to netdev/net.git (main)
>> by David S. Miller <davem@...emloft.net>:
>> 
>> On Mon,  1 Apr 2024 13:09:33 +0200 you 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.
>>> 
>>> [...]
>> 
>> Here is the summary with links:
>>    - [v2] net: bcmgenet: Reset RBUF on first open
>>      https://git.kernel.org/netdev/net/c/0a6380cb4c6b
>> 
>> You are awesome, thank you!
> 
> Good thing I had mentioned in v1 that we were busy with other things
> but that we would like to have tested that patch. I don't expect it to
> cause regressions, but I would have appreciated that there would be a
> mention or a github issue for the VPU firmware that indicated a fix
> was underway.

Eh, yeah, I had already sent an email to "David S. Miller 
<davem@...emloft.net>" indicating my surprise that this was committed.

I had added in the v2 commit msg a link to the firmware issue I created 
at raspberrypi and also linked to the lore of the v1 patch.

Should I have been clearer in some way or form when I posted the v2, 
(which was to fix the minor formatting issues and also add the firmware 
issues link to it)?

Regards,

Maarten Vanraes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ