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]
Date:   Thu, 16 Jun 2022 15:09:24 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Yuntao Wang <ytcoode@...il.com>
Cc:     daniel@...earbox.net, linux-kernel@...r.kernel.org, pavel@...x.de,
        sashal@...nel.org, stable@...r.kernel.org, ast@...nel.org,
        andrii@...nel.org, kafai@...com, songliubraving@...com, yhs@...com,
        john.fastabend@...il.com, kpsingh@...nel.org, bpf@...r.kernel.org
Subject: Re: [PATCH] bpf: Fix incorrect memory charge cost calculation in
 stack_map_alloc()

On Tue, Jun 14, 2022 at 10:26:22PM +0800, Yuntao Wang wrote:
> commit b45043192b3e481304062938a6561da2ceea46a6 upstream.
> 
> This is a backport of the original upstream patch for 5.4/5.10.
> 
> The original upstream patch has been applied to 5.4/5.10 branches, which
> simply removed the line:
> 
>   cost += n_buckets * (value_size + sizeof(struct stack_map_bucket));
> 
> This is correct for upstream branch but incorrect for 5.4/5.10 branches,
> as the 5.4/5.10 branches do not have the commit 370868107bf6 ("bpf:
> Eliminate rlimit-based memory accounting for stackmap maps"), so the
> bpf_map_charge_init() function has not been removed.
> 
> Currently the bpf_map_charge_init() function in 5.4/5.10 branches takes a
> wrong memory charge cost, the
> 
>   attr->max_entries * (sizeof(struct stack_map_bucket) + (u64)value_size))
> 
> part is missing, let's fix it.
> 
> Cc: <stable@...r.kernel.org> # 5.4.y
> Cc: <stable@...r.kernel.org> # 5.10.y
> Signed-off-by: Yuntao Wang <ytcoode@...il.com>
> ---
> Note that the original upstream patch is currently applied to
> linux-stable-rc/linux-5.4.y branch, not linux/linux-5.4.y, this patch
> depends on that patch.

Now queued up, thanks.

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