user/sven/linux.git/mm/dmapool.c, branch v4.1.6

mm/dmapool.c: fixed a brace coding style issue

2014-10-10T02:26:00Z

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

mm: dmapool: add/remove sysfs file outside of the pool lock lock

2014-10-10T02:25:59Z

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

Fix unbalanced mutex in dma_pool_create().

2014-09-18T17:39:16Z

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

mm/dmapool.c: reuse devres_release() to free resources

2014-06-04T23:54:08Z

Instead of calling an additional routine in dmam_pool_destroy() rely on what dmam_pool_release() is doing. Signed-off-by: Andy Shevchenko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mm/dmapool.c: remove redundant NULL check for dev in dma_pool_create()

2014-06-04T23:54:04Z

"dev" cannot be NULL because it is already checked before calling dma_pool_create(). If dev ever was NULL, the code would oops in dev_to_node() after enabling CONFIG_NUMA. It is possible that some driver is using dev==NULL and has never been run on a NUMA machine. Such a driver is probably outdated, possibly buggy and will need some attention if it starts triggering NULL derefs. Signed-off-by: Daeseok Youn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mm: Fix printk typo in dmapool.c

2014-05-05T13:44:47Z

Fix printk typo in dmapool.c Signed-off-by: Hiroshige Sato Signed-off-by: Jiri Kosina

dmapool: make DMAPOOL_DEBUG detect corruption of free marker

2012-12-12T01:22:24Z

This can help to catch the case where hardware is writing after dma free. [akpm@linux-foundation.org: tidy code, fix comment, use sizeof(page->offset), use pr_err()] Signed-off-by: Matthieu Castet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

2012-12-11T08:28:08Z

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

mm: fix implicit stat.h usage in dmapool.c

2011-10-31T13:20:12Z

The removal of the implicitly everywhere module.h and its child includes will reveal this implicit stat.h usage: mm/dmapool.c:108: error: ‘S_IRUGO’ undeclared here (not in a function) Signed-off-by: Paul Gortmaker

mm: Map most files to use export.h instead of module.h

2011-10-31T13:20:12Z

The files changed within are only using the EXPORT_SYMBOL macro variants. They are not using core modular infrastructure and hence don't need module.h but only the export.h header. Signed-off-by: Paul Gortmaker