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)
  • [BUG] drivers/video/sis: deadlock introduced by "fbdev: add mutex for fb_mmap locking"
    ... The kernel stopped at(output via serial port): ... Add a mutex to avoid a circular locking problem between the mm layer ... # Device Drivers ...
    (Linux-Kernel)
  • Re: [PATCH] kdesu broken
    ... No, bz 13841 isn't about pty's, it's about usb serial. ... it should call drv->closewithin the mutex on the error path if the ... tty_block_til_readyfails without which you get a leak on a few drivers ... Most serial drivers don't try and do open clean up in openinstead they ...
    (Linux-Kernel)
  • Re: [BUG] cdev_put() race condition
    ... cdev, then the spinlock has to be replaced by a mutex. ... Note that if we ever allow drivers to hook in their own release callback, ... So why is V4L different than the rest of the kernel in that it wishes to ...
    (Linux-Kernel)
  • =?UTF-8?q?Re:_Re:_matroxfb:_fix_regression_with_uninitalized_fb=5Finfo->mm=5Flock_mutex_(sec
    ... Remove redundant locking by the mm_lock mutex before a second head of ... The mm_lock mutex is used only inside the fb_mmapfunction and driver's specific code. ... All other drivers just have, let's say, inefficient code - calling a function which is called just ... The mm_lock patch converted this inefficient code into broken code. ...
    (Linux-Kernel)