Re: Oops with DCACHE_WORD_ACCESS and ocfs2, autofs4

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, May 03, 2012 at 09:15:41AM -0700, Linus Torvalds wrote:
> I don't know the Xen paravirtualization code, but it looks like it is
> punching holes in the kernel memory map, so you get the same issue you
> get with DEBUG_PAGEALLOC.
> 
> Actually, looking at things, I think there's another case that can do
> it: the AMD gart_64 code also does set_memory_np(), which can cause
> problems.
> 
> So I guess I need to do the exception handling that I was hoping I
> wouldn't have to. Give me a jiffy.

BTW, I've looked through the ->readlink()/->follow_link() instances and
there's an interesting picture:
	* "slow" ocfs2 symlinks could bloody well use generic_readlink();
page_readlink() doesn't buy us anything when we have page_follow_link_light()
as ->follow_link().
	* "fast" ocfs2 symlinks would probably be better off if they just
added ->readlink() of their own and used the same inode_operations as
the rest of them.  And to hell with those dances with kmalloc and special
->readlink().
	* ecryptfs is *definitely* better off by switching to generic_readlink()
and having ecryptfs_follow_link() call ecryptfs_readlink_lower() directly;
we get rid of one of the rounds of kmalloc/memcpy/kfree on that, not to mention
that memcpy being killed is actually copy_to_user() wrapped into set_fs().

I've done (completely untested) patches for those - see vfs.git#symlinks;
if ocfs2 folks can live with that, I'll drop those into #for-next.

BTW, after that we have generic_readlink() for _everything_ with normal symlink
semantics.  Places that are different:
	* /proc/<pid>/{*,fd/*} - magical symlinks, ->follow_link() actually
does a direct jump.
	* /proc/self - different target for every process; we _could_ have
switched it to generic_readlink(), but I'm actually tempted to make it
a "direct jump" kind of symlink instead - its ->follow_link() would be
nicer (and faster) if we did that.
	* hppfs symlinks - those are bounced to procfs, so they inherit
the weirdness
	* afs automount points.  Those are not symlinks at all; we are
probably tied by avoiding userland breakage here, but readlink(2) on those
is badly abusing the syscall.  It's basically "which syscall could we use
to tell what'll get mounted when we step on automount point? aha, readlink()
returns a string, let's use it".
	* bad_inode - actually, we could use generic_readlink() there as well,
it'll fail with the right error ;-)  Again, this one is not quite a garden
variety symlink.
And that's it...