commit e1b4a59f3a661718e7979fadc348c121eaa61717 Author: Alexandre Frade Date: Sat Dec 1 11:50:46 2018 -0200 4.19.6-xanmod4 Signed-off-by: Alexandre Frade commit 6ec8e20913af7721383ddf47ab4d5019b8e41acf Merge: 314ba92e4054 96db90800c06 Author: Alexandre Frade Date: Sat Dec 1 11:34:07 2018 -0200 Merge tag 'v4.19.6' into 4.19 This is the 4.19.6 stable release commit 314ba92e40548ddeccb8233478a165c5a5c03600 Author: Alfred Chen Date: Fri Nov 30 16:39:37 2018 +0800 Tag PDS 0.99f commit 9e27985cfc179abe114244b87291a4216165179d Author: Alfred Chen Date: Fri Nov 16 13:59:35 2018 +0000 pds: Rework slibing group balance. Rework sg balance code to reduce overhead. commit 93709a01b54ff554def1fdcceaa698e7413bb2dd Author: Alfred Chen Date: Tue Nov 13 09:59:18 2018 +0000 pds: Default 4ms rr_interal. commit 68f7e98a29f74cd57c0e9ffddd9155372a373d69 Author: Alfred Chen Date: Fri Nov 9 16:01:47 2018 +0000 pds: Remove load balance code from scheduler_tick() commit 7ad32a6c2bf05c7958caabc6216bd57eab64d9a5 Author: Alfred Chen Date: Fri Nov 16 14:01:32 2018 +0000 Tag PDS 0.99e commit 32b5a1e004ecc75ac02cfdc0b97e0289b29cf8cb Author: Alfred Chen Date: Wed Nov 7 15:46:34 2018 +0000 pds: Remove cpumask_weight() in best_mask_cpu(). commit 51338487eaced2cf55910b7efe2c09fdc21f3081 Author: Alfred Chen Date: Wed Nov 7 11:03:28 2018 +0800 pds: Refine take_other_rq_task() code path. commit 94d9d061d84806a5df999b3ef2dae4399e335ca8 Author: Alfred Chen Date: Wed Oct 24 16:26:39 2018 +0000 pds: Fix sched_fork() time slice fairness. commit c94e49ce731ca176440bbba10c6663c762ccd801 Author: Alfred Chen Date: Mon Nov 12 10:20:18 2018 +0000 Tag PDS 0.99d commit 45f44e151d975e49552221c6b11ae11869620a92 Author: Alfred Chen Date: Mon Nov 12 10:17:39 2018 +0000 pds: UP compilation fix. commit b6e891bf16c10e558d306681def0dc783aaa21b9 Author: Alfred Chen Date: Tue Oct 16 17:09:42 2018 +0000 pds: Rework SCHED_ISO support. commit 96db90800c06d3fe3fa08eb6222fe201286bb778 Author: Greg Kroah-Hartman Date: Sat Dec 1 09:37:35 2018 +0100 Linux 4.19.6 commit d873e63e0a01906e7a3610201c3162d694c72740 Author: Hugues Fruchet Date: Tue Sep 11 09:48:20 2018 -0400 media: ov5640: fix auto controls values when switching to manual mode commit a8f438c684eaa4cbe6c98828eb996d5ec53e24fb upstream. When switching from auto to manual mode, V4L2 core is calling g_volatile_ctrl() in manual mode in order to get the manual initial value. Remove the manual mode check/return to not break this behaviour. Signed-off-by: Hugues Fruchet Tested-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Adam Ford Signed-off-by: Greg Kroah-Hartman commit 5724c6ad1c4ca8396144e16342a356e61d837c3f Author: Hugues Fruchet Date: Tue Sep 11 09:48:19 2018 -0400 media: ov5640: fix wrong binning value in exposure calculation commit c2c3f42df4dd9bb231d756bacb0c897f662c6d3c upstream. ov5640_set_mode_exposure_calc() is checking binning value but binning value read is buggy, fix this. Rename ov5640_binning_on() to ov5640_get_binning() as per other similar functions. Signed-off-by: Hugues Fruchet Reviewed-by: Laurent Pinchart Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Adam Ford Signed-off-by: Greg Kroah-Hartman commit 644fefe4c6a7c892f85948b5c134c72cec4c76e4 Author: Hugues Fruchet Date: Tue Sep 11 09:48:18 2018 -0400 media: ov5640: fix auto gain & exposure when changing mode commit 3cca8ef5f774cbd61c8db05d9aa401de9bb59c66 upstream. Ensure that auto gain and auto exposure are well restored when changing mode. Signed-off-by: Hugues Fruchet Reviewed-by: Jacopo Mondi Tested-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Adam Ford Signed-off-by: Greg Kroah-Hartman commit f8248ad512b61bef934f0c4be3a7983b85f4bf08 Author: Hugues Fruchet Date: Tue Sep 11 09:48:17 2018 -0400 media: ov5640: fix exposure regression commit dc29a1c187eedc1d498cb567c44bbbc832b009cb upstream. Symptom was black image when capturing HD or 5Mp picture due to manual exposure set to 1 while it was intended to set autoexposure to "manual", fix this. Fixes: bf4a4b518c20 ("media: ov5640: Don't force the auto exposure state at start time"). Signed-off-by: Hugues Fruchet Reviewed-by: Laurent Pinchart Tested-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Adam Ford Signed-off-by: Greg Kroah-Hartman commit 905fa2f2ffad7186df9c4997b473a6376f680f99 Author: Jacopo Mondi Date: Wed Jul 18 06:06:23 2018 -0400 media: ov5640: Fix timings setup code commit bad1774ed41e98a43074e50e7d5ac9e1e848d99a upstream. As of: commit 476dec012f4c ("media: ov5640: Add horizontal and vertical totals") the timings parameters gets programmed separately from the static register values array. When changing capture mode, the vertical and horizontal totals gets inspected by the set_mode_exposure_calc() functions, and only later programmed with the new values. This means exposure, light banding filter and shutter gain are calculated using the previous timings, and are thus not correct. Fix this by programming timings right after the static register value table has been sent to the sensor in the ov5640_load_regs() function. Fixes: 476dec012f4c ("media: ov5640: Add horizontal and vertical totals") Tested-by: Steve Longerbeam # i.MX6q SabreSD, CSI-2 Tested-by: Loic Poulain # Dragonboard-410c, CSI-2 Signed-off-by: Samuel Bobrowicz Signed-off-by: Maxime Ripard Signed-off-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Adam Ford Signed-off-by: Greg Kroah-Hartman commit c59dc6cf4fd98c8a9ebf6f807167550eb2e029fb Author: Jacopo Mondi Date: Fri Jul 6 05:51:52 2018 -0400 media: ov5640: Re-work MIPI startup sequence commit aa4bb8b8838ffcc776a79f49a4d7476b82405349 upstream. Rework the MIPI interface startup sequence with the following changes: - Remove MIPI bus initialization from the initial settings blob - At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode. - At s_stream time enable/disable the MIPI interface output. - Restore default settings at set_power(0) time. Before this commit the sensor MIPI interface was initialized with settings that require a start/stop sequence at power-up time in order to force lanes into LP11 state, as they were initialized in LP00 when in 'sleep mode', which is assumed to be the sensor manual definition for the D-PHY defined stop mode. The stream start/stop was performed by enabling disabling clock gating, and had the side effect to change the lanes sleep mode configuration when stream was stopped. Clock gating/ungating: - ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5), - on ? 0 : BIT(5)); - if (ret) Set lanes in LP11 when in 'sleep mode': - ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00, - on ? 0x00 : 0x70); This commit fixes an issue reported by Jagan Teki on i.MX6 platforms that prevents the host interface from powering up correctly: https://lkml.org/lkml/2018/6/1/38 It also improves MIPI capture operations stability on my testing platform where MIPI capture often failed and returned all-purple frames. Fixes: f22996db44e2 ("media: ov5640: add support of DVP parallel interface") Tested-by: Steve Longerbeam (i.MX6q SabreSD, CSI-2) Tested-by: Loic Poulain (Dragonboard-410c, CSI-2) Reported-by: Jagan Teki Signed-off-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Adam Ford Signed-off-by: Greg Kroah-Hartman commit 016a8fc59d14c8b6aebb0ef1405b1cb5275192a3 Author: Paul E. McKenney Date: Mon Jul 9 13:47:30 2018 -0700 rcu: Make need_resched() respond to urgent RCU-QS needs commit 92aa39e9dc77481b90cbef25e547d66cab901496 upstream. The per-CPU rcu_dynticks.rcu_urgent_qs variable communicates an urgent need for an RCU quiescent state from the force-quiescent-state processing within the grace-period kthread to context switches and to cond_resched(). Unfortunately, such urgent needs are not communicated to need_resched(), which is sometimes used to decide when to invoke cond_resched(), for but one example, within the KVM vcpu_run() function. As of v4.15, this can result in synchronize_sched() being delayed by up to ten seconds, which can be problematic, to say nothing of annoying. This commit therefore checks rcu_dynticks.rcu_urgent_qs from within rcu_check_callbacks(), which is invoked from the scheduling-clock interrupt handler. If the current task is not an idle task and is not executing in usermode, a context switch is forced, and either way, the rcu_dynticks.rcu_urgent_qs variable is set to false. If the current task is an idle task, then RCU's dyntick-idle code will detect the quiescent state, so no further action is required. Similarly, if the task is executing in usermode, other code in rcu_check_callbacks() and its called functions will report the corresponding quiescent state. Reported-by: Marius Hillenbrand Reported-by: David Woodhouse Suggested-by: Peter Zijlstra Signed-off-by: Paul E. McKenney [ paulmck: Backported to make patch apply cleanly on older versions. ] Tested-by: Marius Hillenbrand Cc: # 4.12.x - 4.19.x Signed-off-by: Greg Kroah-Hartman commit 38084377af4fc8093f02a47e43124579affa7b16 Author: Andreas Gruenbacher Date: Sun Nov 11 11:15:21 2018 +0000 gfs2: Fix iomap buffer head reference counting bug commit c26b5aa8ef0d46035060fded475e6ab957b9f69f upstream. GFS2 passes the inode buffer head (dibh) from gfs2_iomap_begin to gfs2_iomap_end in iomap->private. It sets that private pointer in gfs2_iomap_get. Users of gfs2_iomap_get other than gfs2_iomap_begin would have to release iomap->private, but this isn't done correctly, leading to a leak of buffer head references. To fix this, move the code for setting iomap->private from gfs2_iomap_get to gfs2_iomap_begin. Fixes: 64bc06bb32 ("gfs2: iomap buffered write support") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9365cdf8db5139f63ffd51fc2743c90cb95fd991 Author: Greg Kroah-Hartman Date: Thu Oct 4 11:06:14 2018 -0700 tty: wipe buffer if not echoing data commit b97b3d9fb57860a60592859e332de7759fd54c2e upstream. If we are not echoing the data to userspace or the console is in icanon mode, then perhaps it is a "secret" so we should wipe it once we are done with it. This mirrors the logic that the audit code has. Reported-by: aszlig Tested-by: Milan Broz Tested-by: Daniel Zatovic Tested-by: aszlig Cc: Willy Tarreau Signed-off-by: Greg Kroah-Hartman commit 5a2261ed3a29a180e006526718acb5712cf5bcc7 Author: Linus Torvalds Date: Thu Oct 4 11:06:13 2018 -0700 tty: wipe buffer. commit c9a8e5fce009e3c601a43c49ea9dbcb25d1ffac5 upstream. After we are done with the tty buffer, zero it out. Reported-by: aszlig Tested-by: Milan Broz Tested-by: Daniel Zatovic Tested-by: aszlig Cc: Willy Tarreau Signed-off-by: Greg Kroah-Hartman commit 5e8c28f4fd641fbc9b1f13448ed7e72019c673f6 Author: Sebastien Boisvert Date: Fri Oct 26 15:02:23 2018 -0700 include/linux/pfn_t.h: force '~' to be parsed as an unary operator commit 4d54954a197175c0dcb3c82af0c0740d0c5f827a upstream. Tracing the event "fs_dax:dax_pmd_insert_mapping" with perf produces this warning: [fs_dax:dax_pmd_insert_mapping] unknown op '~' It is printed in process_op (tools/lib/traceevent/event-parse.c) because '~' is parsed as a binary operator. perf reads the format of fs_dax:dax_pmd_insert_mapping ("print fmt") from /sys/kernel/debug/tracing/events/fs_dax/dax_pmd_insert_mapping/format . The format contains: ~(((u64) ~(~(((1UL) << 12)-1))) ^ \ interpreted as a binary operator by process_op(). This part is generated in the declaration of the event class dax_pmd_insert_mapping_class in include/trace/events/fs_dax.h : __print_flags_u64(__entry->pfn_val & PFN_FLAGS_MASK, "|", PFN_FLAGS_TRACE), This patch adds a pair of parentheses in the declaration of PFN_FLAGS_MASK to make sure that '~' is parsed as a unary operator by perf. The part of the format that was problematic is now: ~(((u64) (~(~(((1UL) << 12)-1)))) Now, all the '~' are parsed as unary operators. Link: http://lkml.kernel.org/r/20181021145939.8760-1-sebhtml@videotron.qc.ca Signed-off-by: Sebastien Boisvert Acked-by: Dan Williams Cc: "Steven Rostedt (VMware)" Cc: Arnaldo Carvalho de Melo Cc: "Tzvetomir Stoyanov (VMware)" Cc: Namhyung Kim Cc: Ross Zwisler Cc: Elenie Godzaridis Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e7a121e34c79bca171e5076a4c30a17d9966e88f Author: Matthew Wilcox Date: Fri Nov 16 15:50:02 2018 -0500 dax: Avoid losing wakeup in dax_lock_mapping_entry commit 25bbe21bf427a81b8e3ccd480ea0e1d940256156 upstream. After calling get_unlocked_entry(), you have to call put_unlocked_entry() to avoid subsequent waiters losing wakeups. Fixes: c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()") Cc: stable@vger.kernel.org Signed-off-by: Matthew Wilcox Signed-off-by: Greg Kroah-Hartman commit 9dec38554aa876700acb851b35ee0c5e28841e03 Author: Michal Hocko Date: Fri Nov 16 15:08:53 2018 -0800 mm, page_alloc: check for max order in hot path [ Upstream commit c63ae43ba53bc432b414fd73dd5f4b01fcb1ab43 ] Konstantin has noticed that kvmalloc might trigger the following warning: WARNING: CPU: 0 PID: 6676 at mm/vmstat.c:986 __fragmentation_index+0x54/0x60 [...] Call Trace: fragmentation_index+0x76/0x90 compaction_suitable+0x4f/0xf0 shrink_node+0x295/0x310 node_reclaim+0x205/0x250 get_page_from_freelist+0x649/0xad0 __alloc_pages_nodemask+0x12a/0x2a0 kmalloc_large_node+0x47/0x90 __kmalloc_node+0x22b/0x2e0 kvmalloc_node+0x3e/0x70 xt_alloc_table_info+0x3a/0x80 [x_tables] do_ip6t_set_ctl+0xcd/0x1c0 [ip6_tables] nf_setsockopt+0x44/0x60 SyS_setsockopt+0x6f/0xc0 do_syscall_64+0x67/0x120 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 the problem is that we only check for an out of bound order in the slow path and the node reclaim might happen from the fast path already. This is fixable by making sure that kvmalloc doesn't ever use kmalloc for requests that are larger than KMALLOC_MAX_SIZE but this also shows that the code is rather fragile. A recent UBSAN report just underlines that by the following report UBSAN: Undefined behaviour in mm/page_alloc.c:3117:19 shift exponent 51 is too large for 32-bit type 'int' CPU: 0 PID: 6520 Comm: syz-executor1 Not tainted 4.19.0-rc2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xd2/0x148 lib/dump_stack.c:113 ubsan_epilogue+0x12/0x94 lib/ubsan.c:159 __ubsan_handle_shift_out_of_bounds+0x2b6/0x30b lib/ubsan.c:425 __zone_watermark_ok+0x2c7/0x400 mm/page_alloc.c:3117 zone_watermark_fast mm/page_alloc.c:3216 [inline] get_page_from_freelist+0xc49/0x44c0 mm/page_alloc.c:3300 __alloc_pages_nodemask+0x21e/0x640 mm/page_alloc.c:4370 alloc_pages_current+0xcc/0x210 mm/mempolicy.c:2093 alloc_pages include/linux/gfp.h:509 [inline] __get_free_pages+0x12/0x60 mm/page_alloc.c:4414 dma_mem_alloc+0x36/0x50 arch/x86/include/asm/floppy.h:156 raw_cmd_copyin drivers/block/floppy.c:3159 [inline] raw_cmd_ioctl drivers/block/floppy.c:3206 [inline] fd_locked_ioctl+0xa00/0x2c10 drivers/block/floppy.c:3544 fd_ioctl+0x40/0x60 drivers/block/floppy.c:3571 __blkdev_driver_ioctl block/ioctl.c:303 [inline] blkdev_ioctl+0xb3c/0x1a30 block/ioctl.c:601 block_ioctl+0x105/0x150 fs/block_dev.c:1883 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0x1c0/0x1150 fs/ioctl.c:687 ksys_ioctl+0x9e/0xb0 fs/ioctl.c:702 __do_sys_ioctl fs/ioctl.c:709 [inline] __se_sys_ioctl fs/ioctl.c:707 [inline] __x64_sys_ioctl+0x7e/0xc0 fs/ioctl.c:707 do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Note that this is not a kvmalloc path. It is just that the fast path really depends on having sanitzed order as well. Therefore move the order check to the fast path. Link: http://lkml.kernel.org/r/20181113094305.GM15120@dhcp22.suse.cz Signed-off-by: Michal Hocko Reported-by: Konstantin Khlebnikov Reported-by: Kyungtae Kim Acked-by: Vlastimil Babka Cc: Balbir Singh Cc: Mel Gorman Cc: Pavel Tatashin Cc: Oscar Salvador Cc: Mike Rapoport Cc: Aaron Lu Cc: Joonsoo Kim Cc: Byoungyoung Lee Cc: "Dae R. Jeong" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit db89fc007b2338ba80336c4ae70687c968267b5b Author: Yufen Yu Date: Fri Nov 16 15:08:39 2018 -0800 tmpfs: make lseek(SEEK_DATA/SEK_HOLE) return ENXIO with a negative offset [ Upstream commit 1a413646931cb14442065cfc17561e50f5b5bb44 ] Other filesystems such as ext4, f2fs and ubifs all return ENXIO when lseek (SEEK_DATA or SEEK_HOLE) requests a negative offset. man 2 lseek says : EINVAL whence is not valid. Or: the resulting file offset would be : negative, or beyond the end of a seekable device. : : ENXIO whence is SEEK_DATA or SEEK_HOLE, and the file offset is beyond : the end of the file. Make tmpfs return ENXIO under these circumstances as well. After this, tmpfs also passes xfstests's generic/448. [akpm@linux-foundation.org: rewrite changelog] Link: http://lkml.kernel.org/r/1540434176-14349-1-git-send-email-yuyufen@huawei.com Signed-off-by: Yufen Yu Reviewed-by: Andrew Morton Cc: Al Viro Cc: Hugh Dickins Cc: William Kucharski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b44fd1268bd2ffa0ae72b647c96fea44eac9cd98 Author: Michal Hocko Date: Fri Nov 16 15:08:15 2018 -0800 mm, memory_hotplug: check zone_movable in has_unmovable_pages [ Upstream commit 9d7899999c62c1a81129b76d2a6ecbc4655e1597 ] Page state checks are racy. Under a heavy memory workload (e.g. stress -m 200 -t 2h) it is quite easy to hit a race window when the page is allocated but its state is not fully populated yet. A debugging patch to dump the struct page state shows has_unmovable_pages: pfn:0x10dfec00, found:0x1, count:0x0 page:ffffea0437fb0000 count:1 mapcount:1 mapping:ffff880e05239841 index:0x7f26e5000 compound_mapcount: 1 flags: 0x5fffffc0090034(uptodate|lru|active|head|swapbacked) Note that the state has been checked for both PageLRU and PageSwapBacked already. Closing this race completely would require some sort of retry logic. This can be tricky and error prone (think of potential endless or long taking loops). Workaround this problem for movable zones at least. Such a zone should only contain movable pages. Commit 15c30bc09085 ("mm, memory_hotplug: make has_unmovable_pages more robust") has told us that this is not strictly true though. Bootmem pages should be marked reserved though so we can move the original check after the PageReserved check. Pages from other zones are still prone to races but we even do not pretend that memory hotremove works for those so pre-mature failure doesn't hurt that much. Link: http://lkml.kernel.org/r/20181106095524.14629-1-mhocko@kernel.org Fixes: 15c30bc09085 ("mm, memory_hotplug: make has_unmovable_pages more robust") Signed-off-by: Michal Hocko Reported-by: Baoquan He Tested-by: Baoquan He Acked-by: Baoquan He Reviewed-by: Oscar Salvador Acked-by: Balbir Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 510066729ba42381c033e4cf4492f5055cc56880 Author: Vitaly Wool Date: Fri Nov 16 15:07:56 2018 -0800 z3fold: fix possible reclaim races [ Upstream commit ca0246bb97c23da9d267c2107c07fb77e38205c9 ] Reclaim and free can race on an object which is basically fine but in order for reclaim to be able to map "freed" object we need to encode object length in the handle. handle_to_chunks() is then introduced to extract object length from a handle and use it during mapping. Moreover, to avoid racing on a z3fold "headless" page release, we should not try to free that page in z3fold_free() if the reclaim bit is set. Also, in the unlikely case of trying to reclaim a page being freed, we should not proceed with that page. While at it, fix the page accounting in reclaim function. This patch supersedes "[PATCH] z3fold: fix reclaim lock-ups". Link: http://lkml.kernel.org/r/20181105162225.74e8837d03583a9b707cf559@gmail.com Signed-off-by: Vitaly Wool Signed-off-by: Jongseok Kim Reported-by-by: Jongseok Kim Reviewed-by: Snild Dolkow Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 43b2ceb0d4e0147b114cb1d0112a988cbb81ecbc Author: Ard Biesheuvel Date: Wed Nov 14 09:55:41 2018 -0800 efi/arm: Revert deferred unmap of early memmap mapping [ Upstream commit 33412b8673135b18ea42beb7f5117ed0091798b6 ] Commit: 3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory map longer for BGRT") deferred the unmap of the early mapping of the UEFI memory map to accommodate the ACPI BGRT code, which looks up the memory type that backs the BGRT table to validate it against the requirements of the UEFI spec. Unfortunately, this causes problems on ARM, which does not permit early mappings to persist after paging_init() is called, resulting in a WARN() splat. Since we don't support the BGRT table on ARM anway, let's revert ARM to the old behaviour, which is to take down the early mapping at the end of efi_init(). Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 3ea86495aef2 ("efi/arm: preserve early mapping of UEFI memory ...") Link: http://lkml.kernel.org/r/20181114175544.12860-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit f5c632cfc4240a3df15b0cefed12961f4422b329 Author: Satheesh Rajendran Date: Thu Nov 8 10:47:56 2018 +0530 powerpc/numa: Suppress "VPHN is not supported" messages [ Upstream commit 437ccdc8ce629470babdda1a7086e2f477048cbd ] When VPHN function is not supported and during cpu hotplug event, kernel prints message 'VPHN function not supported. Disabling polling...'. Currently it prints on every hotplug event, it floods dmesg when a KVM guest tries to hotplug huge number of vcpus, let's just print once and suppress further kernel prints. Signed-off-by: Satheesh Rajendran Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b5ccf0038f34a5a207d9c33d8cc1e40b2faf6725 Author: Trond Myklebust Date: Tue Nov 13 16:37:54 2018 -0500 NFSv4: Fix an Oops during delegation callbacks [ Upstream commit e39d8a186ed002854196668cb7562ffdfbc6d379 ] If the server sends a CB_GETATTR or a CB_RECALL while the filesystem is being unmounted, then we can Oops when releasing the inode in nfs4_callback_getattr() and nfs4_callback_recall(). Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 2bc40f89f47e3b6fb63a2b186073ef1ce75dca53 Author: Prarit Bhargava Date: Thu Sep 20 08:59:14 2018 -0400 kdb: Use strscpy with destination buffer size [ Upstream commit c2b94c72d93d0929f48157eef128c4f9d2e603ce ] gcc 8.1.0 warns with: kernel/debug/kdb/kdb_support.c: In function ‘kallsyms_symbol_next’: kernel/debug/kdb/kdb_support.c:239:4: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] strncpy(prefix_name, name, strlen(name)+1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel/debug/kdb/kdb_support.c:239:31: note: length computed here Use strscpy() with the destination buffer size, and use ellipses when displaying truncated symbols. v2: Use strscpy() Signed-off-by: Prarit Bhargava Cc: Jonathan Toppins Cc: Jason Wessel Cc: Daniel Thompson Cc: kgdb-bugreport@lists.sourceforge.net Reviewed-by: Daniel Thompson Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit 4dc8439068731e22ba02cebb4fdd0d1ce3b362f6 Author: Philip Yang Date: Mon Nov 12 14:00:45 2018 -0500 drm/amdgpu: fix bug with IH ring setup [ Upstream commit c837243ff4017f493c7d6f4ab57278d812a86859 ] The bug limits the IH ring wptr address to 40bit. When the system memory is bigger than 1TB, the bus address is more than 40bit, this causes the interrupt cannot be handled and cleared correctly. Reviewed-by: Christian König Signed-off-by: Philip Yang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 021e2f3fc985842d756e292b7aaa1a44a8d41fd9 Author: Olof Johansson Date: Tue Oct 30 23:47:09 2018 -0700 RISC-V: Silence some module warnings on 32-bit [ Upstream commit ef3a61406618291c46da168ff91acaa28d85944c ] Fixes: arch/riscv/kernel/module.c: In function 'apply_r_riscv_32_rela': ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=] arch/riscv/kernel/module.c:23:27: note: format string is defined here arch/riscv/kernel/module.c: In function 'apply_r_riscv_pcrel_hi20_rela': ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=] arch/riscv/kernel/module.c:104:23: note: format string is defined here arch/riscv/kernel/module.c: In function 'apply_r_riscv_hi20_rela': ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=] arch/riscv/kernel/module.c:146:23: note: format string is defined here arch/riscv/kernel/module.c: In function 'apply_r_riscv_got_hi20_rela': ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=] arch/riscv/kernel/module.c:190:60: note: format string is defined here arch/riscv/kernel/module.c: In function 'apply_r_riscv_call_plt_rela': ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=] arch/riscv/kernel/module.c:214:24: note: format string is defined here arch/riscv/kernel/module.c: In function 'apply_r_riscv_call_rela': ./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=] arch/riscv/kernel/module.c:236:23: note: format string is defined here Signed-off-by: Olof Johansson Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit fc9b1d7f791f4975f196e60280dd0524b31cb98a Author: David Abdurachmanov Date: Mon Nov 5 15:35:37 2018 +0100 riscv: add missing vdso_install target [ Upstream commit f157d411a9eb170d2ee6b766da7a381962017cc9 ] Building kernel 4.20 for Fedora as RPM fails, because riscv is missing vdso_install target in arch/riscv/Makefile. Signed-off-by: David Abdurachmanov Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit ab1a520669381c68b542f5c110a01a514ac28950 Author: Trond Myklebust Date: Mon Nov 12 16:06:51 2018 -0500 SUNRPC: Fix a bogus get/put in generic_key_to_expire() [ Upstream commit e3d5e573a54dabdc0f9f3cb039d799323372b251 ] Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 487d58a9c3e5b2357b8bef6461ae228ad8e73f83 Author: Hannes Reinecke Date: Mon Nov 12 10:35:25 2018 -0700 block: copy ioprio in __bio_clone_fast() and bounce [ Upstream commit ca474b73896bf6e0c1eb8787eb217b0f80221610 ] We need to copy the io priority, too; otherwise the clone will run with a different priority than the original one. Fixes: 43b62ce3ff0a ("block: move bio io prio to a new field") Signed-off-by: Hannes Reinecke Signed-off-by: Jean Delvare Fixed up subject, and ordered stores. Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 08f94d0628c361937d463061cef8d0b9b0a1c718 Author: Kan Liang Date: Fri Oct 19 10:04:18 2018 -0700 perf/x86/intel/uncore: Add more IMC PCI IDs for KabyLake and CoffeeLake CPUs [ Upstream commit c10a8de0d32e95b0b8c7c17b6dc09baea5a5a899 ] KabyLake and CoffeeLake CPUs have the same client uncore events as SkyLake. Add the PCI IDs for the KabyLake Y, U, S processor lines and CoffeeLake U, H, S processor lines. Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Link: http://lkml.kernel.org/r/20181019170419.378-1-kan.liang@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 08fbd4e011ef27e662f26a5ee34ccc54e4eff6bf Author: Patrick Bellasi Date: Mon Nov 5 14:53:58 2018 +0000 sched/fair: Fix cpu_util_wake() for 'execl' type workloads [ Upstream commit c469933e772132aad040bd6a2adc8edf9ad6f825 ] A ~10% regression has been reported for UnixBench's execl throughput test by Aaron Lu and Ye Xiaolong: https://lkml.org/lkml/2018/10/30/765 That test is pretty simple, it does a "recursive" execve() syscall on the same binary. Starting from the syscall, this sequence is possible: do_execve() do_execveat_common() __do_execve_file() sched_exec() select_task_rq_fair() <==| Task already enqueued find_idlest_cpu() find_idlest_group() capacity_spare_wake() <==| Functions not called from cpu_util_wake() | the wakeup path which means we can end up calling cpu_util_wake() not only from the "wakeup path", as its name would suggest. Indeed, the task doing an execve() syscall is already enqueued on the CPU we want to get the cpu_util_wake() for. The estimated utilization for a CPU computed in cpu_util_wake() was written under the assumption that function can be called only from the wakeup path. If instead the task is already enqueued, we end up with a utilization which does not remove the current task's contribution from the estimated utilization of the CPU. This will wrongly assume a reduced spare capacity on the current CPU and increase the chances to migrate the task on execve. The regression is tracked down to: commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates") because in that patch we turn on by default the UTIL_EST sched feature. However, the real issue is introduced by: commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths") Let's fix this by ensuring to always discount the task estimated utilization from the CPU's estimated utilization when the task is also the current one. The same benchmark of the bug report, executed on a dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine, reports these "Execl Throughput" figures (higher the better): mainline : 48136.5 lps mainline+fix : 55376.5 lps which correspond to a 15% speedup. Moreover, since {cpu_util,capacity_spare}_wake() are not really only used from the wakeup path, let's remove this ambiguity by using a better matching name: {cpu_util,capacity_spare}_without(). Since we are at that, let's also improve the existing documentation. Reported-by: Aaron Lu Reported-by: Ye Xiaolong Tested-by: Aaron Lu Signed-off-by: Patrick Bellasi Signed-off-by: Peter Zijlstra (Intel) Cc: Dietmar Eggemann Cc: Juri Lelli Cc: Linus Torvalds Cc: Morten Rasmussen Cc: Peter Zijlstra Cc: Quentin Perret Cc: Steve Muckle Cc: Suren Baghdasaryan Cc: Thomas Gleixner Cc: Todd Kjos Cc: Vincent Guittot Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths) Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/ Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit b771863247e812b1564d852190d61472f603181f Author: Michael Ellerman Date: Tue Nov 6 23:37:58 2018 +1100 powerpc/io: Fix the IO workarounds code to work with Radix [ Upstream commit 43c6494fa1499912c8177e71450c0279041152a6 ] Back in 2006 Ben added some workarounds for a misbehaviour in the Spider IO bridge used on early Cell machines, see commit 014da7ff47b5 ("[POWERPC] Cell "Spider" MMIO workarounds"). Later these were made to be generic, ie. not tied specifically to Spider. The code stashes a token in the high bits (59-48) of virtual addresses used for IO (eg. returned from ioremap()). This works fine when using the Hash MMU, but when we're using the Radix MMU the bits used for the token overlap with some of the bits of the virtual address. This is because the maximum virtual address is larger with Radix, up to c00fffffffffffff, and in fact we use that high part of the address range for ioremap(), see RADIX_KERN_IO_START. As it happens the bits that are used overlap with the bits that differentiate an IO address vs a linear map address. If the resulting address lies outside the linear mapping we will crash (see below), if not we just corrupt memory. virtio-pci 0000:00:00.0: Using 64-bit direct DMA at offset 800000000000000 Unable to handle kernel paging request for data at address 0xc000000080000014 ... CFAR: c000000000626b98 DAR: c000000080000014 DSISR: 42000000 IRQMASK: 0 GPR00: c0000000006c54fc c00000003e523378 c0000000016de600 0000000000000000 GPR04: c00c000080000014 0000000000000007 0fffffff000affff 0000000000000030 ^^^^ ... NIP [c000000000626c5c] .iowrite8+0xec/0x100 LR [c0000000006c992c] .vp_reset+0x2c/0x90 Call Trace: .pci_bus_read_config_dword+0xc4/0x120 (unreliable) .register_virtio_device+0x13c/0x1c0 .virtio_pci_probe+0x148/0x1f0 .local_pci_probe+0x68/0x140 .pci_device_probe+0x164/0x220 .really_probe+0x274/0x3b0 .driver_probe_device+0x80/0x170 .__driver_attach+0x14c/0x150 .bus_for_each_dev+0xb8/0x130 .driver_attach+0x34/0x50 .bus_add_driver+0x178/0x2f0 .driver_register+0x90/0x1a0 .__pci_register_driver+0x6c/0x90 .virtio_pci_driver_init+0x2c/0x40 .do_one_initcall+0x64/0x280 .kernel_init_freeable+0x36c/0x474 .kernel_init+0x24/0x160 .ret_from_kernel_thread+0x58/0x7c This hasn't been a problem because CONFIG_PPC_IO_WORKAROUNDS which enables this code is usually not enabled. It is only enabled when it's selected by PPC_CELL_NATIVE which is only selected by PPC_IBM_CELL_BLADE and that in turn depends on BIG_ENDIAN. So in order to hit the bug you need to build a big endian kernel, with IBM Cell Blade support enabled, as well as Radix MMU support, and then boot that on Power9 using Radix MMU. Still we can fix the bug, so let's do that. We simply use fewer bits for the token, taking the union of the restrictions on the address from both Hash and Radix, we end up with 8 bits we can use for the token. The only user of the token is iowa_mem_find_bus() which only supports 8 token values, so 8 bits is plenty for that. Fixes: 566ca99af026 ("powerpc/mm/radix: Add dummy radix_enabled()") Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 73fd491d770865df4ef34232fce28db8afcb13be Author: Jens Axboe Date: Fri Nov 9 15:58:40 2018 -0700 floppy: fix race condition in __floppy_read_block_0() [ Upstream commit de7b75d82f70c5469675b99ad632983c50b6f7e7 ] LKP recently reported a hang at bootup in the floppy code: [ 245.678853] INFO: task mount:580 blocked for more than 120 seconds. [ 245.679906] Tainted: G T 4.19.0-rc6-00172-ga9f38e1 #1 [ 245.680959] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 245.682181] mount D 6372 580 1 0x00000004 [ 245.683023] Call Trace: [ 245.683425] __schedule+0x2df/0x570 [ 245.683975] schedule+0x2d/0x80 [ 245.684476] schedule_timeout+0x19d/0x330 [ 245.685090] ? wait_for_common+0xa5/0x170 [ 245.685735] wait_for_common+0xac/0x170 [ 245.686339] ? do_sched_yield+0x90/0x90 [ 245.686935] wait_for_completion+0x12/0x20 [ 245.687571] __floppy_read_block_0+0xfb/0x150 [ 245.688244] ? floppy_resume+0x40/0x40 [ 245.688844] floppy_revalidate+0x20f/0x240 [ 245.689486] check_disk_change+0x43/0x60 [ 245.690087] floppy_open+0x1ea/0x360 [ 245.690653] __blkdev_get+0xb4/0x4d0 [ 245.691212] ? blkdev_get+0x1db/0x370 [ 245.691777] blkdev_get+0x1f3/0x370 [ 245.692351] ? path_put+0x15/0x20 [ 245.692871] ? lookup_bdev+0x4b/0x90 [ 245.693539] blkdev_get_by_path+0x3d/0x80 [ 245.694165] mount_bdev+0x2a/0x190 [ 245.694695] squashfs_mount+0x10/0x20 [ 245.695271] ? squashfs_alloc_inode+0x30/0x30 [ 245.695960] mount_fs+0xf/0x90 [ 245.696451] vfs_kern_mount+0x43/0x130 [ 245.697036] do_mount+0x187/0xc40 [ 245.697563] ? memdup_user+0x28/0x50 [ 245.698124] ksys_mount+0x60/0xc0 [ 245.698639] sys_mount+0x19/0x20 [ 245.699167] do_int80_syscall_32+0x61/0x130 [ 245.699813] entry_INT80_32+0xc7/0xc7 showing that we never complete that read request. The reason is that the completion setup is racy - it initializes the completion event AFTER submitting the IO, which means that the IO could complete before/during the init. If it does, we are passing garbage to complete() and we may sleep forever waiting for the event to occur. Fixes: 7b7b68bba5ef ("floppy: bail out in open() if drive is not responding to block0 read") Reviewed-by: Omar Sandoval Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c587ba480e12c6efdd81622fa1a3f865093dcbf5 Author: Ard Biesheuvel Date: Thu Nov 8 23:55:16 2018 +0100 crypto: simd - correctly take reqsize of wrapped skcipher into account [ Upstream commit 508a1c4df085a547187eed346f1bfe5e381797f1 ] The simd wrapper's skcipher request context structure consists of a single subrequest whose size is taken from the subordinate skcipher. However, in simd_skcipher_init(), the reqsize that is retrieved is not from the subordinate skcipher but from the cryptd request structure, whose size is completely unrelated to the actual wrapped skcipher. Reported-by: Qian Cai Signed-off-by: Ard Biesheuvel Tested-by: Qian Cai Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 49bcb0415da9112a60f30e6a94b7cc78c6c97257 Author: Xulin Sun Date: Tue Nov 6 16:42:19 2018 +0800 rtc: pcf2127: fix a kmemleak caused in pcf2127_i2c_gather_write [ Upstream commit 9bde0afb7a906f1dabdba37162551565740b862d ] pcf2127_i2c_gather_write() allocates memory as local variable for i2c_master_send(), after finishing the master transfer, the allocated memory should be freed. The kmemleak is reported: unreferenced object 0xffff80231e7dba80 (size 64): comm "hwclock", pid 27762, jiffies 4296880075 (age 356.944s) hex dump (first 32 bytes): 03 00 12 03 19 02 11 13 00 80 98 18 00 00 ff ff ................ 00 50 00 00 00 00 00 00 02 00 00 00 00 00 00 00 .P.............. backtrace: [] create_object+0xf8/0x278 [] kmemleak_alloc+0x74/0xa0 [] __kmalloc+0x1ac/0x348 [] pcf2127_i2c_gather_write+0x54/0xf8 [] _regmap_raw_write+0x464/0x850 [] regmap_bulk_write+0x1a4/0x348 [] pcf2127_rtc_set_time+0xac/0xe8 [] rtc_set_time+0x80/0x138 [] rtc_dev_ioctl+0x398/0x610 [] do_vfs_ioctl+0xb0/0x848 [] SyS_ioctl+0x8c/0xa8 [] el0_svc_naked+0x34/0x38 [] 0xffffffffffffffff Signed-off-by: Xulin Sun Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b411f9463a781a702246514402b897c9cd87f5f0 Author: Hans de Goede Date: Tue Sep 4 16:51:29 2018 +0200 rtc: cmos: Do not export alarm rtc_ops when we do not support alarms [ Upstream commit fbb974ba693bbfb4e24a62181ef16d4e45febc37 ] When there is no IRQ configured for the RTC, the rtc-cmos code does not support alarms, all alarm rtc_ops fail with -EIO / -EINVAL. The rtc-core expects a rtc driver which does not support rtc alarms to not have alarm ops at all. Otherwise the wakealarm sysfs attr will read as empty rather then returning an error, making it impossible for userspace to find out beforehand if alarms are supported. A system without an IRQ for the RTC before this patch: [root@localhost ~]# cat /sys/class/rtc/rtc0/wakealarm [root@localhost ~]# After this patch: [root@localhost ~]# cat /sys/class/rtc/rtc0/wakealarm cat: /sys/class/rtc/rtc0/wakealarm: No such file or directory [root@localhost ~]# This fixes gnome-session + systemd trying to use suspend-then-hibernate, which causes systemd to abort the suspend when writing the RTC alarm fails. BugLink: https://github.com/systemd/systemd/issues/9988 Signed-off-by: Hans de Goede Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 121f89dd7024bd90e5b1ee25258345a45075a849 Author: Anson Huang Date: Mon Nov 5 00:59:28 2018 +0000 cpufreq: imx6q: add return value check for voltage scale [ Upstream commit 6ef28a04d1ccf718eee069b72132ce4aa1e52ab9 ] Add return value check for voltage scale when ARM clock rate change fail. Signed-off-by: Anson Huang Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8d976d7a883cfc6bdb1199e6b6af20c211facbba Author: Scott Wood Date: Tue Nov 6 19:49:34 2018 -0600 KVM: PPC: Move and undef TRACE_INCLUDE_PATH/FILE [ Upstream commit 28c5bcf74fa07c25d5bd118d1271920f51ce2a98 ] TRACE_INCLUDE_PATH and TRACE_INCLUDE_FILE are used by , so like that #include, they should be outside #ifdef protection. They also need to be #undefed before defining, in case multiple trace headers are included by the same C file. This became the case on book3e after commit cf4a6085151a ("powerpc/mm: Add missing tracepoint for tlbie"), leading to the following build error: CC arch/powerpc/kvm/powerpc.o In file included from arch/powerpc/kvm/powerpc.c:51:0: arch/powerpc/kvm/trace.h:9:0: error: "TRACE_INCLUDE_PATH" redefined [-Werror] #define TRACE_INCLUDE_PATH . ^ In file included from arch/powerpc/kvm/../mm/mmu_decl.h:25:0, from arch/powerpc/kvm/powerpc.c:48: ./arch/powerpc/include/asm/trace.h:224:0: note: this is the location of the previous definition #define TRACE_INCLUDE_PATH asm ^ cc1: all warnings being treated as errors Reported-by: Christian Zigotzky Signed-off-by: Scott Wood Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit c7ae5115e32a4ae968291eb55e710f9d3c90793f Author: YueHaibing Date: Fri Oct 26 15:07:31 2018 +0800 scsi: hisi_sas: Remove set but not used variable 'dq_list' [ Upstream commit e34ff8edcae89922d187425ab0b82e6a039aa371 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/hisi_sas/hisi_sas_v1_hw.c: In function 'start_delivery_v1_hw': drivers/scsi/hisi_sas/hisi_sas_v1_hw.c:907:20: warning: variable 'dq_list' set but not used [-Wunused-but-set-variable] drivers/scsi/hisi_sas/hisi_sas_v2_hw.c: In function 'start_delivery_v2_hw': drivers/scsi/hisi_sas/hisi_sas_v2_hw.c:1671:20: warning: variable 'dq_list' set but not used [-Wunused-but-set-variable] drivers/scsi/hisi_sas/hisi_sas_v3_hw.c: In function 'start_delivery_v3_hw': drivers/scsi/hisi_sas/hisi_sas_v3_hw.c:889:20: warning: variable 'dq_list' set but not used [-Wunused-but-set-variable] It never used since introduction in commit fa222db0b036 ("scsi: hisi_sas: Don't lock DQ for complete task sending") Signed-off-by: YueHaibing Acked-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3d57a04fbd6d97a921030fdee7857485e34a94d0 Author: Arnd Bergmann Date: Fri Nov 2 16:35:48 2018 +0100 scsi: lpfc: fix remoteport access [ Upstream commit f8d294324598ec85bea2779512e48c94cbe4d7c6 ] The addition of a spinlock in lpfc_debugfs_nodelist_data() introduced a bug that lets us not skip NULL pointers correctly, as noticed by gcc-8: drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_nodelist_data.constprop': drivers/scsi/lpfc/lpfc_debugfs.c:728:13: error: 'nrport' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (nrport->port_role & FC_PORT_ROLE_NVME_INITIATOR) This changes the logic back to what it was, while keeping the added spinlock. Fixes: 9e210178267b ("scsi: lpfc: Synchronize access to remoteport via rport") Signed-off-by: Arnd Bergmann Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 08609aace6bb0a9604bcffeff621d8830d5250a1 Author: Masayoshi Mizuma Date: Tue Oct 30 21:50:25 2018 -0400 tools/testing/nvdimm: Fix the array size for dimm devices. [ Upstream commit af31b04b67f4fd7f639fd465a507c154c46fc9fb ] KASAN reports following global out of bounds access while nfit_test is being loaded. The out of bound access happens the following reference to dimm_fail_cmd_flags[dimm]. 'dimm' is over than the index value, NUM_DCR (==5). static int override_return_code(int dimm, unsigned int func, int rc) { if ((1 << func) & dimm_fail_cmd_flags[dimm]) { dimm_fail_cmd_flags[] definition: static unsigned long dimm_fail_cmd_flags[NUM_DCR]; 'dimm' is the return value of get_dimm(), and get_dimm() returns the index of handle[] array. The handle[] has 7 index. Let's use ARRAY_SIZE(handle) as the array size. KASAN report: ================================================================== BUG: KASAN: global-out-of-bounds in nfit_test_ctl+0x47bb/0x55b0 [nfit_test] Read of size 8 at addr ffffffffc10cbbe8 by task kworker/u41:0/8 ... Call Trace: dump_stack+0xea/0x1b0 ? dump_stack_print_info.cold.0+0x1b/0x1b ? kmsg_dump_rewind_nolock+0xd9/0xd9 print_address_description+0x65/0x22e ? nfit_test_ctl+0x47bb/0x55b0 [nfit_test] kasan_report.cold.6+0x92/0x1a6 nfit_test_ctl+0x47bb/0x55b0 [nfit_test] ... The buggy address belongs to the variable: dimm_fail_cmd_flags+0x28/0xffffffffffffa440 [nfit_test] ================================================================== Fixes: 39611e83a28c ("tools/testing/nvdimm: Make DSM failure code injection...") Signed-off-by: Masayoshi Mizuma Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit c4b25ef590f5bc8e4763612e249be67383432064 Author: Jerome Brunet Date: Mon Oct 29 16:13:40 2018 +0100 pinctrl: meson: fix meson8b ao pull register bits [ Upstream commit a1705f02704cd8a24d434bfd0141ee8142ad277a ] AO pull register definition is inverted between pull (up/down) and pull enable. Fixing this allows to properly apply bias setting through pinconf Fixes: 0fefcb6876d0 ("pinctrl: Add support for Meson8b") Signed-off-by: Jerome Brunet Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 93620bc4de8a00aedc08c34728ea5a472989d6ef Author: Jerome Brunet Date: Mon Oct 29 16:13:39 2018 +0100 pinctrl: meson: fix meson8 ao pull register bits [ Upstream commit e91b162d2868672d06010f34aa83d408db13d3c6 ] AO pull register definition is inverted between pull (up/down) and pull enable. Fixing this allows to properly apply bias setting through pinconf Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs") Signed-off-by: Jerome Brunet Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c74e3fc6d0c3dc22a4022c9729cf269278fcdde5 Author: Jerome Brunet Date: Mon Oct 29 16:13:38 2018 +0100 pinctrl: meson: fix gxl ao pull register bits [ Upstream commit ed3a2b74f3eb34c84c8377353f4730f05acdfd05 ] AO pull register definition is inverted between pull (up/down) and pull enable. Fixing this allows to properly apply bias setting through pinconf Fixes: 0f15f500ff2c ("pinctrl: meson: Add GXL pinctrl definitions") Signed-off-by: Jerome Brunet Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5922ab4adc13203f745bb82557e0ffd49c4a1cbb Author: Jerome Brunet Date: Mon Oct 29 16:13:37 2018 +0100 pinctrl: meson: fix gxbb ao pull register bits [ Upstream commit 4bc51e1e350cd4707ce6e551a93eae26d40b9889 ] AO pull register definition is inverted between pull (up/down) and pull enable. Fixing this allows to properly apply bias setting through pinconf Fixes: 468c234f9ed7 ("pinctrl: amlogic: Add support for Amlogic Meson GXBB SoC") Signed-off-by: Jerome Brunet Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 71ab26e917de919b0120738955d5734d02e58d73 Author: Jerome Brunet Date: Tue Oct 23 18:03:19 2018 +0200 pinctrl: meson: fix pinconf bias disable [ Upstream commit e39f9dd8206ad66992ac0e6218ef1ba746f2cce9 ] If a bias is enabled on a pin of an Amlogic SoC, calling .pin_config_set() with PIN_CONFIG_BIAS_DISABLE will not disable the bias. Instead it will force a pull-down bias on the pin. Instead of the pull type register bank, the driver should access the pull enable register bank. Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs") Signed-off-by: Jerome Brunet Acked-by: Neil Armstrong Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 20663629f6ae7bc072a8bbc658721bd99626a26d Author: Amir Goldstein Date: Tue Oct 30 20:29:53 2018 +0200 fanotify: fix handling of events on child sub-directory commit b469e7e47c8a075cc08bcd1e85d4365134bdcdd5 upstream. When an event is reported on a sub-directory and the parent inode has a mark mask with FS_EVENT_ON_CHILD|FS_ISDIR, the event will be sent to fsnotify() even if the event type is not in the parent mark mask (e.g. FS_OPEN). Further more, if that event happened on a mount or a filesystem with a mount/sb mark that does have that event type in their mask, the "on child" event will be reported on the mount/sb mark. That is not desired, because user will get a duplicate event for the same action. Note that the event reported on the victim inode is never merged with the event reported on the parent inode, because of the check in should_merge(): old_fsn->inode == new_fsn->inode. Fix this by looking for a match of an actual event type (i.e. not just FS_ISDIR) in parent's inode mark mask and by not reporting an "on child" event to group if event type is only found on mount/sb marks. [backport hint: The bug seems to have always been in fanotify, but this patch will only apply cleanly to v4.19.y] Cc: # v4.19 Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara [amir: backport to v4.19] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 1dc3c17cdb9fb1dd9ff95c6696f7c13821836cd2 Author: Amir Goldstein Date: Thu Oct 4 00:25:33 2018 +0300 fsnotify: generalize handling of extra event flags commit 007d1e8395eaa59b0e7ad9eb2b53a40859446a88 upstream. FS_EVENT_ON_CHILD gets a special treatment in fsnotify() because it is not a flag specifying an event type, but rather an extra flags that may be reported along with another event and control the handling of the event by the backend. FS_ISDIR is also an "extra flag" and not an "event type" and therefore desrves the same treatment. With inotify/dnotify backends it was never possible to set FS_ISDIR in mark masks, so it did not matter. With fanotify backend, mark adding code jumps through hoops to avoid setting the FS_ISDIR in the commulative object mask. Separate the constant ALL_FSNOTIFY_EVENTS to ALL_FSNOTIFY_FLAGS and ALL_FSNOTIFY_EVENTS, so the latter can be used to test for specific event types. Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 6763372b816c4bf98f6f103bba4c4bf47e3ae0d8 Author: Michael J. Ruhl Date: Mon Sep 10 09:39:03 2018 -0700 IB/hfi1: Eliminate races in the SDMA send error path commit a0e0cb82804a6a21d9067022c2dfdf80d11da429 upstream. pq_update() can only be called in two places: from the completion function when the complete (npkts) sequence of packets has been submitted and processed, or from setup function if a subset of the packets were submitted (i.e. the error path). Currently both paths can call pq_update() if an error occurrs. This race will cause the n_req value to go negative, hanging file_close(), or cause a crash by freeing the txlist more than once. Several variables are used to determine SDMA send state. Most of these are unnecessary, and have code inspectible races between the setup function and the completion function, in both the send path and the error path. The request 'status' value can be set by the setup or by the completion function. This is code inspectibly racy. Since the status is not needed in the completion code or by the caller it has been removed. The request 'done' value races between usage by the setup and the completion function. The completion function does not need this. When the number of processed packets matches npkts, it is done. The 'has_error' value races between usage of the setup and the completion function. This can cause incorrect error handling and leave the n_req in an incorrect value (i.e. negative). Simplify the code by removing all of the unneeded state checks and variables. Clean up iovs node when it is freed. Eliminate race conditions in the error path: If all packets are submitted, the completion handler will set the completion status correctly (ok or aborted). If all packets are not submitted, the caller must wait until the submitted packets have completed, and then set the completion status. These two change eliminate the race condition in the error path. Reviewed-by: Mitko Haralanov Reviewed-by: Mike Marciniszyn Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 87403e35bc56d3c7fa626c1ce1eaeda30763347c Author: Erik Schmauss Date: Wed Oct 17 14:09:35 2018 -0700 ACPICA: AML interpreter: add region addresses in global list during initialization commit 4abb951b73ff0a8a979113ef185651aa3c8da19b upstream. The table load process omitted adding the operation region address range to the global list. This omission is problematic because the OS queries the global list to check for address range conflicts before deciding which drivers to load. This commit may result in warning messages that look like the following: [ 7.871761] ACPI Warning: system_IO range 0x00000428-0x0000042F conflicts with op_region 0x00000400-0x0000047F (\PMIO) (20180531/utaddress-213) [ 7.871769] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver However, these messages do not signify regressions. It is a result of properly adding address ranges within the global address list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011 Tested-by: Jean-Marc Lenoir Signed-off-by: Erik Schmauss Cc: All applicable Signed-off-by: Rafael J. Wysocki Cc: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit d5a9ba4324d5263b7b86cb8fd4779d3f159663db Author: Marc Kleine-Budde Date: Fri Nov 9 15:01:50 2018 +0100 can: flexcan: remove not needed struct flexcan_priv::tx_mb and struct flexcan_priv::tx_mb_idx commit e05237f9da42ee52e73acea0bb082d788e111229 upstream. The previous patch changes the TX path to always use the last mailbox regardless of the used offload scheme (rx-fifo or timestamp based). This means members "tx_mb" and "tx_mb_idx" of the struct flexcan_priv don't depend on the offload scheme, so replace them by compile time constants. Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 24e5589791d09214e31335ae2b581c668d4803b7 Author: Alexander Stein Date: Thu Oct 11 17:01:25 2018 +0200 can: flexcan: Always use last mailbox for TX commit cbffaf7aa09edbaea2bc7dc440c945297095e2fd upstream. Essentially this patch moves the TX mailbox to position 63, regardless of timestamp based offloading or RX FIFO. So mainly the iflag register usage regarding TX has changed. The rest is consolidating RX FIFO and timestamp offloading as they now use both the same TX mailbox. The reason is a very annoying behavior regarding sending RTR frames when _not_ using RX FIFO: If a TX mailbox sent a RTR frame it becomes a RX mailbox. For that reason flexcan_irq disables the TX mailbox again. But if during the time the RTR was sent and the TX mailbox is disabled a new CAN frames is received, it is lost without notice. The reason is that so-called "Move-in" process starts from the lowest mailbox which happen to be a TX mailbox set to EMPTY. Steps to reproduce (I used an imx7d): 1. generate regular bursts of messages 2. send a RTR from flexcan with higher priority than burst messages every 1ms, e.g. cangen -I 0x100 -L 0 -g 1 -R can0 3. notice a lost message without notification after some seconds When running an iperf in parallel this problem is occurring even more frequently. Using filters is not possible as at least one single CAN-ID is allowed. Handling the TX MB during RX is also not possible as there is no race-free disable of RX MB. There is still a slight window when the described problem can occur. But for that all RX MB must be in use which is essentially next to an overrun. Still there will be no indication if it ever occurs. Signed-off-by: Alexander Stein Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 50d94ac1da7457ac66cc6e4dd4e0d804a9bfdd0e Author: Lukas Wunner Date: Sat Oct 27 10:36:54 2018 +0200 can: hi311x: Use level-triggered interrupt commit f164d0204b1156a7e0d8d1622c1a8d25752befec upstream. If the hi3110 shares the SPI bus with another traffic-intensive device and packets are received in high volume (by a separate machine sending with "cangen -g 0 -i -x"), reception stops after a few minutes and the counter in /proc/interrupts stops incrementing. Bus state is "active". Bringing the interface down and back up reconvenes the reception. The issue is not observed when the hi3110 is the sole device on the SPI bus. Using a level-triggered interrupt makes the issue go away and lets the hi3110 successfully receive 2 GByte over the course of 5 days while a ks8851 Ethernet chip on the same SPI bus handles 6 GByte of traffic. Unfortunately the hi3110 datasheet is mum on the trigger type. The pin description on page 3 only specifies the polarity (active high): http://www.holtic.com/documents/371-hi-3110_v-rev-kpdf.do Cc: Mathias Duckeck Cc: Akshay Bhat Cc: Casey Fitzpatrick Signed-off-by: Lukas Wunner Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit bf8295faed733debbe5625ec1a0c137f1170ac2f Author: Oliver Hartkopp Date: Wed Oct 24 10:27:12 2018 +0200 can: raw: check for CAN FD capable netdev in raw_sendmsg() commit a43608fa77213ad5ac5f75994254b9f65d57cfa0 upstream. When the socket is CAN FD enabled it can handle CAN FD frame transmissions. Add an additional check in raw_sendmsg() as a CAN2.0 CAN driver (non CAN FD) should never see a CAN FD frame. Due to the commonly used can_dropped_invalid_skb() function the CAN 2.0 driver would drop that CAN FD frame anyway - but with this patch the user gets a proper -EINVAL return code. Signed-off-by: Oliver Hartkopp Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 04f985776f0428a39cc6a68be5c74c3cf2d8cf83 Author: Oleksij Rempel Date: Tue Sep 18 11:40:39 2018 +0200 can: flexcan: handle tx-complete CAN frames via rx-offload infrastructure commit ed72bc8bcb9277061e753faf300b20f97323761c upstream. Current flexcan driver will put TX-ECHO in regular unsorted way, in this case TX-ECHO can come after the response to the same TXed message. In some cases, for example for J1939 stack, things will break. This patch is using new rx-offload API to put the messages just in the right place. Signed-off-by: Oleksij Rempel Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit f699c3222635eaf919f3d4716fe0e0565cd4afad Author: Oleksij Rempel Date: Tue Sep 18 11:40:41 2018 +0200 can: flexcan: use can_rx_offload_queue_sorted() for flexcan_irq_bus_*() commit d788905f68fd4714c82936f6f7f1d3644d7ae7ef upstream. Currently, in case of bus error, driver will generate error message and put in the tail of the message queue. To avoid confusions, this change should place the bus related messages in proper order. Signed-off-by: Oleksij Rempel Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 6ce9d61a65373d99ad310bf5d1d3786a3d637c72 Author: Oleksij Rempel Date: Tue Sep 18 11:40:40 2018 +0200 can: rx-offload: rename can_rx_offload_irq_queue_err_skb() to can_rx_offload_queue_tail() commit 4530ec36bb1e0d24f41c33229694adacda3d5d89 upstream. This function has nothing todo with error. Signed-off-by: Oleksij Rempel Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 169130c87a88c1d85433cb0ef469c826dbe2f2d1 Author: Oleksij Rempel Date: Tue Sep 18 11:40:38 2018 +0200 can: rx-offload: introduce can_rx_offload_get_echo_skb() and can_rx_offload_queue_sorted() functions commit 55059f2b7f868cd43b3ad30e28e18347e1b46ace upstream. Current CAN framework can't guarantee proper/chronological order of RX and TX-ECHO messages. To make this possible, drivers should use this functions instead of can_get_echo_skb(). Signed-off-by: Oleksij Rempel Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 474673a94f1758a64b22c0c012eaae2ecdcf9810 Author: Marc Kleine-Budde Date: Wed Oct 31 14:15:13 2018 +0100 can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb commit 7da11ba5c5066dadc2e96835a6233d56d7b7764a upstream. Prior to echoing a successfully transmitted CAN frame (by calling can_get_echo_skb()), CAN drivers have to put the CAN frame (by calling can_put_echo_skb() in the transmit function). These put and get function take an index as parameter, which is used to identify the CAN frame. A driver calling can_get_echo_skb() with a index not pointing to a skb is a BUG, so add an appropriate error message. Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e3b8d98e3758514443b39f9e719df03369f18d2b Author: Marc Kleine-Budde Date: Wed Oct 31 14:05:26 2018 +0100 can: dev: __can_get_echo_skb(): Don't crash the kernel if can_priv::echo_skb is accessed out of bounds commit e7a6994d043a1e31d5b17706a22ce33d2a3e4cdc upstream. If the "struct can_priv::echo_skb" is accessed out of bounds would lead to a kernel crash. Better print a sensible warning message instead and try to recover. Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit cfc8ed910312c97fbf7ddf3fca8e65cb76894fa5 Author: Marc Kleine-Budde Date: Wed Oct 31 11:08:21 2018 +0100 can: dev: __can_get_echo_skb(): replace struct can_frame by canfd_frame to access frame length commit 200f5c49f7a2cd694436bfc6cb0662b794c96736 upstream. This patch replaces the use of "struct can_frame::can_dlc" by "struct canfd_frame::len" to access the frame's length. As it is ensured that both structures have a compatible memory layout for this member this is no functional change. Futher, this compatibility is documented in a comment. Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 5877d2c0eac8f19ff8f4a8814708feb71b0fab27 Author: Marc Kleine-Budde Date: Wed Oct 31 10:37:46 2018 +0100 can: dev: can_get_echo_skb(): factor out non sending code to __can_get_echo_skb() commit a4310fa2f24687888ce80fdb0e88583561a23700 upstream. This patch factors out all non sending parts of can_get_echo_skb() into a seperate function __can_get_echo_skb(), so that it can be re-used in an upcoming patch. Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 8d2aed6439cf41bcaee3d44eff5bfacb2bfb3039 Author: Pankaj Bansal Date: Wed Aug 1 19:36:46 2018 +0530 can: flexcan: Unlock the MB unconditionally commit 5178b7cd8e42448b1041716f124734eaaa36ca50 upstream. Unlock the MB irrespective of reception method being FIFO or timestamp based. It is optional but recommended to unlock Mailbox as soon as possible and make it available for reception. Reported-by: Alexander Stein Signed-off-by: Pankaj Bansal Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 09132a6b01a75c5501aa05b388c91b4449459998 Author: Thomas Zimmermann Date: Thu Nov 15 11:42:16 2018 +0100 drm/ast: Remove existing framebuffers before loading driver commit 5478ad10e7850ce3d8b7056db05ddfa3c9ddad9a upstream. If vesafb attaches to the AST device, it configures the framebuffer memory for uncached access by default. When ast.ko later tries to attach itself to the device, it wants to use write-combining on the framebuffer memory, but vesefb's existing configuration for uncached access takes precedence. This results in reduced performance. Removing the framebuffer's configuration before loding the AST driver fixes the problem. Other DRM drivers already contain equivalent code. Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963 Signed-off-by: Thomas Zimmermann Cc: Tested-by: Y.C. Chen Reviewed-by: Jean Delvare Tested-by: Jean Delvare Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 80142af39bd9e403d02d0595736664f6944f1a57 Author: Y.C. Chen Date: Tue Oct 30 11:34:46 2018 +0800 drm/ast: fixed cursor may disappear sometimes commit 7989b9ee8bafe5cc625381dd0c3c4586de27ca26 upstream. Signed-off-by: Y.C. Chen Cc: Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e9d2c0fbe161e3ca77e041cfc72f09a8f69fdbda Author: Y.C. Chen Date: Wed Oct 3 14:57:47 2018 +0800 drm/ast: change resolution may cause screen blurred commit 1a37bd823891568f8721989aed0615835632d81a upstream. The value of pitches is not correct while calling mode_set. The issue we found so far on following system: - Debian8 with XFCE Desktop - Ubuntu with KDE Desktop - SUSE15 with KDE Desktop Signed-off-by: Y.C. Chen Cc: Tested-by: Jean Delvare Reviewed-by: Jean Delvare Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 382debd2fe42f3b6ffbfc089450980411bdfd699 Author: Ville Syrjälä Date: Wed Nov 14 19:34:40 2018 +0200 drm/i915: Disable LP3 watermarks on all SNB machines commit 21556350ade3cb5d7afecc8b3544e56431d21695 upstream. I have a Thinkpad X220 Tablet in my hands that is losing vblank interrupts whenever LP3 watermarks are used. If I nudge the latency value written to the WM3 register just by one in either direction the problem disappears. That to me suggests that the punit will not enter the corrsponding powersave mode (MPLL shutdown IIRC) unless the latency value in the register matches exactly what we read from SSKPD. Ie. it's not really a latency value but rather just a cookie by which the punit can identify the desired power saving state. On HSW/BDW this was changed such that we actually just write the WM level number into those bits, which makes much more sense given the observed behaviour. We could try to handle this by disallowing LP3 watermarks only when vblank interrupts are enabled but we'd first have to prove that only vblank interrupts are affected, which seems unlikely. Also we can't grab the wm mutex from the vblank enable/disable hooks because those are called with various spinlocks held. Thus we'd have to redesigne the watermark locking. So to play it safe and keep the code simple we simply disable LP3 watermarks on all SNB machines. To do that we simply zero out the latency values for watermark level 3, and we adjust the watermark computation to check for that. The behaviour now matches that of the g4x/vlv/skl wm code in the presence of a zeroed latency value. v2: s/USHRT_MAX/U32_MAX/ for consistency with the types (Chris) Cc: stable@vger.kernel.org Cc: Chris Wilson Acked-by: Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20181114173440.6730-1-ville.syrjala@linux.intel.com (cherry picked from commit 03981c6ebec4fc7056b9b45f847393aeac90d060) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit e3290a5e24df81bf2cdb603f0a897725d3eb3ea5 Author: Felix Kuehling Date: Fri Jul 20 11:37:25 2018 -0400 drm/amdgpu: Fix oops when pp_funcs->switch_power_profile is unset commit 919a52fc4ca137c871f295224507fa3401e08472 upstream. On Vega20 and other pre-production GPUs, powerplay is not enabled yet. Check for NULL pointers before calling pp_funcs function pointers. Also affects Kaveri. CC: Joerg Roedel Signed-off-by: Felix Kuehling Reviewed-by: Alex Deucher Tested-by: Joerg Roedel Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d9ea911e2b90478b29fd6b2325723099a55f6171 Author: Boris Brezillon Date: Thu Nov 15 11:58:52 2018 +0100 drm/vc4: Set ->legacy_cursor_update to false when doing non-async updates commit fcc86cb45d38ca2f24bcea9c29c7f4742041caed upstream. drm_atomic_helper_setup_commit() auto-completes commit->flip_done when state->legacy_cursor_update is true, but we know for sure that we want a sync update when we call drm_atomic_helper_setup_commit() from vc4_atomic_commit(). Explicitly set state->legacy_cursor_update to false to prevent this auto-completion. Fixes: 184d3cf4f738 ("drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20181115105852.9844-2-boris.brezillon@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 7841a545f8bd66567edc21669531116caf1daeb1 Author: Takashi Iwai Date: Mon Nov 19 12:55:12 2018 +0100 drm/amdgpu: Add missing firmware entry for HAINAN commit 8d4d7c58994759bbd9f4fec32d88bf0e0b89302e upstream. Due to lack of MODULE_FIRMWARE() with hainan_mc.bin, the driver doesn't work properly in initrd. Let's add it. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1116239 Fixes: 8eaf2b1faaf4 ("drm/amdgpu: switch firmware path for SI parts") Cc: Reviewed-by: Christian König Signed-off-by: Takashi Iwai Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d543f583e3af75ab4c9d5737273614fadcec9d35 Author: Paul Kocialkowski Date: Thu Nov 15 17:32:48 2018 +0100 drm/fb-helper: Blacklist writeback when adding connectors to fbdev commit 8fd3b90300bec541806dac271de2fd44e2e4e2d2 upstream. Writeback connectors do not produce any on-screen output and require special care for use. Such connectors are hidden from enumeration in DRM resources by default, but they are still picked-up by fbdev. This makes rather little sense since fbdev is not really adapted for dealing with writeback. Moreover, this is also a source of issues when userspace disables the CRTC (and associated plane) without detaching the CRTC from the connector (which is hidden by default). In this case, the connector is still using the CRTC, leading to am "enabled/connectors mismatch" and eventually the failure of the associated atomic commit. This situation happens with VC4 testing under IGT GPU Tools. Filter out writeback connectors in the fbdev helper to solve this. Signed-off-by: Paul Kocialkowski Reviewed-by: Boris Brezillon Reviewed-by: Maxime Ripard Tested-by: Maxime Ripard Fixes: 935774cd71fe ("drm: Add writeback connector type") Cc: # v4.19+ Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181115163248.21168-1-paul.kocialkowski@bootlin.com Signed-off-by: Greg Kroah-Hartman commit cddcc9959a32999ce2d38018900595a5ab453eb2 Author: Eric Dumazet Date: Mon Oct 1 23:24:26 2018 -0700 tcp: do not release socket ownership in tcp_close() commit 8873c064d1de579ea23412a6d3eee972593f142b upstream. syzkaller was able to hit the WARN_ON(sock_owned_by_user(sk)); in tcp_close() While a socket is being closed, it is very possible other threads find it in rtnetlink dump. tcp_get_info() will acquire the socket lock for a short amount of time (slow = lock_sock_fast(sk)/unlock_sock_fast(sk, slow);), enough to trigger the warning. Fixes: 67db3e4bfbc9 ("tcp: no longer hold ehash lock while calling tcp_get_info()") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5999609a93a4eb4956b6548159ce69295b1557b2 Author: Aneesh Kumar K.V Date: Fri Oct 26 15:09:01 2018 -0700 mm/memory.c: recheck page table entry with page table lock held commit ff09d7ec9786be4ad7589aa987d7dc66e2dd9160 upstream. We clear the pte temporarily during read/modify/write update of the pte. If we take a page fault while the pte is cleared, the application can get SIGBUS. One such case is with remap_pfn_range without a backing vm_ops->fault callback. do_fault will return SIGBUS in that case. cpu 0 cpu1 mprotect() ptep_modify_prot_start()/pte cleared. . . page fault. . . prep_modify_prot_commit() Fix this by taking page table lock and rechecking for pte_none. [aneesh.kumar@linux.ibm.com: fix crash observed with syzkaller run] Link: http://lkml.kernel.org/r/87va6bwlfg.fsf@linux.ibm.com Link: http://lkml.kernel.org/r/20180926031858.9692-1-aneesh.kumar@linux.ibm.com Signed-off-by: Aneesh Kumar K.V Acked-by: Kirill A. Shutemov Cc: Willem de Bruijn Cc: Eric Dumazet Cc: Ido Schimmel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3996e891ec97c9c5f66ed3a2a450e3621ec32c50 Author: Dmitry Vyukov Date: Fri Oct 26 15:03:12 2018 -0700 mm: don't warn about large allocations for slab commit 61448479a9f2c954cde0cfe778cb6bec5d0a748d upstream. Slub does not call kmalloc_slab() for sizes > KMALLOC_MAX_CACHE_SIZE, instead it falls back to kmalloc_large(). For slab KMALLOC_MAX_CACHE_SIZE == KMALLOC_MAX_SIZE and it calls kmalloc_slab() for all allocations relying on NULL return value for over-sized allocations. This inconsistency leads to unwanted warnings from kmalloc_slab() for over-sized allocations for slab. Returning NULL for failed allocations is the expected behavior. Make slub and slab code consistent by checking size > KMALLOC_MAX_CACHE_SIZE in slab before calling kmalloc_slab(). While we are here also fix the check in kmalloc_slab(). We should check against KMALLOC_MAX_CACHE_SIZE rather than KMALLOC_MAX_SIZE. It all kinda worked because for slab the constants are the same, and slub always checks the size against KMALLOC_MAX_CACHE_SIZE before kmalloc_slab(). But if we get there with size > KMALLOC_MAX_CACHE_SIZE anyhow bad things will happen. For example, in case of a newly introduced bug in slub code. Also move the check in kmalloc_slab() from function entry to the size > 192 case. This partially compensates for the additional check in slab code and makes slub code a bit faster (at least theoretically). Also drop __GFP_NOWARN in the warning check. This warning means a bug in slab code itself, user-passed flags have nothing to do with it. Nothing of this affects slob. Link: http://lkml.kernel.org/r/20180927171502.226522-1-dvyukov@gmail.com Signed-off-by: Dmitry Vyukov Reported-by: syzbot+87829a10073277282ad1@syzkaller.appspotmail.com Reported-by: syzbot+ef4e8fc3a06e9019bb40@syzkaller.appspotmail.com Reported-by: syzbot+6e438f4036df52cbb863@syzkaller.appspotmail.com Reported-by: syzbot+8574471d8734457d98aa@syzkaller.appspotmail.com Reported-by: syzbot+af1504df0807a083dbd9@syzkaller.appspotmail.com Acked-by: Christoph Lameter Acked-by: Vlastimil Babka Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 292c48e2971e7fda592b8e23567c63b7efb267ae Author: Eric Dumazet Date: Mon Oct 22 09:24:27 2018 -0700 llc: do not use sk_eat_skb() commit 604d415e2bd642b7e02c80e719e0396b9d4a77a6 upstream. syzkaller triggered a use-after-free [1], caused by a combination of skb_get() in llc_conn_state_process() and usage of sk_eat_skb() sk_eat_skb() is assuming the skb about to be freed is only used by the current thread. TCP/DCCP stacks enforce this because current thread holds the socket lock. llc_conn_state_process() wants to make sure skb does not disappear, and holds a reference on the skb it manipulates. But as soon as this skb is added to socket receive queue, another thread can consume it. This means that llc must use regular skb_unlink() and kfree_skb() so that both producer and consumer can safely work on the same skb. [1] BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:43 [inline] BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:967 [inline] BUG: KASAN: use-after-free in kfree_skb+0xb7/0x580 net/core/skbuff.c:655 Read of size 4 at addr ffff8801d1f6fba4 by task ksoftirqd/1/18 CPU: 1 PID: 18 Comm: ksoftirqd/1 Not tainted 4.19.0-rc8+ #295 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267 kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272 atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] refcount_read include/linux/refcount.h:43 [inline] skb_unref include/linux/skbuff.h:967 [inline] kfree_skb+0xb7/0x580 net/core/skbuff.c:655 llc_sap_state_process+0x9b/0x550 net/llc/llc_sap.c:224 llc_sap_rcv+0x156/0x1f0 net/llc/llc_sap.c:297 llc_sap_handler+0x65e/0xf80 net/llc/llc_sap.c:438 llc_rcv+0x79e/0xe20 net/llc/llc_input.c:208 __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023 process_backlog+0x218/0x6f0 net/core/dev.c:5829 napi_poll net/core/dev.c:6249 [inline] net_rx_action+0x7c5/0x1950 net/core/dev.c:6315 __do_softirq+0x30c/0xb03 kernel/softirq.c:292 run_ksoftirqd+0x94/0x100 kernel/softirq.c:653 smpboot_thread_fn+0x68b/0xa00 kernel/smpboot.c:164 kthread+0x35a/0x420 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413 Allocated by task 18: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc_node+0x144/0x730 mm/slab.c:3644 __alloc_skb+0x119/0x770 net/core/skbuff.c:193 alloc_skb include/linux/skbuff.h:995 [inline] llc_alloc_frame+0xbc/0x370 net/llc/llc_sap.c:54 llc_station_ac_send_xid_r net/llc/llc_station.c:52 [inline] llc_station_rcv+0x1dc/0x1420 net/llc/llc_station.c:111 llc_rcv+0xc32/0xe20 net/llc/llc_input.c:220 __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023 process_backlog+0x218/0x6f0 net/core/dev.c:5829 napi_poll net/core/dev.c:6249 [inline] net_rx_action+0x7c5/0x1950 net/core/dev.c:6315 __do_softirq+0x30c/0xb03 kernel/softirq.c:292 Freed by task 16383: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x290 mm/slab.c:3756 kfree_skbmem+0x154/0x230 net/core/skbuff.c:582 __kfree_skb+0x1d/0x20 net/core/skbuff.c:642 sk_eat_skb include/net/sock.h:2366 [inline] llc_ui_recvmsg+0xec2/0x1610 net/llc/af_llc.c:882 sock_recvmsg_nosec net/socket.c:794 [inline] sock_recvmsg+0xd0/0x110 net/socket.c:801 ___sys_recvmsg+0x2b6/0x680 net/socket.c:2278 __sys_recvmmsg+0x303/0xb90 net/socket.c:2390 do_sys_recvmmsg+0x181/0x1a0 net/socket.c:2466 __do_sys_recvmmsg net/socket.c:2484 [inline] __se_sys_recvmmsg net/socket.c:2480 [inline] __x64_sys_recvmmsg+0xbe/0x150 net/socket.c:2480 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8801d1f6fac0 which belongs to the cache skbuff_head_cache of size 232 The buggy address is located 228 bytes inside of 232-byte region [ffff8801d1f6fac0, ffff8801d1f6fba8) The buggy address belongs to the page: page:ffffea000747dbc0 count:1 mapcount:0 mapping:ffff8801d9be7680 index:0xffff8801d1f6fe80 flags: 0x2fffc0000000100(slab) raw: 02fffc0000000100 ffffea0007346e88 ffffea000705b108 ffff8801d9be7680 raw: ffff8801d1f6fe80 ffff8801d1f6f0c0 000000010000000b 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801d1f6fa80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ffff8801d1f6fb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8801d1f6fb80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc ^ ffff8801d1f6fc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801d1f6fc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 331bd738eb17903edf6b87e70224395532241650 Author: Andrew Price Date: Mon Oct 8 07:52:43 2018 -0500 gfs2: Don't leave s_fs_info pointing to freed memory in init_sbd commit 4c62bd9cea7bcf10292f7e4c57a2bca332942697 upstream. When alloc_percpu() fails, sdp gets freed but sb->s_fs_info still points to the same address. Move the assignment after that error check so that s_fs_info can only point to a valid sdp or NULL, which is checked for later in the error path, in gfs2_kill_super(). Reported-by: syzbot+dcb8b3587445007f5808@syzkaller.appspotmail.com Signed-off-by: Andrew Price Signed-off-by: Bob Peterson Signed-off-by: Greg Kroah-Hartman commit cd947138e8c31e8cfcd489c12e9b97271beb6e79 Author: Xin Long Date: Mon Oct 29 23:10:29 2018 +0800 sctp: clear the transport of some out_chunk_list chunks in sctp_assoc_rm_peer commit df132eff463873e14e019a07f387b4d577d6d1f9 upstream. If a transport is removed by asconf but there still are some chunks with this transport queuing on out_chunk_list, later an use-after-free issue will be caused when accessing this transport from these chunks in sctp_outq_flush(). This is an old bug, we fix it by clearing the transport of these chunks in out_chunk_list when removing a transport in sctp_assoc_rm_peer(). Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8380cbfe4eab437309da558ceb5404b7be4dfc7a Author: Tetsuo Handa Date: Fri Nov 2 15:48:42 2018 -0700 bfs: add sanity check at bfs_fill_super() commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e upstream. syzbot is reporting too large memory allocation at bfs_fill_super() [1]. Since file system image is corrupted such that bfs_sb->s_start == 0, bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and printf(). [1] https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e96 Link: http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Tetsuo Handa Reported-by: syzbot Reviewed-by: Andrew Morton Cc: Tigran Aivazian Cc: Matthew Wilcox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9891b528f91d57027c1ce7d9f8165f781c1b532c Author: Dmitry Torokhov Date: Tue Oct 16 17:07:35 2018 -0700 Input: synaptics - avoid using uninitialized variable when probing commit f39f8688888ae74fa8deae2d01289b69b4727394 upstream. synaptics_detect() does not check whether sending commands to the device succeeds and instead relies on getting unique data from the device. Let's make sure we seed entire buffer with zeroes to make sure we will not use garbage on stack that just happen to be 0x47. Reported-by: syzbot+13cb3b01d0784e4ffc3f@syzkaller.appspotmail.com Reviewed-by: Benjamin Tissoires Reviewed-by: Peter Hutterer Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3962e78a9fcb881d3865eba7faf51536e062ccf8 Author: Tetsuo Handa Date: Sat Sep 8 01:42:58 2018 +0900 selinux: Add __GFP_NOWARN to allocation at str_read() commit 4458bba09788e70e8fb39ad003f087cd9dfbd6ac upstream. syzbot is hitting warning at str_read() [1] because len parameter can become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for this case. [1] https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 Signed-off-by: Tetsuo Handa Reported-by: syzbot Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 829567dd9196a32951c7e4de91d590e684ce3b00 Author: Dominique Martinet Date: Mon Aug 27 15:12:05 2018 +0900 v9fs_dir_readdir: fix double-free on p9stat_read error commit 81c99089bce693b94b775b6eb888115d2d540086 upstream. p9stat_read will call p9stat_free on error, we should only free the struct content on success. There also is no need to "p9stat_init" st as the read function will zero the whole struct for us anyway, so clean up the code a bit while we are here. Link: http://lkml.kernel.org/r/1535410108-20650-1-git-send-email-asmadeus@codewreck.org Signed-off-by: Dominique Martinet Reported-by: syzbot+d4252148d198410b864f@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman commit 9f9e2bd0bbcf787c90c28bda082b6287b5c5661e Author: Konstantin Khlebnikov Date: Tue Oct 16 11:56:26 2018 +0300 tools/power/cpupower: fix compilation with STATIC=true commit 9de9aa45e9bd67232e000cca42ceb134b8ae51b6 upstream. Rename duplicate sysfs_read_file into cpupower_read_sysfs and fix linking. Signed-off-by: Konstantin Khlebnikov Acked-by: Thomas Renninger Cc: Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Greg Kroah-Hartman commit b7d5ef6af8eb1da163bcec2723c6bec87e95faed Author: Keerthy Date: Wed Nov 7 10:04:23 2018 +0530 opp: ti-opp-supply: Correct the supply in _get_optimal_vdd_voltage call commit 622fecbccfe86a8052dea6b512d3821dcce29994 upstream. _get_optimal_vdd_voltage call provides new_supply_vbb->u_volt as the reference voltage while it should be really new_supply_vdd->u_volt. Cc: 4.16+ # v4.16+ Fixes: 9a835fa6e47 ("PM / OPP: Add ti-opp-supply driver") Signed-off-by: Keerthy Acked-by: Dave Gerlach Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 50f4a3b8eb62a4ff8fbf23a6e8b9fde147ed0202 Author: Keerthy Date: Wed Nov 7 10:04:22 2018 +0530 opp: ti-opp-supply: Dynamically update u_volt_min commit ba038546ff9e15d54d1134b5c5d2355648c00dec upstream. The voltage range (min, max) provided in the device tree is from the data manual and is pretty big, catering to a wide range of devices. On a i2c read/write failure the regulator_set_voltage_triplet function falls back to set voltage between min and max. The min value from Device Tree can be lesser than the optimal value and in that case that can lead to a hang or crash. Hence set the u_volt_min dynamically to the optimal voltage value. Cc: 4.16+ # v4.16+ Fixes: 9a835fa6e47 ("PM / OPP: Add ti-opp-supply driver") Signed-off-by: Keerthy Acked-by: Dave Gerlach Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 54923bc74bebbd93a44380bce87006efdce3a8fe Author: Rafał Miłecki Date: Thu Nov 8 16:08:29 2018 +0100 brcmfmac: fix reporting support for 160 MHz channels commit d1fe6ad6f6bd61c84788d3a7b11e459a439c6169 upstream. Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's important to provide valid & complete info about supported bands for each channel. By default no support for 160 MHz should be assumed unless firmware reports it for a given channel later. This fixes info passed to the userspace. Without that change userspace could try to use invalid channel and fail to start an interface. Signed-off-by: Rafał Miłecki Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit c74c926ffa0a1eb5b430255d35e2336b2f67c921 Author: Luca Coelho Date: Wed Oct 17 08:35:15 2018 +0300 iwlwifi: mvm: don't use SAR Geo if basic SAR is not used commit 5d041c46ccb9b48acc110e214beff5e2789311df upstream. We can't use SAR Geo if basic SAR is not enabled, since the SAR Geo tables define offsets in relation to the basic SAR table in use. To fix this, make iwl_mvm_sar_init() return one in case WRDS is not available, so we can skip reading WGDS entirely. Fixes: a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 4969751575c819d7be50b28f63b7ce1ab933b24e Author: Emmanuel Grumbach Date: Wed Oct 3 11:16:54 2018 +0300 iwlwifi: mvm: fix regulatory domain update when the firmware starts commit 82715ac71e6b94a2c2136e31f3a8e6748e33aa8c upstream. When the firmware starts, it doesn't have any regulatory information, hence it uses the world wide limitations. The driver can feed the firmware with previous knowledge that was kept in the driver, but the firmware may still not update its internal tables. This happens when we start a BSS interface, and then the firmware can change the regulatory tables based on our location and it'll use more lenient, location specific rules. Then, if the firmware is shut down (when the interface is brought down), and then an AP interface is created, the firmware will forget the country specific rules. The host will think that we are in a certain country that may allow channels and will try to teach the firmware about our location, but the firmware may still not allow to drop the world wide limitations and apply country specific rules because it was just re-started. In this case, the firmware will reply with MCC_RESP_ILLEGAL to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let the upper layers (cfg80211 / hostapd) know that the channel list they know about has been updated. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201105 Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit b643d705441c734feeb9e040c3a0ddcc896b58aa Author: Emmanuel Grumbach Date: Thu Aug 16 13:25:48 2018 +0300 iwlwifi: mvm: support sta_statistics() even on older firmware commit ec484d03ef0df8d34086b95710e355a259cbe1f2 upstream. The oldest firmware supported by iwlmvm do support getting the average beacon RSSI. Enable the sta_statistics() call from mac80211 even on older firmware versions. Fixes: 33cef9256342 ("iwlwifi: mvm: support beacon statistics for BSS client") Cc: stable@vger.kernel.org # 4.2+ Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 29d920ba59c30caf9cd8e829f47124de3d200618 Author: Matt Chen Date: Fri Aug 3 14:29:20 2018 +0800 iwlwifi: fix wrong WGDS_WIFI_DATA_SIZE commit 66e839030fd698586734e017fd55c4f2a89dba0b upstream. From coreboot/BIOS: Name ("WGDS", Package() { Revision, Package() { DomainType, // 0x7:WiFi ==> We miss this one. WgdsWiFiSarDeltaGroup1PowerMax1, // Group 1 FCC 2400 Max WgdsWiFiSarDeltaGroup1PowerChainA1, // Group 1 FCC 2400 A Offset WgdsWiFiSarDeltaGroup1PowerChainB1, // Group 1 FCC 2400 B Offset WgdsWiFiSarDeltaGroup1PowerMax2, // Group 1 FCC 5200 Max WgdsWiFiSarDeltaGroup1PowerChainA2, // Group 1 FCC 5200 A Offset WgdsWiFiSarDeltaGroup1PowerChainB2, // Group 1 FCC 5200 B Offset WgdsWiFiSarDeltaGroup2PowerMax1, // Group 2 EC Jap 2400 Max WgdsWiFiSarDeltaGroup2PowerChainA1, // Group 2 EC Jap 2400 A Offset WgdsWiFiSarDeltaGroup2PowerChainB1, // Group 2 EC Jap 2400 B Offset WgdsWiFiSarDeltaGroup2PowerMax2, // Group 2 EC Jap 5200 Max WgdsWiFiSarDeltaGroup2PowerChainA2, // Group 2 EC Jap 5200 A Offset WgdsWiFiSarDeltaGroup2PowerChainB2, // Group 2 EC Jap 5200 B Offset WgdsWiFiSarDeltaGroup3PowerMax1, // Group 3 ROW 2400 Max WgdsWiFiSarDeltaGroup3PowerChainA1, // Group 3 ROW 2400 A Offset WgdsWiFiSarDeltaGroup3PowerChainB1, // Group 3 ROW 2400 B Offset WgdsWiFiSarDeltaGroup3PowerMax2, // Group 3 ROW 5200 Max WgdsWiFiSarDeltaGroup3PowerChainA2, // Group 3 ROW 5200 A Offset WgdsWiFiSarDeltaGroup3PowerChainB2, // Group 3 ROW 5200 B Offset } }) When read the ACPI data to find out the WGDS, the DATA_SIZE is never matched. From the above format, it gives 19 numbers, but our driver is hardcode as 18. Fix it to pass then can parse the data into our wgds table. Then we will see: iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init Sending GEO_TX_POWER_LIMIT iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0] Band[0]: chain A = 68 chain B = 69 max_tx_power = 54 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0] Band[1]: chain A = 48 chain B = 49 max_tx_power = 70 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1] Band[0]: chain A = 51 chain B = 67 max_tx_power = 50 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1] Band[1]: chain A = 69 chain B = 70 max_tx_power = 68 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2] Band[0]: chain A = 49 chain B = 50 max_tx_power = 48 iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2] Band[1]: chain A = 52 chain B = 53 max_tx_power = 51 Cc: stable@vger.kernel.org # 4.12+ Fixes: a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table") Signed-off-by: Matt Chen Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 602162dce8a4cb61686226588161ded7b7ea604c Author: Vladimir Zapolskiy Date: Fri Nov 2 15:39:43 2018 +0200 gpio: don't free unallocated ida on gpiochip_add_data_with_key() error path commit a05a14049999598a3bb6fab12db6b768a0215522 upstream. The change corrects the error path in gpiochip_add_data_with_key() by avoiding to call ida_simple_remove(), if ida_simple_get() returns an error. Note that ida_simple_remove()/ida_free() throws a BUG(), if id argument is negative, it allows to easily check the correctness of the fix by fuzzing the return value from ida_simple_get(). Fixes: ff2b13592299 ("gpio: make the gpiochip a real device") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Vladimir Zapolskiy Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 6d24302acc10279d6e4a02590b4ea06475b1f744 Author: Adrian Hunter Date: Mon Nov 19 14:53:07 2018 +0200 mmc: sdhci-pci: Workaround GLK firmware failing to restore the tuning value commit 5305ec6a27b2dc7398a689e661a4a2e951026f09 upstream. GLK firmware can indicate that the tuning value will be restored after runtime suspend, but not actually do that. Add a workaround that detects such cases, and lets the driver do re-tuning instead. Reported-by: Anisse Astier Tested-by: Anisse Astier Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 52f4036282f79c93447c9eed734610a31ed933da Author: Rajat Jain Date: Mon Oct 29 15:17:01 2018 -0700 mmc: sdhci-pci: Try "cd" for card-detect lookup before using NULL commit cdcefe6bd9df754f528ffc339d3cc143cea4ddf6 upstream. Problem: The card detect IRQ does not work with modern BIOS (that want to use _DSD to provide the card detect GPIO to the driver). Details: The mmc core provides the mmc_gpiod_request_cd() API to let host drivers request the gpio descriptor for the "card detect" pin. This pin is specified in the ACPI for the SDHC device: * Either as a resource using _CRS. This is a method used by legacy BIOS. (The driver needs to tell which resource index). * Or as a named property ("cd-gpios"/"cd-gpio") in _DSD (which internally points to an entry in _CRS). This way, the driver can lookup using a string. This is what modern BIOS prefer to use. This API finally results in a call to the following code: struct gpio_desc *acpi_find_gpio(..., const char *con_id,...) { ... /* Lookup gpio (using "-gpio") in the _DSD */ ... if (!acpi_can_fallback_to_crs(adev, con_id)) return ERR_PTR(-ENOENT); ... /* Falling back to _CRS is allowed, Lookup gpio in the _CRS */ ... } Note that this means that if the ACPI has _DSD properties, the kernel will never use _CRS for the lookup (Because acpi_can_fallback_to_crs() will always be false for any device hat has _DSD entries). The SDHCI driver is thus currently broken on a modern BIOS, even if BIOS provides both _CRS (for index based lookup) and _DSD entries (for string based lookup). Ironically, none of these will be used for the lookup currently because: * Since the con_id is NULL, acpi_find_gpio() does not find a matching entry in DSDT. (The _DSDT entry has the property name = "cd-gpios") * Because ACPI contains DSDT entries, thus acpi_can_fallback_to_crs() returns false (because device properties have been populated from _DSD), thus the _CRS is never used for the lookup. Fix: Try "cd" for lookup in the _DSD before falling back to using NULL so as to try looking up in the _CRS. I've tested this patch successfully with both Legacy BIOS (that provide only _CRS method) as well as modern BIOS (that provide both _CRS and _DSD). Also the use of "cd" appears to be fairly consistent across other users of this API (other MMC host controller drivers). Link: https://lkml.org/lkml/2018/9/25/1113 Signed-off-by: Rajat Jain Acked-by: Adrian Hunter Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit bcec3b858057dfe6dfd05d6ba803e81af8d5adff Author: Will Deacon Date: Mon Nov 19 11:07:18 2018 +0000 Documentation/security-bugs: Postpone fix publication in exceptional cases commit 544b03da39e2d7b4961d3163976ed4bfb1fac509 upstream. At the request of the reporter, the Linux kernel security team offers to postpone the publishing of a fix for up to 5 business days from the date of a report. While it is generally undesirable to keep a fix private after it has been developed, this short window is intended to allow distributions to package the fix into their kernel builds and permits early inclusion of the security team in the case of a co-ordinated disclosure with other parties. Unfortunately, discussions with major Linux distributions and cloud providers has revealed that 5 business days is not sufficient to achieve either of these two goals. As an example, cloud providers need to roll out KVM security fixes to a global fleet of hosts with sufficient early ramp-up and monitoring. An end-to-end timeline of less than two weeks dramatically cuts into the amount of early validation and increases the chance of guest-visible regressions. The consequence of this timeline mismatch is that security issues are commonly fixed without the involvement of the Linux kernel security team and are instead analysed and addressed by an ad-hoc group of developers across companies contributing to Linux. In some cases, mainline (and therefore the official stable kernels) can be left to languish for extended periods of time. This undermines the Linux kernel security process and puts upstream developers in a difficult position should they find themselves involved with an undisclosed security problem that they are unable to report due to restrictions from their employer. To accommodate the needs of these users of the Linux kernel and encourage them to engage with the Linux security team when security issues are first uncovered, extend the maximum period for which fixes may be delayed to 7 calendar days, or 14 calendar days in exceptional cases, where the logistics of QA and large scale rollouts specifically need to be accommodated. This brings parity with the linux-distros@ maximum embargo period of 14 calendar days. Cc: Paolo Bonzini Cc: David Woodhouse Cc: Amit Shah Cc: Laura Abbott Acked-by: Kees Cook Co-developed-by: Thomas Gleixner Co-developed-by: David Woodhouse Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse Signed-off-by: Will Deacon Reviewed-by: Tyler Hicks Acked-by: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 160a390a9d5354caf7bddab4a70c307b8c4f9b17 Author: Will Deacon Date: Mon Oct 22 16:39:01 2018 +0100 Documentation/security-bugs: Clarify treatment of embargoed information commit 14fdc2c5318ae420e68496975f48dc1dbef52649 upstream. The Linux kernel security team has been accused of rejecting the idea of security embargoes. This is incorrect, and could dissuade people from reporting security issues to us under the false assumption that the issue would leak prematurely. Clarify the handling of embargoed information in our process documentation. Co-developed-by: Ingo Molnar Acked-by: Kees Cook Acked-by: Peter Zijlstra Acked-by: Laura Abbott Signed-off-by: Will Deacon Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit fc0f90849a45eb1844116debc5380d9429a3d09b Author: Greg Kroah-Hartman Date: Thu Nov 15 15:03:24 2018 -0800 MAINTAINERS: Add Sasha as a stable branch maintainer commit cb5d21946d2a2f4687c482ab4604af1d29dac35a upstream. Sasha has somehow been convinced into helping me with the stable kernel maintenance. Codify this slip in good judgement before he realizes what he really signed up for :) Signed-off-by: Greg Kroah-Hartman Acked-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27d6abfb99c871b7c0179b52b6a23acc6c7c005b Author: Takashi Iwai Date: Fri Nov 9 11:59:45 2018 +0100 ALSA: oss: Use kvzalloc() for local buffer allocations commit 65766ee0bf7fe8b3be80e2e1c3ef54ad59b29476 upstream. PCM OSS layer may allocate a few temporary buffers, one for the core read/write and another for the conversions via plugins. Currently both are allocated via vmalloc(). But as the allocation size is equivalent with the PCM period size, the required size might be quite small, depending on the application. This patch replaces these vmalloc() calls with kvzalloc() for covering small period sizes better. Also, we use "z"-alloc variant here for addressing the possible uninitialized access reported by syzkaller. Reported-by: syzbot+1cb36954e127c98dd037@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cc8b329fef53c74a4abf98b0755b3832d572d6ce Author: Mathias Nyman Date: Thu Nov 15 11:38:41 2018 +0200 usb: xhci: Prevent bus suspend if a port connect change or polling state is detected commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream. USB3 roothub might autosuspend before a plugged USB3 device is detected, causing USB3 device enumeration failure. USB3 devices don't show up as connected and enabled until USB3 link trainig completes. On a fast booting platform with a slow USB3 link training the link might reach the connected enabled state just as the bus is suspending. If this device is discovered first time by the xhci_bus_suspend() routine it will be put to U3 suspended state like the other ports which failed to suspend earlier. The hub thread will notice the connect change and resume the bus, moving the port back to U0 This U0 -> U3 -> U0 transition right after being connected seems to be too much for some devices, causing them to first go to SS.Inactive state, and finally end up stuck in a polling state with reset asserted Fix this by failing the bus suspend if a port has a connect change or is in a polling state in xhci_bus_suspend(). Don't do any port changes until all ports are checked, buffer all port changes and only write them in the end if suspend can proceed Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit b6cc7f9c6461a3d23bc1e8ad47eacb0a2188168a Author: Cherian, George Date: Fri Nov 9 17:21:22 2018 +0200 xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 Soc commit 11644a7659529730eaf2f166efaabe7c3dc7af8c upstream. Implement workaround for ThunderX2 Errata-129 (documented in CN99XX Known Issues" available at Cavium support site). As per ThunderX2errata-129, USB 2 device may come up as USB 1 if a connection to a USB 1 device is followed by another connection to a USB 2 device, the link will come up as USB 1 for the USB 2 device. Resolution: Reset the PHY after the USB 1 device is disconnected. The PHY reset sequence is done using private registers in XHCI register space. After the PHY is reset we check for the PLL lock status and retry the operation if it fails. From our tests, retrying 4 times is sufficient. Add a new quirk flag XHCI_RESET_PLL_ON_DISCONNECT to invoke the workaround in handle_xhci_port_status(). Cc: stable@vger.kernel.org Signed-off-by: George Cherian Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit cad3876cd23d63e818c3112e885767a09b249905 Author: Aaron Ma Date: Fri Nov 9 17:21:21 2018 +0200 usb: xhci: fix timeout for transition from RExit to U0 commit a5baeaeabcca3244782a9b6382ebab6f8a58f583 upstream. This definition is used by msecs_to_jiffies in milliseconds. According to the comments, max rexit timeout should be 20ms. Align with the comments to properly calculate the delay. Verified on Sunrise Point-LP and Cannon Lake. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 60ac01c60ba94d8a17016ede99789207a5b93856 Author: Aaron Ma Date: Fri Nov 9 17:21:20 2018 +0200 usb: xhci: fix uninitialized completion when USB3 port got wrong status commit 958c0bd86075d4ef1c936998deefe1947e539240 upstream. Realtek USB3.0 Card Reader [0bda:0328] reports wrong port status on Cannon lake PCH USB3.1 xHCI [8086:a36d] after resume from S3, after clear port reset it works fine. Since this device is registered on USB3 roothub at boot, when port status reports not superspeed, xhci_get_port_status will call an uninitialized completion in bus_state[0]. Kernel will hang because of NULL pointer. Restrict the USB2 resume status check in USB2 roothub to fix hang issue. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 3e8886bd158fc34efad491176b8899417736dc1f Author: Sandeep Singh Date: Fri Nov 9 17:21:19 2018 +0200 xhci: Add check for invalid byte size error when UAS devices are connected. commit d9193efba84fe4c4aa22a569fade5e6ca971f8af upstream. Observed "TRB completion code (27)" error which corresponds to Stopped - Length Invalid error(xhci spec section 4.17.4) while connecting USB to SATA bridge. Looks like this case was not considered when the following patch[1] was committed. Hence adding this new check which can prevent the invalid byte size error. [1] ade2e3a xhci: handle transfer events without TRB pointer Cc: Signed-off-by: Sandeep Singh cc: Nehal Shah cc: Shyam Sundar S K Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a237717dfdbc5e6f7cd9d5b2d66627ad793bb8cf Author: Mathias Nyman Date: Fri Nov 9 17:21:18 2018 +0200 xhci: handle port status events for removed USB3 hcd commit 1245374e9b8340fc255fd51b2015173a83050d03 upstream. At xhci removal the USB3 hcd (shared_hcd) is removed before the primary USB2 hcd. Interrupts for port status changes may still occur for USB3 ports after the shared_hcd is freed, causing NULL pointer dereference. Check if xhci->shared_hcd is still valid before handing USB3 port events Cc: Reported-by: Peter Chen Tested-by: Jack Pham Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 82c1b66894fd3b81af823861a39d532af4337f4e Author: Mathias Nyman Date: Fri Nov 9 17:21:17 2018 +0200 xhci: Fix leaking USB3 shared_hcd at xhci removal commit f068090426ea8d72c408ebd42953a82a88e2282c upstream. Ensure that the shared_hcd pointer is valid when calling usb_put_hcd() The shared_hcd is removed and freed in xhci by first calling usb_remove_hcd(xhci->shared_hcd), and later usb_put_hcd(xhci->shared_hcd) Afer commit fe190ed0d602 ("xhci: Do not halt the host until both HCD have disconnected their devices.") the shared_hcd was never properly put as xhci->shared_hcd was set to NULL before usb_put_hcd(xhci->shared_hcd) was called. shared_hcd (USB3) is removed before primary hcd (USB2). While removing the primary hcd we might need to handle xhci interrupts to cleanly remove last USB2 devices, therefore we need to set xhci->shared_hcd to NULL before removing the primary hcd to let xhci interrupt handler know shared_hcd is no longer available. xhci-plat.c, xhci-histb.c and xhci-mtk first create both their hcd's before adding them. so to keep the correct reverse removal order use a temporary shared_hcd variable for them. For more details see commit 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them") Fixes: fe190ed0d602 ("xhci: Do not halt the host until both HCD have disconnected their devices.") Cc: Joel Stanley Cc: Chunfeng Yun Cc: Thierry Reding Cc: Jianguo Sun Cc: Reported-by: Jack Pham Tested-by: Jack Pham Tested-by: Peter Chen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 2ff85eaf165f57c668eee613e9570d94d4b7f4cf Author: Kuppuswamy Sathyanarayanan Date: Wed Oct 17 11:40:26 2018 -0700 usb: dwc3: Fix NULL pointer exception in dwc3_pci_remove() commit 7b412b04a0c7000293008231ce8413056abb1982 upstream. In dwc3_pci_quirks() function, gpiod lookup table is only registered for baytrail SOC. But in dwc3_pci_remove(), we try to unregistered it without any checks. This leads to NULL pointer de-reference exception in gpiod_remove_lookup_table() when unloading the module for non baytrail SOCs. This patch fixes this issue. Fixes: 5741022cbdf3 ("usb: dwc3: pci: Add GPIO lookup table on platforms without ACPI GPIO resources") Cc: Signed-off-by: Kuppuswamy Sathyanarayanan Reviewed-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c4d1e71e56135dcd4f309bf1d3cd9bff36fce2c9 Author: Andy Shevchenko Date: Mon Aug 27 18:30:16 2018 +0300 usb: dwc3: core: Clean up ULPI device commit 08fd9a82fda86529bb2f2af3c2f7cb657b4d3066 upstream. If dwc3_core_init_mode() fails with deferred probe, next probe fails on sysfs with sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:11.0/dwc3.0.auto/dwc3.0.auto.ulpi' To avoid this failure, clean up ULPI device. Cc: Signed-off-by: Andy Shevchenko Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 4b977515da489f5c33762f1475a0fcfaec525704 Author: Thinh Nguyen Date: Thu Aug 2 20:17:16 2018 -0700 usb: dwc3: gadget: Properly check last unaligned/zero chain TRB commit ba3a51ac32ebcf8d0a54b37f1af268ad8a31c52f upstream. Current check for the last extra TRB for zero and unaligned transfers does not account for isoc OUT. The last TRB of the Buffer Descriptor for isoc OUT transfers will be retired with HWO=0. As a result, we won't return early. The req->remaining will be updated to include the BUFSIZ count of the extra TRB, and the actual number of transferred bytes calculation will be wrong. To fix this, check whether it's a short or zero packet and the last TRB chain bit to return early. Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 47cb27191f6cac951bf2bfd00cceff264cfc191f Author: Felipe Balbi Date: Wed Aug 1 09:37:34 2018 +0300 usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers commit 2fc6d4be35fb1e262f209758e25bfe2b7a113a7f upstream. When chaining ISOC TRBs together, only the first ISOC TRB should be of type ISOC_FIRST, all others should be of type ISOC. This patch fixes that. Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: # v4.11+ Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 269c01eb49ed0643a2ed2161fa1d46749cef30b1 Author: Dennis Wassenberg Date: Tue Nov 13 14:40:34 2018 +0100 usb: core: Fix hub port connection events lost commit 22454b79e6de05fa61a2a72d00d2eed798abbb75 upstream. This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset only if a device is was attached to the hub port before resetting the hub port. Using a Lenovo T480s attached to the ultra dock it was not possible to detect some usb-c devices at the dock usb-c ports because the hub_port_reset code will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset. Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit. This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the new device was attached such that it was not detected. This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is currently no device attached to the port before the hub port reset. This will avoid clearing the connection bit for new attached devices. Signed-off-by: Dennis Wassenberg Acked-by: Mathias Nyman Cc: stable Signed-off-by: Greg Kroah-Hartman commit 711bd5d290da6c3bbdb14f53f86f77e372e2e44d Author: Alistair Strachan Date: Thu Aug 9 09:40:42 2018 -0700 efi/libstub: arm: support building with clang commit 41f1c48420709470c51ee0e54b6fb28b956bb4e0 upstream. When building with CONFIG_EFI and CONFIG_EFI_STUB on ARM, the libstub Makefile would use -mno-single-pic-base without checking it was supported by the compiler. As the ARM (32-bit) clang backend does not support this flag, the build would fail. This changes the Makefile to check the compiler's support for -mno-single-pic-base before using it, similar to c1c386681bd7 ("ARM: 8767/1: add support for building ARM kernel with clang"). Signed-off-by: Alistair Strachan Reviewed-by: Stefan Agner Signed-off-by: Ard Biesheuvel Cc: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman commit fb87a92b43961c89bf4a115d8a700885d8959cb1 Author: Rodrigo Rivas Costa Date: Sun Oct 14 19:36:43 2018 +0200 HID: steam: remove input device when a hid client is running. commit 385a4886778f6d6e61eff1d4d295af332d7130e1 upstream. Previously, when a HID client such as the Steam Client was running, this driver disabled its input device to avoid doubling the input events. While it worked mostly fine, some games got confused by the idle gamepad, and switched to two player mode, or asked the user to choose which gamepad to use. Other games just crashed, probably a bug in Unity [1]. With this commit, when a HID client starts, the input device is removed; when the HID client ends the input device is recreated. [1]: https://github.com/ValveSoftware/steam-for-linux/issues/5645 Signed-off-by: Rodrigo Rivas Costa Signed-off-by: Jiri Kosina Cc: Pierre-Loup Griffais Signed-off-by: Greg Kroah-Hartman commit b32d16ec995683be888520d12d8f2833efee5dae Author: Greg Kroah-Hartman Date: Tue Nov 27 16:13:11 2018 +0100 Linux 4.19.5 commit 0d9813319b40399a0d8fd761d2fcfedee5701487 Author: Lorenzo Bianconi Date: Fri Sep 7 23:13:12 2018 +0200 mt76x0: run vco calibration for each channel configuration commit 473f0a763d2c7cd68a6dedf51e7d81e8f58f78ac upstream. According to vendor sdk, vco calibration has to be executed for each channel configuration whereas mcu calibration has to be performed during channel scanning. This patch fixes the mt76x0 monitor mode issue since in that configuration vco calibration was never executed Fixes: 10de7a8b4ab9 ("mt76x0: phy files") Tested-by: Sid Hayn Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Cc: Stanislaw Gruszka Signed-off-by: Greg Kroah-Hartman commit 02e28d5b8537a4438207937e450c302c04db06f5 Author: Ilya Dryomov Date: Thu Nov 8 15:55:37 2018 +0100 libceph: fall back to sendmsg for slab pages commit 7e241f647dc7087a0401418a187f3f5b527cc690 upstream. skb_can_coalesce() allows coalescing neighboring slab objects into a single frag: return page == skb_frag_page(frag) && off == frag->page_offset + skb_frag_size(frag); ceph_tcp_sendpage() can be handed slab pages. One example of this is XFS: it passes down sector sized slab objects for its metadata I/O. If the kernel client is co-located on the OSD node, the skb may go through loopback and pop on the receive side with the exact same set of frags. When tcp_recvmsg() attempts to copy out such a frag, hardened usercopy complains because the size exceeds the object's allocated size: usercopy: kernel memory exposure attempt detected from ffff9ba917f20a00 (kmalloc-512) (1024 bytes) Although skb_can_coalesce() could be taught to return false if the resulting frag would cross a slab object boundary, we already have a fallback for non-refcounted pages. Utilize it for slab pages too. Cc: stable@vger.kernel.org # 4.8+ Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 8ef7c76cb91afdb58b6b2a5933590e1dfbd0dc83 Author: Sebastian Parschauer Date: Wed Nov 7 13:36:40 2018 +0100 HID: Add quirk for Microsoft PIXART OEM mouse commit e82e62e390d39c3819641cd721695702180d54fb upstream. The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. So add quirk ALWAYS_POLL for this one as well. References: https://www.spinics.net/lists/linux-usb/msg88965.html http://linet.gr.jp/~kojima/PlamoWeb/ML/htdocs/201808/msg00019.html Signed-off-by: Sebastian Parschauer CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 0c874f9e7661b344e6ba527fcdfad59c982cb90f Author: Sebastian Parschauer Date: Tue Nov 20 07:25:08 2018 +0100 HID: Add quirk for Primax PIXART OEM mice commit fb862c3b199d28bee238d52e8270eae8650d6cb0 upstream. The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. So add quirk ALWAYS_POLL for two Primax mice as well. 0x4e22 is the Dell MS111-P and 0x4d0f is the unbranded HP Portia mouse HP 697738-001. Both were built until approx. 2014. Those were the standard mice from those vendors and are still around - even as new old stock. Reference: https://github.com/sriemer/fix-linux-mouse/issues/11 Signed-off-by: Sebastian Parschauer CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit cf7de65800299b9699c401ea45b9536b8bacddf5 Author: Eric Biggers Date: Wed Nov 14 13:55:09 2018 -0800 HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges commit 8c01db7619f07c85c5cd81ec5eb83608b56c88f5 upstream. When a UHID_CREATE command is written to the uhid char device, a copy_from_user() is done from a user pointer embedded in the command. When the address limit is KERNEL_DS, e.g. as is the case during sys_sendfile(), this can read from kernel memory. Alternatively, information can be leaked from a setuid binary that is tricked to write to the file descriptor. Therefore, forbid UHID_CREATE in these cases. No other commands in uhid_char_write() are affected by this bug and UHID_CREATE is marked as "obsolete", so apply the restriction to UHID_CREATE only rather than to uhid_char_write() entirely. Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to Jann Horn for commit 9da3f2b740544 ("x86/fault: BUG() when uaccess helpers fault on kernel addresses"), allowing this bug to be found. Reported-by: syzbot+72473edc9bf4eb1c6556@syzkaller.appspotmail.com Fixes: d365c6cfd337 ("HID: uhid: add UHID_CREATE and UHID_DESTROY events") Cc: # v3.6+ Cc: Jann Horn Cc: Andy Lutomirski Signed-off-by: Eric Biggers Reviewed-by: Jann Horn Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit a73a8c3b15f145f0fb8b52246994a88437f15381 Author: Hans de Goede Date: Mon Nov 19 19:06:01 2018 +0100 ACPI / platform: Add SMB0001 HID to forbidden_id_list commit 2bbb5fa37475d7aa5fa62f34db1623f3da2dfdfa upstream. Many HP AMD based laptops contain an SMB0001 device like this: Device (SMBD) { Name (_HID, "SMB0001") // _HID: Hardware ID Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { IO (Decode16, 0x0B20, // Range Minimum 0x0B20, // Range Maximum 0x20, // Alignment 0x20, // Length ) IRQ (Level, ActiveLow, Shared, ) {7} }) } The legacy style IRQ resource here causes acpi_dev_get_irqresource() to be called with legacy=true and this message to show in dmesg: ACPI: IRQ 7 override to edge, high This causes issues when later on the AMD0030 GPIO device gets enumerated: Device (GPIO) { Name (_HID, "AMDI0030") // _HID: Hardware ID Name (_CID, "AMDI0030") // _CID: Compatible ID Name (_UID, Zero) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000007, } Memory32Fixed (ReadWrite, 0xFED81500, // Address Base 0x00000400, // Address Length ) }) Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */ } } Now acpi_dev_get_irqresource() gets called with legacy=false, but because of the earlier override of the trigger-type acpi_register_gsi() returns -EBUSY (because we try to register the same interrupt with a different trigger-type) and we end up setting IORESOURCE_DISABLED in the flags. The setting of IORESOURCE_DISABLED causes platform_get_irq() to call acpi_irq_get() which is not implemented on x86 and returns -EINVAL. resulting in the following in dmesg: amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22 amd_gpio: probe of AMDI0030:00 failed with error -22 The SMB0001 is a "virtual" device in the sense that the only way the OS interacts with it is through calling a couple of methods to do SMBus transfers. As such it is weird that it has IO and IRQ resources at all, because the driver for it is not expected to ever access the hardware directly. The Linux driver for the SMB0001 device directly binds to the acpi_device through the acpi_bus, so we do not need to instantiate a platform_device for this ACPI device. This commit adds the SMB0001 HID to the forbidden_id_list, avoiding the instantiating of a platform_device for it. Not instantiating a platform_device means we will no longer call acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of the AMDI0030 device failing. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523 Reported-by: Lukas Kahnert Tested-by: Marc Cc: All applicable Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3e31936ba001b3d7450898ece1bfeb7c1a6bbc5d Author: Gustavo A. R. Silva Date: Tue Oct 16 12:59:44 2018 +0200 drivers/misc/sgi-gru: fix Spectre v1 vulnerability commit fee05f455ceb5c670cbe48e2f9454ebc4a388554 upstream. req.gid can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn: potential spectre issue 'gru_base' [w] Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which uses it to index gru_base. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Greg Kroah-Hartman commit 78ac3038245938d164b9843dcaa4794b0659ed31 Author: Johan Hovold Date: Mon Aug 27 10:21:49 2018 +0200 mtd: rawnand: atmel: fix OF child-node lookup commit 5d1e9c2212ea6b4dd735e4fc3dd6279a365d5d10 upstream. Use the new of_get_compatible_child() helper to lookup the nfc child node instead of using of_find_compatible_node(), which searches the entire tree from a given start node and thus can return an unrelated (i.e. non-child) node. This also addresses a potential use-after-free (e.g. after probe deferral) as the tree-wide helper drops a reference to its first argument (i.e. the node of the device being probed). While at it, also fix a related nfc-node reference leak. Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Cc: stable # 4.11 Cc: Nicolas Ferre Cc: Josh Wu Cc: Boris Brezillon Signed-off-by: Johan Hovold Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 466720dc7769643948dc6c26e8162c82b88775fc Author: Johan Hovold Date: Wed Nov 14 09:37:54 2018 +0100 gnss: sirf: fix synchronous write timeout commit 1decef370456870bf448a565be95db636428e106 upstream. Passing a timeout of zero to the synchronous serdev_device_write() helper does currently not imply to wait forever (unlike passing zero to serdev_device_wait_until_sent()). Instead, if there's insufficient room in the write buffer, we'd end up with an incomplete write. Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers") Cc: stable # 4.19 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9cdfd2233a6b6e98f5221764b634227bdf6c1764 Author: Johan Hovold Date: Wed Nov 14 09:33:57 2018 +0100 gnss: serial: fix synchronous write timeout commit 56a6c7268312cba9436b84cac01b3e502c5c511d upstream. Passing a timeout of zero to the synchronous serdev_device_write() helper does currently not imply to wait forever (unlike passing zero to serdev_device_wait_until_sent()). Instead, if there's insufficient room in the write buffer, we'd end up with an incomplete write. Fixes: 37768b054f20 ("gnss: add generic serial driver") Cc: stable # 4.19 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3b0fa609e00140ee1ca7300eb6fd023ba5b00193 Author: Mattias Jacobsson <2pi@mok.nu> Date: Sun Oct 21 11:25:37 2018 +0200 USB: misc: appledisplay: add 20" Apple Cinema Display commit f6501f49199097b99e4e263644d88c90d1ec1060 upstream. Add another Apple Cinema Display to the list of supported displays Signed-off-by: Mattias Jacobsson <2pi@mok.nu> Cc: stable Signed-off-by: Greg Kroah-Hartman commit e591b9069b0c93be8e39ef054f07f41c1458e928 Author: Nathan Chancellor Date: Wed Oct 17 10:09:02 2018 -0700 misc: atmel-ssc: Fix section annotation on atmel_ssc_get_driver_data commit 7c97301285b62a41d6bceded7d964085fc8cc50f upstream. After building the kernel with Clang, the following section mismatch warning appears: WARNING: vmlinux.o(.text+0x3bf19a6): Section mismatch in reference from the function ssc_probe() to the function .init.text:atmel_ssc_get_driver_data() The function ssc_probe() references the function __init atmel_ssc_get_driver_data(). This is often because ssc_probe lacks a __init annotation or the annotation of atmel_ssc_get_driver_data is wrong. Remove __init from atmel_ssc_get_driver_data to get rid of the mismatch. Signed-off-by: Nathan Chancellor Cc: stable Signed-off-by: Greg Kroah-Hartman commit 74f5f46a088d5baa03dabe66965998a818fab099 Author: Emmanuel Pescosta Date: Fri Oct 26 14:48:09 2018 +0200 usb: quirks: Add delay-init quirk for Corsair K70 LUX RGB commit a77112577667cbda7c6292c52d909636aef31fd9 upstream. Following on from this patch: https://lkml.org/lkml/2017/11/3/516, Corsair K70 LUX RGB keyboards also require the DELAY_INIT quirk to start correctly at boot. Dmesg output: usb 1-6: string descriptor 0 read error: -110 usb 1-6: New USB device found, idVendor=1b1c, idProduct=1b33 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-6: can't set config #1, error -110 Signed-off-by: Emmanuel Pescosta Cc: stable Signed-off-by: Greg Kroah-Hartman commit ed8acd13e770a1c3ab660d1c0cd83807c3979631 Author: Kai-Heng Feng Date: Fri Oct 19 16:14:50 2018 +0800 USB: Wait for extra delay time after USB_PORT_FEAT_RESET for quirky hub commit 781f0766cc41a9dd2e5d118ef4b1d5d89430257b upstream. Devices connected under Terminus Technology Inc. Hub (1a40:0101) may fail to work after the system resumes from suspend: [ 206.063325] usb 3-2.4: reset full-speed USB device number 4 using xhci_hcd [ 206.143691] usb 3-2.4: device descriptor read/64, error -32 [ 206.351671] usb 3-2.4: device descriptor read/64, error -32 Info for this hub: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1a40 ProdID=0101 Rev=01.11 S: Product=USB 2.0 Hub C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub Some expirements indicate that the USB devices connected to the hub are innocent, it's the hub itself is to blame. The hub needs extra delay time after it resets its port. Hence wait for extra delay, if the device is connected to this quirky hub. Signed-off-by: Kai-Heng Feng Cc: stable Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 20aa051f0004d809c5b8f821161880046c136bdd Author: Kai-Heng Feng Date: Fri Oct 26 13:33:15 2018 +0800 USB: quirks: Add no-lpm quirk for Raydium touchscreens commit deefd24228a172d1b27d4a9adbfd2cdacd60ae64 upstream. Raydium USB touchscreen fails to set config if LPM is enabled: [ 2.030658] usb 1-8: New USB device found, idVendor=2386, idProduct=3119 [ 2.030659] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.030660] usb 1-8: Product: Raydium Touch System [ 2.030661] usb 1-8: Manufacturer: Raydium Corporation [ 7.132209] usb 1-8: can't set config #1, error -110 Same behavior can be observed on 2386:3114. Raydium claims the touchscreen supports LPM under Windows, so I used Microsoft USB Test Tools (MUTT) [1] to check its LPM status. MUTT shows that the LPM doesn't work under Windows, either. So let's just disable LPM for Raydium touchscreens. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-test-tools Signed-off-by: Kai-Heng Feng Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 16a57ceaeddd9dae141c43a16ed15c1a6300e35b Author: Maarten Jacobs Date: Mon Nov 19 23:18:49 2018 +0000 usb: cdc-acm: add entry for Hiro (Conexant) modem commit 63529eaa6164ef7ab4b907b25ac3648177e5e78f upstream. The cdc-acm kernel module currently does not support the Hiro (Conexant) H05228 USB modem. The patch below adds the device specific information: idVendor 0x0572 idProduct 0x1349 Signed-off-by: Maarten Jacobs Acked-by: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman commit 2909e53a72ce7262a627658fdac65916e952ea73 Author: Jimmy Assarsson Date: Mon Aug 6 15:14:50 2018 +0200 can: kvaser_usb: Fix potential uninitialized variable use commit 95217260649aa504eb5d4a0d50959ca4e67c8f96 upstream. If alloc_can_err_skb() fails, cf is never initialized. Move assignment of cf inside check. Reported-by: Dan Carpenter Signed-off-by: Jimmy Assarsson Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 667bd202c5aa10d62afabd5b748bd6709227e88b Author: Jimmy Assarsson Date: Mon Aug 6 15:14:49 2018 +0200 can: kvaser_usb: Fix accessing freed memory in kvaser_usb_start_xmit() commit e13fb9b37cc00616b90df2d620f30345b5ada6ff upstream. The call to can_put_echo_skb() may result in the skb being freed. The skb is later used in the call to dev->ops->dev_frame_to_cmd(). This is avoided by moving the call to can_put_echo_skb() after dev->ops->dev_frame_to_cmd(). Reported-by: Dan Carpenter Signed-off-by: Jimmy Assarsson Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit a0d5745e5a1c03650bb9f8012afda790e7910c07 Author: Takashi Iwai Date: Mon Nov 12 12:26:57 2018 +0100 ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap() commit d99501b8575dc1248bacf1b58d2241cb4b265d49 upstream. We need to call pci_iounmap() instead of iounmap() for the regions obtained via pci_iomap() call for some archs that need special treatment. Fixes: aa31704fd81c ("ALSA: hda/ca0132: Add PCI region2 iomap for SBZ") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e4d1784e1445409b264d6d2b756289144bfd4143 Author: Takashi Iwai Date: Mon Nov 12 09:43:12 2018 +0100 ALSA: hda/realtek - Add quirk entry for HP Pavilion 15 commit 563785edfcef02b566e64fb5292c74c1600808aa upstream. HP Pavilion 15 (103c:820d) with ALC295 codec requires the quirk for the mute LED control over mic3 pin. Added the corresponding quirk entry. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201653 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8600660ce149b32961d0f298eb6cd1c22a161fb1 Author: Dan Carpenter Date: Fri Oct 26 10:19:51 2018 +0300 uio: Fix an Oops on load commit 432798195bbce1f8cd33d1c0284d0538835e25fb upstream. I was trying to solve a double free but I introduced a more serious NULL dereference bug. The problem is that if there is an IRQ which triggers immediately, then we need "info->uio_dev" but it's not set yet. This patch puts the original initialization back to how it was and just sets info->uio_dev to NULL on the error path so it should solve both the Oops and the double free. Fixes: f019f07ecf6a ("uio: potential double frees if __uio_register_device() fails") Reported-by: Mathias Thore Signed-off-by: Dan Carpenter Cc: stable Tested-by: Mathias Thore Signed-off-by: Greg Kroah-Hartman commit a0d5f816c574fe5faaba7c19f4a3b5b11aca8c63 Author: Olof Johansson Date: Wed Nov 14 16:27:55 2018 -0800 RISC-V: Fix raw_copy_{to,from}_user() commit 21f70d4abf9e17c2e3d7e64b7bfa3424e017f176 upstream. Sparse highlighted it, and appears to be a pure bug (from vs to). ./arch/riscv/include/asm/uaccess.h:403:35: warning: incorrect type in argument 1 (different address spaces) ./arch/riscv/include/asm/uaccess.h:403:39: warning: incorrect type in argument 2 (different address spaces) ./arch/riscv/include/asm/uaccess.h:409:37: warning: incorrect type in argument 1 (different address spaces) ./arch/riscv/include/asm/uaccess.h:409:41: warning: incorrect type in argument 2 (different address spaces) Signed-off-by: Olof Johansson Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 0483179a330f1ceeae6ba781f3590fd61b3502e8 Author: Aaro Koskinen Date: Sun Nov 11 00:06:12 2018 +0200 MIPS: OCTEON: cavium_octeon_defconfig: re-enable OCTEON USB driver commit 82fba2df7f7c019627f24c5036dc99f41731d770 upstream. Re-enable OCTEON USB driver which is needed on older hardware (e.g. EdgeRouter Lite) for mass storage etc. This got accidentally deleted when config options were changed for OCTEON2/3 USB. Signed-off-by: Aaro Koskinen Signed-off-by: Paul Burton Fixes: f922bc0ad08b ("MIPS: Octeon: cavium_octeon_defconfig: Enable more drivers") Patchwork: https://patchwork.linux-mips.org/patch/21077/ Cc: Ralf Baechle Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 4.14+ Signed-off-by: Greg Kroah-Hartman commit eaa7def0549ee89f92e4e1b2627f1f4c7fa78bb4 Author: Sakari Ailus Date: Mon Nov 5 09:35:44 2018 -0500 media: v4l: event: Add subscription to list before calling "add" operation commit 92539d3eda2c090b382699bbb896d4b54e9bdece upstream. Patch ad608fbcf166 changed how events were subscribed to address an issue elsewhere. As a side effect of that change, the "add" callback was called before the event subscription was added to the list of subscribed events, causing the first event queued by the add callback (and possibly other events arriving soon afterwards) to be lost. Fix this by adding the subscription to the list before calling the "add" callback, and clean up afterwards if that fails. Fixes: ad608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions while accessed") Reported-by: Dave Stevenson Signed-off-by: Sakari Ailus Tested-by: Dave Stevenson Reviewed-by: Hans Verkuil Tested-by: Hans Verkuil Cc: stable@vger.kernel.org (for 4.14 and up) Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 88723e6ec53b135e6e4fde1e1336386fa358adc5 Author: Kirill A. Shutemov Date: Fri Oct 26 15:28:56 2018 +0300 x86/ldt: Remove unused variable in map_ldt_struct() commit b082f2dd80612015cd6d9d84e52099734ec9a0e1 upstream Splitting out the sanity check in map_ldt_struct() moved page table syncing into a separate function, which made the pgd variable unused. Remove it. [ tglx: Massaged changelog ] Fixes: 9bae3197e15d ("x86/ldt: Split out sanity check in map_ldt_struct()") Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Reviewed-by: Andy Lutomirski Cc: bp@alien8.de Cc: hpa@zytor.com Cc: dave.hansen@linux.intel.com Cc: peterz@infradead.org Cc: boris.ostrovsky@oracle.com Cc: jgross@suse.com Cc: bhe@redhat.com Cc: willy@infradead.org Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181026122856.66224-4-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit b0f16f98d306c0ee0df7b506fd15a1dc3f8888dc Author: Kirill A. Shutemov Date: Fri Oct 26 15:28:55 2018 +0300 x86/ldt: Unmap PTEs for the slot before freeing LDT pages commit a0e6e0831c516860fc7f9be1db6c081fe902ebcf upstream modify_ldt(2) leaves the old LDT mapped after switching over to the new one. The old LDT gets freed and the pages can be re-used. Leaving the mapping in place can have security implications. The mapping is present in the userspace page tables and Meltdown-like attacks can read these freed and possibly reused pages. It's relatively simple to fix: unmap the old LDT and flush TLB before freeing the old LDT memory. This further allows to avoid flushing the TLB in map_ldt_struct() as the slot is unmapped and flushed by unmap_ldt_struct() or has never been mapped at all. [ tglx: Massaged changelog and removed the needless line breaks ] Fixes: f55f0501cbf6 ("x86/pti: Put the LDT in its own PGD if PTI is on") Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Cc: bp@alien8.de Cc: hpa@zytor.com Cc: dave.hansen@linux.intel.com Cc: luto@kernel.org Cc: peterz@infradead.org Cc: boris.ostrovsky@oracle.com Cc: jgross@suse.com Cc: bhe@redhat.com Cc: willy@infradead.org Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181026122856.66224-3-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit 4074ca7d8a1832921c865d250bbd08f3441b3657 Author: Kirill A. Shutemov Date: Fri Oct 26 15:28:54 2018 +0300 x86/mm: Move LDT remap out of KASLR region on 5-level paging commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream On 5-level paging the LDT remap area is placed in the middle of the KASLR randomization region and it can overlap with the direct mapping, the vmalloc or the vmap area. The LDT mapping is per mm, so it cannot be moved into the P4D page table next to the CPU_ENTRY_AREA without complicating PGD table allocation for 5-level paging. The 4 PGD slot gap just before the direct mapping is reserved for hypervisors, so it cannot be used. Move the direct mapping one slot deeper and use the resulting gap for the LDT remap area. The resulting layout is the same for 4 and 5 level paging. [ tglx: Massaged changelog ] Fixes: f55f0501cbf6 ("x86/pti: Put the LDT in its own PGD if PTI is on") Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Reviewed-by: Andy Lutomirski Cc: bp@alien8.de Cc: hpa@zytor.com Cc: dave.hansen@linux.intel.com Cc: peterz@infradead.org Cc: boris.ostrovsky@oracle.com Cc: jgross@suse.com Cc: bhe@redhat.com Cc: willy@infradead.org Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181026122856.66224-2-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit 7818cf3d9aeab4374fa55f54a9da987381f807ff Author: YueHaibing Date: Thu Nov 8 02:04:57 2018 +0000 SUNRPC: drop pointless static qualifier in xdr_get_next_encode_buffer() [ Upstream commit 025911a5f4e36955498ed50806ad1b02f0f76288 ] There is no need to have the '__be32 *p' variable static since new value always be assigned before use it. Signed-off-by: YueHaibing Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 62b5dea3ac936be3c6b268dcce6fcdb3d906f164 Author: Guenter Roeck Date: Tue Nov 6 10:10:38 2018 -0800 Revert "scripts/setlocalversion: git: Make -dirty check more robust" [ Upstream commit 8ef14c2c41d962756d314f1d7dc972b0ea7a180f ] This reverts commit 6147b1cf19651c7de297e69108b141fb30aa2349. The reverted patch results in attempted write access to the source repository, even if that repository is mounted read-only. Output from "strace git status -uno --porcelain": getcwd("/tmp/linux-test", 129) = 16 open("/tmp/linux-test/.git/index.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = -1 EROFS (Read-only file system) While git appears to be able to handle this situation, a monitored build environment (such as the one used for Chrome OS kernel builds) may detect it and bail out with an access violation error. On top of that, the attempted write access suggests that git _will_ write to the file even if a build output directory is specified. Users may have the reasonable expectation that the source repository remains untouched in that situation. Fixes: 6147b1cf19651 ("scripts/setlocalversion: git: Make -dirty check more robust" Cc: Genki Sky Signed-off-by: Guenter Roeck Reviewed-by: Brian Norris Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 4d17f22eb16ed539f6162ea566e89acf6f44354a Author: Masahiro Yamada Date: Tue Nov 6 13:18:05 2018 +0900 kbuild: deb-pkg: fix too low build version number [ Upstream commit bbcde0a7241261cd0ca8d8e6b94a4113a4b71443 ] Since commit b41d920acff8 ("kbuild: deb-pkg: split generating packaging and build"), the build version of the kernel contained in a deb package is too low by 1. Prior to the bad commit, the kernel was built first, then the number in .version file was read out, and written into the debian control file. Now, the debian control file is created before the kernel is actually compiled, which is causing the version number mismatch. Let the mkdebian script pass KBUILD_BUILD_VERSION=${revision} to require the build system to use the specified version number. Fixes: b41d920acff8 ("kbuild: deb-pkg: split generating packaging and build") Reported-by: Doug Smythies Signed-off-by: Masahiro Yamada Tested-by: Doug Smythies Signed-off-by: Sasha Levin commit 30fc828c1e1d86a7e151d8a44ed66ed6e8c79016 Author: Dmitry Bogdanov Date: Fri Nov 9 11:54:01 2018 +0000 net: aquantia: invalid checksumm offload implementation [ Upstream commit ad703c2b9127f9acdef697ec4755f6da4beaa266 ] Packets with marked invalid IP/UDP/TCP checksums were considered as good by the driver. The error was in a logic, processing offload bits in RX descriptor. Signed-off-by: Igor Russkikh Signed-off-by: Dmitry Bogdanov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fb7c179f018110ee450d3a7f7bbb85863f2a4f0a Author: Igor Russkikh Date: Fri Nov 9 11:53:59 2018 +0000 net: aquantia: fixed enable unicast on 32 macvlan [ Upstream commit bfaa9f8553d5c20703781e63f4fc8cb4792f18fd ] Fixed a condition mistake due to which macvlans unicast item number 32 was not added in the unicast filter. The consequence is that when exactly 32 macvlans are created on NIC, the last created macvlan receives no traffic because its MAC was not registered in HW. Fixes: 94b3b542303f ("net: aquantia: vlan unicast address list correct handling") Signed-off-by: Igor Russkikh Tested-by: Nikita Danilov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0d70766b98307ca9e10a94e89043c3001fb5a10e Author: Dmitry Bogdanov Date: Fri Nov 9 11:53:57 2018 +0000 net: aquantia: fix potential IOMMU fault after driver unbind [ Upstream commit 7a1bb49461b12b2e6332a4d054256835f45203f3 ] IOMMU fault may occurr on unbind/bind or if_down/if_up sequence. Although driver disables the rings on down, this is not enough. Due to internal HW design, during subsequent initialization NIC sometimes may reuse RX descriptors cache and write to the host memory from the descriptor cache. That's get catched by IOMMU on host. This patch invalidates the descriptor cache in NIC on interface down to prevent writing to the cached descriptors and to the memory pointed in those descriptors. Signed-off-by: Dmitry Bogdanov Signed-off-by: Igor Russkikh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 30d01cc8df84af5820117c6ae3cfeb2930d0d3e0 Author: Thor Thayer Date: Thu Nov 8 11:42:14 2018 -0600 net: stmmac: Fix RX packet size > 8191 [ Upstream commit 8137b6ef0ce469154e5cf19f8e7fe04d9a72ac5e ] Ping problems with packets > 8191 as shown: PING 192.168.1.99 (192.168.1.99) 8150(8178) bytes of data. 8158 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=0.669 ms wrong data byte 8144 should be 0xd0 but was 0x0 16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f %< ---------------snip-------------------------------------- 8112 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf 8144 0 0 0 0 d0 d1 ^^^^^^^ Notice the 4 bytes of 0 before the expected byte of d0. Databook notes that the RX buffer must be a multiple of 4/8/16 bytes [1]. Update the DMA Buffer size define to 8188 instead of 8192. Remove the -1 from the RX buffer size allocations and use the new DMA Buffer size directly. [1] Synopsys DesignWare Cores Ethernet MAC Universal v3.70a [section 8.4.2 - Table 8-24] Tested on SoCFPGA Stratix10 with ping sweep from 100 to 8300 byte packets. Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)") Suggested-by: Jose Abreu Signed-off-by: Thor Thayer Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f791728ec30bf93b5331668d7e79342a85cf4539 Author: Sagiv Ozeri Date: Thu Nov 8 16:46:11 2018 +0200 qed: Fix potential memory corruption [ Upstream commit fa5c448d98f0df660bfcad3dd5facc027ef84cd3 ] A stuck ramrod should be deleted from the completion_pending list, otherwise it will be added again in the future and corrupt the list. Return error value to inform that ramrod is stuck and should be deleted. Signed-off-by: Sagiv Ozeri Signed-off-by: Denis Bolotin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b228e58a6f1f56a4cc2dd0dae4881fbc99f367cb Author: Denis Bolotin Date: Thu Nov 8 16:46:10 2018 +0200 qed: Fix SPQ entries not returned to pool in error flows [ Upstream commit fb5e7438e7a3c8966e04ccb0760170e9e06f3699 ] qed_sp_destroy_request() API was added for SPQ users that need to free/return the entry they acquired in their error flows. Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b2e5004e1e024e7f919bade2723c7c28fc3b56df Author: Denis Bolotin Date: Thu Nov 8 16:46:09 2018 +0200 qed: Fix blocking/unlimited SPQ entries leak [ Upstream commit 2632f22ebd08da249c2017962a199a0cfb2324bf ] When there are no SPQ entries left in the free_pool, new entries are allocated and are added to the unlimited list. When an entry in the pool is available, the content is copied from the original entry, and the new entry is sent to the device. qed_spq_post() is not aware of that, so the additional entry is stored in the original entry as p_post_ent, which can later be returned to the pool. Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 66473b0ac3afe9ccd4126424aa3054c95050dfdc Author: Denis Bolotin Date: Thu Nov 8 16:46:08 2018 +0200 qed: Fix memory/entry leak in qed_init_sp_request() [ Upstream commit 39477551df940ddb1339203817de04f5caaacf7a ] Free the allocated SPQ entry or return the acquired SPQ entry to the free list in error flows. Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1c87c27ac49f2f5b16015240f96507bfdbc3a61c Author: Jacob Keller Date: Mon Oct 29 10:52:42 2018 -0700 i40e: restore NETIF_F_GSO_IPXIP[46] to netdev features [ Upstream commit ba766b8b99c30ad3c55ed8cf224d1185ecff1476 ] Since commit bacd75cfac8a ("i40e/i40evf: Add capability exchange for outer checksum", 2017-04-06) the i40e driver has not reported support for IP-in-IP offloads. This likely occurred due to a bad rebase, as the commit extracts hw_enc_features into its own variable. As part of this change, it dropped the NETIF_F_FSO_IPXIP flags from the netdev->hw_enc_features. This was unfortunately not caught during code review. Fix this by adding back the missing feature flags. For reference, NETIF_F_GSO_IPXIP4 was added in commit 7e13318daa4a ("net: define gso types for IPx over IPv4 and IPv6", 2016-05-20), replacing NETIF_F_GSO_IPIP and NETIF_F_GSO_SIT. NETIF_F_GSO_IPXIP6 was added in commit bf2d1df39502 ("intel: Add support for IPv6 IP-in-IP offload", 2016-05-20). Signed-off-by: Jacob Keller Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 06f5a1f3ea90f21bb16bef83e56cf7d495137124 Author: Chinh T Cao Date: Mon Nov 5 12:18:35 2018 -0800 ice: Change req_speeds to be u16 [ Upstream commit ffe498237b36ee42624e139b21efa05da4ff1f48 ] Since the req_speeds field in struct ice_link_status is a u8, req_speeds & ICE_AQ_LINK_SPEED_40GB always returns 0. This was caught by a coverity scan. Fix this by changing req_speeds to be u16. Reported-by: Bruce Allan Signed-off-by: Chinh T Cao Signed-off-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 86927afbe9138f8483b44b705585ddb70e407cb9 Author: Brett Creeley Date: Fri Oct 26 10:40:59 2018 -0700 ice: Fix the bytecount sent to netdev_tx_sent_queue [ Upstream commit d944b46992f8e99b6bdc721e44b02e5ca294fa2b ] Currently if the driver does a TSO offload the bytecount sent to netdev_tx_sent_queue will be incorrect. This is because in ice_tso we overwrite the initial value that we set in ice_tx_map. This creates a mismatch between the Tx and Tx clean flow. In the Tx clean flow we calculate the bytecount (called total_bytes) as we clean the descriptors so the value used in the Tx clean path is correct. Fix this by using += in ice_tso instead of =. This fixes the mismatch in bytecount mentioned above. Signed-off-by: Brett Creeley Signed-off-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 9d977cd15a474ea55e5ee2965429c4bdffb3d9a5 Author: Akeem G Abodunrin Date: Fri Oct 26 10:40:52 2018 -0700 ice: Fix dead device link issue with flow control [ Upstream commit 0f5d4c21a50716f8bd4e220544b82dca7408d113 ] Setting Rx or Tx pause parameter currently results in link loss on the interface, requiring the platform/host to be cold power cycled. Fix it. Signed-off-by: Akeem G Abodunrin Signed-off-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 7934a53924aaa79d326c3276dc61eb0b5bca7261 Author: Jiri Olsa Date: Sun Sep 23 17:04:20 2018 +0200 perf tools: Do not zero sample_id_all for group members [ Upstream commit 8e88c29b351ed4e09dd63f825f1c8260b0cb0ab3 ] Andi reported following malfunction: # perf record -e '{ref-cycles,cycles}:S' -a sleep 1 # perf script non matching sample_id_all That's because we disable sample_id_all bit for non-sampling group members. We can't do that, because it needs to be the same over the whole event list. This patch keeps it untouched again. Reported-by: Andi Kleen Tested-by: Andi Kleen Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20180923150420.27327-1-jolsa@kernel.org Fixes: e9add8bac6c6 ("perf evsel: Disable write_backward for leader sampling group events") Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1d6ab5f595b0da3a6f3cc2966e6081b66410b6b4 Author: Gustavo Romero Date: Thu Nov 1 20:13:21 2018 -0400 perf tools: Fix undefined symbol scnprintf in libperf-jvmti.so [ Upstream commit 6ac2226229d931153331a93d90655a3de05b9290 ] Currently jvmti agent can not be used because function scnprintf is not present in the agent libperf-jvmti.so. As a result the JVM when using such agent to record JITed code profiling information will fail on looking up scnprintf: java: symbol lookup error: lib/libperf-jvmti.so: undefined symbol: scnprintf This commit fixes that by reverting to the use of snprintf, that can be looked up, instead of scnprintf, adding a proper check for the returned value in order to print a better error message when the jitdump file pathname is too long. Checking the returned value also helps to comply with some recent gcc versions, like gcc8, which will fail due to truncated writing checks related to the -Werror=format-truncation= flag. Signed-off-by: Gustavo Romero Acked-by: Jiri Olsa LPU-Reference: 1541117601-18937-2-git-send-email-gromero@linux.vnet.ibm.com Link: https://lkml.kernel.org/n/tip-mvpxxxy7wnzaj74cq75muw3f@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b1e814e4826635211cb020b767d374f01ba1679b Author: Valentin Schneider Date: Tue Oct 23 14:37:31 2018 +0100 sched/core: Take the hotplug lock in sched_init_smp() [ Upstream commit 40fa3780bac2b654edf23f6b13f4e2dd550aea10 ] When running on linux-next (8c60c36d0b8c ("Add linux-next specific files for 20181019")) + CONFIG_PROVE_LOCKING=y on a big.LITTLE system (e.g. Juno or HiKey960), we get the following report: [ 0.748225] Call trace: [ 0.750685] lockdep_assert_cpus_held+0x30/0x40 [ 0.755236] static_key_enable_cpuslocked+0x20/0xc8 [ 0.760137] build_sched_domains+0x1034/0x1108 [ 0.764601] sched_init_domains+0x68/0x90 [ 0.768628] sched_init_smp+0x30/0x80 [ 0.772309] kernel_init_freeable+0x278/0x51c [ 0.776685] kernel_init+0x10/0x108 [ 0.780190] ret_from_fork+0x10/0x18 The static_key in question is 'sched_asym_cpucapacity' introduced by commit: df054e8445a4 ("sched/topology: Add static_key for asymmetric CPU capacity optimizations") In this particular case, we enable it because smp_prepare_cpus() will end up fetching the capacity-dmips-mhz entry from the devicetree, so we already have some asymmetry detected when entering sched_init_smp(). This didn't get detected in tip/sched/core because we were missing: commit cb538267ea1e ("jump_label/lockdep: Assert we hold the hotplug lock for _cpuslocked() operations") Calls to build_sched_domains() post sched_init_smp() will hold the hotplug lock, it just so happens that this very first call is a special case. As stated by a comment in sched_init_smp(), "There's no userspace yet to cause hotplug operations" so this is a harmless warning. However, to both respect the semantics of underlying callees and make lockdep happy, take the hotplug lock in sched_init_smp(). This also satisfies the comment atop sched_init_domains() that says "Callers must hold the hotplug lock". Reported-by: Sudeep Holla Tested-by: Sudeep Holla Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Cc: Dietmar.Eggemann@arm.com Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: morten.rasmussen@arm.com Cc: quentin.perret@arm.com Link: http://lkml.kernel.org/r/1540301851-3048-1-git-send-email-valentin.schneider@arm.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 1fac2f4f2faed9524d420f74c205f2fb65c72349 Author: Stephen Boyd Date: Fri Nov 2 13:57:32 2018 -0700 i2c: qcom-geni: Fix runtime PM mismatch with child devices [ Upstream commit 848bd3f3de9d44950c00eda6c115e8e9785440da ] We need to enable runtime PM on this i2c controller before populating child devices with i2c_add_adapter(). Otherwise, if a child device uses runtime PM and stays runtime PM enabled we'll get the following warning at boot. Enabling runtime PM for inactive device (a98000.i2c) with active children [...] Call trace: pm_runtime_enable+0xd8/0xf8 geni_i2c_probe+0x440/0x460 platform_drv_probe+0x74/0xc8 [...] Let's move the runtime PM enabling and setup to before we add the adapter, so that this device can respond to runtime PM requests from children. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Stephen Boyd Reviewed-by: Douglas Anderson Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7d5019ed49df80cc43f4bdd4edfe600160b709ee Author: Vignesh R Date: Fri Nov 9 16:44:11 2018 +0530 i2c: omap: Enable for ARCH_K3 [ Upstream commit 5b277402deac0691226a947df71c581686bd4020 ] Allow I2C_OMAP to be built for K3 platforms. Signed-off-by: Vignesh R Reviewed-by: Grygorii Strashko Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit fa4712942d8ee992af92aee78d6c07c6c5cbfb42 Author: Sagi Grimberg Date: Fri Nov 2 11:22:13 2018 -0700 nvme: make sure ns head inherits underlying device limits [ Upstream commit 8f676b8508c250bbe255096522fdefb73f1ea0b9 ] Whenever we update ns_head info, we need to make sure it is still compatible with all underlying backing devices because although nvme multipath doesn't have any explicit use of these limits, other devices can still be stacked on top of it which may rely on the underlying limits. Start with unlimited stacking limits, and every info update iterate over siblings and adjust queue limits. Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 05e25696bd5fe64fc26ef7e9177a69819404b801 Author: Robin Murphy Date: Wed Nov 7 16:30:32 2018 +0000 of/device: Really only set bus DMA mask when appropriate [ Upstream commit 6778be4e520959659b27a441c06a84c9cb009085 ] of_dma_configure() was *supposed* to be following the same logic as acpi_dma_configure() and only setting bus_dma_mask if some range was specified by the firmware. However, it seems that subtlety got lost in the process of fitting it into the differently-shaped control flow, and as a result the force_dma==true case ends up always setting the bus mask to the 32-bit default, which is not what anyone wants. Make sure we only touch it if the DT actually said so. Fixes: 6c2fb2ea7636 ("of/device: Set bus DMA mask as appropriate") Reported-by: Aaro Koskinen Reported-by: Jean-Philippe Brucker Tested-by: Aaro Koskinen Tested-by: John Stultz Tested-by: Geert Uytterhoeven Tested-by: Robert Richter Signed-off-by: Robin Murphy Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 956d9dd3a7eb3fdf19e068150e675af5afff5b7b Author: Luis Henriques Date: Mon Nov 5 19:00:52 2018 +0000 ceph: quota: fix null pointer dereference in quota check [ Upstream commit 71f2cc64d027d712f29bf8d09d3e123302d5f245 ] This patch fixes a possible null pointer dereference in check_quota_exceeded, detected by the static checker smatch, with the following warning:    fs/ceph/quota.c:240 check_quota_exceeded()     error: we previously assumed 'realm' could be null (see line 188) Fixes: b7a2921765cf ("ceph: quota: support for ceph.quota.max_files") Reported-by: Dan Carpenter Signed-off-by: Luis Henriques Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 990746203150ef965ecb649c9206bf023c63f781 Author: Thomas Richter Date: Mon Oct 29 08:11:33 2018 +0000 s390/perf: Change CPUM_CF return code in event init function [ Upstream commit 0bb2ae1b26e1fb7543ec7474cdd374ac4b88c4da ] The function perf_init_event() creates a new event and assignes it to a PMU. This a done in a loop over all existing PMUs. For each listed PMU the event init function is called and if this function does return any other error than -ENOENT, the loop is terminated the creation of the event fails. If the event is invalid, return -ENOENT to try other PMUs. Signed-off-by: Thomas Richter Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit ea1de530903dee6bfe815f1b82b3fde156c11e1d Author: Lyude Paul Date: Thu Nov 1 21:51:49 2018 -0400 drm/amd/amdgpu/dm: Fix dm_dp_create_fake_mst_encoder() [ Upstream commit 63237f8748bdf46dccf79ef8f98f05e9fe799162 ] [why] Removing connector reusage from DM to match the rest of the tree ended up revealing an issue that was surprisingly subtle. The original amdgpu code for DC that was submitted appears to have left a chunk in dm_dp_create_fake_mst_encoder() that tries to find a "master encoder", the likes of which isn't actually used or stored anywhere. It does so at the wrong time as well by trying to access parts of the drm_connector from the encoder init before it's actually been initialized. This results in a NULL pointer deref on MST hotplugs: [ 160.696613] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [ 160.697234] PGD 0 P4D 0 [ 160.697814] Oops: 0010 [#1] SMP PTI [ 160.698430] CPU: 2 PID: 64 Comm: kworker/2:1 Kdump: loaded Tainted: G O 4.19.0Lyude-Test+ #2 [ 160.699020] Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.22 05/17/2018 [ 160.699672] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ 160.700322] RIP: 0010: (null) [ 160.700920] Code: Bad RIP value. [ 160.701541] RSP: 0018:ffffc9000029fc78 EFLAGS: 00010206 [ 160.702183] RAX: 0000000000000000 RBX: ffff8804440ed468 RCX: ffff8804440e9158 [ 160.702778] RDX: 0000000000000000 RSI: ffff8804556c5700 RDI: ffff8804440ed000 [ 160.703408] RBP: ffff880458e21800 R08: 0000000000000002 R09: 000000005fca0a25 [ 160.704002] R10: ffff88045a077a3d R11: ffff88045a077a3c R12: ffff8804440ed000 [ 160.704614] R13: ffff880458e21800 R14: ffff8804440e9000 R15: ffff8804440e9000 [ 160.705260] FS: 0000000000000000(0000) GS:ffff88045f280000(0000) knlGS:0000000000000000 [ 160.705854] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.706478] CR2: ffffffffffffffd6 CR3: 000000000200a001 CR4: 00000000003606e0 [ 160.707124] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.707724] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.708372] Call Trace: [ 160.708998] ? dm_dp_add_mst_connector+0xed/0x1d0 [amdgpu] [ 160.709625] ? drm_dp_add_port+0x2fa/0x470 [drm_kms_helper] [ 160.710284] ? wake_up_q+0x54/0x70 [ 160.710877] ? __mutex_unlock_slowpath.isra.18+0xb3/0x110 [ 160.711512] ? drm_dp_dpcd_access+0xe7/0x110 [drm_kms_helper] [ 160.712161] ? drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] [ 160.712762] ? drm_dp_check_and_send_link_address+0xa3/0xd0 [drm_kms_helper] [ 160.713408] ? drm_dp_mst_link_probe_work+0x4b/0x80 [drm_kms_helper] [ 160.714013] ? process_one_work+0x1a1/0x3a0 [ 160.714667] ? worker_thread+0x30/0x380 [ 160.715326] ? wq_update_unbound_numa+0x10/0x10 [ 160.715939] ? kthread+0x112/0x130 [ 160.716591] ? kthread_create_worker_on_cpu+0x70/0x70 [ 160.717262] ? ret_from_fork+0x35/0x40 [ 160.717886] Modules linked in: amdgpu(O) vfat fat snd_hda_codec_generic joydev i915 chash gpu_sched ttm i2c_algo_bit drm_kms_helper snd_hda_codec_hdmi hp_wmi syscopyarea iTCO_wdt sysfillrect sparse_keymap sysimgblt fb_sys_fops snd_hda_intel usbhid wmi_bmof drm snd_hda_codec btusb snd_hda_core intel_rapl btrtl x86_pkg_temp_thermal btbcm btintel coretemp snd_pcm crc32_pclmul bluetooth psmouse snd_timer snd pcspkr i2c_i801 mei_me i2c_core soundcore mei tpm_tis wmi tpm_tis_core hp_accel ecdh_generic lis3lv02d tpm video rfkill acpi_pad input_polldev hp_wireless pcc_cpufreq crc32c_intel serio_raw tg3 xhci_pci xhci_hcd [last unloaded: amdgpu] [ 160.720141] CR2: 0000000000000000 Somehow the connector reusage DM was using for MST connectors managed to paper over this issue entirely; hence why this was never caught until now. [how] Since this code isn't used anywhere and seems useless anyway, we can just drop it entirely. This appears to fix the issue on my HP ZBook with an AMD WX4150. Signed-off-by: Lyude Paul Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b3db5d74b933a39267004bcb4c6bc619b9c96d3d Author: Jerry (Fangzhi) Zuo Date: Tue Oct 30 14:37:16 2018 -0400 drm/amd/display: Drop reusing drm connector for MST [ Upstream commit 0e6613e46fed29316f33acf86e1d1568288638b5 ] [why] It is not safe to keep existing connector while entire topology has been removed. Could lead potential impact to uapi. Entirely unregister all the connectors on the topology, and use a new set of connectors when the topology is plugged back on. [How] Remove the drm connector entirely each time when the corresponding MST topology is gone. When hotunplug a connector (e.g., DP2) 1. Remove connector from userspace. 2. Drop it's reference. When hotplug back on: 1. Detect new topology, and create new connectors. 2. Notify userspace with sysfs hotplug event. 3. Reprobe new connectors, and reassign CRTC from old (e.g., DP2) to new (e.g., DP3) connector. Signed-off-by: Jerry (Fangzhi) Zuo Reviewed-by: Harry Wentland Reviewed-by: Lyude Paul Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a4da95ea101b2741488c6d84d3ce6e3d0cdffd62 Author: Keith Busch Date: Wed Nov 7 07:37:45 2018 -0700 block: Clear kernel memory before copying to user [ Upstream commit f3587d76da05f68098ddb1cb3c98cc6a9e8a402c ] If the kernel allocates a bounce buffer for user read data, this memory needs to be cleared before copying it to the user, otherwise it may leak kernel memory to user space. Laurence Oberman Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b352afaac108d9d6c10cd1d9cd6155b83b779b65 Author: Harry Wentland Date: Sun Oct 7 10:01:23 2018 -0400 drm/amd/display: Stop leaking planes [ Upstream commit 02680efbb10be0d2c867fe722ae23d588f6bebef ] [Why] drm_plane_cleanup does not free the plane. [How] Call drm_primary_helper_destroy which will also free the plane. Signed-off-by: Harry Wentland Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 365b1b122406ca26331fc48ab53dfbf5a9b0889c Author: Jeremy Linton Date: Mon Nov 5 18:14:41 2018 -0600 lib/raid6: Fix arm64 test build [ Upstream commit 313a06e636808387822af24c507cba92703568b1 ] The lib/raid6/test fails to build the neon objects on arm64 because the correct machine type is 'aarch64'. Once this is correctly enabled, the neon recovery objects need to be added to the build. Reviewed-by: Ard Biesheuvel Signed-off-by: Jeremy Linton Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 238ab6deba302a1b9b083dbb1c456187105c4ddd Author: Boris Brezillon Date: Tue Nov 6 17:25:37 2018 +0100 mtd: nand: Fix nanddev_pos_next_page() kernel-doc header [ Upstream commit 98ee3fc7ef8395f8b7a379e6608aee91efc66d48 ] Function name is wrong in the kernel-doc header. Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with NAND devices") Signed-off-by: Boris Brezillon Reviewed-by: Miquel Raynal Signed-off-by: Sasha Levin commit 20f020fd089395de918a3e6d4a4c141c25b9a6df Author: Ricardo Ribalda Delgado Date: Thu Nov 1 14:15:49 2018 +0100 clk: fixed-factor: fix of_node_get-put imbalance [ Upstream commit f98e8a572bddbf27032114127d2fcc78fa5e6a9d ] When the fixed factor clock is created by devicetree, of_clk_add_provider is called. Add a call to of_clk_del_provider in the remove function to balance it out. Reported-by: Alan Tull Fixes: 971451b3b15d ("clk: fixed-factor: Convert into a module platform driver") Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit dd9392292e5b769ae8496b6df6eb20668dd91827 Author: Liam Merwick Date: Fri Nov 2 14:04:23 2018 +0000 xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message [ Upstream commit d9cccfa7c4d1d9ef967ec9308df7304a18609b30 ] If a call to xenmem_reservation_increase() in gnttab_dma_free_pages() fails it triggers a message "Failed to decrease reservation..." which should be "Failed to increase reservation..." Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for DMA') Reported-by: Ross Philipson Signed-off-by: Liam Merwick Reviewed-by: Mark Kanda Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 71076a71d81b49404a20307da699bfc719625f58 Author: Sergei Shtylyov Date: Thu Oct 18 19:48:53 2018 +0300 arm64: dts: renesas: condor: switch from EtherAVB to GEther [ Upstream commit eab53fdfd60a84b0cc514d4f1f5d79226c76df01 ] The "official" Condor boards have always been wired to mount NFS via GEther, not EtherAVB -- the boards resoldered for EtherAVB were local to Cogent Embedded, so we've been having an unpleasant situation where a "normal" Condor board still can't mount NFS (unless an EtherAVB PHY extension board is plugged in). Switch from EtherAVB to GEther at last! Fixes: 8091788f3d38 ("arm64: dts: renesas: condor: add EtherAVB support") Signed-off-by: Sergei Shtylyov Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit 9edc40fd786aa99d72095b848ea4fdd0050dc807 Author: Kuninori Morimoto Date: Fri Sep 28 02:38:36 2018 +0000 arm64: dts: renesas: r8a7795: add missing dma-names on hscif2 [ Upstream commit aab7a2414ba0d5c3d0571a90031b535adba7146a ] hscif2 has 4 dmas, but has only 2 dma-names. This patch add missing dma-names. Signed-off-by: Kuninori Morimoto Reviewed-by: Geert Uytterhoeven Fixes: e0f0bda79337701a ("arm64: dts: renesas: r8a7795: sort subnodes of the soc node") Signed-off-by: Simon Horman Signed-off-by: Sasha Levin commit 91611ad1bf69ec46d6c61f27eccb44064c28c45c Author: Inki Dae Date: Fri Oct 5 11:50:20 2018 +0900 Revert "drm/exynos/decon5433: implement frame counter" [ Upstream commit 6ca469e22a30992b4478d2ab88737c70667c1e00 ] This reverts commit 0586feba322e1de05075700eb4b835c8b683e62b This patch makes it to need get_vblank_counter callback in crtc to get frame counter from decon driver. However, drm_dev->max_vblank_count is a member unique to vendor's DRM driver but in case of ARM DRM, some CRTC devices don't provide the frame counter value. As a result, this patch made extension and clone mode not working. Instead of this patch, we may need separated max_vblank_count which belongs to each CRTC device, or need to implement frame counter emulation for them who don't support HW frame counter. Signed-off-by: Inki Dae Signed-off-by: Sasha Levin commit 3190aa80827d497eb1700ef75c28b6be5cc991ea Author: Rob Herring Date: Tue Oct 30 20:02:30 2018 -0500 ARM: dts: fsl: Fix improperly quoted stdout-path values [ Upstream commit 1af6ab3bac8458fc2e92ad7bb97b62de4a1fddef ] A quoted label reference doesn't expand to the node path and is taken as a literal string. Dropping the quotes can fix this unless the baudrate string is appended in which case we have to use the alias. At least on VF610, the problem was masked by setting the console in bootargs. Use the alias syntax with baudrate parameter so we can drop setting the console in bootargs. Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: NXP Linux Team Cc: Mark Rutland Reviewed-by: Fabio Estevam Reviewed-by: Stefan Agner Signed-off-by: Rob Herring Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 22ef72a086d56a56ecb44a5c04994bc71d1afd25 Author: Oleksij Rempel Date: Thu Oct 18 13:26:13 2018 +0200 ARM: dts: imx6sll: fix typo for fsl,imx6sll-i2c node [ Upstream commit 438ad09af5581b7024850b5dbb6353c7f2f7d8a9 ] Fix the type of compatible string "fs,imx6sll-i2c" which should be "fsl,imx6sll-i2c". Signed-off-by: Oleksij Rempel Acked-by: Uwe Kleine-König Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 1ea367bb99a0a31183bcf155974a33f6798dff13 Author: Geert Uytterhoeven Date: Sun Oct 28 18:16:51 2018 +0100 hwmon: (ibmpowernv) Remove bogus __init annotations [ Upstream commit e3e61f01d755188cb6c2dcf5a244b9c0937c258e ] If gcc decides not to inline make_sensor_label(): WARNING: vmlinux.o(.text+0x4df549c): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label() The function .create_device_attrs() references the function __init .make_sensor_label(). This is often because .create_device_attrs lacks a __init annotation or the annotation of .make_sensor_label is wrong. As .probe() can be called after freeing of __init memory, all __init annotiations in the driver are bogus, and should be removed. Signed-off-by: Geert Uytterhoeven Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c981726f16aab432e48cfcf7d72c26b31b50c516 Author: Yunsheng Lin Date: Fri Nov 2 17:47:48 2018 +0800 net: hns3: Fix for out-of-bounds access when setting pfc back pressure [ Upstream commit e8ccbb7d2f53c62e14b889faaa3f6f809b657278 ] The vport should be initialized to hdev->vport for each bp group, otherwise it will cause out-of-bounds access and bp setting not correct problem. [ 35.254124] BUG: KASAN: slab-out-of-bounds in hclge_pause_setup_hw+0x2a0/0x3f8 [hclge] [ 35.254126] Read of size 2 at addr ffff803b6651581a by task kworker/0:1/14 [ 35.254132] CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 4.19.0-rc7-hulk+ #85 [ 35.254133] Hardware name: Huawei D06/D06, BIOS Hisilicon D06 UEFI RC0 - B052 (V0.52) 09/14/2018 [ 35.254141] Workqueue: events work_for_cpu_fn [ 35.254144] Call trace: [ 35.254147] dump_backtrace+0x0/0x2f0 [ 35.254149] show_stack+0x24/0x30 [ 35.254154] dump_stack+0x110/0x184 [ 35.254157] print_address_description+0x168/0x2b0 [ 35.254160] kasan_report+0x184/0x310 [ 35.254162] __asan_load2+0x7c/0xa0 [ 35.254170] hclge_pause_setup_hw+0x2a0/0x3f8 [hclge] [ 35.254177] hclge_tm_init_hw+0x794/0x9f0 [hclge] [ 35.254184] hclge_tm_schd_init+0x48/0x58 [hclge] [ 35.254191] hclge_init_ae_dev+0x778/0x1168 [hclge] [ 35.254196] hnae3_register_ae_dev+0x14c/0x298 [hnae3] [ 35.254206] hns3_probe+0x88/0xa8 [hns3] [ 35.254210] local_pci_probe+0x7c/0xf0 [ 35.254212] work_for_cpu_fn+0x34/0x50 [ 35.254214] process_one_work+0x4d4/0xa38 [ 35.254216] worker_thread+0x55c/0x8d8 [ 35.254219] kthread+0x1b0/0x1b8 [ 35.254222] ret_from_fork+0x10/0x1c [ 35.254224] The buggy address belongs to the page: [ 35.254228] page:ffff7e00ed994400 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0 [ 35.273835] flags: 0xfffff8000008000(head) [ 35.282007] raw: 0fffff8000008000 dead000000000100 dead000000000200 0000000000000000 [ 35.282010] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 35.282012] page dumped because: kasan: bad access detected [ 35.282014] Memory state around the buggy address: [ 35.282017] ffff803b66515700: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe [ 35.282019] ffff803b66515780: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe [ 35.282021] >ffff803b66515800: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe [ 35.282022] ^ [ 35.282024] ffff803b66515880: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe [ 35.282026] ffff803b66515900: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe [ 35.282028] ================================================================== [ 35.282029] Disabling lock debugging due to kernel taint [ 35.282747] hclge driver initialization finished. Fixes: 67bf2541f4b9 ("net: hns3: Fixes the back pressure setting when sriov is enabled") Signed-off-by: Yunsheng Lin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 99b9de47a8b64d534582d26c80f4220e6189df60 Author: Julian Wiedmann Date: Fri Nov 2 19:04:10 2018 +0100 s390/qeth: unregister netdevice only when registered [ Upstream commit 30356d08159d7899438e94503ae322a8b881e205 ] qeth only registers its netdevice when the qeth device is first set online. Thus a device that has never been set online will trigger a WARN ("network todo 'hsi%d' but state 0") in unregister_netdev() when removed. Fix this by protecting the unregister step, just like we already protect against repeated registering of the netdevice. Fixes: d3d1b205e89f ("s390/qeth: allocate netdevice early") Reported-by: Karsten Graul Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d005b563ae0cef9712077ba4407d771c75bd4194 Author: Julian Wiedmann Date: Fri Nov 2 19:04:09 2018 +0100 s390/qeth: fix HiperSockets sniffer [ Upstream commit bd74a7f9cc033cf4d405788f80292268987dc0c5 ] Sniffing mode for L3 HiperSockets requires that no IP addresses are registered with the HW. The preferred way to achieve this is for userspace to delete all the IPs on the interface. But qeth is expected to also tolerate a configuration where that is not the case, by skipping the IP registration when in sniffer mode. Since commit 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback") reworked the IP registration logic in the L3 subdriver, this no longer works. When the qeth device is set online, qeth_l3_recover_ip() now unconditionally registers all unicast addresses from our internal IP table. While we could fix this particular problem by skipping qeth_l3_recover_ip() on a sniffer device, the more future-proof change is to skip the IP address registration at the lowest level. This way we a) catch any future code path that attempts to register an IP address without considering the sniffer scenario, and b) continue to build up our internal IP table, so that if sniffer mode is switched off later we can operate just like normal. Fixes: 5f78e29ceebf ("qeth: optimize IP handling in rx_mode callback") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1cf11e7ca034919f242a855b1a52c018b3cba911 Author: Florian Westphal Date: Fri Nov 2 11:33:37 2018 +0100 netfilter: nft_compat: ebtables 'nat' table is normal chain type [ Upstream commit e4844c9c62a0fe47980d6c3d4b7a096a5d755925 ] Unlike ip(6)tables, the ebtables nat table has no special properties. This bug causes 'ebtables -A' to fail when using a target such as 'snat' (ebt_snat target sets ".table = "nat"'). Targets that have no table restrictions work fine. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2f6bf7917f55f9dae913193e49672b3598620eab Author: Jozsef Kadlecsik Date: Tue Oct 30 22:43:42 2018 +0100 netfilter: ipset: Fix calling ip_set() macro at dumping [ Upstream commit 8a02bdd50b2ecb6d62121d2958d3ea186cc88ce7 ] The ip_set() macro is called when either ip_set_ref_lock held only or no lock/nfnl mutex is held at dumping. Take this into account properly. Also, use Pablo's suggestion to use rcu_dereference_raw(), the ref_netlink protects the set. Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e8b258ce87ff84ee967aad80095bc85dcc9db077 Author: Taehee Yoo Date: Sun Oct 21 00:00:08 2018 +0900 netfilter: xt_IDLETIMER: add sysfs filename checking routine [ Upstream commit 54451f60c8fa061af9051a53be9786393947367c ] When IDLETIMER rule is added, sysfs file is created under /sys/class/xt_idletimer/timers/ But some label name shouldn't be used. ".", "..", "power", "uevent", "subsystem", etc... So that sysfs filename checking routine is needed. test commands: %iptables -I INPUT -j IDLETIMER --timeout 1 --label "power" splat looks like: [95765.423132] sysfs: cannot create duplicate filename '/devices/virtual/xt_idletimer/timers/power' [95765.433418] CPU: 0 PID: 8446 Comm: iptables Not tainted 4.19.0-rc6+ #20 [95765.449755] Call Trace: [95765.449755] dump_stack+0xc9/0x16b [95765.449755] ? show_regs_print_info+0x5/0x5 [95765.449755] sysfs_warn_dup+0x74/0x90 [95765.449755] sysfs_add_file_mode_ns+0x352/0x500 [95765.449755] sysfs_create_file_ns+0x179/0x270 [95765.449755] ? sysfs_add_file_mode_ns+0x500/0x500 [95765.449755] ? idletimer_tg_checkentry+0x3e5/0xb1b [xt_IDLETIMER] [95765.449755] ? rcu_read_lock_sched_held+0x114/0x130 [95765.449755] ? __kmalloc_track_caller+0x211/0x2b0 [95765.449755] ? memcpy+0x34/0x50 [95765.449755] idletimer_tg_checkentry+0x4e2/0xb1b [xt_IDLETIMER] [ ... ] Fixes: 0902b469bd25 ("netfilter: xtables: idletimer target implementation") Signed-off-by: Taehee Yoo Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e395c9d2d9c3d4986b2d79e23efb0d2a7b14e465 Author: Jozsef Kadlecsik Date: Fri Oct 19 19:35:19 2018 +0200 netfilter: ipset: Correct rcu_dereference() call in ip_set_put_comment() [ Upstream commit 17b8b74c0f8dbf9b9e3301f9ca5b65dd1c079951 ] The function is called when rcu_read_lock() is held and not when rcu_read_lock_bh() is held. Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1a7ccf42cb03cd9976134eea111cfc5168a0ea31 Author: Daniel Borkmann Date: Fri Nov 2 11:35:46 2018 +0100 bpf: fix bpf_prog_get_info_by_fd to return 0 func_lens for unpriv [ Upstream commit 28c2fae726bf5003cd209b0d5910a642af98316f ] While dbecd7388476 ("bpf: get kernel symbol addresses via syscall") zeroed info.nr_jited_ksyms in bpf_prog_get_info_by_fd() for queries from unprivileged users, commit 815581c11cc2 ("bpf: get JITed image lengths of functions via syscall") forgot about doing so and therefore returns the #elems of the user set up buffer which is incorrect. It also needs to indicate a info.nr_jited_func_lens of zero. Fixes: 815581c11cc2 ("bpf: get JITed image lengths of functions via syscall") Signed-off-by: Daniel Borkmann Cc: Sandipan Das Cc: Song Liu Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5e4ad7cec8f81ce022d51e6e2d4059d45cc3ac12 Author: Justin M. Forbes Date: Wed Oct 31 13:02:03 2018 -0500 s390/mm: Fix ERROR: "__node_distance" undefined! [ Upstream commit a541f0ebcc08ed8bc0cc492eec9a86cb280a9f24 ] Fixes: ERROR: "__node_distance" [drivers/nvme/host/nvme-core.ko] undefined! make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1 make: *** [Makefile:1275: modules] Error 2 + exit 1 Signed-off-by: Justin M. Forbes Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 4136161d676a93fc8df6bdb80d720c15522d6c24 Author: Martin Schwidefsky Date: Mon Oct 15 11:09:16 2018 +0200 s390/mm: fix mis-accounting of pgtable_bytes [ Upstream commit e12e4044aede97974f2222eb7f0ed726a5179a32 ] In case a fork or a clone system fails in copy_process and the error handling does the mmput() at the bad_fork_cleanup_mm label, the following warning messages will appear on the console: BUG: non-zero pgtables_bytes on freeing mm: 16384 The reason for that is the tricks we play with mm_inc_nr_puds() and mm_inc_nr_pmds() in init_new_context(). A normal 64-bit process has 3 levels of page table, the p4d level and the pud level are folded. On process termination the free_pud_range() function in mm/memory.c will subtract 16KB from pgtable_bytes with a mm_dec_nr_puds() call, but there actually is not really a pud table. One issue with this is the fact that pgtable_bytes is usually off by a few kilobytes, but the more severe problem is that for a failed fork or clone the free_pgtables() function is not called. In this case there is no mm_dec_nr_puds() or mm_dec_nr_pmds() that go together with the mm_inc_nr_puds() and mm_inc_nr_pmds in init_new_context(). The pgtable_bytes will be off by 16384 or 32768 bytes and we get the BUG message. The message itself is purely cosmetic, but annoying. To fix this override the mm_pmd_folded, mm_pud_folded and mm_p4d_folded function to check for the true size of the address space. Reported-by: Li Wang Tested-by: Li Wang Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 97fdf29f7d537826b1174bcbc04a14938c8fae5f Author: Andrey Ryabinin Date: Mon Oct 22 23:30:40 2018 +0200 netfilter: ipset: fix ip_set_list allocation failure [ Upstream commit ed956f3947a01ff9875cd908d7c1ef1fe7f47bf0 ] ip_set_create() and ip_set_net_init() attempt to allocate physically contiguous memory for ip_set_list. If memory is fragmented, the allocations could easily fail: vzctl: page allocation failure: order:7, mode:0xc0d0 Call Trace: dump_stack+0x19/0x1b warn_alloc_failed+0x110/0x180 __alloc_pages_nodemask+0x7bf/0xc60 alloc_pages_current+0x98/0x110 kmalloc_order+0x18/0x40 kmalloc_order_trace+0x26/0xa0 __kmalloc+0x279/0x290 ip_set_net_init+0x4b/0x90 [ip_set] ops_init+0x3b/0xb0 setup_net+0xbb/0x170 copy_net_ns+0xf1/0x1c0 create_new_namespaces+0xf9/0x180 copy_namespaces+0x8e/0xd0 copy_process+0xb61/0x1a00 do_fork+0x91/0x320 Use kvcalloc() to fallback to 0-order allocations if high order page isn't available. Signed-off-by: Andrey Ryabinin Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cb3e590df429ce151d5041884a4947099b8ad6a7 Author: Eric Westbrook Date: Tue Aug 28 15:14:42 2018 -0600 netfilter: ipset: actually allow allowable CIDR 0 in hash:net,port,net [ Upstream commit 886503f34d63e681662057448819edb5b1057a97 ] Allow /0 as advertised for hash:net,port,net sets. For "hash:net,port,net", ipset(8) says that "either subnet is permitted to be a /0 should you wish to match port between all destinations." Make that statement true. Before: # ipset create cidrzero hash:net,port,net # ipset add cidrzero 0.0.0.0/0,12345,0.0.0.0/0 ipset v6.34: The value of the CIDR parameter of the IP address is invalid # ipset create cidrzero6 hash:net,port,net family inet6 # ipset add cidrzero6 ::/0,12345,::/0 ipset v6.34: The value of the CIDR parameter of the IP address is invalid After: # ipset create cidrzero hash:net,port,net # ipset add cidrzero 0.0.0.0/0,12345,0.0.0.0/0 # ipset test cidrzero 192.168.205.129,12345,172.16.205.129 192.168.205.129,tcp:12345,172.16.205.129 is in set cidrzero. # ipset create cidrzero6 hash:net,port,net family inet6 # ipset add cidrzero6 ::/0,12345,::/0 # ipset test cidrzero6 fe80::1,12345,ff00::1 fe80::1,tcp:12345,ff00::1 is in set cidrzero6. See also: https://bugzilla.kernel.org/show_bug.cgi?id=200897 https://github.com/ewestbrook/linux/commit/df7ff6efb0934ab6acc11f003ff1a7580d6c1d9c Signed-off-by: Eric Westbrook Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c75116e66ed3a000798d5a702349446153a0348f Author: Stefano Brivio Date: Sat Jul 14 21:59:43 2018 +0200 netfilter: ipset: list:set: Decrease refcount synchronously on deletion and replace [ Upstream commit 439cd39ea136d2c026805264d58a91f36b6b64ca ] Commit 45040978c899 ("netfilter: ipset: Fix set:list type crash when flush/dump set in parallel") postponed decreasing set reference counters to the RCU callback. An 'ipset del' command can terminate before the RCU grace period is elapsed, and if sets are listed before then, the reference counter shown in userspace will be wrong: # ipset create h hash:ip; ipset create l list:set; ipset add l # ipset del l h; ipset list h Name: h Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 88 References: 1 Number of entries: 0 Members: # sleep 1; ipset list h Name: h Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 88 References: 0 Number of entries: 0 Members: Fix this by making the reference count update synchronous again. As a result, when sets are listed, ip_set_name_byindex() might now fetch a set whose reference count is already zero. Instead of relying on the reference count to protect against concurrent set renaming, grab ip_set_ref_lock as reader and copy the name, while holding the same lock in ip_set_rename() as writer instead. Reported-by: Li Shuang Fixes: 45040978c899 ("netfilter: ipset: Fix set:list type crash when flush/dump set in parallel") Signed-off-by: Stefano Brivio Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit fecf70b13557328cbda7555633377e88ef8a62b6 Author: Pablo Neira Ayuso Date: Fri Oct 26 11:14:28 2018 +0200 Revert "netfilter: nft_numgen: add map lookups for numgen random operations" [ Upstream commit 4269fea768a11a447d8de620ce420f2214d4685c ] Laura found a better way to do this from userspace without requiring kernel infrastructure, revert this. Fixes: 978d8f9055c3 ("netfilter: nft_numgen: add map lookups for numgen random operations") Signed-off-by: Laura Garcia Liebana Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 67b261d76df33d8f6f84754db0078cd9be7b3e34 Author: Benjamin Tissoires Date: Fri Oct 12 16:05:25 2018 +0200 HID: alps: allow incoming reports when only the trackstick is opened [ Upstream commit 7dd8db68949a7acc5bd528ee0ecb8f8720f49921 ] If userspace only reads the trackstick node, and no one is listening to the touchpad nor the hidraw node then, the device is not powered on. Add open/close callbacks to allow users to disable the touchpad in Gnome while keeping the trackstick active. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1559632 Link: https://gitlab.gnome.org/GNOME/mutter/issues/128 Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 3b7b23827dfbcf4d9b0e004016940586a9cc6639 Author: Benjamin Tissoires Date: Wed Oct 17 09:01:53 2018 +0200 Revert "HID: add NOGET quirk for Eaton Ellipse MAX UPS" [ Upstream commit 6298944d8f57f40ee2a3e6dcea1253e78d7a9969 ] This reverts commit 67ddbb3e6568fb1820b2cc45b00c50702b114801. 67ddbb3e656 ("HID: add NOGET quirk for Eaton Ellipse MAX UPS") was reported by Laurent Bigonville. It turns out that a later model Laurent got doesn't need the quirk after all. My take is that Eaton upgraded their firmwares, so we don't need it anymore. The old model was from 2012, so better make sure the new line works properly by removing the quirk. This allows upower to actually fetch the current data. Reported-by: Laurent Bigonville Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 48d49b635b66f3017ecd795c211190d6d1beca57 Author: Kai-Heng Feng Date: Fri Oct 5 12:46:29 2018 +0800 HID: i2c-hid: Add a small delay after sleep command for Raydium touchpanel [ Upstream commit 00b790ea545b6ef30221adef6e9c3707e03b82b5 ] Raydium touchpanel (2386:4B33) sometimes does not work in desktop session although it works in display manager. During user logging, the display manager exits, close the HID device, then the device gets runtime suspended and powered off. The desktop session begins shortly after, opens the HID device, then the device gets runtime resumed and powered on. If the trasition from display manager to desktop sesesion is fast, the touchpanel cannot switch from powered off to powered on in short timeframe. So add a small delay to workaround the issue. Signed-off-by: Kai-Heng Feng Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1d5dfce77c957056f9d92fffa1df7daea757ba13 Author: Vasily Gorbik Date: Fri Oct 19 15:37:01 2018 +0200 s390/vdso: add missing FORCE to build targets [ Upstream commit b44b136a3773d8a9c7853f8df716bd1483613cbb ] According to Documentation/kbuild/makefiles.txt all build targets using if_changed should use FORCE as well. Add missing FORCE to make sure vdso targets are rebuild properly when not just immediate prerequisites have changed but also when build command differs. Reviewed-by: Philipp Rudo Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 9b2d5118f74fede5a989ef8747d8fdfca84771dd Author: Vasily Gorbik Date: Fri Oct 19 13:37:46 2018 +0200 s390/decompressor: add missing FORCE to build targets [ Upstream commit ef5febae1543f35a45f01614123e829d77326d0f ] According to Documentation/kbuild/makefiles.txt all build targets using if_changed should use FORCE as well. Add missing FORCE to make sure vmlinux decompressor targets are rebuild properly when not just immediate prerequisites have changed but also when build command differs. Reviewed-by: Philipp Rudo Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit a3123502b84f33e743507a5e613c3363c16dc525 Author: Jiri Slaby Date: Wed Oct 24 13:54:03 2018 +0200 netfilter: bridge: define INT_MIN & INT_MAX in userspace [ Upstream commit 5a8de47b3c250521dd632cdedaac6db88367defa ] With 4.19, programs like ebtables fail to build when they include "linux/netfilter_bridge.h". It is caused by commit 94276fa8a2a4 which added a use of INT_MIN and INT_MAX to the header: : In file included from /usr/include/linux/netfilter_bridge/ebtables.h:18, : from include/ebtables_u.h:28, : from communication.c:23: : /usr/include/linux/netfilter_bridge.h:30:20: error: 'INT_MIN' undeclared here (not in a function) : NF_BR_PRI_FIRST = INT_MIN, : ^~~~~~~ Define these constants by including "limits.h" when !__KERNEL__ (the same way as for other netfilter_* headers). Fixes: 94276fa8a2a4 ("netfilter: bridge: Expose nf_tables bridge hook priorities through uapi") Signed-off-by: Jiri Slaby Acked-by: Máté Eckl Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 84ed07d9577ec3965c6747ac3cd154844777060e Author: Florian Westphal Date: Tue Oct 23 16:47:16 2018 +0200 netfilter: ipv6: fix oops when defragmenting locally generated fragments [ Upstream commit 61792b677415b77c8db04991c22966bb8de7603e ] Unlike ipv4 and normal ipv6 defrag, netfilter ipv6 defragmentation did not save/restore skb->dst. This causes oops when handling locally generated ipv6 fragments, as output path needs a valid dst. Reported-by: Maciej Żenczykowski Fixes: 84379c9afe01 ("netfilter: ipv6: nf_defrag: drop skb dst before queueing") Signed-off-by: Florian Westphal Reviewed-by: Eric Dumazet Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c2c72619cce2461203bab86984b92d6923882b8e Author: Geert Uytterhoeven Date: Tue Oct 9 19:41:58 2018 +0200 serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA [ Upstream commit 202dc3cc10b4d37e5251431acf8d5040a8876c7d ] On SCIFA and SCIFB serial ports with DMA support (i.e. some ports on R-Car Gen2 and RZ/G1 SoCs), receive DMA operations are submitted before the DMA channel pointer is initialized. Hence this fails, and the driver tries to fall back to PIO. However, at this early phase in the initialization sequence, fallback to PIO does not work, leading to a serial port that cannot receive any data. Fix this by calling sci_submit_rx() after initialization of the DMA channel pointer. Reported-by: Yoshihiro Shimoda Fixes: 2c4ee23530ffc022 ("serial: sh-sci: Postpone DMA release when falling back to PIO") Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 459852bfd6ed77449cbf0a7e7b650bf61dd96162 Author: Johan Hovold Date: Wed Aug 22 11:03:19 2018 +0200 clk: ti: fix OF child-node lookup [ Upstream commit 00a461cc32ec27fa7bd9c874a7b36b0c6c542c12 ] Fix child-node lookup which by using the wrong OF helper was searching the whole tree depth-first, something which could end up matching an unrelated node. Also fix the related node-reference leaks. Fixes: 5b385a45e001 ("clk: ti: add support for clkctrl aliases") Signed-off-by: Johan Hovold Acked-by: Tero Kristo Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1e5ac60289f941a42cb6cedc381f1681320626c5 Author: Phil Edworthy Date: Fri Aug 31 12:26:36 2018 +0100 clk: renesas: r9a06g032: Fix UART34567 clock rate [ Upstream commit ee02950d53eee0d4c7f1c08a35272b77d24b9459 ] The clock for UARTs 0 through 2 is UART012, the clock for UARTs 3 through 7 is UART34567. For UART012, we stop the clock driver from changing the clock rate. This is because the Synopsys UART driver simply sets the reference clock to 16x the baud rate, but doesn't check if the actual rate is within the required tolerance. The RZ/N1 clock divider can't provide this (we have to rely on the UART's internal divider to set the correct clock rate), so you end up with a clock rate that is way off what you wanted. In addition, since the clock is shared between multiple UARTs, you don't want the driver trying to change the clock rate as it may affect the other UARTs (which may not have been configured yet, so you don't know what baud rate they will use). Normally, the clock rate is set early on before Linux to some very high rate that supports all of the clock rates you want. This change stops the UART34567 clock rate from changing for the same reasons. Signed-off-by: Phil Edworthy Fixes: 4c3d88526eba2143 ("clk: renesas: Renesas R9A06G032 clock driver") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a178c7abb3a774fbff7d19fd342175b71b592384 Author: Jerome Brunet Date: Wed Aug 1 16:00:51 2018 +0200 clk: meson: clk-pll: drop CLK_GET_RATE_NOCACHE where unnecessary [ Upstream commit 2303a9ca693e585a558497ad737728fec97e2b8a ] CLK_GET_RATE_NOCACHE should only be necessary when the registers controlling the rate of clock may change outside of CCF. On Amlogic, it should only be the case for the hdmi pll which is directly controlled by the display driver (WIP to fix this). The other plls should not require this flag. Reviewed-by: Martin Blumenstingl Tested-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit ee9b38131b4b288d1db5ce2ac8617f703b3d93e1 Author: Nathan Chancellor Date: Tue Sep 25 12:44:59 2018 -0700 arm64: percpu: Initialize ret in the default case [ Upstream commit b5bb425871186303e6936fa2581521bdd1964a58 ] Clang warns that if the default case is taken, ret will be uninitialized. ./arch/arm64/include/asm/percpu.h:196:2: warning: variable 'ret' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: ^~~~~~~ ./arch/arm64/include/asm/percpu.h:200:9: note: uninitialized use occurs here return ret; ^~~ ./arch/arm64/include/asm/percpu.h:157:19: note: initialize the variable 'ret' to silence this warning unsigned long ret, loop; ^ = 0 This warning appears several times while building the erofs filesystem. While it's not strictly wrong, the BUILD_BUG will prevent this from becoming a true problem. Initialize ret to 0 in the default case right before the BUILD_BUG to silence all of these warnings. Reported-by: Prasad Sodagudi Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Dennis Zhou Signed-off-by: Sasha Levin commit e252c95d05f61efbf8522ac7ed4f8ab7defb77de Author: Yixun Lan Date: Wed Aug 1 12:16:24 2018 +0000 clk: meson-axg: pcie: drop the mpll3 clock parent [ Upstream commit 69b93104c7ec5668019caf5d2dbfd0e182df06db ] We found the PCIe driver doesn't really work with the mpll3 clock which is actually reserved for debug, So drop it from the mux list. Fixes: 33b89db68236 ("clk: meson-axg: add clocks required by pcie driver") Tested-by: Jianxin Qin Signed-off-by: Yixun Lan Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit e28f46344721c8481afd2b706b533a187c0bdb0e Author: Paul Gortmaker Date: Thu Sep 20 21:44:19 2018 -0400 platform/x86: acerhdf: Add BIOS entry for Gateway LT31 v1.3307 [ Upstream commit 684238d79ad85c5e19a71bb5818e77e329912fbc ] To fix: acerhdf: unknown (unsupported) BIOS version Gateway /LT31 /v1.3307 , please report, aborting! As can be seen in the context, the BIOS registers haven't changed in the previous versions, so the assumption is they won't have changed in this last update for this somewhat older platform either. Cc: Peter Feuerer Cc: Darren Hart Cc: Andy Shevchenko Signed-off-by: Paul Gortmaker Signed-off-by: Andy Shevchenko Reviewed-by: Peter Feuerer Signed-off-by: Sasha Levin commit 9f0e46bf5559897f724d940e39e4ffc230413325 Author: Feng Tang Date: Wed Oct 3 00:49:21 2018 +0800 x86/earlyprintk: Add a force option for pciserial device [ Upstream commit d2266bbfa9e3e32e3b642965088ca461bd24a94f ] The "pciserial" earlyprintk variant helps much on many modern x86 platforms, but unfortunately there are still some platforms with PCI UART devices which have the wrong PCI class code. In that case, the current class code check does not allow for them to be used for logging. Add a sub-option "force" which overrides the class code check and thus the use of such device can be enforced. [ bp: massage formulations. ] Suggested-by: Borislav Petkov Signed-off-by: Feng Tang Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: "Stuart R . Anderson" Cc: Bjorn Helgaas Cc: David Rientjes Cc: Feng Tang Cc: Frederic Weisbecker Cc: Greg Kroah-Hartman Cc: H Peter Anvin Cc: Ingo Molnar Cc: Jiri Kosina Cc: Jonathan Corbet Cc: Kai-Heng Feng Cc: Kate Stewart Cc: Konrad Rzeszutek Wilk Cc: Peter Zijlstra Cc: Philippe Ombredanne Cc: Thomas Gleixner Cc: Thymo van Beers Cc: alan@linux.intel.com Cc: linux-doc@vger.kernel.org Link: http://lkml.kernel.org/r/20181002164921.25833-1-feng.tang@intel.com Signed-off-by: Sasha Levin commit c8a1685aa3cb6209c26da50f10364a9842fe2fda Author: Zubin Mithra Date: Thu Sep 27 14:49:17 2018 -0700 apparmor: Fix uninitialized value in aa_split_fqname [ Upstream commit 250f2da49cb8e582215a65c03f50e8ddf5cd119c ] Syzkaller reported a OOB-read with the stacktrace below. This occurs inside __aa_lookupn_ns as `n` is not initialized. `n` is obtained from aa_splitn_fqname. In cases where `name` is invalid, aa_splitn_fqname returns without initializing `ns_name` and `ns_len`. Fix this by always initializing `ns_name` and `ns_len`. __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430 memcmp+0xe3/0x160 lib/string.c:861 strnstr+0x4b/0x70 lib/string.c:934 __aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209 aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240 aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468 fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844 aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908 aa_label_parse+0x42/0x50 security/apparmor/label.c:1943 aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362 apparmor_setprocattr+0xaa4/0x1150 security/apparmor/lsm.c:658 security_setprocattr+0x66/0xc0 security/security.c:1298 proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555 __vfs_write+0x119/0x9f0 fs/read_write.c:485 vfs_write+0x1fc/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 3b0aaf5866bf ("apparmor: add lib fn to find the "split" for fqnames") Reported-by: syzbot+61e4b490d9d2da591b50@syzkaller.appspotmail.com Signed-off-by: Zubin Mithra Reviewed-by: Kees Cook Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 8b9cdb75907735c5b7411a692bbd9b4a96d53830 Author: Marek Szyprowski Date: Mon Sep 24 13:01:20 2018 +0200 clk: samsung: exynos5420: Enable PERIS clocks for suspend [ Upstream commit b33228029d842269e17bba591609e83ed422005d ] Ensure that clocks for core SoC modules (including TZPC0..9 modules) are enabled for suspend/resume cycle. This fixes suspend/resume support on Exynos5422-based Odroid XU3/XU4 boards. Suggested-by: Joonyoung Shim Signed-off-by: Marek Szyprowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit 33df917736f090740e8050d19437e5029be29d00 Author: Chengguang Xu Date: Wed Jun 13 12:05:13 2018 +0800 fs/exofs: fix potential memory leak in mount option parsing [ Upstream commit 515f1867addaba49c1c6ac73abfaffbc192c1db4 ] There are some cases can cause memory leak when parsing option 'osdname'. Signed-off-by: Chengguang Xu Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit b7d1a7868cebb8cde5fe09ba41d44f8b04c990e2 Author: David Miller Date: Wed Oct 17 12:08:59 2018 -0700 perf symbols: Set PLT entry/header sizes properly on Sparc [ Upstream commit d6afa561e1471ccfdaf7191230c0c59a37e45a5b ] Using the sh_entsize for both values isn't correct. It happens to be correct on x86... For both 32-bit and 64-bit sparc, there are four PLT entries in the PLT section. Signed-off-by: David S. Miller Cc: Alexander Shishkin Cc: Alexis Berlemont Cc: David Tolnay Cc: Hanjun Guo Cc: Hemant Kumar Cc: Li Bin Cc: Masami Hiramatsu Cc: Milian Wolff Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Cc: zhangmengting@huawei.com Fixes: b2f7605076d6 ("perf symbols: Fix plt entry calculation for ARM and AARCH64") Link: http://lkml.kernel.org/r/20181017.120859.2268840244308635255.davem@davemloft.net Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 070bbd572c12bd782edcef4a0ebe2304236b0b3e Author: Alan Tull Date: Thu Oct 18 14:54:11 2018 -0500 clk: fixed-rate: fix of_node_get-put imbalance [ Upstream commit 52091c256bdcad0d01e2852a63f19cd2cce6af96 ] When the fixed rate clock is created by devicetree, of_clk_add_provider is called. Add a call to of_clk_del_provider in the remove function to balance it out. Signed-off-by: Alan Tull Fixes: 435779fe1336 ("clk: fixed-rate: Convert into a module platform driver") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c80506fa94531e6beb44658f30c0d375bce8658f Author: Rajneesh Bhardwaj Date: Sat Oct 6 12:21:13 2018 +0530 platform/x86: intel_telemetry: report debugfs failure [ Upstream commit 8d98b1ef368feeb7720b8b9b6f3bd93f2ad892bc ] On some Goldmont based systems such as ASRock J3455M the BIOS may not enable the IPC1 device that provides access to the PMC and PUNIT. In such scenarios, the IOSS and PSS resources from the platform device can not be obtained and result in a invalid telemetry_plt_config which is an internal data structure that holds platform config and is maintained by the telemetry platform driver. This is also applicable to the platforms where the BIOS supports IPC1 device under debug configurations but IPC1 is disabled by user or the policy. This change allows user to know the reason for not seeing entries under /sys/kernel/debug/telemetry/* when there is no apparent failure at boot. Cc: Matt Turner Cc: Len Brown Cc: Souvik Kumar Chakravarty Cc: Kuppuswamy Sathyanarayanan Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198779 Acked-by: Matt Turner Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 464ac699fcbfde1f99826c208de90070cd7ce68e Author: David Howells Date: Sat Oct 20 00:57:57 2018 +0100 afs: Handle EIO from delivery function [ Upstream commit 4ac15ea53622272c01954461b4814892b7481b40 ] Fix afs_deliver_to_call() to handle -EIO being returned by the operation delivery function, indicating that the call found itself in the wrong state, by printing an error and aborting the call. Currently, an assertion failure will occur. This can happen, say, if the delivery function falls off the end without calling afs_extract_data() with the want_more parameter set to false to collect the end of the Rx phase of a call. The assertion failure looks like: AFS: Assertion failed 4 == 7 is false 0x4 == 0x7 is false ------------[ cut here ]------------ kernel BUG at fs/afs/rxrpc.c:462! and is matched in the trace buffer by a line like: kworker/7:3-3226 [007] ...1 85158.030203: afs_io_error: c=0003be0c r=-5 CM_REPLY Fixes: 98bf40cd99fc ("afs: Protect call->state changes against signals") Reported-by: Marc Dionne Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 6ea95033e66f5820a78ee4d1049c5b2eff74d201 Author: Lee, Shawn C Date: Sun Oct 28 22:49:33 2018 -0700 drm/edid: Add 6 bpc quirk for BOE panel. [ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ] BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS". But it's 6bpc panel only instead of 8 bpc. Add panel ID to edid quirk list and set 6 bpc as default to work around this issue. Cc: Jani Nikula Cc: Maarten Lankhorst Cc: Gustavo Padovan Cc: Cooper Chiou Signed-off-by: Lee, Shawn C > Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c.lee@intel.com Signed-off-by: Sasha Levin commit d21e4ba36f8980006c252752b9631c12f0f103b0 Author: Richard Weinberger Date: Fri Jun 15 16:42:56 2018 +0200 um: Give start_idle_thread() a return code [ Upstream commit 7ff1e34bbdc15acab823b1ee4240e94623d50ee8 ] Fixes: arch/um/os-Linux/skas/process.c:613:1: warning: control reaches end of non-void function [-Wreturn-type] longjmp() never returns but gcc still warns that the end of the function can be reached. Add a return code and debug aid to detect this impossible case. Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 6cddd65095279b6f6045ad86624c54e2ee2701dd Author: Milian Wolff Date: Mon Oct 29 15:16:44 2018 +0100 perf unwind: Take pgoff into account when reporting elf to libdwfl [ Upstream commit 1fe627da30331024f453faef04d500079b901107 ] libdwfl parses an ELF file itself and creates mappings for the individual sections. perf on the other hand sees raw mmap events which represent individual sections. When we encounter an address pointing into a mapping with pgoff != 0, we must take that into account and report the file at the non-offset base address. This fixes unwinding with libdwfl in some cases. E.g. for a file like: ``` using namespace std; mutex g_mutex; double worker() { lock_guard guard(g_mutex); uniform_real_distribution uniform(-1E5, 1E5); default_random_engine engine; double s = 0; for (int i = 0; i < 1000; ++i) { s += norm(complex(uniform(engine), uniform(engine))); } cout << s << endl; return s; } int main() { vector> results; for (int i = 0; i < 10000; ++i) { results.push_back(async(launch::async, worker)); } return 0; } ``` Compile it with `g++ -g -O2 -lpthread cpp-locking.cpp -o cpp-locking`, then record it with `perf record --call-graph dwarf -e sched:sched_switch`. When you analyze it with `perf script` and libunwind, you should see: ``` cpp-locking 20038 [005] 54830.236589: sched:sched_switch: prev_comm=cpp-locking prev_pid=20038 prev_prio=120 prev_state=T ==> next_comm=swapper/5 next_pid=0 next_prio=120 ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1670208 schedule+0x28 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb16737cc rwsem_down_read_failed+0xec (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1665e04 call_rwsem_down_read_failed+0x14 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1672a03 down_read+0x13 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb106bd85 __do_page_fault+0x445 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb18015f5 page_fault+0x45 (/lib/modules/4.14.78-1-lts/build/vmlinux) 7f38e4252591 new_heap+0x101 (/usr/lib/libc-2.28.so) 7f38e4252d0b arena_get2.part.4+0x2fb (/usr/lib/libc-2.28.so) 7f38e4255b1c tcache_init.part.6+0xec (/usr/lib/libc-2.28.so) 7f38e42569e5 __GI___libc_malloc+0x115 (inlined) 7f38e4241790 __GI__IO_file_doallocate+0x90 (inlined) 7f38e424fbbf __GI__IO_doallocbuf+0x4f (inlined) 7f38e424ee47 __GI__IO_file_overflow+0x197 (inlined) 7f38e424df36 _IO_new_file_xsputn+0x116 (inlined) 7f38e4242bfb __GI__IO_fwrite+0xdb (inlined) 7f38e463fa6d std::basic_streambuf >::sputn(char const*, long)+0x1cd (inlined) 7f38e463fa6d std::ostreambuf_iterator >::_M_put(char const*, long)+0x1cd (inlined) 7f38e463fa6d std::ostreambuf_iterator > std::__write(std::ostreambuf_iterator >, char const*, int)+0x1cd (inlined) 7f38e463fa6d std::ostreambuf_iterator > std::num_put > >::_M_insert_float(std::ostreambuf_iterator 7f38e464bd70 std::num_put > >::put(std::ostreambuf_iterator >, std::ios_base&, char, double) const+0x90 (inl> 7f38e464bd70 std::ostream& std::ostream::_M_insert(double)+0x90 (/usr/lib/libstdc++.so.6.0.25) 563b9cb502f7 std::ostream::operator<<(double)+0xb7 (inlined) 563b9cb502f7 worker()+0xb7 (/ssd/milian/projects/kdab/rnd/hotspot/build/tests/test-clients/cpp-locking/cpp-locking) 563b9cb506fb double std::__invoke_impl(std::__invoke_other, double (*&&)())+0x2b (inlined) 563b9cb506fb std::__invoke_result::type std::__invoke(double (*&&)())+0x2b (inlined) 563b9cb506fb decltype (__invoke((_S_declval<0ul>)())) std::thread::_Invoker >::_M_invoke<0ul>(std::_Index_tuple<0ul>)+0x2b (inlined) 563b9cb506fb std::thread::_Invoker >::operator()()+0x2b (inlined) 563b9cb506fb std::__future_base::_Task_setter, std::__future_base::_Result_base::_Deleter>, std::thread::_Invoker >, dou> 563b9cb506fb std::_Function_handler (), std::__future_base::_Task_setter 563b9cb507e8 std::function ()>::operator()() const+0x28 (inlined) 563b9cb507e8 std::__future_base::_State_baseV2::_M_do_set(std::function ()>*, bool*)+0x28 (/ssd/milian/> 7f38e46d24fe __pthread_once_slow+0xbe (/usr/lib/libpthread-2.28.so) 563b9cb51149 __gthread_once+0xe9 (inlined) 563b9cb51149 void std::call_once ()>*, bool*)> 563b9cb51149 std::__future_base::_State_baseV2::_M_set_result(std::function ()>, bool)+0xe9 (inlined) 563b9cb51149 std::__future_base::_Async_state_impl >, double>::_Async_state_impl(std::thread::_Invoker >&&)::{lambda()#1}::op> 563b9cb51149 void std::__invoke_impl >, double>::_Async_state_impl(std::thread::_Invoker 563b9cb51149 std::__invoke_result >, double>::_Async_state_impl(std::thread::_Invoker >> 563b9cb51149 decltype (__invoke((_S_declval<0ul>)())) std::thread::_Invoker >, double>::_Async_state_> 563b9cb51149 std::thread::_Invoker >, double>::_Async_state_impl(std::thread::_Invoker 563b9cb51149 std::thread::_State_impl >, double>::_Async_state_impl(std::thread> 7f38e45f0062 execute_native_thread_routine+0x12 (/usr/lib/libstdc++.so.6.0.25) 7f38e46caa9c start_thread+0xfc (/usr/lib/libpthread-2.28.so) 7f38e42ccb22 __GI___clone+0x42 (inlined) ``` Before this patch, using libdwfl, you would see: ``` cpp-locking 20038 [005] 54830.236589: sched:sched_switch: prev_comm=cpp-locking prev_pid=20038 prev_prio=120 prev_state=T ==> next_comm=swapper/5 next_pid=0 next_prio=120 ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1670208 schedule+0x28 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb16737cc rwsem_down_read_failed+0xec (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1665e04 call_rwsem_down_read_failed+0x14 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1672a03 down_read+0x13 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb106bd85 __do_page_fault+0x445 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb18015f5 page_fault+0x45 (/lib/modules/4.14.78-1-lts/build/vmlinux) 7f38e4252591 new_heap+0x101 (/usr/lib/libc-2.28.so) a041161e77950c5c [unknown] ([unknown]) ``` With this patch applied, we get a bit further in unwinding: ``` cpp-locking 20038 [005] 54830.236589: sched:sched_switch: prev_comm=cpp-locking prev_pid=20038 prev_prio=120 prev_state=T ==> next_comm=swapper/5 next_pid=0 next_prio=120 ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb166fec5 __sched_text_start+0x545 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1670208 schedule+0x28 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb16737cc rwsem_down_read_failed+0xec (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1665e04 call_rwsem_down_read_failed+0x14 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb1672a03 down_read+0x13 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb106bd85 __do_page_fault+0x445 (/lib/modules/4.14.78-1-lts/build/vmlinux) ffffffffb18015f5 page_fault+0x45 (/lib/modules/4.14.78-1-lts/build/vmlinux) 7f38e4252591 new_heap+0x101 (/usr/lib/libc-2.28.so) 7f38e4252d0b arena_get2.part.4+0x2fb (/usr/lib/libc-2.28.so) 7f38e4255b1c tcache_init.part.6+0xec (/usr/lib/libc-2.28.so) 7f38e42569e5 __GI___libc_malloc+0x115 (inlined) 7f38e4241790 __GI__IO_file_doallocate+0x90 (inlined) 7f38e424fbbf __GI__IO_doallocbuf+0x4f (inlined) 7f38e424ee47 __GI__IO_file_overflow+0x197 (inlined) 7f38e424df36 _IO_new_file_xsputn+0x116 (inlined) 7f38e4242bfb __GI__IO_fwrite+0xdb (inlined) 7f38e463fa6d std::basic_streambuf >::sputn(char const*, long)+0x1cd (inlined) 7f38e463fa6d std::ostreambuf_iterator >::_M_put(char const*, long)+0x1cd (inlined) 7f38e463fa6d std::ostreambuf_iterator > std::__write(std::ostreambuf_iterator >, char const*, int)+0x1cd (inlined) 7f38e463fa6d std::ostreambuf_iterator > std::num_put > >::_M_insert_float(std::ostreambuf_iterator 7f38e464bd70 std::num_put > >::put(std::ostreambuf_iterator >, std::ios_base&, char, double) const+0x90 (inl> 7f38e464bd70 std::ostream& std::ostream::_M_insert(double)+0x90 (/usr/lib/libstdc++.so.6.0.25) 563b9cb502f7 std::ostream::operator<<(double)+0xb7 (inlined) 563b9cb502f7 worker()+0xb7 (/ssd/milian/projects/kdab/rnd/hotspot/build/tests/test-clients/cpp-locking/cpp-locking) 6eab825c1ee3e4ff [unknown] ([unknown]) ``` Note that the backtrace is still stopping too early, when compared to the nice results obtained via libunwind. It's unclear so far what the reason for that is. Committer note: Further comment by Milian on the thread started on the Link: tag below: --- The remaining issue is due to a bug in elfutils: https://sourceware.org/ml/elfutils-devel/2018-q4/msg00089.html With both patches applied, libunwind and elfutils produce the same output for the above scenario. --- Signed-off-by: Milian Wolff Acked-by: Jiri Olsa Link: http://lkml.kernel.org/r/20181029141644.3907-1-milian.wolff@kdab.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 52fc49b6ae578c6cd07920b29826503f75007eaf Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:00 2018 -0700 hfsplus: prevent btree data loss on root split [ Upstream commit 0a3021d4f5295aa073c7bf5c5e4de60a2e292578 ] Creating, renaming or deleting a file may cause catalog corruption and data loss. This bug is randomly triggered by xfstests generic/027, but here is a faster reproducer: truncate -s 50M fs.iso mkfs.hfsplus fs.iso mount fs.iso /mnt i=100 while [ $i -le 150 ]; do touch /mnt/$i &>/dev/null ((++i)) done i=100 while [ $i -le 150 ]; do mv /mnt/$i /mnt/$(perl -e "print $i x82") &>/dev/null ((++i)) done umount /mnt fsck.hfsplus -n fs.iso The bug is triggered whenever hfs_brec_update_parent() needs to split the root node. The height of the btree is not increased, which leaves the new node orphaned and its records lost. Link: http://lkml.kernel.org/r/26d882184fc43043a810114258f45277752186c7.1535682461.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ea54dce2062cbba2a6a7e3dcac51db6637343c7b Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:07 2018 -0700 hfs: prevent btree data loss on root split [ Upstream commit d057c036672f33d43a5f7344acbb08cf3a8a0c09 ] This bug is triggered whenever hfs_brec_update_parent() needs to split the root node. The height of the btree is not increased, which leaves the new node orphaned and its records lost. It is not possible for this to happen on a valid hfs filesystem because the index nodes have fixed length keys. For reasons I ignore, the hfs module does have support for a number of hfsplus features. A corrupt btree header may report variable length keys and trigger this bug, so it's better to fix it. Link: http://lkml.kernel.org/r/9750b1415685c4adca10766895f6d5ef12babdb0.1535682463.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ee38053fcf5d401e8b5c05bd6a40b687a875f02a Author: Jann Horn Date: Tue Oct 30 15:06:38 2018 -0700 reiserfs: propagate errors from fill_with_dentries() properly [ Upstream commit b10298d56c9623f9b173f19959732d3184b35f4f ] fill_with_dentries() failed to propagate errors up to reiserfs_for_each_xattr() properly. Plumb them through. Note that reiserfs_for_each_xattr() is only used by reiserfs_delete_xattrs() and reiserfs_chown_xattrs(). The result of reiserfs_delete_xattrs() is discarded anyway, the only difference there is whether a warning is printed to dmesg. The result of reiserfs_chown_xattrs() does matter because it can block chowning of the file to which the xattrs belong; but either way, the resulting state can have misaligned ownership, so my patch doesn't improve things greatly. Credit for making me look at this code goes to Al Viro, who pointed out that the ->actor calling convention is suboptimal and should be changed. Link: http://lkml.kernel.org/r/20180802163335.83312-1-jannh@google.com Signed-off-by: Jann Horn Reviewed-by: Andrew Morton Cc: Jeff Mahoney Cc: Eric Biggers Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 23ce028f4564d1ce2df1fc6f99d9fcad5beaa51b Author: Radoslaw Tyl Date: Mon Oct 22 08:44:31 2018 +0200 ixgbe: fix MAC anti-spoofing filter after VFLR [ Upstream commit 6702185c1ffec3421181b5e24491e3fac920cb61 ] This change resolves a driver bug where the driver is logging a message that says "Spoofed packets detected". This can occur on the PF (host) when a VF has VLAN+MACVLAN enabled and is re-started with a different MAC address. MAC and VLAN anti-spoofing filters are to be enabled together. Signed-off-by: Radoslaw Tyl Tested-by: Andrew Bowers Acked-by: Piotr Skajewski Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 91a52a44195e205aaf8a275621bf8fa9cc082b02 Author: Huazhong Tan Date: Tue Oct 30 21:50:46 2018 +0800 net: hns3: bugfix for the initialization of command queue's spin lock [ Upstream commit b2f74dbaf12bf59ff35d451005b3cdee78232ff0 ] The spin lock of the command queue only need to be initialized once when the driver initializes the command queue. It is not necessary to initialize the spin lock when resetting. At the same time, the modification of the queue member should be performed after acquiring the lock. Fixes: 3efb960f056d ("net: hns3: Refactor the initialization of command queue") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 355ec07561044fadd1edc071315105cbdf9f79bf Author: Huazhong Tan Date: Tue Oct 30 21:50:51 2018 +0800 net: hns3: bugfix for handling mailbox while the command queue reinitialized [ Upstream commit 3c88ed1d798da355859ca083d3884a16ce0841f2 ] In a multi-core machine, the mailbox service and reset service will be executed at the same time. The reset service will re-initialize the command queue, before that, the mailbox handler can only get some invalid messages. The HCLGE_STATE_CMD_DISABLE flag means that the command queue is not available and needs to be reinitialized. Therefore, when the mailbox handler recognizes this flag, it should not process the command. Fixes: dde1a86e93ca ("net: hns3: Add mailbox support to PF driver") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 92cb1b096a08723daaf78d5c202c53b11bb282b9 Author: Huazhong Tan Date: Tue Oct 30 21:50:52 2018 +0800 net: hns3: bugfix for rtnl_lock's range in the hclge_reset() [ Upstream commit a963052e539887df481d4d3a6ad4c92ca6461852 ] Since hclge_reset_wait() is used to wait for the hardware to complete the reset, it is not necessary to hold the rtnl_lock during hclge_reset_wait(). So this patch releases the lock for the duration of hclge_reset_wait(). Fixes: 6d4fab39533f ("net: hns3: Reset net device with rtnl_lock") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 733edfd69e092cdabf5e26a41c157662e24279c0 Author: Huazhong Tan Date: Tue Oct 30 21:50:53 2018 +0800 net: hns3: bugfix for rtnl_lock's range in the hclgevf_reset() [ Upstream commit 29118ab962d5476fdc65fae312ac38db68092d78 ] Since hclgevf_reset_wait() is used to wait for the hardware to complete the reset, it is not necessary to hold the rtnl_lock during hclgevf_reset_wait(). So this patch releases the lock for the duration of hclgevf_reset_wait(). Fixes: 6988eb2a9b77 ("net: hns3: Add support to reset the enet/ring mgmt layer") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0987d5a67bc726e99136f623b09ae9e207f50e16 Author: Ming Lei Date: Fri Nov 2 08:50:51 2018 +0800 block: brd: associate with queue until adding disk [ Upstream commit 153fcd5f6d93b8e1e4040b1337f564a10f8d93af ] brd_free() may be called in failure path on one brd instance which disk isn't added yet, so release handler of gendisk may free the associated request_queue early and causes the following use-after-free[1]. This patch fixes this issue by associating gendisk with request_queue just before adding disk. [1] KASAN: use-after-free Read in del_timer_syncNon-volatile memory driver v1.3 Linux agpgart interface v0.103 [drm] Initialized vgem 1.0.0 20120112 for virtual device on minor 0 usbcore: registered new interface driver udl ================================================================== BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 Read of size 8 at addr ffff8801d1b6b540 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.0+ #88 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 del_timer_sync+0xb7/0x270 kernel/time/timer.c:1283 blk_cleanup_queue+0x413/0x710 block/blk-core.c:809 brd_free+0x5d/0x71 drivers/block/brd.c:422 brd_init+0x2eb/0x393 drivers/block/brd.c:518 do_one_initcall+0x145/0x957 init/main.c:890 do_initcall_level init/main.c:958 [inline] do_initcalls init/main.c:966 [inline] do_basic_setup init/main.c:984 [inline] kernel_init_freeable+0x5c6/0x6b9 init/main.c:1148 kernel_init+0x11/0x1ae init/main.c:1068 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:350 Reported-by: syzbot+3701447012fe951dabb2@syzkaller.appspotmail.com Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 262522ccef74e5f1a74f9f5591834f2a97a458fd Author: Anders Roxell Date: Tue Oct 30 12:38:50 2018 +0100 arm64: kprobe: make page to RO mode when allocate it [ Upstream commit 966866892cf89d606544bca22d584ba2ef9ec208 ] Commit 1404d6f13e47 ("arm64: dump: Add checking for writable and exectuable pages") has successfully identified code that leaves a page with W+X permissions. [ 3.245140] arm64/mm: Found insecure W+X mapping at address (____ptrval____)/0xffff000000d90000 [ 3.245771] WARNING: CPU: 0 PID: 1 at ../arch/arm64/mm/dump.c:232 note_page+0x410/0x420 [ 3.246141] Modules linked in: [ 3.246653] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc5-next-20180928-00001-ge70ae259b853-dirty #62 [ 3.247008] Hardware name: linux,dummy-virt (DT) [ 3.247347] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 3.247623] pc : note_page+0x410/0x420 [ 3.247898] lr : note_page+0x410/0x420 [ 3.248071] sp : ffff00000804bcd0 [ 3.248254] x29: ffff00000804bcd0 x28: ffff000009274000 [ 3.248578] x27: ffff00000921a000 x26: ffff80007dfff000 [ 3.248845] x25: ffff0000093f5000 x24: ffff000009526f6a [ 3.249109] x23: 0000000000000004 x22: ffff000000d91000 [ 3.249396] x21: ffff000000d90000 x20: 0000000000000000 [ 3.249661] x19: ffff00000804bde8 x18: 0000000000000400 [ 3.249924] x17: 0000000000000000 x16: 0000000000000000 [ 3.250271] x15: ffffffffffffffff x14: 295f5f5f5f6c6176 [ 3.250594] x13: 7274705f5f5f5f28 x12: 2073736572646461 [ 3.250941] x11: 20746120676e6970 x10: 70616d20582b5720 [ 3.251252] x9 : 6572756365736e69 x8 : 3039643030303030 [ 3.251519] x7 : 306666666678302f x6 : ffff0000095467b2 [ 3.251802] x5 : 0000000000000000 x4 : 0000000000000000 [ 3.252060] x3 : 0000000000000000 x2 : ffffffffffffffff [ 3.252323] x1 : 4d151327adc50b00 x0 : 0000000000000000 [ 3.252664] Call trace: [ 3.252953] note_page+0x410/0x420 [ 3.253186] walk_pgd+0x12c/0x238 [ 3.253417] ptdump_check_wx+0x68/0xf8 [ 3.253637] mark_rodata_ro+0x68/0x98 [ 3.253847] kernel_init+0x38/0x160 [ 3.254103] ret_from_fork+0x10/0x18 kprobes allocates a writable executable page with module_alloc() in order to store executable code. Reworked to that when allocate a page it sets mode RO. Inspired by commit 63fef14fc98a ("kprobes/x86: Make insn buffer always ROX and use text_poke()"). Suggested-by: Arnd Bergmann Suggested-by: Ard Biesheuvel Acked-by: Will Deacon Acked-by: Masami Hiramatsu Reviewed-by: Laura Abbott Signed-off-by: Anders Roxell [catalin.marinas@arm.com: removed unnecessary casts] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit e4ed4e68c6d8aba1e4cd63979e7ac7f42075e21a Author: Ronnie Sahlberg Date: Thu Oct 25 15:43:36 2018 +1000 cifs: fix return value for cifs_listxattr [ Upstream commit 0c5d6cb6643f48ad3775322f3ebab6c7eb67484e ] If the application buffer was too small to fit all the names we would still count the number of bytes and return this for listxattr. This would then trigger a BUG in usercopy.c Fix the computation of the size so that we return -ERANGE correctly when the buffer is too small. This fixes the kernel BUG for xfstest generic/377 Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Signed-off-by: Sasha Levin commit ad1834fd8a479f499918107e1f97591eb0a4b39f Author: Colin Ian King Date: Thu Nov 1 13:14:30 2018 +0000 cifs: don't dereference smb_file_target before null check [ Upstream commit 8c6c9bed8773375b1d54ccca2911ec892c59db5d ] There is a null check on dst_file->private data which suggests it can be potentially null. However, before this check, pointer smb_file_target is derived from dst_file->private and dereferenced in the call to tlink_tcon, hence there is a potential null pointer deference. Fix this by assigning smb_file_target and target_tcon after the null pointer sanity checks. Detected by CoverityScan, CID#1475302 ("Dereference before null check") Fixes: 04b38d601239 ("vfs: pull btrfs clone API to vfs layer") Signed-off-by: Colin Ian King Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 1beb22c52484f8e4047af142ee70e1b357d561c9 Author: Ville Syrjälä Date: Thu Sep 13 18:04:05 2018 +0300 drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE commit f6e35cda66146106cfeb85ed65696e0f8e793fee upstream. Use I915_GTT_PAGE_SIZE when talking about GTT pages rather than physical pages. There are some PAGE_SHIFTs left though. Not sure if we want to introduce I915_GTT_PAGE_SHIFT or what? Cc: Chris Wilson Suggested-by: Chris Wilson # at least some of it :) Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180913150405.706-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman