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]
Date:	Wed, 29 Oct 2008 17:10:27 +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:
> 
> > 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();
> 
> Yes, it could be done.  And the overhead could be minimized by using
> per-CPU variables.  It would still be an awful lot of work, and easy to
> get wrong.

OK, getting back to this, as it seems to be the only way that we agree
is doable.

How about this,

 a) identify syscalls that may make drivers do I/O:

 - read
 - write
 - ioctl
 ???

 b) add the suspend_disable/enable() primitives to these syscalls

 c) push primitives inside the implementation

c) is slightly tricky, but could be done for example by setting a flag
on open: FMODE_NO_SUSPEND_DISABLE (better name required), saying that
implementation is responsible for getting the suspend disable magic
right.

For starters this flag could be set for all non-device opens (maybe all
non-char-dev opens?), solving the fuse vs. freezer issues without any
complicated trickery.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