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

[Sam James]

Adhemerval Zanella Netto via Libc-stable <libc-stable@sourceware.org> writes:

> 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.

Yes, as Florian said, it should be monotonic.

(I don't know if we have that documented, though, and maybe this
discussion shows it needs improvement.)