[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86045fadea030cb8c925c09942ebc5cb164a0f85.camel@nvidia.com>
Date: Fri, 9 May 2025 07:21:45 +0000
From: Cosmin Ratiu <cratiu@...dia.com>
To: "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "davem@...emloft.net"
<davem@...emloft.net>, "jdamato@...tly.com" <jdamato@...tly.com>, Tariq
Toukan <tariqt@...dia.com>, Dragos Tatulea <dtatulea@...dia.com>,
"shuah@...nel.org" <shuah@...nel.org>, "sdf@...ichev.me" <sdf@...ichev.me>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>, "kuba@...nel.org" <kuba@...nel.org>,
"edumazet@...gle.com" <edumazet@...gle.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "almasrymina@...gle.com" <almasrymina@...gle.com>,
Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [PATCH net v2] tests/ncdevmem: Fix double-free of queue array
On Thu, 2025-05-08 at 11:31 -0700, Joe Damato wrote:
>
> Nit: it looks like in the original we didn't care about malloc
> potentially failing. Do we care about checking for that now with
> this cleanup?
Thank you for the review, Joe.
I looked a bit into adding error messages and I think it wouldn't make
sense just for these allocations, as there are others which do not
check for malloc/calloc error (e.g. all generated ynl libs).
Furthermore, I am under the impression that on the kind of systems
ncdevmem would run, malloc/calloc would almost never fail because of
overcommit.
Finally, even if they did fail, the user program would just segfault
(not very user friendly, but good enough).
Cosmin.
Powered by blists - more mailing lists