Re: [PATCH] w1: Introduce a slave mutex for serializing IO.

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]