Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Feb 14, 2015
  1. @jankara

    lib/genalloc.c: check result of devres_alloc()

    jankara authored committed
    devm_gen_pool_create() calls devres_alloc() and dereferences its result
    without checking whether devres_alloc() succeeded.  Check for error and
    bail out if it happened.
    Coverity-id 1016493.
    Signed-off-by: Jan Kara <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Feb 13, 2015
  1. @Villemoes

    lib/genalloc.c: remove redundant include

    Villemoes authored committed
    Removing this include produces byte-identical output, and thus removes a
    false dependency.
    Signed-off-by: Rasmus Villemoes <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
  2. @toshikik

    lib/genalloc.c: fix the end addr check in addr_in_gen_pool()

    toshikik authored committed
    Since chunk->end_addr is (chunk->start_addr + size - 1), the end address
    to compare should be (start + size - 1).
    Signed-off-by: Toshi Kikuchi <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Dec 3, 2014
  1. @michalsimek

    lib/genalloc.c: export devm_gen_pool_create() for modules

    michalsimek authored committed
    Modules can use this function for creating pool.
    Signed-off-by: Michal Simek <>
    Acked-by: Lad, Prabhakar <>
    Cc: Laura Abbott <>
    Cc: Olof Johansson <>
    Cc: Catalin Marinas <>
    Cc: Will Deacon <>
    Cc: Vladimir Zapolskiy <>
    Cc: Philipp Zabel <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Oct 10, 2014
  1. @labbott

    lib/genalloc.c: add genpool range check function

    labbott authored committed
    After allocating an address from a particular genpool, there is no good
    way to verify if that address actually belongs to a genpool.  Introduce
    addr_in_gen_pool which will return if an address plus size falls
    completely within the genpool range.
    Signed-off-by: Laura Abbott <>
    Acked-by: Will Deacon <>
    Reviewed-by: Olof Johansson <>
    Reviewed-by: Catalin Marinas <>
    Cc: Arnd Bergmann <>
    Cc: David Riley <>
    Cc: Ritesh Harjain <>
    Cc: Russell King <>
    Cc: Thierry Reding <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
  2. @labbott

    lib/genalloc.c: add power aligned algorithm

    labbott authored committed
    One of the more common algorithms used for allocation is to align the
    start address of the allocation to the order of size requested.  Add this
    as an algorithm option for genalloc.
    Signed-off-by: Laura Abbott <>
    Acked-by: Will Deacon <>
    Acked-by: Olof Johansson <>
    Reviewed-by: Catalin Marinas <>
    Cc: Arnd Bergmann <>
    Cc: David Riley <>
    Cc: Ritesh Harjain <>
    Cc: Russell King <>
    Cc: Thierry Reding <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Sep 26, 2014
  1. genalloc: fix device node resource counter

    Vladimir Zapolskiy authored committed
    Decrement the np_pool device_node refcount, which was incremented on
    the preceding of_parse_phandle() call.
    Signed-off-by: Vladimir Zapolskiy <>
    Cc: Will Deacon <>
    Cc: Olof Johansson <>
    Cc: Catalin Marinas <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Jan 30, 2014
  1. @prabhakarlad

    lib/genalloc.c: add check gen_pool_dma_alloc() if dma pointer is not …

    prabhakarlad authored committed
    In the gen_pool_dma_alloc() the dma pointer can be NULL and while
    assigning gen_pool_virt_to_phys(pool, vaddr) to dma caused the following
    crash on da850 evm:
       Unable to handle kernel NULL pointer dereference at virtual address 00000000
       Internal error: Oops: 805 [#1] PREEMPT ARM
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper Tainted: G        W    3.13.0-rc1-00001-g0609e45-dirty #5
       task: c4830000 ti: c4832000 task.ti: c4832000
       PC is at gen_pool_dma_alloc+0x30/0x3c
       LR is at gen_pool_virt_to_phys+0x74/0x80
       Process swapper, call trace:
    This patch fixes the above.
    [ update kerneldoc]
    Signed-off-by: Lad, Prabhakar <>
    Cc: Philipp Zabel <>
    Cc: Nicolin Chen <>
    Cc: Joe Perches <>
    Cc: Sachin Kamat <>
    Cc: <>	[3.13.x]
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Nov 13, 2013
  1. lib/genalloc: add a helper function for DMA buffer allocation

    Nicolin Chen authored committed
    When using pool space for DMA buffer, there might be duplicated calling of
    gen_pool_alloc() and gen_pool_virt_to_phys() in each implementation.
    Thus it's better to add a simple helper function, a compatible one to the
    common dma_alloc_coherent(), to save some code.
    Signed-off-by: Nicolin Chen <>
    Cc: "Hans J. Koch" <>
    Cc: Dan Williams <>
    Cc: Eric Miao <>
    Cc: Grant Likely <>
    Cc: Greg Kroah-Hartman <>
    Cc: Haojian Zhuang <>
    Cc: Jaroslav Kysela <>
    Cc: Kevin Hilman <>
    Cc: Liam Girdwood <>
    Cc: Mark Brown <>
    Cc: Mauro Carvalho Chehab <>
    Cc: Rob Herring <>
    Cc: Russell King <>
    Cc: Sekhar Nori <>
    Cc: Takashi Iwai <>
    Cc: Vinod Koul <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Sep 11, 2013
  1. lib/genalloc.c: correct dev_get_gen_pool documentation

    Emilio López authored committed
    The documentation mentions a "name" parameter, which does not exist.  This
    commit removes such mention from the function documentation.
    Signed-off-by: Emilio López <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
  2. lib/genalloc.c: convert kmalloc_node(...GFP_ZERO...) to kzalloc_node(…

    Joe Perches authored committed
    Use the helper function instead of __GFP_ZERO.
    Signed-off-by: Joe Perches <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
  3. lib/genalloc.c: fix overflow of ending address of memory chunk

    Joonyoung Shim authored committed
    In struct gen_pool_chunk, end_addr means the end address of memory chunk
    (inclusive), but in the implementation it is treated as address + size of
    memory chunk (exclusive), so it points to the address plus one instead of
    correct ending address.
    The ending address of memory chunk plus one will cause overflow on the
    memory chunk including the last address of memory map, e.g.  when starting
    address is 0xFFF00000 and size is 0x100000 on 32bit machine, ending
    address will be 0x100000000.
    Use correct ending address like starting address + size - 1.
    [ add comment to struct gen_pool_chunk:end_addr]
    Signed-off-by: Joonyoung Shim <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Apr 30, 2013
  1. genalloc: add devres support, allow to find a managed pool by device

    Philipp Zabel authored committed
    This patch adds three exported functions to lib/genalloc.c:
    devm_gen_pool_create, dev_get_gen_pool, and of_get_named_gen_pool.
    devm_gen_pool_create is a managed version of gen_pool_create that keeps
    track of the pool via devres and allows the management code to
    automatically destroy it after device removal.
    dev_get_gen_pool retrieves the gen_pool for a given device, if it was
    created with devm_gen_pool_create, using devres_find.
    of_get_named_gen_pool retrieves the gen_pool for a given device node and
    property name, where the property must contain a phandle pointing to a
    platform device node.  The corresponding platform device is then fed into
    dev_get_gen_pool and the resulting gen_pool is returned.
    [ make the of_get_named_gen_pool() stub static, fixing a zillion link errors]
    [ squish "struct device declared inside parameter list" warning]
    Signed-off-by: Philipp Zabel <>
    Acked-by: Grant Likely <>
    Tested-by: Michal Simek <>
    Cc: Fabio Estevam <>
    Cc: Matt Porter <>
    Cc: Dong Aisheng <>
    Cc: Greg Kroah-Hartman <>
    Cc: Rob Herring <>
    Cc: Paul Gortmaker <>
    Cc: Javier Martin <>
    Cc: Huang Shijie <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Oct 25, 2012
  1. genalloc: stop crashing the system when destroying a pool

    Thadeu Lima de Souza Cascardo authored committed
    The genalloc code uses the bitmap API from include/linux/bitmap.h and
    lib/bitmap.c, which is based on long values.  Both bitmap_set from
    lib/bitmap.c and bitmap_set_ll, which is the lockless version from
    genalloc.c, use BITMAP_LAST_WORD_MASK to set the first bits in a long in
    the bitmap.
    That one uses (1 << bits) - 1, 0b111, if you are setting the first three
    bits.  This means that the API counts from the least significant bits
    (LSB from now on) to the MSB.  The LSB in the first long is bit 0, then.
    The same works for the lookup functions.
    The genalloc code uses longs for the bitmap, as it should.  In
    include/linux/genalloc.h, struct gen_pool_chunk has unsigned long
    bits[0] as its last member.  When allocating the struct, genalloc should
    reserve enough space for the bitmap.  This should be a proper number of
    longs that can fit the amount of bits in the bitmap.
    However, genalloc allocates an integer number of bytes that fit the
    amount of bits, but may not be an integer amount of longs.  9 bytes, for
    example, could be allocated for 70 bits.
    This is a problem in itself if the Least Significat Bit in a long is in
    the byte with the largest address, which happens in Big Endian machines.
    This means genalloc is not allocating the byte in which it will try to
    set or check for a bit.
    This may end up in memory corruption, where genalloc will try to set the
    bits it has not allocated.  In fact, genalloc may not set these bits
    because it may find them already set, because they were not zeroed since
    they were not allocated.  And that's what causes a BUG when
    gen_pool_destroy is called and check for any set bits.
    What really happens is that genalloc uses kmalloc_node with __GFP_ZERO
    on gen_pool_add_virt.  With SLAB and SLUB, this means the whole slab
    will be cleared, not only the requested bytes.  Since struct
    gen_pool_chunk has a size that is a multiple of 8, and slab sizes are
    multiples of 8, we get lucky and allocate and clear the right amount of
    Hower, this is not the case with SLOB or with older code that did memset
    after allocating instead of using __GFP_ZERO.
    So, a simple module as this (running 3.6.0), will cause a crash when
      [root@phantom-lp2 foo]# cat foo.c
      #include <linux/kernel.h>
      #include <linux/module.h>
      #include <linux/init.h>
      #include <linux/genalloc.h>
      static struct gen_pool *foo_pool;
      static __init int foo_init(void)
              int ret;
              foo_pool = gen_pool_create(10, -1);
              if (!foo_pool)
                      return -ENOMEM;
              ret = gen_pool_add(foo_pool, 0xa0000000, 32 << 10, -1);
              if (ret) {
                      return ret;
              return 0;
      static __exit void foo_exit(void)
      [root@phantom-lp2 foo]# zcat /proc/config.gz | grep SLOB
      [root@phantom-lp2 foo]# insmod ./foo.ko
      [root@phantom-lp2 foo]# rmmod foo
      ------------[ cut here ]------------
      kernel BUG at lib/genalloc.c:243!
      cpu 0x4: Vector: 700 (Program Check) at [c0000000bb0e7960]
          pc: c0000000003cb50c: .gen_pool_destroy+0xac/0x110
          lr: c0000000003cb4fc: .gen_pool_destroy+0x9c/0x110
          sp: c0000000bb0e7be0
         msr: 8000000000029032
        current = 0xc0000000bb0e0000
        paca    = 0xc000000006d30e00   softe: 0        irq_happened: 0x01
          pid   = 13044, comm = rmmod
      kernel BUG at lib/genalloc.c:243!
      [c0000000bb0e7ca0] d000000004b00020 .foo_exit+0x20/0x38 [foo]
      [c0000000bb0e7d20] c0000000000dff98 .SyS_delete_module+0x1a8/0x290
      [c0000000bb0e7e30] c0000000000097d4 syscall_exit+0x0/0x94
      --- Exception: c00 (System Call) at 000000800753d1a0
      SP (fffd0b0e640) is in userspace
    Signed-off-by: Thadeu Lima de Souza Cascardo <>
    Cc: Paul Gortmaker <>
    Cc: Benjamin Gaignard <>
    Cc: <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Oct 5, 2012
  1. genalloc: make it possible to use a custom allocation algorithm

    Benjamin Gaignard authored committed
    Premit use of another algorithm than the default first-fit one.  For
    example a custom algorithm could be used to manage alignment requirements.
    As I can't predict all the possible requirements/needs for all allocation
    uses cases, I add a "free" field 'void *data' to pass any needed
    information to the allocation function.  For example 'data' could be used
    to handle a structure where you store the alignment, the expected memory
    bank, the requester device, or any information that could influence the
    allocation algorithm.
    An usage example may look like this:
    struct my_pool_constraints {
    	int align;
    	int bank;
    unsigned long my_custom_algo(unsigned long *map, unsigned long size,
    		unsigned long start, unsigned int nr, void *data)
    	struct my_pool_constraints *constraints = data;
    	deal with allocation contraints
    	return the index in bitmap where perform the allocation
    void create_my_pool()
    	struct my_pool_constraints c;
    	struct gen_pool *pool = gen_pool_create(...);
    	gen_pool_add(pool, ...);
    	gen_pool_set_algo(pool, my_custom_algo, &c);
    Add of best-fit algorithm function:
    most of the time best-fit is slower then first-fit but memory fragmentation
    is lower. The random buffer allocation/free tests don't show any arithmetic
    relation between the allocation time and fragmentation but the
    best-fit algorithm
    is sometime able to perform the allocation when the first-fit can't.
    This new algorithm help to remove static allocations on ESRAM, a small but
    fast on-chip RAM of few KB, used for high-performance uses cases like DMA
    linked lists, graphic accelerators, encoders/decoders. On the Ux500
    (in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
    static allocations becomes unmaintainable:
    cd arch/arm/mach-ux500 && grep -r ESRAM .
    ./include/mach/db8500-regs.h:/* Base address and bank offsets for ESRAM */
    ./include/mach/db8500-regs.h:#define U8500_ESRAM_BASE   0x40000000
    ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK_SIZE      0x00020000
    ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK0  U8500_ESRAM_BASE
    ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK1       (U8500_ESRAM_BASE + U8500_ESRAM_BANK_SIZE)
    ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK2       (U8500_ESRAM_BANK1 + U8500_ESRAM_BANK_SIZE)
    ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK3       (U8500_ESRAM_BANK2 + U8500_ESRAM_BANK_SIZE)
    ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK4       (U8500_ESRAM_BANK3 + U8500_ESRAM_BANK_SIZE)
    ./include/mach/db8500-regs.h:#define U8500_ESRAM_DMA_LCPA_OFFSET     0x10000
    ./include/mach/db8500-regs.h:#define U8500_DMA_LCPA_BASE
    ./include/mach/db8500-regs.h:#define U8500_DMA_LCLA_BASE U8500_ESRAM_BANK4
    I want to use genalloc to do dynamic allocations but I need to be able to
    fine tune the allocation algorithm. I my case best-fit algorithm give
    better results than first-fit, but it will not be true for every use case.
    Signed-off-by: Benjamin Gaignard <>
    Cc: Huang Ying <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Mar 7, 2012
  1. lib: reduce the use of module.h wherever possible

    Paul Gortmaker authored
    For files only using THIS_MODULE and/or EXPORT_SYMBOL, map
    them onto including export.h -- or if the file isn't even
    using those, then just delete the include.  Fix up any implicit
    include dependencies that were being masked by module.h along
    the way.
    Signed-off-by: Paul Gortmaker <>
Commits on Aug 3, 2011
  1. @lenb

    lib, Make gen_pool memory allocator lockless

    Huang Ying authored lenb committed
    This version of the gen_pool memory allocator supports lockless
    This makes it safe to use in NMI handlers and other special
    unblockable contexts that could otherwise deadlock on locks.  This is
    implemented by using atomic operations and retries on any conflicts.
    The disadvantage is that there may be livelocks in extreme cases.  For
    better scalability, one gen_pool allocator can be used for each CPU.
    The lockless operation only works if there is enough memory available.
    If new memory is added to the pool a lock has to be still taken.  So
    any user relying on locklessness has to ensure that sufficient memory
    is preallocated.
    The basic atomic operation of this allocator is cmpxchg on long.  On
    architectures that don't have NMI-safe cmpxchg implementation, the
    allocator can NOT be used in NMI handler.  So code uses the allocator
    in NMI handler should depend on CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG.
    Signed-off-by: Huang Ying <>
    Reviewed-by: Andi Kleen <>
    Reviewed-by: Mathieu Desnoyers <>
    Cc: Andrew Morton <>
    Signed-off-by: Len Brown <>
Commits on May 25, 2011
  1. @plagnioj

    lib/genalloc.c: add support for specifying the physical address

    plagnioj authored committed
    So we can specify the virtual address as the base of the pool chunk and
    then get physical addresses for hardware IP.
    For example on at91 we will use this on spi, uart or macb
    Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <>
    Cc: Nicolas Ferre <>
    Cc: Patrice VILCHEZ <>
    Cc: Jes Sorensen <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Jun 29, 2010
  1. genalloc: fix allocation from end of pool

    Imre Deak authored committed
    bitmap_find_next_zero_area requires the size of the bitmap, we instead
    passed the last suitable position.  This made it impossible to allocate
    from the end of the pool.
    Fixes a regression introduced by 243797f
    ("genalloc: use bitmap_find_next_zero_area").
    Signed-off-by: Imre Deak <>
    Cc: Zygo Blaxell <>
    Cc: Tejun Heo <>
    Acked-by: Akinobu Mita <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Mar 30, 2010
  1. include cleanup: Update gfp.h and slab.h includes to prepare for brea…

    Tejun Heo authored
    …king implicit slab.h inclusion from percpu.h
    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files.  percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.
    percpu.h -> slab.h dependency is about to be removed.  Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability.  As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.
    The script does the followings.
    * Scan files for gfp and slab usages and update includes such that
      only the necessary includes are there.  ie. if only gfp is used,
      gfp.h, if slab is used, slab.h.
    * When the script inserts a new include, it looks at the include
      blocks and try to put the new include such that its order conforms
      to its surrounding.  It's put in the include block which contains
      core kernel includes, in the same order that the rest are ordered -
      alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
      doesn't seem to be any matching order.
    * If the script can't find a place to put a new include (mostly
      because the file doesn't have fitting include block), it prints out
      an error message indicating which .h file needs to be added to the
    The conversion was done in the following steps.
    1. The initial automatic conversion of all .c files updated slightly
       over 4000 files, deleting around 700 includes and adding ~480 gfp.h
       and ~3000 slab.h inclusions.  The script emitted errors for ~400
    2. Each error was manually checked.  Some didn't need the inclusion,
       some needed manual addition while adding it to implementation .h or
       embedding .c file was more appropriate for others.  This step added
       inclusions to around 150 files.
    3. The script was run again and the output was compared to the edits
       from #2 to make sure no file was left behind.
    4. Several build tests were done and a couple of problems were fixed.
       e.g. lib/decompress_*.c used malloc/free() wrappers around slab
       APIs requiring slab.h to be added manually.
    5. The script was run on all .h files but without automatically
       editing them as sprinkling gfp.h and slab.h inclusions around .h
       files could easily lead to inclusion dependency hell.  Most gfp.h
       inclusion directives were ignored as stuff from gfp.h was usually
       wildly available and often used in preprocessor macros.  Each
       slab.h inclusion directive was examined and added manually as
    6. percpu.h was updated not to include slab.h.
    7. Build test were done on the following configurations and failures
       were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
       distributed build env didn't work with gcov compiles) and a few
       more options had to be turned off depending on archs to make things
       build (like ipr on powerpc/64 which failed due to missing writeq).
       * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
       * powerpc and powerpc64 SMP allmodconfig
       * sparc and sparc64 SMP allmodconfig
       * ia64 SMP allmodconfig
       * s390 SMP allmodconfig
       * alpha SMP allmodconfig
       * um on x86_64 SMP allmodconfig
    8. percpu.h modifications were reverted so that it could be applied as
       a separate patch and serve as bisection point.
    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.
    Signed-off-by: Tejun Heo <>
    Guess-its-ok-by: Christoph Lameter <>
    Cc: Ingo Molnar <>
    Cc: Lee Schermerhorn <>
Commits on Dec 16, 2009
  1. @mita

    genalloc: use bitmap_find_next_zero_area

    mita authored committed
    Signed-off-by: Akinobu Mita <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Jun 17, 2009
  1. lib/genalloc.c: remove unmatched write_lock() in gen_pool_destroy

    Zygo Blaxell authored committed
    There is a call to write_lock() in gen_pool_destroy which is not balanced
    by any corresponding write_unlock().  This causes problems with preemption
    because the preemption-disable counter is incremented in the write_lock()
    call, but never decremented by any call to write_unlock().  This bug is
    gen_pool_destroy, and one of them is non-x86 arch-specific code.
    Signed-off-by: Zygo Blaxell <>
    Cc: Jiri Kosina <>
    Cc: Steve Wise <>
    Cc: <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Jul 17, 2007
  1. Slab allocators: Replace explicit zeroing with __GFP_ZERO

    Christoph Lameter authored Linus Torvalds committed
    kmalloc_node() and kmem_cache_alloc_node() were not available in a zeroing
    variant in the past.  But with __GFP_ZERO it is possible now to do zeroing
    while allocating.
    Use __GFP_ZERO to remove the explicit clearing of memory via memset whereever
    we can.
    Signed-off-by: Christoph Lameter <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Feb 21, 2007
  1. [PATCH] genalloc warning fixes

    Andrew Morton authored Linus Torvalds committed
    lib/genalloc.c: In function 'gen_pool_alloc':
    lib/genalloc.c:151: warning: passing argument 2 of '__set_bit' from incompatible pointer type
    lib/genalloc.c: In function 'gen_pool_free':
    lib/genalloc.c:190: warning: passing argument 2 of '__clear_bit' from incompatible pointer type
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Oct 2, 2006
  1. [PATCH] make genpool allocator adhere to kernel-doc standards

    Dean Nelson authored Linus Torvalds committed
    The exported kernel interfaces of genpool allocator need to adhere to
    the requirements of kernel-doc.
    Signed-off-by: Dean Nelson <>
    Cc: Steve Wise <>
    Acked-by: Randy Dunlap <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
  2. @larrystevenwise

    [PATCH] LIB: add gen_pool_destroy()

    larrystevenwise authored Linus Torvalds committed
    Modules using the genpool allocator need to be able to destroy the data
    structure when unloading.
    Signed-off-by: Steve Wise <>
    Cc: Randy Dunlap <>
    Cc: Dean Nelson <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Jun 23, 2006
  1. [PATCH] change gen_pool allocator to not touch managed memory

    Dean Nelson authored Linus Torvalds committed
    Modify the gen_pool allocator (lib/genalloc.c) to utilize a bitmap scheme
    instead of the buddy scheme.  The purpose of this change is to eliminate
    the touching of the actual memory being allocated.
    Since the change modifies the interface, a change to the uncached allocator
    (arch/ia64/kernel/uncached.c) is also required.
    Both Andrey Volkov and Jes Sorenson have expressed a desire that the
    gen_pool allocator not write to the memory being managed. See the
    Signed-off-by: Dean Nelson <>
    Cc: Andrey Volkov <>
    Acked-by: Jes Sorensen <>
    Cc: "Luck, Tony" <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Nov 28, 2005
  1. [PATCH] fix broken lib/genalloc.c

    Chris Humbert authored Linus Torvalds committed
    genalloc improperly stores the sizes of freed chunks, allocates overlapping
    memory regions, and oopses after its in-band data is overwritten.
    Signed-off-by: Chris Humbert <>
    Cc: Jes Sorensen <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Commits on Jun 22, 2005
  1. [PATCH] ia64 uncached alloc

    Jes Sorensen authored Linus Torvalds committed
    This patch contains the ia64 uncached page allocator and the generic
    allocator (genalloc).  The uncached allocator was formerly part of the SN2
    mspec driver but there are several other users of it so it has been split
    off from the driver.
    The generic allocator can be used by device driver to manage special memory
    etc.  The generic allocator is based on the allocator from the sym53c8xx_2
    Various users on ia64 needs uncached memory.  The SGI SN architecture requires
    it for inter-partition communication between partitions within a large NUMA
    cluster.  The specific user for this is the XPC code.  Another application is
    large MPI style applications which use it for synchronization, on SN this can
    be done using special 'fetchop' operations but it also benefits non SN
    hardware which may use regular uncached memory for this purpose.  Performance
    of doing this through uncached vs cached memory is pretty substantial.  This
    is handled by the mspec driver which I will push out in a seperate patch.
    Rather than creating a specific allocator for just uncached memory I came up
    with genalloc which is a generic purpose allocator that can be used by device
    drivers and other subsystems as they please.  For instance to handle onboard
    device memory.  It was derived from the sym53c7xx_2 driver's allocator which
    is also an example of a potential user (I am refraining from modifying sym2
    right now as it seems to have been under fairly heavy development recently).
    On ia64 memory has various properties within a granule, ie.  it isn't safe to
    access memory as uncached within the same granule as currently has memory
    accessed in cached mode.  The regular system therefore doesn't utilize memory
    in the lower granules which is mixed in with device PAL code etc.  The
    uncached driver walks the EFI memmap and pulls out the spill uncached pages
    and sticks them into the uncached pool.  Only after these chunks have been
    utilized, will it start converting regular cached memory into uncached memory.
    Hence the reason for the EFI related code additions.
    Signed-off-by: Jes Sorensen <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
Something went wrong with that request. Please try again.