10 Oct, 2014

2 commits

  • Remove 3 brace coding style for any arm of this statement

    Signed-off-by: Paul McQuade
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul McQuade
     
  • cat /sys/.../pools followed by removal the device leads to:

    |======================================================
    |[ INFO: possible circular locking dependency detected ]
    |3.17.0-rc4+ #1498 Not tainted
    |-------------------------------------------------------
    |rmmod/2505 is trying to acquire lock:
    | (s_active#28){++++.+}, at: [] kernfs_remove_by_name_ns+0x3c/0x88
    |
    |but task is already holding lock:
    | (pools_lock){+.+.+.}, at: [] dma_pool_destroy+0x18/0x17c
    |
    |which lock already depends on the new lock.
    |the existing dependency chain (in reverse order) is:
    |
    |-> #1 (pools_lock){+.+.+.}:
    | [] show_pools+0x30/0xf8
    | [] dev_attr_show+0x1c/0x48
    | [] sysfs_kf_seq_show+0x88/0x10c
    | [] kernfs_seq_show+0x24/0x28
    | [] seq_read+0x1b8/0x480
    | [] vfs_read+0x8c/0x148
    | [] SyS_read+0x40/0x8c
    | [] ret_fast_syscall+0x0/0x48
    |
    |-> #0 (s_active#28){++++.+}:
    | [] __kernfs_remove+0x258/0x2ec
    | [] kernfs_remove_by_name_ns+0x3c/0x88
    | [] dma_pool_destroy+0x148/0x17c
    | [] hcd_buffer_destroy+0x20/0x34
    | [] usb_remove_hcd+0x110/0x1a4

    The problem is the lock order of pools_lock and kernfs_mutex in
    dma_pool_destroy() vs show_pools() call path.

    This patch breaks out the creation of the sysfs file outside of the
    pools_lock mutex. The newly added pools_reg_lock ensures that there is no
    race of create vs destroy code path in terms whether or not the sysfs file
    has to be deleted (and was it deleted before we try to create a new one)
    and what to do if device_create_file() failed.

    Signed-off-by: Sebastian Andrzej Siewior
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sebastian Andrzej Siewior
     

19 Sep, 2014

1 commit

  • dma_pool_create() needs to unlock the mutex in error case. The bug was
    introduced in the 3.16 by commit cc6b664aa26d ("mm/dmapool.c: remove
    redundant NULL check for dev in dma_pool_create()")/

    Signed-off-by: Krzysztof Hałasa
    Cc: stable@vger.kernel.org # v3.16
    Signed-off-by: Linus Torvalds

    Krzysztof Hałasa
     

05 Jun, 2014

2 commits


05 May, 2014

1 commit


12 Dec, 2012

1 commit


11 Dec, 2012

1 commit

  • dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
    regardless the flags provided by the caller. This causes excessive
    pruning of emergency memory pools without any good reason. Additionaly,
    on ARM architecture any driver which is using dmapools will sooner or
    later trigger the following error:
    "ERROR: 256 KiB atomic DMA coherent pool is too small!
    Please increase it with coherent_pool= kernel parameter!".
    Increasing the coherent pool size usually doesn't help much and only
    delays such error, because all GFP_ATOMIC DMA allocations are always
    served from the special, very limited memory pool.

    This patch changes the dmapool code to correctly use gfp flags provided
    by the dmapool caller.

    Reported-by: Soeren Moch
    Reported-by: Thomas Petazzoni
    Signed-off-by: Marek Szyprowski
    Tested-by: Andrew Lunn
    Tested-by: Soeren Moch
    Cc: stable@vger.kernel.org

    Marek Szyprowski
     

31 Oct, 2011

2 commits


26 Jul, 2011

1 commit

  • devres uses the pointer value as key after it's freed, which is safe but
    triggers spurious use-after-free warnings on some static analysis tools.
    Rearrange code to avoid such warnings.

    Signed-off-by: Maxin B. John
    Reviewed-by: Rolf Eike Beer
    Acked-by: Tejun Heo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Maxin B John
     

14 Jan, 2011

2 commits

  • As it stands this code will degenerate into a busy-wait if the calling task
    has signal_pending().

    Cc: Rolf Eike Beer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • dma_pool_free() scans for the page to free in the pool list holding the
    pool lock. Then it releases the lock basically to acquire it immediately
    again. Modify the code to only take the lock once.

    This will do some additional loops and computations with the lock held in
    if memory debugging is activated. If it is not activated the only new
    operations with this lock is one if and one substraction.

    Signed-off-by: Rolf Eike Beer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rolf Eike Beer
     

27 Oct, 2010

1 commit

  • Buggy drivers (e.g. fsl_udc) could call dma_pool_alloc from atomic
    context with GFP_KERNEL. In most instances, the first pool_alloc_page
    call would succeed and the sleeping functions would never be called. This
    allowed the buggy drivers to slip through the cracks.

    Add a might_sleep_if() checking for __GFP_WAIT in flags.

    Signed-off-by: Dima Zavin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dima Zavin
     

01 Jul, 2009

1 commit


28 Apr, 2008

1 commit

  • Previously it was only enabled for CONFIG_DEBUG_SLAB.

    Not hooked into the slub runtime debug configuration, so you currently only
    get it with CONFIG_SLUB_DEBUG_ON, not plain CONFIG_SLUB_DEBUG

    Acked-by: Matthew Wilcox
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

04 Dec, 2007

7 commits