On Tue, 6 Feb 2018 18:06:33 +0300
Kirill Tkhai <ktk...@virtuozzo.com> wrote:


> There are kfree_rcu() and vfree_rcu() defined below, and they will give
> compilation error if someone tries to implement one more primitive with
> the same name.

Ah, I misread the patch. I was thinking you were simply replacing
kfree_rcu() with kvfree_rcu(), but now see the macros added below it.


> 
> We may add a comment, but I'm not sure it will be good if people will use
> unpaired brackets like:
> 
>       obj = kmalloc(..)
>       kvfree_rcu(obj,..)
> 
> after they read such a commentary that it works for both vmalloc and kmalloc.
> After this unpaired behavior distribute over the kernel, we won't be able
> to implement some debug on top of this defines (I'm not sure it will be really
> need in the future, but anyway).
> 
> Though, we may add a comment forcing use of paired bracket. Something like:
> 
> /**
>   * kvfree_rcu() - kvfree an object after a grace period.
>     This is a primitive for objects allocated via kvmalloc*() family 
> primitives.
>     Do not use it to free kmalloc() and vmalloc() allocated objects, use 
> kfree_rcu()
>     and vfree_rcu() wrappers instead.
> 
> How are you about this?

Never mind, I missed the adding of kfree_rcu() at the bottom, and was
thinking that we were just using kvfree_rcu() for everything.

That's what I get for looking at patches before my first cup of
coffee ;-)

If you want to add a comment, feel free, but taking a second look, I
don't feel it is necessary.

-- Steve

Reply via email to