Re: compat-wireless: backporting kfree_rcu()?

[Hauke Mehrtens <hauke@hauke-m.de>]

Hi Johannes,

now your patch using kfree_rcu went into linux-next. ;-)

On 10/18/2011 10:18 AM, Johannes Berg wrote:
> So I was looking at backporting kfree_rcu(), and came up with this:
> 
> #define kfree_rcu(data, rcuhead)                do {                    \
>                 void __kfree_rcu_fn(struct rcu_head *rcu_head)  \
>                 {                                                       \
>                         void *___ptr;                                   \
>                         ___ptr = container_of(rcu_head, typeof(*(data)), rcuhead);\
>                         kfree(___ptr);                                  \
>                 }                                                       \
>                 call_rcu(&(data)->rcuhead, __kfree_rcu_fn);             \
>         } while (0)
> 
> 
> This works, thanks to gcc supporting nested functions, but has one major
> issue: any module using call_rcu() must have an rcu_barrier() in its
> module_exit() because __kfree_rcu_fn() might be called after the module
> is unloaded. For kfree_rcu() this isn't needed since the function called
> lives in the base kernel.

This looks nice to me.

> I played around with injecting a call to rcu_barrier() into module exit
> by modifying module_exit() but I couldn't make the CPP do that. Anyone
> else have any ideas?

I played around with module_exit and modified the define into the
following. Now rcu_barrier() gets called on every module_exit. As
modules are not unloaded so often it should not hurd that this is also
done when unloading a module not using kfree_rcu().

#undef module_exit
#define module_exit(exitfn)					\
	void __exit __exit_rcu_barrier(void)			\
		{						\
			exitfn();				\
			rcu_barrier();				\
		}						\
	static inline exitcall_t __exittest(void)		\
	{ return exitfn; }					\
	void cleanup_module(void) __attribute__((alias("__exit_rcu_barrier")));

> 
> Another idea I had was to insert the __kfree_rcu_fn() code into the
> compat module instead, but I can't see how to do that short of using
> some source post-processing scripts.

Johannes are you fine with this?

Hauke