netdev - Re: [PATCH v2 bpf-next] bpf: add optional memory accounting for maps

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: <20190131120407.3ebaee11@cakuba.hsd1.ca.comcast.net>
Date:   Thu, 31 Jan 2019 12:04:07 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Martynas Pumputis <m@...bda.lt>
Cc:     netdev@...r.kernel.org, ys114321@...il.com, ast@...nel.org,
        daniel@...earbox.net, Yonghong Song <yhs@...com>
Subject: Re: [PATCH v2 bpf-next] bpf: add optional memory accounting for
 maps

On Thu, 31 Jan 2019 10:38:01 +0100, Martynas Pumputis wrote:
> Previously, memory allocated for a map was not accounted. Therefore,
> this memory could not be taken into consideration by the cgroups
> memory controller.
> 
> This patch introduces the "BPF_F_ACCOUNT_MEM" flag which enables
> the memory accounting for a map, and it can be set during
> the map creation ("BPF_MAP_CREATE") in "map_flags".

What should happen for no-prealloc maps?  Would it make some sense to
charge the max map size to the user and not each allocation?  Or
perhaps remember the owner to be able to charge the data path
allocations which don't happen in process context as well?