Patch Upstream: cputimer: Cure lock inversion

DISCUSSION Greg KH 4 participants 8 messages Oct 19, 2011 1 message not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Greg KH

author

2011-10-19 15:49 UTC #1 lore raw

Quoted 26 lines · Gregs git-bot

commit: bcd5cff7216f9b2de0a148cc355eac199dc6f1cf
From: Peter Zijlstra <[email protected]>
Date: Mon, 17 Oct 2011 11:50:30 +0200
Subject: cputimer: Cure lock inversion
There's a lock inversion between the cputimer->lock and rq->lock; notably the two callchains involved are:
update_rlimit_cpu()
sighand->siglock
set_process_cpu_timer()
     cpu_timer_sample_group()
       thread_group_cputimer()
         cputimer->lock
         thread_group_cputime()
           task_sched_runtime()
             ->pi_lock
             rq->lock
scheduler_tick()
rq->lock
task_tick_fair()
     update_curr()
       account_group_exec()
         cputimer->lock

Quoted 5 lines

Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and the second one is keeping up-to-date.
This problem was introduced by e8abccb7193 ("posix-cpu-timers: Cure SMP accounting oddities").

There is no such patch in Linus's tree that I can find. So, what problem is this really trying to cure here and what kernel did it show up in?

confused,

greg k-h

Josh Boyer

2011-10-19 15:55 UTC #2 lore raw

Quoted 30 lines · Greg KH

Quoted 29 lines · Gregs git-bot
commit: bcd5cff7216f9b2de0a148cc355eac199dc6f1cf
From: Peter Zijlstra <[email protected]>
Date: Mon, 17 Oct 2011 11:50:30 +0200
Subject: cputimer: Cure lock inversion
There's a lock inversion between the cputimer->lock and rq->lock; notably the two callchains involved are:
update_rlimit_cpu()
sighand->siglock
set_process_cpu_timer()
cpu_timer_sample_group()
thread_group_cputimer()
cputimer->lock
thread_group_cputime()
task_sched_runtime()
->pi_lock
rq->lock
scheduler_tick()
rq->lock
task_tick_fair()
update_curr()
account_group_exec()
cputimer->lock
Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and the second one is keeping up-to-date.

Quoted 6 lines

Quoted 2 lines
This problem was introduced by e8abccb7193 ("posix-cpu-timers: Cure SMP accounting oddities").
There is no such patch in Linus's tree that I can find. So, what problem is this really trying to cure here and what kernel did it show up in?

Uh...

bcd5cff7216f9b2de0a148cc355eac199dc6f1cf is the upstream commit (post -rc10).

