Skip to contentSkip to conversation

PATCH: Building on ia32

Linux-ia64 William Taber 2 participants 4 messages Jan 17, 2001 – Jan 18, 2001

Subsystems (6)
lore
Share & tools
lore
#0 lore raw

When I downloaded Linux 2.4.0 and applied the linux-2.4.0-ia64-010109.diff patch, I discovered that I could no longer compile ia32 kernels. It turned out that there were reletively few changes needed to get the ia32 kernel to compile cleanly and come up and run. As I promised yesterday, here are the patches I needed to make. This may not be exhaustive, since I do not have all options turned on and I didn't try to build many drivers. Note that this patch will remove the buggy code that I reported yesterday, rather than just conditionalizing it. Since the code was broken and would not run properly, as well as being non-portable, I just took it out pending a fix. In the interest of getting the latest ia64 changes ready for merging into the the main 2.4.x tree at some point, here are the diffs.

Enjoy.

Will Taber

drivers/char/mem.c +2 -0
diff -Nur linux-2.4.0-base/drivers/char/mem.c linux-2.4.0/drivers/char/mem.c
@@ -205,8 +205,10 @@
 	    || vma->vm_flags & VM_NONCACHED)
 		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 
+#if defined(__ia64__)
 	if (vma->vm_flags & VM_WRITECOMBINED)
 		vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+#endif
 
 	/* Don't try to swap out physical pages.. */
 	vma->vm_flags |= VM_RESERVED;
fs/fcntl.c +2 -0
diff -Nur linux-2.4.0-base/fs/fcntl.c linux-2.4.0/fs/fcntl.c
@@ -269,7 +269,9 @@
 			 * to fix this will be in libc.
 			 */
 			err = filp->f_owner.pid;
+#if (__ia64__)
 			force_successful_syscall_return();
+#endif
 			break;
 		case F_SETOWN:
 			lock_kernel();

diff -Nur linux-2.4.0-base/include/asm-ia64/irq.h
linux-2.4.0/include/asm-ia64/irq.h

include/asm-ia64/irq.h +3 -0
@@ -27,5 +27,8 @@
 extern void disable_irq (unsigned int);
 extern void disable_irq_nosync (unsigned int);
 extern void enable_irq (unsigned int);
+extern unsigned int do_IRQ (unsigned long irq, struct pt_regs *regs);
+extern void do_IRQ_per_cpu (unsigned long irq, struct pt_regs *regs);
+
 
 #endif /* _ASM_IA64_IRQ_H */

diff -Nur linux-2.4.0-base/include/asm-ia64/pgalloc.h linux-2.4.0/include/asm-ia64/pgalloc.h

include/asm-ia64/pgalloc.h +2 -2
@@ -281,14 +281,14 @@
 }
 
 static inline void
-clear_user_page (void *addr, unsigned long vaddr, struct page *page)
+clear_user_page (void *addr, struct page *page)
 {
 	clear_page(addr);
 	flush_dcache_page(page);
 }
 
 static inline void
-copy_user_page (void *to, void *from, unsigned long vaddr, struct page *page)
+copy_user_page (void *to, void *from, struct page *page)
 {
 	copy_page(to, from);
 	flush_dcache_page(page);

diff -Nur linux-2.4.0-base/include/linux/highmem.h linux-2.4.0/include/linux/highmem.h

include/linux/highmem.h +2 -2
@@ -45,7 +45,7 @@
 /* when CONFIG_HIGHMEM is not set these will be plain clear/copy_page */
 static inline void clear_user_highpage(struct page *page, unsigned long vaddr)
 {
-	clear_user_page(kmap(page), vaddr);
+	clear_user_page(kmap(page), page);
 	kunmap(page);
 }
 
@@ -87,7 +87,7 @@
 
 	vfrom = kmap(from);
 	vto = kmap(to);
-	copy_user_page(vto, vfrom, vaddr);
+	copy_user_page(vto, vfrom, to);
 	kunmap(from);
 	kunmap(to);
 }
include/linux/irq.h +0 -2
diff -Nur linux-2.4.0-base/include/linux/irq.h linux-2.4.0/include/linux/irq.h
@@ -56,8 +56,6 @@
 
 #include <asm/hw_irq.h> /* the arch dependent stuff */
 
