- 27 Jan, 2020 40 commits
-
-
Colin Ian King authored
[ Upstream commit 420c20be ] An earlier commit re-worked the setting of the bitmask and is now assigning v with some bit flags rather than bitwise or-ing them into v, consequently the earlier bit-settings of v are being lost. Fix this by replacing an assignment with the bitwise or instead. Addresses-Coverity: ("Unused value") Fixes: 2be25cac ("bcma: add constants for PCI and use them") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dexuan Cui authored
[ Upstream commit 711419e5 ] Recently device pass-through stops working for Linux VM running on Hyper-V. git-bisect shows the regression is caused by the recent commit 467a3bb9 ("PCI: hv: Allocate a named fwnode ..."), but the root cause is that the commit d59f6617 forgets to set the domain->fwnode for IRQCHIP_FWNODE_NAMED*, and as a result: 1. The domain->fwnode remains to be NULL. 2. irq_find_matching_fwspec() returns NULL since "h->fwnode == fwnode" is false, and pci_set_bus_msi_domain() sets the Hyper-V PCI root bus's msi_domain to NULL. 3. When the device is added onto the root bus, the device's dev->msi_domain is set to NULL in pci_set_msi_domain(). 4. When a device driver tries to enable MSI-X, pci_msi_setup_msi_irqs() calls arch_setup_msi_irqs(), which uses the native MSI chip (i.e. arch/x86/kernel/apic/msi.c: pci_msi_controller) to set up the irqs, but actually pci_msi_setup_msi_irqs() is supposed to call msi_domain_alloc_irqs() with the hbus->irq_domain, which is created in hv_pcie_init_irq_domain() and is associated with the Hyper-V chip hv_msi_irq_chip. Consequently, the irq line is not properly set up, and the device driver can not receive any interrupt. Fixes: d59f6617 ("genirq: Allow fwnode to carry name information only") Fixes: 467a3bb9 ("PCI: hv: Allocate a named fwnode instead of an address-based one") Reported-by:
Lili Deng <v-lide@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/PU1P153MB01694D9AF625AC335C600C5FBFBE0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COMSigned-off-by:
-
Dan Carpenter authored
[ Upstream commit 32910124 ] The problem is in gb_lights_request_handler(). If we get a request to change the config then we release the light with gb_lights_light_release() and re-allocated it. However, if the allocation fails part way through then we call gb_lights_light_release() again. This can lead to a couple different double frees where we haven't cleared out the original values: gb_lights_light_v4l2_unregister(light); ... kfree(light->channels); kfree(light->name); I also made a small change to how we set "light->channels_count = 0;". The original code handled this part fine and did not cause a use after free but it was sort of complicated to read. Fixes: 2870b52b ("greybus: lights: add lights implementation") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Rui Miguel Silva <rmfrfs@gmail.com> Link: https://lore.kernel.org/r/20190829122839.GA20116@mwandaSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit 7720804a ] Since x86 instruction decoder is not only for kprobes, it should be tested when the insn.c is compiled. (e.g. perf is enabled but kprobes is disabled) Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: cbe5c34c ("x86: Compile insn.c and inat.c only for KPROBES") Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit 82880222 ] We may want to use the device pointer in device_init_wakeup() with functions that expect the device to already be added with device_add(). For example, if we were to link the device initializing wakeup to something in sysfs such as a class for wakeups we'll run into an error. It looks like this code was written with the assumption that the device would be added before initializing wakeup due to the order of operations in power_supply_unregister(). Let's change the order of operations so we don't run into problems here. Fixes: 948dcf96 ("power_supply: Prevent suspend until power supply events are processed") Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tri Vo <trong@android.com> Cc: Kalesh Singh <kaleshsingh@google.com> Cc: Ravi Chandra Sadineni <ravisadineni@chromium.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Vladimir Oltean authored
[ Upstream commit 1c6c09a0 ] The discussion to be made is absolutely the same as in the case of previous patch ("taprio: Set default link speed to 10 Mbps in taprio_set_picos_per_byte"). Nothing is lost when setting a default. Cc: Leandro Dorileo <leandro.maciel.dorileo@intel.com> Fixes: e0a7683d ("net/sched: cbs: fix port_rate miscalculation") Acked-by:
Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Guenter Roeck authored
[ Upstream commit 7d82fcc9 ] Writes into limit registers fail if the temperature written is negative. The regmap write operation checks the value range, regmap_write accepts an unsigned int as parameter, and the temperature value passed to regmap_write is kept in a variable declared as long. Negative values are converted large unsigned integers, which fails the range check. Fix by type casting the temperature to u16 when calling regmap_write(). Cc: Iker Perez del Palomar Sustatxa <iker.perez@codethink.co.uk> Fixes: e65365fe ("hwmon: (lm75) Convert to use regmap") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Linus Torvalds authored
[ Upstream commit ab9bb631 ] Commit dfe2a77f ("kfifo: fix kfifo_alloc() and kfifo_init()") made the kfifo code round the number of elements up. That was good for __kfifo_alloc(), but it's actually wrong for __kfifo_init(). The difference? __kfifo_alloc() will allocate the rounded-up number of elements, but __kfifo_init() uses an allocation done by the caller. We can't just say "use more elements than the caller allocated", and have to round down. The good news? All the normal cases will be using power-of-two arrays anyway, and most users of kfifo's don't use kfifo_init() at all, but one of the helper macros to declare a KFIFO that enforce the proper power-of-two behavior. But it looks like at least ibmvscsis might be affected. The bad news? Will Deacon refers to an old thread and points points out that the memory ordering in kfifo's is questionable. See https://lore.kernel.org/lkml/20181211034032.32338-1-yuleixzhang@tencent.com/ for more. Fixes: dfe2a77f ("kfifo: fix kfifo_alloc() and kfifo_init()") Reported-by:
laokz <laokz@foxmail.com> Cc: Stefani Seibold <stefani@seibold.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Greg KH <greg@kroah.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Deacon <will@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
David Howells authored
[ Upstream commit d12040b6 ] When a local endpoint is ceases to be in use, such as when the kafs module is unloaded, the kernel will emit an assertion failure if there are any outstanding client connections: rxrpc: Assertion failed ------------[ cut here ]------------ kernel BUG at net/rxrpc/local_object.c:433! and even beyond that, will evince other oopses if there are service connections still present. Fix this by: (1) Removing the triggering of connection reaping when an rxrpc socket is released. These don't actually clean up the connections anyway - and further, the local endpoint may still be in use through another socket. (2) Mark the local endpoint as dead when we start the process of tearing it down. (3) When destroying a local endpoint, strip all of its client connections from the idle list and discard the ref on each that the list was holding. (4) When destroying a local endpoint, call the service connection reaper directly (rather than through a workqueue) to immediately kill off all outstanding service connections. (5) Make the service connection reaper reap connections for which the local endpoint is marked dead. Only after destroying the connections can we close the socket lest we get an oops in a workqueue that's looking at a connection or a peer. Fixes: 3d18cbb7 ("rxrpc: Fix conn expiry timers") Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
Marc Dionne <marc.dionne@auristor.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 60fc35f3 ] The commit ed08d40c ("ahci: Changing two module params with static and __read_mostly") moved ahci_em_messages to be static while missing the fact of exporting it. WARNING: "ahci_em_messages" [vmlinux] is a static EXPORT_SYMBOL_GPL Drop export for the local variable ahci_em_messages. Fixes: ed08d40c ("ahci: Changing two module params with static and __read_mostly") Cc: Chuansheng Liu <chuansheng.liu@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Yong Wu authored
[ Upstream commit 76ce6546 ] In M4U 4GB mode, the physical address is remapped as below: CPU Physical address: ==================== 0 1G 2G 3G 4G 5G |---A---|---B---|---C---|---D---|---E---| +--I/O--+------------Memory-------------+ IOMMU output physical address: ============================= 4G 5G 6G 7G 8G |---E---|---B---|---C---|---D---| +------------Memory-------------+ The Region 'A'(I/O) can not be mapped by M4U; For Region 'B'/'C'/'D', the bit32 of the CPU physical address always is needed to set, and for Region 'E', the CPU physical address keep as is. something looks like this: CPU PA -> M4U OUTPUT PA 0x4000_0000 0x1_4000_0000 (Add bit32) 0x8000_0000 0x1_8000_0000 ... 0xc000_0000 0x1_c000_0000 ... 0x1_0000_0000 0x1_0000_0000 (No change) Additionally, the iommu consumers always use the CPU phyiscal address. The PA in the iova_to_phys that is got from v7s always is u32, But from the CPU point of view, PA only need add BIT(32) when PA < 0x4000_0000. Fixes: 30e2fccf ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Markus Elfring authored
[ Upstream commit ecbce48f ] A null pointer would be passed to a call of the function "kfree" directly after a call of the function "kcalloc" failed at one place. Pass the data structure member "urb" instead for which memory was allocated before (so that this resource will be properly cleaned up). This issue was detected by using the Coccinelle software. Fixes: d571b592 ("media: em28xx: don't use coherent buffer for DMA transfers") Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Nick Desaulniers authored
[ Upstream commit 12051b31 ] The code in question is modifying a variable declared const through pointer manipulation. Such code is explicitly undefined behavior, and is the lone issue preventing malta_defconfig from booting when built with Clang: If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. LLVM is removing such assignments. A simple fix is to not declare variables const that you plan on modifying. Limiting the scope would be a better method of preventing unwanted writes to such a variable. Further, the code in question mentions "compiler bugs" without any links to bug reports, so it is difficult to know if the issue is resolved in GCC. The patch was authored in 2006, which would have been GCC 4.0.3 or 4.1.1. The minimal supported version of GCC in the Linux kernel is currently 4.6. For what its worth, there was UB before the commit in question, it just added a barrier and got lucky IRT codegen. I don't think there's any actual compiler bugs related, just runtime bugs due to UB. Link: https://github.com/ClangBuiltLinux/linux/issues/610 Fixes: 966f4406 ("[MIPS] Work around bad code generation for <asm/io.h>.") Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Debugged-by:
Eli Friedman <efriedma@quicinc.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Paul Burton <paul.burton@mips.com> Cc: ralf@linux-mips.org Cc: jhogan@kernel.org Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Hassan Naveed <hnaveed@wavecomp.com> Cc: Stephen Kitt <steve@sk2.org> Cc: Serge Semin <fancer.lancer@gmail.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: clang-built-linux@googlegroups.com Signed-off-by:
-
Bruno Thomsen authored
[ Upstream commit 7f43020e ] The previous fix listed bulk read of registers as root cause of accendential disabling of watchdog, since the watchdog counter register (WD_VAL) was zeroed. Fixes: 3769a375 rtc: pcf2127: bulk read only date and time registers. Tested with the same PCF2127 chip as Sean reveled root cause of WD_VAL register value zeroing was caused by reading CTRL2 register which is one of the watchdog feature control registers. So the solution is to not read the first two control registers (CTRL1 and CTRL2) in pcf2127_rtc_read_time as they are not needed anyway. Size of local buf variable is kept to allow easy usage of register defines to improve readability of code. Debug trace line was updated after CTRL1 and CTRL2 are no longer read from the chip. Also replaced magic numbers in buf access with register defines. Signed-off-by:
Bruno Thomsen <bruno.thomsen@gmail.com> Link: https://lore.kernel.org/r/20190822131936.18772-3-bruno.thomsen@gmail.comSigned-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 3e07590e ] Since commit ad67b74d ("printk: hash addresses printed with %p"), an obfuscated kernel pointer is printed at every boot if debugging is enabled: vdso: 1 text pages at base (____ptrval____) Remove the print completely, as it's useless without the address. Based on commit 0f1bf7e3 ("arm64/vdso: don't leak kernel addresses"). Fixes: ad67b74d ("printk: hash addresses printed with %p") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Alexandre Kroupski authored
[ Upstream commit 623fd246 ] In case of sensor malfunction, stop streaming timeout takes much longer than expected. This is due to conversion of time to jiffies: milliseconds multiplied with HZ (ticks/second) gives out a value of jiffies with 10^3 greater. We need to also divide by 10^3 to obtain the right jiffies value. In other words FRAME_INTERVAL_MILLI_SEC must be in seconds in order to multiply by HZ and get the right jiffies value to add to the current jiffies for the timeout expire time. Fixes: 195ebc43 ("[media] V4L: at91: add Atmel Image Sensor Interface (ISI) support") Signed-off-by:
Alexandre Kroupski <alexandre.kroupski@ingenico.com> Reviewed-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 33b16568 ] The functions i40e_aq_get_phy_abilities_resp() and i40e_set_fc() both have giant structure on the stack, which makes each one use stack frames larger than 500 bytes. As clang decides one function into the other, we get a warning for exceeding the frame size limit on 32-bit architectures: drivers/net/ethernet/intel/i40e/i40e_common.c:1654:23: error: stack frame size of 1116 bytes in function 'i40e_set_fc' [-Werror,-Wframe-larger-than=] When building with gcc, the inlining does not happen, but i40e_set_fc() calls i40e_aq_get_phy_abilities_resp() anyway, so they add up on the kernel stack just as much. The parts that actually use large stacks don't overlap, so make sure each one is a separate function, and mark them as noinline_for_stack to prevent the compilers from combining them again. Fixes: 0a862b43 ("i40e/i40evf: Add module_types and update_link_info") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit 56dd918f ] The group number needs to be multiplied by the number of rates per group to get the full rate index Fixes: 5935839a ("mac80211: improve minstrel_ht rate sorting by throughput & probability") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20190820095449.45255-1-nbd@nbd.nameSigned-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit a6f26606 ] My error handling "cleanup" was totally wrong. Both the "err" and "ret" variables are required. The "err" variable holds the error codes for rv3029_eeprom_enter/exit() and the "ret" variable holds the error codes for if actual write fails. In my patch if the write failed, the function probably still returned success. Reported-by:
Tom Evans <tom.evans@motec.com.au> Fixes: 97f5b037 ("rtc: rv3029: Clean up error handling in rv3029_eeprom_write()") Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit e7b8514e ] There is a possibility to have registered ACPI DMA controller while it has been gone already. To avoid the potential crash, move to non-managed acpi_dma_controller_register(). Fixes: 42c91ee7 ("dw_dmac: add ACPI support") Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Maxime Ripard authored
[ Upstream commit cf2c0e1c ] The RX and TX counters registers offset have been swapped, fix that. Fixes: fa7c0d13 ("ASoC: sunxi: Add Allwinner A10 Digital Audio driver") Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://lore.kernel.org/r/8b26477560ad5fd8f69e037b167c5e61de5c26a3.1566242458.git-series.maxime.ripard@bootlin.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Nicholas Piggin authored
[ Upstream commit 31f210cf ] create_physical_mapping expects physical addresses, but splitting these mapping on hot unplug is supplying virtual (effective) addresses. Fixes: 4dd5f8a9 ("powerpc/mm/radix: Split linear mapping on hot-unplug") Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190724084638.24982-2-npiggin@gmail.comSigned-off-by:
-
Eric W. Biederman authored
[ Upstream commit 33da8e7c ] My recent to change to only use force_sig for a synchronous events wound up breaking signal reception cifs and drbd. I had overlooked the fact that by default kthreads start out with all signals set to SIG_IGN. So a change I thought was safe turned out to have made it impossible for those kernel thread to catch their signals. Reverting the work on force_sig is a bad idea because what the code was doing was very much a misuse of force_sig. As the way force_sig ultimately allowed the signal to happen was to change the signal handler to SIG_DFL. Which after the first signal will allow userspace to send signals to these kernel threads. At least for wake_ack_receiver in drbd that does not appear actively wrong. So correct this problem by adding allow_kernel_signal that will allow signals whose siginfo reports they were sent by the kernel through, but will not allow userspace generated signals, and update cifs and drbd to call allow_kernel_signal in an appropriate place so that their thread can receive this signal. Fixing things this way ensures that userspace won't be able to send signals and cause problems, that it is clear which signals the threads are expecting to receive, and it guarantees that nothing else in the system will be affected. This change was partly inspired by similar cifs and drbd patches that added allow_signal. Reported-by:
ronnie sahlberg <ronniesahlberg@gmail.com> Reported-by:
Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Tested-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Vasundhara Volam authored
[ Upstream commit dd2ebf34 ] If FW returns FRAG_ERR in response error code, driver is resending the command only when HWRM command returns success. Fix the code to resend NVM_INSTALL_UPDATE command with DEFRAG install flags, if FW returns FRAG_ERR in its response error code. Fixes: cb4d1d62 ("bnxt_en: Retry failed NVM_INSTALL_UPDATE with defragmentation flag enabled.") Signed-off-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Fabrizio Castro authored
[ Upstream commit 0b936e61 ] Using name "bridge" for macro bridge_to_rcar_lvds argument doesn't work when the pointer name used by the caller is not "bridge". Rename the argument to "b" to allow for any pointer name. While at it, fix the connector_to_rcar_lvds macro similarly. Fixes: c6a27fa4 ("drm: rcar-du: Convert LVDS encoder code to bridge driver") Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Fix connector_to_rcar_lvds] Signed-off-by:
-
Quentin Monnet authored
[ Upstream commit 22c349e8 ] There are some mismatches between format strings and arguments passed to jsonw_printf() in the BTF dumper for bpftool, which seems harmless but may result in warnings if the "__printf()" attribute is used correctly for jsonw_printf(). Let's fix relevant format strings and type cast. Fixes: b12d6ec0 ("bpf: btf: add btf print functionality") Signed-off-by:
Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Quentin Monnet authored
[ Upstream commit 9def249d ] The last argument passed to some calls to the p_err() functions is not correct, it should be "*argv" instead of "**argv". This may lead to a segmentation fault error if CPU IDs or indices from the command line cannot be parsed correctly. Let's fix this. Fixes: f412eed9 ("tools: bpftool: add simple perf event output reader") Signed-off-by:
-
Gerd Rausch authored
[ Upstream commit 55c70ca0 ] In a previous commit, fields were added to "struct rds_statistics" but array "rds_stat_names" was not updated accordingly. Please note the inconsistent naming of the string representations that is done in the name of compatibility with the Oracle internal code-base. s_recv_bytes_added_to_socket -> "recv_bytes_added_to_sock" s_recv_bytes_removed_from_socket -> "recv_bytes_freed_fromsock" Fixes: 192a798f ("RDS: add stat for socket recv memory usage") Signed-off-by:
Gerd Rausch <gerd.rausch@oracle.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 554b75bd ] sound/soc/codecs/wm8737.c:112:29: warning: high_3d defined but not used [-Wunused-const-variable=] 'high_3d' should be used for 3D High Cut-off. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 2a9ae13a ("ASoC: Add initial WM8737 driver") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20190815091920.64480-1-yuehaibing@huawei.comSigned-off-by:
-
YueHaibing authored
[ Upstream commit 9b4275c4 ] sound/soc/codecs/cs4349.c:358:32: warning: cs4349_runtime_pm defined but not used [-Wunused-const-variable=] cs4349_runtime_pm ops already defined, it seems we should enable it. Reported-by:
-
YueHaibing authored
[ Upstream commit 630742c2 ] It seems 'es8328_rline_enum' should be used in es8328_right_line_controls Fixes: 567e4f98 ("ASoC: add es8328 codec driver") Signed-off-by:
-
Xi Wang authored
[ Upstream commit bf8c02f9 ] kasan will report a BUG when run command 'insmod hns_roce_hw_v2.ko', the calltrace is as follows: ================================================================== BUG: KASAN: slab-out-of-bounds in hns_roce_v2_init_eq_table+0x1324/0x1948 [hns_roce_hw_v2] Read of size 8 at addr ffff8020e7a10608 by task insmod/256 CPU: 0 PID: 256 Comm: insmod Tainted: G O 5.2.0-rc4 #1 Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 Call trace: dump_backtrace+0x0/0x1e8 show_stack+0x14/0x20 dump_stack+0xc4/0xfc print_address_description+0x60/0x270 __kasan_report+0x164/0x1b8 kasan_report+0xc/0x18 __asan_load8+0x84/0xa8 hns_roce_v2_init_eq_table+0x1324/0x1948 [hns_roce_hw_v2] hns_roce_init+0xf8/0xfe0 [hns_roce] __hns_roce_hw_v2_init_instance+0x284/0x330 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0xd0/0x1b8 [hns_roce_hw_v2] hclge_init_roce_client_instance+0x180/0x310 [hclge] hclge_init_client_instance+0xcc/0x508 [hclge] hnae3_init_client_instance.part.3+0x3c/0x80 [hnae3] hnae3_register_client+0x134/0x1a8 [hnae3] hns_roce_hw_v2_init+0x14/0x10000 [hns_roce_hw_v2] do_one_initcall+0x9c/0x3e0 do_init_module+0xd4/0x2d8 load_module+0x3284/0x3690 __se_sys_init_module+0x274/0x308 __arm64_sys_init_module+0x40/0x50 el0_svc_handler+0xbc/0x210 el0_svc+0x8/0xc Allocated by task 256: __kasan_kmalloc.isra.0+0xd0/0x180 kasan_kmalloc+0xc/0x18 __kmalloc+0x16c/0x328 hns_roce_v2_init_eq_table+0x764/0x1948 [hns_roce_hw_v2] hns_roce_init+0xf8/0xfe0 [hns_roce] __hns_roce_hw_v2_init_instance+0x284/0x330 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0xd0/0x1b8 [hns_roce_hw_v2] hclge_init_roce_client_instance+0x180/0x310 [hclge] hclge_init_client_instance+0xcc/0x508 [hclge] hnae3_init_client_instance.part.3+0x3c/0x80 [hnae3] hnae3_register_client+0x134/0x1a8 [hnae3] hns_roce_hw_v2_init+0x14/0x10000 [hns_roce_hw_v2] do_one_initcall+0x9c/0x3e0 do_init_module+0xd4/0x2d8 load_module+0x3284/0x3690 __se_sys_init_module+0x274/0x308 __arm64_sys_init_module+0x40/0x50 el0_svc_handler+0xbc/0x210 el0_svc+0x8/0xc Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff8020e7a10600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffff8020e7a10600, ffff8020e7a10680) The buggy address belongs to the page: page:ffff7fe00839e840 refcount:1 mapcount:0 mapping:ffff802340020200 index:0x0 flags: 0x5fffe00000000200(slab) raw: 5fffe00000000200 dead000000000100 dead000000000200 ffff802340020200 raw: 0000000000000000 0000000081000100 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8020e7a10500: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff8020e7a10580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8020e7a10600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8020e7a10680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8020e7a10700: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint Fixes: a5073d60 ("RDMA/hns: Add eq support of hip08") Signed-off-by:
Xi Wang <wangxi11@huawei.com> Link: https://lore.kernel.org/r/1565343666-73193-7-git-send-email-oulijun@huawei.comSigned-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Xi Wang authored
[ Upstream commit 9bba3f0c ] kasan will report a BUG when run command 'rmmod hns_roce_hw_v2', the calltrace is as follows: ================================================================== BUG: KASAN: slab-out-of-bounds in hns_roce_table_mhop_put+0x584/0x828 [hns_roce] Read of size 8 at addr ffff802185e08300 by task rmmod/270 Call trace: dump_backtrace+0x0/0x1e8 show_stack+0x14/0x20 dump_stack+0xc4/0xfc print_address_description+0x60/0x270 __kasan_report+0x164/0x1b8 kasan_report+0xc/0x18 __asan_load8+0x84/0xa8 hns_roce_table_mhop_put+0x584/0x828 [hns_roce] hns_roce_table_put+0x174/0x1a0 [hns_roce] hns_roce_mr_free+0x124/0x210 [hns_roce] hns_roce_dereg_mr+0x90/0xb8 [hns_roce] ib_dealloc_pd_user+0x60/0xf0 ib_mad_port_close+0x128/0x1d8 ib_mad_remove_device+0x94/0x118 remove_client_context+0xa0/0xe0 disable_device+0xfc/0x1c0 __ib_unregister_device+0x60/0xe0 ib_unregister_device+0x24/0x38 hns_roce_exit+0x3c/0x138 [hns_roce] __hns_roce_hw_v2_uninit_instance.isra.30+0x28/0x50 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance+0x44/0x60 [hns_roce_hw_v2] hclge_uninit_client_instance+0x15c/0x238 [hclge] hnae3_uninit_client_instance+0x84/0xa8 [hnae3] hnae3_unregister_client+0x84/0x158 [hnae3] hns_roce_hw_v2_exit+0x14/0x20 [hns_roce_hw_v2] __arm64_sys_delete_module+0x20c/0x308 el0_svc_handler+0xbc/0x210 el0_svc+0x8/0xc Allocated by task 255: __kasan_kmalloc.isra.0+0xd0/0x180 kasan_kmalloc+0xc/0x18 __kmalloc+0x16c/0x328 hns_roce_init_hem_table+0x20c/0x428 [hns_roce] hns_roce_init+0x214/0xfe0 [hns_roce] __hns_roce_hw_v2_init_instance+0x284/0x330 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0xd0/0x1b8 [hns_roce_hw_v2] hclge_init_roce_client_instance+0x180/0x310 [hclge] hclge_init_client_instance+0xcc/0x508 [hclge] hnae3_init_client_instance.part.3+0x3c/0x80 [hnae3] hnae3_register_client+0x134/0x1a8 [hnae3] 0xffff200009c00014 do_one_initcall+0x9c/0x3e0 do_init_module+0xd4/0x2d8 load_module+0x3284/0x3690 __se_sys_init_module+0x274/0x308 __arm64_sys_init_module+0x40/0x50 el0_svc_handler+0xbc/0x210 el0_svc+0x8/0xc Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff802185e06300 which belongs to the cache kmalloc-8k of size 8192 The buggy address is located 0 bytes to the right of 8192-byte region [ffff802185e06300, ffff802185e08300) The buggy address belongs to the page: page:ffff7fe008617800 refcount:1 mapcount:0 mapping:ffff802340020e00 index:0x0 compound_mapcount: 0 flags: 0x5fffe00000010200(slab|head) raw: 5fffe00000010200 dead000000000100 dead000000000200 ffff802340020e00 raw: 0000000000000000 00000000803e003e 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff802185e08200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff802185e08280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff802185e08300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff802185e08380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff802185e08400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Disabling lock debugging due to kernel taint Fixes: a25d13cb ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08") Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 7a14826e ] Currently when the call to ext4_htree_store_dirent fails the error return variable 'ret' is is not being set to the error code and variable count is instead, hence the error code is not being returned. Fix this by assigning ret to the error return code. Addresses-Coverity: ("Unused value") Fixes: 8af0f082 ("ext4: fix readdir error in the case of inline_data+dir_index") Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Iuliana Prodan authored
[ Upstream commit c59a1d41 ] Check the return value of the hardware registration for caam_rng and free resources in case of failure. Fixes: e24f7c9e ("crypto: caam - hwrng support") Signed-off-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by:
Horia Geanta <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Chuhong Yuan authored
[ Upstream commit 4a8937b8 ] The atomic_dec_and_test() is not safe because it is outside of locks. Move the locks of t4_smte_free() to its caller, cxgb4_smt_release() to protect the atomic decrement. Fixes: 3bdb376e ("cxgb4: introduce SMT ops to prepare for SMAC rewrite support") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
Rayagonda Kokatanur authored
[ Upstream commit 79629d0f ] Fix data transfer width settings based on DT field 'spi-rx-bus-width' to configure BSPI in single, dual or quad mode by using data width and not the command width. Fixes: 5f195ee7 ("spi: bcm-qspi: Implement the spi_mem interface") Signed-off-by:
Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Link: https://lore.kernel.org/r/1565086070-28451-1-git-send-email-rayagonda.kokatanur@broadcom.comSigned-off-by:
-
Jesper Dangaard Brouer authored
[ Upstream commit 065af355 ] When generic-XDP was moved to a later processing step by commit 458bf2f2 ("net: core: support XDP generic on stacked devices.") a regression was introduced when using bpf_xdp_adjust_head. The issue is that after this commit the skb->network_header is now changed prior to calling generic XDP and not after. Thus, if the header is changed by XDP (via bpf_xdp_adjust_head), then skb->network_header also need to be updated again. Fix by calling skb_reset_network_header(). Fixes: 458bf2f2 ("net: core: support XDP generic on stacked devices.") Reported-by:
Brandon Cazander <brandon.cazander@multapplied.net> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Chuhong Yuan authored
[ Upstream commit 33808413 ] Use devm_add_action_or_reset to call tsl2772_chip_off when the device is removed. This also fixes the issue that the chip is turned off before the device is unregistered. Not marked for stable as fairly hard to hit the bug and this is in the middle of a set making other cleanups to the driver. Hence will probably need explicit backporting. Signed-off-by:
Brian Masney <masneyb@onstation.org> Tested-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Steve French authored
[ Upstream commit 247bc947 ] Fixes: 72abe3bc ("signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig") The global change from force_sig caused module unloading of cifs.ko to fail (since the cifsd process could not be killed, "rmmod cifs" now would always fail) Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Ronnie Sahlberg <lsahlber@redhat.com> CC: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
