Skip to main content

Browse the archive

https://github.com/raspberrypi/linux
02 August 2024, 14:19:03 UTC
sort by:
Revision Author Date Message Commit Date
ec0dcf3 Phil Elwell 16 July 2021, 14:23:50 UTC configs: Add SND_SOC_WM8960=m Enable the WM8960 driver module, as used by the wm8960-soundcard overlay. See: https://github.com/raspberrypi/linux/issues/4454 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 18 July 2021, 19:09:18 UTC
93349cd Joerg Schambacher 24 February 2021, 16:34:05 UTC Hifiberry-DAC+:Avoids loading of headphone controls if not defined in DT-overlay This fix keeps the driver from loading the headphone controls in case they are not defined in the selected device tree overlay. This avoids problems if a device uses the same I2C bus address as the headphone amp. The driver issues a warning in that case. Adds the missing embedded newlines in some printk/info statements. Signed-off-by: Joerg Schambacher <joerg@hifiberry.com> 01 March 2021, 15:33:59 UTC
113831b Joerg Schambacher 01 February 2021, 15:53:46 UTC Hifiberry DAC+ADC Pro fix for the PLL when changing sample rates Adds 2 msecs delay when switching between oscillators to allow correct PLL settling. Thanks to Clive Messer for the support! Signed-off-by: Joerg Schambacher <joerg@hifiberry.com> 09 February 2021, 16:49:04 UTC
61e5a22 Phil Elwell 03 February 2021, 16:23:43 UTC ARM: dts: Declare Pi400 and CM4 have no audio pins The audio_pins node is left as a placeholder for the audremap overlay, and it must have (empty) brcm,function and brcm,pins properties otherwise it will be rejected by the pinctrl driver. See: https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=301891 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 03 February 2021, 16:35:10 UTC
cf14b27 Joerg Schambacher 29 January 2021, 15:16:39 UTC Enhances the Hifiberry DAC+ driver for Hifiberry AMP100 support Adds the necessary GPIO handling and ALSA mixer extensions. Also fixes a problem with the PLL/CLK control when switching sample rates. Thanks to Clive Messer for the support! Signed-off-by: Joerg Schambacher <joerg@hifiberry.com> 01 February 2021, 15:43:07 UTC
044360b Joerg Schambacher 29 January 2021, 07:26:44 UTC Adds the DT-overlays to support Hifiberry AMP100 Adds new DT-overlay to control AMP100. Signed-off-by: Joerg Schambacher <joerg@hifiberry.com> 01 February 2021, 15:43:07 UTC
e3fbd01 Maxime Ripard 29 January 2021, 14:29:04 UTC drm/vc4: hvs: Fix buffer overflow with the dlist handling Commit 0a038c1c29a7 ("drm/vc4: Move LBM creation out of vc4_plane_mode_set()") changed the LBM allocation logic from first allocating the LBM memory for the plane to running mode_set, adding a gap in the LBM, and then running the dlist allocation filling that gap. The gap was introduced by incrementing the dlist array index, but was never checking whether or not we were over the array length, leading eventually to memory corruptions if we ever crossed this limit. vc4_dlist_write had that logic though, and was reallocating a larger dlist array when reaching the end of the buffer. Let's share the logic between both functions. Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Eric Anholt <eric@anholt.net> Fixes: 0a038c1c29a7 ("drm/vc4: Move LBM creation out of vc4_plane_mode_set()") Signed-off-by: Maxime Ripard <maxime@cerno.tech> 29 January 2021, 16:50:55 UTC
7a146dc Phil Elwell 29 January 2021, 10:34:11 UTC kbuild: Silence unavoidable dtc overlay warnings Much effort has been put into finding ways to avoid warnings from dtc about overlays, usually to do with the presence of #address-cells and size-cells, but not exclusively so. Since the issues being warned about are harmless, suppress the warnings to declutter the build output and to avoid alarming users. Signed-off-by: Phil Elwell <phil@raspberrypi.com> 29 January 2021, 16:50:55 UTC
08ae2dd Naushir Patuck 14 January 2021, 09:20:52 UTC staging: vc04_services: ISP: Add colour denoise control Add colour denoise control to the bcm2835 driver through a new v4l2 control: V4L2_CID_USER_BCM2835_ISP_CDN. Add the accompanying MMAL configuration structure definitions as well. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> 20 January 2021, 09:59:41 UTC
6887817 Naushir Patuck 14 January 2021, 09:18:42 UTC uapi: bcm2835-isp: Add colour denoise configuration Add a configuration structure for colour denoise to the bcm2835_isp driver. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> 20 January 2021, 09:59:41 UTC
bd20413 Marc Kleine-Budde 09 January 2021, 16:03:32 UTC overlays: seeed-can-fd-hat: clarify how to identify HAT version It turns out the used CAN SPI chip is not a good way to identify the version of the CAN HAT. There are two different board layouts of the Seeed Studio CAN BUS FD HAT. The v1 board doesn't have a battery holder, while the v2 board has. Update the overlay README accordinly. Link: https://github.com/Seeed-Studio/seeed-linux-dtoverlays/issues/13 Cc: Patrick Menschel <menschel.p@posteo.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 13 January 2021, 21:05:37 UTC
617a1c1 Aaron Shaw 26 December 2020, 03:13:14 UTC overlays: add spi override to merus-amp overlay adds an override to the merus-amp overlay to turn the spi bus off Change-type: patch Signed-off-by: Aaron Shaw <shawaj@gmail.com> 08 January 2021, 10:18:59 UTC
1f085de Aaron Shaw 02 January 2021, 02:34:03 UTC overlays: add wm8960-soundcard overlay add overlay for waveshare wm8960 simple-audio-card Change-type: patch Signed-off-by: Aaron Shaw <shawaj@gmail.com> 07 January 2021, 21:15:59 UTC
abdf918 Marc Kleine-Budde 02 January 2021, 20:38:58 UTC overlays: Add overlay for Seeed Studio CAN BUS FD HAT v1 (based on mcp2517fd) This patch adds the overlay for the Seeed Studio CAN BUS FD HAT v1 with two CAN FD Channels (based on mcp2517fd). https://www.seeedstudio.com/2-Channel-CAN-BUS-FD-Shield-for-Raspberry-Pi-p-4072.html The overlay was generated by: ovmerge -c spi1-1cs-overlay.dts,cs0_pin=18,cs0_spidev=false \ mcp251xfd-overlay.dts,spi0-0,interrupt=25 \ mcp251xfd-overlay.dts,spi1-0,interrupt=24 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 03 January 2021, 13:42:18 UTC
35120df Marc Kleine-Budde 02 January 2021, 20:08:59 UTC overlays: give Seeed Studio CAN BUS FD HAT a -v2 postfix There are several versions of the Seeed Studio CAN BUS FD HAT. This is the second version, based on the mcp2518fd, so give it a -v2 postfix. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 03 January 2021, 13:42:18 UTC
e1ad077 Phil Elwell 30 December 2020, 20:00:38 UTC overlays: Rebuild "upstream" with latest ovmerge The latest ovmerge drops disabled fragments, causing the "upstream" overlay to change. Signed-off-by: Phil Elwell <phil@raspberrypi.com> 30 December 2020, 21:18:22 UTC
774f426 menschel 30 December 2020, 20:55:34 UTC Add overlay for Seeed Studio CAN BUS FD HAT (#4034) This patch adds the overlay for the Seeed Studio CAN BUS FD HAT with two CAN FD Channels and an RTC. https://www.seeedstudio.com/CAN-BUS-FD-HAT-for-Raspberry-Pi-p-4742.html The overlay was generated by ovmerge -c mcp251xfd-overlay.dts,spi0-0,interrupt=25 \ mcp251xfd-overlay.dts,spi0-1,interrupt=24 \ i2c-rtc-overlay.dts,pcf85063 Also, add description on how to generate overlays Signed-off-by: Patrick Menschel <menschel.p@posteo.de> 30 December 2020, 20:55:34 UTC
40cc64a Paul Elder 22 December 2020, 05:27:46 UTC media: i2c: ov5647: Selection compliance fixes To comply with the intended usage of the V4L2 selection target when used to retrieve a sensor image properties, adjust the rectangles returned by the ov5647 driver. The top/left crop coordinates of the TGT_CROP rectangle were set to (0, 0) instead of (16, 16) which is the offset from the larger physical pixel array rectangle. This was also a mismatch with the default values crop rectangle value, so this is corrected. Found with v4l2-compliance. While at it, add V4L2_SEL_TGT_CROP_BOUNDS support: CROP_DEFAULT and CROP_BOUNDS have the same size as the non-active pixels are not readable using the selection API. Found with v4l2-compliance. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> 29 December 2020, 12:30:06 UTC
6da087d Phil Elwell 16 December 2020, 09:28:17 UTC overlays: Add missing addresses to ads1015/ads1115 The overlays for the ads1015 and ads1115 I2C ADCs omitted the addresses in the main device node names. As well as breaking the conventions for I2C devices, this prevents the firmware from renaming them when the "reg" property is modified, which in turn stops the overlays from being instantiated multiple times. See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=294465 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 16 December 2020, 09:40:05 UTC
5a598ac Phil Elwell 15 December 2020, 17:02:17 UTC overlays: mpu6050: Add 'addr' parameter The mpu6050 starts up at address 0x68 by default, but can be set to 0x69 if the ADO pin is pulled high. Give the overlay an addr parameter to allow devices at the alternate address to be used. See: https://github.com/Hexxeh/rpi-firmware/issues/252 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 15 December 2020, 17:11:50 UTC
44c11fa Phil Elwell 15 December 2020, 16:38:37 UTC net: lan78xx: Ack pending PHY ints when resetting lan78xx_link_reset explicitly clears the MAC's view of the PHY's IRQ status. In doing so it potentially leaves the PHY with a pending interrupt that will never be acknowledged, at which point no further interrupts will be generated. Avoid the problem by acknowledging any pending PHY interrupt after clearing the MAC's status bit. See: https://github.com/raspberrypi/linux/issues/2937 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 15 December 2020, 16:43:56 UTC
76c49e6 popcornmix 14 December 2020, 12:43:54 UTC Merge remote-tracking branch 'stable/linux-5.4.y' into rpi-5.4.y 14 December 2020, 12:43:54 UTC
2bff021 Greg Kroah-Hartman 11 December 2020, 12:23:33 UTC Linux 5.4.83 Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Link: https://lore.kernel.org/r/20201210164728.074574869@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:33 UTC
66a08d1 Jakub Kicinski 09 December 2020, 22:39:56 UTC Revert "geneve: pull IP header before ECN decapsulation" commit c02bd115b1d25931159f89c7d9bf47a30f5d4b41 upstream. This reverts commit 4179b00c04d1 ("geneve: pull IP header before ECN decapsulation"). Eric says: "network header should have been pulled already before hitting geneve_rx()". Let's revert the syzbot fix since it's causing more harm than good, and revisit. Suggested-by: Eric Dumazet <edumazet@google.com> Reported-by: Jianlin Shi <jishi@redhat.com> Fixes: 4179b00c04d1 ("geneve: pull IP header before ECN decapsulation") Link: https://bugzilla.kernel.org/show_bug.cgi?id=210569 Link: https://lore.kernel.org/netdev/CANn89iJVWfb=2i7oU1=D55rOyQnBbbikf+Mc6XHMkY7YX-yGEw@mail.gmail.com/ Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:33 UTC
ed58971 Masami Hiramatsu 03 December 2020, 04:50:50 UTC x86/insn-eval: Use new for_each_insn_prefix() macro to loop over prefixes bytes commit 12cb908a11b2544b5f53e9af856e6b6a90ed5533 upstream Since insn.prefixes.nbytes can be bigger than the size of insn.prefixes.bytes[] when a prefix is repeated, the proper check must be insn.prefixes.bytes[i] != 0 and i < 4 instead of using insn.prefixes.nbytes. Use the new for_each_insn_prefix() macro which does it correctly. Debugged by Kees Cook <keescook@chromium.org>. [ bp: Massage commit message. ] Fixes: 32d0b95300db ("x86/insn-eval: Add utility functions to get segment selector") Reported-by: syzbot+9b64b619f10f19d19a7c@syzkaller.appspotmail.com Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/160697104969.3146288.16329307586428270032.stgit@devnote2 [sudip: adjust context] Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:33 UTC
423e1b0 Pablo Neira Ayuso 25 November 2020, 22:50:07 UTC netfilter: nftables_offload: set address type in control dissector commit 3c78e9e0d33a27ab8050e4492c03c6a1f8d0ed6b upstream. This patch adds nft_flow_rule_set_addr_type() to set the address type from the nft_payload expression accordingly. If the address type is not set in the control dissector then a rule that matches either on source or destination IP address does not work. After this patch, nft hardware offload generates the flow dissector configuration as tc-flower does to match on an IP address. This patch has been also tested functionally to make sure packets are filtered out by the NIC. This is also getting the code aligned with the existing netfilter flow offload infrastructure which is also setting the control dissector. Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:33 UTC
1399541 Florian Westphal 19 November 2020, 15:34:54 UTC netfilter: nf_tables: avoid false-postive lockdep splat commit c0700dfa2cae44c033ed97dade8a2679c7d22a9d upstream. There are reports wrt lockdep splat in nftables, e.g.: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 31416 at net/netfilter/nf_tables_api.c:622 lockdep_nfnl_nft_mutex_not_held+0x28/0x38 [nf_tables] ... These are caused by an earlier, unrelated bug such as a n ABBA deadlock in a different subsystem. In such an event, lockdep is disabled and lockdep_is_held returns true unconditionally. This then causes the WARN() in nf_tables. Make the WARN conditional on lockdep still active to avoid this. Fixes: f102d66b335a417 ("netfilter: nf_tables: use dedicated mutex to guard transactions") Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Link: https://lore.kernel.org/linux-kselftest/CA+G9fYvFUpODs+NkSYcnwKnXm62tmP=ksLeBPmB+KFrB2rvCtQ@mail.gmail.com/ Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:33 UTC
f25fa58 Luo Meng 25 November 2020, 01:45:23 UTC Input: i8042 - fix error return code in i8042_setup_aux() commit 855b69857830f8d918d715014f05e59a3f7491a0 upstream. Fix to return a negative error code from the error handling case instead of 0 in function i8042_setup_aux(), as done elsewhere in this function. Fixes: f81134163fc7 ("Input: i8042 - use platform_driver_probe") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Luo Meng <luomeng12@huawei.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20201123133420.4071187-1-luomeng12@huawei.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:33 UTC
b9df537 Mike Snitzer 13 November 2020, 22:52:28 UTC dm writecache: remove BUG() and fail gracefully instead commit 857c4c0a8b2888d806f4308c58f59a6a81a1dee9 upstream. Building on arch/s390/ results in this build error: cc1: some warnings being treated as errors ../drivers/md/dm-writecache.c: In function 'persistent_memory_claim': ../drivers/md/dm-writecache.c:323:1: error: no return statement in function returning non-void [-Werror=return-type] Fix this by replacing the BUG() with an -EOPNOTSUPP return. Fixes: 48debafe4f2f ("dm: add writecache target") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:33 UTC
8e2c503 Zhihao Cheng 16 November 2020, 14:10:58 UTC i2c: qup: Fix error return code in qup_i2c_bam_schedule_desc() commit e9acf0298c664f825e6f1158f2a97341bf9e03ca upstream. Fix to return the error code from qup_i2c_change_state() instaed of 0 in qup_i2c_bam_schedule_desc(). Fixes: fbf9921f8b35d9b2 ("i2c: qup: Fix error handling") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:33 UTC
1015eef Dan Carpenter 03 December 2020, 08:43:37 UTC rtw88: debug: Fix uninitialized memory in debugfs code commit 74a8c816fa8fa7862df870660e9821abb56649fe upstream. This code does not ensure that the whole buffer is initialized and none of the callers check for errors so potentially none of the buffer is initialized. Add a memset to eliminate this bug. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/X8ilOfVz3pf0T5ec@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:32 UTC
af699e9 Luo Meng 23 November 2020, 13:38:39 UTC ASoC: wm_adsp: fix error return code in wm_adsp_load() commit 3fba05a2832f93b4d0cd4204f771fdae0d823114 upstream. Fix to return a negative error code from the error handling case instead of 0 in function wm_adsp_load(), as done elsewhere in this function. Fixes: 170b1e123f38 ("ASoC: wm_adsp: Add support for new Halo core DSPs") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Luo Meng <luomeng12@huawei.com> Acked-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20201123133839.4073787-1-luomeng12@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:32 UTC
fdc1416 Hoang Huu Le 07 September 2020, 06:17:25 UTC tipc: fix a deadlock when flushing scheduled work commit d966ddcc38217a6110a6a0ff37ad2dee7d42e23e upstream. In the commit fdeba99b1e58 ("tipc: fix use-after-free in tipc_bcast_get_mode"), we're trying to make sure the tipc_net_finalize_work work item finished if it enqueued. But calling flush_scheduled_work() is not just affecting above work item but either any scheduled work. This has turned out to be overkill and caused to deadlock as syzbot reported: ====================================================== WARNING: possible circular locking dependency detected 5.9.0-rc2-next-20200828-syzkaller #0 Not tainted ------------------------------------------------------ kworker/u4:6/349 is trying to acquire lock: ffff8880aa063d38 ((wq_completion)events){+.+.}-{0:0}, at: flush_workqueue+0xe1/0x13e0 kernel/workqueue.c:2777 but task is already holding lock: ffffffff8a879430 (pernet_ops_rwsem){++++}-{3:3}, at: cleanup_net+0x9b/0xb10 net/core/net_namespace.c:565 [...] Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pernet_ops_rwsem); lock(&sb->s_type->i_mutex_key#13); lock(pernet_ops_rwsem); lock((wq_completion)events); *** DEADLOCK *** [...] v1: To fix the original issue, we replace above calling by introducing a bit flag. When a namespace cleaned-up, bit flag is set to zero and: - tipc_net_finalize functionial just does return immediately. - tipc_net_finalize_work does not enqueue into the scheduled work queue. v2: Use cancel_work_sync() helper to make sure ONLY the tipc_net_finalize_work() stopped before releasing bcbase object. Reported-by: syzbot+d5aa7e0385f6a5d0f4fd@syzkaller.appspotmail.com Fixes: fdeba99b1e58 ("tipc: fix use-after-free in tipc_bcast_get_mode") Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:32 UTC
6410c7f Eric Dumazet 19 November 2020, 09:59:32 UTC netfilter: ipset: prevent uninit-value in hash_ip6_add commit 68ad89de918e1c5a79c9c56127e5e31741fd517e upstream. syzbot found that we are not validating user input properly before copying 16 bytes [1]. Using NLA_BINARY in ipaddr_policy[] for IPv6 address is not correct, since it ensures at most 16 bytes were provided. We should instead make sure user provided exactly 16 bytes. In old kernels (before v4.20), fix would be to remove the NLA_BINARY, since NLA_POLICY_EXACT_LEN() was not yet available. [1] BUG: KMSAN: uninit-value in hash_ip6_add+0x1cba/0x3a50 net/netfilter/ipset/ip_set_hash_gen.h:892 CPU: 1 PID: 11611 Comm: syz-executor.0 Not tainted 5.10.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 hash_ip6_add+0x1cba/0x3a50 net/netfilter/ipset/ip_set_hash_gen.h:892 hash_ip6_uadt+0x976/0xbd0 net/netfilter/ipset/ip_set_hash_ip.c:267 call_ad+0x329/0xd00 net/netfilter/ipset/ip_set_core.c:1720 ip_set_ad+0x111f/0x1440 net/netfilter/ipset/ip_set_core.c:1808 ip_set_uadd+0xf6/0x110 net/netfilter/ipset/ip_set_core.c:1833 nfnetlink_rcv_msg+0xc7d/0xdf0 net/netfilter/nfnetlink.c:252 netlink_rcv_skb+0x70a/0x820 net/netlink/af_netlink.c:2494 nfnetlink_rcv+0x4f0/0x4380 net/netfilter/nfnetlink.c:600 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x11da/0x14b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x173c/0x1840 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] ____sys_sendmsg+0xc7a/0x1240 net/socket.c:2353 ___sys_sendmsg net/socket.c:2407 [inline] __sys_sendmsg+0x6d5/0x830 net/socket.c:2440 __do_sys_sendmsg net/socket.c:2449 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2447 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2447 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45deb9 Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fe2e503fc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000029ec0 RCX: 000000000045deb9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003 RBP: 000000000118bf60 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118bf2c R13: 000000000169fb7f R14: 00007fe2e50409c0 R15: 000000000118bf2c Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 ip6_netmask include/linux/netfilter/ipset/pfxlen.h:49 [inline] hash_ip6_netmask net/netfilter/ipset/ip_set_hash_ip.c:185 [inline] hash_ip6_uadt+0xb1c/0xbd0 net/netfilter/ipset/ip_set_hash_ip.c:263 call_ad+0x329/0xd00 net/netfilter/ipset/ip_set_core.c:1720 ip_set_ad+0x111f/0x1440 net/netfilter/ipset/ip_set_core.c:1808 ip_set_uadd+0xf6/0x110 net/netfilter/ipset/ip_set_core.c:1833 nfnetlink_rcv_msg+0xc7d/0xdf0 net/netfilter/nfnetlink.c:252 netlink_rcv_skb+0x70a/0x820 net/netlink/af_netlink.c:2494 nfnetlink_rcv+0x4f0/0x4380 net/netfilter/nfnetlink.c:600 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x11da/0x14b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x173c/0x1840 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] ____sys_sendmsg+0xc7a/0x1240 net/socket.c:2353 ___sys_sendmsg net/socket.c:2407 [inline] __sys_sendmsg+0x6d5/0x830 net/socket.c:2440 __do_sys_sendmsg net/socket.c:2449 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2447 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2447 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 kmsan_memcpy_memmove_metadata+0x25e/0x2d0 mm/kmsan/kmsan.c:226 kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:246 __msan_memcpy+0x46/0x60 mm/kmsan/kmsan_instr.c:110 ip_set_get_ipaddr6+0x2cb/0x370 net/netfilter/ipset/ip_set_core.c:310 hash_ip6_uadt+0x439/0xbd0 net/netfilter/ipset/ip_set_hash_ip.c:255 call_ad+0x329/0xd00 net/netfilter/ipset/ip_set_core.c:1720 ip_set_ad+0x111f/0x1440 net/netfilter/ipset/ip_set_core.c:1808 ip_set_uadd+0xf6/0x110 net/netfilter/ipset/ip_set_core.c:1833 nfnetlink_rcv_msg+0xc7d/0xdf0 net/netfilter/nfnetlink.c:252 netlink_rcv_skb+0x70a/0x820 net/netlink/af_netlink.c:2494 nfnetlink_rcv+0x4f0/0x4380 net/netfilter/nfnetlink.c:600 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x11da/0x14b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x173c/0x1840 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] ____sys_sendmsg+0xc7a/0x1240 net/socket.c:2353 ___sys_sendmsg net/socket.c:2407 [inline] __sys_sendmsg+0x6d5/0x830 net/socket.c:2440 __do_sys_sendmsg net/socket.c:2449 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2447 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2447 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_poison_shadow+0x5c/0xf0 mm/kmsan/kmsan.c:104 kmsan_slab_alloc+0x8d/0xe0 mm/kmsan/kmsan_hooks.c:76 slab_alloc_node mm/slub.c:2906 [inline] __kmalloc_node_track_caller+0xc61/0x15f0 mm/slub.c:4512 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0x309/0xae0 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1094 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1176 [inline] netlink_sendmsg+0xdb8/0x1840 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] ____sys_sendmsg+0xc7a/0x1240 net/socket.c:2353 ___sys_sendmsg net/socket.c:2407 [inline] __sys_sendmsg+0x6d5/0x830 net/socket.c:2440 __do_sys_sendmsg net/socket.c:2449 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2447 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2447 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: a7b4f989a629 ("netfilter: ipset: IP set core support") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:32 UTC
cd928d3 Bob Peterson 24 November 2020, 15:44:36 UTC gfs2: check for empty rgrp tree in gfs2_ri_update commit 778721510e84209f78e31e2ccb296ae36d623f5e upstream. If gfs2 tries to mount a (corrupt) file system that has no resource groups it still tries to set preferences on the first one, which causes a kernel null pointer dereference. This patch adds a check to function gfs2_ri_update so this condition is detected and reported back as an error. Reported-by: syzbot+e3f23ce40269a4c9053a@syzkaller.appspotmail.com Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:32 UTC
c358e7e Oliver Hartkopp 26 November 2020, 19:21:40 UTC can: af_can: can_rx_unregister(): remove WARN() statement from list operation sanity check commit d73ff9b7c4eacaba0fd956d14882bcae970f8307 upstream. To detect potential bugs in CAN protocol implementations (double removal of receiver entries) a WARN() statement has been used if no matching list item was found for removal. The fault injection issued by syzkaller was able to create a situation where the closing of a socket runs simultaneously to the notifier call chain for removing the CAN network device in use. This case is very unlikely in real life but it doesn't break anything. Therefore we just replace the WARN() statement with pr_warn() to preserve the notification for the CAN protocol development. Reported-by: syzbot+381d06e0c8eaacb8706f@syzkaller.appspotmail.com Reported-by: syzbot+d0ddd88c9a7432f041e6@syzkaller.appspotmail.com Reported-by: syzbot+76d62d3b8162883c7d11@syzkaller.appspotmail.com Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/r/20201126192140.14350-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:32 UTC
867fbf2 Willy Tarreau 30 November 2020, 07:36:48 UTC lib/syscall: fix syscall registers retrieval on 32-bit platforms commit 4f134b89a24b965991e7c345b9a4591821f7c2a6 upstream. Lilith >_> and Claudio Bozzato of Cisco Talos security team reported that collect_syscall() improperly casts the syscall registers to 64-bit values leaking the uninitialized last 24 bytes on 32-bit platforms, that are visible in /proc/self/syscall. The cause is that info->data.args are u64 while syscall_get_arguments() uses longs, as hinted by the bogus pointer cast in the function. Let's just proceed like the other call places, by retrieving the registers into an array of longs before assigning them to the caller's array. This was successfully tested on x86_64, i386 and ppc32. Reference: CVE-2020-28588, TALOS-2020-1211 Fixes: 631b7abacd02 ("ptrace: Remove maxargs from task_current_syscall()") Cc: Greg KH <greg@kroah.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Michael Ellerman <mpe@ellerman.id.au> (ppc32) Signed-off-by: Willy Tarreau <w@1wt.eu> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:32 UTC
f68f5bd Steven Rostedt (VMware) 04 December 2020, 21:36:16 UTC tracing: Fix userstacktrace option for instances commit bcee5278958802b40ee8b26679155a6d9231783e upstream. When the instances were able to use their own options, the userstacktrace option was left hardcoded for the top level. This made the instance userstacktrace option bascially into a nop, and will confuse users that set it, but nothing happens (I was confused when it happened to me!) Cc: stable@vger.kernel.org Fixes: 16270145ce6b ("tracing: Add trace options for core options to instances") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:32 UTC
dbbf6cd Suravee Suthikulpanit 07 December 2020, 09:19:20 UTC iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs commit 4165bf015ba9454f45beaad621d16c516d5c5afe upstream. According to the AMD IOMMU spec, the commit 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to 512 entries") also requires the interrupt table length (IntTabLen) to be set to 9 (power of 2) in the device table mapping entry (DTE). Fixes: 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to 512 entries") Reported-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20201207091920.3052-1-suravee.suthikulpanit@amd.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:31 UTC
d863a4a Peter Ujfalusi 06 December 2020, 13:10:00 UTC spi: bcm2835: Release the DMA channel if probe fails after dma_init [ Upstream commit 666224b43b4bd4612ce3b758c038f9bc5c5e3fcb ] The DMA channel was not released if either devm_request_irq() or devm_spi_register_controller() failed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20191212135550.4634-3-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> [lukas: backport to 5.4-stable] Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:31 UTC
83d5121 Christian Eggers 09 October 2020, 11:03:19 UTC i2c: imx: Check for I2SR_IAL after every byte commit 1de67a3dee7a279ebe4d892b359fe3696938ec15 upstream. Arbitration Lost (IAL) can happen after every single byte transfer. If arbitration is lost, the I2C hardware will autonomously switch from master mode to slave. If a transfer is not aborted in this state, consecutive transfers will not be executed by the hardware and will timeout. Signed-off-by: Christian Eggers <ceggers@arri.de> Tested (not extensively) on Vybrid VF500 (Toradex VF50): Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:31 UTC
83366a7 Christian Eggers 09 October 2020, 11:03:18 UTC i2c: imx: Fix reset of I2SR_IAL flag commit 384a9565f70a876c2e78e58c5ca0bbf0547e4f6d upstream. According to the "VFxxx Controller Reference Manual" (and the comment block starting at line 97), Vybrid requires writing a one for clearing an interrupt flag. Syncing the method for clearing I2SR_IIF in i2c_imx_isr(). Signed-off-by: Christian Eggers <ceggers@arri.de> Fixes: 4b775022f6fd ("i2c: imx: add struct to hold more configurable quirks") Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:31 UTC
b0d4fa1 Samuel Thibault 29 November 2020, 19:35:23 UTC speakup: Reject setting the speakup line discipline outside of speakup commit f0992098cadb4c9c6a00703b66cafe604e178fea upstream. Speakup exposing a line discipline allows userland to try to use it, while it is deemed to be useless, and thus uselessly exposes potential bugs. One of them is simply that in such a case if the line sends data, spk_ttyio_receive_buf2 is called and crashes since spk_ttyio_synth is NULL. This change restricts the use of the speakup line discipline to speakup drivers, thus avoiding such kind of issues altogether. Cc: stable@vger.kernel.org Reported-by: Shisong Qin <qinshisong1205@gmail.com> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Shisong Qin <qinshisong1205@gmail.com> Link: https://lore.kernel.org/r/20201129193523.hm3f6n5xrn6fiyyc@function Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:31 UTC
a2a163f Qian Cai 06 December 2020, 06:14:55 UTC mm/swapfile: do not sleep with a spin lock held commit b11a76b37a5aa7b07c3e3eeeaae20b25475bddd3 upstream. We can't call kvfree() with a spin lock held, so defer it. Fixes a might_sleep() runtime warning. Fixes: 873d7bcfd066 ("mm/swapfile.c: use kvzalloc for swap_info_struct allocation") Signed-off-by: Qian Cai <qcai@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Hugh Dickins <hughd@google.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201202151549.10350-1-qcai@redhat.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:31 UTC
4870004 Yang Shi 06 December 2020, 06:14:48 UTC mm: list_lru: set shrinker map bit when child nr_items is not zero commit 8199be001a470209f5c938570cc199abb012fe53 upstream. When investigating a slab cache bloat problem, significant amount of negative dentry cache was seen, but confusingly they neither got shrunk by reclaimer (the host has very tight memory) nor be shrunk by dropping cache. The vmcore shows there are over 14M negative dentry objects on lru, but tracing result shows they were even not scanned at all. Further investigation shows the memcg's vfs shrinker_map bit is not set. So the reclaimer or dropping cache just skip calling vfs shrinker. So we have to reboot the hosts to get the memory back. I didn't manage to come up with a reproducer in test environment, and the problem can't be reproduced after rebooting. But it seems there is race between shrinker map bit clear and reparenting by code inspection. The hypothesis is elaborated as below. The memcg hierarchy on our production environment looks like: root / \ system user The main workloads are running under user slice's children, and it creates and removes memcg frequently. So reparenting happens very often under user slice, but no task is under user slice directly. So with the frequent reparenting and tight memory pressure, the below hypothetical race condition may happen: CPU A CPU B reparent dst->nr_items == 0 shrinker: total_objects == 0 add src->nr_items to dst set_bit return SHRINK_EMPTY clear_bit child memcg offline replace child's kmemcg_id with parent's (in memcg_offline_kmem()) list_lru_del() between shrinker runs see parent's kmemcg_id dec dst->nr_items reparent again dst->nr_items may go negative due to concurrent list_lru_del() The second run of shrinker: read nr_items without any synchronization, so it may see intermediate negative nr_items then total_objects may return 0 coincidently keep the bit cleared dst->nr_items != 0 skip set_bit add scr->nr_item to dst After this point dst->nr_item may never go zero, so reparenting will not set shrinker_map bit anymore. And since there is no task under user slice directly, so no new object will be added to its lru to set the shrinker map bit either. That bit is kept cleared forever. How does list_lru_del() race with reparenting? It is because reparenting replaces children's kmemcg_id to parent's without protecting from nlru->lock, so list_lru_del() may see parent's kmemcg_id but actually deleting items from child's lru, but dec'ing parent's nr_items, so the parent's nr_items may go negative as commit 2788cf0c401c ("memcg: reparent list_lrus and free kmemcg_id on css offline") says. Since it is impossible that dst->nr_items goes negative and src->nr_items goes zero at the same time, so it seems we could set the shrinker map bit iff src->nr_items != 0. We could synchronize list_lru_count_one() and reparenting with nlru->lock, but it seems checking src->nr_items in reparenting is the simplest and avoids lock contention. Fixes: fae91d6d8be5 ("mm/list_lru.c: set bit in memcg shrinker bitmap on first list_lru item appearance") Suggested-by: Roman Gushchin <guro@fb.com> Signed-off-by: Yang Shi <shy828301@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Roman Gushchin <guro@fb.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: <stable@vger.kernel.org> [4.19] Link: https://lkml.kernel.org/r/20201202171749.264354-1-shy828301@gmail.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:31 UTC
42ccf9d Menglong Dong 06 December 2020, 06:14:42 UTC coredump: fix core_pattern parse error commit 2bf509d96d84c3336d08375e8af34d1b85ee71c8 upstream. 'format_corename()' will splite 'core_pattern' on spaces when it is in pipe mode, and take helper_argv[0] as the path to usermode executable. It works fine in most cases. However, if there is a space between '|' and '/file/path', such as '| /usr/lib/systemd/systemd-coredump %P %u %g', then helper_argv[0] will be parsed as '', and users will get a 'Core dump to | disabled'. It is not friendly to users, as the pattern above was valid previously. Fix this by ignoring the spaces between '|' and '/file/path'. Fixes: 315c69261dd3 ("coredump: split pipe command whitespace before expanding template") Signed-off-by: Menglong Dong <dong.menglong@zte.com.cn> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Paul Wise <pabs3@bonedaddy.net> Cc: Jakub Wilk <jwilk@jwilk.net> [https://bugs.debian.org/924398] Cc: Neil Horman <nhorman@tuxdriver.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/5fb62870.1c69fb81.8ef5d.af76@mx.google.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:30 UTC
579c977 Masami Hiramatsu 03 December 2020, 04:50:37 UTC x86/uprobes: Do not use prefixes.nbytes when looping over prefixes.bytes commit 4e9a5ae8df5b3365183150f6df49e49dece80d8c upstream. Since insn.prefixes.nbytes can be bigger than the size of insn.prefixes.bytes[] when a prefix is repeated, the proper check must be insn.prefixes.bytes[i] != 0 and i < 4 instead of using insn.prefixes.nbytes. Introduce a for_each_insn_prefix() macro for this purpose. Debugged by Kees Cook <keescook@chromium.org>. [ bp: Massage commit message, sync with the respective header in tools/ and drop "we". ] Fixes: 2b1444983508 ("uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints") Reported-by: syzbot+9b64b619f10f19d19a7c@syzkaller.appspotmail.com Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/160697103739.3146288.7437620795200799020.stgit@devnote2 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:30 UTC
002d2c4 Mike Snitzer 04 December 2020, 20:25:18 UTC dm: remove invalid sparse __acquires and __releases annotations commit bde3808bc8c2741ad3d804f84720409aee0c2972 upstream. Fixes sparse warnings: drivers/md/dm.c:508:12: warning: context imbalance in 'dm_prepare_ioctl' - wrong count at exit drivers/md/dm.c:543:13: warning: context imbalance in 'dm_unprepare_ioctl' - wrong count at exit Fixes: 971888c46993f ("dm: hold DM table for duration of ioctl rather than use blkdev_get") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:30 UTC
3b02d67 Sergei Shtepa 11 November 2020, 12:55:46 UTC dm: fix bug with RCU locking in dm_blk_report_zones commit 89478335718c98557f10470a9bc5c555b9261c4e upstream. The dm_get_live_table() function makes RCU read lock so dm_put_live_table() must be called even if dm_table map is not found. Fixes: e76239a3748c9 ("block: add a report_zones method") Cc: stable@vger.kernel.org Signed-off-by: Sergei Shtepa <sergei.shtepa@veeam.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:30 UTC
7eb5140 Laurent Vivier 26 November 2020, 08:28:52 UTC powerpc/pseries: Pass MSI affinity to irq_create_mapping() commit 9ea69a55b3b9a71cded9726af591949c1138f235 upstream. With virtio multiqueue, normally each queue IRQ is mapped to a CPU. Commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity") exposed an existing shortcoming of the arch code by moving virtio_scsi to the automatic IRQ affinity assignment. The affinity is correctly computed in msi_desc but this is not applied to the system IRQs. It appears the affinity is correctly passed to rtas_setup_msi_irqs() but lost at this point and never passed to irq_domain_alloc_descs() (see commit 06ee6d571f0e ("genirq: Add affinity hint to irq allocation")) because irq_create_mapping() doesn't take an affinity parameter. Use the new irq_create_mapping_affinity() function, which allows to forward the affinity setting from rtas_setup_msi_irqs() to irq_domain_alloc_descs(). With this change, the virtqueues are correctly dispatched between the CPUs on pseries. Fixes: e75eafb9b039 ("genirq/msi: Switch to new irq spreading infrastructure") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Greg Kurz <groug@kaod.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201126082852.1178497-3-lvivier@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:30 UTC
1f72986 Laurent Vivier 26 November 2020, 08:28:51 UTC genirq/irqdomain: Add an irq_create_mapping_affinity() function commit bb4c6910c8b41623104c2e64a30615682689a54d upstream. There is currently no way to convey the affinity of an interrupt via irq_create_mapping(), which creates issues for devices that expect that affinity to be managed by the kernel. In order to sort this out, rename irq_create_mapping() to irq_create_mapping_affinity() with an additional affinity parameter that can be passed down to irq_domain_alloc_descs(). irq_create_mapping() is re-implemented as a wrapper around irq_create_mapping_affinity(). No functional change. Fixes: e75eafb9b039 ("genirq/msi: Switch to new irq spreading infrastructure") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Greg Kurz <groug@kaod.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201126082852.1178497-2-lvivier@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:30 UTC
6466119 Nicholas Piggin 28 November 2020, 07:07:21 UTC powerpc/64s/powernv: Fix memory corruption when saving SLB entries on MCE commit a1ee28117077c3bf24e5ab6324c835eaab629c45 upstream. This can be hit by an HPT guest running on an HPT host and bring down the host, so it's quite important to fix. Fixes: 7290f3b3d3e6 ("powerpc/64s/powernv: machine check dump SLB contents") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201128070728.825934-2-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:30 UTC
8a758e9 Mikulas Patocka 10 November 2020, 12:45:13 UTC dm writecache: fix the maximum number of arguments commit 67aa3ec3dbc43d6e34401d9b2a40040ff7bb57af upstream. Advance the maximum number of arguments to 16. This fixes issue where certain operations, combined with table configured args, exceed 10 arguments. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: 48debafe4f2f ("dm: add writecache target") Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:30 UTC
3f680c5 Suganath Prabu S 25 November 2020, 09:48:38 UTC scsi: mpt3sas: Fix ioctl timeout commit 42f687038bcc34aa919e0e4c29b04e4cda3f6a79 upstream. Commit c1a6c5ac4278 ("scsi: mpt3sas: For NVME device, issue a protocol level reset") modified the ioctl path 'timeout' variable type to u8 from unsigned long, limiting the maximum timeout value that the driver can support to 255 seconds. If the management application is requesting a higher value the resulting timeout will be zero. The operation times out immediately and the ioctl request fails. Change datatype back to unsigned long. Link: https://lore.kernel.org/r/20201125094838.4340-1-suganath-prabu.subramani@broadcom.com Fixes: c1a6c5ac4278 ("scsi: mpt3sas: For NVME device, issue a protocol level reset") Cc: <stable@vger.kernel.org> #v4.18+ Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:29 UTC
812dff6 Chris Wilson 26 November 2020, 14:08:41 UTC drm/i915/gt: Program mocs:63 for cache eviction on gen9 commit 777a7717d60ccdc9b84f35074f848d3f746fc3bf upstream. Ville noticed that the last mocs entry is used unconditionally by the HW when it performs cache evictions, and noted that while the value is not meant to be writable by the driver, we should program it to a reasonable value nevertheless. As it turns out, we can change the value of mocs:63 and the value we were programming into it would cause hard hangs in conjunction with atomic operations. v2: Add details from bspec about how it is used by HW Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707 Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: <stable@vger.kernel.org> # v4.3+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201126140841.1982-1-chris@chris-wilson.co.uk (cherry picked from commit 977933b5da7c16f39295c4c1d4259a58ece65dbe) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:29 UTC
b92738c Mika Westerberg 18 November 2020, 11:08:21 UTC thunderbolt: Fix use-after-free in remove_unplugged_switch() commit 600c0849cf86b75d86352f59745226273290986a upstream. Paulian reported a crash that happens when a dock is unplugged during hibernation: [78436.228217] thunderbolt 0-1: device disconnected [78436.228365] BUG: kernel NULL pointer dereference, address: 00000000000001e0 ... [78436.228397] RIP: 0010:icm_free_unplugged_children+0x109/0x1a0 ... [78436.228432] Call Trace: [78436.228439] icm_rescan_work+0x24/0x30 [78436.228444] process_one_work+0x1a3/0x3a0 [78436.228449] worker_thread+0x30/0x370 [78436.228454] ? process_one_work+0x3a0/0x3a0 [78436.228457] kthread+0x13d/0x160 [78436.228461] ? kthread_park+0x90/0x90 [78436.228465] ret_from_fork+0x1f/0x30 This happens because remove_unplugged_switch() calls tb_switch_remove() that releases the memory pointed by sw so the following lines reference to a memory that might be released already. Fix this by saving pointer to the parent device before calling tb_switch_remove(). Reported-by: Paulian Bogdan Marinca <paulian@marinca.net> Fixes: 4f7c2e0d8765 ("thunderbolt: Make sure device runtime resume completes before taking domain lock") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:29 UTC
ed201cb Christian Eggers 09 October 2020, 11:03:20 UTC i2c: imx: Don't generate STOP condition if arbitration has been lost commit 61e6fe59ede155881a622f5901551b1cc8748f6a upstream. If arbitration is lost, the master automatically changes to slave mode. I2SR_IBB may or may not be reset by hardware. Raising a STOP condition by resetting I2CR_MSTA has no effect and will not clear I2SR_IBB. So calling i2c_imx_bus_busy() is not required and would busy-wait until timeout. Signed-off-by: Christian Eggers <ceggers@arri.de> Tested (not extensively) on Vybrid VF500 (Toradex VF50): Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: stable@vger.kernel.org # Requires trivial backporting, simple remove # the 3rd argument from the calls to # i2c_imx_bus_busy(). Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:29 UTC
73948ab Paulo Alcantara 28 November 2020, 19:54:02 UTC cifs: fix potential use-after-free in cifs_echo_request() commit 212253367dc7b49ed3fc194ce71b0992eacaecf2 upstream. This patch fixes a potential use-after-free bug in cifs_echo_request(). For instance, thread 1 -------- cifs_demultiplex_thread() clean_demultiplex_info() kfree(server) thread 2 (workqueue) -------- apic_timer_interrupt() smp_apic_timer_interrupt() irq_exit() __do_softirq() run_timer_softirq() call_timer_fn() cifs_echo_request() <- use-after-free in server ptr Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> CC: Stable <stable@vger.kernel.org> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:29 UTC
a0ca8cb Paulo Alcantara 28 November 2020, 18:57:06 UTC cifs: allow syscalls to be restarted in __smb_send_rqst() commit 6988a619f5b79e4efadea6e19dcfe75fbcd350b5 upstream. A customer has reported that several files in their multi-threaded app were left with size of 0 because most of the read(2) calls returned -EINTR and they assumed no bytes were read. Obviously, they could have fixed it by simply retrying on -EINTR. We noticed that most of the -EINTR on read(2) were due to real-time signals sent by glibc to process wide credential changes (SIGRT_1), and its signal handler had been established with SA_RESTART, in which case those calls could have been automatically restarted by the kernel. Let the kernel decide to whether or not restart the syscalls when there is a signal pending in __smb_send_rqst() by returning -ERESTARTSYS. If it can't, it will return -EINTR anyway. Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> CC: Stable <stable@vger.kernel.org> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:29 UTC
205740c Naveen N. Rao 26 November 2020, 18:08:38 UTC ftrace: Fix updating FTRACE_FL_TRAMP commit 4c75b0ff4e4bf7a45b5aef9639799719c28d0073 upstream. On powerpc, kprobe-direct.tc triggered FTRACE_WARN_ON() in ftrace_get_addr_new() followed by the below message: Bad trampoline accounting at: 000000004222522f (wake_up_process+0xc/0x20) (f0000001) The set of steps leading to this involved: - modprobe ftrace-direct-too - enable_probe - modprobe ftrace-direct - rmmod ftrace-direct <-- trigger The problem turned out to be that we were not updating flags in the ftrace record properly. From the above message about the trampoline accounting being bad, it can be seen that the ftrace record still has FTRACE_FL_TRAMP set though ftrace-direct module is going away. This happens because we are checking if any ftrace_ops has the FTRACE_FL_TRAMP flag set _before_ updating the filter hash. The fix for this is to look for any _other_ ftrace_ops that also needs FTRACE_FL_TRAMP. Link: https://lkml.kernel.org/r/56c113aa9c3e10c19144a36d9684c7882bf09af5.1606412433.git.naveen.n.rao@linux.vnet.ibm.com Cc: stable@vger.kernel.org Fixes: a124692b698b0 ("ftrace: Enable trampoline when rec count returns back to one") Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:29 UTC
d18379b Takashi Iwai 27 November 2020, 14:11:03 UTC ALSA: hda/generic: Add option to enforce preferred_dacs pairs commit 242d990c158d5b1dabd166516e21992baef5f26a upstream. The generic parser accepts the preferred_dacs[] pairs as a hint for assigning a DAC to each pin, but this hint doesn't work always effectively. Currently it's merely a secondary choice after the trial with the path index failed. This made sometimes it difficult to assign DACs without mimicking the connection list and/or the badness table. This patch adds a new flag, obey_preferred_dacs, that changes the behavior of the parser. As its name stands, the parser obeys the given preferred_dacs[] pairs by skipping the path index matching and giving a high penalty if no DAC is assigned by the pairs. This mode will help for assigning the fixed DACs forcibly from the codec driver. Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201127141104.11041-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:29 UTC
f28666e Kailang Yang 27 November 2020, 06:39:23 UTC ALSA: hda/realtek - Add new codec supported for ALC897 commit e5782a5d5054bf1e03cb7fbd87035037c2a22698 upstream. Enable new codec supported for ALC897. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/3b00520f304842aab8291eb8d9191bd8@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:28 UTC
c57556f Jian-Hong Pan 24 November 2020, 09:20:25 UTC ALSA: hda/realtek: Enable headset of ASUS UX482EG & B9400CEA with ALC294 commit eeacd80fcb29b769ea915cd06b7dd35e0bf0bc25 upstream. Some laptops like ASUS UX482EG & B9400CEA's headset audio does not work until the quirk ALC294_FIXUP_ASUS_HPE is applied. Signed-off-by: Jian-Hong Pan <jhp@endlessos.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201124092024.179540-1-jhp@endlessos.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:28 UTC
f3fc366 Takashi Iwai 28 November 2020, 09:00:15 UTC ALSA: hda/realtek: Add mute LED quirk to yet another HP x360 model commit aeedad2504997be262c98f6e3228173225a8d868 upstream. HP Spectre x360 Convertible 15" version (SSID 103c:827f) needs the same quirk to make the mute LED working like other models. System Information Manufacturer: HP Product Name: HP Spectre x360 Convertible 15-bl1XX Sound Codec: Codec: Realtek ALC295 Vendor Id: 0x10ec0295 Subsystem Id: 0x103c827f Revision Id: 0x100002 Reported-by: <christoph.plattner@gmx.at> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201128090015.7743-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:28 UTC
de41002 Takashi Iwai 27 November 2020, 14:11:04 UTC ALSA: hda/realtek: Fix bass speaker DAC assignment on Asus Zephyrus G14 commit c84bfedce60192c08455ee2d25dd13d19274a266 upstream. ASUS Zephyrus G14 has two speaker pins, and the auto-parser tries to assign an individual DAC to each pin as much as possible. Unfortunately the third DAC has no volume control unlike the two DACs, and this resulted in the inconsistent speaker volumes. As a workaround, wire both speaker pins to the same DAC by modifying the existing quirk (ALC289_FIXUP_ASUS_GA401) applied to this device. Since this quirk entry is chained by another, we need to avoid applying the DAC assignment change for it. Luckily, there is another quirk entry (ALC289_FIXUP_ASUS_GA502) doing the very same thing, so we can chain to the GA502 quirk instead. Note that this patch uses a new flag of the generic parser, obey_preferred_dacs, for enforcing the DACs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210359 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201127141104.11041-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:28 UTC
35ee9ac Jann Horn 03 December 2020, 01:25:05 UTC tty: Fix ->session locking commit c8bcd9c5be24fb9e6132e97da5a35e55a83e36b9 upstream. Currently, locking of ->session is very inconsistent; most places protect it using the legacy tty mutex, but disassociate_ctty(), __do_SAK(), tiocspgrp() and tiocgsid() don't. Two of the writers hold the ctrl_lock (because they already need it for ->pgrp), but __proc_set_tty() doesn't do that yet. On a PREEMPT=y system, an unprivileged user can theoretically abuse this broken locking to read 4 bytes of freed memory via TIOCGSID if tiocgsid() is preempted long enough at the right point. (Other things might also go wrong, especially if root-only ioctls are involved; I'm not sure about that.) Change the locking on ->session such that: - tty_lock() is held by all writers: By making disassociate_ctty() hold it. This should be fine because the same lock can already be taken through the call to tty_vhangup_session(). The tricky part is that we need to shorten the area covered by siglock to be able to take tty_lock() without ugly retry logic; as far as I can tell, this should be fine, since nothing in the signal_struct is touched in the `if (tty)` branch. - ctrl_lock is held by all writers: By changing __proc_set_tty() to hold the lock a little longer. - All readers that aren't holding tty_lock() hold ctrl_lock: By adding locking to tiocgsid() and __do_SAK(), and expanding the area covered by ctrl_lock in tiocspgrp(). Cc: stable@kernel.org Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:28 UTC
c536ecd Jann Horn 03 December 2020, 01:25:04 UTC tty: Fix ->pgrp locking in tiocspgrp() commit 54ffccbf053b5b6ca4f6e45094b942fab92a25fc upstream. tiocspgrp() takes two tty_struct pointers: One to the tty that userspace passed to ioctl() (`tty`) and one to the TTY being changed (`real_tty`). These pointers are different when ioctl() is called with a master fd. To properly lock real_tty->pgrp, we must take real_tty->ctrl_lock. This bug makes it possible for racing ioctl(TIOCSPGRP, ...) calls on both sides of a PTY pair to corrupt the refcount of `struct pid`, leading to use-after-free errors. Fixes: 47f86834bbd4 ("redo locking of tty->pgrp") CC: stable@kernel.org Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:28 UTC
013d2d0 Bjørn Mork 01 December 2020, 10:03:18 UTC USB: serial: option: fix Quectel BG96 matching commit c98fff7332dbd6e028969f8c2bda3d7bc7a024d8 upstream. This is a partial revert of commit 2bb70f0a4b23 ("USB: serial: option: support dynamic Quectel USB compositions") The Quectel BG96 is different from most other modern Quectel modems, having serial functions with 3 endpoints using ff/ff/ff and ff/fe/ff class/subclass/protocol. Including it in the change to accommodate dynamic function mapping was incorrect. Revert to interface number matching for the BG96, assuming static layout of the RMNET function on interface 4. This restores support for the serial functions on interfaces 2 and 3. Full lsusb output for the BG96: Bus 002 Device 003: ID 2c7c:0296 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2c7c idProduct 0x0296 bcdDevice 0.00 iManufacturer 3 Qualcomm, Incorporated iProduct 2 Qualcomm CDMA Technologies MSM iSerial 4 d1098243 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 145 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 1 Qualcomm Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 254 bInterfaceProtocol 255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Cc: Sebastian Sjoholm <sebastian.sjoholm@gmail.com> Fixes: 2bb70f0a4b23 ("USB: serial: option: support dynamic Quectel USB compositions") Signed-off-by: Bjørn Mork <bjorn@mork.no> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:28 UTC
3cf9494 Giacinto Cifelli 25 November 2020, 14:53:04 UTC USB: serial: option: add support for Thales Cinterion EXS82 commit 6d6556c04ebaeaf4e7fa8b791c97e2a7c41b38a3 upstream. There is a single option port in this modem, and it is used as debug port. lsusb -v for this device: Bus 001 Device 002: ID 1e2d:006c Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1e2d idProduct 0x006c bcdDevice 0.00 iManufacturer 4 iProduct 3 iSerial 5 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 243 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 2 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 1 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 2 CDC Union: bMasterInterface 1 bSlaveInterface 2 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 3 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 4 CDC Union: bMasterInterface 3 bSlaveInterface 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 5 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 0 CDC Header: bcdCDC 1.10 CDC Ethernet: iMacAddress 1 (??) bmEthernetStatistics 0x00000000 wMaxSegmentSize 16384 wNumberMCFilters 0x0001 bNumberPowerFilters 0 CDC Union: bMasterInterface 5 bSlaveInterface 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Signed-off-by: Giacinto Cifelli <gciofono@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:27 UTC
0f8af69 Vincent Palatin 20 November 2020, 09:28:28 UTC USB: serial: option: add Fibocom NL668 variants commit 5e4d659b10fde14403adb2e215df4a3168fe8465 upstream. Update the USB serial option driver support for the Fibocom NL668 Cat.4 LTE modules as there are actually several different variants. Got clarifications from Fibocom, there are distinct products: - VID:PID 1508:1001, NL668 for IOT (no MBIM interface) - VID:PID 2cb7:01a0, NL668-AM and NL652-EU are laptop M.2 cards (with MBIM interfaces for Windows/Linux/Chrome OS), respectively for Americas and Europe. usb-devices output for the laptop M.2 cards: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2cb7 ProdID=01a0 Rev=03.18 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom NL652-EU Modem S: SerialNumber=0123456789ABCDEF C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:27 UTC
250930f Johan Hovold 03 December 2020, 09:11:59 UTC USB: serial: ch341: sort device-id entries commit bf193bfc12dbc3754fc8a6e0e1e3702f1af2f772 upstream. Keep the device-id entries sorted to make it easier to add new ones in the right spot. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:27 UTC
25b90f8 Jan-Niklas Burfeind 03 December 2020, 03:03:59 UTC USB: serial: ch341: add new Product ID for CH341A commit 46ee4abb10a07bd8f8ce910ee6b4ae6a947d7f63 upstream. Add PID for CH340 that's found on a ch341 based Programmer made by keeyees. The specific device that contains the serial converter is described here: http://www.keeyees.com/a/Products/ej/36.html The driver works flawlessly as soon as the new PID (0x5512) is added to it. Signed-off-by: Jan-Niklas Burfeind <kernel@aiyionpri.me> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:27 UTC
f0990c2 Johan Hovold 04 December 2020, 08:55:19 UTC USB: serial: kl5kusb105: fix memleak on open commit 3f203f057edfcf6bd02c6b942799262bfcf31f73 upstream. Fix memory leak of control-message transfer buffer on successful open(). Fixes: 6774d5f53271 ("USB: serial: kl5kusb105: fix open error path") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:27 UTC
8954745 Vamsi Krishna Samavedam 30 November 2020, 20:34:53 UTC usb: gadget: f_fs: Use local copy of descriptors for userspace copy commit a4b98a7512f18534ce33a7e98e49115af59ffa00 upstream. The function may be unbound causing the ffs_ep and its descriptors to be freed while userspace is in the middle of an ioctl requesting the same descriptors. Avoid dangling pointer reference by first making a local copy of desctiptors before releasing the spinlock. Fixes: c559a3534109 ("usb: gadget: f_fs: add ioctl returning ep descriptor") Reviewed-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Vamsi Krishna Samavedam <vskrishn@codeaurora.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201130203453.28154-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 11 December 2020, 12:23:27 UTC
4a77729 Sasha Levin 08 December 2020, 14:52:46 UTC Partially revert bpf: Zero-fill re-used per-cpu map element Drop the added selftest as it depends on functionality that doesn't exist in 5.4. Signed-off-by: Sasha Levin <sashal@kernel.org> 11 December 2020, 12:23:27 UTC
512b18e Hans de Goede 06 June 2020, 09:31:50 UTC pinctrl: baytrail: Fix pin being driven low for a while on gpiod_get(..., GPIOD_OUT_HIGH) commit 156abe2961601d60a8c2a60c6dc8dd6ce7adcdaf upstream The pins on the Bay Trail SoC have separate input-buffer and output-buffer enable bits and a read of the level bit of the value register will always return the value from the input-buffer. The BIOS of a device may configure a pin in output-only mode, only enabling the output buffer, and write 1 to the level bit to drive the pin high. This 1 written to the level bit will be stored inside the data-latch of the output buffer. But a subsequent read of the value register will return 0 for the level bit because the input-buffer is disabled. This causes a read-modify-write as done by byt_gpio_set_direction() to write 0 to the level bit, driving the pin low! Before this commit byt_gpio_direction_output() relied on pinctrl_gpio_direction_output() to set the direction, followed by a call to byt_gpio_set() to apply the selected value. This causes the pin to go low between the pinctrl_gpio_direction_output() and byt_gpio_set() calls. Change byt_gpio_direction_output() to directly make the register modifications itself instead. Replacing the 2 subsequent writes to the value register with a single write. Note that the pinctrl code does not keep track internally of the direction, so not going through pinctrl_gpio_direction_output() is not an issue. This issue was noticed on a Trekstor SurfTab Twin 10.1. When the panel is already on at boot (no external monitor connected), then the i915 driver does a gpiod_get(..., GPIOD_OUT_HIGH) for the panel-enable GPIO. The temporarily going low of that GPIO was causing the panel to reset itself after which it would not show an image until it was turned off and back on again (until a full modeset was done on it). This commit fixes this. This commit also updates the byt_gpio_direction_input() to use direct register accesses instead of going through pinctrl_gpio_direction_input(), to keep it consistent with byt_gpio_direction_output(). Note for backporting, this commit depends on: commit e2b74419e5cc ("pinctrl: baytrail: Replace WARN with dev_info_once when setting direct-irq pin to output") Cc: stable@vger.kernel.org Fixes: 86e3ef812fe3 ("pinctrl: baytrail: Update gpio chip operations") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [sudip: use byt_gpio and vg->pdev->dev for dev_info()] Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 11 December 2020, 12:23:27 UTC
e90d11d Hans de Goede 01 January 2020, 14:52:43 UTC pinctrl: baytrail: Replace WARN with dev_info_once when setting direct-irq pin to output commit e2b74419e5cc7cfc58f3e785849f73f8fa0af5b3 upstream Suspending Goodix touchscreens requires changing the interrupt pin to output before sending them a power-down command. Followed by wiggling the interrupt pin to wake the device up, after which it is put back in input mode. On Cherry Trail device the interrupt pin is listed as a GpioInt ACPI resource so we can do this without problems as long as we release the IRQ before changing the pin to output mode. On Bay Trail devices with a Goodix touchscreen direct-irq mode is used in combination with listing the pin as a normal GpioIo resource. This works fine, but this triggers the WARN in byt_gpio_set_direction-s output path because direct-irq support is enabled on the pin. This commit replaces the WARN call with a dev_info_once call, fixing a bunch of WARN splats in dmesg on each suspend/resume cycle. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 11 December 2020, 12:23:26 UTC
a80c030 Naushir Patuck 09 December 2020, 11:30:12 UTC media: i2c: imx477: Selection compliance fixes To comply with the intended usage of the V4L2 selection target when used to retrieve a sensor image properties, adjust the rectangles returned by the imx477 driver. The top/left crop coordinates of the TGT_CROP rectangle were set to (0, 0) instead of (8, 16) which is the offset from the larger physical pixel array rectangle. This was also a mismatch with the default values crop rectangle value, so this is corrected. Found with v4l2-compliance. While at it, add V4L2_SEL_TGT_CROP_BOUNDS support: CROP_DEFAULT and CROP_BOUNDS have the same size as the non-active pixels are not readable using the selection API. Found with v4l2-compliance. This commit mirrors 543790f777ba1b3264c168c653db6d415e7c983f done for the imx219 sensor. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> 09 December 2020, 14:04:41 UTC
ec274ec Greg Kroah-Hartman 08 December 2020, 09:40:28 UTC Linux 5.4.82 Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20201206111554.677764505@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:28 UTC
4460a7c Shiraz Saleem 25 November 2020, 00:56:16 UTC RDMA/i40iw: Address an mmap handler exploit in i40iw commit 2ed381439e89fa6d1a0839ef45ccd45d99d8e915 upstream. i40iw_mmap manipulates the vma->vm_pgoff to differentiate a push page mmap vs a doorbell mmap, and uses it to compute the pfn in remap_pfn_range without any validation. This is vulnerable to an mmap exploit as described in: https://lore.kernel.org/r/20201119093523.7588-1-zhudi21@huawei.com The push feature is disabled in the driver currently and therefore no push mmaps are issued from user-space. The feature does not work as expected in the x722 product. Remove the push module parameter and all VMA attribute manipulations for this feature in i40iw_mmap. Update i40iw_mmap to only allow DB user mmapings at offset = 0. Check vm_pgoff for zero and if the mmaps are bound to a single page. Cc: <stable@kernel.org> Fixes: d37498417947 ("i40iw: add files for iwarp interface") Link: https://lore.kernel.org/r/20201125005616.1800-2-shiraz.saleem@intel.com Reported-by: Di Zhu <zhudi21@huawei.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:28 UTC
0743417 Vasily Averin 18 November 2020, 12:05:20 UTC tracing: Remove WARN_ON in start_thread() commit 310e3a4b5a4fc718a72201c1e4cf5c64ac6f5442 upstream. This patch reverts commit 978defee11a5 ("tracing: Do a WARN_ON() if start_thread() in hwlat is called when thread exists") .start hook can be legally called several times if according tracer is stopped screen window 1 [root@localhost ~]# echo 1 > /sys/kernel/tracing/events/kmem/kfree/enable [root@localhost ~]# echo 1 > /sys/kernel/tracing/options/pause-on-trace [root@localhost ~]# less -F /sys/kernel/tracing/trace screen window 2 [root@localhost ~]# cat /sys/kernel/debug/tracing/tracing_on 0 [root@localhost ~]# echo hwlat > /sys/kernel/debug/tracing/current_tracer [root@localhost ~]# echo 1 > /sys/kernel/debug/tracing/tracing_on [root@localhost ~]# cat /sys/kernel/debug/tracing/tracing_on 0 [root@localhost ~]# echo 2 > /sys/kernel/debug/tracing/tracing_on triggers warning in dmesg: WARNING: CPU: 3 PID: 1403 at kernel/trace/trace_hwlat.c:371 hwlat_tracer_start+0xc9/0xd0 Link: https://lkml.kernel.org/r/bd4d3e70-400d-9c82-7b73-a2d695e86b58@virtuozzo.com Cc: Ingo Molnar <mingo@redhat.com> Cc: stable@vger.kernel.org Fixes: 978defee11a5 ("tracing: Do a WARN_ON() if start_thread() in hwlat is called when thread exists") Signed-off-by: Vasily Averin <vvs@virtuozzo.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:28 UTC
6ad995b Po-Hsu Lin 01 December 2020, 06:39:40 UTC Input: i8042 - add ByteSpeed touchpad to noloop table commit a48491c65b513e5cdc3e7a886a4db915f848a5f5 upstream. It looks like the C15B laptop got another vendor: ByteSpeed LLC. Avoid AUX loopback on this touchpad as well, thus input subsystem will be able to recognize a Synaptics touchpad in the AUX port. BugLink: https://bugs.launchpad.net/bugs/1906128 Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Link: https://lore.kernel.org/r/20201201054723.5939-1-po-hsu.lin@canonical.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:27 UTC
dfe5d9a Sanjay Govind 01 December 2020, 07:41:48 UTC Input: xpad - support Ardwiino Controllers commit 2aab1561439032be2e98811dd0ddbeb5b2ae4c61 upstream. This commit adds support for Ardwiino Controllers Signed-off-by: Sanjay Govind <sanjay.govind9@gmail.com> Link: https://lore.kernel.org/r/20201201071922.131666-1-sanjay.govind9@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:27 UTC
c38a702 Hector Martin 27 November 2020, 13:26:35 UTC ALSA: usb-audio: US16x08: fix value count for level meters commit 402d5840b0d40a2a26c8651165d29b534abb6d36 upstream. The level meter control returns 34 integers of info. This fixes: snd-usb-audio 3-1:1.0: control 2:0:0:Level Meter:0: access overflow Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk") Cc: stable@vger.kernel.org Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20201127132635.18947-1-marcan@marcan.st Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:27 UTC
8cd76da Eran Ben Elisha 03 December 2020, 04:39:43 UTC net/mlx5: Fix wrong address reclaim when command interface is down [ Upstream commit 1d2bb5ad89f47d8ce8aedc70ef85059ab3870292 ] When command interface is down, driver to reclaim all 4K page chucks that were hold by the Firmeware. Fix a bug for 64K page size systems, where driver repeatedly released only the first chunk of the page. Define helper function to fill 4K chunks for a given Firmware pages. Iterate over all unreleased Firmware pages and call the hepler per each. Fixes: 5adff6a08862 ("net/mlx5: Fix incorrect page count when in internal error") Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:27 UTC
2598dd8 Yevgeny Kliteynik 03 December 2020, 04:39:46 UTC net/mlx5: DR, Proper handling of unsupported Connect-X6DX SW steering [ Upstream commit d421e466c2373095f165ddd25cbabd6c5b077928 ] STEs format for Connect-X5 and Connect-X6DX different. Currently, on Connext-X6DX the SW steering would break at some point when building STEs w/o giving a proper error message. Fix this by checking the STE format of the current device when initializing domain: add mlx5_ifc definitions for Connect-X6DX SW steering, read FW capability to get the current format version, and check this version when domain is being created. Fixes: 26d688e33f88 ("net/mlx5: DR, Add Steering entry (STE) utilities") Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:27 UTC
8f92330 Davide Caratti 03 December 2020, 09:37:52 UTC net/sched: act_mpls: ensure LSE is pullable before reading it [ Upstream commit 9608fa653059c3f72faab0c148ac8773c46e7314 ] when 'act_mpls' is used to mangle the LSE, the current value is read from the packet dereferencing 4 bytes at mpls_hdr(): ensure that the label is contained in the skb "linear" area. Found by code inspection. v2: - use MPLS_HLEN instead of sizeof(new_lse), thanks to Jakub Kicinski Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC") Signed-off-by: Davide Caratti <dcaratti@redhat.com> Acked-by: Guillaume Nault <gnault@redhat.com> Link: https://lore.kernel.org/r/3243506cba43d14858f3bd21ee0994160e44d64a.1606987058.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:27 UTC
1086f78 Davide Caratti 03 December 2020, 09:46:06 UTC net: openvswitch: ensure LSE is pullable before reading it [ Upstream commit 43c13605bad44b8abbc9776d6e63f62ccb7a47d6 ] when openvswitch is configured to mangle the LSE, the current value is read from the packet dereferencing 4 bytes at mpls_hdr(): ensure that the label is contained in the skb "linear" area. Found by code inspection. Fixes: d27cf5c59a12 ("net: core: add MPLS update core helper and use in OvS") Signed-off-by: Davide Caratti <dcaratti@redhat.com> Link: https://lore.kernel.org/r/aa099f245d93218b84b5c056b67b6058ccf81a66.1606987185.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:27 UTC
ba203b9 Davide Caratti 03 December 2020, 09:58:21 UTC net: skbuff: ensure LSE is pullable before decrementing the MPLS ttl [ Upstream commit 13de4ed9e3a9ccbe54d05f7d5c773f69ecaf6c64 ] skb_mpls_dec_ttl() reads the LSE without ensuring that it is contained in the skb "linear" area. Fix this calling pskb_may_pull() before reading the current ttl. Found by code inspection. Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC") Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: Davide Caratti <dcaratti@redhat.com> Link: https://lore.kernel.org/r/53659f28be8bc336c113b5254dc637cc76bbae91.1606987074.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:26 UTC
892e08e Wang Hai 03 December 2020, 14:18:06 UTC net: mvpp2: Fix error return code in mvpp2_open() [ Upstream commit 82a10dc7f0960735f40e8d7d3bee56934291600f ] Fix to return negative error code -ENOENT from invalid configuration error handling case instead of 0, as done elsewhere in this function. Fixes: 4bb043262878 ("net: mvpp2: phylink support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201203141806.37966-1-wanghai38@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:26 UTC
7c3894f Dan Carpenter 03 December 2020, 08:44:31 UTC chelsio/chtls: fix a double free in chtls_setkey() [ Upstream commit 391119fb5c5c4bdb4d57c7ffeb5e8d18560783d1 ] The "skb" is freed by the transmit code in cxgb4_ofld_send() and we shouldn't use it again. But in the current code, if we hit an error later on in the function then the clean up code will call kfree_skb(skb) and so it causes a double free. Set the "skb" to NULL and that makes the kfree_skb() a no-op. Fixes: d25f2f71f653 ("crypto: chtls - Program the TLS session Key") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/X8ilb6PtBRLWiSHp@mwanda Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:26 UTC
178da08 Zhang Changzhong 02 December 2020, 09:58:42 UTC vxlan: fix error return code in __vxlan_dev_create() [ Upstream commit 832e09798c261cf58de3a68cfcc6556408c16a5a ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1606903122-2098-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:26 UTC
5405a29 Zhang Changzhong 02 December 2020, 09:57:15 UTC net: pasemi: fix error return code in pasemi_mac_open() [ Upstream commit aba84871bd4f52c4dfcf3ad5d4501a6c9d2de90e ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 72b05b9940f0 ("pasemi_mac: RX/TX ring management cleanup") Fixes: 8d636d8bc5ff ("pasemi_mac: jumbo frame support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1606903035-1838-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:26 UTC
dc469f4 Zhang Changzhong 02 December 2020, 09:56:05 UTC cxgb3: fix error return code in t3_sge_alloc_qset() [ Upstream commit ff9924897f8bfed82e61894b373ab9d2dfea5b10 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: b1fb1f280d09 ("cxgb3 - Fix dma mapping error path") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Raju Rangoju <rajur@chelsio.com> Link: https://lore.kernel.org/r/1606902965-1646-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:26 UTC
8bfe5b7 Dan Carpenter 01 December 2020, 15:15:12 UTC net/x25: prevent a couple of overflows [ Upstream commit 6ee50c8e262a0f0693dad264c3c99e30e6442a56 ] The .x25_addr[] address comes from the user and is not necessarily NUL terminated. This leads to a couple problems. The first problem is that the strlen() in x25_bind() can read beyond the end of the buffer. The second problem is more subtle and could result in memory corruption. The call tree is: x25_connect() --> x25_write_internal() --> x25_addr_aton() The .x25_addr[] buffers are copied to the "addresses" buffer from x25_write_internal() so it will lead to stack corruption. Verify that the strings are NUL terminated and return -EINVAL if they are not. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: a9288525d2ae ("X25: Dont let x25_bind use addresses containing characters") Reported-by: "kiyin(尹亮)" <kiyin@tencent.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Martin Schiller <ms@dev.tdt.de> Link: https://lore.kernel.org/r/X8ZeAKm8FnFpN//B@mwanda Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:26 UTC
187a6da Antoine Tenart 30 November 2020, 16:19:11 UTC net: ip6_gre: set dev->hard_header_len when using header_ops [ Upstream commit 832ba596494b2c9eac7760259eff2d8b7dcad0ee ] syzkaller managed to crash the kernel using an NBMA ip6gre interface. I could reproduce it creating an NBMA ip6gre interface and forwarding traffic to it: skbuff: skb_under_panic: text:ffffffff8250e927 len:148 put:44 head:ffff8c03c7a33 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:109! Call Trace: skb_push+0x10/0x10 ip6gre_header+0x47/0x1b0 neigh_connected_output+0xae/0xf0 ip6gre tunnel provides its own header_ops->create, and sets it conditionally when initializing the tunnel in NBMA mode. When header_ops->create is used, dev->hard_header_len should reflect the length of the header created. Otherwise, when not used, dev->needed_headroom should be used. Fixes: eb95f52fc72d ("net: ipv6_gre: Fix GRO to work on IPv6 over GRE tap") Cc: Maria Pasechnik <mariap@mellanox.com> Signed-off-by: Antoine Tenart <atenart@kernel.org> Link: https://lore.kernel.org/r/20201130161911.464106-1-atenart@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:26 UTC
a6cd761 Eric Dumazet 01 December 2020, 09:05:07 UTC geneve: pull IP header before ECN decapsulation [ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ] IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume IP header is already pulled. geneve does not ensure this yet. Fixing this generically in IP_ECN_decapsulate() and IP6_ECN_decapsulate() is not possible, since callers pass a pointer that might be freed by pskb_may_pull() syzbot reported : BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:238 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate+0x345/0x1db0 include/net/inet_ecn.h:260 CPU: 1 PID: 8941 Comm: syz-executor.0 Not tainted 5.10.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 __INET_ECN_decapsulate include/net/inet_ecn.h:238 [inline] INET_ECN_decapsulate+0x345/0x1db0 include/net/inet_ecn.h:260 geneve_rx+0x2103/0x2980 include/net/inet_ecn.h:306 geneve_udp_encap_recv+0x105c/0x1340 drivers/net/geneve.c:377 udp_queue_rcv_one_skb+0x193a/0x1af0 net/ipv4/udp.c:2093 udp_queue_rcv_skb+0x282/0x1050 net/ipv4/udp.c:2167 udp_unicast_rcv_skb net/ipv4/udp.c:2325 [inline] __udp4_lib_rcv+0x399d/0x5880 net/ipv4/udp.c:2394 udp_rcv+0x5c/0x70 net/ipv4/udp.c:2564 ip_protocol_deliver_rcu+0x572/0xc50 net/ipv4/ip_input.c:204 ip_local_deliver_finish net/ipv4/ip_input.c:231 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip_local_deliver+0x583/0x8d0 net/ipv4/ip_input.c:252 dst_input include/net/dst.h:449 [inline] ip_rcv_finish net/ipv4/ip_input.c:428 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip_rcv+0x5c3/0x840 net/ipv4/ip_input.c:539 __netif_receive_skb_one_core net/core/dev.c:5315 [inline] __netif_receive_skb+0x1ec/0x640 net/core/dev.c:5429 process_backlog+0x523/0xc10 net/core/dev.c:6319 napi_poll+0x420/0x1010 net/core/dev.c:6763 net_rx_action+0x35c/0xd40 net/core/dev.c:6833 __do_softirq+0x1a9/0x6fa kernel/softirq.c:298 asm_call_irq_on_stack+0xf/0x20 </IRQ> __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline] do_softirq_own_stack+0x6e/0x90 arch/x86/kernel/irq_64.c:77 do_softirq kernel/softirq.c:343 [inline] __local_bh_enable_ip+0x184/0x1d0 kernel/softirq.c:195 local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32 rcu_read_unlock_bh include/linux/rcupdate.h:730 [inline] __dev_queue_xmit+0x3a9b/0x4520 net/core/dev.c:4167 dev_queue_xmit+0x4b/0x60 net/core/dev.c:4173 packet_snd net/packet/af_packet.c:2992 [inline] packet_sendmsg+0x86f9/0x99d0 net/packet/af_packet.c:3017 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:671 [inline] __sys_sendto+0x9dc/0xc80 net/socket.c:1992 __do_sys_sendto net/socket.c:2004 [inline] __se_sys_sendto+0x107/0x130 net/socket.c:2000 __x64_sys_sendto+0x6e/0x90 net/socket.c:2000 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 2d07dc79fe04 ("geneve: add initial netdev driver for GENEVE tunnels") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Link: https://lore.kernel.org/r/20201201090507.4137906-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:25 UTC
2b714b6 Toke Høiland-Jørgensen 30 November 2020, 18:37:05 UTC inet_ecn: Fix endianness of checksum update when setting ECT(1) [ Upstream commit 2867e1eac61016f59b3d730e3f7aa488e186e917 ] When adding support for propagating ECT(1) marking in IP headers it seems I suffered from endianness-confusion in the checksum update calculation: In fact the ECN field is in the *lower* bits of the first 16-bit word of the IP header when calculating in network byte order. This means that the addition performed to update the checksum field was wrong; let's fix that. Fixes: b723748750ec ("tunnel: Propagate ECT(1) when decapsulating as recommended by RFC6040") Reported-by: Jonathan Morton <chromatix99@gmail.com> Tested-by: Pete Heist <pete@heistp.net> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/r/20201130183705.17540-1-toke@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:25 UTC
9a3cce1 Thomas Falcon 01 December 2020, 15:52:11 UTC ibmvnic: Fix TX completion error handling [ Upstream commit ba246c175116e2e8fa4fdfa5f8e958e086a9a818 ] TX completions received with an error return code are not being processed properly. When an error code is seen, do not proceed to the next completion before cleaning up the existing entry's data structures. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:25 UTC
40caea3 Thomas Falcon 01 December 2020, 15:52:10 UTC ibmvnic: Ensure that SCRQ entry reads are correctly ordered [ Upstream commit b71ec952234610b4f90ef17a2fdcb124d5320070 ] Ensure that received Subordinate Command-Response Queue (SCRQ) entries are properly read in order by the driver. These queues are used in the ibmvnic device to process RX buffer and TX completion descriptors. dma_rmb barriers have been added after checking for a pending descriptor to ensure the correct descriptor entry is checked and after reading the SCRQ descriptor to ensure the entire descriptor is read before processing. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 08 December 2020, 09:40:25 UTC
back to top