Hi Jeff,
I was running 2.4.18-16um until last days and given that I use UML
more intensively from now on, I upgraded my tree to 2.4.18-29um
today. Unfortunately I noticed that some change since 16um broke my
code.
Checking all versions, I first noticed that my code was broken in
19um, when you changed some code that handles pte. In particular, in
include/asm-um/pgtable.h
--- pgtable.h.18 Thu May 23 16:46:52 2002
+++ pgtable.h.19 Thu May 23 16:46:42 2002
@@ -78,23 +78,17 @@
#define VMALLOC_VMADDR(x) ((unsigned long)(x))
#define VMALLOC_END (end_vm)
-/*
- * The 4MB page is guessing.. Detailed in the infamous "Chapter H"
- * of the Pentium details, but assuming intel did the straightforward
- * thing, this bit set in the page directory entry just means that
- * the page directory entry points directly to a 4MB-aligned block of
- * memory.
- */
#define _PAGE_PRESENT 0x001
#define _PAGE_NEWPAGE 0x002
#define _PAGE_PROTNONE 0x004 /* If not present */
#define _PAGE_RW 0x008
#define _PAGE_USER 0x010
-#define _PAGE_PCD 0x020
-#define _PAGE_ACCESSED 0x040
-#define _PAGE_DIRTY 0x080
-#define _PAGE_NEWPROT 0x100
+#define _PAGE_ACCESSED 0x020
+#define _PAGE_DIRTY 0x040
+#define _PAGE_NEWPROT 0x080
[snip]
From the excerpt above, we can notice that you changed _PAGE_NEWPROT
from 0x100 to 0x080. Incidentally, that change's broken my code. Let
me explain. I use swap type number NUM_SWAPFILES (in my case 31) as a
virtual swap device. In fix_range() and in pte_to_swp_entry() you call
pte_mkuptodate() macro which will clean _PAGE_NEWPROT bit for the pte
we are handling. In the case _PAGE_NEWPROT is 0x080 (unlike 0x100),
pte_mkuptodate() will clean a bit that is used for my swap type, so I
end up having a swap type number 15 (not 31 like as first set). It's
obvious that swap code won't be able to recognize my swap addresses
any longer.
First I thought about changing pte_mkuptodate() to clean _PAGE_NEWPROT
bit only for present ptes, since non-present ptes don't have this bit
on (do they?). However that's not enough because this non-present pte
will be taken as having new protection (pte_newprot() == 1) and we
will try to protect a wrong pte in fix_range(), panicing. Thus I think
we actually can't have a _PAGE_NEWPROT bit that isn't exclusive for
swap types bit.
I'd like to know what do you think about backing out this PAGE_NEWPROT
change and set it back as 0x100 (or even 0x200). This won't break swap
addresses and will allow us to have safely 32 swap devices (or 64 if
set to 0x200). Recall that 32 is the default maximum number of swap
devices in vanilla.
I am sending attached a 2-liner patch for 29um that set the value back
to 0x100.
Best regards,
--
Rodrigo S. de Castro <rc...@im...>
|
