On Thu, Aug 29, 2013 at 3:01 PM, Maxim Patlasov <mpatlasov@xxxxxxxxxxxxx> wrote: > The patch looks fine, but it solves only one side of the problem (exactly > what you formulated above). Another side is opposite: truncating page cache > too late, when the state of inode changed significantly. The beginning may > be as in the scenario above: fuse_dentry_revalidate() discovered that i_size > changed (due to our own fuse_do_setattr()) and is going to call > truncate_pagecache() for some 'new_size' it believes valid right now. But by > the time that particular truncate_pagecache() is called, a lot of things may > happen: > > 1) fuse_do_setattr() called truncate_pagecache() according to your patch > 2) the file was extended either by write(2) or ftruncate(2) or fallocate(2). > 3) mmap-ed write make a page in the extended region dirty > > The result will be the lost of data user wrote on the step '3)'. (my patch > solves the issue at least for all cases w/o external changes) I get it. Could you please resend the patch with all these failure cases described in the header? Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
