On 03/25/2014 05:12 PM, Jan Kara wrote:
On Tue 25-03-14 13:51:11, Sasha Levin wrote:
On 03/25/2014 01:33 PM, Jan Kara wrote:
On Mon 24-03-14 20:44:14, Sasha Levin wrote:
On 03/24/2014 05:48 PM, Jan Kara wrote:
[ 339.948946] ** 4194304 ffff8805ac03ba38 [eventpoll] ffff8806ec051fe0
[eventpoll] ffffffff84666040 ffff88056c73e7b0 (null)
OK, great. So finally we have something useful. We know we have problems
with [eventpoll] dentry. That is actually a special filesystem not mounted
anywhere - likely you get to that dentry through/proc/<pid>/fd/. Now
eventpoll is interesting because it uses single anon inode for all
eventpoll instances. And that inode should stay in place as long as
eventpoll filesystem exists. So it's not clear how come that inode is
freed. The basic check of handling of inode use count didn't find anything
suspicious. But I can check in more detail and if I fail, we now have a
pretty narrow area where to look...
Seems like it's not specific to eventpoll, I saw the same error message with
"eventfd" and "perf_event".
Yup, all these use anon_inode_getfile() so it all points to the fact that
for some reason we freed anon_inode_inode. But I don't see where the
problem is. Can you maybe make 'anon_inode_inode' external to
fs/anon_inodes.c and dump stack for all iput() calls to anon_inode_inode?
There must be some suckers which don't belong there...
Okay, this is straightforward. It happened right after boot so we're lucky.
I'm also looking into that, but odds you'll spot the issue faster than me.
Can you try whether the following patch fixes the issue for you?
Looks like it fixes it, thanks!
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
