xfs
[Top] [All Lists]

Re: [PATCH 4/5] xfs: xfs_inode_free() isn't RCU safe

To: Alex Lyakas <alex@xxxxxxxxxxxxxxxxx>, <xfs@xxxxxxxxxxx>
Subject: Re: [PATCH 4/5] xfs: xfs_inode_free() isn't RCU safe
From: Brent Bice <bbice@xxxxxxx>
Date: Tue, 12 Apr 2016 05:29:15 -0600
Cc: <david@xxxxxxxxxxxxx>, Shyam Kaushik <shyam@xxxxxxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <0A92B65A3BF94F60BB36EA3FA716DF1F@alyakaslap>
References: <0A92B65A3BF94F60BB36EA3FA716DF1F@alyakaslap>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
Could you resend it to be sure? I flagged it for redelivery the day I emailed you so if nobody else has seen it yet then something still didn't work. I was pretty sure I'd seen it get delivered ok to oss, but... (shrug)

Brent

On 04/12/2016 02:56 AM, Alex Lyakas wrote:
Hello Dave,
Looking at the patch, I see that now we call xfs_idestroy_fork() in RCU
callback. This can do the following chain:
xfs_iext_destroy => xfs_iext_irec_remove => xfs_iext_realloc_indirect=>
kmem_realloc => kmem_alloc => kmem_alloc => congestion_wait()
At least according to documentation, the RCU callback cannot block,
since it may be called from softirq context. Is this fine?
Thanks,
Alex.
P.S.: I have submitted a patch called â[PATCH] xfs: optimize destruction
of the indirection arrayâ, which changes xfs_iext_destroy to call only
kmem_free(). But this patch got stuck in the spam filter of the mailing
list, and Brent is working to release it from there.




<Prev in Thread] Current Thread [Next in Thread>