On Thu, Aug 04, 2016 at 05:34:32PM +0800, zhuyj wrote: > Sure. > Is it better to add > #ifndef CONFIG_PREEMPT_RCU ? > > On Thu, Aug 4, 2016 at 4:28 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > > Please do not top post > > > > On Thu, 2016-08-04 at 16:08 +0800, zhuyj wrote: > >> +void register_checmate_prog_ops(void); > >> maybe it is extern void register_checmate_prog_ops(void);? > >> > >> + preempt_disable(); > >> + rcu_read_lock(); > >> IMHO, it is not necessary to use the above 2 since rcu_read_lock will > >> call preempt_disable. > > > > You might double check if this claim is true if CONFIG_PREEMPT_RCU=y > > > > > > Thanks for your feedback zhuyj, Looking at kernel documentation itself, it looks like this is the preferred mechanism[1]. Their example:
1 preempt_disable(); 2 rcu_read_lock(); 3 do_something(); 4 rcu_read_unlock(); 5 preempt_enable(); But, I think you're right. Do you know if there's a great benefit of doing this? Or does it make sense to implement a new macro, a la rcu_read_lock_and_preent_disable()? [1] https://www.kernel.org/doc/Documentation/RCU/Design/Requirements/Requirements.html#Disabling Preemption Does Not Block Grace Periods
