From: Peter Zijlstra <peterz@infradead.org>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
Cc: TKLEIN@de.ibm.com, Jan-Bernd Themann <THEMANN@de.ibm.com>,
Mel Gorman <mel@csn.ul.ie>, netdev <netdev@vger.kernel.org>,
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
linuxppc-dev@ozlabs.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [Powerpc / eHEA] Circular dependency with 2.6.29-rc6
Date: Wed, 25 Feb 2009 16:50:13 +0100 [thread overview]
Message-ID: <1235577013.4645.3548.camel@laptop> (raw)
In-Reply-To: <49A55E54.4080304@de.ibm.com>
On Wed, 2009-02-25 at 16:05 +0100, Jan-Bernd Themann wrote:
> - When "open" is called for a registered network device, port->port_lock
> is taken first,
> then ehea_fw_handles.lock
> - When "open" is left these locks are released in a proper way (inverse
> order)
So this has:
port->port_lock
ehea_fw_handles.lock
This would be the case that is generating the warning.
> - In addition: ehea_fw_handles.lock is held by the function
> "driver_probe_device"
> that registers all available network devices (register_netdev)
> - When multiple network devices are registered, it is possible that
> "open" is
> called on an already registered network device while further
> netdevices are still registered
> in "driver_probe_device". ---> "open" will take port->port_lock, but
> won't get ehea_fw_handles.lock
Right, so here you have
ehea_fw_handles.lock
port->port_lock
Overlay these two cases and you have AB-BA deadlocks.
> - However, ehea_fw_handles.lock is freed once all netdevices are registered.
> - When the second netdevice is registered in "driver_probe_device", it
> will also try to get
> the port->port_lock (which in fact is a different one, as there is one
> per netdevice).
> - Does the mutex debug mechanism distinguish between the different
> port->port_lock instances?
Not unless you tell it to.
Are you really sure the port->port_lock in this AB-BA scenario are never
the same? The above explanation didn't convince me (also very hard to
read due to funny wrapping).
Suppose you do an open concurrently with a re-probe, which apparently
takes port->port_lock's of existing devices, in the above scenario that
deadlocks.
next prev parent reply other threads:[~2009-02-25 15:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 8:47 [Powerpc / eHEA] Circular dependency with 2.6.29-rc6 Sachin P. Sant
2009-02-23 8:47 ` Sachin P. Sant
2009-02-25 15:05 ` Jan-Bernd Themann
2009-02-25 15:05 ` Jan-Bernd Themann
2009-02-25 15:50 ` Peter Zijlstra [this message]
2009-02-25 17:07 ` Jan-Bernd Themann
2009-02-25 18:24 ` Peter Zijlstra
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=1235577013.4645.3548.camel@laptop \
--to=peterz@infradead.org \
--cc=THEMANN@de.ibm.com \
--cc=TKLEIN@de.ibm.com \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=ossthema@de.ibm.com \
/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.