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, 18 Oct 2007 10:02:37 +0530 From: Vivek Goyal <vgoyal@...ibm.com> To: linux-kernel@...r.kernel.org, kexec@...ts.infradead.org, akpm@...ux-foundation.org, ak@...e.de Subject: Re: [patch 2/3] Introduce BOOTMEM_EXCLUSIVE On Wed, Oct 17, 2007 at 01:36:51PM +0200, Bernhard Walle wrote: [..] > > > +static int __init reserve_bootmem_core(bootmem_data_t *bdata, unsigned long addr, > > > + unsigned long size, int flags) > > > { > > > unsigned long sidx, eidx; > > > unsigned long i; > > > @@ -133,7 +133,11 @@ static void __init reserve_bootmem_core( > > > #ifdef CONFIG_DEBUG_BOOTMEM > > > printk("hm, page %08lx reserved twice.\n", i*PAGE_SIZE); > > > #endif > > > + if (flags & BOOTMEM_EXCLUSIVE) > > > + return -EBUSY; > > > > I think we should unreserve the chunks of memory we have reserved so > > far (Memory reserved from sidx to i), in case of error. > > Unfortunately, that's not possible without using a lock (or counters > instead of a bitmap) any more. If we just do > > for (i--; i >= sidx; i--) > clear_bit(i, bdata->node_bootmem_map); > > then another thread of execution could reserve the memory (without > BOOTMEM_EXCLUSIVE) in between -- and the code would free the memory > which is already reserved. > > I think that could be modelled with a rwlock, not changing the default > case where BOOTMEM_EXCLUSIVE is not specified. SMP initialization takes place after bootmem allocator has retired. That would mean only one thread will be using bootmem allocator. Hence I think unreserving memory without any kind of locking should be safe. Thanks Vivek - 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