Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Wed, 8 Jun 2022 13:40:49 +0200
From:   Pavel Machek <pavel@denx.de>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Yuntao Wang <ytcoode@gmail.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 5.10 136/452] bpf: Fix excessive memory allocation in
 stack_map_alloc()
Message-ID: <20220608114049.GC9333@duo.ucw.cz>
References: <20220607164908.521895282@linuxfoundation.org>
 <20220607164912.613808833@linuxfoundation.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="wxDdMuZNg1r63Hyj"
Content-Disposition: inline
In-Reply-To: <20220607164912.613808833@linuxfoundation.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--wxDdMuZNg1r63Hyj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

> The 'n_buckets * (value_size + sizeof(struct stack_map_bucket))' part of =
the
> allocated memory for 'smap' is never used after the memlock accounting was
> removed, thus get rid of it.
>=20
> [ Note, Daniel:
>=20
> Commit b936ca643ade ("bpf: rework memlock-based memory accounting for map=
s")
> moved `cost +=3D n_buckets * (value_size + sizeof(struct stack_map_bucket=
))`
> up and therefore before the bpf_map_area_alloc() allocation, sigh. In a l=
ater
> step commit c85d69135a91 ("bpf: move memory size checks to bpf_map_charge=
_init()"),
> and the overflow checks of `cost >=3D U32_MAX - PAGE_SIZE` moved into
> bpf_map_charge_init(). And then 370868107bf6 ("bpf: Eliminate rlimit-based
> memory accounting for stackmap maps") finally removed the bpf_map_charge_=
init().
> Anyway, the original code did the allocation same way as /after/ this fix=
=2E ]

We don't have 370868107bf6 in 5.10. Can someone verify this is still
right think to do for 5.10?

Best regards,
								Pavel
							=09
> +++ b/kernel/bpf/stackmap.c
> @@ -121,7 +121,6 @@ static struct bpf_map *stack_map_alloc(union bpf_attr=
 *attr)
>  		return ERR_PTR(-E2BIG);
> =20
>  	cost =3D n_buckets * sizeof(struct stack_map_bucket *) + sizeof(*smap);
> -	cost +=3D n_buckets * (value_size + sizeof(struct stack_map_bucket));
>  	err =3D bpf_map_charge_init(&mem, cost);
>  	if (err)
>  		return ERR_PTR(err);

--=20
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

--wxDdMuZNg1r63Hyj
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCYqCKwQAKCRAw5/Bqldv6
8gOoAKCas9XK10HZN7NVkNBIUOQbTy1WBwCgoAlWLuRiNvh4TR+vRWJWLu6ex8Q=
=o2rh
-----END PGP SIGNATURE-----

--wxDdMuZNg1r63Hyj--