[lkml]   [2012]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Oops with DCACHE_WORD_ACCESS and ocfs2, autofs4
    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
    * 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...

     \ /
      Last update: 2012-05-03 19:41    [W:0.022 / U:2.280 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site