Re: [patch 2/3] Introduce BOOTMEM_EXCLUSIVE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Vivek Goyal <[email protected]> [2007-10-17 13:05]:
> 
> [..]
> > +/*
> > + * If flags is 0, then the return value is always 0 (success). If
> > + * flags contains BOOTMEM_EXCLUSIVE, then -EBUSY is returned if the
> > + * memory already was reserved.
> > + */
> > +extern int reserve_bootmem(unsigned long addr, unsigned long size, int flags);
> >  #define alloc_bootmem(x) \
> >  	__alloc_bootmem(x, SMP_CACHE_BYTES, __pa(MAX_DMA_ADDRESS))
> >  #define alloc_bootmem_low(x) \
> > --- a/mm/bootmem.c
> > +++ b/mm/bootmem.c
> > @@ -111,8 +111,8 @@ static unsigned long __init init_bootmem
> >   * might be used for boot-time allocations - or it might get added
> >   * to the free page pool later on.
> >   */
> > -static void __init reserve_bootmem_core(bootmem_data_t *bdata, unsigned long addr,
> > -					unsigned long size)
> > +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.


Thanks,
   Bernhard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux