Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 3 May 2012 09:15:41 -0700 | Subject | Re: Oops with DCACHE_WORD_ACCESS and ocfs2, autofs4 |
| |
On Wed, May 2, 2012 at 11:47 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: > > What I'd really like to know is whether we can hit the same kind of "steps > off the end of page" crap on pagecache based symlinks with very long bodies. > The upper limit is 4K, which allows that sucker to reach the end of page > on most of the architectures. And that can be done on just about any fs > supporting symlinks at all - create a symlink with the long body (up to the > limit), something like (("./"x2047)."a").
Sure. And I've even tested that. You don't need a symlink, you can have just a regular system call that passes a filename that is 4095 bytes long, and ends in a short component. We *will* access the next page.
And that was always understood to be the case for the DCACHE_WORD_ACCESS patches. It's just that accessing the next page should be entirely harmless on any actual real x86 implementation.
Well, except for the DEBUG_PAGEALLOC case, which is why it's disabled for that case.
And apparently except for some Xen PV case, where we have similar issues, and which seems to be the reason Jana sees the problems.
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.
Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |