On Wed, 17 May 2000, Matt Yourst wrote:
>
> Well, I tracked the problem down to several lines in filemap.c that totally
> changed the filemap_write_page locking semantics between pre7-3 and pre7-4.
"swapout()" is now called with the page lock held.
Your patch will make any filemap swapout() deadlock very quickly. The page
has already been locked earlier in vmscan.c.
> A
> patch is attached that appears to fix the problem on both ReiserFS and (the much
> less common case) on ext2 filesystems. I don't know how this affects other code,
> but since filemap_write_page is private to filemap.c, I'm guessing it doesn't
> matter much. The problem seems to arise since filemap_swapout does NOT
> lock/unlock the page (it wrongly still assumes filemap_write_page does this),
It does _not_ wrongly assume this. It _correctly_ assumes that the page
has been locked by higher layers - the higher layer just happens to be
"try_to_swap_out()" rather than "filemap_write_page()".
> while filemap_sync_pte (i.e., called from munmap) DOES try to lock the page (but
> not anymore, since I fixed it.) In any case, I restored the old semantics and
> everything seems to work fine now.
Try doing a writable mmap() under low memory, and you will lock up pretty
much immediately.
You did not restore the old semantics, you just restored some old code
that is no longer valid. I don't know what the problem is, but this patch
is not the solution.
Linus
-
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 : Sat May 20 2000 - 12:56:24 EDT