- 29 Jan, 2020 1 commit
-
-
Richard Palethorpe authored
[ Upstream commit 0ace17d5 ] write_wakeup can happen in parallel with close/hangup where tty->disc_data is set to NULL and the netdevice is freed thus also freeing disc_data. write_wakeup accesses disc_data so we must prevent close from freeing the netdev while write_wakeup has a non-NULL view of tty->disc_data. We also need to make sure that accesses to disc_data are atomic. Which can all be done with RCU. This problem was found by Syzkaller on SLCAN, but the same issue is reproducible with the SLIP line discipline using an LTP test based on the Syzkaller reproducer. A fix which didn't use RCU was posted by Hillf Danton. Fixes: 661f7fda ("slip: Fix deadlock in write_wakeup") Fixes: a8e83b17 ("slcan: Port write_wakeup deadlock fix from slip") Reported-by: syzbot+017e491ae13c0068598a@syzkaller.appspotmail.com Signed-off-by:
Richard Palethorpe <rpalethorpe@suse.com> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Tyler Hall <tylerwhall@gmail.com> Cc: linux-can@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: syzkaller@googlegroups.com Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 27 Jan, 2020 39 commits
-
-
Greg Kroah-Hartman authored
-
Finn Thain authored
[ Upstream commit 1efdd4bd ] Some platforms execute their timer handler with the interrupt priority level set below 6. That means the handler could be interrupted by another driver and this could lead to re-entry of the timer core. Avoid this by use of local_irq_save/restore for timer interrupt dispatch. This provides mutual exclusion around the timer interrupt flag access which is needed later in this series for the clocksource conversion. Reported-by:
Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1811131407120.2697@nanos.tec.linutronix.deSigned-off-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Christian Hewitt authored
[ Upstream commit 388a2772 ] Fixes: 33344e21 ("arm64: dts: meson-gxm-khadas-vim2: fix Bluetooth support") Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Reviewed-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Fabrice Gasnier authored
[ Upstream commit 1250ed71 ] The interrupt clear flag register is a "write 1 to clear" register. So, only writing ones allows to clear flags: - Replace buggy stm32_clr_bits() by a simple write to clear error flags - Replace useless read/modify/write stm32_set_bits() routine by a simple write to clear TC (transfer complete) flag. Fixes: 4f01d833 ("serial: stm32: fix rx error handling") Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@st.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1574323849-1909-1-git-send-email-fabrice.gasnier@st.comSigned-off-by:
-
Max Gurtovoy authored
[ Upstream commit c1545f1a ] The retured value from ib_dma_map_sg saved in dma_nents variable. To avoid future mismatch between types, define dma_nents as an integer instead of unsigned. Fixes: 57b26497 ("IB/iser: Pass the correct number of entries for dma mapped SGL") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Israel Rukshin <israelr@mellanox.com> Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Acked-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Marc Gonzalez authored
[ Upstream commit 77a49465 ] Keep EXTCON support optional, as some platforms do not need it. Do the same for USB_DWC3_OMAP while we're at it. Fixes: 3def4031 ("usb: dwc3: add EXTCON dependency for qcom") Signed-off-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Jesper Dangaard Brouer authored
[ Upstream commit edbca120 ] In the days of using bpf_load.c the order in which the 'maps' sections were defines in BPF side (*_kern.c) file, were used by userspace side to identify the map via using the map order as an index. In effect the order-index is created based on the order the maps sections are stored in the ELF-object file, by the LLVM compiler. This have also carried over in libbpf via API bpf_map__next(NULL, obj) to extract maps in the order libbpf parsed the ELF-object file. When BTF based maps were introduced a new section type ".maps" were created. I found that the LLVM compiler doesn't create the ".maps" sections in the order they are defined in the C-file. The order in the ELF file is based on the order the map pointer is referenced in the code. This combination of changes lead to xdp_rxq_info mixing up the map file-descriptors in userspace, resulting in very broken behaviour, but without warning the user. This patch fix issue by instead using bpf_object__find_map_by_name() to find maps via their names. (Note, this is the ELF name, which can be longer than the name the kernel retains). Fixes: be5bca44 ("samples: bpf: convert some XDP samples from bpf_load to libbpf") Fixes: 451d1dc8 ("samples: bpf: update map definition to new syntax BTF-defined map") Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Acked-by:
Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/157529025128.29832.5953245340679936909.stgit@firesoulSigned-off-by:
-
Andre Przywara authored
[ Upstream commit 39a1a894 ] Older versions of the Juno *SoC* TRM [1] recommended that the UART clock source should be 7.2738 MHz, whereas the *system* TRM [2] stated a more correct value of 7.3728 MHz. Somehow the wrong value managed to end up in our DT. Doing a prime factorisation, a modulo divide by 115200 and trying to buy a 7.2738 MHz crystal at your favourite electronics dealer suggest that the old value was actually a typo. The actual UART clock is driven by a PLL, configured via a parameter in some board.txt file in the firmware, which reads 7.37 MHz (sic!). Fix this to correct the baud rate divisor calculation on the Juno board. [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0515b.b/DDI0515B_b_juno_arm_development_platform_soc_trm.pdf [2] http://infocenter.arm.com/help/topic/com.arm.doc.100113_0000_07_en/arm_versatile_express_juno_development_platform_(v2m_juno)_technical_reference_manual_100113_0000_07_en.pdf Fixes: 71f867ec ("arm64: Add Juno board device tree.") Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Sam Bobroff authored
[ Upstream commit 62d91dd2 ] The INTERRUPT_CNTL2 register expects a valid DMA address, but is currently set with a GPU MC address. This can cause problems on systems that detect the resulting DMA read from an invalid address (found on a Power8 guest). Instead, use the DMA address of the dummy page because it will always be safe. Fixes: d8f60cfc ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)") Fixes: 25a857fb ("drm/radeon/kms: add support for interrupts on SI") Fixes: a59781bb ("drm/radeon: add support for interrupts on CIK (v5)") Signed-off-by:
Sam Bobroff <sbobroff@linux.ibm.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Chuhong Yuan authored
[ Upstream commit 340049d4 ] When devm_kcalloc fails, it forgets to call edma_free_slot. Replace direct return with failure handler to fix it. Fixes: 1be5336b ("dmaengine: edma: New device tree binding") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20191118073802.28424-1-hslester96@gmail.comSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
zhengbin authored
[ Upstream commit 51590df4 ] Fixes gcc '-Wunused-but-set-variable' warning: fs/afs/dir_edit.c: In function afs_set_contig_bits: fs/afs/dir_edit.c:75:20: warning: variable after set but not used [-Wunused-but-set-variable] fs/afs/dir_edit.c: In function afs_set_contig_bits: fs/afs/dir_edit.c:75:12: warning: variable before set but not used [-Wunused-but-set-variable] fs/afs/dir_edit.c: In function afs_clear_contig_bits: fs/afs/dir_edit.c:100:20: warning: variable after set but not used [-Wunused-but-set-variable] fs/afs/dir_edit.c: In function afs_clear_contig_bits: fs/afs/dir_edit.c:100:12: warning: variable before set but not used [-Wunused-but-set-variable] They are never used since commit 63a4681f. Fixes: 63a4681f ("afs: Locally edit directory data for mkdir/create/unlink/...") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Navid Emamdoost authored
[ Upstream commit 450c3d41 ] In affs_remount if data is provided it is duplicated into new_opts. The allocated memory for new_opts is only released if parse_options fails. There's a bit of history behind new_options, originally there was save/replace options on the VFS layer so the 'data' passed must not change (thus strdup), this got cleaned up in later patches. But not completely. There's no reason to do the strdup in cases where the filesystem does not need to reuse the 'data' again, because strsep would modify it directly. Fixes: c8f33d0b ("affs: kstrdup() memory handling") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> [ update changelog ] Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
H. Nikolaus Schaller authored
[ Upstream commit 16568b4a ] wl1251 and wl1271 have different vendor id and device id. So we need to handle both with sdio quirks. Fixes: 884f3860 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
H. Nikolaus Schaller authored
[ Upstream commit e5db673e ] v4.11-rc1 did introduce a patch series that rearranged the sdio quirks into a header file. Unfortunately this did forget to handle SDIO_VENDOR_ID_TI differently between wl1251 and wl1271 with the result that although the wl1251 was found on the sdio bus, the firmware did not load any more and there was no interface registration. This patch defines separate constants to be used by sdio quirks and drivers. Fixes: 884f3860 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by:
-
Alain Volmat authored
[ Upstream commit d77eceb2 ] Distinguish between the case where dma information is not provided within the DT and the case of an error during the dma init. Exit the probe with error in case of an error during dma init. Fixes: bb8822cb ("i2c: i2c-stm32: Add generic DMA API") 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:
-
Eric Dumazet authored
[ Upstream commit b756ad92 ] KCSAN reported the following data-race [1] Adding a couple of READ_ONCE()/WRITE_ONCE() should silence it. Since the report hinted about multiple cpus using the history concurrently, I added a test avoiding writing on it if the victim slot already contains the desired value. [1] BUG: KCSAN: data-race in fanout_demux_rollover / fanout_demux_rollover read to 0xffff8880b01786cc of 4 bytes by task 18921 on cpu 1: fanout_flow_is_huge net/packet/af_packet.c:1303 [inline] fanout_demux_rollover+0x33e/0x3f0 net/packet/af_packet.c:1353 packet_rcv_fanout+0x34e/0x490 net/packet/af_packet.c:1453 deliver_skb net/core/dev.c:1888 [inline] dev_queue_xmit_nit+0x15b/0x540 net/core/dev.c:1958 xmit_one net/core/dev.c:3195 [inline] dev_hard_start_xmit+0x3f5/0x430 net/core/dev.c:3215 __dev_queue_xmit+0x14ab/0x1b40 net/core/dev.c:3792 dev_queue_xmit+0x21/0x30 net/core/dev.c:3825 neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116 __ip6_finish_output net/ipv6/ip6_output.c:142 [inline] __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127 ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179 ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795 udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173 udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471 inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0x9f/0xc0 net/socket.c:657 ___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311 __sys_sendmmsg+0x123/0x350 net/socket.c:2413 __do_sys_sendmmsg net/socket.c:2442 [inline] __se_sys_sendmmsg net/socket.c:2439 [inline] __x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 write to 0xffff8880b01786cc of 4 bytes by task 18922 on cpu 0: fanout_flow_is_huge net/packet/af_packet.c:1306 [inline] fanout_demux_rollover+0x3a4/0x3f0 net/packet/af_packet.c:1353 packet_rcv_fanout+0x34e/0x490 net/packet/af_packet.c:1453 deliver_skb net/core/dev.c:1888 [inline] dev_queue_xmit_nit+0x15b/0x540 net/core/dev.c:1958 xmit_one net/core/dev.c:3195 [inline] dev_hard_start_xmit+0x3f5/0x430 net/core/dev.c:3215 __dev_queue_xmit+0x14ab/0x1b40 net/core/dev.c:3792 dev_queue_xmit+0x21/0x30 net/core/dev.c:3825 neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116 __ip6_finish_output net/ipv6/ip6_output.c:142 [inline] __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127 ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179 ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795 udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173 udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471 inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0x9f/0xc0 net/socket.c:657 ___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311 __sys_sendmmsg+0x123/0x350 net/socket.c:2413 __do_sys_sendmmsg net/socket.c:2442 [inline] __se_sys_sendmmsg net/socket.c:2439 [inline] __x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 18922 Comm: syz-executor.3 Not tainted 5.4.0-rc6+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 3b3a5b0a ("packet: rollover huge flows before small flows") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 9d027e3a ] A difference of two unsigned long needs long storage. Fixes: c7fb64db ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink") Signed-off-by:
-
Stephen Hemminger authored
[ Upstream commit df9f540c ] When the driver needs to create a hash value because it was not done at higher level, then the hash should be marked as a software not hardware hash. Fixes: f72860af ("hv_netvsc: Exclude non-TCP port numbers from vRSS hashing") Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
Tiezhu Yang authored
[ Upstream commit dece3c2a ] When call function hwmon_device_register failed, use the actual return value instead of always -ENOMEM. Fixes: 64f09aa9 ("MIPS: Loongson-3: Add CPU Hwmon platform driver") Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Paul Burton <paulburton@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Huacai Chen <chenhc@lemote.com> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Madalin Bucur authored
[ Upstream commit 9a4f4f3a ] The dpaa_cleanup_tx_fd() function is called by the frame transmit confirmation callback but also on several error paths. This function is reading the transmit timestamp value. Avoid reading an invalid timestamp value on the error paths. Fixes: 4664856e ("dpaa_eth: add support for hardware timestamping") Signed-off-by:
Madalin Bucur <madalin.bucur@nxp.com> Signed-off-by:
-
Madalin Bucur authored
[ Upstream commit c70fd318 ] DMA unmapping is required before accessing the HW provided timestamping information. Fixes: 4664856e ("dpaa_eth: add support for hardware timestamping") Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 0c0ef9ea ] Commit 0ed266d7 ("clk: ti: omap3: cleanup unnecessary clock aliases") removed old omap3 clock framework aliases but caused omap3-rom-rng to stop working with clock not found error. Based on discussions on the mailing list it was requested by Tero Kristo that it would be best to fix this issue by probing omap3-rom-rng using device tree to provide a proper clk property. The other option would be to add back the missing clock alias, but that does not help moving things forward with removing old legacy platform_data. Let's also add a proper device tree binding and keep it together with the fix. Cc: devicetree@vger.kernel.org Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Fixes: 0ed266d7 ("clk: ti: omap3: cleanup unnecessary clock aliases") Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit fb2ee9bf ] The "lvds->backlight" pointer could be NULL in situations where of_parse_phandle() returns NULL. This code is cleaner if we use the managed devm_of_find_backlight() so the clean up is automatic. Fixes: 7c9dff5b ("drm: panels: Add LVDS panel driver") Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190911104928.GA15930@mwandaSigned-off-by:
-
Marc Dionne authored
[ Upstream commit b485275f ] By default s_maxbytes is set to MAX_NON_LFS, which limits the usable file size to 2GB, enforced by the vfs. Commit b9b1f8d5 ("AFS: write support fixes") added support for the 64-bit fetch and store server operations, but did not change this value. As a result, attempts to write past the 2G mark result in EFBIG errors: $ dd if=/dev/zero of=foo bs=1M count=1 seek=2048 dd: error writing 'foo': File too large Set s_maxbytes to MAX_LFS_FILESIZE. Fixes: b9b1f8d5 ("AFS: write support fixes") Signed-off-by:
Marc Dionne <marc.dionne@auristor.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Haiyang Zhang authored
[ Upstream commit 171c1fd9 ] If negotiated NVSP version <= NVSP_PROTOCOL_VERSION_6, the offset may be wrong (too small) due to a host bug. This can cause missing the end of the send indirection table, and add multiple zero entries from leading zeros before the data region. This bug adds extra burden on channel 0. So fix the offset by computing it from the data structure sizes. This will ensure netvsc driver runs normally on unfixed hosts, and future fixed hosts. Fixes: 5b54dac8 ("hyperv: Add support for virtual Receive Side Scaling (vRSS)") Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Haiyang Zhang authored
[ Upstream commit 71f21959 ] To reach the data region, the existing code adds offset in struct nvsp_5_send_indirect_table on the beginning of this struct. But the offset should be based on the beginning of its container, struct nvsp_message. This bug causes the first table entry missing, and adds an extra zero from the zero pad after the data region. This can put extra burden on the channel 0. So, correct the offset usage. Also add a boundary check to ensure not reading beyond data region. Fixes: 5b54dac8 ("hyperv: Add support for virtual Receive Side Scaling (vRSS)") Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit bc19c329 ] The reset counter is specific for every QCA700x chip. So move this into the private driver struct. Otherwise we get unpredictable reset behavior in setups with multiple QCA700x chips. Fixes: 291ab06e (net: qualcomm: new Ethernet over SPI driver for QCA7000) Signed-off-by:
Stefan Wahren <stefan.wahren@in-tech.com> Signed-off-by:
Stefan Wahren <wahrenst@gmx.net> Signed-off-by:
-
David Howells authored
[ Upstream commit c74386d5 ] In afs_wait_for_call_to_complete(), rather than immediately aborting an operation if a signal occurs, the code attempts to wait for it to complete, using a schedule timeout of 2*RTT (or min 2 jiffies) and a check that we're still receiving relevant packets from the server before we consider aborting the call. We may even ping the server to check on the status of the call. However, there's a missing timeout reset in the event that we do actually get a packet to process, such that if we then get a couple of short stalls, we then time out when progress is actually being made. Fix this by resetting the timeout any time we get something to process. If it's the failure of the call then the call state will get changed and we'll exit the loop shortly thereafter. A symptom of this is data fetches and stores failing with EINTR when they really shouldn't. Fixes: bc5e3a54 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit d0fbb51d ] We need to drop the bpf_devs_lock on error before returning. Fixes: 9fd7c555 ("bpf: offload: aggregate offloads per-device") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Link: https://lore.kernel.org/bpf/20191104091536.GB31509@mwandaSigned-off-by:
-
Magnus Karlsson authored
[ Upstream commit 2afd23f7 ] Having Rx-only AF_XDP sockets can potentially lead to a crash in the system by a NULL pointer dereference in xsk_umem_consume_tx(). This function iterates through a list of all sockets tied to a umem and checks if there are any packets to send on the Tx ring. Rx-only sockets do not have a Tx ring, so this will cause a NULL pointer dereference. This will happen if you have registered one or more Rx-only sockets to a umem and the driver is checking the Tx ring even on Rx, or if the XDP_SHARED_UMEM mode is used and there is a mix of Rx-only and other sockets tied to the same umem. Fixed by only putting sockets with a Tx component on the list that xsk_umem_consume_tx() iterates over. Fixes: ac98d8aa ("xsk: wire upp Tx zero-copy functions") Reported-by:
Kal Cutter Conley <kal.conley@dectris.com> Signed-off-by:
Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Link: https://lore.kernel.org/bpf/1571645818-16244-1-git-send-email-magnus.karlsson@intel.comSigned-off-by:
-
Jakub Kicinski authored
[ Upstream commit e0ad032e ] If packet corruption failed we jump to finish_segs and return NET_XMIT_SUCCESS. Seeing success will make the parent qdisc increment its backlog, that's incorrect - we need to return NET_XMIT_DROP. Fixes: 6071bd1a ("netem: Segment GSO packets on enqueue") Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
[ Upstream commit a7fa12d1 ] To corrupt a GSO frame we first perform segmentation. We then proceed using the first segment instead of the full GSO skb and requeue the rest of the segments as separate packets. If there are any issues with processing the first segment we still want to process the rest, therefore we jump to the finish_segs label. Commit 177b8007 ("net: netem: fix backlog accounting for corrupted GSO frames") started using the pointer to the first segment in the "rest of segments processing", but as mentioned above the first segment may had already been freed at this point. Backlog corrections for parent qdiscs have to be adjusted. Fixes: 177b8007 ("net: netem: fix backlog accounting for corrupted GSO frames") Reported-by:
kbuild test robot <lkp@intel.com> Reported-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Pavel Tatashin authored
[ Upstream commit 8c551f91 ] There is a bug in create_safe_exec_page(), when page table is allocated it is not checked that table is allocated successfully: But it is dereferenced in: pgd_none(READ_ONCE(*pgdp)). Check that allocation was successful. Fixes: 82869ac5 ("arm64: kernel: Add support for hibernate/suspend-to-disk") Reviewed-by:
James Morse <james.morse@arm.com> Signed-off-by:
Pavel Tatashin <pasha.tatashin@soleen.com> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Jean Delvare authored
[ Upstream commit 81dde26d ] Before reading the Extended Size field, we should ensure it fits in the DMI record. There is already a record length check but it does not cover that field. It would take a seriously corrupted DMI table to hit that bug, so no need to worry, but we should still fix it. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: 6deae96b ("firmware, DMI: Add function to look up a handle and return DIMM size") Cc: Tony Luck <tony.luck@intel.com> Cc: Borislav Petkov <bp@suse.de> Signed-off-by:
-
Robin Gong authored
[ Upstream commit bd73dfab ] Illegal memory will be touch if SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (41) exceed the size of structure sdma_script_start_addrs(40), thus cause memory corrupt such as slob block header so that kernel trap into while() loop forever in slob_free(). Please refer to below code piece in imx-sdma.c: for (i = 0; i < sdma->script_number; i++) if (addr_arr[i] > 0) saddr_arr[i] = addr_arr[i]; /* memory corrupt here */ That issue was brought by commit a572460b ("dmaengine: imx-sdma: Add support for version 3 firmware") because SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (38->41 3 scripts added) not align with script number added in sdma_script_start_addrs(2 scripts). Fixes: a572460b ("dmaengine: imx-sdma: Add support for version 3 firmware") Cc: stable@vger.kernel Link: https://www.spinics.net/lists/arm-kernel/msg754895.htmlSigned-off-by:
Robin Gong <yibin.gong@nxp.com> Reported-by:
Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> Link: https://lore.kernel.org/r/1569347584-3478-1-git-send-email-yibin.gong@nxp.com [vkoul: update the patch title] Signed-off-by:
-
Michael S. Tsirkin authored
[ Upstream commit 245cdd9f ] When device stop was moved out of reset, test device wasn't updated to stop before reset, this resulted in a use after free. Fix by invoking stop appropriately. Fixes: b211616d ("vhost: move -net specific code out") Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Jeffrey Hugo authored
[ Upstream commit 78e31c42 ] On msm8998, vblank timeouts are observed because the DSI controller is not reset properly, which ends up stalling the MDP. This is because the reset logic is not correct per the hardware documentation. The documentation states that after asserting reset, software should wait some time (no indication of how long), or poll the status register until it returns 0 before deasserting reset. wmb() is insufficient for this purpose since it just ensures ordering, not timing between writes. Since asserting and deasserting reset occurs on the same register, ordering is already guaranteed by the architecture, making the wmb extraneous. Since we would define a timeout for polling the status register to avoid a possible infinite loop, lets just use a static delay of 20 ms, since 16.666 ms is the time available to process one frame at 60 fps. Fixes: a689554b ("drm/msm: Initial add DSI connector support") Cc: Hai Li <hali@codeaurora.org> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by:
Sean Paul <sean@poorly.run> [seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS] Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.hugo@gmail.comSigned-off-by:
-
Karsten Graul authored
[ Upstream commit 107529e3 ] smc_rx_recvmsg() first checks if data is available, and then if RCV_SHUTDOWN is set. There is a race when smc_cdc_msg_recv_action() runs in between these 2 checks, receives data and sets RCV_SHUTDOWN. In that case smc_rx_recvmsg() would return from receive without to process the available data. Fix that with a final check for data available if RCV_SHUTDOWN is set. Move the check for data into a function and call it twice. And use the existing helper smc_rx_data_available(). Fixes: 952310cc ("smc: receive data from RMBE") Reviewed-by:
Ursula Braun <ubraun@linux.ibm.com> Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
-
Karsten Graul authored
[ Upstream commit 882dcfe5 ] smc_cdc_rxed_any_close_or_senddone() is used as an end condition for the receive loop. This conflicts with smc_cdc_msg_recv_action() which could run in parallel and set the bits checked by smc_cdc_rxed_any_close_or_senddone() before the receive is processed. In that case we could return from receive with no data, although data is available. The same applies to smc_rx_wait(). Fix this by checking for RCV_SHUTDOWN only, which is set in smc_cdc_msg_recv_action() after the receive was actually processed. Fixes: 952310cc ("smc: receive data from RMBE") Reviewed-by:
-
