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] [day] [month] [year] [list]
Message-ID: <4A76F8A1.3020000@windriver.com>
Date:	Mon, 03 Aug 2009 09:48:01 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	gregkh@...e.de, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, dbrownell@...rs.sourceforge.net,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Yinghai Lu <yinghai@...nel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH 07/10] ehci-dbgp,ehci: Allow early or late use of the
 dbgp device

Alan Stern wrote:
> On Fri, 31 Jul 2009, Jason Wessel wrote:
>
>   
>> Alan Stern wrote:
>>     
>>> What happens across a system suspend?
>>>
>>>   
>>>       
>> I assume you mean as a test case:
>>
>> echo -n mem > /sys/power/state
>>
>> The dbgp device goes away entirely, when used with
>> earlyprintk=dbgp,keep.  But there is a way to fix it reasonably
>> easily.  Perhaps you might ack this resume patch, if you agree?
>>
>> Jason.
>>
>> ---
>> From: Jason Wessel <jason.wessel@...driver.com>
>> Subject: [PATCH] ehci-dbgp,ehci: Allow dbpg to work with suspend/resume
>>
>> In order for the dbgp driver to survive suspend/resume, on every ehci
>> resume operation the debug controller must get re-initialized.
>>
>> Signed-off-by: Jason Wessel <jason.wessel@...driver.com>
>> Cc: Greg KH <gregkh@...e.de>
>> Cc: Alan Stern <stern@...land.harvard.edu>
>> Cc: dbrownell@...rs.sourceforge.net
>> Cc: Ingo Molnar <mingo@...e.hu>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: Yinghai Lu <yinghai@...nel.org>
>> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>
>>
>> ---
>>  drivers/usb/host/ehci-hub.c |    6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> --- a/drivers/usb/host/ehci-hub.c
>> +++ b/drivers/usb/host/ehci-hub.c
>> @@ -204,6 +204,13 @@ static int ehci_bus_resume (struct usb_h
>>  		return -ESHUTDOWN;
>>  	}
>>  
>> +	if (unlikely(ehci->debug)) {
>> +		if (ehci->debug && !dbgp_reset_prep())
>> +			ehci->debug = NULL;
>> +		else
>> +			dbgp_external_startup();
>> +	}
>> +
>>  	/* Ideally and we've got a real resume here, and no port's power
>>  	 * was lost.  (For PCI, that means Vaux was maintained.)  But we
>>  	 * could instead be restoring a swsusp snapshot -- so that BIOS was
>>     
>
> It looks fine to me.  Would you perhaps want to make dbgp_reset_prep()
> automatically call dbgp_external_startup() on success so that ehci-hcd
> doesn't have to?
>   

Unfortunately the dbgp_reset_prep() and dbgp_external_startup() have to
be separate for the hcd case because the ehci controller reset comes in
between.  If you don't call dbgp_reset_prep() first, the ehci controller
can hang the system for the "ehci debug controller timeout death
period", or you can end up with undefined behavior if the ehci debug
controller is accessed while the reset code is being processed.

The dbgp_reset_prep() puts the ehci debug controller/driver into a safe
state until after the reset is done, and then the
dbgp_external_startup() re-initializes the ehci debug controller.

For the case of the power suspend, the ehci debug controller appeared to
be usable all the way to the time the power got yanked.  For the resume
operation, the debug controller driver sees that from the resume state
that the enable bit is off and doesn't try to use the device until
dbgp_reset_prep() and dbgp_external_reset() are called in sequence.

The dbgp_reset_prep() has to get called in resume to handle the case
where you remove the dbgp device while suspended and before you resumed
such that it won't hang the kernel.

Jason.
--
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