[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1KBWBK-0006Lp-03@pomaz-ex.szeredi.hu>
Date: Wed, 25 Jun 2008 16:41:10 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: johnpol@....mipt.ru
CC: miklos@...redi.hu, jens.axboe@...cle.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, hugh@...itas.com,
nickpiggin@...oo.com.au
Subject: Re: [patch 1/2] mm: dont clear PG_uptodate in invalidate_complete_page2()
> > > 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.
> > 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)?
> 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.
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists