Re: [PATCH v2 0/8] assorted replacement of x[mz]alloc_bytes()

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 21/04/2021 15:54, Jan Beulich wrote:
> In the long run I think we want to do away with these type-unsafe
> interfaces, the more that they also request (typically) excess
> alignment. This series of entirely independent patches is
> eliminating the instances where it's relatively clear that they're
> not just "blob" allocations.
>
> v2 only has commit messages extended.
>
> 1: x86/MCE: avoid effectively open-coding xmalloc_array()
> 2: x86/HVM: avoid effectively open-coding xmalloc_array()
> 3: x86/oprofile: avoid effectively open-coding xmalloc_array()
> 4: x86/IRQ: avoid over-alignment in alloc_pirq_struct()
> 5: EFI/runtime: avoid effectively open-coding xmalloc_array()
> 6: kexec: avoid effectively open-coding xzalloc_flex_struct()
> 7: video/lfb: avoid effectively open-coding xzalloc_array()
> 8: Arm/optee: don't open-code xzalloc_flex_struct()

I'm tempted to nack this, but for now will go with a firm -2 to the
whole series.

It is unreasonable, at an API level, for *lloc_bytes(...) to not be
interchangeable *alloc_array(char, ...), and the former is the clearer
way of writing code.

The alignment details are internal properties, dubious at best, and
totally unreasonable for maintainer to know or care about as far as the
API is concerned.  There is also no type safety to be gained by making
the transformation.

If you want to improve the alignment, fix the allocator and the
behind-the-scenes semantics.  Don't make every callsite more complicated
to follow, and definitely don't introduce perf problems from cacheline
sharing in the name of typesafey.

~Andrew