| 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> |
|---|---|---|
| ||
| Previous by Date: | RE: [PATCH 4/5] xfs: xfs_inode_free() isn't RCU safe, Alex Lyakas |
|---|---|
| Next by Date: | RE: [PATCH] xfs: Abort intent log item in xfs_iflush() upon error to get buf, Shyam Kaushik |
| Previous by Thread: | RE: [PATCH 4/5] xfs: xfs_inode_free() isn't RCU safe, Alex Lyakas |
| Next by Thread: | Re: [PATCH 4/5] xfs: xfs_inode_free() isn't RCU safe, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |