17 Jun, 2009

1 commit

  • 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

    Zygo Blaxell
     

18 Jul, 2007

1 commit

  • 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

    Christoph Lameter
     

21 Feb, 2007

1 commit

  • 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

    Andrew Morton
     

02 Oct, 2006

2 commits


23 Jun, 2006

1 commit

  • 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
    following:

    http://marc.theaimsgroup.com/?l=linux-kernel&m=113518602713125&w=2
    http://marc.theaimsgroup.com/?l=linux-kernel&m=113533568827916&w=2

    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

    Dean Nelson
     

29 Nov, 2005

1 commit

  • 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

    Chris Humbert
     

22 Jun, 2005

1 commit

  • 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
    driver.

    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

    Jes Sorensen