On Sat, 12 Jan 2008, Jay Vosburgh wrote:
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
[...]
Exactly. All I need to do is to reboot my server, I have 100% probability
to get the warning.
I wish it were that easy for me; I'm not sure what magic thing
you've got on your server or
On Wed, 9 Jan 2008, Andy Gospodarek wrote:
On Wed, Jan 09, 2008 at 09:54:56AM -0800, Jay Vosburgh wrote:
CUT
This should silence the lockdep (if I'm understanding what
everybody's saying), and keep the change set to a minimum. This might
The lockdep problem is easy to trigger.
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
[...]
Exactly. All I need to do is to reboot my server, I have 100% probability
to get the warning.
I wish it were that easy for me; I'm not sure what magic thing
you've got on your server or network that I don't, but I haven't been
able to make
Jay Vosburgh [EMAIL PROTECTED] wrote:
Can you test the following and let me know if it triggers the
warning? I believe this is the minimum locking needed, and based on
input from Herbert, we shouldn't need to hold the lock at _bh. If this
one works, and nobody sees any other issues
On Thu, Jan 10, 2008 at 11:58:09AM +1100, Herbert Xu wrote:
On Wed, Jan 09, 2008 at 03:19:10PM -0800, Jay Vosburgh wrote:
No that's not the point. The point is to move the majority of the code
into process context so that you can take the RTNL. Once you have taken
the RTNL you can
On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
That wasn't the only purpose, Herbert. Making sure that calls to
dev_set_mac_address were called from process context was important at
the time of the coding as well since at least the tg3 driver took locks
that could not be
Herbert Xu [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
That wasn't the only purpose, Herbert. Making sure that calls to
dev_set_mac_address were called from process context was important at
the time of the coding as well since at least the tg3
Andy Gospodarek [EMAIL PROTECTED] wrote:
[...]
That wasn't the only purpose, Herbert. Making sure that calls to
dev_set_mac_address were called from process context was important at
the time of the coding as well since at least the tg3 driver took locks
that could not be taken reliably in
On Thu, Jan 10, 2008 at 04:03:53PM -0500, Andy Gospodarek wrote:
Sure, but where do you call that function while holding the bond lock?
If I recall correctly, the problem was that tg3, et al, did
things that might sleep, and bonding was calling from a timer context,
which couldn't
On Thu, Jan 10, 2008 at 12:50:46PM -0800, Jay Vosburgh wrote:
Herbert Xu [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
That wasn't the only purpose, Herbert. Making sure that calls to
dev_set_mac_address were called from process context was
Herbert Xu [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 04:03:53PM -0500, Andy Gospodarek wrote:
Sure, but where do you call that function while holding the bond lock?
If I recall correctly, the problem was that tg3, et al, did
things that might sleep, and bonding was calling
Jay Vosburgh [EMAIL PROTECTED] wrote:
For the case of the bond_set_multicast_list function, changing
the existing write_lock to a read_lock_bh doesn't affect any calls to
Right that should also resolve the lockdep issue. So as long as you
guys are sure that this is safe with respect to
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
Fine. Just let you know that someone test your patches and everything
works, except mentioned problem.
And I appreciate it; I just wanted to make sure our many fans
following along at home didn't misunderstand.
Could you let me know if
On Tue, 8 Jan 2008, Jay Vosburgh wrote:
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
Fine. Just let you know that someone test your patches and everything
works, except mentioned problem.
And I appreciate it; I just wanted to make sure our many fans
following along at home didn't
On Tue, Jan 08, 2008 at 11:58:34PM -0800, Jay Vosburgh wrote:
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
Fine. Just let you know that someone test your patches and everything
works, except mentioned problem.
And I appreciate it; I just wanted to make sure our many fans
following
Andy Gospodarek [EMAIL PROTECTED] wrote:
[...]
My initial concern was that a slave device could disappear out from
under us, but it seems like this certainly isn't the case since all
calls to bond_release are protected by rtnl-locks, so I think you are
correct that we are safe. I'll test this on
On Wed, Jan 09, 2008 at 09:54:56AM -0800, Jay Vosburgh wrote:
Andy Gospodarek [EMAIL PROTECTED] wrote:
[...]
My initial concern was that a slave device could disappear out from
under us, but it seems like this certainly isn't the case since all
calls to bond_release are protected by
On Wed, Jan 09, 2008 at 03:17:09PM -0500, Andy Gospodarek wrote:
Agreed. And despite Herbert's opinion that this isn't the correct fix,
I think this will work fine. This is one of the cases where we can take
a write_lock(bond-lock) in softirq context, so we need to drop that (or
make sure
Herbert Xu [EMAIL PROTECTED] wrote:
On Wed, Jan 09, 2008 at 03:17:09PM -0500, Andy Gospodarek wrote:
Agreed. And despite Herbert's opinion that this isn't the correct fix,
I think this will work fine. This is one of the cases where we can take
a write_lock(bond-lock) in softirq context, so
On Wed, Jan 09, 2008 at 03:19:10PM -0800, Jay Vosburgh wrote:
No that's not the point. The point is to move the majority of the code
into process context so that you can take the RTNL. Once you have taken
the RTNL you can disable BH all you want and I don't care one bit.
I'm not
On Mon, 7 Jan 2008, Jay Vosburgh wrote:
Following are three fixes to fix locking problems and
silence locking-related warnings in the current 2.6.24-rc.
patch 1: fix locking in sysfs primary/active selection
Call core network functions with expected locks to
On Tue, Jan 08, 2008 at 07:50:22PM +0100, Krzysztof Oledzki wrote:
On Mon, 7 Jan 2008, Jay Vosburgh wrote:
Following are three fixes to fix locking problems and
silence locking-related warnings in the current 2.6.24-rc.
patch 1: fix locking in sysfs primary/active selection
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
On Mon, 7 Jan 2008, Jay Vosburgh wrote:
Following are three fixes to fix locking problems and
silence locking-related warnings in the current 2.6.24-rc.
patch 1: fix locking in sysfs primary/active selection
Call core network
Andy Gospodarek [EMAIL PROTECTED] wrote:
[...]
Jay's patches will not fix this issue. I think something like this did
it for me, but as I mentioned to Jay in the last thread, I'm not
convinced it doesn't violate some of the locking expectations we have.
diff --git
Andy Gospodarek [EMAIL PROTECTED] wrote:
Jay's patches will not fix this issue. I think something like this did
it for me, but as I mentioned to Jay in the last thread, I'm not
convinced it doesn't violate some of the locking expectations we have.
diff --git
On Tue, 8 Jan 2008, Jay Vosburgh wrote:
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
On Mon, 7 Jan 2008, Jay Vosburgh wrote:
Following are three fixes to fix locking problems and
silence locking-related warnings in the current 2.6.24-rc.
patch 1: fix locking in sysfs
Following are three fixes to fix locking problems and
silence locking-related warnings in the current 2.6.24-rc.
patch 1: fix locking in sysfs primary/active selection
Call core network functions with expected locks to
eliminate potential deadlock and silence warnings.
27 matches
Mail list logo
