tty: avoid recursive BTM in pty_close
in [Kernel]
|
Prev: [PATCH 0/3} hwmon: Driver for SMM665 Six-Channel Active DC Output Controller/Monitor
Next: USB: gadget: g_multi: added documentation and INF files
From: Alan Cox on 18 Jun 2010 12:20 > I'd like to get Alan's opinion on whether he considers the change in > pty.c safe. I considered it a while ago when trying to work out removing the BKL from this path. After much head banging and an overwhelming desire to go and get drunk instead I concluded it wasn't possible to tell by analysis. So I ack this patch - it's the only way to find out 8) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Luck on 18 Jun 2010 13:00 On Fri, Jun 18, 2010 at 9:21 AM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > So I ack this patch - it's the only way to find out 8) Here's the results from this patch on top of next-20100618 The "WARNING: at include/linux/tty.h:589 tty_open+0x9d0/0xc60()" messages are back, two of them, both with same stack trace: Call Trace: [<a0000001000159d0>] show_stack+0x50/0xa0 [<a00000010090f270>] dump_stack+0x30/0x50 [<a00000010008e2c0>] warn_slowpath_common+0xc0/0x120 [<a00000010008e360>] warn_slowpath_null+0x40/0x60 [<a00000010053eb40>] tty_open+0x160/0xc60 [<a0000001001af9b0>] chrdev_open+0x310/0x360 [<a0000001001a58b0>] __dentry_open+0x350/0x680 [<a0000001001a5d80>] nameidata_to_filp+0x80/0xc0 [<a0000001001bfee0>] finish_open+0x160/0x380 [<a0000001001c0cc0>] do_last+0xbc0/0xce0 [<a0000001001c5270>] do_filp_open+0x2f0/0xb40 [<a0000001001a5290>] do_sys_open+0x90/0x200 [<a0000001001a54d0>] sys_open+0x50/0x80 [<a000000100b907e0>] kernel_init+0x340/0x420 [<a000000100013c10>] kernel_thread_helper+0x30/0x60 [<a00000010000a0c0>] start_kernel_thread+0x20/0x40 The tty_release() ones have all gone though. I've also just noticed that the serial console output gets garbled (like it is at the wrong baud rate) when userland code starts printing messages. Stays garbled until /sbin/agetty starts up to print the "Welcome ... login:" banner. Similar garbage when shutting down with "reboot" command. I can see "INIT", then it all goes to pieces until I see the kernel print "Restarting system". -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 18 Jun 2010 14:40 On Friday 18 June 2010, Tony Luck wrote: > On Fri, Jun 18, 2010 at 9:21 AM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > > So I ack this patch - it's the only way to find out 8) > > Here's the results from this patch on top of next-20100618 > > The "WARNING: at include/linux/tty.h:589 tty_open+0x9d0/0xc60()" messages > are back, two of them, both with same stack trace: > > > Call Trace: > [<a0000001000159d0>] show_stack+0x50/0xa0 > [<a00000010090f270>] dump_stack+0x30/0x50 > [<a00000010008e2c0>] warn_slowpath_common+0xc0/0x120 > [<a00000010008e360>] warn_slowpath_null+0x40/0x60 > [<a00000010053eb40>] tty_open+0x160/0xc60 > [<a0000001001af9b0>] chrdev_open+0x310/0x360 > [<a0000001001a58b0>] __dentry_open+0x350/0x680 > [<a0000001001a5d80>] nameidata_to_filp+0x80/0xc0 > [<a0000001001bfee0>] finish_open+0x160/0x380 > [<a0000001001c0cc0>] do_last+0xbc0/0xce0 > [<a0000001001c5270>] do_filp_open+0x2f0/0xb40 > [<a0000001001a5290>] do_sys_open+0x90/0x200 > [<a0000001001a54d0>] sys_open+0x50/0x80 > [<a000000100b907e0>] kernel_init+0x340/0x420 > [<a000000100013c10>] kernel_thread_helper+0x30/0x60 > [<a00000010000a0c0>] start_kernel_thread+0x20/0x40 Ok, this is the same one you reported at first. I forgot to mention that the other patch I sent as a reply to your report is still needed and not yet in -next since I'm trying to sort through the other BKL removal patches now. This instance of the WARN_ON is completely harmless though, you could consider this one a false positive. > The tty_release() ones have all gone though. ok, good. > I've also just noticed that the serial console output gets garbled > (like it is at the wrong baud rate) when userland code starts > printing messages. Stays garbled until /sbin/agetty starts up > to print the "Welcome ... login:" banner. > > Similar garbage when shutting down with "reboot" command. > I can see "INIT", then it all goes to pieces until I see the kernel > print "Restarting system". Do you know if this was a problem with the original series or something that got introduced by my last patch? Also, if you don't mind, could you try if the problem also exists with CONFIG_TTY_MUTEX enabled? Which serial driver do you use? I'll try to set up a serial console here to reproduce and bisect this problem on my own system. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Luck on 18 Jun 2010 16:30 On Fri, Jun 18, 2010 at 11:35 AM, Arnd Bergmann <arnd(a)arndb.de> wrote: > Ok, this is the same one you reported at first. I forgot to > mention that the other patch I sent as a reply to your report > is still needed and not yet in -next since I'm trying to > sort through the other BKL removal patches now. > This instance of the WARN_ON is completely harmless though, > you could consider this one a false positive. Ok. Adding your first patch into todays mix cleaned away these messages, > Do you know if this was a problem with the original series or > something that got introduced by my last patch? Problem was there before. Looks like it was not in next-20100616 but began with next-20100617. > Also, if you don't mind, could you try if the problem also exists > with CONFIG_TTY_MUTEX enabled? With CONFIG_TTY_MUTEX=y kernel with both your patches builds and boots with no unusual messages. Application output still gets garbled. > Which serial driver do you use? I boot with a "console=uart,io,0x3f8" argument, so I start out using 8250_early.c. Looks like it switched to 8250.c based on seeing this: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled on the console log. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 19 Jun 2010 08:40
On Friday 18 June 2010 22:25:22 Tony Luck wrote: > On Fri, Jun 18, 2010 at 11:35 AM, Arnd Bergmann <arnd(a)arndb.de> wrote: > > Do you know if this was a problem with the original series or > > something that got introduced by my last patch? > > Problem was there before. Looks like it was not in next-20100616 > but began with next-20100617. Ok, so it's certainly in one of the patches from Alan or me. > > Also, if you don't mind, could you try if the problem also exists > > with CONFIG_TTY_MUTEX enabled? > With CONFIG_TTY_MUTEX=y kernel with both your patches builds > and boots with no unusual messages. Application output still gets > garbled. ok. > > Which serial driver do you use? > I boot with a "console=uart,io,0x3f8" argument, so I start out using > 8250_early.c. Looks like it switched to 8250.c based on seeing > this: > > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > > on the console log. Good, so it's something I should be able to reproduce on a PC. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |