An error occurred fetching the project authors.
- 27 Jan, 2020 6 commits
-
-
Chuck Lever authored
commit 5866efa8 upstream. gss_read_proxy_verf() assumes things about the XDR buffer containing the RPC Call that are not true for buffers generated by svc_rdma_recv(). RDMA's buffers look more like what the upper layer generates for sending: head is a kmalloc'd buffer; it does not point to a page whose contents are contiguous with the first page in the buffers' page array. The result is that ACCEPT_SEC_CONTEXT via RPC/RDMA has stopped working on Linux NFS servers that use gssproxy. This does not affect clients that use only TCP to send their ACCEPT_SEC_CONTEXT operation (that's all Linux clients). Other clients, like Solaris NFS clients, send ACCEPT_SEC_CONTEXT on the same transport as they send all other NFS operations. Such clients can send ACCEPT_SEC_CONTEXT via RPC/RDMA. I thought I had found every direct reference in the server RPC code to the rqstp->rq_pages field. Bug found at the 2019 Westford NFS bake-a-thon. Fixes: 3316f063 ("svcrdma: Persistently allocate and DMA- ... ") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Tested-by:
Bill Baker <bill.baker@oracle.com> Reviewed-by:
Simo Sorce <simo@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jarkko Nikula authored
commit 3f31bc67 upstream. It turned out Intel Gemini Lake doesn't use the same I2C timing parameters as Broxton. I got confirmation from the Windows team that Gemini Lake systems should use updated timing parameters that differ from those used in Broxton based systems. Fixes: f80e78aa ("mfd: intel-lpss: Add Intel Gemini Lake PCI IDs") Tested-by:
Chris Chiu <chiu@endlessm.com> Signed-off-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Alain Volmat authored
commit 7787657d upstream. Fix a typo in the free slave id search loop. Instead of I2C_CLIENT_PEC, it should have been I2C_CLIENT_TEN. The slave id 1 can only handle 7-bit addresses and thus is not eligible in case of 10-bit addresses. As a matter of fact none of the slave id support I2C_CLIENT_PEC, overall check is performed at the beginning of the stm32f7_i2c_reg_slave function. Fixes: 60d609f3 ("i2c: i2c-stm32f7: Add slave support") Signed-off-by:
Alain Volmat <alain.volmat@st.com> Reviewed-by:
Pierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Alain Volmat authored
commit 52d3be71 upstream. The IP can handle two slave addresses. One address can either be 7 bits or 10 bits while the other can only be 7 bits. In order to ensure that a 10 bits address can always be allocated (assuming there is only one 7 bits address already allocated), pick up the 7-bits only address slot in priority when performing a 7-bits address allocation. Fixes: 60d609f3 ("i2c: i2c-stm32f7: Add slave support") Signed-off-by:
-
Jan Kara authored
commit 3dd4d40b upstream. Flags passed to Q_XQUOTARM were not sanity checked for invalid values. Fix that. Fixes: 9da93f9b ("xfs: fix Q_XQUOTARM ioctl") Reported-by:
Yang Xu <xuyang2018.jy@cn.fujitsu.com> Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 3e6b472f which is commit ef1491e7 upstream. Chris reports that this commit has problems and should not have been backported to 4.19.y Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Waiman Long <longman@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Cc: Ingo Molnar <mingo@kernel.org> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
-
- 23 Jan, 2020 34 commits
-
-
Greg Kroah-Hartman authored
-
Eddie James authored
commit 9861ff95 upstream. Since i2c_smbus functions can sleep, the brightness setting function for this driver must be the blocking version to avoid scheduling while atomic. Signed-off-by:
Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20191106200106.29519-2-eajames@linux.ibm.com Fixes: ef9e1cdf ("hwmon: (pmbus/cffps) Add led class device for power supply fault led") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Stephan Gerhold authored
commit 458ea3ad upstream. Those regulators are not actually supported by the AB8500 regulator driver. There is no ab8500_regulator_info for them and no entry in ab8505_regulator_match. As such, they cannot be registered successfully, and looking them up in ab8505_regulator_match causes an out-of-bounds array read. Fixes: 547f384f ("regulator: ab8500: add support for ab8505") Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191106173125.14496-2-stephan@gerhold.netSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Baolin Wang authored
commit 9629dbda upstream. The syscon_regmap_lookup_by_phandle() will never return NULL, thus use IS_ERR() to validate the return value instead of IS_ERR_OR_NULL(). Fixes: d41f59fd ("clk: sprd: Add common infrastructure") Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Link: https://lkml.kernel.org/r/1995139bee5248ff3e9d46dc715968f212cfc4cc.1570520268.git.baolin.wang@linaro.orgSigned-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Masami Hiramatsu authored
commit 07d36985 upstream. Since there are some DIE which has only ranges instead of the combination of entrypc/highpc, address verification must use dwarf_haspc() instead of dwarf_entrypc/dwarf_highpc. Also, the ranges only DIE will have a partial code in different section (e.g. unlikely code will be in text.unlikely as "FUNC.cold" symbol). In that case, we can not use dwarf_entrypc() or die_entrypc(), because the offset from original DIE can be a minus value. Instead, this simply gets the symbol and offset from symtab. Without this patch; # perf probe -D clear_tasks_mm_cpumask:1 Failed to get entry address of clear_tasks_mm_cpumask Error: Failed to add events. And with this patch: # perf probe -D clear_tasks_mm_cpumask:1 p:probe/clear_tasks_mm_cpumask clear_tasks_mm_cpumask+0 p:probe/clear_tasks_mm_cpumask_1 clear_tasks_mm_cpumask+5 p:probe/clear_tasks_mm_cpumask_2 clear_tasks_mm_cpumask+8 p:probe/clear_tasks_mm_cpumask_3 clear_tasks_mm_cpumask+16 p:probe/clear_tasks_mm_cpumask_4 clear_tasks_mm_cpumask+82 Committer testing: I managed to reproduce the above: [root@quaco ~]# perf probe -D clear_tasks_mm_cpumask:1 p:probe/clear_tasks_mm_cpumask _text+919968 p:probe/clear_tasks_mm_cpumask_1 _text+919973 p:probe/clear_tasks_mm_cpumask_2 _text+919976 [root@quaco ~]# But then when trying to actually put the probe in place, it fails if I use :0 as the offset: [root@quaco ~]# perf probe -L clear_tasks_mm_cpumask | head -5 <clear_tasks_mm_cpumask@/usr/src/debug/kernel-5.2.fc30/linux-5.2.18-200.fc30.x86_64/kernel/cpu.c:0> 0 void clear_tasks_mm_cpumask(int cpu) 1 { 2 struct task_struct *p; [root@quaco ~]# perf probe clear_tasks_mm_cpumask:0 Probe point 'clear_tasks_mm_cpumask' not found. Error: Failed to add events. [root@quaco The next patch is needed to fix this case. Fixes: 576b5237 ("perf probe: Fix probing symbols with optimization suffix") Reported-by:
Arnaldo Carvalho de Melo <acme@kernel.org> Tested-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lore.kernel.org/lkml/157199318513.8075.10463906803299647907.stgit@devnote2Signed-off-by:
-
Bart Van Assche authored
commit b1335f5b upstream. This patch fixes an unintended sign extension on left shifts. From Colin King: "Shifting a u8 left will cause the value to be promoted to an integer. If the top bit of the u8 is set then the following conversion to an u64 will sign extend the value causing the upper 32 bits to be set in the result." Fix this by using get_unaligned_be*() instead. Fixes: bf816235 ("[SCSI] add scsi trace core functions and put trace points") Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Cc: Douglas Gilbert <dgilbert@interlog.com> Link: https://lore.kernel.org/r/20191101211447.187151-1-bvanassche@acm.orgReported-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Martin Wilck authored
commit d341e9a8 upstream. In qla2x00_find_all_fabric_devs(), fcport->flags & FCF_LOGIN_NEEDED is a necessary condition for logging into new rports, but not for dropping lost ones. Fixes: 726b8548 ("qla2xxx: Add framework for async fabric discovery") Link: https://lore.kernel.org/r/20191122221912.20100-2-martin.wilck@suse.comTested-by:
David Bond <dbond@suse.com> Signed-off-by:
Martin Wilck <mwilck@suse.com> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Huacai Chen authored
commit 45dc8f2d upstream. Commit 4fa18345 ("scsi: qla2xxx: Utilize pci_alloc_irq_vectors/ pci_free_irq_vectors calls.") use pci_alloc_irq_vectors() to replace pci_enable_msi() but it didn't handle the return value correctly. This bug make qla2x00 always fail to setup MSI if MSI-X fail, so fix it. BTW, improve the log message of return value in qla2x00_request_irqs() to avoid confusion. Fixes: 4fa18345 ("scsi: qla2xxx: Utilize pci_alloc_irq_vectors/pci_free_irq_vectors calls.") Cc: Michael Hernandez <michael.hernandez@cavium.com> Link: https://lore.kernel.org/r/1574314847-14280-1-git-send-email-chenhc@lemote.comSigned-off-by:
Huacai Chen <chenhc@lemote.com> Acked-by:
-
Bart Van Assche authored
commit c941e0d1 upstream. Print the string for which conversion failed instead of printing the function name twice. Fixes: 2650d71e ("target: move transport ID handling to the core") Cc: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20191107215525.64415-1-bvanassche@acm.orgSigned-off-by:
-
Pan Bian authored
commit 29d28f2b upstream. The member hba->pcidev may be used after its reference is dropped. Move the put function to where it is never used to avoid potential use after free issues. Fixes: a7717180 ("[SCSI] bnx2i: Removed the reference to the netdev->base_addr") Link: https://lore.kernel.org/r/1573043541-19126-1-git-send-email-bianpan2016@163.comSigned-off-by:
Pan Bian <bianpan2016@163.com> Signed-off-by:
-
Pan Bian authored
commit 3fe3d242 upstream. The variable init_fw_cb is released twice, resulting in a double free bug. The call to the function dma_free_coherent() before goto is removed to get rid of potential double free. Fixes: 2a49a78e ("[SCSI] qla4xxx: added IPv6 support.") Link: https://lore.kernel.org/r/1572945927-27796-1-git-send-email-bianpan2016@163.comSigned-off-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
-
Dan Carpenter authored
commit 906ca635 upstream. This error path is missing an unlock. Fixes: 26780d9e ("[SCSI] esas2r: ATTO Technology ExpressSAS 6G SAS/SATA RAID Adapter Driver") Link: https://lore.kernel.org/r/20191022102324.GA27540@mwandaSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jeff Mahoney authored
commit 394440d4 upstream. Commit 60e4cf67 (reiserfs: fix extended attributes on the root directory) introduced a regression open_xa_root started returning -EOPNOTSUPP but it was not handled properly in reiserfs_for_each_xattr. When the reiserfs module is built without CONFIG_REISERFS_FS_XATTR, deleting an inode would result in a warning and chowning an inode would also result in a warning and then fail to complete. With CONFIG_REISERFS_FS_XATTR enabled, the xattr root would always be present for read-write operations. This commit handles -EOPNOSUPP in the same way -ENODATA is handled. Fixes: 60e4cf67 ("reiserfs: fix extended attributes on the root directory") CC: stable@vger.kernel.org # Commit 60e4cf67 was picked up by stable Link: https://lore.kernel.org/r/20200115180059.6935-1-jeffm@suse.comReported-by:
Michael Brunnbauer <brunni@netestate.de> Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Jon Derrick authored
commit 15516bf9 upstream. If the BAR initialization failed it may leave the vmm structure in an unitialized state, leading to a null-pointer-dereference when the vmm is dereferenced during teardown. Signed-off-by:
Jon Derrick <jonathan.derrick@intel.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Sushma Kalakota <sushmax.kalakota@intel.com> Signed-off-by:
-
Jon Derrick authored
commit 12e08beb upstream. If the BAR is zero size, it indicates it was never successfully mapped. Ensure that the BAR is valid during initialization before attempting to use it. Signed-off-by:
-
Jon Derrick authored
commit 307a312d upstream. Check bar1's new vmm creation return value for errors. Signed-off-by:
-
Angelo Dureghello authored
commit 14f89e08 upstream. Due to the use of sizeof(), command size set for the spi transfer was wrong. Driver was sending and receiving always 1 byte less and especially on write, it was hanging. echo -n -e "\\x1\\x2\\x3\\x4" > /dev/mtd1 And read part too now works as expected. hexdump -C -n16 /dev/mtd1 00000000 01 02 03 04 ab f3 ad c2 ab e3 f4 36 dd 38 04 15 00000010 Fixes: 4379075a ("mtd: mchp23k256: Add support for mchp23lcv1024") Signed-off-by:
Angelo Dureghello <angelo.dureghello@timesys.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Sudeep Holla authored
commit 54fb3fe0 upstream. This reverts commit 193d00a2. Commit 951d4885 ("of: Make of_dma_get_range() work on bus nodes") reworked the logic such that of_dma_get_range() works correctly starting from a bus node containing "dma-ranges". Since on Juno we don't have a SoC level bus node and "dma-ranges" is present only in the root node, we get the following error: OF: translation of DMA address(0) to CPU address failed node(/sram@2e000000) OF: translation of DMA address(0) to CPU address failed node(/uart@7ff80000) ... OF: translation of DMA address(0) to CPU address failed node(/mhu@2b1f0000) OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000) OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000) OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000) So let's fix it by dropping the "dma-ranges" property for now. This should be fine since it doesn't represent any kind of device-visible restriction; it was only there for completeness, and we've since given in to the assumption that missing "dma-ranges" implies a 1:1 mapping anyway. We can add it later with a proper SoC bus node and moving all the devices that belong there along with the "dma-ranges" if required. Fixes: 193d00a2 ("arm64: dts: juno: add dma-ranges property") Cc: Rob Herring <robh+dt@kernel.org> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Miquel Raynal authored
commit 2bc26088 upstream. Fix this tiny typo before renaming/changing this file. Fixes: 72a3713f ("arm64: dts: marvell: de-duplicate CP110 description") Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
-
Eric Dumazet authored
commit de95a991 upstream. syzbot (KCSAN) reported a data-race in tick_do_update_jiffies64(): BUG: KCSAN: data-race in tick_do_update_jiffies64 / tick_do_update_jiffies64 write to 0xffffffff8603d008 of 8 bytes by interrupt on cpu 1: tick_do_update_jiffies64+0x100/0x250 kernel/time/tick-sched.c:73 tick_sched_do_timer+0xd4/0xe0 kernel/time/tick-sched.c:138 tick_sched_timer+0x43/0xe0 kernel/time/tick-sched.c:1292 __run_hrtimer kernel/time/hrtimer.c:1514 [inline] __hrtimer_run_queues+0x274/0x5f0 kernel/time/hrtimer.c:1576 hrtimer_interrupt+0x22a/0x480 kernel/time/hrtimer.c:1638 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline] smp_apic_timer_interrupt+0xdc/0x280 arch/x86/kernel/apic/apic.c:1135 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 arch_local_irq_restore arch/x86/include/asm/paravirt.h:756 [inline] kcsan_setup_watchpoint+0x1d4/0x460 kernel/kcsan/core.c:436 check_access kernel/kcsan/core.c:466 [inline] __tsan_read1 kernel/kcsan/core.c:593 [inline] __tsan_read1+0xc2/0x100 kernel/kcsan/core.c:593 kallsyms_expand_symbol.constprop.0+0x70/0x160 kernel/kallsyms.c:79 kallsyms_lookup_name+0x7f/0x120 kernel/kallsyms.c:170 insert_report_filterlist kernel/kcsan/debugfs.c:155 [inline] debugfs_write+0x14b/0x2d0 kernel/kcsan/debugfs.c:256 full_proxy_write+0xbd/0x100 fs/debugfs/file.c:225 __vfs_write+0x67/0xc0 fs/read_write.c:494 vfs_write fs/read_write.c:558 [inline] vfs_write+0x18a/0x390 fs/read_write.c:542 ksys_write+0xd5/0x1b0 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x4c/0x60 fs/read_write.c:620 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 read to 0xffffffff8603d008 of 8 bytes by task 0 on cpu 0: tick_do_update_jiffies64+0x2b/0x250 kernel/time/tick-sched.c:62 tick_nohz_update_jiffies kernel/time/tick-sched.c:505 [inline] tick_nohz_irq_enter kernel/time/tick-sched.c:1257 [inline] tick_irq_enter+0x139/0x1c0 kernel/time/tick-sched.c:1274 irq_enter+0x4f/0x60 kernel/softirq.c:354 entering_irq arch/x86/include/asm/apic.h:517 [inline] entering_ack_irq arch/x86/include/asm/apic.h:523 [inline] smp_apic_timer_interrupt+0x55/0x280 arch/x86/kernel/apic/apic.c:1133 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:60 arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:571 default_idle_call+0x1e/0x40 kernel/sched/idle.c:94 cpuidle_idle_call kernel/sched/idle.c:154 [inline] do_idle+0x1af/0x280 kernel/sched/idle.c:263 cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355 rest_init+0xec/0xf6 init/main.c:452 arch_call_rest_init+0x17/0x37 start_kernel+0x838/0x85e init/main.c:786 x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:490 x86_64_start_kernel+0x72/0x76 arch/x86/kernel/head64.c:471 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Use READ_ONCE() and WRITE_ONCE() to annotate this expected race. Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20191205045619.204946-1-edumazet@google.comSigned-off-by:
-
Johannes Berg authored
commit 24953de0 upstream. Check if set_wiphy_params is assigned and return an error if not, some drivers (e.g. virt_wifi where syzbot reported it) don't have it. Reported-by: syzbot+e8a797964a4180eb57d5@syzkaller.appspotmail.com Reported-by: syzbot+34b582cf32c1db008f8e@syzkaller.appspotmail.com Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20200113125358.ac07f276efff.Ibd85ee1b12e47b9efb00a2adc5cd3fac50da791a@changeidSigned-off-by:
-
Christian Hewitt authored
commit d5f6fa90 upstream. Fix DTC warnings: arch/arm/dts/meson-gxl-s905x-khadas-vim.dtb: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property Fixes: e15d2774 ("ARM64: dts: meson-gxl: add support for the Khadas VIM board") Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Dan Carpenter authored
commit 4a50d454 upstream. The "priv->hw_type" is an enum and in this context GCC will treat it as an unsigned int so the error handling will never trigger. Fixes: a910e4a9 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Jonathan Neuschäfer authored
commit 01493855 upstream. Somehow CONFIG_SIFIVE_PLIC ended up outside of the "IRQ chip support" menu. Fixes: 8237f8bc ("irqchip: add a SiFive PLIC driver") Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
Marc Zyngier <maz@kernel.org> Reviewed-by:
Palmer Dabbelt <palmer@sifive.com> Acked-by:
-
Eric Dumazet authored
commit 216808c6 upstream. At the time commit ce5ec440 ("tcp: ensure epoll edge trigger wakeup when write queue is empty") was added to the kernel, we still had a single write queue, combining rtx and write queues. Once we moved the rtx queue into a separate rb-tree, testing if sk_write_queue is empty has been suboptimal. Indeed, if we have packets in the rtx queue, we probably want to delay the EPOLLOUT generation at the time incoming packets will free them, making room, but more importantly avoiding flooding application with EPOLLOUT events. Solution is to use tcp_rtx_and_write_queues_empty() helper. Fixes: 75c119af ("tcp: implement rb-tree based retransmit queue") Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Nathan Chancellor authored
commit 589b7289 upstream. Clang warns: ../drivers/block/xen-blkfront.c:1117:4: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] nr_parts = PARTS_PER_DISK; ^ ../drivers/block/xen-blkfront.c:1115:3: note: previous statement is here if (err) ^ This is because there is a space at the beginning of this line; remove it so that the indentation is consistent according to the Linux kernel coding style and clang no longer warns. While we are here, the previous line has some trailing whitespace; clean that up as well. Fixes: c80a4209 ("xen-blkfront: handle Xen major numbers other than XENVBD") Link: https://github.com/ClangBuiltLinux/linux/issues/791Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Acked-by:
Roger Pau Monné <roger.pau@citrix.com> Signed-off-by:
-
Petr Machata authored
commit 85005b82 upstream. mlxsw configures Spectrum in such a way that BUM traffic is passed not through its nominal traffic class TC, but through its MC counterpart TC+8. However, when collecting statistics, Qdiscs only look at the nominal TC and ignore the MC TC. Add two helpers to compute the value for logical TC from the constituents, one for backlog, the other for tail drops. Use them throughout instead of going through the xstats pointer directly. Counters for TX bytes and packets are deduced from packet priority counters, and therefore already include BUM traffic. wred_drop counter is irrelevant on MC TCs, because RED is not enabled on them. Fixes: 7b819530 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw ports") 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:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Petr Machata authored
commit ca7609ff upstream. Per-port counter cache used by Qdiscs is updated periodically, unless the port is down. The fact that the cache is not updated for down ports is no problem for most counters, which are relative in nature. However, backlog is absolute in nature, and if there is a non-zero value in the cache around the time that the port goes down, that value just stays there. This value then leaks to offloaded Qdiscs that report non-zero backlog even if there (obviously) is no traffic. The HW does not keep backlog of a downed port, so do likewise: as the port goes down, wipe the backlog value from xstats. Fixes: 075ab8ad ("mlxsw: spectrum: Collect tclass related stats periodically") Signed-off-by:
-
Sergei Shtylyov authored
commit 3249b1e4 upstream. When adding the sh_eth_cpu_data::dual_port flag I forgot to add the flag checks to __sh_eth_get_regs(), causing the non-existing TSU registers to be dumped by 'ethtool' on the single port Ether controllers having TSU... Fixes: a94cf2a6 ("sh_eth: fix TSU init on SH7734/R8A7740") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Pengcheng Yang authored
[ Upstream commit e176b1ba ] When the packet pointed to by retransmit_skb_hint is unlinked by ACK, retransmit_skb_hint will be set to NULL in tcp_clean_rtx_queue(). If packet loss is detected at this time, retransmit_skb_hint will be set to point to the current packet loss in tcp_verify_retransmit_hint(), then the packets that were previously marked lost but not retransmitted due to the restriction of cwnd will be skipped and cannot be retransmitted. To fix this, when retransmit_skb_hint is NULL, retransmit_skb_hint can be reset only after all marked lost packets are retransmitted (retrans_out >= lost_out), otherwise we need to traverse from tcp_rtx_queue_head in tcp_xmit_retransmit_queue(). Packetdrill to demonstrate: // Disable RACK and set max_reordering to keep things simple 0 `sysctl -q net.ipv4.tcp_recovery=0` +0 `sysctl -q net.ipv4.tcp_max_reordering=3` // Establish a connection +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +.1 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7> +0 > S. 0:0(0) ack 1 <...> +.01 < . 1:1(0) ack 1 win 257 +0 accept(3, ..., ...) = 4 // Send 8 data segments +0 write(4, ..., 8000) = 8000 +0 > P. 1:8001(8000) ack 1 // Enter recovery and 1:3001 is marked lost +.01 < . 1:1(0) ack 1 win 257 <sack 3001:4001,nop,nop> +0 < . 1:1(0) ack 1 win 257 <sack 5001:6001 3001:4001,nop,nop> +0 < . 1:1(0) ack 1 win 257 <sack 5001:7001 3001:4001,nop,nop> // Retransmit 1:1001, now retransmit_skb_hint points to 1001:2001 +0 > . 1:1001(1000) ack 1 // 1001:2001 was ACKed causing retransmit_skb_hint to be set to NULL +.01 < . 1:1(0) ack 2001 win 257 <sack 5001:8001 3001:4001,nop,nop> // Now retransmit_skb_hint points to 4001:5001 which is now marked lost // BUG: 2001:3001 was not retransmitted +0 > . 2001:3001(1000) ack 1 Signed-off-by:
Pengcheng Yang <yangpc@wangsu.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Tested-by:
-
Johan Hovold authored
[ Upstream commit 86f3f4cd ] Add missing endpoint sanity check to probe in order to prevent a NULL-pointer dereference (or slab out-of-bounds access) when retrieving the interrupt-endpoint bInterval on ndo_open() in case a device lacks the expected endpoints. Fixes: 40a82917 ("net/usb/r8152: enable interrupt transfer") Cc: hayeswang <hayeswang@realtek.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Vladis Dronov authored
[ Upstream commit 75718584 ] There is a bug in ptp_clock_unregister(), where ptp_cleanup_pin_groups() first frees ptp->pin_{,dev_}attr, but then posix_clock_unregister() needs them to destroy a related sysfs device. These functions can not be just swapped, as posix_clock_unregister() frees ptp which is needed in the ptp_cleanup_pin_groups(). Fix this by calling ptp_cleanup_pin_groups() in ptp_clock_release(), right before ptp is freed. This makes this patch fix an UAF bug in a patch which fixes an UAF bug. Reported-by:
Antti Laakso <antti.laakso@intel.com> Fixes: a33121e5 ("ptp: fix the race between the release of ptp_clock and cdev") Link: https://lore.kernel.org/netdev/3d2bd09735dbdaf003585ca376b7c1e5b69a19bd.camel@intel.com/Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit ddf42039 ] Array utdm_info is declared as an array of MAX_HDLC_NUM (4) elements however up to UCC_MAX_NUM (8) elements are potentially being written to it. Currently we have an array out-of-bounds write error on the last 4 elements. Fix this by making utdm_info UCC_MAX_NUM elements in size. Addresses-Coverity: ("Out-of-bounds write") Fixes: c19b6d24 ("drivers/net: support hdlc function for QE-UCC") Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit f8d7408a ] lan78xx_tx_bh() makes sure to not exceed MAX_SINGLE_PACKET_SIZE bytes in the aggregated packets it builds, but does nothing to prevent large GSO packets being submitted. Pierre-Francois reported various hangs when/if TSO is enabled. For localy generated packets, we can use netif_set_gso_max_size() to limit the size of TSO packets. Note that forwarded packets could still hit the issue, so a complete fix might require implementing .ndo_features_check for this driver, forcing a software segmentation if the size of the TSO packet exceeds MAX_SINGLE_PACKET_SIZE. Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by:
RENARD Pierre-Francois <pfrenard@gmail.com> Tested-by:
-
