Re: [PATCH RFD] alternative kobject release wait mechanism

Tejun Heo wrote:
Incidentally, Tejun, I'm all in favor of a immediate-detach driver model
approach. Unfortunately it's impossible to realize fully, although we
could come much closer than we are now.

Here's an example where immediate-detach cannot be implemented. A driver
binds to a device and uses that device is a kernel thread. The thread
carries out certain operations which require it to hold the device
semaphore (because, for example, they need to be mutually exclusive with
unbind).

The driver's remove() method is called with the semaphore held. If the
thread tries to lock the semaphore at the same time and blocks, there is
no way at all for the remove() method to force the thread to drop its
reference.

This isn't merely a theoretical example. The USB hub driver works in
exactly this way.

Dunno if I understood the problem right but can't we do the following?

remove()
{
acquire sem;
device_del();
release sem;
device_put_wait();
}

More afterthoughts. If a mutex is used to protect access against
removal. There is no reason to hold reference to it.

kernel_thread()
{
/* wanna dereference my_obj */
mutex_lock();
verify my_obj is there and use it if so.
mutex_unlock();
}

remove()
{
mutex_lock();
kill_it();
mutex_unlock();
}

I probably have over simplified it but using both mutex and reference
counts doesn't make much sense. IOW, you get an active reference when
you grab the mutex excluding its removal and verified it's still there.

There probably are other reasons why things are done that way and we can
and probably will have to resort to mixed solutions in foreseeable
future but I don't think there is any inherent problem in applying
immediate-disconnect in the described situation.

Feel free to scream at me if I'm getting it totally wrong. :-)

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

  • Unexpected release of named mutex
    ... I have a mutex that releases while I am still holding a reference to ... Dim singleInstance As Threading.Mutex = Nothing ... Application.ProductName & ".SingleInstance", goodToGo) ... Silly me, thinking that I could keep a reference to an object by, uh, ...
    (microsoft.public.dotnet.framework)
  • Re: [PATCH RFD] alternative kobject release wait mechanism
    ... There is no reason to hold reference to it. ... you grab the mutex excluding its removal and verified it's still there. ... It also wakes up all threads that are blocked trying to lock the ...
    (Linux-Kernel)
  • Re: WaitForSingleObject() will not deadlock
    ... You keep talking about needing to know the reference count. ... algorithm that uses a recursive mutex that cares in the slightest what the reference count ... attempts to lock appears to be isomorphic to a recursive lock, ... cycle detection until you reach the end of the list, ...
    (microsoft.public.vc.mfc)
  • Re: Library design for canceling a running operation?
    ... The main part of the public api is very similar to normal file I/O: ... cancel a running operation. ... thread that's performing the operation has a reference. ... The operation object contains a mutex, condition variable, and any ...
    (comp.programming.threads)
  • Re: [PATCH] sysfs: kill an extra put in sysfs_create_link() failure path
    ... Tejun Heo wrote: ... [It's weird to grab a reference on the target ... for ourselves (and in fact even allocate the new dirent for the ...
    (Linux-Kernel)