On Tue, Dec 01, 2015 at 12:21:31AM +0100, Nicolai Stange wrote: > Nothing prevents a dentry found by path lookup before a return of > __debugfs_remove() to actually get opened after that return. Now, after > the return of __debugfs_remove(), there are no guarantees whatsoever > regarding the memory the corresponding inode's file_operations object > had been kept in. > > Since __debugfs_remove() is seldomly invoked, usually from module exit > handlers only, the race is hard to trigger and the impact is very low. > > A discussion of the problem outlined above as well as a suggested > solution can be found in the (sub-)thread rooted at > > http://lkml.kernel.org/g/20130401203445.ga20...@zeniv.linux.org.uk > ("Yet another pipe related oops.") > > Basically, Greg KH suggests to introduce an intermediate fops and > Al Viro points out that a pointer to the original ones may be stored in > ->d_fsdata.
Nice work, thanks for doing this. I'll review it in a week or so when I've caught up on my huge pending patch queue... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
