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

Miguel Martín mmartinv@redhat.com
Tue May 21 13:00:18 GMT 2024


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

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?
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEERBNxlsW9fRmqDQAeOZwMQZdKxwAFAmZMmuIACgkQOZwMQZdK
xwAafxAAh1XZKHHfy0AlBf0rhg7vvCLy5deORdaCt7h5+eTb0m82az3nKfp/Symb
zxnMHGbfSefopfaTyeubpE5NzKhDjSqaNaONXsF8L2SPYYUrVtGFhLKwgdc5Fp8Z
6S6B9hYsPQzDj1J1aFspMsfbM8czLkwXxpyvWBK3vpZpHfCNroD7SWbecZ+Cbr+V
pl2cnZl0bfKz1G5UCbwX3sm+SDfex54mljZjOxqabqv/9lFsY15GPjhKBnwzzg+C
dLdLZVtd7MxUAs5wOZ7FYa+i0b7zLahjSpXX9YtEJlqC3Pcoc+cN0Hj65P5w/DH8
1Or205qdquAzGpf5J47pBLFB2vOr4hHQuotc36BpXBuv71zXAXqSDGs387zLQ0Z+
GxbWukTVp0r/Y5GMsuPTPFELNVLiM7roUrzlNmyqShOkIg8KVMto9q685NyXnyTl
E3M4M+CfPLms/5lcByvW3OEz00dNklj0BmuxhkOxU+AxNr34GzkBKX/O3/NmdetR
PBjGww1ILsMmNAoyEQM2qU65mf4I4bcEQzLiMHievA4voD3hvjYoo1jX8YNhDzzx
nOx1ULQ0zOIu/9i4wCUskXI+050NlaqQqZmT9fp1N1s0kAcCxLjGsWO2LMXrwGqn
tvbgZsfYu5pnzxLMAd6xEUvBqGdue8w362XYSsOpMlCc5/XkA38=
=ZHmN
-----END PGP SIGNATURE-----



More information about the Libc-stable mailing list