convert page-l3.h macros to inlines

Avoid multiple evals as discussed in "double incrementing l2tab" thread.

sRp

Scott Parish
Signed-off-by: [email protected]

@@ -24,28 +24,66 @@ typedef struct { u32 l3_lo; u32 l3_hi; }
 typedef l3_pgentry_t root_pgentry_t;
 
 /* read access (depricated) */
-#define l1e_get_value(_x)         ((u64)(_x).l1_lo | (u64)(_x).l1_hi << 32)
-#define l2e_get_value(_x)         ((u64)(_x).l2_lo | (u64)(_x).l2_hi << 32)
-#define l3e_get_value(_x)         ((u64)(_x).l3_lo | (u64)(_x).l3_hi << 32)
+static inline u64 l1e_get_value(l1_pgentry_t x)
+{
+    return ((u64)x.l1_lo | (u64)x.l1_hi << 32);
+}
+static inline u64 l2e_get_value(l2_pgentry_t x)
+{
+    return ((u64)x.l2_lo | (u64)x.l2_hi << 32);
+}
+static inline u64 l3e_get_value(l3_pgentry_t x)
+{
+    return ((u64)x.l3_lo | (u64)x.l3_hi << 32);
+}
+
 
 /* read access */
-#define l1e_get_pfn(_x)           ((((_x).l1_hi & 0x0f) << (32-PAGE_SHIFT))  |\
-				    ((_x).l1_lo         >> PAGE_SHIFT))
-#define l1e_get_phys(_x)          ((((u64)(_x).l1_hi & 0x0f) << 32)  |\
-				    ((u64)(_x).l1_lo & PAGE_MASK))
-#define l1e_get_flags(_x)         ((_x).l1_lo &  ~PAGE_MASK)
-
-#define l2e_get_pfn(_x)           ((((_x).l2_hi & 0x0f) << (32-PAGE_SHIFT))  |\
-				    ((_x).l2_lo         >> PAGE_SHIFT))
-#define l2e_get_phys(_x)          ((((u64)(_x).l2_hi & 0x0f) << 32)  |\
-				    ((u64)(_x).l2_lo & PAGE_MASK))
-#define l2e_get_flags(_x)         ((_x).l2_lo &  ~PAGE_MASK)
-
-#define l3e_get_pfn(_x)           ((((_x).l3_hi & 0x0f) << (32-PAGE_SHIFT))  |\
-				    ((_x).l3_lo         >> PAGE_SHIFT))
-#define l3e_get_phys(_x)          ((((u64)(_x).l3_hi & 0x0f) << 32)  |\
-				    ((u64)(_x).l3_lo & PAGE_MASK))
-#define l3e_get_flags(_x)         ((_x).l3_lo &  ~PAGE_MASK)
+static inline unsigned long l1e_get_pfn(l1_pgentry_t x)
+{
+    return (((x.l1_hi & 0x0fULL) << (32-PAGE_SHIFT))  |
+	     (x.l1_lo         >> PAGE_SHIFT));
+}
+static inline u64 l1e_get_phys(l1_pgentry_t x)
+{
+    return ((((u64)x.l1_hi & 0x0fULL) << 32)  |
+	     ((u64)x.l1_lo & PAGE_MASK));
+}
+static inline unsigned long l1e_get_flags(l1_pgentry_t x)
+{
+    return (x.l1_lo & ~PAGE_MASK);
+}
+
+static inline unsigned long l2e_get_pfn(l2_pgentry_t x)
+{
+    return (((x.l2_hi & 0x0fULL) << (32-PAGE_SHIFT))  |
+	     (x.l2_lo         >> PAGE_SHIFT));
+}
+static inline u64 l2e_get_phys(l2_pgentry_t x)
+{
+    return ((((u64)x.l2_hi & 0x0fULL) << 32)  |
+	     ((u64)x.l2_lo & PAGE_MASK));
+}
+static inline unsigned long l2e_get_flags(l2_pgentry_t x)
+{
+    return (x.l2_lo & ~PAGE_MASK);
+}
+
+static inline unsigned long l3e_get_pfn(l3_pgentry_t x)
+{
+    return (((x.l3_hi & 0x0fULL) << (32-PAGE_SHIFT))  |
+	     (x.l3_lo         >> PAGE_SHIFT));
+}
+static inline u64 l3e_get_phys(l3_pgentry_t x)
+{
+    return ((((u64)x.l3_hi & 0x0fULL) << 32)  |
+	     ((u64)x.l3_lo & PAGE_MASK));
+}
+static inline unsigned long l3e_get_flags(l3_pgentry_t x)
+{
+    return (x.l3_lo & ~PAGE_MASK);
+}
+
 
 /* write access */
 static inline l1_pgentry_t l1e_empty(void)

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Oh, great, saves me some work ;)

