commit 9c07fc259396fb5a26713755f92f60eb477ed567 Author: Greg Kroah-Hartman Date: Sun Jan 13 10:01:07 2019 +0100 Linux 4.14.93 commit 59ed81e1eede2cb90010ee923c853a58535aff85 Author: Jiri Slaby Date: Tue Apr 24 09:43:44 2018 +0200 tools: power/acpi, revert to LD = gcc commit 755396163148b50fe1afb4bdd3365e47f3ff7a42 upstream. Commit 7ed1c1901fe5 (tools: fix cross-compile var clobbering) removed setting of LD to $(CROSS_COMPILE)gcc. This broke build of acpica (acpidump) in power/acpi: ld: unrecognized option '-D_LINUX' The tools pass CFLAGS to the linker (incl. -D_LINUX), so revert this particular change and let LD be $(CC) again. Note that the old behaviour was a bit different, it used $(CROSS_COMPILE)gcc which was eliminated by the commit 7ed1c1901fe5. We use $(CC) for that reason. Fixes: 7ed1c1901fe5 (tools: fix cross-compile var clobbering) Signed-off-by: Jiri Slaby Cc: 4.16+ # 4.16+ Signed-off-by: Rafael J. Wysocki Cc: Sudip Mukherjee Cc: Martin Kelly Signed-off-by: Greg Kroah-Hartman commit b018b00c39767e4ddc4d802471eda46abcb9c87b Author: Ivan Mironov Date: Mon Dec 24 20:13:05 2018 +0500 bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw commit 38355a5f9a22bfa5bd5b1bb79805aca39fa53729 upstream. This happened when I tried to boot normal Fedora 29 system with latest available kernel (from fedora rawhide, plus some unrelated custom patches): BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP PTI CPU: 6 PID: 1422 Comm: libvirtd Tainted: G I 4.20.0-0.rc7.git3.hpsa2.1.fc29.x86_64 #1 Hardware name: HP ProLiant BL460c G6, BIOS I24 05/21/2018 RIP: 0010: (null) Code: Bad RIP value. RSP: 0018:ffffa47ccdc9fbe0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000003e8 RCX: ffffa47ccdc9fbf8 RDX: ffffa47ccdc9fc00 RSI: ffff97d9ee7b01f8 RDI: ffff97d9f0150b80 RBP: ffff97d9f0150b80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff97d9ef1e53e8 R14: 0000000000000009 R15: ffff97d9f0ac6730 FS: 00007f4d224ef700(0000) GS:ffff97d9fa200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000011ece52006 CR4: 00000000000206e0 Call Trace: ? bnx2x_chip_cleanup+0x195/0x610 [bnx2x] ? bnx2x_nic_unload+0x1e2/0x8f0 [bnx2x] ? bnx2x_reload_if_running+0x24/0x40 [bnx2x] ? bnx2x_set_features+0x79/0xa0 [bnx2x] ? __netdev_update_features+0x244/0x9e0 ? netlink_broadcast_filtered+0x136/0x4b0 ? netdev_update_features+0x22/0x60 ? dev_disable_lro+0x1c/0xe0 ? devinet_sysctl_forward+0x1c6/0x211 ? proc_sys_call_handler+0xab/0x100 ? __vfs_write+0x36/0x1a0 ? rcu_read_lock_sched_held+0x79/0x80 ? rcu_sync_lockdep_assert+0x2e/0x60 ? __sb_start_write+0x14c/0x1b0 ? vfs_write+0x159/0x1c0 ? vfs_write+0xba/0x1c0 ? ksys_write+0x52/0xc0 ? do_syscall_64+0x60/0x1f0 ? entry_SYSCALL_64_after_hwframe+0x49/0xbe After some investigation I figured out that recently added cleanup code tries to call VLAN filtering de-initialization function which exist only for newer hardware. Corresponding function pointer is not set (== 0) for older hardware, namely these chips: #define CHIP_NUM_57710 0x164e #define CHIP_NUM_57711 0x164f #define CHIP_NUM_57711E 0x1650 And I have one of those in my test system: Broadcom Inc. and subsidiaries NetXtreme II BCM57711E 10-Gigabit PCIe [14e4:1650] Function bnx2x_init_vlan_mac_fp_objs() from drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h decides whether to initialize relevant pointers in bnx2x_sp_objs.vlan_obj or not. This regression was introduced after v4.20-rc7, and still exists in v4.20 release. Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload sequence.") Signed-off-by: Ivan Mironov Signed-off-by: Ivan Mironov Acked-by: Sudarsana Kalluru Signed-off-by: David S. Miller Cc: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit e956139f32412160616d52f5f630da68a40e4c47 Author: Boris Brezillon Date: Tue Oct 9 15:24:46 2018 +0200 drm/vc4: Set ->is_yuv to false when num_planes == 1 commit 2b02a05bdc3a62d36e0d0b015351897109e25991 upstream. When vc4_plane_state is duplicated ->is_yuv is left assigned to its previous value, and we never set it back to false when switching to a non-YUV format. Fix that by setting ->is_yuv to false in the 'num_planes == 1' branch of the vc4_plane_setup_clipping_and_scaling() function. Fixes: fc04023fafecf ("drm/vc4: Add support for YUV planes.") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20181009132446.21960-1-boris.brezillon@bootlin.com Signed-off-by: Greg Kroah-Hartman commit ff420ff182322f5f81925a0de7081b28a0c2d5af Author: Christophe Leroy Date: Mon Dec 10 08:08:28 2018 +0000 lib: fix build failure in CONFIG_DEBUG_VIRTUAL test commit 10fdf838e5f540beca466e9d1325999c072e5d3f upstream. On several arches, virt_to_phys() is in io.h Build fails without it: CC lib/test_debug_virtual.o lib/test_debug_virtual.c: In function 'test_debug_virtual_init': lib/test_debug_virtual.c:26:7: error: implicit declaration of function 'virt_to_phys' [-Werror=implicit-function-declaration] pa = virt_to_phys(va); ^ Fixes: e4dace361552 ("lib: add test module for CONFIG_DEBUG_VIRTUAL") CC: stable@vger.kernel.org Signed-off-by: Christophe Leroy Reviewed-by: Kees Cook Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 8936b67c81e14e7f8a63f3ebd3e3a29c1dddfed8 Author: Lubomir Rintel Date: Fri Nov 16 17:23:47 2018 +0100 power: supply: olpc_battery: correct the temperature units commit ed54ffbe554f0902689fd6d1712bbacbacd11376 upstream. According to [1] and [2], the temperature values are in tenths of degree Celsius. Exposing the Celsius value makes the battery appear on fire: $ upower -i /org/freedesktop/UPower/devices/battery_olpc_battery ... temperature: 236.9 degrees C Tested on OLPC XO-1 and OLPC XO-1.75 laptops. [1] include/linux/power_supply.h [2] Documentation/power/power_supply_class.txt Fixes: fb972873a767 ("[BATTERY] One Laptop Per Child power/battery driver") Cc: stable@vger.kernel.org Signed-off-by: Lubomir Rintel Acked-by: Pavel Machek Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 6293890419baea40d95b71beb671ab472c93e2c9 Author: Alexander Shishkin Date: Wed Dec 19 17:19:22 2018 +0200 intel_th: msu: Fix an off-by-one in attribute store commit ec5b5ad6e272d8d6b92d1007f79574919862a2d2 upstream. The 'nr_pages' attribute of the 'msc' subdevices parses a comma-separated list of window sizes, passed from userspace. However, there is a bug in the string parsing logic wherein it doesn't exclude the comma character from the range of characters as it consumes them. This leads to an out-of-bounds access given a sufficiently long list. For example: > # echo 8,8,8,8 > /sys/bus/intel_th/devices/0-msc0/nr_pages > ================================================================== > BUG: KASAN: slab-out-of-bounds in memchr+0x1e/0x40 > Read of size 1 at addr ffff8803ffcebcd1 by task sh/825 > > CPU: 3 PID: 825 Comm: npktest.sh Tainted: G W 4.20.0-rc1+ > Call Trace: > dump_stack+0x7c/0xc0 > print_address_description+0x6c/0x23c > ? memchr+0x1e/0x40 > kasan_report.cold.5+0x241/0x308 > memchr+0x1e/0x40 > nr_pages_store+0x203/0xd00 [intel_th_msu] Fix this by accounting for the comma character. Signed-off-by: Alexander Shishkin Fixes: ba82664c134ef ("intel_th: Add Memory Storage Unit driver") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Greg Kroah-Hartman commit a1fe71105652b463bf551b9e525e0d6d12f0c2f5 Author: Christian Borntraeger Date: Wed Dec 12 14:45:18 2018 +0100 genwqe: Fix size check commit fdd669684655c07dacbdb0d753fd13833de69a33 upstream. Calling the test program genwqe_cksum with the default buffer size of 2MB triggers the following kernel warning on s390: WARNING: CPU: 30 PID: 9311 at mm/page_alloc.c:3189 __alloc_pages_nodemask+0x45c/0xbe0 CPU: 30 PID: 9311 Comm: genwqe_cksum Kdump: loaded Not tainted 3.10.0-957.el7.s390x #1 task: 00000005e5d13980 ti: 00000005e7c6c000 task.ti: 00000005e7c6c000 Krnl PSW : 0704c00180000000 00000000002780ac (__alloc_pages_nodemask+0x45c/0xbe0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3 Krnl GPRS: 00000000002932b8 0000000000b73d7c 0000000000000010 0000000000000009 0000000000000041 00000005e7c6f9b8 0000000000000001 00000000000080d0 0000000000000000 0000000000b70500 0000000000000001 0000000000000000 0000000000b70528 00000000007682c0 0000000000277df2 00000005e7c6f9a0 Krnl Code: 000000000027809e: de7195001000 ed 1280(114,%r9),0(%r1) 00000000002780a4: a774fead brc 7,277dfe #00000000002780a8: a7f40001 brc 15,2780aa >00000000002780ac: 92011000 mvi 0(%r1),1 00000000002780b0: a7f4fea7 brc 15,277dfe 00000000002780b4: 9101c6b6 tm 1718(%r12),1 00000000002780b8: a784ff3a brc 8,277f2c 00000000002780bc: a7f4fe2e brc 15,277d18 Call Trace: ([<0000000000277df2>] __alloc_pages_nodemask+0x1a2/0xbe0) [<000000000013afae>] s390_dma_alloc+0xfe/0x310 [<000003ff8065f362>] __genwqe_alloc_consistent+0xfa/0x148 [genwqe_card] [<000003ff80658f7a>] genwqe_mmap+0xca/0x248 [genwqe_card] [<00000000002b2712>] mmap_region+0x4e2/0x778 [<00000000002b2c54>] do_mmap+0x2ac/0x3e0 [<0000000000292d7e>] vm_mmap_pgoff+0xd6/0x118 [<00000000002b081c>] SyS_mmap_pgoff+0xdc/0x268 [<00000000002b0a34>] SyS_old_mmap+0x8c/0xb0 [<000000000074e518>] sysc_tracego+0x14/0x1e [<000003ffacf87dc6>] 0x3ffacf87dc6 turns out the check in __genwqe_alloc_consistent uses "> MAX_ORDER" while the mm code uses ">= MAX_ORDER". Fix genwqe. Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Signed-off-by: Frank Haverkamp Signed-off-by: Greg Kroah-Hartman commit 7983d29437b99e1e9786e2621f297aa6cd6bf3ba Author: Yan, Zheng Date: Thu Nov 29 11:22:50 2018 +0800 ceph: don't update importing cap's mseq when handing cap export commit 3c1392d4c49962a31874af14ae9ff289cb2b3851 upstream. Updating mseq makes client think importer mds has accepted all prior cap messages and importer mds knows what caps client wants. Actually some cap messages may have been dropped because of mseq mismatch. If mseq is left untouched, importing cap's mds_wanted later will get reset by cap import message. Cc: stable@vger.kernel.org Signed-off-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit c6a9a1ccafc49fe95d8de54eef154ad5c3b94077 Author: Linus Torvalds Date: Thu Dec 27 13:46:17 2018 -0800 sched/fair: Fix infinite loop in update_blocked_averages() by reverting a9e7f6544b9c commit c40f7d74c741a907cfaeb73a7697081881c497d0 upstream. Zhipeng Xie, Xie XiuQi and Sargun Dhillon reported lockups in the scheduler under high loads, starting at around the v4.18 time frame, and Zhipeng Xie tracked it down to bugs in the rq->leaf_cfs_rq_list manipulation. Do a (manual) revert of: a9e7f6544b9c ("sched/fair: Fix O(nr_cgroups) in load balance path") It turns out that the list_del_leaf_cfs_rq() introduced by this commit is a surprising property that was not considered in followup commits such as: 9c2791f936ef ("sched/fair: Fix hierarchical order in rq->leaf_cfs_rq_list") As Vincent Guittot explains: "I think that there is a bigger problem with commit a9e7f6544b9c and cfs_rq throttling: Let take the example of the following topology TG2 --> TG1 --> root: 1) The 1st time a task is enqueued, we will add TG2 cfs_rq then TG1 cfs_rq to leaf_cfs_rq_list and we are sure to do the whole branch in one path because it has never been used and can't be throttled so tmp_alone_branch will point to leaf_cfs_rq_list at the end. 2) Then TG1 is throttled 3) and we add TG3 as a new child of TG1. 4) The 1st enqueue of a task on TG3 will add TG3 cfs_rq just before TG1 cfs_rq and tmp_alone_branch will stay on rq->leaf_cfs_rq_list. With commit a9e7f6544b9c, we can del a cfs_rq from rq->leaf_cfs_rq_list. So if the load of TG1 cfs_rq becomes NULL before step 2) above, TG1 cfs_rq is removed from the list. Then at step 4), TG3 cfs_rq is added at the beginning of rq->leaf_cfs_rq_list but tmp_alone_branch still points to TG3 cfs_rq because its throttled parent can't be enqueued when the lock is released. tmp_alone_branch doesn't point to rq->leaf_cfs_rq_list whereas it should. So if TG3 cfs_rq is removed or destroyed before tmp_alone_branch points on another TG cfs_rq, the next TG cfs_rq that will be added, will be linked outside rq->leaf_cfs_rq_list - which is bad. In addition, we can break the ordering of the cfs_rq in rq->leaf_cfs_rq_list but this ordering is used to update and propagate the update from leaf down to root." Instead of trying to work through all these cases and trying to reproduce the very high loads that produced the lockup to begin with, simplify the code temporarily by reverting a9e7f6544b9c - which change was clearly not thought through completely. This (hopefully) gives us a kernel that doesn't lock up so people can continue to enjoy their holidays without worrying about regressions. ;-) [ mingo: Wrote changelog, fixed weird spelling in code comment while at it. ] Analyzed-by: Xie XiuQi Analyzed-by: Vincent Guittot Reported-by: Zhipeng Xie Reported-by: Sargun Dhillon Reported-by: Xie XiuQi Tested-by: Zhipeng Xie Tested-by: Sargun Dhillon Signed-off-by: Linus Torvalds Acked-by: Vincent Guittot Cc: # v4.13+ Cc: Bin Li Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Tejun Heo Cc: Thomas Gleixner Fixes: a9e7f6544b9c ("sched/fair: Fix O(nr_cgroups) in load balance path") Link: http://lkml.kernel.org/r/1545879866-27809-1-git-send-email-xiexiuqi@huawei.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit d59964607842725de662d112c125ec8223a82a20 Author: Sohil Mehta Date: Wed Nov 21 15:29:33 2018 -0800 iommu/vt-d: Handle domain agaw being less than iommu agaw commit 3569dd07aaad71920c5ea4da2d5cc9a167c1ffd4 upstream. The Intel IOMMU driver opportunistically skips a few top level page tables from the domain paging directory while programming the IOMMU context entry. However there is an implicit assumption in the code that domain's adjusted guest address width (agaw) would always be greater than IOMMU's agaw. The IOMMU capabilities in an upcoming platform cause the domain's agaw to be lower than IOMMU's agaw. The issue is seen when the IOMMU supports both 4-level and 5-level paging. The domain builds a 4-level page table based on agaw of 2. However the IOMMU's agaw is set as 3 (5-level). In this case the code incorrectly tries to skip page page table levels. This causes the IOMMU driver to avoid programming the context entry. The fix handles this case and programs the context entry accordingly. Fixes: de24e55395698 ("iommu/vt-d: Simplify domain_context_mapping_one") Cc: Cc: Ashok Raj Cc: Jacob Pan Cc: Lu Baolu Reviewed-by: Lu Baolu Reported-by: Ramos Falcon, Ernesto R Tested-by: Ricardo Neri Signed-off-by: Sohil Mehta Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 2063fe0ec52344dc9b784735a58afbb97c29dcae Author: Sagi Grimberg Date: Thu Oct 25 12:40:57 2018 -0700 rxe: fix error completion wr_id and qp_num commit e48d8ed9c6193502d849b35767fd18e20bbd7ba2 upstream. Error completions must still contain a valid wr_id and qp_num such that the consumer can rely on. Correctly fill these fields in receive error completions. Reported-by: Walker Benjamin Cc: stable@vger.kernel.org Signed-off-by: Sagi Grimberg Reviewed-by: Zhu Yanjun Tested-by: Zhu Yanjun Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 186213114b74bd52f5014e2877c3a6d72299762a Author: Dominique Martinet Date: Mon Nov 5 09:52:48 2018 +0100 9p/net: put a lower bound on msize commit 574d356b7a02c7e1b01a1d9cba8a26b3c2888f45 upstream. If the requested msize is too small (either from command line argument or from the server version reply), we won't get any work done. If it's *really* too small, nothing will work, and this got caught by syzbot recently (on a new kmem_cache_create_usercopy() call) Just set a minimum msize to 4k in both code paths, until someone complains they have a use-case for a smaller msize. We need to check in both mount option and server reply individually because the msize for the first version request would be unchecked with just a global check on clnt->msize. Link: http://lkml.kernel.org/r/1541407968-31350-1-git-send-email-asmadeus@codewreck.org Reported-by: syzbot+0c1d61e4db7db94102ca@syzkaller.appspotmail.com Signed-off-by: Dominique Martinet Cc: Eric Van Hensbergen Cc: Latchesar Ionkov Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b57b508bdcfd365b63e04ec6d9152e045e1cd476 Author: Breno Leitao Date: Wed Nov 21 17:21:09 2018 -0200 powerpc/tm: Set MSR[TS] just prior to recheckpoint commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream. On a signal handler return, the user could set a context with MSR[TS] bits set, and these bits would be copied to task regs->msr. At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set, several __get_user() are called and then a recheckpoint is executed. This is a problem since a page fault (in kernel space) could happen when calling __get_user(). If it happens, the process MSR[TS] bits were already set, but recheckpoint was not executed, and SPRs are still invalid. The page fault can cause the current process to be de-scheduled, with MSR[TS] active and without tm_recheckpoint() being called. More importantly, without TEXASR[FS] bit set also. Since TEXASR might not have the FS bit set, and when the process is scheduled back, it will try to reclaim, which will be aborted because of the CPU is not in the suspended state, and, then, recheckpoint. This recheckpoint will restore thread->texasr into TEXASR SPR, which might be zero, hitting a BUG_ON(). kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434! cpu 0xb: Vector: 700 (Program Check) at [c00000041f1576d0] pc: c000000000054550: restore_gprs+0xb0/0x180 lr: 0000000000000000 sp: c00000041f157950 msr: 8000000100021033 current = 0xc00000041f143000 paca = 0xc00000000fb86300 softe: 0 irq_happened: 0x01 pid = 1021, comm = kworker/11:1 kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434! Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) enter ? for help [c00000041f157b30] c00000000001bc3c tm_recheckpoint.part.11+0x6c/0xa0 [c00000041f157b70] c00000000001d184 __switch_to+0x1e4/0x4c0 [c00000041f157bd0] c00000000082eeb8 __schedule+0x2f8/0x990 [c00000041f157cb0] c00000000082f598 schedule+0x48/0xc0 [c00000041f157ce0] c0000000000f0d28 worker_thread+0x148/0x610 [c00000041f157d80] c0000000000f96b0 kthread+0x120/0x140 [c00000041f157e30] c00000000000c0e0 ret_from_kernel_thread+0x5c/0x7c This patch simply delays the MSR[TS] set, so, if there is any page fault in the __get_user() section, it does not have regs->msr[TS] set, since the TM structures are still invalid, thus avoiding doing TM operations for in-kernel exceptions and possible process reschedule. With this patch, the MSR[TS] will only be set just before recheckpointing and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in invalid state. Other than that, if CONFIG_PREEMPT is set, there might be a preemption just after setting MSR[TS] and before tm_recheckpoint(), thus, this block must be atomic from a preemption perspective, thus, calling preempt_disable/enable() on this code. It is not possible to move tm_recheckpoint to happen earlier, because it is required to get the checkpointed registers from userspace, with __get_user(), thus, the only way to avoid this undesired behavior is delaying the MSR[TS] set. The 32-bits signal handler seems to be safe this current issue, but, it might be exposed to the preemption issue, thus, disabling preemption in this chunk of code. Changes from v2: * Run the critical section with preempt_disable. Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals") Cc: stable@vger.kernel.org (v3.9+) Signed-off-by: Breno Leitao Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f21ce3cdff2f2be72fd85efab90785307384eed6 Author: Ard Biesheuvel Date: Mon Dec 3 20:58:05 2018 +0100 arm64: relocatable: fix inconsistencies in linker script and options commit 3bbd3db86470c701091fb1d67f1fab6621debf50 upstream. readelf complains about the section layout of vmlinux when building with CONFIG_RELOCATABLE=y (for KASLR): readelf: Warning: [21]: Link field (0) should index a symtab section. readelf: Warning: [21]: Info field (0) should index a relocatable section. Also, it seems that our use of '-pie -shared' is contradictory, and thus ambiguous. In general, the way KASLR is wired up at the moment is highly tailored to how ld.bfd happens to implement (and conflate) PIE executables and shared libraries, so given the current effort to support other toolchains, let's fix some of these issues as well. - Drop the -pie linker argument and just leave -shared. In ld.bfd, the differences between them are unclear (except for the ELF type of the produced image [0]) but lld chokes on seeing both at the same time. - Rename the .rela output section to .rela.dyn, as is customary for shared libraries and PIE executables, so that it is not misidentified by readelf as a static relocation section (producing the warnings above). - Pass the -z notext and -z norelro options to explicitly instruct the linker to permit text relocations, and to omit the RELRO program header (which requires a certain section layout that we don't adhere to in the kernel). These are the defaults for current versions of ld.bfd. - Discard .eh_frame and .gnu.hash sections to avoid them from being emitted between .head.text and .text, screwing up the section layout. These changes only affect the ELF image, and produce the same binary image. [0] b9dce7f1ba01 ("arm64: kernel: force ET_DYN ELF type for ...") Cc: Nick Desaulniers Cc: Peter Smith Tested-by: Nick Desaulniers Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit b3424be0753e229112d6c4ef266737f10e958b5e Author: Ard Biesheuvel Date: Tue Jan 8 13:15:49 2019 -0800 arm64: drop linker script hack to hide __efistub_ symbols commit dd6846d774693bfa27d7db4dae5ea67dfe373fa1 upstream. Commit 1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_ symbols") updated the kallsyms code to filter out symbols with the __efistub_ prefix explicitly, so we no longer require the hack in our linker script to emit them as absolute symbols. Cc: Nick Desaulniers Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon [ND: adjusted for context] Signed-off-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman commit 28493b4147ea3f982e9cff269dc068ac0a98be74 Author: Ard Biesheuvel Date: Thu Mar 1 17:19:01 2018 +0000 scripts/kallsyms: filter arm64's __efistub_ symbols commit 1212f7a16af492d59304ba3abccbcc5b5e41423e upstream. On arm64, the EFI stub and the kernel proper are essentially the same binary, although the EFI stub executes at a different virtual address as the kernel. For this reason, the EFI stub is restricted in the symbols it can link to, which is ensured by prefixing all EFI stub symbols with __efistub_ (and emitting __efistub_ prefixed aliases for routines that may be shared between the core kernel and the stub) These symbols are leaking into kallsyms, polluting the namespace, so let's filter them explicitly. Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon Cc: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman commit 01b79d20008d26d9e908551bd32f01ed0cbf6f53 Author: Benjamin Coddington Date: Thu Nov 1 13:39:49 2018 -0400 lockd: Show pid of lockd for remote locks commit b8eee0e90f9797b747113638bc75e739b192ad38 upstream. Commit 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific l_pid for remote locks") specified that the l_pid returned for F_GETLK on a local file that has a remote lock should be the pid of the lock manager process. That commit, while updating other filesystems, failed to update lockd, such that locks created by lockd had their fl_pid set to that of the remote process holding the lock. Fix that here to be the pid of lockd. Also, fix the client case so that the returned lock pid is negative, which indicates a remote lock on a remote file. Fixes: 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific...") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Coddington Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 2524f5d6f4603e6dece56ea62c09ced0d6a635b9 Author: Ondrej Mosnacek Date: Tue Oct 23 09:02:17 2018 +0200 selinux: policydb - fix byte order and alignment issues commit 5df275cd4cf51c86d49009f1397132f284ba515e upstream. Do the LE conversions before doing the Infiniband-related range checks. The incorrect checks are otherwise causing a failure to load any policy with an ibendportcon rule on BE systems. This can be reproduced by running (on e.g. ppc64): cat >my_module.cil < Cc: Eli Cohen Cc: James Morris Cc: Doug Ledford Cc: # 4.13+ Fixes: a806f7a1616f ("selinux: Create policydb version for Infiniband support") Signed-off-by: Ondrej Mosnacek Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit b274cc25da938698dbc525f9a914f82fb3678c19 Author: Larry Finger Date: Mon Nov 19 20:01:24 2018 +0200 b43: Fix error in cordic routine commit 8ea3819c0bbef57a51d8abe579e211033e861677 upstream. The cordic routine for calculating sines and cosines that was added in commit 6f98e62a9f1b ("b43: update cordic code to match current specs") contains an error whereby a quantity declared u32 can in fact go negative. This problem was detected by Priit Laes who is switching b43 to use the routine in the library functions of the kernel. Fixes: 986504540306 ("b43: make cordic common (LP-PHY and N-PHY need it)") Reported-by: Priit Laes Cc: Rafał Miłecki Cc: Stable # 2.6.34 Signed-off-by: Larry Finger Signed-off-by: Priit Laes Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 6d75eb875b67b984e9804fa485e60716b363eaf5 Author: Andreas Gruenbacher Date: Tue Dec 4 15:06:27 2018 +0100 gfs2: Fix loop in gfs2_rbm_find commit 2d29f6b96d8f80322ed2dd895bca590491c38d34 upstream. Fix the resource group wrap-around logic in gfs2_rbm_find that commit e579ed4f44 broke. The bug can lead to unnecessary repeated scanning of the same bitmaps; there is a risk that future changes will turn this into an endless loop. Fixes: e579ed4f44 ("GFS2: Introduce rbm field bii") Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Bob Peterson Signed-off-by: Greg Kroah-Hartman commit 26538d51467f9255be56a354f103928d2acf5590 Author: Andreas Gruenbacher Date: Mon Nov 26 18:45:35 2018 +0100 gfs2: Get rid of potential double-freeing in gfs2_create_inode commit 6ff9b09e00a441599f3aacdf577254455a048bc9 upstream. In gfs2_create_inode, after setting and releasing the acl / default_acl, the acl / default_acl pointers are not set to NULL as they should be. In that state, when the function reaches label fail_free_acls, gfs2_create_inode will try to release the same acls again. Fix that by setting the pointers to NULL after releasing the acls. Slightly simplify the logic. Also, posix_acl_release checks for NULL already, so there is no need to duplicate those checks here. Fixes: e01580bf9e4d ("gfs2: use generic posix ACL infrastructure") Reported-by: Pan Bian Cc: Christoph Hellwig Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Bob Peterson Signed-off-by: Greg Kroah-Hartman commit f69ed08c4197a131949c1ac4ec067ef7d8104bc5 Author: Vasily Averin Date: Thu Nov 15 13:18:56 2018 +0300 dlm: memory leaks on error path in dlm_user_request() commit d47b41aceeadc6b58abc9c7c6485bef7cfb75636 upstream. According to comment in dlm_user_request() ua should be freed in dlm_free_lkb() after successful attach to lkb. However ua is attached to lkb not in set_lock_args() but later, inside request_lock(). Fixes 597d0cae0f99 ("[DLM] dlm: user locks") Cc: stable@kernel.org # 2.6.19 Signed-off-by: Vasily Averin Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 6c03da607b3339011c56560f007afb5307b9aa73 Author: Vasily Averin Date: Thu Nov 15 13:18:24 2018 +0300 dlm: lost put_lkb on error path in receive_convert() and receive_unlock() commit c0174726c3976e67da8649ac62cae43220ae173a upstream. Fixes 6d40c4a708e0 ("dlm: improve error and debug messages") Cc: stable@kernel.org # 3.5 Signed-off-by: Vasily Averin Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit f3d0f0a912776fb03e3499c62002d162d047c8c4 Author: Vasily Averin Date: Thu Nov 15 13:18:18 2018 +0300 dlm: possible memory leak on error path in create_lkb() commit 23851e978f31eda8b2d01bd410d3026659ca06c7 upstream. Fixes 3d6aa675fff9 ("dlm: keep lkbs in idr") Cc: stable@kernel.org # 3.1 Signed-off-by: Vasily Averin Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 8f0bfd40724072cd79afa7c77b77036c4490aa8b Author: Vasily Averin Date: Thu Nov 15 13:15:05 2018 +0300 dlm: fixed memory leaks after failed ls_remove_names allocation commit b982896cdb6e6a6b89d86dfb39df489d9df51e14 upstream. If allocation fails on last elements of array need to free already allocated elements. v2: just move existing out_rsbtbl label to right place Fixes 789924ba635f ("dlm: fix race between remove and lookup") Cc: stable@kernel.org # 3.6 Signed-off-by: Vasily Averin Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 385c23d626937494f90563a563c210b15c371b2a Author: Hui Peng Date: Tue Dec 25 18:11:52 2018 -0500 ALSA: usb-audio: Fix an out-of-bound read in create_composite_quirks commit cbb2ebf70daf7f7d97d3811a2ff8e39655b8c184 upstream. In `create_composite_quirk`, the terminating condition of for loops is `quirk->ifnum < 0`. So any composite quirks should end with `struct snd_usb_audio_quirk` object with ifnum < 0. for (quirk = quirk_comp->data; quirk->ifnum >= 0; ++quirk) { ..... } the data field of Bower's & Wilkins PX headphones usb device device quirks do not end with {.ifnum = -1}, wihch may result in out-of-bound read. This Patch fix the bug by adding an ending quirk object. Fixes: 240a8af929c7 ("ALSA: usb-audio: Add a quirck for B&W PX headphones") Signed-off-by: Hui Peng Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1117b7a380f4b4f575d90a318a43d2e168c01fbd Author: Takashi Iwai Date: Wed Dec 19 12:36:27 2018 +0100 ALSA: usb-audio: Avoid access before bLength check in build_audio_procunit() commit f4351a199cc120ff9d59e06d02e8657d08e6cc46 upstream. The parser for the processing unit reads bNrInPins field before the bLength sanity check, which may lead to an out-of-bound access when a malformed descriptor is given. Fix it by assignment after the bLength check. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 89c7ba90185dc9af684a17027300899e189039cd Author: Dan Carpenter Date: Tue Jan 8 10:43:30 2019 +0300 ALSA: cs46xx: Potential NULL dereference in probe commit 1524f4e47f90b27a3ac84efbdd94c63172246a6f upstream. The "chip->dsp_spos_instance" can be NULL on some of the ealier error paths in snd_cs46xx_create(). Reported-by: "Yavuz, Tuba" Signed-off-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a3c16e5f99c7805e3c76d94c4e1575fce11ae9d5 Author: Damien Le Moal Date: Fri Nov 30 15:31:48 2018 +0900 dm zoned: Fix target BIO completion handling commit d57f9da890696af1484f4a47f7f123560197865a upstream. struct bioctx includes the ref refcount_t to track the number of I/O fragments used to process a target BIO as well as ensure that the zone of the BIO is kept in the active state throughout the lifetime of the BIO. However, since decrementing of this reference count is done in the target .end_io method, the function bio_endio() must be called multiple times for read and write target BIOs, which causes problems with the value of the __bi_remaining struct bio field for chained BIOs (e.g. the clone BIO passed by dm core is large and splits into fragments by the block layer), resulting in incorrect values and inconsistencies with the BIO_CHAIN flag setting. This is turn triggers the BUG_ON() call: BUG_ON(atomic_read(&bio->__bi_remaining) <= 0); in bio_remaining_done() called from bio_endio(). Fix this ensuring that bio_endio() is called only once for any target BIO by always using internal clone BIOs for processing any read or write target BIO. This allows reference counting using the target BIO context counter to trigger the target BIO completion bio_endio() call once all data, metadata and other zone work triggered by the BIO complete. Overall, this simplifies the code too as the target .end_io becomes unnecessary and differences between read and write BIO issuing and completion processing disappear. Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0be812a800391c6d9447ed15b4bedb63b941b5aa Author: Mikulas Patocka Date: Wed Aug 22 12:45:51 2018 -0400 dm verity: fix crash on bufio buffer that was allocated with vmalloc commit e4b069e0945fa14c71cf8b5b89f8b1b2aa68dbc2 upstream. Since commit d1ac3ff008fb ("dm verity: switch to using asynchronous hash crypto API") dm-verity uses asynchronous crypto calls for verification, so that it can use hardware with asynchronous processing of crypto operations. These asynchronous calls don't support vmalloc memory, but the buffer data can be allocated with vmalloc if dm-bufio is short of memory and uses a reserved buffer that was preallocated in dm_bufio_client_create(). Fix verity_hash_update() so that it deals with vmalloc'd memory correctly. Reported-by: "Xiao, Jin" Signed-off-by: Mikulas Patocka Fixes: d1ac3ff008fb ("dm verity: switch to using asynchronous hash crypto API") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: Mike Snitzer Signed-off-by: Sudip Mukherjee Acked-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 14c2cd93e276832e92c1a811a1552bb4036108af Author: Stefan Hajnoczi Date: Thu Nov 9 13:29:10 2017 +0000 vhost/vsock: fix uninitialized vhost_vsock->guest_cid commit a72b69dc083a931422cc8a5e33841aff7d5312f2 upstream. The vhost_vsock->guest_cid field is uninitialized when /dev/vhost-vsock is opened until the VHOST_VSOCK_SET_GUEST_CID ioctl is called. kvmalloc(..., GFP_KERNEL | __GFP_RETRY_MAYFAIL) does not zero memory. All other vhost_vsock fields are initialized explicitly so just initialize this field too. Signed-off-by: Stefan Hajnoczi Signed-off-by: Michael S. Tsirkin Cc: Daniel Verkamp Signed-off-by: Greg Kroah-Hartman commit 1f33700bdf421490aef65bb794dbd9d9837f7ea0 Author: Joel Stanley Date: Fri Nov 2 11:14:55 2018 +1030 raid6/ppc: Fix build for clang commit e213574a449f7a57d4202c1869bbc7680b6b5521 upstream. We cannot build these files with clang as it does not allow altivec instructions in assembly when -msoft-float is passed. Jinsong Ji wrote: > We currently disable Altivec/VSX support when enabling soft-float. So > any usage of vector builtins will break. > > Enable Altivec/VSX with soft-float may need quite some clean up work, so > I guess this is currently a limitation. > > Removing -msoft-float will make it work (and we are lucky that no > floating point instructions will be generated as well). This is a workaround until the issue is resolved in clang. Link: https://bugs.llvm.org/show_bug.cgi?id=31177 Link: https://github.com/ClangBuiltLinux/linux/issues/239 Signed-off-by: Joel Stanley Reviewed-by: Nick Desaulniers Signed-off-by: Michael Ellerman [nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG' because that config does not exist in 4.14; the Kconfig rewrite that added that config happened in 4.18] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit d75c8c0afd357e66b55b4548919bb6d5a5a8e8fb Author: Joel Stanley Date: Mon Nov 12 14:51:16 2018 +1030 powerpc/boot: Set target when cross-compiling for clang commit 813af51f5d30a2da6a2523c08465f9726e51772e upstream. Clang needs to be told which target it is building for when cross compiling. Link: https://github.com/ClangBuiltLinux/linux/issues/259 Signed-off-by: Joel Stanley Tested-by: Daniel Axtens # powerpc 64-bit BE Acked-by: Michael Ellerman Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada [nc: Use 'ifeq ($(cc-name),clang)' instead of 'ifdef CONFIG_CC_IS_CLANG' because that config does not exist in 4.14; the Kconfig rewrite that added that config happened in 4.18] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 72d217d5df485027769cfc1a69e4d9bffaa30bfe Author: Joel Stanley Date: Mon Nov 12 14:51:15 2018 +1030 Makefile: Export clang toolchain variables commit 3bd9805090af843b25f97ffe5049f20ade1d86d6 upstream. The powerpc makefile will use these in it's boot wrapper. Signed-off-by: Joel Stanley Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit ff858d82207470c8612bb66d7129235f81567524 Author: Masahiro Yamada Date: Tue Nov 6 12:04:55 2018 +0900 kbuild: consolidate Clang compiler flags commit 238bcbc4e07fad2fff99c5b157d0c37ccd4d093c upstream. Collect basic Clang options such as --target, --prefix, --gcc-toolchain, -no-integrated-as into a single variable CLANG_FLAGS so that it can be easily reused in other parts of Makefile. Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Acked-by: Greg Hackmann Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 23d9f5e4a3ad66061e96dc467e65b580fafe3648 Author: Masahiro Yamada Date: Tue Nov 6 12:04:54 2018 +0900 kbuild: add -no-integrated-as Clang option unconditionally commit dbe27a002ef8573168cb64e181458ea23a74e2b6 upstream. We are still a way off the Clang's integrated assembler support for the kernel. Hence, -no-integrated-as is mandatory to build the kernel with Clang. If you had an ancient version of Clang that does not recognize this option, you would not be able to compile the kernel anyway. Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 03df2c59562a2d8851fea32f833e48193f6cd8ad Author: Matthias Kaehlcke Date: Thu Oct 5 11:28:47 2017 -0700 md: raid10: remove VLAIS commit 584ed9fa9532f8b9d5955628ff87ee3b2ab9f5a9 upstream. The raid10 driver can't be built with clang since it uses a variable length array in a structure (VLAIS): drivers/md/raid10.c:4583:17: error: fields must have a constant size: 'variable length array in structure' extension will never be supported Allocate the r10bio struct with kmalloc instead of using the VLAIS construct. Shaohua: set the MD_RECOVERY_INTR bit Neil Brown: use GFP_NOIO Signed-off-by: Matthias Kaehlcke Reviewed-by: Guenter Roeck Signed-off-by: Shaohua Li Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 487467e7d031e73907c820ef05ce0d4d18c24767 Author: Joel Stanley Date: Mon Sep 17 17:07:54 2018 +0930 ftrace: Build with CPPFLAGS to get -Qunused-arguments When building to record the mcount locations the kernel uses KBUILD_CFLAGS but not KBUILD_CPPFLAGS. This means it lacks -Qunused-arguments when building with clang, resulting in a lot of noisy warnings. Signed-off-by: Joel Stanley Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada [nc: Fix conflicts due to lack of 87a32e624037 and d503ac531a52] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 4df445a77526593d6236af778fda1627bd114000 Author: Joel Stanley Date: Mon Sep 17 17:16:21 2018 +0930 powerpc: Disable -Wbuiltin-requires-header when setjmp is used commit aea447141c7e7824b81b49acd1bc785506fba46e upstream. The powerpc kernel uses setjmp which causes a warning when building with clang: In file included from arch/powerpc/xmon/xmon.c:51: ./arch/powerpc/include/asm/setjmp.h:15:13: error: declaration of built-in function 'setjmp' requires inclusion of the header [-Werror,-Wbuiltin-requires-header] extern long setjmp(long *); ^ ./arch/powerpc/include/asm/setjmp.h:16:13: error: declaration of built-in function 'longjmp' requires inclusion of the header [-Werror,-Wbuiltin-requires-header] extern void longjmp(long *, long); ^ This *is* the header and we're not using the built-in setjump but rather the one in arch/powerpc/kernel/misc.S. As the compiler warning does not make sense, it for the files where setjmp is used. Signed-off-by: Joel Stanley Reviewed-by: Nick Desaulniers [mpe: Move subdir-ccflags in xmon/Makefile to not clobber -Werror] Signed-off-by: Michael Ellerman Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit f716d5e5fa6b6b498435ae67817122e73a8774ee Author: Nicholas Piggin Date: Fri Sep 14 15:08:54 2018 +1000 powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer commit 6977f95e63b9b3fb4a5973481a800dd9f48a1338 upstream. Signed-off-by: Nicholas Piggin Reviewed-by: Joel Stanley Signed-off-by: Michael Ellerman [nc: Adjust context due to lack of f2910f0e6835 and 2a056f58fd33] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit aa71dcfe9c4210f471d3d3c6153ec34ba2606597 Author: Vasily Averin Date: Mon Dec 24 14:44:42 2018 +0300 sunrpc: use SVC_NET() in svcauth_gss_* functions commit b8be5674fa9a6f3677865ea93f7803c4212f3e10 upstream. Signed-off-by: Vasily Averin Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 76da01793fbdcac42d9828b778cfa0d63d27bfac Author: Vasily Averin Date: Wed Nov 28 11:45:57 2018 +0300 sunrpc: fix cache_head leak due to queued request commit 4ecd55ea074217473f94cfee21bb72864d39f8d7 upstream. After commit d202cce8963d, an expired cache_head can be removed from the cache_detail's hash. However, the expired cache_head may be waiting for a reply from a previously submitted request. Such a cache_head has an increased refcounter and therefore it won't be freed after cache_put(freeme). Because the cache_head was removed from the hash it cannot be found during cache_clean() and can be leaked forever, together with stalled cache_request and other taken resources. In our case we noticed it because an entry in the export cache was holding a reference on a filesystem. Fixes d202cce8963d ("sunrpc: never return expired entries in sunrpc_cache_lookup") Cc: Pavel Tikhomirov Cc: stable@kernel.org # 2.6.35 Signed-off-by: Vasily Averin Reviewed-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 89b03877088751fc44dd93d40fdcd74a04927c45 Author: Huang Ying Date: Fri Dec 28 00:39:53 2018 -0800 mm, swap: fix swapoff with KSM pages commit 7af7a8e19f0c5425ff639b0f0d2d244c2a647724 upstream. KSM pages may be mapped to the multiple VMAs that cannot be reached from one anon_vma. So during swapin, a new copy of the page need to be generated if a different anon_vma is needed, please refer to comments of ksm_might_need_to_copy() for details. During swapoff, unuse_vma() uses anon_vma (if available) to locate VMA and virtual address mapped to the page, so not all mappings to a swapped out KSM page could be found. So in try_to_unuse(), even if the swap count of a swap entry isn't zero, the page needs to be deleted from swap cache, so that, in the next round a new page could be allocated and swapin for the other mappings of the swapped out KSM page. But this contradicts with the THP swap support. Where the THP could be deleted from swap cache only after the swap count of every swap entry in the huge swap cluster backing the THP has reach 0. So try_to_unuse() is changed in commit e07098294adf ("mm, THP, swap: support to reclaim swap space for THP swapped out") to check that before delete a page from swap cache, but this has broken KSM swapoff too. Fortunately, KSM is for the normal pages only, so the original behavior for KSM pages could be restored easily via checking PageTransCompound(). That is how this patch works. The bug is introduced by e07098294adf ("mm, THP, swap: support to reclaim swap space for THP swapped out"), which is merged by v4.14-rc1. So I think we should backport the fix to from 4.14 on. But Hugh thinks it may be rare for the KSM pages being in the swap device when swapoff, so nobody reports the bug so far. Link: http://lkml.kernel.org/r/20181226051522.28442-1-ying.huang@intel.com Fixes: e07098294adf ("mm, THP, swap: support to reclaim swap space for THP swapped out") Signed-off-by: "Huang, Ying" Reported-by: Hugh Dickins Tested-by: Hugh Dickins Acked-by: Hugh Dickins Cc: Rik van Riel Cc: Johannes Weiner Cc: Minchan Kim Cc: Shaohua Li Cc: Daniel Jordan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c5a2c79da3f8685de31791358a98a352f241fb83 Author: Dan Williams Date: Fri Dec 28 00:35:15 2018 -0800 mm, hmm: mark hmm_devmem_{add, add_resource} EXPORT_SYMBOL_GPL commit 02917e9f8676207a4c577d4d94eae12bf348e9d7 upstream. At Maintainer Summit, Greg brought up a topic I proposed around EXPORT_SYMBOL_GPL usage. The motivation was considerations for when EXPORT_SYMBOL_GPL is warranted and the criteria for taking the exceptional step of reclassifying an existing export. Specifically, I wanted to make the case that although the line is fuzzy and hard to specify in abstract terms, it is nonetheless clear that devm_memremap_pages() and HMM (Heterogeneous Memory Management) have crossed it. The devm_memremap_pages() facility should have been EXPORT_SYMBOL_GPL from the beginning, and HMM as a derivative of that functionality should have naturally picked up that designation as well. Contrary to typical rules, the HMM infrastructure was merged upstream with zero in-tree consumers. There was a promise at the time that those users would be merged "soon", but it has been over a year with no drivers arriving. While the Nouveau driver is about to belatedly make good on that promise it is clear that HMM was targeted first and foremost at an out-of-tree consumer. HMM is derived from devm_memremap_pages(), a facility Christoph and I spearheaded to support persistent memory. It combines a device lifetime model with a dynamically created 'struct page' / memmap array for any physical address range. It enables coordination and control of the many code paths in the kernel built to interact with memory via 'struct page' objects. With HMM the integration goes even deeper by allowing device drivers to hook and manipulate page fault and page free events. One interpretation of when EXPORT_SYMBOL is suitable is when it is exporting stable and generic leaf functionality. The devm_memremap_pages() facility continues to see expanding use cases, peer-to-peer DMA being the most recent, with no clear end date when it will stop attracting reworks and semantic changes. It is not suitable to export devm_memremap_pages() as a stable 3rd party driver API due to the fact that it is still changing and manipulates core behavior. Moreover, it is not in the best interest of the long term development of the core memory management subsystem to permit any external driver to effectively define its own system-wide memory management policies with no encouragement to engage with upstream. I am also concerned that HMM was designed in a way to minimize further engagement with the core-MM. That, with these hooks in place, device-drivers are free to implement their own policies without much consideration for whether and how the core-MM could grow to meet that need. Going forward not only should HMM be EXPORT_SYMBOL_GPL, but the core-MM should be allowed the opportunity and stimulus to change and address these new use cases as first class functionality. Original changelog: hmm_devmem_add(), and hmm_devmem_add_resource() duplicated devm_memremap_pages() and are now simple now wrappers around the core facility to inject a dev_pagemap instance into the global pgmap_radix and hook page-idle events. The devm_memremap_pages() interface is base infrastructure for HMM. HMM has more and deeper ties into the kernel memory management implementation than base ZONE_DEVICE which is itself a EXPORT_SYMBOL_GPL facility. Originally, the HMM page structure creation routines copied the devm_memremap_pages() code and reused ZONE_DEVICE. A cleanup to unify the implementations was discussed during the initial review: http://lkml.iu.edu/hypermail/linux/kernel/1701.2/00812.html Recent work to extend devm_memremap_pages() for the peer-to-peer-DMA facility enabled this cleanup to move forward. In addition to the integration with devm_memremap_pages() HMM depends on other GPL-only symbols: mmu_notifier_unregister_no_release percpu_ref region_intersects __class_create It goes further to consume / indirectly expose functionality that is not exported to any other driver: alloc_pages_vma walk_page_range HMM is derived from devm_memremap_pages(), and extends deep core-kernel fundamentals. Similar to devm_memremap_pages(), mark its entry points EXPORT_SYMBOL_GPL(). [logang@deltatee.com: PCI/P2PDMA: match interface changes to devm_memremap_pages()] Link: http://lkml.kernel.org/r/20181130225911.2900-1-logang@deltatee.com Link: http://lkml.kernel.org/r/154275560565.76910.15919297436557795278.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Logan Gunthorpe Reviewed-by: Christoph Hellwig Cc: Logan Gunthorpe Cc: "Jérôme Glisse" Cc: Balbir Singh , Cc: Michal Hocko Cc: Benjamin Herrenschmidt Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 465c5cf0bfdb7836dcb2012a52e79eb79f5e16ac Author: Dan Williams Date: Fri Dec 28 00:35:07 2018 -0800 mm, hmm: use devm semantics for hmm_devmem_{add, remove} commit 58ef15b765af0d2cbe6799ec564f1dc485010ab8 upstream. devm semantics arrange for resources to be torn down when device-driver-probe fails or when device-driver-release completes. Similar to devm_memremap_pages() there is no need to support an explicit remove operation when the users properly adhere to devm semantics. Note that devm_kzalloc() automatically handles allocating node-local memory. Link: http://lkml.kernel.org/r/154275559545.76910.9186690723515469051.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Reviewed-by: Christoph Hellwig Reviewed-by: Jérôme Glisse Cc: "Jérôme Glisse" Cc: Logan Gunthorpe Cc: Balbir Singh Cc: Michal Hocko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1432754217f7eec4cfa9794012d2e5d34b9ebef7 Author: Dan Williams Date: Fri Dec 28 00:34:54 2018 -0800 mm, devm_memremap_pages: kill mapping "System RAM" support commit 06489cfbd915ff36c8e36df27f1c2dc60f97ca56 upstream. Given the fact that devm_memremap_pages() requires a percpu_ref that is torn down by devm_memremap_pages_release() the current support for mapping RAM is broken. Support for remapping "System RAM" has been broken since the beginning and there is no existing user of this this code path, so just kill the support and make it an explicit error. This cleanup also simplifies a follow-on patch to fix the error path when setting a devm release action for devm_memremap_pages_release() fails. Link: http://lkml.kernel.org/r/154275557997.76910.14689813630968180480.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Reviewed-by: "Jérôme Glisse" Reviewed-by: Christoph Hellwig Reviewed-by: Logan Gunthorpe Cc: Balbir Singh Cc: Michal Hocko Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 47d24f8c8feee17d9f3e58c4227e3d00d7210120 Author: Dan Williams Date: Fri Dec 28 00:34:50 2018 -0800 mm, devm_memremap_pages: mark devm_memremap_pages() EXPORT_SYMBOL_GPL commit 808153e1187fa77ac7d7dad261ff476888dcf398 upstream. devm_memremap_pages() is a facility that can create struct page entries for any arbitrary range and give drivers the ability to subvert core aspects of page management. Specifically the facility is tightly integrated with the kernel's memory hotplug functionality. It injects an altmap argument deep into the architecture specific vmemmap implementation to allow allocating from specific reserved pages, and it has Linux specific assumptions about page structure reference counting relative to get_user_pages() and get_user_pages_fast(). It was an oversight and a mistake that this was not marked EXPORT_SYMBOL_GPL from the outset. Again, devm_memremap_pagex() exposes and relies upon core kernel internal assumptions and will continue to evolve along with 'struct page', memory hotplug, and support for new memory types / topologies. Only an in-kernel GPL-only driver is expected to keep up with this ongoing evolution. This interface, and functionality derived from this interface, is not suitable for kernel-external drivers. Link: http://lkml.kernel.org/r/154275557457.76910.16923571232582744134.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Reviewed-by: Christoph Hellwig Acked-by: Michal Hocko Cc: "Jérôme Glisse" Cc: Balbir Singh Cc: Logan Gunthorpe Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2c25071bed4b1f9c4cfb10a7914847d7069794bf Author: Michal Hocko Date: Fri Dec 28 00:38:01 2018 -0800 hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined commit b15c87263a69272423771118c653e9a1d0672caa upstream. We have received a bug report that an injected MCE about faulty memory prevents memory offline to succeed on 4.4 base kernel. The underlying reason was that the HWPoison page has an elevated reference count and the migration keeps failing. There are two problems with that. First of all it is dubious to migrate the poisoned page because we know that accessing that memory is possible to fail. Secondly it doesn't make any sense to migrate a potentially broken content and preserve the memory corruption over to a new location. Oscar has found out that 4.4 and the current upstream kernels behave slightly differently with his simply testcase === int main(void) { int ret; int i; int fd; char *array = malloc(4096); char *array_locked = malloc(4096); fd = open("/tmp/data", O_RDONLY); read(fd, array, 4095); for (i = 0; i < 4096; i++) array_locked[i] = 'd'; ret = mlock((void *)PAGE_ALIGN((unsigned long)array_locked), sizeof(array_locked)); if (ret) perror("mlock"); sleep (20); ret = madvise((void *)PAGE_ALIGN((unsigned long)array_locked), 4096, MADV_HWPOISON); if (ret) perror("madvise"); for (i = 0; i < 4096; i++) array_locked[i] = 'd'; return 0; } === + offline this memory. In 4.4 kernels he saw the hwpoisoned page to be returned back to the LRU list kernel: [] dump_trace+0x59/0x340 kernel: [] show_stack_log_lvl+0xea/0x170 kernel: [] show_stack+0x21/0x40 kernel: [] dump_stack+0x5c/0x7c kernel: [] warn_slowpath_common+0x81/0xb0 kernel: [] __pagevec_lru_add_fn+0x14c/0x160 kernel: [] pagevec_lru_move_fn+0xad/0x100 kernel: [] __lru_cache_add+0x6c/0xb0 kernel: [] add_to_page_cache_lru+0x46/0x70 kernel: [] extent_readpages+0xc3/0x1a0 [btrfs] kernel: [] __do_page_cache_readahead+0x177/0x200 kernel: [] ondemand_readahead+0x168/0x2a0 kernel: [] generic_file_read_iter+0x41f/0x660 kernel: [] __vfs_read+0xcd/0x140 kernel: [] vfs_read+0x7a/0x120 kernel: [] kernel_read+0x3b/0x50 kernel: [] do_execveat_common.isra.29+0x490/0x6f0 kernel: [] do_execve+0x28/0x30 kernel: [] call_usermodehelper_exec_async+0xfb/0x130 kernel: [] ret_from_fork+0x55/0x80 And that latter confuses the hotremove path because an LRU page is attempted to be migrated and that fails due to an elevated reference count. It is quite possible that the reuse of the HWPoisoned page is some kind of fixed race condition but I am not really sure about that. With the upstream kernel the failure is slightly different. The page doesn't seem to have LRU bit set but isolate_movable_page simply fails and do_migrate_range simply puts all the isolated pages back to LRU and therefore no progress is made and scan_movable_pages finds same set of pages over and over again. Fix both cases by explicitly checking HWPoisoned pages before we even try to get reference on the page, try to unmap it if it is still mapped. As explained by Naoya: : Hwpoison code never unmapped those for no big reason because : Ksm pages never dominate memory, so we simply didn't have strong : motivation to save the pages. Also put WARN_ON(PageLRU) in case there is a race and we can hit LRU HWPoison pages which shouldn't happen but I couldn't convince myself about that. Naoya has noted the following: : Theoretically no such gurantee, because try_to_unmap() doesn't have a : guarantee of success and then memory_failure() returns immediately : when hwpoison_user_mappings fails. : Or the following code (comes after hwpoison_user_mappings block) also impli= : es : that the target page can still have PageLRU flag. : : /* : * Torn down by someone else? : */ : if (PageLRU(p) && !PageSwapCache(p) && p->mapping =3D=3D NULL) { : action_result(pfn, MF_MSG_TRUNCATED_LRU, MF_IGNORED); : res =3D -EBUSY; : goto out; : } : : So I think it's OK to keep "if (WARN_ON(PageLRU(page)))" block in : current version of your patch. Link: http://lkml.kernel.org/r/20181206120135.14079-1-mhocko@kernel.org Signed-off-by: Michal Hocko Reviewed-by: Oscar Salvador Debugged-by: Oscar Salvador Tested-by: Oscar Salvador Acked-by: David Hildenbrand Acked-by: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ce8daa28a1d53dcf4258cff2b559d7ad37325dfa Author: Minchan Kim Date: Fri Dec 28 00:36:37 2018 -0800 zram: fix double free backing device commit 5547932dc67a48713eece4fa4703bfdf0cfcb818 upstream. If blkdev_get fails, we shouldn't do blkdev_put. Otherwise, kernel emits below log. This patch fixes it. WARNING: CPU: 0 PID: 1893 at fs/block_dev.c:1828 blkdev_put+0x105/0x120 Modules linked in: CPU: 0 PID: 1893 Comm: swapoff Not tainted 4.19.0+ #453 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 RIP: 0010:blkdev_put+0x105/0x120 Call Trace: __x64_sys_swapoff+0x46d/0x490 do_syscall_64+0x5a/0x190 entry_SYSCALL_64_after_hwframe+0x49/0xbe irq event stamp: 4466 hardirqs last enabled at (4465): __free_pages_ok+0x1e3/0x490 hardirqs last disabled at (4466): trace_hardirqs_off_thunk+0x1a/0x1c softirqs last enabled at (3420): __do_softirq+0x333/0x446 softirqs last disabled at (3407): irq_exit+0xd1/0xe0 Link: http://lkml.kernel.org/r/20181127055429.251614-3-minchan@kernel.org Signed-off-by: Minchan Kim Reviewed-by: Sergey Senozhatsky Reviewed-by: Joey Pabalinas Cc: [4.14+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3f2e4e1d9a6cffa95d31b7a491243d5e92a82507 Author: David Herrmann Date: Tue Jan 8 13:58:52 2019 +0100 fork: record start_time late commit 7b55851367136b1efd84d98fea81ba57a98304cf upstream. This changes the fork(2) syscall to record the process start_time after initializing the basic task structure but still before making the new process visible to user-space. Technically, we could record the start_time anytime during fork(2). But this might lead to scenarios where a start_time is recorded long before a process becomes visible to user-space. For instance, with userfaultfd(2) and TLS, user-space can delay the execution of fork(2) for an indefinite amount of time (and will, if this causes network access, or similar). By recording the start_time late, it much closer reflects the point in time where the process becomes live and can be observed by other processes. Lastly, this makes it much harder for user-space to predict and control the start_time they get assigned. Previously, user-space could fork a process and stall it in copy_thread_tls() before its pid is allocated, but after its start_time is recorded. This can be misused to later-on cycle through PIDs and resume the stalled fork(2) yielding a process that has the same pid and start_time as a process that existed before. This can be used to circumvent security systems that identify processes by their pid+start_time combination. Even though user-space was always aware that start_time recording is flaky (but several projects are known to still rely on start_time-based identification), changing the start_time to be recorded late will help mitigate existing attacks and make it much harder for user-space to control the start_time a process gets assigned. Reported-by: Jann Horn Signed-off-by: Tom Gundersen Signed-off-by: David Herrmann Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5ee254ef76e8c5f052487a5c3e0cd5fcfa805ec7 Author: Martin Kelly Date: Wed Feb 21 14:45:12 2018 -0800 tools: fix cross-compile var clobbering commit 7ed1c1901fe52e6c5828deb155920b44b0adabb1 upstream. Currently a number of Makefiles break when used with toolchains that pass extra flags in CC and other cross-compile related variables (such as --sysroot). Thus we get this error when we use a toolchain that puts --sysroot in the CC var: ~/src/linux/tools$ make iio [snip] iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory #include ^~~~~~~~~~ This occurs because we clobber several env vars related to cross-compiling with lines like this: CC = $(CROSS_COMPILE)gcc Although this will point to a valid cross-compiler, we lose any extra flags that might exist in the CC variable, which can break toolchains that rely on them (for example, those that use --sysroot). This easily shows up using a Yocto SDK: $ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi $ echo $CC arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a8 --sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi $ echo $CROSS_COMPILE arm-poky-linux-gnueabi- $ echo ${CROSS_COMPILE}gcc krm-poky-linux-gnueabi-gcc Although arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the --sysroot and other flags that enable us to find the right libraries to link against, so we can't find unistd.h and other libraries and headers. Normally with the --sysroot flag we would find unistd.h in the sdk directory in the sysroot: $ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h' [snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.h The perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not already set, and it compiles correctly with the above toolchain. So, generalize the logic that perf uses in the common Makefile and remove the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile. Note that this patch does not fix cross-compile for all the tools (some have other bugs), but it does fix it for all except usb and acpi, which still have other unrelated issues. I tested both with and without the patch on native and cross-build and there appear to be no regressions. Link: http://lkml.kernel.org/r/20180107214028.23771-1-martin@martingkelly.com Signed-off-by: Martin Kelly Acked-by: Mark Brown Cc: Tejun Heo Cc: Li Zefan Cc: Johannes Weiner Cc: Linus Walleij Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Jonathan Cameron Cc: Pali Rohar Cc: Richard Purdie Cc: Jacek Anaszewski Cc: Pavel Machek Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Robert Moore Cc: Lv Zheng Cc: "Rafael J. Wysocki" Cc: Greg Kroah-Hartman Cc: Valentina Manea Cc: Shuah Khan Cc: Mario Limonciello Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Ignat Korchagin Signed-off-by: Greg Kroah-Hartman commit 76369ed5bce3b31de6c21ebf216d01fd9c9d3476 Author: Thomas Gleixner Date: Wed Apr 4 12:40:07 2018 +0200 genirq/affinity: Don't return with empty affinity masks on error commit 0211e12dd0a5385ecffd3557bc570dbad7fcf245 upstream. When the allocation of node_to_possible_cpumask fails, then irq_create_affinity_masks() returns with a pointer to the empty affinity masks array, which will cause malfunction. Reorder the allocations so the masks array allocation comes last and every failure path returns NULL. Fixes: 9a0ef98e186d ("genirq/affinity: Assign vectors to all present CPUs") Signed-off-by: Thomas Gleixner Cc: Christoph Hellwig Cc: Ming Lei Cc: Mihai Carabas Signed-off-by: Greg Kroah-Hartman commit 0840feb396aa78cdcac7f9b30f7678b68e22fddb Author: Ewan D. Milne Date: Thu Dec 13 15:25:16 2018 -0500 scsi: lpfc: do not set queue->page_count to 0 if pc_sli4_params.wqpcnt is invalid commit 4e87eb2f46ea547d12a276b2e696ab934d16cfb6 upstream. Certain older adapters such as the OneConnect OCe10100 may not have a valid wqpcnt value. In this case, do not set queue->page_count to 0 in lpfc_sli4_queue_alloc() as this will prevent the driver from initializing. Fixes: 895427bd01 ("scsi: lpfc: NVME Initiator: Base modifications") Cc: stable@vger.kernel.org # 4.11+ Signed-off-by: Ewan D. Milne Reviewed-by: Laurence Oberman Tested-by: Laurence Oberman Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 8eb9f245dc977335fbff8ad5f428447a55f24484 Author: Steffen Maier Date: Thu Dec 6 17:31:20 2018 +0100 scsi: zfcp: fix posting too many status read buffers leading to adapter shutdown commit 60a161b7e5b2a252ff0d4c622266a7d8da1120ce upstream. Suppose adapter (open) recovery is between opened QDIO queues and before (the end of) initial posting of status read buffers (SRBs). This time window can be seconds long due to FSF_PROT_HOST_CONNECTION_INITIALIZING causing by design looping with exponential increase sleeps in the function performing exchange config data during recovery [zfcp_erp_adapter_strat_fsf_xconf()]. Recovery triggered by local link up. Suppose an event occurs for which the FCP channel would send an unsolicited notification to zfcp by means of a previously posted SRB. We saw it with local cable pull (link down) in multi-initiator zoning with multiple NPIV-enabled subchannels of the same shared FCP channel. As soon as zfcp_erp_adapter_strategy_open_fsf() starts posting the initial status read buffers from within the adapter's ERP thread, the channel does send an unsolicited notification. Since v2.6.27 commit d26ab06ede83 ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall"), zfcp_fsf_status_read_handler() schedules adapter->stat_work to re-fill the just consumed SRB from a work item. Now the ERP thread and the work item post SRBs in parallel. Both contexts call the helper function zfcp_status_read_refill(). The tracking of missing (to be posted / re-filled) SRBs is not thread-safe due to separate atomic_read() and atomic_dec(), in order to depend on posting success. Hence, both contexts can see atomic_read(&adapter->stat_miss) == 1. One of the two contexts posts one too many SRB. Zfcp gets QDIO_ERROR_SLSB_STATE on the output queue (trace tag "qdireq1") leading to zfcp_erp_adapter_shutdown() in zfcp_qdio_handler_error(). An obvious and seemingly clean fix would be to schedule stat_work from the ERP thread and wait for it to finish. This would serialize all SRB re-fills. However, we already have another work item wait on the ERP thread: adapter->scan_work runs zfcp_fc_scan_ports() which calls zfcp_fc_eval_gpn_ft(). The latter calls zfcp_erp_wait() to wait for all the open port recoveries during zfcp auto port scan, but in fact it waits for any pending recovery including an adapter recovery. This approach leads to a deadlock. [see also v3.19 commit 18f87a67e6d6 ("zfcp: auto port scan resiliency"); v2.6.37 commit d3e1088d6873 ("[SCSI] zfcp: No ERP escalation on gpn_ft eval"); v2.6.28 commit fca55b6fb587 ("[SCSI] zfcp: fix deadlock between wq triggered port scan and ERP") fixing v2.6.27 commit c57a39a45a76 ("[SCSI] zfcp: wait until adapter is finished with ERP during auto-port"); v2.6.27 commit cc8c282963bd ("[SCSI] zfcp: Automatically attach remote ports")] Instead make the accounting of missing SRBs atomic for parallel execution in both the ERP thread and adapter->stat_work. Signed-off-by: Steffen Maier Fixes: d26ab06ede83 ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall") Cc: #2.6.27+ Reviewed-by: Jens Remus Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d87abc2ae5474bd4b42e892ee7369086d2d6af6b Author: Yangtao Li Date: Wed Dec 12 11:01:45 2018 -0500 serial/sunsu: fix refcount leak [ Upstream commit d430aff8cd0c57502d873909c184e3b5753f8b88 ] The function of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. su_get_type() doesn't do that. The match node are used as an identifier to compare against the current node, so we can directly drop the refcount after getting the node from the path as it is not used as pointer. Fix this by use a single variable and drop the refcount right after of_find_node_by_path(). Signed-off-by: Yangtao Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit be899fe44fe522bc3f573cee3b381c7c733d5961 Author: Daniele Palmas Date: Fri Dec 21 13:07:23 2018 +0100 qmi_wwan: Fix qmap header retrieval in qmimux_rx_fixup [ Upstream commit d667044f49513d55fcfefe4fa8f8d96091782901 ] This patch fixes qmap header retrieval when modem is configured for dl data aggregation. Signed-off-by: Daniele Palmas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 29b7def0ffb1c9acc043a5ca4b9fb212c2d0687d Author: Kangjie Lu Date: Fri Dec 21 00:22:32 2018 -0600 net: netxen: fix a missing check and an uninitialized use [ Upstream commit d134e486e831defd26130770181f01dfc6195f7d ] When netxen_rom_fast_read() fails, "bios" is left uninitialized and may contain random value, thus should not be used. The fix ensures that if netxen_rom_fast_read() fails, we return "-EIO". Signed-off-by: Kangjie Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dd707bdce260c0b9adf99e9a3a77a21ca3ead2eb Author: Mantas Mikulėnas Date: Fri Dec 21 01:04:26 2018 -0800 Input: synaptics - enable SMBus for HP EliteBook 840 G4 [ Upstream commit 7a71712293ba303aad928f580b89addb0be2892e ] dmesg reports that "Your touchpad (PNP: SYN3052 SYN0100 SYN0002 PNP0f13) says it can support a different bus." I've tested the offered psmouse.synaptics_intertouch=1 with 4.18.x and 4.19.x and it seems to work well. No problems seen with suspend/resume. Also, it appears that RMI/SMBus mode is actually required for 3-4 finger multitouch gestures to work -- otherwise they are not reported at all. Information from dmesg in both modes: psmouse serio3: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 0xf00123/0x840300/0x2e800/0x0, board id: 3139, fw id: 2000742 psmouse serio3: synaptics: Trying to set up SMBus access rmi4_smbus 6-002c: registering SMbus-connected sensor rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM3139-001, fw id: 2000742 Signed-off-by: Mantas Mikulėnas Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 7bee9f9a131059a16538bb8e86ba567fc39ef733 Author: Uwe Kleine-König Date: Mon Dec 17 09:43:13 2018 +0100 gpio: mvebu: only fail on missing clk if pwm is actually to be used [ Upstream commit c8da642d41a6811c21177c9994aa7dc35be67d46 ] The gpio IP on Armada 370 at offset 0x18180 has neither a clk nor pwm registers. So there is no need for a clk as the pwm isn't used anyhow. So only check for the clk in the presence of the pwm registers. This fixes a failure to probe the gpio driver for the above mentioned gpio device. Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support") Signed-off-by: Uwe Kleine-König Reviewed-by: Gregory CLEMENT Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9adf9d714b3dd94fddf583eb8e8f12efdfa797e4 Author: Michael S. Tsirkin Date: Wed Dec 19 18:21:51 2018 -0500 virtio: fix test build after uio.h change [ Upstream commit c5c08bed843c2b2c048c16d1296d7631d7c1620e ] Fixes: d38499530e5 ("fs: decouple READ and WRITE from the block layer ops") Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit b08f331e84f75a2981350d3ee7452ea67412776d Author: Masahiro Yamada Date: Tue Dec 18 14:25:41 2018 +0900 kbuild: fix false positive warning/error about missing libelf [ Upstream commit ef7cfd00b2caf6edeb7f169682b64be2d0a798cf ] For the same reason as commit 25896d073d8a ("x86/build: Fix compiler support check for CONFIG_RETPOLINE"), you cannot put this $(error ...) into the parse stage of the top Makefile. Perhaps I'd propose a more sophisticated solution later, but this is the best I can do for now. Link: https://lkml.org/lkml/2017/12/25/211 Reported-by: Paul Gortmaker Reported-by: Bernd Edlinger Reported-by: Qian Cai Cc: Josh Poimboeuf Signed-off-by: Masahiro Yamada Tested-by: Qian Cai Signed-off-by: Sasha Levin commit bb2509c12bea9601f0637f815936e9562d3c3cbc Author: Sara Sharon Date: Sat Dec 15 11:03:06 2018 +0200 mac80211: free skb fraglist before freeing the skb [ Upstream commit 34b1e0e9efe101822e83cc62d22443ed3867ae7a ] mac80211 uses the frag list to build AMSDU. When freeing the skb, it may not be really freed, since someone is still holding a reference to it. In that case, when TCP skb is being retransmitted, the pointer to the frag list is being reused, while the data in there is no longer valid. Since we will never get frag list from the network stack, as mac80211 doesn't advertise the capability, we can safely free and nullify it before releasing the SKB. Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit fb34793c9f380b99c9ce925ff2d4e6b7f5af32c8 Author: Colin Ian King Date: Tue Dec 18 15:19:47 2018 +0000 vxge: ensure data0 is initialized in when fetching firmware version information [ Upstream commit f7db2beb4c2c6cc8111f5ab90fc7363ca91107b6 ] Currently variable data0 is not being initialized so a garbage value is being passed to vxge_hw_vpath_fw_api and this value is being written to the rts_access_steer_data0 register. There are other occurrances where data0 is being initialized to zero (e.g. in function vxge_hw_upgrade_read_version) so I think it makes sense to ensure data0 is initialized likewise to 0. Detected by CoverityScan, CID#140696 ("Uninitialized scalar variable") Fixes: 8424e00dfd52 ("vxge: serialize access to steering control register") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9c5239ee1c3f59e1ece9072cae57af8b601e0b99 Author: Jason Martinsen Date: Tue Dec 18 05:38:22 2018 +0000 lan78xx: Resolve issue with changing MAC address [ Upstream commit 15515aaaa69659c502003926a2067ee76176148a ] Current state for the lan78xx driver does not allow for changing the MAC address of the interface, without either removing the module (if you compiled it that way) or rebooting the machine. If you attempt to change the MAC address, ifconfig will show the new address, however, the system/interface will not respond to any traffic using that configuration. A few short-term options to work around this are to unload the module and reload it with the new MAC address, change the interface to "promisc", or reboot with the correct configuration to change the MAC. This patch enables the ability to change the MAC address via fairly normal means... ifdown modify entry in /etc/network/interfaces OR a similar method ifup Then test via any network communication, such as ICMP requests to gateway. My only test platform for this patch has been a raspberry pi model 3b+. Signed-off-by: Jason Martinsen ----- Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4d45ed2d0d28326b9fb7401d96f7c772ee0ad078 Author: Anssi Hannula Date: Mon Dec 17 15:05:40 2018 +0200 net: macb: fix dropped RX frames due to a race [ Upstream commit 8159ecab0db9095902d4c73605fb8787f5c7d653 ] Bit RX_USED set to 0 in the address field allows the controller to write data to the receive buffer descriptor. The driver does not ensure the ctrl field is ready (cleared) when the controller sees the RX_USED=0 written by the driver. The ctrl field might only be cleared after the controller has already updated it according to a newly received frame, causing the frame to be discarded in gem_rx() due to unexpected ctrl field contents. A message is logged when the above scenario occurs: macb ff0b0000.ethernet eth0: not whole frame pointed by descriptor Fix the issue by ensuring that when the controller sees RX_USED=0 the ctrl field is already cleared. This issue was observed on a ZynqMP based system. Fixes: 4df95131ea80 ("net/macb: change RX path for GEM") Signed-off-by: Anssi Hannula Tested-by: Claudiu Beznea Cc: Nicolas Ferre Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 358e56b282ecfd3ca9ff6521ee6e35ef34945bcd Author: Anssi Hannula Date: Mon Dec 17 15:05:39 2018 +0200 net: macb: fix random memory corruption on RX with 64-bit DMA [ Upstream commit e100a897bf9b19089e57f236f2398c9e0538900e ] 64-bit DMA addresses are split in upper and lower halves that are written in separate fields on GEM. For RX, bit 0 of the address is used as the ownership bit (RX_USED). When the RX_USED bit is unset the controller is allowed to write data to the buffer. The driver does not guarantee that the controller already sees the upper half when the RX_USED bit is cleared, possibly resulting in the controller writing an incoming frame to an address with an incorrect upper half and therefore possibly corrupting unrelated system memory. Fix that by adding the necessary DMA memory barrier between the writes. This corruption was observed on a ZynqMP based system. Fixes: fff8019a08b6 ("net: macb: Add 64 bit addressing support for GEM") Signed-off-by: Anssi Hannula Acked-by: Harini Katakam Tested-by: Claudiu Beznea Cc: Nicolas Ferre Cc: Michal Simek Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6de29b8cd448490a6ba514d9f6b334341cf99eff Author: Dan Carpenter Date: Mon Dec 17 10:05:13 2018 +0300 qed: Fix an error code qed_ll2_start_xmit() [ Upstream commit f07d4276892d97671e880190ff195a288b2d8d92 ] We accidentally deleted the code to set "rc = -ENOMEM;" and this patch adds it back. Fixes: d2201a21598a ("qed: No need for LL2 frags indication") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8265e34e5705c21978f1e3359c430832110057f1 Author: Trond Myklebust Date: Mon Dec 17 17:38:51 2018 -0500 SUNRPC: Fix a race with XPRT_CONNECTING [ Upstream commit cf76785d30712d90185455e752337acdb53d2a5d ] Ensure that we clear XPRT_CONNECTING before releasing the XPRT_LOCK so that we don't have races between the (asynchronous) socket setup code and tasks in xprt_connect(). Signed-off-by: Trond Myklebust Tested-by: Chuck Lever Signed-off-by: Sasha Levin commit 1eac41bac7c9a578c6bd93d4660fa4c67b4238d9 Author: Yonglong Liu Date: Sat Dec 15 11:53:29 2018 +0800 net: hns: Fix ping failed when use net bridge and send multicast [ Upstream commit 6adafc356e20189193b38ee6b9af7743078bf6b4 ] Create a net bridge, add eth and vnet to the bridge. The vnet is used by a virtual machine. When ping the virtual machine from the outside host and the virtual machine send multicast at the same time, the ping package will lost. The multicast package send to the eth, eth will send it to the bridge too, and the bridge learn the mac of eth. When outside host ping the virtual mechine, it will match the promisc entry of the eth which is not expected, and the bridge send it to eth not to vnet, cause ping lost. So this patch change promisc tcam entry position to the END of 512 tcam entries, which indicate lower priority. And separate one promisc entry to two: mc & uc, to avoid package match the wrong tcam entry. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 31212d944a0f3873e6bc6c28d352db7d6493fcac Author: Yonglong Liu Date: Sat Dec 15 11:53:28 2018 +0800 net: hns: Add mac pcs config when enable|disable mac [ Upstream commit 726ae5c9e5f0c18eca8ea5296b526242c3e89822 ] In some case, when mac enable|disable and adjust link, may cause hard to link(or abnormal) between mac and phy. This patch adds the code for rx PCS to avoid this bug. Disable the rx PCS when driver disable the gmac, and enable the rx PCS when driver enable the mac. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f64bc8f6626b39a4a65d2450b980de00c742db2 Author: Yonglong Liu Date: Sat Dec 15 11:53:27 2018 +0800 net: hns: Fix ntuple-filters status error. [ Upstream commit 7e74a19ca522aec7c2be201a7ae1d1d57ded409b ] The ntuple-filters features is forced on by chip. But it shows "ntuple-filters: off [fixed]" when use ethtool. This patch make it correct with "ntuple-filters: on [fixed]". Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b984806de33f1bade282aac1725610698ceff4f2 Author: Yonglong Liu Date: Sat Dec 15 11:53:26 2018 +0800 net: hns: Avoid net reset caused by pause frames storm [ Upstream commit a57275d35576fdd89d8c771eedf1e7cf97e0dfa6 ] There will be a large number of MAC pause frames on the net, which caused tx timeout of net device. And then the net device was reset to try to recover it. So that is not useful, and will cause some other problems. So need doubled ndev->watchdog_timeo if device watchdog occurred until watchdog_timeo up to 40s and then try resetting to recover it. When collecting dfx information such as hardware registers when tx timeout. Some registers for count were cleared when read. So need move this task before update net state which also read the count registers. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 02ad6ced13d71d8af63c6195ac1a8205d8d40e2f Author: Yonglong Liu Date: Sat Dec 15 11:53:25 2018 +0800 net: hns: Free irq when exit from abnormal branch [ Upstream commit c82bd077e1ba3dd586569c733dc6d3dd4b0e43cd ] 1.In "hns_nic_init_irq", if request irq fail at index i, the function return directly without releasing irq resources that already requested. 2.In "hns_nic_net_up" after "hns_nic_init_irq", if exceptional branch occurs, irqs that already requested are not release. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ddca1a9915f48f583186c627865d20f1e435d23 Author: Yonglong Liu Date: Sat Dec 15 11:53:24 2018 +0800 net: hns: Clean rx fbd when ae stopped. [ Upstream commit 31f6b61d810654fb3ef43f4d8afda0f44b142fad ] If there are packets in hardware when changing the speed or duplex, it may cause hardware hang up. This patch adds the code to wait rx fbd clean up when ae stopped. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1ef17642df395627055661c3c20dfd183e78b07a Author: Yonglong Liu Date: Sat Dec 15 11:53:23 2018 +0800 net: hns: Fixed bug that netdev was opened twice [ Upstream commit 5778b13b64eca5549d242686f2f91a2c80c8fa40 ] After resetting dsaf to try to repair chip error such as ecc error, the net device will be open if net interface is up. But at this time if there is the users set the net device up with the command ifconfig, the net device will be opened twice consecutively. Function napi_enable was called when open device. And Kernel panic will be occurred if it was called twice consecutively. Such as follow: static inline void napi_enable(struct napi_struct *n) { BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state)); smp_mb__before_clear_bit(); clear_bit(NAPI_STATE_SCHED, &n->state); } [37255.571996] Kernel panic - not syncing: BUG! [37255.595234] Call trace: [37255.597694] [] dump_backtrace+0x0/0x1a0 [37255.603114] [] show_stack+0x20/0x28 [37255.608187] [] dump_stack+0x98/0xb8 [37255.613258] [] panic+0x10c/0x26c [37255.618070] [] hns_nic_net_up+0x30c/0x4e0 [37255.623664] [] hns_nic_net_open+0x94/0x12c [37255.629346] [] __dev_open+0xf4/0x168 [37255.634504] [] __dev_change_flags+0x98/0x15c [37255.640359] [] dev_change_flags+0x2c/0x68 [37255.769580] [] devinet_ioctl+0x650/0x704 [37255.775086] [] inet_ioctl+0x98/0xb4 [37255.780159] [] sock_do_ioctl+0x44/0x84 [37255.785490] [] sock_ioctl+0x248/0x30c [37255.790737] [] do_vfs_ioctl+0x480/0x618 [37255.796156] [] SyS_ioctl+0x90/0xa4 [37255.801139] SMP: stopping secondary CPUs [37255.805079] kbox: catch panic event. [37255.809586] collected_len = 128928, LOG_BUF_LEN_LOCAL = 131072 [37255.816103] flush cache 0xffff80003f000000 size 0x800000 [37255.822192] flush cache 0xffff80003f000000 size 0x800000 [37255.828289] flush cache 0xffff80003f000000 size 0x800000 [37255.834378] kbox: no notify die func register. no need to notify [37255.840413] ---[ end Kernel panic - not syncing: BUG! This patchset fix this bug according to the flag NIC_STATE_DOWN. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5fed62f0692508804684a0e79719569e146c3300 Author: Yonglong Liu Date: Sat Dec 15 11:53:22 2018 +0800 net: hns: Some registers use wrong address according to the datasheet. [ Upstream commit 4ad26f117b6ea0f5d5f1592127bafb5ec65904d3 ] According to the hip06 datasheet: 1.Six registers use wrong address: RCB_COM_SF_CFG_INTMASK_RING RCB_COM_SF_CFG_RING_STS RCB_COM_SF_CFG_RING RCB_COM_SF_CFG_INTMASK_BD RCB_COM_SF_CFG_BD_RINT_STS DSAF_INODE_VC1_IN_PKT_NUM_0_REG 2.The offset of DSAF_INODE_VC1_IN_PKT_NUM_0_REG should be 0x103C + 0x80 * all_chn_num 3.The offset to show the value of DSAF_INODE_IN_DATA_STP_DISC_0_REG is wrong, so the value of DSAF_INODE_SW_VLAN_TAG_DISC_0_REG will be overwrite These registers are only used in "ethtool -d", so that did not cause ndev to misfunction. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 649171175b35f9f36f58bbe886718ebc2e788e0b Author: Yonglong Liu Date: Sat Dec 15 11:53:21 2018 +0800 net: hns: All ports can not work when insmod hns ko after rmmod. [ Upstream commit 308c6cafde0147616da45e3a928adae55c428deb ] There are two test cases: 1. Remove the 4 modules:hns_enet_drv/hns_dsaf/hnae/hns_mdio, and install them again, must use "ifconfig down/ifconfig up" command pair to bring port to work. This patch calls phy_stop function when init phy to fix this bug. 2. Remove the 2 modules:hns_enet_drv/hns_dsaf, and install them again, all ports can not use anymore, because of the phy devices register failed(phy devices already exists). Phy devices are registered when hns_dsaf installed, this patch removes them when hns_dsaf removed. The two cases are sometimes related, fixing the second case also requires fixing the first case, so fix them together. Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9c97aac00f9d6b01d45f3731b7f14f9d34a167c1 Author: Yonglong Liu Date: Sat Dec 15 11:53:20 2018 +0800 net: hns: Incorrect offset address used for some registers. [ Upstream commit 4e1d4be681b2c26fd874adbf584bf034573ac45d ] According to the hip06 Datasheet: 1. The offset of INGRESS_SW_VLAN_TAG_DISC should be 0x1A00+4*all_chn_num 2. The offset of INGRESS_IN_DATA_STP_DISC should be 0x1A50+4*all_chn_num Signed-off-by: Yonglong Liu Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 491fe3ac1e8a3b8dfbb280a6a0e3bd3b0faf3c67 Author: Arnd Bergmann Date: Mon Dec 10 21:45:07 2018 +0100 w90p910_ether: remove incorrect __init annotation [ Upstream commit 51367e423c6501a26e67d91a655d2bc892303462 ] The get_mac_address() function is normally inline, but when it is not, we get a warning that this configuration is broken: WARNING: vmlinux.o(.text+0x4aff00): Section mismatch in reference from the function w90p910_ether_setup() to the function .init.text:get_mac_address() The function w90p910_ether_setup() references the function __init get_mac_address(). This is often because w90p910_ether_setup lacks a __init Remove the __init to make it always do the right thing. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0758a796eb07a6eb65af0bb7161c0f74f431eea6 Author: Nathan Chancellor Date: Mon Dec 10 21:20:30 2018 -0700 drivers: net: xgene: Remove unnecessary forward declarations [ Upstream commit 2ab4c3426c0cf711d7147e3f559638e4ab88960e ] Clang warns: drivers/net/ethernet/apm/xgene/xgene_enet_main.c:33:36: warning: tentative array definition assumed to have one element static const struct acpi_device_id xgene_enet_acpi_match[]; ^ 1 warning generated. Both xgene_enet_acpi_match and xgene_enet_of_match are defined before their uses at the bottom of the file so this is unnecessary. When CONFIG_ACPI is disabled, ACPI_PTR becomes NULL so xgene_enet_acpi_match doesn't need to be defined. Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bcf86ba5e2b487df5e2a891f9131b6368791510e Author: Sinan Kaya Date: Sat Dec 1 21:40:38 2018 +0000 x86, hyperv: remove PCI dependency [ Upstream commit c629421a990033ba539eb8585e73a2e6fa9ea631 ] Need to be able to boot without PCI devices present. Signed-off-by: Sinan Kaya Signed-off-by: Sasha Levin commit 5e6aefd625f30006fe443ac714d240a6362c6b9a Author: Varun Prakash Date: Fri Nov 9 20:59:46 2018 +0530 scsi: target: iscsi: cxgbit: add missing spin_lock_init() [ Upstream commit 9e6371d3c6913ff1707fb2c0274c9925f7aaef80 ] Add missing spin_lock_init() for cdev->np_lock. Signed-off-by: Varun Prakash Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b831528038e3cad0d745c53bcaeedb642f5cbc1f Author: Varun Prakash Date: Fri Nov 9 20:59:01 2018 +0530 scsi: target: iscsi: cxgbit: fix csk leak [ Upstream commit 801df68d617e3cb831f531c99fa6003620e6b343 ] csk leak can happen if a new TCP connection gets established after cxgbit_accept_np() returns, to fix this leak free remaining csk in cxgbit_free_np(). Signed-off-by: Varun Prakash Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 70875bda5af2066dba4bc227f927be4abb603531 Author: Sudarsana Reddy Kalluru Date: Wed Dec 12 08:57:03 2018 -0800 bnx2x: Send update-svid ramrod with retry/poll flags enabled [ Upstream commit 9061193c4ee065d3240fde06767c2e06ec61decc ] Driver sends update-SVID ramrod in the MFW notification path. If there is a pending ramrod, driver doesn't retry the command and storm firmware will never be updated with the SVID value. The patch adds changes to send update-svid ramrod in process context with retry/poll flags set. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d964ef1d09b5526b244bfcb57dec76d69a79a7f5 Author: Sudarsana Reddy Kalluru Date: Wed Dec 12 08:57:01 2018 -0800 bnx2x: Remove configured vlans as part of unload sequence. [ Upstream commit 04f05230c5c13b1384f66f5186a68d7499e34622 ] Vlans are not getting removed when drivers are unloaded. The recent storm firmware versions had added safeguards against re-configuring an already configured vlan. As a result, PF inner reload flows (e.g., mtu change) might trigger an assertion. This change is going to remove vlans (same as we do for MACs) when doing a chip cleanup during unload. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a00f97b1af6c78f27876091b5efbc347a6262b57 Author: Sudarsana Reddy Kalluru Date: Wed Dec 12 08:57:00 2018 -0800 bnx2x: Clear fip MAC when fcoe offload support is disabled [ Upstream commit bbf666c1af916ed74795493c564df6fad462cc80 ] On some customer setups it was observed that shmem contains a non-zero fip MAC for 57711 which would lead to enabling of SW FCoE. Add a software workaround to clear the bad fip mac address if no FCoE connections are supported. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b0e56e3c569932e937fa2fa0dc5799c8f023d07e Author: Florian Westphal Date: Tue Dec 11 07:45:29 2018 +0100 netfilter: nat: can't use dst_hold on noref dst [ Upstream commit 542fbda0f08f1cbbc250f9e59f7537649651d0c8 ] The dst entry might already have a zero refcount, waiting on rcu list to be free'd. Using dst_hold() transitions its reference count to 1, and next dst release will try to free it again -- resulting in a double free: WARNING: CPU: 1 PID: 0 at include/net/dst.h:239 nf_xfrm_me_harder+0xe7/0x130 [nf_nat] RIP: 0010:nf_xfrm_me_harder+0xe7/0x130 [nf_nat] Code: 48 8b 5c 24 60 65 48 33 1c 25 28 00 00 00 75 53 48 83 c4 68 5b 5d 41 5c c3 85 c0 74 0d 8d 48 01 f0 0f b1 0a 74 86 85 c0 75 f3 <0f> 0b e9 7b ff ff ff 29 c6 31 d2 b9 20 00 48 00 4c 89 e7 e8 31 27 Call Trace: nf_nat_ipv4_out+0x78/0x90 [nf_nat_ipv4] nf_hook_slow+0x36/0xd0 ip_output+0x9f/0xd0 ip_forward+0x328/0x440 ip_rcv+0x8a/0xb0 Use dst_hold_safe instead and bail out if we cannot take a reference. Fixes: a4c2fd7f7891 ("net: remove DST_NOCACHE flag") Reported-by: Martin Zaharinov Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e8267a5ec404913cd2fcfc51ff5e5b3671ed4916 Author: Pan Bian Date: Mon Dec 10 14:39:37 2018 +0100 netfilter: ipset: do not call ipset_nest_end after nla_nest_cancel [ Upstream commit 708abf74dd87f8640871b814faa195fb5970b0e3 ] In the error handling block, nla_nest_cancel(skb, atd) is called to cancel the nest operation. But then, ipset_nest_end(skb, atd) is unexpected called to end the nest operation. This patch calls the ipset_nest_end only on the branch that nla_nest_cancel is not called. Fixes: 45040978c899 ("netfilter: ipset: Fix set:list type crash when flush/dump set in parallel") Signed-off-by: Pan Bian Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 214b5617cc701471374f7ccfe748399f952646ec Author: Stefan Assmann Date: Tue Dec 4 15:18:52 2018 +0100 i40e: fix mac filter delete when setting mac address [ Upstream commit 158daed16efb1170694e420ae06ba8ba954d82e5 ] A previous commit moved the ether_addr_copy() in i40e_set_mac() before the mac filter del/add to avoid a race. However it wasn't taken into account that this alters the mac address being handed to i40e_del_mac_filter(). Also changed i40e_add_mac_filter() to operate on netdev->dev_addr, hopefully that makes the code easier to read. Fixes: 458867b2ca0c ("i40e: don't remove netdev->dev_addr when syncing uc list") Signed-off-by: Stefan Assmann Tested-by: Andrew Bowers Acked-by: Jacob Keller Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 10294811172cc7f4ff1d67ef842064f5a4cf5fce Author: Kirill A. Shutemov Date: Fri Nov 30 23:23:28 2018 +0300 x86/dump_pagetables: Fix LDT remap address marker [ Upstream commit 254eb5505ca0ca749d3a491fc6668b6c16647a99 ] The LDT remap placement has been changed. It's now placed before the direct mapping in the kernel virtual address space for both paging modes. Change address markers order accordingly. Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") 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: hans.van.kranenburg@mendix.com Cc: linux-mm@kvack.org Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/20181130202328.65359-3-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit 0f0b37af1d3c11cf4d17c4b74e2ba3bb23b277fb Author: Kirill A. Shutemov Date: Fri Nov 30 23:23:27 2018 +0300 x86/mm: Fix guard hole handling [ Upstream commit 16877a5570e0c5f4270d5b17f9bab427bcae9514 ] There is a guard hole at the beginning of the kernel address space, also used by hypervisors. It occupies 16 PGD entries. This reserved range is not defined explicitely, it is calculated relative to other entities: direct mapping and user space ranges. The calculation got broken by recent changes of the kernel memory layout: LDT remap range is now mapped before direct mapping and makes the calculation invalid. The breakage leads to crash on Xen dom0 boot[1]. Define the reserved range explicitely. It's part of kernel ABI (hypervisors expect it to be stable) and must not depend on changes in the rest of kernel memory layout. [1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") Reported-by: Hans van Kranenburg Signed-off-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Tested-by: Hans van Kranenburg Reviewed-by: Juergen Gross 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: bhe@redhat.com Cc: linux-mm@kvack.org Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/20181130202328.65359-2-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit a8fe14fcfe50e8170eeae31684eeeb42aa15e921 Author: YueHaibing Date: Tue Dec 11 11:13:39 2018 +0800 ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done [ Upstream commit 8e41cae64b08fe2e86a9ffb88b295c6b4b3a3322 ] gcc warning this: drivers/net/ieee802154/ca8210.c:730:10: warning: comparison is always false due to limited range of data type [-Wtype-limits] 'len' is u8 type, we get it from buf[1] adding 2, which can overflow. This patch change the type of 'len' to unsigned int to avoid this,also fix the gcc warning. Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Signed-off-by: YueHaibing Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit ae6f4c3cbad175800c318c4fde54a3699fcdb431 Author: Thomas Falcon Date: Mon Dec 10 15:22:23 2018 -0600 ibmvnic: Fix non-atomic memory allocation in IRQ context [ Upstream commit 1d1bbc37f89b0559c9e913682f2489d89cfde6b8 ] ibmvnic_reset allocated new reset work item objects in a non-atomic context. This can be called from a tasklet, generating the output below. Allocate work items with the GFP_ATOMIC flag instead. BUG: sleeping function called from invalid context at mm/slab.h:421 in_atomic(): 1, irqs_disabled(): 1, pid: 93, name: kworker/0:2 INFO: lockdep is turned off. irq event stamp: 66049 hardirqs last enabled at (66048): [] tasklet_action_common.isra.12+0x78/0x1c0 hardirqs last disabled at (66049): [] _raw_spin_lock_irqsave+0x48/0xf0 softirqs last enabled at (66044): [] dev_deactivate_queue.constprop.28+0xc8/0x160 softirqs last disabled at (66045): [] call_do_softirq+0x14/0x24 CPU: 0 PID: 93 Comm: kworker/0:2 Kdump: loaded Not tainted 4.20.0-rc6-00001-g1b50a8f03706 #7 Workqueue: events linkwatch_event Call Trace: [c0000003fffe7ae0] [c000000000bc83e4] dump_stack+0xe8/0x164 (unreliable) [c0000003fffe7b30] [c00000000015ba0c] ___might_sleep+0x2dc/0x320 [c0000003fffe7bb0] [c000000000391514] kmem_cache_alloc_trace+0x3e4/0x440 [c0000003fffe7c30] [d000000005b2309c] ibmvnic_reset+0x16c/0x360 [ibmvnic] [c0000003fffe7cc0] [d000000005b29834] ibmvnic_tasklet+0x1054/0x2010 [ibmvnic] [c0000003fffe7e00] [c0000000001224c8] tasklet_action_common.isra.12+0xd8/0x1c0 [c0000003fffe7e60] [c000000000bf1238] __do_softirq+0x1a8/0x64c [c0000003fffe7f90] [c0000000000306e0] call_do_softirq+0x14/0x24 [c0000003f3967980] [c00000000001ba50] do_softirq_own_stack+0x60/0xb0 [c0000003f39679c0] [c0000000001218a8] do_softirq+0xa8/0x100 [c0000003f39679f0] [c000000000121a74] __local_bh_enable_ip+0x174/0x180 [c0000003f3967a60] [c000000000bf003c] _raw_spin_unlock_bh+0x5c/0x80 [c0000003f3967a90] [c000000000a8ac78] dev_deactivate_queue.constprop.28+0xc8/0x160 [c0000003f3967ad0] [c000000000a8c8b0] dev_deactivate_many+0xd0/0x520 [c0000003f3967b70] [c000000000a8cd40] dev_deactivate+0x40/0x60 [c0000003f3967ba0] [c000000000a5e0c4] linkwatch_do_dev+0x74/0xd0 [c0000003f3967bd0] [c000000000a5e694] __linkwatch_run_queue+0x1a4/0x1f0 [c0000003f3967c30] [c000000000a5e728] linkwatch_event+0x48/0x60 [c0000003f3967c50] [c0000000001444e8] process_one_work+0x238/0x710 [c0000003f3967d20] [c000000000144a48] worker_thread+0x88/0x4e0 [c0000003f3967db0] [c00000000014e3a8] kthread+0x178/0x1c0 [c0000003f3967e20] [c00000000000bfd0] ret_from_kernel_thread+0x5c/0x6c Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 154ed1efeac4be5f8dc6469e08bacf5a5e45e245 Author: Yussuf Khalil Date: Sat Dec 8 20:13:35 2018 -0800 Input: synaptics - enable RMI on ThinkPad T560 [ Upstream commit ca5047286c9c93a01e1f471d00a6019536992954 ] Before commit 7fd6d98b89f3 ("i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBus"), enabling RMI on the T560 would cause the touchpad to stop working after resuming from suspend. Now that this issue is fixed, RMI can be enabled safely and works fine. Reviewed-by: Benjamin Tissoires Signed-off-by: Yussuf Khalil Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 6989cedd762f2e1b9062f2c20f19528f9116badc Author: Tony Lindgren Date: Tue Dec 4 13:52:49 2018 -0800 Input: omap-keypad - fix idle configuration to not block SoC idle states [ Upstream commit e2ca26ec4f01486661b55b03597c13e2b9c18b73 ] With PM enabled, I noticed that pressing a key on the droid4 keyboard will block deeper idle states for the SoC. Let's fix this by using IRQF_ONESHOT and stop constantly toggling the device OMAP4_KBD_IRQENABLE register as suggested by Dmitry Torokhov . From the hardware point of view, looks like we need to manage the registers for OMAP4_KBD_IRQENABLE and OMAP4_KBD_WAKEUPENABLE together to avoid blocking deeper SoC idle states. And with toggling of OMAP4_KBD_IRQENABLE register now gone with IRQF_ONESHOT, also the SoC idle state problem is gone during runtime. We still also need to clear OMAP4_KBD_WAKEUPENABLE in omap4_keypad_close() though to pair it with omap4_keypad_open() to prevent blocking deeper SoC idle states after rmmod omap4-keypad. Reported-by: Pavel Machek Signed-off-by: Tony Lindgren Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit bbed2ced931009ba45ff32e8abdef8523548fd9b Author: Dan Carpenter Date: Thu Nov 1 08:25:30 2018 +0300 scsi: bnx2fc: Fix NULL dereference in error handling [ Upstream commit 9ae4f8420ed7be4b13c96600e3568c144d101a23 ] If "interface" is NULL then we can't release it and trying to will only lead to an Oops. Fixes: aea71a024914 ("[SCSI] bnx2fc: Introduce interface structure for each vlan interface") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5ac1f046ab4a6f629a524b9bd4f15f72bf6a4798 Author: Florian Westphal Date: Wed Dec 5 14:12:19 2018 +0100 netfilter: seqadj: re-load tcp header pointer after possible head reallocation [ Upstream commit 530aad77010b81526586dfc09130ec875cd084e4 ] When adjusting sack block sequence numbers, skb_make_writable() gets called to make sure tcp options are all in the linear area, and buffer is not shared. This can cause tcp header pointer to get reallocated, so we must reaload it to avoid memory corruption. This bug pre-dates git history. Reported-by: Neel Mehta Reported-by: Shane Huntley Reported-by: Heather Adkins Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 4ddb80f4193cf344550458087977a500a2c3cd4c Author: Steffen Klassert Date: Thu Nov 22 07:26:24 2018 +0100 xfrm: Fix NULL pointer dereference in xfrm_input when skb_dst_force clears the dst_entry. [ Upstream commit 0152eee6fc3b84298bb6a79961961734e8afa5b8 ] Since commit 222d7dbd258d ("net: prevent dst uses after free") skb_dst_force() might clear the dst_entry attached to the skb. The xfrm code doesn't expect this to happen, so we crash with a NULL pointer dereference in this case. Fix it by checking skb_dst(skb) for NULL after skb_dst_force() and drop the packet in case the dst_entry was cleared. We also move the skb_dst_force() to a codepath that is not used when the transformation was offloaded, because in this case we don't have a dst_entry attached to the skb. The output and forwarding path was already fixed by commit 9e1437937807 ("xfrm: Fix NULL pointer dereference when skb_dst_force clears the dst_entry.") Fixes: 222d7dbd258d ("net: prevent dst uses after free") Reported-by: Jean-Philippe Menil Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ed04bb260d161cab36118537f888329712ad4abe Author: Benjamin Poirier Date: Mon Nov 5 17:00:53 2018 +0900 xfrm: Fix bucket count reported to userspace [ Upstream commit ca92e173ab34a4f7fc4128bd372bd96f1af6f507 ] sadhcnt is reported by `ip -s xfrm state count` as "buckets count", not the hash mask. Fixes: 28d8909bc790 ("[XFRM]: Export SAD info.") Signed-off-by: Benjamin Poirier Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit bf2b044bc820cf1d6fa74ff77b09c33886a01568 Author: Wei Yongjun Date: Sat Oct 27 06:12:06 2018 +0000 xfrm: Fix error return code in xfrm_output_one() [ Upstream commit 533555e5cbb6aa2d77598917871ae5b579fe724b ] xfrm_output_one() does not return a error code when there is no dst_entry attached to the skb, it is still possible crash with a NULL pointer dereference in xfrm_output_resume(). Fix it by return error code -EHOSTUNREACH. Fixes: 9e1437937807 ("xfrm: Fix NULL pointer dereference when skb_dst_force clears the dst_entry.") Signed-off-by: Wei Yongjun Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 7932e14f9fec2dca602b6e213445eb9bc5c6c4c6 Author: Qian Cai Date: Fri Dec 14 14:17:20 2018 -0800 checkstack.pl: fix for aarch64 [ Upstream commit f1733a1d3cd32a9492f4cf866be37bb46e10163d ] There is actually a space after "sp," like this, ffff2000080813c8: a9bb7bfd stp x29, x30, [sp, #-80]! Right now, checkstack.pl isn't able to print anything on aarch64, because it won't be able to match the stating objdump line of a function due to this missing space. Hence, it displays every stack as zero-size. After this patch, checkpatch.pl is able to match the start of a function's objdump, and is then able to calculate each function's stack correctly. Link: http://lkml.kernel.org/r/20181207195843.38528-1-cai@lca.pw Signed-off-by: Qian Cai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9940eeaa995557b3ece7d45b567701550863013f Author: Peter Hutterer Date: Thu Dec 6 09:03:36 2018 +1000 Input: restore EV_ABS ABS_RESERVED [ Upstream commit c201e3808e0e4be9b98d192802085a9f491bd80c ] ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of ffe0e7cf290f5c9 when the high-resolution scrolling code was removed. Signed-off-by: Peter Hutterer Reviewed-by: Martin Kepplinger Acked-by: Benjamin Tissoires Acked-by: Dmitry Torokhov Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 9c3fe68759f0743897bc9c8ab0ba3c5e7d9f0925 Author: Fabio Estevam Date: Wed Dec 5 09:05:30 2018 -0200 ARM: dts: imx7d-nitrogen7: Fix the description of the Wifi clock [ Upstream commit f15096f12a4e9340168df5fdd9201aa8ed60d59e ] According to bindings/regulator/fixed-regulator.txt the 'clocks' and 'clock-names' properties are not valid ones. In order to turn on the Wifi clock the correct location for describing the CLKO2 clock is via a mmc-pwrseq handle, so do it accordingly. Fixes: 56354959cfec ("ARM: dts: imx: add Boundary Devices Nitrogen7 board") Signed-off-by: Fabio Estevam Acked-by: Troy Kisky Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8cd34030db2ab78d572e3276d7f4e508c392b6e3 Author: Anson Huang Date: Tue Dec 4 03:17:45 2018 +0000 ARM: imx: update the cpu power up timing setting on i.mx6sx [ Upstream commit 1e434b703248580b7aaaf8a115d93e682f57d29f ] The sw2iso count should cover ARM LDO ramp-up time, the MAX ARM LDO ramp-up time may be up to more than 100us on some boards, this patch sets sw2iso to 0xf (~384us) which is the reset value, and it is much more safe to cover different boards, since we have observed that some customer boards failed with current setting of 0x2. Fixes: 05136f0897b5 ("ARM: imx: support arm power off in cpuidle for i.mx6sx") Signed-off-by: Anson Huang Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit af00b69210ca7e9c97a6b3a77841c4f32139125d Author: Hans de Goede Date: Mon Nov 26 11:52:18 2018 +0100 HID: ite: Add USB id match for another ITE based keyboard rfkill key quirk [ Upstream commit 4050207485e47e00353e87f2fe2166083e282688 ] The 258a:6a88 keyboard-dock shipped with the Prowise PT301 tablet is likely another ITE based design. The controller die is directly bonded to the PCB with a blob of black glue on top so there are no markings and the 258a vendor-id used is unknown anywhere. But the keyboard has the exact same hotkeys mapped to Fn+F1 - F10 as the other ITE8595 keyboard I have *and* it has the same quirky behavior wrt the rfkill hotkey. Either way as said this keyboard has the same quirk for its rfkill / airplane mode hotkey as the ITE 8595 chip, it only sends a single release event when pressed and released, it never sends a press event. This commit adds the 258a:6a88 USB id to the hid-ite id-table, fixing the rfkill key not working on this keyboard. Signed-off-by: Hans de Goede Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 5d661328f91c3c429a96dd62b628254057f200e8 Author: Michael Ellerman Date: Mon Nov 26 12:59:16 2018 +1100 powerpc/mm: Fix linux page tables build with some configs [ Upstream commit 462951cd32e1496dc64b00051dfb777efc8ae5d8 ] For some configs the build fails with: arch/powerpc/mm/dump_linuxpagetables.c: In function 'populate_markers': arch/powerpc/mm/dump_linuxpagetables.c:306:39: error: 'PKMAP_BASE' undeclared (first use in this function) arch/powerpc/mm/dump_linuxpagetables.c:314:50: error: 'LAST_PKMAP' undeclared (first use in this function) These come from highmem.h, including that fixes the build. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 3f9db10dfc625b294b636d59eb87754940cce30e Author: Paul Mackerras Date: Tue Nov 27 09:01:54 2018 +1100 powerpc: Fix COFF zImage booting on old powermacs [ Upstream commit 5564597d51c8ff5b88d95c76255e18b13b760879 ] Commit 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN", 2011-04-12) changed the procedure descriptor at the start of crt0.S to have a hard-coded start address of 0x500000 rather than a reference to _zimage_start, presumably because having a reference to a symbol introduced a relocation which is awkward to handle in a position-independent executable. Unfortunately, what is at 0x500000 in the COFF image is not the first instruction, but the procedure descriptor itself, that is, a word containing 0x500000, which is not a valid instruction. Hence, booting a COFF zImage results in a "DEFAULT CATCH!, code=FFF00700" message from Open Firmware. This fixes the problem by (a) putting the procedure descriptor in the data section and (b) adding a branch to _zimage_start as the first instruction in the program. Fixes: 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN") Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit fd78ae770d6f5caa6a97af7757fdfa92be066a6e Author: Jerome Brunet Date: Tue Nov 13 11:55:36 2018 +0100 pinctrl: meson: fix pull enable register calculation [ Upstream commit 614b1868a125a0ba24be08f3a7fa832ddcde6bca ] We just changed the code so we apply bias disable on the correct register but forgot to align the register calculation. The result is that we apply the change on the correct register, but possibly at the incorrect offset/bit This went undetected because offsets tends to be the same between REG_PULL and REG_PULLEN for a given pin the EE controller. This is not true for the AO controller. Fixes: e39f9dd8206a ("pinctrl: meson: fix pinconf bias disable") Signed-off-by: Jerome Brunet Acked-by: Neil Armstrong Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin