linux-kernel - Re: linux-next crash in xhci_add_ep_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPcyv4gYnvF4Nt5itkDsD=DzL8sfETZUBmQqZwiHE1SOZvtsbw@mail.gmail.com>
Date:	Thu, 5 Jun 2014 09:35:48 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Valdis.Kletnieks@...edu
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>
Subject: Re: linux-next crash in xhci_add_ep_to_interval

On Thu, Jun 5, 2014 at 9:24 AM,  <Valdis.Kletnieks@...edu> wrote:
> On Thu, 05 Jun 2014 08:55:07 -0700, Dan Williams said:
>
>> > On a working boot, it progresses:
>>
>> Is a working boot after reverting that change, or it intermittently
>> works?  If it's the latter I'm not sure I trust the bisect result,
>> yet.
>
> Oh, it's a 100% guaranteed crash.  The following is from a good kernel:
>
>> > [    3.823139] usb 3-4.1: New USB device found, idVendor=0e8f, idProduct=0020
>> > [    3.823160] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>> > [    3.823174] usb 3-4.1: Product: PS2toUSB Adapter
>> > [    3.823187] usb 3-4.1: Manufacturer: GASIA
>> > [    3.842836] input: GASIA PS2toUSB Adapter as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.1/3-4.1:1.0/0003:0E8F:0020.0001/input/input14
>> > [    3.848598] hid-generic 0003:0E8F:0020.0001: input,hidraw0: USB HID v1.10 Keyboard [GASIA PS2toUSB Adapter] on usb-0000:00:14.0-4.1/input0
>> > [    3.863592] input: GASIA PS2toUSB Adapter as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.1/3-4.1:1.1/0003:0E8F:0020.0002/input/input15
>> > [    3.878608] hid-generic 0003:0E8F:0020.0002: input,hidraw1: USB HID v1.10 Mouse [GASIA PS2toUSB Adapter] on usb-0000:00:14.0-4.1/input1
>
> I'm booted on next-20140519
>
>
>> It's a really odd place to crash relative to the peer port changes
>> since those do not affect any xhci internals.  At first glance this
>> also does not look related to the command queue changes.  Mathias, any
>> ideas?
>>
>> Valdis, can you get me the output of:
>>
>> $ gdb drivers/usb/host/xhci-hcd.ko
>> (gdb) li *(xhci_add_ep_to_interval_table+0xc8)
>
> (gdb) li *(xhci_add_ep_to_interval_table+0xc8)
> 0x10c9 is in xhci_add_ep_to_interval_table (drivers/usb/host/xhci.c:2446).
> 2441                    normalized_interval = ep_bw->ep_interval - 3;
> 2442
> 2443            if (normalized_interval == 0)
> 2444                    bw_table->interval0_esit_payload += ep_bw->max_esit_payload;
> 2445            interval_bw = &bw_table->interval_bw[normalized_interval];
> 2446            interval_bw->num_packets += ep_bw->num_packets;
> 2447            switch (udev->speed) {
> 2448            case USB_SPEED_LOW:
> 2449                    interval_bw->overhead[LS_OVERHEAD_TYPE] += 1;
> 2450                    break;
>
> Note that's as of the end of the git bisect.  Looks like it picked up
> a duff value for interval_bw somehow, but I have no idea why.
>
> Yeah, you're right, the bisected commit doesn't seem to have anything
> to do with it.  Weird. ;)

Actually, on second look I bet xhci_alloc_tt_info() is being called
while hdev->maxchild is not set.  Let me throw together a debug
patch...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/