[lkml]   [2007]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland
    In message <Pine.LNX.4.64.0710142049000.13119@sbz-30.cs.Helsinki.FI>, Pekka J Enberg writes:
    > Hi Erez,
    > On Sun, 14 Oct 2007, Erez Zadok wrote:
    > > In unionfs_writepage() I tried to emulate as best possible what the lower
    > > f/s will have returned to the VFS. Since tmpfs's ->writepage can return
    > > AOP_WRITEPAGE_ACTIVATE and re-mark its page as dirty, I did the same in
    > > unionfs: mark again my page as dirty, and return AOP_WRITEPAGE_ACTIVATE.
    > >
    > > Should I be doing something different when unionfs stacks on top of tmpfs?
    > > (BTW, this is probably also relevant to ecryptfs.)
    > Look at mm/filemap.c:__filemap_fdatawrite_range(). You shouldn't be
    > calling unionfs_writepage() _at all_ if the lower mapping has
    > BDI_CAP_NO_WRITEBACK capability set. Perhaps something like the totally
    > untested patch below?
    > Pekka

    Pekka, with a small change to your patch (to handle time-based cache
    coherency), your patch worked well and passed all my tests. Thanks.

    So now I wonder if we still need the patch to prevent AOP_WRITEPAGE_ACTIVATE
    from being returned to userland. I guess we still need it, b/c even with
    your patch, generic_writepages() can return AOP_WRITEPAGE_ACTIVATE back to
    the VFS and we need to ensure that doesn't "leak" outside the kernel.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-10-15 00:35    [W:0.025 / U:29.992 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site