This thread covers the conversation (it's long):

http://thread.gmane.org/gmane.linux.kernel/1199406/focus=1204676

josh

Greg KH

author

2011-10-19 16:00 UTC #3 lore raw

Quoted 34 lines · Josh Boyer

Quoted 33 lines · Greg KH
Quoted 31 lines · Gregs git-bot
commit: bcd5cff7216f9b2de0a148cc355eac199dc6f1cf
From: Peter Zijlstra <[email protected]>
Date: Mon, 17 Oct 2011 11:50:30 +0200
Subject: cputimer: Cure lock inversion
There's a lock inversion between the cputimer->lock and rq->lock; notably the two callchains involved are:
update_rlimit_cpu()
sighand->siglock
set_process_cpu_timer()
cpu_timer_sample_group()
thread_group_cputimer()
cputimer->lock
thread_group_cputime()
task_sched_runtime()
->pi_lock
rq->lock
scheduler_tick()
rq->lock
task_tick_fair()
update_curr()
account_group_exec()
cputimer->lock
Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and the second one is keeping up-to-date.
This problem was introduced by e8abccb7193 ("posix-cpu-timers: Cure SMP accounting oddities").

Quoted 7 lines

Quoted 3 lines
There is no such patch in Linus's tree that I can find. So, what problem is this really trying to cure here and what kernel did it show up in?
Uh...
bcd5cff7216f9b2de0a148cc355eac199dc6f1cf is the upstream commit (post -rc10).

No, I understand that this is the commit I just referenced.

I'm talking about the "This problem was introduced..." line in the commit. I want to find out what was the original problem that this patch is fixing, to determine how far back in the -stable series I need to backport this to.

The issue is that there is no e8abccb7193 ("posix-cpu-timers: Cure SMP accounting oddities") commit that I can see in Linus's tree right now.

Quoted 3 lines

This thread covers the conversation (it's long):
http://thread.gmane.org/gmane.linux.kernel/1199406/focus=1204676

Ugh, I'll go dig, but help would be appreciated...

greg k-h

Josh Boyer

2011-10-19 16:03 UTC #4 lore raw

Quoted 41 lines · Greg KH

Quoted 40 lines · Josh Boyer
Quoted 30 lines · Greg KH
Quoted 29 lines · Gregs git-bot
commit: bcd5cff7216f9b2de0a148cc355eac199dc6f1cf
From: Peter Zijlstra <[email protected]>
Date: Mon, 17 Oct 2011 11:50:30 +0200
Subject: cputimer: Cure lock inversion
There's a lock inversion between the cputimer->lock and rq->lock; notably the two callchains involved are:
update_rlimit_cpu()
sighand->siglock
set_process_cpu_timer()
cpu_timer_sample_group()
thread_group_cputimer()
cputimer->lock
thread_group_cputime()
task_sched_runtime()
->pi_lock
rq->lock
scheduler_tick()
rq->lock
task_tick_fair()
update_curr()
account_group_exec()
cputimer->lock
Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and the second one is keeping up-to-date.
Quoted 6 lines
Quoted 2 lines
This problem was introduced by e8abccb7193 ("posix-cpu-timers: Cure SMP accounting oddities").
There is no such patch in Linus's tree that I can find. So, what problem is this really trying to cure here and what kernel did it show up in?
Uh...

Quoted 8 lines

Quoted 1 line
bcd5cff7216f9b2de0a148cc355eac199dc6f1cf is the upstream commit (post -rc10).
No, I understand that this is the commit I just referenced.
I'm talking about the "This problem was introduced..." line in the commit. I want to find out what was the original problem that this patch is fixing, to determine how far back in the -stable series I need to backport this to.

Ah, I misunderstood.

Quoted 9 lines

The issue is that there is no e8abccb7193 ("posix-cpu-timers: Cure SMP accounting oddities") commit that I can see in Linus's tree right now.
Quoted 3 lines
This thread covers the conversation (it's long):
http://thread.gmane.org/gmane.linux.kernel/1199406/focus=1204676
Ugh, I'll go dig, but help would be appreciated...

My guess is they meant d670ec13178d0fd868

josh

Peter Zijlstra

2011-10-19 16:19 UTC #5 lore raw

Quoted 4 lines · Josh Boyer

Quoted 1 line
Ugh, I'll go dig, but help would be appreciated...
My guess is they meant d670ec13178d0fd868

Your guess is right, no idea how I messed that up, my git tree contains both commits and they're similar but different version of the same patch.

:-(

Greg KH

author

2011-10-19 20:03 UTC #6 lore raw

Quoted 8 lines · Peter Zijlstra

Quoted 4 lines · Josh Boyer
Quoted 1 line
Ugh, I'll go dig, but help would be appreciated...
My guess is they meant d670ec13178d0fd868
Your guess is right, no idea how I messed that up, my git tree contains both commits and they're similar but different version of the same patch.

No problem, just got confused here,

greg k-h

Thomas Gleixner

2011-10-19 19:42 UTC #7 lore raw

In reply to Greg KH

Quoted 30 lines · Greg KH

Quoted 29 lines · Gregs git-bot
commit: bcd5cff7216f9b2de0a148cc355eac199dc6f1cf
From: Peter Zijlstra <[email protected]>
Date: Mon, 17 Oct 2011 11:50:30 +0200
Subject: cputimer: Cure lock inversion
There's a lock inversion between the cputimer->lock and rq->lock; notably the two callchains involved are:
update_rlimit_cpu()
sighand->siglock
set_process_cpu_timer()
     cpu_timer_sample_group()
       thread_group_cputimer()
         cputimer->lock
         thread_group_cputime()
           task_sched_runtime()
             ->pi_lock
             rq->lock
scheduler_tick()
rq->lock
task_tick_fair()
     update_curr()
       account_group_exec()
         cputimer->lock
Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and the second one is keeping up-to-date.

Quoted 6 lines

Quoted 2 lines
This problem was introduced by e8abccb7193 ("posix-cpu-timers: Cure SMP accounting oddities").
There is no such patch in Linus's tree that I can find. So, what problem is this really trying to cure here and what kernel did it show up in?

Oops. It's in 3.0.7

commit 249cf808ba1a0d403fe7c476a74b66e2bc0a8e53

Author: Peter Zijlstra <[email protected]>
Date:   Thu Sep 1 12:42:04 2011 +0200

posix-cpu-timers: Cure SMP wobbles

commit d670ec13178d0fd8680e6742a2bc6e04f28f87d8 upstream.

and that patch introduced the above deadlock, which is cured by:

commit bcd5cff7216f9b2de0a148cc355eac199dc6f1cf

Author: Peter Zijlstra <[email protected]>
Date:   Mon Oct 17 11:50:30 2011 +0200

cputimer: Cure lock inversion

Thanks,

tglx

Greg KH

author

2011-10-19 20:03 UTC #8 lore raw

Quoted 49 lines · Thomas Gleixner

Quoted 30 lines · Greg KH
Quoted 29 lines · Gregs git-bot
commit: bcd5cff7216f9b2de0a148cc355eac199dc6f1cf
From: Peter Zijlstra <[email protected]>
Date: Mon, 17 Oct 2011 11:50:30 +0200
Subject: cputimer: Cure lock inversion
There's a lock inversion between the cputimer->lock and rq->lock; notably the two callchains involved are:
update_rlimit_cpu()
sighand->siglock
set_process_cpu_timer()
     cpu_timer_sample_group()
       thread_group_cputimer()
         cputimer->lock
         thread_group_cputime()
           task_sched_runtime()
             ->pi_lock
             rq->lock
scheduler_tick()
rq->lock
task_tick_fair()
     update_curr()
       account_group_exec()
         cputimer->lock
Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and the second one is keeping up-to-date.
Quoted 6 lines
Quoted 2 lines
This problem was introduced by e8abccb7193 ("posix-cpu-timers: Cure SMP accounting oddities").
There is no such patch in Linus's tree that I can find. So, what problem is this really trying to cure here and what kernel did it show up in?
Oops. It's in 3.0.7
commit 249cf808ba1a0d403fe7c476a74b66e2bc0a8e53
Author: Peter Zijlstra <[email protected]>
Date:   Thu Sep 1 12:42:04 2011 +0200
posix-cpu-timers: Cure SMP wobbles
commit d670ec13178d0fd8680e6742a2bc6e04f28f87d8 upstream.

Quoted 7 lines

and that patch introduced the above deadlock, which is cured by:
commit bcd5cff7216f9b2de0a148cc355eac199dc6f1cf
Author: Peter Zijlstra <[email protected]>
Date:   Mon Oct 17 11:50:30 2011 +0200
cputimer: Cure lock inversion

Thanks for the explanation. I should have it all straightened out now.

greg k-h