| 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
| ||
|
Date: Thu, 13 Sep 2007 00:52:10 -0700 From: Rick Lindsley <ricklind@...ibm.com> To: linux-kernel@...r.kernel.org Subject: Bad hotplug/scheduler interaction? I'm concerned that we don't have adequate protection for the scheduler during cpu hotplug events, but I'm willing to believe I simply don't understand the mechanism well enough. We had a crash in (comparatively ancient) 2.6.16.* but I think the relevant code is basically unchanged since then. First we introduced some cpu-intensive workloads. Then we added two cpus. System quickly crashed. The crash was in find_busiest_group(), when the kernel tried to access "this", which was NULL. If we don't find a localgroup, we won't set this, and when we try to calculate *imbalance, we'll dereference a NULL "this" and crash. As I looked over the code, though, I couldn't tell if the fault was with find_busiest_group() for not covering this case, or if the problem was that the method the hotplug code is using to reconstruct the sched_domains really doesn't protect find_busiest_group (and find_idlest_group) at all. Can anybody explain how synchronize_sched() is really syncing? It looks like a half-implemented RCU setup. I fear we really don't have any way to protect the two functions above from hotplug's desire to twiddle with the sched_domains. Do we? Rick - 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/
Powered by blists - more mailing lists