svn commit: r327676 - head/sys/compat/linuxkpi/common/include/linux

[Rodney W. Grimes]

> On 7 Jan 2018, at 19:02, Rodney W. Grimes wrote:
> >> Author: kp
> >> Date: Sun Jan  7 13:39:12 2018
> >> New Revision: 327676
> >> URL: https://svnweb.freebsd.org/changeset/base/327676
> >>
> >> Log:
> >>   linuxkpi: Implement kcalloc() based on mallocarray()
> >>
> >>   This means we now get integer overflow protection, which Linux code
> >>   might expect as it is also provided by kcalloc() in Linux.
> >>
> >> Modified:
> >>   head/sys/compat/linuxkpi/common/include/linux/slab.h
> >>
> >> Modified: head/sys/compat/linuxkpi/common/include/linux/slab.h
> >> ==============================================================================
> >> --- head/sys/compat/linuxkpi/common/include/linux/slab.h	Sun Jan  7 
> >> 13:35:15 2018	(r327675)
> >> +++ head/sys/compat/linuxkpi/common/include/linux/slab.h	Sun Jan  7 
> >> 13:39:12 2018	(r327676)
> >> @@ -46,7 +46,6 @@ MALLOC_DECLARE(M_KMALLOC);
> >>  #define	kzalloc(size, flags)		kmalloc(size, (flags) | __GFP_ZERO)
> >>  #define	kzalloc_node(size, flags, node)	kmalloc(size, (flags) | 
> >> __GFP_ZERO)
> >>  #define	kfree_const(ptr)		kfree(ptr)
> >> -#define	kcalloc(n, size, flags)	        kmalloc((n) * (size), 
> >> (flags) | __GFP_ZERO)
> >
> > Would not:
> > #define	kcalloc(n, size, flags)	        mallocarray(mallocarray((n), 
> > (size), M_KMALLOC, linux_check_m_flags((flags | __GFP_ZERO))
> > work just fine, saving a call and stack use of about framesize + 32 
> > bytes?
> >
> >
> It would also work, but it?d have to be split up into multiple lines 
> then.

But it would retain the direct macro form, your change changes it
from a #define which is evaluated at pre proc time to a function
call that is evaluated at compile time.  The resulting code from
a -O0 well be different because of this.

> I thought it?d be more readable as a function.

If that is the only reason I would rather see it retain the
same form as all the other allocs.

> It?s an inline function, so it won?t actually use stack space in 
> practice.

That depends on compiler and optimization levels.  

> Also, it used to call kmalloc(), which is also an inline function, so at 
> worst we?ve traded one function for another.

I am not sure, well the inlining of all compilers unwrap 2 levels?


-- 
Rod Grimes                                                 rgrimes at freebsd.org