[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d41dfe33-0811-4db5-eda6-89820b3d3ac5@gmail.com>
Date: Wed, 5 Apr 2023 10:34:07 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: edward.cree@....com, linux-net-drivers@....com,
davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
netdev@...r.kernel.org, habetsm.xilinx@...il.com,
sudheer.mogilappagari@...el.com
Subject: Re: [RFC PATCH net-next 2/6] net: ethtool: record custom RSS contexts
in the IDR
On 05/04/2023 00:40, Jakub Kicinski wrote:
> On Tue, 4 Apr 2023 12:49:18 +0100 Edward Cree wrote:
>>> GFP_USER? Do you mean it for accounting? GFP_KERNEL_ACCOUNT?
>>
>> It's an allocation triggerable by userland; I was under the
>> impression that those were supposed to use GFP_USER for some
>> reason; the rss_config alloc further up this function does.
>
> That's what I thought, too, and that it implies memory accounting.
> But then someone from MM told me that that's not the case, and
> that GFP_USER is supposed to be mmap()able. Or maybe the latter
> part I got from the kdoc in gfp_types.h.
>
> I think we should make sure the memory is accounted.
Okay. Presumably this doesn't apply to `rss_config` because it's
short-lived (freed on the way out of the function)?
(In which case I think `rss_config` should just be GFP_KERNEL;
we don't try to map it to userspace, we just copy_{from,to}_user
between it and the ioctl data. But that's unrelated cleanup
which we can worry about later, if at all.)
Powered by blists - more mailing lists