linux-kernel - Re: [linux-pm] Freezer: Don't count threads waiting for frozen filesystems.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1KvCN9-00081i-KF@pomaz-ex.szeredi.hu>
Date:	Wed, 29 Oct 2008 15:50:11 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	stern@...land.harvard.edu
CC:	miklos@...redi.hu, rjw@...k.pl, linux-kernel@...r.kernel.org,
	ncunningham@...a.org.au, linux-pm@...ts.linux-foundation.org
Subject: Re: [linux-pm] Freezer: Don't count threads waiting for frozen
 filesystems.

On Wed, 29 Oct 2008, Alan Stern wrote:
> On Wed, 29 Oct 2008, Miklos Szeredi wrote:
> 
> > Not all callbacks.  I don't know what the current model is but AFAIR
> > it should be something like this:
> > 
> >   1) call drivers to prepare for suspend (allocate space, etc)
> >   2) stop all driver activity (plug queues, disable interrupts, etc)
> >   3) call drivers to actually save state and power down
> >   4) suspend
> > 
> > The part we are concerned is stopping driver activity.  It could be
> > done with a mutex, or it could be done by freezing tasks.  Adding a
> > mutex or other mechanism is the one I most like, but it's probably the
> > biggest work, so lets look at how to fix the freezing:
> 
> Not only is adding a mutex the biggest amount of work, it has has the 
> largest impact.  Every I/O pathway would have to acquire the 
> appropriate mutex.  That's a significant additional load on the system.

Actually I was thinking of an rw-semaphore, not a mutex.  But yeah
that still has scalability problems.  But it could be done with custom
locking primitives, optimized for this case:

   suspend_disable();
   /* driver stuff */
   suspend_enable();

> The problem with unrestricted freezing shows up when you freeze tasks
> that hold a mutex or other sort of lock.  If this mutex is needed later
> on for suspending a device then the suspend will hang, because a frozen
> task can't release any mutexes.

I did a random sampling of ->suspend() callbacks, and they don't seem
to be taking mutexes.  Does that happen at all?

Did anybody ever try modifying the freezer for suspend (not
hibernate), so that it allows tasks not in running state to freeze?
If not, I think that's an experiment worth doing.

Miklos
--
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/