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 netwo
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 i
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 ma
On Wed, 9 Jan 2008, Andy Gospodarek wrote:
On Wed, Jan 09, 2008 at 09:54:56AM -0800, Jay Vosburgh wrote:
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. The lo
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 respec
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 bondin
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
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,
> > whic
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
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 so
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 b
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 yo
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
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 c
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 s
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
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 thi
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
> fol
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 m
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
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 prima
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 a/drivers/net/bonding/b
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 a/drivers/net/bonding/bon
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
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
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
eliminate
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
