talloc: Other minor issues/queries

[Jeremy Allison]

On Tue, Oct 20, 2020 at 03:10:14PM -0500, Arran Cudbard-Bell via samba-technical wrote:
> Just to keep this separate from the memlimit/pools discussion.
> 
> - I've noticed talloc_realloc_size clears the name/type of the chunk be 
>  allocated.  This isn't mentioned in the documentation.  Is clearing the 
>  name/type of the chunk expected behaviour?

Doesn't it add the name of the program text that called the realloc ?

> - talloc_set_memlimit is marked as deprecated in the
>   current HEAD version of talloc, with a note to use cgroups.
>   cgroups wouldn't offer equivalent functionality for us.  Could I humbly
>   request memlimits not be deprecated? :)

OK, I think memlimits add horrible extra complexity to
save applications some bookkeeping.

I want to *reduce* complexity in talloc.

First fix I want to do after the memlimit changes and tests
have gone in is to remove the code paths around ALWAYS_REALLOC.
We never compile with it in test, and we have tests that
depend on it *not* being set, so it really needs to go.

Second, I'd like to remove the memlimit code. Can you be
*really* clear as to what you are using them for, and
can we find some other way to do this ?

If we can do that, then.....

> - Is there any appetite for functions which return chunks of a specific
>   alignment?  i.e. talloc_aligned, talloc_aligned_array,
>   talloc_aligned_pool.
>   I've had to fudge some horrible variants of the above for local use.
>   We use aligned memory for the following purposes:
>   - Page aligned pools for protecting memory areas with mprotect
>     to prevent runtime modifications.
>   - 8 byte aligned buffers that can have the start and end regions
>     easily poisoned with ASAN.
>   - Cache line aligned ring buffers, with the cache line 
>     alignment done to reduce contention where the producer and
>     consumer are close.

Adding this, more interesting functionality becomes
a lot easier to handle and manage complexity wise.

Just my 2cents :-).