Re: reallocarr(3)

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

christos%zoulas.com@localhost (Christos Zoulas) wrote:
> On Feb 7,  5:54pm, jym%NetBSD.org@localhost (Jean-Yves Migeon) wrote:
> -- Subject: Re: reallocarr(3)
> 
> | Le 06/02/2015 01:50, Kamil Rytarowski a écrit :
> | > Is it fine to have this function for the kernel too?
> | 
> | TBH I think that the kernel should rather rely on generic integer 
> | overflow/underflow checks for its allocation APIs, a bit like the size 
> | overflow plugin you can find in grsec.
> | 
> | pool_cache(9) are generally sufficient enough to handle arrays of
> | object with a fixed size (behind the curtain), adding yet-another
> | allocator would not address the various kmem_alloc/malloc() call sites
> | that already exist in kernel.
> | 
> | Of course this opinion is just mine :)
> 
> The idiom number-of-elements * size is too common, and instead of
> protecting it by opencoding overflow everywhere, it is simpler to provide
> an allocator that does this internally...

We really do not need another interface in the kernel.  If you allocate
kernel memory given the user input, it should be sanity-checked anyway,
i.e. not only for the overflow, unless you think that letting the user
to arbitrarily allocate tons of KVA is a good idea.

Nevermind that this reallocarr{ay,} is a pretty poor interface anyway..

-- 
Mindaugas