summaryrefslogtreecommitdiff
path: root/lib (unfollow)
Commit message (Collapse)Author
2016-08-26Revert "Merge remote-tracking branch 'msm-4.4/tmp-510d0a3f' into msm-4.4"Trilok Soni
This reverts commit 9d6fd2c3e9fcfb ("Merge remote-tracking branch 'msm-4.4/tmp-510d0a3f' into msm-4.4"), because it breaks the dump parsing tools due to kernel can be loaded anywhere in the memory now and not fixed at linear mapping. Change-Id: Id416f0a249d803442847d09ac47781147b0d0ee6 Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
2016-05-11extable: add support for relative extables to search and sort routinesArd Biesheuvel
This adds support to the generic search_extable() and sort_extable() implementations for dealing with exception table entries whose fields contain relative offsets rather than absolute addresses. Acked-by: Helge Deller <deller@gmx.de> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: H. Peter Anvin <hpa@linux.intel.com> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit a272858a3c1ecd4a935ba23c66668f81214bd110) Signed-off-by: Alex Shi <alex.shi@linaro.org>
2016-05-11lib/test-string_helpers.c: fix and improve string_get_size() testsVitaly Kuznetsov
commit 72676bb53f33fd0ef3a1484fc1ecfd306dc6ff40 upstream. Recently added commit 564b026fbd0d ("string_helpers: fix precision loss for some inputs") fixed precision issues for string_get_size() and broke tests. Fix and improve them: test both STRING_UNITS_2 and STRING_UNITS_10 at a time, better failure reporting, test small an huge values. Fixes: 564b026fbd0d28e9 ("string_helpers: fix precision loss for some inputs") Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: James Bottomley <JBottomley@Odin.com> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-05-05workqueue: implement lockup detectorTejun Heo
Workqueue stalls can happen from a variety of usage bugs such as missing WQ_MEM_RECLAIM flag or concurrency managed work item indefinitely staying RUNNING. These stalls can be extremely difficult to hunt down because the usual warning mechanisms can't detect workqueue stalls and the internal state is pretty opaque. To alleviate the situation, this patch implements workqueue lockup detector. It periodically monitors all worker_pools periodically and, if any pool failed to make forward progress longer than the threshold duration, triggers warning and dumps workqueue state as follows. BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 31s! Showing busy workqueues and worker pools: workqueue events: flags=0x0 pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=17/256 pending: monkey_wrench_fn, e1000_watchdog, cache_reap, vmstat_shepherd, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, release_one_tty, cgroup_release_agent workqueue events_power_efficient: flags=0x80 pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256 pending: check_lifetime, neigh_periodic_work workqueue cgroup_pidlist_destroy: flags=0x0 pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1 pending: cgroup_pidlist_destroy_work_fn ... The detection mechanism is controller through kernel parameter workqueue.watchdog_thresh and can be updated at runtime through the sysfs module parameter file. v2: Decoupled from softlockup control knobs. CRs-Fixed: 1007459 Change-Id: Id7dfbbd2701128a942b1bcac2299e07a66db8657 Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Don Zickus <dzickus@redhat.com> Cc: Ulrich Obergfell <uobergfe@redhat.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Chris Mason <clm@fb.com> Cc: Andrew Morton <akpm@linux-foundation.org> Git-commit: 82607adcf9cdf40fb7b5331269780c8f70ec6e35 Git-repo: git://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
2016-05-05lib: Makefile: Ignore Kasan errors reported from the find_bitTrilok Soni
This is same as commit c836a400dd1e ("lib: Ignore kasan errors from find_next_bit and last bit") but 4.4 kernel had done the re-org of the find_next_bit.c and find_last_bit.c files and merged them as one file find_bit.c. CRs-Fixed: 1007351 Change-Id: Iff58832a535227ea071ce5b14d537d9993f9dfc2 Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
2016-05-05lib: memtest: Add MEMTEST_ENABLE_DEFAULT optionTrilok Soni
As of now memtest remains disabled until we specify the patterns through the kernel command line. Some platforms have two different configurations files (one for debug and another for product) which can use the configuration option to enable the memtest by default (in the debug configuration file). CRs-Fixed: 1007344 Change-Id: I0bf7b33c3584f3d6cf5ef58dfe72be46212041da Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
2016-05-04lib/mpi: Endianness fixMichal Marek
commit 3ee0cb5fb5eea2110db1b5cb7f67029b7be8a376 upstream. The limbs are integers in the host endianness, so we can't simply iterate over the individual bytes. The current code happens to work on little-endian, because the order of the limbs in the MPI array is the same as the order of the bytes in each limb, but it breaks on big-endian. Fixes: 0f74fbf77d45 ("MPI: Fix mpi_read_buffer") Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-05-04lib: lz4: fixed zram with lz4 on big endian machinesRui Salvaterra
commit 3e26a691fe3fe1e02a76e5bab0c143ace4b137b4 upstream. Based on Sergey's test patch [1], this fixes zram with lz4 compression on big endian cpus. Note that the 64-bit preprocessor test is not a cleanup, it's part of the fix, since those identifiers are bogus (for example, __ppc64__ isn't defined anywhere else in the kernel, which means we'd fall into the 32-bit definitions on ppc64). Tested on ppc64 with no regression on x86_64. [1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4 Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-05-04assoc_array: don't call compare_object() on a nodeJerome Marchand
commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream. Changes since V1: fixed the description and added KASan warning. In assoc_array_insert_into_terminal_node(), we call the compare_object() method on all non-empty slots, even when they're not leaves, passing a pointer to an unexpected structure to compare_object(). Currently it causes an out-of-bound read access in keyring_compare_object detected by KASan (see below). The issue is easily reproduced with keyutils testsuite. Only call compare_object() when the slot is a leave. KASan warning: ================================================================== BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838 Read of size 8 by task keyctl/1655 ============================================================================= BUG kmalloc-192 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647 ___slab_alloc+0x563/0x5c0 __slab_alloc+0x51/0x90 kmem_cache_alloc_trace+0x263/0x300 assoc_array_insert+0xfd0/0x3a60 __key_link_begin+0xfc/0x270 key_create_or_update+0x459/0xaf0 SyS_add_key+0x1ba/0x350 entry_SYSCALL_64_fastpath+0x12/0x76 INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080 INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1 Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00 ...`............ Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff ...`.......`.... Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 0 PID: 1655 Comm: keyctl Tainted: G B 4.5.0-rc4-kasan+ #291 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491 ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969 ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650 Call Trace: [<ffffffff81b60491>] dump_stack+0x85/0xc4 [<ffffffff815e2969>] print_trailer+0xf9/0x150 [<ffffffff815e9454>] object_err+0x34/0x40 [<ffffffff815ebe50>] kasan_report_error+0x230/0x550 [<ffffffff819949be>] ? keyring_get_key_chunk+0x13e/0x210 [<ffffffff815ec62d>] __asan_report_load_n_noabort+0x5d/0x70 [<ffffffff81994cc3>] ? keyring_compare_object+0x213/0x240 [<ffffffff81994cc3>] keyring_compare_object+0x213/0x240 [<ffffffff81bc238c>] assoc_array_insert+0x86c/0x3a60 [<ffffffff81bc1b20>] ? assoc_array_cancel_edit+0x70/0x70 [<ffffffff8199797d>] ? __key_link_begin+0x20d/0x270 [<ffffffff8199786c>] __key_link_begin+0xfc/0x270 [<ffffffff81993389>] key_create_or_update+0x459/0xaf0 [<ffffffff8128ce0d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81992f30>] ? key_type_lookup+0xc0/0xc0 [<ffffffff8199e19d>] ? lookup_user_key+0x13d/0xcd0 [<ffffffff81534763>] ? memdup_user+0x53/0x80 [<ffffffff819983ea>] SyS_add_key+0x1ba/0x350 [<ffffffff81998230>] ? key_get_type_from_user.constprop.6+0xa0/0xa0 [<ffffffff828bcf4e>] ? retint_user+0x18/0x23 [<ffffffff8128cc7e>] ? trace_hardirqs_on_caller+0x3fe/0x580 [<ffffffff81004017>] ? trace_hardirqs_on_thunk+0x17/0x19 [<ffffffff828bc432>] entry_SYSCALL_64_fastpath+0x12/0x76 Memory state around the buggy address: ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc >ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00 ================================================================== Signed-off-by: Jerome Marchand <jmarchan@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-05-03mm/page_owner: ask users about default setting of PAGE_OWNERTrilok Soni
Since this commit 48c96a3685795 ("mm/page_owner: keep track of page owners") doesn't enable the page_owner by default even though CONFIG_PAGE_OWNER is enabled. Add configuration option CONFIG_PAGE_OWNER_ENABLE_DEFAULT to allow user to enable it by default through the defconfig file. CRs-Fixed: 1006743 Change-Id: I9b565a34e2068bf575974eaf3dc9f7820bdd7a96 Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
2016-04-22Revert "kernel: lib: allow larger stack frame size for KASan"Satya Durga Srinivasu Prabhala
This reverts commit 8bb334401c84 ("kernel: lib: allow larger stack frame size for KASan"). Stack frame size set to 5600 to fix compilation error/s if KASAN enabled by the commit 8bb334401c84 ("kernel: lib: allow larger stack frame size for KASan") in 3.18 Kernel and same commit got pulled into Kernel 4.4, which replaced stack frame size 0 with 5600 as part of resolution of merge conflict. But, by setting stack frame size to 0 will ignore stack frame size warnings and so the compilation errors. So, revert commit to fix below error while compiling Kernel 4.4 with KASAN enabled and GCC 5.1 compiler. kernel/net/wireless/nl80211.c: In function 'nl80211_send_wiphy': kernel/net/wireless/nl80211.c:1745:1: warning: the frame size of \ 5760 bytes is larger than 5600 bytes [-Wframe-larger-than=] error, forbidden warning: nl80211.c:1745 make[4]: *** [net/wireless/nl80211.o] Error 1 CRs-Fixed: 1004225 Change-Id: I97e52302197c9933bec5cac3ebdc4ec73fee0816 Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
2016-04-19lib: do_strncpy_from_user: Fix return error code for get_user failuresImran Khan
If byte wise copy fails here, we should return EFAULT. Returning a value other than that would cause failure of some of the user-space test cases. CRs-Fixed: 989314 Change-Id: I38ce12d44f25dc89bdd29e8abacd8777f0a8b9a1 Signed-off-by: Imran Khan <kimran@codeaurora.org>
2016-03-23debugobjects: use kmemleak_not_leak for debug object memoryVignesh Radhakrishnan
debug objects are placed in a list obj_pool which is static. This is placed in __initdata which kmemleak will not scan unless task stack scan is enabled. We have taken the explicit choice of disabling task stack scan by default through the creation of config in the 'commit 7f15dd8a750e ("kmemleak : Make kmemleak_stack_scan optional using config")' Thus kmemleak would think that there is no reference to this and thus we will see this report as leaking memory. Further, this memory would be freed by the debugobjects framework when there is a memory crunch or when the object size exceeds the max limit of ODEBUG_POOL_SIZE. Fix this by using kmemleak_not_leak() when a debug object is allocated to specify explicitly that this is not a leak. Change-Id: I0ce66b1be4e5984681af9fd61883e7010e7bbd1b Signed-off-by: Vignesh Radhakrishnan <vigneshr@codeaurora.org> Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
2016-03-23kmemleak : Make module scanning optional using configVignesh Radhakrishnan
Currently kmemleak scans module memory as provided in the area list. This takes up lot of time with irq's and preemption disabled. Provide a compile time configurable config to enable this functionality. Change-Id: I5117705e7e6726acdf492e7f87c0703bc1f28da0 Signed-off-by: Vignesh Radhakrishnan <vigneshr@codeaurora.org> Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org> [satyap: trivial merge conflict resolution and remove duplicate entry] Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
2016-03-23lib: align source before using optimized implementationSanrio Alvares
If the source is at the boundary of the VMA, loading one word at a time can cause an alignment fault when the adjacent VMA is IO mapped. Do byte-by-byte copy until source aligns to 8 bytes and then continue with optimized version. CRs-Fixed: 973724 Change-Id: I05e085597c58169fc6e275508a907029b9c7ec64 Signed-off-by: Sanrio Alvares <salvares@codeaurora.org>
2016-03-23radix-tree: add radix_tree_gang_lookup_indexVinayak Menon
Add radix_tree_gang_lookup_index to get the radix tree indices along with the pointers. This will be helpful, for e.g. if a radix_tree_delete has to be performed depending on one of the result values. Change-Id: Iab83d027968462aa30da5341fa3f60134b6c1137 Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
2016-03-23sched/debug: Add Kconfig to trigger panics on all 'BUG:' conditionsMatt Wagantall
Introduce CONFIG_PANIC_ON_SCHED_BUG to trigger panics along with all 'BUG:' prints from the scheduler core, even potentially-recoverable ones such as scheduling while atomic, sleeping from invalid context, and detection of broken arch topologies. Change-Id: I5d2f561614604357a2bc7900b047e53b3a0b7c6d Signed-off-by: Matt Wagantall <mattw@codeaurora.org> [joonwoop@codeaurora.org: fixed trivial merge conflict in lib/Kconfig.debug.] Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
2016-03-23sched/debug: Make sysrq prints of sched debug data optionalMatt Wagantall
Calls to sysrq_sched_debug_show() can yield rather verbose output which contributes to log spew and, under heavy load, may increase the chances of a watchdog bark. Make printing of this data optional with the introduction of a new Kconfig, CONFIG_SYSRQ_SCHED_DEBUG. Change-Id: I5f54d901d0dea403109f7ac33b8881d967a899ed Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
2016-03-23sched/rt: Add Kconfig option to enable panicking for RT throttlingMatt Wagantall
This may be useful for detecting and debugging RT throttling issues. Change-Id: I5807a897d11997d76421c1fcaa2918aad988c6c9 Signed-off-by: Matt Wagantall <mattw@codeaurora.org> [rameezmustafa@codeaurora.org]: Port to msm-3.18] Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org> [joonwoop@codeaurora.org: fixed conflict in lib/Kconfig.debug] Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
2016-03-22lib: Kconfig.debug: Fix the recursive dependencyRohit Vaswani
An earlier commit 52a3101ed9b61787a49f3b5c298aa9240f4006dd added a recursive dependency as part of CONFIG_DEBUG_SPINLOCK lib/Kconfig.debug:585:error: recursive dependency detected! lib/Kconfig.debug:585:symbol DEBUG_SPINLOCK_BITE_ON_BUG depends on DEBUG_SPINLOCK_PANIC_ON_BUG lib/Kconfig.debug:593:symbol DEBUG_SPINLOCK_PANIC_ON_BUG depends on DEBUG_SPINLOCK_BITE_ON_BUG Fix this by adding a choice menu. Change-Id: I0e50103397bb71dec7056db5148cba988550b860 Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org> Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
2016-03-22lib: spinlock: Trigger a watchdog bite on spin_dump for rwlockPrasad Sodagudi
Currently dump_stack is printed once a spin_bug is detected for rwlock. So provide an options to trigger a panic or watchdog bite for debugging rwlock magic corruptions and lockups. Change-Id: I20807e8eceb8b81635e58701d1f9f9bd36ab5877 [abhimany: replace msm with qcom] Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org> Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
2016-03-22lib: spinlock: Cause a watchdog bite on spin_dumpRohit Vaswani
Currently we cause a BUG_ON once a spin_bug is detected, but that causes a whole lot of processing and the other CPUs would have proceeded to perform other actions and the state of the system is moved by the time we can analyze it. Provide an option to trigger a watchdog bite instead so that we can get the traces as close to the issue as possible. Change-Id: Ic8d692ebd02c6940a3b4e5798463744db20b0026 Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org> Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
2016-03-22kernel/lib: add additional debug capabilites for data corruptionSyed Rameez Mustafa
Data corruptions in the kernel often end up in system crashes that are easier to debug closer to the time of detection. Specifically, if we do not panic immediately after lock or list corruptions have been detected, the problem context is lost in the ensuing system mayhem. Add support for allowing system crash immediately after such corruptions are detected. The CONFIG option controls the enabling/disabling of the feature. Change-Id: I9b2eb62da506a13007acff63e85e9515145909ff Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org> [abhimany: minor merge conflict resolution] Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
2016-03-22kasan: Kconfig: Add KASAN_SANITIZE_ALLPatrick Daly
Allow enabling KASAN on a per-directory or per-file basis rather than for the entire kernel. Change-Id: I9a491d3ab0df4c42302a258b9edb3b78cf4e1db0 Signed-off-by: Patrick Daly <pdaly@codeaurora.org> [satyap: trivial merge conflict resolution] Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
2016-03-22lib: Ignore kasan errors from find_next_bit and last bitPatrick Daly
find_next_bit and find_last_bit code operates on the unsigned long *addr, and without knowing the size of the actual buffer passed to it, Kasan detects it as invalid Out of Bound read access. find_next_bit and find_last_bit implementation is very generic and it need not to be modified for the Kasan, so we are skipping it from the sanitization. Following is the Kasan error log for the reference. [ 1.262524] BUG: KASan: out of bounds access in find_next_bit+0xa4/0xf0 at addr ffffffc00e9af260 [ 1.262534] Read of size 8 by task swapper/0/1 [ 1.262546] page:ffffffbc00920d60 count:0 mapcount:0 mapping: (null) index:0x0 [ 1.262554] page flags: 0x0() [ 1.262570] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.49-gef71b0c-00348-g4f06d68-dirty #160 [ 1.262577] Call trace: [ 1.262594] [<ffffffc00040a2d4>] dump_backtrace+0x0/0x1d4 [ 1.262610] [<ffffffc00040a4b8>] show_stack+0x10/0x1c [ 1.262625] [<ffffffc000face70>] dump_stack+0x1c/0x28 [ 1.262641] [<ffffffc000552448>] kasan_report_error+0x294/0x3e4 [ 1.262656] [<ffffffc0005526a8>] kasan_report+0x68/0x78 [ 1.262671] [<ffffffc00055169c>] __asan_load8+0x90/0x9c [ 1.262686] [<ffffffc00076fff8>] find_next_bit+0xa0/0xf0 [ 1.262701] [<ffffffc000de37d0>] bam_pipe_set_desc_write_offset+0xc8/0x378 [ 1.262716] [<ffffffc000e005e4>] sps_bam_pipe_transfer_one+0x6b8/0x70c [ 1.262730] [<ffffffc000e04f84>] sps_transfer_one+0x230/0x298 [ 1.262746] [<ffffffc000da4c58>] ipa_replenish_rx_cache+0x2e8/0x430 [ 1.262762] [<ffffffc000da891c>] ipa_setup_sys_pipe+0x14a8/0x22bc [ 1.262779] [<ffffffc000d8a554>] ipa_setup_apps_pipes+0x580/0x6a0 [ 1.262797] [<ffffffc000d91ef0>] ipa_init.constprop.8+0x134c/0x1dd4 [ 1.262814] [<ffffffc000d93038>] ipa_plat_drv_probe+0x6c0/0x720 [ 1.262829] [<ffffffc0009b51e0>] platform_drv_probe+0x2c/0x3c [ 1.262842] [<ffffffc0009b32d0>] driver_probe_device+0x1f4/0x47c [ 1.262856] [<ffffffc0009b3644>] __driver_attach+0x88/0xc0 [ 1.262873] [<ffffffc0009b05b4>] bus_for_each_dev+0xdc/0x11c [ 1.262886] [<ffffffc0009b2a2c>] driver_attach+0x2c/0x3c [ 1.262903] [<ffffffc0009b237c>] bus_add_driver+0x1bc/0x32c [ 1.262916] [<ffffffc0009b3eb0>] driver_register+0x10c/0x1d8 [ 1.262931] [<ffffffc0009b5a28>] platform_driver_register+0x98/0xa8 [ 1.262946] [<ffffffc0018422d4>] ipa_module_init+0x3c/0x48 [ 1.262960] [<ffffffc000400b08>] do_one_initcall+0xcc/0x188 [ 1.262978] [<ffffffc001800bd0>] kernel_init_freeable+0x1c0/0x264 [ 1.262992] [<ffffffc000f9f338>] kernel_init+0x10/0xcc [ 1.263000] Memory state around the buggy address: [ 1.263012] ffffffc00e9af100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1.263024] ffffffc00e9af180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1.263037] >ffffffc00e9af200: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 [ 1.263046] ^ [ 1.263058] ffffffc00e9af280: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 f4 f4 [ 1.263071] ffffffc00e9af300: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 1.263079] ================================================================== Change-Id: I7b7bde5f408dc1f04a773b7a314662ec91344a5e Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
2016-03-22kernel: lib: allow larger stack frame size for KASanSe Wang (Patrick) Oh
Some functions consume more than allowed stack frame size with KASan enabled and GCC warns it as an error. To avoid compilation warning, allow larger stack frame size when KASan is enabled instead of changing each file. Below is one of the warning messages for reference. kernel/net/wireless/nl80211.c: In function 'nl80211_send_wiphy': kernel/net/wireless/nl80211.c:1705:1: warning: the frame size of 5488 bytes is larger than 2048 bytes [-Wframe-larger-than=] Change-Id: I953018f459bf048366f0ba5ff7c980edcd9bbe07 Signed-off-by: Se Wang (Patrick) Oh <sewango@codeaurora.org> [satyap: trivial merge conflict resolution] Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
2016-03-22UBSAN: run-time undefined behavior sanity checkerAndrey Ryabinin
UBSAN uses compile-time instrumentation to catch undefined behavior (UB). Compiler inserts code that perform certain kinds of checks before operations that could cause UB. If check fails (i.e. UB detected) __ubsan_handle_* function called to print error message. So the most of the work is done by compiler. This patch just implements ubsan handlers printing errors. GCC has this capability since 4.9.x [1] (see -fsanitize=undefined option and its suboptions). However GCC 5.x has more checkers implemented [2]. Article [3] has a bit more details about UBSAN in the GCC. [1] - https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html [2] - https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html [3] - http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ Issues which UBSAN has found thus far are: Found bugs: * out-of-bounds access - 97840cb67ff5 ("netfilter: nfnetlink: fix insufficient validation in nfnetlink_bind") undefined shifts: * d48458d4a768 ("jbd2: use a better hash function for the revoke table") * 10632008b9e1 ("clockevents: Prevent shift out of bounds") * 'x << -1' shift in ext4 - http://lkml.kernel.org/r/<5444EF21.8020501@samsung.com> * undefined rol32(0) - http://lkml.kernel.org/r/<1449198241-20654-1-git-send-email-sasha.levin@oracle.com> * undefined dirty_ratelimit calculation - http://lkml.kernel.org/r/<566594E2.3050306@odin.com> * undefined roundown_pow_of_two(0) - http://lkml.kernel.org/r/<1449156616-11474-1-git-send-email-sasha.levin@oracle.com> * [WONTFIX] undefined shift in __bpf_prog_run - http://lkml.kernel.org/r/<CACT4Y+ZxoR3UjLgcNdUm4fECLMx2VdtfrENMtRRCdgHB2n0bJA@mail.gmail.com> WONTFIX here because it should be fixed in bpf program, not in kernel. signed overflows: * 32a8df4e0b33f ("sched: Fix odd values in effective_load() calculations") * mul overflow in ntp - http://lkml.kernel.org/r/<1449175608-1146-1-git-send-email-sasha.levin@oracle.com> * incorrect conversion into rtc_time in rtc_time64_to_tm() - http://lkml.kernel.org/r/<1449187944-11730-1-git-send-email-sasha.levin@oracle.com> * unvalidated timespec in io_getevents() - http://lkml.kernel.org/r/<CACT4Y+bBxVYLQ6LtOKrKtnLthqLHcw-BMp3aqP3mjdAvr9FULQ@mail.gmail.com> * [NOTABUG] signed overflow in ktime_add_safe() - http://lkml.kernel.org/r/<CACT4Y+aJ4muRnWxsUe1CMnA6P8nooO33kwG-c8YZg=0Xc8rJqw@mail.gmail.com> [akpm@linux-foundation.org: fix unused local warning] [akpm@linux-foundation.org: fix __int128 build woes] Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Michal Marek <mmarek@suse.cz> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Yury Gribov <y.gribov@samsung.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Kostya Serebryany <kcc@google.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Git-repo: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Git-commit: c6d308534aef6c99904bf5862066360ae067abc4 [tsoni@codeaurora.org: trivial merge conflict resolution] CRs-Fixed: 969533 Change-Id: I048b9936b1120e0d375b7932c59de78d8ef8f411 Signed-off-by: Trilok Soni <tsoni@codeaurora.org> [satyap@codeaurora.org: trivial merge conflict resolution] Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
2016-03-22Revert "net, lib: kill arch_fast_hash library bits"Rohit Vaswani
This reverts commit 0cb6c969ed9de43687abdfc63714b6fe4385d2fc.
2016-03-22soc: qcom: Add snapshot of QMIKarthikeyan Ramasubramanian
This snapshot is taken as of msm-3.18 commit e70ad0cd (Promotion of kernel.lnx.3.18-151201.) Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
2016-03-22kmemleak : Make kmemleak_stack_scan optional using configVignesh Radhakrishnan
Currently we have kmemleak_stack_scan enabled by default. This can hog the cpu with pre-emption disabled for a long time starving other tasks. Make this optional at compile time, since if required we can always write to sysfs entry and enable this option. Change-Id: Ie30447861c942337c7ff25ac269b6025a527e8eb Signed-off-by: Vignesh Radhakrishnan <vigneshr@codeaurora.org> Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
2016-03-22kmemleak : Make kmemleak_stack_scan optional using configVignesh Radhakrishnan
Currently we have kmemleak_stack_scan enabled by default. This can hog the cpu with pre-emption disabled for a long time starving other tasks. Make this optional at compile time, since if required we can always write to sysfs entry and enable this option. Change-Id: Ie30447861c942337c7ff25ac269b6025a527e8eb Signed-off-by: Vignesh Radhakrishnan <vigneshr@codeaurora.org> Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
2016-03-22scsi: ufs: Inject errors to verify error handlingSujit Reddy Thumma
Use fault-injection framework to simulate error conditions in the controller and verify error handling mechanisms implemented in UFS host controller driver. This is used only during development and hence guarded by CONFIG_UFS_FAULT_INJECTION debug config option. Change-Id: Ia63c276c5e56d677a92332b42b670300ad82af7a Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org> [venkatg@codeaurora.org: resolved trivial merge conflicts] Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
2016-03-03lib: sw842: select crc32Arnd Bergmann
commit 5b57167749274961baf15ed1f05a4996b3ab0487 upstream. The sw842 library code was merged in linux-4.1 and causes a very rare randconfig failure when CONFIG_CRC32 is not set: lib/built-in.o: In function `sw842_compress': oid_registry.c:(.text+0x12ddc): undefined reference to `crc32_be' lib/built-in.o: In function `sw842_decompress': oid_registry.c:(.text+0x137e4): undefined reference to `crc32_be' This adds an explict 'select CRC32' statement, similar to what the other users of the crc32 code have. In practice, CRC32 is always enabled anyway because over 100 other symbols select it. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 2da572c959dd ("lib: add software 842 compression/decompression") Acked-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-03lib/ucs2_string: Correct ucs2 -> utf8 conversionJason Andryuk
commit a68075908a37850918ad96b056acc9ac4ce1bd90 upstream. The comparisons should be >= since 0x800 and 0x80 require an additional bit to store. For the 3 byte case, the existing shift would drop off 2 more bits than intended. For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in byte 2. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@coreos.com> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-03lib/ucs2_string: Add ucs2 -> utf8 helper functionsPeter Jones
commit 73500267c930baadadb0d02284909731baf151f7 upstream. This adds ucs2_utf8size(), which tells us how big our ucs2 string is in bytes, and ucs2_as_utf8, which translates from ucs2 to utf8.. Signed-off-by: Peter Jones <pjones@redhat.com> Tested-by: Lee, Chun-Yi <jlee@suse.com> Acked-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-01lib: iomap: Add MSM RTB supportRohit Vaswani
The ioread* and the iowrite* functions and not inlined and hence the RTB logs end up containing the ioread and iowrite functions themselves and not the ones invoking them. Add RTB support to the ioread*and iowrite* functions so that we can get meaningful RTB logs. Note that to avoid multiple RTB logs for ioread* and iowrite* functions, read*_no_log and write*_no_log macros are added. Change-Id: I2315d44c4dfbeee6be4a52f21bf4a20dd9508597 Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org> Signed-off-by: David Keitel <dkeitel@codeaurora.org> Conflicts: arch/arm64/include/asm/io.h
2016-02-25dump_stack: avoid potential deadlocksEric Dumazet
commit d7ce36924344ace0dbdc855b1206cacc46b36d45 upstream. Some servers experienced fatal deadlocks because of a combination of bugs, leading to multiple cpus calling dump_stack(). The checksumming bug was fixed in commit 34ae6a1aa054 ("ipv6: update skb->csum when CE mark is propagated"). The second problem is a faulty locking in dump_stack() CPU1 runs in process context and calls dump_stack(), grabs dump_lock. CPU2 receives a TCP packet under softirq, grabs socket spinlock, and call dump_stack() from netdev_rx_csum_fault(). dump_stack() spins on atomic_cmpxchg(&dump_lock, -1, 2), since dump_lock is owned by CPU1 While dumping its stack, CPU1 is interrupted by a softirq, and happens to process a packet for the TCP socket locked by CPU2. CPU1 spins forever in spin_lock() : deadlock Stack trace on CPU1 looked like : NMI backtrace for cpu 1 RIP: _raw_spin_lock+0x25/0x30 ... Call Trace: <IRQ> tcp_v6_rcv+0x243/0x620 ip6_input_finish+0x11f/0x330 ip6_input+0x38/0x40 ip6_rcv_finish+0x3c/0x90 ipv6_rcv+0x2a9/0x500 process_backlog+0x461/0xaa0 net_rx_action+0x147/0x430 __do_softirq+0x167/0x2d0 call_softirq+0x1c/0x30 do_softirq+0x3f/0x80 irq_exit+0x6e/0xc0 smp_call_function_single_interrupt+0x35/0x40 call_function_single_interrupt+0x6a/0x70 <EOI> printk+0x4d/0x4f printk_address+0x31/0x33 print_trace_address+0x33/0x3c print_context_stack+0x7f/0x119 dump_trace+0x26b/0x28e show_trace_log_lvl+0x4f/0x5c show_stack_log_lvl+0x104/0x113 show_stack+0x42/0x44 dump_stack+0x46/0x58 netdev_rx_csum_fault+0x38/0x3c __skb_checksum_complete_head+0x6e/0x80 __skb_checksum_complete+0x11/0x20 tcp_rcv_established+0x2bd5/0x2fd0 tcp_v6_do_rcv+0x13c/0x620 sk_backlog_rcv+0x15/0x30 release_sock+0xd2/0x150 tcp_recvmsg+0x1c1/0xfc0 inet_recvmsg+0x7d/0x90 sock_recvmsg+0xaf/0xe0 ___sys_recvmsg+0x111/0x3b0 SyS_recvmsg+0x5c/0xb0 system_call_fastpath+0x16/0x1b Fixes: b58d977432c8 ("dump_stack: serialize the output from dump_stack()") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Alex Thorlton <athorlton@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25radix-tree: fix race in gang lookupMatthew Wilcox
commit 46437f9a554fbe3e110580ca08ab703b59f2f95a upstream. If the indirect_ptr bit is set on a slot, that indicates we need to redo the lookup. Introduce a new function radix_tree_iter_retry() which forces the loop to retry the lookup by setting 'slot' to NULL and turning the iterator back to point at the problematic entry. This is a pretty rare problem to hit at the moment; the lookup has to race with a grow of the radix tree from a height of 0. The consequences of hitting this race are that gang lookup could return a pointer to a radix_tree_node instead of a pointer to whatever the user had inserted in the tree. Fixes: cebbd29e1c2f ("radix-tree: rewrite gang lookup using iterator") Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25dma-debug: switch check from _text to _stextLaura Abbott
commit ea535e418c01837d07b6c94e817540f50bfdadb0 upstream. In include/asm-generic/sections.h: /* * Usage guidelines: * _text, _data: architecture specific, don't use them in * arch-independent code * [_stext, _etext]: contains .text.* sections, may also contain * .rodata.* * and/or .init.* sections _text is not guaranteed across architectures. Architectures such as ARM may reuse parts which are not actually text and erroneously trigger a bug. Switch to using _stext which is guaranteed to contain text sections. Came out of https://lkml.kernel.org/g/<567B1176.4000106@redhat.com> Signed-off-by: Laura Abbott <labbott@fedoraproject.org> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25string_helpers: fix precision loss for some inputsJames Bottomley
commit 564b026fbd0d28e9f70fb3831293d2922bb7855b upstream. It was noticed that we lose precision in the final calculation for some inputs. The most egregious example is size=3000 blk_size=1900 in units of 10 should yield 5.70 MB but in fact yields 3.00 MB (oops). This is because the current algorithm doesn't correctly account for all the remainders in the logarithms. Fix this by doing a correct calculation in the remainders based on napier's algorithm. Additionally, now we have the correct result, we have to account for arithmetic rounding because we're printing 3 digits of precision. This means that if the fourth digit is five or greater, we have to round up, so add a section to ensure correct rounding. Finally account for all possible inputs correctly, including zero for block size. Fixes: b9f28d863594c429e1df35a0474d2663ca28b307 Signed-off-by: James Bottomley <JBottomley@Odin.com> Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25klist: fix starting point removed bug in klist iteratorsJames Bottomley
commit 00cd29b799e3449f0c68b1cc77cd4a5f95b42d17 upstream. The starting node for a klist iteration is often passed in from somewhere way above the klist infrastructure, meaning there's no guarantee the node is still on the list. We've seen this in SCSI where we use bus_find_device() to iterate through a list of devices. In the face of heavy hotplug activity, the last device returned by bus_find_device() can be removed before the next call. This leads to Dec 3 13:22:02 localhost kernel: WARNING: CPU: 2 PID: 28073 at include/linux/kref.h:47 klist_iter_init_node+0x3d/0x50() Dec 3 13:22:02 localhost kernel: Modules linked in: scsi_debug x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel joydev iTCO_wdt dcdbas ipmi_devintf acpi_power_meter iTCO_vendor_support ipmi_si imsghandler pcspkr wmi acpi_cpufreq tpm_tis tpm shpchp lpc_ich mfd_core nfsd nfs_acl lockd grace sunrpc tg3 ptp pps_core Dec 3 13:22:02 localhost kernel: CPU: 2 PID: 28073 Comm: cat Not tainted 4.4.0-rc1+ #2 Dec 3 13:22:02 localhost kernel: Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013 Dec 3 13:22:02 localhost kernel: ffffffff81a20e77 ffff880613acfd18 ffffffff81321eef 0000000000000000 Dec 3 13:22:02 localhost kernel: ffff880613acfd50 ffffffff8107ca52 ffff88061176b198 0000000000000000 Dec 3 13:22:02 localhost kernel: ffffffff814542b0 ffff880610cfb100 ffff88061176b198 ffff880613acfd60 Dec 3 13:22:02 localhost kernel: Call Trace: Dec 3 13:22:02 localhost kernel: [<ffffffff81321eef>] dump_stack+0x44/0x55 Dec 3 13:22:02 localhost kernel: [<ffffffff8107ca52>] warn_slowpath_common+0x82/0xc0 Dec 3 13:22:02 localhost kernel: [<ffffffff814542b0>] ? proc_scsi_show+0x20/0x20 Dec 3 13:22:02 localhost kernel: [<ffffffff8107cb4a>] warn_slowpath_null+0x1a/0x20 Dec 3 13:22:02 localhost kernel: [<ffffffff8167225d>] klist_iter_init_node+0x3d/0x50 Dec 3 13:22:02 localhost kernel: [<ffffffff81421d41>] bus_find_device+0x51/0xb0 Dec 3 13:22:02 localhost kernel: [<ffffffff814545ad>] scsi_seq_next+0x2d/0x40 [...] And an eventual crash. It can actually occur in any hotplug system which has a device finder and a starting device. We can fix this globally by making sure the starting node for klist_iter_init_node() is actually a member of the list before using it (and by starting from the beginning if it isn't). Reported-by: Ewan D. Milne <emilne@redhat.com> Tested-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-17crypto: crc32c - Fix crc32c soft dependencyJean Delvare
commit fd7f6727102a1ccf6b4c1dfcc631f9b546526b26 upstream. I don't think it makes sense for a module to have a soft dependency on itself. This seems quite cyclic by nature and I can't see what purpose it could serve. OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty much assumes that some incarnation of the "crc32c" hash algorithm has been loaded. Therefore it makes sense to have the soft dependency there (as crc-t10dif does.) Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-16hardlockup: detect hard lockups without NMIs using secondary cpusColin Cross
Emulate NMIs on systems where they are not available by using timer interrupts on other cpus. Each cpu will use its softlockup hrtimer to check that the next cpu is processing hrtimer interrupts by verifying that a counter is increasing. This patch is useful on systems where the hardlockup detector is not available due to a lack of NMIs, for example most ARM SoCs. Without this patch any cpu stuck with interrupts disabled can cause a hardware watchdog reset with no debugging information, but with this patch the kernel can detect the lockup and panic, which can result in useful debugging info. Change-Id: Ia5faf50243e19c1755201212e04c8892d929785a Signed-off-by: Colin Cross <ccross@android.com>
2015-12-18rhashtable: Kill harmless RCU warning in rhashtable_walk_initHerbert Xu
The commit c6ff5268293ef98e48a99597e765ffc417e39fa5 ("rhashtable: Fix walker list corruption") causes a suspicious RCU usage warning because we no longer hold ht->mutex when we dereference ht->tbl. However, this is a false positive because we now hold ht->lock which also guarantees that ht->tbl won't disppear from under us. This patch kills the warning by using rcu_dereference_protected. Reported-by: kernel test robot <ying.huang@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-16dma-debug: Fix dma_debug_entry offset calculationDaniel Mentz
dma-debug uses struct dma_debug_entry to keep track of dma coherent memory allocation requests. The virtual address is converted into a pfn and an offset. Previously, the offset was calculated using an incorrect bit mask. As a result, we saw incorrect error messages from dma-debug like the following: "DMA-API: exceeded 7 overlapping mappings of cacheline 0x03e00000" Cacheline 0x03e00000 does not exist on our platform. Cc: <stable@vger.kernel.org> Fixes: 0abdd7a81b7e ("dma-debug: introduce debug_dma_assert_idle()") Signed-off-by: Daniel Mentz <danielmentz@google.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-12-16rhashtable: Fix walker list corruptionHerbert Xu
The commit ba7c95ea3870fe7b847466d39a049ab6f156aa2c ("rhashtable: Fix sleeping inside RCU critical section in walk_stop") introduced a new spinlock for the walker list. However, it did not convert all existing users of the list over to the new spin lock. Some continued to use the old mutext for this purpose. This obviously led to corruption of the list. The fix is to use the spin lock everywhere where we touch the list. This also allows us to do rcu_rad_lock before we take the lock in rhashtable_walk_start. With the old mutex this would've deadlocked but it's safe with the new spin lock. Fixes: ba7c95ea3870 ("rhashtable: Fix sleeping inside RCU...") Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-16rhashtable: Enforce minimum size on initial hash tableHerbert Xu
William Hua <william.hua@canonical.com> wrote: > > I wasn't aware there was an enforced minimum size. I simply set the > nelem_hint in the rhastable_params struct to 1, expecting it to grow as > needed. This caused a segfault afterwards when trying to insert an > element. OK we're doing the size computation before we enforce the limit on min_size. ---8<--- We need to do the initial hash table size computation after we have obtained the correct min_size/max_size parameters. Otherwise we may end up with a hash table whose size is outside the allowed envelope. Fixes: a998f712f77e ("rhashtable: Round up/down min/max_size to...") Reported-by: William Hua <william.hua@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-05Revert "rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation"David S. Miller
This reverts commit d3716f18a7d841565c930efde30737a3557eee69. vmalloc cannot be used in BH disabled contexts, even with GFP_ATOMIC. And we certainly want to support rhashtable users inserting entries with software interrupts disabled. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04rhashtable: Use __vmalloc with GFP_ATOMIC for table allocationHerbert Xu
When an rhashtable user pounds rhashtable hard with back-to-back insertions we may end up growing the table in GFP_ATOMIC context. Unfortunately when the table reaches a certain size this often fails because we don't have enough physically contiguous pages to hold the new table. Eric Dumazet suggested (and in fact wrote this patch) using __vmalloc instead which can be used in GFP_ATOMIC context. Reported-by: Phil Sutter <phil@nwl.cc> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04rhashtable: Prevent spurious EBUSY errors on insertionHerbert Xu
Thomas and Phil observed that under stress rhashtable insertion sometimes failed with EBUSY, even though this error should only ever been seen when we're under attack and our hash chain length has grown to an unacceptable level, even after a rehash. It turns out that the logic for detecting whether there is an existing rehash is faulty. In particular, when two threads both try to grow the same table at the same time, one of them may see the newly grown table and thus erroneously conclude that it had been rehashed. This is what leads to the EBUSY error. This patch fixes this by remembering the current last table we used during insertion so that rhashtable_insert_rehash can detect when another thread has also done a resize/rehash. When this is detected we will give up our resize/rehash and simply retry the insertion with the new table. Reported-by: Thomas Graf <tgraf@suug.ch> Reported-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Tested-by: Phil Sutter <phil@nwl.cc> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-06 16:50:25 +0000