On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138.
v5.0.6: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.19.33: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.14.110: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
This is a minor context difference. There is no actual dependency on the c0ad4aa4d841 patch. It would be easy to produce new version that could go in these trees. I'm not sure what the right action is in that case. Should I spin a new version with the different locking in the context?
Also, I can't find this commit in tip. It's visible in gitweb but it's not in the tip tree as far as I can tell.
v4.9.167: Failed to apply! Possible dependencies: 8a8c69c32778 ("sched/core: Add rq->lock wrappers") 92509b732baf ("sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock") c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking") cb42c9a3ebbb ("sched/core: Add debugging code to catch missing update_rq_clock() calls") d1ccc66df8bf ("sched/core: Clean up comments") d8ac897137a2 ("sched/core: Add wrappers for lockdep_(un)pin_lock()")
v4.4.178: Failed to apply! Possible dependencies: 2a67e741bbbc ("rcu: Create transitive rnp->lock acquisition functions") 3e71a462dd48 ("sched/core: Move task_rq_lock() out of line") 3ea94de15ce9 ("sched/core: Fix incorrect wait time and wait count statistics") 46a5d164db53 ("rcu: Stop disabling interrupts in scheduler fastpaths") 8a8c69c32778 ("sched/core: Add rq->lock wrappers") 958c5f848e17 ("stop_machine: Change stop_one_cpu() to rely on cpu_stop_queue_work()") bf89a304722f ("stop_machine: Avoid a sleep and wakeup in stop_one_cpu()") c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking") cb2517653fcc ("sched/debug: Make schedstats a runtime tunable that is disabled by default") d8ac897137a2 ("sched/core: Add wrappers for lockdep_(un)pin_lock()") e7904a28f533 ("locking/lockdep, sched/core: Implement a better lock pinning scheme") fecbf6f01fbd ("rcu: Simplify rcu_sched_qs() control flow")
v3.18.138: Failed to apply! Possible dependencies: 1a43a14a5bd9 ("sched: Fix schedule_tail() to disable preemption") 1b537c7d1e58 ("sched/core: Remove check of p->sched_class") 1d7e974cbf2f ("sched/deadline: Don't check SD_BALANCE_FORK") 3960c8c0c789 ("sched: Make dl_task_time() use task_rq_lock()") 3e71a462dd48 ("sched/core: Move task_rq_lock() out of line") 4c9a4bc89a9c ("sched: Allow balance callbacks for check_class_changed()") 5cc389bcee08 ("sched: Move code around") 5e16bbc2fb40 ("sched: Streamline the task migration locking a little") 67dfa1b756f2 ("sched/deadline: Implement cancel_dl_timer() to use in switched_from_dl()") 6c1d9410f007 ("sched: Move p->nr_cpus_allowed check to select_task_rq()") 74b8a4cb6ce3 ("sched: Clarify ordering between task_rq_lock() and move_queued_task()") 8a8c69c32778 ("sched/core: Add rq->lock wrappers") c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking") cbce1a686700 ("sched,lockdep: Employ lock pinning") dfa50b605c2a ("sched: Make finish_task_switch() return 'struct rq *'") f4e9d94a5bf6 ("sched/deadline: Don't balance during wakeup if wakee is pinned")
How should we proceed with this patch?
I haven't look that far back. This patch should be pretty self contained. I don't think it's worth pulling it back to these trees if it would require all of these patches. The risk would out-weigh the reward.
Cheers, Phil
-- Thanks, Sasha
--
On Mon, Apr 08, 2019 at 09:42:14AM -0400, Phil Auld wrote:
On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138.
v5.0.6: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.19.33: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.14.110: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
This is a minor context difference. There is no actual dependency on the c0ad4aa4d841 patch. It would be easy to produce new version that could go in these trees. I'm not sure what the right action is in that case. Should I spin a new version with the different locking in the context?
Please do :)
The algorithm does the dependency analysis by looking at surrounding code rather than actual functional dependency.
-- Thanks, Sasha
On Mon, Apr 08, 2019 at 10:50:26AM -0400 Sasha Levin wrote:
On Mon, Apr 08, 2019 at 09:42:14AM -0400, Phil Auld wrote:
On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138.
v5.0.6: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.19.33: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.14.110: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
This is a minor context difference. There is no actual dependency on the c0ad4aa4d841 patch. It would be easy to produce new version that could go in these trees. I'm not sure what the right action is in that case. Should I spin a new version with the different locking in the context?
Please do :)
Sure. I'm just not sure how to post it. It only shows up in this tip-bot email and on gitweb. It's not in tip.git and not in Linus' upstream tree.
I've updated the patch at it will apply now to v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178 all with increasing offsets but nothing else.
v3.18.138 won't take it without more work. I'd be inclined to skip that one.
The algorithm does the dependency analysis by looking at surrounding code rather than actual functional dependency.
That's pretty cool though :)
Cheers, Phil
-- Thanks, Sasha
--
On Mon, Apr 08, 2019 at 01:03:05PM -0400, Phil Auld wrote:
On Mon, Apr 08, 2019 at 10:50:26AM -0400 Sasha Levin wrote:
On Mon, Apr 08, 2019 at 09:42:14AM -0400, Phil Auld wrote:
On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138.
v5.0.6: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.19.33: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.14.110: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
This is a minor context difference. There is no actual dependency on the c0ad4aa4d841 patch. It would be easy to produce new version that could go in these trees. I'm not sure what the right action is in that case. Should I spin a new version with the different locking in the context?
Please do :)
Sure. I'm just not sure how to post it. It only shows up in this tip-bot email and on gitweb. It's not in tip.git and not in Linus' upstream tree.
I've updated the patch at it will apply now to v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178 all with increasing offsets but nothing else.
You can either reply to this thread with the patch(es), or just send them out and annotate one way or the other that they should go to their appropriate stable trees.
v3.18.138 won't take it without more work. I'd be inclined to skip that one.
No problem there.
-- Thanks, Sasha
On Mon, Apr 08, 2019 at 01:06:12PM -0400 Sasha Levin wrote:
On Mon, Apr 08, 2019 at 01:03:05PM -0400, Phil Auld wrote:
On Mon, Apr 08, 2019 at 10:50:26AM -0400 Sasha Levin wrote:
On Mon, Apr 08, 2019 at 09:42:14AM -0400, Phil Auld wrote:
On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138.
v5.0.6: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.19.33: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
v4.14.110: Failed to apply! Possible dependencies: c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
This is a minor context difference. There is no actual dependency on the c0ad4aa4d841 patch. It would be easy to produce new version that could go in these trees. I'm not sure what the right action is in that case. Should I spin a new version with the different locking in the context?
Please do :)
Sure. I'm just not sure how to post it. It only shows up in this tip-bot email and on gitweb. It's not in tip.git and not in Linus' upstream tree.
I've updated the patch at it will apply now to v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178 all with increasing offsets but nothing else.
You can either reply to this thread with the patch(es), or just send them out and annotate one way or the other that they should go to their appropriate stable trees.
Okay, I'll do that. Am I the only one who finds it strange that the commit exists only in this email and gitweb but not the actual git tree(s)?
v3.18.138 won't take it without more work. I'd be inclined to skip that one.
No problem there.
-- Thanks, Sasha
--
linux-stable-mirror@lists.linaro.org