Re: 3.1-rc10 oops in nameidata_to_filp

[Al Viro]

On Thu, Nov 24, 2011 at 04:47:10PM -0500, George Spelvin wrote:
> Thanks for the pointer.  I'll write some debug code.
> 
> > Said that, I'm not buying the theory of open assigning to ->f_mapping and
> > screwing it up; all such assignments end up with ->i_mapping of *some*
> > inode, as far as I can see from cursory grep over the tree.  Just in case:
> > do you have CONFIG_FS_POSIX_ACL set?
> 
> No, I always turn that off.  (And TMPFS_POSIX_ACL, too.)

OK, then this 0x18 is very likely to be offset of i_mapping in struct inode
and we have file->f_mapping->host == NULL.  Very odd...  The only struct
address_space on your config besides inode->i_data (which _all_ get non-NULL
->host, pointing straight back to the containing struct inode) is
swapper_space.  And there's no way in hell for it to legitimately end up
in file->f_mapping or inode->i_mapping.

So the possibilities are:
	legitimate ->f_mapping, fucked contents of address_space it points to.
	fucked ->i_mapping, ->f_mapping copied from it.
	legitimate ->i_mapping, open() callback fucking ->f_mapping up.
Try to enable memory poisoning; if it turns those into oopsen on attempt
to access poison + 0x18, we'll know it's some inode getting freed while we
still have references to it...  OTOH, that would make your debugging printks
not fire at all, so it might be better to get the pathname first before
enabling that and seeing how behaviour changes...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/