| Message ID | 20150414081254.GD14691@type.youpi.perso.aquilenet.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Apr 14, 2015 at 10:12:54AM +0200, Samuel Thibault wrote: > So it seems that shrink_dentry_list was trying to kill an inode which > already has I_CLEAR. I'll be trying the attached patch in the next > days. That patch is just papering over the problem. What you have is a dentry with ->d_inode pointing to something with I_CLEAR set. So either * dentry has already been through __dentry_kill() * or you have live dentry with ->d_inode somehow not contributing to refcount of ->d_inode * or you have an inode with positive refcount and I_CLEAR set. The first variant can happen, but in that case it should have had DCACHE_DENTRY_KILLED set by said __dentry_kill() and skipped. The other two are clear inode refcounting bugs. Do you have a reproducer for that? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Al Viro, le Tue 14 Apr 2015 13:44:29 +0100, a écrit : > On Tue, Apr 14, 2015 at 10:12:54AM +0200, Samuel Thibault wrote: > > So it seems that shrink_dentry_list was trying to kill an inode which > > already has I_CLEAR. I'll be trying the attached patch in the next > > days. > > That patch is just papering over the problem. I never said it was a proper fix :) > The first variant can happen, but in that case it should have had > DCACHE_DENTRY_KILLED set by said __dentry_kill() and skipped. The other > two are clear inode refcounting bugs. > > Do you have a reproducer for that? It just happened in the middle of the night. Samuel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Samuel Thibault, le Tue 14 Apr 2015 16:44:02 +0200, a écrit : > Al Viro, le Tue 14 Apr 2015 13:44:29 +0100, a écrit : > > The first variant can happen, but in that case it should have had > > DCACHE_DENTRY_KILLED set by said __dentry_kill() and skipped. The other > > two are clear inode refcounting bugs. > > > > Do you have a reproducer for that? > > It just happened in the middle of the night. I haven't seen it happening again since then. Samuel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/fs/dcache.c +++ b/fs/dcache.c @@ -949,6 +949,14 @@ static void shrink_dentry_list(struct li spin_unlock(&parent->d_lock); continue; } + if (inode && (inode->i_state & I_CLEAR)) { + spin_unlock(&inode->i_lock); + d_shrink_add(dentry, list); + spin_unlock(&dentry->d_lock); + if (parent) + spin_unlock(&parent->d_lock); + continue; + } __dentry_kill(dentry);