All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <zbr@ioremap.net>
To: NeilBrown <neilb@suse.de>
Cc: linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] w1: Introduce a slave mutex for serializing IO.
Date: Thu, 3 May 2012 21:58:57 +0400	[thread overview]
Message-ID: <20120503175857.GA13988@ioremap.net> (raw)
In-Reply-To: <20120502162627.50544c8b@notabene.brown>

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.

-- 
	Evgeniy Polyakov

  reply	other threads:[~2012-05-03 17:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-25  2:49 [PATCH] w1: Introduce a slave mutex for serializing IO NeilBrown
2012-05-01 21:39 ` Evgeniy Polyakov
2012-05-02  6:26   ` NeilBrown
2012-05-03 17:58     ` Evgeniy Polyakov [this message]
2012-05-03 21:08       ` NeilBrown
2012-05-03 21:27         ` Evgeniy Polyakov
2012-05-09  1:43           ` NeilBrown
2012-05-15  1:26             ` Evgeniy Polyakov
2012-05-18  6:05               ` NeilBrown
2012-06-10 20:58                 ` Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120503175857.GA13988@ioremap.net \
    --to=zbr@ioremap.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.