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: <20140108041620.GA9618@kroah.com>
Date:	Tue, 7 Jan 2014 20:16:20 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	"Tang, Jianqiang" <jianqiang.tang@...el.com>
Cc:	David Cohen <david.a.cohen@...ux.intel.com>,
	"stern@...land.harvard.edu" <stern@...land.harvard.edu>,
	"sarah.a.sharp@...ux.intel.com" <sarah.a.sharp@...ux.intel.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC/PATCH] usb/xhci: avoid kernel panic on xhci_suspend()


A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Jan 08, 2014 at 03:49:07AM +0000, Tang, Jianqiang wrote:
> Hi,
>  1) I met this issue one time just boot up our Linux Platform(Kernel3.10) with XHCI driver, then kernel panic happen.
> 
>    And this issue reported once by other internal team.
> 
>    Nothing special of reproduce step and do not need special Hardware I think.
> 
>    Just random issue which will happen when meet the timing condition.
> 
>  2) This issue is introduced by this patch:
> 
>      https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=596d789a211d134dc5f94d1e5957248c204ef850
> 
>    which set all hub autosuspend delay to 0.

That patch was released in a kernel almost a full year ago, yet we have
never had a report of this happening before, so are you sure this patch
is the root cause?

>    This causes race condition during XHCI driver initialization,
> 
>     After USB2 hcd and USB2 root hub finish the initialization, USB2 root hub is functional and auto suspend right now, hence trigger XHCI runtime suspend flow;
> 
>     At the same time, XHCI driver continue to initialize the USB3 hcd and assign to xhci->shared_hcd after finish the initialization;
>     
>     Since xhci_suspend() use the xhci->shared_hcd, so there is race condition that when XHCI runtime suspend called, xhci->shared_hcd still NULL.
> 
>     I think this patch is a fix solution since before XHCI finish the whole initialization, USB2 root hub triggered runtime suspend is mean less and do not need to handle.

With this patch applied, does the crash go away?

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