Messages in this thread |  | | | Date | Fri, 4 May 2012 07:08:38 +1000 | | From | NeilBrown <> | | Subject | Re: [PATCH] w1: Introduce a slave mutex for serializing IO. |
| |
On Thu, 3 May 2012 21:58:57 +0400 Evgeniy Polyakov <zbr@ioremap.net> wrote:
> On Wed, May 02, 2012 at 04:26:27PM +1000, NeilBrown (neilb@suse.de) wrote: > > Take takes me back to the deadlock. > > To be precise: > > while scanning the w1 bus - with master->mutex held - w1_attach_slave_device > > eventually calls into bq27000_battery_probe which calls > > power_supply_register -> device_add -> kobject_uevent_env > > > > and the to get all the data for the uevent, power_supply_uevent calls > > the get_property callback which tries to read from the w1 bus and so > > needs the master->mutex. Which is held. Deadlock. > > > > So options seems to be: > > - drop the lock while attaching slave devices > > - create a list of slave devices, then attach them after the bus scan has > > finished. > > - have device_add run the kobject_uevent in a separate task (work_queue) > > - or maybe the following which feels ugly but is easy. Mark the bq27000 as > > not ready until after the power_supply_register, and if get_property is > > called before the device is ready, return ENODATA. > > Simple and works. Maybe horrible. > > power_supply_register will have scheduled a power_supply_changed() which > > will poll > > You can check mutex owner - and if it is you who holds it, then dig into > low-level function without lock. >
Interesting idea. However:
struct mutex { /* 1: unlocked, 0: locked, negative: locked, possible waiters */ atomic_t count; spinlock_t wait_lock; struct list_head wait_list; #if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_SMP) struct task_struct *owner; #endif
You can only check the owner on SMP builds, or when debugging is enabled. So I don't think that approach can work.
Thanks, NeilBrown [unhandled content-type:application/pgp-signature] |  |