-extern unsigned int do_IRQ (unsigned long irq, struct pt_regs *regs);
-extern void do_IRQ_per_cpu (unsigned long irq, struct pt_regs *regs);
 extern int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction 

*);
extern int setup_irq(unsigned int , struct irqaction * );

mm/memory.c +1 -5
diff -Nur linux-2.4.0-base/mm/memory.c linux-2.4.0/mm/memory.c
@@ -1150,10 +1150,8 @@
  */
 static inline int handle_pte_fault(struct mm_struct *mm,
 	struct vm_area_struct * vma, unsigned long address,
-	int access_type, pte_t * pte)
+	int write_access, pte_t * pte)
 {
-	int write_access = is_write_access(access_type);
-	int exec_access = is_exec_access(access_type);
 	pte_t entry;
 
 	/*
@@ -1180,8 +1178,6 @@
 
 		entry = pte_mkdirty(entry);
 	}
-	if (exec_access)
-		entry = pte_mkexec(entry);
 	entry = pte_mkyoung(entry);
 	establish_pte(vma, address, pte, entry);
 	spin_unlock(&mm->page_table_lock);
+---------------------------------------------------------------------+
| Will Taber                                                          |
| Software Engineer, CMBU                 E-mail  [email protected] |
| Rational Software Corporation           Phone:  781-676-2436        |
| 20 Maguire Road, Lexington, Mass. 02421                             |
+---------------------------------------------------------------------+
#1 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · William Taber

William> When I downloaded Linux 2.4.0 and applied the
William> linux-2.4.0-ia64-010109.diff patch, I discovered that I could no William> longer compile ia32 kernels. It turned out that there were William> reletively few changes needed to get the ia32 kernel to compile William> cleanly and come up and run. As I promised yesterday, here are the William> patches I needed to make. This may not be exhaustive, since I do not William> have all options turned on and I didn't try to build many William> drivers. Note that this patch will remove the buggy code that I William> reported yesterday, rather than just conditionalizing it. Since the William> code was broken and would not run properly, as well as being William> non-portable, I just took it out pending a fix. In the interest of William> getting the latest ia64 changes ready for merging into the the main William> 2.4.x tree at some point, here are the diffs.

But your patch breaks the lazy-execute bit scheme that IA-64 relies on to avoid cache flushing. Your kernel will probably hang on any app that does dynamic code generation (e.g., such as due to nested C functions).

You're probably better off implementing is_exec_access() on x86 as always returning 0.

	--david
#2 lore raw
In reply to William Taber
Quoted 9 lines

But your patch breaks the lazy-execute bit scheme that IA-64 relies on to avoid cache flushing. Your kernel will probably hang on any app that does dynamic code generation (e.g., such as due to nested C functions).

You're probably better off implementing is_exec_access() on x86 as always returning 0.

	--david

David,

Actually, I think the best solution is to move is_exec_access() and is_write_access() out of asm-ia64/pgtable.h, and into some machine independent header (perhaps mm.h ?), redefining the magic numbers 2 and 4 to be VM_WRITE and VM_EXEC respectively. This still leaves the question of who is responsible for changing all of the platform specific callers of handle_mm_fault to reflect the new semantics?

Will

+---------------------------------------------------------------------+
| Will Taber                                                          |
| Software Engineer, CMBU                 E-mail  [email protected] |
| Rational Software Corporation           Phone:  781-676-2436        |
| 20 Maguire Road, Lexington, Mass. 02421                             |
+---------------------------------------------------------------------+
#3 lore raw
In reply to William Taber
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · William Taber

William> Actually, I think the best solution is to move William> is_exec_access() and is_write_access() out of William> asm-ia64/pgtable.h, and into some machine independent William> header (perhaps mm.h ?), redefining the magic numbers 2 and William> 4 to be VM_WRITE and VM_EXEC respectively. This still William> leaves the question of who is responsible for changing all William> of the platform specific callers of handle_mm_fault to William> reflect the new semantics?

The sole reason for the existence of those macros is so they can be defined in a platform-specific way. No other platform is currently using lazy-execute bits and on those platforms, there is no need to check the executable bit in the page fault handler. However, I don't think is_exec_access() is the final answer either---that's why I don't bother updating the other ports: it's still very much works in progress.

	--david