linux-kernel - Re: On resume from suspend only CPU 0 comes back on-line [REGRESSION][BISECTED]

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:	Thu, 14 May 2015 16:01:44 +0100
From:	Juri Lelli <juri.lelli@....com>
To:	Doug Smythies <dsmythies@...us.net>,
	"peterz@...radead.org" <peterz@...radead.org>,
	'Ingo Molnar' <mingo@...nel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: On resume from suspend only CPU 0 comes back on-line [REGRESSION][BISECTED]

Hi Doug,

On 14/05/15 15:41, Doug Smythies wrote:
> As of, or about, Kernel 4.1RC1 on resume from suspend only CPU 0 comes back on-line.
> The issue persists through Kernel 4.1RC3.
> This is on my test computer with an i7-2600K.
> I do not normally use suspend on this computer, but was doing so while working on a bug report.
> 
> The kernel was bisected, and this is the result:
> 

Does commit 533445c6e533 "sched/core: Fix regression in
cpuset_cpu_inactive() for suspend" on tip/sched/core
fix the bug?

Thanks,

- Juri

> 3c18d447b3b36a8d3c90dc37dfbd363cdb685d0a is the first bad commit
> commit 3c18d447b3b36a8d3c90dc37dfbd363cdb685d0a
> Author: Juri Lelli <juri.lelli@....com>
> Date:   Tue Mar 31 09:53:37 2015 +0100
> 
>     sched/core: Check for available DL bandwidth in cpuset_cpu_inactive()
> 
>     Hotplug operations are destructive w.r.t. cpusets. In case such an
>     operation is performed on a CPU belonging to an exlusive cpuset, the
>     DL bandwidth information associated with the corresponding root
>     domain is gone even if the operation fails (in sched_cpu_inactive()).
> 
>     For this reason we need to move the check we currently have in
>     sched_cpu_inactive() to cpuset_cpu_inactive() to prevent useless
>     cpusets reconfiguration in the CPU_DOWN_FAILED path.
> 
>     Signed-off-by: Juri Lelli <juri.lelli@....com>
>     Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>     Cc: Juri Lelli <juri.lelli@...il.com>
>     Link: http://lkml.kernel.org/r/1427792017-7356-2-git-send-email-juri.lelli@arm.com
>     Signed-off-by: Ingo Molnar <mingo@...nel.org>
> 
> :040000 040000 10f8d81afdc8e625f8e6720883d3eb42c28d452b c08264528890941bad35d5d4cc134c03f259c534 M      kernel
> 
> Since I sometimes mess up using git bisect, and end up at some random result,
> the above was double checked manually:
> 
> 3c18d447b3b36a8d3c90dc37dfbd363cdb685d0a has the issue.
> 4cd57f97135840f637431c92380c8da3edbe44ed (the previous commit) does not have the issue.
> 
> 

--
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/