Re: [PATCH RFD] alternative kobject release wait mechanism

Hello, Alan.

Alan Stern wrote:
This doesn't solve a related problem: a subsystem wants to register
devices and to provide a set of mutually-exclusive services to the
devices' drivers. The mutual exclusion has to be provided by a mutex or
something similar, and the drivers need a way to unbind even while waiting
to acquire the mutex.

I don't really follow why the drivers need a way to unbind even while
waiting to acquire the mutex. Care to enlighten me?

The obvious answer is to introduce a different sort of synchronization
primitive: a mutex (or semaphore or rwsem) which can be invalidated.

The semantics would be straightforward. When mutex_invalidate() is
called, it marks the mutex so that all future lock attempts will fail with
-ENODEV. It also wakes up all threads that are blocked trying to lock the
mutex and causes them to fail with the same error. Once all that is done
mutex_invalidate() returns. In particular, it doesn't wait for the
current lock to be released -- in fact, you would call it while holding
the lock.

This would solve a lot of your problems. But it would also mean making
extensive changes to the kernel. For one thing, mutex_lock() would return
int instead of void, and you would want to mark it __must_check. Every
place where a mutex is locked, the code would have to be changed to add an
error pathway. That's the sort of thing I was talking about when I said
it was going to be a tremendous job.

I think we both agree that's not a good idea. :-)

I thought of something else that could also be done: There should be a way
to cancel an outstanding workqueue request. At the moment all you can do
is call flush_workqueue(), which will hang if you are already executing in
a workqueue routine. You should be able to delete a particular entry from
the workqueue (or wait for it to complete if it has already started
running). This could be implemented right away.

It all depends on how a particular subsystem is shaped but having such
thing would definitely help.

More problems with immediate detach -- it would have to apply to char
devices. When a char device is unregistered you can't force user
processes to close their open file handles. Instead something like your
change to sysfs is needed -- wait for outstanding calls to complete and
fail any future calls. This means that registering a device will use up
more than just a pointer in a table of minor device numbers. Each entry
would require at least an rwsem, and device I/O would be slowed down by
the need to get a read-lock each time before entering the device driver.

The same idea applies to block devices, although here the problems center
more around the block core and request queues.

Yeah, exactly. My argument is that that impedance matching between
lifetime rules must happen at some place and it's better if we can do in
the higher layer where we can afford more effort and thus complexity.
We're currently pushing that down to each drivers and not too many are
getting it right. I think it's just unrealistic to expect every and
each driver subsystems to get it right, so some overhead at higher layer
is acceptable and we can definitely afford much more optimization at
higher layer.

Thanks.

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

Relevant Pages

  • Re: msleep() on recursivly locked mutexes
    ... Further the idea that holding a mutex "except for when we sleep" is a ... This is basically when I need to exit mutexes. ... I agree with the other comment that all drivers should be multi-thread ... lock a mutex again. ...
    (freebsd-hackers)
  • Re: msleep() on recursivly locked mutexes
    ... I agree with the other comment that all drivers should be multi-thread ... after that you lock a mutex. ... of a macro level than micro level, then you probably want a condvar ... or possibly a rwlock. ...
    (freebsd-hackers)
  • Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
    ... a requirement for STR is that all drivers do runtime PM. ... carrying out an actual suspend requires a ... delay. ... other task won't be able to run and release the mutex, ...
    (Linux-Kernel)
  • Re: [patch 5/6] Convert to use mutexes instead of semaphores
    ... Apparently I missed that several drivers also use bd->sem so they need ... mutex as well). ... I never did find out what it was trying to protect ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
    (Linux-Kernel)
  • Re: Recursive mutex that can be waited upon (pthread)
    ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
    (comp.programming.threads)