diff mbox

tty_register_device NULL pointer dereference in 2.6.31-rc4

Message ID 20090731093949.GA4867@darkstar
State Superseded, archived
Delegated to: David Miller
Headers show

Commit Message

Dave Young July 31, 2009, 9:39 a.m. UTC
On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
> Dave Young wrote:
> > On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@hartkopp.net> wrote:
> >> Hi Dave,
> >>
> >> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
> >> attached screenshot).
> > 
> > Weird, the oops occurs between sock init and tty init routines. Could
> > you tell your bluez version and your configuration?
> > 
> 
> No problem:

Thanks.

It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.

Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Dave Young July 31, 2009, 10:10 a.m. UTC | #1
On Fri, Jul 31, 2009 at 5:39 PM, Dave Young<hidave.darkstar@gmail.com> wrote:
> On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
>> Dave Young wrote:
>> > On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@hartkopp.net> wrote:
>> >> Hi Dave,
>> >>
>> >> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
>> >> attached screenshot).
>> >
>> > Weird, the oops occurs between sock init and tty init routines. Could
>> > you tell your bluez version and your configuration?
>> >
>>
>> No problem:
>
> Thanks.
>
> It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
>
> Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
>
> --- linux-2.6.orig/net/bluetooth/rfcomm/core.c  2009-07-31 17:14:07.000000000 +0800
> +++ linux-2.6/net/bluetooth/rfcomm/core.c       2009-07-31 17:30:39.000000000 +0800
> @@ -36,6 +36,7 @@
>  #include <linux/net.h>
>  #include <linux/mutex.h>
>  #include <linux/kthread.h>
> +#include <linux/nmi.h>
>
>  #include <net/sock.h>
>  #include <asm/uaccess.h>
> @@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
>  /* ---- Initialization ---- */
>  static int __init rfcomm_init(void)
>  {
> -       int ret;
> +       int ret, i;
>
>        l2cap_load();
>
> @@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
>        if (ret)
>                goto out_sock;
>
> +       /* delay 5 seconds to trigger the tty bug */
> +       for (i = 0; i < 50; i++) {
> +               touch_nmi_watchdog();
> +               mdelay(100);

Hi, for this case, msleep is better, you can just replace the above
two lines with msleep(100)

> +       }
> +
>        ret = rfcomm_init_ttys();
>        if (ret)
>                goto out_tty;
>
Oliver Hartkopp July 31, 2009, 11:20 a.m. UTC | #2
Dave Young wrote:
> On Fri, Jul 31, 2009 at 5:39 PM, Dave Young<hidave.darkstar@gmail.com> wrote:
>> On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
>>> Dave Young wrote:
>>>> On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@hartkopp.net> wrote:
>>>>> Hi Dave,
>>>>>
>>>>> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
>>>>> attached screenshot).
>>>> Weird, the oops occurs between sock init and tty init routines. Could
>>>> you tell your bluez version and your configuration?
>>>>
>>> No problem:
>> Thanks.
>>
>> It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
>>
>> Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
>>
>> --- linux-2.6.orig/net/bluetooth/rfcomm/core.c  2009-07-31 17:14:07.000000000 +0800
>> +++ linux-2.6/net/bluetooth/rfcomm/core.c       2009-07-31 17:30:39.000000000 +0800
>> @@ -36,6 +36,7 @@
>>  #include <linux/net.h>
>>  #include <linux/mutex.h>
>>  #include <linux/kthread.h>
>> +#include <linux/nmi.h>
>>
>>  #include <net/sock.h>
>>  #include <asm/uaccess.h>
>> @@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
>>  /* ---- Initialization ---- */
>>  static int __init rfcomm_init(void)
>>  {
>> -       int ret;
>> +       int ret, i;
>>
>>        l2cap_load();
>>
>> @@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
>>        if (ret)
>>                goto out_sock;
>>
>> +       /* delay 5 seconds to trigger the tty bug */
>> +       for (i = 0; i < 50; i++) {
>> +               touch_nmi_watchdog();
>> +               mdelay(100);
> 
> Hi, for this case, msleep is better, you can just replace the above
> two lines with msleep(100)
> 

Hi Dave,

applied this patch and replaced mdelay(100) with msleep(100).

I got two crashes and three proper boots.

The crashes look like the formerly posted screenshots.
When it boots properly i can see the delay in the boot process.

Does this help?

Regards,
Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- linux-2.6.orig/net/bluetooth/rfcomm/core.c	2009-07-31 17:14:07.000000000 +0800
+++ linux-2.6/net/bluetooth/rfcomm/core.c	2009-07-31 17:30:39.000000000 +0800
@@ -36,6 +36,7 @@ 
 #include <linux/net.h>
 #include <linux/mutex.h>
 #include <linux/kthread.h>
+#include <linux/nmi.h>
 
 #include <net/sock.h>
 #include <asm/uaccess.h>
@@ -2080,7 +2081,7 @@  static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
 /* ---- Initialization ---- */
 static int __init rfcomm_init(void)
 {
-	int ret;
+	int ret, i;
 
 	l2cap_load();
 
@@ -2088,6 +2089,12 @@  static int __init rfcomm_init(void)
 	if (ret)
 		goto out_sock;
 
+	/* delay 5 seconds to trigger the tty bug */
+	for (i = 0; i < 50; i++) {
+		touch_nmi_watchdog();
+		mdelay(100);
+	}
+
 	ret = rfcomm_init_ttys();
 	if (ret)
 		goto out_tty;