linux-kernel - Re: 2.6.32 cgroup regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Aug 2010 07:56:01 +0200
From:	Mike Galbraith <efault@....de>
To:	Josh Hunt <johunt@...mai.com>
Cc:	a.p.zijlstra@...llo.nl, mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: 2.6.32 cgroup regression

On Tue, 2010-08-24 at 13:10 -0700, Josh Hunt wrote:
> This commit makes the ltp cpuctl latency test #2 hang indefinitely:
> 
> commit b5d9d734a53e0204aab0089079cbde2a1285a38f
> Author: Mike Galbraith <efault@....de>
> Date:   Tue Sep 8 11:12:28 2009 +0200
> 
>     sched: Ensure that a child can't gain time over it's parent after fork()

Ouch.  Yeah, that commit is buggy, and never got fixed up in stable.
Reverting it will restore a slightly less buggy, but not very good
situation.  Getting the fork problems all fixed up took a while.
(quick fix vs revert didn't help your testcase)

> When I revert this commit the test progresses as it did in 2.6.31. I
> have seen this issue on 2.6.32 and 2.6.32.19. The hang goes away in
> 2.6.33 starting with this commit:
> 
> commit 88ec22d3edb72b261f8628226cd543589a6d5e1b
> Author: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Date:   Wed Dec 16 18:04:41 2009 +0100
> 
>     sched: Remove the cfs_rq dependency from set_task_cpu()

Excellent timing you have.  I have a tree of backports, but I wasn't
counting this commit as a must have, merely highly desirable.  This
testcase showed that it's a needed fix.
  
> Even though this appears to be resolved in 2.6.33, I am reporting it
> because 2.6.32 is the "long-term stable release".

Yeah, there are a _lot_ of fixes that should wander back to 32-stable.

> My test system is a single socket dual core amd -
> model name	: Dual Core AMD Opteron(tm) Processor 180
> with 4GB of RAM.
> Kernel config file attached.
> 
> The issue is easily reproducible for me by downloading and building ltp,
> then running
> testcases/kernel/controllers/cpuctl/run_cpuctl_latency_test.sh 2
> 
> Please let me know if you need any other information to help reproduce
> this issue.

No, the testcase works well.  Thanks.

	-Mike


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/