After looking through the code and seeing how some other filesystems
use call_rcu, it seems that call_rcu has to do with consistency and
waiting for stuff to complete before returning an object to the slab cache,
whereas we were just calling kmem_cache_free without worrying about that
kind of stuff...
Is that a "close enough" description of the error that is being
fixed here?
-Mike
On Fri, Feb 24, 2017 at 6:00 PM, Mike Marshall <hub...@omnibond.com> wrote:
> Thanks Al... I was going to try and evaluate that patch next
> week, now all I have to do is test it <g> ...
>
> -Mike
>
> On Fri, Feb 24, 2017 at 3:52 PM, Al Viro <v...@zeniv.linux.org.uk> wrote:
>> That, AFAICS, fixes a real bug. Applied, and it needs Cc:stable as well.
>>
>>
>>> Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
>>> ---
>>> fs/orangefs/super.c | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> --- a/fs/orangefs/super.c
>>> +++ b/fs/orangefs/super.c
>>> @@ -115,6 +115,13 @@ static struct inode *orangefs_alloc_inod
>>> return &orangefs_inode->vfs_inode;
>>> }
>>>
>>> +static void orangefs_i_callback(struct rcu_head *head)
>>> +{
>>> + struct inode *inode = container_of(head, struct inode, i_rcu);
>>> + struct orangefs_inode_s *orangefs_inode = ORANGEFS_I(inode);
>>> + kmem_cache_free(orangefs_inode_cache, orangefs_inode);
>>> +}
>>> +
>>> static void orangefs_destroy_inode(struct inode *inode)
>>> {
>>> struct orangefs_inode_s *orangefs_inode = ORANGEFS_I(inode);
>>> @@ -123,7 +130,7 @@ static void orangefs_destroy_inode(struc
>>> "%s: deallocated %p destroying inode %pU\n",
>>> __func__, orangefs_inode,
>>> get_khandle_from_ino(inode));
>>>
>>> - kmem_cache_free(orangefs_inode_cache, orangefs_inode);
>>> + call_rcu(&inode->i_rcu, orangefs_i_callback);
>>> }
>>>
>>> /*
>>>
>>>
