| Message ID | 1312066923.22074.53.camel@i7.infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Jul 31, 2011 at 1:02 AM, David Woodhouse <dwmw2@infradead.org> wrote: > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> > --- > arch/um/os-Linux/Makefile | 2 -- > arch/um/os-Linux/user_syms.c | 2 +- > 2 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile > index b33f4df..78658a7 100644 > --- a/arch/um/os-Linux/Makefile > +++ b/arch/um/os-Linux/Makefile > @@ -13,8 +13,6 @@ USER_OBJS := $(user-objs-y) aio.o elf_aux.o execvp.o file.o helper.o irq.o \ > main.o mem.o process.o registers.o sigio.o signal.o start_up.o time.o \ > tty.o tls.o uaccess.o umid.o util.o > > -CFLAGS_user_syms.o += -DSUBARCH_$(SUBARCH) > - > HAVE_AIO_ABI := $(shell [ -r /usr/include/linux/aio_abi.h ] && \ > echo -DHAVE_AIO_ABI ) > CFLAGS_aio.o += $(HAVE_AIO_ABI) > diff --git a/arch/um/os-Linux/user_syms.c b/arch/um/os-Linux/user_syms.c > index 45ffe46..9165513 100644 > --- a/arch/um/os-Linux/user_syms.c > +++ b/arch/um/os-Linux/user_syms.c > @@ -45,7 +45,7 @@ EXPORT_SYMBOL(readdir64); > extern void truncate64(void) __attribute__((weak)); > EXPORT_SYMBOL(truncate64); > > -#ifdef SUBARCH_i386 > +#ifdef __i386__ > EXPORT_SYMBOL(vsyscall_ehdr); > EXPORT_SYMBOL(vsyscall_end); > #endif Why do we need this?
On Mon, 2011-08-01 at 00:11 +0200, richard -rw- weinberger wrote: > > Why do we need this? The arch/x86_64 and arch/i386 directories were removed from the kernel four years ago, and replaced by the 'x86' arch. UML is still dependent on the legacy SUBARCH=i386 and SUBARCH=x86_64 settings, and the patch sequence I just posted makes it cope with SUBARCH=x86.
On Sun, Jul 31, 2011 at 11:24:21PM +0100, David Woodhouse wrote: > On Mon, 2011-08-01 at 00:11 +0200, richard -rw- weinberger wrote: > > > > Why do we need this? > > The arch/x86_64 and arch/i386 directories were removed from the kernel > four years ago, and replaced by the 'x86' arch. UML is still dependent > on the legacy SUBARCH=i386 and SUBARCH=x86_64 settings, and the patch > sequence I just posted makes it cope with SUBARCH=x86. Hell, no. If you want to do it, do it the right way. See #x86_merge in git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/ -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jul 31, 2011 at 11:48:35PM +0100, Al Viro wrote: > On Sun, Jul 31, 2011 at 11:24:21PM +0100, David Woodhouse wrote: > > On Mon, 2011-08-01 at 00:11 +0200, richard -rw- weinberger wrote: > > > > > > Why do we need this? > > > > The arch/x86_64 and arch/i386 directories were removed from the kernel > > four years ago, and replaced by the 'x86' arch. UML is still dependent > > on the legacy SUBARCH=i386 and SUBARCH=x86_64 settings, and the patch > > sequence I just posted makes it cope with SUBARCH=x86. > > Hell, no. If you want to do it, do it the right way. See #x86_merge in > git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/ FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux, Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to arch/x86/um/Makefile.defs. Next after that - arch/powerpc/um (and yes, it means resurrected uml/ppc port; for now - only ppc32, since I have no ppc64 boxen to test on). -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote: > FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to > arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux, > Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to > arch/x86/um/Makefile.defs. Next after that - arch/powerpc/um (and yes, > it means resurrected uml/ppc port; for now - only ppc32, since I have no > ppc64 boxen to test on). I can give you an account on a ppc64 box if that would help... What you've done so far, with the one extra patch I just sent, seems perfectly sufficient to make it cope with SUBARCH defaulting to x86 instead of to i386 or x86_64. Are you happy to push it before you do the rest of the refactoring/moving?
On Mon, Aug 1, 2011 at 1:13 AM, David Woodhouse <dwmw2@infradead.org> wrote: > On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote: >> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to >> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux, >> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to >> arch/x86/um/Makefile.defs. Next after that - arch/powerpc/um (and yes, >> it means resurrected uml/ppc port; for now - only ppc32, since I have no >> ppc64 boxen to test on). > > I can give you an account on a ppc64 box if that would help... Isn't UML on ppc broken since ages? As I don't have a ppc box I could never test it...
On Mon, 2011-08-01 at 01:17 +0200, richard -rw- weinberger wrote: > Isn't UML on ppc broken since ages? Since before the ppc{,64} -> powerpc merge, by the looks of it. > As I don't have a ppc box I could never test it... Give SSH public key and preferred username...
On Mon, Aug 01, 2011 at 01:17:17AM +0200, richard -rw- weinberger wrote: > On Mon, Aug 1, 2011 at 1:13 AM, David Woodhouse <dwmw2@infradead.org> wrote: > > On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote: > >> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to > >> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux, > >> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to > >> arch/x86/um/Makefile.defs. ?Next after that - arch/powerpc/um (and yes, > >> it means resurrected uml/ppc port; for now - only ppc32, since I have no > >> ppc64 boxen to test on). > > > > I can give you an account on a ppc64 box if that would help... > > Isn't UML on ppc broken since ages? Yes. Resurrected is not the right word here, sorry... Anyway, could you take a look at the git tree at git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/, branch x86_merge and comment? It doesn't include stuff from this thread (yet); what it does is * further headers cleanups * sys-{i386,x86_64} merged; all[1] x86-specific code taken first to arch/um/sys-x86 and then (by final commit) to arch/x86/um. IMO that's the right place for it - target-dependent code is better off not hidden from maintainers of the target arch. When we get other ports to working shape, their target-specific parts ought to go into arch/<target>/um. * hopefully saner treatment of sigcontext; should make life easier for other ports. [1] theoretically - in reality we still have more than a few x86-isms in "generic" um headers in arch/um/include/asm. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 1, 2011 at 06:32, Al Viro <viro@zeniv.linux.org.uk> wrote: > On Mon, Aug 01, 2011 at 01:17:17AM +0200, richard -rw- weinberger wrote: >> On Mon, Aug 1, 2011 at 1:13 AM, David Woodhouse <dwmw2@infradead.org> wrote: >> > On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote: >> >> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to >> >> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux, >> >> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to >> >> arch/x86/um/Makefile.defs. ?Next after that - arch/powerpc/um (and yes, >> >> it means resurrected uml/ppc port; for now - only ppc32, since I have no >> >> ppc64 boxen to test on). >> > >> > I can give you an account on a ppc64 box if that would help... >> >> Isn't UML on ppc broken since ages? > > Yes. Resurrected is not the right word here, sorry... Oh, what a disappointment. I really hoped it was true... BTW, how much work would it be to port UML to ARM? Would be nice-to-have on your Android phone, as it can provide a full Linux userspace without requiring rooting the phone. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 1, 2011 at 12:04 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > BTW, how much work would it be to port UML to ARM? Would be nice-to-have on > your Android phone, as it can provide a full Linux userspace without > requiring rooting > the phone. > Depends how strong your UML- and ARM-fu is. ;-) I'm sure it will be non-trivial...
On Mon, Aug 01, 2011 at 12:04:37PM +0200, Geert Uytterhoeven wrote: > > Yes. ??Resurrected is not the right word here, sorry... > > Oh, what a disappointment. I really hoped it was true... > > BTW, how much work would it be to port UML to ARM? Would be nice-to-have on > your Android phone, as it can provide a full Linux userspace without > requiring rooting > the phone. Moderately unpleasant, but not fatally so. I have no idea how often will cache aliasing bite you, though. We really need to get non-x86 ports working to see how many portability issues are there; what I've got for ppc is promising, but very preliminary... -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 1, 2011 at 6:32 AM, Al Viro <viro@zeniv.linux.org.uk> wrote: > Anyway, could you take a look at the git tree at > git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/, > branch x86_merge and comment? It doesn't include stuff from this > thread (yet); what it does is > * further headers cleanups > * sys-{i386,x86_64} merged; all[1] x86-specific code taken first > to arch/um/sys-x86 and then (by final commit) to arch/x86/um. IMO that's > the right place for it - target-dependent code is better off not hidden > from maintainers of the target arch. When we get other ports to working > shape, their target-specific parts ought to go into arch/<target>/um. > * hopefully saner treatment of sigcontext; should make life easier > for other ports. > > [1] theoretically - in reality we still have more than a few x86-isms in > "generic" um headers in arch/um/include/asm. > Ok, will look at it in the next few days. "sys-{i386,x86_64} merged" sounds great!
On Mon, Aug 01, 2011 at 07:52:35PM +0200, richard -rw- weinberger wrote: > Ok, will look at it in the next few days. > "sys-{i386,x86_64} merged" sounds great! Update pushed; x86-specific stuff moved to arch/x86/um, more things merged/cleaned up. Works here, both for 32bit and 64bit builds... At least as well as the mainline one does, that is - there still are two very annoying issues, shared with mainline at least as far back as 2.6.36: * dancing close to OOM sometimes ends up with reserved pages showing up in pagetables. Code in mm/* is Not Happy(tm)... * tty-on-xterm sometimes crashes on the first keysyms reaching it; as far as I can tell, it's something related to SIGWINCH handling - whether it happens or not depends on the way xterm windows are laid out and flipping between them first seems to prevent that shit. If it hasn't happened at once, it won't happen at all... Something in drivers/chan or drivers/line, most likely... I can post the damn thing as patch series, but it's about 380Mb even with git format-patch -M and 78-posting mailbomb is a bit over the top anyway... -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 10, 2011 at 12:38:17AM +0100, Al Viro wrote: > * tty-on-xterm sometimes crashes on the first keysyms reaching it; > as far as I can tell, it's something related to SIGWINCH handling - whether > it happens or not depends on the way xterm windows are laid out and flipping > between them first seems to prevent that shit. If it hasn't happened at once, > it won't happen at all... Something in drivers/chan or drivers/line, most > likely... FWIW, what I'm seeing there is chan_interrupt() with tty that has definitely been kfree'd. What happens is that we have several opened files for given tty and they all get closed in parallel. Now, ->release() of tty calls ->close() of driver (line_close() in this case) and then gets around to decrementing tty->count. As the result, *all* callers of line_close() see line->tty->count > 1 and leave line->tty not reset to NULL. Oops... Moral: do not use the counters on upper layer objects unless you know what you are doing *and* know what will happen to that upper layer in years to come... -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> FWIW, what I'm seeing there is chan_interrupt() with tty that has definitely > been kfree'd. What happens is that we have several opened files for > given tty and they all get closed in parallel. Now, ->release() of > tty calls ->close() of driver (line_close() in this case) and then > gets around to decrementing tty->count. As the result, *all* callers > of line_close() see line->tty->count > 1 and leave line->tty not reset to > NULL. Oops... > > Moral: do not use the counters on upper layer objects unless you know > what you are doing *and* know what will happen to that upper layer in > years to come... Fixed and pushed (um-header.git #master); however, looking around that area shows more races ;-/ Incidentally, why the hell is ->chan_list a cyclic list? Holding at most two elements... Why not an array of two possibly NULL pointers? And what is chan->primary? Unless I'm seriously misreading that code, it's always 1; moreover, all instances of the method that gets ->primary value as argument ignore that argument completely... -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 10, 2011 at 06:44:32PM +0100, Al Viro wrote: > Fixed and pushed (um-header.git #master); however, looking around that area > shows more races ;-/ Such as, for example, seriously broken handling of free_winch(): delaying free_irq() until after return from IRQ handler is nice, but not enough - freeing struct winch itself (or winch->stack, for that matter) is also best left until after free_irq(). Normal way to do that is schedule_work()... Fixed and pushed... Folks, I don't know what to do with all that stuff; as far as I'm concerned the ideal variant would be to have functioning git tree maintained by Richard. Is that possible? I can ask to start pulling um-header.git into linux-next, but I would very much prefer to avoid that, TYVM... If nothing else, ACK/NAK on the stuff in there should be done by architecture maintainer(s). -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 11, 2011 at 6:23 AM, Al Viro <viro@zeniv.linux.org.uk> wrote: > On Wed, Aug 10, 2011 at 06:44:32PM +0100, Al Viro wrote: > >> Fixed and pushed (um-header.git #master); however, looking around that area >> shows more races ;-/ > > Such as, for example, seriously broken handling of free_winch(): delaying > free_irq() until after return from IRQ handler is nice, but not enough - > freeing struct winch itself (or winch->stack, for that matter) is also best > left until after free_irq(). Normal way to do that is schedule_work()... > Fixed and pushed... > > Folks, I don't know what to do with all that stuff; as far as I'm concerned > the ideal variant would be to have functioning git tree maintained by Richard. > Is that possible? I can ask to start pulling um-header.git into linux-next, > but I would very much prefer to avoid that, TYVM... If nothing else, ACK/NAK > on the stuff in there should be done by architecture maintainer(s). > Sorry for the delay. Writing my theses consumes a lot of my time... I've already started reviewing and testing your changes. Currently they life in my local git repo. But a git.kernel.org repo is on the way! Later I'll submit all changes to akpm.
On Thu, Aug 11, 2011 at 02:13:22PM +0200, richard -rw- weinberger wrote: > Sorry for the delay. > Writing my theses consumes a lot of my time... > > I've already started reviewing and testing your changes. > Currently they life in my local git repo. > But a git.kernel.org repo is on the way! > > Later I'll submit all changes to akpm. OK... It does end up in linux-next, so... OTOH, why not send direct pull requests to Linus? Speaking of more fun in there: * coredumps do not contain fp registers; fixable by switching to what x86 is doing (CORE_DUMP_USE_REGSET and corresponding bits in uml-x86 ptrace.c - arch/x86/um/ptrace*.c in this tree, arch/um/sys-*/ptrace.c in mainline) * more drivers/{lin,chan*}.c races ;-/ Protecting setup_one_line() from being done on opened ones is nice, but we are really not safe until parse_chan_pair() has been finished... I've partial fixes, but it's not quite trivial. * fixrange_init() assumes that start and end are both multiples of PMD_SIZE, which is not true, to put it mildly. Wraparounds are possible there - e.g. I've seen it called with 0xfffe000/0xffff000 for 32bit UML running on amd64 host. Not pretty, since vaddr < end will always remain true when called that way. With 3-level pagetables it gets really ugly - it's nowhere near the end of upper-level table yet, so i < PTRS_PER_PGD also doesn't stop the sucker. I think the right solution here is to shift vaddr down by PMD_SHIFT and do the same to end (taking care of fencepost errors, of course). * no biarch support; that one might be really painful to implement, but if we want it on something like ppc64 or sparc64 where the userland is routinely 32bit... That's going to be really rough on mm-switching variants, BTW - when kernel address space is 64bit one and userland ones are 32bit... <shudder> Anyway, I'm back to pure VFS work for the next few weeks. I'll probably dump fixrange_init() fixes into this tree, but anything beyond that will have to wait until I dig myself out of atomic_open work and unionfs/overlayfs/aufs/whatnot mess... -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile index b33f4df..78658a7 100644 --- a/arch/um/os-Linux/Makefile +++ b/arch/um/os-Linux/Makefile @@ -13,8 +13,6 @@ USER_OBJS := $(user-objs-y) aio.o elf_aux.o execvp.o file.o helper.o irq.o \ main.o mem.o process.o registers.o sigio.o signal.o start_up.o time.o \ tty.o tls.o uaccess.o umid.o util.o -CFLAGS_user_syms.o += -DSUBARCH_$(SUBARCH) - HAVE_AIO_ABI := $(shell [ -r /usr/include/linux/aio_abi.h ] && \ echo -DHAVE_AIO_ABI ) CFLAGS_aio.o += $(HAVE_AIO_ABI) diff --git a/arch/um/os-Linux/user_syms.c b/arch/um/os-Linux/user_syms.c index 45ffe46..9165513 100644 --- a/arch/um/os-Linux/user_syms.c +++ b/arch/um/os-Linux/user_syms.c @@ -45,7 +45,7 @@ EXPORT_SYMBOL(readdir64); extern void truncate64(void) __attribute__((weak)); EXPORT_SYMBOL(truncate64); -#ifdef SUBARCH_i386 +#ifdef __i386__ EXPORT_SYMBOL(vsyscall_ehdr); EXPORT_SYMBOL(vsyscall_end); #endif
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> --- arch/um/os-Linux/Makefile | 2 -- arch/um/os-Linux/user_syms.c | 2 +- 2 files changed, 1 insertions(+), 3 deletions(-)