linux-kernel - Re: [Regression][v3.17][v3.18] USB: Fix persist resume of some SS USB devices

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]

Date:	Wed, 5 Nov 2014 10:53:35 +0530
From:	Pratyush Anand <pratyush.anand@...com>
To:	Joseph Salisbury <joseph.salisbury@...onical.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	"pmladek@...e.cz" <pmladek@...e.cz>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	"peter.chen@...escale.com" <peter.chen@...escale.com>,
	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [Regression][v3.17][v3.18]   USB: Fix persist resume of some SS
 USB devices

Hello Joe,

On Wed, Nov 05, 2014 at 06:20:06AM +0800, Joseph Salisbury wrote:
> Hello Pratyush,
> 
> A kernel bug report was opened against Ubuntu [0].  After a kernel
> bisect, it was found that reverting the following commit resolved this bug:
> 
> commit a40178b2fa6ad87670fb1e5fa4024db00c149629
> Author: Pratyush Anand <pratyush.anand@...com>
> Date:   Fri Jul 18 12:37:10 2014 +0530
> 
>     USB: Fix persist resume of some SS USB devices
> 
> The regression was introduced as of v3.17-rc1.  The regression still
> exists in the 3.18-rc3 mainline kernel, and has made it's way into the
> stable kernels.

Its strange, as per my understanding patch does not introduce any side
effect for devices whose resume time is normal. So, if a device is
connected to the SS port and it was working after resume from
suspend to ram without this patch, then that device should still work
with this patch.

Infact this has resolved another bug reported to bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=53211


> 
> I was hoping to get your feedback, since you are the patch author.  Do
> you think gathering any additional data will help diagnose this issue,

Yaa, sure additional info will help to understand the issue.
-- dmesg log of suspend resume when this patch is not applied and also
when applied.
-- dmesg log with following additional debug print.
@@ -3318,6 +3318,7 @@ static int wait_for_ss_port_enable(struct usb_device *udev,
        int status = 0, delay_ms = 0;
         
        while (delay_ms < 2000) {
+               printk("%s:portstatus is %x and portchange is %x\n", __func__, *portstatus, *portchange);
               if (status || *portstatus & USB_PORT_STAT_CONNECTION)
                        break;

> or would it be best to submit a revert request?

Let me see what is the portstatus value and why didn't it break loop in first
iteration if device was OK.

Regards
Pratyush

>    
> 
> Thanks,
>    
> Joe
> 
> [0] http://pad.lv/1384041
--
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/