aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-02-21mm, page_alloc: fix a division by zero error when boosting watermarks v2Mel Gorman1-0/+12
Yury Norov reported that an arm64 KVM instance could not boot since after v5.0-rc1 and could addressed by reverting the patches 1c30844d2dfe272d58c ("mm: reclaim small amounts of memory when an external 73444bc4d8f92e46a20 ("mm, page_alloc: do not wake kswapd with zone lock held") The problem is that a division by zero error is possible if boosting occurs very early in boot if the system has very little memory. This patch avoids the division by zero error. Link: http://lkml.kernel.org/r/[email protected] Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs") Signed-off-by: Mel Gorman <[email protected]> Reported-by: Yury Norov <[email protected]> Tested-by: Yury Norov <[email protected]> Tested-by: Will Deacon <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: David Rientjes <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Catalin Marinas <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21mm/debug.c: fix __dump_page() for poisoned pagesRobin Murphy1-1/+3
Evaluating page_mapping() on a poisoned page ends up dereferencing junk and making PF_POISONED_CHECK() considerably crashier than intended: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000006 Mem abort info: ESR = 0x96000005 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c2f6ac38 [0000000000000006] pgd=0000000000000000, pud=0000000000000000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 491 Comm: bash Not tainted 5.0.0-rc1+ #1 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Dec 17 2018 pstate: 00000005 (nzcv daif -PAN -UAO) pc : page_mapping+0x18/0x118 lr : __dump_page+0x1c/0x398 Process bash (pid: 491, stack limit = 0x000000004ebd4ecd) Call trace: page_mapping+0x18/0x118 __dump_page+0x1c/0x398 dump_page+0xc/0x18 remove_store+0xbc/0x120 dev_attr_store+0x18/0x28 sysfs_kf_write+0x40/0x50 kernfs_fop_write+0x130/0x1d8 __vfs_write+0x30/0x180 vfs_write+0xb4/0x1a0 ksys_write+0x60/0xd0 __arm64_sys_write+0x18/0x20 el0_svc_common+0x94/0xf8 el0_svc_handler+0x68/0x70 el0_svc+0x8/0xc Code: f9400401 d1000422 f240003f 9a801040 (f9400402) ---[ end trace cdb5eb5bf435cecb ]--- Fix that by not inspecting the mapping until we've determined that it's likely to be valid. Now the above condition still ends up stopping the kernel, but in the correct manner: page:ffffffbf20000000 is uninitialized and poisoned raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) ------------[ cut here ]------------ kernel BUG at ./include/linux/mm.h:1006! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 483 Comm: bash Not tainted 5.0.0-rc1+ #3 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Dec 17 2018 pstate: 40000005 (nZcv daif -PAN -UAO) pc : remove_store+0xbc/0x120 lr : remove_store+0xbc/0x120 ... Link: http://lkml.kernel.org/r/03b53ee9d7e76cda4b9b5e1e31eea080db033396.1550071778.git.robin.murphy@arm.com Fixes: 1c6fb1d89e73 ("mm: print more information about mapping in __dump_page") Signed-off-by: Robin Murphy <[email protected]> Acked-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21proc, oom: do not report alien mms when setting oom_score_adjMichal Hocko1-4/+0
Tetsuo has reported that creating a thousands of processes sharing MM without SIGHAND (aka alien threads) and setting /proc/<pid>/oom_score_adj will swamp the kernel log and takes ages [1] to finish. This is especially worrisome that all that printing is done under RCU lock and this can potentially trigger RCU stall or softlockup detector. The primary reason for the printk was to catch potential users who might depend on the behavior prior to 44a70adec910 ("mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj") but after more than 2 years without a single report I guess it is safe to simply remove the printk altogether. The next step should be moving oom_score_adj over to the mm struct and remove all the tasks crawling as suggested by [2] [1] http://lkml.kernel.org/r/[email protected] [2] http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Michal Hocko <[email protected]> Reported-by: Tetsuo Handa <[email protected]> Acked-by: Johannes Weiner <[email protected]> Cc: David Rientjes <[email protected]> Cc: Yong-Taek Lee <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21slub: fix SLAB_CONSISTENCY_CHECKS + KASAN_SW_TAGSQian Cai1-0/+1
Enabling SLUB_DEBUG's SLAB_CONSISTENCY_CHECKS with KASAN_SW_TAGS triggers endless false positives during boot below due to check_valid_pointer() checks tagged pointers which have no addresses that is valid within slab pages: BUG radix_tree_node (Tainted: G B ): Freelist Pointer check fails ----------------------------------------------------------------------------- INFO: Slab objects=69 used=69 fp=0x (null) flags=0x7ffffffc000200 INFO: Object @offset=15060037153926966016 fp=0x Redzone: bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 18 6b 06 00 08 80 ff d0 .........k...... Object : 18 6b 06 00 08 80 ff d0 00 00 00 00 00 00 00 00 .k.............. Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Redzone: bb bb bb bb bb bb bb bb ........ Padding: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ CPU: 0 PID: 0 Comm: swapper/0 Tainted: G B 5.0.0-rc5+ #18 Call trace: dump_backtrace+0x0/0x450 show_stack+0x20/0x2c __dump_stack+0x20/0x28 dump_stack+0xa0/0xfc print_trailer+0x1bc/0x1d0 object_err+0x40/0x50 alloc_debug_processing+0xf0/0x19c ___slab_alloc+0x554/0x704 kmem_cache_alloc+0x2f8/0x440 radix_tree_node_alloc+0x90/0x2fc idr_get_free+0x1e8/0x6d0 idr_alloc_u32+0x11c/0x2a4 idr_alloc+0x74/0xe0 worker_pool_assign_id+0x5c/0xbc workqueue_init_early+0x49c/0xd50 start_kernel+0x52c/0xac4 FIX radix_tree_node: Marking all objects used Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Qian Cai <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21kasan, slub: fix more conflicts with CONFIG_SLAB_FREELIST_HARDENEDAndrey Konovalov1-1/+12
When CONFIG_KASAN_SW_TAGS is enabled, ptr_addr might be tagged. Normally, this doesn't cause any issues, as both set_freepointer() and get_freepointer() are called with a pointer with the same tag. However, there are some issues with CONFIG_SLUB_DEBUG code. For example, when __free_slub() iterates over objects in a cache, it passes untagged pointers to check_object(). check_object() in turns calls get_freepointer() with an untagged pointer, which causes the freepointer to be restored incorrectly. Add kasan_reset_tag to freelist_ptr(). Also add a detailed comment. Link: http://lkml.kernel.org/r/bf858f26ef32eb7bd24c665755b3aee4bc58d0e4.1550103861.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <[email protected]> Reported-by: Qian Cai <[email protected]> Tested-by: Qian Cai <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENEDAndrey Konovalov1-13/+7
CONFIG_SLAB_FREELIST_HARDENED hashes freelist pointer with the address of the object where the pointer gets stored. With tag based KASAN we don't account for that when building freelist, as we call set_freepointer() with the first argument untagged. This patch changes the code to properly propagate tags throughout the loop. Link: http://lkml.kernel.org/r/3df171559c52201376f246bf7ce3184fe21c1dc7.1549921721.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <[email protected]> Reported-by: Qian Cai <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Vincenzo Frascino <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: Evgeniy Stepanov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21kasan, slub: move kasan_poison_slab hook before page_addressAndrey Konovalov1-4/+15
With tag based KASAN page_address() looks at the page flags to see whether the resulting pointer needs to have a tag set. Since we don't want to set a tag when page_address() is called on SLAB pages, we call page_kasan_tag_reset() in kasan_poison_slab(). However in allocate_slab() page_address() is called before kasan_poison_slab(). Fix it by changing the order. [[email protected]: fix compilation error when CONFIG_SLUB_DEBUG=n] Link: http://lkml.kernel.org/r/ac27cc0bbaeb414ed77bcd6671a877cf3546d56e.1550066133.git.andreyknvl@google.com Link: http://lkml.kernel.org/r/cd895d627465a3f1c712647072d17f10883be2a1.1549921721.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Rientjes <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Evgeniy Stepanov <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Qian Cai <[email protected]> Cc: Vincenzo Frascino <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21kmemleak: account for tagged pointers when calculating pointer rangeAndrey Konovalov4-3/+10
kmemleak keeps two global variables, min_addr and max_addr, which store the range of valid (encountered by kmemleak) pointer values, which it later uses to speed up pointer lookup when scanning blocks. With tagged pointers this range will get bigger than it needs to be. This patch makes kmemleak untag pointers before saving them to min_addr and max_addr and when performing a lookup. Link: http://lkml.kernel.org/r/16e887d442986ab87fe87a755815ad92fa431a5f.1550066133.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <[email protected]> Tested-by: Qian Cai <[email protected]> Acked-by: Catalin Marinas <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Rientjes <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Evgeniy Stepanov <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Vincenzo Frascino <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21kasan, kmemleak: pass tagged pointers to kmemleakAndrey Konovalov3-6/+5
Right now we call kmemleak hooks before assigning tags to pointers in KASAN hooks. As a result, when an objects gets allocated, kmemleak sees a differently tagged pointer, compared to the one it sees when the object gets freed. Fix it by calling KASAN hooks before kmemleak's ones. Link: http://lkml.kernel.org/r/cd825aa4897b0fc37d3316838993881daccbe9f5.1549921721.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <[email protected]> Reported-by: Qian Cai <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Rientjes <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Evgeniy Stepanov <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Vincenzo Frascino <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21kasan: fix assigning tags twiceAndrey Konovalov1-12/+17
When an object is kmalloc()'ed, two hooks are called: kasan_slab_alloc() and kasan_kmalloc(). Right now we assign a tag twice, once in each of the hooks. Fix it by assigning a tag only in the former hook. Link: http://lkml.kernel.org/r/ce8c6431da735aa7ec051fd6497153df690eb021.1549921721.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Rientjes <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Evgeniy Stepanov <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Qian Cai <[email protected]> Cc: Vincenzo Frascino <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21numa: change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODESRalph Campbell1-3/+3
The system call, get_mempolicy() [1], passes an unsigned long *nodemask pointer and an unsigned long maxnode argument which specifies the length of the user's nodemask array in bits (which is rounded up). The manual page says that if the maxnode value is too small, get_mempolicy will return EINVAL but there is no system call to return this minimum value. To determine this value, some programs search /proc/<pid>/status for a line starting with "Mems_allowed:" and use the number of digits in the mask to determine the minimum value. A recent change to the way this line is formatted [2] causes these programs to compute a value less than MAX_NUMNODES so get_mempolicy() returns EINVAL. Change get_mempolicy(), the older compat version of get_mempolicy(), and the copy_nodes_to_user() function to use nr_node_ids instead of MAX_NUMNODES, thus preserving the defacto method of computing the minimum size for the nodemask array and the maxnode argument. [1] http://man7.org/linux/man-pages/man2/get_mempolicy.2.html [2] https://lore.kernel.org/lkml/[email protected] Link: http://lkml.kernel.org/r/[email protected] Fixes: 4fb8e5b89bcbbbb ("include/linux/nodemask.h: use nr_node_ids (not MAX_NUMNODES) in __nodemask_pr_numnodes()") Signed-off-by: Ralph Campbell <[email protected]> Suggested-by: Alexander Duyck <[email protected]> Cc: Waiman Long <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21revert "initramfs: cleanup incomplete rootfs"Andrew Morton1-3/+3
Revert ff1522bb7d9845 ("initramfs: cleanup incomplete rootfs"). Andy reports : This breaks my setup where I have U-boot provided more size of initramfs : than needed. This allows a bit of flexibility to increase or decrease : initramfs compressed image without taking care of bootloader. The proper : solution is to do this if we sure that we didn't get enough memory, : otherwise I can't consider the error fatal to clean up rootfs. Fixes: ff1522bb7d9845 ("initramfs: cleanup incomplete rootfs") Reported-by: Andy Shevchenko <[email protected]> Tested-by: Andy Shevchenko <[email protected]> Cc: David Engraf <[email protected]> Cc: Dominik Brodowski <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Philippe Ombredanne <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Luc Van Oostenryck <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-21Revert "xsk: simplify AF_XDP socket teardown"Björn Töpel1-1/+15
This reverts commit e2ce3674883ecba2605370404208c9d4a07ae1c3. It turns out that the sock destructor xsk_destruct was needed after all. The cleanup simplification broke the skb transmit cleanup path, due to that the umem was prematurely destroyed. The umem cannot be destroyed until all outstanding skbs are freed, which means that we cannot remove the umem until the sk_destruct has been called. Signed-off-by: Björn Töpel <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2019-02-21PM-runtime: Fix deadlock when canceling hrtimerVincent Guittot1-1/+1
When rpm_resume() desactivates the autosuspend timer, it should only try to cancel hrtimer but not wait for the handler to finish, because both rpm_resume() and pm_suspend_timer_fn() take the power.lock. A deadlock is possible as follows: CPU0 CPU1 rpm_resume() spin_lock_irqsave pm_suspend_timer_fn() spin_lock_irqsave pm_runtime_deactivate_timer() hrtimer_cancel() It is sufficient to call hrtimer_try_to_cancel() from pm_runtime_deactivate_timer(), because dev->power.timer_expires reset to 0 by it, so use that function instead of hrtimer_cancel(). Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") Reported-by: Sunzhaosheng Sun(Zhaosheng) <[email protected]> Signed-off-by: Vincent Guittot <[email protected]> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-02-20missing barriers in some of unix_sock ->addr and ->path accessesAl Viro3-29/+41
Several u->addr and u->path users are not holding any locks in common with unix_bind(). unix_state_lock() is useless for those purposes. u->addr is assign-once and *(u->addr) is fully set up by the time we set u->addr (all under unix_table_lock). u->path is also set in the same critical area, also before setting u->addr, and any unix_sock with ->path filled will have non-NULL ->addr. So setting ->addr with smp_store_release() is all we need for those "lockless" users - just have them fetch ->addr with smp_load_acquire() and don't even bother looking at ->path if they see NULL ->addr. Users of ->addr and ->path fall into several classes now: 1) ones that do smp_load_acquire(u->addr) and access *(u->addr) and u->path only if smp_load_acquire() has returned non-NULL. 2) places holding unix_table_lock. These are guaranteed that *(u->addr) is seen fully initialized. If unix_sock is in one of the "bound" chains, so's ->path. 3) unix_sock_destructor() using ->addr is safe. All places that set u->addr are guaranteed to have seen all stores *(u->addr) while holding a reference to u and unix_sock_destructor() is called when (atomic) refcount hits zero. 4) unix_release_sock() using ->path is safe. unix_bind() is serialized wrt unix_release() (normally - by struct file refcount), and for the instances that had ->path set by unix_bind() unix_release_sock() comes from unix_release(), so they are fine. Instances that had it set in unix_stream_connect() either end up attached to a socket (in unix_accept()), in which case the call chain to unix_release_sock() and serialization are the same as in the previous case, or they never get accept'ed and unix_release_sock() is called when the listener is shut down and its queue gets purged. In that case the listener's queue lock provides the barriers needed - unix_stream_connect() shoves our unix_sock into listener's queue under that lock right after having set ->path and eventual unix_release_sock() caller picks them from that queue under the same lock right before calling unix_release_sock(). 5) unix_find_other() use of ->path is pointless, but safe - it happens with successful lookup by (abstract) name, so ->path.dentry is guaranteed to be NULL there. earlier-variant-reviewed-by: "Paul E. McKenney" <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-20net: marvell: mvneta: fix DMA debug warningRussell King1-1/+1
Booting 4.20 on SolidRun Clearfog issues this warning with DMA API debug enabled: WARNING: CPU: 0 PID: 555 at kernel/dma/debug.c:1230 check_sync+0x514/0x5bc mvneta f1070000.ethernet: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000002dd7dc00] [size=240 bytes] Modules linked in: ahci mv88e6xxx dsa_core xhci_plat_hcd xhci_hcd devlink armada_thermal marvell_cesa des_generic ehci_orion phy_armada38x_comphy mcp3021 spi_orion evbug sfp mdio_i2c ip_tables x_tables CPU: 0 PID: 555 Comm: bridge-network- Not tainted 4.20.0+ #291 Hardware name: Marvell Armada 380/385 (Device Tree) [<c0019638>] (unwind_backtrace) from [<c0014888>] (show_stack+0x10/0x14) [<c0014888>] (show_stack) from [<c07f54e0>] (dump_stack+0x9c/0xd4) [<c07f54e0>] (dump_stack) from [<c00312bc>] (__warn+0xf8/0x124) [<c00312bc>] (__warn) from [<c00313b0>] (warn_slowpath_fmt+0x38/0x48) [<c00313b0>] (warn_slowpath_fmt) from [<c00b0370>] (check_sync+0x514/0x5bc) [<c00b0370>] (check_sync) from [<c00b04f8>] (debug_dma_sync_single_range_for_cpu+0x6c/0x74) [<c00b04f8>] (debug_dma_sync_single_range_for_cpu) from [<c051bd14>] (mvneta_poll+0x298/0xf58) [<c051bd14>] (mvneta_poll) from [<c0656194>] (net_rx_action+0x128/0x424) [<c0656194>] (net_rx_action) from [<c000a230>] (__do_softirq+0xf0/0x540) [<c000a230>] (__do_softirq) from [<c00386e0>] (irq_exit+0x124/0x144) [<c00386e0>] (irq_exit) from [<c009b5e0>] (__handle_domain_irq+0x58/0xb0) [<c009b5e0>] (__handle_domain_irq) from [<c03a63c4>] (gic_handle_irq+0x48/0x98) [<c03a63c4>] (gic_handle_irq) from [<c0009a10>] (__irq_svc+0x70/0x98) ... This appears to be caused by mvneta_rx_hwbm() calling dma_sync_single_range_for_cpu() with the wrong struct device pointer, as the buffer manager device pointer is used to map and unmap the buffer. Fix this. Signed-off-by: Russell King <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-21Merge tag 'drm-intel-fixes-2019-02-20' of ↵Dave Airlie1-5/+7
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fbdev takeover fix for v5.0 Signed-off-by: Dave Airlie <[email protected]> From: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-02-20Merge tag 'kvm-s390-master-5.0' of ↵Paolo Bonzini1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master KVM: s390: Fix crypto handling for nested KVM
2019-02-20Merge tag 'docs-5.0-fix' of git://git.lwn.net/linuxLinus Torvalds3-73/+78
Pull documentation fix from Jonathan Corbet: "A single patch from Arnd bringing some top-level docs into the 5.0 era" * tag 'docs-5.0-fix' of git://git.lwn.net/linux: Documentation: change linux-4.x references to 5.x
2019-02-20drm/amdgpu: disable bulk moves for nowChristian König1-0/+2
The changes to fix those are two invasive for backporting. Just disable the feature in 4.20 and 5.0. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Christian König <[email protected]> Cc: <[email protected]> [4.20+] Signed-off-by: Alex Deucher <[email protected]>
2019-02-20drm/amd/display: set clocks to 0 on suspend on dce80Bhawanpreet Lakha1-3/+16
[Why] When a dce80 asic was suspended, the clocks were not set to 0. Upon resume, the new clock was compared to the existing clock, they were found to be the same, and so the clock was not set. This resulted in a blackscreen. [How] In atomic commit, check to see if there are any active pipes. If no, set clocks to 0 Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Leo Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-02-20drm/amd/display: fix optimize_bandwidth func pointer for dce80Bhawanpreet Lakha2-1/+5
[Why] optimize_bandwidth was using dce100_prepare_bandwidth this is incorrect [How] change it to dce100_optimize_bandwidth Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Charlene Liu <[email protected]> Acked-by: Leo Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-02-20drm/amd/display: Fix negative cursor pos programmingNicholas Kazlauskas1-2/+2
[Why] If the cursor pos passed from DM is less than the plane_state->dst_rect top left corner then the unsigned cursor pos wraps around to a large positive number since cursor pos is a u32. There was an attempt to guard against this in hubp1_cursor_set_position by checking the src_x_offset and src_y_offset and offseting the cursor hotspot within hubp1_cursor_set_position. However, the cursor position itself is still being programmed incorrectly as a large value. This manifests itself visually as the cursor disappearing or containing strange artifacts near the middle of the screen on raven. [How] Don't subtract the destination rect top left corner from the pos but add it to the hotspot instead. This happens before the pos gets passed into hubp1_cursor_set_position. This achieves the same result but avoids the subtraction wrap around. With this fix the original cursor programming logic can be used again. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Charlene Liu <[email protected]> Acked-by: Leo Li <[email protected]> Acked-by: Murton Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-02-20clk: at91: fix masterck nameAlexandre Belloni3-4/+4
The master clock is actually named masterck earlier in the driver. Having "mck" in the parent list means that it can never be selected. Fixes: 1eabdc2f9dd8 ("clk: at91: add at91sam9x5 PMCs driver") Fixes: a2038077de9a ("clk: at91: add sama5d2 PMC driver") Fixes: 084b696bb509 ("clk: at91: add sama5d4 pmc driver") Signed-off-by: Alexandre Belloni <[email protected]> Acked-by: Nicolas Ferre <[email protected]> Cc: <[email protected]> # v4.20+ Signed-off-by: Stephen Boyd <[email protected]>
2019-02-20clk: at91: fix at91sam9x5 peripheral clock numberAlexandre Belloni1-2/+1
nck() looks at the last id in an array and unfortunately, at91sam9x35_periphck has a sentinel, hence the id is 0 and the calculated number of peripheral clocks is 1 instead of a maximum of 31. Fixes: 1eabdc2f9dd8 ("clk: at91: add at91sam9x5 PMCs driver") Signed-off-by: Alexandre Belloni <[email protected]> Acked-by: Nicolas Ferre <[email protected]> Cc: <[email protected]> # v4.20+ Signed-off-by: Stephen Boyd <[email protected]>
2019-02-20net: dsa: fix unintended change of bridge interface STP stateRussell King1-3/+4
When a DSA port is added to a bridge and brought up, the resulting STP state programmed into the hardware depends on the order that these operations are performed. However, the Linux bridge code believes that the port is in disabled mode. If the DSA port is first added to a bridge and then brought up, it will be in blocking mode. If it is brought up and then added to the bridge, it will be in disabled mode. This difference is caused by DSA always setting the STP mode in dsa_port_enable() whether or not this port is part of a bridge. Since bridge always sets the STP state when the port is added, brought up or taken down, it is unnecessary for us to manipulate the STP state. Apparently, this code was copied from Rocker, and the very next day a similar fix for Rocker was merged but was not propagated to DSA. See e47172ab7e41 ("rocker: put port in FORWADING state after leaving bridge") Fixes: b73adef67765 ("net: dsa: integrate with SWITCHDEV for HW bridging") Signed-off-by: Russell King <[email protected]> Reviewed-by: Vivien Didelot <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-20Merge tag 'sound-5.0' of ↵Linus Torvalds4-4/+56
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Here are a few last-minute fixes for 5.0. The most significant one is the OF-node refcount fix for ASoC simple-card, which could be triggered on many boards. Another fix for ASoC core is for the error handling in topology, while others are device-specific fixes for Samsung and HD-audio" * tag 'sound-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: simple-card: fixup refcount_t underflow ASoC: topology: free created components in tplg load error ALSA: hda/realtek: Disable PC beep in passthrough on alc285 ALSA: hda/realtek - Headset microphone and internal speaker support for System76 oryp5 ASoC: samsung: i2s: Fix prescaler setting for the secondary DAI
2019-02-20Merge tag 'pinctrl-v5.0-3' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Some final pin control fixes (I hope) to round off the v5.0 pin control development cycle. Only driver fixes, one for stable: - Meson8B fixup for the sdc pins - Fix SDC tile position for Qualcomm QCS404" * tag 'pinctrl-v5.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: meson: meson8b: fix the sdxc_a data 1..3 pins pinctrl: qcom: qcs404: Correct SDC tile
2019-02-20Merge tag 'gpio-v5.0-4' of ↵Linus Torvalds2-10/+11
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Two GPIO fixes for the v5.0 series: - Per-instance irqchip on the MT7621 - Avoid direction setting using pin control on MMP2" * tag 'gpio-v5.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2 gpio: MT7621: use a per instance irq_chip structure
2019-02-20Merge tag 'mtd/fixes-for-5.0-rc8' of git://git.infradead.org/linux-mtdLinus Torvalds2-1/+2
Pull MTD fixes from Boris Brezillon: - Don't add a digit to MTD-backed nvmem device names - Make sure powernv flash names are unique * tag 'mtd/fixes-for-5.0-rc8' of git://git.infradead.org/linux-mtd: mtd: powernv_flash: Fix device registration error mtd: Use mtd->name when registering nvmem device
2019-02-20Merge branch 'fixes-v5.1-rc6' of ↵Linus Torvalds10-97/+108
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull keys fixes from James Morris: - Handle quotas better, allowing full quota to be reached. - Fix the creation of shortcuts in the assoc_array internal representation when the index key needs to be an exact multiple of the machine word size. - Fix a dependency loop between the request_key contruction record and the request_key authentication key. The construction record isn't really necessary and can be dispensed with. - Set the timestamp on a new key rather than leaving it as 0. This would ordinarily be fine - provided the system clock is never set to a time before 1970 * 'fixes-v5.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: keys: Timestamp new keys keys: Fix dependency loop between construction record and auth key assoc_array: Fix shortcut creation KEYS: allow reaching the keys quotas exactly
2019-02-20ARM: tegra: Restore DT ABI on Tegra124 ChromebooksThierry Reding1-1/+16
Commit 482997699ef0 ("ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory") inadventently broke device tree ABI by adding a unit- address to the "/memory" node because the device tree compiler flagged the missing unit-address as a warning. Tegra124 Chromebooks (a.k.a. Nyan) use a bootloader that relies on the full name of the memory node in device tree being exactly "/memory". It can be argued whether this was a good decision or not, and some other bootloaders (such as U-Boot) do accept a unit-address in the name of the node, but the device tree is an ABI and we can't break existing setups just because the device tree compiler considers it bad practice to omit the unit-address nowadays. This partially reverts the offending commit and restores device tree ABI compatibility. Fixes: 482997699ef0 ("ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory") Reported-by: Tristan Bastian <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Tested-by: Tristan Bastian <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2019-02-20arm64: Relax GIC version check during early bootVladimir Murzin1-2/+1
Updates to the GIC architecture allow ID_AA64PFR0_EL1.GIC to have values other than 0 or 1. At the moment, Linux is quite strict in the way it handles this field at early boot stage (cpufeature is fine) and will refuse to use the system register CPU interface if it doesn't find the value 1. Fixes: 021f653791ad17e03f98aaa7fb933816ae16f161 ("irqchip: gic-v3: Initial support for GICv3") Reported-by: Chase Conklin <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Signed-off-by: Vladimir Murzin <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-02-20drm/i915/fbdev: Actually configure untiled displaysChris Wilson1-5/+7
If we skipped all the connectors that were not part of a tile, we would leave conn_seq=0 and conn_configured=0, convincing ourselves that we had stagnated in our configuration attempts. Avoid this situation by starting conn_seq=ALL_CONNECTORS, and repeating until we find no more connectors to configure. Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on stagnation") Reported-by: Maarten Lankhorst <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Cc: <[email protected]> # v3.19+ (cherry picked from commit d9b308b1f8a1acc0c3279f443d4fe0f9f663252e) Signed-off-by: Jani Nikula <[email protected]>
2019-02-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds41-244/+355
Pull networking fixes from David Miller: 1) Fix suspend and resume in mt76x0u USB driver, from Stanislaw Gruszka. 2) Missing memory barriers in xsk, from Magnus Karlsson. 3) rhashtable fixes in mac80211 from Herbert Xu. 4) 32-bit MIPS eBPF JIT fixes from Paul Burton. 5) Fix for_each_netdev_feature() on big endian, from Hauke Mehrtens. 6) GSO validation fixes from Willem de Bruijn. 7) Endianness fix for dwmac4 timestamp handling, from Alexandre Torgue. 8) More strict checks in tcp_v4_err(), from Eric Dumazet. 9) af_alg_release should NULL out the sk after the sock_put(), from Mao Wenan. 10) Missing unlock in mac80211 mesh error path, from Wei Yongjun. 11) Missing device put in hns driver, from Salil Mehta. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (44 commits) sky2: Increase D3 delay again vhost: correctly check the return value of translate_desc() in log_used() net: netcp: Fix ethss driver probe issue net: hns: Fixes the missing put_device in positive leg for roce reset net: stmmac: Fix a race in EEE enable callback qed: Fix iWARP syn packet mac address validation. qed: Fix iWARP buffer size provided for syn packet processing. r8152: Add support for MAC address pass through on RTL8153-BD mac80211: mesh: fix missing unlock on error in table_path_del() net/mlx4_en: fix spelling mistake: "quiting" -> "quitting" net: crypto set sk to NULL when af_alg_release. net: Do not allocate page fragments that are not skb aligned mm: Use fixed constant in page_frag_alloc instead of size + 1 tcp: tcp_v4_err() should be more careful tcp: clear icsk_backoff in tcp_write_queue_purge() net: mv643xx_eth: disable clk on error path in mv643xx_eth_shared_probe() qmi_wwan: apply SET_DTR quirk to Sierra WP7607 net: stmmac: handle endianness in dwmac4_get_timestamp doc: Mention MSG_ZEROCOPY implementation for UDP mlxsw: __mlxsw_sp_port_headroom_set(): Fix a use of local variable ...
2019-02-19sky2: Increase D3 delay againKai-Heng Feng1-1/+1
Another platform requires even longer delay to make the device work correctly after S3. So increase the delay to 300ms. BugLink: https://bugs.launchpad.net/bugs/1798921 Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-19vhost: correctly check the return value of translate_desc() in log_used()Jason Wang1-1/+1
When fail, translate_desc() returns negative value, otherwise the number of iovs. So we should fail when the return value is negative instead of a blindly check against zero. Detected by CoverityScan, CID# 1442593: Control flow issues (DEADCODE) Fixes: cc5e71075947 ("vhost: log dirty page correctly") Acked-by: Michael S. Tsirkin <[email protected]> Reported-by: Stephen Hemminger <[email protected]> Signed-off-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-02-19drm/amd/display: Raise dispclk value for dce11Roman Li1-3/+8
[Why] The visual corruption due to low display clock value. Observed on Carrizo 4K@60Hz. [How] There was earlier patch for dce_update_clocks: Adding +15% workaround also to to dce11_update_clocks Signed-off-by: Roman Li <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Leo Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-02-19drm/amd/display: Fix MST reboot/poweroff sequenceLeo (Hanghong) Ma1-2/+3
[Why] drm_dp_mst_topology_mgr_suspend() is added into the new reboot sequence, which disables the UP request at the beginning. Therefore sideband messages are blocked. [How] Finish MST sideband message transaction before UP request is suppressed. Signed-off-by: Leo (Hanghong) Ma <[email protected]> Reviewed-by: Roman Li <[email protected]> Acked-by: Leo Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-02-19drm/amdgpu: Update sdma golden setting for vega20shaoyunl1-2/+2
According to hardware engineer, WRITE_BURST_LENGTH [9:8] in register SDMA0_CHICKEN_BITS need to change to 3 for better performance Signed-off-by: shaoyunl <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-02-19drm/amdgpu: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtimeAlex Deucher1-0/+1
Based on a similar patch from Rafael for radeon. When using ATPX to control dGPU power, the state is not retained across suspend and resume cycles by default. This can probably be loosened for Hybrid Graphics (_PR3) laptops where I think the state is properly retained. Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks") Cc: Rafael J. Wysocki <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-02-19gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtimeRafael J. Wysocki1-0/+1
On HP ProBook 4540s, if PM-runtime is enabled in the radeon driver and the direct-complete optimization is used for the radeon device during system-wide suspend, the system doesn't resume. Preventing direct-complete from being used with the radeon device by setting the DPM_FLAG_NEVER_SKIP driver flag for it makes the problem go away, which indicates that direct-complete is not safe for the radeon driver in general and should not be used with it (at least for now). This fixes a regression introduced by commit c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks") which allowed direct-complete to be applied to devices without PM callbacks (again) which in turn unlocked direct-complete for radeon on HP ProBook 4540s. Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks") Link: https://bugzilla.kernel.org/show_bug.cgi?id=201519 Reported-by: Ярослав Семченко <[email protected]> Tested-by: Ярослав Семченко <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-02-19Merge branch 'am335x-phy-fixes' into omap-for-v5.0/fixes-v2Tony Lindgren2-3/+3
2019-02-19ARM: dts: am335x-evm: Fix PHY mode for ethernetPeter Ujfalusi1-1/+1
The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled. The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2019-02-19ARM: dts: am335x-evmsk: Fix PHY mode for ethernetPeter Ujfalusi1-2/+2
The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled. The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2019-02-19arm64: dts: clearfog-gt-8k: fix SGMII PHY reset signalBaruch Siach1-1/+1
The PHY reset signal goes to mpp43 on CP0. Fixes: babc5544c293 ("arm64: dts: clearfog-gt-8k: 1G eth PHY reset signal") Reported-by: Denis Odintsov <[email protected]> Signed-off-by: Baruch Siach <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2019-02-19ARM: dts: armada-xp: fix Armada XP boards NAND descriptionThomas Petazzoni3-68/+76
Commit 3b79919946cd2cf4dac47842afc9a893acec4ed7 ("ARM: dts: armada-370-xp: update NAND node with new bindings") updated some Marvell Armada DT description to use the new NAND controller bindings, but did it incorrectly for a number of boards: armada-xp-gp, armada-xp-db and armada-xp-lenovo-ix4-300d. Due to this, the NAND is no longer detected on those platforms. This commit fixes that by properly using the new NAND DT binding. This commit was runtime-tested on Armada XP GP, the two other platforms are only compile-tested. Fixes: 3b79919946cd2 ("ARM: dts: armada-370-xp: update NAND node with new bindings") Cc: Miquel Raynal <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]>
2019-02-19Merge tag 'asoc-fix-v5.0-rc6' of ↵Takashi Iwai3-3/+15
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.0 A few small fixes, a driver fix for Samsung, a fix for refcounting of of_nodes in the simple-card driver that triggered on a lot of systems and a fix for topology error handling.
2019-02-19cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit()Yangtao Li1-1/+1
This issue was detected with the help of Coccinelle. So change the order of function calls to fix it. Fixes: 1690d8bb91e37 (cpufreq: scpi/scmi: Fix freeing of dynamic OPPs) Signed-off-by: Yangtao Li <[email protected]> Acked-by: Viresh Kumar <[email protected]> Acked-by: Sudeep Holla <[email protected]> Cc: 4.20+ <[email protected]> # 4.20+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-02-18Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller2-1/+5
Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains Netfilter/IPVS fixes for net: 1) Follow up patch to fix a compilation warning in a recent IPVS fix: 098e13f5b21d ("ipvs: fix dependency on nf_defrag_ipv6"). 2) Bogus ENOENT error on flush after rule deletion in the same batch, reported by Phil Sutter. ==================== Signed-off-by: David S. Miller <[email protected]>