> On Sat, 6 Jul 2002, Andrew Morton wrote:
>>
>> That is basically what do_munmap() does. But I'm quite unfamiliar with
>> the locking in there.
>
> The only major user of i_shared is really vmtruncate, I think, and it's
> quite ok to unmap the file before removing the mapping from the shared
> list - if vmtruncate finds a unmapped area, it just won't be doing
> anything (zap_page_range, but that won't do anything without any page
> tables).
>
> Together with the fact that unmap() already does it this way anyway, it
> looks like the obvious fix..
I would tend to agree in principle -- shouldn't be a problem with
truncate since it can never lead to stale pages anyhow, which
is why munmap can do it that way without losing correctness today.
However I recall we had a discussion on this a very long while back
(around end of 2000), when I was trying to solve this i_shared_lock
vs page_table_lock ordering problem by taking a exactly similar
approach for the case of mmap, mprotect etc as well (taking a cue
from what munmap did) rather than acquire both locks at the same
time in those cases. At that time Dave Miller had expressed some
reservations about such assumptions in the view of impact of
(future) code that might use the shared list differently. He
preferred to solve the problem by always taking the i_shared_lock
before page_table_lock everywhere, and at that was the fix that
got checked in. (Except that this didn't hold for munmap where
of course this doesn't work, since unmap could cross multiple
mappings)
Its been a long time since I've looked at that code, and things
have changed quite drastically, so I might be jumping too early,
but if I look at the code now I'm a little confused about whether
the locking order has been audited for other paths either ---
vma_link seems to acquire page_table_lock before i_shared_lock --
the reverse of what vmtruncate does. Are there other things that
save us from races there ?
Regards
Suparna
>
> Linus
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in the body
> to majordomo@kvack.org. For more info on Linux MM, see:
> http://www.linux-mm.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:12 EST