Merged and uploaded with patchset #7 (it's against cset 1.1445). That one works fine for me, with both preempt on/off. I'll go test it a bit more.

Gerd

-mm seems unusually stable at present.
	-- akpm about 2.6.12-rc3-mm3

That was fast! Unfortunately i'm still ending up with the same crash:

http://srparish.net/tmp/2/xen-93 (.config/vmlinux/xen-syms)

sRp

Scott Parish
Signed-off-by: [email protected]

preempt off didn't help either.

sRp

Scott Parish
Signed-off-by: [email protected]

Seems to be the same very place. Adding current->comm to the printk next to the BUG() should show which process this is, probably it is the same every time which triggers some bug. If so, can you place the binary somewhere?

The system looks like Debian, correct?

Any difference when you move away /lib/tls (probably not, but who knows ...) ?

Sticking some debug printk into mm_walk which triggers depending on current->comm might help to see what is going on.

Gerd

-mm seems unusually stable at present.
	-- akpm about 2.6.12-rc3-mm3

I'm getting to a prompt now, although the system is still _very_ flaky and crashes (same basic trace: mm_walk..)

/lib/tls didn't seem to have any effect when it was crashing during boot, and it still doesn't seem to have any effect now that its finishing boot.

somewhere along the lines i told debian to update itself, and this might have been what got me to a prompt. (fwiw i'm running debian sid)

current->comm might have showed more consistancy earlier, but now its as random as when i crash (which i haven't been able to consistantly reproduce or consistantly avoid reproducing). i've seen stuff like "sshd" "bash" "rcX" so far.

the rest of this data is stuff i collected before moving to your 7th patch release. i can reproduce it if needed, but it was kind of tedious and nothing appears to have changed about the details of the crash..

+ the crash is always the last mm_walk_set_prot() in mm_walk(), that is the one for ptes.

+ the crash is always when pte == 0x15555000 (where pte is type 'pte_t *')

+ the pmd (pmd_t *) always has the lowest bits of 0xd60

+ the pte == 0x15555000 will appear in the middle of a seemingly fine pmd. by "continue"ing if pte == 0x15555000, i found there's a cluster of them:

...
mw pmd: 0xcf49fd50 pte: 0xc007d000
mw pmd: 0xcf49fd58 pte: 0xc007c000
mw pmd: 0xcf49fd60 pte: 0x15555000
mw pmd: 0xcf49fd68 pte: 0x15555000
mw pmd: 0xcf49fda0 pte: 0x15555000
...
mw pmd: 0xcf49ff48 pte: 0x15555000
mw pmd: 0xcf49ff50 pte: 0x15555000
mw pmd: 0xcf49ff58 pte: 0x15555000
mw pmd: 0xcf49ff60 pte: 0xcf4a0000
mw pmd: 0xcf49ff68 pte: 0xcf4a1000
mw pmd: 0xcf49ff70 pte: 0xcf4b2000
mw pmd: 0xcf49ff78 pte: 0xcf49f000
mw pmd: 0xcf49ff80 pte: 0x15555000
mw pmd: 0xcf49ff88 pte: 0x15555000
mw pmd: 0xcf49ff90 pte: 0x15555000
mw pmd: 0xcf49ff98 pte: 0x15555000
mw pmd: 0xcf49ffa0 pte: 0xbffff000
mw pmd: 0xcf49ffa8 pte: 0x15555000
mw pmd: 0xcf49ffb0 pte: 0x15555000
mw pmd: 0xcf49ffb8 pte: 0x15555000
mw pmd: 0xcf49ffc0 pte: 0x15555000
mw pmd: 0xcf49ffc8 pte: 0x15555000
mw pmd: 0xcf49ffd0 pte: 0x15555000
mw pmd: 0xcf49ffd8 pte: 0x15555000
mw pmd: 0xcf49ffe0 pte: 0x15555000
mw pmd: 0xcf49ffe8 pte: 0x15555000
mw pmd: 0xcf49fff0 pte: 0x15555000
mw pmd: 0xcf49fff8 pte: 0x15555000
mw pmd: 0xc0536df8 pte: 0xcf276000
mw pmd: 0xc0536e00 pte: 0xcf277000
mw pmd: 0xc0536ff8 pte: 0xcece8000

that's all i can think of right now that i found interesting

sRp

Scott Parish
Signed-off-by: [email protected]

fwiw, i've been temporarily moved to helping out with amd64

sRp

Scott Parish
Signed-off-by: [email protected]