- 31 May, 2019 40 commits
-
-
Nicolas Ferre authored
[ Upstream commit e2c114c0 ] Even if this case shouldn't happen when controller is properly programmed, it's still better to avoid dumping a kernel Oops for this. As the sequence may happen only for debugging purposes, log the error and just finish the tasklet call. Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Robin Murphy authored
[ Upstream commit 0d2e2a82 ] Uncore PMU drivers face an awkward cyclic dependency wherein: - They have to pick a valid online CPU to associate with before registering the PMU device, since it will get exposed to userspace immediately. - The PMU registration has to be be at least partly complete before hotplug events can be handled, since trying to migrate an uninitialised context would be bad. - The hotplug handler has to be ready as soon as a CPU is chosen, lest it go offline without the user-visible cpumask value getting updated. The arm-cci driver has tried to solve this by using get_cpu() to pick the current CPU and prevent it from disappearing while both registrations are performed, but that results in taking mutexes with preemption disabled, which makes certain configurations very unhappy: [ 1.983337] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:2004 [ 1.983340] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0 [ 1.983342] Preemption disabled at: [ 1.983353] [<ffffff80089801f4>] cci_pmu_probe+0x1dc/0x488 [ 1.983360] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.20-rt8-yocto-preempt-rt #1 [ 1.983362] Hardware name: ZynqMP ZCU102 Rev1.0 (DT) [ 1.983364] Call trace: [ 1.983369] dump_backtrace+0x0/0x158 [ 1.983372] show_stack+0x24/0x30 [ 1.983378] dump_stack+0x80/0xa4 [ 1.983383] ___might_sleep+0x138/0x160 [ 1.983386] __might_sleep+0x58/0x90 [ 1.983391] __rt_mutex_lock_state+0x30/0xc0 [ 1.983395] _mutex_lock+0x24/0x30 [ 1.983400] perf_pmu_register+0x2c/0x388 [ 1.983404] cci_pmu_probe+0x2bc/0x488 [ 1.983409] platform_drv_probe+0x58/0xa8 It is not feasible to resolve all the possible races outside of the perf core itself, so address the immediate bug by following the example of nearly every other PMU driver and not even trying to do so. Registering the hotplug notifier first should minimise the window in which things can go wrong, so that's about as much as we can reasonably do here. This also revealed an additional race in assigning the global pointer too late relative to the hotplug notifier, which gets fixed in the process. Reported-by:
Li, Meng <Meng.Li@windriver.com> Tested-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Reviewed-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit f4033db5 ] This is mostly a revert of commit 55bb6a63 ("clk: rockchip: mark noc and some special clk as critical on rk3288") except that we're keeping "pmu_hclk_otg0" as critical still. NOTE: turning these clocks off doesn't seem to do a whole lot in terms of power savings (checking the power on the logic rail). It appears to save maybe 1-2mW. ...but still it seems like we should turn the clocks off if they aren't needed. About "pmu_hclk_otg0" (the one clock from the original commit we're still keeping critical) from an email thread: > pmu ahb clock > > Function: Clock to pmu module when hibernation and/or ADP is > enabled. Must be greater than or equal to 30 MHz. > > If the SOC design does not support hibernation/ADP function, only have > hclk_otg, this clk can be switched according to the usage of otg. > If the SOC design support hibernation/ADP, has two clocks, hclk_otg and > pmu_hclk_otg0. > Hclk_otg belongs to the closed part of otg logic, which can be switched > according to the use of otg. > > pmu_hclk_otg0 belongs to the always on part. > > As for whether pmu_hclk_otg0 can be turned off when otg is not in use, > we have not tested. IC suggest make pmu_hclk_otg0 always on. For the rest of the clocks: atclk: No documentation about this clock other than that it goes to the CPU. CPU functions fine without it on. Maybe needed for JTAG? jtag: Presumably this clock is only needed if you're debugging with JTAG. It doesn't seem like it makes sense to waste power for every rk3288 user. In any case to do JTAG you'd need private patches to adjust the pinctrl the mux the JTAG out anyway. pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two clocks on only during kernel panics in order to access some coresight registers. Since nothing in the upstream kernel does this we should be able to leave them off safely. Maybe also needed for JTAG? hsicphy12m_xin12m: There is no indication of why this clock would need to be turned on for boards that don't use HSIC. pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn these 4 clocks on only when doing DDR transitions and they are off otherwise. I see no reason why they'd need to be on in the upstream kernel which doesn't support DDRFreq. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Wen Yang authored
[ Upstream commit 44b9f86c ] The call to of_find_compatible_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/pinctrl/samsung/pinctrl-exynos-arm.c:76:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 66, but without a corresponding object release within this function. ./drivers/pinctrl/samsung/pinctrl-exynos-arm.c:82:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 66, but without a corresponding object release within this function. Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Tomasz Figa <tomasz.figa@gmail.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-samsung-soc@vger.kernel.org Cc: linux-gpio@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Wen Yang authored
[ Upstream commit 483d70d7 ] The call to of_get_child_by_name returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/pinctrl/pinctrl-st.c:1188:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1175, but without a corresponding object release within this function. ./drivers/pinctrl/pinctrl-st.c:1188:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1175, but without a corresponding object release within this function. ./drivers/pinctrl/pinctrl-st.c:1199:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1175, but without a corresponding object release within this function. ./drivers/pinctrl/pinctrl-st.c:1199:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1175, but without a corresponding object release within this function. Signed-off-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
-
Wen Yang authored
[ Upstream commit 44a4455a ] The call to of_get_child_by_name returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/pinctrl/pinctrl-pistachio.c:1422:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1360, but without a corresponding object release within this function. Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 09637752 ] According to the logitech_hidpp_2.0_specification_draft_2012-06-04.pdf doc: https://lekensteyn.nl/files/logitech/logitech_hidpp_2.0_specification_draft_2012-06-04.pdf We should use a register-access-protocol request using the short input / output report ids. This is necessary because 27MHz HID++ receivers have a max-packetsize on their HIP++ endpoint of 8, so they cannot support long reports. Using a feature-access-protocol request (which is always long or very-long) with these will cause a timeout error, followed by the hidpp driver treating the device as not being HID++ capable. This commit fixes this by switching to using a rap request to get the protocol version. Besides being tested with a (046d:c517) 27MHz receiver with various 27MHz keyboards and mice, this has also been tested to not cause regressions on a non-unifying dual-HID++ nano receiver (046d:c534) with k270 and m185 HID++-2.0 devices connected and on a unifying/dj receiver (046d:c52b) with a HID++-2.0 Logitech Rechargeable Touchpad T650. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Sean Wang authored
[ Upstream commit cac63f9b ] Fixed warning: incorrect type in assignment reported by kbuild test robot. The detailed warning is shown as below. make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' All warnings (new ones prefixed by >>): btmtkuart.c:671:18: sparse: warning: incorrect type in assignment (different base types) btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate btmtkuart.c:671:18: sparse: got restricted __le32 [usertype] sparse warnings: (new ones prefixed by >>) btmtkuart.c:671:18: sparse: warning: incorrect type in assignment (different base types) btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate btmtkuart.c:671:18: sparse: got restricted __le32 [usertype] vim +671 drivers/bluetooth/btmtkuart.c 659 660 static int btmtkuart_change_baudrate(struct hci_dev *hdev) 661 { 662 struct btmtkuart_dev *bdev = hci_get_drvdata(hdev); 663 struct btmtk_hci_wmt_params wmt_params; 664 u32 baudrate; 665 u8 param; 666 int err; 667 668 /* Indicate the device to enter the probe state the host is 669 * ready to change a new baudrate. 670 */ > 671 baudrate = cpu_to_le32(bdev->desired_speed); 672 wmt_params.op = MTK_WMT_HIF; Fixes: 22eaf6c9 ("Bluetooth: mediatek: add support for MediaTek MT7663U and MT7668U UART devices") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Ferry Toth authored
[ Upstream commit 50357261 ] The BCM43341B has the default MAC address 43:34:1B:00:1F:AC if none is given. This address was found when enabling Bluetooth on multiple Intel Edison modules. It also contains the sequence 43341B, the name the chip identifies itself as. Using the same BD_ADDR is problematic when having multiple Intel Edison modules in each others range. The default address also has the LAA (locally administered address) bit set which prevents a BNEP device from being created, needed for BT tethering. Add this to the list of black listed default MAC addresses and let the user configure a valid one using f.i. `btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx` Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Ferry Toth <ftoth@exalondelft.nl> Reviewed-by:
-
Balakrishna Godavarthi authored
[ Upstream commit 7f09d5a6 ] This patch enables enough time to ROME controller to bootup after we bring the enable pin out of reset. Fixes: 05ba533c ("Bluetooth: hci_qca: Add serdev support"). Signed-off-by:
Balakrishna Godavarthi <bgodavar@codeaurora.org> Reviewed-by:
Rocky Liao <rjliao@codeaurora.org> Tested-by:
Claire Chang <tientzu@chromium.org> Signed-off-by:
-
Matthias Kaehlcke authored
[ Upstream commit ecf2b768 ] qca_set_baudrate() calls serdev_device_wait_until_sent() assuming that the HCI is always associated with a serdev device. This isn't true for ROME controllers instantiated through ldisc, where the call causes a crash due to a NULL pointer dereferentiation. Only call the function when we have a serdev device. The timeout for ROME devices at the end of qca_set_baudrate() is long enough to be reasonably sure that the command was sent. Fixes: fa9ad876 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Reported-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
-
Peter Zijlstra authored
[ Upstream commit 29da93fe ] Randy reported objtool triggered on his (GCC-7.4) build: lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x315: call to __ubsan_handle_add_overflow() with UACCESS enabled lib/strnlen_user.o: warning: objtool: strnlen_user()+0x337: call to __ubsan_handle_sub_overflow() with UACCESS enabled This is due to UBSAN generating signed-overflow-UB warnings where it should not. Prior to GCC-8 UBSAN ignored -fwrapv (which the kernel uses through -fno-strict-overflow). Make the functions use 'unsigned long' throughout. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: luto@kernel.org Link: http://lkml.kernel.org/r/20190424072208.754094071@infradead.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Jiri Kosina authored
[ Upstream commit a65c88e1 ] In-NMI warnings have been added to vmalloc_fault() via: ebc8827f ("x86: Barf when vmalloc and kmemcheck faults happen in NMI") back in the time when our NMI entry code could not cope with nested NMIs. These days, it's perfectly fine to take a fault in NMI context and we don't have to care about the fact that IRET from the fault handler might cause NMI nesting. This warning has already been removed from 32-bit implementation of vmalloc_fault() in: 6863ea0c ("x86/mm: Remove in_nmi() warning from vmalloc_fault()") but the 64-bit version was omitted. Remove the bogus warning also from 64-bit implementation of vmalloc_fault(). Reported-by:
Nicolai Stange <nstange@suse.de> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Acked-by:
-
Peter Zijlstra authored
[ Upstream commit 6ae86561 ] The __put_user() macro evaluates it's @ptr argument inside the __uaccess_begin() / __uaccess_end() region. While this would normally not be expected to be an issue, an UBSAN bug (it ignored -fwrapv, fixed in GCC 8+) would transform the @ptr evaluation for: drivers/gpu/drm/i915/i915_gem_execbuffer.c: if (unlikely(__put_user(offset, &urelocs[r-stack].presumed_offset))) { into a signed-overflow-UB check and trigger the objtool AC validation. Finish this commit: 2a418cf3 ("x86/uaccess: Don't leak the AC flag into __put_user() value evaluation") and explicitly evaluate all 3 arguments early. Reported-by:
-
Sebastian Andrzej Siewior authored
[ Upstream commit d4645d30 ] The test robot reported a wrong assignment of a per-CPU variable which it detected by using sparse and sent a report. The assignment itself is correct. The annotation for sparse was wrong and hence the report. The first pointer is a "normal" pointer and points to the per-CPU memory area. That means that the __percpu annotation has to be moved. Move the __percpu annotation to pointer which points to the per-CPU area. This change affects only the sparse tool (and is ignored by the compiler). Reported-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: f97f8f06 ("smpboot: Provide infrastructure for percpu hotplug threads") Link: http://lkml.kernel.org/r/20190424085253.12178-1-bigeasy@linutronix.deSigned-off-by:
-
Kees Cook authored
[ Upstream commit 392bef70 ] When building x86 with Clang LTO and CFI, CFI jump regions are automatically added to the end of the .text section late in linking. As a result, the _etext position was being labelled before the appended jump regions, causing confusion about where the boundaries of the executable region actually are in the running kernel, and broke at least the fault injection code. This moves the _etext mark to outside (and immediately after) the .text area, as it already the case on other architectures (e.g. arm64, arm). Reported-and-tested-by:
Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20190423183827.GA4012@beastSigned-off-by:
-
Farhan Ali authored
[ Upstream commit b49bdc86 ] When releasing the vfio-ccw mdev, we currently do not release any existing channel program and its pinned pages. This can lead to the following warning: [1038876.561565] WARNING: CPU: 2 PID: 144727 at drivers/vfio/vfio_iommu_type1.c:1494 vfio_sanity_check_pfn_list+0x40/0x70 [vfio_iommu_type1] .... 1038876.561921] Call Trace: [1038876.561935] ([<00000009897fb870>] 0x9897fb870) [1038876.561949] [<000003ff8013bf62>] vfio_iommu_type1_detach_group+0xda/0x2f0 [vfio_iommu_type1] [1038876.561965] [<000003ff8007b634>] __vfio_group_unset_container+0x64/0x190 [vfio] [1038876.561978] [<000003ff8007b87e>] vfio_group_put_external_user+0x26/0x38 [vfio] [1038876.562024] [<000003ff806fc608>] kvm_vfio_group_put_external_user+0x40/0x60 [kvm] [1038876.562045] [<000003ff806fcb9e>] kvm_vfio_destroy+0x5e/0xd0 [kvm] [1038876.562065] [<000003ff806f63fc>] kvm_put_kvm+0x2a4/0x3d0 [kvm] [1038876.562083] [<000003ff806f655e>] kvm_vm_release+0x36/0x48 [kvm] [1038876.562098] [<00000000003c2dc4>] __fput+0x144/0x228 [1038876.562113] [<000000000016ee82>] task_work_run+0x8a/0xd8 [1038876.562125] [<000000000014c7a8>] do_exit+0x5d8/0xd90 [1038876.562140] [<000000000014d084>] do_group_exit+0xc4/0xc8 [1038876.562155] [<000000000015c046>] get_signal+0x9ae/0xa68 [1038876.562169] [<0000000000108d66>] do_signal+0x66/0x768 [1038876.562185] [<0000000000b9e37e>] system_call+0x1ea/0x2d8 [1038876.562195] 2 locks held by qemu-system-s39/144727: [1038876.562205] #0: 00000000537abaf9 (&container->group_lock){++++}, at: __vfio_group_unset_container+0x3c/0x190 [vfio] [1038876.562230] #1: 00000000670008b5 (&iommu->lock){+.+.}, at: vfio_iommu_type1_detach_group+0x36/0x2f0 [vfio_iommu_type1] [1038876.562250] Last Breaking-Event-Address: [1038876.562262] [<000003ff8013aa24>] vfio_sanity_check_pfn_list+0x3c/0x70 [vfio_iommu_type1] [1038876.562272] irq event stamp: 4236481 [1038876.562287] hardirqs last enabled at (4236489): [<00000000001cee7a>] console_unlock+0x6d2/0x740 [1038876.562299] hardirqs last disabled at (4236496): [<00000000001ce87e>] console_unlock+0xd6/0x740 [1038876.562311] softirqs last enabled at (4234162): [<0000000000b9fa1e>] __do_softirq+0x556/0x598 [1038876.562325] softirqs last disabled at (4234153): [<000000000014e4cc>] irq_exit+0xac/0x108 [1038876.562337] ---[ end trace 6c96d467b1c3ca06 ]--- Similarly we do not free the channel program when we are removing the vfio-ccw device. Let's fix this by resetting the device and freeing the channel program and pinned pages in the release path. For the remove path we can just quiesce the device, since in the remove path the mediated device is going away for good and so we don't need to do a full reset. Signed-off-by:
Farhan Ali <alifm@linux.ibm.com> Message-Id: <ae9f20dc8873f2027f7b3c5d2aaa0bdfe06850b8.1554756534.git.alifm@linux.ibm.com> Acked-by:
Eric Farman <farman@linux.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
-
Farhan Ali authored
[ Upstream commit cea5dde4 ] Currently we call flush_workqueue while holding the subchannel spinlock. But flush_workqueue function can go to sleep, so do not call the function while holding the spinlock. Fixes the following bug: [ 285.203430] BUG: scheduling while atomic: bash/14193/0x00000002 [ 285.203434] INFO: lockdep is turned off. .... [ 285.203485] Preemption disabled at: [ 285.203488] [<000003ff80243e5c>] vfio_ccw_sch_quiesce+0xbc/0x120 [vfio_ccw] [ 285.203496] CPU: 7 PID: 14193 Comm: bash Tainted: G W .... [ 285.203504] Call Trace: [ 285.203510] ([<0000000000113772>] show_stack+0x82/0xd0) [ 285.203514] [<0000000000b7a102>] dump_stack+0x92/0xd0 [ 285.203518] [<000000000017b8be>] __schedule_bug+0xde/0xf8 [ 285.203524] [<0000000000b95b5a>] __schedule+0x7a/0xc38 [ 285.203528] [<0000000000b9678a>] schedule+0x72/0xb0 [ 285.203533] [<0000000000b9bfbc>] schedule_timeout+0x34/0x528 [ 285.203538] [<0000000000b97608>] wait_for_common+0x118/0x1b0 [ 285.203544] [<0000000000166d6a>] flush_workqueue+0x182/0x548 [ 285.203550] [<000003ff80243e6e>] vfio_ccw_sch_quiesce+0xce/0x120 [vfio_ccw] [ 285.203556] [<000003ff80245278>] vfio_ccw_mdev_reset+0x38/0x70 [vfio_ccw] [ 285.203562] [<000003ff802458b0>] vfio_ccw_mdev_remove+0x40/0x78 [vfio_ccw] [ 285.203567] [<000003ff801a499c>] mdev_device_remove_ops+0x3c/0x80 [mdev] [ 285.203573] [<000003ff801a4d5c>] mdev_device_remove+0xc4/0x130 [mdev] [ 285.203578] [<000003ff801a5074>] remove_store+0x6c/0xa8 [mdev] [ 285.203582] [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8 [ 285.203588] [<00000000003c1530>] __vfs_write+0x38/0x1a8 [ 285.203593] [<00000000003c187c>] vfs_write+0xb4/0x198 [ 285.203597] [<00000000003c1af2>] ksys_write+0x5a/0xb0 [ 285.203601] [<0000000000b9e270>] system_call+0xdc/0x2d8 Signed-off-by:
Pierre Morel <pmorel@linux.ibm.com> Message-Id: <626bab8bb2958ae132452e1ddaf1b20882ad5a9d.1554756534.git.alifm@linux.ibm.com> Signed-off-by:
-
Parav Pandit authored
[ Upstream commit 5d7ed2f2 ] When two netdev have same link local addresses (such as vlan and non vlan), two rdma cm listen id should be able to bind to following different addresses. listener-1: addr=lla, scope_id=A, port=X listener-2: addr=lla, scope_id=B, port=X However while comparing the addresses only addr and port are considered, due to which 2nd listener fails to listen. In below example of two listeners, 2nd listener is failing with address in use error. $ rping -sv -a fe80::268a:7ff:feb3:d113%ens2f1 -p 4545& $ rping -sv -a fe80::268a:7ff:feb3:d113%ens2f1.200 -p 4545 rdma_bind_addr: Address already in use To overcome this, consider the scope_ids as well which forms the accurate IPv6 link local address. Signed-off-by:
Parav Pandit <parav@mellanox.com> Reviewed-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 78d4eb8a ] clang has identified a code path in which it thinks a variable may be unused: drivers/md/bcache/alloc.c:333:4: error: variable 'bucket' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] fifo_pop(&ca->free_inc, bucket); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/md/bcache/util.h:219:27: note: expanded from macro 'fifo_pop' #define fifo_pop(fifo, i) fifo_pop_front(fifo, (i)) ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/md/bcache/util.h:189:6: note: expanded from macro 'fifo_pop_front' if (_r) { \ ^~ drivers/md/bcache/alloc.c:343:46: note: uninitialized use occurs here allocator_wait(ca, bch_allocator_push(ca, bucket)); ^~~~~~ drivers/md/bcache/alloc.c:287:7: note: expanded from macro 'allocator_wait' if (cond) \ ^~~~ drivers/md/bcache/alloc.c:333:4: note: remove the 'if' if its condition is always true fifo_pop(&ca->free_inc, bucket); ^ drivers/md/bcache/util.h:219:27: note: expanded from macro 'fifo_pop' #define fifo_pop(fifo, i) fifo_pop_front(fifo, (i)) ^ drivers/md/bcache/util.h:189:2: note: expanded from macro 'fifo_pop_front' if (_r) { \ ^ drivers/md/bcache/alloc.c:331:15: note: initialize the variable 'bucket' to silence this warning long bucket; ^ This cannot happen in practice because we only enter the loop if there is at least one element in the list. Slightly rearranging the code makes this clearer to both the reader and the compiler, which avoids the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Coly Li authored
[ Upstream commit ce3e4cfb ] Currently run_cache_set() has no return value, if there is failure in bch_journal_replay(), the caller of run_cache_set() has no idea about such failure and just continue to execute following code after run_cache_set(). The internal failure is triggered inside bch_journal_replay() and being handled in async way. This behavior is inefficient, while failure handling inside bch_journal_replay(), cache register code is still running to start the cache set. Registering and unregistering code running as same time may introduce some rare race condition, and make the code to be more hard to be understood. This patch adds return value to run_cache_set(), and returns -EIO if bch_journal_rreplay() fails. Then caller of run_cache_set() may detect such failure and stop registering code flow immedidately inside register_cache_set(). If journal replay fails, run_cache_set() can report error immediately to register_cache_set(). This patch makes the failure handling for bch_journal_replay() be in synchronized way, easier to understand and debug, and avoid poetential race condition for register-and-unregister in same time. Signed-off-by:
-
Tang Junhui authored
[ Upstream commit 63120731 ] journal replay failed with messages: Sep 10 19:10:43 ceph kernel: bcache: error on bb379a64-e44e-4812-b91d-a5599871a3b1: bcache: journal entries 2057493-2057567 missing! (replaying 2057493-20766016), disabling caching The reason is in journal_reclaim(), when discard is enabled, we send discard command and reclaim those journal buckets whose seq is old than the last_seq_now, but before we write a journal with last_seq_now, the machine is restarted, so the journal with the last_seq_now is not written to the journal bucket, and the last_seq_wrote in the newest journal is old than last_seq_now which we expect to be, so when we doing replay, journals from last_seq_wrote to last_seq_now are missing. It's hard to write a journal immediately after journal_reclaim(), and it harmless if those missed journal are caused by discarding since those journals are already wrote to btree node. So, if miss seqs are started from the beginning journal, we treat it as normal, and only print a message to show the miss journal, and point out it maybe caused by discarding. Patch v2 add a judgement condition to ignore the missed journal only when discard enabled as Coly suggested. (Coly Li: rebase the patch with other changes in bch_journal_replay()) Signed-off-by:
Tang Junhui <tang.junhui.linux@gmail.com> Tested-by:
Dennis Schridde <devurandom@gmx.net> Signed-off-by:
-
Coly Li authored
[ Upstream commit 68d10e69 ] When failure happens inside bch_journal_replay(), calling cache_set_err_on() and handling the failure in async way is not a good idea. Because after bch_journal_replay() returns, registering code will continue to execute following steps, and unregistering code triggered by cache_set_err_on() is running in same time. First it is unnecessary to handle failure and unregister cache set in an async way, second there might be potential race condition to run register and unregister code for same cache set. So in this patch, if failure happens in bch_journal_replay(), we don't call cache_set_err_on(), and just print out the same error message to kernel message buffer, then return -EIO immediately caller. Then caller can detect such failure and handle it in synchrnozied way. Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Shenghui Wang authored
bcache: avoid potential memleak of list of journal_replay(s) in the CACHE_SYNC branch of run_cache_set [ Upstream commit 95f18c9d ] In the CACHE_SYNC branch of run_cache_set(), LIST_HEAD(journal) is used to collect journal_replay(s) and filled by bch_journal_read(). If all goes well, bch_journal_replay() will release the list of jounal_replay(s) at the end of the branch. If something goes wrong, code flow will jump to the label "err:" and leave the list unreleased. This patch will release the list of journal_replay(s) in the case of error detected. v1 -> v2: * Move the release code to the location after label 'err:' to simply the change. Signed-off-by:
Shenghui Wang <shhuiw@foxmail.com> Signed-off-by:
-
Corentin Labbe authored
[ Upstream commit f8739155 ] When nbytes < 4, end is wronlgy set to a negative value which, due to uint, is then interpreted to a large value leading to a deadlock in the following code. This patch fix this problem. Fixes: 6298e948 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 7a425896 ] If we timeout the admin startup sequence we might not yet have an I/O tagset allocated which causes the teardown sequence to crash. Make nvme_tcp_teardown_io_queues safe by not iterating inflight tags if the tagset wasn't allocated. Fixes: 39d57757 ("nvme-tcp: fix timeout handler") Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 1007709d ] If we timeout the admin startup sequence we might not yet have an I/O tagset allocated which causes the teardown sequence to crash. Make nvme_tcp_teardown_io_queues safe by not iterating inflight tags if the tagset wasn't allocated. Fixes: 4c174e63 ("nvme-rdma: fix timeout handler") Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 01fa0174 ] If our target exposed a namespace with a block size that is greater than PAGE_SIZE, set 0 capacity on the namespace as we do not support it. This issue encountered when the nvmet namespace was backed by a tempfile. Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 0ed2a005 ] In case create_singlethread_workqueue fails, the fix free the hardware and returns NULL to avoid NULL pointer dereference. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Aditya Pakki authored
[ Upstream commit d5414c23 ] kmalloc can fail in rsi_register_rates_channels but memcpy still attempts to write to channels. The patch replaces these calls with kmemdup and passes the error upstream. Signed-off-by:
Aditya Pakki <pakki001@umn.edu> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit b4c35c17 ] The "rate_index" is only used as an index into the phist_data->rx_rate[] array in the mwifiex_hist_data_set() function. That array has MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some debugfs information. The "rate_index" variable comes from the network skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap it to prevent an array overflow. Fixes: cbf6e055 ("mwifiex: add rx histogram statistics support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Xiaoli Feng authored
[ Upstream commit ce96e888 ] dedupe_file_range operations is combiled into remap_file_range. But in nfs42_remap_file_range, it's skiped for dedupe operations. Before this patch: # dd if=/dev/zero of=nfs/file bs=1M count=1 # xfs_io -c "dedupe nfs/file 4k 64k 4k" nfs/file XFS_IOC_FILE_EXTENT_SAME: Invalid argument After this patch: # dd if=/dev/zero of=nfs/file bs=1M count=1 # xfs_io -c "dedupe nfs/file 4k 64k 4k" nfs/file deduped 4096/4096 bytes at offset 65536 4 KiB, 1 ops; 0.0046 sec (865.988 KiB/sec and 216.4971 ops/sec) Signed-off-by:
Xiaoli Feng <fengxiaoli0714@gmail.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Daniel Baluta authored
[ Upstream commit ddb35114 ] is_slave_mode defaults to false because sai structure that contains it is kzalloc'ed. Anyhow, if we decide to set the following configuration SAI slave -> SAI master, is_slave_mode will remain set on true although SAI being master it should be set to false. Fix this by updating is_slave_mode for each call of fsl_sai_set_dai_fmt. Signed-off-by:
Daniel Baluta <daniel.baluta@nxp.com> Acked-by:
Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit 78927aa4 ] I went to great lengths to hand over the management of the GPIO descriptors to the regulator core, and some stray rebased oneliner in the old patch must have been assuming the devices were still doing devres management of it. We handed the management over to the regulator core, so of course the regulator core shall issue gpiod_put() when done. Sorry for the descriptor leak. Fixes: 541d052d ("regulator: core: Only support passing enable GPIO descriptors") Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 06d5d6b7 ] In case platform_device_alloc fails, the fix returns an error code to avoid the NULL pointer dereference. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Daniel T. Lee authored
[ Upstream commit 32e621e5 ] Currently, building bpf samples will cause the following error. ./tools/lib/bpf/bpf.h:132:27: error: 'UINT32_MAX' undeclared here (not in a function) .. #define BPF_LOG_BUF_SIZE (UINT32_MAX >> 8) /* verifier maximum in kernels <= 5.1 */ ^ ./samples/bpf/bpf_load.h:31:25: note: in expansion of macro 'BPF_LOG_BUF_SIZE' extern char bpf_log_buf[BPF_LOG_BUF_SIZE]; ^~~~~~~~~~~~~~~~ Due to commit 4519efa6 ("libbpf: fix BPF_LOG_BUF_SIZE off-by-one error") hard-coded size of BPF_LOG_BUF_SIZE has been replaced with UINT32_MAX which is defined in <stdint.h> header. Even with this change, bpf selftests are running fine since these are built with clang and it includes header(-idirafter) from clang/6.0.0/include. (it has <stdint.h>) clang -I. -I./include/uapi -I../../../include/uapi -idirafter /usr/local/include -idirafter /usr/include \ -idirafter /usr/lib/llvm-6.0/lib/clang/6.0.0/include -idirafter /usr/include/x86_64-linux-gnu \ -Wno-compare-distinct-pointer-types -O2 -target bpf -emit-llvm -c progs/test_sysctl_prog.c -o - | \ llc -march=bpf -mcpu=generic -filetype=obj -o /linux/tools/testing/selftests/bpf/test_sysctl_prog.o But bpf samples are compiled with GCC, and it only searches and includes headers declared at the target file. As '#include <stdint.h>' hasn't been declared in tools/lib/bpf/bpf.h, it causes build failure of bpf samples. gcc -Wp,-MD,./samples/bpf/.sockex3_user.o.d -Wall -Wmissing-prototypes -Wstrict-prototypes \ -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ \ -I./tools/ lib/ -I./tools/include -I./tools/perf -c -o ./samples/bpf/sockex3_user.o ./samples/bpf/sockex3_user.c; This commit add declaration of '#include <stdint.h>' to tools/lib/bpf/bpf.h to fix this problem. Signed-off-by:
Daniel T. Lee <danieltimlee@gmail.com> Acked-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 43068cb7 ] Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit 48f6e3cf ("kbuild: do not drop -I without parameter"). [1]: https://patchwork.kernel.org/patch/9632347/Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1553859161-2628-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by:
-
Sergey Matyukevich authored
[ Upstream commit 5dc8cdce ] FullMAC STAs have no way to update bss channel after CSA channel switch completion. As a result, user-space tools may provide inconsistent channel info. For instance, consider the following two commands: $ sudo iw dev wlan0 link $ sudo iw dev wlan0 info The latter command gets channel info from the hardware, so most probably its output will be correct. However the former command gets channel info from scan cache, so its output will contain outdated channel info. In fact, current bss channel info will not be updated until the next [re-]connect. Note that mac80211 STAs have a workaround for this, but it requires access to internal cfg80211 data, see ieee80211_chswitch_work: /* XXX: shouldn't really modify cfg80211-owned data! */ ifmgd->associated->channel = sdata->csa_chandef.chan; This patch suggests to convert mac80211 workaround into cfg80211 behavior and to update current bss channel in cfg80211_ch_switch_notify. Signed-off-by:
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sugar Zhang authored
[ Upstream commit 2da254cc ] This patch kill instructs the DMAC to immediately terminate execution of a thread. and then clear the interrupt status, at last, stop generating interrupts for DMA_SEV. to guarantee the next dma start is clean. otherwise, one interrupt maybe leave to next start and make some mistake. we can reporduce the problem as follows: DMASEV: modify the event-interrupt resource, and if the INTEN sets function as interrupt, the DMAC will set irq<event_num> HIGH to generate interrupt. write INTCLR to clear interrupt. DMA EXECUTING INSTRUCTS DMA TERMINATE | | | | ... _stop | | | spin_lock_irqsave DMASEV | | | | mask INTEN | | | DMAKILL | | | spin_unlock_irqrestore in above case, a interrupt was left, and if we unmask INTEN, the DMAC will set irq<event_num> HIGH to generate interrupt. to fix this, do as follows: DMA EXECUTING INSTRUCTS DMA TERMINATE | | | | ... _stop | | | spin_lock_irqsave DMASEV | | | | DMAKILL | | | clear INTCLR | mask INTEN | | | spin_unlock_irqrestore Signed-off-by:
Sugar Zhang <sugar.zhang@rock-chips.com> Signed-off-by:
-
Huazhong Tan authored
[ Upstream commit 30780a8b ] Since irq handler and mailbox task will both update arq's count, so arq's count should use atomic_t instead of u32, otherwise its value may go wrong finally. Fixes: 07a0556a ("net: hns3: Changes to support ARQ(Asynchronous Receive Queue)") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
