summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-01-20Linux 6.7.1v6.7.1Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20240118104301.249503558@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Allen Pais <apais@linux.microsoft.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: SeongJae Park <sj@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Ricardo B. Marliere <ricardo@marliere.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20mm/memory_hotplug: fix memmap_on_memory sysfs value retrievalSumanth Korikkar1-3/+5
commit 11684134140bb708b6e6de969a060535630b1b53 upstream. set_memmap_mode() stores the kernel parameter memmap mode as an integer. However, the get_memmap_mode() function utilizes param_get_bool() to fetch the value as a boolean, leading to potential endianness issue. On Big-endian architectures, the memmap_on_memory is consistently displayed as 'N' regardless of its actual status. To address this endianness problem, the solution involves obtaining the mode as an integer. This adjustment ensures the proper display of the memmap_on_memory parameter, presenting it as one of the following options: Force, Y, or N. Link: https://lkml.kernel.org/r/20240110140127.241451-1-sumanthk@linux.ibm.com Fixes: 2d1f649c7c08 ("mm/memory_hotplug: support memmap_on_memory when memmap is not aligned to pageblocks") Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Suggested-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: <stable@vger.kernel.org> [6.6+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20docs: kernel_feat.py: fix potential command injectionVegard Nossum22-65/+32
commit c48a7c44a1d02516309015b6134c9bb982e17008 upstream. The kernel-feat directive passes its argument straight to the shell. This is unfortunate and unnecessary. Let's always use paths relative to $srctree/Documentation/ and use subprocess.check_call() instead of subprocess.Popen(shell=True). This also makes the code shorter. This is analogous to commit 3231dd586277 ("docs: kernel_abi.py: fix command injection") where we did exactly the same thing for kernel_abi.py, somehow I completely missed this one. Link: https://fosstodon.org/@jani/111676532203641247 Reported-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20240110174758.3680506-1-vegard.nossum@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20scripts/decode_stacktrace.sh: optionally use LLVM utilitiesCarlos Llamas1-2/+17
commit efbd6398353315b7018e6943e41fee9ec35e875f upstream. GNU's addr2line can have problems parsing a vmlinux built with LLVM, particularly when LTO was used. In order to decode the traces correctly this patch adds the ability to switch to LLVM's utilities readelf and addr2line. The same approach is followed by Will in [1]. Before: $ scripts/decode_stacktrace.sh vmlinux < kernel.log [17716.240635] Call trace: [17716.240646] skb_cow_data (??:?) [17716.240654] esp6_input (ld-temp.o:?) [17716.240666] xfrm_input (ld-temp.o:?) [17716.240674] xfrm6_rcv (??:?) [...] After: $ LLVM=1 scripts/decode_stacktrace.sh vmlinux < kernel.log [17716.240635] Call trace: [17716.240646] skb_cow_data (include/linux/skbuff.h:2172 net/core/skbuff.c:4503) [17716.240654] esp6_input (net/ipv6/esp6.c:977) [17716.240666] xfrm_input (net/xfrm/xfrm_input.c:659) [17716.240674] xfrm6_rcv (net/ipv6/xfrm6_input.c:172) [...] Note that one could set CROSS_COMPILE=llvm- instead to hack around this issue. However, doing so can break the decodecode routine as it will force the selection of other LLVM utilities down the line e.g. llvm-as. [1] https://lore.kernel.org/all/20230914131225.13415-3-will@kernel.org/ Link: https://lkml.kernel.org/r/20230929034836.403735-1-cmllamas@google.com Signed-off-by: Carlos Llamas <cmllamas@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Tested-by: Justin Stitt <justinstitt@google.com> Cc: Will Deacon <will@kernel.org> Cc: John Stultz <jstultz@google.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Tom Rix <trix@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20coresight: etm4x: Fix width of CCITMIN fieldJames Clark1-1/+1
commit cc0271a339cc70cae914c3ec20edc2a8058407da upstream. CCITMIN is a 12 bit field and doesn't fit in a u8, so extend it to u16. This probably wasn't an issue previously because values higher than 255 never occurred. But since commit 4aff040bcc8d ("coresight: etm: Override TRCIDR3.CCITMIN on errata affected cpus"), a comparison with 256 was done to enable the errata, generating the following W=1 build error: coresight-etm4x-core.c:1188:24: error: result of comparison of constant 256 with expression of type 'u8' (aka 'unsigned char') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (drvdata->ccitmin == 256) Cc: stable@vger.kernel.org Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310302043.as36UFED-lkp@intel.com/ Reviewed-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: James Clark <james.clark@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20231101115206.70810-1-james.clark@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20PCI: Add ACS quirk for more Zhaoxin Root PortsLeoLiuoc1-2/+6
commit e367e3c765f5477b2e79da0f1399aed49e2d1e37 upstream. Add more Root Port Device IDs to pci_quirk_zhaoxin_pcie_ports_acs() for some new Zhaoxin platforms. Fixes: 299bd044a6f3 ("PCI: Add ACS quirk for Zhaoxin Root/Downstream Ports") Link: https://lore.kernel.org/r/20231211091543.735903-1-LeoLiu-oc@zhaoxin.com Signed-off-by: LeoLiuoc <LeoLiu-oc@zhaoxin.com> [bhelgaas: update subject, drop changelog, add Fixes, add stable tag, fix whitespace, wrap code comment] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: <stable@vger.kernel.org> # 5.7 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20leds: ledtrig-tty: Free allocated ttyname buffer on deactivateFlorian Eckert1-0/+4
commit 25054b232681c286fca9c678854f56494d1352cc upstream. The ttyname buffer for the ledtrig_tty_data struct is allocated in the sysfs ttyname_store() function. This buffer must be released on trigger deactivation. This was missing and is thus a memory leak. While we are at it, the TTY handler in the ledtrig_tty_data struct should also be returned in case of the trigger deactivation call. Cc: stable@vger.kernel.org Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger") Signed-off-by: Florian Eckert <fe@dev.tdt.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20231127081621.774866-1-fe@dev.tdt.de Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20parport: parport_serial: Add Brainboxes device IDs and geometryCameron Williams1-0/+56
commit 6aa1fc5a8085bbc01687aa708dcf2dbe637a5ee3 upstream. Add device IDs for the Brainboxes UC-203, UC-257, UC-414, UC-475, IS-300/IS-500 and PX-263/PX-295 and define the relevant "geometry" for the cards. This patch requires part 1 of this series. Cc: <stable@vger.kernel.org> Signed-off-by: Cameron Williams <cang1@live.co.uk> Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Link: https://lore.kernel.org/r/AS4PR02MB7903A4094564BE28F1F926A6C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20parport: parport_serial: Add Brainboxes BAR detailsCameron Williams1-0/+8
commit 65fde134b0a4ffe838729f9ee11b459a2f6f2815 upstream. Add BAR/enum entries for Brainboxes serial/parallel cards. Cc: <stable@vger.kernel.org> Signed-off-by: Cameron Williams <cang1@live.co.uk> Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Link: https://lore.kernel.org/r/AS4PR02MB79035155C2D5C3333AE6FA52C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20uio: Fix use-after-free in uio_openGuanghui Feng1-4/+3
commit 0c9ae0b8605078eafc3bea053cc78791e97ba2e2 upstream. core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock. Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered") Cc: stable <stable@kernel.org> Signed-off-by: Guanghui Feng <guanghuifeng@linux.alibaba.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Link: https://lore.kernel.org/r/1703152663-59949-1-git-send-email-guanghuifeng@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20binder: fix comment on binder_alloc_new_buf() return valueCarlos Llamas1-1/+1
commit e1090371e02b601cbfcea175c2a6cc7c955fa830 upstream. Update the comments of binder_alloc_new_buf() to reflect that the return value of the function is now ERR_PTR(-errno) on failure. No functional changes in this patch. Cc: stable@vger.kernel.org Fixes: 57ada2fb2250 ("binder: add log information for binder transaction failures") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20231201172212.1813387-8-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20binder: fix trivial typo of binder_free_buf_locked()Carlos Llamas1-1/+1
commit 122a3c1cb0ff304c2b8934584fcfea4edb2fe5e3 upstream. Fix minor misspelling of the function in the comment section. No functional changes in this patch. Cc: stable@vger.kernel.org Fixes: 0f966cba95c7 ("binder: add flag to clear buffer on txn complete") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20231201172212.1813387-7-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20binder: fix use-after-free in shinker's callbackCarlos Llamas1-1/+5
commit 3f489c2067c5824528212b0fc18b28d51332d906 upstream. The mmap read lock is used during the shrinker's callback, which means that using alloc->vma pointer isn't safe as it can race with munmap(). As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") the mmap lock is downgraded after the vma has been isolated. I was able to reproduce this issue by manually adding some delays and triggering page reclaiming through the shrinker's debug sysfs. The following KASAN report confirms the UAF: ================================================================== BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8 Read of size 8 at addr ffff356ed50e50f0 by task bash/478 CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 Hardware name: linux,dummy-virt (DT) Call trace: zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c Allocated by task 492: kmem_cache_alloc+0x130/0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 Freed by task 491: kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 Last potentially related work creation: __call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c Fix this issue by performing instead a vma_lookup() which will fail to find the vma that was isolated before the mmap lock downgrade. Note that this option has better performance than upgrading to a mmap write lock which would increase contention. Plus, mmap_write_trylock() has been recently removed anyway. Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") Cc: stable@vger.kernel.org Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Minchan Kim <minchan@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20231201172212.1813387-3-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20binder: use EPOLLERR from eventpoll.hCarlos Llamas1-1/+1
commit 6ac061db9c58ca5b9270b1b3940d2464fb3ff183 upstream. Use EPOLLERR instead of POLLERR to make sure it is cast to the correct __poll_t type. This fixes the following sparse issue: drivers/android/binder.c:5030:24: warning: incorrect type in return expression (different base types) drivers/android/binder.c:5030:24: expected restricted __poll_t drivers/android/binder.c:5030:24: got int Fixes: f88982679f54 ("binder: check for binder_thread allocation failure in binder_poll()") Cc: stable@vger.kernel.org Cc: Eric Biggers <ebiggers@google.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20231201172212.1813387-2-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"Junxiao Bi1-12/+0
commit bed9e27baf52a09b7ba2a3714f1e24e17ced386d upstream. This reverts commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74. That commit introduced the following race and can cause system hung. md_write_start: raid5d: // mddev->in_sync == 1 set "MD_SB_CHANGE_PENDING" // running before md_write_start wakeup it waiting "MD_SB_CHANGE_PENDING" cleared >>>>>>>>> hung wakeup mddev->thread ... waiting "MD_SB_CHANGE_PENDING" cleared >>>> hung, raid5d should clear this flag but get hung by same flag. The issue reverted commit fixing is fixed by last patch in a new way. Fixes: 5e2cf333b7bd ("md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d") Cc: stable@vger.kernel.org # v5.19+ Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20231108182216.73611-2-junxiao.bi@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ksmbd: free ppace array on error in parse_daclFedor Pchelkin1-4/+7
commit 8cf9bedfc3c47d24bb0de386f808f925dc52863e upstream. The ppace array is not freed if one of the init_acl_state() calls inside parse_dacl() fails. At the moment the function may fail only due to the memory allocation errors so it's highly unlikely in this case but nevertheless a fix is needed. Move ppace allocation after the init_acl_state() calls with proper error handling. Found by Linux Verification Center (linuxtesting.org). Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ksmbd: don't allow O_TRUNC open on read-only shareNamjae Jeon1-14/+9
commit d592a9158a112d419f341f035d18d02f8d232def upstream. When file is changed using notepad on read-only share(read_only = yes in ksmbd.conf), There is a problem where existing data is truncated. notepad in windows try to O_TRUNC open(FILE_OVERWRITE_IF) and all data in file is truncated. This patch don't allow O_TRUNC open on read-only share and add KSMBD_TREE_CONN_FLAG_WRITABLE check in smb2_set_info(). Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20drm/amd/display: Pass pwrseq inst for backlight and ABMLewis Huang14-53/+119
commit b17ef04bf3a4346d66404454d6a646343ddc9749 upstream. [Why] OTG inst and pwrseq inst mapping is not align therefore we cannot use otg_inst as pwrseq inst to get DCIO register. [How] 1. Pass the correct pwrseq instance to dmub when set abm pipe. 2. LVTMA control index change from panel_inst to pwrseq_inst. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Phil Hsieh <phil.hsieh@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Lewis Huang <lewis.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20bus: moxtet: Add spi device tableSjoerd Simons1-0/+7
commit aaafe88d5500ba18b33be72458439367ef878788 upstream. The moxtet module fails to auto-load on. Add a SPI id table to allow it to do so. Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> Cc: <stable@vger.kernel.org> Reviewed-by: Marek Behún <kabel@kernel.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20bus: moxtet: Mark the irq as sharedSjoerd Simons1-1/+1
commit e7830f5a83e96d8cb8efc0412902a03008f8fbe3 upstream. The Turris Mox shares the moxtet IRQ with various devices on the board, so mark the IRQ as shared in the driver as well. Without this loading the module will fail with: genirq: Flags mismatch irq 40. 00002002 (moxtet) vs. 00002080 (mcp7940x) Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> Cc: <stable@vger.kernel.org> # v6.2+ Reviewed-by: Marek Behún <kabel@kernel.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ACPI: resource: Add another DMI match for the TongFang GMxXGxxHans de Goede1-0/+7
commit df0cced74159c79e36ce7971f0bf250673296d93 upstream. The TongFang GMxXGxx, which needs IRQ overriding for the keyboard to work, is also sold as the Eluktronics RP-15 which does not use the standard TongFang GMxXGxx DMI board_name. Add an entry for this laptop to the irq1_edge_low_force_override[] DMI table to make the internal keyboard functional. Reported-by: Luis Acuna <ldacuna@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ALSA: hda: cs35l41: Support more HP models without _DSDLorenz Brun1-0/+44
commit 7d65d70161ef75a3991480c91668ac11acedf211 upstream. This adds overrides for a series of notebooks using a common config taken from HP's proprietary Windows driver. This has been tested on a HP 15-ey0xxxx device (subsystem 103C8A31) together with another Realtek quirk and the calibration files from the proprietary driver. Signed-off-by: Lorenz Brun <lorenz@brun.one> Cc: <stable@vger.kernel.org> # v6.7 Link: https://lore.kernel.org/r/20240102214821.3394810-1-lorenz@brun.one Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP Envy X360 13-ay0xxxTom Jason Schwanke1-0/+1
commit 6b3d14b7f9b1acaf7303d8499836bf78ee9c470c upstream. This enables the mute and mic-mute LEDs on the HP Envy X360 13-ay0xxx convertibles. The quirk 'ALC245_FIXUP_HP_X360_MUTE_LEDS' already exists and is now enabled for this device. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216197 Signed-off-by: Tom Jason Schwanke <tom@catboys.cloud> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/651b26e9-e86b-45dd-aa90-3e43d6b99823@catboys.cloud Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ALSA: hda/realtek: enable SND_PCI_QUIRK for Lenovo Legion Slim 7 Gen 8 ↵Dorian Cruveiller1-0/+4
(2023) serie commit 99af5b11c57d33c32d761797f6308b40936c22ed upstream. Link up the realtek audio chip to the cirrus cs35l41 sound amplifier chip on 4 models of the Lenovo legion slim 7 gen 8 (2023). These models are 16IRH8 (2 differents subsystem id) and 16APH8 (2 differents subsystem ids). Subsystem ids list: - 17AA38B4 - 17AA38B5 - 17AA38B6 - 17AA38B7 Signed-off-by: Dorian Cruveiller <doriancruveiller@gmail.com> Cc: <stable@vger.kernel.org> # v6.7 Link: https://lore.kernel.org/r/20231230114001.19855-1-doriancruveiller@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ALSA: hda: Add driver properties for cs35l41 for Lenovo Legion Slim 7 Gen 8 ↵Dorian Cruveiller1-0/+8
serie commit ba7053b4b4a4ddcf530fa2b897e697004715d086 upstream. Add driver properties on 4 models of this laptop serie since they don't have _DSD in the ACPI table Signed-off-by: Dorian Cruveiller <doriancruveiller@gmail.com> Cc: <stable@vger.kernel.org> # v6.7 Link: https://lore.kernel.org/r/20231230114312.22118-1-doriancruveiller@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ALSA: hda: cs35l41: Prevent firmware load if SPI speed too lowStefan Binding5-45/+70
commit d110858a6925827609d11db8513d76750483ec06 upstream. Some laptops without _DSD have the SPI speed set very low in the BIOS. Since the SPI controller uses this speed as its max speed, the SPI transactions are very slow. Firmware download writes to many registers, and if the SPI speed is too slow, it can take a long time to download. For this reason, disable firmware loading if the maximum SPI speed is too low. Without Firmware, audio playback will work, but the volume will be low to ensure safe operation of the CS35L41. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Cc: <stable@vger.kernel.org> # v6.7+ Link: https://lore.kernel.org/r/20231221132518.3213-3-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ALSA: hda: cs35l41: Support additional Dell models without _DSDStefan Binding1-0/+8
commit ee694e7db47e1af00ffb29f569904a9ed576868f upstream. Add new model entries into configuration table. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Cc: <stable@vger.kernel.org> # v6.7+ Link: https://lore.kernel.org/r/20231221132518.3213-2-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20ALSA: hda/realtek: Add quirks for Dell modelsStefan Binding1-0/+13
commit 423206604b28174698d77bf5ea81365cdd6c0f77 upstream. These models use 2 or 4 CS35L41 amps with HDA using SPI and I2C. Models use internal and external boost. All models require DSD support to be added inside cs35l41_hda_property.c Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Cc: <stable@vger.kernel.org> # v6.7+ Link: https://lore.kernel.org/r/20231221132518.3213-4-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-20f2fs: explicitly null-terminate the xattr listEric Biggers1-0/+6
commit e26b6d39270f5eab0087453d9b544189a38c8564 upstream. When setting an xattr, explicitly null-terminate the xattr list. This eliminates the fragile assumption that the unused xattr space is always zeroed. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-07Linux 6.7v6.7Linus Torvalds1-1/+1
2024-01-06Merge tag 'i2c-for-6.7-final' of ↵Linus Torvalds2-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Improve the detection when to run atomic transfer handlers for kernels with preemption disabled. This removes some false positive splats a number of users were seeing if their driver didn't have support for atomic transfers. Also, fix a typo in the docs while we are here" * tag 'i2c-for-6.7-final' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: core: Fix atomic xfer check for non-preempt config Documentation/i2c: fix spelling error in i2c-address-translators
2024-01-06i2c: core: Fix atomic xfer check for non-preempt configBenjamin Bara1-1/+3
Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible"), the whole reboot/power off sequence on non-preempt kernels is using atomic i2c xfer, as !preemptible() always results to 1. During device_shutdown(), the i2c might be used a lot and not all busses have implemented an atomic xfer handler. This results in a lot of avoidable noise, like: [ 12.687169] No atomic I2C transfer handler for 'i2c-0' [ 12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118 ... Fix this by allowing non-atomic xfer when the interrupts are enabled, as it was before. Link: https://lore.kernel.org/r/20231222230106.73f030a5@yea Link: https://lore.kernel.org/r/20240102150350.3180741-1-mwalle@kernel.org Link: https://lore.kernel.org/linux-i2c/13271b9b-4132-46ef-abf8-2c311967bb46@mailbox.org/ Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com> Tested-by: Michael Walle <mwalle@kernel.org> Tested-by: Tor Vic <torvic9@mailbox.org> [wsa: removed a comment which needs more work, code is ok] Signed-off-by: Wolfram Sang <wsa@kernel.org>
2024-01-06Merge tag 'mm-hotfixes-stable-2024-01-05-11-35' of ↵Linus Torvalds15-19/+52
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc mm fixes from Andrew Morton: "12 hotfixes. Two are cc:stable and the remainder either address post-6.7 issues or aren't considered necessary for earlier kernel versions" * tag 'mm-hotfixes-stable-2024-01-05-11-35' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm: shrinker: use kvzalloc_node() from expand_one_shrinker_info() mailmap: add entries for Mathieu Othacehe MAINTAINERS: change vmware.com addresses to broadcom.com arch/mm/fault: fix major fault accounting when retrying under per-VMA lock mm/mglru: skip special VMAs in lru_gen_look_around() MAINTAINERS: hand over hwpoison maintainership to Miaohe Lin MAINTAINERS: remove hugetlb maintainer Mike Kravetz mm: fix unmap_mapping_range high bits shift bug mm: memcg: fix split queue list crash when large folio migration mm: fix arithmetic for max_prop_frac when setting max_ratio mm: fix arithmetic for bdi min_ratio mm: align larger anonymous mappings on THP boundaries
2024-01-06Merge tag 'nfsd-6.7-3' of ↵Linus Torvalds2-21/+17
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux Pull nfsd fix from Chuck Lever: - Fix another regression in the NFSD administrative API * tag 'nfsd-6.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux: nfsd: drop the nfsd_put helper
2024-01-05Merge tag 'firewire-fixes-6.7-final' of ↵Linus Torvalds1-0/+51
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fix from Takashi Sakamoto: "A single patch to suppress unexpected system reboot in AMD Ryzen machines with PCIe card consisting of Asmedia ASM1083/1085 and VT6306/6307/6308. When the 1394 OHCI driver for the card accesses a specific register in PCI memory space, the system reboot often occurs. The issue affects all versions of Linux kernel as long as the 1394 OHCI driver is included. The mechanism of unexpected system reboot is not clear, so the driver is changed to avoid the access itself when detecting the combination of hardware" * tag 'firewire-fixes-6.7-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards
2024-01-05Merge tag 'mmc-v6.7-rc4' of ↵Linus Torvalds4-27/+17
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: "MMC core: - Fix releasing the host by canceling the delayed work - Fix pause retune on all RPMB partitions MMC host: - meson-mx-sdhc: Fix HW hang during card initialization - sdhci-sprd: Fix eMMC init failure after HW reset" * tag 'mmc-v6.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-sprd: Fix eMMC init failure after hw reset mmc: core: Cancel delayed work before releasing host mmc: rpmb: fixes pause retune on all RPMB partitions. mmc: meson-mx-sdhc: Fix initialization frozen issue
2024-01-05Merge tag 'drm-fixes-2024-01-05' of git://anongit.freedesktop.org/drm/drmLinus Torvalds16-196/+603
Pull more drm fixes from Dave Airlie: "The amdgpu ones are fairly normal, the one that is a bit large is a fix for a newly introduced IP in 6.7 so unlikely to cause regressions. The nouveau ones are mostly memory leaks and debugging cleanups from the GSP (new nvidia firmware) enablement. There are some GSP changes to the message passing code and a subsequent fix for eDP panel turn on, that means my laptop can turn on the panel in GSP mode. These are fairly low chance of disrupting things since GSP is new in 6.7. The final not all in GSP fix is a deadlock seen with i915/nouveau when GSP is used where the the fence and irq paths have locking inversions, I've pushed some irq enablement out to a workqueue, and this has seen some fairly decent testing. amdgpu: - DP MST fix - SMU 13.0.6 fixes - fix displays on macbooks using vega12 - fix VSC and colorimetry on DP/eDP nouveau: - fix deadlock between fence signalling and irq paths - fix GSP memory leaks - fix GSP leftover debug - hide some GSP callback messages - fix GSP display disable path - fix GSP ACPI interaction - handle errors in ctrl messages - use errors info to fix DP link training" * tag 'drm-fixes-2024-01-05' of git://anongit.freedesktop.org/drm/drm: drm/nouveau/dp: Honor GSP link training retry timeouts nouveau: push event block/allowing out of the fence context nouveau/gsp: always free the alloc messages on r535 nouveau/gsp: don't free ctrl messages on errors nouveau/gsp: convert gsp errors to generic errors drm/nouveau/gsp: Fix ACPI MXDM/MXDS method invocations nouveau/gsp: free userd allocation. nouveau/gsp: free acpi object after use nouveau: fix disp disabling with GSP nouveau/gsp: drop some acpi related debug nouveau/gsp: add three notifier callbacks that we see in normal operation (v2) drm/amd/pm: Use gpu_metrics_v1_5 for SMUv13.0.6 drm/amd/pm: Add gpu_metrics_v1_5 drm/amd/pm: Add mem_busy_percent for GCv9.4.3 apu drm/amd/display: Fix sending VSC (+ colorimetry) packets for DP/eDP displays without PSR drm/amdgpu: skip gpu_info fw loading on navi12 drm/amd/display: add nv12 bounding box drm/amd/pm: Update metric table for jpeg/vcn data drm/amd/pm: Use separate metric table for APU drm/amd/display: pbn_div need be updated for hotplug event
2024-01-05mm: shrinker: use kvzalloc_node() from expand_one_shrinker_info()Tetsuo Handa1-1/+1
syzbot is reporting uninit-value at shrinker_alloc(), for commit 307bececcd12 ("mm: shrinker: add a secondary array for shrinker_info::{map, nr_deferred}") which assumed that the ->unit was allocated with __GFP_ZERO forgot to replace kvmalloc_node() in expand_one_shrinker_info() with kvzalloc_node(). Link: https://lkml.kernel.org/r/9226cc0a-10e0-4489-80c5-58c3b5b4359c@I-love.SAKURA.ne.jp Reported-by: syzbot <syzbot+1e0ed05798af62917464@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=1e0ed05798af62917464 Fixes: 307bececcd12 ("mm: shrinker: add a secondary array for shrinker_info::{map, nr_deferred}") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: Qi Zheng <zhengqi.arch@bytedance.com> Cc: Muchun Song <songmuchun@bytedance.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-05Merge tag 'soc-fixes-6.7-3a' of ↵Linus Torvalds1-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "These are two correctness fixes for handing DT input in the Allwinner (sunxi) SMP startup code" * tag 'soc-fixes-6.7-3a' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: sun9i: smp: fix return code check of of_property_match_string ARM: sun9i: smp: Fix array-index-out-of-bounds read in sunxi_mc_smp_init
2024-01-05Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds1-1/+6
Pull kvm fix from Paolo Bonzini: - Fix boolean logic in intel_guest_get_msrs * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86/pmu: fix masking logic for MSR_CORE_PERF_GLOBAL_CTRL
2024-01-05Merge tag 'probes-fixes-v6.7-rc8' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull kprobes/x86 fix from Masami Hiramatsu: - Fix to emulate indirect call which size is not 5 byte. Current code expects the indirect call instructions are 5 bytes, but that is incorrect. Usually indirect call based on register is shorter than that, thus the emulation causes a kernel crash by accessing wrong instruction boundary. This uses the instruction size to calculate the return address correctly. * tag 'probes-fixes-v6.7-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: x86/kprobes: fix incorrect return address calculation in kprobe_emulate_call_indirect
2024-01-05Merge tag '6.7-rc8-smb3-mchan-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds3-22/+40
Pull smb client fixes from Steve French: "Three important multichannel smb3 client fixes found in recent testing: - fix oops due to incorrect refcounting of interfaces after disabling multichannel - fix possible unrecoverable session state after disabling multichannel with active sessions - fix two places that were missing use of chan_lock" * tag '6.7-rc8-smb3-mchan-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: do not depend on release_iface for maintaining iface_list cifs: cifs_chan_is_iface_active should be called with chan_lock held cifs: after disabling multichannel, mark tcon for reconnect
2024-01-05firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ↵Takashi Sakamoto1-0/+51
ASM108x/VT630x PCIe cards VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge, it appears that accesses to its 'Isochronous Cycle Timer' register (offset 0xf0 on PCI memory space) often causes unexpected system reboot in any type of AMD Ryzen machine (both 0x17 and 0x19 families). It does not appears in the other type of machine (AMD pre-Ryzen machine, Intel machine, at least), or in the other OHCI 1394 hardware (e.g. Texas Instruments). The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core: use union for callback of transaction completion") added to v6.5 kernel. It changed 1394 OHCI driver to access to the register every time to dispatch local asynchronous transaction. However, the issue exists in older version of kernel as long as it runs in AMD Ryzen machine, since the access to the register is required to maintain bus time. It is not hard to imagine that users experience the unexpected system reboot when generating bus reset by plugging any devices in, or reading the register by time-aware application programs; e.g. audio sample processing. This commit suppresses the unexpected system reboot in the combination of hardware. It avoids the access itself. As a result, the software stack can not provide the hardware time anymore to unit drivers, userspace applications, and nodes in the same IEEE 1394 bus. It brings apparent disadvantage since time-aware application programs require it, while time-unaware applications are available again; e.g. sbp2. Cc: stable@vger.kernel.org Reported-by: Jiri Slaby <jirislaby@kernel.org> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 Reported-by: Mario Limonciello <mario.limonciello@amd.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 Reported-by: Tobias Gruetzmacher <tobias-lists@23.gs> Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/ Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973 Closes: https://bugs.launchpad.net/linux/+bug/2043905 Link: https://lore.kernel.org/r/20240102110150.244475-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2024-01-05nfsd: drop the nfsd_put helperJeff Layton2-21/+17
It's not safe to call nfsd_put once nfsd_last_thread has been called, as that function will zero out the nn->nfsd_serv pointer. Drop the nfsd_put helper altogether and open-code the svc_put in its callers instead. That allows us to not be reliant on the value of that pointer when handling an error. Fixes: 2a501f55cd64 ("nfsd: call nfsd_last_thread() before final nfsd_put()") Reported-by: Zhi Li <yieli@redhat.com> Cc: NeilBrown <neilb@suse.de> Signed-off-by: Jeffrey Layton <jlayton@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-01-05drm/nouveau/dp: Honor GSP link training retry timeoutsLyude Paul1-22/+42
Turns out that one of the ways that Nvidia's driver handles the pre-LT timeout for eDP panels is by providing a retry timeout in their link training callbacks that we're expected to wait for. Up until now we didn't pay any attention to this parameter. So, start honoring the timeout if link training fails - and retry up to 3 times. The "3 times" bit comes from OpenRM's link training code. [airlied: this fixes the panel on one of my laptops] Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-12-airlied@gmail.com
2024-01-05nouveau: push event block/allowing out of the fence contextDave Airlie2-6/+27
There is a deadlock between the irq and fctx locks, the irq handling takes irq then fctx lock the fence signalling takes fctx then irq lock This splits the fence signalling path so the code that hits the irq lock is done in a separate work queue. This seems to fix crashes/hangs when using nouveau gsp with i915 primary GPU. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-11-airlied@gmail.com
2024-01-05nouveau/gsp: always free the alloc messages on r535Dave Airlie1-2/+1
Fixes a memory leak seen with kmemleak. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-10-airlied@gmail.com
2024-01-05nouveau/gsp: don't free ctrl messages on errorsDave Airlie3-61/+100
It looks like for some messages the upper layers need to get access to the results of the message so we can interpret it. Rework the ctrl push interface to not free things and cleanup properly whereever it errors out. Requested-by: Lyude Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-9-airlied@gmail.com
2024-01-05nouveau/gsp: convert gsp errors to generic errorsDave Airlie1-5/+21
This should let the upper layers retry as needed on EAGAIN. There may be other values we will care about in the future, but this covers our present needs. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-8-airlied@gmail.com
2024-01-05drm/nouveau/gsp: Fix ACPI MXDM/MXDS method invocationsLyude Paul1-2/+8
Currently we get an error from ACPI because both of these arguments expect a single argument, and we don't provide one. I'm not totally clear on what that argument does, but we're able to find the missing value from _acpiCacheMethodData() in src/kernel/platform/acpi_common.c in nvidia's driver. So, let's add that - which doesn't get eDP displays to power on quite yet, but gets rid of the argument warning at least. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-7-airlied@gmail.com
generated by cgit v1.2.3 (git 2.39.0) at 2026-09-02 07:51:24 +0300