[COMMITTED 2.34 2/2] malloc: Improve aligned_alloc and calloc test coverage.

[Miguel Martín]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, 2024-05-21 at 10:06 -0300, Adhemerval Zanella Netto wrote:
> 
> 
> On 21/05/24 10:00, Miguel Martín via Libc-stable wrote:
> > On Tue, 2024-05-21 at 12:42 +0200, Florian Weimer wrote:
> > > * Miguel Martin via Libc-stable:
> > 
> > > > From: Joe Simmons-Talbott <josimmon@redhat.com>
> > > > 
> > > > Add a DSO (malloc/tst-aligned_alloc-lib.so) that can be used
> > > > during
> > > > testing to interpose malloc with a call that randomly uses
> > > > either
> > > > aligned_alloc, __libc_malloc, or __libc_calloc in the place of
> > > > malloc.
> > > > Use LD_PRELOAD with the DSO to mirror malloc/tst-malloc.c
> > > > testing
> > > > as an
> > > > example in malloc/tst-malloc-random.c.  Add malloc/tst-aligned-
> > > > alloc-random.c
> > > > as another example that does a number of malloc calls with
> > > > randomly
> > > > sized,
> > > > but limited to 0xffff, requests.
> > > > 
> > > > The intention is to be able to utilize existing malloc testing
> > > > to
> > > > ensure
> > > > that similar allocation APIs are also exposed to the same
> > > > rigors.
> > > > 
> > > > Reviewed-by: DJ Delorie <dj@redhat.com>
> > > > (cherry picked from commit
> > > > 3395157ff2b0657d70c36169156f67440205c8bf)
> > 
> > > In general, we don't backport such mere test additions to
> > > upstream
> > > release branches, especially if they do not relate to known
> > > previous
> > > regressions or might cover potential regressions in changes we
> > > backport
> > > later.  One reason is that we like to maintain monoticity in the
> > > sense
> > > that if a commit has been backported to 2.X, we also want it
> > > backported
> > > to 2.X+1 (if it wasn't already committed during 2.X+1
> > > development). 
> > > For
> > > earlier branches such as 2.34, that requires fixing a lot of
> > > other
> > > branches, and the branch count is steadily growing over time. 
> > > This
> > > effort is better spent elsewhere.
> > 
> > > Our downstream procedures do not require that the branch is
> > > backported
> > > to the upstream base branch.
> > 
> > > Thanks,
> > > Florian
> > 
> > 
> > Ok, it make sense.
> > 
> > Then, we only need to backport d141717 to glibc/2.39/master so
> > all the commits are in upstream 2.39 before backporting them
> > downstream
> > to 2.34, right?
> > 
> 
> Also, do you plan to backport it to all other affected releases
> branches?
> Because it does not make much sense to have it only for 2.34, 2.39,
> and
> master.
> 

No, AFAIU I only need to backport it to 2.39, the 2.34 backport will be
done downstream.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEERBNxlsW9fRmqDQAeOZwMQZdKxwAFAmZMofEACgkQOZwMQZdK
xwBArQ/9HvcHHLlU6zavp1kqF0dAiTiaKClecnCWJCGFz5wNEG3lPWxYoMSLnT55
M1VzcPgF55j/mrMtweJTItixhC/Nod6HY1IRoM9KjcR+J/Pgtg0SXDivHqUpUAG/
FKiDBoB6LkcvjwqBo5qsEM6+U+tvsRCRCyEyn+8Hz29Z0PYNzIi3xLHA85TXPWwj
zGnUjaJuoWymI5CYXbLeJ7NbmF41tsokQjcBjVqCnbFeyccB2HOCJW77pudN8TQj
DFWm1g/B2rMu4uhWEIYFc1J3qwLdos/BYrYFBtEK/uYhRGllVKWsAPNeBCHWs39z
cxgfhIlMGxdS5d0WLjGM8fiym8+irX46lqEscSsa3wU4w5v850l/njO1acDC6Nzf
ANqbu6zGg2nLpmTRyc38sOhIWcdCTIK4bb9RiNMyXZPsdAYUMjr0j3rOsfZS6sAO
5N9WE6mkCBwtOdl03hpzeqp4+/fc8gx/fX1BuDHJU4c5RkplPbzZeeZIoseTXba8
hHUas6hGaNMOvIsEmk+mjI/exEMM5w6PjGeyJGRBKV1vb4BbTM9VK1hf2tiZluMH
VNdiVPlWXrQ1MEz0ywcQNCvPDUoq+xrf2U2E1xMyQo7d0Q6oS/o2XVa5HFek01kZ
dBIOAtaRAdwzvv8LJAig4P1RvtQbtNGouw7qeiXhgJ+GxVjOyBA=
=FzBj
-----END PGP SIGNATURE-----