LinuxKPI: switch mallocarray to an lpi implementation using __kmalloc()

[bz]

Summary

With mallocarray() we cannot guarantee that any size larger than
PAGE_SIZE will be contiguous. Switch to use the internal __kmalloc()
implementation which now does provide that guarantee.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

[emaste]

OK

[bz]

Also change the (internal) mallocarray() calls in linux_compat.c to lkpi_mallocarray()
given we are using the LinuxKPI malloc type (M_KMALLOC) there already; better for
consistency.

[bz]

@jhb any comments?

[emaste]

Probably fine to go in

[manu]

I'm not a fan of this, mallocarray is a OpenBSD thing, not a Linux thing, I don't see why we should have an lkpi implementation.

[bz]

It's a helper function; because we do use mallocarray internally and it doesn't go by Linux guarantees on memory being physically contiguous in some cases. I can replace all the mallocarray calls directly with __kmalloc() but that just makes it harder to maintain in many places rather one. We can name this whatever we want it to be if you do not like the name...

[jhb]

This seems certainly fine. This is the semantics required for kcalloc and kmalloc_array

sys/compat/linuxkpi/common/include/linux/slab.h

118

This isn't enforcing contigmalloc for size > PAGE_SIZE?

133

Similarly, this also needs to enforce contigmalloc.

I would be tempted to implement the *calloc functions by setting the ZERO flag and then calling the malloc_array function, e.g.:

kcalloc_node()
{
   flags |= __GFP_ZERO;
   return kmalloc_array_node(...)
}

Same can be true for kcalloc() calling kmalloc_array(). Then, you could just have the ABI symbols be lkpi_kmalloc_array and lkpi_kmalloc_array_node as you do today for kmalloc. This also suggests btw that you need to add a shim for kmalloc_node that uses contigmalloc for larger sizes.

sys/compat/linuxkpi/common/src/linux_compat.c

2713 ↗

(On Diff #143296)

Maybe use just use the kmalloc_array here instead and elsewhere in this file, then you aren't exposing the internal symbol more widely?