Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abel Vesa
abel.vesa
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
- Mar 26, 2024
-
-
Eric Dumazet authored
[ Upstream commit 6ebfad33 ] ignore_outgoing is read locklessly from dev_queue_xmit_nit() and packet_getsockopt() Add appropriate READ_ONCE()/WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c:2311 [inline] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 [inline] dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 worker_thread+0x526/0x730 kernel/workqueue.c:3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet Fixes: fa788d98 ("packet: add sockopt to ignore outgoing packets") Reported-by:
<syzbot+c669c1136495a2e7c31f@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/netdev/CANn89i+Z7MfbkBLOv=p7KZ7=K1rKHO4P1OL5LYDCtBiyqsa9oQ@mail.gmail.com/T/#t Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Reviewed-by:
Jason Xing <kerneljasonxing@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Shigeru Yoshida authored
[ Upstream commit ddbec99f ] KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue. This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag. Fixes: f266a683 ("net/hsr: Better frame dispatch") Reported-and-tested-by:
<syzbot+2ef3a8ce8e91b5a50098@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=2ef3a8ce8e91b5a50098 [1] Signed-off-by:
Shigeru Yoshida <syoshida@redhat.com> Link: https://lore.kernel.org/r/20240312152719.724530-1-syoshida@redhat.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 72ebb41b ] A previous bugfix added a call to kcalloc(), which starting in gcc-14 causes a harmless warning about the argument order: drivers/soc/fsl/dpio/dpio-service.c: In function 'dpaa2_io_service_enqueue_multiple_desc_fq': drivers/soc/fsl/dpio/dpio-service.c:526:29: error: 'kcalloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] 526 | ed = kcalloc(sizeof(struct qbman_eq_desc), 32, GFP_KERNEL); | ^~~~~~ drivers/soc/fsl/dpio/dpio-service.c:526:29: note: earlier argument should specify number of elements, later size of each element Since the two are only multiplied, the order does not change the behavior, so just fix it now to shut up the compiler warning. Dmity independently came up with the same fix. Fixes: 5c4a5999 ("soc: fsl: dpio: avoid stack usage warning") Reported-by:
Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Mete Durlu authored
[ Upstream commit 367c50f7 ] Current average steal timer calculation produces volatile and inflated values. The only user of this value is KVM so far and it uses that to decide whether or not to yield the vCPU which is seeing steal time. KVM compares average steal timer to a threshold and if the threshold is past then it does not allow CPU polling and yields it to host, else it keeps the CPU by polling. Since KVM's steal time threshold is very low by default (%10) it most likely is not effected much by the bloated average steal timer values because the operating region is pretty small. However there might be new users in the future who might rely on this number. Fix average steal timer calculation by changing the formula from: avg_steal_timer = avg_steal_timer / 2 + steal_timer; to the following: avg_steal_timer = (avg_steal_timer + steal_timer) / 2; This ensures that avg_steal_timer is actually a naive average of steal timer values. It now closely follows steal timer values but of course in a smoother manner. Fixes: 152e9b86 ("s390/vtime: steal time exponential moving average") Signed-off-by:
Mete Durlu <meted@linux.ibm.com> Acked-by:
Heiko Carstens <hca@linux.ibm.com> Acked-by:
Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by:
-
Linu Cherian authored
[ Upstream commit e642921d ] Use wake_up API instead of wake_up_interruptible, since wait_event_timeout API is used for waiting on command completion. Fixes: 1463f382 ("octeontx2-af: Add support for CGX link management") Signed-off-by:
Linu Cherian <lcherian@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 6f0974ec ] This kind of state is per-syscall, and since we're doing the waiting off entering the io_uring_enter(2) syscall, there's no way that iowait can already be set for this case. Simplify it by setting it if we need to, and always clearing it to 0 when done. Fixes: 7b72d661 ("io_uring: gate iowait schedule on having pending requests") Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 60055680 ] Currently the variable irqflags is being set but is not being used, it appears it should be used in the call to net2272_probe_fin rather than IRQF_TRIGGER_LOW being used. Kudos to Uwe Kleine-König for suggesting the fix. Cleans up clang scan build warning: drivers/usb/gadget/udc/net2272.c:2610:15: warning: variable 'irqflags' set but not used [-Wunused-but-set-variable] Fixes: ceb80363 ("USB: net2272: driver for PLX NET2272 USB device controller") Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20240307181734.2034407-1-colin.i.king@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 34164202 ] The get_channel_from_mode() function is supposed to return the channel which matches the mode. But it has a bug where if it doesn't find a matching channel then it returns the last channel. It should return NULL instead. Also remove an unnecessary NULL check on "channel". Fixes: 2870b52b ("greybus: lights: add lights implementation") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Rui Miguel Silva <rmfrfs@gmail.com> Reviewed-by:
Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/379c0cb4-39e0-4293-8a18-c7b1298e5420@moroto.mountain Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 73b5a5c0 ] It seems a copy&paste mistake that suspend callback removes the GPIO device. There is no counterpart of this action, means once suspended there is no more GPIO device available untile full unbind-bind cycle is performed. Remove suspicious GPIO device removal in suspend. Fixes: d0aeaa83 ("serial: exar: split out the exar code from 8250_pci") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240219150627.2101198-2-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit 544c42f7 ] IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Relying on it being set for a dependency is risky. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on" for IRQ_DOMAIN to "select" for RTC_DRV_MT6397. Fixes: 04d3ba70 ("rtc: mt6397: add IRQ domain dependency") Cc: Arnd Bergmann <arnd@arndb.de> Cc: Eddie Huang <eddie.huang@mediatek.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: linux-rtc@vger.kernel.org Cc: Marc Zyngier <maz@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Peter Rosin <peda@axentia.se> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20240213050258.6167-1-rdunlap@infradead.org Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit af8bbce9 ] A macro placed at the end of a file with no newline causes an infinite loop. [Test Kconfig] $(info,hello) \ No newline at end of file I realized that flex-provided input() returns 0 instead of EOF when it reaches the end of a file. Fixes: 104daea1 ("kconfig: reference environment variables directly and remove 'option env='") Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Tudor Ambarus authored
[ Upstream commit 314c2b39 ] The core expects for tx_empty() either TIOCSER_TEMT when the tx is empty or 0 otherwise. s3c24xx_serial_txempty_nofifo() might return 0x4, and at least uart_get_lsr_info() tries to clear exactly TIOCSER_TEMT (BIT(1)). Fix tx_empty() to return TIOCSER_TEMT. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by:
Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20240119104526.1221243-2-tudor.ambarus@linaro.org Signed-off-by:
-
Hugo Villeneuve authored
[ Upstream commit 8ede8c6f ] Replace g with q. Helpful when grepping thru source code or logs for "request" keyword. Fixes: f6544418 ("serial: New serial driver MAX310X") Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240118152213.2644269-6-hugo@hugovil.com Signed-off-by:
-
Jiri Slaby (SUSE) authored
[ Upstream commit 0e6a92f6 ] The if (c >= 20 && c <= 0x3f) test added in commit 7a99565f is wrong. 20 is DC4 in ascii and it makes no sense to consider that as the bottom limit. Instead, it should be 0x20 as in the other test in the commit above. This is supposed to NOT change anything as we handle interesting 20-0x20 asciis far before this if. So for sakeness, change to 0x20 (which is SPACE). Signed-off-by:
"Jiri Slaby (SUSE)" <jirislaby@kernel.org> Fixes: 7a99565f ("vt: ignore csi sequences with intermediate characters.") Cc: Martin Hostettler <textshell@uchuujin.de> Link: https://lore.kernel.org/all/ZaP45QY2WEsDqoxg@neutronstar.dyndns.org/ Tested-by: Helge Deller <deller@gmx.de> # parisc STI console Link: https://lore.kernel.org/r/20240122110401.7289-4-jirislaby@kernel.org Signed-off-by:
-
Arnaud Pouliquen authored
[ Upstream commit c77b35ce ] The sparse tool complains about the remove of the _iomem attribute. stm32_rproc.c:660:17: warning: cast removes address space '__iomem' of expression Add '__force' to explicitly specify that the cast is intentional. This conversion is necessary to cast to addresses pointer, which are then managed by the remoteproc core as a pointer to a resource_table structure. Fixes: 8a471396 ("remoteproc: stm32: Move resource table setup to rproc_ops") Signed-off-by:
Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20240117135312.3381936-3-arnaud.pouliquen@foss.st.com Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Arnaud Pouliquen authored
[ Upstream commit 32381bbc ] The sparse tool complains about the attribute conversion between a _iomem void * and a void *: stm32_rproc.c:122:12: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *va @@ got void [noderef] __iomem * @@ stm32_rproc.c:122:12: sparse: expected void *va stm32_rproc.c:122:12: sparse: got void [noderef] __iomem * Add '__force' to explicitly specify that the cast is intentional. This conversion is necessary to cast to virtual addresses pointer,used, by the remoteproc core. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312150052.HCiNKlqB-lkp@intel.com/ Fixes: 13140de0 ("remoteproc: stm32: add an ST stm32_rproc driver") Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 03bd158e ] With CONFIG_ARCH_STM32 making it into arch/arm64, a couple of format strings no longer work, since they rely on size_t being compatible with %x, or they print an 'int' using %z: drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_mem_alloc': drivers/remoteproc/stm32_rproc.c:122:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=] drivers/remoteproc/stm32_rproc.c:122:40: note: format string is defined here 122 | dev_dbg(dev, "map memory: %pa+%x\n", &mem->dma, mem->len); | ~^ | | | unsigned int | %lx drivers/remoteproc/stm32_rproc.c:125:30: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=] drivers/remoteproc/stm32_rproc.c:125:65: note: format string is defined here 125 | dev_err(dev, "Unable to map memory region: %pa+%x\n", | ~^ | | | unsigned int | %lx drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_get_loaded_rsc_table': drivers/remoteproc/stm32_rproc.c:646:30: error: format '%zx' expects argument of type 'size_t', but argument 4 has type 'int' [-Werror=format=] drivers/remoteproc/stm32_rproc.c:646:66: note: format string is defined here 646 | dev_err(dev, "Unable to map memory region: %pa+%zx\n", | ~~^ | | | long unsigned int | %x Fix up all three instances to work across architectures, and enable compile testing for this driver to ensure it builds everywhere. Reviewed-by:
-
Mathieu Poirier authored
[ Upstream commit 8a471396 ] Move the setting of the resource table installed by an external entity to rproc_ops::get_loaded_rsc_table(). This is to support scenarios where a remote processor has been attached to but is detached at a later stage. To re-attach the remote processor, the address of the resource table needs to be available at a later time than the platform driver's probe() function. Signed-off-by:
Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20210312162453.1234145-7-mathieu.poirier@linaro.org Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Stable-dep-of: 32381bbc ("remoteproc: stm32: Fix incorrect type in assignment for va") Signed-off-by:
-
Mathieu Poirier authored
[ Upstream commit 1a631382 ] Add a new get_loaded_rsc_table() operation in order to support scenarios where the remoteproc core has booted a remote processor and detaches from it. When re-attaching to the remote processor, the core needs to know where the resource table has been placed in memory. Signed-off-by:
-
Rikard Falkeborn authored
[ Upstream commit 0eee3d28 ] The only usage of st_rproc_ops is to pass its address to rproc_alloc() which accepts a const pointer. Make it const to allow the compiler to put it in read-only memory. Acked-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20201107233630.9728-3-rikard.falkeborn@gmail.com Signed-off-by:
-
David Howells authored
[ Upstream commit 0aec3847 ] This reverts commit 57e9d49c. This undoes the hiding of .__afsXXXX silly-rename files. The problem with hiding them is that rm can't then manually delete them. This also reverts commit 5f7a0764 ("afs: Fix endless loop in directory parsing") as that's a bugfix for the above. Fixes: 57e9d49c ("afs: Hide silly-rename files from userspace") Reported-by:
Markus Suvanto <markus.suvanto@gmail.com> Link: https://lists.infradead.org/pipermail/linux-afs/2024-February/008102.html Signed-off-by:
David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/3085695.1710328121@warthog.procyon.org.uk Reviewed-by:
Jeffrey E Altman <jaltman@auristor.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Signed-off-by:
Christian Brauner <brauner@kernel.org> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 698ad1a5 ] The intent is to check if 'dest' is truncated or not. So, >= should be used instead of >, because strlcat() returns the length of 'dest' and 'src' excluding the trailing NULL. Fixes: 56463e50 ("NFS: Use super.c for NFSROOT mount option parsing") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Ben Wolsieffer authored
[ Upstream commit dbd7c008 ] The driver never sets a default timeout value, therefore it is initialized to zero. When CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is enabled, the watchdog is started during probe. The kernel is supposed to automatically ping the watchdog from this point until userspace takes over, but this does not happen if the configured timeout is zero. A zero timeout causes watchdog_need_worker() to return false, so the heartbeat worker does not run and the system therefore resets soon after the driver is probed. This patch fixes this by setting an arbitrary non-zero default timeout. The default could be read from the hardware instead, but I didn't see any reason to add this complexity. This has been tested on an STM32F746. Fixes: 85fdc63f ("drivers: watchdog: stm32_iwdg: set WDOG_HW_RUNNING at probe") Signed-off-by:
Ben Wolsieffer <ben.wolsieffer@hefring.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20240228182723.12855-1-ben.wolsieffer@hefring.com Signed-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
-
Jorge Mora authored
[ Upstream commit bcac8bff ] Switch order of operations to avoid creating a short XDR buffer: e.g., buflen = 12, old xdrlen = 12, new xdrlen = 20. Having a short XDR buffer leads to lxa_maxcount be a few bytes less than what is needed to retrieve the whole list when using a buflen as returned by a call with size = 0: buflen = listxattr(path, NULL, 0); buf = malloc(buflen); buflen = listxattr(path, buf, buflen); For a file with one attribute (name = '123456'), the first call with size = 0 will return buflen = 12 ('user.123456\x00'). The second call with size = 12, sends LISTXATTRS with lxa_maxcount = 12 + 8 (cookie) + 4 (array count) = 24. The XDR buffer needs 8 (cookie) + 4 (array count) + 4 (name count) + 6 (name len) + 2 (padding) + 4 (eof) = 28 which is 4 bytes shorter than the lxa_maxcount provided in the call. Fixes: 04a5da69 ("NFSv4.2: define limits and sizes for user xattr handling") Signed-off-by:
Jorge Mora <mora@netapp.com> Reviewed-by:
-
Jorge Mora authored
[ Upstream commit 251a658b ] A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000) Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug. Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size. Fixes: 012a211a ("NFSv4.2: hook in the user extended attribute handlers") Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit d6f4de70 ] The intent is to check if the strings' are truncated or not. So, >= should be used instead of >, because strlcat() and snprintf() return the length of the output, excluding the trailing NULL. Fixes: a02d6926 ("SUNRPC: Provide functions for managing universal addresses") Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit b6960023 ] Some callback functions used here take a boolean argument, others take a status argument. This breaks KCFI type checking, so clang now warns about the function pointer cast: drivers/scsi/bfa/bfad_bsg.c:2138:29: error: cast from 'void (*)(void *, enum bfa_status)' to 'bfa_cb_cbfn_t' (aka 'void (*)(void *, enum bfa_boolean)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] Assuming the code is actually correct here and the callers always match the argument types of the callee, rework this to replace the explicit cast with a union of the two pointer types. This does not change the behavior of the code, so if something is actually broken here, a larger rework may be necessary. Fixes: 37ea0558 ("[SCSI] bfa: Added support to collect and reset fcport stats") Fixes: 3ec4f2c8 ("[SCSI] bfa: Added support to configure QOS and collect stats.") Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Shifeng Li authored
[ Upstream commit 7a8bccd8 ] The mad_client will be initialized in enable_device_and_get(), while the devices_rwsem will be downgraded to a read semaphore. There is a window that leads to the failed initialization for cm_client, since it can not get matched mad port from ib_mad_port_list, and the matched mad port will be added to the list after that. mad_client | cm_client ------------------|-------------------------------------------------------- ib_register_device| enable_device_and_get down_write(&devices_rwsem) xa_set_mark(&devices, DEVICE_REGISTERED) downgrade_write(&devices_rwsem) | |ib_cm_init |ib_register_client(&cm_client) |down_read(&devices_rwsem) |xa_for_each_marked (&devices, DEVICE_REGISTERED) |add_client_context |cm_add_one |ib_register_mad_agent |ib_get_mad_port |__ib_get_mad_port |list_for_each_entry(entry, &ib_mad_port_list, port_list) |return NULL |up_read(&devices_rwsem) | add_client_context| ib_mad_init_device| ib_mad_port_open | list_add_tail(&port_priv->port_list, &ib_mad_port_list) up_read(&devices_rwsem) | Fix it by using down_write(&devices_rwsem) in ib_register_client(). Fixes: d0899892 ("RDMA/device: Provide APIs from the core code to help unregistration") Link: https://lore.kernel.org/r/20240203035313.98991-1-lishifeng@sangfor.com.cn Suggested-by:
Jason Gunthorpe <jgg@ziepe.ca> Signed-off-by:
Shifeng Li <lishifeng@sangfor.com.cn> Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 9f3dbcb5 ] csiostor uses function pointer casts to keep the csio_ln_ev state machine hidden, but this causes warnings about control flow integrity (KCFI) violations in clang-16 and higher: drivers/scsi/csiostor/csio_lnode.c:1098:33: error: cast from 'void (*)(struct csio_lnode *, enum csio_ln_ev)' to 'csio_sm_state_t' (aka 'void (*)(void *, unsigned int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 1098 | return (csio_get_state(ln) == ((csio_sm_state_t)csio_lns_ready)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/csiostor/csio_lnode.c:1369:29: error: cast from 'void (*)(struct csio_lnode *, enum csio_ln_ev)' to 'csio_sm_state_t' (aka 'void (*)(void *, unsigned int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 1369 | if (csio_get_state(ln) == ((csio_sm_state_t)csio_lns_uninit)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/csiostor/csio_lnode.c:1373:29: error: cast from 'void (*)(struct csio_lnode *, enum csio_ln_ev)' to 'csio_sm_state_t' (aka 'void (*)(void *, unsigned int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 1373 | if (csio_get_state(ln) == ((csio_sm_state_t)csio_lns_ready)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/csiostor/csio_lnode.c:1377:29: error: cast from 'void (*)(struct csio_lnode *, enum csio_ln_ev)' to 'csio_sm_state_t' (aka 'void (*)(void *, unsigned int)') converts to incompatible function type [-Werror,-Wcast-function-type-strict] 1377 | if (csio_get_state(ln) == ((csio_sm_state_t)csio_lns_offline)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Move the enum into a shared header so the correct types can be used without the need for casts. Fixes: a3667aae ("[SCSI] csiostor: Chelsio FCoE offload driver") Signed-off-by:
-
Sheng Yong authored
[ Upstream commit eb8fbaa5 ] Compressed cluster may not be released due to we can fail in release_compress_blocks(), fix to handle reserved compressed cluster correctly in reserve_compress_blocks(). Fixes: 4c8ff709 ("f2fs: support data compression") Signed-off-by:
Sheng Yong <shengyong@oppo.com> Signed-off-by:
Chao Yu <chao@kernel.org> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
William Kucharski authored
[ Upstream commit c21a8870 ] Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete. Fixes: a42d985b ("ib_srpt: Initial SRP Target merge for v3.3-rc1") Signed-off-by:
William Kucharski <william.kucharski@oracle.com> Link: https://lore.kernel.org/r/20240202091549.991784-2-william.kucharski@oracle.com Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
Johan Carlsson authored
[ Upstream commit a39d51ff ] If a usb audio device sets more bits than the amount of channels it could write outside of the map array. Signed-off-by:
Johan Carlsson <johan.carlsson@teenage.engineering> Fixes: 04324ccc ("ALSA: usb-audio: add channel map support") Message-ID: <20240313081509.9801-1-johan.carlsson@teenage.engineering> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Athaariq Ardhiansyah authored
[ Upstream commit c0621669 ] Realtek codec on HP Envy laptop series are heavily modified by vendor. Therefore, need intervention to make it work properly. The patch fixes: - B&O soundbar speakers (between lid and keyboard) activation - Enable LED on mute button - Add missing process coefficient which affects the output amplifier - Volume control synchronization between B&O soundbar and side speakers - Unmute headset output on several HP Envy models - Auto-enable headset mic when plugged This patch was tested on HP Envy x360 13-AR0107AU with Realtek ALC285 The only unsolved problem is output amplifier of all built-in speakers is too weak, which causes volume of built-in speakers cannot be loud as vendor's proprietary driver due to missing _DSD parameter in the firmware. The solution is currently on research. Expected to has another patch in the future. Potential fix to related issues, need test before close those issues: - https://bugzilla.kernel.org/show_bug.cgi?id=189331 - https://bugzilla.kernel.org/show_bug.cgi?id=216632 - https://bugzilla.kernel.org/show_bug.cgi?id=216311 - https://bugzilla.kernel.org/show_bug.cgi?id=213507 Signed-off-by:
Athaariq Ardhiansyah <foss@athaariq.my.id> Message-ID: <20240310140249.3695-1-foss@athaariq.my.id> Signed-off-by:
-
Bryan O'Donoghue authored[ Upstream commit e97fe490 ] It is possible for clk_core_get to dereference a NULL in the following sequence: clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw() __clk_get_hw() can return NULL which is dereferenced by clk_core_get() at hw->core. Prior to commit dde4eff4 ("clk: Look for parents with clkdev based clk_lookups") the check IS_ERR_OR_NULL() was performed which would have caught the NULL. Reading the description of this function it talks about returning NULL but that cannot be so at the moment. Update the function to check for hw before dereferencing it and return NULL if hw is NULL. Fixes: dde4eff4 ("clk: Look for parents with clkdev based clk_lookups") Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20240302-linux-next-24-03-01-simple-clock-fixes-v1-1-25f348a5982b@linaro.org Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Sam Ravnborg authored
[ Upstream commit 24338a6a ] Passing a datastructre marked _initconst to platform_driver_register() is wrong. Drop the __initconst notation. This fixes the following warnings: WARNING: modpost: vmlinux: section mismatch in reference: grpci1_of_driver+0x30 (section: .data) -> grpci1_of_match (section: .init.rodata) WARNING: modpost: vmlinux: section mismatch in reference: grpci2_of_driver+0x30 (section: .data) -> grpci2_of_match (section: .init.rodata) Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Andreas Larsson <andreas@gaisler.com> Fixes: 4154bb82 ("sparc: leon: grpci1: constify of_device_id") Fixes: 03949b1c ("sparc: leon: grpci2: constify of_device_id") Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Reviewed-by:
Andreas Larsson <andreas@gaisler.com> Tested-by:
-
Daniel Thompson authored[ Upstream commit 39234682 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: c5a51053 ("backlight: add new lp8788 backlight driver") Signed-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20240220153532.76613-4-daniel.thompson@linaro.org Signed-off-by:
Lee Jones <lee@kernel.org> Signed-off-by:
-
Daniel Thompson authored
[ Upstream commit abb5a5d9 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: 0f59858d ("backlight: add new lm3639 backlight driver") Signed-off-by:
-
Daniel Thompson authored
[ Upstream commit 0285e9ef ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: 6ede3d83 ("backlight: add driver for DA9052/53 PMIC v1") Signed-off-by:
-
Luca Weiss authored
[ Upstream commit 4bf7ddd2 ] There's no need to set bl->props.brightness, the get_brightness function is just supposed to return the current brightness and not touch the struct. With that done we can also remove the 'goto out' and just return the value. Fixes: 0c2a665a ("backlight: add Backlight driver for lm3630 chip") Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Reviewed-by:
-
Luca Weiss authored
[ Upstream commit ad9aeb0e ] The backlight_properties struct should be initialized to zero before using, otherwise there will be some random values in the struct. Fixes: 0c2a665a ("backlight: add Backlight driver for lm3630 chip") Signed-off-by:
-
