- 22 Jun, 2019 40 commits
-
-
Igor Russkikh authored
[ Upstream commit 31bafc49 ] In case no other traffic happening on the ring, full tx cleanup may not be completed. That may cause socket buffer to overflow and tx traffic to stuck until next activity on the ring happens. This is due to logic error in budget variable decrementor. Variable is compared with zero, and then post decremented, causing it to become MAX_INT. Solution is remove decrementor from the `for` statement and rewrite it in a clear way. Fixes: b647d398 ("net: aquantia: Add tx clean budget and valid budget handling logic") Signed-off-by:
Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Lucas Stach authored
[ Upstream commit 1396500d ] The devcoredump needs to operate on a stable state of the MMU while it is writing the MMU state to the coredump. The missing lock allowed both the userspace submit, as well as the GPU job finish paths to mutate the MMU state while a coredump is under way. Fixes: a8c21a54 (drm/etnaviv: add initial etnaviv DRM driver) Reported-by:
David Jander <david@protonic.nl> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Tested-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 9a51c6b1 ] Both acpi_pci_need_resume() and acpi_dev_needs_resume() check if the current ACPI wakeup configuration of the device matches what is expected as far as system wakeup from sleep states is concerned, as reflected by the device_may_wakeup() return value for the device. However, they only should do that if wakeup.flags.valid is set for the device's ACPI companion, because otherwise the wakeup.prepare_count value for it is meaningless. Add the missing wakeup.flags.valid checks to these functions. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Kees Cook authored
[ Upstream commit 3e66b7cc ] Building with Clang reports the redundant use of MODULE_DEVICE_TABLE(): drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table' MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids); ^ ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE' extern typeof(name) __mod_##type##__##name##_device_table \ ^ <scratch space>:90:1: note: expanded from here __mod_eisa__de4x5_eisa_ids_device_table ^ drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids); ^ ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE' extern typeof(name) __mod_##type##__##name##_device_table \ ^ <scratch space>:85:1: note: expanded from here __mod_eisa__de4x5_eisa_ids_device_table ^ This drops the one further from the table definition to match the common use of MODULE_DEVICE_TABLE(). Fixes: 07563c71 ("EISA bus MODALIAS attributes support") Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Ioana Radulescu authored
[ Upstream commit bd8460fa ] Use PTR_ERR_OR_ZERO instead of PTR_ERR in cases where zero is a valid input. Reported by smatch. Signed-off-by:
Ioana Radulescu <ruxandra.radulescu@nxp.com> Signed-off-by:
-
Ioana Radulescu authored
[ Upstream commit 5a20a093 ] Smatch reports a potential spectre vulnerability in the dpaa2-eth driver, where the value of rxnfc->fs.location (which is provided from user-space) is used as index in an array. Add a call to array_index_nospec() to sanitize the access. Signed-off-by:
-
Pavel Begunkov authored
[ Upstream commit a278682d ] If io_copy_iov() fails, it will break the loop and report success, albeit partially completed operation. Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Biao Huang authored
[ Upstream commit f4ca7a92 ] 1. the frequency of csr clock is 66.5MHz, so the csr_clk value should be 0 other than 5. 2. the csr_clk can be got from device tree, so remove initialization here. Fixes: 9992f37e ("stmmac: dwmac-mediatek: add support for mt2712") Signed-off-by:
Biao Huang <biao.huang@mediatek.com> Signed-off-by:
-
Biao Huang authored
[ Upstream commit 5e7f7fc5 ] The specific clk_csr value can be zero, and stmmac_clk is necessary for MDC clock which can be set dynamically. So, change the condition from plat->clk_csr to plat->stmmac_clk to fix clk_csr can't be zero issue. Fixes: cd7201f4 ("stmmac: MDC clock dynamically based on the csr clock input") Signed-off-by:
Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by:
-
Biao Huang authored
[ Upstream commit 4523a561 ] Currently we will not update the receive descriptor tail pointer in stmmac_rx_refill. Rx dma will think no available descriptors and stop once received packets exceed DMA_RX_SIZE, so that the rx only test will fail. Update the receive tail pointer in stmmac_rx_refill to add more descriptors to the rx channel, so packets can be received continually Fixes: 54139cf3 ("net: stmmac: adding multiple buffers for rx") Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit e9646f0f ] The gpio-adp5588 driver uses interfaces that are provided by GPIOLIB_IRQCHIP, so select that symbol in its Kconfig entry. Fixes these build errors: ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_handler’: ../drivers/gpio/gpio-adp5588.c:266:26: error: ‘struct gpio_chip’ has no member named ‘irq’ dev->gpio_chip.irq.domain, gpio)); ^ ../drivers/gpio/gpio-adp5588.c: In function ‘adp5588_irq_setup’: ../drivers/gpio/gpio-adp5588.c:298:2: error: implicit declaration of function ‘gpiochip_irqchip_add_nested’ [-Werror=implicit-function-declaration] ret = gpiochip_irqchip_add_nested(&dev->gpio_chip, ^ ../drivers/gpio/gpio-adp5588.c:307:2: error: implicit declaration of function ‘gpiochip_set_nested_irqchip’ [-Werror=implicit-function-declaration] gpiochip_set_nested_irqchip(&dev->gpio_chip, ^ Fixes: 459773ae ("gpio: adp5588-gpio: support interrupt controller") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: linux-gpio@vger.kernel.org Reviewed-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 4d839dd9 ] We must use {READ,WRITE}_ONCE() on rb->user_page data such that concurrent usage will see whole values. A few key sites were missing this. Suggested-by:
Yabin Cui <yabinc@google.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: acme@kernel.org Cc: mark.rutland@arm.com Cc: namhyung@kernel.org Fixes: 7b732a75 ("perf_counter: new output ABI - part 1") Link: http://lkml.kernel.org/r/20190517115418.394192145@infradead.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 3f9fbe9b ] Similar to how decrementing rb->next too early can cause data_head to (temporarily) be observed to go backward, so too can this happen when we increment too late. This barrier() ensures the rb->head load happens after the increment, both the one in the 'goto again' path, as the one from perf_output_get_handle() -- albeit very unlikely to matter for the latter. Suggested-by:
-
Yabin Cui authored
[ Upstream commit 1b038c6e ] In perf_output_put_handle(), an IRQ/NMI can happen in below location and write records to the same ring buffer: ... local_dec_and_test(&rb->nest) ... <-- an IRQ/NMI can happen here rb->user_page->data_head = head; ... In this case, a value A is written to data_head in the IRQ, then a value B is written to data_head after the IRQ. And A > B. As a result, data_head is temporarily decreased from A to B. And a reader may see data_head < data_tail if it read the buffer frequently enough, which creates unexpected behaviors. This can be fixed by moving dec(&rb->nest) to after updating data_head, which prevents the IRQ/NMI above from updating data_head. [ Split up by peterz. ] Signed-off-by:
-
Frank van der Linden authored
[ Upstream commit 2ac44ab6 ] For F17h AMD CPUs, the CPB capability ('Core Performance Boost') is forcibly set, because some versions of that chip incorrectly report that they do not have it. However, a hypervisor may filter out the CPB capability, for good reasons. For example, KVM currently does not emulate setting the CPB bit in MSR_K7_HWCR, and unchecked MSR access errors will be thrown when trying to set it as a guest: unchecked MSR access error: WRMSR to 0xc0010015 (tried to write 0x0000000001000011) at rIP: 0xffffffff890638f4 (native_write_msr+0x4/0x20) Call Trace: boost_set_msr+0x50/0x80 [acpi_cpufreq] cpuhp_invoke_callback+0x86/0x560 sort_range+0x20/0x20 cpuhp_thread_fun+0xb0/0x110 smpboot_thread_fn+0xef/0x160 kthread+0x113/0x130 kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x35/0x40 To avoid this issue, don't forcibly set the CPB capability for a CPU when running under a hypervisor. Signed-off-by:
Frank van der Linden <fllinden@amazon.com> Acked-by:
Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: jiaxun.yang@flygoat.com Fixes: 02371991 ("x86/CPU/AMD: Set the CPB bit unconditionally on F17h") Link: http://lkml.kernel.org/r/20190522221745.GA15789@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com [ Minor edits to the changelog. ] Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit ccfb62f2 ] The user can change the device_name with the IMSETDEVNAME ioctl, but we need to ensure that the user's name is NUL terminated. Otherwise it could result in a buffer overflow when we copy the name back to the user with IMGETDEVINFO ioctl. I also changed two strcpy() calls which handle the name to strscpy(). Hopefully, there aren't any other ways to create a too long name, but it's nice to do this as a kernel hardening measure. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit 5bce256f ] In xhci_debugfs_create_slot(), kzalloc() can fail and dev->debugfs_private will be NULL. In xhci_debugfs_create_endpoint(), dev->debugfs_private is used without any null-pointer check, and can cause a null pointer dereference. To fix this bug, a null-pointer check is added in xhci_debugfs_create_endpoint(). This bug is found by a runtime fuzzing tool named FIZZER written by us. [subjet line change change, add potential -Mathais] Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Anju T Sudhakar authored
[ Upstream commit b59bd352 ] Currently init_imc_pmu() can fail either because we try to register an IMC unit with an invalid domain (i.e an IMC node not supported by the kernel) or something went wrong while registering a valid IMC unit. In both the cases kernel provides a 'Register failed' error message. For example when trace-imc node is not supported by the kernel, but skiboot advertises a trace-imc node we print: IMC Unknown Device type IMC PMU (null) Register failed To avoid confusion just print the unknown device type message, before attempting PMU registration, so the second message isn't printed. Fixes: 8f95faaa ("powerpc/powernv: Detect and create IMC device") Reported-by:
Pavaman Subramaniyam <pavsubra@in.ibm.com> Signed-off-by:
Anju T Sudhakar <anju@linux.vnet.ibm.com> Reviewed-by:
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> [mpe: Reword change log a bit] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 1cc54078 ] We need to always call clkdm_clk_enable() and clkdm_clk_disable() even the clkctrl clock(s) enabled for the domain do not have any gate register bits. Otherwise clockdomains may never get enabled except when devices get probed with the legacy "ti,hwmods" devicetree property. Fixes: 88a17252 ("clk: ti: add support for clkctrl clocks") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Jeffrin Jose T authored
[ Upstream commit 82ce6eb1 ] A test for the basic NAT functionality uses ip command which needs veth device. There is a condition where the kernel support for veth is not compiled into the kernel and the test script breaks. This patch contains code for reasonable error display and correct code exit. Signed-off-by:
Jeffrin Jose T <jeffrin@rajagiritech.edu.in> Acked-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 719c7d56 ] BUG: KASAN: use-after-free in ip_vs_in.part.29+0xe8/0xd20 [ip_vs] Read of size 4 at addr ffff8881e9b26e2c by task sshd/5603 CPU: 0 PID: 5603 Comm: sshd Not tainted 4.19.39+ #30 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: dump_stack+0x71/0xab print_address_description+0x6a/0x270 kasan_report+0x179/0x2c0 ip_vs_in.part.29+0xe8/0xd20 [ip_vs] ip_vs_in+0xd8/0x170 [ip_vs] nf_hook_slow+0x5f/0xe0 __ip_local_out+0x1d5/0x250 ip_local_out+0x19/0x60 __tcp_transmit_skb+0xba1/0x14f0 tcp_write_xmit+0x41f/0x1ed0 ? _copy_from_iter_full+0xca/0x340 __tcp_push_pending_frames+0x52/0x140 tcp_sendmsg_locked+0x787/0x1600 ? tcp_sendpage+0x60/0x60 ? inet_sk_set_state+0xb0/0xb0 tcp_sendmsg+0x27/0x40 sock_sendmsg+0x6d/0x80 sock_write_iter+0x121/0x1c0 ? sock_sendmsg+0x80/0x80 __vfs_write+0x23e/0x370 vfs_write+0xe7/0x230 ksys_write+0xa1/0x120 ? __ia32_sys_read+0x50/0x50 ? __audit_syscall_exit+0x3ce/0x450 do_syscall_64+0x73/0x200 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7ff6f6147c60 Code: 73 01 c3 48 8b 0d 28 12 2d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 5d 73 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 RSP: 002b:00007ffd772ead18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000034 RCX: 00007ff6f6147c60 RDX: 0000000000000034 RSI: 000055df30a31270 RDI: 0000000000000003 RBP: 000055df30a31270 R08: 0000000000000000 R09: 0000000000000000 R10: 00007ffd772ead70 R11: 0000000000000246 R12: 00007ffd772ead74 R13: 00007ffd772eae20 R14: 00007ffd772eae24 R15: 000055df2f12ddc0 Allocated by task 6052: kasan_kmalloc+0xa0/0xd0 __kmalloc+0x10a/0x220 ops_init+0x97/0x190 register_pernet_operations+0x1ac/0x360 register_pernet_subsys+0x24/0x40 0xffffffffc0ea016d do_one_initcall+0x8b/0x253 do_init_module+0xe3/0x335 load_module+0x2fc0/0x3890 __do_sys_finit_module+0x192/0x1c0 do_syscall_64+0x73/0x200 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 6067: __kasan_slab_free+0x130/0x180 kfree+0x90/0x1a0 ops_free_list.part.7+0xa6/0xc0 unregister_pernet_operations+0x18b/0x1f0 unregister_pernet_subsys+0x1d/0x30 ip_vs_cleanup+0x1d/0xd2f [ip_vs] __x64_sys_delete_module+0x20c/0x300 do_syscall_64+0x73/0x200 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff8881e9b26600 which belongs to the cache kmalloc-4096 of size 4096 The buggy address is located 2092 bytes inside of 4096-byte region [ffff8881e9b26600, ffff8881e9b27600) The buggy address belongs to the page: page:ffffea0007a6c800 count:1 mapcount:0 mapping:ffff888107c0e600 index:0x0 compound_mapcount: 0 flags: 0x17ffffc0008100(slab|head) raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff888107c0e600 raw: 0000000000000000 0000000080070007 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected while unregistering ipvs module, ops_free_list calls __ip_vs_cleanup, then nf_unregister_net_hooks be called to do remove nf hook entries. It need a RCU period to finish, however net->ipvs is set to NULL immediately, which will trigger NULL pointer dereference when a packet is hooked and handled by ip_vs_in where net->ipvs is dereferenced. Another scene is ops_free_list call ops_free to free the net_generic directly while __ip_vs_cleanup finished, then calling ip_vs_in will triggers use-after-free. This patch moves nf_unregister_net_hooks from __ip_vs_cleanup() to __ip_vs_dev_cleanup(), where rcu_barrier() is called by unregister_pernet_device -> unregister_pernet_operations, that will do the needed grace period. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: efe41606 ("ipvs: convert to use pernet nf_hook api") Suggested-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Phil Sutter authored
[ Upstream commit e633508a ] NFTA_FIB_F_PRESENT flag was not always honored since eval functions did not call nft_fib_store_result in all cases. Given that in all callsites there is a struct net_device pointer available which holds the interface data to be stored in destination register, simplify nft_fib_store_result() to just accept that pointer instead of the nft_pktinfo pointer and interface index. This also allows to drop the index to interface lookup previously needed to get the name associated with given index. Fixes: 055c4b34 ("netfilter: nft_fib: Support existence check") Signed-off-by:
Phil Sutter <phil@nwl.cc> Signed-off-by:
-
Jagdish Motwani authored
[ Upstream commit 946c0d8e ] This patch fixes netfilter hook traversal when there are more than 1 hooks returning NF_QUEUE verdict. When the first queue reinjects the packet, 'nf_reinject' starts traversing hooks with a proper hook_index. However, if it again receives a NF_QUEUE verdict (by some other netfilter hook), it queues the packet with a wrong hook_index. So, when the second queue reinjects the packet, it re-executes hooks in between. Fixes: 960632ec ("netfilter: convert hook list to an array") Signed-off-by:
Jagdish Motwani <jagdish.motwani@sophos.com> Signed-off-by:
-
Stephane Eranian authored
[ Upstream commit 23e3983a ] This patch fixes an bug revealed by the following commit: 6b89d4c1 ("perf/x86/intel: Fix INTEL_FLAGS_EVENT_CONSTRAINT* masking") That patch modified INTEL_FLAGS_EVENT_CONSTRAINT() to only look at the event code when matching a constraint. If code+umask were needed, then the INTEL_FLAGS_UEVENT_CONSTRAINT() macro was needed instead. This broke with some of the constraints for PEBS events. Several of them, including the one used for cycles:p, cycles:pp, cycles:ppp fell in that category and caused the event to be rejected in PEBS mode. In other words, on some platforms a cmdline such as: $ perf top -e cycles:pp would fail with -EINVAL. This patch fixes this bug by properly using INTEL_FLAGS_UEVENT_CONSTRAINT() when needed in the PEBS constraint tables. Reported-by:
Stephane Eranian <eranian@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: kan.liang@intel.com Link: http://lkml.kernel.org/r/20190521005246.423-1-eranian@google.comSigned-off-by:
-
Florian Westphal authored
[ Upstream commit 2c82c7e7 ] We can oops in nf_tables_fill_rule_info(). Its not possible to fetch previous element in rcu-protected lists when deletions are not prevented somehow: list_del_rcu poisons the ->prev pointer value. Before rcu-conversion this was safe as dump operations did hold nfnetlink mutex. Pass previous rule as argument, obtained by keeping a pointer to the previous rule during traversal. Fixes: d9adf22a ("netfilter: nf_tables: use call_rcu in netlink dumps") Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 670784fb ] Commit a939bb57 ("pinctrl: intel: implement gpio_irq_enable") was added because clearing interrupt status bit is required to avoid unexpected behavior. Turns out the unmask callback also needs the fix, which can solve weird IRQ triggering issues on I2C touchpad ELAN1200. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit fea69916 ] If ->hif_read_reg() or ->hif_write_reg() fail then the code unlocks and keeps executing. It should just return. Fixes: c5c77ba1 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit ca4e4efb ] These are accidentally returning positive EINVAL instead of negative -EINVAL. Some of the callers treat positive values as success. Fixes: 7b3ad5ab ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.") Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Chengguang Xu authored
[ Upstream commit f2dcb884 ] Set sb->s_root to NULL when failing from __getname(), so that we can avoid double dput and unnecessary operations in generic_shutdown_super(). Signed-off-by:
Chengguang Xu <cgxu519@gmail.com> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Reviewed-by:
Gao Xiang <gaoxiang25@huawei.com> Signed-off-by:
-
Steve Moskovchenko authored
[ Upstream commit 1615fe41 ] The MPU6050 driver has recently gained support for the ICM20602 IMU, which is very similar to MPU6xxx. However, the ICM20602's FIFO data specifically includes temperature readings, which were not present on MPU6xxx parts. As a result, the driver will under-read the ICM20602's FIFO register, causing the same (partial) sample to be returned for all reads, until the FIFO overflows. Fix this by adding a table of scan elements specifically for the ICM20602, which takes the extra temperature data into consideration. While we're at it, fix the temperature offset and scaling on ICM20602, since it uses different scale/offset constants than the rest of the MPU6xxx devices. Signed-off-by:
Steve Moskovchenko <stevemo@skydio.com> Fixes: 22904bdf ("iio: imu: mpu6050: Add support for the ICM 20602 IMU") Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Alaa Hleihel authored
After introducing dedicated uplink representor, the netdev instance set over the esw manager vport (PF) became no longer in use, so it was removed in the cited commit once we're on switchdev mode. However, the mlx5e_detach function was not updated accordingly, and it still tries to detach a non-existing netdev, causing a kernel crash. This patch fixes this issue. Fixes: aec002f6 ("net/mlx5e: Uninstantiate esw manager vport netdev on switchdev mode") Signed-off-by:
Alaa Hleihel <alaa@mellanox.com> Reviewed-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Willem de Bruijn authored
[ Upstream commit 522924b5 ] The below patch fixes an incorrect zerocopy refcnt increment when appending with MSG_MORE to an existing zerocopy udp skb. send(.., MSG_ZEROCOPY | MSG_MORE); // refcnt 1 send(.., MSG_ZEROCOPY | MSG_MORE); // refcnt still 1 (bar frags) But it missed that zerocopy need not be passed at the first send. The right test whether the uarg is newly allocated and thus has extra refcnt 1 is not !skb, but !skb_zcopy. send(.., MSG_MORE); // <no uarg> send(.., MSG_ZEROCOPY); // refcnt 1 Fixes: 100f6d8e ("net: correct zerocopy refcnt with udp MSG_MORE") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Eli Britstein authored
Stacked devices like bond interface may have a VLAN device on top of them. Detect lag state correctly under this condition, and return the correct routed net device, according to it the encap header is built. Fixes: e32ee6c7 ("net/mlx5e: Support tunnel encap over tagged Ethernet") Signed-off-by:
Eli Britstein <elibr@mellanox.com> Reviewed-by:
-
Petr Machata authored
Due to an issue on Spectrum-2, in front-panel ports split four ways, 2 out of 32 port buffers cannot be used. To work around this, the next FW release will mark them as unused, and will report correspondingly lower total shared buffer size. mlxsw will pick up the new value through a query to cap_total_buffer_size resource. However the initial size for shared buffer pool 0 is hard-coded and therefore needs to be updated. Thus reduce the pool size by 2.7 MiB (which corresponds to 2/32 of the total size of 42 MiB), and round down to the whole number of cells. Fixes: fe099bf6 ("mlxsw: spectrum_buffers: Add Spectrum-2 shared buffer configuration") Signed-off-by:
Petr Machata <petrm@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Raed Salem authored
The cited commit changed the initialization placement of the eswitch attributes so it is done prior to parse tc actions function call, including among others the in_rep and in_mdev fields which are mistakenly reassigned inside the parse actions function. This breaks the source port matching criteria of the peer redirect rule. Fix by removing the now redundant reassignment of the already initialized fields. Fixes: 988ab9c7 ("net/mlx5e: Introduce mlx5e_flow_esw_attr_init() helper") Signed-off-by:
Raed Salem <raeds@mellanox.com> Reviewed-by:
-
Jiri Pirko authored
The TOS value was not extracted correctly. Fix it. Fixes: 87996f91 ("mlxsw: spectrum_flower: Add support for ip tos") Reported-by:
Alexander Petrovskiy <alexpe@mellanox.com> Signed-off-by:
-
Chris Mi authored
After we have a dedicated uplink representor, the new netdev ops doesn't support ndo_set_feature. Because of that, we can't change some features, eg. rxvlan. Now add it back. In this patch, I also do a cleanup for the features flag handling, eg. remove duplicate NETIF_F_HW_TC flag setting. Fixes: aec002f6 ("net/mlx5e: Uninstantiate esw manager vport netdev on switchdev mode") Signed-off-by:
Chris Mi <chrism@mellanox.com> Reviewed-by:
Vlad Buslov <vladbu@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
The driver tries to periodically refresh neighbours that are used to reach nexthops. This is done by periodically calling neigh_event_send(). However, if the neighbour becomes dead, there is nothing we can do to return it to a connected state and the above function call is basically a NOP. This results in the nexthop never being written to the device's adjacency table and therefore never used to forward packets. Fix this by dropping our reference from the dead neighbour and associating the nexthop with a new neigbhour which we will try to refresh. Fixes: a7ff87ac ("mlxsw: spectrum_router: Implement next-hop routing") Signed-off-by:
Alex Veber <alexve@mellanox.com> Tested-by:
-
Edward Srouji authored
Add missing entries for create/destroy UCTX and UMEM commands. This could get us wrong "unknown FW command" error in flows where we unbind the device or reset the driver. Also the translation of these commands from opcodes to string was missing. Fixes: 6e3722ba ("IB/mlx5: Use the correct commands for UMEM and UCTX allocation") Signed-off-by:
Edward Srouji <edwards@mellanox.com> Signed-off-by:
-
Maxime Chevallier authored
[ Upstream commit f0d2ca15 ] Using ethtool, users can specify a classification action matching on the full vlan tag, which includes the DEI bit (also previously called CFI). However, when converting the ethool_flow_spec to a flow_rule, we use dissector keys to represent the matching patterns. Since the vlan dissector key doesn't include the DEI bit, this information was silently discarded when translating the ethtool flow spec in to a flow_rule. This commit adds the DEI bit into the vlan dissector key, and allows propagating the information to the driver when parsing the ethtool flow spec. Fixes: eca4205f ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator") Reported-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by:
-
