Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops

[Jeff Dike]

On Sun, May 08, 2005 at 01:18:32AM +0100, Al Viro wrote:
> Hrm...

I had a lot of these fixed already.  These will be mostly in the fixlets
patch.

> 	a) stub.S handling breaks on O= builds.   Actually, your unprofile
> breaks there - it's bypassing the machinery that deals with include path.

This?
	$(patsubst -pg,,$(patsubst -fprofile-arcs -ftest-coverage,,$(1)))

I don't see any connection to include paths there.


> 	b) stub_segv.c on amd64 includes <signal.h>.  Not a good idea...

x86_64 doesn't, but i386 does.  Fixed now.

> 	c) sysdep-x86_64/checksum.h in -rc4 has csum_partial_copy_from_user()
> that needs updating (AFAICS, you have that in your patchset, but it hadn't
> reached Linus)

Fixed.

> 	d) ip_compute_csum() prototype is missing (same file)
> 	j) ip_compute_csum should be exported on amd64.

OK, I need to look at this a bit more.

> 	e) #define UPT_SYSCALL_RET(r) UPT_RAX(r) is needed in amd64 ptrace.h

Fixed.

> 	f) take a good look at UPT_SET() in the same file ;-)

Sigh.  Fixed now.

> 	g) CFLAGS_csum-partial.o := -Dcsum_partial=arch_csum_partial in
> sys-x86_64/Makefile needs to be removed.

Fixed.

> 	h) Makefile.rules should be included _after_ SYMLINKS = in the same
> file.

Fixed.

> 	i) sys-x86_64/delay.c needs exports of __udelay() and __const_udelay(),
> include of linux/module.h and barriers in your delay loop bodies (or games
> with volatile - anything that would guarantee that gcc won't decide to optimize
> the entire loop away).  The last part applies to i386 as well.

Looks to me like it all applies to i386 too, except that __delay looks 
unoptimizable.

It also looks to me like I could implement __udelay as n=... ; __delay(n);

And also never mind the fact that __udelay and __const_udelay are identical.

> 	k) sys-x86_64/syscalls.c needs include "kern.h"

Fixed now.

> 	l) elf-i386.h should include <asm/user.h>, not "user.h"

Fixed now.

> 	m) elf-x86_64.h lacks R_X86_64_... definitions

Fixed now.

> 	n) WTF _is_ that #ifdef TIF_IA32 in there?  Aside of the trailing \,
> we could as well put #error there - free-floating clear_thread_flag(TIF_IA32);> outside of any function body will have that effect anyway.

The trailing \ aside, which is fixed, that's a reminder for me when I add
the 32-bit compatibility code.

> 	o) in drivers/chan_kern.c we have several printf(KERN_ERR "...");
> these should become printk, as they clearly had been intended.  As it is,
> they give instant panic if we ever call them.

Oops.  This requires a bit of thought.  Offhand, I think they need to be 
printf, because that early in boot, printk'd stuff may not reach the screen
if UML exits then.

> 	p) TOP_ADDR in Kconfig_x86_64 got lost in transmission - your patchset
> has it, but same patch in Linus' tree does not.

Fixed

> 
> I've got patches for everything except (a); that one is really nasty.  I hope
> to sort it out by tonight; if not, I'll just send what I've got by now.

OK, send me what you have, and if we've fixed the same thing differently,
I choose one or the other.

				Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/