lkml.org 
[lkml]   [2007]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: unionfs: several more problems
    On Mon, 26 Nov 2007, Erez Zadok wrote:
    >
    > I just posted a series of patches to unionfs (already in unionfs.git on
    > korg), which fix every problem LTP found, as well as other problems
    > mentioned in your email. With this series of patches, the same set of tests
    > which pass on ext3 also pass with unionfs mounted over ext3.

    Good, I'll give them a try, but not tonight - my own bugs to work on!

    >
    > I'd like to call your attention to one small unionfs_writepage fix. One of
    > the ltp fs tests (rwtest04) triggered a BUG_ON(PageWriteback(page)) in
    > fs/buffer.c:1706, when we call the lower ->writepage. This was due to
    > multiple writers to the same page. Looking at other kernel code, it seems
    > that the right fix is to use wait_on_page_writeback(lower_page) to serialize
    > concurrent writebacks to the same page, no?

    Ah, yes. I believe that's the right thing to do (and you do have the
    lower_page locked there, which is necessary for that serialization).

    > The small patch below fixed the problem. Let me know what you think.

    I've one issue with it: please move that wait_on_page_writeback before
    the clear_page_dirty_for_io instead of after it, then resubmit your 14/16.

    As it stands, you're still mixing the end of the previous writeback with
    the beginning of the new one (e.g. clear_page_dirty_for_io is clearing
    the PageReclaim flag when it shouldn't be interfering at all); and the
    page might get dirtied during that wait for the previous writeback to
    complete, in which case you'd end up doing an extra unnecessary write
    (because page later found "dirty" even though written back long after
    last modification).

    Whether this is a big deal in any way, I don't know; but if you look
    at other instances, you'll find the wait_on_page_writeback is done
    before the clear_page_dirty_for_io, so you'll surely be on safer
    ground to follow the same ordering.

    (And so far as I can see, everyone who calls write_one_page does so
    with the wait flag 1: that's the clearest example. Hmm, I wonder if
    its initial wait_on_page_writeback is right to be conditional on wait
    at all. Well, until someone calls it with wait 0, it's hard to tell.)

    Hugh

    >
    > Thanks,
    > Erez.
    >
    >
    > diff --git a/fs/unionfs/mmap.c b/fs/unionfs/mmap.c
    > index eef43aa..d0fd4d0 100644
    > --- a/fs/unionfs/mmap.c
    > +++ b/fs/unionfs/mmap.c
    > @@ -73,6 +73,7 @@ static int unionfs_writepage(struct page *page, struct writeback_control *wbc)
    >
    > BUG_ON(!lower_mapping->a_ops->writepage);
    > clear_page_dirty_for_io(lower_page); /* emulate VFS behavior */
    > + wait_on_page_writeback(lower_page); /* prevent multiple writers */
    > err = lower_mapping->a_ops->writepage(lower_page, wbc);
    > if (err < 0)
    > goto out_release;
    -
    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/

    \
     
     \ /
      Last update: 2007-11-26 21:17    [W:0.029 / U:0.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site