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, 31 Aug 2006 09:11:55 -0700 From: Jeremy Fitzhardinge <jeremy@...p.org> To: Pavel Machek <pavel@...e.cz> CC: Andrew Morton <akpm@...l.org>, kernel list <linux-kernel@...r.kernel.org> Subject: Re: cpu_init is called during resume Pavel Machek wrote: > cpu_init() is called during resume, at time when GFP_KERNEL is not > available. This silences warning, and adds few small cleanups. > I presume this is resume from disk. If you're doing resume from RAM, all the CPU-related stuff should already be allocated, unless you're bringing up a new CPU which wasn't previously there, right? What's the call path for this on resume? In my i386-pda patches, I've rearranged this so that the secondary CPU's GDT (and PDA) are pre-allocated on the boot CPU. Does this help this case, or would they still need to be atomic allocations? And wouldn't making these allocations atomic make real CPU hotplug (ie, on an active, running system) more likely to fail? This code doesn't deal with allocation failure very elegantly. J - 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