>>>>> " " == Linus Torvalds <torvalds@transmeta.com> writes:
> On Mon, 15 May 2000, Trond Myklebust wrote:
>>
>> Would the following compromise be acceptable? It differs from
>> Andreas previous attempt by the extra line which clears
>> PG_uptodate on the page.
> It touches the "Uptodate" bit without holding the page lock,
> which means that there could be any number of random races
> causing undefined behaviour..
My question should perhaps be reformulated: Would these be worse than
the races from just dropping the page the way we have to do now?
>From the point of regular files, there is not much of a race possible:
we're holding the page cache lock, so the danger would be limited to
IO issues. Common sense at the fs level can correct this. The question
(again) is mmapped files.
> It also means that you might have a page mapped even though it
> is marked not-up-todate, which sounds very wrong.
Yes, but the data *are* not uptodate here. When you call
invalidate_inode_pages() it is precisely because you do not trust the
page cache. Of course if the MM people can design a way of safely
unmapping the bad page...
Another problem with this scheme of keeping bad pages hashed and
not-uptodate: if you then run one of the generic_file_*() routines on
the page, mmapped writes etc. are going to get clobbered. For that
particular case, the current behaviour of a private mapping seems
better.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:26 EST