On Wed, 29 Oct 2008, Miklos Szeredi wrote:

quoted text
> 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

I discussed this last summer with Rafael.  It's a lot harder than it 
looks, for all sorts of reasons.  For example, what about user tasks 
that have access to memory-mapped I/O regions?

quoted text
> 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.

I don't know.  There are other interfaces too, like sysfs attributes, 
that would have to be handled specially.  On the whole, the freezer 
seems much, much simpler.

Regarding fuse, something like Nigel's scheme for preventing new 
requests and then waiting for old requests to complete might work out.  
Especially if you combine it with a strategy for making the freezer 
back and retry after a delay when something goes wrong.

Alan Stern

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/