netdev - Re: 2.6.29-rc3: tg3 dead after resume

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:	Sun, 1 Feb 2009 01:41:29 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Parag Warudkar <parag.lkml@...il.com>,
	Matt Carlson <mcarlson@...adcom.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: 2.6.29-rc3: tg3 dead after resume

On Sunday 01 February 2009, Linus Torvalds wrote:
> 
> On Sun, 1 Feb 2009, Rafael J. Wysocki wrote:
> > > The problems happen on purely the suspend path. How the f*ck do you know 
> > > that the drivers behind the bridge don't do everything at 'suspend_late' 
> > > time, and expect to be working up until that time?
> > 
> > DMA from suspend_late?  Come on.
> 
> Rafael. Stop being a total idiot.
> 
> Read what I wrote.
> 
> I'm saying that the driver may not do anything at all at suspend() time, 
> and leaves everything until suspend_late. Then, at suspend_late(), it 
> finally really shuts down.
> 
> That's actually a very reasonable thing to do in some circumstances. It 
> simplifies everything, in particular all interrupt handling, since the 
> device is now fully live all the way while interrupts can happen.
> 
> For a USB host controller, for example, it really could make sense to do 
> that - just leave all the core host controller stuff running, and the only 
> thing the "suspend()" callback does is to send the commands to the actual 
> devices, it doesn't necessarily touch the host controller itself at all.
> 
> Then, at suspend_late time, you just clear the "running" bit in the 
> controller (and perhaps not even that - because you want to still push 
> things out for debugging). End result: you never actually had to shut 
> anything down at all, and you could (for example) still run a USB serial 
> port console all the way to shutdown.
> 
> And yes, I wanted to do basically exactly that when I was debugging some 
> issues a year or two ago.
> 
> See? The device and driver may be totally alive over a ->suspend() call. 
> And that means that the bridge CANNOT KNOW that it's ok to shut down DMA. 
> Because DMA may be the only way the device communicates (again: USB 
> actually works that way).
> 
> So dammit, just admit that you were wrong,

I said I was.

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