Re: rmap: page_mapping barrier

[Hugh Dickins]

On Thu, 8 Apr 2004, Andrea Arcangeli wrote:
> 
> I'll do further checking on this when I'm back from vacations on 14,

Have a good one.

> though if you didn't find anything by that time it most certainly means
> there's no race ;).

I'm afraid we can't deduce the nonexistence of a race from my failure
to search very hard.

> I don't want to discourage you in searching for more
> races in this area ;), I just don't see problems. BTW, if my tree will
> have a problem here, anonmm should have it too, maybe the other way

Oh yes, we're quite equal on this: I wasn't trying to blacken
your approach, just raising an issue and asking for help.

> around not (really Hugh, my approch of being transparent with
> page_mapping if far superior, you may find it ugly to check for
> swapper_inode in the pagecache entry/exit points but then it gets
> everything right and more obviously, just see the backing-dev-unplugging
> code, and the swap_unplug_fn stuff, I only had to change a page->mapping
> into a page_mapping in block_sync_page [the per-mapping unplug stuff]
> and everything else just worked without rejects).

On that we differ, and always shall, I expect.  Yes, carrying around
the PageSwapCache? &swapper_space stuff does make sync_page look
cleaner, and shrink_list quite a lot easier - I gave up on trying to
eliminate it completely, would uglify shrink_list too much.  But it
is a fiction, and for everywhere else (I think that's correct) it's
just baggage - made sense when you could stuff it in page->mapping
and then forget about it, but a lot less sense if we have to check
PageSwapCache all over (even if that is hidden in an inline function).

Hugh

-
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/