netdev - Re: [RFC PATCH 0/1] vmxnet3: Adjust maximum Rx ring buffer size

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: <2f127a6d-7fa2-5e99-093f-40ab81ece5b1@atomlin.com>
Date: Tue, 7 Jan 2025 22:55:38 +0000 (GMT)
From: Aaron Tomlin <atomlin@...mlin.com>
To: Jakub Kicinski <kuba@...nel.org>
cc: Florian Fainelli <florian.fainelli@...adcom.com>, 
    Aaron Tomlin <atomlin@...mlin.com>, ronak.doshi@...adcom.com, 
    andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com, 
    pabeni@...hat.com, bcm-kernel-feedback-list@...adcom.com, 
    netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/1] vmxnet3: Adjust maximum Rx ring buffer size

On Tue, 7 Jan 2025, Jakub Kicinski wrote:
> True, although TBH I don't fully understand why this flag exists
> in the first place. Is it just supposed to be catching programming
> errors, or is it due to potential DoS implications of users triggering
> large allocations?

Jakub,

I suspect that introducing __GFP_NOWARN would mask the issue, no?
I think the warning was useful. Otherwise it would be rather difficult to
establish precisely why the Rx Data ring was disable. In this particular
case, if I understand correctly, the intended size of the Rx Data ring was
simply too large due to the size of the maximum supported Rx Data buffer.

-- 
Aaron Tomlin