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:	Mon, 28 May 2007 09:53:50 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Pavel Machek <pavel@....cz>
cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Romano Giannetti <romanol@...omillas.es>,
	Chris Wright <chrisw@...s-sol.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	stable@...nel.org, Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	"Theodore Ts'o" <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	Chris Wedgwood <reviews@...cw.f00f.org>,
	Michael Krufky <mkrufky@...uxtv.org>,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review



On Mon, 28 May 2007, Pavel Machek wrote:
> 
> I guess we should warn the driver authors, then; and decide what driver 
> authors should do.

Drivers really shouldn't do anythign at all.

> If I'm video4linux driver for grabbing screen, have been suspended, and 
> someone asks me to read a frame, should I
> 
> a) return -ESORRYIMSUSPENDED
> 
> b) just block the caller

The "subsystem" thing should have stopped the queues, and the device 
should never even _see_ this.

Before we suspend a device, we call the subsystem that that device has 
been registered with. Ie, we have code like this:

	if (dev->class && dev->class->suspend)
		error = dev->class->suspend(dev, state);

which was very much designed so that individual devices wouldn't have to 
always know - if the upper layer devices for that class can handle these 
things, they should.

Do people actually _do_ this, right now? No. But we do actually have the 
infrastructure, and I think we have one or two classes that actually do 
use it (at least the "rfkill_class" has a suspend member, dunno how well 
this model actually works).

I think Greg had some patches to make network drivers use this, for 
example. Network drivers right now all end up doing stuff that really 
doesn't belong in the driver at all when they suspend, and the 
infrastructure _should_ just do it for them (ie do all the _network_ 
related stuff, as opposed to the actual hardware-related stuff).

(Examples of things that we probably _should_ do for network devices on a 
class level:

	suspend:
		netif_poll_disable()
		if (netif_running(dev))
			dev->stop(dev);

	resume:
		if (netif_running(dev))
			dev->start(dev);
		netif_poll_enable(dev);

or something similar).

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