Re: [patch 1/2] mm: dont clear PG_uptodate in invalidate_complete_page2()

From: Evgeniy Polyakov
Date: Wed Jun 25 2008 - 11:37:03 EST


On Wed, Jun 25, 2008 at 04:41:10PM +0200, Miklos Szeredi (miklos@xxxxxxxxxx) wrote:
> > > > Like __block_prepare_write()?
> > >
> > > That's called with the page locked and page->mapping verified.
> >
> > Only when called via standard codepath.
>
> It would be a grave error to call it without the page lock.

Page is locked of course, but invalidated, removed from all trees and
caches, i.e. grab, lock, check, unlock... invalidate, write into that
page should fail, but it will not, since page is uptodate and
prepare_write does not check mapping at all.

> > > I want the page fully invalidated, and I also want splice and nfs
> > > exporting to work as for other filesystems.
> >
> > Fully invalidated page can not be uptodate, doesnt' it? :)
>
> That's just a question of how we interpret PG_uptodate. If it means:
> the page contains data that is valid, or was valid at some point in
> time, then an invalidated or truncated page can be uptodate.
>
> > You destroy existing functionality just because there are some obscure
> > places, where it is used, so instead of fixing that places, you treat
> > the symptom. After writing previous mail I found a way to workaround it
> > even with your changes, but the whole approach of changing
> > invalidate_complete_page2() is not correct imho.
>
> You rely on page being !PageUptodate() after being invalidated? Why
> can't you check page->mapping instead (as everything else does)?

I already found a solution, but I worry about splice code, which usage
results in hidden error now.

> > Is this nfs/fuse problem you described:
> > http://marc.info/?l=linux-fsdevel&m=121396920822693&w=2
>
> Yes.
>
> > Instead of returning error when reading from invalid page, now you
> > return old content of it?
>
> No, instead of returning a short count, it is now returning old
> content.

Or instead of returning error or zero and relookup page eventually,
which can already contain new data, we get old data.

--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/