commit 0788acb1a3ed1589da1768ba64b1e5c76e8cb661 Author: Greg Kroah-Hartman Date: Tue Feb 12 20:02:39 2019 +0100 Linux 4.20.8 commit db74e5aebab92dc3132afb3f6a98ccfe4757a517 Author: Lorenzo Bianconi Date: Fri Nov 2 21:49:57 2018 +0100 ath9k: dynack: check da->enabled first in sampling routines commit 9d3d65a91f027b8a9af5e63752d9b78cb10eb92d upstream. Check da->enabled flag first in ath_dynack_sample_tx_ts and ath_dynack_sample_ack_ts routines in order to avoid useless processing Tested-by: Koen Vandeputte Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit e7e4c25c1b17f4582aabfb0b535d8cfd2b94fd7d Author: Lorenzo Bianconi Date: Fri Nov 2 21:49:58 2018 +0100 ath9k: dynack: make ewma estimation faster commit 0c60c490830a1a756c80f8de8d33d9c6359d4a36 upstream. In order to make propagation time estimation faster, use current sample as ewma output value during 'late ack' tracking Tested-by: Koen Vandeputte Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit fbd03574b5682462b9abce676b6fe7f21aab7ef1 Author: Trond Myklebust Date: Mon Jan 21 15:58:38 2019 -0500 nfsd: Fix error return values for nfsd4_clone_file_range() commit e3fdc89ca47ef34dfb6fd5101fec084c3dba5486 upstream. If the parameter 'count' is non-zero, nfsd4_clone_file_range() will currently clobber all errors returned by vfs_clone_file_range() and replace them with EINVAL. Fixes: 42ec3d4c0218 ("vfs: make remap_file_range functions take and...") Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 6f38cb51121e1a5c300ea1c33ccaba38b61114ef Author: Huacai Chen Date: Wed Dec 19 16:16:03 2018 +0800 cacheinfo: Keep the old value if of_property_read_u32 fails commit 3a34c986324c07dde32903f7bb262e6138e77c2a upstream. Commit 448a5a552f336bd7b847b1951 ("drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number") makes cache size and number_of_sets be 0 if DT doesn't provide there values. I think this is unreasonable so make them keep the old values, which is the same as old kernels. Fixes: 448a5a552f33 ("drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number") Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Reviewed-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit 05161b41e86efa755816e58d5e9461db4b71c5bf Author: Chris Brandt Date: Mon Jan 28 13:25:56 2019 -0500 serial: sh-sci: Do not free irqs that have already been freed commit 4d95987a32db53f3beca76f8c4c8309ef6a5f192 upstream. Since IRQs might be muxed on some parts, we need to pay attention when we are freeing them. Otherwise we get the ugly WARNING "Trying to free already-free IRQ 20". Fixes: 628c534ae735 ("serial: sh-sci: Improve support for separate TEI and DRI interrupts") Cc: stable Signed-off-by: Chris Brandt Signed-off-by: Greg Kroah-Hartman commit 9ed556075d98e278853daa6a06e9c3fc48b6cb78 Author: Andy Shevchenko Date: Thu Jan 24 23:51:21 2019 +0200 serial: 8250_pci: Make PCI class test non fatal commit 824d17c57b0abbcb9128fb3f7327fae14761914b upstream. As has been reported the National Instruments serial cards have broken PCI class. The commit 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list") made the PCI class check mandatory for the case when device is listed in a quirk list. Make PCI class test non fatal to allow broken card be enumerated. Fixes: 7d8905d06405 ("serial: 8250_pci: Enable device after we check black list") Cc: stable Reported-by: Guan Yung Tseng Tested-by: Guan Yung Tseng Tested-by: KHUENY.Gerhard Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 12cb6384e7a23a25353bc3621777115c38a63de3 Author: Greg Kroah-Hartman Date: Thu Jan 31 17:43:16 2019 +0800 serial: fix race between flush_to_ldisc and tty_open commit fedb5760648a291e949f2380d383b5b2d2749b5e upstream. There still is a race window after the commit b027e2298bd588 ("tty: fix data race between tty_init_dev and flush of buf"), and we encountered this crash issue if receive_buf call comes before tty initialization completes in tty_open and tty->driver_data may be NULL. CPU0 CPU1 ---- ---- tty_open tty_init_dev tty_ldisc_unlock schedule flush_to_ldisc receive_buf tty_port_default_receive_buf tty_ldisc_receive_buf n_tty_receive_buf_common __receive_buf uart_flush_chars uart_start /*tty->driver_data is NULL*/ tty->ops->open /*init tty->driver_data*/ it can be fixed by extending ldisc semaphore lock in tty_init_dev to driver_data initialized completely after tty->ops->open(), but this will lead to get lock on one function and unlock in some other function, and hard to maintain, so fix this race only by checking tty->driver_data when receiving, and return if tty->driver_data is NULL, and n_tty_receive_buf_common maybe calls uart_unthrottle, so add the same check. Because the tty layer knows nothing about the driver associated with the device, the tty layer can not do anything here, it is up to the tty driver itself to check for this type of race. Fix up the serial driver to correctly check to see if it is finished binding with the device when being called, and if not, abort the tty calls. [Description and problem report and testing from Li RongQing, I rewrote the patch to be in the serial layer, not in the tty core - gregkh] Reported-by: Li RongQing Tested-by: Li RongQing Signed-off-by: Wang Li Signed-off-by: Zhang Yu Signed-off-by: Li RongQing Cc: stable Signed-off-by: Greg Kroah-Hartman commit 8b5846fb3b33fadef3515faef810697a5c0ae6f0 Author: Gustavo A. R. Silva Date: Tue Jan 22 17:34:39 2019 -0600 perf tests evsel-tp-sched: Fix bitwise operator commit 489338a717a0dfbbd5a3fabccf172b78f0ac9015 upstream. Notice that the use of the bitwise OR operator '|' always leads to true in this particular case, which seems a bit suspicious due to the context in which this expression is being used. Fix this by using bitwise AND operator '&' instead. This bug was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Namhyung Kim Cc: Peter Zijlstra Cc: stable@vger.kernel.org Fixes: 6a6cd11d4e57 ("perf test: Add test for the sched tracepoint format fields") Link: http://lkml.kernel.org/r/20190122233439.GA5868@embeddedor Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit c2df99efd03e8255a127e685bd6c8b584d8c1dd8 Author: Mark Rutland Date: Thu Jan 10 14:27:45 2019 +0000 perf/core: Don't WARN() for impossible ring-buffer sizes commit 9dff0aa95a324e262ffb03f425d00e4751f3294e upstream. The perf tool uses /proc/sys/kernel/perf_event_mlock_kb to determine how large its ringbuffer mmap should be. This can be configured to arbitrary values, which can be larger than the maximum possible allocation from kmalloc. When this is configured to a suitably large value (e.g. thanks to the perf fuzzer), attempting to use perf record triggers a WARN_ON_ONCE() in __alloc_pages_nodemask(): WARNING: CPU: 2 PID: 5666 at mm/page_alloc.c:4511 __alloc_pages_nodemask+0x3f8/0xbc8 Let's avoid this by checking that the requested allocation is possible before calling kzalloc. Reported-by: Julien Thierry Signed-off-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Julien Thierry Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Link: https://lkml.kernel.org/r/20190110142745.25495-1-mark.rutland@arm.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 016ef22d2f32ba6f5cbc3f4b474f7f92d7845802 Author: Tony Luck Date: Thu Jan 31 16:33:41 2019 -0800 x86/MCE: Initialize mce.bank in the case of a fatal error in mce_no_way_out() commit d28af26faa0b1daf3c692603d46bc4687c16f19e upstream. Internal injection testing crashed with a console log that said: mce: [Hardware Error]: CPU 7: Machine Check Exception: f Bank 0: bd80000000100134 This caused a lot of head scratching because the MCACOD (bits 15:0) of that status is a signature from an L1 data cache error. But Linux says that it found it in "Bank 0", which on this model CPU only reports L1 instruction cache errors. The answer was that Linux doesn't initialize "m->bank" in the case that it finds a fatal error in the mce_no_way_out() pre-scan of banks. If this was a local machine check, then this partially initialized struct mce is being passed to mce_panic(). Fix is simple: just initialize m->bank in the case of a fatal error. Fixes: 40c36e2741d7 ("x86/mce: Fix incorrect "Machine check from unknown source" message") Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Vishal Verma Cc: x86-ml Cc: stable@vger.kernel.org # v4.18 Note pre-v5.0 arch/x86/kernel/cpu/mce/core.c was called arch/x86/kernel/cpu/mcheck/mce.c Link: https://lkml.kernel.org/r/20190201003341.10638-1-tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman commit 5cbde46eb9c89c5fa02a5927103c4e738c5d08b9 Author: Peter Zijlstra Date: Wed Dec 19 17:53:50 2018 +0100 perf/x86/intel: Delay memory deallocation until x86_pmu_dead_cpu() commit 602cae04c4864bb3487dfe4c2126c8d9e7e1614a upstream. intel_pmu_cpu_prepare() allocated memory for ->shared_regs among other members of struct cpu_hw_events. This memory is released in intel_pmu_cpu_dying() which is wrong. The counterpart of the intel_pmu_cpu_prepare() callback is x86_pmu_dead_cpu(). Otherwise if the CPU fails on the UP path between CPUHP_PERF_X86_PREPARE and CPUHP_AP_PERF_X86_STARTING then it won't release the memory but allocate new memory on the next attempt to online the CPU (leaking the old memory). Also, if the CPU down path fails between CPUHP_AP_PERF_X86_STARTING and CPUHP_PERF_X86_PREPARE then the CPU will go back online but never allocate the memory that was released in x86_pmu_dying_cpu(). Make the memory allocation/free symmetrical in regard to the CPU hotplug notifier by moving the deallocation to intel_pmu_cpu_dead(). This started in commit: a7e3ed1e47011 ("perf: Add support for supplementary event registers"). In principle the bug was introduced in v2.6.39 (!), but it will almost certainly not backport cleanly across the big CPU hotplug rewrite between v4.7-v4.15... [ bigeasy: Added patch description. ] [ mingo: Added backporting guidance. ] Reported-by: He Zhe Signed-off-by: Peter Zijlstra (Intel) # With developer hat on Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) # With maintainer hat on Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: acme@kernel.org Cc: bp@alien8.de Cc: hpa@zytor.com Cc: jolsa@kernel.org Cc: kan.liang@linux.intel.com Cc: namhyung@kernel.org Cc: Fixes: a7e3ed1e47011 ("perf: Add support for supplementary event registers"). Link: https://lkml.kernel.org/r/20181219165350.6s3jvyxbibpvlhtq@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bb549f6c764ba62e597f61b03ce76325bb46cafd Author: Kan Liang Date: Sun Jan 27 06:53:14 2019 -0800 perf/x86/intel/uncore: Add Node ID mask commit 9e63a7894fd302082cf3627fe90844421a6cbe7f upstream. Some PCI uncore PMUs cannot be registered on an 8-socket system (HPE Superdome Flex). To understand which Socket the PCI uncore PMUs belongs to, perf retrieves the local Node ID of the uncore device from CPUNODEID(0xC0) of the PCI configuration space, and the mapping between Socket ID and Node ID from GIDNIDMAP(0xD4). The Socket ID can be calculated accordingly. The local Node ID is only available at bit 2:0, but current code doesn't mask it. If a BIOS doesn't clear the rest of the bits, an incorrect Node ID will be fetched. Filter the Node ID by adding a mask. Reported-by: Song Liu Tested-by: Song Liu Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: # v3.7+ Fixes: 7c94ee2e0917 ("perf/x86: Add Intel Nehalem and Sandy Bridge-EP uncore support") Link: https://lkml.kernel.org/r/1548600794-33162-1-git-send-email-kan.liang@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f29a8be0e5d28f89c835cbae700e67a383280916 Author: Josh Poimboeuf Date: Wed Jan 30 07:13:58 2019 -0600 cpu/hotplug: Fix "SMT disabled by BIOS" detection for KVM commit b284909abad48b07d3071a9fc9b5692b3e64914b upstream. With the following commit: 73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS") ... the hotplug code attempted to detect when SMT was disabled by BIOS, in which case it reported SMT as permanently disabled. However, that code broke a virt hotplug scenario, where the guest is booted with only primary CPU threads, and a sibling is brought online later. The problem is that there doesn't seem to be a way to reliably distinguish between the HW "SMT disabled by BIOS" case and the virt "sibling not yet brought online" case. So the above-mentioned commit was a bit misguided, as it permanently disabled SMT for both cases, preventing future virt sibling hotplugs. Going back and reviewing the original problems which were attempted to be solved by that commit, when SMT was disabled in BIOS: 1) /sys/devices/system/cpu/smt/control showed "on" instead of "notsupported"; and 2) vmx_vm_init() was incorrectly showing the L1TF_MSG_SMT warning. I'd propose that we instead consider #1 above to not actually be a problem. Because, at least in the virt case, it's possible that SMT wasn't disabled by BIOS and a sibling thread could be brought online later. So it makes sense to just always default the smt control to "on" to allow for that possibility (assuming cpuid indicates that the CPU supports SMT). The real problem is #2, which has a simple fix: change vmx_vm_init() to query the actual current SMT state -- i.e., whether any siblings are currently online -- instead of looking at the SMT "control" sysfs value. So fix it by: a) reverting the original "fix" and its followup fix: 73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS") bc2d8d262cba ("cpu/hotplug: Fix SMT supported evaluation") and b) changing vmx_vm_init() to query the actual current SMT state -- instead of the sysfs control value -- to determine whether the L1TF warning is needed. This also requires the 'sched_smt_present' variable to exported, instead of 'cpu_smt_control'. Fixes: 73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS") Reported-by: Igor Mammedov Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Cc: Joe Mario Cc: Jiri Kosina Cc: Peter Zijlstra Cc: kvm@vger.kernel.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/e3a85d585da28cc333ecbc1e78ee9216e6da9396.1548794349.git.jpoimboe@redhat.com Signed-off-by: Greg Kroah-Hartman commit c645d81d70579acbdebbda16f0dc003a9c6d223a Author: Peter Shier Date: Thu Oct 11 11:46:46 2018 -0700 KVM: nVMX: unconditionally cancel preemption timer in free_nested (CVE-2019-7221) commit ecec76885bcfe3294685dc363fd1273df0d5d65f upstream. Bugzilla: 1671904 There are multiple code paths where an hrtimer may have been started to emulate an L1 VMX preemption timer that can result in a call to free_nested without an intervening L2 exit where the hrtimer is normally cancelled. Unconditionally cancel in free_nested to cover all cases. Embargoed until Feb 7th 2019. Signed-off-by: Peter Shier Reported-by: Jim Mattson Reviewed-by: Jim Mattson Reported-by: Felix Wilhelm Cc: stable@kernel.org Message-Id: <20181011184646.154065-1-pshier@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit e02d0a24a0faa566b9c87c5c301255c5f203875c Author: Jann Horn Date: Sat Jan 26 01:54:33 2019 +0100 kvm: fix kvm_ioctl_create_device() reference counting (CVE-2019-6974) commit cfa39381173d5f969daf43582c95ad679189cbc9 upstream. kvm_ioctl_create_device() does the following: 1. creates a device that holds a reference to the VM object (with a borrowed reference, the VM's refcount has not been bumped yet) 2. initializes the device 3. transfers the reference to the device to the caller's file descriptor table 4. calls kvm_get_kvm() to turn the borrowed reference to the VM into a real reference The ownership transfer in step 3 must not happen before the reference to the VM becomes a proper, non-borrowed reference, which only happens in step 4. After step 3, an attacker can close the file descriptor and drop the borrowed reference, which can cause the refcount of the kvm object to drop to zero. This means that we need to grab a reference for the device before anon_inode_getfd(), otherwise the VM can disappear from under us. Fixes: 852b6d57dc7f ("kvm: add device control API") Cc: stable@kernel.org Signed-off-by: Jann Horn Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 69b8c405155e0dcaee718434ff7859b757641646 Author: Paolo Bonzini Date: Tue Jan 29 18:41:16 2019 +0100 KVM: x86: work around leak of uninitialized stack contents (CVE-2019-7222) commit 353c0956a618a07ba4bbe7ad00ff29fe70e8412a upstream. Bugzilla: 1671930 Emulation of certain instructions (VMXON, VMCLEAR, VMPTRLD, VMWRITE with memory operand, INVEPT, INVVPID) can incorrectly inject a page fault when passed an operand that points to an MMIO address. The page fault will use uninitialized kernel stack memory as the CR2 and error code. The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR exit to userspace; however, it is not an easy fix, so for now just ensure that the error code and CR2 are zero. Embargoed until Feb 7th 2019. Reported-by: Felix Wilhelm Cc: stable@kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit db584be34ec0c024c28de496f6766d6e5d4f490e Author: James Bottomley Date: Wed Jan 30 16:42:12 2019 -0800 scsi: aic94xx: fix module loading commit 42caa0edabd6a0a392ec36a5f0943924e4954311 upstream. The aic94xx driver is currently failing to load with errors like sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:03.0/0000:02:00.3/0000:07:02.0/revision' Because the PCI code had recently added a file named 'revision' to every PCI device. Fix this by renaming the aic94xx revision file to aic_revision. This is safe to do for us because as far as I can tell, there's nothing in userspace relying on the current aic94xx revision file so it can be renamed without breaking anything. Fixes: 702ed3be1b1b (PCI: Create revision file in sysfs) Cc: stable@vger.kernel.org Signed-off-by: James Bottomley Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 4dd5cccca1d853824adaac6be93d2e2ba17ce8c9 Author: Vaibhav Jain Date: Wed Jan 30 17:56:51 2019 +0530 scsi: cxlflash: Prevent deadlock when adapter probe fails commit bb61b843ffd46978d7ca5095453e572714934eeb upstream. Presently when an error is encountered during probe of the cxlflash adapter, a deadlock is seen with cpu thread stuck inside cxlflash_remove(). Below is the trace of the deadlock as logged by khungtaskd: cxlflash 0006:00:00.0: cxlflash_probe: init_afu failed rc=-16 INFO: task kworker/80:1:890 blocked for more than 120 seconds. Not tainted 5.0.0-rc4-capi2-kexec+ #2 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/80:1 D 0 890 2 0x00000808 Workqueue: events work_for_cpu_fn Call Trace: 0x4d72136320 (unreliable) __switch_to+0x2cc/0x460 __schedule+0x2bc/0xac0 schedule+0x40/0xb0 cxlflash_remove+0xec/0x640 [cxlflash] cxlflash_probe+0x370/0x8f0 [cxlflash] local_pci_probe+0x6c/0x140 work_for_cpu_fn+0x38/0x60 process_one_work+0x260/0x530 worker_thread+0x280/0x5d0 kthread+0x1a8/0x1b0 ret_from_kernel_thread+0x5c/0x80 INFO: task systemd-udevd:5160 blocked for more than 120 seconds. The deadlock occurs as cxlflash_remove() is called from cxlflash_probe() without setting 'cxlflash_cfg->state' to STATE_PROBED and the probe thread starts to wait on 'cxlflash_cfg->reset_waitq'. Since the device was never successfully probed the 'cxlflash_cfg->state' never changes from STATE_PROBING hence the deadlock occurs. We fix this deadlock by setting the variable 'cxlflash_cfg->state' to STATE_PROBED in case an error occurs during cxlflash_probe() and just before calling cxlflash_remove(). Cc: stable@vger.kernel.org Fixes: c21e0bbfc485("cxlflash: Base support for IBM CXL Flash Adapter") Signed-off-by: Vaibhav Jain Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0dcf211406abbd6a88f0e632976811e9fc8b5c5c Author: Damien Le Moal Date: Wed Jan 30 15:54:58 2019 +0900 scsi: sd_zbc: Fix zone information messages commit 88fc41c407158a7d2eaa4b2f7cfa289749d456c6 upstream. Commit bf5054569653 ("block: Introduce blk_revalidate_disk_zones()") inadvertently broke the message output of sd_zbc_print_zones() because the zone information initialization of the scsi disk structure was moved to the second scan run while sd_zbc_print_zones() is called on the first scan. This leads to the following incorrect message to be printed for any ZBC or ZAC zoned disks. "...[sdX] 4294967295 zones of 0 logical blocks + 1 runt zone" Fix this by initializing sdkp zone size and number of zones early on the first scan. This does not impact the execution of blk_revalidate_zones(). This functions is still called only once the block device capacity is set on the second revalidate run on boot, or if the disk zone configuration changed (i.e. the disk changed). Fixes: bf5054569653 ("block: Introduce blk_revalidate_disk_zones()") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit de07a864989d46dc2f8c2e9c8e2ad8d0a79da653 Author: Johan Hovold Date: Wed Jan 30 10:49:34 2019 +0100 staging: speakup: fix tty-operation NULL derefs commit a1960e0f1639cb1f7a3d94521760fc73091f6640 upstream. The send_xchar() and tiocmset() tty operations are optional. Add the missing sanity checks to prevent user-space triggerable NULL-pointer dereferences. Fixes: 6b9ad1c742bf ("staging: speakup: add send_xchar, tiocmset and input functionality for tty") Cc: stable # 4.13 Cc: Okash Khawaja Cc: Samuel Thibault Signed-off-by: Johan Hovold Reviewed-by: Samuel Thibault Signed-off-by: Greg Kroah-Hartman commit 92833f8076eae09978fe9d81cb29d911578dc919 Author: Paul Elder Date: Wed Jan 30 08:13:21 2019 -0600 usb: gadget: musb: fix short isoc packets with inventra dma commit c418fd6c01fbc5516a2cd1eaf1df1ec86869028a upstream. Handling short packets (length < max packet size) in the Inventra DMA engine in the MUSB driver causes the MUSB DMA controller to hang. An example of a problem that is caused by this problem is when streaming video out of a UVC gadget, only the first video frame is transferred. For short packets (mode-0 or mode-1 DMA), MUSB_TXCSR_TXPKTRDY must be set manually by the driver. This was previously done in musb_g_tx (musb_gadget.c), but incorrectly (all csr flags were cleared, and only MUSB_TXCSR_MODE and MUSB_TXCSR_TXPKTRDY were set). Fixing that problem allows some requests to be transferred correctly, but multiple requests were often put together in one USB packet, and caused problems if the packet size was not a multiple of 4. Instead, set MUSB_TXCSR_TXPKTRDY in dma_controller_irq (musbhsdma.c), just like host mode transfers. This topic was originally tackled by Nicolas Boichat [0] [1] and is discussed further at [2] as part of his GSoC project [3]. [0] https://groups.google.com/forum/?hl=en#!topic/beagleboard-gsoc/k8Azwfp75CU [1] https://gitorious.org/beagleboard-usbsniffer/beagleboard-usbsniffer-kernel/commit/b0be3b6cc195ba732189b04f1d43ec843c3e54c9?p=beagleboard-usbsniffer:beagleboard-usbsniffer-kernel.git;a=patch;h=b0be3b6cc195ba732189b04f1d43ec843c3e54c9 [2] http://beagleboard-usbsniffer.blogspot.com/2010/07/musb-isochronous-transfers-fixed.html [3] http://elinux.org/BeagleBoard/GSoC/USBSniffer Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support") Signed-off-by: Paul Elder Signed-off-by: Bin Liu Cc: stable Signed-off-by: Greg Kroah-Hartman commit 1e52f46f884d836d27cd20f1a386a3ef9b40cd54 Author: Gustavo A. R. Silva Date: Tue Jan 22 15:28:08 2019 -0600 usb: gadget: udc: net2272: Fix bitwise and boolean operations commit 07c69f1148da7de3978686d3af9263325d9d60bd upstream. (!x & y) strikes again. Fix bitwise and boolean operations by enclosing the expression: intcsr & (1 << NET2272_PCI_IRQ) in parentheses, before applying the boolean operator '!'. Notice that this code has been there since 2011. So, it would be helpful if someone can double-check this. This issue was detected with the help of Coccinelle. Fixes: ceb80363b2ec ("USB: net2272: driver for PLX NET2272 USB device controller") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 003e5eab7547d87b0fed0eb4ce17ca5a43ee3ad0 Author: Tejas Joglekar Date: Tue Jan 22 13:26:51 2019 +0530 usb: dwc3: gadget: Handle 0 xfer length for OUT EP commit 1e19cdc8060227b0802bda6bc0bd22b23679ba32 upstream. For OUT endpoints, zero-length transfers require MaxPacketSize buffer as per the DWC_usb3 programming guide 3.30a section 4.2.3.3. This patch fixes this by explicitly checking zero length transfer to correctly pad up to MaxPacketSize. Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable@vger.kernel.org Signed-off-by: Tejas Joglekar Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d021bb6cd02ac79ad9ce084030872ddba0e7b63b Author: Bin Liu Date: Wed Jan 16 11:54:07 2019 -0600 usb: phy: am335x: fix race condition in _probe commit a53469a68eb886e84dd8b69a1458a623d3591793 upstream. power off the phy should be done before populate the phy. Otherwise, am335x_init() could be called by the phy owner to power on the phy first, then am335x_phy_probe() turns off the phy again without the caller knowing it. Fixes: 2fc711d76352 ("usb: phy: am335x: Enable USB remote wakeup using PHY wakeup") Cc: stable@vger.kernel.org # v3.18+ Signed-off-by: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 191db00080a968a58c22fb42c9cebabd536898da Author: Jernej Skrabec Date: Wed Jan 9 19:16:04 2019 +0100 arm64: dts: allwinner: a64: Fix USB OTG regulator commit b1360dcfdaa1d55952e5ec8dd9d99f88965d7ac9 upstream. Currently, AXP803 driver assumes that reg_drivevbus is input which is wrong. Unfortunate consequence of that is that none of the USB ports work on the board, even USB HOST port, because USB PHY driver probing fails due to missing regulator. Fix that by adding "x-powers,drive-vbus-en" property to AXP803 node. Fixes: 14ff5d8f9151 ("arm64: dts: allwinner: a64: Orange Pi Win: Enable USB OTG socket") Cc: stable@vger.kernel.org Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit 2894d62102a676fcbcf2ed3f902af720196cfc3b Author: Marc Zyngier Date: Tue Jan 29 10:02:33 2019 +0000 irqchip/gic-v3-its: Plug allocation race for devices sharing a DevID commit 9791ec7df0e7b4d80706ccea8f24b6542f6059e9 upstream. On systems or VMs where multiple devices share a single DevID (because they sit behind a PCI bridge, or because the HW is broken in funky ways), we reuse the save its_device structure in order to reflect this. It turns out that there is a distinct lack of locking when looking up the its_device, and two device being probed concurrently can result in double allocations. That's obviously not nice. A solution for this is to have a per-ITS mutex that serializes device allocation. A similar issue exists on the freeing side, which can run concurrently with the allocation. On top of now taking the appropriate lock, we also make sure that a shared device is never freed, as we have no way to currently track the life cycle of such object. Reported-by: Zheng Xiang Tested-by: Zheng Xiang Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 6a6f4647455d2154cc9b5d94c390cb4526e3e55f Author: Thomas Gleixner Date: Tue Jan 29 23:15:12 2019 +0100 futex: Handle early deadlock return correctly commit 1a1fb985f2e2b85ec0d3dc2e519ee48389ec2434 upstream. commit 56222b212e8e ("futex: Drop hb->lock before enqueueing on the rtmutex") changed the locking rules in the futex code so that the hash bucket lock is not longer held while the waiter is enqueued into the rtmutex wait list. This made the lock and the unlock path symmetric, but unfortunately the possible early exit from __rt_mutex_proxy_start() due to a detected deadlock was not updated accordingly. That allows a concurrent unlocker to observe inconsitent state which triggers the warning in the unlock path. futex_lock_pi() futex_unlock_pi() lock(hb->lock) queue(hb_waiter) lock(hb->lock) lock(rtmutex->wait_lock) unlock(hb->lock) // acquired hb->lock hb_waiter = futex_top_waiter() lock(rtmutex->wait_lock) __rt_mutex_proxy_start() ---> fail remove(rtmutex_waiter); ---> returns -EDEADLOCK unlock(rtmutex->wait_lock) // acquired wait_lock wake_futex_pi() rt_mutex_next_owner() --> returns NULL --> WARN lock(hb->lock) unqueue(hb_waiter) The problem is caused by the remove(rtmutex_waiter) in the failure case of __rt_mutex_proxy_start() as this lets the unlocker observe a waiter in the hash bucket but no waiter on the rtmutex, i.e. inconsistent state. The original commit handles this correctly for the other early return cases (timeout, signal) by delaying the removal of the rtmutex waiter until the returning task reacquired the hash bucket lock. Treat the failure case of __rt_mutex_proxy_start() in the same way and let the existing cleanup code handle the eventual handover of the rtmutex gracefully. The regular rt_mutex_proxy_start() gains the rtmutex waiter removal for the failure case, so that the other callsites are still operating correctly. Add proper comments to the code so all these details are fully documented. Thanks to Peter for helping with the analysis and writing the really valuable code comments. Fixes: 56222b212e8e ("futex: Drop hb->lock before enqueueing on the rtmutex") Reported-by: Heiko Carstens Co-developed-by: Peter Zijlstra Signed-off-by: Peter Zijlstra Signed-off-by: Thomas Gleixner Tested-by: Heiko Carstens Cc: Martin Schwidefsky Cc: linux-s390@vger.kernel.org Cc: Stefan Liebler Cc: Sebastian Sewior Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1901292311410.1950@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman commit dfaa3232fc0634167a08a703b2c44db9409d6daa Author: Leonid Iziumtsev Date: Tue Jan 15 17:15:23 2019 +0000 dmaengine: imx-dma: fix wrong callback invoke commit 341198eda723c8c1cddbb006a89ad9e362502ea2 upstream. Once the "ld_queue" list is not empty, next descriptor will migrate into "ld_active" list. The "desc" variable will be overwritten during that transition. And later the dmaengine_desc_get_callback_invoke() will use it as an argument. As result we invoke wrong callback. That behaviour was in place since: commit fcaaba6c7136 ("dmaengine: imx-dma: fix callback path in tasklet"). But after commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") things got worse, since possible delay between tasklet_schedule() from DMA irq handler and actual tasklet function execution got bigger. And that gave more time for new DMA request to be submitted and to be put into "ld_queue" list. It has been noticed that DMA issue is causing problems for "mxc-mmc" driver. While stressing the system with heavy network traffic and writing/reading to/from sd card simultaneously the timeout may happen: 10013000.sdhci: mxcmci_watchdog: read time out (status = 0x30004900) That often lead to file system corruption. Signed-off-by: Leonid Iziumtsev Signed-off-by: Vinod Koul Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4209b907121aeb63498cd7259f65d40ab32545c8 Author: Lukas Wunner Date: Wed Jan 23 09:26:00 2019 +0100 dmaengine: bcm2835: Fix abort of transactions commit 9e528c799d17a4ac37d788c81440b50377dd592d upstream. There are multiple issues with bcm2835_dma_abort() (which is called on termination of a transaction): * The algorithm to abort the transaction first pauses the channel by clearing the ACTIVE flag in the CS register, then waits for the PAUSED flag to clear. Page 49 of the spec documents the latter as follows: "Indicates if the DMA is currently paused and not transferring data. This will occur if the active bit has been cleared [...]" https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf So the function is entering an infinite loop because it is waiting for PAUSED to clear which is always set due to the function having cleared the ACTIVE flag. The only thing that's saving it from itself is the upper bound of 10000 loop iterations. The code comment says that the intention is to "wait for any current AXI transfer to complete", so the author probably wanted to check the WAITING_FOR_OUTSTANDING_WRITES flag instead. Amend the function accordingly. * The CS register is only read at the beginning of the function. It needs to be read again after pausing the channel and before checking for outstanding writes, otherwise writes which were issued between the register read at the beginning of the function and pausing the channel may not be waited for. * The function seeks to abort the transfer by writing 0 to the NEXTCONBK register and setting the ABORT and ACTIVE flags. Thereby, the 0 in NEXTCONBK is sought to be loaded into the CONBLK_AD register. However experimentation has shown this approach to not work: The CONBLK_AD register remains the same as before and the CS register contains 0x00000030 (PAUSED | DREQ_STOPS_DMA). In other words, the control block is not aborted but merely paused and it will be resumed once the next DMA transaction is started. That is absolutely not the desired behavior. A simpler approach is to set the channel's RESET flag instead. This reliably zeroes the NEXTCONBK as well as the CS register. It requires less code and only a single MMIO write. This is also what popular user space DMA drivers do, e.g.: https://github.com/metachris/RPIO/blob/master/source/c_pwm/pwm.c Note that the spec is contradictory whether the NEXTCONBK register is writeable at all. On the one hand, page 41 claims: "The value loaded into the NEXTCONBK register can be overwritten so that the linked list of Control Block data structures can be dynamically altered. However it is only safe to do this when the DMA is paused." On the other hand, page 40 specifies: "Only three registers in each channel's register set are directly writeable (CS, CONBLK_AD and DEBUG). The other registers (TI, SOURCE_AD, DEST_AD, TXFR_LEN, STRIDE & NEXTCONBK), are automatically loaded from a Control Block data structure held in external memory." Fixes: 96286b576690 ("dmaengine: Add support for BCM2835") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.14+ Cc: Frank Pavlic Cc: Martin Sperl Cc: Florian Meier Cc: Clive Messer Cc: Matthias Reichl Tested-by: Stefan Wahren Acked-by: Florian Kauer Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 06c383c99976e953b5fe66c70b21b8d3d320e4a0 Author: Lukas Wunner Date: Wed Jan 23 09:26:00 2019 +0100 dmaengine: bcm2835: Fix interrupt race on RT commit f7da7782aba92593f7b82f03d2409a1c5f4db91b upstream. If IRQ handlers are threaded (either because CONFIG_PREEMPT_RT_BASE is enabled or "threadirqs" was passed on the command line) and if system load is sufficiently high that wakeup latency of IRQ threads degrades, SPI DMA transactions on the BCM2835 occasionally break like this: ks8851 spi0.0: SPI transfer timed out bcm2835-dma 3f007000.dma: DMA transfer could not be terminated ks8851 spi0.0 eth2: ks8851_rdfifo: spi_sync() failed The root cause is an assumption made by the DMA driver which is documented in a code comment in bcm2835_dma_terminate_all(): /* * Stop DMA activity: we assume the callback will not be called * after bcm_dma_abort() returns (even if it does, it will see * c->desc is NULL and exit.) */ That assumption falls apart if the IRQ handler bcm2835_dma_callback() is threaded: A client may terminate a descriptor and issue a new one before the IRQ handler had a chance to run. In fact the IRQ handler may miss an *arbitrary* number of descriptors. The result is the following race condition: 1. A descriptor finishes, its interrupt is deferred to the IRQ thread. 2. A client calls dma_terminate_async() which sets channel->desc = NULL. 3. The client issues a new descriptor. Because channel->desc is NULL, bcm2835_dma_issue_pending() immediately starts the descriptor. 4. Finally the IRQ thread runs and writes BCM2835_DMA_INT to the CS register to acknowledge the interrupt. This clears the ACTIVE flag, so the newly issued descriptor is paused in the middle of the transaction. Because channel->desc is not NULL, the IRQ thread finalizes the descriptor and tries to start the next one. I see two possible solutions: The first is to call synchronize_irq() in bcm2835_dma_issue_pending() to wait until the IRQ thread has finished before issuing a new descriptor. The downside of this approach is unnecessary latency if clients desire rapidly terminating and re-issuing descriptors and don't have any use for an IRQ callback. (The SPI TX DMA channel is a case in point.) A better alternative is to make the IRQ thread recognize that it has missed descriptors and avoid finalizing the newly issued descriptor. So first of all, set the ACTIVE flag when acknowledging the interrupt. This keeps a newly issued descriptor running. If the descriptor was finished, the channel remains idle despite the ACTIVE flag being set. However the ACTIVE flag can then no longer be used to check whether the channel is idle, so instead check whether the register containing the current control block address is zero and finalize the current descriptor only if so. That way, there is no impact on latency and throughput if the client doesn't care for the interrupt: Only minimal additional overhead is introduced for non-cyclic descriptors as one further MMIO read is necessary per interrupt to check for idleness of the channel. Cyclic descriptors are sped up slightly by removing one MMIO write per interrupt. Fixes: 96286b576690 ("dmaengine: Add support for BCM2835") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.14+ Cc: Frank Pavlic Cc: Martin Sperl Cc: Florian Meier Cc: Clive Messer Cc: Matthias Reichl Tested-by: Stefan Wahren Acked-by: Florian Kauer Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit a8d5fb2f83c533379b8e78f5647c412e47009a46 Author: Vladis Dronov Date: Tue Jan 29 11:58:35 2019 +0100 HID: debug: fix the ring buffer implementation commit 13054abbaa4f1fd4e6f3b4b63439ec033b4c8035 upstream. Ring buffer implementation in hid_debug_event() and hid_debug_events_read() is strange allowing lost or corrupted data. After commit 717adfdaf147 ("HID: debug: check length before copy_to_user()") it is possible to enter an infinite loop in hid_debug_events_read() by providing 0 as count, this locks up a system. Fix this by rewriting the ring buffer implementation with kfifo and simplify the code. This fixes CVE-2019-3819. v2: fix an execution logic and add a comment v3: use __set_current_state() instead of set_current_state() Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187 Cc: stable@vger.kernel.org # v4.18+ Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping") Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()") Signed-off-by: Vladis Dronov Reviewed-by: Oleg Nesterov Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit f191c028cc33ca99c766dfafb92bbf1ea0f0f6d4 Author: Miklos Szeredi Date: Wed Jan 16 10:27:59 2019 +0100 cuse: fix ioctl commit 8a3177db59cd644fde05ba9efee29392dfdec8aa upstream. cuse_process_init_reply() doesn't initialize fc->max_pages and thus all cuse bases ioctls fail with ENOMEM. Reported-by: Andreas Steinmetz Fixes: 5da784cce430 ("fuse: add max_pages to init_out") Cc: # v4.20 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 725af4227103da18f7c07e4d7fcb00c0dbcb49e9 Author: Miklos Szeredi Date: Wed Jan 16 10:27:59 2019 +0100 fuse: handle zero sized retrieve correctly commit 97e1532ef81acb31c30f9e75bf00306c33a77812 upstream. Dereferencing req->page_descs[0] will Oops if req->max_pages is zero. Reported-by: syzbot+c1e36d30ee3416289cc0@syzkaller.appspotmail.com Tested-by: syzbot+c1e36d30ee3416289cc0@syzkaller.appspotmail.com Fixes: b2430d7567a3 ("fuse: add per-page descriptor to fuse_req") Cc: # v3.9 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 598cebebe671be9b894c78eba7e50ca6f824c890 Author: Miklos Szeredi Date: Wed Jan 16 10:27:59 2019 +0100 fuse: decrement NR_WRITEBACK_TEMP on the right page commit a2ebba824106dabe79937a9f29a875f837e1b6d4 upstream. NR_WRITEBACK_TEMP is accounted on the temporary page in the request, not the page cache page. Fixes: 8b284dc47291 ("fuse: writepages: handle same page rewrites") Cc: # v3.13 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 4b10cee464a04a8b3809d400f231f41c0dad3fbd Author: Jann Horn Date: Sat Jan 12 02:39:05 2019 +0100 fuse: call pipe_buf_release() under pipe lock commit 9509941e9c534920ccc4771ae70bd6cbbe79df1c upstream. Some of the pipe_buf_release() handlers seem to assume that the pipe is locked - in particular, anon_pipe_buf_release() accesses pipe->tmp_page without taking any extra locks. From a glance through the callers of pipe_buf_release(), it looks like FUSE is the only one that calls pipe_buf_release() without having the pipe locked. This bug should only lead to a memory leak, nothing terrible. Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit b4063bffaceed685d9a3acbc188218da6af4b11a Author: Jeremy Soller Date: Wed Jan 30 16:12:31 2019 -0700 ALSA: hda/realtek - Headset microphone support for System76 darp5 commit 89e3a5682edaa4e5bb334719afb180256ac7bf78 upstream. On the System76 Darter Pro (darp5), there is a headset microphone input attached to 0x1a that does not have a jack detect. In order to get it working, the pin configuration needs to be set correctly, and the ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC fixup needs to be applied. This is similar to the MIC_NO_PRESENCE fixups for some Dell laptops, except we have a separate microphone jack that is already configured correctly. Signed-off-by: Jeremy Soller Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6beb90c8720382c4107b14785530728ebf11b130 Author: Takashi Iwai Date: Fri Feb 1 11:19:50 2019 +0100 ALSA: hda/realtek - Use a common helper for hp pin reference commit 35a39f98567d8d3f1cea48f0f30de1a7e736b644 upstream. Replace the open-codes in many places with a new common helper for performing the same thing: referring to the primary headphone pin. This eventually fixes the potentially missing headphone pin on some weird devices, too. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1c4f4d4ee7796d37854b026a430bfbbdd039ef70 Author: Kailang Yang Date: Fri Feb 1 16:51:10 2019 +0800 ALSA: hda/realtek - Fix lose hp_pins for disable auto mute commit d561aa0a70bb2e1dd85fde98b6a5561e4175ac3e upstream. When auto_mute = no or spec->suppress_auto_mute = 1, cfg->hp_pins will lose value. Add this patch to find hp_pins value. I add fixed for ALC282 ALC225 ALC256 ALC294 and alc_default_init() alc_default_shutup(). Signed-off-by: Kailang Yang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 970ad7a25df774538bc4457bbb62746086f62461 Author: Takashi Iwai Date: Wed Jan 30 17:46:03 2019 +0100 ALSA: hda - Serialize codec registrations commit 305a0ade180981686eec1f92aa6252a7c6ebb1cf upstream. In the current code, the codec registration may happen both at the codec bind time and the end of the controller probe time. In a rare occasion, they race with each other, leading to Oops due to the still uninitialized card device. This patch introduces a simple flag to prevent the codec registration at the codec bind time as long as the controller probe is going on. The controller probe invokes snd_card_register() that does the whole registration task, and we don't need to register each piece beforehand. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ec322b3e0e523ee18c3578d840460143c2209d70 Author: Udo Eberhardt Date: Tue Feb 5 17:20:47 2019 +0100 ALSA: usb-audio: Add support for new T+A USB DAC commit 3bff2407fbd28fd55ad5b5cccd98fc0c9598f23b upstream. This patch adds the T+A VID to the generic check in order to enable native DSD support for T+A devices. This works with the new T+A USB DAC model SD3100HV and will also work with future devices which support the XMOS/Thesycon style DSD format. Signed-off-by: Udo Eberhardt Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 18a47b483ba0d713e287beb695acea683c14a0eb Author: Charles Keepax Date: Tue Feb 5 16:29:40 2019 +0000 ALSA: compress: Fix stop handling on compressed capture streams commit 4f2ab5e1d13d6aa77c55f4914659784efd776eb4 upstream. It is normal user behaviour to start, stop, then start a stream again without closing it. Currently this works for compressed playback streams but not capture ones. The states on a compressed capture stream go directly from OPEN to PREPARED, unlike a playback stream which moves to SETUP and waits for a write of data before moving to PREPARED. Currently however, when a stop is sent the state is set to SETUP for both types of streams. This leaves a capture stream in the situation where a new start can't be sent as that requires the state to be PREPARED and a new set_params can't be sent as that requires the state to be OPEN. The only option being to close the stream, and then reopen. Correct this issues by allowing snd_compr_drain_notify to set the state depending on the stream direction, as we already do in set_params. Fixes: 49bb6402f1aa ("ALSA: compress_core: Add support for capture streams") Signed-off-by: Charles Keepax Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d512397265e89b2a11497b8ef21b685c81a326b1 Author: Brian Foster Date: Fri Feb 1 09:36:36 2019 -0800 xfs: eof trim writeback mapping as soon as it is cached commit aa6ee4ab69293969867ab09b57546d226ace3d7a upstream. The cached writeback mapping is EOF trimmed to try and avoid races between post-eof block management and writeback that result in sending cached data to a stale location. The cached mapping is currently trimmed on the validation check, which leaves a race window between the time the mapping is cached and when it is trimmed against the current inode size. For example, if a new mapping is cached by delalloc conversion on a blocksize == page size fs, we could cycle various locks, perform memory allocations, etc. in the writeback codepath before the associated mapping is eventually trimmed to i_size. This leaves enough time for a post-eof truncate and file append before the cached mapping is trimmed. The former event essentially invalidates a range of the cached mapping and the latter bumps the inode size such the trim on the next writepage event won't trim all of the invalid blocks. fstest generic/464 reproduces this scenario occasionally and causes a lost writeback and stale delalloc blocks warning on inode inactivation. To work around this problem, trim the cached writeback mapping as soon as it is cached in addition to on subsequent validation checks. This is a minor tweak to tighten the race window as much as possible until a proper invalidation mechanism is available. Fixes: 40214d128e07 ("xfs: trim writepage mapping to within eof") Cc: # v4.14+ Signed-off-by: Brian Foster Reviewed-by: Allison Henderson Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit 66e966082e12673cfbd3359c859fcebf1e2d7262 Author: Cong Wang Date: Mon Dec 3 22:14:04 2018 -0800 net/mlx5e: Force CHECKSUM_UNNECESSARY for short ethernet frames [ Upstream commit e8c8b53ccaff568fef4c13a6ccaf08bf241aa01a ] When an ethernet frame is padded to meet the minimum ethernet frame size, the padding octets are not covered by the hardware checksum. Fortunately the padding octets are usually zero's, which don't affect checksum. However, we have a switch which pads non-zero octets, this causes kernel hardware checksum fault repeatedly. Prior to: commit '88078d98d1bb ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE ...")' skb checksum was forced to be CHECKSUM_NONE when padding is detected. After it, we need to keep skb->csum updated, like what we do for RXFCS. However, fixing up CHECKSUM_COMPLETE requires to verify and parse IP headers, it is not worthy the effort as the packets are so small that CHECKSUM_COMPLETE can't save anything. Fixes: 88078d98d1bb ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"), Cc: Eric Dumazet Cc: Tariq Toukan Cc: Nikola Ciprich Signed-off-by: Cong Wang Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 1b07bc1c10cc14a2729c035848e4f860f631d863 Author: Guy Shattah Date: Mon Jan 28 13:58:07 2019 +0000 net/mlx5e: Use the inner headers to determine tc/pedit offload limitation on decap flows [ Upstream commit 1651925d403e077e3fc86f961905e27c6810e132 ] In packets that need to be decaped the internal headers have to be checked, not the external ones. Fixes: bdd66ac0aeed ("net/mlx5e: Disallow TC offloading of unsupported match/action combinations") Signed-off-by: Guy Shattah Reviewed-by: Or Gerlitz Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 49731b4b109090f1f2a7323c19f13ba046c044d9 Author: Arun Parameswaran Date: Thu Feb 7 16:01:18 2019 -0800 net: dsa: b53: Fix for failure when irq is not defined in dt [ Upstream commit 39841cc1cbb69344539c98a1fa9d858ed124c7ba ] Fixes the issues with non BCM58XX chips in the b53 driver failing, when the irq is not specified in the device tree. Removed the check for BCM58XX in b53_srab_prepare_irq(), so the 'port->irq' will be set to '-EXIO' if the irq is not specified in the device tree. Fixes: 16994374a6fc ("net: dsa: b53: Make SRAB driver manage port interrupts") Fixes: b2ddc48a81b5 ("net: dsa: b53: Do not fail when IRQ are not initialized") Signed-off-by: Arun Parameswaran Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f4016379d01c17ea09dbdaac4c485139376ec734 Author: Petr Machata Date: Mon Feb 4 14:50:38 2019 +0000 net: cls_flower: Remove filter from mask before freeing it [ Upstream commit c1f7e02979edd7a3a3e69fe04be60b1d650dc8a7 ] In fl_change(), when adding a new rule (i.e. fold == NULL), a driver may reject the new rule, for example due to resource exhaustion. By that point, the new rule was already assigned a mask, and it was added to that mask's hash table. The clean-up path that's invoked as a result of the rejection however neglects to undo the hash table addition, and proceeds to free the new rule, thus leaving a dangling pointer in the hash table. Fix by removing fnew from the mask's hash table before it is freed. Fixes: 35cc3cefc4de ("net/sched: cls_flower: Reject duplicated rules also under skip_sw") Signed-off-by: Petr Machata Acked-by: Jiri Pirko Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 62c2a5b857f2f250d561a81f941dacf896688c4d Author: Michael Chan Date: Thu Jan 31 14:31:48 2019 -0500 bnxt_en: Disable interrupts when allocating CP rings or NQs. [ Upstream commit 5e66e35aab335b83d9ffb220d8a3a13986a7a60e ] When calling firmware to allocate a CP ring or NQ, an interrupt associated with that ring may be generated immediately before the doorbell is even setup after the firmware call returns. When servicing the interrupt, the driver may crash when trying to access the doorbell. Fix it by disabling interrupt on that vector until the doorbell is set up. Fixes: 697197e5a173 ("bnxt_en: Re-structure doorbells.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 95880f9fc0d91852104251eecf7d022363c332f3 Author: Toshiaki Makita Date: Thu Jan 31 20:40:30 2019 +0900 virtio_net: Account for tx bytes and packets on sending xdp_frames [ Upstream commit 546f28974d771b124fb0bf7b551b343888cf0419 ] Previously virtnet_xdp_xmit() did not account for device tx counters, which caused confusions. To be consistent with SKBs, account them on freeing xdp_frames. Reported-by: David Ahern Signed-off-by: Toshiaki Makita Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 708a1911aa2c5462d5722a431339d77c3bf323ab Author: Dan Carpenter Date: Fri Feb 1 11:28:16 2019 +0300 skge: potential memory corruption in skge_get_regs() [ Upstream commit 294c149a209c6196c2de85f512b52ef50f519949 ] The "p" buffer is 0x4000 bytes long. B3_RI_WTO_R1 is 0x190. The value of "regs->len" is in the 1-0x4000 range. The bug here is that "regs->len - B3_RI_WTO_R1" can be a negative value which would lead to memory corruption and an abrupt crash. Fixes: c3f8be961808 ("[PATCH] skge: expand ethtool debug register dump") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cc3a83d1428693d6039387a8bedbfe970d629867 Author: Greg Kroah-Hartman Date: Fri Feb 1 15:15:22 2019 +0100 sctp: walk the list of asoc safely [ Upstream commit ba59fb0273076637f0add4311faa990a5eec27c0 ] In sctp_sendmesg(), when walking the list of endpoint associations, the association can be dropped from the list, making the list corrupt. Properly handle this by using list_for_each_entry_safe() Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg") Reported-by: Secunia Research Tested-by: Secunia Research Signed-off-by: Greg Kroah-Hartman Acked-by: Marcelo Ricardo Leitner Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4fbbfcb2ef472c4810842fac022344f29aa14196 Author: Xin Long Date: Mon Feb 4 03:27:58 2019 +0800 sctp: check and update stream->out_curr when allocating stream_out [ Upstream commit cfe4bd7a257f6d6f81d3458d8c9d9ec4957539e6 ] Now when using stream reconfig to add out streams, stream->out will get re-allocated, and all old streams' information will be copied to the new ones and the old ones will be freed. So without stream->out_curr updated, next time when trying to send from stream->out_curr stream, a panic would be caused. This patch is to check and update stream->out_curr when allocating stream_out. v1->v2: - define fa_index() to get elem index from stream->out_curr. v2->v3: - repost with no change. Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") Reported-by: Ying Xu Reported-by: syzbot+e33a3a138267ca119c7d@syzkaller.appspotmail.com Signed-off-by: Xin Long Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 138b6286638988d1d455338649803956cd19adcf Author: Eric Dumazet Date: Mon Feb 4 08:36:06 2019 -0800 rxrpc: bad unlock balance in rxrpc_recvmsg [ Upstream commit 6dce3c20ac429e7a651d728e375853370c796e8d ] When either "goto wait_interrupted;" or "goto wait_error;" paths are taken, socket lock has already been released. This patch fixes following syzbot splat : WARNING: bad unlock balance detected! 5.0.0-rc4+ #59 Not tainted ------------------------------------- syz-executor223/8256 is trying to release lock (sk_lock-AF_RXRPC) at: [] rxrpc_recvmsg+0x6d3/0x3099 net/rxrpc/recvmsg.c:598 but there are no more locks to release! other info that might help us debug this: 1 lock held by syz-executor223/8256: #0: 00000000fa9ed0f4 (slock-AF_RXRPC){+...}, at: spin_lock_bh include/linux/spinlock.h:334 [inline] #0: 00000000fa9ed0f4 (slock-AF_RXRPC){+...}, at: release_sock+0x20/0x1c0 net/core/sock.c:2798 stack backtrace: CPU: 1 PID: 8256 Comm: syz-executor223 Not tainted 5.0.0-rc4+ #59 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_unlock_imbalance_bug kernel/locking/lockdep.c:3391 [inline] print_unlock_imbalance_bug.cold+0x114/0x123 kernel/locking/lockdep.c:3368 __lock_release kernel/locking/lockdep.c:3601 [inline] lock_release+0x67e/0xa00 kernel/locking/lockdep.c:3860 sock_release_ownership include/net/sock.h:1471 [inline] release_sock+0x183/0x1c0 net/core/sock.c:2808 rxrpc_recvmsg+0x6d3/0x3099 net/rxrpc/recvmsg.c:598 sock_recvmsg_nosec net/socket.c:794 [inline] sock_recvmsg net/socket.c:801 [inline] sock_recvmsg+0xd0/0x110 net/socket.c:797 __sys_recvfrom+0x1ff/0x350 net/socket.c:1845 __do_sys_recvfrom net/socket.c:1863 [inline] __se_sys_recvfrom net/socket.c:1859 [inline] __x64_sys_recvfrom+0xe1/0x1a0 net/socket.c:1859 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x446379 Code: e8 2c b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fe5da89fd98 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00000000006dbc28 RCX: 0000000000446379 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00000000006dbc20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dbc2c R13: 0000000000000000 R14: 0000000000000000 R15: 20c49ba5e353f7cf Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Signed-off-by: Eric Dumazet Cc: David Howells Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ebac0b806cac2120aa63c710a7dd4c16e5d8607e Author: Russell King Date: Thu Jan 31 16:59:46 2019 +0000 Revert "net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x" [ Upstream commit c14f07c6211cc01d52ed92cce1fade5071b8d197 ] This reverts commit 6623c0fba10ef45b64ca213ad5dec926f37fa9a0. The original diagnosis was incorrect: it appears that the NIC had PHY polling mode enabled, which meant that it overwrote the PHYs advertisement register during negotiation. Signed-off-by: Russell King Tested-by: Yonglong Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 94f70056bac9cda1adc52891cdbba2b20c1b3baa Author: Eric Dumazet Date: Thu Jan 31 08:47:10 2019 -0800 rds: fix refcount bug in rds_sock_addref [ Upstream commit 6fa19f5637a6c22bc0999596bcc83bdcac8a4fa6 ] syzbot was able to catch a bug in rds [1] The issue here is that the socket might be found in a hash table but that its refcount has already be set to 0 by another cpu. We need to use refcount_inc_not_zero() to be safe here. [1] refcount_t: increment on 0; use-after-free. WARNING: CPU: 1 PID: 23129 at lib/refcount.c:153 refcount_inc_checked lib/refcount.c:153 [inline] WARNING: CPU: 1 PID: 23129 at lib/refcount.c:153 refcount_inc_checked+0x61/0x70 lib/refcount.c:151 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 23129 Comm: syz-executor3 Not tainted 5.0.0-rc4+ #53 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1db/0x2d0 lib/dump_stack.c:113 panic+0x2cb/0x65c kernel/panic.c:214 __warn.cold+0x20/0x48 kernel/panic.c:571 report_bug+0x263/0x2b0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] fixup_bug arch/x86/kernel/traps.c:173 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 RIP: 0010:refcount_inc_checked lib/refcount.c:153 [inline] RIP: 0010:refcount_inc_checked+0x61/0x70 lib/refcount.c:151 Code: 1d 51 63 c8 06 31 ff 89 de e8 eb 1b f2 fd 84 db 75 dd e8 a2 1a f2 fd 48 c7 c7 60 9f 81 88 c6 05 31 63 c8 06 01 e8 af 65 bb fd <0f> 0b eb c1 90 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 49 RSP: 0018:ffff8880a0cbf1e8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90006113000 RDX: 000000000001047d RSI: ffffffff81685776 RDI: 0000000000000005 RBP: ffff8880a0cbf1f8 R08: ffff888097c9e100 R09: ffffed1015ce5021 R10: ffffed1015ce5020 R11: ffff8880ae728107 R12: ffff8880723c20c0 R13: ffff8880723c24b0 R14: dffffc0000000000 R15: ffffed1014197e64 sock_hold include/net/sock.h:647 [inline] rds_sock_addref+0x19/0x20 net/rds/af_rds.c:675 rds_find_bound+0x97c/0x1080 net/rds/bind.c:82 rds_recv_incoming+0x3be/0x1430 net/rds/recv.c:362 rds_loop_xmit+0xf3/0x2a0 net/rds/loop.c:96 rds_send_xmit+0x1355/0x2a10 net/rds/send.c:355 rds_sendmsg+0x323c/0x44e0 net/rds/send.c:1368 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:631 __sys_sendto+0x387/0x5f0 net/socket.c:1788 __do_sys_sendto net/socket.c:1800 [inline] __se_sys_sendto net/socket.c:1796 [inline] __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x458089 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fc266df8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000458089 RDX: 0000000000000000 RSI: 00000000204b3fff RDI: 0000000000000005 RBP: 000000000073bf00 R08: 00000000202b4000 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc266df96d4 R13: 00000000004c56e4 R14: 00000000004d94a8 R15: 00000000ffffffff Fixes: cc4dfb7f70a3 ("rds: fix two RCU related problems") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Sowmini Varadhan Cc: Santosh Shilimkar Cc: rds-devel@oss.oracle.com Cc: Cong Wang Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0f063f878dcc6aceea4d6d25c24e9cb435ed7c37 Author: Florian Fainelli Date: Fri Feb 1 13:23:38 2019 -0800 net: systemport: Fix WoL with password after deep sleep [ Upstream commit 8dfb8d2cceb76b74ad5b58cc65c75994329b4d5e ] Broadcom STB chips support a deep sleep mode where all register contents are lost. Because we were stashing the MagicPacket password into some of these registers a suspend into that deep sleep then a resumption would not lead to being able to wake-up from MagicPacket with password again. Fix this by keeping a software copy of the password and program it during suspend. Fixes: 83e82f4c706b ("net: systemport: add Wake-on-LAN support") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 789a4b72d0780eb66ecdf2719a10fcd38f46e864 Author: Rundong Ge Date: Sat Feb 2 14:29:35 2019 +0000 net: dsa: slave: Don't propagate flag changes on down slave interfaces [ Upstream commit 17ab4f61b8cd6f9c38e9d0b935d86d73b5d0d2b5 ] The unbalance of master's promiscuity or allmulti will happen after ifdown and ifup a slave interface which is in a bridge. When we ifdown a slave interface , both the 'dsa_slave_close' and 'dsa_slave_change_rx_flags' will clear the master's flags. The flags of master will be decrease twice. In the other hand, if we ifup the slave interface again, since the slave's flags were cleared the 'dsa_slave_open' won't set the master's flag, only 'dsa_slave_change_rx_flags' that triggered by 'br_add_if' will set the master's flags. The flags of master is increase once. Only propagating flag changes when a slave interface is up makes sure this does not happen. The 'vlan_dev_change_rx_flags' had the same problem and was fixed, and changes here follows that fix. Fixes: 91da11f870f0 ("net: Distributed Switch Architecture protocol support") Signed-off-by: Rundong Ge Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1657d2814e83d3e338d6d60c5829d15d86645bc0 Author: Andrew Lunn Date: Wed Feb 6 00:02:58 2019 +0100 net: dsa: mv88e6xxx: Fix counting of ATU violations [ Upstream commit 75c05a74e745ae7d663b04d75777af80ada2233c ] The ATU port vector contains a bit per port of the switch. The code wrongly used it as a port number, and incremented a port counter. This resulted in the wrong interfaces counter being incremented, and potentially going off the end of the array of ports. Fix this by using the source port ID for the violation, which really is a port number. Reported-by: Chris Healy Tested-by: Chris Healy Fixes: 65f60e4582bd ("net: dsa: mv88e6xxx: Keep ATU/VTU violation statistics") Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 620f1379a59c039d0b9bd99ebcc8d6d50cba6386 Author: Dan Carpenter Date: Wed Feb 6 18:35:15 2019 +0300 net: dsa: Fix NULL checking in dsa_slave_set_eee() [ Upstream commit 00670cb8a73b10b10d3c40f045c15411715e4465 ] This function can't succeed if dp->pl is NULL. It will Oops inside the call to return phylink_ethtool_get_eee(dp->pl, e); Fixes: 1be52e97ed3e ("dsa: slave: eee: Allow ports to use phylink") Signed-off-by: Dan Carpenter Reviewed-by: Florian Fainelli Reviewed-by: Vivien Didelot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 324153413903e5cf009080a3eacf5ba44b397318 Author: Marc Zyngier Date: Sat Feb 2 17:53:29 2019 +0000 net: dsa: Fix lockdep false positive splat [ Upstream commit c8101f7729daee251f4f6505f9d135ec08e1342f ] Creating a macvtap on a DSA-backed interface results in the following splat when lockdep is enabled: [ 19.638080] IPv6: ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready [ 23.041198] device lan0 entered promiscuous mode [ 23.043445] device eth0 entered promiscuous mode [ 23.049255] [ 23.049557] ============================================ [ 23.055021] WARNING: possible recursive locking detected [ 23.060490] 5.0.0-rc3-00013-g56c857a1b8d3 #118 Not tainted [ 23.066132] -------------------------------------------- [ 23.071598] ip/2861 is trying to acquire lock: [ 23.076171] 00000000f61990cb (_xmit_ETHER){+...}, at: dev_set_rx_mode+0x1c/0x38 [ 23.083693] [ 23.083693] but task is already holding lock: [ 23.089696] 00000000ecf0c3b4 (_xmit_ETHER){+...}, at: dev_uc_add+0x24/0x70 [ 23.096774] [ 23.096774] other info that might help us debug this: [ 23.103494] Possible unsafe locking scenario: [ 23.103494] [ 23.109584] CPU0 [ 23.112093] ---- [ 23.114601] lock(_xmit_ETHER); [ 23.117917] lock(_xmit_ETHER); [ 23.121233] [ 23.121233] *** DEADLOCK *** [ 23.121233] [ 23.127325] May be due to missing lock nesting notation [ 23.127325] [ 23.134315] 2 locks held by ip/2861: [ 23.137987] #0: 000000003b766c72 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x338/0x4e0 [ 23.146231] #1: 00000000ecf0c3b4 (_xmit_ETHER){+...}, at: dev_uc_add+0x24/0x70 [ 23.153757] [ 23.153757] stack backtrace: [ 23.158243] CPU: 0 PID: 2861 Comm: ip Not tainted 5.0.0-rc3-00013-g56c857a1b8d3 #118 [ 23.166212] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT) [ 23.172843] Call trace: [ 23.175358] dump_backtrace+0x0/0x188 [ 23.179116] show_stack+0x14/0x20 [ 23.182524] dump_stack+0xb4/0xec [ 23.185928] __lock_acquire+0x123c/0x1860 [ 23.190048] lock_acquire+0xc8/0x248 [ 23.193724] _raw_spin_lock_bh+0x40/0x58 [ 23.197755] dev_set_rx_mode+0x1c/0x38 [ 23.201607] dev_set_promiscuity+0x3c/0x50 [ 23.205820] dsa_slave_change_rx_flags+0x5c/0x70 [ 23.210567] __dev_set_promiscuity+0x148/0x1e0 [ 23.215136] __dev_set_rx_mode+0x74/0x98 [ 23.219167] dev_uc_add+0x54/0x70 [ 23.222575] macvlan_open+0x170/0x1d0 [ 23.226336] __dev_open+0xe0/0x160 [ 23.229830] __dev_change_flags+0x16c/0x1b8 [ 23.234132] dev_change_flags+0x20/0x60 [ 23.238074] do_setlink+0x2d0/0xc50 [ 23.241658] __rtnl_newlink+0x5f8/0x6e8 [ 23.245601] rtnl_newlink+0x50/0x78 [ 23.249184] rtnetlink_rcv_msg+0x360/0x4e0 [ 23.253397] netlink_rcv_skb+0xe8/0x130 [ 23.257338] rtnetlink_rcv+0x14/0x20 [ 23.261012] netlink_unicast+0x190/0x210 [ 23.265043] netlink_sendmsg+0x288/0x350 [ 23.269075] sock_sendmsg+0x18/0x30 [ 23.272659] ___sys_sendmsg+0x29c/0x2c8 [ 23.276602] __sys_sendmsg+0x60/0xb8 [ 23.280276] __arm64_sys_sendmsg+0x1c/0x28 [ 23.284488] el0_svc_common+0xd8/0x138 [ 23.288340] el0_svc_handler+0x24/0x80 [ 23.292192] el0_svc+0x8/0xc This looks fairly harmless (no actual deadlock occurs), and is fixed in a similar way to c6894dec8ea9 ("bridge: fix lockdep addr_list_lock false positive splat") by putting the addr_list_lock in its own lockdep class. Signed-off-by: Marc Zyngier Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ce57b3e188214127e16996b03f37924bca9128a6 Author: Sebastian Andrzej Siewior Date: Mon Feb 4 11:20:29 2019 +0100 net: dp83640: expire old TX-skb [ Upstream commit 53bc8d2af08654659abfadfd3e98eb9922ff787c ] During sendmsg() a cloned skb is saved via dp83640_txtstamp() in ->tx_queue. After the NIC sends this packet, the PHY will reply with a timestamp for that TX packet. If the cable is pulled at the right time I don't see that packet. It might gets flushed as part of queue shutdown on NIC's side. Once the link is up again then after the next sendmsg() we enqueue another skb in dp83640_txtstamp() and have two on the list. Then the PHY will send a reply and decode_txts() attaches it to the first skb on the list. No crash occurs since refcounting works but we are one packet behind. linuxptp/ptp4l usually closes the socket and opens a new one (in such a timeout case) so those "stale" replies never get there. However it does not resume normal operation anymore. Purge old skbs in decode_txts(). Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.") Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Kurt Kanzenbach Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5dd31dbce9d9f6e91cc9b6b7db34f41d2ee4376b Author: Bart Van Assche Date: Wed Jan 30 10:42:30 2019 -0800 lib/test_rhashtable: Make test_insert_dup() allocate its hash table dynamically [ Upstream commit fc42a689c4c097859e5bd37b5ea11b60dc426df6 ] The test_insert_dup() function from lib/test_rhashtable.c passes a pointer to a stack object to rhltable_init(). Allocate the hash table dynamically to avoid that the following is reported with object debugging enabled: ODEBUG: object (ptrval) is on stack (ptrval), but NOT annotated. WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:368 __debug_object_init+0x312/0x480 Modules linked in: EIP: __debug_object_init+0x312/0x480 Call Trace: ? debug_object_init+0x1a/0x20 ? __init_work+0x16/0x30 ? rhashtable_init+0x1e1/0x460 ? sched_clock_cpu+0x57/0xe0 ? rhltable_init+0xb/0x20 ? test_insert_dup+0x32/0x20f ? trace_hardirqs_on+0x38/0xf0 ? ida_dump+0x10/0x10 ? jhash+0x130/0x130 ? my_hashfn+0x30/0x30 ? test_rht_init+0x6aa/0xab4 ? ida_dump+0x10/0x10 ? test_rhltable+0xc5c/0xc5c ? do_one_initcall+0x67/0x28e ? trace_hardirqs_off+0x22/0xe0 ? restore_all_kernel+0xf/0x70 ? trace_hardirqs_on_thunk+0xc/0x10 ? restore_all_kernel+0xf/0x70 ? kernel_init_freeable+0x142/0x213 ? rest_init+0x230/0x230 ? kernel_init+0x10/0x110 ? schedule_tail_wrapper+0x9/0xc ? ret_from_fork+0x19/0x24 Cc: Thomas Graf Cc: Herbert Xu Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Bart Van Assche Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0059e6721db9d37f626d72c8cd3a67fbfef0041f Author: Govindarajulu Varadarajan Date: Wed Jan 30 06:59:00 2019 -0800 enic: fix checksum validation for IPv6 [ Upstream commit 7596175e99b3d4bce28022193efd954c201a782a ] In case of IPv6 pkts, ipv4_csum_ok is 0. Because of this, driver does not set skb->ip_summed. So IPv6 rx checksum is not offloaded. Signed-off-by: Govindarajulu Varadarajan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb3e52a6ea30cf73d142059b4a7546ce99f04be4 Author: Eric Dumazet Date: Wed Jan 30 11:39:41 2019 -0800 dccp: fool proof ccid_hc_[rt]x_parse_options() [ Upstream commit 9b1f19d810e92d6cdc68455fbc22d9f961a58ce1 ] Similarly to commit 276bdb82dedb ("dccp: check ccid before dereferencing") it is wise to test for a NULL ccid. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0-rc3+ #37 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ccid_hc_tx_parse_options net/dccp/ccid.h:205 [inline] RIP: 0010:dccp_parse_options+0x8d9/0x12b0 net/dccp/options.c:233 Code: c5 0f b6 75 b3 80 38 00 0f 85 d6 08 00 00 48 b9 00 00 00 00 00 fc ff df 48 8b 45 b8 4c 8b b8 f8 07 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 08 00 0f 85 95 08 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b kobject: 'loop5' (0000000080f78fc1): kobject_uevent_env RSP: 0018:ffff8880a94df0b8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880858ac723 RCX: dffffc0000000000 RDX: 0000000000000100 RSI: 0000000000000007 RDI: 0000000000000001 RBP: ffff8880a94df140 R08: 0000000000000001 R09: ffff888061b83a80 R10: ffffed100c370752 R11: ffff888061b83a97 R12: 0000000000000026 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0defa33518 CR3: 000000008db5e000 CR4: 00000000001406e0 kobject: 'loop5' (0000000080f78fc1): fill_kobj_path: path = '/devices/virtual/block/loop5' DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: dccp_rcv_state_process+0x2b6/0x1af6 net/dccp/input.c:654 dccp_v4_do_rcv+0x100/0x190 net/dccp/ipv4.c:688 sk_backlog_rcv include/net/sock.h:936 [inline] __sk_receive_skb+0x3a9/0xea0 net/core/sock.c:473 dccp_v4_rcv+0x10cb/0x1f80 net/dccp/ipv4.c:880 ip_protocol_deliver_rcu+0xb6/0xa20 net/ipv4/ip_input.c:208 ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234 NF_HOOK include/linux/netfilter.h:289 [inline] NF_HOOK include/linux/netfilter.h:283 [inline] ip_local_deliver+0x1f0/0x740 net/ipv4/ip_input.c:255 dst_input include/net/dst.h:450 [inline] ip_rcv_finish+0x1f4/0x2f0 net/ipv4/ip_input.c:414 NF_HOOK include/linux/netfilter.h:289 [inline] NF_HOOK include/linux/netfilter.h:283 [inline] ip_rcv+0xed/0x620 net/ipv4/ip_input.c:524 __netif_receive_skb_one_core+0x160/0x210 net/core/dev.c:4973 __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083 process_backlog+0x206/0x750 net/core/dev.c:5923 napi_poll net/core/dev.c:6346 [inline] net_rx_action+0x76d/0x1930 net/core/dev.c:6412 __do_softirq+0x30b/0xb11 kernel/softirq.c:292 run_ksoftirqd kernel/softirq.c:654 [inline] run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646 smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164 kthread+0x357/0x430 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Modules linked in: ---[ end trace 58a0ba03bea2c376 ]--- RIP: 0010:ccid_hc_tx_parse_options net/dccp/ccid.h:205 [inline] RIP: 0010:dccp_parse_options+0x8d9/0x12b0 net/dccp/options.c:233 Code: c5 0f b6 75 b3 80 38 00 0f 85 d6 08 00 00 48 b9 00 00 00 00 00 fc ff df 48 8b 45 b8 4c 8b b8 f8 07 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 08 00 0f 85 95 08 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b RSP: 0018:ffff8880a94df0b8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880858ac723 RCX: dffffc0000000000 RDX: 0000000000000100 RSI: 0000000000000007 RDI: 0000000000000001 RBP: ffff8880a94df140 R08: 0000000000000001 R09: ffff888061b83a80 R10: ffffed100c370752 R11: ffff888061b83a97 R12: 0000000000000026 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0defa33518 CR3: 0000000009871000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 76afe9c2354c71f0d417f4a184ee7bc0f65396a1 Author: Eduardo Valentin Date: Wed Jan 2 00:34:03 2019 +0000 thermal: hwmon: inline helpers when CONFIG_THERMAL_HWMON is not set commit 03334ba8b425b2ad275c8f390cf83c7b081c3095 upstream. Avoid warnings like this: thermal_hwmon.h:29:1: warning: ‘thermal_remove_hwmon_sysfs’ defined but not used [-Wunused-function] thermal_remove_hwmon_sysfs(struct thermal_zone_device *tz) Fixes: 0dd88793aacd ("thermal: hwmon: move hwmon support to single file") Reviewed-by: Geert Uytterhoeven Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman commit d8cbd0a225f1148eabff850ba7f2721bd550fb07 Author: Chuck Lever Date: Wed Dec 19 10:58:40 2018 -0500 xprtrdma: Don't wake pending tasks until disconnect is done [ Upstream commit 0c0829bcf51aef713806e49b8ea2bac7962f54e2 ] Transport disconnect processing does a "wake pending tasks" at various points. Suppose an RPC Reply is being processed. The RPC task that Reply goes with is waiting on the pending queue. If a disconnect wake-up happens before reply processing is done, that reply, even if it is good, is thrown away, and the RPC has to be sent again. This window apparently does not exist for socket transports because there is a lock held while a reply is being received which prevents the wake-up call until after reply processing is done. To resolve this, all RPC replies being processed on an RPC-over-RDMA transport have to complete before pending tasks are awoken due to a transport disconnect. Callers that already hold the transport write lock may invoke ->ops->close directly. Others use a generic helper that schedules a close when the write lock can be taken safely. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 1700f82d6df8d2ab630096e44a70db6aa8eff928 Author: Du Changbin Date: Thu Jan 3 15:28:27 2019 -0800 scripts/gdb: fix lx-version string output [ Upstream commit b058809bfc8faeb7b7cae047666e23375a060059 ] A bug is present in GDB which causes early string termination when parsing variables. This has been reported [0], but we should ensure that we can support at least basic printing of the core kernel strings. For current gdb version (has been tested with 7.3 and 8.1), 'lx-version' only prints one character. (gdb) lx-version L(gdb) This can be fixed by casting 'linux_banner' as (char *). (gdb) lx-version Linux version 4.19.0-rc1+ (changbin@acer) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #21 SMP Sat Sep 1 21:43:30 CST 2018 [0] https://sourceware.org/bugzilla/show_bug.cgi?id=20077 [kbingham@kernel.org: add detail to commit message] Link: http://lkml.kernel.org/r/20181111162035.8356-1-kieran.bingham@ideasonboard.com Fixes: 2d061d999424 ("scripts/gdb: add version command") Signed-off-by: Du Changbin Signed-off-by: Kieran Bingham Acked-by: Jan Kiszka Cc: Jan Kiszka Cc: Jason Wessel Cc: Daniel Thompson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 563d89858aa50433aa0417aa236fb378b8094dcc Author: Anders Roxell Date: Thu Jan 3 15:28:24 2019 -0800 kernel/kcov.c: mark write_comp_data() as notrace [ Upstream commit 634724431607f6f46c495dfef801a1c8b44a96d9 ] Since __sanitizer_cov_trace_const_cmp4 is marked as notrace, the function called from __sanitizer_cov_trace_const_cmp4 shouldn't be traceable either. ftrace_graph_caller() gets called every time func write_comp_data() gets called if it isn't marked 'notrace'. This is the backtrace from gdb: #0 ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:179 #1 0xffffff8010201920 in ftrace_caller () at ../arch/arm64/kernel/entry-ftrace.S:151 #2 0xffffff8010439714 in write_comp_data (type=5, arg1=0, arg2=0, ip=18446743524224276596) at ../kernel/kcov.c:116 #3 0xffffff8010439894 in __sanitizer_cov_trace_const_cmp4 (arg1=, arg2=) at ../kernel/kcov.c:188 #4 0xffffff8010201874 in prepare_ftrace_return (self_addr=18446743524226602768, parent=0xffffff801014b918, frame_pointer=18446743524223531344) at ./include/generated/atomic-instrumented.h:27 #5 0xffffff801020194c in ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:182 Rework so that write_comp_data() that are called from __sanitizer_cov_trace_*_cmp*() are marked as 'notrace'. Commit 903e8ff86753 ("kernel/kcov.c: mark funcs in __sanitizer_cov_trace_pc() as notrace") missed to mark write_comp_data() as 'notrace'. When that patch was created gcc-7 was used. In lib/Kconfig.debug config KCOV_ENABLE_COMPARISONS depends on $(cc-option,-fsanitize-coverage=trace-cmp) That code path isn't hit with gcc-7. However, it were that with gcc-8. Link: http://lkml.kernel.org/r/20181206143011.23719-1-anders.roxell@linaro.org Signed-off-by: Anders Roxell Signed-off-by: Arnd Bergmann Co-developed-by: Arnd Bergmann Acked-by: Steven Rostedt (VMware) Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c3b081f9e2e3377af8c28336e23efab606268eb3 Author: Oleg Nesterov Date: Thu Jan 3 15:28:07 2019 -0800 exec: load_script: don't blindly truncate shebang string [ Upstream commit 8099b047ecc431518b9bb6bdbba3549bbecdc343 ] load_script() simply truncates bprm->buf and this is very wrong if the length of shebang string exceeds BINPRM_BUF_SIZE-2. This can silently truncate i_arg or (worse) we can execute the wrong binary if buf[2:126] happens to be the valid executable path. Change load_script() to return ENOEXEC if it can't find '\n' or zero in bprm->buf. Note that '\0' can come from either prepare_binprm()->memset() or from kernel_read(), we do not care. Link: http://lkml.kernel.org/r/20181112160931.GA28463@redhat.com Signed-off-by: Oleg Nesterov Acked-by: Kees Cook Acked-by: Michal Hocko Cc: Ben Woodard Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a2504f28543d165700f55159c2f9b38b36ea523f Author: Davidlohr Bueso Date: Thu Jan 3 15:27:09 2019 -0800 fs/epoll: drop ovflist branch prediction [ Upstream commit 76699a67f3041ff4c7af6d6ee9be2bfbf1ffb671 ] The ep->ovflist is a secondary ready-list to temporarily store events that might occur when doing sproc without holding the ep->wq.lock. This accounts for every time we check for ready events and also send events back to userspace; both callbacks, particularly the latter because of copy_to_user, can account for a non-trivial time. As such, the unlikely() check to see if the pointer is being used, seems both misleading and sub-optimal. In fact, we go to an awful lot of trouble to sync both lists, and populating the ovflist is far from an uncommon scenario. For example, profiling a concurrent epoll_wait(2) benchmark, with CONFIG_PROFILE_ANNOTATED_BRANCHES shows that for a two threads a 33% incorrect rate was seen; and when incrementally increasing the number of epoll instances (which is used, for example for multiple queuing load balancing models), up to a 90% incorrect rate was seen. Similarly, by deleting the prediction, 3% throughput boost was seen across incremental threads. Link: http://lkml.kernel.org/r/20181108051006.18751-4-dave@stgolabs.net Signed-off-by: Davidlohr Bueso Reviewed-by: Andrew Morton Cc: Al Viro Cc: Jason Baron Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ce53b938a27e6ed7dc486f482a83877e841fec80 Author: Liu, Chuansheng Date: Thu Jan 3 15:26:27 2019 -0800 kernel/hung_task.c: force console verbose before panic [ Upstream commit 168e06f7937d96c7222037d8a05565e8a6eb00fe ] Based on commit 401c636a0eeb ("kernel/hung_task.c: show all hung tasks before panic"), we could get the call stack of hung task. However, if the console loglevel is not high, we still can not see the useful panic information in practice, and in most cases users don't set console loglevel to high level. This patch is to force console verbose before system panic, so that the real useful information can be seen in the console, instead of being like the following, which doesn't have hung task information. INFO: task init:1 blocked for more than 120 seconds. Tainted: G U W 4.19.0-quilt-2e5dc0ac-g51b6c21d76cc #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Kernel panic - not syncing: hung_task: blocked tasks CPU: 2 PID: 479 Comm: khungtaskd Tainted: G U W 4.19.0-quilt-2e5dc0ac-g51b6c21d76cc #1 Call Trace: dump_stack+0x4f/0x65 panic+0xde/0x231 watchdog+0x290/0x410 kthread+0x12c/0x150 ret_from_fork+0x35/0x40 reboot: panic mode set: p,w Kernel Offset: 0x34000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Link: http://lkml.kernel.org/r/27240C0AC20F114CBF8149A2696CBE4A6015B675@SHSMSX101.ccr.corp.intel.com Signed-off-by: Chuansheng Liu Reviewed-by: Petr Mladek Reviewed-by: Sergey Senozhatsky Cc: Tetsuo Handa Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3afa6faf9fe8e676b442eed537bbfa3975e85910 Author: Cheng Lin Date: Thu Jan 3 15:26:13 2019 -0800 proc/sysctl: fix return error for proc_doulongvec_minmax() [ Upstream commit 09be178400829dddc1189b50a7888495dd26aa84 ] If the number of input parameters is less than the total parameters, an EINVAL error will be returned. For example, we use proc_doulongvec_minmax to pass up to two parameters with kern_table: { .procname = "monitor_signals", .data = &monitor_sigs, .maxlen = 2*sizeof(unsigned long), .mode = 0644, .proc_handler = proc_doulongvec_minmax, }, Reproduce: When passing two parameters, it's work normal. But passing only one parameter, an error "Invalid argument"(EINVAL) is returned. [root@cl150 ~]# echo 1 2 > /proc/sys/kernel/monitor_signals [root@cl150 ~]# cat /proc/sys/kernel/monitor_signals 1 2 [root@cl150 ~]# echo 3 > /proc/sys/kernel/monitor_signals -bash: echo: write error: Invalid argument [root@cl150 ~]# echo $? 1 [root@cl150 ~]# cat /proc/sys/kernel/monitor_signals 3 2 [root@cl150 ~]# The following is the result after apply this patch. No error is returned when the number of input parameters is less than the total parameters. [root@cl150 ~]# echo 1 2 > /proc/sys/kernel/monitor_signals [root@cl150 ~]# cat /proc/sys/kernel/monitor_signals 1 2 [root@cl150 ~]# echo 3 > /proc/sys/kernel/monitor_signals [root@cl150 ~]# echo $? 0 [root@cl150 ~]# cat /proc/sys/kernel/monitor_signals 3 2 [root@cl150 ~]# There are three processing functions dealing with digital parameters, __do_proc_dointvec/__do_proc_douintvec/__do_proc_doulongvec_minmax. This patch deals with __do_proc_doulongvec_minmax, just as __do_proc_dointvec does, adding a check for parameters 'left'. In __do_proc_douintvec, its code implementation explicitly does not support multiple inputs. static int __do_proc_douintvec(...){ ... /* * Arrays are not supported, keep this simple. *Do not* add * support for them. */ if (vleft != 1) { *lenp = 0; return -EINVAL; } ... } So, just __do_proc_doulongvec_minmax has the problem. And most use of proc_doulongvec_minmax/proc_doulongvec_ms_jiffies_minmax just have one parameter. Link: http://lkml.kernel.org/r/1544081775-15720-1-git-send-email-cheng.lin130@zte.com.cn Signed-off-by: Cheng Lin Acked-by: Luis Chamberlain Reviewed-by: Kees Cook Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a2e23bb60cc8884c35e08210d2827da82c8c1dd9 Author: Tetsuo Handa Date: Thu Jan 3 15:26:31 2019 -0800 kernel/hung_task.c: break RCU locks based on jiffies [ Upstream commit 304ae42739b108305f8d7b3eb3c1aec7c2b643a9 ] check_hung_uninterruptible_tasks() is currently calling rcu_lock_break() for every 1024 threads. But check_hung_task() is very slow if printk() was called, and is very fast otherwise. If many threads within some 1024 threads called printk(), the RCU grace period might be extended enough to trigger RCU stall warnings. Therefore, calling rcu_lock_break() for every some fixed jiffies will be safer. Link: http://lkml.kernel.org/r/1544800658-11423-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Tetsuo Handa Acked-by: Paul E. McKenney Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Dmitry Vyukov Cc: "Rafael J. Wysocki" Cc: Vitaly Kuznetsov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9de551e03fa4ac8d52b7988f2765e95725de4332 Author: Dave Martin Date: Fri Jan 4 13:09:50 2019 +0000 arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition [ Upstream commit ee1b465b303591d3a04d403122bbc0d7026520fb ] SVE_PT_REGS_OFFSET is supposed to indicate the offset for skipping over the ptrace NT_ARM_SVE header (struct user_sve_header) to the start of the SVE register data proper. However, currently SVE_PT_REGS_OFFSET is defined in terms of struct sve_context, which is wrong: that structure describes the SVE header in the signal frame, not in the ptrace regset. This patch fixes the definition to use the ptrace header structure struct user_sve_header instead. By good fortune, the two structures are the same size anyway, so there is no functional or ABI change. Signed-off-by: Dave Martin Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d04c62c35d4dd7d7cd6275c9e85e16c55caf9fa1 Author: Aditya Pakki Date: Mon Dec 24 15:39:14 2018 -0600 HID: lenovo: Add checks to fix of_led_classdev_register [ Upstream commit 6ae16dfb61bce538d48b7fe98160fada446056c5 ] In lenovo_probe_tpkbd(), the function of_led_classdev_register() could return an error value that is unchecked. The fix adds these checks. Signed-off-by: Aditya Pakki Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 42249cb24cf9509d872f7ab3d1a3afe7bdb61615 Author: Bjorn Andersson Date: Sun Dec 23 23:26:44 2018 -0800 thermal: generic-adc: Fix adc to temp interpolation [ Upstream commit 9d216211fded20fff301d0317af3238d8383634c ] First correct the edge case to return the last element if we're outside the range, rather than at the last element, so that interpolation is not omitted for points between the two last entries in the table. Then correct the formula to perform linear interpolation based the two points surrounding the read ADC value. The indices for temp are kept as "hi" and "lo" to pair with the adc indices, but there's no requirement that the temperature is provided in descendent order. mult_frac() is used to prevent issues with overflowing the int. Cc: Laxman Dewangan Signed-off-by: Bjorn Andersson Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit a36d7f038de9821ae21fde4ce17bd9c771c61ca6 Author: Finn Thain Date: Mon Dec 31 16:44:09 2018 +1100 block/swim3: Fix regression on PowerBook G3 [ Upstream commit 427c5ce4417cba0801fbf79c8525d1330704759c ] As of v4.20, the swim3 driver crashes when loaded on a PowerBook G3 (Wallstreet). MacIO PCI driver attached to Gatwick chipset MacIO PCI driver attached to Heathrow chipset swim3 0.00015000:floppy: [fd0] SWIM3 floppy controller in media bay 0.00013020:ch-a: ttyS0 at MMIO 0xf3013020 (irq = 16, base_baud = 230400) is a Z85c30 ESCC - Serial port 0.00013000:ch-b: ttyS1 at MMIO 0xf3013000 (irq = 17, base_baud = 230400) is a Z85c30 ESCC - Infrared port macio: fixed media-bay irq on gatwick macio: fixed left floppy irqs swim3 1.00015000:floppy: [fd1] Couldn't request interrupt Unable to handle kernel paging request for data at address 0x00000024 Faulting instruction address: 0xc02652f8 Oops: Kernel access of bad area, sig: 11 [#1] BE SMP NR_CPUS=2 PowerMac Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0 #2 NIP: c02652f8 LR: c026915c CTR: c0276d1c REGS: df43ba10 TRAP: 0300 Not tainted (4.20.0) MSR: 00009032 CR: 28228288 XER: 00000100 DAR: 00000024 DSISR: 40000000 GPR00: c026915c df43bac0 df439060 c0731524 df494700 00000000 c06e1c08 00000001 GPR08: 00000001 00000000 df5ff220 00001032 28228282 00000000 c0004ca4 00000000 GPR16: 00000000 00000000 00000000 c073144c dfffe064 c0731524 00000120 c0586108 GPR24: c073132c c073143c c073143c 00000000 c0731524 df67cd70 df494700 00000001 NIP [c02652f8] blk_mq_free_rqs+0x28/0xf8 LR [c026915c] blk_mq_sched_tags_teardown+0x58/0x84 Call Trace: [df43bac0] [c0045f50] flush_workqueue_prep_pwqs+0x178/0x1c4 (unreliable) [df43bae0] [c026915c] blk_mq_sched_tags_teardown+0x58/0x84 [df43bb00] [c02697f0] blk_mq_exit_sched+0x9c/0xb8 [df43bb20] [c0252794] elevator_exit+0x84/0xa4 [df43bb40] [c0256538] blk_exit_queue+0x30/0x50 [df43bb50] [c0256640] blk_cleanup_queue+0xe8/0x184 [df43bb70] [c034732c] swim3_attach+0x330/0x5f0 [df43bbb0] [c034fb24] macio_device_probe+0x58/0xec [df43bbd0] [c032ba88] really_probe+0x1e4/0x2f4 [df43bc00] [c032bd28] driver_probe_device+0x64/0x204 [df43bc20] [c0329ac4] bus_for_each_drv+0x60/0xac [df43bc50] [c032b824] __device_attach+0xe8/0x160 [df43bc80] [c032ab38] bus_probe_device+0xa0/0xbc [df43bca0] [c0327338] device_add+0x3d8/0x630 [df43bcf0] [c0350848] macio_add_one_device+0x444/0x48c [df43bd50] [c03509f8] macio_pci_add_devices+0x168/0x1bc [df43bd90] [c03500ec] macio_pci_probe+0xc0/0x10c [df43bda0] [c02ad884] pci_device_probe+0xd4/0x184 [df43bdd0] [c032ba88] really_probe+0x1e4/0x2f4 [df43be00] [c032bd28] driver_probe_device+0x64/0x204 [df43be20] [c032bfcc] __driver_attach+0x104/0x108 [df43be40] [c0329a00] bus_for_each_dev+0x64/0xb4 [df43be70] [c032add8] bus_add_driver+0x154/0x238 [df43be90] [c032ca24] driver_register+0x84/0x148 [df43bea0] [c0004aa0] do_one_initcall+0x40/0x188 [df43bf00] [c0690100] kernel_init_freeable+0x138/0x1d4 [df43bf30] [c0004cbc] kernel_init+0x18/0x10c [df43bf40] [c00121e4] ret_from_kernel_thread+0x14/0x1c Instruction dump: 5484d97e 4bfff4f4 9421ffe0 7c0802a6 bf410008 7c9e2378 90010024 8124005c 2f890000 419e0078 81230004 7c7c1b78 <81290024> 2f890000 419e0064 81440000 ---[ end trace 12025ab921a9784c ]--- Reverting commit 8ccb8cb1892b ("swim3: convert to blk-mq") resolves the problem. That commit added a struct blk_mq_tag_set to struct floppy_state and initialized it with a blk_mq_init_sq_queue() call. Unfortunately, there is a memset() in swim3_add_device() that subsequently clears the floppy_state struct. That means fs->tag_set->ops is a NULL pointer, and it gets dereferenced by blk_mq_free_rqs() which gets called in the request_irq() error path. Move the memset() to fix this bug. BTW, the request_irq() failure for the left mediabay floppy (fd1) is not a regression. I don't know why it happens. The right media bay floppy (fd0) works fine however. Reported-and-tested-by: Stan Johnson Fixes: 8ccb8cb1892b ("swim3: convert to blk-mq") Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Finn Thain Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5c300bb224eb47e8f77e9a8ed2b3a3a23e9312df Author: Richard Zhu Date: Fri Dec 21 04:33:38 2018 +0000 PCI: imx: Enable MSI from downstream components [ Upstream commit 75cb8d20c112aba70f23d98e3f8d0a38ace16006 ] The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2) controls whether a Function can request service using MSI. i.MX6 Root Ports implement the MSI Capability and may use MSI to request service for events like PME, hotplug, AER, etc. In addition, on i.MX6, the MSI Enable bit controls delivery of MSI interrupts from components below the Root Port. Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically also enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root Ports, it set the MSI Enable bit so it could use PME, hotplug, AER, etc. As a side effect, that also enabled delivery of MSI interrupts from downstream components. The imx6q-pcie driver itself does not depend on portdrv, so set MSI Enable in imx6q-pcie so MSI from downstream components works even if nobody uses MSI for the Root Port events. Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS") Signed-off-by: Richard Zhu Signed-off-by: Bjorn Helgaas Tested-by: Sven Van Asbroeck Tested-by: Trent Piepho Reviewed-by: Lucas Stach Acked-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 22723eecb95782fe0dd41f67e96b2ce22784a008 Author: Srinivas Kandagatla Date: Thu Nov 15 17:43:30 2018 +0000 thermal: tsens: qcom: do not create duplicate regmap debugfs entries [ Upstream commit 4ab248b3b10a58e379e2d32333fff99ea5ca256c ] Regmap would use device name to create debugfs entries. If the device has multiple regmaps it is recommended to use name field in regmap_config. Fix this by providing name to the regmap configs correctly. Without this patch we would see below error on DB820c. qcom-tsens 4a9000.thermal-sensor: Failed to create 4a9000.thermal-sensor debugfs directory Signed-off-by: Srinivas Kandagatla Acked-by: Amit Kucheria Tested-by: Amit Kucheria Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit 4a53bde834af3c7f81a6f1022e9395330b594922 Author: Douglas Anderson Date: Tue Dec 4 19:38:28 2018 -0800 kdb: Don't back trace on a cpu that didn't round up [ Upstream commit 162bc7f5afd75b72acbe3c5f3488ef7e64a3fe36 ] If you have a CPU that fails to round up and then run 'btc' you'll end up crashing in kdb becaue we dereferenced NULL. Let's add a check. It's wise to also set the task to NULL when leaving the debugger so that if we fail to round up on a later entry into the debugger we won't backtrace a stale task. Signed-off-by: Douglas Anderson Acked-by: Daniel Thompson Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit acd38b4d4eeab35c03e1aa0bf169ab3b8a7cad76 Author: Matthias Brugger Date: Sun Oct 21 23:58:48 2018 +0200 thermal: bcm2835: enable hwmon explicitly [ Upstream commit d56c19d07e0bc3ceff366a49b7d7a2440c967b1b ] By defaul of-based thermal driver do not enable hwmon. This patch does this explicitly, so that the temperature can be read through the common hwmon sysfs. Signed-off-by: Matthias Brugger Acked-by: Stefan Wahren Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit 41c8920c515619cd77e15f7ea3a97f52ae83aec6 Author: Finn Thain Date: Mon Dec 31 16:44:09 2018 +1100 block/swim3: Fix -EBUSY error when re-opening device after unmount [ Upstream commit 296dcc40f2f2e402facf7cd26cf3f2c8f4b17d47 ] When the block device is opened with FMODE_EXCL, ref_count is set to -1. This value doesn't get reset when the device is closed which means the device cannot be opened again. Fix this by checking for refcount <= 0 in the release method. Reported-and-tested-by: Stan Johnson Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Finn Thain Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f48987c8a42ab27857c31d3755cf27f05095cc20 Author: Scott Wood Date: Thu Dec 27 18:29:09 2018 -0600 fsl/fman: Use GFP_ATOMIC in {memac,tgec}_add_hash_mac_address() [ Upstream commit 0d9c9a238faf925823bde866182c663b6d734f2e ] These functions are called from atomic context: [ 9.150239] BUG: sleeping function called from invalid context at /home/scott/git/linux/mm/slab.h:421 [ 9.158159] in_atomic(): 1, irqs_disabled(): 0, pid: 4432, name: ip [ 9.163128] CPU: 8 PID: 4432 Comm: ip Not tainted 4.20.0-rc2-00169-g63d86876f324 #29 [ 9.163130] Call Trace: [ 9.170701] [c0000002e899a980] [c0000000009c1068] .dump_stack+0xa8/0xec (unreliable) [ 9.177140] [c0000002e899aa10] [c00000000007a7b4] .___might_sleep+0x138/0x164 [ 9.184440] [c0000002e899aa80] [c0000000001d5bac] .kmem_cache_alloc_trace+0x238/0x30c [ 9.191216] [c0000002e899ab40] [c00000000065ea1c] .memac_add_hash_mac_address+0x104/0x198 [ 9.199464] [c0000002e899abd0] [c00000000065a788] .set_multi+0x1c8/0x218 [ 9.206242] [c0000002e899ac80] [c0000000006615ec] .dpaa_set_rx_mode+0xdc/0x17c [ 9.213544] [c0000002e899ad00] [c00000000083d2b0] .__dev_set_rx_mode+0x80/0xd4 [ 9.219535] [c0000002e899ad90] [c00000000083d334] .dev_set_rx_mode+0x30/0x54 [ 9.225271] [c0000002e899ae10] [c00000000083d4a0] .__dev_open+0x148/0x1c8 [ 9.230751] [c0000002e899aeb0] [c00000000083d934] .__dev_change_flags+0x19c/0x1e0 [ 9.230755] [c0000002e899af60] [c00000000083d9a4] .dev_change_flags+0x2c/0x80 [ 9.242752] [c0000002e899aff0] [c0000000008554ec] .do_setlink+0x350/0xf08 [ 9.248228] [c0000002e899b170] [c000000000857ad0] .rtnl_newlink+0x588/0x7e0 [ 9.253965] [c0000002e899b740] [c000000000852424] .rtnetlink_rcv_msg+0x3e0/0x498 [ 9.261440] [c0000002e899b820] [c000000000884790] .netlink_rcv_skb+0x134/0x14c [ 9.267607] [c0000002e899b8e0] [c000000000851840] .rtnetlink_rcv+0x18/0x2c [ 9.274558] [c0000002e899b950] [c000000000883c8c] .netlink_unicast+0x214/0x318 [ 9.281163] [c0000002e899ba00] [c000000000884220] .netlink_sendmsg+0x348/0x444 [ 9.287076] [c0000002e899bae0] [c00000000080d13c] .sock_sendmsg+0x2c/0x54 [ 9.287080] [c0000002e899bb50] [c0000000008106c0] .___sys_sendmsg+0x2d0/0x2d8 [ 9.298375] [c0000002e899bd30] [c000000000811a80] .__sys_sendmsg+0x5c/0xb0 [ 9.303939] [c0000002e899be20] [c0000000000006b0] system_call+0x60/0x6c Signed-off-by: Scott Wood Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 49e14c1dce564517afdb440c61825d851601840e Author: Wenwen Wang Date: Wed Dec 26 20:15:13 2018 -0600 gdrom: fix a memory leak bug [ Upstream commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017 ] In probe_gdrom(), the buffer pointed by 'gd.cd_info' is allocated through kzalloc() and is used to hold the information of the gdrom device. To register and unregister the device, the pointer 'gd.cd_info' is passed to the functions register_cdrom() and unregister_cdrom(), respectively. However, this buffer is not freed after it is used, which can cause a memory leak bug. This patch simply frees the buffer 'gd.cd_info' in exit_gdrom() to fix the above issue. Signed-off-by: Wenwen Wang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 25cb6653e588cea0e09927bec7f14796b1373ef5 Author: Jia-Ju Bai Date: Wed Dec 26 22:09:34 2018 +0800 isdn: hisax: hfc_pci: Fix a possible concurrency use-after-free bug in HFCPCI_l1hw() [ Upstream commit 7418e6520f22a2e35815122fa5a53d5bbfa2c10f ] In drivers/isdn/hisax/hfc_pci.c, the functions hfcpci_interrupt() and HFCPCI_l1hw() may be concurrently executed. HFCPCI_l1hw() line 1173: if (!cs->tx_skb) hfcpci_interrupt() line 942: spin_lock_irqsave(); line 1066: dev_kfree_skb_irq(cs->tx_skb); Thus, a possible concurrency use-after-free bug may occur in HFCPCI_l1hw(). To fix these bugs, the calls to spin_lock_irqsave() and spin_unlock_irqrestore() are added in HFCPCI_l1hw(), to protect the access to cs->tx_skb. Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6ffef4ce8b88b3401195510366803bb493aa0bbe Author: Minchan Kim Date: Fri Dec 28 00:36:33 2018 -0800 zram: fix lockdep warning of free block handling [ Upstream commit 3c9959e025472122a61faebb208525cf26b305d1 ] Patch series "zram idle page writeback", v3. Inherently, swap device has many idle pages which are rare touched since it was allocated. It is never problem if we use storage device as swap. However, it's just waste for zram-swap. This patchset supports zram idle page writeback feature. * Admin can define what is idle page "no access since X time ago" * Admin can define when zram should writeback them * Admin can define when zram should stop writeback to prevent wearout Details are in each patch's description. This patch (of 7): ================================ WARNING: inconsistent lock state 4.19.0+ #390 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. zram_verify/2095 [HC0[0]:SC1[1]:HE1:SE0] takes: 00000000b1828693 (&(&zram->bitmap_lock)->rlock){+.?.}, at: put_entry_bdev+0x1e/0x50 {SOFTIRQ-ON-W} state was registered at: _raw_spin_lock+0x2c/0x40 zram_make_request+0x755/0xdc9 generic_make_request+0x373/0x6a0 submit_bio+0x6c/0x140 __swap_writepage+0x3a8/0x480 shrink_page_list+0x1102/0x1a60 shrink_inactive_list+0x21b/0x3f0 shrink_node_memcg.constprop.99+0x4f8/0x7e0 shrink_node+0x7d/0x2f0 do_try_to_free_pages+0xe0/0x300 try_to_free_pages+0x116/0x2b0 __alloc_pages_slowpath+0x3f4/0xf80 __alloc_pages_nodemask+0x2a2/0x2f0 __handle_mm_fault+0x42e/0xb50 handle_mm_fault+0x55/0xb0 __do_page_fault+0x235/0x4b0 page_fault+0x1e/0x30 irq event stamp: 228412 hardirqs last enabled at (228412): [] __slab_free+0x3e6/0x600 hardirqs last disabled at (228411): [] __slab_free+0x1c5/0x600 softirqs last enabled at (228396): [] __do_softirq+0x31e/0x427 softirqs last disabled at (228403): [] irq_exit+0xd1/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&zram->bitmap_lock)->rlock); lock(&(&zram->bitmap_lock)->rlock); *** DEADLOCK *** no locks held by zram_verify/2095. stack backtrace: CPU: 5 PID: 2095 Comm: zram_verify Not tainted 4.19.0+ #390 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0x67/0x9b print_usage_bug+0x1bd/0x1d3 mark_lock+0x4aa/0x540 __lock_acquire+0x51d/0x1300 lock_acquire+0x90/0x180 _raw_spin_lock+0x2c/0x40 put_entry_bdev+0x1e/0x50 zram_free_page+0xf6/0x110 zram_slot_free_notify+0x42/0xa0 end_swap_bio_read+0x5b/0x170 blk_update_request+0x8f/0x340 scsi_end_request+0x2c/0x1e0 scsi_io_completion+0x98/0x650 blk_done_softirq+0x9e/0xd0 __do_softirq+0xcc/0x427 irq_exit+0xd1/0xe0 do_IRQ+0x93/0x120 common_interrupt+0xf/0xf With writeback feature, zram_slot_free_notify could be called in softirq context by end_swap_bio_read. However, bitmap_lock is not aware of that so lockdep yell out: get_entry_bdev spin_lock(bitmap->lock); irq softirq end_swap_bio_read zram_slot_free_notify zram_slot_lock <-- deadlock prone zram_free_page put_entry_bdev spin_lock(bitmap->lock); <-- deadlock prone With akpm's suggestion (i.e. bitmap operation is already atomic), we could remove bitmap lock. It might fail to find a empty slot if serious contention happens. However, it's not severe problem because huge page writeback has already possiblity to fail if there is severe memory pressure. Worst case is just keeping the incompressible in memory, not storage. The other problem is zram_slot_lock in zram_slot_slot_free_notify. To make it safe is this patch introduces zram_slot_trylock where zram_slot_free_notify uses it. Although it's rare to be contented, this patch adds new debug stat "miss_free" to keep monitoring how often it happens. Link: http://lkml.kernel.org/r/20181127055429.251614-2-minchan@kernel.org Signed-off-by: Minchan Kim Reviewed-by: Sergey Senozhatsky Reviewed-by: Joey Pabalinas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 39255e9b63cbb42bf4915abe291414a0d7baf22c Author: Waiman Long Date: Fri Dec 28 00:38:51 2018 -0800 mm/page_alloc.c: don't call kasan_free_pages() at deferred mem init [ Upstream commit 3c0c12cc8f00ca5f81acb010023b8eb13e9a7004 ] When CONFIG_KASAN is enabled on large memory SMP systems, the deferrred pages initialization can take a long time. Below were the reported init times on a 8-socket 96-core 4TB IvyBridge system. 1) Non-debug kernel without CONFIG_KASAN [ 8.764222] node 1 initialised, 132086516 pages in 7027ms 2) Debug kernel with CONFIG_KASAN [ 146.288115] node 1 initialised, 132075466 pages in 143052ms So the page init time in a debug kernel was 20X of the non-debug kernel. The long init time can be problematic as the page initialization is done with interrupt disabled. In this particular case, it caused the appearance of following warning messages as well as NMI backtraces of all the cores that were doing the initialization. [ 68.240049] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 68.241000] rcu: 25-...0: (100 ticks this GP) idle=b72/1/0x4000000000000000 softirq=915/915 fqs=16252 [ 68.241000] rcu: 44-...0: (95 ticks this GP) idle=49a/1/0x4000000000000000 softirq=788/788 fqs=16253 [ 68.241000] rcu: 54-...0: (104 ticks this GP) idle=03a/1/0x4000000000000000 softirq=721/825 fqs=16253 [ 68.241000] rcu: 60-...0: (103 ticks this GP) idle=cbe/1/0x4000000000000000 softirq=637/740 fqs=16253 [ 68.241000] rcu: 72-...0: (105 ticks this GP) idle=786/1/0x4000000000000000 softirq=536/641 fqs=16253 [ 68.241000] rcu: 84-...0: (99 ticks this GP) idle=292/1/0x4000000000000000 softirq=537/537 fqs=16253 [ 68.241000] rcu: 111-...0: (104 ticks this GP) idle=bde/1/0x4000000000000000 softirq=474/476 fqs=16253 [ 68.241000] rcu: (detected by 13, t=65018 jiffies, g=249, q=2) The long init time was mainly caused by the call to kasan_free_pages() to poison the newly initialized pages. On a 4TB system, we are talking about almost 500GB of memory probably on the same node. In reality, we may not need to poison the newly initialized pages before they are ever allocated. So KASAN poisoning of freed pages before the completion of deferred memory initialization is now disabled. Those pages will be properly poisoned when they are allocated or freed after deferred pages initialization is done. With this change, the new page initialization time became: [ 21.948010] node 1 initialised, 132075466 pages in 18702ms This was still about double the non-debug kernel time, but was much better than before. Link: http://lkml.kernel.org/r/1544459388-8736-1-git-send-email-longman@redhat.com Signed-off-by: Waiman Long Reviewed-by: Andrew Morton Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Michal Hocko Cc: Pasha Tatashin Cc: Oscar Salvador Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 769d6393e60510b754466e319069eb896e2117c3 Author: Larry Chen Date: Fri Dec 28 00:32:46 2018 -0800 ocfs2: improve ocfs2 Makefile [ Upstream commit 9e6aea22802b5684c7e1d69822aeb0844dd01953 ] Included file path was hard-wired in the ocfs2 makefile, which might causes some confusion when compiling ocfs2 as an external module. Say if we compile ocfs2 module as following. cp -r /kernel/tree/fs/ocfs2 /other/dir/ocfs2 cd /other/dir/ocfs2 make -C /path/to/kernel_source M=`pwd` modules Acutally, the compiler wil try to find included file in /kernel/tree/fs/ocfs2, rather than the directory /other/dir/ocfs2. To fix this little bug, we introduce the var $(src) provided by kbuild. $(src) means the absolute path of the running kbuild file. Link: http://lkml.kernel.org/r/20181108085546.15149-1-lchen@suse.com Signed-off-by: Larry Chen Reviewed-by: Andrew Morton Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b48085ef25b3205e29cca66a5c875bc6f6c1842e Author: Junxiao Bi Date: Fri Dec 28 00:32:57 2018 -0800 ocfs2: don't clear bh uptodate for block read [ Upstream commit 70306d9dce75abde855cefaf32b3f71eed8602a3 ] For sync io read in ocfs2_read_blocks_sync(), first clear bh uptodate flag and submit the io, second wait io done, last check whether bh uptodate, if not return io error. If two sync io for the same bh were issued, it could be the first io done and set uptodate flag, but just before check that flag, the second io came in and cleared uptodate, then ocfs2_read_blocks_sync() for the first io will return IO error. Indeed it's not necessary to clear uptodate flag, as the io end handler end_buffer_read_sync() will set or clear it based on io succeed or failed. The following message was found from a nfs server but the underlying storage returned no error. [4106438.567376] (nfsd,7146,3):ocfs2_get_suballoc_slot_bit:2780 ERROR: read block 1238823695 failed -5 [4106438.567569] (nfsd,7146,3):ocfs2_get_suballoc_slot_bit:2812 ERROR: status = -5 [4106438.567611] (nfsd,7146,3):ocfs2_test_inode_bit:2894 ERROR: get alloc slot and bit failed -5 [4106438.567643] (nfsd,7146,3):ocfs2_test_inode_bit:2932 ERROR: status = -5 [4106438.567675] (nfsd,7146,3):ocfs2_get_dentry:94 ERROR: test inode bit failed -5 Same issue in non sync read ocfs2_read_blocks(), fixed it as well. Link: http://lkml.kernel.org/r/20181121020023.3034-4-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Changwei Ge Reviewed-by: Yiwen Jiang Cc: Joel Becker Cc: Joseph Qi Cc: Jun Piao Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit bdecfeb0ad79dc97e28b831a43e01ee19831dbc0 Author: Randy Dunlap Date: Fri Dec 28 00:31:39 2018 -0800 arch/sh/boards/mach-kfr2r09/setup.c: fix struct mtd_oob_ops build warning [ Upstream commit 440e7b379f91acd245d5c8de94d533f40f5dffb3 ] arch/sh/boards/mach-kfr2r09/setup.c does not need to #include , and doing so causes a build warning, so drop that header file. In file included from ../arch/sh/boards/mach-kfr2r09/setup.c:28: ../include/linux/mtd/onenand.h:225:12: warning: 'struct mtd_oob_ops' declared inside parameter list will not be visible outside of this definition or declaration struct mtd_oob_ops *ops); Link: http://lkml.kernel.org/r/702f0a25-c63e-6912-4640-6ab0f00afbc7@infradead.org Fixes: f3590dc32974 ("media: arch: sh: kfr2r09: Use new renesas-ceu camera driver") Signed-off-by: Randy Dunlap Reported-by: Geert Uytterhoeven Suggested-by: Miquel Raynal Reviewed-by: Miquel Raynal Cc: Yoshinori Sato Cc: Rich Felker Cc: Jacopo Mondi Cc: Magnus Damm Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c1aeb1937b89af34c68e96fd42eb6bb7f0e339bf Author: Marc Zyngier Date: Fri Dec 28 00:31:25 2018 -0800 scripts/decode_stacktrace: only strip base path when a prefix of the path [ Upstream commit 67a28de47faa83585dd644bd4c31e5a1d9346c50 ] Running something like: decodecode vmlinux . leads to interested results where not only the leading "." gets stripped from the displayed paths, but also anywhere in the string, displaying something like: kvm_vcpu_check_block (arch/arm64/kvm/virt/kvm/kvm_mainc:2141) which doesn't help further processing. Fix it by only stripping the base path if it is a prefix of the path. Link: http://lkml.kernel.org/r/20181210174659.31054-3-marc.zyngier@arm.com Signed-off-by: Marc Zyngier Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c1d03fb11fe257f4657668378f36c2016c249f04 Author: Jiri Olsa Date: Wed Dec 26 12:21:21 2018 +0100 perf python: Do not force closing original perf descriptor in evlist.get_pollfd() [ Upstream commit a389aece97938966616ce0336466b98b0351ef10 ] Ondřej reported that when compiled with python3, the python extension regresses in evlist.get_pollfd function behaviour. The evlist.get_pollfd function creates file objects from evlist's fds and returns them in a list. The python3 version also sets them to 'close the original descriptor' when the object dies (is closed), by passing True via the 'closefd' arg in the PyFile_FromFd call. The python's closefd doc says: If closefd is False, the underlying file descriptor will be kept open when the file is closed. That's why the following line in python3 closes all evlist fds: evlist.get_pollfd() the returned list is immediately destroyed and that takes down the original events fds. Passing closefd as False to PyFile_FromFd to fix this. Reported-by: Ondřej Lysoněk Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Jaroslav Škarvada Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: 66dfdff03d19 ("perf tools: Add Python 3 support") Link: http://lkml.kernel.org/r/20181226112121.5285-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 65ad8e0a1567a2243ebb8cec06733ecd98b32137 Author: Ondrej Mosnacek Date: Thu Dec 13 15:17:37 2018 +0100 cgroup: fix parsing empty mount option string [ Upstream commit e250d91d65750a0c0c62483ac4f9f357e7317617 ] This fixes the case where all mount options specified are consumed by an LSM and all that's left is an empty string. In this case cgroupfs should accept the string and not fail. How to reproduce (with SELinux enabled): # umount /sys/fs/cgroup/unified # mount -o context=system_u:object_r:cgroup_t:s0 -t cgroup2 cgroup2 /sys/fs/cgroup/unified mount: /sys/fs/cgroup/unified: wrong fs type, bad option, bad superblock on cgroup2, missing codepage or helper program, or other error. # dmesg | tail -n 1 [ 31.575952] cgroup: cgroup2: unknown option "" Fixes: 67e9c74b8a87 ("cgroup: replace __DEVEL__sane_behavior with cgroup2 fs type") [NOTE: should apply on top of commit 5136f6365ce3 ("cgroup: implement "nsdelegate" mount option"), older versions need manual rebase] Suggested-by: Stephen Smalley Signed-off-by: Ondrej Mosnacek Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 478fec4a984a08860a9f0982c8c4d9819eec7c8c Author: Sahitya Tummala Date: Tue Dec 18 16:39:24 2018 +0530 f2fs: fix sbi->extent_list corruption issue [ Upstream commit e4589fa545e0020dbbc3c9bde35f35f949901392 ] When there is a failure in f2fs_fill_super() after/during the recovery of fsync'd nodes, it frees the current sbi and retries again. This time the mount is successful, but the files that got recovered before retry, still holds the extent tree, whose extent nodes list is corrupted since sbi and sbi->extent_list is freed up. The list_del corruption issue is observed when the file system is getting unmounted and when those recoverd files extent node is being freed up in the below context. list_del corruption. prev->next should be fffffff1e1ef5480, but was (null) <...> kernel BUG at kernel/msm-4.14/lib/list_debug.c:53! lr : __list_del_entry_valid+0x94/0xb4 pc : __list_del_entry_valid+0x94/0xb4 <...> Call trace: __list_del_entry_valid+0x94/0xb4 __release_extent_node+0xb0/0x114 __free_extent_tree+0x58/0x7c f2fs_shrink_extent_tree+0xdc/0x3b0 f2fs_leave_shrinker+0x28/0x7c f2fs_put_super+0xfc/0x1e0 generic_shutdown_super+0x70/0xf4 kill_block_super+0x2c/0x5c kill_f2fs_super+0x44/0x50 deactivate_locked_super+0x60/0x8c deactivate_super+0x68/0x74 cleanup_mnt+0x40/0x78 __cleanup_mnt+0x1c/0x28 task_work_run+0x48/0xd0 do_notify_resume+0x678/0xe98 work_pending+0x8/0x14 Fix this by not creating extents for those recovered files if shrinker is not registered yet. Once mount is successful and shrinker is registered, those files can have extents again. Signed-off-by: Sahitya Tummala Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 6e61830a8a7db5cd61d05cc0803333f452f8833a Author: Kangjie Lu Date: Tue Dec 25 01:56:14 2018 -0600 niu: fix missing checks of niu_pci_eeprom_read [ Upstream commit 26fd962bde0b15e54234fe762d86bc0349df1de4 ] niu_pci_eeprom_read() may fail, so we should check its return value before using the read data. Signed-off-by: Kangjie Lu Acked-by: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c5b6f9d5f83472e53f5dc34ac7db96dc81fb4065 Author: Anton Ivanov Date: Wed Dec 5 12:37:41 2018 +0000 um: Avoid marking pages with "changed protection" [ Upstream commit 8892d8545f2d0342b9c550defbfb165db237044b ] Changing protection is a very high cost operation in UML because in addition to an extra syscall it also interrupts mmap merge sequences generated by the tlb. While the condition is not particularly common it is worth avoiding. Signed-off-by: Anton Ivanov Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 549f0edb3e5925cc0ab30648c85bca9c9fbe1553 Author: Sahitya Tummala Date: Wed Dec 26 11:20:29 2018 +0530 f2fs: fix use-after-free issue when accessing sbi->stat_info [ Upstream commit 60aa4d5536ab7fe32433ca1173bd9d6633851f27 ] iput() on sbi->node_inode can update sbi->stat_info in the below context, if the f2fs_write_checkpoint() has failed with error. f2fs_balance_fs_bg+0x1ac/0x1ec f2fs_write_node_pages+0x4c/0x260 do_writepages+0x80/0xbc __writeback_single_inode+0xdc/0x4ac writeback_single_inode+0x9c/0x144 write_inode_now+0xc4/0xec iput+0x194/0x22c f2fs_put_super+0x11c/0x1e8 generic_shutdown_super+0x70/0xf4 kill_block_super+0x2c/0x5c kill_f2fs_super+0x44/0x50 deactivate_locked_super+0x60/0x8c deactivate_super+0x68/0x74 cleanup_mnt+0x40/0x78 Fix this by moving f2fs_destroy_stats() further below iput() in both f2fs_put_super() and f2fs_fill_super() paths. Signed-off-by: Sahitya Tummala Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 705d3aec9fa4afc9df33a930ad9742d0fb9aa1f8 Author: Ronnie Sahlberg Date: Thu Dec 13 08:06:16 2018 +1000 cifs: check ntwrk_buf_start for NULL before dereferencing it [ Upstream commit 59a63e479ce36a3f24444c3a36efe82b78e4a8e0 ] RHBZ: 1021460 There is an issue where when multiple threads open/close the same directory ntwrk_buf_start might end up being NULL, causing the call to smbCalcSize later to oops with a NULL deref. The real bug is why this happens and why this can become NULL for an open cfile, which should not be allowed. This patch tries to avoid a oops until the time when we fix the underlying issue. Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b46dc93fbcb07e94b032a5d15f5430d6c5565ce2 Author: Stefan Roese Date: Mon Dec 17 10:47:48 2018 +0100 MIPS: ralink: Select CONFIG_CPU_MIPSR2_IRQ_VI on MT7620/8 [ Upstream commit 0b15394475e3bcaf35ca4bf22fc55d56df67224e ] Testing has shown, that when using mainline U-Boot on MT7688 based boards, the system may hang or crash while mounting the root-fs. The main issue here is that mainline U-Boot configures EBase to a value near the end of system memory. And with CONFIG_CPU_MIPSR2_IRQ_VI disabled, trap_init() will not allocate a new area to place the exception handler. The original value will be used and the handler will be copied to this location, which might already be used by some userspace application. The MT7688 supports VI - its config3 register is 0x00002420, so VInt (Bit 5) is set. But without setting CONFIG_CPU_MIPSR2_IRQ_VI this bit will not be evaluated to result in "cpu_has_vi" being set. This patch now selects CONFIG_CPU_MIPSR2_IRQ_VI on MT7620/8 which results trap_init() to allocate some memory for the exception handler. Please note that this issue was not seen with the Mediatek U-Boot version, as it does not touch EBase (stays at default of 0x8000.0000). This is strictly also not correct as the kernel (_text) resides here. Signed-off-by: Stefan Roese [paul.burton@mips.com: s/beeing/being/] Signed-off-by: Paul Burton Cc: John Crispin Cc: Daniel Schwierzeck Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Signed-off-by: Sasha Levin commit 5e776948b95356ab7b2beaf960dd730f0c8a9c02 Author: Nathan Chancellor Date: Mon Dec 10 16:49:54 2018 -0700 crypto: ux500 - Use proper enum in hash_set_dma_transfer [ Upstream commit 5ac93f808338f4dd465402e91869702eb87db241 ] Clang warns when one enumerated type is implicitly converted to another: drivers/crypto/ux500/hash/hash_core.c:169:4: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] direction, DMA_CTRL_ACK | DMA_PREP_INTERRUPT); ^~~~~~~~~ 1 warning generated. dmaengine_prep_slave_sg expects an enum from dma_transfer_direction. We know that the only direction supported by this function is DMA_TO_DEVICE because of the check at the top of this function so we can just use the equivalent value from dma_transfer_direction. DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6462e0c1e7d4d2e16d6af5c577875a1fff222256 Author: Nathan Chancellor Date: Mon Dec 10 16:49:29 2018 -0700 crypto: ux500 - Use proper enum in cryp_set_dma_transfer [ Upstream commit 9d880c5945c748d8edcac30965f3349a602158c4 ] Clang warns when one enumerated type is implicitly converted to another: drivers/crypto/ux500/cryp/cryp_core.c:559:5: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] direction, DMA_CTRL_ACK); ^~~~~~~~~ drivers/crypto/ux500/cryp/cryp_core.c:583:5: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] direction, ^~~~~~~~~ 2 warnings generated. dmaengine_prep_slave_sg expects an enum from dma_transfer_direction. Because we know the value of the dma_data_direction enum from the switch statement, we can just use the proper value from dma_transfer_direction so there is no more conversion. DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1 DMA_FROM_DEVICE = DMA_DEV_TO_MEM = 2 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5f48eb89d51c48876d8e9bc84182349f3283c304 Author: Michael Ellerman Date: Fri Oct 19 15:21:08 2018 +1100 seq_buf: Make seq_buf_puts() null-terminate the buffer [ Upstream commit 0464ed24380905d640030d368cd84a4e4d1e15e2 ] Currently seq_buf_puts() will happily create a non null-terminated string for you in the buffer. This is particularly dangerous if the buffer is on the stack. For example: char buf[8]; char secret = "secret"; struct seq_buf s; seq_buf_init(&s, buf, sizeof(buf)); seq_buf_puts(&s, "foo"); printk("Message is %s\n", buf); Can result in: Message is fooªªªªªsecret We could require all users to memset() their buffer to zero before use. But that seems likely to be forgotten and lead to bugs. Instead we can change seq_buf_puts() to always leave the buffer in a null-terminated state. The only downside is that this makes the buffer 1 character smaller for seq_buf_puts(), but that seems like a good trade off. Link: http://lkml.kernel.org/r/20181019042109.8064-1-mpe@ellerman.id.au Acked-by: Kees Cook Signed-off-by: Michael Ellerman Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit a5583e596d37cbfcf45a8e6ef73f7e5136f1c2a4 Author: Kangjie Lu Date: Fri Dec 21 13:10:39 2018 -0600 hwmon: (lm80) fix a missing check of bus read in lm80 probe [ Upstream commit 9aa3aa15f4c2f74f47afd6c5db4b420fadf3f315 ] In lm80_probe(), if lm80_read_value() fails, it returns a negative error number which is stored to data->fan[f_min] and will be further used. We should avoid using the data if the read fails. The fix checks if lm80_read_value() fails, and if so, returns with the error number. Signed-off-by: Kangjie Lu Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit cf9b3cb85ee65e4cec227d267a7c33e3f2a49446 Author: Kangjie Lu Date: Fri Dec 21 13:01:33 2018 -0600 hwmon: (lm80) fix a missing check of the status of SMBus read [ Upstream commit c9c63915519b1def7043b184680f33c24cd49d7b ] If lm80_read_value() fails, it returns a negative number instead of the correct read data. Therefore, we should avoid using the data if it fails. The fix checks if lm80_read_value() fails, and if so, returns with the error number. Signed-off-by: Kangjie Lu [groeck: One variable for return values is enough] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 0828fbbd86fb66b2f7c80137c0d739521c85adc4 Author: Stanislav Fomichev Date: Thu Nov 15 16:32:01 2018 -0800 perf build: Don't unconditionally link the libbfd feature test to -liberty and -lz [ Upstream commit 14541b1e7e723859ff2c75c6fc10cdbbec6b8c34 ] Current libbfd feature test unconditionally links against -liberty and -lz. While it's required on some systems (e.g. opensuse), it's completely unnecessary on the others, where only -lbdf is sufficient (debian). This patch streamlines (and renames) the following feature checks: feature-libbfd - only link against -lbfd (debian), see commit 2cf9040714f3 ("perf tools: Fix bfd dependency libraries detection") feature-libbfd-liberty - link against -lbfd and -liberty feature-libbfd-liberty-z - link against -lbfd, -liberty and -lz (opensuse), see commit 280e7c48c3b8 ("perf tools: fix BFD detection on opensuse") (feature-liberty{,-z} were renamed to feature-libbfd-liberty{,z} for clarity) The main motivation is to fix this feature test for bpftool which is currently broken on debian (libbfd feature shows OFF, but we still unconditionally link against -lbfd and it works). Tested on debian with only -lbfd installed (without -liberty); I'd appreciate if somebody on the other systems can test this new detection method. Signed-off-by: Stanislav Fomichev Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Mathieu Poirier Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/4dfc634cfcfb236883971b5107cf3c28ec8a31be.1542328222.git.sdf@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f449ec370ca990963ac5274f8e5167a50915f18a Author: Chris Perl Date: Mon Dec 17 10:56:38 2018 -0500 NFS: nfs_compare_mount_options always compare auth flavors. [ Upstream commit 594d1644cd59447f4fceb592448d5cd09eb09b5e ] This patch removes the check from nfs_compare_mount_options to see if a `sec' option was passed for the current mount before comparing auth flavors and instead just always compares auth flavors. Consider the following scenario: You have a server with the address 192.168.1.1 and two exports /export/a and /export/b. The first export supports `sys' and `krb5' security, the second just `sys'. Assume you start with no mounts from the server. The following results in EIOs being returned as the kernel nfs client incorrectly thinks it can share the underlying `struct nfs_server's: $ mkdir /tmp/{a,b} $ sudo mount -t nfs -o vers=3,sec=krb5 192.168.1.1:/export/a /tmp/a $ sudo mount -t nfs -o vers=3 192.168.1.1:/export/b /tmp/b $ df >/dev/null df: ‘/tmp/b’: Input/output error Signed-off-by: Chris Perl Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 0635be297a0252ef6d7ec7669a66a9a835f6c42b Author: Jim Mattson Date: Fri Dec 14 14:34:43 2018 -0800 kvm: Change offset in kvm_write_guest_offset_cached to unsigned [ Upstream commit 7a86dab8cf2f0fdf508f3555dddfc236623bff60 ] Since the offset is added directly to the hva from the gfn_to_hva_cache, a negative offset could result in an out of bounds write. The existing BUG_ON only checks for addresses beyond the end of the gfn_to_hva_cache, not for addresses before the start of the gfn_to_hva_cache. Note that all current call sites have non-negative offsets. Fixes: 4ec6e8636256 ("kvm: Introduce kvm_write_guest_offset_cached()") Reported-by: Cfir Cohen Signed-off-by: Jim Mattson Reviewed-by: Cfir Cohen Reviewed-by: Peter Shier Reviewed-by: Krish Sadhukhan Reviewed-by: Sean Christopherson Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit bb736efe21d6beecb992609bc89a31e0054df82b Author: Vitaly Kuznetsov Date: Wed Dec 19 12:15:18 2018 +0100 selftests: kvm: report failed stage when exit reason is unexpected [ Upstream commit b85c32dd27495075380350fcd5d614a6b45311b8 ] When we get a report like ==== Test Assertion Failure ==== x86_64/state_test.c:157: run->exit_reason == KVM_EXIT_IO pid=955 tid=955 - Success 1 0x0000000000401350: main at state_test.c:154 2 0x00007fc31c9e9412: ?? ??:0 3 0x000000000040159d: _start at ??:? Unexpected exit reason: 8 (SHUTDOWN), it is not obvious which particular stage failed. Add the info. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit b5965289fb8941a33b9fac72d4e6d3d9733ccd1c Author: Mahesh Salgaonkar Date: Mon Aug 20 13:47:32 2018 +0530 powerpc/fadump: Do not allow hot-remove memory from fadump reserved area. [ Upstream commit 0db6896ff6332ba694f1e61b93ae3b2640317633 ] For fadump to work successfully there should not be any holes in reserved memory ranges where kernel has asked firmware to move the content of old kernel memory in event of crash. Now that fadump uses CMA for reserved area, this memory area is now not protected from hot-remove operations unless it is cma allocated. Hence, fadump service can fail to re-register after the hot-remove operation, if hot-removed memory belongs to fadump reserved region. To avoid this make sure that memory from fadump reserved area is not hot-removable if fadump is registered. However, if user still wants to remove that memory, he can do so by manually stopping fadump service before hot-remove operation. Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit bff6fd3845e0ca8f5cb0c70f620f3d7f554753b8 Author: Vitaly Kuznetsov Date: Wed Dec 19 12:06:13 2018 +0100 KVM: x86: svm: report MSR_IA32_MCG_EXT_CTL as unsupported [ Upstream commit e87555e550cef4941579cd879759a7c0dee24e68 ] AMD doesn't seem to implement MSR_IA32_MCG_EXT_CTL and svm code in kvm knows nothing about it, however, this MSR is among emulated_msrs and thus returned with KVM_GET_MSR_INDEX_LIST. The consequent KVM_GET_MSRS, of course, fails. Report the MSR as unsupported to not confuse userspace. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 7039e6c122f5538f6dba22300bce4aa9775b59a5 Author: Martin Blumenstingl Date: Sun Dec 9 20:50:51 2018 +0100 pinctrl: meson: meson8b: fix the GPIO function for the GPIOAO pins [ Upstream commit 2b745ac3cceb8fc1d9985990c8241a821ea97e53 ] The GPIOAO pins (as well as the two exotic GPIO_BSD_EN and GPIO_TEST_N) only belong to the pin controller in the AO domain. With the current definition these pins cannot be referred to in .dts files as group (which is possible on GXBB and GXL for example). Add a separate "gpio_aobus" function to fix the mapping between the pin controller and the GPIO pins in the AO domain. This is similar to how the GXBB and GXL drivers implement this functionality. Fixes: 9dab1868ec0db4 ("pinctrl: amlogic: Make driver independent from two-domain configuration") Signed-off-by: Martin Blumenstingl Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 81c86135ca37f1b070503ef9b343cec151816db8 Author: Martin Blumenstingl Date: Sun Dec 9 20:50:50 2018 +0100 pinctrl: meson: meson8: fix the GPIO function for the GPIOAO pins [ Upstream commit 42f9b48cc5402be11d2364275eb18c257d2a79e8 ] The GPIOAO pins (as well as the two exotic GPIO_BSD_EN and GPIO_TEST_N) only belong to the pin controller in the AO domain. With the current definition these pins cannot be referred to in .dts files as group (which is possible on GXBB and GXL for example). Add a separate "gpio_aobus" function to fix the mapping between the pin controller and the GPIO pins in the AO domain. This is similar to how the GXBB and GXL drivers implement this functionality. Fixes: 9dab1868ec0db4 ("pinctrl: amlogic: Make driver independent from two-domain configuration") Signed-off-by: Martin Blumenstingl Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 47c12a8a77e129fa934226af414a38043ab69d46 Author: John Fastabend Date: Thu Dec 20 11:35:33 2018 -0800 bpf: sk_msg, fix socket data_ready events [ Upstream commit 552de91068828daef50a227a665068cf8dde835e ] When a skb verdict program is in-use and either another BPF program redirects to that socket or the new SK_PASS support is used the data_ready callback does not wake up application. Instead because the stream parser/verdict is using the sk data_ready callback we wake up the stream parser/verdict block. Fix this by adding a helper to check if the stream parser block is enabled on the sk and if so call the saved pointer which is the upper layers wake up function. This fixes application stalls observed when an application is waiting for data in a blocking read(). Fixes: d829e9c4112b ("tls: convert to generic sk_msg interface") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit a802513bff9657bbc60aea34f8932692f3c471eb Author: Christophe Leroy Date: Wed Nov 28 09:27:04 2018 +0000 powerpc/mm: Fix reporting of kernel execute faults on the 8xx [ Upstream commit ffca395b11c4a5a6df6d6345f794b0e3d578e2d0 ] On the 8xx, no-execute is set via PPP bits in the PTE. Therefore a no-exec fault generates DSISR_PROTFAULT error bits, not DSISR_NOEXEC_OR_G. This patch adds DSISR_PROTFAULT in the test mask. Fixes: d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 91a87d4fb0e625348714d3ae1c5370f3b5b8d136 Author: John Fastabend Date: Thu Dec 20 11:35:34 2018 -0800 bpf: sk_msg, zap ingress queue on psock down [ Upstream commit a136678c0bdbb650daff5df5eec1dab960e074a7 ] In addition to releasing any cork'ed data on a psock when the psock is removed we should also release any skb's in the ingress work queue. Otherwise the skb's eventually get free'd but late in the tear down process so we see the WARNING due to non-zero sk_forward_alloc. void sk_stream_kill_queues(struct sock *sk) { ... WARN_ON(sk->sk_forward_alloc); ... } Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 3b0b78c4fe49b25926eca4703e0ad19db92e47f3 Author: Noralf Trønnes Date: Thu Dec 20 19:13:09 2018 +0100 fbdev: fbcon: Fix unregister crash when more than one framebuffer [ Upstream commit 2122b40580dd9d0620398739c773d07a7b7939d0 ] When unregistering fbdev using unregister_framebuffer(), any bound console will unbind automatically. This is working fine if this is the only framebuffer, resulting in a switch to the dummy console. However if there is a fb0 and I unregister fb1 having a bound console, I eventually get a crash. The fastest way for me to trigger the crash is to do a reboot, resulting in this splat: [ 76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 __queue_work+0x2d4/0x41c [ 76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight bcm2835_rng rng_core [last unloaded: tinydrm] [ 76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4 [ 76.478933] Hardware name: BCM2835 [ 76.478949] Backtrace: [ 76.478995] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [ 76.479022] r6:00000000 r5:c0bc73be r4:00000000 r3:6fb5bf81 [ 76.479060] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c) [ 76.479134] [] (__warn) from [] (warn_slowpath_null+0x4c/0x58) [ 76.479165] r9:c0eb6944 r8:00000001 r7:c0e927f8 r6:c0bc73be r5:000005a2 r4:c0139e84 [ 76.479197] [] (warn_slowpath_null) from [] (__queue_work+0x2d4/0x41c) [ 76.479222] r6:d7666a00 r5:c0e918ee r4:dbc4e700 [ 76.479251] [] (__queue_work) from [] (queue_work_on+0x60/0x88) [ 76.479281] r10:c0496bf8 r9:00000100 r8:c0e92ae0 r7:00000001 r6:d9403700 r5:d7666a00 [ 76.479298] r4:20000113 [ 76.479348] [] (queue_work_on) from [] (cursor_timer_handler+0x30/0x54) [ 76.479374] r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc [ 76.479413] [] (cursor_timer_handler) from [] (call_timer_fn+0x100/0x230) [ 76.479435] r4:c0e9192f r3:d758a340 [ 76.479465] [] (call_timer_fn) from [] (expire_timers+0x10c/0x12c) [ 76.479495] r10:40000000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 r5:c0496bf8 [ 76.479513] r4:d8a8fabc [ 76.479541] [] (expire_timers) from [] (run_timer_softirq+0xa8/0x184) [ 76.479570] r9:00000001 r8:c0e19280 r7:00000000 r6:c0e08088 r5:c0e1a3e0 r4:c0e19280 [ 76.479603] [] (run_timer_softirq) from [] (__do_softirq+0x1ac/0x3fc) [ 76.479632] r10:c0e91680 r9:d8afc020 r8:0000000a r7:00000100 r6:00000001 r5:00000002 [ 76.479650] r4:c0eb65ec [ 76.479686] [] (__do_softirq) from [] (irq_exit+0xe8/0x168) [ 76.479716] r10:d8d1a9b0 r9:d8afc000 r8:00000001 r7:d949c000 r6:00000000 r5:c0e8b3f0 [ 76.479734] r4:00000000 [ 76.479764] [] (irq_exit) from [] (__handle_domain_irq+0x94/0xb0) [ 76.479793] [] (__handle_domain_irq) from [] (bcm2835_handle_irq+0x3c/0x48) [ 76.479823] r8:d8afdebc r7:d8afddfc r6:ffffffff r5:c0e089f8 r4:d8afddc8 r3:d8afddc8 [ 76.479851] [] (bcm2835_handle_irq) from [] (__irq_svc+0x70/0x98) The problem is in the console rebinding in fbcon_fb_unbind(). It uses the virtual console index as the new framebuffer index to bind the console(s) to. The correct way is to use the con2fb_map lookup table to find the framebuffer index. Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from unregister_framebuffer") Signed-off-by: Noralf Trønnes Reviewed-by: Mikulas Patocka Acked-by: Daniel Vetter Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit 981845a3d8965dd65356c16195f3ff569b96a689 Author: Lenny Szubowicz Date: Wed Dec 19 11:50:52 2018 -0500 ACPI/APEI: Clear GHES block_status before panic() [ Upstream commit 98cff8b23ed1c763a029ee81ea300df0d153d07d ] In __ghes_panic() clear the block status in the APEI generic error status block for that generic hardware error source before calling panic() to prevent a second panic() in the crash kernel for exactly the same fatal error. Otherwise ghes_probe(), running in the crash kernel, would see an unhandled error in the APEI generic error status block and panic again, thereby precluding any crash dump. Signed-off-by: Lenny Szubowicz Signed-off-by: David Arcari Tested-by: Tyler Baicar Acked-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit fb29f76cc5668d8fc9e2b04ebfaf4de4f62e1866 Author: Kai-Heng Feng Date: Mon Dec 3 13:54:38 2018 +0800 igb: Fix an issue that PME is not enabled during runtime suspend [ Upstream commit 1fb3a7a75e2efcc83ef21f2434069cddd6fae6f5 ] I210 ethernet card doesn't wakeup when a cable gets plugged. It's because its PME is not set. Since commit 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3"), if the PCI state is saved, pci_pm_runtime_suspend() stops calling pci_finish_runtime_suspend(), which enables the PCI PME. To fix the issue, let's not to save PCI states when it's runtime suspend, to let the PCI subsystem enables PME. Fixes: 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3") Signed-off-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 121eeae0af533b9f9a4978f742ebbc2aa36f3623 Author: Young Xiao Date: Thu Nov 29 01:54:10 2018 +0000 ice: Do not enable NAPI on q_vectors that have no rings [ Upstream commit eec903769b4ea476591ffff73bb7359f14f38c51 ] If ice driver has q_vectors w/ active NAPI that has no rings, then this will result in a divide by zero error. To correct it I am updating the driver code so that we only support NAPI on q_vectors that have 1 or more rings allocated to them. See commit 13a8cd191a2b ("i40e: Do not enable NAPI on q_vectors that have no rings") for detail. Signed-off-by: Young Xiao Acked-by: Anirudh Venkataramanan Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit a3cc8fde5137292b0eb958b74d68b294edab6545 Author: Konstantin Khorenko Date: Fri Nov 23 19:10:28 2018 +0300 i40e: define proper net_device::neigh_priv_len [ Upstream commit 31389b53b3e0b535867af9090a5d19ec64768d55 ] Out of bound read reported by KASan. i40iw_net_event() reads unconditionally 16 bytes from neigh->primary_key while the memory allocated for "neighbour" struct is evaluated in neigh_alloc() as tbl->entry_size + dev->neigh_priv_len where "dev" is a net_device. But the driver does not setup dev->neigh_priv_len and we read beyond the neigh entry allocated memory, so the patch in the next mail fixes this. Signed-off-by: Konstantin Khorenko Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 3968079afeec280491e6684481f55de898474b2d Author: Peter Rosin Date: Thu Dec 20 19:13:07 2018 +0100 fbdev: fbmem: behave better with small rotated displays and many CPUs [ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ] Blitting an image with "negative" offsets is not working since there is no clipping. It hopefully just crashes. For the bootup logo, there is protection so that blitting does not happen as the image is drawn further and further to the right (ROTATE_UR) or further and further down (ROTATE_CW). There is however no protection when drawing in the opposite directions (ROTATE_UD and ROTATE_CCW). Add back this protection. The regression is 20-odd years old but the mindless warning-killing mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove positive test on unsigned values") is also to blame, methinks. Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates") Signed-off-by: Peter Rosin Cc: Tomi Valkeinen Cc: Fabian Frederick Cc: Geert Uytterhoeven cc: Geoff Levand Cc: James Simmons Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit ac1a47438f5f60c70bca8d02e6501e72d95dcccd Author: Guoqing Jiang Date: Wed Dec 19 14:19:25 2018 +0800 md: fix raid10 hang issue caused by barrier [ Upstream commit e820d55cb99dd93ac2dc949cf486bb187e5cd70d ] When both regular IO and resync IO happen at the same time, and if we also need to split regular. Then we can see tasks hang due to barrier. 1. resync thread [ 1463.757205] INFO: task md1_resync:5215 blocked for more than 480 seconds. [ 1463.757207] Not tainted 4.19.5-1-default #1 [ 1463.757209] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1463.757212] md1_resync D 0 5215 2 0x80000000 [ 1463.757216] Call Trace: [ 1463.757223] ? __schedule+0x29a/0x880 [ 1463.757231] ? raise_barrier+0x8d/0x140 [raid10] [ 1463.757236] schedule+0x78/0x110 [ 1463.757243] raise_barrier+0x8d/0x140 [raid10] [ 1463.757248] ? wait_woken+0x80/0x80 [ 1463.757257] raid10_sync_request+0x1f6/0x1e30 [raid10] [ 1463.757265] ? _raw_spin_unlock_irq+0x22/0x40 [ 1463.757284] ? is_mddev_idle+0x125/0x137 [md_mod] [ 1463.757302] md_do_sync.cold.78+0x404/0x969 [md_mod] [ 1463.757311] ? wait_woken+0x80/0x80 [ 1463.757336] ? md_rdev_init+0xb0/0xb0 [md_mod] [ 1463.757351] md_thread+0xe9/0x140 [md_mod] [ 1463.757358] ? _raw_spin_unlock_irqrestore+0x2e/0x60 [ 1463.757364] ? __kthread_parkme+0x4c/0x70 [ 1463.757369] kthread+0x112/0x130 [ 1463.757374] ? kthread_create_worker_on_cpu+0x40/0x40 [ 1463.757380] ret_from_fork+0x3a/0x50 2. regular IO [ 1463.760679] INFO: task kworker/0:8:5367 blocked for more than 480 seconds. [ 1463.760683] Not tainted 4.19.5-1-default #1 [ 1463.760684] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1463.760687] kworker/0:8 D 0 5367 2 0x80000000 [ 1463.760718] Workqueue: md submit_flushes [md_mod] [ 1463.760721] Call Trace: [ 1463.760731] ? __schedule+0x29a/0x880 [ 1463.760741] ? wait_barrier+0xdd/0x170 [raid10] [ 1463.760746] schedule+0x78/0x110 [ 1463.760753] wait_barrier+0xdd/0x170 [raid10] [ 1463.760761] ? wait_woken+0x80/0x80 [ 1463.760768] raid10_write_request+0xf2/0x900 [raid10] [ 1463.760774] ? wait_woken+0x80/0x80 [ 1463.760778] ? mempool_alloc+0x55/0x160 [ 1463.760795] ? md_write_start+0xa9/0x270 [md_mod] [ 1463.760801] ? try_to_wake_up+0x44/0x470 [ 1463.760810] raid10_make_request+0xc1/0x120 [raid10] [ 1463.760816] ? wait_woken+0x80/0x80 [ 1463.760831] md_handle_request+0x121/0x190 [md_mod] [ 1463.760851] md_make_request+0x78/0x190 [md_mod] [ 1463.760860] generic_make_request+0x1c6/0x470 [ 1463.760870] raid10_write_request+0x77a/0x900 [raid10] [ 1463.760875] ? wait_woken+0x80/0x80 [ 1463.760879] ? mempool_alloc+0x55/0x160 [ 1463.760895] ? md_write_start+0xa9/0x270 [md_mod] [ 1463.760904] raid10_make_request+0xc1/0x120 [raid10] [ 1463.760910] ? wait_woken+0x80/0x80 [ 1463.760926] md_handle_request+0x121/0x190 [md_mod] [ 1463.760931] ? _raw_spin_unlock_irq+0x22/0x40 [ 1463.760936] ? finish_task_switch+0x74/0x260 [ 1463.760954] submit_flushes+0x21/0x40 [md_mod] So resync io is waiting for regular write io to complete to decrease nr_pending (conf->barrier++ is called before waiting). The regular write io splits another bio after call wait_barrier which call nr_pending++, then the splitted bio would continue with raid10_write_request -> wait_barrier, so the splitted bio has to wait for barrier to be zero, then deadlock happens as follows. resync io regular io raise_barrier wait_barrier generic_make_request wait_barrier To resolve the issue, we need to call allow_barrier to decrease nr_pending before generic_make_request since regular IO is not issued to underlying devices, and wait_barrier is called again to ensure no internal IO happening. Fixes: fc9977dd069e ("md/raid10: simplify the splitting of requests.") Reported-and-tested-by: Siniša Bandin Signed-off-by: Guoqing Jiang Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit 0e4bd8f5436c59d8c0bc416d320f91b22615b12f Author: Alexey Khoroshilov Date: Thu Dec 20 19:13:07 2018 +0100 video: clps711x-fb: release disp device node in probe() [ Upstream commit fdac751355cd76e049f628afe6acb8ff4b1399f7 ] clps711x_fb_probe() increments refcnt of disp device node by of_parse_phandle() and leaves it undecremented on both successful and error paths. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Cc: Alexander Shiyan Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Sasha Levin commit c06394a5c9368db3e25423bd5f96cb986973d9aa Author: Wenjing Liu Date: Wed Dec 5 12:14:45 2018 -0500 drm/amd/display: validate extended dongle caps [ Upstream commit 99b922f9ed6a6313c0d2247cde8aa1e4a0bd67e4 ] [why] Some dongle doesn't have a valid extended dongle caps, but we still set the extended dongle caps to be valid. This causes validation fails for all timing. [how] If no dp_hdmi_max_pixel_clk is provided, don't use extended dongle caps. Signed-off-by: Wenjing Liu Reviewed-by: Aric Cyr Reviewed-by: Jun Lei Acked-by: Abdoulaye Berthe Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7ee55abc1fee9da7080d18db8a1918021d57859e Author: Zhi Chen Date: Thu Dec 20 14:25:18 2018 +0200 ath10k: fix tx_stats memory leak [ Upstream commit 386f97e3b201d18578abb0e7037b85a1ae50c0a3 ] Memory of tx_stats was allocated when a STA was added. But it's not freed if the STA failed to be added to driver. This issue could be seen in MDK3 attack case when STA number reached the limit. Tested: QCA9984 with firmware ver 10.4-3.9.0.1-00005 Signed-off-by: Zhi Chen Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 38e98806b7608e1bb5c3577a10d32a2023ad3113 Author: Karthikeyan Periyasamy Date: Thu Dec 20 09:53:17 2018 +0200 ath10k: fix kernel panic due to use after free [ Upstream commit 553a7cca769d551f1317186760631487c47e23bf ] This issue arise in a race condition between ath10k_sta_state() and ath10k_htt_fetch_peer_stats(), explained in below scenario Steps: 1. In ath10k_sta_state(), arsta->tx_stats get deallocated before peer deletion when the station moves from IEEE80211_STA_NONE to IEEE80211_STA_NOTEXIST state. 2. Meanwhile ath10k receive HTT_T2H_MSG_TYPE_PEER_STATS message. In ath10k_htt_fetch_peer_stats(), arsta->tx_stats get accessed after the peer validation check. Since arsta->tx_stats get freed before the peer deletion [1]. ath10k_htt_fetch_peer_stats() ended up in "use after free" situation. Fixed this issue by moving the arsta->tx_stats free handling after the peer deletion. so that ath10k_htt_fetch_peer_stats() will not end up in "use after free" situation. Kernel Panic: Unable to handle kernel NULL pointer dereference at virtual address 00000286 pgd = d8754000 [00000286] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM ... CPU: 0 PID: 6245 Comm: hostapd Not tainted task: dc44cac0 ti: d4a38000 task.ti: d4a38000 PC is at kmem_cache_alloc+0x7c/0x114 LR is at ath10k_sta_state+0x190/0xd58 [ath10k_core] pc : [] lr : [] psr: 20000013 sp : d4a39b88 ip : 00000000 fp : 00000001 r10: 00000000 r9 : 1d3bc000 r8 : 00000dc0 r7 : 000080d0 r6 : d4a38000 r5 : dd401b00 r4 : 00000286 r3 : 00000000 r2 : d4a39ba0 r1 : 000080d0 r0 : dd401b00 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5787d Table: 5a75406a DAC: 00000015 Process hostapd (pid: 6245, stack limit = 0xd4a38238) Stack: (0xd4a39b88 to 0xd4a3a000) ... [] (kmem_cache_alloc) from [] (ath10k_sta_state+0x190/0xd58 [ath10k_core]) [] (ath10k_sta_state [ath10k_core]) from [] (sta_info_insert_rcu+0x418/0x61c [mac80211]) [] (sta_info_insert_rcu [mac80211]) from [] (ieee80211_add_station+0xf0/0x134 [mac80211]) [] (ieee80211_add_station [mac80211]) from [] (nl80211_new_station+0x330/0x36c [cfg80211]) [] (nl80211_new_station [cfg80211]) from [] (extack_doit+0x2c/0x74 [compat]) [] (extack_doit [compat]) from [] (genl_rcv_msg+0x274/0x30c) [] (genl_rcv_msg) from [] (netlink_rcv_skb+0x58/0xac) [] (netlink_rcv_skb) from [] (genl_rcv+0x20/0x34) [] (genl_rcv) from [] (netlink_unicast+0x11c/0x204) [] (netlink_unicast) from [] (netlink_sendmsg+0x30c/0x370) [] (netlink_sendmsg) from [] (sock_sendmsg+0x70/0x84) [] (sock_sendmsg) from [] (___sys_sendmsg.part.3+0x188/0x228) [] (___sys_sendmsg.part.3) from [] (__sys_sendmsg+0x4c/0x70) [] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x44) Code: ebfffec1 e1a04000 ea00001b e5953014 (e7940003) ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon Hardware tested: QCA9984 Firmware tested: 10.4-3.6.0.1-00004 Fixes: a904417fc ("ath10k: add extended per sta tx statistics support") Signed-off-by: Karthikeyan Periyasamy Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit bee009d6c021743352729b8bdf5b408f66493072 Author: Nathan Chancellor Date: Thu Dec 20 17:23:43 2018 +0100 drbd: Avoid Clang warning about pointless switch statment [ Upstream commit a52c5a16cf19d8a85831bb1b915a221dd4ffae3c ] There are several warnings from Clang about no case statement matching the constant 0: In file included from drivers/block/drbd/drbd_receiver.c:48: In file included from drivers/block/drbd/drbd_int.h:48: In file included from ./include/linux/drbd_genl_api.h:54: In file included from ./include/linux/genl_magic_struct.h:236: ./include/linux/drbd_genl.h:321:1: warning: no case matching constant switch condition '0' GENL_struct(DRBD_NLA_HELPER, 24, drbd_helper_info, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/genl_magic_struct.h:220:10: note: expanded from macro 'GENL_struct' switch (0) { ^ Silence this warning by adding a 'case 0:' statement. Additionally, adjust the alignment of the statements in the ct_assert_unique macro to avoid a checkpatch warning. This solution was originally sent by Arnd Bergmann with a default case statement: https://lore.kernel.org/patchwork/patch/756723/ Link: https://github.com/ClangBuiltLinux/linux/issues/43 Suggested-by: Lars Ellenberg Signed-off-by: Nathan Chancellor Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 28585c844529832d15160addda3b21bc3e75ab66 Author: Lars Ellenberg Date: Thu Dec 20 17:23:41 2018 +0100 drbd: skip spurious timeout (ping-timeo) when failing promote [ Upstream commit 9848b6ddd8c92305252f94592c5e278574e7a6ac ] If you try to promote a Secondary while connected to a Primary and allow-two-primaries is NOT set, we will wait for "ping-timeout" to give this node a chance to detect a dead primary, in case the cluster manager noticed faster than we did. But if we then are *still* connected to a Primary, we fail (after an additional timeout of ping-timout). This change skips the spurious second timeout. Most people won't notice really, since "ping-timeout" by default is half a second. But in some installations, ping-timeout may be 10 or 20 seconds or more, and spuriously delaying the error return becomes annoying. Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit aa0173f553f1c732448efe8f77f1536450824d7e Author: Lars Ellenberg Date: Thu Dec 20 17:23:32 2018 +0100 drbd: disconnect, if the wrong UUIDs are attached on a connected peer [ Upstream commit b17b59602b6dcf8f97a7dc7bc489a48388d7063a ] With "on-no-data-accessible suspend-io", DRBD requires the next attach or connect to be to the very same data generation uuid tag it lost last. If we first lost connection to the peer, then later lost connection to our own disk, we would usually refuse to re-connect to the peer, because it presents the wrong data set. However, if the peer first connects without a disk, and then attached its disk, we accepted that same wrong data set, which would be "unexpected" by any user of that DRBD and cause "undefined results" (read: very likely data corruption). The fix is to forcefully disconnect as soon as we notice that the peer attached to the "wrong" dataset. Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f7d594d051ff6f38c40b0766e26a6e77b3d8328d Author: Roland Kammerer Date: Thu Dec 20 17:23:28 2018 +0100 drbd: narrow rcu_read_lock in drbd_sync_handshake [ Upstream commit d29e89e34952a9ad02c77109c71a80043544296e ] So far there was the possibility that we called genlmsg_new(GFP_NOIO)/mutex_lock() while holding an rcu_read_lock(). This included cases like: drbd_sync_handshake (acquire the RCU lock) drbd_asb_recover_1p drbd_khelper drbd_bcast_event genlmsg_new(GFP_NOIO) --> may sleep drbd_sync_handshake (acquire the RCU lock) drbd_asb_recover_1p drbd_khelper notify_helper genlmsg_new(GFP_NOIO) --> may sleep drbd_sync_handshake (acquire the RCU lock) drbd_asb_recover_1p drbd_khelper notify_helper mutex_lock --> may sleep While using GFP_ATOMIC whould have been possible in the first two cases, the real fix is to narrow the rcu_read_lock. Reported-by: Jia-Ju Bai Reviewed-by: Lars Ellenberg Signed-off-by: Roland Kammerer Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f8a8291e3f87e4f7df13b438ba2497160032831e Author: Miroslav Lichvar Date: Mon Dec 3 13:59:41 2018 +0100 mlx5: update timecounter at least twice per counter overflow [ Upstream commit 5d8678365c90b9ce1fd2243ff5ea562609f6cec1 ] The timecounter needs to be updated at least once in half of the cyclecounter interval to prevent timecounter_cyc2time() interpreting a new timestamp as an old value and causing a backward jump. This would be an issue if the timecounter multiplier was so small that the update interval would not be limited by the 64-bit overflow in multiplication. Shorten the calculated interval to make sure the timecounter is updated in time even when the system clock is slowed down by up to 10%, the multiplier is increased by up to 10%, and the scheduled overflow check is late by 15%. Cc: Richard Cochran Cc: Ariel Levkovich Cc: Saeed Mahameed Signed-off-by: Miroslav Lichvar Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 4fe87824d16c726ca5ff9f052bb8319947131f3b Author: Alexey Kardashevskiy Date: Fri Sep 28 16:45:39 2018 +1000 powerpc/powernv/ioda: Allocate indirect TCE levels of cached userspace addresses on demand [ Upstream commit bdbf649efe21173cae63b4b71db84176420f9039 ] The powernv platform maintains 2 TCE tables for VFIO - a hardware TCE table and a table with userspace addresses; the latter is used for marking pages dirty when corresponging TCEs are unmapped from the hardware table. a68bd1267b72 ("powerpc/powernv/ioda: Allocate indirect TCE levels on demand") enabled on-demand allocation of the hardware table, however it missed the other table so it has still been fully allocated at the boot time. This fixes the issue by allocating a single level, just like we do for the hardware table. Fixes: a68bd1267b72 ("powerpc/powernv/ioda: Allocate indirect TCE levels on demand") Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit d2cf1056d7cc8badc370986e2009d7ba817ea6f4 Author: Naftali Goldstein Date: Wed Aug 22 12:18:19 2018 +0300 iwlwifi: mvm: fix setting HE ppe FW config [ Upstream commit 189b8d441b0f7825f0b4278851c52afaa0515ed2 ] The FW expects to get the ppe value for each NSS-BW pair in the same format as in the he phy capabilities IE, which means that a value of 0 implies ppe should be used for BPSK (mcs 0). If there are no PPE thresholds in the IE, or if for some NSS-RU pair there's no threshold set for it (this could happen because it's a variable-sized field), it means no PPE should not be used for that pair, so the value sent to FW should be 7 which corresponds to "none". Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") Signed-off-by: Naftali Goldstein Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 800868e397fdb4ca64a79849e50b998c95045856 Author: Madhavan Srinivasan Date: Sun Dec 9 14:48:15 2018 +0530 powerpc/perf: Fix thresholding counter data for unknown type [ Upstream commit 17cfccc91545682513541924245abb876d296063 ] MMCRA[34:36] and MMCRA[38:44] expose the thresholding counter value. Thresholding counter can be used to count latency cycles such as load miss to reload. But threshold counter value is not relevant when the sampled instruction type is unknown or reserved. Patch to fix the thresholding counter value to zero when sampled instruction type is unknown or reserved. Fixes: 170a315f41c6('powerpc/perf: Support to export MMCRA[TEC*] field to userspace') Signed-off-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 7c50af52bf578db57ee851ae0e92bfa59fa0c600 Author: Jian Shen Date: Thu Dec 20 11:52:04 2018 +0800 net: hns3: don't restore rules when flow director is disabled [ Upstream commit 8edc2285b7285c5fbffe438dc8113260d3e76656 ] When user disables flow director, all the rules will be disabled. But when reset happens, it will restore all the rules again. It's not reasonable. This patch fixes it by add flow director status check before restore fules. Fixes: 6871af29b3ab ("net: hns3: Add reset handle for flow director") Fixes: c17852a8932f ("net: hns3: Add support for enable/disable flow director") Signed-off-by: Jian Shen Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8f6c74d1a1c44a5ede818951c752233d3321b669 Author: Peng Li Date: Thu Dec 20 11:52:05 2018 +0800 net: hns3: fix the descriptor index when get rss type [ Upstream commit 31a16f99e02c2e0b40a5fb05d66f5e56721027e2 ] Driver gets rss information from the last descriptor of the packet. When driver handle the rss type, ring->next_to_clean indicates the first descriptor of next packet. This patch fix the descriptor index with "ring->next_to_clean - 1". Fixes: 232fc64b6e62 ("net: hns3: Add HW RSS hash information to RX skb") Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0453c5dd8b826b7c4a711670357448b83d72d846 Author: Jian Shen Date: Thu Dec 20 11:52:01 2018 +0800 net: hns3: add max vector number check for pf [ Upstream commit 75edb610860fda65ceedb017fc69afabd2806b8b ] Each pf supports max 64 vectors and 128 tqps. For 2p/4p core scenario, there may be more than 64 cpus online. So the result of min_t(u16, num_Online_cpus(), tqp_num) may be more than 64. This patch adds check for the vector number. Fixes: dd38c72604dc ("net: hns3: fix for coalesce configuration lost during reset") Signed-off-by: Jian Shen Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e8fdcc65642ec6865f0a6d865e5ec5fab1f5ca19 Author: Jia-Ju Bai Date: Fri Dec 14 11:55:21 2018 +0800 cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan() [ Upstream commit 4f68ef64cd7feb1220232bd8f501d8aad340a099 ] The function cw1200_bss_info_changed() and cw1200_hw_scan() can be concurrently executed. The two functions both access a possible shared variable "frame.skb". This shared variable is freed by dev_kfree_skb() in cw1200_upload_beacon(), which is called by cw1200_bss_info_changed(). The free operation is protected by a mutex lock "priv->conf_mutex" in cw1200_bss_info_changed(). In cw1200_hw_scan(), this shared variable is accessed without the protection of the mutex lock "priv->conf_mutex". Thus, concurrency use-after-free bugs may occur. To fix these bugs, the original calls to mutex_lock(&priv->conf_mutex) and mutex_unlock(&priv->conf_mutex) are moved to the places, which can protect the accesses to the shared variable. Signed-off-by: Jia-Ju Bai Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 8e199bb5de5e0574f3cdcc6f28aaecb810c94e6c Author: Mahesh Rajashekhara Date: Tue Dec 18 17:39:01 2018 -0600 scsi: smartpqi: increase fw status register read timeout [ Upstream commit 65111785acccb836ec75263b03b0e33f21e74f47 ] Problem: - during the driver initialization, driver will poll fw for KERNEL_UP in a 30 seconds timeout. - if the firmware is not ready after 30 seconds, driver will not be loaded. Fix: - change timeout from 30 seconds to 3 minutes. Reported-by: Feng Li Reviewed-by: Ajish Koshy Reviewed-by: Murthy Bhat Reviewed-by: Dave Carroll Reviewed-by: Kevin Barnett Signed-off-by: Mahesh Rajashekhara Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 863b007a234729cfeee9edca71cb93642d1df2b4 Author: Dave Carroll Date: Fri Dec 7 16:29:45 2018 -0600 scsi: smartpqi: correct volume status [ Upstream commit 7ff44499bafbd376115f0bb6b578d980f56ee13b ] - fix race condition when a unit is deleted after an RLL, and before we have gotten the LV_STATUS page of the unit. - In this case we will get a standard inquiry, rather than the desired page. This will result in a unit presented which no longer exists. - If we ask for LV_STATUS, insure we get LV_STATUS Reviewed-by: Murthy Bhat Reviewed-by: Mahesh Rajashekhara Reviewed-by: Scott Teel Reviewed-by: Kevin Barnett Signed-off-by: Dave Carroll Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 238fd479f01a63c53cec4c3d41fe60a6499d8ad4 Author: Mahesh Rajashekhara Date: Fri Dec 7 16:28:29 2018 -0600 scsi: smartpqi: correct host serial num for ssa [ Upstream commit b2346b5030cf9458f30a84028d9fe904b8c942a7 ] Reviewed-by: Scott Benesh Reviewed-by: Ajish Koshy Reviewed-by: Murthy Bhat Reviewed-by: Mahesh Rajashekhara Reviewed-by: Dave Carroll Reviewed-by: Scott Teel Reviewed-by: Kevin Barnett Signed-off-by: Mahesh Rajashekhara Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 724234517772e22262b7aace47b4c6260290b7de Author: Ido Schimmel Date: Wed Dec 19 06:08:45 2018 +0000 mlxsw: spectrum: Properly cleanup LAG uppers when removing port from LAG [ Upstream commit be2d6f421f680e01d58f7cd452646e0d8586d49b ] When a LAG device or a VLAN device on top of it is enslaved to a bridge, the driver propagates the CHANGEUPPER event to the LAG's slaves. This causes each physical port to increase the reference count of the internal representation of the bridge port by calling mlxsw_sp_port_bridge_join(). However, when a port is removed from a LAG, the corresponding leave() function is not called and the reference count is not decremented. This leads to ugly hacks such as mlxsw_sp_bridge_port_should_destroy() that try to understand if the bridge port should be destroyed even when its reference count is not 0. Instead, make sure that when a port is unlinked from a LAG it would see the same events as if the LAG (or its uppers) were unlinked from a bridge. The above is achieved by walking the LAG's uppers when a port is unlinked and calling mlxsw_sp_port_bridge_leave() for each upper that is enslaved to a bridge. Signed-off-by: Ido Schimmel Reviewed-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 26eee9088b3901a5817584d0b6284d004061ce70 Author: YueHaibing Date: Wed Dec 19 14:45:09 2018 +0800 xfrm6_tunnel: Fix spi check in __xfrm6_tunnel_alloc_spi [ Upstream commit fa89a4593b927b3f59c3b69379f31d3b22272e4e ] gcc warn this: net/ipv6/xfrm6_tunnel.c:143 __xfrm6_tunnel_alloc_spi() warn: always true condition '(spi <= 4294967295) => (0-u32max <= u32max)' 'spi' is u32, which always not greater than XFRM6_TUNNEL_SPI_MAX because of wrap around. So the second forloop will never reach. Signed-off-by: YueHaibing Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 6098aab90073580f073aa5a9a7eb96040c4cd0ef Author: Johannes Berg Date: Sat Dec 15 11:03:12 2018 +0200 mac80211: fix radiotap vendor presence bitmap handling [ Upstream commit efc38dd7d5fa5c8cdd0c917c5d00947aa0539443 ] Due to the alignment handling, it actually matters where in the code we add the 4 bytes for the presence bitmap to the length; the first field is the timestamp with 8 byte alignment so we need to add the space for the extra vendor namespace presence bitmap *before* we do any alignment for the fields. Move the presence bitmap length accounting to the right place to fix the alignment for the data properly. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ea76421fc41c6e80aaaca6c559bdb10ade28d48e Author: Christophe Leroy Date: Mon Dec 10 06:50:09 2018 +0000 powerpc/uaccess: fix warning/error with access_ok() [ Upstream commit 05a4ab823983d9136a460b7b5e0d49ee709a6f86 ] With the following piece of code, the following compilation warning is encountered: if (_IOC_DIR(ioc) != _IOC_NONE) { int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ; if (!access_ok(verify, ioarg, _IOC_SIZE(ioc))) { drivers/platform/test/dev.c: In function 'my_ioctl': drivers/platform/test/dev.c:219:7: warning: unused variable 'verify' [-Wunused-variable] int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ; This patch fixes it by referencing 'type' in the macro allthough doing nothing with it. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 1509f994e5ed461c435aefa2e5c19394e2690dc2 Author: Eric Yang Date: Thu Nov 22 02:07:06 2018 -0500 drm/amd/display: fix YCbCr420 blank color [ Upstream commit 12750d1647f118496f1da727146f255f5e44d500 ] [Why] YCbCr420 packing format uses two chanels for luma, and 1 channel for both chroma component. Our previous implementation did not account for this and results in every other pixel having very high luma value, showing greyish color instead of black. YCbCr444 = ; ..... YCbCr420 = ; ..... [How] Program the second channel with the black color value for luma as well. Signed-off-by: Eric Yang Reviewed-by: Hugo Hu Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 815e4fe3fdeab984f3da04ee438f9f657e97f05e Author: Chen-Yu Tsai Date: Mon Dec 17 12:04:39 2018 +0800 Bluetooth: hci_bcm: Handle deferred probing for the clock supply [ Upstream commit 28ac03b9ac3f784c2f048a910c8d0a7a87483b66 ] On some systems that actually have the bluetooth controller wired up with an extra clock signal, it's possible the bluetooth controller probes before the clock provider. clk_get would return a defer probe error, which was not handled by this driver. Handle this properly, so that these systems can work reliably. Tested-by: Ondrej Jirman Signed-off-by: Chen-Yu Tsai Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit e1f7735b261fa71ad85021680dbc9ab391c9d9b7 Author: Dale Zhao Date: Thu Nov 22 17:13:46 2018 +0800 drm/amd/display: Wait edp HPD to high in detect_sink [ Upstream commit 0a6414e75d231ee1bb7ffb2f5eb246b682a884cd ] [Why] In 99% user case, edp will be post by vbios. In 1% / current case: Lenovo don't light up edp panel in vbios post stage, vbios won't be lit up. Thus in dal when we init DCN 10 hw, we power up edp, then we start detect_sink, but internal time is too short, when we detect it, HPD is still low, so we don't detect the edp, and edp shows black. [How] When we init hw, we wait edp HPD to high after power up edp. Signed-off-by: Dale Zhao Reviewed-by: Eric Yang Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9c77d1a5311e95522abedf797285afa49f10d920 Author: Paul Hsieh Date: Thu Nov 22 18:43:45 2018 +0800 drm/amd/display: Add retry to read ddc_clock pin [ Upstream commit bd4905a9583c760da31ded7256dca6f71483c3dc ] [WHY] On customer board, there is one pluse (1v , < 1ms) on DDC_CLK pin when plug / unplug DP cable. Driver will read it and config DP to HDMI/DVI dongle. [HOW] If there is a real dongle, DDC_CLK should be always pull high. Try to read again to recovery this special case. Retry times = 3. Need additional 3ms to detect DP passive dongle(3 failures) Signed-off-by: Paul Hsieh Reviewed-by: Eric Yang Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 368aa93b49cc6482df6375d59adf9943b46f890b Author: Huazhong Tan Date: Tue Dec 18 19:37:53 2018 +0800 net: hns3: fix incomplete uninitialization of IRQ in the hns3_nic_uninit_vector_data() [ Upstream commit ae6017a71115ebc4e5c1a3f0f451319ab3f5c447 ] In the hns3_nic_uninit_vector_data(), the procedure of uninitializing the tqp_vector's IRQ has not set affinity_notify to NULL and changes its init flag. This patch fixes it. And for simplificaton, local variable tqp_vector is used instead of priv->tqp_vector[i]. Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC") Signed-off-by: Huazhong Tan Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 07a521165f787cd5f9767029924bf2ad797ef60f Author: Huazhong Tan Date: Tue Dec 18 19:37:48 2018 +0800 net: hns3: fix error handling int the hns3_get_vector_ring_chain [ Upstream commit cda69d244585bc4497d3bb878c22fe2b6ad647c1 ] When hns3_get_vector_ring_chain() failed in the hns3_nic_init_vector_data(), it should do the error handling instead of return directly. Also, cur_chain should be freed instead of chain and head->next should be set to NULL in error handling of hns3_get_vector_ring_chain. This patch fixes them. Fixes: 73b907a083b8 ("net: hns3: bugfix for buffer not free problem during resetting") Signed-off-by: Huazhong Tan Signed-off-by: Peng Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9b8b41319dba06ca3adb53b7aeafa4798353ac5d Author: Dennis Zhou Date: Tue Dec 18 08:42:27 2018 -0800 percpu: convert spin_lock_irq to spin_lock_irqsave. [ Upstream commit 6ab7d47bcbf0144a8cb81536c2cead4cde18acfe ] From Michael Cree: "Bisection lead to commit b38d08f3181c ("percpu: restructure locking") as being the cause of lockups at initial boot on the kernel built for generic Alpha. On a suggestion by Tejun Heo that: So, the only thing I can think of is that it's calling spin_unlock_irq() while irq handling isn't set up yet. Can you please try the followings? 1. Convert all spin_[un]lock_irq() to spin_lock_irqsave/unlock_irqrestore()." Fixes: b38d08f3181c ("percpu: restructure locking") Reported-and-tested-by: Michael Cree Acked-by: Tejun Heo Signed-off-by: Dennis Zhou Signed-off-by: Sasha Levin commit ff32c3a3b0dd6d93de32a1c407d3a8247b23a407 Author: Arnaldo Carvalho de Melo Date: Tue Dec 11 16:43:40 2018 -0300 perf tools: Cast off_t to s64 to avoid warning on bionic libc [ Upstream commit 866053bb644f754d1a93aaa9db9998fecf7a8978 ] To avoid this warning: CC /tmp/build/perf/util/s390-cpumsf.o util/s390-cpumsf.c: In function 's390_cpumsf_samples': util/s390-cpumsf.c:508:3: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'off_t' [-Wformat=] pr_err("[%#08" PRIx64 "] Invalid AUX trailer entry TOD clock base\n", ^ Now the various Android cross toolchains used in the perf tools container test builds are all clean and we can remove this: export EXTRA_MAKE_ARGS="WERROR=0" Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: Thomas Richter Link: https://lkml.kernel.org/n/tip-5rav4ccyb0sjciysz2i4p3sx@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ea6e499c2bfe879de0f92530218dc27179f5a713 Author: Arnaldo Carvalho de Melo Date: Tue Dec 11 16:11:54 2018 -0300 perf header: Fix up argument to ctime() [ Upstream commit 0afcf29bab35d3785204cd9bd51693b231ad7181 ] Reducing this noise when cross building to the Android NDK: util/header.c: In function 'perf_header__fprintf_info': util/header.c:2710:45: warning: pointer targets in passing argument 1 of 'ctime' differ in signedness [-Wpointer-sign] fprintf(fp, "# captured on : %s", ctime(&st.st_ctime)); ^ In file included from util/../perf.h:5:0, from util/evlist.h:11, from util/header.c:22: /opt/android-ndk-r15c/platforms/android-26/arch-arm/usr/include/time.h:81:14: note: expected 'const time_t *' but argument is of type 'long unsigned int *' extern char* ctime(const time_t*) __LIBC_ABI_PUBLIC__; ^ Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-6bz74zp080yhmtiwb36enso9@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2cd6e922faeca0287b7fefc7f73cba2031dfb4f6 Author: Bin Liu Date: Tue Dec 18 07:58:05 2018 -0600 usb: musb: dsps: fix runtime pm for peripheral mode [ Upstream commit 54578ee883e34d2d1c518d48f1c1e2dd3f387188 ] Since the runtime PM support was added in musb, dsps relies on the timer calling otg_timer() to activate the usb subsystem. However the driver doesn't enable the timer for peripheral port, then the peripheral port is unable to be enumerated by a host if the other usb port is disabled or in peripheral mode too. So let's start the timer for peripheral port too. Fixes: ea2f35c01d5e ("usb: musb: Fix sleeping function called from invalid context for hdrc glue") Acked-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 558321c9b7c6d6f5547b5a4d8967d36700fd6b8e Author: Bin Liu Date: Tue Dec 18 07:58:04 2018 -0600 usb: musb: dsps: fix otg state machine [ Upstream commit 6010abf2c2c0e382d7e8ee44bd11f343aae90cce ] Due to lack of ID pin interrupt event on AM335x devices, the musb dsps driver uses polling to detect usb device attach for dual-role port. But in the case if a micro-A cable adapter is attached without a USB device attached to the cable, the musb state machine gets stuck in a_wait_vrise state waiting for the MUSB_CONNECT interrupt which won't happen due to the usb device is not attached. The state is stuck in a_wait_vrise even after the micro-A cable is detached, which could cause VBUS retention if then the dual-role port is attached to a host port. To fix the problem, make a_wait_vrise as a transient state, then move the state to either a_wait_bcon for host port or a_idle state for dual-role port, if no usb device is attached to the port. Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 816a263d0986b8105777bef24fa4b8b463ee598d Author: Mark Rutland Date: Fri Nov 9 15:07:10 2018 +0000 arm64: KVM: Skip MMIO insn after emulation [ Upstream commit 0d640732dbebed0f10f18526de21652931f0b2f2 ] When we emulate an MMIO instruction, we advance the CPU state within decode_hsr(), before emulating the instruction effects. Having this logic in decode_hsr() is opaque, and advancing the state before emulation is problematic. It gets in the way of applying consistent single-step logic, and it prevents us from being able to fail an MMIO instruction with a synchronous exception. Clean this up by only advancing the CPU state *after* the effects of the instruction are emulated. Cc: Peter Maydell Reviewed-by: Alex Bennée Reviewed-by: Christoffer Dall Signed-off-by: Mark Rutland Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 0d403218b64c9877b62f5e628f698e4696618497 Author: Nicholas Mc Guire Date: Fri Dec 14 17:56:10 2018 +0100 livepatch: check kzalloc return values [ Upstream commit 5f30b2e823484ce6a79f2b59901b6351c15effa6 ] kzalloc() return should always be checked - notably in example code where this may be seen as reference. On failure of allocation in livepatch_fix1_dummy_alloc() respectively dummy_alloc() previous allocation is freed (thanks to Petr Mladek for catching this) and NULL returned. Signed-off-by: Nicholas Mc Guire Fixes: 439e7271dc2b ("livepatch: introduce shadow variable API") Acked-by: Joe Lawrence Reviewed-by: Petr Mladek Acked-by: Miroslav Benes Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 1901cf6043b28e84c7f3e13bd38cea083e38aca3 Author: Ilan Peer Date: Sat Dec 15 11:03:17 2018 +0200 mac80211: Properly handle SKB with radiotap only [ Upstream commit 8020919a9b99d6c990dc6a50e8215e291fbbe5a6 ] The monitor interface Rx handling of SKBs that contain only radiotap information was buggy as it tried to access the SKB assuming it contains a frame. To fix this, check the RX_FLAG_NO_PSDU flag in the Rx status (indicting that the SKB contains only radiotap information), and do not perform data path specific processing when the flag is set. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit abcfd9c3d93b105c8cae9d43d18ed5d9765611f2 Author: Nicholas Mc Guire Date: Fri Dec 7 11:34:27 2018 +0100 pinctrl: rza1: Handle devm_kasprintf() failure cases [ Upstream commit db221412cd2014506642967155698825ad80f6b6 ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignments are not safe if not checked. On error rza1_pinctrl_register() respectively rza1_parse_gpiochip() return negative values so -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here. Signed-off-by: Nicholas Mc Guire Fixes: 5a49b644b307 ("pinctrl: Renesas RZ/A1 pin and gpio controller") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 5c4c55083953eea6649dc4c19606b5a77daa7030 Author: Doug Smythies Date: Mon Dec 17 23:34:04 2018 -0800 tools/power/x86/intel_pstate_tracer: Fix non root execution for post processing a trace file [ Upstream commit 663546903c835fe46308b1b1e53d32d1f2b33da9 ] This script is supposed to be allowed to run with regular user privileges if a previously captured trace is being post processed. Commit fbe313884d7d (tools/power/x86/intel_pstate_tracer: Free the trace buffer memory) introduced a bug that breaks that option. Commit 35459105deb2 (tools/power/x86/intel_pstate_tracer: Add optional setting of trace buffer memory allocation) moved the code but kept the bug. This patch fixes the issue. Fixes: 35459105deb2 (tools/power/x86/intel_pstate_tracer: Add optional ...) Signed-off-by: Doug Smythies Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 928dbf6a29a1a1a9626103f742ba2e2116a44045 Author: Michael Chan Date: Sun Dec 16 18:46:24 2018 -0500 bnxt_en: Disable MSIX before re-reserving NQs/CMPL rings. [ Upstream commit 36d65be9a88052cdfc8524eb591baf0e6c878408 ] When bringing up a device, the code checks to see if the number of MSIX has changed. pci_disable_msix() should be called first before changing the number of reserved NQs/CMPL rings. This ensures that the MSIX vectors associated with the NQs/CMPL rings are still properly mapped when pci_disable_msix() masks the vectors. This patch will prevent errors when RDMA support is added for the new 57500 chips. When the RDMA driver shuts down, the number of NQs is decreased and we must use the new sequence to prevent MSIX errors. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8b5518fa39b8f5a38afe8d5e07fbf54e2034b584 Author: Fabrizio Castro Date: Thu Dec 13 20:22:34 2018 +0000 i2c: sh_mobile: Add support for r8a774c0 (RZ/G2E) [ Upstream commit 51243b73455f2d12cb82abffa7bc9028aec656e0 ] Similarly to R-Car E3, RZ/G2E doesn't come with automatic transmission registers, as such it is not considered compatible with the existing fallback bindings. Add SoC specific binding compatibility to allow for later support for automatic transmission. Signed-off-by: Fabrizio Castro Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 9c10d5b2e371c52962b00273210cf5a933fe8301 Author: Arnaldo Carvalho de Melo Date: Thu Dec 6 11:50:08 2018 -0300 perf probe: Fix unchecked usage of strncpy() [ Upstream commit bef0b8970f27da5ca223e522a174d03e2587761d ] The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. In this case the 'target' buffer is coming from a list of build-ids that are expected to have a len of at most (SBUILD_ID_SIZE - 1) chars, so probably we're safe, but since we're using strncpy() here, use strlcpy() instead to provide the intended safety checking without the using the problematic strncpy() function. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: util/probe-file.c: In function 'probe_cache__open.isra.5': util/probe-file.c:427:3: error: 'strncpy' specified bound 41 equals destination size [-Werror=stringop-truncation] strncpy(sbuildid, target, SBUILD_ID_SIZE); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Cc: Adrian Hunter Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Fixes: 1f3736c9c833 ("perf probe: Show all cached probes") Link: https://lkml.kernel.org/n/tip-l7n8ggc9kl38qtdlouke5yp5@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 724317bc960f9dab88dc4909f59159e8ee21b150 Author: Ethan Lien Date: Thu Nov 1 14:49:03 2018 +0800 btrfs: use tagged writepage to mitigate livelock of snapshot [ Upstream commit 3cd24c698004d2f7668e0eb9fc1f096f533c791b ] Snapshot is expected to be fast. But if there are writers steadily creating dirty pages in our subvolume, the snapshot may take a very long time to complete. To fix the problem, we use tagged writepage for snapshot flusher as we do in the generic write_cache_pages(), so we can omit pages dirtied after the snapshot command. This does not change the semantics regarding which data get to the snapshot, if there are pages being dirtied during the snapshotting operation. There's a sync called before snapshot is taken in old/new case, any IO in flight just after that may be in the snapshot but this depends on other system effects that might still sync the IO. We do a simple snapshot speed test on a Intel D-1531 box: fio --ioengine=libaio --iodepth=32 --bs=4k --rw=write --size=64G --direct=0 --thread=1 --numjobs=1 --time_based --runtime=120 --filename=/mnt/sub/testfile --name=job1 --group_reporting & sleep 5; time btrfs sub snap -r /mnt/sub /mnt/snap; killall fio original: 1m58sec patched: 6.54sec This is the best case for this patch since for a sequential write case, we omit nearly all pages dirtied after the snapshot command. For a multi writers, random write test: fio --ioengine=libaio --iodepth=32 --bs=4k --rw=randwrite --size=64G --direct=0 --thread=1 --numjobs=4 --time_based --runtime=120 --filename=/mnt/sub/testfile --name=job1 --group_reporting & sleep 5; time btrfs sub snap -r /mnt/sub /mnt/snap; killall fio original: 15.83sec patched: 10.35sec The improvement is smaller compared to the sequential write case, since we omit only half of the pages dirtied after snapshot command. Reviewed-by: Nikolay Borisov Signed-off-by: Ethan Lien Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b0e6bdbf51cba1d6f0c9d68b693d7b7e9e7d3575 Author: Arnaldo Carvalho de Melo Date: Thu Dec 6 11:02:57 2018 -0300 perf header: Fix unchecked usage of strncpy() [ Upstream commit 7572588085a13d5db02bf159542189f52fdb507e ] The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: util/header.c: In function 'perf_event__synthesize_event_update_unit': util/header.c:3586:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation] strncpy(ev->data, evsel->unit, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ util/header.c:3579:16: note: length computed here size_t size = strlen(evsel->unit); ^~~~~~~~~~~~~~~~~~~ Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Fixes: a6e5281780d1 ("perf tools: Add event_update event unit type") Link: https://lkml.kernel.org/n/tip-fiikh5nay70bv4zskw2aa858@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0d0fa1a67531df8ac1827c2ab7e31be1d191c261 Author: Arnaldo Carvalho de Melo Date: Thu Dec 6 10:49:46 2018 -0300 perf dso: Fix unchecked usage of strncpy() [ Upstream commit fca5085c15255bbde203b7322c15f07ebb12f63e ] The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: In function 'decompress_kmodule', inlined from 'dso__decompress_kmodule_fd' at util/dso.c:305:9: util/dso.c:298:3: error: 'strncpy' destination unchanged after copying no bytes [-Werror=stringop-truncation] strncpy(pathname, tmpbuf, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC /tmp/build/perf/util/values.o CC /tmp/build/perf/util/debug.o cc1: all warnings being treated as errors Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Fixes: c9a8a6131fb6 ("perf tools: Move the temp file processing into decompress_kmodule") Link: https://lkml.kernel.org/n/tip-tl2hdxj64tt4k8btbi6a0ugw@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 411966ccd7bfa0ce87190bb5b14e20a93b68beac Author: Adrian Hunter Date: Thu Nov 22 16:04:56 2018 +0200 perf test: Fix perf_event_attr test failure [ Upstream commit 741dad88dde296999da30332157ca47f0543747d ] Fix inconsistent use of tabs and spaces error: # perf test 16 -v 16: Setup struct perf_event_attr : --- start --- test child forked, pid 20224 File "/usr/libexec/perf-core/tests/attr.py", line 119 log.warning("expected %s=%s, got %s" % (t, self[t], other[t])) ^ TabError: inconsistent use of tabs and spaces in indentation test child finished with -1 ---- end ---- Setup struct perf_event_attr: FAILED! Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/20181122140456.16817-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 52ed1f4c8e784288b530764d3ff4277523fb52ea Author: Stephane Eranian Date: Wed Nov 7 02:50:45 2018 -0800 perf stat: Fix CSV mode column output for non-cgroup events [ Upstream commit bc4da38a4789e7819fca4c7723ded0b86aea27c0 ] When using the -x option, perf stat prints CSV-style output with one event per line. For each event, it prints the count, the unit, the event name, the cgroup, and a bunch of other event specific fields (such as insn per cycles). When you use CSV-style mode, you expect a normalized output where each event is printed with the same number of fields regardless of what it is so it can easily be imported into a spreadsheet or parsed. For instance, if an event does not have a unit, then print an empty field for it. Although this approach was implemented for the unit, it was not for the cgroup. When mixing cgroup and non-cgroup events, then non-cgroup events would not show an empty field, instead the next field was printed, make columns not line up correctly. This patch fixes the cgroup output issues by forcing an empty field for non-cgroup events as soon as one event has cgroup. Before: @ @cycles @foo @ 0 @100.00@@ 2531614 @ @cycles @6420922@100.00@ @ foo cgroup lines up with time_running! After: @ @cycles @foo @0 @100.00@@ 2594834 @ @cycles @ @5287372 @100.00@@ Fields line up. Signed-off-by: Stephane Eranian Acked-by: Jiri Olsa Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1541587845-9150-1-git-send-email-eranian@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 98b0af2133141860ed74a78fe60b7e76b63e492a Author: Beomho Seo Date: Fri Dec 14 12:34:08 2018 +0100 tty: serial: samsung: Properly set flags in autoCTS mode [ Upstream commit 31e933645742ee6719d37573a27cce0761dcf92b ] Commit 391f93f2ec9f ("serial: core: Rework hw-assited flow control support") has changed the way the autoCTS mode is handled. According to that change, serial drivers which enable H/W autoCTS mode must set UPSTAT_AUTOCTS to prevent the serial core from inadvertently disabling TX. This patch adds proper handling of UPSTAT_AUTOCTS flag. Signed-off-by: Beomho Seo [mszyprow: rephrased commit message] Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d5f463c698086997c5753b5299da945db1411781 Author: Geert Uytterhoeven Date: Thu Dec 13 19:44:43 2018 +0100 serial: sh-sci: Resume PIO in sci_rx_interrupt() on DMA failure [ Upstream commit 71ab1c0336c71ace5725740f200beca9667a339f ] On (H)SCIF, sci_submit_rx() is called in the receive interrupt handler. Hence if DMA submission fails, the interrupt handler should resume handling reception using PIO, else no more data is received. Make sci_submit_rx() return an error indicator, so the receive interrupt handler can act appropriately. Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Acked-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 556822da8da10a878a4f49afe991db5660aff9c9 Author: Geert Uytterhoeven Date: Thu Dec 13 19:44:41 2018 +0100 serial: sh-sci: Fix locking in sci_submit_rx() [ Upstream commit dd1f2250da95e87cb3e612858f94b14f99445a7c ] Some callers of sci_submit_rx() hold the port spinlock, others don't. During fallback to PIO, the driver needs to obtain the port spinlock. If the lock was already held, spinlock recursion is detected, causing a deadlock: BUG: spinlock recursion on CPU#0. Fix this by adding a flag parameter to sci_submit_rx() for the caller to indicate the port spinlock is already held, so spinlock recursion can be avoided. Move the spin_lock_irqsave() up, so all DMA disable steps are protected, which is safe as the recently introduced dmaengine_terminate_async() can be called in atomic context. Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7e018cddb7cb3dd004acccf188e32040cf8677b4 Author: Anand Jain Date: Mon Oct 15 10:45:17 2018 +0800 btrfs: harden agaist duplicate fsid on scanned devices [ Upstream commit a9261d4125c97ce8624e9941b75dee1b43ad5df9 ] It's not that impossible to imagine that a device OR a btrfs image is copied just by using the dd or the cp command. Which in case both the copies of the btrfs will have the same fsid. If on the system with automount enabled, the copied FS gets scanned. We have a known bug in btrfs, that we let the device path be changed after the device has been mounted. So using this loop hole the new copied device would appears as if its mounted immediately after it's been copied. For example: Initially.. /dev/mmcblk0p4 is mounted as / $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 29.2G 0 disk |-mmcblk0p4 179:4 0 4G 0 part / |-mmcblk0p2 179:2 0 500M 0 part /boot |-mmcblk0p3 179:3 0 256M 0 part [SWAP] `-mmcblk0p1 179:1 0 256M 0 part /boot/efi $ btrfs fi show Label: none uuid: 07892354-ddaa-4443-90ea-f76a06accaba Total devices 1 FS bytes used 1.40GiB devid 1 size 4.00GiB used 3.00GiB path /dev/mmcblk0p4 Copy mmcblk0 to sda $ dd if=/dev/mmcblk0 of=/dev/sda And immediately after the copy completes the change in the device superblock is notified which the automount scans using btrfs device scan and the new device sda becomes the mounted root device. $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 14.9G 0 disk |-sda4 8:4 1 4G 0 part / |-sda2 8:2 1 500M 0 part |-sda3 8:3 1 256M 0 part `-sda1 8:1 1 256M 0 part mmcblk0 179:0 0 29.2G 0 disk |-mmcblk0p4 179:4 0 4G 0 part |-mmcblk0p2 179:2 0 500M 0 part /boot |-mmcblk0p3 179:3 0 256M 0 part [SWAP] `-mmcblk0p1 179:1 0 256M 0 part /boot/efi $ btrfs fi show / Label: none uuid: 07892354-ddaa-4443-90ea-f76a06accaba Total devices 1 FS bytes used 1.40GiB devid 1 size 4.00GiB used 3.00GiB path /dev/sda4 The bug is quite nasty that you can't either unmount /dev/sda4 or /dev/mmcblk0p4. And the problem does not get solved until you take sda out of the system on to another system to change its fsid using the 'btrfstune -u' command. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 562fd87a92e7df703983202540ed033c26fc8b60 Author: Fabrizio Castro Date: Fri Dec 14 08:27:03 2018 +0000 usb: renesas_usbhs: add support for RZ/G2E [ Upstream commit 1d6e81a288e28d8d0e38e0501a324216f79bba35 ] HS-USB found in RZ/G2E (a.k.a. r8a774c0) is very similar to the one found in R-Car E3 (a.k.a. r8a77990), as it needs to release the PLL reset by the UGCTRL register like R-Car E3, therefore add r8a774c0 support in a similar fashion to what was done for the r8a77990. Signed-off-by: Fabrizio Castro Reviewed-by: Simon Horman Acked-by: Yoshihiro Shimoda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 12b6f0b2e7e15024f502312a0d1186f2d82aad1d Author: Linus Walleij Date: Mon Nov 12 15:12:31 2018 +0100 mmc: jz4740: Get CD/WP GPIOs from descriptors [ Upstream commit 0c901c0566fb4edc2631c3786e5085a037be91f8 ] Modifty the JZ4740 driver to retrieve card detect and write protect GPIO pins from GPIO descriptors instead of hard-coded global numbers. Augment the only board file using this in the process and cut down on passed in platform data. Preserve the code setting the caps2 flags for CD and WP as active low or high since the slot GPIO code currently ignores the gpiolib polarity inversion semantice and uses the raw accessors to read the GPIO lines, but set the right polarity flags in the descriptor table for jz4740. Cc: Paul Cercueil Cc: linux-mips@linux-mips.org Signed-off-by: Linus Walleij Acked-by: Paul Burton Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 3a96c89871654b36faed09ba7d7bf722f914b7e4 Author: Adrian Hunter Date: Mon Dec 10 10:56:26 2018 +0200 mmc: sdhci-xenon: Fix timeout checks [ Upstream commit 0e6e7c2ff397e1bbebc882ca3132148aaaef1ddd ] Always check the wait condition before returning timeout. Signed-off-by: Adrian Hunter Reviewed-by: Zhoujie Wu Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit fd655c826a6040026e0c48eda33a8837bb578763 Author: Adrian Hunter Date: Mon Dec 10 10:56:25 2018 +0200 mmc: sdhci-omap: Fix timeout checks [ Upstream commit 9f0ea0bda1d06120b053bb0c283f54afec59293d ] Always check the wait condition before returning timeout. Signed-off-by: Adrian Hunter Acked-by: Kishon Vijay Abraham I Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit c9934513f36530a2d8db7310b4137544c6d65c52 Author: Adrian Hunter Date: Mon Dec 10 10:56:24 2018 +0200 mmc: sdhci-of-esdhc: Fix timeout checks [ Upstream commit ea6d027312111c6d96309ad1a684b33cb37e6764 ] Always check the wait condition before returning timeout. Signed-off-by: Adrian Hunter Reviewed-by: Yangbo Lu Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a759ce39ec9b6ddd5396f1963f77a040e2ca00c7 Author: Kai-Heng Feng Date: Mon Nov 5 16:45:04 2018 +0800 memstick: Prevent memstick host from getting runtime suspended during card detection [ Upstream commit e03e303edf1c63e6dd455ccd568c74e93ef3ba8c ] We can use MEMSTICK_POWER_{ON,OFF} along with pm_runtime_{get,put} helpers to let memstick host support runtime pm. The rpm count may go down to zero before the memstick host powers on, so the host can be runtime suspended. So before doing card detection, increment the rpm count to avoid the host gets runtime suspended. Balance the rpm count after card detection is done. Signed-off-by: Kai-Heng Feng Tested-by: Oleksandr Natalenko Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7011f77137659a095697e3bbbe007223d2e0ceb4 Author: Nicholas Mc Guire Date: Thu Nov 22 10:35:19 2018 +0100 mmc: meson-mx-sdio: check devm_kasprintf for failure [ Upstream commit b0d06f1cb0e2079a3c64fb6e27c19d9a55c723a1 ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignments to init.name are not safe if not checked. On error meson_mx_mmc_register_clks() returns negative values so -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here. Signed-off-by: Nicholas Mc Guire Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Acked-by: Martin Blumenstingl Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9b5c08ab3445ce3ec0502b5325dd46c19f16e246 Author: Michal Suchanek Date: Sun Nov 11 21:23:53 2018 +0100 mmc: bcm2835: reset host on timeout [ Upstream commit f6000a4eb34e6462bc0dd39809c1bb99f9633269 ] The bcm2835 mmc host tends to lock up for unknown reason so reset it on timeout. The upper mmc block layer tries retransimitting with single blocks which tends to work out after a long wait. This is better than giving up and leaving the machine broken for no obvious reason. Fixes: 660fc733bd74 ("mmc: bcm2835: Add new driver for the sdhost controller.") Signed-off-by: Michal Suchanek Signed-off-by: Stefan Wahren Acked-by: Eric Anholt Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ada18da8c7cdda4af8d622c31acd6b1ee31ba7c3 Author: Phil Elwell Date: Sun Nov 11 21:23:54 2018 +0100 mmc: bcm2835: Recover from MMC_SEND_EXT_CSD [ Upstream commit 07d405769afea5718529fc9e341f0b13b3189b6f ] If the user issues an "mmc extcsd read", the SD controller receives what it thinks is a SEND_IF_COND command with an unexpected data block. The resulting operations leave the FSM stuck in READWAIT, a state which persists until the MMC framework resets the controller, by which point the root filesystem is likely to have been unmounted. A less heavyweight solution is to detect the condition and nudge the FSM by asserting the (self-clearing) FORCE_DATA_MODE bit. Link: https://github.com/raspberrypi/linux/issues/2728 Signed-off-by: Phil Elwell Signed-off-by: Stefan Wahren Acked-by: Eric Anholt Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit bc97a60d576c2b9e4b7af24f250e1f29731b1828 Author: Suraj Jitindar Singh Date: Fri Dec 14 16:29:03 2018 +1100 KVM: PPC: Book3S: Only report KVM_CAP_SPAPR_TCE_VFIO on powernv machines [ Upstream commit 693ac10a88a2219bde553b2e8460dbec97e594e6 ] The kvm capability KVM_CAP_SPAPR_TCE_VFIO is used to indicate the availability of in kernel tce acceleration for vfio. However it is currently the case that this is only available on a powernv machine, not for a pseries machine. Thus make this capability dependent on having the cpu feature CPU_FTR_HVMODE. [paulus@ozlabs.org - fixed compilation for Book E.] Signed-off-by: Suraj Jitindar Singh Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 0bca454a880d1d0b445c2b0b04a48524b23a459e Author: Quentin Monnet Date: Fri Dec 14 13:56:01 2018 +0000 tools: bpftool: fix -Wmissing declaration warnings [ Upstream commit c101189bc9680675a2686bafe908015a07a0da51 ] Help compiler check arguments for several utility functions used to print items to the console by adding the "printf" attribute when declaring those functions. Also, declare as "static" two functions that are only used in prog.c. All of them discovered by compiling bpftool with -Wmissing-format-attribute -Wmissing-declarations. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 7d3cc872713d5156f20446de8ea7aa621984e3c2 Author: David Ahern Date: Wed Dec 12 15:27:38 2018 -0800 ipv6: Fix handling of LLA with VRF and sockets bound to VRF [ Upstream commit c2027d1e17582903e368abf5d4838b22a98f2b7b ] A recent commit allows sockets bound to a VRF to receive ipv6 link local packets. However, it only works for UDP and worse TCP connection attempts to the LLA with the only listener bound to the VRF just hang where as before the client gets a reset and connection refused. Fix by adjusting ir_iif for LL addresses and packets received through a device enslaved to a VRF. Fixes: 6f12fa775530 ("vrf: mark skb for multicast or link-local as enslaved to VRF") Reported-by: Donald Sharp Cc: Mike Manning Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d946d55bc7b0fe00dc70717968e5e93fe3d0fb00 Author: Chao Yu Date: Wed Dec 12 18:12:30 2018 +0800 f2fs: fix to reorder set_page_dirty and wait_on_page_writeback [ Upstream commit 8d64d365aed355b2e2465d19ba61df02462fff4d ] This patch reorders flow from - update page - set_page_dirty - wait_on_page_writeback to - wait_on_page_writeback - update page - set_page_dirty The reason is: - set_page_dirty will increase reference of dirty page, the reference should be cleared before wait_on_page_writeback to keep its consistency. - some devices need stable page during page writebacking, so we should not change page's data. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ef2c5838c38cd5cfd799237ce41976e6d19c034a Author: Jeffrey Hugo Date: Thu Dec 13 15:43:40 2018 -0700 clk: qcom: Leave mmss noc on for 8998 [ Upstream commit 12eced09cd301aa7b1868a67c50a651c2aacd363 ] Similar to other qcom targets, gcc_mmss_noc_cfg_ahb_clk should not be disabled. Any mmss access depends on this clock, and its been observed that enabling mmssnoc_axi_rpm_clk with rpmcc results in an implicit access to mmss and will crash the system if gcc_mmss_noc_cfg_ahb_clk is disabled. Signed-off-by: Jeffrey Hugo Fixes: 4807c71cc688 (arm64: dts: Add msm8998 SoC and MTP board support) Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6288495780c39af5bf02bb13239c6a0c7d42fa1f Author: Tom Murphy Date: Tue Nov 27 10:33:08 2018 +0000 fix dma-buf/udmabuf selftest [ Upstream commit 6edf2e3710f4ef2555ad7a2681dbeb4a69092b2d ] This patch fixes the udmabuf selftest. Currently the selftest is broken. I fixed the selftest by setting the F_SEAL_SHRINK seal on the memfd file descriptor which is required by udmabuf and added the test to the selftest Makefile. Signed-off-by: Tom Murphy Reviewed-by: Gerd Hoffmann Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 1e2aaaf6ced2684f8c4f9a42367e8cacd17fccec Author: Fabio Estevam Date: Thu Dec 13 00:08:38 2018 -0200 ASoC: fsl: Fix SND_SOC_EUKREA_TLV320 build error on i.MX8M [ Upstream commit add6883619a9e3bf9658eaff1a547354131bbcd9 ] eukrea-tlv320.c machine driver runs on non-DT platforms and include header file in order to be able to use some machine_is_eukrea_xxx() macros. Building it for ARM64 causes the following build error: sound/soc/fsl/eukrea-tlv320.c:28:10: fatal error: asm/mach-types.h: No such file or directory Avoid this error by not allowing to build the SND_SOC_EUKREA_TLV320 driver when ARM64 is selected. This is needed in preparation for the i.MX8M support. Reported-by: kbuild test robot Signed-off-by: Fabio Estevam Acked-by: Shawn Guo Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1ad76e8892c321d9056911b00d473245730807a0 Author: Arnd Bergmann Date: Mon Dec 10 22:58:39 2018 +0100 ARM: pxa: avoid section mismatch warning [ Upstream commit 88af3209aa0881aa5ffd99664b6080a4be5f24e5 ] WARNING: vmlinux.o(.text+0x19f90): Section mismatch in reference from the function littleton_init_lcd() to the function .init.text:pxa_set_fb_info() The function littleton_init_lcd() references the function __init pxa_set_fb_info(). This is often because littleton_init_lcd lacks a __init annotation or the annotation of pxa_set_fb_info is wrong. WARNING: vmlinux.o(.text+0xf824): Section mismatch in reference from the function zeus_register_ohci() to the function .init.text:pxa_set_ohci_info() The function zeus_register_ohci() references the function __init pxa_set_ohci_info(). This is often because zeus_register_ohci lacks a __init annotation or the annotation of pxa_set_ohci_info is wrong. WARNING: vmlinux.o(.text+0xf95c): Section mismatch in reference from the function cm_x300_init_u2d() to the function .init.text:pxa3xx_set_u2d_info() The function cm_x300_init_u2d() references the function __init pxa3xx_set_u2d_info(). This is often because cm_x300_init_u2d lacks a __init annotation or the annotation of pxa3xx_set_u2d_info is wrong. Signed-off-by: Arnd Bergmann Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 7d8fa6594beb07955cc473c069b764a1fbe8e897 Author: Stanislav Fomichev Date: Tue Dec 11 19:20:52 2018 -0800 selftests/bpf: use __bpf_constant_htons in test_prog.c [ Upstream commit a0517a0f7ef23550b4484c37e2b9c2d32abebf64 ] For some reason, my older GCC (< 4.8) isn't smart enough to optimize the !__builtin_constant_p() branch in bpf_htons, I see: error: implicit declaration of function '__builtin_bswap16' Let's use __bpf_constant_htons as suggested by Daniel Borkmann. I tried to use simple htons, but it produces the following: test_progs.c:54:17: error: braced-group within expression allowed only inside a function .eth.h_proto = htons(ETH_P_IP), Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 4d604c6f3e39558418e9090ea2a1c73fbba0800d Author: Joey Zhang Date: Mon Dec 10 17:12:22 2018 +0800 switchtec: Fix SWITCHTEC_IOCTL_EVENT_IDX_ALL flags overwrite [ Upstream commit e4a7dca5de625018b29417ecc39dc5037d9a5a36 ] In the ioctl_event_ctl() SWITCHTEC_IOCTL_EVENT_IDX_ALL case, we call event_ctl() several times with the same "ctl" struct. Each call clobbers ctl.flags, which leads to the problem that we may not actually enable or disable all events as the user requested. Preserve the event flag value with a temporary variable. Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver") Signed-off-by: Joey Zhang Signed-off-by: Wesley Sheng [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Signed-off-by: Sasha Levin commit 570f31838a932c1c748db703a49e0671ee84ce08 Author: Jan Kara Date: Wed Dec 12 14:29:20 2018 +0100 udf: Fix BUG on corrupted inode [ Upstream commit d288d95842f1503414b7eebce3773bac3390457e ] When inode is corrupted so that extent type is invalid, some functions (such as udf_truncate_extents()) will just BUG. Check that extent type is valid when loading the inode to memory. Reported-by: Anatoly Trosinenko Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 92430df6f8fbb7c47d70302e8ac92cd9dc68f14d Author: Nir Dotan Date: Mon Dec 10 07:11:44 2018 +0000 mlxsw: spectrum_acl: Limit priority value [ Upstream commit d7263ab35be25505ab57ebecd93cbc5dba8be717 ] In Spectrum-2, higher priority value wins and priority valid values are in the range of {1,cap_kvd_size-1}. mlxsw_sp_acl_tcam_priority_get converts from lower-bound priorities alike tc flower to Spectrum-2 HW range. Up until now tc flower did not provide priority 0 or reached the maximal value, however multicast routing does provide priority 0. Therefore, Change mlxsw_sp_acl_tcam_priority_get to verify priority is in the correct range. Make sure priority is never set to zero and never exceeds the maximal allowed value. Signed-off-by: Nir Dotan Reviewed-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 87888d7b1f6640bce73baac4fe410fcc19aca95f Author: Icenowy Zheng Date: Thu Oct 4 20:28:47 2018 +0800 phy: sun4i-usb: add support for missing USB PHY index [ Upstream commit 2659392e5c08dff626e6db1d739adff58a94604d ] The new Allwinner H6 SoC's USB2 PHY has two holes -- USB1 (which is a 3.0 port with dedicated PHY) and USB2 (which doesn't exist at all). Add support for this kind of missing USB PHY index. Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 8fcd2eb827e14b49785db87ec704f6a8e08a6c2c Author: Geert Uytterhoeven Date: Tue Dec 11 20:16:08 2018 +0100 lightnvm: Fix uninitialized return value in nvm_get_chunk_meta() [ Upstream commit 55e58c5e78aad9d3246f57e7718cf5ee7adde9e3 ] With gcc 4.1: drivers/lightnvm/core.c: In function ‘nvm_get_bb_meta’: drivers/lightnvm/core.c:977: warning: ‘ret’ may be used uninitialized in this function and drivers/nvme/host/lightnvm.c: In function ‘nvme_nvm_get_chk_meta’: drivers/nvme/host/lightnvm.c:580: warning: ‘ret’ may be used uninitialized in this function Indeed, if (for the former) the number of channels or LUNs is zero, or (for both) the passed number of chunks is zero, ret will be returned uninitialized. Fix this by preinitializing ret to zero. Fixes: aff3fb18f957de93 ("lightnvm: move bad block and chunk state logic to core") Fixes: a294c199455187d1 ("lightnvm: implement get log report chunk helpers") Signed-off-by: Geert Uytterhoeven Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c7ce08e203f645dc617fcd8b6cfebfd7090a15da Author: Adamski, Krzysztof (Nokia - PL/Wroclaw) Date: Mon Dec 10 15:01:27 2018 +0000 i2c-axxia: check for error conditions first [ Upstream commit 4f5c85fe3a60ace555d09898166af372547f97fc ] It was observed that when using seqentional mode contrary to the documentation, the SS bit (which is supposed to only be set if automatic/sequence command completed normally), is sometimes set together with NA (NAK in address phase) causing transfer to falsely be considered successful. My assumption is that this does not happen during manual mode since the controller is stopping its work the moment it sets NA/ND bit in status register. This is not the case in Automatic/Sequentional mode where it is still working to send STOP condition and the actual status we get depends on the time when the ISR is run. This patch changes the order of checking status bits in ISR - error conditions are checked first and only if none of them occurred, the transfer may be considered successful. This is required to introduce using of sequentional mode in next patch. Signed-off-by: Krzysztof Adamski Reviewed-by: Alexander Sverdlin Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 521b8625eefb1cc1dde1621d9d7b5892a64af031 Author: Hua Su Date: Tue Dec 11 20:16:18 2018 +0100 lightnvm: pblk: add lock protection to list operations [ Upstream commit fde201a466c6ad5efd72cb54fdf2cefa8b6c6ad7 ] Protect the list_add on the pblk_line_init_bb() error path in case this code is used for some other purpose in the future. Signed-off-by: Hua Su Reviewed-by: Javier González Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 11dd6d2155296700959615360ea086c215db58db Author: Hans Holmberg Date: Tue Dec 11 20:16:10 2018 +0100 lightnvm: pblk: fix resubmission of overwritten write err lbas [ Upstream commit c12fa401ac8c94a74aff68bb5736b3f1dc695fa8 ] Make sure we only look up valid lba addresses on the resubmission path. If an lba is invalidated in the write buffer, that sector will be submitted to disk (as it is already mapped to a ppa), and that write might fail, resulting in a crash when trying to look up the lba in the mapping table (as the lba is marked as invalid). Signed-off-by: Hans Holmberg Reviewed-by: Javier González Signed-off-by: Matias Bjørling Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ab84ec6ef8f98014084ca2d535aaa48ea6ba138e Author: Sean Paul Date: Tue Oct 30 12:00:08 2018 -0400 drm/msm: dpu: Only check flush register against pending flushes [ Upstream commit 5f79e03b1f7c1b2cf0019ce6365fe5d52629813d ] There exists a case where a flush of a plane/dma may have been triggered & started from an async commit. If that plane/dma is subsequently disabled by the next commit, the flush register will continue to hold the flush bit for the disabled plane. Since the bit remains active, pending_kickoff_cnt will never decrement and we'll miss frame_done events. This patch limits the check of flush_register to include only those bits which have been updated with the latest commit. Changes in v2: - None Reviewed-by: Jeykumar Sankaran Signed-off-by: Sean Paul Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 84423f325e9a6051ac59d510c15b2fb0cb4cf782 Author: Abhinav Kumar Date: Thu Oct 11 10:18:57 2018 -0700 drm/msm/dsi: fix dsi clock names in DSI 10nm PLL driver [ Upstream commit c1866d44d149a1ea5c303632114fb6aa08cfd263 ] Fix the dsi clock names in the DSI 10nm PLL driver to match the names in the dispcc driver as those are according to the clock plan of the chipset. Changes in v2: - Update the clock diagram with the new clock name Reviewed-by: Sean Paul Signed-off-by: Abhinav Kumar Signed-off-by: Sean Paul Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 50efaf4b1817c2f2c2b09015a1e18194a3573e39 Author: Zhizhou Zhang Date: Wed Nov 21 11:01:43 2018 +0800 tee: optee: avoid possible double list_del() [ Upstream commit b2d102bd0146d9eb1fa630ca0cd19a15ef2f74c8 ] This bug occurs when: - a new request arrives, one thread(let's call it A) is pending in optee_supp_req() with req->busy is initial value false. - tee-supplicant is killed, then optee_supp_release() is called, this function calls list_del(&req->link), and set supp->ctx to NULL. And it also wake up process A. - process A continues, it firstly checks supp->ctx which is NULL, then checks req->busy which is false, at last run list_del(&req->link). This triggers double list_del() and results kernel panic. For solve this problem, we rename req->busy to req->in_queue, and associate it with state of whether req is linked to supp->reqs. So we can just only check req->in_queue to make decision calling list_del() or not. Signed-off-by: Zhizhou Zhang Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 9565dd2144cf205730e07a714db93c168995dd9c Author: Viresh Kumar Date: Tue Dec 11 16:32:47 2018 +0530 OPP: Use opp_table->regulators to verify no regulator case [ Upstream commit 90e3577b5feb42bac1269e16bb3d2bdd8f6df40f ] The value of opp_table->regulator_count is not very consistent right now and it may end up being 0 while we do have a "opp-microvolt" property in the OPP table. It was kept that way as we used to check if any regulators are set with the OPP core for a device or not using value of regulator_count. Lets use opp_table->regulators for that purpose as the meaning of regulator_count is going to change in the later patches. Reported-by: Quentin Perret Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit d1dda680ffbbd1c52dc0e4e0ff9d6e3ef3885ef4 Author: Yangtao Li Date: Mon Dec 10 11:26:41 2018 -0500 cpuidle: big.LITTLE: fix refcount leak [ Upstream commit 9456823c842f346c74265fcd98d008d87a7eb6f5 ] of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. bl_idle_init() doesn't do that, so fix it. Signed-off-by: Yangtao Li Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 48bfd6158c0f734c663f5d8f4ea0a43b1940e508 Author: Vadim Pasternak Date: Thu Nov 15 17:26:56 2018 +0000 platform/x86: mlx-platform: Fix tachometer registers [ Upstream commit edd45cba5ed7f53974475ddc9a1453c2c87b3328 ] Shift by one the registers for tachometers (7 - 12). This fix is relevant for the same new systems MQMB7, MSN37, MSN34, which are about to be released to the customers. At the moment, none of them is at customers sites. The customers will not suffer from this change. This fix is necessary, because register used before for tachometer 7 has been than reserved for the second PWM for newer systems, which are not supported yet in mlx-platform driver. So registers of tachometers 7-12 have been shifted by one. Fixes: 0378123c5800 ("platform/x86: mlx-platform: Add mlxreg-fan platform driver activation") Signed-off-by: Vadim Pasternak Signed-off-by: Darren Hart (VMware) Signed-off-by: Sasha Levin commit a99044e9934e15e83bb16c69eeeb1e8acc0faff3 Author: Anson Huang Date: Fri Nov 30 07:23:47 2018 +0000 clk: imx6sl: ensure MMDC CH0 handshake is bypassed [ Upstream commit 0efcc2c0fd2001a83240a8c3d71f67770484917e ] Same as other i.MX6 SoCs, ensure unused MMDC channel's handshake is bypassed, this is to make sure no request signal will be generated when periphe_clk_sel is changed or SRC warm reset is triggered. Signed-off-by: Anson Huang Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 9523d7df24c1cd41c2778697ec40dc1c79adebc6 Author: Sergei Shtylyov Date: Sat Nov 24 21:14:16 2018 +0300 sata_rcar: fix deferred probing [ Upstream commit 9f83cfdb1ace3ef268ecc6fda50058d2ec37d603 ] The driver overrides the error codes returned by platform_get_irq() to -EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Switch to propagating the error code upstream, still checking/overriding IRQ0 as libata regards it as "no IRQ" (thus polling) anyway... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Reviewed-by: Simon Horman Reviewed-by: Geert Uytterhoeven Signed-off-by: Sergei Shtylyov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2e6743c608235385e93a90e0a692ea2cf5d15937 Author: Will Deacon Date: Wed Nov 7 22:58:24 2018 +0000 iommu/arm-smmu-v3: Use explicit mb() when moving cons pointer [ Upstream commit a868e8530441286342f90c1fd9c5f24de3aa2880 ] After removing an entry from a queue (e.g. reading an event in arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer pointer to free the queue slot back to the SMMU. A memory barrier is required here so that all reads targetting the queue entry have completed before the consumer pointer is updated. The implementation of queue_inc_cons() relies on a writel() to complete the previous reads, but this is incorrect because writel() is only guaranteed to complete prior writes. This patch replaces the call to writel() with an mb(); writel_relaxed() sequence, which gives us the read->write ordering which we require. Cc: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b34b2f334b4cc93a76f0e9cb2de7a23c80ce14ca Author: Vivek Gautam Date: Tue Dec 4 11:52:13 2018 +0530 iommu/arm-smmu: Add support for qcom,smmu-v2 variant [ Upstream commit 89cddc563743cb1e0068867ac97013b2a5bf86aa ] qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. On msm8996, multiple cores, viz. mdss, video, etc. use this smmu. On sdm845, this smmu is used with gpu. Add bindings for the same. Signed-off-by: Vivek Gautam Reviewed-by: Rob Herring Reviewed-by: Tomasz Figa Tested-by: Srinivas Kandagatla Reviewed-by: Robin Murphy Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e738e753a68f4909df200d1f32a33cadb5a1804b Author: Zhen Lei Date: Wed Oct 31 12:02:07 2018 +0800 iommu/arm-smmu-v3: Avoid memory corruption from Hisilicon MSI payloads [ Upstream commit 84a9a75774961612d0c7dd34a1777e8f98a65abd ] The GITS_TRANSLATER MMIO doorbell register in the ITS hardware is architected to be 4 bytes in size, yet on hi1620 and earlier, Hisilicon have allocated the adjacent 4 bytes to carry some IMPDEF sideband information which results in an 8-byte MSI payload being delivered when signalling an interrupt: MSIAddr: |----4bytes----|----4bytes----| | MSIData | IMPDEF | This poses no problem for the ITS hardware because the adjacent 4 bytes are reserved in the memory map. However, when delivering MSIs to memory, as we do in the SMMUv3 driver for signalling the completion of a SYNC command, the extended payload will corrupt the 4 bytes adjacent to the "sync_count" member in struct arm_smmu_device. Fortunately, the current layout allocates these bytes to padding, but this is fragile and we should make this explicit. Reviewed-by: Robin Murphy Signed-off-by: Zhen Lei [will: Rewrote commit message and comment] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2de23f52a08a57d91a6a38d411505ea44a61fe87 Author: Tejas Joglekar Date: Mon Dec 10 16:08:13 2018 +0530 usb: dwc3: gadget: Disable CSP for stream OUT ep [ Upstream commit 244add8ebfb231c39db9e33b204bd0ce8f24f782 ] In stream mode, when fast-forwarding TRBs, the stream number is not cleared causing the new stream to not get assigned. So we don't want controller to carry on transfers when short packet is received. So disable the CSP for stream capable endpoint. This is based on the 3.30a Programming guide, where table 3-1 device descriptor structure field definitions says for CSP bit If this bit is 0, the controller generates an XferComplete event and remove the stream. So if we keep CSP as 1 then switching between streams would not happen as in stream mode, when fast-forwarding TRBs, the stream number is not cleared causing the new stream to not get assigned. Signed-off-by: Tejas Joglekar Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 813f8c2eddeaa5ac4a6fb389ddf905b6cb42d320 Author: Andrey Smirnov Date: Thu Dec 6 21:41:17 2018 -0200 ARM: dts: imx51-zii-rdu1: Do not specify "power-gpio" for hpa1 [ Upstream commit 79da07dec740a42c70963ebacbd2bf8866af9e20 ] TPA6130A2 SD pin on RDU1 is not really controlled by SoC and instead is only meant to notify the system that audio was "muted" by external actors. To accommodate that, drop "power-gpio" property of hpa1 node as well as specify a name for that GPIO so that userspace can access it. Signed-off-by: Andrey Smirnov Signed-off-by: Fabio Estevam Tested-by: Chris Healy Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit ff5a441411a62e2b1b1063c7e37775cec809c2bd Author: Wolfram Sang Date: Wed Nov 7 20:46:02 2018 +0100 watchdog: renesas_wdt: don't set divider while watchdog is running [ Upstream commit e990e12741877e9bfac402ca468f4007a75f6e2a ] The datasheet says we must stop the timer before changing the clock divider. This can happen when the restart handler is called while the watchdog is running. Signed-off-by: Wolfram Sang Reviewed-by: Fabrizio Castro Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit a0cb037f272b1160617dbdc16cb2510859d8aac8 Author: Linus Walleij Date: Thu May 17 17:00:10 2018 +0200 ARM: dts: Fix up the D-Link DIR-685 MTD partition info [ Upstream commit 738a05e673435afb986b53da43befd83ad87ec3b ] The vendor firmware was analyzed to get the right idea about this flash layout. /proc/mtd contains: dev: size erasesize name mtd0: 01e7ff40 00020000 "rootfs" mtd1: 01f40000 00020000 "upgrade" mtd2: 00040000 00020000 "rgdb" mtd3: 00020000 00020000 "nvram" mtd4: 00040000 00020000 "RedBoot" mtd5: 00020000 00020000 "LangPack" mtd6: 02000000 00020000 "flash" Here "flash" is obviously the whole device and we know "rootfs" is a bogus hack to point to a squashfs rootfs inside of the main "upgrade partition". We know "RedBoot" is the first 0x40000 of the flash and the "upgrade" partition follows from 0x40000 to 0x1f8000. So we have mtd0, 1, 4 and 6 covered. Remains: mtd2: 00040000 00020000 "rgdb" mtd3: 00020000 00020000 "nvram" mtd5: 00020000 00020000 "LangPack" Inspecting the flash at 0x1f8000 and 0x1fa000 reveals each of these starting with "RGCFG1" so we assume 0x1f8000-1fbfff is "rgdb" of 0x40000. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1a7cc0bb70d8b837260cc17cea685101aa159c06 Author: Carlo Caione Date: Fri Dec 7 10:52:30 2018 +0000 arm64: dts: meson: Fix IRQ trigger type for macirq [ Upstream commit 8b3e6f8999f8d704fccce225b9455b3fa639d1c9 ] A long running stress test on a custom board shipping an AXG SoCs and a Realtek RTL8211F PHY revealed that after a few hours the connection speed would drop drastically, from ~1000Mbps to ~3Mbps. At the same time the 'macirq' (eth0) IRQ would stop being triggered at all and as consequence the GMAC IRQs never ACKed. After a painful investigation the problem seemed to be due to a wrong defined IRQ type for the GMAC IRQ that should be LEVEL_HIGH instead of EDGE_RISING. The change in the macirq IRQ type also solved another long standing issue affecting this SoC/PHY where EEE was causing the network connection to die after stressing it with iperf3 (even though much sooner). It's now possible to remove the 'eee-broken-1000t' quirk as well. Fixes: feb3cbea0946 ("ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage") Fixes: 6d28d577510f ("ARM64: dts: meson-axg: fix ethernet stability issue") Reviewed-by: Jerome Brunet Tested-by: Jerome Brunet Acked-by: Neil Armstrong Signed-off-by: Carlo Caione Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit 9667fb5d9df2b61b750e2b51caf5a7f26c7d6bd7 Author: Philipp Zabel Date: Wed Nov 28 08:01:22 2018 -0500 media: coda: fix H.264 deblocking filter controls [ Upstream commit 75fa6e4f83a0923fe753827d354998d448b4fd6a ] Add support for the third loop filter mode V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_DISABLED_AT_SLICE_BOUNDARY, and fix V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_ALPHA and V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_BETA controls. The filter offset controls are signed values in the -6 to 6 range and are stored into the slice header fields slice_alpha_c0_offset_div2 and slice_beta_offset_div2. The actual filter offsets FilterOffsetA/B are double their value, in range of -12 to 12. Rename variables to more closely match the nomenclature in the H.264 specification. Signed-off-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d00d571f7b80d7773ef96dfa9011a03f5215ec3d Author: Jiong Wang Date: Mon Dec 3 17:27:54 2018 -0500 mips: bpf: fix encoding bug for mm_srlv32_op [ Upstream commit 17f6c83fb5ebf7db4fcc94a5be4c22d5a7bfe428 ] For micro-mips, srlv inside POOL32A encoding space should use 0x50 sub-opcode, NOT 0x90. Some early version ISA doc describes the encoding as 0x90 for both srlv and srav, this looks to me was a typo. I checked Binutils libopcode implementation which is using 0x50 for srlv and 0x90 for srav. v1->v2: - Keep mm_srlv32_op sorted by value. Fixes: f31318fdf324 ("MIPS: uasm: Add srlv uasm instruction") Cc: Markos Chandras Cc: Paul Burton Cc: linux-mips@vger.kernel.org Acked-by: Jakub Kicinski Acked-by: Song Liu Signed-off-by: Jiong Wang Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f058a86e717396bd7fa81fe27d32d61eca4a5cc5 Author: Russell King - ARM Linux Date: Fri Dec 7 09:17:07 2018 -0800 ARM: dts: Fix OMAP4430 SDP Ethernet startup [ Upstream commit 84fb6c7feb1494ebb7d1ec8b95cfb7ada0264465 ] It was noticed that unbinding and rebinding the KSZ8851 ethernet resulted in the driver reporting "failed to read device ID" at probe. Probing the reset line with a 'scope while repeatedly attempting to bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is constantly held at zero, meaning the device is held in reset, and does not respond on the SPI bus. Experimentation with the startup delay on the regulator set to 50ms shows that the reset is positively released after 20ms. Schematics for this board are not available, and the traces are buried in the inner layers of the board which makes tracing where the RSTN pin extremely difficult. We can only guess that the RSTN pin is wired to a reset generator chip driven off the ethernet supply, which fits the observed behaviour. Include this delay in the regulator startup delay - effectively treating the reset as a "supply stable" indicator. This can not be modelled as a delay in the KSZ8851 driver since the reset generation is board specific - if the RSTN pin had been wired to a GPIO, reset could be released earlier via the already provided support in the KSZ8851 driver. This also got confirmed by Peter Ujfalusi based on Blaze schematics that should be very close to SDP4430: TPS22902YFPR is used as the regulator switch (gpio48 controlled): Convert arm boot_lock to raw The VOUT is routed to TPS3808G01DBV. (SCH Note: Threshold set at 90%. Vsense: 0.405V). According to the TPS3808 data sheet the RESET delay time when Ct is open (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms. Signed-off-by: Russell King Reviewed-by: Peter Ujfalusi [tony@atomide.com: updated with notes from schematics from Peter] Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 535586f388aa01e4de242a49e8f85d1334c3edc6 Author: Janusz Krzysztofik Date: Fri Nov 23 12:19:45 2018 +0100 ARM: OMAP1: ams-delta: Fix audio permanently muted [ Upstream commit 2afdb4c41d7876e430b9bc6e2d7e2fe28609fd6a ] Since commit 1137ceee76ba ("ARM: OMAP1: ams-delta: Don't request unused GPIOs"), on-board audio has appeared muted. Believed to be unused GPIO pin "hookflash1", apparently set high regardless of the corresponding bit of "latch2" port attempted to be set low during .init_machine(), has been identified as the reason. According to Amstrad E3 wiki, the purpose of the pin hasn't been clearly identified. Original Amstrad software used to produce a high pulse on it when the phone was taken off hook or recall was pressed. With the current finding, we can assume the pin provides a kind of audio mute function. Proper resolution of the issue should be done in two steps: - resolution of an issue with the pin state not reflecting the value the corresponding bit of the port was attempted to be initialized with, - extension of on-board audio driver with a new control. For now, rename the pin to "audio_mute" to reflect its function and, as a quick fix, hogg it as output low so on-board audio can produce audible sound again. Fixes: 1137ceee76ba ("ARM: OMAP1: ams-delta: Don't request unused GPIOs") Signed-off-by: Janusz Krzysztofik Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 3cfbad89b2a78cc837075101ea4e42726b59a572 Author: Tomasz Figa Date: Thu Dec 14 23:32:21 2017 -0500 media: v4l2-device: Link subdevices to their parent devices if available [ Upstream commit ee494cf377e142f65f202fadf0d859f8e12119fb ] Currently v4l2_device_register_subdev_nodes() does not initialize the dev_parent field of the video_device structs it creates for subdevices being registered. This leads to __video_register_device() falling back to the parent device of associated v4l2_device struct, which often does not match the physical device the subdevice is registered for. Due to the problem above, the links between real devices and v4l-subdev nodes cannot be obtained from sysfs, which might be confusing for the userspace trying to identify the hardware. Fix this by initializing the dev_parent field of the video_device struct with the value of dev field of the v4l2_subdev struct. In case of subdevices without a parent struct device, the field will be NULL and the old behavior will be preserved by the semantics of __video_register_device(). Signed-off-by: Tomasz Figa Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 679aa4ffce0aa0ca965ff599b14b3abfcf220fdc Author: Yu Zhao Date: Thu Dec 6 14:39:15 2018 -0700 iommu/amd: Fix amd_iommu=force_isolation [ Upstream commit c12b08ebbe16f0d3a96a116d86709b04c1ee8e74 ] The parameter is still there but it's ignored. We need to check its value before deciding to go into passthrough mode for AMD IOMMU v2 capable device. We occasionally use this parameter to force v2 capable device into translation mode to debug memory corruption that we suspect is caused by DMA writes. To address the following comment from Joerg Roedel on the first version, v2 capability of device is completely ignored. > This breaks the iommu_v2 use-case, as it needs a direct mapping for the > devices that support it. And from Documentation/admin-guide/kernel-parameters.txt: This option does not override iommu=pt Fixes: aafd8ba0ca74 ("iommu/amd: Implement add_device and remove_device") Signed-off-by: Yu Zhao Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 1790518a8682e0bc5db77c0e7101e5d05de7202b Author: Nicholas Mc Guire Date: Sun Dec 2 11:04:17 2018 +0100 pinctrl: sx150x: handle failure case of devm_kstrdup [ Upstream commit a9d9f6b83f1bb05da849b3540e6d1f70ef1c2343 ] devm_kstrdup() may return NULL if internal allocation failed. Thus using label, name is unsafe without checking. Therefor in the unlikely case of allocation failure, sx150x_probe() simply returns -ENOMEM. Signed-off-by: Nicholas Mc Guire Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit a2a7e43e2b9f1815e7d7533ef6b2050b1bdf11e9 Author: Nicholas Mc Guire Date: Tue Nov 27 18:00:18 2018 +0100 gpio: mt7621: pass mediatek_gpio_bank_probe() failure up the stack [ Upstream commit a109c2dbb571b10bb9969285b646f57309c98251 ] The error cases of mediatek_gpio_bank_probe() would go unnoticed (except for the dev_err() messages). The probe function should return an error if one of the banks failed to initialize properly indicated by not returning non-0. Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621") Signed-off-by: Nicholas Mc Guire Acked-by: Sean Wang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 43902c262b128a97d76ea77db66b3ce4ef46ece5 Author: Nicholas Mc Guire Date: Wed Nov 21 19:06:12 2018 +0100 gpio: mt7621: report failure of devm_kasprintf() [ Upstream commit 59d646c775d6ae688ee90fda9f2a4270c47b7490 ] kasprintf() may return NULL on failure of internal allocation thus the assigned label is not safe if not explicitly checked. On error mediatek_gpio_bank_probe() returns negative values so -ENOMEM in the (unlikely) failure case should be fine here. Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621") Signed-off-by: Nicholas Mc Guire Reviewed-by: Bartosz Golaszewski Acked-by: Sean Wang Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4dc2acb15d52af484ee1155aee9ae53474827647 Author: Andy Shevchenko Date: Mon Dec 3 11:28:47 2018 +0200 usb: dwc3: trace: add missing break statement to make compiler happy [ Upstream commit 54d48183d21e03f780053d7129312049cb5dd591 ] The missed break statement in the outer switch makes the code fall through always and thus always same value will be printed. Besides that, compiler warns about missed fall through marker: drivers/usb/dwc3/./trace.h: In function ‘trace_raw_output_dwc3_log_trb’: drivers/usb/dwc3/./trace.h:246:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (pcm) { ^~~~~~ Add the missing break statement to work correctly without compilation warnings. Fixes: fa8d965d736b ("usb: dwc3: trace: pretty print high-bandwidth transfers too") Cc: Felipe Balbi Signed-off-by: Andy Shevchenko Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 16946d7f820b06e5e18e39b2a85cb99c363c2f0c Author: Kaike Wan Date: Wed Nov 28 10:22:09 2018 -0800 IB/hfi1: Unreserve a reserved request when it is completed [ Upstream commit ca95f802ef5139722acc8d30aeaab6fe5bbe939e ] Currently, When a reserved operation is completed, its entry in the send queue will not be unreserved, which leads to the miscalculation of qp->s_avail and thus the triggering of a WARN_ON call trace. This patch fixes the problem by unreserving the reserved operation when it is completed. Fixes: 856cc4c237ad ("IB/hfi1: Add the capability for reserved operations") Reviewed-by: Mike Marciniszyn Signed-off-by: Kaike Wan Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 66734aef2a49ad14448f774172a811730a0f1a63 Author: Peter Rajnoha Date: Wed Dec 5 12:27:44 2018 +0100 kobject: return error code if writing /sys/.../uevent fails [ Upstream commit df44b479654f62b478c18ee4d8bc4e9f897a9844 ] Propagate error code back to userspace if writing the /sys/.../uevent file fails. Before, the write operation always returned with success, even if we failed to recognize the input string or if we failed to generate the uevent itself. With the error codes properly propagated back to userspace, we are able to react in userspace accordingly by not assuming and awaiting a uevent that is not delivered. Signed-off-by: Peter Rajnoha Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 916372445c3dc9fead15056cdac3f7f98a258181 Author: Alexander Duyck Date: Wed Nov 28 16:32:11 2018 -0800 driver core: Move async_synchronize_full call [ Upstream commit c37d721c68ad88925ba0e72f6e14acb829a8c6bb ] Move the async_synchronize_full call out of __device_release_driver and into driver_detach. The idea behind this is that the async_synchronize_full call will only guarantee that any existing async operations are flushed. This doesn't do anything to guarantee that a hotplug event that may occur while we are doing the release of the driver will not be asynchronously scheduled. By moving this into the driver_detach path we can avoid potential deadlocks as we aren't holding the device lock at this point and we should not have the driver we want to flush loaded so the flush will take care of any asynchronous events the driver we are detaching might have scheduled. Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers") Reviewed-by: Bart Van Assche Reviewed-by: Dan Williams Signed-off-by: Alexander Duyck Reviewed-by: Luis Chamberlain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b375eeeb78e7fe5b4dde683b2dcb1742e7926d50 Author: Oskari Lemmela Date: Sat Dec 1 12:08:16 2018 +0200 arm64: dts: rockchip: fix rk3399-rockpro64 regulator gpios [ Upstream commit 690e16bada6029694740d5501025faf483d14339 ] Rockpro64 is not able boot if GPIO1_C1 pin is pulled high before loading linux kernel. In rockpro64 GPIO1_C1 pin is connected vdd_cpu_b regulator VSEL pin. Pin should be pulled down in normal operation and pulled high in suspend. PMIC LDO_REG2 is connected to touch panel connector. Rename regulator and set it to correct voltage. PCIe power is controller by GPIO1_D0. Schematics can be downloaded from: http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf Signed-off-by: Oskari Lemmela Acked-by: Akash Gajjar Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit afe10edd0a962200ef095fcc20ba02090249b931 Author: Hoang Le Date: Thu Dec 6 09:00:09 2018 +0700 tipc: fix node keep alive interval calculation [ Upstream commit f5d6c3e5a359c0507800e7ac68d565c21de9b5a1 ] When setting LINK tolerance, node timer interval will be calculated base on the LINK with lowest tolerance. But when calculated, the old node timer interval only updated if current setting value (tolerance/4) less than old ones regardless of number of links as well as links' lowest tolerance value. This caused to two cases missing if tolerance changed as following: Case 1: 1.1/ There is one link (L1) available in the system 1.2/ Set L1's tolerance from 1500ms => lower (i.e 500ms) 1.3/ Then, fallback to default (1500ms) or higher (i.e 2000ms) Expected: node timer interval is 1500/4=375ms after 1.3 Result: node timer interval will not being updated after changing tolerance at 1.3 since its value 1500/4=375ms is not less than 500/4=125ms at 1.2. Case 2: 2.1/ There are two links (L1, L2) available in the system 2.2/ L1 and L2 tolerance value are 2000ms as initial 2.3/ Set L2's tolerance from 2000ms => lower 1500ms 2.4/ Disable link L2 (bring down its bearer) Expected: node timer interval is 2000ms/4=500ms after 2.4 Result: node timer interval will not being updated after disabling L2 since its value 2000ms/4=500ms is still not less than 1500/4=375ms at 2.3 although L2 is already not available in the system. To fix this, we start the node interval calculation by initializing it to a value larger than any conceivable calculated value. This way, the link with the lowest tolerance will always determine the calculated value. Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f922064b292a2bf7db01bbcd71e2e7e0508316c Author: Alex Deucher Date: Thu Nov 29 19:22:07 2018 -0500 drm/amdgpu/powerplay: fix clock stretcher limits on polaris (v2) [ Upstream commit de4aaab5cc9770a8c4dc13d9bfb6a83b06bba57e ] Adjust limits for newer polaris variants. v2: fix polaris11 kicker (Jerry) Reviewed-by: Junwei Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c10c3d86c5607a92d0c31ba9a58308668c203ba0 Author: Nicholas Mc Guire Date: Fri Nov 23 17:12:58 2018 +0100 pinctrl: nuvoton: check for devm_kasprintf() failure [ Upstream commit 4be1eaf322f07bb9694618fd2763a3a1f0a3dd25 ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignment to .label is not safe if not checked. On error npcm7xx_gpio_of() returns negative values so -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here. Signed-off-by: Nicholas Mc Guire Fixes: 3b588e43ee5c ("pinctrl: nuvoton: add NPCM7xx pinctrl and GPIO driver") Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit a8a93e11847bf5e100f5441d59e93e62b17d402c Author: Emmanuel Grumbach Date: Mon Dec 3 21:15:49 2018 +0200 mac80211: fix deauth TX when we disconnect [ Upstream commit f6c7f03f69f7422bc237bc79599e152d390b74e0 ] The iTXQs stop/wake queue mechanism involves a whole bunch of locks and this is probably why the call to ieee80211_wake_txqs is deferred to a tasklet when called from __ieee80211_wake_queue. Another advantage of that is that ieee80211_wake_txqs might call the wake_tx_queue() callback and then the driver may call mac80211 which will call it back in the same context. The bug I saw is that when we send a deauth frame as a station we do: flush(drop=1) tx deauth flush(drop=0) While we flush we stop the queues and wake them up immediately after we finished flushing. The problem here is that the tasklet that de-facto enables the queue may not have run until we send the deauth. Then the deauth frame is sent to the driver (which is surprising by itself), but the driver won't get anything useful from ieee80211_tx_dequeue because the queue is stopped (or more precisely because vif->txqs_stopped[0] is true). Then the deauth is not sent. Later on, the tasklet will run, but that'll be too late. We'll already have removed all the vif etc... Fix this by calling ieee80211_wake_txqs synchronously if we are not waking up the queues from the driver (we check the reason to determine that). This makes the code really convoluted because we may call ieee80211_wake_txqs from __ieee80211_wake_queue. The latter assumes that queue_stop_reason_lock has been taken by the caller and ieee80211_wake_txqs may release the lock to send the frames. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c462d22d60902db95d26bfda1b5a14b4a2cc1f17 Author: Luca Ceresoli Date: Tue Nov 27 03:34:45 2018 -0500 media: imx274: select REGMAP_I2C [ Upstream commit 4f9d7225c70dd9d3f406b79e60f8dbd2cd5ae743 ] The imx274 driver uses regmap and the build will fail without it. Fixes: drivers/media/i2c/imx274.c:142:21: error: variable ‘imx274_regmap_config’ has initializer but incomplete type static const struct regmap_config imx274_regmap_config = { ^~~~~~~~~~~~~ drivers/media/i2c/imx274.c:1869:19: error: implicit declaration of function ‘devm_regmap_init_i2c’ [-Werror=implicit-function-declaration] imx274->regmap = devm_regmap_init_i2c(client, &imx274_regmap_config); ^~~~~~~~~~~~~~~~~~~~ and others. Signed-off-by: Luca Ceresoli Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 65009e5318f585ce41708dff205ffa76f845c17c Author: Chen-Yu Tsai Date: Wed Dec 5 18:11:51 2018 +0800 clk: sunxi-ng: a33: Set CLK_SET_RATE_PARENT for all audio module clocks [ Upstream commit 6e6da2039c82271dd873b9ad2b902a692a7dd554 ] All the audio interfaces on Allwinner SoCs need to change their module clocks during operation, to switch between support for 44.1 kHz and 48 kHz family sample rates. The clock rate for the module clocks is governed by their upstream audio PLL. The module clocks themselves only have a gate, and sometimes a divider or mux. Thus any rate changes need to be propagated upstream. Set the CLK_SET_RATE_PARENT flag for all audio module clocks to achieve this. Signed-off-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 9aab383a7308db0159355d3f53cc5ac746b772fa Author: Chunfeng Yun Date: Thu Nov 29 10:34:34 2018 +0800 usb: mtu3: fix the issue about SetFeature(U1/U2_Enable) [ Upstream commit a0678e2eed41e81004308693ac84ea95614b0920 ] Fix the issue: device doesn't accept LGO_U1/U2: 1. set SW_U1/U2_ACCEPT_ENABLE to eanble controller to accept LGO_U1/U2 by default; 2. enable/disable controller to initiate requests for transition into U1/U2 by SW_U1/U2_REQUEST_ENABLE instead of SW_U1/U2_ACCEPT_ENABLE; Signed-off-by: Chunfeng Yun Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 63f46c261b9f982c66fff5eb64db70dd5b05d657 Author: Bart Van Assche Date: Wed Nov 28 15:43:09 2018 -0800 timekeeping: Use proper seqcount initializer [ Upstream commit ce10a5b3954f2514af726beb78ed8d7350c5e41c ] tk_core.seq is initialized open coded, but that misses to initialize the lockdep map when lockdep is enabled. Lockdep splats involving tk_core seq consequently lack a name and are hard to read. Use the proper initializer which takes care of the lockdep map initialization. [ tglx: Massaged changelog ] Signed-off-by: Bart Van Assche Signed-off-by: Thomas Gleixner Cc: peterz@infradead.org Cc: tj@kernel.org Cc: johannes.berg@intel.com Link: https://lkml.kernel.org/r/20181128234325.110011-12-bvanassche@acm.org Signed-off-by: Sasha Levin commit 2fe047eb0eceb4144240517737c6a0d8d721a71b Author: Mathias Nyman Date: Wed Nov 28 15:55:21 2018 +0200 usb: hub: delay hub autosuspend if USB3 port is still link training [ Upstream commit e86108940e541febf35813402ff29fa6f4a9ac0b ] When initializing a hub we want to give a USB3 port in link training the same debounce delay time before autosuspening the hub as already trained, connected enabled ports. USB3 ports won't reach the enabled state with "current connect status" and "connect status change" bits set until the USB3 link training finishes. Catching the port in link training (polling) and adding the debounce delay prevents unnecessary failed attempts to autosuspend the hub. Signed-off-by: Mathias Nyman Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 582f664651800f7f7cae719ba34d0b626d6466b1 Author: Marek Szyprowski Date: Tue Nov 20 16:38:15 2018 +0100 usb: dwc2: Disable power down feature on Samsung SoCs [ Upstream commit 35a6054132286a4ab92b536595093b82e6bdfcbc ] Power down feature of DWC2 module integrated in Samsung SoCs doesn't work properly or needs some additional handling in PHY or SoC glue layer, so disable it for now. Without disabling power down, DWC2 causes random memory trashes and fails enumeration if there is no USB link to host on driver probe. Fixes: 03ea6d6e9e1ff1 ("usb: dwc2: Enable power down") Acked-by: Minas Harutyunyan Signed-off-by: Marek Szyprowski Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9535baf8a6835898b98f71bfb9253dd65e0a1ec9 Author: Eric Long Date: Tue Nov 6 13:01:35 2018 +0800 dmaengine: sprd: Support DMA link-list cyclic callback [ Upstream commit 97dbd6ea02beb3a7027c158e0a110b5095268d59 ] The Spreadtrum DMA link-list mode is always one cyclic transfer, so we should clear the SPRD_DMA_LLIST_END flag for the link-list configuration. Moreover add cyclic callback support for the cyclic transfer. Signed-off-by: Eric Long Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4f05f36a3a7a12bf34d530e22c900bbf9105c028 Author: Anurag Kumar Vulisha Date: Sat Dec 1 16:43:29 2018 +0530 usb: dwc3: Correct the logic for checking TRB full in __dwc3_prepare_one_trb() [ Upstream commit b7a4fbe2300a8965ea760c7e871507b84aea17f6 ] Availability of TRB's is calculated using dwc3_calc_trbs_left(), which determines total available TRB's based on the HWO bit set in a TRB. In the present code, __dwc3_prepare_one_trb() is called with a TRB which needs to be prepared for transfer. This __dwc3_prepare_one_trb() calls dwc3_calc_trbs_left() to determine total available TRBs and set IOC bit if the total available TRBs are zero. Since the present working TRB (which is passed as an argument to __dwc3_prepare_one_trb() ) doesn't yet have the HWO bit set before calling dwc3_calc_trbs_left(), there are chances that dwc3_calc_trbs_left() wrongly calculates this present working TRB as free(since the HWO bit is not yet set) and returns the total available TRBs as greater than zero (including the present working TRB). This could be a problem. This patch corrects the above mentioned problem in __dwc3_prepare_one_trb() by increementing the dep->trb_enqueue at the last (after preparing the TRB) instead of increementing at the start and setting the IOC bit only if the total available TRBs returned by dwc3_calc_trbs_left() is 1 . Since we are increementing the dep->trb_enqueue at the last, the present working TRB is also considered as available by dwc3_calc_trbs_left() and non zero value is returned . So, according to the modified logic, when the total available TRBs is equal to 1 that means the total available TRBs in the pool are 0. Signed-off-by: Anurag Kumar Vulisha Reviewed-by: Thinh Nguyen Tested-by: Tejas Joglekar Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9f27a3a516d04002e28dff07fc8e53611a9a377d Author: Max Filippov Date: Tue Dec 4 16:08:20 2018 -0800 xtensa: xtfpga.dtsi: fix dtc warnings about SPI [ Upstream commit f37598be4e3896359e87c824be57ddddc280cc3f ] Rename SPI controller node in the XTFPGA DTS to spi@... This fixes the following build warnings: arch/xtensa/boot/dts/kc705_nommu.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/kc705_nommu.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/lx200mx.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/lx200mx.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/kc705.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/kc705.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/ml605.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/ml605.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' arch/xtensa/boot/dts/lx60.dtb: Warning (spi_bus_bridge): /soc/spi-master@0d0a0000: node name for SPI buses should be 'spi' arch/xtensa/boot/dts/lx60.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit ea2e6a0975a4bd93dc43f26363c0905eac5304d3 Author: Zoran Markovic Date: Wed Oct 17 16:25:44 2018 -0700 smack: fix access permissions for keyring [ Upstream commit 5b841bfab695e3b8ae793172a9ff7990f99cc3e2 ] Function smack_key_permission() only issues smack requests for the following operations: - KEY_NEED_READ (issues MAY_READ) - KEY_NEED_WRITE (issues MAY_WRITE) - KEY_NEED_LINK (issues MAY_WRITE) - KEY_NEED_SETATTR (issues MAY_WRITE) A blank smack request is issued in all other cases, resulting in smack access being granted if there is any rule defined between subject and object, or denied with -EACCES otherwise. Request MAY_READ access for KEY_NEED_SEARCH and KEY_NEED_VIEW. Fix the logic in the unlikely case when both MAY_READ and MAY_WRITE are needed. Validate access permission field for valid contents. Signed-off-by: Zoran Markovic Signed-off-by: Casey Schaufler Cc: Casey Schaufler Cc: James Morris Cc: "Serge E. Hallyn" Signed-off-by: Sasha Levin commit 8632c16068864e290588c02bda1a85b9835cfe95 Author: Ville Syrjälä Date: Thu Nov 29 19:44:45 2018 +0200 platform/x86: Fix config space access for intel_atomisp2_pm [ Upstream commit 6a31061833a52a79c99221b6251db08cf377470e ] We lose even config space access when we power gate the ISP via the PUNIT. That makes lspci & co. produce gibberish. To fix that let's try to implement actual runtime pm hooks and inform the pci core that the device always goes to D3cold. That will cause the pci core to resume the device before attempting config space access. This introduces another annoyance though. We get the following error every time we try to resume the device: intel_atomisp2_pm 0000:00:03.0: Refused to change power state, currently in D3 The reason being that the pci core tries to put the device back into D0 via the standard PCI PM mechanism before calling the driver resume hook. To fix this properly we'd need to infiltrate the platform pm hooks (could turn ugly real fast), or use pm domains (which don't seem to exist on x86), or some extra early resume hook for the driver (which doesn't exist either). So maybe we just choose to live with the error? Cc: Hans de Goede Cc: Alan Cox Cc: Andy Shevchenko Cc: Darren Hart Signed-off-by: Ville Syrjälä Signed-off-by: Andy Shevchenko Reviewed-by: Hans de Goede Signed-off-by: Sasha Levin commit e0c7fa70ee38e9781ddb5ff7c966fef028102069 Author: Alexey Khoroshilov Date: Fri Nov 23 16:56:26 2018 -0500 media: DaVinci-VPBE: fix error handling in vpbe_initialize() [ Upstream commit aa35dc3c71950e3fec3e230c06c27c0fbd0067f8 ] If vpbe_set_default_output() or vpbe_set_default_mode() fails, vpbe_initialize() returns error code without releasing resources. The patch adds error handling for that case. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2efe021b5ee4abb6070ec705702469d5ead459ad Author: Arnd Bergmann Date: Tue Oct 2 17:12:43 2018 -0400 media: i2c: TDA1997x: select CONFIG_HDMI [ Upstream commit 79e89e36dc8a47ef965a35b484d737a5227feed1 ] Without CONFIG_HDMI, we get a link error for this driver: drivers/media/i2c/tda1997x.o: In function `tda1997x_parse_infoframe': tda1997x.c:(.text+0x2195): undefined reference to `hdmi_infoframe_unpack' tda1997x.c:(.text+0x21b6): undefined reference to `hdmi_infoframe_log' drivers/media/i2c/tda1997x.o: In function `tda1997x_log_infoframe': tda1997x.c:(.text.unlikely+0x13d3): undefined reference to `hdmi_infoframe_unpack' tda1997x.c:(.text.unlikely+0x1426): undefined reference to `hdmi_infoframe_log' All other drivers in this directory that use HDMI select CONFIG_HDMI, so do the same here: Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 07b8c64a85feafb000ac75b0f2e11e5afd6e747f Author: Sebastian Andrzej Siewior Date: Wed Nov 28 23:20:11 2018 +0100 x86/fpu: Add might_fault() to user_insn() [ Upstream commit 6637401c35b2f327a35d27f44bda05e327f2f017 ] Every user of user_insn() passes an user memory pointer to this macro. Add might_fault() to user_insn() so we can spot users which are using this macro in sections where page faulting is not allowed. [ bp: Space it out to make it more visible. ] Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Borislav Petkov Reviewed-by: Rik van Riel Cc: "H. Peter Anvin" Cc: "Jason A. Donenfeld" Cc: Andy Lutomirski Cc: Dave Hansen Cc: Ingo Molnar Cc: Jann Horn Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Thomas Gleixner Cc: kvm ML Cc: x86-ml Link: https://lkml.kernel.org/r/20181128222035.2996-6-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 7a3963ff79fc98b326c865926c37cd0671d34b81 Author: Randy Dunlap Date: Thu Nov 29 14:34:15 2018 -0800 spi: fix spi-at91-usart.c build errors when PINCTRL is not set [ Upstream commit c2b142cc3939e932d4fa2210c2a5155df5736590 ] Fix build errors when CONFIG_PINCTRL is not enabled. The header file handles both CONFIG_PINCTRL enabled and disabled cases. CC [M] drivers/spi/spi-at91-usart.o ../drivers/spi/spi-at91-usart.c: In function 'at91_usart_spi_runtime_suspend': ../drivers/spi/spi-at91-usart.c:409:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration] pinctrl_pm_select_sleep_state(dev); ../drivers/spi/spi-at91-usart.c: In function 'at91_usart_spi_runtime_resume': ../drivers/spi/spi-at91-usart.c:419:2: error: implicit declaration of function 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration] pinctrl_pm_select_default_state(dev); Signed-off-by: Randy Dunlap Cc: Radu Pirea Cc: Mark Brown Cc: linux-spi@vger.kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2615d947e611f139b65c134671159153a66e8413 Author: Rob Herring Date: Thu Nov 29 19:52:51 2018 -0600 ARM: dts: aspeed: add missing memory unit-address [ Upstream commit 8ef86955fe59f7912a40d57ae4c6d511f0187b4d ] The base aspeed-g5.dtsi already defines a '/memory@80000000' node, so '/memory' in the board files create a duplicate node. We're probably getting lucky that the bootloader fixes up the memory node that the kernel ends up using. Add the unit-address so it's merged with the base node. Found with DT json-schema checks. Cc: Joel Stanley Cc: Andrew Jeffery Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-aspeed@lists.ozlabs.org Signed-off-by: Rob Herring Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 3159a4ec00f39b43ce1f43412ddcc868835ad067 Author: Lubomir Rintel Date: Wed Nov 28 18:53:10 2018 +0100 ARM: dts: mmp2: fix TWSI2 [ Upstream commit 1147e05ac9fc2ef86a3691e7ca5c2db7602d81dd ] Marvell keeps their MMP2 datasheet secret, but there are good clues that TWSI2 is not on 0xd4025000 on that platform, not does it use IRQ 58. In fact, the IRQ 58 on MMP2 seems to be a signal processor: arch/arm/mach-mmp/irqs.h:#define IRQ_MMP2_MSP 58 I'm taking a somewhat educated guess that is probably a copy & paste error from PXA168 or PXA910 and that the real controller in fact hides at address 0xd4031000 and uses an interrupt line multiplexed via IRQ 17. I'm also copying some properties from TWSI1 that were missing or incorrect. Tested on a OLPC XO 1.75 machine, where the RTC is on TWSI2. Signed-off-by: Lubomir Rintel Tested-by: Pavel Machek Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin commit 12eea1384f4d60c398dd2677afb262b70f40d925 Author: Eric Anholt Date: Wed Nov 28 15:09:27 2018 -0800 drm/v3d: Fix prime imports of buffers from other drivers. [ Upstream commit 62d1a752874962f072de8a779e960fcd2ab4847b ] v3d_bo_get_pages() checks this to decide to map the imported buffer instead of the backing shmem file. The caller was about to set this value anyway, and there's no error path in between. Ideally we wouldn't even allocate the shmem file for our imports, but that's a more invasive fix. Signed-off-by: Eric Anholt Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Link: https://patchwork.freedesktop.org/patch/msgid/20181128230927.10951-3-eric@anholt.net Acked-by: Daniel Vetter Reviewed-by: Dave Emett Signed-off-by: Sasha Levin commit 09f4b5aa261513490bf0361460f7fd30d1b2ce0f Author: Mark Rutland Date: Thu Nov 15 22:42:01 2018 +0000 arm64: ftrace: don't adjust the LR value [ Upstream commit 6e803e2e6e367db9a0d6ecae1bd24bb5752011bd ] The core ftrace code requires that when it is handed the PC of an instrumented function, this PC is the address of the instrumented instruction. This is necessary so that the core ftrace code can identify the specific instrumentation site. Since the instrumented function will be a BL, the address of the instrumented function is LR - 4 at entry to the ftrace code. This fixup is applied in the mcount_get_pc and mcount_get_pc0 helpers, which acquire the PC of the instrumented function. The mcount_get_lr helper is used to acquire the LR of the instrumented function, whose value does not require this adjustment, and cannot be adjusted to anything meaningful. No adjustment of this value is made on other architectures, including arm. However, arm64 adjusts this value by 4. This patch brings arm64 in line with other architectures and removes the adjustment of the LR value. Signed-off-by: Mark Rutland Cc: AKASHI Takahiro Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Torsten Duwe Cc: Will Deacon Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2c4b61d520beafcc6a89c55d01746f8d368f4fe8 Author: Lorenzo Bianconi Date: Mon Nov 5 00:18:26 2018 +0100 mt76x0: dfs: fix IBI_R11 configuration on non-radar channels [ Upstream commit 6bf4a8e902aad7df55d7f2b10b850cfa3f880996 ] Fix IBI_R11 configuration on non-radar channels for mt76x0e driver. This patch improve system stability under heavy load. Moreover use IBI_R11 name and remove magic numbers for 0x212c register Fixes: 0c3b3abc9251 ("mt76x0: pci: add DFS support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b7c51057f50392fe1882059b8e30f011d91a6549 Author: Harald Freudenberger Date: Mon Nov 19 11:36:13 2018 +0100 s390/zcrypt: improve special ap message cmd handling [ Upstream commit be534791011100d204602e2e0496e9e6ce8edf63 ] There exist very few ap messages which need to have the 'special' flag enabled. This flag tells the firmware layer to do some pre- and maybe postprocessing. However, it may happen that this special flag is enabled but the firmware is unable to deal with this kind of message and thus returns with reply code 0x41. For example older firmware may not know the newest messages triggered by the zcrypt device driver and thus react with reject and the named reply code. Unfortunately this reply code is not known to the zcrypt error routines and thus default behavior is to switch the ap queue offline. This patch now makes the ap error routine aware of the reply code and so userspace is informed about the bad processing result but the queue is not switched to offline state any more. Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 51f7a5342e3498b2ab1e4ada0be807c725646c6d Author: Arend van Spriel Date: Thu Nov 29 18:12:27 2018 +0100 firmware/efi: Add NULL pointer checks in efivars API functions [ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ] Since commit: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") we have a device driver accessing the efivars API. Several functions in the efivars API assume __efivars is set, i.e., that they will be accessed only after efivars_register() has been called. However, the following NULL pointer access was reported calling efivar_entry_size() from the brcmfmac device driver: Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = 60bfa5f1 [00000008] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM ... Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) Workqueue: events request_firmware_work_func PC is at efivar_entry_size+0x28/0x90 LR is at brcmf_fw_complete_request+0x3f8/0x8d4 [brcmfmac] pc : [] lr : [] psr: a00d0113 sp : ede7fe28 ip : ee983410 fp : c1787f30 r10: 00000000 r9 : 00000000 r8 : bf2b2258 r7 : ee983000 r6 : c1604c48 r5 : ede7fe88 r4 : edf337c0 r3 : 00000000 r2 : 00000000 r1 : ede7fe88 r0 : c17712c8 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: ad16804a DAC: 00000051 Disassembly showed that the local static variable __efivars is NULL, which is not entirely unexpected given that it is a non-EFI platform. So add a NULL pointer check to efivar_entry_size(), and to related functions while at it. In efivars_register() a couple of sanity checks are added as well. Reported-by: Jon Hunter Signed-off-by: Arend van Spriel Signed-off-by: Ard Biesheuvel Cc: Andy Lutomirski Cc: Bhupesh Sharma Cc: Borislav Petkov Cc: Dave Hansen Cc: Eric Snowberg Cc: Hans de Goede Cc: Joe Perches Cc: Julien Thierry Cc: Linus Torvalds Cc: Marc Zyngier Cc: Matt Fleming Cc: Nathan Chancellor Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Sedat Dilek Cc: Thomas Gleixner Cc: YiFei Zhu Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20181129171230.18699-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 5b8aafa6ce91dde873917178f697c212d5a1e0be Author: Thara Gopinath Date: Tue Nov 27 17:43:11 2018 -0500 thermal: Fix locking in cooling device sysfs update cur_state [ Upstream commit 68000a0d983f539c95ebe5dccd4f29535c7ac0af ] Sysfs interface to update cooling device cur_state does not currently holding cooling device lock sometimes leading to stale values in cur_state if getting updated simultanelously from user space and thermal framework. Adding the proper locking code fixes this issue. Signed-off-by: Thara Gopinath Signed-off-by: Zhang Rui Signed-off-by: Sasha Levin commit 39b28779167233626344ed62dc2d53e517a8973c Author: Wei Wang Date: Wed Nov 7 14:36:11 2018 -0800 Thermal: do not clear passive state during system sleep [ Upstream commit 964f4843a455d2ffb199512b08be8d5f077c4cac ] commit ff140fea847e ("Thermal: handle thermal zone device properly during system sleep") added PM hook to call thermal zone reset during sleep. However resetting thermal zone will also clear the passive state and thus cancel the polling queue which leads the passive cooling device state not being cleared properly after sleep. thermal_pm_notify => thermal_zone_device_reset set passive to 0 thermal_zone_trip_update will skip update passive as `old_target == instance->target'. monitor_thermal_zone => thermal_zone_device_set_polling will cancel tz->poll_queue, so the cooling device state will not be changed afterwards. Reported-by: Kame Wang Signed-off-by: Wei Wang Signed-off-by: Zhang Rui Signed-off-by: Sasha Levin commit c547539973227fe766ad777d5ca83577e8495e85 Author: Will Deacon Date: Thu Nov 29 16:31:04 2018 +0000 arm64: io: Ensure value passed to __iormb() is held in a 64-bit register [ Upstream commit 1b57ec8c75279b873639eb44a215479236f93481 ] As of commit 6460d3201471 ("arm64: io: Ensure calls to delay routines are ordered against prior readX()"), MMIO reads smaller than 64 bits fail to compile under clang because we end up mixing 32-bit and 64-bit register operands for the same data processing instruction: ./include/asm-generic/io.h:695:9: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths] return readb(addr); ^ ./arch/arm64/include/asm/io.h:147:58: note: expanded from macro 'readb' ^ ./include/asm-generic/io.h:695:9: note: use constraint modifier "w" ./arch/arm64/include/asm/io.h:147:50: note: expanded from macro 'readb' ^ ./arch/arm64/include/asm/io.h:118:24: note: expanded from macro '__iormb' asm volatile("eor %0, %1, %1\n" \ ^ Fix the build by casting the macro argument to 'unsigned long' when used as an input to the inline asm. Reported-by: Nick Desaulniers Reported-by: Nathan Chancellor Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 48d7d6f86d089b7bbd64436d06ca011c609dfd73 Author: Nicholas Mc Guire Date: Wed Nov 28 12:24:47 2018 +0100 perf: arm_spe: handle devm_kasprintf() failure [ Upstream commit 754a58db6a556e6e5f5e32f3e84e7d67b5bf9c8e ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignment to 'name' is not safe if unchecked. If NULL is passed in for name then perf_pmu_register() would not fail but rather silently jump to skip_type which is not the intent here. As perf_pmu_register() may also return -ENOMEM returning -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here as well. Acked-by: Mark Rutland Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Signed-off-by: Nicholas Mc Guire [will: reworded error message] Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8576fc44ba2391a2aef530b669308138dab4da81 Author: Sean Paul Date: Thu Nov 29 10:04:14 2018 -0500 drm: Clear state->acquire_ctx before leaving drm_atomic_helper_commit_duplicated_state() [ Upstream commit aa394b0dd68cb00c483e151dcd84713d4d517ed1 ] drm_atomic_helper_commit_duplicated_state() sets state->acquire_ctx to the context given in the argument and leaves it in state after it quits. The lifetime of state and context are not guaranteed to be the same, so we shouldn't leave that pointer hanging around. This patch resets the context to NULL to avoid any oopses. Changes in v2: - Added to the set Suggested-by: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20181129150423.239081-1-sean@poorly.run Signed-off-by: Sasha Levin commit 4faacc07e08f17db5d8087343da0b28cf25827a9 Author: J. Bruce Fields Date: Tue Nov 27 15:54:17 2018 -0500 nfsd4: fix crash on writing v4_end_grace before nfsd startup [ Upstream commit 62a063b8e7d1db684db3f207261a466fa3194e72 ] Anatoly Trosinenko reports that this: 1) Checkout fresh master Linux branch (tested with commit e195ca6cb) 2) Copy x84_64-config-4.14 to .config, then enable NFS server v4 and build 3) From `kvm-xfstests shell`: results in NULL dereference in locks_end_grace. Check that nfsd has been started before trying to end the grace period. Reported-by: Anatoly Trosinenko Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit f2ab5666f90c635dc729fb0416053bab10c25547 Author: Yangtao Li Date: Sat Nov 24 09:52:23 2018 -0500 soc: bcm: brcmstb: Don't leak device tree node reference [ Upstream commit 1861a7f07e02292830a1ca256328d370deefea30 ] of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. soc_is_brcmstb() doesn't do that, so fix it. [treding: slightly rewrite to avoid inline comparison] Fixes: d52fad262041 ("soc: add stubs for brcmstb SoC's") Signed-off-by: Yangtao Li Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 3e380fc2ae4d18210eec9c472b12e2b2544f7dc1 Author: Young Xiao Date: Wed Nov 28 12:36:39 2018 +0000 sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN [ Upstream commit a11f6ca9aef989b56cd31ff4ee2af4fb31a172ec ] __vdc_tx_trigger should only loop on EAGAIN a finite number of times. See commit adddc32d6fde ("sunvnet: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN") for detail. Signed-off-by: Young Xiao Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a35e4e7ca77a9f1dca8b57333721903ba7d5feec Author: YueHaibing Date: Sat Nov 24 18:16:41 2018 +0800 net: aquantia: return 'err' if set MPI_DEINIT state fails [ Upstream commit 4e3c7c00bba0636b97eb23d582c20b0f5d95ce20 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c:260:7: warning: variable 'err' set but not used [-Wunused-but-set-variable] 'err' should be returned while set MPI_DEINIT state fails in hw_atl_utils_soft_reset. Fixes: cce96d1883da ("net: aquantia: Regression on reset with 1.x firmware") Signed-off-by: YueHaibing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5950802fc30199b8892acb201d2a82614a23137e Author: Will Deacon Date: Wed Nov 7 23:06:15 2018 +0000 arm64: io: Ensure calls to delay routines are ordered against prior readX() [ Upstream commit 6460d32014717686d3b7963595950ba2c6d1bb5e ] A relatively standard idiom for ensuring that a pair of MMIO writes to a device arrive at that device with a specified minimum delay between them is as follows: writel_relaxed(42, dev_base + CTL1); readl(dev_base + CTL1); udelay(10); writel_relaxed(42, dev_base + CTL2); the intention being that the read-back from the device will push the prior write to CTL1, and the udelay will hold up the write to CTL1 until at least 10us have elapsed. Unfortunately, on arm64 where the underlying delay loop is implemented as a read of the architected counter, the CPU does not guarantee ordering from the readl() to the delay loop and therefore the delay loop could in theory be speculated and not provide the desired interval between the two writes. Fix this in a similar manner to PowerPC by introducing a dummy control dependency on the output of readX() which, combined with the ISB in the read of the architected counter, guarantees that a subsequent delay loop can not be executed until the readX() has returned its result. Cc: Benjamin Herrenschmidt Cc: Arnd Bergmann Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6911d528c3284fafcf8b91d9a8bcfe7aa11a5d44 Author: Simon Horman Date: Wed Nov 21 13:09:28 2018 +0100 i2c: sh_mobile: add support for r8a77990 (R-Car E3) [ Upstream commit 5eb316e636eb298c204f5b368526d4480b63c0ba ] Add support for the IIC code for the r8a77990 (R-Car E3). It is not considered compatible with existing fallback bindings due to the documented absence of automatic transmission registers. These registers are currently not used by the driver and thus the provides the same behaviour for "renesas,iic-r8a77990" and "renesas,rcar-gen3-iic". The point of declaring incompatibility is to allow for automatic transmission register support to be added to "renesas,iic-r8a77990" and "renesas,rcar-gen3-iic" in future. Signed-off-by: Simon Horman Reviewed-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 35435b6d5727398032d7c802ecadf36a11bc06e8 Author: Tiezhu Yang Date: Wed Nov 21 07:21:38 2018 +0800 f2fs: fix wrong return value of f2fs_acl_create [ Upstream commit f6176473a0c7472380eef72ebeb330cf9485bf0a ] When call f2fs_acl_create_masq() failed, the caller f2fs_acl_create() should return -EIO instead of -ENOMEM, this patch makes it consistent with posix_acl_create() which has been fixed in commit beaf226b863a ("posix_acl: don't ignore return value of posix_acl_create_masq()"). Fixes: 83dfe53c185e ("f2fs: fix reference leaks in f2fs_acl_create") Signed-off-by: Tiezhu Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0c815c0aacfc34af31b03642dd2ae6a01c68aae9 Author: Sheng Yong Date: Wed Nov 14 19:34:28 2018 +0800 f2fs: fix race between write_checkpoint and write_begin [ Upstream commit 2866fb16d67992195b0526d19e65acb6640fb87f ] The following race could lead to inconsistent SIT bitmap: Task A Task B ====== ====== f2fs_write_checkpoint block_operations f2fs_lock_all down_write(node_change) down_write(node_write) ... sync ... up_write(node_change) f2fs_file_write_iter set_inode_flag(FI_NO_PREALLOC) ...... f2fs_write_begin(index=0, has inline data) prepare_write_begin __do_map_lock(AIO) => down_read(node_change) f2fs_convert_inline_page => update SIT __do_map_lock(AIO) => up_read(node_change) f2fs_flush_sit_entries <= inconsistent SIT finish write checkpoint sudden-power-off If SPO occurs after checkpoint is finished, SIT bitmap will be set incorrectly. Signed-off-by: Sheng Yong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit df1b9fea7a77f64a2b9c9a3dd05b01d751fa5a60 Author: Yunlei He Date: Tue Nov 6 10:25:29 2018 +0800 f2fs: move dir data flush to write checkpoint process [ Upstream commit b61ac5b720146c619c7cdf17eff2551b934399e5 ] This patch move dir data flush to write checkpoint process, by doing this, it may reduce some time for dir fsync. pre: -f2fs_do_sync_file enter -file_write_and_wait_range <- flush & wait -write_checkpoint -do_checkpoint <- wait all -f2fs_do_sync_file exit now: -f2fs_do_sync_file enter -write_checkpoint -block_operations <- flush dir & no wait -do_checkpoint <- wait all -f2fs_do_sync_file exit Signed-off-by: Yunlei He Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2e8248ddc9e388e106827f9503124eebe06bb5b0 Author: Yunlong Song Date: Tue Sep 18 20:39:53 2018 +0800 f2fs: avoid GC causing encrypted file corrupted [ Upstream commit 9bf1a3f73927492c8be127b642197125e9d52be8 ] The encrypted file may be corrupted by GC in following case: Time 1: | segment 1 blkaddr = A | GC -> | segment 2 blkaddr = B | Encrypted block 1 is moved from blkaddr A of segment 1 to blkaddr B of segment 2, Time 2: | segment 1 blkaddr = B | GC -> | segment 3 blkaddr = C | Before page 1 is written back and if segment 2 become a victim, then page 1 is moved from blkaddr B of segment 2 to blkaddr Cof segment 3, during the GC process of Time 2, f2fs should wait for page 1 written back before reading it, or move_data_block will read a garbage block from blkaddr B since page is not written back to blkaddr B yet. Commit 6aa58d8a ("f2fs: readahead encrypted block during GC") introduce ra_data_block to read encrypted block, but it forgets to add f2fs_wait_on_page_writeback to avoid racing between GC and flush. Signed-off-by: Yunlong Song Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f860782b9fc08f8149ab7943c7c3706264168569 Author: Michael Straube Date: Sun Nov 25 10:22:25 2018 +0100 staging: pi433: fix potential null dereference [ Upstream commit 64c4c4ca6c129a4191e8e1e91b2d5d9b8d08c518 ] Add a test for successful call to cdev_alloc() to avoid potential null dereference. Issue reported by smatch. Signed-off-by: Michael Straube Fixes: 874bcba65f9a ("staging: pi433: New driver") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f1d84e3c45c3f8b1b2c3c76ef7a52c8e23e67b56 Author: Andy Shevchenko Date: Wed Nov 21 15:43:37 2018 +0200 ACPI: SPCR: Consider baud rate 0 as preconfigured state [ Upstream commit b413b1abeb21b4a152c0bf8d1379efa30759b6e3 ] Since SPCR 1.04 [1] the baud rate of 0 means a preconfigured state of UART. Assume firmware or bootloader configures console correctly. [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table Signed-off-by: Andy Shevchenko Reviewed-by: Prarit Bhargava Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c22be94a55876b78777a916f406373d103b1cad0 Author: Hans Verkuil Date: Thu Nov 8 04:51:51 2018 -0500 media: adv*/tc358743/ths8200: fill in min width/height/pixelclock [ Upstream commit 2912289a518077ddb8214e05336700148e97e235 ] The v4l2_dv_timings_cap struct is used to do sanity checks when setting and enumerating DV timings, ensuring that only valid timings as per the HW capabilities are allowed. However, many drivers just filled in 0 for the minimum width, height or pixelclock frequency. This can cause timings with e.g. 0 as width and height to be accepted, which will in turn lead to a potential division by zero. Fill in proper values are minimum boundaries. 640x350 was chosen since it is the smallest resolution in v4l2-dv-timings.h. Same for 13 MHz as the lowest pixelclock frequency (it's slightly below the minimum of 13.5 MHz in the v4l2-dv-timings.h header). Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 50df554e91d1a101e4957aa88f71b014281d6e7a Author: Hans de Goede Date: Tue Nov 20 12:10:14 2018 +0100 iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID [ Upstream commit 7f6232e69539971cf9eaed07a6c14ab4a2361133 ] Various 2-in-1's use KIOX010A and KIOX020A as HIDs for 2 KXCJ91008 accelerometers. The KIOX010A HID is for the one in the base and the KIOX020A for the accelerometer in the keyboard. Since userspace does not have a way yet to deal with (or ignore) the accelerometer in the keyboard, this commit just adds the KIOX010A HID for now so that display rotation will work. Related: https://github.com/hadess/iio-sensor-proxy/issues/166 Signed-off-by: Hans de Goede Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 8fafca7b64028040382445000b6d471b30708594 Author: Martin Blumenstingl Date: Thu Nov 22 23:01:11 2018 +0100 iio: adc: meson-saradc: fix internal clock names [ Upstream commit 50314f98b0ac468218e7c9af8c99f215a35436df ] Before this patch we are registering the internal clocks (for example on Meson8b, where the SAR ADC IP block implements the divider and gate clocks) with the following names: - /soc/cbus@c1100000/adc@8680#adc_div - /soc/cbus@c1100000/adc@8680#adc_en This is bad because the common clock framework uses the clock to create a directory in /clk. With such name, the directory creation (silently) fails and the debugfs entry ends up being created at the debugfs root. With this change, the new clock names are: - c1108680.adc#adc_div - c1108680.adc#adc_en This matches the clock naming scheme used in the PWM, Ethernet and MMC drivers. It also fixes the problem with debugfs. The idea is shamelessly taken from commit b96e9eb62841c5 ("pwm: meson: Fix mux clock names"). Fixes: 3921db46a8c5bc ("iio: Convert to using %pOF instead of full_name") Signed-off-by: Martin Blumenstingl Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit dcf38182017d8793342e4aaee6df24c29777b26e Author: Nicholas Mc Guire Date: Thu Nov 22 08:46:43 2018 +0100 iio: adc: meson-saradc: check for devm_kasprintf failure [ Upstream commit aad172b017617994343e36d8659c69e14cd694fd ] devm_kasprintf() may return NULL on failure of internal allocation thus the assignments to init.name are not safe if not checked. On error meson_sar_adc_clk_init() returns negative values so -ENOMEM in the (unlikely) failure case of devm_kasprintf() should be fine here. Signed-off-by: Nicholas Mc Guire Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs") Acked-by: Martin Blumenstingl Tested-by: Martin Blumenstingl Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit eaa9cde28e3b4cb8e7476f49b052092b68bfbe8b Author: Mathieu Malaterre Date: Wed Oct 31 13:31:56 2018 +0100 powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly [ Upstream commit beba24ac59133cb36ecd03f9af9ccb11971ee20e ] When both `CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y` and `CONFIG_UBSAN=y` are set, link step typically produce numberous warnings about orphan section: + powerpc-linux-gnu-ld -EB -m elf32ppc -Bstatic --orphan-handling=warn --build-id --gc-sections -X -o .tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --who le-archive built-in.a --no-whole-archive --start-group lib/lib.a --end-group powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_data393' from `init/main.o' being placed in section `.data..Lubsan_data393'. powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_data394' from `init/main.o' being placed in section `.data..Lubsan_data394'. ... powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_type11' from `init/main.o' being placed in section `.data..Lubsan_type11'. powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_type12' from `init/main.o' being placed in section `.data..Lubsan_type12'. ... This commit remove those warnings produced at W=1. Link: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg135407.html Suggested-by: Nicholas Piggin Signed-off-by: Mathieu Malaterre Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 4baa4c53174d8a99c4aae82ba4b1d29cced8fa2a Author: Nathan Chancellor Date: Thu Oct 25 11:05:25 2018 -0700 dmaengine: xilinx_dma: Remove __aligned attribute on zynqmp_dma_desc_ll [ Upstream commit aeaebcc17cdf37065d2693865eeb1ff1c7dc5bf3 ] Clang warns: drivers/dma/xilinx/zynqmp_dma.c:166:4: warning: attribute 'aligned' is ignored, place it after "struct" to apply attribute to type declaration [-Wignored-attributes] }; __aligned(64) ^ ./include/linux/compiler_types.h:200:38: note: expanded from macro '__aligned' ^ 1 warning generated. As Nick pointed out in the previous version of this patch, the author likely intended for this struct to be 8-byte (64-bit) aligned, not 64-byte, which is the default. Remove the hanging __aligned attribute. Fixes: b0cc417c1637 ("dmaengine: Add Xilinx zynqmp dma engine driver support") Reported-by: Nick Desaulniers Suggested-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 77ac53238f5df2ad84cd89944c058133060f6f0b Author: YueHaibing Date: Fri Nov 23 09:54:55 2018 +0800 ptp: Fix pass zero to ERR_PTR() in ptp_clock_register [ Upstream commit aea0a897af9e44c258e8ab9296fad417f1bc063a ] Fix smatch warning: drivers/ptp/ptp_clock.c:298 ptp_clock_register() warn: passing zero to 'ERR_PTR' 'err' should be set while device_create_with_groups and pps_register_source fails Fixes: 85a66e550195 ("ptp: create "pins" together with the rest of attributes") Signed-off-by: YueHaibing Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 659614dbd43d8ab9c2d330bc17d5dee8c3f6440b Author: Martin Blumenstingl Date: Thu Nov 15 23:40:45 2018 +0100 clk: meson: meson8b: mark the CPU clock as CLK_IS_CRITICAL [ Upstream commit 0dad1ec65bc30a549aba38d34a727309bbf41bc8 ] We don't want the common clock framework to disable the "cpu_clk" if it's not used by any device. The cpufreq-dt driver does not enable the CPU clocks. However, even if it would we would still want the CPU clock to be enabled at all times because the CPU clock is also required even if we disable CPU frequency scaling on a specific board. The reason why we want the CPU clock to be enabled is a clock further up in the tree: Since commit 6f888e7bc7bd58 ("clk: meson: clk-pll: add enable bit") the sys_pll can be disabled. However, since the CPU clock is derived from sys_pll we don't want sys_pll to get disabled. The common clock framework takes care of that for us by enabling all parent clocks of our CPU clock when we mark the CPU clock with CLK_IS_CRITICAL. Until now this is not a problem yet because all clocks in the CPU clock's tree (including sys_pll) are read-only. However, once we allow modifications to the clocks in that tree we will need this. Signed-off-by: Martin Blumenstingl Acked-by: Jerome Brunet Signed-off-by: Neil Armstrong Link: https://lkml.kernel.org/r/20181115224048.13511-4-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit d723c317c9aa8da88cf9f00a1b337967cb91fb79 Author: Martin Blumenstingl Date: Thu Sep 27 10:59:21 2018 +0200 clk: meson: meson8b: fix the width of the cpu_scale_div clock [ Upstream commit a8662eadd1032018f31e37deda811790b2326662 ] According to the public S805 datasheet HHI_SYS_CPU_CLK_CNTL1[29:20] is the register for the CPU scale_div clock. This matches the code in Amlogic's 3.10 GPL kernel sources: N = (aml_read_reg32(P_HHI_SYS_CPU_CLK_CNTL1) >> 20) & 0x3FF; This means that the divider register is 10 bit wide instead of 9 bits. So far this is not a problem since all u-boot versions I have seen are not using the cpu_scale_div clock at all (instead they are configuring the CPU clock to run off cpu_in_sel directly). The fixes tag points to the latest rework of the CPU clocks. However, even before the rework it was wrong. Commit 7a29a869434e8b ("clk: meson: Add support for Meson clock controller") defines MESON_N_WIDTH as 9 (in drivers/clk/meson/clk-cpu.c). But since the old clk-cpu implementation this only carries the fixes tag for the CPU clock rewordk. Fixes: 251b6fd38bcb9c ("clk: meson: rework meson8b cpu clock") Signed-off-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lkml.kernel.org/r/20180927085921.24627-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 5e8cb7e03d3dd21e3fde03e4a631c60fb18c6004 Author: Martin Blumenstingl Date: Thu Nov 15 23:40:44 2018 +0100 clk: meson: meson8b: do not use cpu_div3 for cpu_scale_out_sel [ Upstream commit a5ac1ead32c9aac285f6436e09b4f6111996e9b8 ] The cpu_div3 clock (cpu_in divided by 3) generates a signal with a duty cycle of 33%. The CPU clock however requires a clock signal with a duty cycle of 50% to run stable. cpu_div3 was observed to be problematic when cycling through all available CPU frequencies (with additional patches on top of this one) while running "stress --cpu 4" in the background. This caused sporadic hangs where the whole system would fully lock up. Amlogic's 3.10 kernel code also does not use the cpu_div3 clock either when changing the CPU clock. Signed-off-by: Martin Blumenstingl Reviewed-by: Jerome Brunet Signed-off-by: Neil Armstrong Link: https://lkml.kernel.org/r/20181115224048.13511-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit fe6148df4d3f78af4a63238ae701c00980a054d9 Author: Laurent Pinchart Date: Tue Nov 6 17:13:44 2018 +0200 drm: rcar-du: Fix external clock error checks [ Upstream commit 63a298f22a6183b5b7536a203596c6570dfcfe8e ] The rcar-du driver supports probe deferral for external clocks, but implements it badly by checking the wrong pointer due to a bad copy and paste. Fix it. While at it, reject invalid clocks outright for DU channels that have a display PLL, as the external clock is mandatory in that case. This avoids a WARN_ON() at runtime. Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel clock") Reported-by: Kuninori Morimoto Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Sasha Levin commit f9acb02096f0a8927029a1861cc6b143ac9b8f0c Author: Parav Pandit Date: Fri Nov 16 03:50:57 2018 +0200 RDMA/core: Sync unregistration with netlink commands [ Upstream commit 01b671170d7f82b959dad6d5dbb44d7a915e647d ] When the rdma device is getting removed, get resource info can race with device removal, as below: CPU-0 CPU-1 -------- -------- rdma_nl_rcv_msg() nldev_res_get_cq_dumpit() mutex_lock(device_lock); get device reference mutex_unlock(device_lock); [..] ib_unregister_device() /* Valid reference to * device->dev exists. */ ib_dealloc_device() [..] provider->fill_res_entry(); Even though device object is not freed, fill_res_entry() can get called on device which doesn't have a driver anymore. Kernel core device reference count is not sufficient, as this only keeps the structure valid, and doesn't guarantee the driver is still loaded. Similar race can occur with device renaming and device removal, where device_rename() tries to rename a unregistered device. While this is fine for devices of a class which are not net namespace aware, but it is incorrect for net namespace aware class coming in subsequent series. If a class is net namespace aware, then the below [1] call trace is observed in above situation. Therefore, to avoid the race, keep a reference count and let device unregistration wait until all netlink users drop the reference. [1] Call trace: kernfs: ns required in 'infiniband' for 'mlx5_0' WARNING: CPU: 18 PID: 44270 at fs/kernfs/dir.c:842 kernfs_find_ns+0x104/0x120 libahci i2c_core mlxfw libata dca [last unloaded: devlink] RIP: 0010:kernfs_find_ns+0x104/0x120 Call Trace: kernfs_find_and_get_ns+0x2e/0x50 sysfs_rename_link_ns+0x40/0xb0 device_rename+0xb2/0xf0 ib_device_rename+0xb3/0x100 [ib_core] nldev_set_doit+0x165/0x190 [ib_core] rdma_nl_rcv_msg+0x249/0x250 [ib_core] ? netlink_deliver_tap+0x8f/0x3e0 rdma_nl_rcv+0xd6/0x120 [ib_core] netlink_unicast+0x17c/0x230 netlink_sendmsg+0x2f0/0x3e0 sock_sendmsg+0x30/0x40 __sys_sendto+0xdc/0x160 Fixes: da5c85078215 ("RDMA/nldev: add driver-specific resource tracking") Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7b26372fbd239fd0de5dc4d349691767ac01b90d Author: Hans Verkuil Date: Tue Nov 6 09:06:41 2018 -0500 media: vivid: fill in media_device bus_info [ Upstream commit e10b40f3304360d3a2d07d690ff12197f828f2c8 ] If you create multiple vivid instances, each with their own media device, then there was no way to tell them apart. Fill in the bus_info so each instance has a unique bus_info string. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e6cef0ba3b97744883d83867ac9d18c8b3f1b404 Author: Gao Xiang Date: Fri Nov 23 01:16:00 2018 +0800 staging: erofs: fix race when the managed cache is enabled [ Upstream commit 51232df5e4b268936beccde5248f312a316800be ] When the managed cache is enabled, the last reference count of a workgroup must be used for its workstation. Otherwise, it could lead to incorrect (un)freezes in the reclaim path, and it would be harmful. A typical race as follows: Thread 1 (In the reclaim path) Thread 2 workgroup_freeze(grp, 1) refcnt = 1 ... workgroup_unfreeze(grp, 1) refcnt = 1 workgroup_get(grp) refcnt = 2 (x) workgroup_put(grp) refcnt = 1 (x) ...unexpected behaviors * grp is detached but still used, which violates cache-managed freeze constraint. Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 289d181cfaa5ffb6898735d191f1a660ca6229bf Author: Gao Xiang Date: Fri Nov 23 01:15:59 2018 +0800 staging: erofs: fix the definition of DBG_BUGON [ Upstream commit eef168789866514e5d4316f030131c9fe65b643f ] It's better not to positively BUG_ON the kernel, however developers need a way to locate issues as soon as possible. DBG_BUGON is introduced and it could only crash when EROFS_FS_DEBUG (EROFS developping feature) is on. It is helpful for developers to find and solve bugs quickly by eng builds. Previously, DBG_BUGON is defined as ((void)0) if EROFS_FS_DEBUG is off, but some unused variable warnings as follows could occur: drivers/staging/erofs/unzip_vle.c: In function `init_alway:': drivers/staging/erofs/unzip_vle.c:61:33: warning: unused variable `work' [-Wunused-variable] struct z_erofs_vle_work *const work = ^~~~ Fix it to #define DBG_BUGON(x) ((void)(x)). Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cef43a90421a840daccf0e2fb42fc53afb27cfaf Author: Alexey Khoroshilov Date: Sat Oct 20 13:50:19 2018 -0400 media: mtk-vcodec: Release device nodes in mtk_vcodec_init_enc_pm() [ Upstream commit 8ea0f2ba0fa3f91ea1b8d823a54b042026ada6b3 ] of_parse_phandle() returns the device node with refcount incremented. There are two nodes that are used temporary in mtk_vcodec_init_enc_pm(), but their refcounts are not decremented. The patch adds one of_node_put() and fixes returning error codes. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7db34269808a25731785f5e2aa35fa62716416f4 Author: Akinobu Mita Date: Sat Oct 20 10:26:23 2018 -0400 media: video-i2c: avoid accessing released memory area when removing driver [ Upstream commit c764da98a600a4b068d25c77164f092f159cecec ] The video device release() callback for video-i2c driver frees the whole struct video_i2c_data. If there is no user left for the video device when video_unregister_device() is called, the release callback is executed. However, in video_i2c_remove() some fields (v4l2_dev, lock, and queue_lock) in struct video_i2c_data are still accessed after video_unregister_device() is called. This fixes the use after free by moving the code from video_i2c_remove() to the release() callback. Fixes: 5cebaac60974 ("media: video-i2c: add video-i2c driver") Reviewed-by: Matt Ranostay Signed-off-by: Akinobu Mita Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 25b2b2a581366be0c14ec0ec5b702197f54a0a64 Author: Sean Young Date: Sun Nov 4 05:12:09 2018 -0500 media: rc: ensure close() is called on rc_unregister_device [ Upstream commit 8e782fcf78275f505194e767c515202d4fd274bc ] If userspace has an open file descriptor on the rc input device or lirc device when rc_unregister_device() is called, then the rc close() is never called. This ensures that the receiver is turned off on the nuvoton-cir driver during shutdown. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f44490918b99606f61e231d27e04ceb5a869912a Author: Yangtao Li Date: Wed Nov 21 07:49:12 2018 -0500 soc/tegra: Don't leak device tree node reference [ Upstream commit 9eb40fa2cd2d1f6829e7b49bb22692f754b9cfe0 ] of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. soc_is_tegra() doesn't do that, so fix it. Signed-off-by: Yangtao Li Acked-by: Jon Hunter [treding: slightly rewrite to avoid inline comparison] Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 77635e73424a6f940d62f559858715ddc0e40d2a Author: Arnd Bergmann Date: Fri Nov 2 16:35:23 2018 +0100 scsi: cxgb4i: fix thermal configuration dependencies [ Upstream commit 8d0bb86e2cf6c96d88c3de56a2a29329872c454d ] I fixed a bug by adding a dependency in the network driver, but that fix caused a related bug in the SCSI driver: WARNING: unmet direct dependencies detected for CHELSIO_T4 Depends on [m]: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_CHELSIO [=y] && PCI [=y] && (IPV6 [=y] || IPV6 [=y]=n) && (THERMAL [=m] || !THERMAL [=m]) Selected by [y]: - SCSI_CXGB4_ISCSI [=y] && SCSI_LOWLEVEL [=y] && SCSI [=y] && PCI [=y] && INET [=y] && (IPV6 [=y] || IPV6 [=y]=n) drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.o: In function `cxgb4_thermal_init': cxgb4_thermal.c:(.text+0x158): undefined reference to `thermal_zone_device_register' drivers/net/ethernet/chelsio/cxgb4/cxgb4_thermal.o: In function `cxgb4_thermal_remove': cxgb4_thermal.c:(.text+0x1d8): undefined reference to `thermal_zone_device_unregister' /git/arm-soc/Makefile:1042: recipe for target 'vmlinux' failed The same dependency needs to be propagated here to make it work correctly with CONFIG_THERMAL=m and SCSI_CXGB4_ISCSI=y. That change by itself causes another problem with a circular dependency, as we use 'select NETDEVICES'. This is something we really should not do anyway, as a driver symbol should never select another major subsystem, so let's turn that into a 'depends on'. I don't see any downsides of that, as NETDEVICES is only disabled in rather obscure cases that are not relevant to the users of cxgb4i. Fixes: e70a57fa59bb ("cxgb4: fix thermal configuration dependencies") Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3ec666a60bd6f49910b1d8f148d32ca16175f528 Author: Pu Wen Date: Mon Nov 12 15:40:51 2018 +0800 perf tools: Add Hygon Dhyana support [ Upstream commit 4787eff3fa88f62fede6ed7afa06477ae6bf984d ] The tool perf is useful for the performance analysis on the Hygon Dhyana platform. But right now there is no Hygon support for it to analyze the KVM guest os data. So add Hygon Dhyana support to it by checking vendor string to share the code path of AMD. Signed-off-by: Pu Wen Acked-by: Borislav Petkov Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1542008451-31735-1-git-send-email-puwen@hygon.cn Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 976f037aa2d7075625b582f9392ac9916ad86521 Author: Sami Tolvanen Date: Tue Oct 23 15:15:35 2018 -0700 modpost: validate symbol names also in find_elf_symbol [ Upstream commit 5818c683a619c534c113e1f66d24f636defc29bc ] If an ARM mapping symbol shares an address with a valid symbol, find_elf_symbol can currently return the mapping symbol instead, as the symbol is not validated. This can result in confusing warnings: WARNING: vmlinux.o(.text+0x18f4028): Section mismatch in reference from the function set_reset_devices() to the variable .init.text:$x.0 This change adds a call to is_valid_name to find_elf_symbol, similarly to how it's already used in find_elf_symbol2. Signed-off-by: Sami Tolvanen Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 57da3b1f9974aa43a04c5f32adf633467d3e7ced Author: Saeed Mahameed Date: Mon Nov 19 10:52:31 2018 -0800 net/mlx5: EQ, Use the right place to store/read IRQ affinity hint [ Upstream commit 1e86ace4c140fd5a693e266c9b23409358f25381 ] Currently the cpu affinity hint mask for completion EQs is stored and read from the wrong place, since reading and storing is done from the same index, there is no actual issue with that, but internal irq_info for completion EQs stars at MLX5_EQ_VEC_COMP_BASE offset in irq_info array, this patch changes the code to use the correct offset to store and read the IRQ affinity hint. Signed-off-by: Saeed Mahameed Reviewed-by: Leon Romanovsky Reviewed-by: Tariq Toukan Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c3538844113119c0b8d3715afecac36878573a36 Author: Stanislav Fomichev Date: Mon Nov 19 14:49:01 2018 -0800 bpf: libbpf: retry map creation without the name [ Upstream commit 23499442c319412aa8e54e7a939e2eb531bdd77d ] Since commit 88cda1c9da02 ("bpf: libbpf: Provide basic API support to specify BPF obj name"), libbpf unconditionally sets bpf_attr->name for maps. Pre v4.14 kernels don't know about map names and return an error about unexpected non-zero data. Retry sys_bpf without a map name to cover older kernels. v2 changes: * check for errno == EINVAL as suggested by Daniel Borkmann Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 8f718712ff1748331fe585fcd245266f093cb7b1 Author: Yogesh Mohan Marimuthu Date: Sat Oct 20 01:21:40 2018 +0530 drm/amd/display: calculate stream->phy_pix_clk before clock mapping [ Upstream commit 08e1c28dd521c7b08d1b0af0bae9fb22ccc012a4 ] [why] phy_pix_clk is one of the variable used to check if one PLL can be shared with displays having common mode set configuration. As of now phy_pix_clock varialbe is calculated in function dc_validate_stream(). dc_validate_stream() function is called after clocks are assigned for the new display. Due to this during hotplug, when PLL sharing conditions are checked for new display phy_pix_clk variable will be 0 and for displays that are already enabled phy_pix_clk will have some value. Hence PLL will not be shared and if the display hardware doesn't have any more PLL to assign, mode set will fail due to resource unavailability. [how] Instead of only calculating the phy_pix_clk variable after the PLL is assigned for new display, this patch calculates phy_pix_clk also during the before assigning the PLL for new display. Signed-off-by: Yogesh Mohan Marimuthu Reviewed-by: Harry Wentland Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e4ac759ee9d7957d06f739c13acd7c125f336166 Author: Murton Liu Date: Wed Oct 17 14:47:45 2018 -0400 drm/amd/display: fix gamma not being applied correctly [ Upstream commit 8ce504b9389be846bcdf512ed5be8f661b3bf097 ] [why] Gamma was always being set as identity on SDR monitor, leading to no changes in gamma. This caused nightlight to not apply correctly. [how] Added a default gamma structure to compare against in the sdr case. Signed-off-by: Murton Liu Reviewed-by: Krunoslav Kovac Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 19c0a077a90cc77ab10530df83b0a60411bbe943 Author: Nathan Chancellor Date: Wed Oct 17 17:52:07 2018 -0700 ARM: OMAP2+: hwmod: Fix some section annotations [ Upstream commit c10b26abeb53cabc1e6271a167d3f3d396ce0218 ] When building the kernel with Clang, the following section mismatch warnings appears: WARNING: vmlinux.o(.text+0x2d398): Section mismatch in reference from the function _setup() to the function .init.text:_setup_iclk_autoidle() The function _setup() references the function __init _setup_iclk_autoidle(). This is often because _setup lacks a __init annotation or the annotation of _setup_iclk_autoidle is wrong. WARNING: vmlinux.o(.text+0x2d3a0): Section mismatch in reference from the function _setup() to the function .init.text:_setup_reset() The function _setup() references the function __init _setup_reset(). This is often because _setup lacks a __init annotation or the annotation of _setup_reset is wrong. WARNING: vmlinux.o(.text+0x2d408): Section mismatch in reference from the function _setup() to the function .init.text:_setup_postsetup() The function _setup() references the function __init _setup_postsetup(). This is often because _setup lacks a __init annotation or the annotation of _setup_postsetup is wrong. _setup is used in omap_hwmod_allocate_module, which isn't marked __init and looks like it shouldn't be, meaning to fix these warnings, those functions must be moved out of the init section, which this patch does. Signed-off-by: Nathan Chancellor Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 71edc80ef344b85ca928ef9721744bed456bb12b Author: Damian Kos Date: Tue Nov 6 15:37:05 2018 +0000 drm/rockchip: fix for mailbox read size [ Upstream commit fa68d4f8476bea4cdf441062b614b41bb85ef1da ] Some of the functions (like cdn_dp_dpcd_read, cdn_dp_get_edid_block) allow to read 64KiB, but the cdn_dp_mailbox_read_receive, that is used by them, can read only up to 255 bytes at once. Normally, it's not a big issue as DPCD or EDID reads won't (hopefully) exceed that value. The real issue here is the revocation list read during the HDCP authentication process. (problematic use case: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/cdn-dp-reg.c#1152) The list can reach 127*5+4 bytes (num devs * 5 bytes per ID/Bksv + 4 bytes of an additional info). In other words - CTSes with HDCP Repeater won't pass without this fix. Oh, and the driver will most likely stop working (best case scenario). Signed-off-by: Damian Kos Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/1541518625-25984-1-git-send-email-dkos@cadence.com Signed-off-by: Sasha Levin commit 1ee5c23eb5b7bb3ac8a6848e91265a294a811246 Author: Ben Dooks Date: Wed Nov 14 11:50:19 2018 +0000 usbnet: smsc95xx: fix rx packet alignment [ Upstream commit 810eeb1f41a9a272eedc94ca18c072e75678ede4 ] The smsc95xx driver already takes into account the NET_IP_ALIGN parameter when setting up the receive packet data, which means we do not need to worry about aligning the packets in the usbnet driver. Adding the EVENT_NO_IP_ALIGN means that the IPv4 header is now passed to the ip_rcv() routine with the start on an aligned address. Tested on Raspberry Pi B3. Signed-off-by: Ben Dooks Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8252a95415bbf2fc5b309ab4052d99989b9b1aae Author: Renato Lui Geh Date: Mon Nov 5 17:14:58 2018 -0200 staging: iio: ad7780: update voltage on read [ Upstream commit 336650c785b62c3bea7c8cf6061c933a90241f67 ] The ad7780 driver previously did not read the correct device output, as it read an outdated value set at initialization. It now updates its voltage on read. Signed-off-by: Renato Lui Geh Acked-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fe4cbb38a02e3a05edaf6abe852d8e92a9759655 Author: Xiang Chen Date: Fri Nov 9 22:06:36 2018 +0800 scsi: hisi_sas: change the time of SAS SSP connection [ Upstream commit 15bc43f31a074076f114e0b87931e3b220b7bff1 ] Currently the time of SAS SSP connection is 1ms, which means the link connection will fail if no IO response after this period. For some disks handling large IO (such as 512k), 1ms is not enough, so change it to 5ms. Signed-off-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 33210638a64b732ee52602c932b9b57ca884f1ca Author: Alan Brady Date: Mon Oct 29 11:27:21 2018 -0700 i40e: prevent overlapping tx_timeout recover [ Upstream commit d5585b7b6846a6d0f9517afe57be3843150719da ] If a TX hang occurs, we attempt to recover by incrementally resetting. If we're starved for CPU time, it's possible the reset doesn't actually complete (or even fire) before another tx_timeout fires causing us to fly through the different resets without actually doing them. This adds a bit to set and check if a timeout recovery is already pending and, if so, bail out of tx_timeout. The bit will get cleared at the end of i40e_rebuild when reset is complete. Signed-off-by: Alan Brady Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 3fe0bb2c7a86e9664129eced61a101fa2969107a Author: Mitch Williams Date: Fri Oct 26 14:33:33 2018 -0700 i40e: suppress bogus error message [ Upstream commit 7cd8eb0861981ad212ce4242a1870c4b5831ceff ] The i40e driver complains about unprivileged VFs trying to configure promiscuous mode each time a VF reset occurs. This isn't the fault of the poor VF driver - the PF driver itself is making the request. To fix this, skip the privilege check if the request is to disable all promiscuous activity. This gets rid of the bogus message, but doesn't affect privilege checks, since we really only care if the unprivileged VF is trying to enable promiscuous mode. Signed-off-by: Mitch Williams Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 4a9260a92daccf0d483c14b0fbdd26993035a43b Author: Brian Norris Date: Wed Nov 7 18:49:39 2018 -0800 platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup [ Upstream commit 6ad16b78a039b45294b1ad5d69c14ac57b2fe706 ] EC_MKBP_EVENT_SENSOR_FIFO events can be triggered for a variety of reasons, and there are very few cases in which they should be treated as wakeup interrupts (particularly, when a certain MOTIONSENSE_MODULE_FLAG_* is set, but this is not even supported in the mainline cros_ec_sensor driver yet). Most of the time, they are benign sensor readings. In any case, the top-level cros_ec device doesn't know enough to determine that they should wake the system, and so it should not report the event. This would be the job of the cros_ec_sensors driver to parse. This patch adds checks to cros_ec_get_next_event() such that it doesn't signal 'wakeup' for events of type EC_MKBP_EVENT_SENSOR_FIFO. This patch is particularly relevant on devices like Scarlet (Rockchip RK3399 tablet, known as Acer Chromebook Tab 10), where the EC firmware reports sensor events much more frequently. This was causing /sys/power/wakeup_count to increase very frequently, often needlessly interrupting our ability to suspend the system. Signed-off-by: Brian Norris Signed-off-by: Benson Leung Signed-off-by: Sasha Levin commit 42d12097870deaa6e3c8091eaee36001fd24a025 Author: Arnd Bergmann Date: Fri Nov 2 16:38:53 2018 +0100 vbox: fix link error with 'gcc -Og' [ Upstream commit b8ae30a7020d61e0504529adf45abb08fa5c59f5 ] With the new CONFIG_CC_OPTIMIZE_FOR_DEBUGGING option, we get a link error in the vboxguest driver, when that fails to optimize out the call to the compat handler: drivers/virt/vboxguest/vboxguest_core.o: In function `vbg_ioctl_hgcm_call': vboxguest_core.c:(.text+0x1f6e): undefined reference to `vbg_hgcm_call32' Another compile-time check documents better what we want and avoids the error. Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Arnd Bergmann Reviewed-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8c5d16583a2a5062113f9ae132449391c1b99314 Author: Anatolij Gustschin Date: Wed Nov 7 11:51:45 2018 -0600 fpga: altera-cvp: fix 'bad IO access' on x86_64 [ Upstream commit 187fade88ca0ff2df9d360ca751d948d73db7095 ] If mapping the CvP BAR fails, we still can configure the FPGA via PCI config space access. In this case the iomap pointer is NULL. On x86_64, passing NULL address to pci_iounmap() generates "Bad IO access at port 0x0" output with stack call trace. Fix it. Signed-off-by: Anatolij Gustschin Acked-by: Alan Tull Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5fe8572ca379d4f1be797434d2242e847c8afd9c Author: Dexuan Cui Date: Thu Oct 18 05:09:32 2018 +0000 Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1 [ Upstream commit 4fcba7802c3e15a6e56e255871d6c72f829b9dd8 ] The patch fixes: hv_kvp_daemon.c: In function 'kvp_set_ip_info': hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes into a destination of size 4096 The "(unsigned int)str_len" is to avoid: hv_kvp_daemon.c:1309:30: warning: comparison of integer expressions of different signedness: 'int' and 'long unsigned int' [-Wsign-compare] Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4af6d2112191271aacf0c742dedceb6bb7a46df8 Author: Andreas Puhm Date: Wed Nov 7 11:51:47 2018 -0600 fpga: altera-cvp: Fix registration for CvP incapable devices [ Upstream commit 68f60538daa4bc3da5d0764d46f391916fba20fd ] The probe function needs to verify the CvP enable bit in order to properly determine if FPGA Manager functionality can be safely enabled. Fixes: 34d1dc17ce97 ("fpga manager: Add Altera CvP driver") Signed-off-by: Andreas Puhm Signed-off-by: Anatolij Gustschin Reviewed-by: Moritz Fischer Acked-by: Alan Tull Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4b923eb49cf8e15616861b488a37938c34abb24c Author: Matheus Tavares Date: Sat Nov 3 19:49:44 2018 -0300 staging:iio:ad2s90: Make probe handle spi_setup failure [ Upstream commit b3a3eafeef769c6982e15f83631dcbf8d1794efb ] Previously, ad2s90_probe ignored the return code from spi_setup, not handling its possible failure. This patch makes ad2s90_probe check if the code is an error code and, if so, do the following: - Call dev_err with an appropriate error message. - Return the spi_setup's error code. Note: The 'return ret' statement could be out of the 'if' block, but this whole block will be moved up in the function in the patch: 'staging:iio:ad2s90: Move device registration to the end of probe'. Signed-off-by: Matheus Tavares Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 218bbbd770978fb48b906e237c0477184d762b1d Author: Naftali Goldstein Date: Sun Jul 15 15:26:27 2018 +0300 iwlwifi: fw: do not set sgi bits for HE connection [ Upstream commit 5c2dbebb446539eb9640bf59a02756d6e7f1fc53 ] If the association supports HE, HT/VHT rates will never be used for Tx and therefore there's no need to set the sgi-per-channel-width-support bits, so don't set them in this case. Fixes: 110b32f065f3 ("iwlwifi: mvm: rs: add basic implementation of the new RS API handlers") Signed-off-by: Naftali Goldstein Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 15b4e9e2869b71893cf5ae346e776b2c2b0248f9 Author: Ioana Ciornei Date: Fri Nov 9 15:26:46 2018 +0000 dpaa2-ptp: defer probe when portal allocation failed [ Upstream commit 5500598abbfb5b46201b9768bd9ea873a5eeaece ] The fsl_mc_portal_allocate can fail when the requested MC portals are not yet probed by the fsl_mc_allocator. In this situation, the driver should defer the probe. Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c6981ee92ac33191dfac57ce44e2dffbb318503f Author: Paul Burton Date: Sat Nov 10 00:12:06 2018 +0000 MIPS: Boston: Disable EG20T prefetch [ Upstream commit 5ec17af7ead09701e23d2065e16db6ce4e137289 ] The Intel EG20T Platform Controller Hub used on the MIPS Boston development board supports prefetching memory to optimize DMA transfers. Unfortunately for unknown reasons this doesn't work well with some MIPS CPUs such as the P6600, particularly when using an I/O Coherence Unit (IOCU) to provide cache-coherent DMA. In these systems it is common for DMA data to be lost, resulting in broken access to EG20T devices such as the MMC or SATA controllers. Support for a DT property to configure the prefetching was added a while back by commit 549ce8f134bd ("misc: pch_phub: Read prefetch value from device tree if passed") but we never added the DT snippet to make use of it. Add that now in order to disable the prefetching & fix DMA on the affected systems. Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/21068/ Cc: linux-mips@linux-mips.org Signed-off-by: Sasha Levin commit c178a35320da597a9a8cc1fc6647992e8ac3f3f0 Author: Miroslav Lichvar Date: Fri Nov 9 11:14:43 2018 +0100 ptp: check gettime64 return code in PTP_SYS_OFFSET ioctl [ Upstream commit 83d0bdc7390b890905634186baaa294475cd6a06 ] If a gettime64 call fails, return the error and avoid copying data back to user. Cc: Richard Cochran Cc: Jacob Keller Signed-off-by: Miroslav Lichvar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ebd79de192358a79fee8e6972ba0a0c6c5e410d1 Author: Andy Duan Date: Tue Oct 16 07:32:22 2018 +0000 serial: fsl_lpuart: clear parity enable bit when disable parity [ Upstream commit 397bd9211fe014b347ca8f95a8f4e1017bac1aeb ] Current driver only enable parity enable bit and never clear it when user set the termios. The fix clear the parity enable bit when PARENB flag is not set in termios->c_cflag. Cc: Lukas Wunner Signed-off-by: Andy Duan Reviewed-by: Fabio Estevam Acked-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 71cd745a9adbe46d2c3f4c684bd5bf7f47f3d327 Author: Boris Brezillon Date: Fri Nov 9 11:26:32 2018 +0100 drm/vc4: ->x_scaling[1] should never be set to VC4_SCALING_NONE [ Upstream commit 0560054da5673b25d56bea6c57c8d069673af73b ] For the YUV conversion to work properly, ->x_scaling[1] should never be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE into VC4_SCALING_PPF when that happens. The old ->x_scaling[0] adjustment is dropped as I couldn't find any mention to this constraint in the spec and it's proven to be unnecessary (I tested various multi-planar YUV formats with scaling disabled, and all of them worked fine without this adjustment). Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Boris Brezillon Reviewed-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-1-boris.brezillon@bootlin.com Signed-off-by: Sasha Levin commit 355f5af996189db4351a2f76238f5efa5a610287 Author: Eric Biggers Date: Wed Oct 17 21:37:58 2018 -0700 crypto: aes_ti - disable interrupts while accessing S-box [ Upstream commit 0a6a40c2a8c184a2fb467efacfb1cd338d719e0b ] In the "aes-fixed-time" AES implementation, disable interrupts while accessing the S-box, in order to make cache-timing attacks more difficult. Previously it was possible for the CPU to be interrupted while the S-box was loaded into L1 cache, potentially evicting the cachelines and causing later table lookups to be time-variant. In tests I did on x86 and ARM, this doesn't affect performance significantly. Responsiveness is potentially a concern, but interrupts are only disabled for a single AES block. Note that even after this change, the implementation still isn't necessarily guaranteed to be constant-time; see https://cr.yp.to/antiforgery/cachetiming-20050414.pdf for a discussion of the many difficulties involved in writing truly constant-time AES software. But it's valuable to make such attacks more difficult. Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 25ad9c5e62faa816313026811b8dd28df5b3dae2 Author: Julian Wiedmann Date: Thu Nov 8 15:06:15 2018 +0100 s390/qeth: utilize virtual MAC for Layer2 OSD devices [ Upstream commit b144b99fff69a5bc0d34c8e168bedb88c68ca23d ] By default, READ MAC on a Layer2 OSD device returns the adapter's burnt-in MAC address. Given the default scenario of many virtual devices on the same adapter, qeth can't make any use of this address and therefore skips the READ MAC call for this device type. But in some configurations, the READ MAC command for a Layer2 OSD device actually returns a pre-provisioned, virtual MAC address. So enable the READ MAC code to detect this situation, and let the L2 subdriver call READ MAC for OSD devices. This also removes the QETH_LAYER2_MAC_READ flag, which protects L2 devices against calling READ MAC multiple times. Instead protect the whole call to qeth_l2_request_initial_mac(). Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cb4e74c18939f9af4251edb8579699cdc92c2d6c Author: David Ahern Date: Thu Nov 8 13:00:07 2018 -0800 bpftool: Improve handling of ENOENT on map dumps [ Upstream commit bf598a8f0f771302d4ecb0ef0003c54732221597 ] bpftool output is not user friendly when dumping a map with only a few populated entries: $ bpftool map 1: devmap name tx_devmap flags 0x0 key 4B value 4B max_entries 64 memlock 4096B 2: array name tx_idxmap flags 0x0 key 4B value 4B max_entries 64 memlock 4096B $ bpftool map dump id 1 key: 00 00 00 00 value: No such file or directory key: 01 00 00 00 value: No such file or directory key: 02 00 00 00 value: No such file or directory key: 03 00 00 00 value: 03 00 00 00 Handle ENOENT by keeping the line format sane and dumping "" for the value $ bpftool map dump id 1 key: 00 00 00 00 value: key: 01 00 00 00 value: key: 02 00 00 00 value: key: 03 00 00 00 value: 03 00 00 00 ... Signed-off-by: David Ahern Acked-by: Jakub Kicinski Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 38e643a541b56a1fb84aa14ba3c0a512c98ee6a2 Author: Frank Rowand Date: Thu Oct 4 20:27:16 2018 -0700 powerpc/pseries: add of_node_put() in dlpar_detach_node() [ Upstream commit 5b3f5c408d8cc59b87e47f1ab9803dbd006e4a91 ] The previous commit, "of: overlay: add missing of_node_get() in __of_attach_node_sysfs" added a missing of_node_get() to __of_attach_node_sysfs(). This results in a refcount imbalance for nodes attached with dlpar_attach_node(). The calling sequence from dlpar_attach_node() to __of_attach_node_sysfs() is: dlpar_attach_node() of_attach_node() __of_attach_node_sysfs() For more detailed description of the node refcount, see commit 68baf692c435 ("powerpc/pseries: Fix of_node_put() underflow during DLPAR remove"). Tested-by: Alan Tull Acked-by: Michael Ellerman Signed-off-by: Frank Rowand Signed-off-by: Sasha Levin commit 562139027c8c50d96495d66a26c263799af2eb24 Author: Colin Ian King Date: Thu Oct 25 14:52:31 2018 +0100 x86/PCI: Fix Broadcom CNB20LE unintended sign extension (redux) [ Upstream commit 53bb565fc5439f2c8c57a786feea5946804aa3e9 ] In the expression "word1 << 16", word1 starts as u16, but is promoted to a signed int, then sign-extended to resource_size_t, which is probably not what was intended. Cast to resource_size_t to avoid the sign extension. This fixes an identical issue as fixed by commit 0b2d70764bb3 ("x86/PCI: Fix Broadcom CNB20LE unintended sign extension") back in 2014. Detected by CoverityScan, CID#138749, 138750 ("Unintended sign extension") Fixes: 3f6ea84a3035 ("PCI: read memory ranges out of Broadcom CNB20LE host bridge") Signed-off-by: Colin Ian King Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 118a9d3625ab638a0dfd971d86ab201ec0fed8e0 Author: Bob Peterson Date: Thu Nov 8 14:04:50 2018 -0500 dlm: Don't swamp the CPU with callbacks queued during recovery [ Upstream commit 216f0efd19b9cc32207934fd1b87a45f2c4c593e ] Before this patch, recovery would cause all callbacks to be delayed, put on a queue, and afterward they were all queued to the callback work queue. This patch does the same thing, but occasionally takes a break after 25 of them so it won't swamp the CPU at the expense of other RT processes like corosync. Signed-off-by: Bob Peterson Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit ce770ebfaf72fd31609a8cd38ef29dde62d4c26d Author: Yi Wang Date: Wed Oct 31 15:41:41 2018 +0800 clk: boston: fix possible memory leak in clk_boston_setup() [ Upstream commit 46fda5b5067a391912cf73bf3d32c26b6a22ad09 ] Smatch report warnings: drivers/clk/imgtec/clk-boston.c:76 clk_boston_setup() warn: possible memory leak of 'onecell' drivers/clk/imgtec/clk-boston.c:83 clk_boston_setup() warn: possible memory leak of 'onecell' drivers/clk/imgtec/clk-boston.c:90 clk_boston_setup() warn: possible memory leak of 'onecell' 'onecell' is malloced in clk_boston_setup(), but not be freed before leaving from the error handling cases. Signed-off-by: Yi Wang Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit e33590dc8a83cf3ae40403a3f69b5c4c8f77dba6 Author: Yufen Wang Date: Fri Nov 2 11:51:31 2018 +0100 ARM: 8808/1: kexec:offline panic_smp_self_stop CPU [ Upstream commit 82c08c3e7f171aa7f579b231d0abbc1d62e91974 ] In case panic() and panic() called at the same time on different CPUS. For example: CPU 0: panic() __crash_kexec machine_crash_shutdown crash_smp_send_stop machine_kexec BUG_ON(num_online_cpus() > 1); CPU 1: panic() local_irq_disable panic_smp_self_stop If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump fails. CPU1 can't receive the ipi irq, CPU1 will be always online. To fix this problem, this patch split out the panic_smp_self_stop() and add set_cpu_online(smp_processor_id(), false). Signed-off-by: Yufen Wang Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 8f36e264f7a960a041d32d523511f7b91419dc72 Author: James Smart Date: Tue Oct 23 13:41:03 2018 -0700 scsi: lpfc: Fix LOGO/PLOGI handling when triggerd by ABTS Timeout event [ Upstream commit 30e196cacefdd9a38c857caed23cefc9621bc5c1 ] After a LOGO in response to an ABTS timeout, a PLOGI wasn't issued to re-establish the login. An nlp_type check in the LOGO completion handler failed to restart discovery for NVME targets. Revised the nlp_type check for NVME as well as SCSI. While reviewing the LOGO handling a few other issues were seen and were addressed: - Better lock synchronization around ndlp data types - When the ABTS times out, unregister the RPI before sending the LOGO so that all local exchange contexts are cleared and nothing received while awaiting LOGO/PLOGI handling will be accepted. - LOGO handling optimized to: Wait only R_A_TOV for a response. It doesn't need to be retried on timeout. If there wasn't a response, a PLOGI will be sent, thus an implicit logout applies as well when the other port sees it. If there is a response, any kind of response is considered "good" and the XRI quarantined for a exchange qualifier window. - PLOGI is issued as soon a LOGO state is resolved. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit afa44e049fa3fa10b4ec99e56f8c5229306ba03f Author: Suganath Prabu Date: Wed Oct 31 18:53:35 2018 +0530 scsi: mpt3sas: Call sas_remove_host before removing the target devices [ Upstream commit dc730212e8a378763cb182b889f90c8101331332 ] Call sas_remove_host() before removing the target devices in the driver's .remove() callback function(i.e. during driver unload time). So that driver can provide a way to allow SYNC CACHE, START STOP unit commands etc. (which are issued from SML) to the target drives during driver unload time. Once sas_remove_host() is called before removing the target drives then driver can just clean up the resources allocated for target devices and no need to call sas_port_delete_phy(), sas_port_delete() API's as these API's internally called from sas_remove_host(). Signed-off-by: Suganath Prabu Reviewed-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 42a16a31d1ec69051e156c9561be8ac7ce2f2742 Author: James Smart Date: Tue Oct 23 13:41:07 2018 -0700 scsi: lpfc: Correct LCB RJT handling [ Upstream commit b114d9009d386276bfc3352289fc235781ae3353 ] When LCB's are rejected, if beaconing was already in progress, the Reason Code Explanation was not being set. Should have been set to command in progress. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 13fb29fd2b7145b4674b36d67da261d2f2f209c3 Author: Lorenzo Bianconi Date: Fri Nov 2 21:49:55 2018 +0100 ath9k: dynack: use authentication messages for 'late' ack [ Upstream commit 3831a2a0010c72e3956020cbf1057a1701a2e469 ] In order to properly support dynack in ad-hoc mode running wpa_supplicant, take into account authentication frames for 'late ack' detection. This patch has been tested on devices mounted on offshore high-voltage stations connected through ~24Km link Reported-by: Koen Vandeputte Tested-by: Koen Vandeputte Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit a055693f05f5aee1406e42e0a4c9fb0534b2ab29 Author: Brian Norris Date: Fri Nov 2 10:17:47 2018 -0700 ath10k: assign 'n_cipher_suites' for WCN3990 [ Upstream commit 2bd345cd2bfc0bd44528896313c0b45f087bdf67 ] Commit 2ea9f12cefe4 ("ath10k: add new cipher suite support") added a new n_cipher_suites HW param with a fallback value and a warning log. Commit 03a72288c546 ("ath10k: wmi: add hw params entry for wcn3990") later added WCN3990 HW entries, but it missed the n_cipher_suites. Rather than seeing this warning every boot ath10k_snoc 18800000.wifi: invalid hw_params.n_cipher_suites 0 let's provide the appropriate value. Cc: Rakesh Pillai Cc: Govind Singh Signed-off-by: Brian Norris Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 112aac1653688c07d1a6ed29c92e2fa6627442e2 Author: Lior David Date: Wed Oct 31 10:52:14 2018 +0200 wil6210: fix memory leak in wil_find_tx_bcast_2 [ Upstream commit 664497400c89a4d40aee51bcf48bbd2e4dc71104 ] A successful call to wil_tx_ring takes skb reference so it will only be freed in wil_tx_complete. Consume the skb in wil_find_tx_bcast_2 to prevent memory leak. Signed-off-by: Lior David Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9dc29400d82139fa7ec5636b1bd375693bec522f Author: Alexei Avshalom Lazar Date: Wed Oct 31 10:52:10 2018 +0200 wil6210: fix reset flow for Talyn-mb [ Upstream commit d083b2e2b7db5cca1791643d036e6597af27f49b ] With current reset flow, Talyn sometimes get stuck causing PCIe enumeration to fail. Fix this by removing some reset flow operations that are not relevant for Talyn. Setting bit 15 in RGF_HP_CTRL is WBE specific and is not in use for all wil6210 devices. For Sparrow, BIT_HPAL_PERST_FROM_PAD and BIT_CAR_PERST_RST were set as a WA an HW issue. Signed-off-by: Alexei Avshalom Lazar Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 35005791fd3b6671213549692cdf6881af383245 Author: Nickhu Date: Thu Oct 18 16:37:55 2018 +0800 nds32: Fix gcc 8.0 compiler option incompatible. [ Upstream commit 4c3d6174e0e17599549f636ec48ddf78627a17fe ] When the kernel configs of ftrace and frame pointer options are choosed, the compiler option of kernel will incompatible. Error message: nds32le-linux-gcc: error: -pg and -fomit-frame-pointer are incompatible Signed-off-by: Nickhu Signed-off-by: Zong Li Acked-by: Greentime Hu Signed-off-by: Greentime Hu Signed-off-by: Sasha Levin commit d972ff1f7031e2f361edf119292074124e4f65d1 Author: Bhawanpreet Lakha Date: Tue Oct 9 13:47:34 2018 -0400 drm/amd/display: Fix potential nullptr error [ Upstream commit 4f7129112c2a30331f3045a42026fad82e6cb72b ] [Why] Fix surface/plane potential nullptr [How] add null check Signed-off-by: Bhawanpreet Lakha Reviewed-by: Aric Cyr Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6d395f0c7ff89981a349e7f3fc971547baca34d4 Author: Steve Longerbeam Date: Wed Sep 19 16:07:18 2018 -0700 gpu: ipu-v3: image-convert: Prevent race between run and unprepare [ Upstream commit 819bec35c8c9706185498c9222bd244e0781ad35 ] Prevent possible race by parallel threads between ipu_image_convert_run() and ipu_image_convert_unprepare(). This involves setting ctx->aborting to true unconditionally so that no new job runs can be queued during unprepare, and holding the ctx->aborting flag until the context is freed. Note that the "normal" ipu_image_convert_abort() case (e.g. not during context unprepare) should clear the ctx->aborting flag after aborting any active run and clearing the context's pending queue. This is because it should be possible to continue to use the conversion context and queue more runs after an abort. Signed-off-by: Steve Longerbeam Tested-by: Philipp Zabel Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 6dd7618d7dead7b4f369d3e24e80232b8eb676c3 Author: Long Li Date: Fri Nov 2 18:02:48 2018 +0000 genirq/affinity: Spread IRQs to all available NUMA nodes [ Upstream commit b82592199032bf7c778f861b936287e37ebc9f62 ] If the number of NUMA nodes exceeds the number of MSI/MSI-X interrupts which are allocated for a device, the interrupt affinity spreading code fails to spread them across all nodes. The reason is, that the spreading code starts from node 0 and continues up to the number of interrupts requested for allocation. This leaves the nodes past the last interrupt unused. This results in interrupt concentration on the first nodes which violates the assumption of the block layer that all nodes are covered evenly. As a consequence the NUMA nodes above the number of interrupts are all assigned to hardware queue 0 and therefore NUMA node 0, which results in bad performance and has CPU hotplug implications, because queue 0 gets shut down when the last CPU of node 0 is offlined. Go over all NUMA nodes and assign them round-robin to all requested interrupts to solve this. [ tglx: Massaged changelog ] Signed-off-by: Long Li Signed-off-by: Thomas Gleixner Reviewed-by: Ming Lei Cc: Michael Kelley Link: https://lkml.kernel.org/r/20181102180248.13583-1-longli@linuxonhyperv.com Signed-off-by: Sasha Levin commit 174f97e48bb0cbe90edc8b1b60201166a658a6b6 Author: Dan Carpenter Date: Thu Oct 18 10:36:19 2018 +0300 ath10k: fixup extended per sta tx statistics [ Upstream commit 539b44e70c5b4ad82d2c0c97a4dfb37523d891f6 ] I had a couple concerns with this code. First, we definitely need to set the error code if the kzalloc() fails. Secondly, I was worried that if we didn't set "arsta->tx_stats" to NULL after freeing it, then it looks to me like it might lead to a use after free. I can't test that, but it's harmless to set it to NULL so I did. Fixes: a904417fc876 ("ath10k: add extended per sta tx statistics support") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit b1dd4acecb74455d0ee73ae54ebe604838c73695 Author: Jernej Skrabec Date: Sun Nov 4 19:27:00 2018 +0100 drm/sun4i: Initialize registers in tcon-top driver [ Upstream commit c96d62215fb540e2ae61de44cb7caf4db50958e3 ] It turns out that TCON TOP registers in H6 SoC have non-zero reset value. This may cause issues if bits are not changed during configuration. To prevent that, initialize registers to 0. Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20181104182705.18047-24-jernej.skrabec@siol.net Signed-off-by: Sasha Levin commit 4672971c827e043c0d0b3ffc955309370487621f Author: Muchun Song Date: Thu Nov 1 21:12:50 2018 +0800 gpiolib: Fix possible use after free on label [ Upstream commit 18534df419041e6c1f4b41af56ee7d41f757815c ] gpiod_request_commit() copies the pointer to the label passed as an argument only to be used later. But there's a chance the caller could immediately free the passed string(e.g., local variable). This could trigger a use after free when we use gpio label(e.g., gpiochip_unlock_as_irq(), gpiochip_is_requested()). To be on the safe side: duplicate the string with kstrdup_const() so that if an unaware user passes an address to a stack-allocated buffer, we won't get the arbitrary label. Also fix gpiod_set_consumer_name(). Signed-off-by: Muchun Song Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 83e25ef2b847796f8e1d0ec1d2a7cd3f3ba7285d Author: Arnd Bergmann Date: Sat Nov 3 22:21:22 2018 +0100 ASoC: Intel: mrfld: fix uninitialized variable access [ Upstream commit 1539c7f23f256120f89f8b9ec53160790bce9ed2 ] Randconfig testing revealed a very old bug, with gcc-8: sound/soc/intel/atom/sst/sst_loader.c: In function 'sst_load_fw': sound/soc/intel/atom/sst/sst_loader.c:357:5: error: 'fw' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (fw == NULL) { ^ sound/soc/intel/atom/sst/sst_loader.c:354:25: note: 'fw' was declared here const struct firmware *fw; We must check the return code of request_firmware() before we look at the pointer result that may be uninitialized when the function fails. Fixes: 9012c9544eea ("ASoC: Intel: mrfld - Add DSP load and management") Signed-off-by: Arnd Bergmann Acked-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 815b3768681f77593ae3fc6f2a3e333a04645210 Author: Jernej Skrabec Date: Sun Nov 4 19:26:41 2018 +0100 clk: sunxi-ng: h6: Set video PLLs limits [ Upstream commit ed4433419d45bf8b58aef34c4450a27e1c8699e8 ] Video PLL factors can be set in a way that final PLL rate is outside stable range. H6 user manual specifically says that N factor should not be below 12. While it doesn't says anything about maximum stable rate, it is clear that PLL doesn't work at 6.096 GHz (254 * 24 MHz). Set minimum allowed PLL video rate to 288 MHz (12 * 24 MHz) and maximum to 2.4 GHz, which is maximum in BSP driver. Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 0dcf13d9aef89c1cdf0af16e6d4c823d917fd0c5 Author: Lukas Wunner Date: Sat Oct 27 10:15:33 2018 +0200 pinctrl: bcm2835: Use raw spinlock for RT compatibility [ Upstream commit 3c7b30f704b6f5e53eed6bf89cf2c8d1b38b02c0 ] The BCM2835 pinctrl driver acquires a spinlock in its ->irq_enable, ->irq_disable and ->irq_set_type callbacks. Spinlocks become sleeping locks with CONFIG_PREEMPT_RT_FULL=y, therefore invocation of one of the callbacks in atomic context may cause a hard lockup if at least two GPIO pins in the same bank are used as interrupts. The issue doesn't occur with just a single interrupt pin per bank because the lock is never contended. I'm experiencing such lockups with GPIO 8 and 28 used as level-triggered interrupts, i.e. with ->irq_disable being invoked on reception of every IRQ. The critical section protected by the spinlock is very small (one bitop and one RMW of an MMIO register), hence converting to a raw spinlock seems a better trade-off than converting the driver to threaded IRQ handling (which would increase latency to handle an interrupt). Cc: Mathias Duckeck Signed-off-by: Lukas Wunner Acked-by: Julia Cartwright Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2935471affe2cd5a160d3ab9e6598c5a6252e7ac Author: Deepak Sharma Date: Tue Oct 23 17:35:48 2018 +0100 drm/vgem: Fix vgem_init to get drm device available. [ Upstream commit d5c04dff24870ef07ce6453a3f4e1ffd9cf88d27 ] Modify vgem_init to take platform dev as parent in drm_dev_init. This will make drm device available at "/sys/devices/platform/vgem" in x86 chromebook. v2: rebase, address checkpatch typo and line over 80 characters Cc: Daniel Vetter Signed-off-by: Deepak Sharma Reviewed-by: Sean Paul Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181023163550.15211-1-emil.l.velikov@gmail.com Signed-off-by: Sasha Levin commit 791caa38f125251aa2cacd934771ac0471a46a11 Author: Slawomir Stepien Date: Sat Oct 20 23:04:11 2018 +0200 staging: iio: adc: ad7280a: handle error from __ad7280_read32() [ Upstream commit 0559ef7fde67bc6c83c6eb6329dbd6649528263e ] Inside __ad7280_read32(), the spi_sync_transfer() can fail with negative error code. This change will ensure that this error is being passed up in the call stack, so it can be handled. Signed-off-by: Slawomir Stepien Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit de6a6f5151c8d7f2ee7e27ce632f4fe842097ff7 Author: Eric Anholt Date: Fri Sep 28 16:21:23 2018 -0700 drm/v3d: Fix a use-after-free race accessing the scheduler's fences. [ Upstream commit 34c2c4f632f232ed2fdb66d4e42cc72d322273fe ] Once we push the job, the scheduler could run it and free it. So, if we want to reference their fences, we need to grab them before then. I haven't seen this happen in many days of conformance test runtime, but let's still close the race. Signed-off-by: Eric Anholt Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Link: https://patchwork.freedesktop.org/patch/254119/ Reviewed-by: Boris Brezillon Signed-off-by: Sasha Levin commit bf7ac708dd1b0f9bb84fc428338b03d1560bdd2f Author: Gustavo A. R. Silva Date: Tue Oct 16 11:55:49 2018 +0200 drm/bufs: Fix Spectre v1 vulnerability [ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ] idx can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential spectre issue 'dma->buflist' [r] (local cap) Fix this by sanitizing idx before using it to index dma->buflist Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embeddedor.com Signed-off-by: Sasha Levin