Re: [PATCH V2 1/5] xfsprogs: introduce liburcu support

[Eric Sandeen <sandeen@sandeen.net>]

On 9/24/21 9:09 AM, Chandan Babu R wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> The upcoming buffer cache rework/kerenl sync-up requires atomic
> variables. I could use C++11 atomics build into GCC, but they are a
> pain to work with and shoe-horn into the kernel atomic variable API.
> 
> Much easier is to introduce a dependency on liburcu - the userspace
> RCU library. This provides atomic variables that very closely match
> the kernel atomic variable API, and it provides a very similar
> memory model and memory barrier support to the kernel. And we get
> RCU support that has an identical interface to the kernel and works
> the same way.
> 
> Hence kernel code written with RCU algorithms and atomic variables
> will just slot straight into the userspace xfsprogs code without us
> having to think about whether the lockless algorithms will work in
> userspace or not. This reduces glue and hoop jumping, and gets us
> a step closer to having the entire userspace libxfs code MT safe.
> 
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> [chandan.babu@oracle.com: Add m4 macros to detect availability of liburcu]

Thanks for fixing that up. I had tried to use rcu_init like Dave originally
had, and I like that better in general, but I had trouble with it - I guess
maybe it gets redefined based on memory model magic and the actual symbol
"rcu_init" maybe isn't available? I didn't dig very much.

Also, dumb question from me - how do we know where we need the
rcu_[un]register_thread() calls? Will it be obvious if we miss it
in the future?  "each thread must invoke this function before its
first call to rcu_read_lock() or call_rcu()."

Thanks,
-Eric