linux-kernel - Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway

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: <200707041221.04708.rjw@sisk.pl>
Date:	Wed, 4 Jul 2007 12:21:04 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	linux-pm@...ts.linux-foundation.org
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Robert Hancock <hancockr@...w.ca>,
	linux-kernel@...r.kernel.org,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway

On Wednesday, 4 July 2007 02:34, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 06:17:04PM -0600, Robert Hancock wrote:
> > Matthew Garrett wrote:
> > >Leave the process blocked and defer any i/o until after resume. Why does 
> > >it need to be any more complicated than that?
> > 
> > It gets complicated when this has to be added and TESTED in EVERY 
> > driver. The implied contract for drivers previously was that their 
> > device would not get accessed after it was suspended until it had been 
> > resumed first. This proposed change violates that.
> 
> No, that's only ever been true for ACPI systems.

Sorry, but you're mistaken.

Some ARM platforms also use the suspend code in kernel/power and the 52xx
powerpc too (BTW, I don't know of any ARM platforms that support suspend and
don't use it).

> It's never been true elsewhere, and it won't be true for anything
> implementing any sort of runtime power management.

There are not many drivers in the tree supporting that right now.

> > I don't think this sort of handling is something that individual drivers 
> > should have to deal with (at least not ones that are part of a framework 
> > like USB, libata, etc.)
> 
> I'd agree there. Driver midlayers (where they exist) are the appropriate 
> place to handle this.

So perhaps we should modify them first and we can drop the freezer?

Perhaps we can schedule the freezer removal (from the suspend code path), so
that people have the time to rework the driver midlayers to take that into
account?

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
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/