Skip to contentSkip to conversation

2.4.7pre8aa1

DISCUSSION Jeff Dike 2 participants 5 messages Jul 19, 2001 – Jul 23, 2001

Subsystems (2)
User-mode Linux (UML) ptrace support
lore
Share & tools
lore

Jeff Dike

author
#0 lore raw
Quoted 6 lines

Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2
Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2
Moved part of it in the tux directory so it can compile without tux (in reality I got errno compilation error but it's low prio and I'll sort it out later, Jeff Dike any hint is welcome ;).

This is the patch I sent to Alan a while back which works around the problem.

rmk suggested a better way which I'll add at some point.

Jeff

arch/um/Makefile +2 -0
diff -Naur -X exclude-files ac_cur/arch/um/Makefile ac/arch/um/Makefile
@@ -20,6 +20,8 @@
 LINK_PROFILE = $(PROFILE) -Wl,--wrap,__monstartup
 endif
 
+CFLAGS := $(subst -fno-common,,$(CFLAGS))
+
 SUBDIRS += $(ARCH_DIR)/fs $(ARCH_DIR)/drivers $(ARCH_DIR)/kernel \
 	$(ARCH_DIR)/sys-$(SUBARCH)
#1 lore raw
Quoted 18 lines · Jeff Dike
Quoted 6 lines

Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2
Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2
Moved part of it in the tux directory so it can compile without tux (in reality I got errno compilation error but it's low prio and I'll sort it out later, Jeff Dike any hint is welcome ;).

This is the patch I sent to Alan a while back which works around the problem.

rmk suggested a better way which I'll add at some point.

Jeff

diff -Naur -X exclude-files ac_cur/arch/um/Makefile ac/arch/um/Makefile

arch/um/Makefile line 26

Quoted 7 lines
arch/um/Makefile +2 -0
@@ -20,6 +20,8 @@
 LINK_PROFILE = $(PROFILE) -Wl,--wrap,__monstartup
 endif
 
+CFLAGS := $(subst -fno-common,,$(CFLAGS))
+
 SUBDIRS += $(ARCH_DIR)/fs $(ARCH_DIR)/drivers $(ARCH_DIR)/kernel \
 	$(ARCH_DIR)/sys-$(SUBARCH)

works fine thanks! Of course I agree with rmk it would be better not to disable -fno-common but this is ok for now ;) (after all we would catch any potential important name collision during the compiles of the other targets)

Andrea

author
#2 lore raw
Quoted 2 lines · [email protected] said:

works fine thanks! Of course I agree with rmk it would be better not to disable -fno-common but this is ok for now ;)

Yeah, it's temporary. rmk's idea was to use the link script to toss errno.o out of the final binary.

Quoted 3 lines

(after all we would
catch any potential important name collision during the compiles of the other targets)

Agreed. -fno-common is definitely good. The only conflict is errno, but when Arjan first started playing with -fno-common, he found a couple of UML bugs.

Jeff

#3 lore raw
In reply to Jeff Dike
Quoted 22 lines · Andrea Arcangeli
Quoted 21 lines · Jeff Dike
Quoted 6 lines

Only in 2.4.7pre6aa1: 51_uml-ac-to-aa-2.bz2
Only in 2.4.7pre8aa1/: 51_uml-ac-to-aa-3.bz2
Moved part of it in the tux directory so it can compile without tux (in reality I got errno compilation error but it's low prio and I'll sort it out later, Jeff Dike any hint is welcome ;).

This is the patch I sent to Alan a while back which works around the problem.

rmk suggested a better way which I'll add at some point.

Jeff

diff -Naur -X exclude-files ac_cur/arch/um/Makefile ac/arch/um/Makefile

arch/um/Makefile +0 -0
@@ -20,6 +20,8 @@
 LINK_PROFILE = $(PROFILE) -Wl,--wrap,__monstartup
 endif
Quoted 6 lines

arch/um/Makefile line 26

Quoted 4 lines
arch/um/Makefile +2 -0
+CFLAGS := $(subst -fno-common,,$(CFLAGS))
+
 SUBDIRS += $(ARCH_DIR)/fs $(ARCH_DIR)/drivers $(ARCH_DIR)/kernel \
 	$(ARCH_DIR)/sys-$(SUBARCH)

works fine thanks! Of course I agree with rmk it would be better not to

I should have said "compiles" fine (not "works" fine :).

__initdata is broken in uml and the kernel deadlocks because the wait list is empty in complete() despite wait_for_completion actually registered correctly into it. This because wait_for_completion runs in a different address space than complete() and the virtual memory is not shared across the two address spaces (it is not rempped in a MAP_SHARED so it generates a cow). The registration is basically only private to the entity that is registrating and it will never get visible to the waker task that will do nothing. This is a severe bug not just for the completion code in 2.4.7. here the fix (plus the ptrace bit):

arch/um/kernel/ptrace.c renamed from arch/um/kernel/ptrace.c.~1~ +1 -1
@@ -43,7 +43,7 @@
 	if (request == PTRACE_ATTACH) {
 		if (child == current)
 			goto out_tsk;
-		if ((!child->dumpable ||
+		if ((!ptrace_dumpable(child) ||
 		     (current->uid != child->euid) ||
 		     (current->uid != child->suid) ||
 		     (current->uid != child->uid) ||
arch/um/link.ld.in renamed from arch/um/link.ld.in.~1~ +1 -1
@@ -45,7 +45,6 @@
   . = ALIGN(4096);		/* Init code and data */
   __init_begin = .;
   .text.init : { *(.text.init) }
-  .data.init : { *(.data.init) }
   . = ALIGN(16);
   __setup_start = .;
   .setup.init : { *(.setup.init) }

@@ -92,6 +91,7 @@
     . = ALIGN(16384);		/* init_task */
     *(.data.init_task)
     *(.data)
+    *(.data.init)
     *(.gnu.linkonce.d*)
     CONSTRUCTORS
   }

(I didn't update the init_begin/end logic since there's no logic at all in uml because we don't free that memory anyways so there's no side effect because of that change)

Quoted 5 lines

disable -fno-common but this is ok for now ;) (after all we would catch any potential important name collision during the compiles of the other targets)

Andrea

Andrea

author
#4 lore raw
Quoted 1 line · [email protected] said:

I should have said "compiles" fine (not "works" fine :).

2.4.6 "works" fine :-)

I just finished fixing 2.4.7. My fixes are similar to yours (I moved stext rather than moving .data.init).

Quoted 9 lines

__initdata is broken in uml and the kernel deadlocks because the wait list is empty in complete() despite wait_for_completion actually registered correctly into it. This because wait_for_completion runs in a different address space than complete() and the virtual memory is not shared across the two address spaces (it is not rempped in a MAP_SHARED so it generates a cow). The registration is basically only private to the entity that is registrating and it will never get visible to the waker task that will do nothing. This is a severe bug not just for the completion code in 2.4.7.

Nice debugging, btw. I spent an hour this morning chasing that problem.

My 2.4.7 patch is available from the usual places:

       http://ftp.nl.linux.org/pub/uml/uml-patch-2.4.7-1.bz2
       http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.4.7-1.bz2
       http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.4.7-1.bz2

				Jeff