On Tue, Aug 14, 2018 at 10:35 AM Vlad Buslov wrote:
>
>
> On Mon 13 Aug 2018 at 23:18, Cong Wang wrote:
> > Hi, Vlad,
> >
> > Could you help to test my fixes?
> >
> > I just pushed them into my own git repo:
> > https://github.com/congwang/linux/commits/net-sched-fixes
> >
> > Particularly, this
On Mon 13 Aug 2018 at 23:18, Cong Wang wrote:
> Hi, Vlad,
>
> Could you help to test my fixes?
>
> I just pushed them into my own git repo:
> https://github.com/congwang/linux/commits/net-sched-fixes
>
> Particularly, this is the revert:
> https://github.com/congwang/linux/commit/b3f51c4ab8272cc
Hi, Vlad,
Could you help to test my fixes?
I just pushed them into my own git repo:
https://github.com/congwang/linux/commits/net-sched-fixes
Particularly, this is the revert:
https://github.com/congwang/linux/commit/b3f51c4ab8272cc8d3244848e528fce1426c4659
and this is my fix for the lockdep war
On Mon, Aug 13, 2018 at 3:53 PM David Miller wrote:
>
> From: Cong Wang
> Date: Mon, 13 Aug 2018 12:16:52 -0700
>
> > Your fix doesn't make sense, because what ife_mod_lock protects
> > is absolutely not touched in BH context, they have no race.
>
> It does make sense, the problem is if you acqui
From: Cong Wang
Date: Mon, 13 Aug 2018 12:16:52 -0700
> Your fix doesn't make sense, because what ife_mod_lock protects
> is absolutely not touched in BH context, they have no race.
It does make sense, the problem is if you acquire ife_mod_lock and
take a software interrupt while you hold it.
I
On Mon, Aug 13, 2018 at 12:16 PM Cong Wang wrote:
>
> On Mon, Aug 13, 2018 at 10:20 AM Vlad Buslov wrote:
> >
> > Lockdep reports deadlock for following locking scenario in ife action:
> >
> > Task one:
> > 1) Executes ife action update.
> > 2) Takes tcfa_lock.
> > 3) Waits on ife_mod_lock which
On Mon, Aug 13, 2018 at 10:20 AM Vlad Buslov wrote:
>
> Lockdep reports deadlock for following locking scenario in ife action:
>
> Task one:
> 1) Executes ife action update.
> 2) Takes tcfa_lock.
> 3) Waits on ife_mod_lock which is already taken by task two.
>
> Task two:
>
> 1) Executes any path
From: Vlad Buslov
Date: Mon, 13 Aug 2018 20:20:11 +0300
> Lockdep reports deadlock for following locking scenario in ife action:
>
> Task one:
> 1) Executes ife action update.
> 2) Takes tcfa_lock.
> 3) Waits on ife_mod_lock which is already taken by task two.
>
> Task two:
>
> 1) Executes any
On Mon 13 Aug 2018 at 17:23, Jamal Hadi Salim wrote:
> On 2018-08-13 1:20 p.m., Vlad Buslov wrote:
>> Lockdep reports deadlock for following locking scenario in ife action:
>>
>> Task one:
>> 1) Executes ife action update.
>> 2) Takes tcfa_lock.
>> 3) Waits on ife_mod_lock which is already take
From: Vlad Buslov
Date: Mon, 13 Aug 2018 20:26:40 +0300
> Is it okay to submit a fix for issue I uncovered when testing actions
> with estimators, or I should resubmit to net when net-next is moved?
Yes, this is fine.
Hi David,
Is it okay to submit a fix for issue I uncovered when testing actions
with estimators, or I should resubmit to net when net-next is moved?
Thanks,
Vlad
On 2018-08-13 1:20 p.m., Vlad Buslov wrote:
Lockdep reports deadlock for following locking scenario in ife action:
Task one:
1) Executes ife action update.
2) Takes tcfa_lock.
3) Waits on ife_mod_lock which is already taken by task two.
Task two:
1) Executes any path that obtains ife_mod_lock
Lockdep reports deadlock for following locking scenario in ife action:
Task one:
1) Executes ife action update.
2) Takes tcfa_lock.
3) Waits on ife_mod_lock which is already taken by task two.
Task two:
1) Executes any path that obtains ife_mod_lock without disabling bh (any
path that takes ife_
13 matches
Mail list logo
