> Thanks --- this tells us exactly what has gone wrong, I think.
> Something, somewhere, (electric fence, perhaps?) has set up a region of
> memory with no access allowed. There is a page mapped, but it is not
> visible to the process: somebody has done an mprotect() to eliminate the
> visibility of the page. That clears the _PAGE_PRESENT bit on the pte
> but keeps the _PAGE_PROTNONE bit set, and _PAGE_PROTNONE is an alias for
> _PAGE_RW!! That's the trouble: the pte_write() test to see if a page is
> writable tests the _PAGE_RW bit but fails to first of all check whether
> or not _PAGE_PRESENT is set in the first place.
>
> I've just tried to reproduce this with the program at the end, which
> creates page of local memory, allows it to be swapped out, then pages it
> in and marks it PROT_NONE.
Hi Stephen,
Glad to see you've got the "writable" swap problem figured out, and it
turned out not to be a problem with the swap at all. In my searches for
the problem I had overlooked the interaction between the PRESENT and
PROT_NONE bits.
Interestingly enough, the patch I posted last week for mm/mprotect.c
immediately reported the problem when I ran your test program. I got:
[root@acer /root]# ./protnone
[1]+ Stopped (signal) ./protnone
[root@acer /root]# %
./protnone
mprotect: swapped page now writable
[1]+ Stopped (signal) ./protnone
The patch makes the same test for pte_present and pte_write as the
vmscan code, and so was confused in the same way as the test in
vmscan.c.
Hopefully any remaining swap bugs won't be so hard to track down ...
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu