commit aed23654e8ed2cc776ae26a87ef773ff38b48d7f Author: Greg Kroah-Hartman Date: Thu Jun 9 10:23:32 2022 +0200 Linux 5.15.46 Link: https://lore.kernel.org/r/20220607164934.766888869@linuxfoundation.org Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit c24cff01242005a958f1c0921f8a783ec0591911 Author: Jan Kara Date: Thu Jun 2 10:12:42 2022 +0200 block: fix bio_clone_blkg_association() to associate with proper blkcg_gq commit 22b106e5355d6e7a9c3b5cb5ed4ef22ae585ea94 upstream. Commit d92c370a16cb ("block: really clone the block cgroup in bio_clone_blkg_association") changed bio_clone_blkg_association() to just clone bio->bi_blkg reference from source to destination bio. This is however wrong if the source and destination bios are against different block devices because struct blkcg_gq is different for each bdev-blkcg pair. This will result in IOs being accounted (and throttled as a result) multiple times against the same device (src bdev) while throttling of the other device (dst bdev) is ignored. In case of BFQ the inconsistency can even result in crashes in bfq_bic_update_cgroup(). Fix the problem by looking up correct blkcg_gq for the cloned bio. Reported-by: Logan Gunthorpe Reported-and-tested-by: Donald Buczek Fixes: d92c370a16cb ("block: really clone the block cgroup in bio_clone_blkg_association") CC: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220602081242.7731-1-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 97a40c22013adfbabb39fedf895e8febaa5b48a3 Author: Caleb Connolly Date: Mon Mar 28 01:50:03 2022 +0100 pinctrl/rockchip: support setting input-enable param commit 42d90a1e5caf73138ddde42da5a9fe2b543f9a2c upstream. Handle the PIN_CONFIG_INPUT_ENABLE param for configuring GPIOs as input. Signed-off-by: Caleb Connolly Link: https://lore.kernel.org/r/20220328005005.72492-3-kc@postmarketos.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 2027647245ef44d6a86dc2a2220457e2fc8d3349 Author: Jia-Ju Bai Date: Fri May 27 23:28:18 2022 +0800 md: bcache: check the return value of kzalloc() in detached_dev_do_request() commit 40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19 upstream. The function kzalloc() in detached_dev_do_request() can fail, so its return value should be checked. Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached bcache devices") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: Coly Li Link: https://lore.kernel.org/r/20220527152818.27545-4-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 36a2fc44c574a59ee3b5e2cb327182f227b2b07e Author: Xiao Ni Date: Thu May 12 17:21:09 2022 +0800 md: fix double free of io_acct_set bioset commit 42b805af102471f53e3c7867b8c2b502ea4eef7e upstream. Now io_acct_set is alloc and free in personality. Remove the codes that free io_acct_set in md_free and md_stop. Fixes: 0c031fd37f69 (md: Move alloc/free acct bioset in to personality) Signed-off-by: Xiao Ni Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit f63fd1e0e0fc158023cc67ea6a07e278019061ba Author: Xiao Ni Date: Thu May 12 17:21:08 2022 +0800 md: Don't set mddev private to NULL in raid0 pers->free commit 0f2571ad7a30ff6b33cde142439f9378669f8b4f upstream. In normal stop process, it does like this: do_md_stop | __md_stop (pers->free(); mddev->private=NULL) | md_free (free mddev) __md_stop sets mddev->private to NULL after pers->free. The raid device will be stopped and mddev memory is free. But in reshape, it doesn't free the mddev and mddev will still be used in new raid. In reshape, it first sets mddev->private to new_pers and then runs old_pers->free(). Now raid0 sets mddev->private to NULL in raid0_free. The new raid can't work anymore. It will panic when dereference mddev->private because of NULL pointer dereference. It can panic like this: [63010.814972] kernel BUG at drivers/md/raid10.c:928! [63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1 [63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020 [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10] [63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246 [63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000 [63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800 [63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000 [63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200 [63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003 [63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000 [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0 [63010.927363] Call Trace: [63010.929822] ? bio_reset+0xe/0x40 [63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10] [63010.938629] raid10_sync_request+0x756/0x1610 [raid10] [63010.943770] md_do_sync.cold+0x3e4/0x94c [63010.947698] md_thread+0xab/0x160 [63010.951024] ? md_write_inc+0x50/0x50 [63010.954688] kthread+0x149/0x170 [63010.957923] ? set_kthread_struct+0x40/0x40 [63010.962107] ret_from_fork+0x22/0x30 Removing the code that sets mddev->private to NULL in raid0 can fix problem. Fixes: 0c031fd37f69 (md: Move alloc/free acct bioset in to personality) Reported-by: Fine Fan Signed-off-by: Xiao Ni Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 61decb58486d7c0cbded25fe4d301ab4fa148cd8 Author: Namjae Jeon Date: Mon May 30 18:43:01 2022 +0300 fs/ntfs3: Fix invalid free in log_replay commit f26967b9f7a830e228bb13fb41bd516ddd9d789d upstream. log_read_rst() returns ENOMEM error when there is not enough memory. In this case, if info is returned without initialization, it attempts to kfree the uninitialized info->r_page pointer. This patch moves the memset initialization code to before log_read_rst() is called. Reported-by: Gerald Lee Signed-off-by: Namjae Jeon Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 00f1de9cffec26c4a80d36e8bf7509506825b360 Author: Christian Brauner Date: Mon Apr 4 12:51:41 2022 +0200 exportfs: support idmapped mounts commit 3a761d72fa62eec8913e45d29375344f61706541 upstream. Make the two locations where exportfs helpers check permission to lookup a given inode idmapped mount aware by switching it to the lookup_one() helper. This is a bugfix for the open_by_handle_at() system call which doesn't take idmapped mounts into account currently. It's not tied to a specific commit so we'll just Cc stable. In addition this is required to support idmapped base layers in overlay. The overlay filesystem uses exportfs to encode and decode file handles for its index=on mount option and when nfs_export=on. Cc: Cc: Tested-by: Giuseppe Scrivano Reviewed-by: Amir Goldstein Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit e5b310b512e748461be4bf954fc684cbeda24416 Author: Christian Brauner Date: Mon Apr 4 12:51:40 2022 +0200 fs: add two trivial lookup helpers commit 00675017e0aeba5305665c52ded4ddce6a4c0231 upstream. Similar to the addition of lookup_one() add a version of lookup_one_unlocked() and lookup_one_positive_unlocked() that take idmapped mounts into account. This is required to port overlay to support idmapped base layers. Cc: Tested-by: Giuseppe Scrivano Reviewed-by: Amir Goldstein Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit b175e8c46d93bc958db9810b769e70316687b9e6 Author: Mike Tipton Date: Thu Nov 25 19:47:51 2021 +0200 interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate commit b95b668eaaa2574e8ee72f143c52075e9955177e upstream. We're only adding BCMs to the commit list in aggregate(), but there are cases where pre_aggregate() is called without subsequently calling aggregate(). In particular, in icc_sync_state() when a node with initial BW has zero requests. Since BCMs aren't added to the commit list in these cases, we don't actually send the zero BW request to HW. So the resources remain on unnecessarily. Add BCMs to the commit list in pre_aggregate() instead, which is always called even when there are no requests. Signed-off-by: Mike Tipton [georgi: remove icc_sync_state for platforms with incomplete support] Link: https://lore.kernel.org/r/20211125174751.25317-1-djakov@kernel.org Signed-off-by: Georgi Djakov Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 8e79bf98061c9171719f5413559715e45c7c0402 Author: Stephen Boyd Date: Tue Apr 12 15:00:32 2022 -0700 interconnect: qcom: sc7180: Drop IP0 interconnects commit 2f3724930eb4bba74f7d10bc3bef5bb22dd323df upstream. The IPA BCM resource ("IP0") on sc7180 was moved to the clk-rpmh driver in commit bcd63d222b60 ("clk: qcom: rpmh: Add IPA clock for SC7180") and modeled as a clk, but this interconnect driver still had it modeled as an interconnect. This was mostly OK because nobody used the interconnect definition, until the interconnect framework started dropping bandwidth requests on interconnects that aren't used via the sync_state callback in commit 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state"). Once that patch was applied the IP0 resource was going to be controlled from two places, the clk framework and the interconnect framework. Even then, things were probably going to be OK, because commit b95b668eaaa2 ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate") was needed to actually drop bandwidth requests on unused interconnects, of which the IPA was one of the interconnect that wasn't getting dropped to zero. Combining the three commits together leads to bad behavior where the interconnect framework is disabling the IP0 resource because it has no users while the clk framework thinks the IP0 resource is on because the only user, the IPA driver, has turned it on via clk_prepare_enable(). Depending on when sync_state is called, we can get into a situation like below: IPA driver probes IPA driver gets notified modem started runtime PM get() IPA clk enabled -> IP0 resource is ON sync_state runs interconnect zeroes out the IP0 resource -> IP0 resource is off IPA driver tries to access a register and blows up The crash is an unclocked access that manifest as an SError. SError Interrupt on CPU0, code 0xbe000011 -- SError CPU: 0 PID: 3595 Comm: mmdata_mgr Not tainted 5.17.1+ #166 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mutex_lock+0x4c/0x80 lr : mutex_lock+0x30/0x80 sp : ffffffc00da9b9c0 x29: ffffffc00da9b9c0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffc00da9bc90 x25: ffffff80c2024010 x24: ffffff80c2024000 x23: ffffff8083100000 x22: ffffff80831000d0 x21: ffffff80831000a8 x20: ffffff80831000a8 x19: ffffff8083100070 x18: 00000000ffff0a00 x17: 000000002f7254f1 x16: 0000000000000100 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 000000000001f0b8 x10: ffffffc00931f0b8 x9 : 0000000000000000 x8 : 0000000000000000 x7 : fefefefefeff2f60 x6 : 0000808080808080 x5 : 0000000000000000 x4 : 8080808080800000 x3 : ffffff80d2d4ee28 x2 : ffffff808c1d6e40 x1 : 0000000000000000 x0 : ffffff8083100070 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 0 PID: 3595 Comm: mmdata_mgr Not tainted 5.17.1+ #166 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) Call trace: dump_backtrace+0xf4/0x114 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 panic+0x150/0x38c nmi_panic+0x88/0xa0 arm64_serror_panic+0x74/0x80 do_serror+0x0/0x80 do_serror+0x58/0x80 el1h_64_error_handler+0x34/0x4c el1h_64_error+0x78/0x7c mutex_lock+0x4c/0x80 __gsi_channel_start+0x50/0x17c gsi_channel_start+0x54/0x90 ipa_endpoint_enable_one+0x34/0xc0 ipa_open+0x4c/0x120 Remove all IP0 resource management from the interconnect driver so that clk-rpmh is the sole owner. This fixes the issue by preventing the interconnect driver from overwriting the IP0 resource data that the clk-rpmh driver wrote. Cc: Alex Elder Cc: Bjorn Andersson Cc: Taniya Das Cc: Mike Tipton Fixes: b95b668eaaa2 ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate") Fixes: bcd63d222b60 ("clk: qcom: rpmh: Add IPA clock for SC7180") Fixes: 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state") Signed-off-by: Stephen Boyd Tested-by: Alex Elder Reviewed-by: Alex Elder Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220412220033.1273607-2-swboyd@chromium.org Signed-off-by: Georgi Djakov Signed-off-by: Greg Kroah-Hartman commit d973bc80e7d4065cdf566246772d60515760adc5 Author: Eric Biggers Date: Thu May 19 13:44:37 2022 -0700 ext4: only allow test_dummy_encryption when supported commit 5f41fdaea63ddf96d921ab36b2af4a90ccdb5744 upstream. Make the test_dummy_encryption mount option require that the encrypt feature flag be already enabled on the filesystem, rather than automatically enabling it. Practically, this means that "-O encrypt" will need to be included in MKFS_OPTIONS when running xfstests with the test_dummy_encryption mount option. (ext4/053 also needs an update.) Moreover, as long as the preconditions for test_dummy_encryption are being tightened anyway, take the opportunity to start rejecting it when !CONFIG_FS_ENCRYPTION rather than ignoring it. The motivation for requiring the encrypt feature flag is that: - Having the filesystem auto-enable feature flags is problematic, as it bypasses the usual sanity checks. The specific issue which came up recently is that in kernel versions where ext4 supports casefold but not encrypt+casefold (v5.1 through v5.10), the kernel will happily add the encrypt flag to a filesystem that has the casefold flag, making it unmountable -- but only for subsequent mounts, not the initial one. This confused the casefold support detection in xfstests, causing generic/556 to fail rather than be skipped. - The xfstests-bld test runners (kvm-xfstests et al.) already use the required mkfs flag, so they will not be affected by this change. Only users of test_dummy_encryption alone will be affected. But, this option has always been for testing only, so it should be fine to require that the few users of this option update their test scripts. - f2fs already requires it (for its equivalent feature flag). Signed-off-by: Eric Biggers Reviewed-by: Gabriel Krisman Bertazi Link: https://lore.kernel.org/r/20220519204437.61645-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit cd2086394f04437a005bc7f8a8c8351fc093e1bf Author: Maciej W. Rozycki Date: Sun May 1 23:14:22 2022 +0100 MIPS: IP30: Remove incorrect `cpu_has_fpu' override commit f44b3e74c33fe04defeff24ebcae98c3bcc5b285 upstream. Remove unsupported forcing of `cpu_has_fpu' to 1, which makes the `nofpu' kernel parameter non-functional, and also causes a link error: ld: arch/mips/kernel/traps.o: in function `trap_init': ./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe' where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled. Signed-off-by: Maciej W. Rozycki Reported-by: Stephen Zhang Fixes: 7505576d1c1a ("MIPS: add support for SGI Octane (IP30)") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit bfa8e0dfa2ff234390a8ff9803ba549879a4b748 Author: Maciej W. Rozycki Date: Sun May 1 23:14:16 2022 +0100 MIPS: IP27: Remove incorrect `cpu_has_fpu' override commit 424c3781dd1cb401857585331eaaa425a13f2429 upstream. Remove unsupported forcing of `cpu_has_fpu' to 1, which makes the `nofpu' kernel parameter non-functional, and also causes a link error: ld: arch/mips/kernel/traps.o: in function `trap_init': ./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe' where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled. Signed-off-by: Maciej W. Rozycki Reported-by: Stephen Zhang Fixes: 0ebb2f4159af ("MIPS: IP27: Update/restructure CPU overrides") Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 9262f0ce3c76e769db10e525a37d241cfedca962 Author: Xiao Yang Date: Sun Apr 10 19:35:13 2022 +0800 RDMA/rxe: Generate a completion for unsupported/invalid opcode commit 2f917af777011c88e977b9b9a5d00b280d3a59ce upstream. Current rxe_requester() doesn't generate a completion when processing an unsupported/invalid opcode. If rxe driver doesn't support a new opcode (e.g. RDMA Atomic Write) and RDMA library supports it, an application using the new opcode can reproduce this issue. Fix the issue by calling "goto err;". Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20220410113513.27537-1-yangx.jy@fujitsu.com Signed-off-by: Xiao Yang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 83f4a22ca6ec74852e57b38874f79c5ead4482da Author: Yixing Liu Date: Fri Apr 29 17:35:45 2022 +0800 RDMA/hns: Remove the num_cqc_timer variable commit db5dfbf5b201df65c1f5332c4d9d5e7c2f42396b upstream. The bt number of cqc_timer of HIP09 increases compared with that of HIP08. Therefore, cqc_timer_bt_num and num_cqc_timer do not match. As a result, the driver may fail to allocate cqc_timer. So the driver needs to uniquely uses cqc_timer_bt_num to represent the bt number of cqc_timer. Fixes: 0e40dc2f70cd ("RDMA/hns: Add timer allocation support for hip08") Link: https://lore.kernel.org/r/20220429093545.58070-1-liangwenpeng@huawei.com Signed-off-by: Yixing Liu Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit fdcb03632ab6a365167964f0a5d36fd175cdcab9 Author: Dan Carpenter Date: Thu May 19 08:17:20 2022 +0300 staging: r8188eu: delete rtw_wx_read/write32() commit 4d0cc9e0e53e9946d7b8dc58279c62dfa7a2191b upstream. These debugging tools let you call: status = usb_control_msg_recv/send(udev, 0, REALTEK_USB_VENQT_CMD_REQ, REALTEK_USB_VENQT_READ/WRITE, value, REALTEK_USB_VENQT_CMD_IDX, io_buf, size, RTW_USB_CONTROL_MSG_TIMEOUT, GFP_KERNEL); with a user controlled "value" in the 0-0xffff range. It's not a valid API. Fixes: 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YoXS4OaD1oauPvmj@kili Signed-off-by: Greg Kroah-Hartman commit 6004fccaf82f71d6cd03537ef08d182487eb8d5e Author: Jason A. Donenfeld Date: Tue Jun 7 10:40:05 2022 +0200 Revert "random: use static branch for crng_ready()" This reverts upstream commit f5bda35fba615ace70a656d4700423fa6c9bebee from stable. It's not essential and will take some time during 5.19 to work out properly. Signed-off-by: Jason A. Donenfeld commit 358f12ae2e53bf402b5e864f74d083d330f59977 Author: David Gow Date: Fri Feb 25 10:52:48 2022 +0800 list: test: Add a test for list_is_head() commit 37dc573c0a547e1aed0c9abb480fab797bd3833f upstream. list_is_head() was added recently[1], and didn't have a KUnit test. The implementation is trivial, so it's not a particularly exciting test, but it'd be nice to get back to full coverage of the list functions. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/list.h?id=0425473037db40d9e322631f2d4dc6ef51f97e88 Signed-off-by: David Gow Acked-by: Daniel Latypov Acked-by: Brendan Higgins Reviewed-by: Andy Shevchenko Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 85a2806c40dae9b4ccefd94a4ce1e9f6307d4b6e Author: Waiman Long Date: Fri May 13 15:09:28 2022 -0400 kseltest/cgroup: Make test_stress.sh work if run interactively commit 213adc63dfbcdff9a0c19ec1f2681fda9c05cf6d upstream. Commit 54de76c01239 ("kselftest/cgroup: fix test_stress.sh to use OUTPUT dir") changes the test_core command path from . to $OUTPUT. However, variable OUTPUT may not be defined if the command is run interactively. Fix that by using ${OUTPUT:-.} to cover both cases. Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 1810bafaca2bb3bca6e6ae29a79f55d454ef5021 Author: Alex Elder Date: Thu May 26 10:23:14 2022 -0500 net: ipa: fix page free in ipa_endpoint_replenish_one() commit 70132763d5d2e94cd185e3aa92ac6a3ba89068fa upstream. Currently the (possibly compound) pages used for receive buffers are freed using __free_pages(). But according to this comment above the definition of that function, that's wrong: If you want to use the page's reference count to decide when to free the allocation, you should allocate a compound page, and use put_page() instead of __free_pages(). Convert the call to __free_pages() in ipa_endpoint_replenish_one() to use put_page() instead. Fixes: 6a606b90153b8 ("net: ipa: allocate transaction in replenish loop") Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f654596e3a0864012bb3a5a5234f5c88c293c5c6 Author: Alex Elder Date: Thu May 26 10:23:13 2022 -0500 net: ipa: fix page free in ipa_endpoint_trans_release() commit 155c0c90bca918de6e4327275dfc1d97fd604115 upstream. Currently the (possibly compound) page used for receive buffers are freed using __free_pages(). But according to this comment above the definition of that function, that's wrong: If you want to use the page's reference count to decide when to free the allocation, you should allocate a compound page, and use put_page() instead of __free_pages(). Convert the call to __free_pages() in ipa_endpoint_trans_release() to use put_page() instead. Fixes: ed23f02680caa ("net: ipa: define per-endpoint receive buffer size") Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ba173a6f8d8dffed64bb13ab23081bdddfb464f0 Author: Johan Hovold Date: Wed Apr 27 08:32:42 2022 +0200 phy: qcom-qmp: fix reset-controller leak on probe errors commit 4d2900f20edfe541f75756a00deeb2ffe7c66bc1 upstream. Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral). Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly. Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets") Cc: stable@vger.kernel.org # 4.12 Cc: Vivek Gautam Reviewed-by: Philipp Zabel Signed-off-by: Johan Hovold Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220427063243.32576-3-johan+linaro@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit e9f53bfcd4ae9790504ed8dc450b2260abe666b5 Author: Mao Jinlong Date: Wed Mar 9 06:22:06 2022 -0800 coresight: core: Fix coresight device probe failure issue commit 8c1d3f79d9ca48e406b78e90e94cf09a8c076bf2 upstream. It is possibe that probe failure issue happens when the device and its child_device's probe happens at the same time. In coresight_make_links, has_conns_grp is true for parent, but has_conns_grp is false for child device as has_conns_grp is set to true in coresight_create_conns_sysfs_group. The probe of parent device will fail at this condition. Add has_conns_grp check for child device before make the links and make the process from device_register to connection_create be atomic to avoid this probe failure issue. Cc: stable@vger.kernel.org Suggested-by: Suzuki K Poulose Suggested-by: Mike Leach Signed-off-by: Mao Jinlong Link: https://lore.kernel.org/r/20220309142206.15632-1-quic_jinlmao@quicinc.com [ Added Cc stable ] Signed-off-by: Suzuki K Poulose Signed-off-by: Greg Kroah-Hartman commit a30acbb5dfb7bcc813ad6a18ca31011ac44e5547 Author: Tejun Heo Date: Fri May 13 20:55:45 2022 -1000 blk-iolatency: Fix inflight count imbalances and IO hangs on offline commit 8a177a36da6c54c98b8685d4f914cb3637d53c0d upstream. iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared. Signed-off-by: Tejun Heo Cc: Josef Bacik Cc: Liu Bo Fixes: 8c772a9bfc7c ("blk-iolatency: fix IO hang due to negative inflight counter") Cc: stable@vger.kernel.org # v5.0+ Link: https://lore.kernel.org/r/Yn9ScX6Nx2qIiQQi@slm.duckdns.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 501c5eae2697db2254b55d4c61dae30963f400c4 Author: Eugenio Pérez Date: Thu May 19 16:59:19 2022 +0200 vdpasim: allow to enable a vq repeatedly commit 242436973831aa97e8ce19533c6c912ea8def31b upstream. Code must be resilient to enable a queue many times. At the moment the queue is resetting so it's definitely not the expected behavior. v2: set vq->ready = 0 at disable. Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator") Cc: stable@vger.kernel.org Signed-off-by: Eugenio Pérez Message-Id: <20220519145919.772896-1-eperezma@redhat.com> Signed-off-by: Michael S. Tsirkin Reviewed-by: Stefano Garzarella Signed-off-by: Greg Kroah-Hartman commit bd56db7cb81ea1e29c5066514697479abd9a5c37 Author: Dinh Nguyen Date: Wed May 11 12:54:46 2022 -0500 dt-bindings: gpio: altera: correct interrupt-cells commit 3a21c3ac93aff7b4522b152399df8f6a041df56d upstream. update documentation to correctly state the interrupt-cells to be 2. Cc: stable@vger.kernel.org Fixes: 4fd9bbc6e071 ("drivers/gpio: Altera soft IP GPIO driver devicetree binding") Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 5b726ed6a54c0cfc8264cf186e6b6efb099959cd Author: Akira Yokosawa Date: Wed Jun 1 23:34:06 2022 +0900 docs/conf.py: Cope with removal of language=None in Sphinx 5.0.0 commit 627f01eab93d8671d4e4afee9b148f9998d20e7c upstream. One of the changes in Sphinx 5.0.0 [1] says [sic]: 5.0.0 final - #10474: language does not accept None as it value. The default value of language becomes to 'en' now. [1]: https://www.sphinx-doc.org/en/master/changes.html#release-5-0-0-released-may-30-2022 It results in a new warning from Sphinx 5.0.0 [sic]: WARNING: Invalid configuration value found: 'language = None'. Update your configuration to a valid langauge code. Falling back to 'en' (English). Silence the warning by using 'en'. It works with all the Sphinx versions required for building kernel documentation (1.7.9 or later). Signed-off-by: Akira Yokosawa Link: https://lore.kernel.org/r/bd0c2ddc-2401-03cb-4526-79ca664e1cbe@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit b5cb51cf21f5bd388392fdbe752b6db006a29212 Author: Steve French Date: Thu May 12 10:18:00 2022 -0500 SMB3: EBADF/EIO errors in rename/open caused by race condition in smb2_compound_op commit 0a55cf74ffb5d004b93647e4389096880ce37d6b upstream. There is a race condition in smb2_compound_op: after_close: num_rqst++; if (cfile) { cifsFileInfo_put(cfile); // sends SMB2_CLOSE to the server cfile = NULL; This is triggered by smb2_query_path_info operation that happens during revalidate_dentry. In smb2_query_path_info, get_readable_path is called to load the cfile, increasing the reference counter. If in the meantime, this reference becomes the very last, this call to cifsFileInfo_put(cfile) will trigger a SMB2_CLOSE request sent to the server just before sending this compound request – and so then the compound request fails either with EBADF/EIO depending on the timing at the server, because the handle is already closed. In the first scenario, the race seems to be happening between smb2_query_path_info triggered by the rename operation, and between “cleanup” of asynchronous writes – while fsync(fd) likely waits for the asynchronous writes to complete, releasing the writeback structures can happen after the close(fd) call. So the EBADF/EIO errors will pop up if the timing is such that: 1) There are still outstanding references after close(fd) in the writeback structures 2) smb2_query_path_info successfully fetches the cfile, increasing the refcounter by 1 3) All writeback structures release the same cfile, reducing refcounter to 1 4) smb2_compound_op is called with that cfile In the second scenario, the race seems to be similar – here open triggers the smb2_query_path_info operation, and if all other threads in the meantime decrease the refcounter to 1 similarly to the first scenario, again SMB2_CLOSE will be sent to the server just before issuing the compound request. This case is harder to reproduce. See https://bugzilla.samba.org/show_bug.cgi?id=15051 Cc: stable@vger.kernel.org Fixes: 8de9e86c67ba ("cifs: create a helper to find a writeable handle by path name") Signed-off-by: Ondrej Hubsch Reviewed-by: Ronnie Sahlberg Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 54de256d35b00651fd7ede9e8e849bd06988811a Author: Arnd Bergmann Date: Wed Sep 11 22:31:51 2019 +0200 ARM: pxa: maybe fix gpio lookup tables commit 2672a4bff6c03a20d5ae460a091f67ee782c3eff upstream. From inspection I found a couple of GPIO lookups that are listed with device "gpio-pxa", but actually have a number from a different gpio controller. Try to rectify that here, with a guess of what the actual device name is. Acked-by: Robert Jarzmik Reviewed-by: Linus Walleij Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 2c3dd5badde8ad1ad9ff6d1776e3514716d2b6a0 Author: Jonathan Bakker Date: Sun Mar 27 11:08:50 2022 -0700 ARM: dts: s5pv210: Remove spi-cs-high on panel in Aries commit 096f58507374e1293a9e9cff8a1ccd5f37780a20 upstream. Since commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors"), the panel has been blank due to an inverted CS GPIO. In order to correct this, drop the spi-cs-high from the panel SPI device. Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors") Cc: Signed-off-by: Jonathan Bakker Link: https://lore.kernel.org/r/CY4PR04MB05670C771062570E911AF3B4CB1C9@CY4PR04MB0567.namprd04.prod.outlook.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit b246695636a861a09f0e2cde92bb2dd8f114f024 Author: Johan Hovold Date: Wed Apr 27 08:32:41 2022 +0200 phy: qcom-qmp: fix struct clk leak on probe errors commit f0a4bc38a12f5a0cc5ad68670d9480e91e6a94df upstream. Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral). Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets") Cc: stable@vger.kernel.org # 4.12 Cc: Vivek Gautam Reviewed-by: Bjorn Andersson Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20220427063243.32576-2-johan+linaro@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit ebc56b0f737b8effec7dade67f46b242849d460b Author: Diogo Ivo Date: Fri Apr 29 13:58:43 2022 +0100 clk: tegra: Add missing reset deassertion commit 23a43cc437e747473d5f8f98b4fe189fb5c433b7 upstream. Commit 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling clocks") removed deassertion of reset lines when enabling peripheral clocks. This breaks the initialization of the DFLL driver which relied on this behaviour. Fix this problem by adding explicit deassert/assert requests to the driver. Tested on Google Pixel C. Cc: stable@vger.kernel.org Fixes: 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling clocks") Signed-off-by: Diogo Ivo Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit c465cf934bb1c2b63b09b8ebb7dd8730b030f131 Author: Diogo Ivo Date: Fri Apr 29 13:58:43 2022 +0100 arm64: tegra: Add missing DFLL reset on Tegra210 commit 0017f2c856e21bb900be88469e15dac4f41f4065 upstream. Commit 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling clocks") removed deassertion of reset lines when enabling peripheral clocks. This breaks the initialization of the DFLL driver which relied on this behaviour. In order to be able to fix this, add the corresponding reset to the DT. Tested on Google Pixel C. Cc: stable@vger.kernel.org Fixes: 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling clocks") Signed-off-by: Diogo Ivo Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 977cc97b2e50904e9c5d62059cf46ba466e080b1 Author: Kathiravan T Date: Fri Feb 11 17:44:15 2022 +0530 arm64: dts: qcom: ipq8074: fix the sleep clock frequency commit f607dd767f5d6800ffbdce5b99ba81763b023781 upstream. Sleep clock frequency should be 32768Hz. Lets fix it. Cc: stable@vger.kernel.org Fixes: 41dac73e243d ("arm64: dts: Add ipq8074 SoC and HK01 board support") Link: https://lore.kernel.org/all/e2a447f8-6024-0369-f698-2027b6edcf9e@codeaurora.org/ Signed-off-by: Kathiravan T Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1644581655-11568-1-git-send-email-quic_kathirav@quicinc.com Signed-off-by: Greg Kroah-Hartman commit 99367bf45dc61dccf57207aede41c2142ea08f38 Author: Xiaomeng Tong Date: Sun Mar 27 13:20:28 2022 +0800 gma500: fix an incorrect NULL check on list iterator commit bdef417d84536715145f6dc9cc3275c46f26295a upstream. The bug is here: return crtc; The list iterator value 'crtc' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, return 'crtc' when found, otherwise return NULL. Cc: stable@vger.kernel.org fixes: 89c78134cc54d ("gma500: Add Poulsbo support") Signed-off-by: Xiaomeng Tong Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/20220327052028.2013-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9a1f41d77bb4cf54a001a7cbc3d4c0808eebe98c Author: Xiaomeng Tong Date: Sun Mar 27 14:15:16 2022 +0800 tilcdc: tilcdc_external: fix an incorrect NULL check on list iterator commit 8b917cbe38e9b0d002492477a9fc2bfee2412ce4 upstream. The bug is here: if (!encoder) { The list iterator value 'encoder' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'encoder' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: ec9eab097a500 ("drm/tilcdc: Add drm bridge support for attaching drm bridge drivers") Signed-off-by: Xiaomeng Tong Reviewed-by: Jyri Sarha Tested-by: Jyri Sarha Signed-off-by: Jyri Sarha Link: https://patchwork.freedesktop.org/patch/msgid/20220327061516.5076-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman commit 339ddef25f8697c0d5747634ad289f3c8188f376 Author: Jiri Slaby Date: Tue May 3 10:08:03 2022 +0200 serial: pch: don't overwrite xmit->buf[0] by x_char commit d9f3af4fbb1d955bbaf872d9e76502f6e3e803cb upstream. When x_char is to be sent, the TX path overwrites whatever is in the circular buffer at offset 0 with x_char and sends it using pch_uart_hal_write(). I don't understand how this was supposed to work if xmit->buf[0] already contained some character. It must have been lost. Remove this whole pop_tx_x() concept and do the work directly in the callers. (Without printing anything using dev_dbg().) Cc: Fixes: 3c6a483275f4 (Serial: EG20T: add PCH_UART driver) Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20220503080808.28332-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman commit 5607652823ac65e2c6885e73bd46d5a4f9a20363 Author: Coly Li Date: Tue May 24 18:23:36 2022 +0800 bcache: avoid journal no-space deadlock by reserving 1 journal bucket commit 32feee36c30ea06e38ccb8ae6e5c44c6eec790a6 upstream. The journal no-space deadlock was reported time to time. Such deadlock can happen in the following situation. When all journal buckets are fully filled by active jset with heavy write I/O load, the cache set registration (after a reboot) will load all active jsets and inserting them into the btree again (which is called journal replay). If a journaled bkey is inserted into a btree node and results btree node split, new journal request might be triggered. For example, the btree grows one more level after the node split, then the root node record in cache device super block will be upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no space in journal buckets, the journal replay has to wait for new journal bucket to be reclaimed after at least one journal bucket replayed. This is one example that how the journal no-space deadlock happens. The solution to avoid the deadlock is to reserve 1 journal bucket in run time, and only permit the reserved journal bucket to be used during cache set registration procedure for things like journal replay. Then the journal space will never be fully filled, there is no chance for journal no-space deadlock to happen anymore. This patch adds a new member "bool do_reserve" in struct journal, it is inititalized to 0 (false) when struct journal is allocated, and set to 1 (true) by bch_journal_space_reserve() when all initialization done in run_cache_set(). In the run time when journal_reclaim() tries to allocate a new journal bucket, free_journal_buckets() is called to check whether there are enough free journal buckets to use. If there is only 1 free journal bucket and journal->do_reserve is 1 (true), the last bucket is reserved and free_journal_buckets() will return 0 to indicate no free journal bucket. Then journal_reclaim() will give up, and try next time to see whetheer there is free journal bucket to allocate. By this method, there is always 1 jouranl bucket reserved in run time. During the cache set registration, journal->do_reserve is 0 (false), so the reserved journal bucket can be used to avoid the no-space deadlock. Reported-by: Nikhil Kshirsagar Signed-off-by: Coly Li Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220524102336.10684-5-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit cc7ff57a0acf349c4d7ed79d01a4078646e478d8 Author: Coly Li Date: Tue May 24 18:23:35 2022 +0800 bcache: remove incremental dirty sector counting for bch_sectors_dirty_init() commit 80db4e4707e78cb22287da7d058d7274bd4cb370 upstream. After making bch_sectors_dirty_init() being multithreaded, the existing incremental dirty sector counting in bch_root_node_dirty_init() doesn't release btree occupation after iterating 500000 (INIT_KEYS_EACH_TIME) bkeys. Because a read lock is added on btree root node to prevent the btree to be split during the dirty sectors counting, other I/O requester has no chance to gain the write lock even restart bcache_btree(). That is to say, the incremental dirty sectors counting is incompatible to the multhreaded bch_sectors_dirty_init(). We have to choose one and drop another one. In my testing, with 512 bytes random writes, I generate 1.2T dirty data and a btree with 400K nodes. With single thread and incremental dirty sectors counting, it takes 30+ minites to register the backing device. And with multithreaded dirty sectors counting, the backing device registration can be accomplished within 2 minutes. The 30+ minutes V.S. 2- minutes difference makes me decide to keep multithreaded bch_sectors_dirty_init() and drop the incremental dirty sectors counting. This is what this patch does. But INIT_KEYS_EACH_TIME is kept, in sectors_dirty_init_fn() the CPU will be released by cond_resched() after every INIT_KEYS_EACH_TIME keys iterated. This is to avoid the watchdog reports a bogus soft lockup warning. Fixes: b144e45fc576 ("bcache: make bch_sectors_dirty_init() to be multithreaded") Signed-off-by: Coly Li Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220524102336.10684-4-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit df973468f9cebeaa9fd5a11c22b73599e1ebe8a7 Author: Coly Li Date: Tue May 24 18:23:34 2022 +0800 bcache: improve multithreaded bch_sectors_dirty_init() commit 4dc34ae1b45fe26e772a44379f936c72623dd407 upstream. Commit b144e45fc576 ("bcache: make bch_sectors_dirty_init() to be multithreaded") makes bch_sectors_dirty_init() to be much faster when counting dirty sectors by iterating all dirty keys in the btree. But it isn't in ideal shape yet, still can be improved. This patch does the following changes to improve current parallel dirty keys iteration on the btree, - Add read lock to root node when multiple threads iterating the btree, to prevent the root node gets split by I/Os from other registered bcache devices. - Remove local variable "char name[32]" and generate kernel thread name string directly when calling kthread_run(). - Allocate "struct bch_dirty_init_state state" directly on stack and avoid the unnecessary dynamic memory allocation for it. - Decrease BCH_DIRTY_INIT_THRD_MAX from 64 to 12 which is enough indeed. - Increase &state->started to count created kernel thread after it succeeds to create. - When wait for all dirty key counting threads to finish, use wait_event() to replace wait_event_interruptible(). With the above changes, the code is more clear, and some potential error conditions are avoided. Fixes: b144e45fc576 ("bcache: make bch_sectors_dirty_init() to be multithreaded") Signed-off-by: Coly Li Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220524102336.10684-3-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a5580b90d378cfaa150c145d4880c9047810fb7f Author: Coly Li Date: Tue May 24 18:23:33 2022 +0800 bcache: improve multithreaded bch_btree_check() commit 622536443b6731ec82c563aae7807165adbe9178 upstream. Commit 8e7102273f59 ("bcache: make bch_btree_check() to be multithreaded") makes bch_btree_check() to be much faster when checking all btree nodes during cache device registration. But it isn't in ideal shap yet, still can be improved. This patch does the following thing to improve current parallel btree nodes check by multiple threads in bch_btree_check(), - Add read lock to root node while checking all the btree nodes with multiple threads. Although currently it is not mandatory but it is good to have a read lock in code logic. - Remove local variable 'char name[32]', and generate kernel thread name string directly when calling kthread_run(). - Allocate local variable "struct btree_check_state check_state" on the stack and avoid unnecessary dynamic memory allocation for it. - Reduce BCH_BTR_CHKTHREAD_MAX from 64 to 12 which is enough indeed. - Increase check_state->started to count created kernel thread after it succeeds to create. - When wait for all checking kernel threads to finish, use wait_event() to replace wait_event_interruptible(). With this change, the code is more clear, and some potential error conditions are avoided. Fixes: 8e7102273f59 ("bcache: make bch_btree_check() to be multithreaded") Signed-off-by: Coly Li Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220524102336.10684-2-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2037d8cf8ceba8dbb37dd0528af9b6a2ee1b3631 Author: Xiaomeng Tong Date: Sun Mar 27 13:53:55 2022 +0800 stm: ltdc: fix two incorrect NULL checks on list iterator commit 2e6c86be0e57079d1fb6c7c7e5423db096d0548a upstream. The two bugs are here: if (encoder) { if (bridge && bridge->timings) The list iterator value 'encoder/bridge' will *always* be set and non-NULL by drm_for_each_encoder()/list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, use a new variable '*_iter' as the list iterator, while use the old variable 'encoder/bridge' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: 99e360442f223 ("drm/stm: Fix bus_flags handling") Signed-off-by: Xiaomeng Tong Acked-by: Raphael Gallais-Pou Signed-off-by: Philippe Cornu Link: https://patchwork.freedesktop.org/patch/msgid/20220327055355.3808-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9161ae1c04cd1f5a84008d1f75608d899c3177b4 Author: Xiaomeng Tong Date: Mon Mar 28 20:28:20 2022 +0800 carl9170: tx: fix an incorrect use of list iterator commit 54a6f29522da3c914da30e50721dedf51046449a upstream. If the previous list_for_each_entry_continue_rcu() don't exit early (no goto hit inside the loop), the iterator 'cvif' after the loop will be a bogus pointer to an invalid structure object containing the HEAD (&ar->vif_list). As a result, the use of 'cvif' after that will lead to a invalid memory access (i.e., 'cvif->id': the invalid pointer dereference when return back to/after the callsite in the carl9170_update_beacon()). The original intention should have been to return the valid 'cvif' when found in list, NULL otherwise. So just return NULL when no entry found, to fix this bug. Cc: stable@vger.kernel.org Fixes: 1f1d9654e183c ("carl9170: refactor carl9170_update_beacon") Signed-off-by: Xiaomeng Tong Acked-by: Christian Lamparter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220328122820.1004-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman commit 91d973aa0d6963d94030241021c4e16d1f1a795a Author: Mark Brown Date: Thu Apr 28 17:24:44 2022 +0100 ASoC: rt5514: Fix event generation for "DSP Voice Wake Up" control commit 4213ff556740bb45e2d9ff0f50d056c4e7dd0921 upstream. The driver has a custom put function for "DSP Voice Wake Up" which does not generate event notifications on change, instead returning 0. Since we already exit early in the case that there is no change this can be fixed by unconditionally returning 1 at the end of the function. Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220428162444.3883147-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6ad81ad0cf5744738ce94c8e64051ddd80a1734c Author: Alexander Wetzel Date: Fri Apr 22 16:52:28 2022 +0200 rtl818x: Prevent using not initialized queues commit 746285cf81dc19502ab238249d75f5990bd2d231 upstream. Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized. Cc: stable@vger.kernel.org Reported-by: pa@panix.com Tested-by: pa@panix.com Signed-off-by: Alexander Wetzel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220422145228.7567-1-alexander@wetzel-home.de Signed-off-by: Greg Kroah-Hartman commit 4b02493838d9057b1062c55c678b18ffe291b9d7 Author: Yi Yang Date: Tue May 10 16:05:33 2022 +0800 xtensa/simdisk: fix proc_read_simdisk() commit b011946d039d66bbc7102137e98cc67e1356aa87 upstream. The commit a69755b18774 ("xtensa simdisk: switch to proc_create_data()") split read operation into two parts, first retrieving the path when it's non-null and second retrieving the trailing '\n'. However when the path is non-null the first simple_read_from_buffer updates ppos, and the second simple_read_from_buffer returns 0 if ppos is greater than 1 (i.e. almost always). As a result reading from that proc file is almost always empty. Fix it by making a temporary copy of the path with the trailing '\n' and using simple_read_from_buffer on that copy. Cc: stable@vger.kernel.org Fixes: a69755b18774 ("xtensa simdisk: switch to proc_create_data()") Signed-off-by: Yi Yang Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit fd9a5081ee3311a3ceee9f0f3ddbf508e119b580 Author: Miaohe Lin Date: Tue May 31 20:26:43 2022 +0800 mm/memremap: fix missing call to untrack_pfn() in pagemap_range() commit a04e1928e2ead144dc2f369768bc0a0f3110af89 upstream. We forget to call untrack_pfn() to pair with track_pfn_remap() when range is not allowed to hotplug. Fix it by jump err_kasan. Link: https://lkml.kernel.org/r/20220531122643.25249-1-linmiaohe@huawei.com Fixes: bca3feaa0764 ("mm/memory_hotplug: prevalidate the address range being added with platform") Signed-off-by: Miaohe Lin Reviewed-by: David Hildenbrand Acked-by: Muchun Song Cc: Anshuman Khandual Cc: Oscar Salvador Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 715455ca5e81cc28ee3d606cce5c223e26b5ad24 Author: Mike Kravetz Date: Tue May 24 13:50:03 2022 -0700 hugetlb: fix huge_pmd_unshare address update commit 48381273f8734d28ef56a5bdf1966dd8530111bc upstream. The routine huge_pmd_unshare() is passed a pointer to an address associated with an area which may be unshared. If unshare is successful this address is updated to 'optimize' callers iterating over huge page addresses. For the optimization to work correctly, address should be updated to the last huge page in the unmapped/unshared area. However, in the common case where the passed address is PUD_SIZE aligned, the address is incorrectly updated to the address of the preceding huge page. That wastes CPU cycles as the unmapped/unshared range is scanned twice. Link: https://lkml.kernel.org/r/20220524205003.126184-1-mike.kravetz@oracle.com Fixes: 39dde65c9940 ("shared page table for hugetlb page") Signed-off-by: Mike Kravetz Acked-by: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0a561368cecae320a78eaa2ebbf46712c132a083 Author: Christophe de Dinechin Date: Thu Apr 14 17:08:54 2022 +0200 nodemask.h: fix compilation error with GCC12 commit 37462a920392cb86541650a6f4121155f11f1199 upstream. With gcc version 12.0.1 20220401 (Red Hat 12.0.1-0), building with defconfig results in the following compilation error: | CC mm/swapfile.o | mm/swapfile.c: In function `setup_swap_info': | mm/swapfile.c:2291:47: error: array subscript -1 is below array bounds | of `struct plist_node[]' [-Werror=array-bounds] | 2291 | p->avail_lists[i].prio = 1; | | ~~~~~~~~~~~~~~^~~ | In file included from mm/swapfile.c:16: | ./include/linux/swap.h:292:27: note: while referencing `avail_lists' | 292 | struct plist_node avail_lists[]; /* | | ^~~~~~~~~~~ This is due to the compiler detecting that the mask in node_states[__state] could theoretically be zero, which would lead to first_node() returning -1 through find_first_bit. I believe that the warning/error is legitimate. I first tried adding a test to check that the node mask is not emtpy, since a similar test exists in the case where MAX_NUMNODES == 1. However, adding the if statement causes other warnings to appear in for_each_cpu_node_but, because it introduces a dangling else ambiguity. And unfortunately, GCC is not smart enough to detect that the added test makes the case where (node) == -1 impossible, so it still complains with the same message. This is why I settled on replacing that with a harmless, but relatively useless (node) >= 0 test. Based on the warning for the dangling else, I also decided to fix the case where MAX_NUMNODES == 1 by moving the condition inside the for loop. It will still only be tested once. This ensures that the meaning of an else following for_each_node_mask or derivatives would not silently have a different meaning depending on the configuration. Link: https://lkml.kernel.org/r/20220414150855.2407137-3-dinechin@redhat.com Signed-off-by: Christophe de Dinechin Signed-off-by: Christophe de Dinechin Reviewed-by: Andrew Morton Cc: Ben Segall Cc: "Michael S. Tsirkin" Cc: Steven Rostedt Cc: Ingo Molnar Cc: Mel Gorman Cc: Dietmar Eggemann Cc: Vincent Guittot Cc: Paolo Bonzini Cc: Daniel Bristot de Oliveira Cc: Jason Wang Cc: Zhen Lei Cc: Juri Lelli Cc: Peter Zijlstra Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit fb49bd85dfac8c25dffa4b79825570e4c63a41b3 Author: Mel Gorman Date: Thu May 26 10:12:10 2022 +0100 mm/page_alloc: always attempt to allocate at least one page during bulk allocation commit c572e4888ad1be123c1516ec577ad30a700bbec4 upstream. Peter Pavlisko reported the following problem on kernel bugzilla 216007. When I try to extract an uncompressed tar archive (2.6 milion files, 760.3 GiB in size) on newly created (empty) XFS file system, after first low tens of gigabytes extracted the process hangs in iowait indefinitely. One CPU core is 100% occupied with iowait, the other CPU core is idle (on 2-core Intel Celeron G1610T). It was bisected to c9fa563072e1 ("xfs: use alloc_pages_bulk_array() for buffers") but XFS is only the messenger. The problem is that nothing is waking kswapd to reclaim some pages at a time the PCP lists cannot be refilled until some reclaim happens. The bulk allocator checks that there are some pages in the array and the original intent was that a bulk allocator did not necessarily need all the requested pages and it was best to return as quickly as possible. This was fine for the first user of the API but both NFS and XFS require the requested number of pages be available before making progress. Both could be adjusted to call the page allocator directly if a bulk allocation fails but it puts a burden on users of the API. Adjust the semantics to attempt at least one allocation via __alloc_pages() before returning so kswapd is woken if necessary. It was reported via bugzilla that the patch addressed the problem and that the tar extraction completed successfully. This may also address bug 215975 but has yet to be confirmed. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215975 Link: https://lkml.kernel.org/r/20220526091210.GC3441@techsingularity.net Fixes: 387ba26fb1cb ("mm/page_alloc: add a bulk page allocator") Signed-off-by: Mel Gorman Cc: "Darrick J. Wong" Cc: Dave Chinner Cc: Jan Kara Cc: Vlastimil Babka Cc: Jesper Dangaard Brouer Cc: Chuck Lever Cc: [5.13+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c142bddf370649a4802e32be4b9516f336c61c05 Author: Dong Aisheng Date: Fri May 13 15:11:26 2022 -0700 Revert "mm/cma.c: remove redundant cma_mutex lock" commit 60a60e32cf91169840abcb4a80f0b0df31708ba7 upstream. This reverts commit a4efc174b382fcdb which introduced a regression issue that when there're multiple processes allocating dma memory in parallel by calling dma_alloc_coherent(), it may fail sometimes as follows: Error log: cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret: -16 cma: number of available pages: 3@125+20@172+12@236+4@380+32@736+17@2287+23@2473+20@36076+99@40477+108@40852+44@41108+20@41196+108@41364+108@41620+ 108@42900+108@43156+483@44061+1763@45341+1440@47712+20@49324+20@49388+5076@49452+2304@55040+35@58141+20@58220+20@58284+ 7188@58348+84@66220+7276@66452+227@74525+6371@75549=> 33161 free of 81920 total pages When issue happened, we saw there were still 33161 pages (129M) free CMA memory and a lot available free slots for 148 pages in CMA bitmap that we want to allocate. When dumping memory info, we found that there was also ~342M normal memory, but only 1352K CMA memory left in buddy system while a lot of pageblocks were isolated. Memory info log: Normal free:351096kB min:30000kB low:37500kB high:45000kB reserved_highatomic:0KB active_anon:98060kB inactive_anon:98948kB active_file:60864kB inactive_file:31776kB unevictable:0kB writepending:0kB present:1048576kB managed:1018328kB mlocked:0kB bounce:0kB free_pcp:220kB local_pcp:192kB free_cma:1352kB lowmem_reserve[]: 0 0 0 Normal: 78*4kB (UECI) 1772*8kB (UMECI) 1335*16kB (UMECI) 360*32kB (UMECI) 65*64kB (UMCI) 36*128kB (UMECI) 16*256kB (UMCI) 6*512kB (EI) 8*1024kB (UEI) 4*2048kB (MI) 8*4096kB (EI) 8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB The root cause of this issue is that since commit a4efc174b382 ("mm/cma.c: remove redundant cma_mutex lock"), CMA supports concurrent memory allocation. It's possible that the memory range process A trying to alloc has already been isolated by the allocation of process B during memory migration. The problem here is that the memory range isolated during one allocation by start_isolate_page_range() could be much bigger than the real size we want to alloc due to the range is aligned to MAX_ORDER_NR_PAGES. Taking an ARMv7 platform with 1G memory as an example, when MAX_ORDER_NR_PAGES is big (e.g. 32M with max_order 14) and CMA memory is relatively small (e.g. 128M), there're only 4 MAX_ORDER slot, then it's very easy that all CMA memory may have already been isolated by other processes when one trying to allocate memory using dma_alloc_coherent(). Since current CMA code will only scan one time of whole available CMA memory, then dma_alloc_coherent() may easy fail due to contention with other processes. This patch simply falls back to the original method that using cma_mutex to make alloc_contig_range() run sequentially to avoid the issue. Link: https://lkml.kernel.org/r/20220509094551.3596244-1-aisheng.dong@nxp.com Link: https://lore.kernel.org/all/20220315144521.3810298-2-aisheng.dong@nxp.com/ Fixes: a4efc174b382 ("mm/cma.c: remove redundant cma_mutex lock") Signed-off-by: Dong Aisheng Acked-by: Minchan Kim Acked-by: David Hildenbrand Cc: Marek Szyprowski Cc: Lecopzer Chen Cc: Vlastimil Babka Cc: [5.11+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f81e67efa7124d26cb47e05ea7b2ce40ca536899 Author: Yunfei Wang Date: Sat May 7 16:52:03 2022 +0800 iommu/dma: Fix iova map result check bug commit a3884774d731f03d3a3dd4fb70ec2d9341ceb39d upstream. The data type of the return value of the iommu_map_sg_atomic is ssize_t, but the data type of iova size is size_t, e.g. one is int while the other is unsigned int. When iommu_map_sg_atomic return value is compared with iova size, it will force the signed int to be converted to unsigned int, if iova map fails and iommu_map_sg_atomic return error code is less than 0, then (ret < iova_len) is false, which will to cause not do free iova, and the master can still successfully get the iova of map fail, which is not expected. Therefore, we need to check the return value of iommu_map_sg_atomic in two cases according to whether it is less than 0. Fixes: ad8f36e4b6b1 ("iommu: return full error code from iommu_map_sg[_atomic]()") Signed-off-by: Yunfei Wang Cc: # 5.15.* Reviewed-by: Robin Murphy Reviewed-by: Miles Chen Link: https://lore.kernel.org/r/20220507085204.16914-1-yf.wang@mediatek.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit a3f98e4331e05385c5fc65952ef666c137326bed Author: Xiaomeng Tong Date: Sun May 1 21:28:23 2022 +0800 iommu/msm: Fix an incorrect NULL check on list iterator commit 8b9ad480bd1dd25f4ff4854af5685fa334a2f57a upstream. The bug is here: if (!iommu || iommu->dev->of_node != spec->np) { The list iterator value 'iommu' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found (in fact, it will point to a invalid structure object containing HEAD). To fix the bug, use a new value 'iter' as the list iterator, while use the old value 'iommu' as a dedicated variable to point to the found one, and remove the unneeded check for 'iommu->dev->of_node != spec->np' outside the loop. Cc: stable@vger.kernel.org Fixes: f78ebca8ff3d6 ("iommu/msm: Add support for generic master bindings") Signed-off-by: Xiaomeng Tong Link: https://lore.kernel.org/r/20220501132823.12714-1-xiam0nd.tong@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 69c14d29727c17d45a8c2b34d1e6a534e5b2dacb Author: Hyunchul Lee Date: Fri May 20 14:35:47 2022 +0900 ksmbd: fix outstanding credits related bugs commit 376b9133826865568167b4091ef92a68c4622b87 upstream. outstanding credits must be initialized to 0, because it means the sum of credits consumed by in-flight requests. And outstanding credits must be compared with total credits in smb2_validate_credit_charge(), because total credits are the sum of credits granted by ksmbd. This patch fix the following error, while frametest with Windows clients: Limits exceeding the maximum allowable outstanding requests, given : 128, pending : 8065 Fixes: b589f5db6d4a ("ksmbd: limits exceeding the maximum allowable outstanding requests") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Reported-by: Yufan Chen Tested-by: Yufan Chen Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit cae2978d6907ef2c08b9b15f704e783f7c284713 Author: Song Liu Date: Tue May 24 10:08:39 2022 -0700 ftrace: Clean up hash direct_functions on register failures commit 7d54c15cb89a29a5f59e5ffc9ee62e6591769ef1 upstream. We see the following GPF when register_ftrace_direct fails: [ ] general protection fault, probably for non-canonical address \ 0x200000000000010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [...] [ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70 [ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...] [ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206 [ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 000000000000003b [ ] RDX: 0200000000000000 RSI: 000000000000000c RDI: ffffffff813e0df0 [ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: 0000000000000001 [ ] R10: ffffc9000138bc18 R11: 0000000000000001 R12: ffffffff813e0df0 [ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: 0000000000000000 [ ] FS: 00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000 [ ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ ] CR2: 000000000770d000 CR3: 0000000107d50003 CR4: 0000000000370ee0 [ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ ] Call Trace: [ ] [ ] register_ftrace_direct+0x54/0x290 [ ] ? render_sigset_t+0xa0/0xa0 [ ] bpf_trampoline_update+0x3f5/0x4a0 [ ] ? 0xffffffffa00a3000 [ ] bpf_trampoline_link_prog+0xa9/0x140 [ ] bpf_tracing_prog_attach+0x1dc/0x450 [ ] bpf_raw_tracepoint_open+0x9a/0x1e0 [ ] ? find_held_lock+0x2d/0x90 [ ] ? lock_release+0x150/0x430 [ ] __sys_bpf+0xbd6/0x2700 [ ] ? lock_is_held_type+0xd8/0x130 [ ] __x64_sys_bpf+0x1c/0x20 [ ] do_syscall_64+0x3a/0x80 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xae [ ] RIP: 0033:0x7fa9421defa9 [ ] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 9 f8 [...] [ ] RSP: 002b:00007ffed743bd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ ] RAX: ffffffffffffffda RBX: 00000000069d2480 RCX: 00007fa9421defa9 [ ] RDX: 0000000000000078 RSI: 00007ffed743bd80 RDI: 0000000000000011 [ ] RBP: 00007ffed743be00 R08: 0000000000bb7270 R09: 0000000000000000 [ ] R10: 00000000069da210 R11: 0000000000000246 R12: 0000000000000001 [ ] R13: 00007ffed743c4b0 R14: 00000000069d2480 R15: 0000000000000001 [ ] [ ] Modules linked in: klp_vm(OK) [ ] ---[ end trace 0000000000000000 ]--- One way to trigger this is: 1. load a livepatch that patches kernel function xxx; 2. run bpftrace -e 'kfunc:xxx {}', this will fail (expected for now); 3. repeat #2 => gpf. This is because the entry is added to direct_functions, but not removed. Fix this by remove the entry from direct_functions when register_ftrace_direct fails. Also remove the last trailing space from ftrace.c, so we don't have to worry about it anymore. Link: https://lkml.kernel.org/r/20220524170839.900849-1-song@kernel.org Cc: stable@vger.kernel.org Fixes: 763e34e74bb7 ("ftrace: Add register_ftrace_direct()") Signed-off-by: Song Liu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 53b858c807533a3451668d1e18d21c9d4a3f22b4 Author: Naveen N. Rao Date: Thu May 19 14:42:37 2022 +0530 kexec_file: drop weak attribute from arch_kexec_apply_relocations[_add] commit 3e35142ef99fe6b4fe5d834ad43ee13cca10a2dc upstream. Since commit d1bcae833b32f1 ("ELF: Don't generate unused section symbols") [1], binutils (v2.36+) started dropping section symbols that it thought were unused. This isn't an issue in general, but with kexec_file.c, gcc is placing kexec_arch_apply_relocations[_add] into a separate .text.unlikely section and the section symbol ".text.unlikely" is being dropped. Due to this, recordmcount is unable to find a non-weak symbol in .text.unlikely to generate a relocation record against. Address this by dropping the weak attribute from these functions. Instead, follow the existing pattern of having architectures #define the name of the function they want to override in their headers. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1 [akpm@linux-foundation.org: arch/s390/include/asm/kexec.h needs linux/module.h] Link: https://lkml.kernel.org/r/20220519091237.676736-1-naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Michael Ellerman Signed-off-by: Naveen N. Rao Cc: "Eric W. Biederman" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 10995a382271254bd276627ec74136da4a23c4a6 Author: Vincent Whitchurch Date: Mon May 23 16:04:03 2022 +0200 um: Fix out-of-bounds read in LDT setup commit 2a4a62a14be1947fa945c5c11ebf67326381a568 upstream. syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ================================================================== Fixes: 858259cf7d1c443c83 ("uml: maintain own LDT entries") Signed-off-by: Vincent Whitchurch Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 06ebe1bd307191c8f51cccb73db85095388cae35 Author: Johannes Berg Date: Fri May 20 19:45:36 2022 +0200 um: chan_user: Fix winch_tramp() return value commit 57ae0b67b747031bc41fb44643aa5344ab58607e upstream. The previous fix here was only partially correct, it did result in returning a proper error value in case of error, but it also clobbered the pid that we need to return from this function (not just zero for success). As a result, it returned 0 here, but later this is treated as a pid and used to kill the process, but since it's now 0 we kill(0, SIGKILL), which makes UML kill itself rather than just the helper thread. Fix that and make it more obvious by using a separate variable for the pid. Fixes: ccf1236ecac4 ("um: fix error return code in winch_tramp()") Reported-and-tested-by: Nathan Chancellor Signed-off-by: Johannes Berg Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit b012254ad018ae33ca6ccf18ff4e62a21a87d94d Author: Johannes Berg Date: Mon Mar 28 09:46:25 2022 +0200 um: Use asm-generic/dma-mapping.h commit 365719035526e8eda214a1cedb2e1c96e969a0d7 upstream. If DMA (PCI over virtio) is enabled, then some drivers may enable CONFIG_DMA_OPS as well, and then we pull in the x86 definition of get_arch_dma_ops(), which uses the dma_ops symbol, which isn't defined. Since we don't have real DMA ops nor any kind of IOMMU fix this in the simplest possible way: pull in the asm-generic file instead of inheriting the x86 one. It's not clear why those drivers that do (e.g. VDPA) "select DMA_OPS", and if they'd even work with this, but chances are nobody will be wanting to do that anyway, so fixing the build failure is good enough. Reported-by: Randy Dunlap Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Johannes Berg Tested-by: Randy Dunlap Acked-by: Randy Dunlap Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 92dce560a809949c998c8a7187cc2051b3ca9de0 Author: Felix Fietkau Date: Wed Apr 20 12:49:07 2022 +0200 mac80211: upgrade passive scan to active scan on DFS channels after beacon rx commit b041b7b9de6e1d4362de855ab90f9d03ef323edd upstream. In client mode, we can't connect to hidden SSID APs or SSIDs not advertised in beacons on DFS channels, since we're forced to passive scan. Fix this by sending out a probe request immediately after the first beacon, if active scan was requested by the user. Cc: stable@vger.kernel.org Reported-by: Catrinel Catrinescu Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20220420104907.36275-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9cf980092286af683e8c59fcd678032a2a51e605 Author: Dimitri John Ledkov Date: Thu Apr 14 13:50:03 2022 +0100 cfg80211: declare MODULE_FIRMWARE for regulatory.db commit 7bc7981eeebe1b8e603ad2ffc5e84f4df76920dd upstream. Add MODULE_FIRMWARE declarations for regulatory.db and regulatory.db.p7s such that userspace tooling can discover and include these files. Cc: stable@vger.kernel.org Signed-off-by: Dimitri John Ledkov Link: https://lore.kernel.org/r/20220414125004.267819-1-dimitri.ledkov@canonical.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 8e354518f576307658d79847a3ec94025e42983f Author: Kant Fan Date: Fri Mar 25 15:30:30 2022 +0800 thermal: devfreq_cooling: use local ops instead of global ops commit b947769b8f778db130aad834257fcaca25df2edc upstream. Fix access illegal address problem in following condition: There are multiple devfreq cooling devices in system, some of them has EM model but others do not. Energy model ops such as state2power will append to global devfreq_cooling_ops when the cooling device with EM model is registered. It makes the cooling device without EM model also use devfreq_cooling_ops after appending when registered later by of_devfreq_cooling_register_power() or of_devfreq_cooling_register(). The IPA governor regards the cooling devices without EM model as a power actor, because they also have energy model ops, and will access illegal address at dfc->em_pd when execute cdev->ops->get_requested_power, cdev->ops->state2power or cdev->ops->power2state. Fixes: 615510fe13bd2 ("thermal: devfreq_cooling: remove old power model and use EM") Cc: 5.13+ # 5.13+ Signed-off-by: Kant Fan Reviewed-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit de23a6a1a31fcf259fa7cdf39f30d743b43971bd Author: Max Filippov Date: Tue Apr 26 09:01:18 2022 -0700 irqchip: irq-xtensa-mx: fix initial IRQ affinity commit a255ee29252066d621df5d6b420bf534c6ba5bc0 upstream. When irq-xtensa-mx chip is used in non-SMP configuration its irq_set_affinity callback is not called leaving IRQ affinity set empty. As a result IRQ delivery does not work in that configuration. Initialize IRQ affinity of the xtensa MX interrupt distributor to CPU 0 for all external IRQ lines. Cc: stable@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 297c9c640d6e28c71a2d15c719b6dfb4b9448e68 Author: Pali Rohár Date: Mon Apr 25 13:37:05 2022 +0200 irqchip/armada-370-xp: Do not touch Performance Counter Overflow on A375, A38x, A39x commit a3d66a76348daf559873f19afc912a2a7c2ccdaf upstream. Register ARMADA_370_XP_INT_FABRIC_MASK_OFFS is Armada 370 and XP specific and on new Armada platforms it has different meaning. It does not configure Performance Counter Overflow interrupt masking. So do not touch this register on non-A370/XP platforms (A375, A38x and A39x). Signed-off-by: Pali Rohár Cc: stable@vger.kernel.org Fixes: 28da06dfd9e4 ("irqchip: armada-370-xp: Enable the PMU interrupts") Reviewed-by: Andrew Lunn Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220425113706.29310-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman commit ba810df878b0862e01b8e9d2158f7c74dfc76b96 Author: Guo Ren Date: Wed Apr 6 22:28:43 2022 +0800 csky: patch_text: Fixup last cpu should be master commit 8c4d16471e2babe9bdfe41d6ef724526629696cb upstream. These patch_text implementations are using stop_machine_cpuslocked infrastructure with atomic cpu_count. The original idea: When the master CPU patch_text, the others should wait for it. But current implementation is using the first CPU as master, which couldn't guarantee the remaining CPUs are waiting. This patch changes the last CPU as the master to solve the potential risk. Fixes: 33e53ae1ce41 ("csky: Add kprobes supported") Signed-off-by: Guo Ren Signed-off-by: Guo Ren Reviewed-by: Masami Hiramatsu Cc: Signed-off-by: Greg Kroah-Hartman commit f828af2c527de683b48f8463f7b5011b4b45a4f3 Author: Bean Huo Date: Sun Apr 24 00:16:23 2022 +0200 mmc: core: Allows to override the timeout value for ioctl() path commit 23e09be254f95a5b75cd87f91a4014f3b46dda3f upstream. Occasionally, user-land applications initiate longer timeout values for certain commands through ioctl() system call. But so far we are still using a fixed timeout of 10 seconds in mmc_poll_for_busy() on the ioctl() path, even if a custom timeout is specified in the userspace application. This patch allows custom timeout values to override this default timeout values on the ioctl path. Cc: stable Signed-off-by: Bean Huo Acked-by: Avri Altman Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20220423221623.1074556-3-huobean@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3f09ec80f115d2875d747ed28adc1773037e0f8b Author: Dennis Dalessandro Date: Fri May 20 14:37:12 2022 -0400 RDMA/hfi1: Fix potential integer multiplication overflow errors commit f93e91a0372c922c20d5bee260b0f43b4b8a1bee upstream. When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow. Cc: stable@vger.kernel.org Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20220520183712.48973.29855.stgit@awfm-01.cornelisnetworks.com Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 64639d11186e208f371cbbff74115514ac53a606 Author: Sean Christopherson Date: Wed Feb 2 00:49:41 2022 +0000 Kconfig: Add option for asm goto w/ tied outputs to workaround clang-13 bug commit 1aa0e8b144b6474c4914439d232d15bfe883636b upstream. Add a config option to guard (future) usage of asm_volatile_goto() that includes "tied outputs", i.e. "+" constraints that specify both an input and output parameter. clang-13 has a bug[1] that causes compilation of such inline asm to fail, and KVM wants to use a "+m" constraint to implement a uaccess form of CMPXCHG[2]. E.g. the test code fails with :1:29: error: invalid operand in inline asm: '.long (${1:l}) - .' int foo(int *x) { asm goto (".long (%l[bar]) - .\n": "+m"(*x) ::: bar); return *x; bar: return 0; } ^ :1:29: error: unknown token in expression :1:9: note: instantiated into assembly here .long () - . ^ 2 errors generated. on clang-13, but passes on gcc (with appropriate asm goto support). The bug is fixed in clang-14, but won't be backported to clang-13 as the changes are too invasive/risky. gcc also had a similar bug[3], fixed in gcc-11, where gcc failed to account for its behavior of assigning two numbers to tied outputs (one for input, one for output) when evaluating symbolic references. [1] https://github.com/ClangBuiltLinux/linux/issues/1512 [2] https://lore.kernel.org/all/YfMruK8%2F1izZ2VHS@google.com [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096 Suggested-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20220202004945.2540433-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3892794a18136452101fc86cebc5c6d69ac93683 Author: GUO Zihua Date: Thu Apr 7 10:16:19 2022 +0800 ima: remove the IMA_TEMPLATE Kconfig option commit 891163adf180bc369b2f11c9dfce6d2758d2a5bd upstream. The original 'ima' measurement list template contains a hash, defined as 20 bytes, and a null terminated pathname, limited to 255 characters. Other measurement list templates permit both larger hashes and longer pathnames. When the "ima" template is configured as the default, a new measurement list template (ima_template=) must be specified before specifying a larger hash algorithm (ima_hash=) on the boot command line. To avoid this boot command line ordering issue, remove the legacy "ima" template configuration option, allowing it to still be specified on the boot command line. The root cause of this issue is that during the processing of ima_hash, we would try to check whether the hash algorithm is compatible with the template. If the template is not set at the moment we do the check, we check the algorithm against the configured default template. If the default template is "ima", then we reject any hash algorithm other than sha1 and md5. For example, if the compiled default template is "ima", and the default algorithm is sha1 (which is the current default). In the cmdline, we put in "ima_hash=sha256 ima_template=ima-ng". The expected behavior would be that ima starts with ima-ng as the template and sha256 as the hash algorithm. However, during the processing of "ima_hash=", "ima_template=" has not been processed yet, and hash_setup would check the configured hash algorithm against the compiled default: ima, and reject sha256. So at the end, the hash algorithm that is actually used will be sha1. With template "ima" removed from the configured default, we ensure that the default tempalte would at least be "ima-ng" which allows for basically any hash algorithm. This change would not break the algorithm compatibility checks for IMA. Fixes: 4286587dccd43 ("ima: add Kconfig default measurement list template") Signed-off-by: GUO Zihua Cc: Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 5fd1717439eac9b25a2bea182abc90f58c22ea7d Author: Nicolas Dufresne Date: Wed Apr 6 21:23:43 2022 +0100 media: coda: Add more H264 levels for CODA960 commit eb2fd187abc878a2dfad46902becb74963473c7d upstream. Add H264 level 1.0, 4.1, 4.2 to the list of supported formats. While the hardware does not fully support these levels, it does support most of them. The constraints on frame size and pixel formats already cover the limitation. This fixes negotiation of level on GStreamer 1.17.1. Cc: stable@vger.kernel.org Fixes: 42a68012e67c2 ("media: coda: add read-only h.264 decoder profile/level controls") Suggested-by: Philipp Zabel Signed-off-by: Nicolas Dufresne Signed-off-by: Ezequiel Garcia Signed-off-by: Fabio Estevam Reviewed-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit dc2672109c862688b7ef52702443b2104b78fe7a Author: Nicolas Dufresne Date: Wed Apr 6 21:23:42 2022 +0100 media: coda: Fix reported H264 profile commit 7110c08ea71953a7fc342f0b76046f72442cf26c upstream. The CODA960 manual states that ASO/FMO features of baseline are not supported, so for this reason this driver should only report constrained baseline support. This fixes negotiation issue with constrained baseline content on GStreamer 1.17.1. ASO/FMO features are unsupported for the encoder and untested for the decoder because there is currently no userspace support. Neither GStreamer parsers nor FFMPEG parsers support ASO/FMO. Cc: stable@vger.kernel.org Fixes: 42a68012e67c2 ("media: coda: add read-only h.264 decoder profile/level controls") Signed-off-by: Nicolas Dufresne Signed-off-by: Ezequiel Garcia Tested-by: Pascal Speck Signed-off-by: Fabio Estevam Reviewed-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c925d688e4dcc0f16efd97f0d6ff56242a9de179 Author: Tokunori Ikegami Date: Thu Mar 24 02:04:56 2022 +0900 mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N commit 0a8e98305f63deaf0a799d5cf5532cc83af035d1 upstream. Since commit dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") buffered writes fail on S29GL064N. This is because, on S29GL064N, reads return 0xFF at the end of DQ polling for write completion, where as, chip_good() check expects actual data written to the last location to be returned post DQ polling completion. Fix is to revert to using chip_good() for S29GL064N which only checks for DQ lines to settle down to determine write completion. Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/ Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") Cc: stable@vger.kernel.org Signed-off-by: Tokunori Ikegami Acked-by: Vignesh Raghavendra Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-3-ikegami.t@gmail.com Signed-off-by: Greg Kroah-Hartman commit b974364bda1935234af7973bd6099c6799729bd2 Author: Tokunori Ikegami Date: Thu Mar 24 02:04:55 2022 +0900 mtd: cfi_cmdset_0002: Move and rename chip_check/chip_ready/chip_good_for_write commit 083084df578a8bdb18334f69e7b32d690aaa3247 upstream. This is a preparation patch for the S29GL064N buffer writes fix. There is no functional change. Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/ Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") Signed-off-by: Tokunori Ikegami Cc: stable@vger.kernel.org Acked-by: Vignesh Raghavendra Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-2-ikegami.t@gmail.com Signed-off-by: Greg Kroah-Hartman commit a105177c0510d3c88ee89c5e801d819fdbdadddf Author: Xiaomeng Tong Date: Fri Apr 8 16:47:15 2022 +0800 md: fix an incorrect NULL check in md_reload_sb commit 64c54d9244a4efe9bc6e9c98e13c4bbb8bb39083 upstream. The bug is here: if (!rdev || rdev->desc_nr != nr) { The list iterator value 'rdev' will *always* be set and non-NULL by rdev_for_each_rcu(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element found (In fact, it will be a bogus pointer to an invalid struct object containing the HEAD). Otherwise it will bypass the check and lead to invalid memory access passing the check. To fix the bug, use a new variable 'iter' as the list iterator, while using the original variable 'pdev' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: 70bcecdb1534 ("md-cluster: Improve md_reload_sb to be less error prone") Signed-off-by: Xiaomeng Tong Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 7907930218a6ef6b0f1eacce9dbe7b425c492117 Author: Xiaomeng Tong Date: Fri Apr 8 16:37:28 2022 +0800 md: fix an incorrect NULL check in does_sb_need_changing commit fc8738343eefc4ea8afb6122826dea48eacde514 upstream. The bug is here: if (!rdev) The list iterator value 'rdev' will *always* be set and non-NULL by rdev_for_each(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element found. Otherwise it will bypass the NULL check and lead to invalid memory access passing the check. To fix the bug, use a new variable 'iter' as the list iterator, while using the original variable 'rdev' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: 2aa82191ac36 ("md-cluster: Perform a lazy update") Acked-by: Guoqing Jiang Signed-off-by: Xiaomeng Tong Acked-by: Goldwyn Rodrigues Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 35511d4fdd6b82c887ef038278fd808d7c7f98de Author: Jani Nikula Date: Fri May 20 12:46:00 2022 +0300 drm/i915/dsi: fix VBT send packet port selection for ICL+ commit 0ea917819d12fed41ea4662cc26ffa0060a5c354 upstream. The VBT send packet port selection was never updated for ICL+ where the 2nd link is on port B instead of port C as in VLV+ DSI. First, single link DSI needs to use the configured port instead of relying on the VBT sequence block port. Remove the hard-coded port C check here and make it generic. For reference, see commit f915084edc5a ("drm/i915: Changes related to the sequence port no for") for the original VLV specific fix. Second, the sequence block port number is either 0 or 1, where 1 indicates the 2nd link. Remove the hard-coded port C here for 2nd link. (This could be a "find second set bit" on DSI ports, but just check the two possible options.) Third, sanity check the result with a warning to avoid a NULL pointer dereference. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5984 Cc: stable@vger.kernel.org # v4.19+ Cc: Ville Syrjala Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220520094600.2066945-1-jani.nikula@intel.com (cherry picked from commit 08c59dde71b73a0ac94e3ed2d431345b01f20485) Signed-off-by: Greg Kroah-Hartman commit df1f9631eb6d0aff9cff34ed38343093b539a717 Author: Brian Norris Date: Tue Mar 1 18:11:38 2022 -0800 drm/bridge: analogix_dp: Grab runtime PM reference for DP-AUX commit 8fb6c44fe8468f92ac7b8bbfcca4404a4e88645f upstream. If the display is not enable()d, then we aren't holding a runtime PM reference here. Thus, it's easy to accidentally cause a hang, if user space is poking around at /dev/drm_dp_aux0 at the "wrong" time. Let's get a runtime PM reference, and check that we "see" the panel. Don't force any panel power-up, etc., because that can be intrusive, and that's not what other drivers do (see drivers/gpu/drm/bridge/ti-sn65dsi86.c and drivers/gpu/drm/bridge/parade-ps8640.c.) Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code") Cc: Cc: Tomeu Vizoso Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20220301181107.v4.1.I773a08785666ebb236917b0c8e6c05e3de471e75@changeid Signed-off-by: Greg Kroah-Hartman commit a810f54d05769d2db6e2316601f5f61b8cc14eb1 Author: Xiaomeng Tong Date: Sun Mar 27 15:39:25 2022 +0800 drm/nouveau/kms/nv50-: atom: fix an incorrect NULL check on list iterator commit 6ce4431c7ba7954c4fa6a96ce16ca1b2943e1a83 upstream. The bug is here: return encoder; The list iterator value 'encoder' will *always* be set and non-NULL by drm_for_each_encoder_mask(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element found. Otherwise it will bypass some NULL checks and lead to invalid memory access passing the check. To fix this bug, just return 'encoder' when found, otherwise return NULL. Cc: stable@vger.kernel.org Fixes: 12885ecbfe62d ("drm/nouveau/kms/nvd9-: Add CRC support") Signed-off-by: Xiaomeng Tong Reviewed-by: Lyude Paul [Changed commit title] Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20220327073925.11121-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman commit d1efc36beaaabda4766b1d1a00e27f0c3920ab80 Author: Xiaomeng Tong Date: Sun Mar 27 15:58:24 2022 +0800 drm/nouveau/clk: Fix an incorrect NULL check on list iterator commit 1c3b2a27def609473ed13b1cd668cb10deab49b4 upstream. The bug is here: if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp)) return cstate; The list iterator value 'cstate' will *always* be set and non-NULL by list_for_each_entry_from_reverse(), so it is incorrect to assume that the iterator value will be unchanged if the list is empty or no element is found (In fact, it will be a bogus pointer to an invalid structure object containing the HEAD). Also it missed a NULL check at callsite and may lead to invalid memory access after that. To fix this bug, just return 'encoder' when found, otherwise return NULL. And add the NULL check. Cc: stable@vger.kernel.org Fixes: 1f7f3d91ad38a ("drm/nouveau/clk: Respect voltage limits in nvkm_cstate_prog") Signed-off-by: Xiaomeng Tong Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20220327075824.11806-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman commit 03bd455a79f69d97fee3e3b212ab754442f10e5c Author: Lucas Stach Date: Wed Mar 23 17:08:22 2022 +0100 drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem commit e168c25526cd0368af098095c2ded4a008007e1b upstream. When the mapping is already reaped the unmap must be a no-op, as we would otherwise try to remove the mapping twice, corrupting the involved data structures. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel Tested-by: Guido Günther Acked-by: Guido Günther Signed-off-by: Greg Kroah-Hartman commit 6e842e680bf0d7533d7c3115c9c71e3541ddb749 Author: Lyude Paul Date: Fri Apr 29 15:53:47 2022 -0400 drm/nouveau/subdev/bus: Ratelimit logging for fault errors commit 9887bda0c831df0c044d6de147d002e48024fb4a upstream. There's plenty of ways to fudge the GPU when developing on nouveau by mistake, some of which can result in nouveau seriously spamming dmesg with fault errors. This can be somewhat annoying, as it can quickly overrun the message buffer (or your terminal emulator's buffer) and get rid of actually useful feedback from the driver. While working on my new atomic only MST branch, I ran into this issue a couple of times. So, let's fix this by adding nvkm_error_ratelimited(), and using it to ratelimit errors from faults. This should be fine for developers, since it's nearly always only the first few faults that we care about seeing. Plus, you can turn off rate limiting in the kernel if you really need to. Signed-off-by: Lyude Paul Reviewed-by: Karol Herbst Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20220429195350.85620-1-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit 70276460e914d560e96bfc208695a872fe9469c9 Author: Dave Airlie Date: Mon May 23 10:24:18 2022 +1000 drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. commit 31ab27b14daaa75541a415c6794d6f3567fea44a upstream. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018 Signed-off-by: Dave Airlie Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f55f9e7ce63bbc92efd83134d5876bdcd16f725f Author: Mickaël Salaün Date: Fri May 6 18:10:54 2022 +0200 landlock: Fix same-layer rule unions commit 8ba0005ff418ec356e176b26eaa04a6ac755d05b upstream. The original behavior was to check if the full set of requested accesses was allowed by at least a rule of every relevant layer. This didn't take into account requests for multiple accesses and same-layer rules allowing the union of these accesses in a complementary way. As a result, multiple accesses requested on a file hierarchy matching rules that, together, allowed these accesses, but without a unique rule allowing all of them, was illegitimately denied. This case should be rare in practice and it can only be triggered by the path_rename or file_open hook implementations. For instance, if, for the same layer, a rule allows execution beneath /a/b and another rule allows read beneath /a, requesting access to read and execute at the same time for /a/b should be allowed for this layer. This was an inconsistency because the union of same-layer rule accesses was already allowed if requested once at a time anyway. This fix changes the way allowed accesses are gathered over a path walk. To take into account all these rule accesses, we store in a matrix all layer granting the set of requested accesses, according to the handled accesses. To avoid heap allocation, we use an array on the stack which is 2*13 bytes. A following commit bringing the LANDLOCK_ACCESS_FS_REFER access right will increase this size to reach 112 bytes (2*14*4) in case of link or rename actions. Add a new layout1.layer_rule_unions test to check that accesses from different rules pertaining to the same layer are ORed in a file hierarchy. Also test that it is not the case for rules from different layers. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-5-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit f859580c2738889dcd4a7b9ad96e385e6e30fb0b Author: Mickaël Salaün Date: Fri May 6 18:10:53 2022 +0200 landlock: Create find_rule() from unmask_layers() commit 2cd7cd6eed88b8383cfddce589afe9c0ae1d19b4 upstream. This refactoring will be useful in a following commit. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-4-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit f7d62cb59f6d9346b0d7f4771a770f9b08157621 Author: Mickaël Salaün Date: Fri May 6 18:10:52 2022 +0200 landlock: Reduce the maximum number of layers to 16 commit 75c542d6c6cc48720376862d5496d51509160dfd upstream. The maximum number of nested Landlock domains is currently 64. Because of the following fix and to help reduce the stack size, let's reduce it to 16. This seems large enough for a lot of use cases (e.g. sandboxed init service, spawning a sandboxed SSH service, in nested sandboxed containers). Reducing the number of nested domains may also help to discover misuse of Landlock (e.g. creating a domain per rule). Add and use a dedicated layer_mask_t typedef to fit with the number of layers. This might be useful when changing it and to keep it consistent with the maximum number of layers. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-3-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit f4cd27b8466ac806a7b6c0d0986ca5f0d0a88980 Author: Mickaël Salaün Date: Fri May 6 18:10:51 2022 +0200 landlock: Define access_mask_t to enforce a consistent access mask size commit 5f2ff33e10843ef51275c8611bdb7b49537aba5d upstream. Create and use the access_mask_t typedef to enforce a consistent access mask size and uniformly use a 16-bits type. This will helps transition to a 32-bits value one day. Add a build check to make sure all (filesystem) access rights fit in. This will be extended with a following commit. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-2-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 90136f20a3d4e4dea5b865fc9d5cc4bfdbd5b65f Author: Mickaël Salaün Date: Fri May 6 18:08:20 2022 +0200 selftests/landlock: Test landlock_create_ruleset(2) argument check ordering commit 6533d0c3a86ee1cc74ff37ac92ca597deb87015c upstream. Add inval_create_ruleset_arguments, extension of inval_create_ruleset_flags, to also check error ordering for landlock_create_ruleset(2). This is similar to the previous commit checking landlock_add_rule(2). Test coverage for security/landlock is 94.4% of 504 lines accorging to gcc/gcov-11. Link: https://lore.kernel.org/r/20220506160820.524344-11-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit c1d9c0d0c7a90dfe09d7054315a9d08e1394c01f Author: Mickaël Salaün Date: Fri May 6 18:08:19 2022 +0200 landlock: Change landlock_restrict_self(2) check ordering commit eba39ca4b155c54adf471a69e91799cc1727873f upstream. According to the Landlock goal to be a security feature available to unprivileges processes, it makes more sense to first check for no_new_privs before checking anything else (i.e. syscall arguments). Merge inval_fd_enforce and unpriv_enforce_without_no_new_privs tests into the new restrict_self_checks_ordering. This is similar to the previous commit checking other syscalls. Link: https://lore.kernel.org/r/20220506160820.524344-10-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 1707df9edaedf4c5b75d2cc8c123ce6c6bbeab8c Author: Mickaël Salaün Date: Fri May 6 18:08:18 2022 +0200 landlock: Change landlock_add_rule(2) argument check ordering commit 589172e5636c4d16c40b90e87543d43defe2d968 upstream. This makes more sense to first check the ruleset FD and then the rule attribute. It will be useful to factor out code for other rule types. Add inval_add_rule_arguments tests, extension of empty_path_beneath_attr tests, to also check error ordering for landlock_add_rule(2). Link: https://lore.kernel.org/r/20220506160820.524344-9-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit bb416965dbb8da026f40557f769c884ff32a18a0 Author: Mickaël Salaün Date: Fri May 6 18:08:17 2022 +0200 selftests/landlock: Add tests for O_PATH commit d1788ad990874734341b05ab8ccb6448c09c6422 upstream. The O_PATH flag is currently not handled by Landlock. Let's make sure this behavior will remain consistent with the same ruleset over time. Cc: Shuah Khan Link: https://lore.kernel.org/r/20220506160820.524344-8-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit e3e10606ba50b1ac9d2518cda27a90302dec341e Author: Mickaël Salaün Date: Fri May 6 18:08:16 2022 +0200 selftests/landlock: Fully test file rename with "remove" access commit 6a1bdd4a0bfc30fa4fa2b3a979e6525f28996db9 upstream. These tests were missing to check the check_access_path() call with all combinations of maybe_remove(old_dentry) and maybe_remove(new_dentry). Extend layout1.link with a new complementary test and check that REMOVE_FILE is not required to link a file. Cc: Shuah Khan Link: https://lore.kernel.org/r/20220506160820.524344-7-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit df2af378bc0c837453c5d544061e017dc0263d3c Author: Mickaël Salaün Date: Fri May 6 18:08:15 2022 +0200 selftests/landlock: Extend access right tests to directories commit d18955d094d09a220cf8f533f5e896a2fe31575a upstream. Make sure that all filesystem access rights can be tied to directories. Rename layout1.file_access_rights to layout1.file_and_dir_access_rights to reflect this change. Cc: Shuah Khan Link: https://lore.kernel.org/r/20220506160820.524344-6-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 1d6722353be71b8905900d1778c24bb79d90d03f Author: Mickaël Salaün Date: Fri May 6 18:08:14 2022 +0200 selftests/landlock: Add tests for unknown access rights commit c56b3bf566da5a0dd3b58ad97a614b0928b06ebf upstream. Make sure that trying to use unknown access rights returns an error. Cc: Shuah Khan Link: https://lore.kernel.org/r/20220506160820.524344-5-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit d709e275a05bdcc6cb3753baf19387b998ad975f Author: Mickaël Salaün Date: Fri May 6 18:08:13 2022 +0200 selftests/landlock: Extend tests for minimal valid attribute size commit 291865bd7e8bb4b4033d341fa02dafa728e6378c upstream. This might be useful when the struct landlock_ruleset_attr will get more fields. Cc: Shuah Khan Link: https://lore.kernel.org/r/20220506160820.524344-4-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit a6d127b86916f2b4eb59074bd438b50d44fbf497 Author: Mickaël Salaün Date: Fri May 6 18:08:12 2022 +0200 selftests/landlock: Make tests build with old libc commit 87129ef13603ae46c82bcd09eed948acf0506dbb upstream. Replace SYS_ with __NR_. Using the __NR_ notation, provided by UAPI, is useful to build tests on systems without the SYS_ definitions. Replace SYS_pivot_root with __NR_pivot_root, and SYS_move_mount with __NR_move_mount. Define renameat2() and RENAME_EXCHANGE if they are unknown to old build systems. Cc: Shuah Khan Link: https://lore.kernel.org/r/20220506160820.524344-3-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit e42fd07755364329c99e51d069d2daa96df77ed7 Author: Mickaël Salaün Date: Fri May 6 18:08:11 2022 +0200 landlock: Fix landlock_add_rule(2) documentation commit a13e248ff90e81e9322406c0e618cf2168702f4e upstream. It is not mandatory to pass a file descriptor obtained with the O_PATH flag. Also, replace rule's accesses with ruleset's accesses. Link: https://lore.kernel.org/r/20220506160820.524344-2-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit ef350611729b946e8e793d1ebe667cb9411a5d2e Author: Mickaël Salaün Date: Fri May 6 18:05:13 2022 +0200 samples/landlock: Format with clang-format commit 81709f3dccacf4104a4bc2daa80bdd767a9c4c54 upstream. Let's follow a consistent and documented coding style. Everything may not be to our liking but it is better than tacit knowledge. Moreover, this will help maintain style consistency between different developers. This contains only whitespace changes. Automatically formatted with: clang-format-14 -i samples/landlock/*.[ch] Link: https://lore.kernel.org/r/20220506160513.523257-8-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit ace624691974a0dac05d34949756c27d8b605a13 Author: Mickaël Salaün Date: Fri May 6 18:05:12 2022 +0200 samples/landlock: Add clang-format exceptions commit 9805a722db071e1772b80e6e0ff33f35355639ac upstream. In preparation to a following commit, add clang-format on and clang-format off stanzas around constant definitions. This enables to keep aligned values, which is much more readable than packed definitions. Link: https://lore.kernel.org/r/20220506160513.523257-7-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit de7a39e8458844a3714cdd4710bdc7ee0fc37d4e Author: Mickaël Salaün Date: Fri May 6 18:05:11 2022 +0200 selftests/landlock: Format with clang-format commit 371183fa578a4cf56b3ae12e54b7f01a4249add1 upstream. Let's follow a consistent and documented coding style. Everything may not be to our liking but it is better than tacit knowledge. Moreover, this will help maintain style consistency between different developers. This contains only whitespace changes. Automatically formatted with: clang-format-14 -i tools/testing/selftests/landlock/*.[ch] Link: https://lore.kernel.org/r/20220506160513.523257-6-mic@digikod.net Cc: stable@vger.kernel.org [mic: Update style according to https://lore.kernel.org/r/02494cb8-2aa5-1769-f28d-d7206f284e5a@digikod.net] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 43c3014c6fd4d512d41ec6a12a4888fe064bd426 Author: Mickaël Salaün Date: Fri May 6 18:05:10 2022 +0200 selftests/landlock: Normalize array assignment commit 135464f9d29c5b306d7201220f1d00dab30fea89 upstream. Add a comma after each array value to make clang-format keep the current array formatting. See the following commit. Automatically modified with: sed -i 's/\t\({}\|NULL\)$/\0,/' tools/testing/selftests/landlock/fs_test.c Link: https://lore.kernel.org/r/20220506160513.523257-5-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit f5c70d9deab02f7eeb92a80b073a0ec6ad218fd4 Author: Mickaël Salaün Date: Fri May 6 18:05:09 2022 +0200 selftests/landlock: Add clang-format exceptions commit 4598d9abf4215e1e371a35683350d50122793c80 upstream. In preparation to a following commit, add clang-format on and clang-format off stanzas around constant definitions and the TEST_F_FORK macro. This enables to keep aligned values, which is much more readable than packed definitions. Add other clang-format exceptions for FIXTURE() and FIXTURE_VARIANT_ADD() declarations to force space before open brace, which is reported by checkpatch.pl . Link: https://lore.kernel.org/r/20220506160513.523257-4-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 695c7c06162a5427e97c262f08d427a8e7b7b972 Author: Mickaël Salaün Date: Fri May 6 18:05:08 2022 +0200 landlock: Format with clang-format commit 06a1c40a09a8dded4bf0e7e3ccbda6bddcccd7c8 upstream. Let's follow a consistent and documented coding style. Everything may not be to our liking but it is better than tacit knowledge. Moreover, this will help maintain style consistency between different developers. This contains only whitespace changes. Automatically formatted with: clang-format-14 -i security/landlock/*.[ch] include/uapi/linux/landlock.h Link: https://lore.kernel.org/r/20220506160513.523257-3-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 58f52ad1d0adcae46b0f3e76665e624fc60766dd Author: Mickaël Salaün Date: Fri May 6 18:05:07 2022 +0200 landlock: Add clang-format exceptions commit 6cc2df8e3a3967e7c13a424f87f6efb1d4a62d80 upstream. In preparation to a following commit, add clang-format on and clang-format off stanzas around constant definitions. This enables to keep aligned values, which is much more readable than packed definitions. Link: https://lore.kernel.org/r/20220506160513.523257-2-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 1be49ae16f5348e71505cc96a424ce914983171a Author: Manivannan Sadhasivam Date: Wed May 4 14:12:10 2022 +0530 scsi: ufs: qcom: Add a readl() to make sure ref_clk gets enabled commit 8eecddfca30e1651dc1c74531ed5eef21dcce7e3 upstream. In ufs_qcom_dev_ref_clk_ctrl(), it was noted that the ref_clk needs to be stable for at least 1us. Even though there is wmb() to make sure the write gets "completed", there is no guarantee that the write actually reached the UFS device. There is a good chance that the write could be stored in a Write Buffer (WB). In that case, even though the CPU waits for 1us, the ref_clk might not be stable for that period. So lets do a readl() to make sure that the previous write has reached the UFS device before udelay(). Also, the wmb() after writel_relaxed() is not really needed. Both writel() and readl() are ordered on all architectures and the CPU won't speculate instructions after readl() due to the in-built control dependency with read value on weakly ordered architectures. So it can be safely removed. Link: https://lore.kernel.org/r/20220504084212.11605-4-manivannan.sadhasivam@linaro.org Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Cc: stable@vger.kernel.org Reviewed-by: Bjorn Andersson Signed-off-by: Manivannan Sadhasivam Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a078e6e8f4e32b6fc8dd26adc84313f2a4de233d Author: Xiaomeng Tong Date: Thu Apr 14 12:02:31 2022 +0800 scsi: dc395x: Fix a missing check on list iterator commit 036a45aa587a10fa2abbd50fbd0f6c4cfc44f69f upstream. The bug is here: p->target_id, p->target_lun); The list iterator 'p' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to an invalid memory access. To fix this bug, add a check. Use a new variable 'iter' as the list iterator, and use the original variable 'p' as a dedicated pointer to point to the found element. Link: https://lore.kernel.org/r/20220414040231.2662-1-xiam0nd.tong@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Xiaomeng Tong Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9c96238fac045b289993d7bc5aae7b2d72b25c76 Author: Junxiao Bi via Ocfs2-devel Date: Wed May 18 16:52:24 2022 -0700 ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock commit 863e0d81b6683c4cbc588ad831f560c90e494bef upstream. When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when bast come in, it will trigger a panic due to user-after-free. See the following panic call trace. To fix this, USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink fail. For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN, USER_LOCK_BUSY is also required to be cleared. Even though spin lock is released in between, but USER_LOCK_IN_TEARDOWN is still set, for USER_LOCK_BUSY, if before every place that waits on this flag, USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow waits on the busy flag set by user_dlm_destroy_lock(), then we can simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix user_dlm_cluster_lock() which is the only function not following this. [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink 004fb0000060000b5a90b8c847b72e1, error -16 from destroy [ 989.757536] ------------[ cut here ]------------ [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] invalid opcode: 0000 [#1] SMP [ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O) ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE 4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021 [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[] [] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4: 0000000000042660 [ 989.765081] Stack: [ 989.765167] 0000000000000003 ffff880174d48040 ffff88017f7cbd18 ffffffffc07d455f [ 989.765442] ffff88017f7cbd88 ffffffff816fb639 ffff88017f7cbd38 ffff8800361b5600 [ 989.765717] ffff88021db7a000 ffff88021f429380 0000000000000003 ffffffffc0453020 [ 989.765991] Call Trace: [ 989.766093] [] user_bast+0x5f/0xf0 [ocfs2_dlmfs] [ 989.766287] [] ? schedule_timeout+0x169/0x2d0 [ 989.766475] [] ? o2dlm_lock_ast_wrapper+0x20/0x20 [ocfs2_stack_o2cb] [ 989.766738] [] o2dlm_blocking_ast_wrapper+0x1a/0x20 [ocfs2_stack_o2cb] [ 989.767010] [] dlm_do_local_bast+0x46/0xe0 [ocfs2_dlm] [ 989.767217] [] ? dlm_lockres_calc_usage+0x4c/0x60 [ocfs2_dlm] [ 989.767466] [] dlm_thread+0xa31/0x1140 [ocfs2_dlm] [ 989.767662] [] ? __schedule+0x24a/0x810 [ 989.767834] [] ? __schedule+0x23e/0x810 [ 989.768006] [] ? __schedule+0x24a/0x810 [ 989.768178] [] ? __schedule+0x23e/0x810 [ 989.768349] [] ? __schedule+0x24a/0x810 [ 989.768521] [] ? __schedule+0x23e/0x810 [ 989.768693] [] ? __schedule+0x24a/0x810 [ 989.768893] [] ? __schedule+0x23e/0x810 [ 989.769067] [] ? __schedule+0x24a/0x810 [ 989.769241] [] ? wait_woken+0x90/0x90 [ 989.769411] [] ? dlm_kick_thread+0x80/0x80 [ocfs2_dlm] [ 989.769617] [] kthread+0xcb/0xf0 [ 989.769774] [] ? __schedule+0x24a/0x810 [ 989.769945] [] ? __schedule+0x24a/0x810 [ 989.770117] [] ? kthread_create_on_node+0x180/0x180 [ 989.770321] [] ret_from_fork+0x61/0x90 [ 989.770492] [] ? kthread_create_on_node+0x180/0x180 [ 989.770689] Code: d0 00 00 00 f0 45 7d c0 bf 00 20 00 00 48 89 83 c0 00 00 00 48 89 83 c8 00 00 00 e8 55 c1 8c c0 83 4b 04 10 48 83 c4 08 5b 5d c3 <0f> 0b 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 55 41 54 53 48 83 [ 989.771892] RIP [] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.772174] RSP [ 989.772704] ---[ end trace ebd1e38cebcc93a8 ]--- [ 989.772907] Kernel panic - not syncing: Fatal exception [ 989.773173] Kernel Offset: disabled Link: https://lkml.kernel.org/r/20220518235224.87100-2-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e70f0582805b5698e4ddcf6d48323ff5cc6318f6 Author: Alexander Aring Date: Fri Apr 29 11:06:51 2022 -0400 dlm: fix missing lkb refcount handling commit 1689c169134f4b5a39156122d799b7dca76d8ddb upstream. We always call hold_lkb(lkb) if we increment lkb->lkb_wait_count. So, we always need to call unhold_lkb(lkb) if we decrement lkb->lkb_wait_count. This patch will add missing unhold_lkb(lkb) if we decrement lkb->lkb_wait_count. In case of setting lkb->lkb_wait_count to zero we need to countdown until reaching zero and call unhold_lkb(lkb). The waiters list unhold_lkb(lkb) can be removed because it's done for the last lkb_wait_count decrement iteration as it's done in _remove_from_waiters(). This issue was discovered by a dlm gfs2 test case which use excessively dlm_unlock(LKF_CANCEL) feature. Probably the lkb->lkb_wait_count value never reached above 1 if this feature isn't used and so it was not discovered before. The testcase ended in a rsb on the rsb keep data structure with a refcount of 1 but no lkb was associated with it, which is itself an invalid behaviour. A side effect of that was a condition in which the dlm was sending remove messages in a looping behaviour. With this patch that has not been reproduced. Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 697b45d5f06a86ae95819c98a2e974f792d74409 Author: Dan Carpenter Date: Mon Apr 4 16:06:28 2022 -0400 dlm: uninitialized variable on error in dlm_listen_for_all() commit 1f4f10845e14690b02410de50d9ea9684625a4ae upstream. The "sock" variable is not initialized on this error path. Cc: stable@vger.kernel.org Fixes: 2dc6b1158c28 ("fs: dlm: introduce generic listen") Signed-off-by: Dan Carpenter Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit acdad5bc9827922ec2f2e84fd198718aa8e8ab92 Author: Alexander Aring Date: Mon Apr 4 16:06:30 2022 -0400 dlm: fix plock invalid read commit 42252d0d2aa9b94d168241710a761588b3959019 upstream. This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 [dlm] [ 2064.399932] process_recv_sockets+0x32/0x40 [dlm] [ 2064.402180] process_one_work+0x9a8/0x16e0 [ 2064.404388] worker_thread+0x87/0xbf0 [ 2064.406124] kthread+0x3ac/0x490 [ 2064.408021] ret_from_fork+0x22/0x30 [ 2064.409834] [ 2064.410599] The buggy address belongs to the object at ffff88800ef22780 [ 2064.410599] which belongs to the cache kmalloc-96 of size 96 [ 2064.416495] The buggy address is located 88 bytes inside of [ 2064.416495] 96-byte region [ffff88800ef22780, ffff88800ef227e0) [ 2064.422045] The buggy address belongs to the page: [ 2064.424635] page:00000000b6bef8bc refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xef22 [ 2064.428970] flags: 0xfffffc0000200(slab|node=0|zone=1|lastcpupid=0x1fffff) [ 2064.432515] raw: 000fffffc0000200 ffffea0000d68b80 0000001400000014 ffff888001041780 [ 2064.436110] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 [ 2064.439813] page dumped because: kasan: bad access detected [ 2064.442548] [ 2064.443310] Memory state around the buggy address: [ 2064.445988] ffff88800ef22680: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 2064.449444] ffff88800ef22700: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 2064.452941] >ffff88800ef22780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc [ 2064.456383] ^ [ 2064.459386] ffff88800ef22800: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2064.462788] ffff88800ef22880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 2064.466239] ================================================================== reproducer in python: import argparse import struct import fcntl import os parser = argparse.ArgumentParser() parser.add_argument('-f', '--file', help='file to use fcntl, must be on dlm lock filesystem e.g. gfs2') args = parser.parse_args() f = open(args.file, 'wb+') lockdata = struct.pack('hhllhh', fcntl.F_WRLCK,0,0,0,0,0) fcntl.fcntl(f, fcntl.F_SETLK, lockdata) lockdata = struct.pack('hhllhh', fcntl.F_UNLCK,0,0,0,0,0) fcntl.fcntl(f, fcntl.F_SETLK, lockdata) Fixes: 586759f03e2e ("gfs2: nfs lock support for gfs2") Cc: stable@vger.kernel.org Signed-off-by: Andreas Gruenbacher Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit f19e2e1d8528c268c0ddfe41142c63730df79f9b Author: Sven Schnelle Date: Tue May 3 09:58:33 2022 +0200 s390/stp: clock_delta should be signed commit 5ace65ebb5ce9fe1cc8fdbdd97079fb566ef0ea4 upstream. clock_delta is declared as unsigned long in various places. However, the clock sync delta can be negative. This would add a huge positive offset in clock_sync_global where clock_delta is added to clk.eitod which is a 72 bit integer. Declare it as signed long to fix this. Cc: stable@vger.kernel.org Signed-off-by: Sven Schnelle Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 42b2f5ddc2204db845cf1f78ae296194557df714 Author: Nico Boehr Date: Tue May 24 15:43:20 2022 +0200 s390/perf: obtain sie_block from the right address commit c9bfb460c3e4da2462e16b0f0b200990b36b1dd2 upstream. Since commit 1179f170b6f0 ("s390: fix fpu restore in entry.S"), the sie_block pointer is located at empty1[1], but in sie_block() it was taken from empty1[0]. This leads to a random pointer being dereferenced, possibly causing system crash. This problem can be observed when running a simple guest with an endless loop and recording the cpu-clock event: sudo perf kvm --guestvmlinux= --guest top -e cpu-clock With this fix, the correct guest address is shown. Fixes: 1179f170b6f0 ("s390: fix fpu restore in entry.S") Cc: stable@vger.kernel.org Acked-by: Christian Borntraeger Acked-by: Claudio Imbrenda Reviewed-by: Heiko Carstens Signed-off-by: Nico Boehr Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 20e6ec76aed47c65ee2dd7636f4911396c9396c7 Author: Rei Yamamoto Date: Fri May 13 16:48:57 2022 -0700 mm, compaction: fast_find_migrateblock() should return pfn in the target zone commit bbe832b9db2e1ad21522f8f0bf02775fff8a0e0e upstream. At present, pages not in the target zone are added to cc->migratepages list in isolate_migratepages_block(). As a result, pages may migrate between nodes unintentionally. This would be a serious problem for older kernels without commit a984226f457f849e ("mm: memcontrol: remove the pgdata parameter of mem_cgroup_page_lruvec"), because it can corrupt the lru list by handling pages in list without holding proper lru_lock. Avoid returning a pfn outside the target zone in the case that it is not aligned with a pageblock boundary. Otherwise isolate_migratepages_block() will handle pages not in the target zone. Link: https://lkml.kernel.org/r/20220511044300.4069-1-yamamoto.rei@jp.fujitsu.com Fixes: 70b44595eafe ("mm, compaction: use free lists to quickly locate a migration source") Signed-off-by: Rei Yamamoto Reviewed-by: Miaohe Lin Acked-by: Mel Gorman Reviewed-by: Oscar Salvador Cc: Don Dutile Cc: Wonhyuk Yang Cc: Rei Yamamoto Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ac2eab7de458f5e1210ce1237afab40a307075c8 Author: Denis Efremov Date: Wed May 18 11:00:52 2022 +0400 staging: r8188eu: prevent ->Ssid overflow in rtw_wx_set_scan() commit bc10916e890948d8927a5c8c40fb5dc44be5e1b8 upstream. This code has a check to prevent read overflow but it needs another check to prevent writing beyond the end of the ->Ssid[] array. Fixes: 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver") Cc: stable Signed-off-by: Denis Efremov Link: https://lore.kernel.org/r/20220518070052.108287-1-denis.e.efremov@oracle.com Signed-off-by: Greg Kroah-Hartman commit a7daaaa84548c62177dd5872cf636d8085cd1b7a Author: Johan Hovold Date: Fri Apr 1 15:38:54 2022 +0200 PCI: qcom: Fix unbalanced PHY init on probe errors commit 83013631f0f9961416abd812e228c8efbc2f6069 upstream. Undo the PHY initialisation (e.g. balance runtime PM) if host initialisation fails during probe. Link: https://lore.kernel.org/r/20220401133854.10421-3-johan+linaro@kernel.org Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Johan Hovold Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Acked-by: Stanimir Varbanov Cc: stable@vger.kernel.org # 4.5 Signed-off-by: Greg Kroah-Hartman commit 4f9d6407b60764c4b77c80f72cfdd952d5db5b8e Author: Johan Hovold Date: Fri Apr 1 15:38:53 2022 +0200 PCI: qcom: Fix runtime PM imbalance on probe errors commit 87d83b96c8d6c6c2d2096bd0bdba73bcf42b8ef0 upstream. Drop the leftover pm_runtime_disable() calls from the late probe error paths that would, for example, prevent runtime PM from being reenabled after a probe deferral. Link: https://lore.kernel.org/r/20220401133854.10421-2-johan+linaro@kernel.org Fixes: 6e5da6f7d824 ("PCI: qcom: Fix error handling in runtime PM support") Signed-off-by: Johan Hovold Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Acked-by: Stanimir Varbanov Cc: stable@vger.kernel.org # 4.20 Cc: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 0db67767ff3a1f0829fdd2d49b828bd23d01f250 Author: Bjorn Helgaas Date: Thu May 26 16:52:23 2022 -0500 PCI/PM: Fix bridge_d3_blacklist[] Elo i2 overwrite of Gigabyte X299 commit 12068bb346db5776d0ec9bb4cd073f8427a1ac92 upstream. 92597f97a40b ("PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold") omitted braces around the new Elo i2 entry, so it overwrote the existing Gigabyte X299 entry. Add the appropriate braces. Found by: $ make W=1 drivers/pci/pci.o CC drivers/pci/pci.o drivers/pci/pci.c:2974:12: error: initialized field overwritten [-Werror=override-init] 2974 | .ident = "Elo i2", | ^~~~~~~~ Link: https://lore.kernel.org/r/20220526221258.GA409855@bhelgaas Fixes: 92597f97a40b ("PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold") Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Greg Kroah-Hartman commit 283bda02d0c16f1c86904d75f88dbc68d88ae46a Author: Alex Deucher Date: Tue May 24 23:23:59 2022 -0400 drm/amdgpu: add beige goby PCI ID commit 62e9bd20035b53ff6c679499c08546d96c6c60a7 upstream. Add a beige goby PCI ID. Reviewed-by: Guchun Chen Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4ef5ab5344bae712c09f8d36f8fe1996b6fedb2a Author: Gautam Menghani Date: Sat May 21 23:18:26 2022 -0700 tracing: Initialize integer variable to prevent garbage return value commit 154827f8e53d8c492b3fb0cb757fbcadb5d516b5 upstream. Initialize the integer variable to 0 to fix the clang scan warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn] return ret; Link: https://lkml.kernel.org/r/20220522061826.1751-1-gautammenghani201@gmail.com Cc: stable@vger.kernel.org Fixes: 8993665abcce ("tracing/boot: Support multiple handlers for per-event histogram") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Gautam Menghani Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 37443b3508b8cce6832f8d25cb4550b2f7801f50 Author: Keita Suzuki Date: Mon Apr 25 06:37:38 2022 +0000 tracing: Fix potential double free in create_var_ref() commit 99696a2592bca641eb88cc9a80c90e591afebd0f upstream. In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref(). Link: https://lkml.kernel.org/r/20220425063739.3859998-1-keitasuzuki.park@sslab.ics.keio.ac.jp Fixes: 067fe038e70f ("tracing: Add variable reference handling to hist triggers") CC: stable@vger.kernel.org Reviewed-by: Masami Hiramatsu Reviewed-by: Tom Zanussi Signed-off-by: Keita Suzuki Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 0b011b408f349e76f7903a477870051f94c7e119 Author: Laurent Vivier Date: Wed Apr 6 22:15:20 2022 +0200 tty: goldfish: Introduce gf_ioread32()/gf_iowrite32() commit 2e2ac4a3327479f7e2744cdd88a5c823f2057bad upstream. The goldfish TTY device was clearly defined as having little-endian registers, but the switch to __raw_{read,write}l(() broke its driver when running on big-endian kernels (if anyone ever tried this). The m68k qemu implementation got this wrong, and assumed native-endian registers. While this is a bug in qemu, it is probably impossible to fix that since there is no way of knowing which other operating systems have started relying on that bug over the years. Hence revert commit da31de35cd2f ("tty: goldfish: use __raw_writel()/__raw_readl()", and define gf_ioread32()/gf_iowrite32() to be able to use accessors defined by the architecture. Cc: stable@vger.kernel.org # v5.11+ Fixes: da31de35cd2fb78f ("tty: goldfish: use __raw_writel()/__raw_readl()") Signed-off-by: Laurent Vivier Link: https://lore.kernel.org/r/20220406201523.243733-2-laurent@vivier.eu [geert: Add rationale based on Arnd's comments] Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit b3485d2b09e946da83e530112e7eea0da997b96a Author: Sakari Ailus Date: Wed Apr 6 16:12:08 2022 +0300 ACPI: property: Release subnode properties with data nodes commit 3bd561e1572ee02a50cd1a5be339abf1a5b78d56 upstream. struct acpi_device_properties describes one source of properties present on either struct acpi_device or struct acpi_data_node. When properties are parsed, both are populated but when released, only those properties that are associated with the device node are freed. Fix this by also releasing memory of the data node properties. Fixes: 5f5e4890d57a ("ACPI / property: Allow multiple property compatible _DSD entries") Cc: 4.20+ # 4.20+ Signed-off-by: Sakari Ailus Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3a3ce941645407cd0b0b7f01ad9e2ea3770f46cc Author: Jan Kara Date: Wed May 18 11:33:29 2022 +0200 ext4: avoid cycles in directory h-tree commit 3ba733f879c2a88910744647e41edeefbc0d92b2 upstream. A maliciously corrupted filesystem can contain cycles in the h-tree stored inside a directory. That can easily lead to the kernel corrupting tree nodes that were already verified under its hands while doing a node split and consequently accessing unallocated memory. Fix the problem by verifying traversed block numbers are unique. Cc: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220518093332.13986-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit ca17db384762be0ec38373a12460081d22a8b42d Author: Jan Kara Date: Wed May 18 11:33:28 2022 +0200 ext4: verify dir block before splitting it commit 46c116b920ebec58031f0a78c5ea9599b0d2a371 upstream. Before splitting a directory block verify its directory entries are sane so that the splitting code does not access memory it should not. Cc: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220518093332.13986-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 3c617827cd51018bc377bd2954e176920ddbcfad Author: Baokun Li Date: Wed May 18 20:08:16 2022 +0800 ext4: fix bug_on in __es_tree_search commit d36f6ed761b53933b0b4126486c10d3da7751e7f upstream. Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/extents_status.c:199! [...] RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline] RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217 [...] Call Trace: ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 mount_bdev+0x2e9/0x3b0 fs/super.c:1158 mount_fs+0x4b/0x1e4 fs/super.c:1261 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_enable_quotas ext4_quota_enable ext4_iget __ext4_iget ext4_ext_check_inode ext4_ext_check __ext4_ext_check ext4_valid_extent_entries Check for overlapping extents does't take effect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent ext4_es_cache_extent __es_tree_search ext4_es_end BUG_ON(es->es_lblk + es->es_len < es->es_lblk) The error ext4 extents is as follows: 0af3 0300 0400 0000 00000000 extent_header 00000000 0100 0000 12000000 extent1 00000000 0100 0000 18000000 extent2 02000000 0400 0000 14000000 extent3 In the ext4_valid_extent_entries function, if prev is 0, no error is returned even if lblock<=prev. This was intended to skip the check on the first extent, but in the error image above, prev=0+1-1=0 when checking the second extent, so even though lblock<=prev, the function does not return an error. As a result, bug_ON occurs in __es_tree_search and the system panics. To solve this problem, we only need to check that: 1. The lblock of the first extent is not less than 0. 2. The lblock of the next extent is not less than the next block of the previous extent. The same applies to extent_idx. Cc: stable@kernel.org Fixes: 5946d089379a ("ext4: check for overlapping extents in ext4_valid_extent_entries()") Reported-by: Hulk Robot Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220518120816.1541863-1-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit b99fd73418350dea360da8311e87a6a7b0e15a4c Author: Theodore Ts'o Date: Tue May 17 13:27:55 2022 -0400 ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state commit c878bea3c9d724ddfa05a813f30de3d25a0ba83f upstream. The EXT4_FC_REPLAY bit in sbi->s_mount_state is used to indicate that we are in the middle of replay the fast commit journal. This was actually a mistake, since the sbi->s_mount_info is initialized from es->s_state. Arguably s_mount_state is misleadingly named, but the name is historical --- s_mount_state and s_state dates back to ext2. What should have been used is the ext4_{set,clear,test}_mount_flag() inline functions, which sets EXT4_MF_* bits in sbi->s_mount_flags. The problem with using EXT4_FC_REPLAY is that a maliciously corrupted superblock could result in EXT4_FC_REPLAY getting set in s_mount_state. This bypasses some sanity checks, and this can trigger a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter out the EXT4_FC_REPLAY bit for now. We should eventually transition away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY. Cc: stable@kernel.org Signed-off-by: Theodore Ts'o Link: https://lore.kernel.org/r/20220420192312.1655305-1-phind.uet@gmail.com Link: https://lore.kernel.org/r/20220517174028.942119-1-tytso@mit.edu Reported-by: syzbot+c7358a3cd05ee786eb31@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman commit 18a759f7f99f0b65a08ff5b7e745fc405a42bde4 Author: Ye Bin Date: Mon May 16 20:26:34 2022 +0800 ext4: fix bug_on in ext4_writepages commit ef09ed5d37b84d18562b30cf7253e57062d0db05 upstream. we got issue as follows: EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls ------------[ cut here ]------------ kernel BUG at fs/ext4/inode.c:2708! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90 It may happen as follows: 1. write inline_data inode vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> If inline data size too small will allocate block to write, then mapping will has dirty page ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> fail will goto restore data ext4_restore_inline_data ext4_create_inline_data ext4_write_inline_data ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages if (ext4_has_inline_data(inode)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) The root cause of this issue is we destory inline data until call ext4_writepages under delay allocation mode. But there maybe already convert from inline to extent. To solve this issue, we call filemap_flush first.. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220516122634.1690462-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit b81d2ff6885e38fc745eeaf9565775055778fc0b Author: Ye Bin Date: Sat Mar 26 14:53:51 2022 +0800 ext4: fix warning in ext4_handle_inode_extension commit f4534c9fc94d22383f187b9409abb3f9df2e3db3 upstream. We got issue as follows: EXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory EXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error EXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory EXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can't allocate blocks for non-extent mapped inodes with bigalloc ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220 Modules linked in: CPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1 RIP: 0010:ext4_file_write_iter+0x11c9/0x1220 RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282 RAX: ffffffff815a3379 RBX: 0000000000000000 RCX: 000000003b000000 RDX: ffff924d81601000 RSI: 00000000000009cc RDI: 00000000000009cd RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a R13: 0000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_iter_readv_writev+0x2e5/0x360 do_iter_write+0x112/0x4c0 do_pwritev+0x1e5/0x390 __x64_sys_pwritev2+0x7e/0xa0 do_syscall_64+0x37/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: Assume inode.i_size=4096 EXT4_I(inode)->i_disksize=4096 step 1: set inode->i_isize = 8192 ext4_setattr if (attr->ia_size != inode->i_size) EXT4_I(inode)->i_disksize = attr->ia_size; rc = ext4_mark_inode_dirty ext4_reserve_inode_write ext4_get_inode_loc __ext4_get_inode_loc sb_getblk --> return -ENOMEM ... if (!error) ->will not update i_size i_size_write(inode, attr->ia_size); Now: inode.i_size=4096 EXT4_I(inode)->i_disksize=8192 step 2: Direct write 4096 bytes ext4_file_write_iter ext4_dio_write_iter iomap_dio_rw ->return error if (extend) ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize); ->Then trigger warning. To solve above issue, if mark inode dirty failed in ext4_setattr just set 'EXT4_I(inode)->i_disksize' with old value. Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20220326065351.761952-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 14602353b350950b551eccc6b46411aa3b12ffe2 Author: Baokun Li Date: Thu Apr 28 21:40:31 2022 +0800 ext4: fix race condition between ext4_write and ext4_convert_inline_data commit f87c7a4b084afc13190cbb263538e444cb2b392a upstream. Hulk Robot reported a BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ================================================================== Above issue may happen as follows: cpu1 cpu2 __________________________|__________________________ do_pwritev vfs_writev do_iter_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks ext4_mb_regular_allocator ext4_mb_good_group_nolock ext4_mb_init_group ext4_mb_init_cache ext4_mb_generate_buddy --> error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_restore_inline_data set EXT4_STATE_MAY_INLINE_DATA ext4_block_write_begin ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) __ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ON The lock held by ext4_convert_inline_data is xattr_sem, but the lock held by generic_perform_write is i_rwsem. Therefore, the two locks can be concurrent. To solve above issue, we add inode_lock() for ext4_convert_inline_data(). At the same time, move ext4_convert_inline_data() in front of ext4_punch_hole(), remove similar handling from ext4_punch_hole(). Fixes: 0c8d414f163f ("ext4: let fallocate handle inline data correctly") Cc: stable@vger.kernel.org Reported-by: Hulk Robot Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220428134031.4153381-1-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 364380c00912bed9b5d99eb485018360b0ecf64f Author: Ye Bin Date: Thu Apr 14 10:52:23 2022 +0800 ext4: fix use-after-free in ext4_rename_dir_prepare commit 0be698ecbe4471fcad80e81ec6a05001421041b3 upstream. We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ] Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220414025223.4113128-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3e4b684f1e32540bec1a77b96779df35c0ff300c Author: Dmitry Monakhov Date: Sun Apr 17 20:03:15 2022 +0300 ext4: mark group as trimmed only if it was fully scanned commit d63c00ea435a5352f486c259665a4ced60399421 upstream. Otherwise nonaligned fstrim calls will works inconveniently for iterative scanners, for example: // trim [0,16MB] for group-1, but mark full group as trimmed fstrim -o $((1024*1024*128)) -l $((1024*1024*16)) ./m // handle [16MB,16MB] for group-1, do nothing because group already has the flag. fstrim -o $((1024*1024*144)) -l $((1024*1024*16)) ./m [ Update function documentation for ext4_trim_all_free -- TYT ] Signed-off-by: Dmitry Monakhov Link: https://lore.kernel.org/r/1650214995-860245-1-git-send-email-dmtrmonakhov@yandex-team.ru Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6ee0868b0c3ccead5907685fcdcdd0c08dfe4b0b Author: Jan Kara Date: Fri Apr 1 12:27:50 2022 +0200 bfq: Make sure bfqg for which we are queueing requests is online commit 075a53b78b815301f8d3dd1ee2cd99554e34f0dd upstream. Bios queued into BFQ IO scheduler can be associated with a cgroup that was already offlined. This may then cause insertion of this bfq_group into a service tree. But this bfq_group will get freed as soon as last bio associated with it is completed leading to use after free issues for service tree users. Fix the problem by making sure we always operate on online bfq_group. If the bfq_group associated with the bio is not online, we pick the first online parent. CC: stable@vger.kernel.org Fixes: e21b7a0b9887 ("block, bfq: add full hierarchical scheduling and cgroups support") Tested-by: "yukuai (C)" Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-9-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 86defc5424414f3beb598f02da162eb571fc0762 Author: Jan Kara Date: Fri Apr 1 12:27:49 2022 +0200 bfq: Get rid of __bio_blkcg() usage commit 4e54a2493e582361adc3bfbf06c7d50d19d18837 upstream. BFQ usage of __bio_blkcg() is a relict from the past. Furthermore if bio would not be associated with any blkcg, the usage of __bio_blkcg() in BFQ is prone to races with the task being migrated between cgroups as __bio_blkcg() calls at different places could return different blkcgs. Convert BFQ to the new situation where bio->bi_blkg is initialized in bio_set_dev() and thus practically always valid. This allows us to save blkcg_gq lookup and noticeably simplify the code. CC: stable@vger.kernel.org Fixes: 0fe061b9f03c ("blkcg: fix ref count issue with bio_blkcg() using task_css") Tested-by: "yukuai (C)" Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-8-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 54c08ef2d296ca7321955379cd0a6005882baa7c Author: Jan Kara Date: Fri Apr 1 12:27:48 2022 +0200 bfq: Track whether bfq_group is still online commit 09f871868080c33992cd6a9b72a5ca49582578fa upstream. Track whether bfq_group is still online. We cannot rely on blkcg_gq->online because that gets cleared only after all policies are offlined and we need something that gets updated already under bfqd->lock when we are cleaning up our bfq_group to be able to guarantee that when we see online bfq_group, it will stay online while we are holding bfqd->lock lock. CC: stable@vger.kernel.org Tested-by: "yukuai (C)" Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-7-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2b802c0cb872cbc47f0021398a1c16a52c6a349a Author: Jan Kara Date: Fri Apr 1 12:27:47 2022 +0200 bfq: Remove pointless bfq_init_rq() calls commit 5f550ede5edf846ecc0067be1ba80514e6fe7f8e upstream. We call bfq_init_rq() from request merging functions where requests we get should have already gone through bfq_init_rq() during insert and anyway we want to do anything only if the request is already tracked by BFQ. So replace calls to bfq_init_rq() with RQ_BFQQ() instead to simply skip requests untracked by BFQ. We move bfq_init_rq() call in bfq_insert_request() a bit earlier to cover request merging and thus can transfer FIFO position in case of a merge. CC: stable@vger.kernel.org Tested-by: "yukuai (C)" Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-6-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a107df383c163fdf9fdf748bc8f1a5e8f00d29c1 Author: Jan Kara Date: Fri Apr 1 12:27:46 2022 +0200 bfq: Drop pointless unlock-lock pair commit fc84e1f941b91221092da5b3102ec82da24c5673 upstream. In bfq_insert_request() we unlock bfqd->lock only to call trace_block_rq_insert() and then lock bfqd->lock again. This is really pointless since tracing is disabled if we really care about performance and even if the tracepoint is enabled, it is a quick call. CC: stable@vger.kernel.org Tested-by: "yukuai (C)" Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-5-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e8821f45612f2e6d9adb9c6ba0fb4184f57692aa Author: Jan Kara Date: Fri Apr 1 12:27:45 2022 +0200 bfq: Update cgroup information before merging bio commit ea591cd4eb270393810e7be01feb8fde6a34fbbe upstream. When the process is migrated to a different cgroup (or in case of writeback just starts submitting bios associated with a different cgroup) bfq_merge_bio() can operate with stale cgroup information in bic. Thus the bio can be merged to a request from a different cgroup or it can result in merging of bfqqs for different cgroups or bfqqs of already dead cgroups and causing possible use-after-free issues. Fix the problem by updating cgroup information in bfq_merge_bio(). CC: stable@vger.kernel.org Fixes: e21b7a0b9887 ("block, bfq: add full hierarchical scheduling and cgroups support") Tested-by: "yukuai (C)" Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-4-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 81b7d0c717a487ec50e2924a773ff501ee40f0d5 Author: Jan Kara Date: Fri Apr 1 12:27:44 2022 +0200 bfq: Split shared queues on move between cgroups commit 3bc5e683c67d94bd839a1da2e796c15847b51b69 upstream. When bfqq is shared by multiple processes it can happen that one of the processes gets moved to a different cgroup (or just starts submitting IO for different cgroup). In case that happens we need to split the merged bfqq as otherwise we will have IO for multiple cgroups in one bfqq and we will just account IO time to wrong entities etc. Similarly if the bfqq is scheduled to merge with another bfqq but the merge didn't happen yet, cancel the merge as it need not be valid anymore. CC: stable@vger.kernel.org Fixes: e21b7a0b9887 ("block, bfq: add full hierarchical scheduling and cgroups support") Tested-by: "yukuai (C)" Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-3-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5ee21edaed09e6b25f2c007b3f326752bc89bacf Author: Jan Kara Date: Fri Apr 1 12:27:43 2022 +0200 bfq: Avoid merging queues with different parents commit c1cee4ab36acef271be9101590756ed0c0c374d9 upstream. It can happen that the parent of a bfqq changes between the moment we decide two queues are worth to merge (and set bic->stable_merge_bfqq) and the moment bfq_setup_merge() is called. This can happen e.g. because the process submitted IO for a different cgroup and thus bfqq got reparented. It can even happen that the bfqq we are merging with has parent cgroup that is already offline and going to be destroyed in which case the merge can lead to use-after-free issues such as: BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50 Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544 CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x46/0x5a print_address_description.constprop.0+0x1f/0x140 ? __bfq_deactivate_entity+0x9cb/0xa50 kasan_report.cold+0x7f/0x11b ? __bfq_deactivate_entity+0x9cb/0xa50 __bfq_deactivate_entity+0x9cb/0xa50 ? update_curr+0x32f/0x5d0 bfq_deactivate_entity+0xa0/0x1d0 bfq_del_bfqq_busy+0x28a/0x420 ? resched_curr+0x116/0x1d0 ? bfq_requeue_bfqq+0x70/0x70 ? check_preempt_wakeup+0x52b/0xbc0 __bfq_bfqq_expire+0x1a2/0x270 bfq_bfqq_expire+0xd16/0x2160 ? try_to_wake_up+0x4ee/0x1260 ? bfq_end_wr_async_queues+0xe0/0xe0 ? _raw_write_unlock_bh+0x60/0x60 ? _raw_spin_lock_irq+0x81/0xe0 bfq_idle_slice_timer+0x109/0x280 ? bfq_dispatch_request+0x4870/0x4870 __hrtimer_run_queues+0x37d/0x700 ? enqueue_hrtimer+0x1b0/0x1b0 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_update_offsets_now+0x6f/0x280 hrtimer_interrupt+0x2c8/0x740 Fix the problem by checking that the parent of the two bfqqs we are merging in bfq_setup_merge() is the same. Link: https://lore.kernel.org/linux-block/20211125172809.GC19572@quack2.suse.cz/ CC: stable@vger.kernel.org Fixes: 430a67f9d616 ("block, bfq: merge bursts of newly-created queues") Tested-by: "yukuai (C)" Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-2-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d639a4c0df2b1efc9db84d88c9803d8478427752 Author: Jan Kara Date: Fri Apr 1 12:27:42 2022 +0200 bfq: Avoid false marking of bic as stably merged commit 70456e5210f40ffdb8f6d905acfdcec5bd5fad9e upstream. bfq_setup_cooperator() can mark bic as stably merged even though it decides to not merge its bfqqs (when bfq_setup_merge() returns NULL). Make sure to mark bic as stably merged only if we are really going to merge bfqqs. CC: stable@vger.kernel.org Tested-by: "yukuai (C)" Fixes: 430a67f9d616 ("block, bfq: merge bursts of newly-created queues") Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220401102752.8599-1-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 65237307f88f5200782ae7f243bdd385e37cde5d Author: Aditya Garg Date: Fri Apr 15 17:02:46 2022 +0000 efi: Do not import certificates from UEFI Secure Boot for T2 Macs commit 155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb upstream. On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs: [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 So we avoid reading these UEFI variables and thus prevent the crash. Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg Reviewed-by: Mimi Zohar Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 9bc601c6642c302d82a84ca49da157d553f62c24 Author: Zhihao Cheng Date: Tue May 10 21:38:05 2022 +0800 fs-writeback: writeback_sb_inodes:Recalculate 'wrote' according skipped pages commit 68f4c6eba70df70a720188bce95c85570ddfcc87 upstream. Commit 505a666ee3fc ("writeback: plug writeback in wb_writeback() and writeback_inodes_wb()") has us holding a plug during wb_writeback, which may cause a potential ABBA dead lock: wb_writeback fat_file_fsync blk_start_plug(&plug) for (;;) { iter i-1: some reqs have been added into plug->mq_list // LOCK A iter i: progress = __writeback_inodes_wb(wb, work) . writeback_sb_inodes // fat's bdev . __writeback_single_inode . . generic_writepages . . __block_write_full_page . . . . __generic_file_fsync . . . . sync_inode_metadata . . . . writeback_single_inode . . . . __writeback_single_inode . . . . fat_write_inode . . . . __fat_write_inode . . . . sync_dirty_buffer // fat's bdev . . . . lock_buffer(bh) // LOCK B . . . . submit_bh . . . . blk_mq_get_tag // LOCK A . . . trylock_buffer(bh) // LOCK B . . . redirty_page_for_writepage . . . wbc->pages_skipped++ . . --wbc->nr_to_write . wrote += write_chunk - wbc.nr_to_write // wrote > 0 . requeue_inode . redirty_tail_locked if (progress) // progress > 0 continue; iter i+1: queue_io // similar process with iter i, infinite for-loop ! } blk_finish_plug(&plug) // flush plug won't be called Above process triggers a hungtask like: [ 399.044861] INFO: task bb:2607 blocked for more than 30 seconds. [ 399.046824] Not tainted 5.18.0-rc1-00005-gefae4d9eb6a2-dirty [ 399.051539] task:bb state:D stack: 0 pid: 2607 ppid: 2426 flags:0x00004000 [ 399.051556] Call Trace: [ 399.051570] __schedule+0x480/0x1050 [ 399.051592] schedule+0x92/0x1a0 [ 399.051602] io_schedule+0x22/0x50 [ 399.051613] blk_mq_get_tag+0x1d3/0x3c0 [ 399.051640] __blk_mq_alloc_requests+0x21d/0x3f0 [ 399.051657] blk_mq_submit_bio+0x68d/0xca0 [ 399.051674] __submit_bio+0x1b5/0x2d0 [ 399.051708] submit_bio_noacct+0x34e/0x720 [ 399.051718] submit_bio+0x3b/0x150 [ 399.051725] submit_bh_wbc+0x161/0x230 [ 399.051734] __sync_dirty_buffer+0xd1/0x420 [ 399.051744] sync_dirty_buffer+0x17/0x20 [ 399.051750] __fat_write_inode+0x289/0x310 [ 399.051766] fat_write_inode+0x2a/0xa0 [ 399.051783] __writeback_single_inode+0x53c/0x6f0 [ 399.051795] writeback_single_inode+0x145/0x200 [ 399.051803] sync_inode_metadata+0x45/0x70 [ 399.051856] __generic_file_fsync+0xa3/0x150 [ 399.051880] fat_file_fsync+0x1d/0x80 [ 399.051895] vfs_fsync_range+0x40/0xb0 [ 399.051929] __x64_sys_fsync+0x18/0x30 In my test, 'need_resched()' (which is imported by 590dca3a71 "fs-writeback: unplug before cond_resched in writeback_sb_inodes") in function 'writeback_sb_inodes()' seldom comes true, unless cond_resched() is deleted from write_cache_pages(). Fix it by correcting wrote number according number of skipped pages in writeback_sb_inodes(). Goto Link to find a reproducer. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215837 Cc: stable@vger.kernel.org # v4.3 Signed-off-by: Zhihao Cheng Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220510133805.1988292-1-chengzhihao1@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 87737ee52963ad56f70e739d3ac25b7865db191b Author: Emmanuel Grumbach Date: Tue May 17 12:05:09 2022 +0300 iwlwifi: mvm: fix assert 1F04 upon reconfig commit 9d096e3d3061dbf4ee10e2b59fc2c06e05bdb997 upstream. When we reconfig we must not send the MAC_POWER command that relates to a MAC that was not yet added to the firmware. Ignore those in the iterator. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach Signed-off-by: Gregory Greenman Link: https://lore.kernel.org/r/20220517120044.ed2ffc8ce732.If786e19512d0da4334a6382ea6148703422c7d7b@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit b79110f2bf6022e60e590d2e094728a8eec3e79e Author: Johannes Berg Date: Wed Jun 1 09:19:36 2022 +0200 wifi: mac80211: fix use-after-free in chanctx code commit 2965c4cdf7ad9ce0796fac5e57debb9519ea721e upstream. In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx. Cc: stable@vger.kernel.org Fixes: 5bcae31d9cb1 ("mac80211: implement multi-vif in-place reservations") Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220601091926.df419d91b165.I17a9b3894ff0b8323ce2afdb153b101124c821e5@changeid Signed-off-by: Greg Kroah-Hartman commit 4a6ca6f8a3a0600fda8bc26f7aff89369610cb05 Author: Peter Zijlstra Date: Tue May 17 17:42:04 2022 +0200 objtool: Fix symbol creation commit ead165fa1042247b033afad7be4be9b815d04ade upstream. Nathan reported objtool failing with the following messages: warning: objtool: no non-local symbols !? warning: objtool: gelf_update_symshndx: invalid section index The problem is due to commit 4abff6d48dbc ("objtool: Fix code relocs vs weak symbols") failing to consider the case where an object would have no non-local symbols. The problem that commit tries to address is adding a STB_LOCAL symbol to the symbol table in light of the ELF spec's requirement that: In each symbol table, all symbols with STB_LOCAL binding preced the weak and global symbols. As ``Sections'' above describes, a symbol table section's sh_info section header member holds the symbol table index for the first non-local symbol. The approach taken is to find this first non-local symbol, move that to the end and then re-use the freed spot to insert a new local symbol and increment sh_info. Except it never considered the case of object files without global symbols and got a whole bunch of details wrong -- so many in fact that it is a wonder it ever worked :/ Specifically: - It failed to re-hash the symbol on the new index, so a subsequent find_symbol_by_index() would not find it at the new location and a query for the old location would now return a non-deterministic choice between the old and new symbol. - It failed to appreciate that the GElf wrappers are not a valid disk format (it works because GElf is basically Elf64 and we only support x86_64 atm.) - It failed to fully appreciate how horrible the libelf API really is and got the gelf_update_symshndx() call pretty much completely wrong; with the direct consequence that if inserting a second STB_LOCAL symbol would require moving the same STB_GLOBAL symbol again it would completely come unstuck. Write a new elf_update_symbol() function that wraps all the magic required to update or create a new symbol at a given index. Specifically, gelf_update_sym*() require an @ndx argument that is relative to the @data argument; this means you have to manually iterate the section data descriptor list and update @ndx. Fixes: 4abff6d48dbc ("objtool: Fix code relocs vs weak symbols") Reported-by: Nathan Chancellor Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Acked-by: Josh Poimboeuf Tested-by: Nathan Chancellor Cc: Link: https://lkml.kernel.org/r/YoPCTEYjoPqE4ZxB@hirez.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman commit c49238245dd90e0713229d683ffae9540cd47328 Author: Mikulas Patocka Date: Mon May 16 11:06:36 2022 -0400 objtool: Fix objtool regression on x32 systems commit 22682a07acc308ef78681572e19502ce8893c4d4 upstream. Commit c087c6e7b551 ("objtool: Fix type of reloc::addend") failed to appreciate cross building from ILP32 hosts, where 'int' == 'long' and the issue persists. As such, use s64/int64_t/Elf64_Sxword for this field and suffer the pain that is ISO C99 printf formats for it. Fixes: c087c6e7b551 ("objtool: Fix type of reloc::addend") Signed-off-by: Mikulas Patocka [peterz: reword changelog, s/long long/s64/] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/alpine.LRH.2.02.2205161041260.11556@file01.intranet.prod.int.rdu2.redhat.com Signed-off-by: Greg Kroah-Hartman commit 7cfe2d43becaf76e562b9617d2c2d9b445f86761 Author: Chao Yu Date: Wed May 18 20:28:41 2022 +0800 f2fs: fix to do sanity check for inline inode commit 677a82b44ebf263d4f9a0cfbd576a6ade797a07b upstream. Yanming reported a kernel bug in Bugzilla kernel [1], which can be reproduced. The bug message is: The kernel message is shown below: kernel BUG at fs/inode.c:611! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 dput+0x2dd/0x720 do_renameat2+0x596/0x970 __x64_sys_rename+0x78/0x90 do_syscall_64+0x3b/0x90 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895 The bug is due to fuzzed inode has both inline_data and encrypted flags. During f2fs_evict_inode(), as the inode was deleted by rename(), it will cause inline data conversion due to conflicting flags. The page cache will be polluted and the panic will be triggered in clear_inode(). Try fixing the bug by doing more sanity checks for inline data inode in sanity_check_inode(). Cc: stable@vger.kernel.org Reported-by: Ming Yan Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 59f42b4150022f216a4e92bbf672ef2bc9c413c8 Author: Chao Yu Date: Tue May 17 11:37:23 2022 +0800 f2fs: fix fallocate to use file_modified to update permissions consistently commit 958ed92922028ec67f504dcdc72bfdfd0f43936a upstream. This patch tries to fix permission consistency issue as all other mainline filesystems. Since the initial introduction of (posix) fallocate back at the turn of the century, it has been possible to use this syscall to change the user-visible contents of files. This can happen by extending the file size during a preallocation, or through any of the newer modes (punch, zero, collapse, insert range). Because the call can be used to change file contents, we should treat it like we do any other modification to a file -- update the mtime, and drop set[ug]id privileges/capabilities. The VFS function file_modified() does all this for us if pass it a locked inode, so let's make fallocate drop permissions correctly. Cc: stable@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 6bde47f4e81344f43514408f8ba799e8c2b090e8 Author: Eric Biggers Date: Sat May 14 10:59:29 2022 -0700 f2fs: don't use casefolded comparison for "." and ".." commit b5639bb4313b9d455fc9fc4768d23a5e4ca8cb9d upstream. Tryng to rename a directory that has all following properties fails with EINVAL and triggers the 'WARN_ON_ONCE(!fscrypt_has_encryption_key(dir))' in f2fs_match_ci_name(): - The directory is casefolded - The directory is encrypted - The directory's encryption key is not yet set up - The parent directory is *not* encrypted The problem is incorrect handling of the lookup of ".." to get the parent reference to update. fscrypt_setup_filename() treats ".." (and ".") specially, as it's never encrypted. It's passed through as-is, and setting up the directory's key is not attempted. As the name isn't a no-key name, f2fs treats it as a "normal" name and attempts a casefolded comparison. That breaks the assumption of the WARN_ON_ONCE() in f2fs_match_ci_name() which assumes that for encrypted directories, casefolded comparisons only happen when the directory's key is set up. We could just remove this WARN_ON_ONCE(). However, since casefolding is always a no-op on "." and ".." anyway, let's instead just not casefold these names. This results in the standard bytewise comparison. Fixes: 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption") Cc: # v5.11+ Signed-off-by: Eric Biggers Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit c9e4cd5b0ccd7168801d6a811919171b185c5cf8 Author: Chao Yu Date: Fri May 6 09:33:06 2022 +0800 f2fs: fix to do sanity check on total_data_blocks commit 6b8beca0edd32075a769bfe4178ca00c0dcd22a9 upstream. As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215916 The kernel message is shown below: kernel BUG at fs/f2fs/segment.c:2560! Call Trace: allocate_segment_by_default+0x228/0x440 f2fs_allocate_data_block+0x13d1/0x31f0 do_write_page+0x18d/0x710 f2fs_outplace_write_data+0x151/0x250 f2fs_do_write_data_page+0xef9/0x1980 move_data_page+0x6af/0xbc0 do_garbage_collect+0x312f/0x46f0 f2fs_gc+0x6b0/0x3bc0 f2fs_balance_fs+0x921/0x2260 f2fs_write_single_data_page+0x16be/0x2370 f2fs_write_cache_pages+0x428/0xd00 f2fs_write_data_pages+0x96e/0xd50 do_writepages+0x168/0x550 __writeback_single_inode+0x9f/0x870 writeback_sb_inodes+0x47d/0xb20 __writeback_inodes_wb+0xb2/0x200 wb_writeback+0x4bd/0x660 wb_workfn+0x5f3/0xab0 process_one_work+0x79f/0x13e0 worker_thread+0x89/0xf60 kthread+0x26a/0x300 ret_from_fork+0x22/0x30 RIP: 0010:new_curseg+0xe8d/0x15f0 The root cause is: ckpt.valid_block_count is inconsistent with SIT table, stat info indicates filesystem has free blocks, but SIT table indicates filesystem has no free segment. So that during garbage colloection, it triggers panic when LFS allocator fails to find free segment. This patch tries to fix this issue by checking consistency in between ckpt.valid_block_count and block accounted from SIT. Cc: stable@vger.kernel.org Reported-by: Ming Yan Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 01572a3cb59f1b769d0a23d03e10fc748f7e6980 Author: Jaegeuk Kim Date: Thu May 5 17:40:25 2022 -0700 f2fs: don't need inode lock for system hidden quota commit 6213f5d4d23c50d393a31dc8e351e63a1fd10dbe upstream. Let's avoid false-alarmed lockdep warning. [ 58.914674] [T1501146] -> #2 (&sb->s_type->i_mutex_key#20){+.+.}-{3:3}: [ 58.915975] [T1501146] system_server: down_write+0x7c/0xe0 [ 58.916738] [T1501146] system_server: f2fs_quota_sync+0x60/0x1a8 [ 58.917563] [T1501146] system_server: block_operations+0x16c/0x43c [ 58.918410] [T1501146] system_server: f2fs_write_checkpoint+0x114/0x318 [ 58.919312] [T1501146] system_server: f2fs_issue_checkpoint+0x178/0x21c [ 58.920214] [T1501146] system_server: f2fs_sync_fs+0x48/0x6c [ 58.920999] [T1501146] system_server: f2fs_do_sync_file+0x334/0x738 [ 58.921862] [T1501146] system_server: f2fs_sync_file+0x30/0x48 [ 58.922667] [T1501146] system_server: __arm64_sys_fsync+0x84/0xf8 [ 58.923506] [T1501146] system_server: el0_svc_common.llvm.12821150825140585682+0xd8/0x20c [ 58.924604] [T1501146] system_server: do_el0_svc+0x28/0xa0 [ 58.925366] [T1501146] system_server: el0_svc+0x24/0x38 [ 58.926094] [T1501146] system_server: el0_sync_handler+0x88/0xec [ 58.926920] [T1501146] system_server: el0_sync+0x1b4/0x1c0 [ 58.927681] [T1501146] -> #1 (&sbi->cp_global_sem){+.+.}-{3:3}: [ 58.928889] [T1501146] system_server: down_write+0x7c/0xe0 [ 58.929650] [T1501146] system_server: f2fs_write_checkpoint+0xbc/0x318 [ 58.930541] [T1501146] system_server: f2fs_issue_checkpoint+0x178/0x21c [ 58.931443] [T1501146] system_server: f2fs_sync_fs+0x48/0x6c [ 58.932226] [T1501146] system_server: sync_filesystem+0xac/0x130 [ 58.933053] [T1501146] system_server: generic_shutdown_super+0x38/0x150 [ 58.933958] [T1501146] system_server: kill_block_super+0x24/0x58 [ 58.934791] [T1501146] system_server: kill_f2fs_super+0xcc/0x124 [ 58.935618] [T1501146] system_server: deactivate_locked_super+0x90/0x120 [ 58.936529] [T1501146] system_server: deactivate_super+0x74/0xac [ 58.937356] [T1501146] system_server: cleanup_mnt+0x128/0x168 [ 58.938150] [T1501146] system_server: __cleanup_mnt+0x18/0x28 [ 58.938944] [T1501146] system_server: task_work_run+0xb8/0x14c [ 58.939749] [T1501146] system_server: do_notify_resume+0x114/0x1e8 [ 58.940595] [T1501146] system_server: work_pending+0xc/0x5f0 [ 58.941375] [T1501146] -> #0 (&sbi->gc_lock){+.+.}-{3:3}: [ 58.942519] [T1501146] system_server: __lock_acquire+0x1270/0x2868 [ 58.943366] [T1501146] system_server: lock_acquire+0x114/0x294 [ 58.944169] [T1501146] system_server: down_write+0x7c/0xe0 [ 58.944930] [T1501146] system_server: f2fs_issue_checkpoint+0x13c/0x21c [ 58.945831] [T1501146] system_server: f2fs_sync_fs+0x48/0x6c [ 58.946614] [T1501146] system_server: f2fs_do_sync_file+0x334/0x738 [ 58.947472] [T1501146] system_server: f2fs_ioc_commit_atomic_write+0xc8/0x14c [ 58.948439] [T1501146] system_server: __f2fs_ioctl+0x674/0x154c [ 58.949253] [T1501146] system_server: f2fs_ioctl+0x54/0x88 [ 58.950018] [T1501146] system_server: __arm64_sys_ioctl+0xa8/0x110 [ 58.950865] [T1501146] system_server: el0_svc_common.llvm.12821150825140585682+0xd8/0x20c [ 58.951965] [T1501146] system_server: do_el0_svc+0x28/0xa0 [ 58.952727] [T1501146] system_server: el0_svc+0x24/0x38 [ 58.953454] [T1501146] system_server: el0_sync_handler+0x88/0xec [ 58.954279] [T1501146] system_server: el0_sync+0x1b4/0x1c0 Cc: stable@vger.kernel.org Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 7fc40280103f14d935a6417d86103144a2aa2e85 Author: Chao Yu Date: Wed May 4 14:09:22 2022 +0800 f2fs: fix deadloop in foreground GC commit cfd66bb715fd11fde3338d0660cffa1396adc27d upstream. As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215914 The root cause is: in a very small sized image, it's very easy to exceed threshold of foreground GC, if we calculate free space and dirty data based on section granularity, in corner case, has_not_enough_free_secs() will always return true, result in deadloop in f2fs_gc(). So this patch refactors has_not_enough_free_secs() as below to fix this issue: 1. calculate needed space based on block granularity, and separate all blocks to two parts, section part, and block part, comparing section part to free section, and comparing block part to free space in openned log. 2. account F2FS_DIRTY_NODES, F2FS_DIRTY_IMETA and F2FS_DIRTY_DENTS as node block consumer; 3. account F2FS_DIRTY_DENTS as data block consumer; Cc: stable@vger.kernel.org Reported-by: Ming Yan Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit c9196d21359be8c7ee231029d13682273925fd00 Author: Chao Yu Date: Sat Apr 30 21:19:24 2022 +0800 f2fs: fix to clear dirty inode in f2fs_evict_inode() commit f2db71053dc0409fae785096ad19cce4c8a95af7 upstream. As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215904 The kernel message is shown below: kernel BUG at fs/f2fs/inode.c:825! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 shrink_dentry_list+0x17c/0x4f0 shrink_dcache_parent+0x143/0x1e0 do_one_tree+0x9/0x30 shrink_dcache_for_umount+0x51/0x120 generic_shutdown_super+0x5c/0x3a0 kill_block_super+0x90/0xd0 kill_f2fs_super+0x225/0x310 deactivate_locked_super+0x78/0xc0 cleanup_mnt+0x2b7/0x480 task_work_run+0xc8/0x150 exit_to_user_mode_prepare+0x14a/0x150 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 The root cause is: inode node and dnode node share the same nid, so during f2fs_evict_inode(), dnode node truncation will invalidate its NAT entry, so when truncating inode node, it fails due to invalid NAT entry, result in inode is still marked as dirty, fix this issue by clearing dirty for inode and setting SBI_NEED_FSCK flag in filesystem. output from dump.f2fs: [print_node_info: 354] Node ID [0xf:15] is inode i_nid[0] [0x f : 15] Cc: stable@vger.kernel.org Reported-by: Ming Yan Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit f2e1c38b5ac64eb1a16a89c52fb419409d12c25b Author: Chao Yu Date: Wed Apr 27 17:51:40 2022 +0800 f2fs: fix to do sanity check on block address in f2fs_do_zero_range() commit 25f8236213a91efdf708b9d77e9e51b6fc3e141c upstream. As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215894 I have encountered a bug in F2FS file system in kernel v5.17. I have uploaded the system call sequence as case.c, and a fuzzed image can be found in google net disk The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can reproduce the bug by running the following commands: kernel BUG at fs/f2fs/segment.c:2291! Call Trace: f2fs_invalidate_blocks+0x193/0x2d0 f2fs_fallocate+0x2593/0x4a70 vfs_fallocate+0x2a5/0xac0 ksys_fallocate+0x35/0x70 __x64_sys_fallocate+0x8e/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is, after image was fuzzed, block mapping info in inode will be inconsistent with SIT table, so in f2fs_fallocate(), it will cause panic when updating SIT with invalid blkaddr. Let's fix the issue by adding sanity check on block address before updating SIT table with it. Cc: stable@vger.kernel.org Reported-by: Ming Yan Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit bce859358d3d5940aa858e40ceee70ee6e76130e Author: Chao Yu Date: Wed Apr 27 01:06:02 2022 +0800 f2fs: fix to avoid f2fs_bug_on() in dec_valid_node_count() commit 4d17e6fe9293d57081ffdc11e1cf313e25e8fd9e upstream. As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215897 I have encountered a bug in F2FS file system in kernel v5.17. The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can reproduce the bug by running the following commands: The kernel message is shown below: kernel BUG at fs/f2fs/f2fs.h:2511! Call Trace: f2fs_remove_inode_page+0x2a2/0x830 f2fs_evict_inode+0x9b7/0x1510 evict+0x282/0x4e0 do_unlinkat+0x33a/0x540 __x64_sys_unlinkat+0x8e/0xd0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is: .total_valid_block_count or .total_valid_node_count could fuzzed to zero, then once dec_valid_node_count() was called, it will cause BUG_ON(), this patch fixes to print warning info and set SBI_NEED_FSCK into CP instead of panic. Cc: stable@vger.kernel.org Reported-by: Ming Yan Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 54c408800f3ff847762999569b122c220c258311 Author: Olga Kornievskaia Date: Wed May 25 12:12:59 2022 -0400 NFSv4.1 mark qualified async operations as MOVEABLE tasks [ Upstream commit 118f09eda21d392e1eeb9f8a4bee044958cccf20 ] Mark async operations such as RENAME, REMOVE, COMMIT MOVEABLE for the nfsv4.1+ sessions. Fixes: 85e39feead948 ("NFSv4.1 identify and mark RPC tasks that can move between transports") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit c5665c29dd41ea831191437ad0139f7c4193bf81 Author: Trond Myklebust Date: Sat Jan 29 13:57:38 2022 -0500 NFS: Convert GFP_NOFS to GFP_KERNEL [ Upstream commit da48f267f90d9dc9f930fd9a67753643657b404f ] Assume that sections that should not re-enter the filesystem are already protected with memalloc_nofs_save/restore call, so relax those GFP_NOFS instances which might be used by other contexts. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 29b51ae02df50647ff90b3b2a6c8e28f99d52abc Author: Anna Schumaker Date: Fri Oct 22 13:11:00 2021 -0400 NFS: Create a new nfs_alloc_fattr_with_label() function [ Upstream commit d755ad8dc752d44545613ea04d660aed674e540d ] For creating fattrs with the label field already allocated for us. I also update nfs_free_fattr() to free the label in the end. Signed-off-by: Anna Schumaker Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 00fa80189c979f7aa0d4927852879e20da60b231 Author: Trond Myklebust Date: Thu Nov 4 18:03:26 2021 -0400 NFS: Always initialise fattr->label in nfs_fattr_alloc() [ Upstream commit d4a95a7e5a4d3b68b26f70668cf77324a11b5718 ] We're about to add a check in nfs_free_fattr() for whether or not the label is non-zero. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 0fac5f8fb1bc2fc4f8714bf5e743c9cc3f547c63 Author: Javier Martinez Canillas Date: Thu May 26 21:47:52 2022 +0200 video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup [ Upstream commit acde4003efc16480375543638484d8f13f2e99a3 ] Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove") fixed a use-after-free error due the vesafb driver freeing the fb_info in the .remove handler instead of doing it in .fb_destroy. This can happen if the .fb_destroy callback is executed after the .remove callback, since the former tries to access a pointer freed by the latter. But that change didn't take into account that another possible scenario is that .fb_destroy is called before the .remove callback. For example, if no process has the fbdev chardev opened by the time the driver is removed. If that's the case, fb_info will be freed when unregister_framebuffer() is called, making the fb_info pointer accessed in vesafb_remove() after that to no longer be valid. To prevent that, move the expression containing the info->par to happen before the unregister_framebuffer() function call. Fixes: b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove") Reported-by: Pascal Ernster Signed-off-by: Javier Martinez Canillas Tested-by: Pascal Ernster Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 7654c4563501fefca76cdd5a0986023feb78ce7c Author: Zhengjun Xing Date: Wed May 25 22:04:10 2022 +0800 perf jevents: Fix event syntax error caused by ExtSel [ Upstream commit f4df0dbbe62ee8e4405a57b27ccd54393971c773 ] In the origin code, when "ExtSel" is 1, the eventcode will change to "eventcode |= 1 << 21”. For event “UNC_Q_RxL_CREDITS_CONSUMED_VN0.DRS", its "ExtSel" is "1", its eventcode will change from 0x1E to 0x20001E, but in fact the eventcode should <=0x1FF, so this will cause the parse fail: # perf stat -e "UNC_Q_RxL_CREDITS_CONSUMED_VN0.DRS" -a sleep 0.1 event syntax error: '.._RxL_CREDITS_CONSUMED_VN0.DRS' \___ value too big for format, maximum is 511 On the perf kernel side, the kernel assumes the valid bits are continuous. It will adjust the 0x100 (bit 8 for perf tool) to bit 21 in HW. DEFINE_UNCORE_FORMAT_ATTR(event_ext, event, "config:0-7,21"); So the perf tool follows the kernel side and just set bit8 other than bit21. Fixes: fedb2b518239cbc0 ("perf jevents: Add support for parsing uncore json files") Reviewed-by: Kan Liang Signed-off-by: Xing Zhengjun Acked-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Jiri Olsa Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20220525140410.1706851-1-zhengjun.xing@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 590df0a151d36b6deedcbc982dfcb0665355d19c Author: Leo Yan Date: Thu May 26 22:54:00 2022 +0800 perf c2c: Use stdio interface if slang is not supported [ Upstream commit c4040212bc97d16040712a410335f93bc94d2262 ] If the slang lib is not installed on the system, perf c2c tool disables TUI mode and roll back to use stdio mode; but the flag 'c2c.use_stdio' is missed to set true and thus it wrongly applies UI quirks in the function ui_quirks(). This commit forces to use stdio interface if slang is not supported, and it can avoid to apply the UI quirks and show the correct metric header. Before: ================================================= Shared Cache Line Distribution Pareto ================================================= ------------------------------------------------------------------------------- 0 0 0 99 0 0 0 0xaaaac17d6000 ------------------------------------------------------------------------------- 0.00% 0.00% 6.06% 0.00% 0.00% 0.00% 0x20 N/A 0 0xaaaac17c25ac 0 0 43 375 18469 2 [.] 0x00000000000025ac memstress memstress[25ac] 0 0.00% 0.00% 93.94% 0.00% 0.00% 0.00% 0x29 N/A 0 0xaaaac17c3e88 0 0 173 180 135 2 [.] 0x0000000000003e88 memstress memstress[3e88] 0 After: ================================================= Shared Cache Line Distribution Pareto ================================================= ------------------------------------------------------------------------------- 0 0 0 99 0 0 0 0xaaaac17d6000 ------------------------------------------------------------------------------- 0.00% 0.00% 6.06% 0.00% 0.00% 0.00% 0x20 N/A 0 0xaaaac17c25ac 0 0 43 375 18469 2 [.] 0x00000000000025ac memstress memstress[25ac] 0 0.00% 0.00% 93.94% 0.00% 0.00% 0.00% 0x29 N/A 0 0xaaaac17c3e88 0 0 173 180 135 2 [.] 0x0000000000003e88 memstress memstress[3e88] 0 Fixes: 5a1a99cd2e4e1557 ("perf c2c report: Add main TUI browser") Reported-by: Joe Mario Signed-off-by: Leo Yan Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20220526145400.611249-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 06e4fa5a5cbf7d1db3d4181bec0d318741f6486e Author: Jiri Olsa Date: Tue May 24 14:06:12 2022 +0200 perf build: Fix btf__load_from_kernel_by_id() feature check [ Upstream commit 73534617dfa3c4cd95fe5ffaeff5315e9ffc2de6 ] The btf__load_from_kernel_by_id() only takes one arg, not two. Committer notes: I tested it just with an older libbpf, one where btf__load_from_kernel_by_id() wasn't introduced yet. A test with a newer dynamic libbpf would fail because the btf__load_from_kernel_by_id() is there, but takes just one arg. Fixes: 0ae065a5d265bc5a ("perf build: Fix check for btf__load_from_kernel_by_id() in libbpf") Signed-off-by: Jiri Olsa Cc: Heiko Carstens Cc: Ian Rogers Cc: Ilya Leoshkevich Cc: Sumanth Korikkar Cc: Sven Schnelle Cc: Thomas Richter Cc: Vasily Gorbik Link: http://lore.kernel.org/linux-perf-users/YozLKby7ITEtchC9@krava Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b52e192ffda823a7d224623aa01ebd4d306cbf85 Author: Kuninori Morimoto Date: Fri May 20 11:54:21 2022 +0200 i2c: rcar: fix PM ref counts in probe error paths [ Upstream commit 3fe2ec59db1a7569e18594b9c0cf1f4f1afd498e ] We have to take care of ID_P_PM_BLOCKED when bailing out during probe. Fixes: 7ee24eb508d6 ("i2c: rcar: disable PM in multi-master mode") Signed-off-by: Kuninori Morimoto Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit c06cfe582f42eb5f827e3f0b4b61c99879260e93 Author: Tali Perry Date: Tue May 17 18:11:39 2022 +0800 i2c: npcm: Handle spurious interrupts [ Upstream commit e5222d408de2a88e6b206c38217b48d092184553 ] On some platforms in rare cases (1 to 100,000 transactions), the i2c gets a spurious interrupt which means that we enter an interrupt but in the interrupt handler we don't find any status bit that points to the reason we got this interrupt. This may be a case of a rare HW issue or signal integrity issue that is still under investigation. In order to overcome this we are doing the following: 1. Disable incoming interrupts in master mode only when slave mode is not enabled. 2. Clear end of busy (EOB) after every interrupt. 3. Clear other status bits (just in case since we found them cleared) 4. Return correct status during the interrupt that will finish the transaction. On next xmit transaction if the bus is still busy the master will issue a recovery process before issuing the new transaction. Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver") Signed-off-by: Tali Perry Signed-off-by: Tyrone Ting Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 708c34bc723d563f8e23b4397d2cf3c1b1ea926e Author: Tyrone Ting Date: Tue May 17 18:11:38 2022 +0800 i2c: npcm: Correct register access width [ Upstream commit ea9f8426d17620214ee345ffb77ee6cc196ff14f ] The SMBnCTL3 register is 8-bit wide and the 32-bit access was always incorrect, but simply didn't cause a visible error on the 32-bit machine. On the 64-bit machine, the kernel message reports that ESR value is 0x96000021. Checking Arm Architecture Reference Manual Armv8 suggests that it's the alignment fault. SMBnCTL3's address is 0xE. Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver") Signed-off-by: Tyrone Ting Reviewed-by: Jonathan Neuschäfer Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 84721299cb9fbfe2c7e0b71716d5ee33a84e1cee Author: Tali Perry Date: Tue May 17 18:11:36 2022 +0800 i2c: npcm: Fix timeout calculation [ Upstream commit 288b204492fddf28889cea6dc95a23976632c7a0 ] Use adap.timeout for timeout calculation instead of hard-coded value of 35ms. Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver") Signed-off-by: Tali Perry Signed-off-by: Tyrone Ting Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7e4bfd3b9a598866feff1e8e7437e988a3242f63 Author: Joerg Roedel Date: Fri May 20 12:22:14 2022 +0200 iommu/amd: Increase timeout waiting for GA log enablement [ Upstream commit 42bb5aa043382f09bef2cc33b8431be867c70f8e ] On some systems it can take a long time for the hardware to enable the GA log of the AMD IOMMU. The current wait time is only 0.1ms, but testing showed that it can take up to 14ms for the GA log to enter running state after it has been enabled. Sometimes the long delay happens when booting the system, sometimes only on resume. Adjust the timeout accordingly to not print a warning when hardware takes a longer than usual. There has already been an attempt to fix this with commit 9b45a7738eec ("iommu/amd: Fix loop timeout issue in iommu_ga_log_enable()") But that commit was based on some wrong math and did not fix the issue in all cases. Cc: "D. Ziegfeld" Cc: Jörg-Volker Peetz Fixes: 8bda0cfbdc1a ("iommu/amd: Detect and initialize guest vAPIC log") Signed-off-by: Joerg Roedel Link: https://lore.kernel.org/r/20220520102214.12563-1-joro@8bytes.org Signed-off-by: Sasha Levin commit 85c2d1bb73dea16fd21b50742d79649e1c421692 Author: Amelie Delaunay Date: Wed May 4 17:53:21 2022 +0200 dmaengine: stm32-mdma: fix chan initialization in stm32_mdma_irq_handler() [ Upstream commit da3b8ddb464bd49b6248d00ca888ad751c9e44fd ] The parameter to pass back to the handler function when irq has been requested is a struct stm32_mdma_device pointer, not a struct stm32_mdma_chan pointer. Even if chan is reinit later in the function, remove this wrong initialization. Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver") Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20220504155322.121431-3-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 33b5d6add852bfaaa0c19433f1ee315d3cbf0551 Author: Amelie Delaunay Date: Wed May 4 17:53:20 2022 +0200 dmaengine: stm32-mdma: remove GISR1 register [ Upstream commit 9d6a2d92e450926c483e45eaf426080a19219f4e ] GISR1 was described in a not up-to-date documentation when the stm32-mdma driver has been developed. This register has not been added in reference manual of STM32 SoC with MDMA, which have only 32 MDMA channels. So remove it from stm32-mdma driver. Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver") Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20220504155322.121431-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f2dfb4ab887d67be7d0892ba041d3c8d738d3356 Author: Miaoqian Lin Date: Thu May 12 15:59:08 2022 +0400 video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup [ Upstream commit b23789a59fa6f00e98a319291819f91fbba0deb8 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: d10715be03bd ("video: ARM CLCD: Add DT support") Signed-off-by: Miaoqian Lin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 08b9d374c84a81ab88e4be6c30748681608ed707 Author: Trond Myklebust Date: Sat May 14 10:08:12 2022 -0400 NFS: Further fixes to the writeback error handling [ Upstream commit c6fd3511c3397dd9cbc6dc5d105bbedb69bf4061 ] When we handle an error by redirtying the page, we're not corrupting the mapping, so we don't want the error to be recorded in the mapping. If the caller has specified a sync_mode of WB_SYNC_NONE, we can just return AOP_WRITEPAGE_ACTIVATE. However if we're dealing with WB_SYNC_ALL, we need to ensure that retries happen when the errors are non-fatal. Reported-by: Olga Kornievskaia Fixes: 8fc75bed96bb ("NFS: Fix up return value on fatal errors in nfs_page_async_flush()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit eaf407d5b5fe6a829f60357038f99c38e2986dcb Author: Trond Myklebust Date: Sat May 14 10:08:11 2022 -0400 NFSv4/pNFS: Do not fail I/O when we fail to allocate the pNFS layout [ Upstream commit 3764a17e31d579cf9b4bd0a69894b577e8d75702 ] Commit 587f03deb69b caused pnfs_update_layout() to stop returning ENOMEM when the memory allocation fails, and hence causes it to fall back to trying to do I/O through the MDS. There is no guarantee that this will fare any better. If we're failing the pNFS layout allocation, then we should just redirty the page and retry later. Reported-by: Olga Kornievskaia Fixes: 587f03deb69b ("pnfs: refactor send_layoutget") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 471577e926ebc9cf4d661fde7558f4910a53273f Author: Trond Myklebust Date: Sat May 14 10:27:04 2022 -0400 NFS: Don't report errors from nfs_pageio_complete() more than once [ Upstream commit c5e483b77cc2edb318da152abe07e33006b975fd ] Since errors from nfs_pageio_complete() are already being reported through nfs_async_write_error(), we should not be returning them to the callers of do_writepages() as well. They will end up being reported through the generic mechanism instead. Fixes: 6fbda89b257f ("NFS: Replace custom error reporting mechanism with generic one") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit a3bbd8b1aa4ccbf19c0ff7b07e7ebe457cbf2094 Author: Trond Myklebust Date: Sat May 14 10:27:03 2022 -0400 NFS: Do not report flush errors in nfs_write_end() [ Upstream commit d95b26650e86175e4a97698d89bc1626cd1df0c6 ] If we do flush cached writebacks in nfs_write_end() due to the imminent expiration of an RPCSEC_GSS session, then we should defer reporting any resulting errors until the calls to file_check_and_advance_wb_err() in nfs_file_write() and nfs_file_fsync(). Fixes: 6fbda89b257f ("NFS: Replace custom error reporting mechanism with generic one") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 3a2d62ec419bf38ed63a9753c854bee3f068829c Author: Trond Myklebust Date: Sat May 14 10:27:02 2022 -0400 NFS: Don't report ENOSPC write errors twice [ Upstream commit e6005436f6cc9ed13288f936903f0151e5543485 ] Any errors reported by the write() system call need to be cleared from the file descriptor's error tracking. The current call to nfs_wb_all() causes the error to be reported, but since it doesn't call file_check_and_advance_wb_err(), we can end up reporting the same error a second time when the application calls fsync(). Note that since Linux 4.13, the rule is that EIO may be reported for write(), but it must be reported by a subsequent fsync(), so let's just drop reporting it in write. The check for nfs_ctx_key_to_expire() is just a duplicate to the one already in nfs_write_end(), so let's drop that too. Reported-by: ChenXiaoSong Fixes: ce368536dd61 ("nfs: nfs_file_write() should check for writeback errors") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 0d548c0c7082f08f5d7dbab8da0a7475ce8c5099 Author: Trond Myklebust Date: Sat May 14 10:27:01 2022 -0400 NFS: fsync() should report filesystem errors over EINTR/ERESTARTSYS [ Upstream commit 9641d9bc9b75f11f70646f5c6ee9f5f519a1012e ] If the commit to disk is interrupted, we should still first check for filesystem errors so that we can report them in preference to the error due to the signal. Fixes: 2197e9b06c22 ("NFS: Fix up fsync() when the server rebooted") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 79e0b7436bc4673ac8e6868bab681450e7d57cec Author: Trond Myklebust Date: Sat May 14 10:27:00 2022 -0400 NFS: Do not report EINTR/ERESTARTSYS as mapping errors [ Upstream commit cea9ba7239dcc84175041174304c6cdeae3226e5 ] If the attempt to flush data was interrupted due to a local signal, then just requeue the writes back for I/O. Fixes: 6fbda89b257f ("NFS: Replace custom error reporting mechanism with generic one") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit b3c7b5d08e9d5b2ff31c03078c00ecf11042419f Author: Christophe JAILLET Date: Thu Apr 21 08:13:38 2022 +0200 dmaengine: idxd: Fix the error handling path in idxd_cdev_register() [ Upstream commit aab08c1aac01097815fbcf10fce7021d2396a31f ] If a call to alloc_chrdev_region() fails, the already allocated resources are leaking. Add the needed error handling path to fix the leak. Fixes: 42d279f9137a ("dmaengine: idxd: add char driver to expose submission portal to userland") Signed-off-by: Christophe JAILLET Acked-by: Dave Jiang Link: https://lore.kernel.org/r/1b5033dcc87b5f2a953c413f0306e883e6114542.1650521591.git.christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b9c9b4584b4b65fcf2d2d4d26ebfdca884bea525 Author: Nathan Chancellor Date: Thu May 5 08:27:38 2022 -0700 i2c: at91: Initialize dma_buf in at91_twi_xfer() [ Upstream commit 6977262c2eee111645668fe9e235ef2f5694abf7 ] Clang warns: drivers/i2c/busses/i2c-at91-master.c:707:6: warning: variable 'dma_buf' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (dev->use_dma) { ^~~~~~~~~~~~ drivers/i2c/busses/i2c-at91-master.c:717:27: note: uninitialized use occurs here i2c_put_dma_safe_msg_buf(dma_buf, m_start, !ret); ^~~~~~~ Initialize dma_buf to NULL, as i2c_put_dma_safe_msg_buf() is a no-op when the first argument is NULL, which will work for the !dev->use_dma case. Fixes: 03fbb903c8bf ("i2c: at91: use dma safe buffers") Link: https://github.com/ClangBuiltLinux/linux/issues/1629 Signed-off-by: Nathan Chancellor Reviewed-by: Michael Walle Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit c3c2734e28d7fac50228c4d2b8896e8695adf304 Author: Miles Chen Date: Thu May 5 21:27:30 2022 +0800 iommu/mediatek: Fix NULL pointer dereference when printing dev_name [ Upstream commit de78657e16f41417da9332f09c2d67d100096939 ] When larbdev is NULL (in the case I hit, the node is incorrectly set iommus = <&iommu NUM>), it will cause device_link_add() fail and kernel crashes when we try to print dev_name(larbdev). Let's fail the probe if a larbdev is NULL to avoid invalid inputs from dts. It should work for normal correct setting and avoid the crash caused by my incorrect setting. Error log: [ 18.189042][ T301] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 ... [ 18.344519][ T301] pstate: a0400005 (NzCv daif +PAN -UAO) [ 18.345213][ T301] pc : mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu] [ 18.346050][ T301] lr : mtk_iommu_probe_device+0xd0/0x118 [mtk_iommu] [ 18.346884][ T301] sp : ffffffc00a5635e0 [ 18.347392][ T301] x29: ffffffc00a5635e0 x28: ffffffd44a46c1d8 [ 18.348156][ T301] x27: ffffff80c39a8000 x26: ffffffd44a80cc38 [ 18.348917][ T301] x25: 0000000000000000 x24: ffffffd44a80cc38 [ 18.349677][ T301] x23: ffffffd44e4da4c6 x22: ffffffd44a80cc38 [ 18.350438][ T301] x21: ffffff80cecd1880 x20: 0000000000000000 [ 18.351198][ T301] x19: ffffff80c439f010 x18: ffffffc00a50d0c0 [ 18.351959][ T301] x17: ffffffffffffffff x16: 0000000000000004 [ 18.352719][ T301] x15: 0000000000000004 x14: ffffffd44eb5d420 [ 18.353480][ T301] x13: 0000000000000ad2 x12: 0000000000000003 [ 18.354241][ T301] x11: 00000000fffffad2 x10: c0000000fffffad2 [ 18.355003][ T301] x9 : a0d288d8d7142d00 x8 : a0d288d8d7142d00 [ 18.355763][ T301] x7 : ffffffd44c2bc640 x6 : 0000000000000000 [ 18.356524][ T301] x5 : 0000000000000080 x4 : 0000000000000001 [ 18.357284][ T301] x3 : 0000000000000000 x2 : 0000000000000005 [ 18.358045][ T301] x1 : 0000000000000000 x0 : 0000000000000000 [ 18.360208][ T301] Hardware name: MT6873 (DT) [ 18.360771][ T301] Call trace: [ 18.361168][ T301] dump_backtrace+0xf8/0x1f0 [ 18.361737][ T301] dump_stack_lvl+0xa8/0x11c [ 18.362305][ T301] dump_stack+0x1c/0x2c [ 18.362816][ T301] mrdump_common_die+0x184/0x40c [mrdump] [ 18.363575][ T301] ipanic_die+0x24/0x38 [mrdump] [ 18.364230][ T301] atomic_notifier_call_chain+0x128/0x2b8 [ 18.364937][ T301] die+0x16c/0x568 [ 18.365394][ T301] __do_kernel_fault+0x1e8/0x214 [ 18.365402][ T301] do_page_fault+0xb8/0x678 [ 18.366934][ T301] do_translation_fault+0x48/0x64 [ 18.368645][ T301] do_mem_abort+0x68/0x148 [ 18.368652][ T301] el1_abort+0x40/0x64 [ 18.368660][ T301] el1h_64_sync_handler+0x54/0x88 [ 18.368668][ T301] el1h_64_sync+0x68/0x6c [ 18.368673][ T301] mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu] ... Cc: Robin Murphy Cc: Yong Wu Reported-by: kernel test robot Fixes: 635319a4a744 ("media: iommu/mediatek: Add device_link between the consumer and the larb devices") Signed-off-by: Miles Chen Reviewed-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220505132731.21628-1-miles.chen@mediatek.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 646070b64836aea9227affd8064a7125402cda3b Author: Guenter Roeck Date: Wed May 11 07:56:59 2022 -0700 MIPS: Loongson: Use hwmon_device_register_with_groups() to register hwmon [ Upstream commit abae018a03821be2b65c01ebe2bef06fd7d85a4c ] Calling hwmon_device_register_with_info() with NULL dev and/or chip information parameters is an ABI abuse and not a real conversion to the new API. Also, the code creates sysfs attributes _after_ creating the hwmon device, which is racy and unsupported to start with. On top of that, the removal code tries to remove the name attribute which is owned by the hwmon core. Use hwmon_device_register_with_groups() to register the hwmon device instead. In the future, the hwmon subsystem will reject calls to hwmon_device_register_with_info with NULL dev or chip/info parameters. Without this patch, the hwmon device will fail to register. Fixes: f59dc5119192 ("MIPS: Loongson: Fix boot warning about hwmon_device_register()") Cc: Zhi Li Signed-off-by: Guenter Roeck Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit fc90f13ea0dcd960e5002d204fa55cec4e0db2fa Author: Jean-Philippe Brucker Date: Tue Apr 26 14:04:45 2022 +0100 iommu/arm-smmu-v3-sva: Fix mm use-after-free [ Upstream commit cbd23144f7662b00bcde32a938c4a4057e476d68 ] We currently call arm64_mm_context_put() without holding a reference to the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to ensure the mm only gets freed after we unpinned the ASID. Fixes: 32784a9562fb ("iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind()") Signed-off-by: Jean-Philippe Brucker Tested-by: Zhangfei Gao Link: https://lore.kernel.org/r/20220426130444.300556-1-jean-philippe@linaro.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2f124280f0aed93b6fadc64ccb51c670f088150d Author: Rex-BC Chen Date: Thu May 5 19:52:18 2022 +0800 cpufreq: mediatek: Unregister platform device on exit [ Upstream commit f126fbadce92b92c3a7be41e4abc1fbae93ae2ef ] We register the platform device when driver inits. However, we do not unregister it when driver exits. To resolve this, we declare the platform data to be a global static variable and rename it to be "cpufreq_pdev". With this global variable, we can do platform_device_unregister() when driver exits. Fixes: 501c574f4e3a ("cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC") Signed-off-by: Rex-BC Chen [ Viresh: Commit log and Subject ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 4477a67d0b568d8f8ab8f1e112d1e4dc4f97c053 Author: Jia-Wei Chang Date: Fri Apr 8 12:58:55 2022 +0800 cpufreq: mediatek: Use module_init and add module_exit [ Upstream commit b7070187c81cb90549d7561c0e750d7c7eb751f4 ] - Use module_init instead of device_initcall. - Add a function for module_exit to unregister driver. Signed-off-by: Jia-Wei Chang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 8d27c2186eeac351c08022e3580f1348fe09d7b5 Author: Michael Walle Date: Thu Apr 7 17:08:28 2022 +0200 i2c: at91: use dma safe buffers [ Upstream commit 03fbb903c8bf7e53e101e8d9a7b261264317c411 ] The supplied buffer might be on the stack and we get the following error message: [ 3.312058] at91_i2c e0070600.i2c: rejecting DMA map of vmalloc memory Use i2c_{get,put}_dma_safe_msg_buf() to get a DMA-able memory region if necessary. Fixes: 60937b2cdbf9 ("i2c: at91: add dma support") Signed-off-by: Michael Walle Reviewed-by: Codrin Ciubotariu Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 596f59d3369175142f967ae8bf76ed768b202888 Author: Yong Wu Date: Tue May 3 15:13:58 2022 +0800 iommu/mediatek: Add mutex for m4u_group and m4u_dom in data [ Upstream commit 0e5a3f2e630b28e88e018655548212ef8eb4dfcb ] Add a mutex to protect the data in the structure mtk_iommu_data, like ->"m4u_group" ->"m4u_dom". For the internal data, we should protect it in ourselves driver. Add a mutex for this. This could be a fix for the multi-groups support. Fixes: c3045f39244e ("iommu/mediatek: Support for multi domains") Signed-off-by: Yunfei Wang Signed-off-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/r/20220503071427.2285-8-yong.wu@mediatek.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 053465ab20dcd324a43a1811ee98e5721e6a3e65 Author: Yong Wu Date: Tue May 3 15:13:57 2022 +0800 iommu/mediatek: Remove clk_disable in mtk_iommu_remove [ Upstream commit 98df772bdd1c4ce717a26289efea15cbbe4b64ed ] After the commit b34ea31fe013 ("iommu/mediatek: Always enable the clk on resume"), the iommu clock is controlled by the runtime callback. thus remove the clk control in the mtk_iommu_remove. Otherwise, it will warning like: echo 14018000.iommu > /sys/bus/platform/drivers/mtk-iommu/unbind [ 51.413044] ------------[ cut here ]------------ [ 51.413648] vpp0_smi_iommu already disabled [ 51.414233] WARNING: CPU: 2 PID: 157 at */v5.15-rc1/kernel/mediatek/ drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8 [ 51.417174] Hardware name: MT8195V/C(ENG) (DT) [ 51.418635] pc : clk_core_disable+0xb0/0xb8 [ 51.419177] lr : clk_core_disable+0xb0/0xb8 ... [ 51.429375] Call trace: [ 51.429694] clk_core_disable+0xb0/0xb8 [ 51.430193] clk_core_disable_lock+0x24/0x40 [ 51.430745] clk_disable+0x20/0x30 [ 51.431189] mtk_iommu_remove+0x58/0x118 [ 51.431705] platform_remove+0x28/0x60 [ 51.432197] device_release_driver_internal+0x110/0x1f0 [ 51.432873] device_driver_detach+0x18/0x28 [ 51.433418] unbind_store+0xd4/0x108 [ 51.433886] drv_attr_store+0x24/0x38 [ 51.434363] sysfs_kf_write+0x40/0x58 [ 51.434843] kernfs_fop_write_iter+0x164/0x1e0 Fixes: b34ea31fe013 ("iommu/mediatek: Always enable the clk on resume") Reported-by: Hsin-Yi Wang Signed-off-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/r/20220503071427.2285-7-yong.wu@mediatek.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a216539403caa9cbfb7f1de6706248b399d8b514 Author: Yong Wu Date: Tue May 3 15:13:56 2022 +0800 iommu/mediatek: Add list_del in mtk_iommu_remove [ Upstream commit ee55f75e4bcade81d253163641b63bef3e76cac4 ] Lack the list_del in the mtk_iommu_remove, and remove bus_set_iommu(*, NULL) since there may be several iommu HWs. we can not bus_set_iommu null when one iommu driver unbind. This could be a fix for mt2712 which support 2 M4U HW and list them. Fixes: 7c3a2ec02806 ("iommu/mediatek: Merge 2 M4U HWs into one iommu domain") Signed-off-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/r/20220503071427.2285-6-yong.wu@mediatek.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit bf45d764616a02a1dd5bd019cd5e563204b264ff Author: Yong Wu Date: Tue May 3 15:13:55 2022 +0800 iommu/mediatek: Fix 2 HW sharing pgtable issue [ Upstream commit 645b87c190c959e9bb4f216b8c4add4ee880451a ] In the commit 4f956c97d26b ("iommu/mediatek: Move domain_finalise into attach_device"), I overlooked the sharing pgtable case. After that commit, the "data" in the mtk_iommu_domain_finalise always is the data of the current IOMMU HW. Fix this for the sharing pgtable case. Only affect mt2712 which is the only SoC that share pgtable currently. Fixes: 4f956c97d26b ("iommu/mediatek: Move domain_finalise into attach_device") Signed-off-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/r/20220503071427.2285-5-yong.wu@mediatek.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 9e53c25f326604c838d528b430b8e603944b9e28 Author: Mario Limonciello Date: Mon Apr 4 15:47:22 2022 -0500 iommu/amd: Enable swiotlb in all cases [ Upstream commit 121660bba631104154b7c15e88f208c48c8c3297 ] Previously the AMD IOMMU would only enable SWIOTLB in certain circumstances: * IOMMU in passthrough mode * SME enabled This logic however doesn't work when an untrusted device is plugged in that doesn't do page aligned DMA transactions. The expectation is that a bounce buffer is used for those transactions. This fails like this: swiotlb buffer is full (sz: 4096 bytes), total 0 (slots), used 0 (slots) That happens because the bounce buffers have been allocated, followed by freed during startup but the bounce buffering code expects that all IOMMUs have left it enabled. Remove the criteria to set up bounce buffers on AMD systems to ensure they're always available for supporting untrusted devices. Fixes: 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers") Suggested-by: Christoph Hellwig Signed-off-by: Mario Limonciello Reviewed-by: Robin Murphy Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220404204723.9767-2-mario.limonciello@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 45b2b7d7108ae1e25a5036cab04ab9273e792332 Author: Jakob Koschel Date: Fri Apr 1 00:34:14 2022 +0200 f2fs: fix dereference of stale list iterator after loop body [ Upstream commit 2aaf51dd39afb6d01d13f1e6fe20b684733b37d5 ] The list iterator variable will be a bogus pointer if no break was hit. Dereferencing it (cur->page in this case) could load an out-of-bounds/undefined value making it unsafe to use that in the comparision to determine if the specific element was found. Since 'cur->page' *can* be out-ouf-bounds it cannot be guaranteed that by chance (or intention of an attacker) it matches the value of 'page' even though the correct element was not found. This is fixed by using a separate list iterator variable for the loop and only setting the original variable if a suitable element was found. Then determing if the element was found is simply checking if the variable is set. Fixes: 8c242db9b8c0 ("f2fs: fix stale ATOMIC_WRITTEN_PAGE private pointer") Signed-off-by: Jakob Koschel Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 250e5a6be52a6b9d82fe91976c83cc158868b4e9 Author: Chao Yu Date: Tue Mar 29 00:02:53 2022 +0800 f2fs: fix to do sanity check on inline_dots inode [ Upstream commit 12662d19467b391b5b509ac5e9ab4f583c6dde16 ] As Wenqing reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215765 It will cause a kernel panic with steps: - mkdir mnt - mount tmp40.img mnt - ls mnt folio_mark_dirty+0x33/0x50 f2fs_add_regular_entry+0x541/0xad0 [f2fs] f2fs_add_dentry+0x6c/0xb0 [f2fs] f2fs_do_add_link+0x182/0x230 [f2fs] __recover_dot_dentries+0x2d6/0x470 [f2fs] f2fs_lookup+0x5af/0x6a0 [f2fs] __lookup_slow+0xac/0x200 lookup_slow+0x45/0x70 walk_component+0x16c/0x250 path_lookupat+0x8b/0x1f0 filename_lookup+0xef/0x250 user_path_at_empty+0x46/0x70 vfs_statx+0x98/0x190 __do_sys_newlstat+0x41/0x90 __x64_sys_newlstat+0x1a/0x30 do_syscall_64+0x37/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is for special file: e.g. character, block, fifo or socket file, f2fs doesn't assign address space operations pointer array for mapping->a_ops field, so, in a fuzzed image, if inline_dots flag was tagged in special file, during lookup(), when f2fs runs into __recover_dot_dentries(), it will cause NULL pointer access once f2fs_add_regular_entry() calls a_ops->set_dirty_page(). Fixes: 510022a85839 ("f2fs: add F2FS_INLINE_DOTS to recover missing dot dentries") Reported-by: Wenqing Liu Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2646992ddf3eb1093806dd822a11a51f4e89ef13 Author: Chao Yu Date: Thu Oct 28 21:03:05 2021 +0800 f2fs: support fault injection for dquot_initialize() [ Upstream commit 10a26878564f27327b12e8f4b4d8d7b43065fae5 ] This patch adds a new function f2fs_dquot_initialize() to wrap dquot_initialize(), and it supports to inject fault into f2fs_dquot_initialize() to simulate inner failure occurs in dquot_initialize(). Usage: a) echo 65536 > /sys/fs/f2fs//inject_type or b) mount -o fault_type=65536 Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 24705fd3f390c02757b23765db9a25d090f99faa Author: Dan Carpenter Date: Wed Apr 6 09:40:14 2022 +0300 OPP: call of_node_put() on error path in _bandwidth_supported() [ Upstream commit 907ed123b9d096c73e9361f6cd4097f0691497f2 ] This code does not call of_node_put(opp_np) if of_get_next_available_child() returns NULL. But it should. Fixes: 45679f9b508f ("opp: Don't parse icc paths unnecessarily") Signed-off-by: Dan Carpenter Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 64522155ea73cc580be931f10aa29e3a51f5c6d5 Author: Dmitry Torokhov Date: Wed May 25 09:51:08 2022 -0700 Input: stmfts - do not leave device disabled in stmfts_input_open [ Upstream commit 5f76955ab1e43e5795a9631b22ca4f918a0ae986 ] The commit 26623eea0da3 attempted to deal with potential leak of runtime PM counter when opening the touchscreen device, however it ended up erroneously dropping the counter in the case of successfully enabling the device. Let's address this by using pm_runtime_resume_and_get() and then executing pm_runtime_put_sync() only when we fail to send "sense on" command to the device. Fixes: 26623eea0da3 ("Input: stmfts - fix reference leak in stmfts_input_open") Reported-by: Pavel Machek Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 4f1c4fa37f8bd0d142d6641db4c82094124f468c Author: Wanpeng Li Date: Fri May 20 10:15:18 2022 -0400 KVM: LAPIC: Drop pending LAPIC timer injection when canceling the timer [ Upstream commit 619f51da097952194a5d4d6a6c5f9ef3b9d1b25a ] The timer is disarmed when switching between TSC deadline and other modes; however, the pending timer is still in-flight, so let's accurately remove any traces of the previous mode. Fixes: 4427593258 ("KVM: x86: thoroughly disarm LAPIC timer around TSC deadline switch") Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ca55150bff5817af4f857a746ecab9862c23e12a Author: Douglas Miller Date: Fri May 20 14:37:01 2022 -0400 RDMA/hfi1: Prevent use of lock before it is initialized [ Upstream commit 05c03dfd09c069c4ffd783b47b2da5dcc9421f2c ] If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0 The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized. Fixes: 473291b3ea0e ("IB/hfi1: Fix for early release of sdma context") Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20220520183701.48973.72434.stgit@awfm-01.cornelisnetworks.com Reported-by: Zheyu Ma Signed-off-by: Douglas Miller Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 119f99209d8531359bcb935f252ec435f9d21b13 Author: Björn Ardö Date: Thu Mar 31 09:01:15 2022 +0200 mailbox: forward the hrtimer if not queued and under a lock [ Upstream commit bca1a1004615efe141fd78f360ecc48c60bc4ad5 ] This reverts commit c7dacf5b0f32957b24ef29df1207dc2cd8307743, "mailbox: avoid timer start from callback" The previous commit was reverted since it lead to a race that caused the hrtimer to not be started at all. The check for hrtimer_active() in msg_submit() will return true if the callback function txdone_hrtimer() is currently running. This function could return HRTIMER_NORESTART and then the timer will not be restarted, and also msg_submit() will not start the timer. This will lead to a message actually being submitted but no timer will start to check for its compleation. The original fix that added checking hrtimer_active() was added to avoid a warning with hrtimer_forward. Looking in the kernel another solution to avoid this warning is to check hrtimer_is_queued() before calling hrtimer_forward_now() instead. This however requires a lock so the timer is not started by msg_submit() inbetween this check and the hrtimer_forward() call. Fixes: c7dacf5b0f32 ("mailbox: avoid timer start from callback") Signed-off-by: Björn Ardö Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 075564ed4089353557d2e3f5d0fba39b52181aff Author: Julian Schroeder Date: Mon May 23 18:52:26 2022 +0000 nfsd: destroy percpu stats counters after reply cache shutdown [ Upstream commit fd5e363eac77ef81542db77ddad0559fa0f9204e ] Upon nfsd shutdown any pending DRC cache is freed. DRC cache use is tracked via a percpu counter. In the current code the percpu counter is destroyed before. If any pending cache is still present, percpu_counter_add is called with a percpu counter==NULL. This causes a kernel crash. The solution is to destroy the percpu counter after the cache is freed. Fixes: e567b98ce9a4b (“nfsd: protect concurrent access to nfsd stats counters”) Signed-off-by: Julian Schroeder Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 5289795824b77489803b0802cd9edc13824a2d0b Author: Yang Yingliang Date: Tue Apr 26 11:08:57 2022 +0800 mfd: davinci_voicecodec: Fix possible null-ptr-deref davinci_vc_probe() [ Upstream commit 311242c7703df0da14c206260b7e855f69cb0264 ] It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Fixes: b5e29aa880be ("mfd: davinci_voicecodec: Remove pointless #include") Signed-off-by: Yang Yingliang Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220426030857.3539336-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 7b668a59ddfb32727e39b06fdf52b28e58c684e0 Author: Miaoqian Lin Date: Thu May 12 16:37:18 2022 +0400 powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup [ Upstream commit fcee96924ba1596ca80a6770b2567ca546f9a482 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: abc3aeae3aaa ("fsl-rio: Add two ports and rapidio message units support") Signed-off-by: Miaoqian Lin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220512123724.62931-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit 65f11ccdd746e0e7f0b469cc989ba43d4f30ecfe Author: Miaoqian Lin Date: Thu May 12 13:05:33 2022 +0400 powerpc/xive: Fix refcount leak in xive_spapr_init [ Upstream commit 1d1fb9618bdd5a5fbf9a9eb75133da301d33721c ] of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller") Signed-off-by: Miaoqian Lin Reviewed-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220512090535.33397-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit fd7a3548af09660908a63e824eedf78cc4a089e3 Author: Christophe JAILLET Date: Tue Feb 1 13:31:16 2022 +0100 powerpc/xive: Add some error handling code to 'xive_spapr_init()' [ Upstream commit e414e2938ee26e734f19e92a60cd090ebaff37e6 ] 'xive_irq_bitmap_add()' can return -ENOMEM. In this case, we should free the memory already allocated and return 'false' to the caller. Also add an error path which undoes the 'tima = ioremap(...)' Signed-off-by: Christophe JAILLET Reviewed-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/564998101804886b151235c8a9f93020923bfd2c.1643718324.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit f04604987c7b054c8bc63b1814dc56d161ba587a Author: Randy Dunlap Date: Sun Apr 10 09:10:35 2022 -0700 macintosh: via-pmu and via-cuda need RTC_LIB [ Upstream commit 9a9c5ff5fff87eb1a43db0d899473554e408fd7b ] Fix build when RTC_LIB is not set/enabled. Eliminates these build errors: m68k-linux-ld: drivers/macintosh/via-pmu.o: in function `pmu_set_rtc_time': drivers/macintosh/via-pmu.c:1769: undefined reference to `rtc_tm_to_time64' m68k-linux-ld: drivers/macintosh/via-cuda.o: in function `cuda_set_rtc_time': drivers/macintosh/via-cuda.c:797: undefined reference to `rtc_tm_to_time64' Fixes: 0792a2c8e0bb ("macintosh: Use common code to access RTC") Reported-by: kernel test robot Suggested-by: Christophe Leroy Signed-off-by: Randy Dunlap Acked-by: Arnd Bergmann Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220410161035.592-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit bd89ccd736bfcb9d2036a5bdfd295f9d7aa69be2 Author: Kajol Jain Date: Fri May 6 11:40:15 2022 +0530 powerpc/perf: Fix the threshold compare group constraint for power9 [ Upstream commit ab0cc6bbf0c812731c703ec757fcc3fc3a457a34 ] Thresh compare bits for a event is used to program thresh compare field in Monitor Mode Control Register A (MMCRA: 9-18 bits for power9). When scheduling events as a group, all events in that group should match value in threshold bits (like thresh compare, thresh control, thresh select). Otherwise event open for the sibling events should fail. But in the current code, incase thresh compare bits are not valid, we are not failing in group_constraint function which can result in invalid group schduling. Fix the issue by returning -1 incase event is threshold and threshold compare value is not valid. Thresh control bits in the event code is used to program thresh_ctl field in Monitor Mode Control Register A (MMCRA: 48-55). In below example, the scheduling of group events PM_MRK_INST_CMPL (873534401e0) and PM_THRESH_MET (8734340101ec) is expected to fail as both event request different thresh control bits and invalid thresh compare value. Result before the patch changes: [command]# perf stat -e "{r8735340401e0,r8734340101ec}" sleep 1 Performance counter stats for 'sleep 1': 11,048 r8735340401e0 1,967 r8734340101ec 1.001354036 seconds time elapsed 0.001421000 seconds user 0.000000000 seconds sys Result after the patch changes: [command]# perf stat -e "{r8735340401e0,r8734340101ec}" sleep 1 Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (r8735340401e0). /bin/dmesg | grep -i perf may provide additional information. Fixes: 78a16d9fc1206 ("powerpc/perf: Avoid FAB_*_MATCH checks for power9") Signed-off-by: Kajol Jain Reviewed-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220506061015.43916-2-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit 42063c1c1fb19721e263c82b23cb1da582e5182a Author: Kajol Jain Date: Fri May 6 11:40:14 2022 +0530 powerpc/perf: Fix the threshold compare group constraint for power10 [ Upstream commit 505d31650ba96d6032313480fdb566d289a4698c ] Thresh compare bits for a event is used to program thresh compare field in Monitor Mode Control Register A (MMCRA: 8-18 bits for power10). When scheduling events as a group, all events in that group should match value in threshold bits. Otherwise event open for the sibling events should fail. But in the current code, incase thresh compare bits are not valid, we are not failing in group_constraint function which can result in invalid group schduling. Fix the issue by returning -1 incase event is threshold and threshold compare value is not valid in group_constraint function. Patch also fixes the p10_thresh_cmp_val function to return -1, incase threshold bits are not valid and changes corresponding check in is_thresh_cmp_valid function to return false only when the thresh_cmp value is less then 0. Thresh control bits in the event code is used to program thresh_ctl field in Monitor Mode Control Register A (MMCRA: 48-55). In below example, the scheduling of group events PM_MRK_INST_CMPL (3534401e0) and PM_THRESH_MET (34340101ec) is expected to fail as both event request different thresh control bits. Result before the patch changes: [command]# perf stat -e "{r35340401e0,r34340101ec}" sleep 1 Performance counter stats for 'sleep 1': 8,482 r35340401e0 0 r34340101ec 1.001474838 seconds time elapsed 0.001145000 seconds user 0.000000000 seconds sys Result after the patch changes: [command]# perf stat -e "{r35340401e0,r34340101ec}" sleep 1 Performance counter stats for 'sleep 1': r35340401e0 r34340101ec 1.001499607 seconds time elapsed 0.000204000 seconds user 0.000760000 seconds sys Fixes: 82d2c16b350f7 ("powerpc/perf: Adds support for programming of Thresholding in P10") Signed-off-by: Kajol Jain Reviewed-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220506061015.43916-1-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit 5a8849d3cb80e31e74ab007a9a7c185950ee89da Author: Michael Ellerman Date: Thu Apr 7 00:58:01 2022 +1000 powerpc/64: Only WARN if __pa()/__va() called with bad addresses [ Upstream commit c4bce84d0bd3f396f702d69be2e92bbd8af97583 ] We added checks to __pa() / __va() to ensure they're only called with appropriate addresses. But using BUG_ON() is too strong, it means virt_addr_valid() will BUG when DEBUG_VIRTUAL is enabled. Instead switch them to warnings, arm64 does the same. Fixes: 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220406145802.538416-5-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 2530a7c23643a67951b67378136ad67034f53fb5 Author: Yang Yingliang Date: Sat May 14 16:42:41 2022 +0800 hwrng: omap3-rom - fix using wrong clk_disable() in omap_rom_rng_runtime_resume() [ Upstream commit e4e62bbc6aba49a5edb3156ec65f6698ff37d228 ] 'ddata->clk' is enabled by clk_prepare_enable(), it should be disabled by clk_disable_unprepare(). Fixes: 8d9d4bdc495f ("hwrng: omap3-rom - Use runtime PM instead of custom functions") Signed-off-by: Yang Yingliang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bb1030d3de10cdd37f73a40a3651200762c45fd0 Author: Daire McNamara Date: Tue May 17 15:16:22 2022 +0100 PCI: microchip: Fix potential race in interrupt handling [ Upstream commit 7013654af694f6e1a2e699a6450ea50d309dd0e5 ] Clear the MSI bit in ISTATUS_LOCAL register after reading it, but before reading and handling individual MSI bits from the ISTATUS_MSI register. This avoids a potential race where new MSI bits may be set on the ISTATUS_MSI register after it was read and be missed when the MSI bit in the ISTATUS_LOCAL register is cleared. ISTATUS_LOCAL is a read/write/clear register; the register's bits are set when the corresponding interrupt source is activated. Each source is independent and thus multiple sources may be active simultaneously. The processor can monitor and clear status bits. If one or more ISTATUS_LOCAL interrupt sources are active, the RootPort issues an interrupt towards the processor (on the AXI domain). Bit 28 of this register reports an MSI has been received by the RootPort. ISTATUS_MSI is a read/write/clear register. Bits 31-0 are asserted when an MSI with message number 31-0 is received by the RootPort. The processor must monitor and clear these bits. Effectively, Bit 28 of ISTATUS_LOCAL informs the processor that an MSI has arrived at the RootPort and ISTATUS_MSI informs the processor which MSI (in the range 0 - 31) needs handling. Reported by: Bjorn Helgaas Link: https://lore.kernel.org/linux-pci/20220127202000.GA126335@bhelgaas/ Link: https://lore.kernel.org/r/20220517141622.145581-1-daire.mcnamara@microchip.com Fixes: 6f15a9c9f941 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver") Signed-off-by: Daire McNamara Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit acb748fdc59e11bccf84fc3411e9d579e484e043 Author: Kuppuswamy Sathyanarayanan Date: Mon Apr 18 15:02:37 2022 +0000 PCI/AER: Clear MULTI_ERR_COR/UNCOR_RCV bits [ Upstream commit 203926da2bff8e172200a2f11c758987af112d4a ] When a Root Port or Root Complex Event Collector receives an error Message e.g., ERR_COR, it sets PCI_ERR_ROOT_COR_RCV in the Root Error Status register and logs the Requester ID in the Error Source Identification register. If it receives a second ERR_COR Message before software clears PCI_ERR_ROOT_COR_RCV, hardware sets PCI_ERR_ROOT_MULTI_COR_RCV and the Requester ID is lost. In the following scenario, PCI_ERR_ROOT_MULTI_COR_RCV was never cleared: - hardware receives ERR_COR message - hardware sets PCI_ERR_ROOT_COR_RCV - aer_irq() entered - aer_irq(): status = pci_read_config_dword(PCI_ERR_ROOT_STATUS) - aer_irq(): now status == PCI_ERR_ROOT_COR_RCV - hardware receives second ERR_COR message - hardware sets PCI_ERR_ROOT_MULTI_COR_RCV - aer_irq(): pci_write_config_dword(PCI_ERR_ROOT_STATUS, status) - PCI_ERR_ROOT_COR_RCV is cleared; PCI_ERR_ROOT_MULTI_COR_RCV is set - aer_irq() entered again - aer_irq(): status = pci_read_config_dword(PCI_ERR_ROOT_STATUS) - aer_irq(): now status == PCI_ERR_ROOT_MULTI_COR_RCV - aer_irq() exits because PCI_ERR_ROOT_COR_RCV not set - PCI_ERR_ROOT_MULTI_COR_RCV is still set The same problem occurred with ERR_NONFATAL/ERR_FATAL Messages and PCI_ERR_ROOT_UNCOR_RCV and PCI_ERR_ROOT_MULTI_UNCOR_RCV. Fix the problem by queueing an AER event and clearing the Root Error Status bits when any of these bits are set: PCI_ERR_ROOT_COR_RCV PCI_ERR_ROOT_UNCOR_RCV PCI_ERR_ROOT_MULTI_COR_RCV PCI_ERR_ROOT_MULTI_UNCOR_RCV See the bugzilla link for details from Eric about how to reproduce this problem. [bhelgaas: commit log, move repro details to bugzilla] Fixes: e167bfcaa4cd ("PCI: aerdrv: remove magical ROOT_ERR_STATUS_MASKS") Link: https://bugzilla.kernel.org/show_bug.cgi?id=215992 Link: https://lore.kernel.org/r/20220418150237.1021519-1-sathyanarayanan.kuppuswamy@linux.intel.com Reported-by: Eric Badger Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Bjorn Helgaas Reviewed-by: Ashok Raj Signed-off-by: Sasha Levin commit 418b6a3e12f75638abc5673eb76cb32127d0ab13 Author: Miaoqian Lin Date: Mon May 16 14:55:55 2022 -0700 Input: sparcspkr - fix refcount leak in bbc_beep_probe [ Upstream commit c8994b30d71d64d5dcc9bc0edbfdf367171aa96f ] of_find_node_by_path() calls of_find_node_opts_by_path(), which returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 9c1a5077fdca ("input: Rewrite sparcspkr device probing.") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220516081018.42728-1-linmq006@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 35972ce3fb7af5ea08a92efc20f72bdc4864d301 Author: Mina Almasry Date: Mon May 9 18:20:50 2022 -0700 hugetlbfs: fix hugetlbfs_statfs() locking [ Upstream commit 4b25f030ae69ba710eff587cabb4c57cb7e7a8a1 ] After commit db71ef79b59b ("hugetlb: make free_huge_page irq safe"), the subpool lock should be locked with spin_lock_irq() and all call sites was modified as such, except for the ones in hugetlbfs_statfs(). Link: https://lkml.kernel.org/r/20220429202207.3045-1-almasrymina@google.com Fixes: db71ef79b59b ("hugetlb: make free_huge_page irq safe") Signed-off-by: Mina Almasry Reviewed-by: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit cd4815c5c97f693e6a00812f18ec0ce8301ed5ee Author: Eugen Hristev Date: Tue May 3 16:31:27 2022 +0300 ARM: dts: at91: sama7g5: remove interrupt-parent from gic node [ Upstream commit b7e86ef7afd128577ff7bb0db0ae82d27d7ed7ad ] interrupt-parent is not to be used as a boolean property. It is already present in the DT in the proper way it's supposed to be used: interrupt-parent = <&gic>; This is also reported by dtbs_check: arch/arm/boot/dts/at91-sama7g5ek.dtb: interrupt-controller@e8c11000: interrupt-parent: True is not of type 'array' From schema: /.local/lib/python3.8/site-packages/dtschema/schemas/interrupts.yaml Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") Signed-off-by: Eugen Hristev Reviewed-by: Claudiu Beznea Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220503133127.64320-1-eugen.hristev@microchip.com Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit 2a30446f40143f1e76086b538a882181a7be4380 Author: Sebastian Andrzej Siewior Date: Wed May 4 17:07:36 2022 +0200 crypto: cryptd - Protect per-CPU resource by disabling BH. [ Upstream commit 91e8bcd7b4da182e09ea19a2c73167345fe14c98 ] The access to cryptd_queue::cpu_queue is synchronized by disabling preemption in cryptd_enqueue_request() and disabling BH in cryptd_queue_worker(). This implies that access is allowed from BH. If cryptd_enqueue_request() is invoked from preemptible context _and_ soft interrupt then this can lead to list corruption since cryptd_enqueue_request() is not protected against access from soft interrupt. Replace get_cpu() in cryptd_enqueue_request() with local_bh_disable() to ensure BH is always disabled. Remove preempt_disable() from cryptd_queue_worker() since it is not needed because local_bh_disable() ensures synchronisation. Fixes: 254eff771441 ("crypto: cryptd - Per-CPU thread implementation...") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit de5b734db2953b1c9d1bb8f725c64325ec31b5ec Author: Corentin Labbe Date: Mon May 2 20:19:15 2022 +0000 crypto: sun8i-ss - handle zero sized sg [ Upstream commit c149e4763d28bb4c0e5daae8a59f2c74e889f407 ] sun8i-ss does not handle well the possible zero sized sg. Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bbfc612ac579dee355b212e492b22ce273dfa4a7 Author: Corentin Labbe Date: Mon May 2 20:19:14 2022 +0000 crypto: sun8i-ss - rework handling of IV [ Upstream commit 359e893e8af456be2fefabe851716237df289cbf ] sun8i-ss fail handling IVs when doing decryption of multiple SGs in-place. It should backup the last block of each SG source for using it later as IVs. In the same time remove allocation on requests path for storing all IVs. Fixes: f08fcced6d00 ("crypto: allwinner - Add sun8i-ss cryptographic offloader") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 18ca0d55e8639b911df8aae1b47598b13f9acded Author: Qi Zheng Date: Thu May 12 20:38:37 2022 -0700 tty: fix deadlock caused by calling printk() under tty_port->lock [ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ] pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner); vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023 vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 fail_dump lib/fault-inject.c:45 [inline] should_fail+0x67b/0x7c0 lib/fault-inject.c:144 __should_failslab+0x152/0x1c0 mm/failslab.c:33 should_failslab+0x5/0x10 mm/slab_common.c:1224 slab_pre_alloc_hook mm/slab.h:468 [inline] slab_alloc_node mm/slub.c:2723 [inline] slab_alloc mm/slub.c:2807 [inline] __kmalloc+0x72/0x300 mm/slub.c:3871 kmalloc include/linux/slab.h:582 [inline] tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175 __tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273 tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318 tty_insert_flip_string include/linux/tty_flip.h:37 [inline] pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock); n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356 do_tty_write drivers/tty/tty_io.c:961 [inline] tty_write+0x512/0x930 drivers/tty/tty_io.c:1045 __vfs_write+0x76/0x100 fs/read_write.c:494 [...] other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &port->lock Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag") Signed-off-by: Qi Zheng Acked-by: Jiri Slaby Acked-by: Greg Kroah-Hartman Cc: Akinobu Mita Cc: Vlastimil Babka Cc: Steven Rostedt (Google) Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 518fa6bc7a5210ddcf9730619765289d1d1abbce Author: Francesco Dolcini Date: Mon Apr 4 10:15:09 2022 +0200 PCI: imx6: Fix PERST# start-up sequence [ Upstream commit a6809941c1f17f455db2cf4ca19c6d8c8746ec25 ] According to the PCIe standard the PERST# signal (reset-gpio in fsl,imx* compatible dts) should be kept asserted for at least 100 usec before the PCIe refclock is stable, should be kept asserted for at least 100 msec after the power rails are stable and the host should wait at least 100 msec after it is de-asserted before accessing the configuration space of any attached device. From PCIe CEM r2.0, sec 2.6.2 T-PVPERL: Power stable to PERST# inactive - 100 msec T-PERST-CLK: REFCLK stable before PERST# inactive - 100 usec. From PCIe r5.0, sec 6.6.1 With a Downstream Port that does not support Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms before sending a Configuration Request to the device immediately below that Port. Failure to do so could prevent PCIe devices to be working correctly, and this was experienced with real devices. Move reset assert to imx6_pcie_assert_core_reset(), this way we ensure that PERST# is asserted before enabling any clock, move de-assert to the end of imx6_pcie_deassert_core_reset() after the clock is enabled and deemed stable and add a new delay of 100 msec just afterward. Link: https://lore.kernel.org/all/20220211152550.286821-1-francesco.dolcini@toradex.com Link: https://lore.kernel.org/r/20220404081509.94356-1-francesco.dolcini@toradex.com Fixes: bb38919ec56e ("PCI: imx6: Add support for i.MX6 PCIe controller") Signed-off-by: Francesco Dolcini Signed-off-by: Lorenzo Pieralisi Reviewed-by: Lucas Stach Acked-by: Richard Zhu Signed-off-by: Sasha Levin commit 6df8af611d60f2d18e45e07d1d0800250d9f6554 Author: Waiman Long Date: Mon May 9 18:29:21 2022 -0700 ipc/mqueue: use get_tree_nodev() in mqueue_get_tree() [ Upstream commit d60c4d01a98bc1942dba6e3adc02031f5519f94b ] When running the stress-ng clone benchmark with multiple testing threads, it was found that there were significant spinlock contention in sget_fc(). The contended spinlock was the sb_lock. It is under heavy contention because the following code in the critcal section of sget_fc(): hlist_for_each_entry(old, &fc->fs_type->fs_supers, s_instances) { if (test(old, fc)) goto share_extant_sb; } After testing with added instrumentation code, it was found that the benchmark could generate thousands of ipc namespaces with the corresponding number of entries in the mqueue's fs_supers list where the namespaces are the key for the search. This leads to excessive time in scanning the list for a match. Looking back at the mqueue calling sequence leading to sget_fc(): mq_init_ns() => mq_create_mount() => fc_mount() => vfs_get_tree() => mqueue_get_tree() => get_tree_keyed() => vfs_get_super() => sget_fc() Currently, mq_init_ns() is the only mqueue function that will indirectly call mqueue_get_tree() with a newly allocated ipc namespace as the key for searching. As a result, there will never be a match with the exising ipc namespaces stored in the mqueue's fs_supers list. So using get_tree_keyed() to do an existing ipc namespace search is just a waste of time. Instead, we could use get_tree_nodev() to eliminate the useless search. By doing so, we can greatly reduce the sb_lock hold time and avoid the spinlock contention problem in case a large number of ipc namespaces are present. Of course, if the code is modified in the future to allow mqueue_get_tree() to be called with an existing ipc namespace instead of a new one, we will have to use get_tree_keyed() in this case. The following stress-ng clone benchmark command was run on a 2-socket 48-core Intel system: ./stress-ng --clone 32 --verbose --oomable --metrics-brief -t 20 The "bogo ops/s" increased from 5948.45 before patch to 9137.06 after patch. This is an increase of 54% in performance. Link: https://lkml.kernel.org/r/20220121172315.19652-1-longman@redhat.com Fixes: 935c6912b198 ("ipc: Convert mqueue fs to fs_context") Signed-off-by: Waiman Long Cc: Al Viro Cc: David Howells Cc: Manfred Spraul Cc: Davidlohr Bueso Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f588b925915a19473dfce1d0566c387abe5fc8af Author: Alexey Dobriyan Date: Mon May 9 18:29:19 2022 -0700 proc: fix dentry/inode overinstantiating under /proc/${pid}/net [ Upstream commit 7055197705709c59b8ab77e6a5c7d46d61edd96e ] When a process exits, /proc/${pid}, and /proc/${pid}/net dentries are flushed. However some leaf dentries like /proc/${pid}/net/arp_cache aren't. That's because respective PDEs have proc_misc_d_revalidate() hook which returns 1 and leaves dentries/inodes in the LRU. Force revalidation/lookup on everything under /proc/${pid}/net by inheriting proc_net_dentry_ops. [akpm@linux-foundation.org: coding-style cleanups] Link: https://lkml.kernel.org/r/YjdVHgildbWO7diJ@localhost.localdomain Fixes: c6c75deda813 ("proc: fix lookup in /proc/net subdirectories after setns(2)") Signed-off-by: Alexey Dobriyan Reported-by: hui li Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit eb610fdf4916e3c08ab7aa2a585e02e74eb07a81 Author: Charles Keepax Date: Wed May 4 18:08:30 2022 +0100 ASoC: atmel-classd: Remove endianness flag on class d component [ Upstream commit 0104d52a6a69b06b0e8167f7c1247e8c76aca070 ] The endianness flag should have been removed when the driver was ported across from having both a CODEC and CPU side component, to just having a CPU component and using the dummy for the CODEC. The endianness flag is used to indicate that the device is completely ambivalent to the endianness of the data, typically due to the endianness being lost over the hardware link (ie. the link defines bit ordering). It's usage didn't have any effect when the driver had both a CPU and CODEC component, since the union of those equals the CPU side settings, but now causes the driver to falsely report it supports big endian. Correct this by removing the flag. Fixes: 1dfdbe73ccf9 ("ASoC: atmel-classd: remove codec component") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220504170905.332415-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7553130725eb3447bbb886af2610907e64ca60dd Author: Charles Keepax Date: Wed May 4 18:08:29 2022 +0100 ASoC: atmel-pdmic: Remove endianness flag on pdmic component [ Upstream commit 52857c3baa0e5ddeba7b2c84e56bb71c9674e048 ] The endianness flag should have been removed when the driver was ported across from having both a CODEC and CPU side component, to just having a CPU component and using the dummy for the CODEC. The endianness flag is used to indicate that the device is completely ambivalent to the endianness of the data, typically due to the endianness being lost over the hardware link (ie. the link defines bit ordering). It's usage didn't have any effect when the driver had both a CPU and CODEC component, since the union of those equals the CPU side settings, but now causes the driver to falsely report it supports big endian. Correct this by removing the flag. Fixes: f3c668074a04 ("ASoC: atmel-pdmic: remove codec component") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220504170905.332415-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dd0ee5549368881c7e9d3f75846c6d73df4c713e Author: Robert Marko Date: Tue Sep 28 19:09:19 2021 +0200 arm64: dts: marvell: espressobin-ultra: enable front USB3 port [ Upstream commit eacec7ebc16cf5d2f6a6c7cf5d57156da2c3e98f ] Espressobin Ultra has a front panel USB3.0 Type-A port which works just fine so enable it. I dont see a reason why it was disabled in the first place anyway. Fixes: 3404fe15a60f ("arm64: dts: marvell: add DT for ESPRESSObin-Ultra") Signed-off-by: Robert Marko Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 4ece24db394c6966ebfeb3e725ac3a2ebf1f2ee2 Author: Robert Marko Date: Tue Sep 28 19:09:17 2021 +0200 arm64: dts: marvell: espressobin-ultra: fix SPI-NOR config [ Upstream commit 5202f4c3816b42e989f9cad49a73c7e88fba89f4 ] SPI config for the SPI-NOR is incorrect and completely breaking reading/writing to the onboard SPI-NOR. SPI-NOR is connected in the single(x1) IO mode and not in the quad (x4) mode. Also, there is no need to override the max frequency from the DTSI as the mx25u3235f that is used supports 104Mhz. Fixes: 3404fe15a60f ("arm64: dts: marvell: add DT for ESPRESSObin-Ultra") Signed-off-by: Robert Marko Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit e42ceeca700a01f4c33a5d1509d0231a99dba7b7 Author: Yangyang Li Date: Fri Apr 29 17:31:04 2022 +0800 RDMA/hns: Add the detection for CMDQ status in the device initialization process [ Upstream commit e8ea058edc2b225a68b307057a65599625daaebf ] CMDQ may fail during HNS ROCEE initialization. The following is the log when the execution fails: hns3 0000:bd:00.2: In reset process RoCE client reinit. hns3 0000:bd:00.2: CMDQ move tail from 840 to 839 hns3 0000:bd:00.2 hns_2: failed to set gid, ret = -11! hns3 0000:bd:00.2: CMDQ move tail from 840 to 839 <...> hns3 0000:bd:00.2: CMDQ move tail from 840 to 839 hns3 0000:bd:00.2: CMDQ move tail from 840 to 0 hns3 0000:bd:00.2: [cmd]token 14e mailbox 20 timeout. hns3 0000:bd:00.2 hns_2: set HEM step 0 failed! hns3 0000:bd:00.2 hns_2: set HEM address to HW failed! hns3 0000:bd:00.2 hns_2: failed to alloc mtpt, ret = -16. infiniband hns_2: Couldn't create ib_mad PD infiniband hns_2: Couldn't open port 1 hns3 0000:bd:00.2: Reset done, RoCE client reinit finished. However, even if ib_mad client registration failed, ib_register_device() still returns success to the driver. In the device initialization process, CMDQ execution fails because HW/FW is abnormal. Therefore, if CMDQ fails, the initialization function should set CMDQ to a fatal error state and return a failure to the caller. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Link: https://lore.kernel.org/r/20220429093104.26687-1-liangwenpeng@huawei.com Signed-off-by: Yangyang Li Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4237eb9bdf59b6b0756f894b5043424fbad332f0 Author: Randy Dunlap Date: Mon May 2 12:29:41 2022 -0700 powerpc/4xx/cpm: Fix return value of __setup() handler [ Upstream commit 5bb99fd4090fe1acfdb90a97993fcda7f8f5a3d6 ] __setup() handlers should return 1 to obsolete_checksetup() in init/main.c to indicate that the boot option has been handled. A return of 0 causes the boot option/value to be listed as an Unknown kernel parameter and added to init's (limited) argument or environment strings. Also, error return codes don't mean anything to obsolete_checksetup() -- only non-zero (usually 1) or zero. So return 1 from cpm_powersave_off(). Fixes: d164f6d4f910 ("powerpc/4xx: Add suspend and idle support") Reported-by: Igor Zhbanov Signed-off-by: Randy Dunlap Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220502192941.20955-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit c8a9b3defaad1adc82efb003a6a9b87dd74300e0 Author: Randy Dunlap Date: Mon May 2 12:29:25 2022 -0700 powerpc/idle: Fix return value of __setup() handler [ Upstream commit b793a01000122d2bd133ba451a76cc135b5e162c ] __setup() handlers should return 1 to obsolete_checksetup() in init/main.c to indicate that the boot option has been handled. A return of 0 causes the boot option/value to be listed as an Unknown kernel parameter and added to init's (limited) argument or environment strings. Also, error return codes don't mean anything to obsolete_checksetup() -- only non-zero (usually 1) or zero. So return 1 from powersave_off(). Fixes: 302eca184fb8 ("[POWERPC] cell: use ppc_md->power_save instead of cbe_idle_loop") Reported-by: Igor Zhbanov Signed-off-by: Randy Dunlap Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220502192925.19954-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 5ed0519d425619b435150372cce2ffeec71581fa Author: Yang Yingliang Date: Fri Apr 29 16:26:36 2022 +0800 pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources() [ Upstream commit 5376e3d904532e657fd7ca1a9b1ff3d351527b90 ] It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Fixes: c7977ec4a336 ("pinctrl: sh-pfc: Convert to platform_get_*()") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20220429082637.1308182-1-yangyingliang@huawei.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 6a9992f80c0f0e3fa80cee74d5301aa0647e2720 Author: Geert Uytterhoeven Date: Fri Apr 22 09:29:30 2022 +0200 pinctrl: renesas: r8a779a0: Fix GPIO function on I2C-capable pins [ Upstream commit 4288caed9a6319b766dc0adf605c7b401180db34 ] Unlike on R-Car Gen3 SoCs, setting a bit to zero in a GPIO / Peripheral Function Select Register (GPSRn) on R-Car V3U is not always sufficient to configure a pin for GPIO. For I2C-capable pins, the I2C function must also be explicitly disabled in the corresponding Module Select Register (MODSELn). Add the missing FN_SEL_I2Ci_0 function enums to the pinmux_data[] array by temporarily overriding the GP_2_j_FN function enum to expand to two enums: the original GP_2_j_FN enum to configure the GSPR register bits, and the missing FN_SEL_I2Ci_0 enum to configure the MODSEL register bits. Fixes: 741a7370fc3b8b54 ("pinctrl: renesas: Initial R8A779A0 (V3U) PFC support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/4611e29e7b105513883084c1d6dc39c3ac8b525c.1650610471.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 6cc90d5d449ef6f3cba4973db882318b1f45edbd Author: Randy Dunlap Date: Thu Jan 21 17:08:19 2021 -0800 powerpc/8xx: export 'cpm_setbrg' for modules [ Upstream commit 22f8e625ebabd7ed3185b82b44b4f12fc0402113 ] Fix missing export for a loadable module build: ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined! Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc") Signed-off-by: Randy Dunlap Reported-by: kernel test robot [chleroy: Changed Fixes: tag] Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210122010819.30986-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 878f89e7261e9c367de41466d15e9976078468ee Author: Lv Ruyi Date: Mon Apr 25 09:09:47 2022 +0000 drm/msm/dpu: fix error check return value of irq_of_parse_and_map() [ Upstream commit 95093595914c17f32e1d6228b4db06fab8cebd35 ] The irq_of_parse_and_map() function returns 0 on failure, and does not return a negative value anyhow, so never enter this conditional branch. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/483291/ Link: https://lore.kernel.org/r/20220425090947.3498897-1-lv.ruyi@zte.com.cn Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 5d5d993f16be15d124be7b8ec71b28ef7b7dc3af Author: Kuniyuki Iwashima Date: Fri Apr 29 14:38:01 2022 -0700 list: fix a data-race around ep->rdllist [ Upstream commit d679ae94fdd5d3ab00c35078f5af5f37e068b03d ] ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next. Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Link: https://lkml.kernel.org/r/20220322002653.33865-3-kuniyu@amazon.co.jp Fixes: e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") Fixes: c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") Fixes: bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") Signed-off-by: Kuniyuki Iwashima Reported-by: syzbot+bdd6e38a1ed5ee58d8bd@syzkaller.appspotmail.com Cc: Al Viro , Andrew Morton Cc: Kuniyuki Iwashima Cc: Kuniyuki Iwashima Cc: "Soheil Hassas Yeganeh" Cc: Davidlohr Bueso Cc: "Sridhar Samudrala" Cc: Alexander Duyck Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8be32624f4572c017e4514d680213f5d0b276bd5 Author: Andy Shevchenko Date: Wed Jan 19 18:08:56 2022 -0800 list: introduce list_is_head() helper and re-use it in list.h [ Upstream commit 0425473037db40d9e322631f2d4dc6ef51f97e88 ] Introduce list_is_head() in the similar (*) way as it's done for list_entry_is_head(). Make use of it in the list.h. *) it's done as inliner and not a macro to be aligned with other list_is_*() APIs; while at it, make all three to have the same style. Link: https://lkml.kernel.org/r/20211201141824.81400-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko Cc: Heikki Krogerus Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b53f6ba21b9446779e1acbe62ffff1b04f860e74 Author: Sudeep Holla Date: Fri Apr 29 12:39:44 2022 +0100 firmware: arm_ffa: Remove incorrect assignment of driver_data [ Upstream commit 00512d2930b338fdd42bd90bbd1793fe212c2d31 ] The ffa core driver currently assigns its own driver information to individual ffa device driver_data which is wrong. Firstly, it leaks this core driver information to individual ffa_device and hence to ffa_driver. Secondly the ffa_device driver_data is for use by individual ffa_driver and not for this core driver managing all those devices. Link: https://lore.kernel.org/r/20220429113946.2087145-2-sudeep.holla@arm.com Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions") Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit b5c203ea0b961ac4b34268e2023496fec60745d4 Author: Sudeep Holla Date: Fri Apr 29 12:39:43 2022 +0100 firmware: arm_ffa: Fix uuid parameter to ffa_partition_probe [ Upstream commit f3c45c045e25ed52461829d2ce07954f72b6ad15 ] While we pass uuid_null intentionally to ffa_partition_probe in ffa_setup_partitions to get the count of the partitions, it must not be uuid_null in ffa_partition_info_get which is used by the ffa_drivers to fetch the specific partition info passing the UUID of the partition. Fix ffa_partition_info_get by passing the received uuid down to ffa_partition_probe so that the correct partition information is fetched. Link: https://lore.kernel.org/r/20220429113946.2087145-1-sudeep.holla@arm.com Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions") Reported-by: Arunachalam Ganapathy Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit eca2c185bbbf6105c1972f8a7e109abbe47e0c83 Author: Christophe JAILLET Date: Thu Apr 28 23:16:19 2022 -0700 drivers/base/memory: fix an unlikely reference counting issue in __add_memory_block() [ Upstream commit f47f758cff59c68015d6b9b9c077110df7c2c828 ] __add_memory_block() calls both put_device() and device_unregister() when storing the memory block into the xarray. This is incorrect because xarray doesn't take an additional reference and device_unregister() already calls put_device(). Triggering the issue looks really unlikely and its only effect should be to log a spurious warning about a ref counted issue. Link: https://lkml.kernel.org/r/d44c63d78affe844f020dc02ad6af29abc448fc4.1650611702.git.christophe.jaillet@wanadoo.fr Fixes: 4fb6eabf1037 ("drivers/base/memory.c: cache memory blocks in xarray to accelerate lookup") Signed-off-by: Christophe JAILLET Acked-by: Michal Hocko Reviewed-by: David Hildenbrand Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Scott Cheloha Cc: Nathan Lynch Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 42ff63c485eb5218c6cb23d6e562837e20099021 Author: Muchun Song Date: Thu Apr 28 23:16:09 2022 -0700 dax: fix cache flush on PMD-mapped pages [ Upstream commit e583b5c472bd23d450e06f148dc1f37be74f7666 ] The flush_cache_page() only remove a PAGE_SIZE sized range from the cache. However, it does not cover the full pages in a THP except a head page. Replace it with flush_cache_range() to fix this issue. This is just a documentation issue with the respect to properly documenting the expected usage of cache flushing before modifying the pmd. However, in practice this is not a problem due to the fact that DAX is not available on architectures with virtually indexed caches per: commit d92576f1167c ("dax: does not work correctly with virtual aliasing caches") Link: https://lkml.kernel.org/r/20220403053957.10770-3-songmuchun@bytedance.com Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean") Signed-off-by: Muchun Song Reviewed-by: Dan Williams Reviewed-by: Christoph Hellwig Cc: Alistair Popple Cc: Al Viro Cc: Hugh Dickins Cc: Jan Kara Cc: "Kirill A. Shutemov" Cc: Matthew Wilcox Cc: Ralph Campbell Cc: Ross Zwisler Cc: Xiongchun Duan Cc: Xiyu Yang Cc: Yang Shi Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit b3fcf1f583b1a0946d9d9bfb7362c9c186801775 Author: Miaohe Lin Date: Thu Apr 28 23:16:06 2022 -0700 drivers/base/node.c: fix compaction sysfs file leak [ Upstream commit da63dc84befaa9e6079a0bc363ff0eaa975f9073 ] Compaction sysfs file is created via compaction_register_node in register_node. But we forgot to remove it in unregister_node. Thus compaction sysfs file is leaked. Using compaction_unregister_node to fix this issue. Link: https://lkml.kernel.org/r/20220401070905.43679-1-linmiaohe@huawei.com Fixes: ed4a6d7f0676 ("mm: compaction: add /sys trigger for per-node memory compaction") Signed-off-by: Miaohe Lin Cc: Greg Kroah-Hartman Cc: Rafael J. Wysocki Cc: Mel Gorman Cc: Minchan Kim Cc: KAMEZAWA Hiroyuki Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 05f34867b616483913963e2a39c3733290de2462 Author: Krzysztof Kozlowski Date: Fri Apr 22 12:53:38 2022 +0200 pinctrl: mvebu: Fix irq_of_parse_and_map() return value [ Upstream commit 71bc7cf3be65bab441e03667cf215c557712976c ] The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO. Fixes: 2f227605394b ("pinctrl: armada-37xx: Add irqchip support") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220422105339.78810-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 638d39ed2ce65cb9795263be3ce541ee890ebbdd Author: Dan Williams Date: Thu Apr 28 15:47:46 2022 -0700 nvdimm: Allow overwrite in the presence of disabled dimms [ Upstream commit bb7bf697fed58eae9d3445944e457ab0de4da54f ] It is not clear why the original implementation of overwrite support required the dimm driver to be active before overwrite could proceed. In fact that can lead to cases where the kernel retains an invalid cached copy of the labels from before the overwrite. Unfortunately the kernel has not only allowed that case, but enforced it. Going forward, allow for overwrite to happen while the label area is offline, and follow-on with updates to 'ndctl sanitize-dimm --overwrite' to trigger the label area invalidation by default. Cc: Vishal Verma Cc: Dave Jiang Cc: Ira Weiny Cc: Jeff Moyer Reported-by: Krzysztof Kensicki Fixes: 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM overwrite support") Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 2f97ebc58d5fc83ca1528cd553fa725472ab3ca8 Author: Dan Williams Date: Tue Apr 26 13:23:05 2022 -0700 nvdimm: Fix firmware activation deadlock scenarios [ Upstream commit e6829d1bd3c4b58296ee9e412f7ed4d6cb390192 ] Lockdep reports the following deadlock scenarios for CXL root device power-management, device_prepare(), operations, and device_shutdown() operations for 'nd_region' devices: Chain exists of: &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(system_transition_mutex); lock(&nvdimm_bus->reconfig_mutex); lock(system_transition_mutex); lock(&nvdimm_region_key); Chain exists of: &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cxl_root_key); lock(acpi_scan_lock); lock(&cxl_root_key); lock(&cxl_nvdimm_bridge_key); These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec() which walks the entire system device topology taking device_lock() along the way. The nvdimm_bus_lock() is protecting against unregistration, multiple simultaneous ops callers, and preventing activate_show() from racing activate_store(). For the first 2, the lock is redundant. Unregistration already flushes all ops users, and sysfs already prevents multiple threads to be active in an ops handler at the same time. For the last userspace should already be waiting for its last activate_store() to complete, and does not need activate_show() to flush the write side, so this lock usage can be deleted in these attributes. Fixes: 48001ea50d17 ("PM, libnvdimm: Add runtime firmware activation support") Reviewed-by: Ira Weiny Link: https://lore.kernel.org/r/165074883800.4116052.10737040861825806582.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 98342148a8cd242855d7e257f298c966c96dba9f Author: Cristian Marussi Date: Wed Mar 30 16:05:32 2022 +0100 firmware: arm_scmi: Fix list protocols enumeration in the base protocol [ Upstream commit 8009120e0354a67068e920eb10dce532391361d0 ] While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough. Fix the validation avoiding the addition. Link: https://lore.kernel.org/r/20220330150551.2573938-4-cristian.marussi@arm.com Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit cff2553569f3afe8598f9556b17be3071decaf0b Author: Lad Prabhakar Date: Tue Apr 26 08:49:22 2022 +0100 ASoC: sh: rz-ssi: Release the DMA channels in rz_ssi_probe() error path [ Upstream commit 767e6f26204d3f5406630e86b720d01818b8616d ] DMA channels requested by rz_ssi_dma_request() in rz_ssi_probe() were never released in the error path apart from one place. This patch fixes this issue by calling rz_ssi_release_dma_channels() in the error path. Fixes: 26ac471c5354 ("ASoC: sh: rz-ssi: Add SSI DMAC support") Reported-by: Pavel Machek Signed-off-by: Lad Prabhakar Link: https://lore.kernel.org/r/20220426074922.13319-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b7c13643e1f6042e884e8343a66c9d2637009a30 Author: Lad Prabhakar Date: Tue Apr 26 08:49:21 2022 +0100 ASoC: sh: rz-ssi: Propagate error codes returned from platform_get_irq_byname() [ Upstream commit 91686a3984f34df0ab844cdbaa7e4d9621129f5d ] Propagate error codes returned from platform_get_irq_byname() instead of returning -ENODEV. platform_get_irq_byname() may return -EPROBE_DEFER, to handle such cases propagate the error codes. While at it drop the dev_err_probe() messages as platform_get_irq_byname() already does this for us in case of error. Signed-off-by: Lad Prabhakar Link: https://lore.kernel.org/r/20220426074922.13319-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 94241e74b79cbe90530996b73110bc9d1cba9196 Author: Heiner Kallweit Date: Fri Dec 17 10:22:31 2021 +0100 ASoC: sh: rz-ssi: Check return value of pm_runtime_resume_and_get() [ Upstream commit f04b4fb47d83b110a5b007fb2eddea862cfeb151 ] The return value of pm_runtime_resume_and_get() needs to be checked to avoid a usage count imbalance in the error case. This fix is basically the same as 92c959bae2e5 ("reset: renesas: Fix Runtime PM usage"), and the last step before pm_runtime_resume_and_get() can be annotated as __must_check. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/9fed506d-b780-55cd-45a4-9bd2407c910f@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d5e9dd4f651e7fc82655fe1efb3489e9a022d1d4 Author: Matthias Schiffer Date: Tue Apr 19 09:51:57 2022 +0200 arm64: dts: ti: k3-am64-mcu: remove incorrect UART base clock rates [ Upstream commit 439677d416b17dd39964d5f7d64b742a2e51da5b ] We found that (at least some versions of) the sci-fw set the base clock rate for UARTs in the MCU domain to 96 MHz instead of the expected 48 MHz, leading to incorrect baud rates when used from Linux. As the 8250_omap driver will query the actual clock rate from the clk driver when clock-frequency is unset, removing the incorrect property is sufficient to fix the baud rate. Fixes: 8abae9389bdb ("arm64: dts: ti: Add support for AM642 SoC") Signed-off-by: Matthias Schiffer Signed-off-by: Vignesh Raghavendra Reviewed-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20220419075157.189347-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Sasha Levin commit 5650e103bfc70156001615861fb8aafb3947da6e Author: QintaoShen Date: Thu Mar 24 16:35:40 2022 +0800 soc: bcm: Check for NULL return of devm_kzalloc() [ Upstream commit b4bd2aafacce48db26b0a213d849818d940556dd ] As the potential failure of allocation, devm_kzalloc() may return NULL. Then the 'pd->pmb' and the follow lines of code may bring null pointer dereference. Therefore, it is better to check the return value of devm_kzalloc() to avoid this confusion. Fixes: 8bcac4011ebe ("soc: bcm: add PM driver for Broadcom's PMB") Signed-off-by: QintaoShen Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 45f1920e26ebebf5611dc1094cb5a511f57f8015 Author: Gustavo A. R. Silva Date: Thu Mar 3 17:55:21 2022 -0600 scsi: fcoe: Fix Wstringop-overflow warnings in fcoe_wwn_from_mac() [ Upstream commit 54db804d5d7d36709d1ce70bde3b9a6c61b290b6 ] Fix the following Wstringop-overflow warnings when building with GCC-11: drivers/scsi/fcoe/fcoe.c: In function ‘fcoe_netdev_config’: drivers/scsi/fcoe/fcoe.c:744:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 744 | wwnn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, 1, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/fcoe/fcoe.c:744:32: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/fcoe/fcoe.c:36: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ drivers/scsi/fcoe/fcoe.c:747:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 747 | wwpn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 748 | 2, 0); | ~~~~~ drivers/scsi/fcoe/fcoe.c:747:32: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/fcoe/fcoe.c:36: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ CC drivers/scsi/bnx2fc/bnx2fc_io.o In function ‘bnx2fc_net_config’, inlined from ‘bnx2fc_if_create’ at drivers/scsi/bnx2fc/bnx2fc_fcoe.c:1543:7: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:833:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 833 | wwnn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 834 | 1, 0); | ~~~~~ drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function ‘bnx2fc_if_create’: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:833:32: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/bnx2fc/bnx2fc.h:53, from drivers/scsi/bnx2fc/bnx2fc_fcoe.c:17: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ In function ‘bnx2fc_net_config’, inlined from ‘bnx2fc_if_create’ at drivers/scsi/bnx2fc/bnx2fc_fcoe.c:1543:7: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:839:32: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 839 | wwpn = fcoe_wwn_from_mac(ctlr->ctl_src_addr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 840 | 2, 0); | ~~~~~ drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function ‘bnx2fc_if_create’: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:839:32: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/bnx2fc/bnx2fc.h:53, from drivers/scsi/bnx2fc/bnx2fc_fcoe.c:17: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ drivers/scsi/qedf/qedf_main.c: In function ‘__qedf_probe’: drivers/scsi/qedf/qedf_main.c:3520:30: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 3520 | qedf->wwnn = fcoe_wwn_from_mac(qedf->mac, 1, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/qedf/qedf_main.c:3520:30: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/qedf/qedf.h:9, from drivers/scsi/qedf/qedf_main.c:23: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ drivers/scsi/qedf/qedf_main.c:3521:30: warning: ‘fcoe_wwn_from_mac’ accessing 32 bytes in a region of size 6 [-Wstringop-overflow=] 3521 | qedf->wwpn = fcoe_wwn_from_mac(qedf->mac, 2, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/qedf/qedf_main.c:3521:30: note: referencing argument 1 of type ‘unsigned char *’ In file included from drivers/scsi/qedf/qedf.h:9, from drivers/scsi/qedf/qedf_main.c:23: ./include/scsi/libfcoe.h:252:5: note: in a call to function ‘fcoe_wwn_from_mac’ 252 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int); | ^~~~~~~~~~~~~~~~~ by changing the array size to the correct value of ETH_ALEN in the argument declaration. Also, fix a couple of checkpatch warnings: WARNING: function definition argument 'unsigned int' should also have an identifier name This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/181 Fixes: 85b4aa4926a5 ("[SCSI] fcoe: Fibre Channel over Ethernet") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Sasha Levin commit c762c4206bb440736def860a994d6e2cb6fa7b15 Author: Lv Ruyi Date: Tue Apr 12 08:53:05 2022 +0000 mfd: ipaq-micro: Fix error check return value of platform_get_irq() [ Upstream commit 3b49ae380ce1a3054e0c505dd9a356b82a5b48e8 ] platform_get_irq() return negative value on failure, so null check of irq is incorrect. Fix it by comparing whether it is less than zero. Fixes: dcc21cc09e3c ("mfd: Add driver for Atmel Microcontroller on iPaq h3xxx") Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Reviewed-by: Linus Walleij Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220412085305.2533030-1-lv.ruyi@zte.com.cn Signed-off-by: Sasha Levin commit 2db3a8f54184228a0d93e8f538aeeb7e6629274c Author: Hari Bathini Date: Wed Apr 6 15:08:37 2022 +0530 powerpc/fadump: fix PT_LOAD segment for boot memory area [ Upstream commit 15eb77f873255cf9f4d703b63cfbd23c46579654 ] Boot memory area is setup as separate PT_LOAD segment in the vmcore as it is moved by f/w, on crash, to a destination address provided by the kernel. Having separate PT_LOAD segment helps in handling the different physical address and offset for boot memory area in the vmcore. Commit ced1bf52f477 ("powerpc/fadump: merge adjacent memory ranges to reduce PT_LOAD segements") inadvertly broke this pre-condition for cases where some of the first kernel memory is available adjacent to boot memory area. This scenario is rare but possible when memory for fadump could not be reserved adjacent to boot memory area owing to memory hole or such. Reading memory from a vmcore exported in such scenario provides incorrect data. Fix it by ensuring no other region is folded into boot memory area. Fixes: ced1bf52f477 ("powerpc/fadump: merge adjacent memory ranges to reduce PT_LOAD segements") Signed-off-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220406093839.206608-2-hbathini@linux.ibm.com Signed-off-by: Sasha Levin commit 40c84e778e5fdab3a84f46258319b1b8967126b9 Author: Andrea Parri (Microsoft) Date: Tue Apr 19 14:23:20 2022 +0200 Drivers: hv: vmbus: Fix handling of messages with transaction ID of zero [ Upstream commit 82cd4bacff88a11e36f143e2cb950174b09c86c3 ] vmbus_request_addr() returns 0 (zero) if the transaction ID passed to as argument is 0. This is unfortunate for two reasons: first, netvsc_send_completion() does not check for a NULL cmd_rqst (before dereferencing the corresponding NVSP message); second, 0 is a *valid* value of cmd_rqst in netvsc_send_tx_complete(), cf. the call of vmbus_sendpacket() in netvsc_send_pkt(). vmbus_request_addr() has included the code in question since its introduction with commit e8b7db38449ac ("Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening"); such code was motivated by the early use of vmbus_requestor by hv_storvsc. Since hv_storvsc moved to a tag-based mechanism to generate and retrieve transaction IDs with commit bf5fd8cae3c8f ("scsi: storvsc: Use blk_mq_unique_tag() to generate requestIDs"), vmbus_request_addr() can be modified to return VMBUS_RQST_ERROR if the ID is 0. This change solves the issues in hv_netvsc (and makes the handling of messages with transaction ID of 0 consistent with the semantics "the ID is not contained in the requestor/invalid ID"). vmbus_next_request_id(), vmbus_request_addr() should still reserve the ID of 0 for Hyper-V, because Hyper-V will "ignore" (not respond to) VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED packets/requests with transaction ID of 0 from the guest. Fixes: bf5fd8cae3c8f ("scsi: storvsc: Use blk_mq_unique_tag() to generate requestIDs") Signed-off-by: Andrea Parri (Microsoft) Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20220419122325.10078-2-parri.andrea@gmail.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit c43efa63a61072d482ddaea6be749520c156d193 Author: Vinod Koul Date: Thu Apr 21 13:05:02 2022 +0530 arm64: dts: qcom: qrb5165-rb5: Fix can-clock node name [ Upstream commit 1eae95fb1d696968ca72be3ac8e0d62bb4d8da42 ] Per DT spec node names should not have underscores (_) in them, so change can_clock to can-clock. Fixes: 5c44c564e449 ("arm64: dts: qcom: qrb5165-rb5: Add support for MCP2518FD") Signed-off-by: Vinod Koul Acked-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220421073502.1824089-1-vkoul@kernel.org Signed-off-by: Sasha Levin commit 01d4fe0380f9bad6fca500ea9393d00812624089 Author: Fabien Parent Date: Sun Mar 27 18:08:13 2022 +0200 pinctrl: mediatek: mt8195: enable driver on mtk platforms [ Upstream commit 931d7fa89e640dea146e00b77c1d73459e66ab6e ] Set the pinctrl driver as built-in by default if ARM64 and ARCH_MEDIATEK are enabled. Fixes: 6cf5e9ef362a ("pinctrl: add pinctrl driver on mt8195") Signed-off-by: Fabien Parent Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Miles Chen Link: https://lore.kernel.org/r/20220327160813.2978637-1-fparent@baylibre.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit dbd72f452e2126327c3c4ff105643e452c86fdac Author: Caleb Connolly Date: Mon Mar 28 01:50:02 2022 +0100 pinctrl/rockchip: support deferring other gpio params [ Upstream commit 8ce5ef64546850294b021497046588a7abcebe96 ] Add support for deferring other params like PIN_CONFIG_INPUT_ENABLE. This will be used to add support for PIN_CONFIG_INPUT_ENABLE to the driver. Fixes: e7165b1dff06 ("pinctrl/rockchip: add a queue for deferred pin output settings on probe") Fixes: 59dd178e1d7c ("gpio/rockchip: fetch deferred output settings on probe") Signed-off-by: Caleb Connolly Link: https://lore.kernel.org/r/20220328005005.72492-2-kc@postmarketos.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ffea838686b82fbb2801cdfad6ba5309d15c032d Author: Chuanhong Guo Date: Sat Apr 9 17:13:47 2022 +0800 arm: mediatek: select arch timer for mt7629 [ Upstream commit d66aea197d534e23d4989eb72fca9c0c114b97c9 ] This chip has an armv7 arch timer according to the dts. Select it in Kconfig to enforce the support for it. Otherwise the system time is just completely wrong if user forget to enable ARM_ARCH_TIMER in kernel config. Fixes: a43379dddf1b ("arm: mediatek: add MT7629 smp bring up code") Signed-off-by: Chuanhong Guo Link: https://lore.kernel.org/r/20220409091347.2473449-1-gch981213@gmail.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 2b9f355ad891520525edaf8a0d100423bffe19ca Author: Stefan Wahren Date: Sat Apr 9 11:51:29 2022 +0200 pinctrl: bcm2835: implement hook for missing gpio-ranges [ Upstream commit d2b67744fd99b06555b7e4d67302ede6c7c6a638 ] The commit c8013355ead6 ("ARM: dts: gpio-ranges property is now required") fixed the GPIO probing issues caused by "pinctrl: bcm2835: Change init order for gpio hogs". This changed only the kernel DTS files. Unfortunately it isn't guaranteed that these files are shipped to all users. So implement the necessary backward compatibility for BCM2835 and BCM2711 platform. Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs") Signed-off-by: Stefan Wahren Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20220409095129.45786-3-stefan.wahren@i2se.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 20340be21699b35591fbcded4aa09d0aa8479c83 Author: Stefan Wahren Date: Sat Apr 9 11:51:28 2022 +0200 gpiolib: of: Introduce hook for missing gpio-ranges [ Upstream commit 3550bba25d5587a701e6edf20e20984d2ee72c78 ] Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") the device tree nodes of GPIO controller need the gpio-ranges property to handle gpio-hogs. Unfortunately it's impossible to guarantee that every new kernel is shipped with an updated device tree binary. In order to provide backward compatibility with those older DTB, we need a callback within of_gpiochip_add_pin_range() so the relevant platform driver can handle this case. Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Signed-off-by: Stefan Wahren Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Acked-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ef1e9def63e403d8c0d0d8f7fd167d54b49ed9a4 Author: Corentin Labbe Date: Wed Apr 13 19:11:54 2022 +0000 crypto: marvell/cesa - ECB does not IV [ Upstream commit 4ffa1763622ae5752961499588f3f8874315f974 ] The DES3 ECB has an IV size set but ECB does not need one. Fixes: 4ada483978237 ("crypto: marvell/cesa - add Triple-DES support") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8fb674216835e1f0c143762696d645facebb4685 Author: Hangyu Hua Date: Mon Apr 18 16:57:58 2022 +0800 misc: ocxl: fix possible double free in ocxl_file_register_afu [ Upstream commit 950cf957fe34d40d63dfa3bf3968210430b6491e ] info_release() will be called in device_unregister() when info->dev's reference count is 0. So there is no need to call ocxl_afu_put() and kfree() again. Fix this by adding free_minor() and return to err_unregister error path. Fixes: 75ca758adbaf ("ocxl: Create a clear delineation between ocxl backend & frontend") Signed-off-by: Hangyu Hua Acked-by: Frederic Barrat Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220418085758.38145-1-hbh25y@gmail.com Signed-off-by: Sasha Levin commit 11ee8e960007b5f0a9d34078fbf02d3580b97733 Author: Stefan Wahren Date: Mon Apr 11 22:01:41 2022 +0200 ARM: dts: bcm2835-rpi-b: Fix GPIO line names [ Upstream commit 97bd8659c1c46c23e4daea7e040befca30939950 ] Recently this has been fixed in the vendor tree, so upstream this. Fixes: 731b26a6ac17 ("ARM: bcm2835: Add names for the Raspberry Pi GPIO lines") Signed-off-by: Phil Elwell Signed-off-by: Stefan Wahren Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit fafc8daf0a2471b8abc348be0073c347ca1a7afd Author: Phil Elwell Date: Mon Apr 11 22:01:40 2022 +0200 ARM: dts: bcm2837-rpi-3-b-plus: Fix GPIO line name of power LED [ Upstream commit 57f718aa4b93392fb1a8c0a874ab882b9e18136a ] The red LED on the Raspberry Pi 3 B Plus is the power LED. So fix the GPIO line name accordingly. Fixes: 71c0cd2283f2 ("ARM: dts: bcm2837: Add Raspberry Pi 3 B+") Signed-off-by: Phil Elwell Signed-off-by: Stefan Wahren Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit fdafe0bb000e7da7904e9e98f79217f4f0bcfe62 Author: Phil Elwell Date: Mon Apr 11 22:01:39 2022 +0200 ARM: dts: bcm2837-rpi-cm3-io3: Fix GPIO line names for SMPS I2C [ Upstream commit 9fd26fd02749ec964eb0d588a3bab9e09bf77927 ] The GPIOs 46 & 47 are already used for a I2C interface to a SMPS. So fix the GPIO line names accordingly. Fixes: a54fe8a6cf66 ("ARM: dts: add Raspberry Pi Compute Module 3 and IO board") Signed-off-by: Phil Elwell Signed-off-by: Stefan Wahren Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit a444bafd72f3d71a76c665ec2ec0de58dac5b055 Author: Phil Elwell Date: Mon Apr 11 22:01:38 2022 +0200 ARM: dts: bcm2835-rpi-zero-w: Fix GPIO line name for Wifi/BT [ Upstream commit 2c663e5e5bbf2a5b85e0f76ccb69663f583c3e33 ] The GPIOs 30 to 39 are connected to the Cypress CYW43438 (Wifi/BT). So fix the GPIO line names accordingly. Fixes: 2c7c040c73e9 ("ARM: dts: bcm2835: Add Raspberry Pi Zero W") Signed-off-by: Phil Elwell Signed-off-by: Stefan Wahren Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 775992b4cb1d48703aa6969ff8e20ed4df007b4a Author: Marek Vasut Date: Fri Mar 25 18:58:51 2022 +0100 ARM: dts: stm32: Fix PHY post-reset delay on Avenger96 [ Upstream commit ef2d90708883f4025a801feb0ba8411a7a4387e1 ] Per KSZ9031RNX PHY datasheet FIGURE 7-5: POWER-UP/POWER-DOWN/RESET TIMING Note 2: After the de-assertion of reset, wait a minimum of 100 μs before starting programming on the MIIM (MDC/MDIO) interface. Add 1ms post-reset delay to guarantee this figure. Fixes: 010ca9fe500bf ("ARM: dts: stm32: Add missing ethernet PHY reset on AV96") Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit ec65a8d8ca30c9b69b73897362c2d300e9658460 Author: Marc Kleine-Budde Date: Thu Mar 17 21:29:07 2022 +0100 can: xilinx_can: mark bit timing constants as const [ Upstream commit ae38fda02996d43d9fb09f16e81e0008704dd524 ] This patch marks the bit timing constants as const. Fixes: c223da689324 ("can: xilinx_can: Add support for CANFD FD frames") Link: https://lore.kernel.org/all/20220317203119.792552-1-mkl@pengutronix.de Cc: Appana Durga Kedareswara rao Cc: Naga Sureshkumar Relli Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 6830891ed5e4dd49dc3da3a6b278a89b7bba43fc Author: Guenter Roeck Date: Fri Mar 18 09:54:22 2022 -0700 platform/chrome: Re-introduce cros_ec_cmd_xfer and use it for ioctls [ Upstream commit 57b888ca2541785de2fcb90575b378921919b6c0 ] Commit 413dda8f2c6f ("platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helper") inadvertendly changed the userspace ABI. Previously, cros_ec ioctls would only report errors if the EC communication failed, and otherwise return success and the result of the EC communication. An EC command execution failure was reported in the EC response field. The above mentioned commit changed this behavior, and the ioctl itself would fail. This breaks userspace commands trying to analyze the EC command execution error since the actual EC command response is no longer reported to userspace. Fix the problem by re-introducing the cros_ec_cmd_xfer() helper, and use it to handle ioctl messages. Fixes: 413dda8f2c6f ("platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helper") Cc: Daisuke Nojiri Cc: Rob Barnes Cc: Rajat Jain Cc: Brian Norris Cc: Parth Malkan Reviewed-by: Daisuke Nojiri Reviewed-by: Brian Norris Signed-off-by: Guenter Roeck Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit fc1e9dd97cec28e4355f533bb4c30de71211e081 Author: Max Krummenacher Date: Mon Apr 11 17:22:24 2022 +0200 ARM: dts: imx6dl-colibri: Fix I2C pinmuxing [ Upstream commit 5f5c579a34a87117c20b411df583ae816c1ec84f ] Fix names of extra pingroup node and property for gpio bus recovery. Without the change i2c2 is not functional. Fixes: 56f0df6b6b58 ("ARM: dts: imx*(colibri|apalis): add missing recovery modes to i2c") Signed-off-by: Max Krummenacher Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 9816480848c3e2b0c9c8c75b0180b17ab6a8d84d Author: Tzung-Bi Shih Date: Wed Feb 16 16:03:02 2022 +0800 platform/chrome: cros_ec: fix error handling in cros_ec_register() [ Upstream commit 2cd01bd6b117df07b1bc2852f08694fdd29e40ed ] Fix cros_ec_register() to unregister platform devices if blocking_notifier_chain_register() fails. Also use the single exit path to handle the platform device unregistration. Fixes: 42cd0ab476e2 ("platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW") Reviewed-by: Prashant Malani Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 55e1c42d968f1dc14e32cbc535d65d9a73602b7d Author: Giovanni Cabiddu Date: Thu Apr 7 17:54:41 2022 +0100 crypto: qat - set COMPRESSION capability for DH895XCC [ Upstream commit 0eaa51543273fd0f4ba9bea83638f7033436e5eb ] The capability detection logic clears bits for the features that are disabled in a certain SKU. For example, if the bit associate to compression is not present in the LEGFUSE register, the correspondent bit is cleared in the capability mask. This change adds the compression capability to the mask as this was missing in the commit that enhanced the capability detection logic. Fixes: cfe4894eccdc ("crypto: qat - set COMPRESSION capability for QAT GEN2") Signed-off-by: Giovanni Cabiddu Signed-off-by: Marco Chiappero Reviewed-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7829a859582500acd0ab88167cfbf19b8433ee83 Author: Giovanni Cabiddu Date: Thu Apr 7 17:54:40 2022 +0100 crypto: qat - set CIPHER capability for DH895XCC [ Upstream commit 6a23804cb8bcb85c6998bf193d94d4036db26f51 ] Set the CIPHER capability for QAT DH895XCC devices if the hardware supports it. This is done if both the CIPHER and the AUTHENTICATION engines are available on the device. Fixes: ad1332aa67ec ("crypto: qat - add support for capability detection") Signed-off-by: Giovanni Cabiddu Signed-off-by: Marco Chiappero Reviewed-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bb170dac3b7f8c76a2c58212e274a507f502a0ea Author: Giovanni Cabiddu Date: Thu Dec 16 09:13:13 2021 +0000 crypto: qat - set COMPRESSION capability for QAT GEN2 [ Upstream commit cfe4894eccdc7fa5cd35bf34e918614d06ecce38 ] Enhance the device capability detection for QAT GEN2 devices to detect if a device supports the compression service. This is done by checking both the fuse and the strap registers for c62x and c3xxx and only the fuse register for dh895xcc. Signed-off-by: Giovanni Cabiddu Signed-off-by: Marco Chiappero Reviewed-by: Fiona Trahe Reviewed-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 69f4641ad4924d4cee609478353c6fc3f420b65b Author: Giovanni Cabiddu Date: Thu Dec 16 09:13:12 2021 +0000 crypto: qat - set CIPHER capability for QAT GEN2 [ Upstream commit 547bde7bd4ecd78f36f98744e6c9a0999e52da5a ] Set the CIPHER capability for QAT GEN2 devices if the hardware supports it. This is done if both the CIPHER and the AUTHENTICATION engines are available on the device. Signed-off-by: Giovanni Cabiddu Signed-off-by: Marco Chiappero Reviewed-by: Fiona Trahe Reviewed-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 99ace864e53ea3b3de8b805631dfebd1818d0c0b Author: Sean Christopherson Date: Thu Apr 7 00:23:15 2022 +0000 KVM: nVMX: Clear IDT vectoring on nested VM-Exit for double/triple fault [ Upstream commit 9bd1f0efa859b61950d109b32ff8d529cc33a3ad ] Clear the IDT vectoring field in vmcs12 on next VM-Exit due to a double or triple fault. Per the SDM, a VM-Exit isn't considered to occur during event delivery if the exit is due to an intercepted double fault or a triple fault. Opportunistically move the default clearing (no event "pending") into the helper so that it's more obvious that KVM does indeed handle this case. Note, the double fault case is worded rather wierdly in the SDM: The original event results in a double-fault exception that causes the VM exit directly. Temporarily ignoring injected events, double faults can _only_ occur if an exception occurs while attempting to deliver a different exception, i.e. there's _always_ an original event. And for injected double fault, while there's no original event, injected events are never subject to interception. Presumably the SDM is calling out that a the vectoring info will be valid if a different exit occurs after a double fault, e.g. if a #PF occurs and is intercepted while vectoring #DF, then the vectoring info will show the double fault. In other words, the clause can simply be read as: The VM exit is caused by a double-fault exception. Fixes: 4704d0befb07 ("KVM: nVMX: Exiting from L2 to L1") Cc: Chenyi Qiang Signed-off-by: Sean Christopherson Message-Id: <20220407002315.78092-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit a1d52910a0f46abac76f99ea409e8d91f4e6e1c9 Author: Sean Christopherson Date: Thu Apr 7 00:23:14 2022 +0000 KVM: nVMX: Leave most VM-Exit info fields unmodified on failed VM-Entry [ Upstream commit c3634d25fbee88e2368a8e0903ae0d0670eb9e71 ] Don't modify vmcs12 exit fields except EXIT_REASON and EXIT_QUALIFICATION when performing a nested VM-Exit due to failed VM-Entry. Per the SDM, only the two aformentioned fields are filled and "All other VM-exit information fields are unmodified". Fixes: 4704d0befb07 ("KVM: nVMX: Exiting from L2 to L1") Signed-off-by: Sean Christopherson Message-Id: <20220407002315.78092-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 854904552ee71bae0a2977f7faf0332d9acba2ce Author: Bjorn Andersson Date: Fri Apr 8 14:33:36 2022 -0700 soc: qcom: llcc: Add MODULE_DEVICE_TABLE() [ Upstream commit 5334a3b12a7233b31788de60d61bfd890059d783 ] The llcc-qcom driver can be compiled as a module, but lacks MODULE_DEVICE_TABLE() and will therefore not be loaded automatically. Fix this. Fixes: a3134fb09e0b ("drivers: soc: Add LLCC driver") Signed-off-by: Bjorn Andersson Reviewed-by: Sai Prakash Ranjan Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220408213336.581661-3-bjorn.andersson@linaro.org Signed-off-by: Sasha Levin commit 940808971b19a7665fdb699de46ad2c18275d04e Author: Thorsten Scherer Date: Wed Apr 6 06:39:45 2022 +0200 ARM: dts: ci4x10: Adapt to changes in imx6qdl.dtsi regarding fec clocks [ Upstream commit 3d397a1277853498e8b7b305f2610881357c033f ] Commit f3e7dae323ab ("ARM: dts: imx6qdl: add enet_out clk support") added another item to the list of clocks for the fec device. As imx6dl-eckelmann-ci4x10.dts only overwrites clocks, but not clock-names this resulted in an inconsistency with clocks having one item more than clock-names. Also overwrite clock-names with the same value as in imx6qdl.dtsi. This is a no-op today, but prevents similar inconsistencies if the soc file will be changed in a similar way in the future. Signed-off-by: Thorsten Scherer Reviewed-by: Uwe Kleine-König Fixes: f3e7dae323ab ("ARM: dts: imx6qdl: add enet_out clk support") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 16c25287acd0aaadb7dd70c5133f7d5b6e6711a3 Author: Jiantao Zhang Date: Wed Mar 9 20:01:04 2022 +0800 PCI: dwc: Fix setting error return on MSI DMA mapping failure [ Upstream commit 88557685cd72cf0db686a4ebff3fad4365cb6071 ] When dma_mapping_error() returns error because of no enough memory, but dw_pcie_host_init() returns success, which will mislead the callers. Link: https://lore.kernel.org/r/30170911-0e2f-98ce-9266-70465b9073e5@huawei.com Fixes: 07940c369a6b ("PCI: dwc: Fix MSI page leakage in suspend/resume") Signed-off-by: Jianrong Zhang Signed-off-by: Jiantao Zhang Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Signed-off-by: Sasha Levin commit ad1c9d13e04509ae24fae8dd2897148657323519 Author: Miaoqian Lin Date: Wed Mar 9 09:19:52 2022 +0000 PCI: mediatek: Fix refcount leak in mtk_pcie_subsys_powerup() [ Upstream commit 214e0d8fe4a813ae6ffd62bc2dfe7544c20914f4 ] The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. Link: https://lore.kernel.org/r/20220309091953.5630-1-linmq006@gmail.com Fixes: 87e8657ba99c ("PCI: mediatek: Add new method to get shared pcie-cfg base address") Signed-off-by: Miaoqian Lin Signed-off-by: Lorenzo Pieralisi Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Miles Chen Acked-by: Rob Herring Signed-off-by: Sasha Levin commit d41a739cc7c17809dcfc26483289e1e2fbac4b4f Author: Dan Carpenter Date: Tue Mar 15 09:59:44 2022 +0300 PCI: rockchip: Fix find_first_zero_bit() limit [ Upstream commit 096950e230b8d83645c7cf408b9f399f58c08b96 ] The ep->ob_region_map bitmap is a long and it has BITS_PER_LONG bits. Link: https://lore.kernel.org/r/20220315065944.GB13572@kili Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller") Signed-off-by: Dan Carpenter Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit d3c684749f8724228a8833858dd3a9dbe5a049fd Author: Dan Carpenter Date: Tue Mar 15 09:58:29 2022 +0300 PCI: cadence: Fix find_first_zero_bit() limit [ Upstream commit 0aa3a0937feeb91a0e4e438c3c063b749b194192 ] The ep->ob_region_map bitmap is a long and it has BITS_PER_LONG bits. Link: https://lore.kernel.org/r/20220315065829.GA13572@kili Fixes: 37dddf14f1ae ("PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller") Signed-off-by: Dan Carpenter Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit c0730d8658c0836c68fca00c9f2c51054273d058 Author: Miaoqian Lin Date: Tue Mar 8 07:36:48 2022 +0000 soc: qcom: smsm: Fix missing of_node_put() in smsm_parse_ipc [ Upstream commit aad66a3c78da668f4506356c2fdb70b7a19ecc76 ] The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Signed-off-by: Miaoqian Lin Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220308073648.24634-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit e13ad5f230493e0895deceb551265af7dd485e7d Author: Miaoqian Lin Date: Tue Mar 8 07:19:42 2022 +0000 soc: qcom: smp2p: Fix missing of_node_put() in smp2p_parse_ipc [ Upstream commit 8fd3f18ea31a398ecce4a6d3804433658678b0a3 ] The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: 50e99641413e ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point") Signed-off-by: Miaoqian Lin Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220308071942.22942-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit 3f4c0083dd9ac85af64e2a06e3f1cfa0195fa0ab Author: Andre Przywara Date: Thu Mar 17 16:23:40 2022 +0000 ARM: dts: suniv: F1C100: fix watchdog compatible [ Upstream commit 01a850ee61cbf0ab77dcbf26bb133fec2dd640d6 ] The F1C100 series of SoCs actually have their watchdog IP being compatible with the newer Allwinner generation, not the older one. The currently described sun4i-a10-wdt actually does not work, neither the watchdog functionality (just never fires), nor the reset part (reboot hangs). Replace the compatible string with the one used by the newer generation. Verified to work with both the watchdog and reboot functionality on a LicheePi Nano. Also add the missing interrupt line and clock source, to make it binding compliant. Fixes: 4ba16d17efdd ("ARM: dts: suniv: add initial DTSI file for F1C100s") Signed-off-by: Andre Przywara Acked-by: Guenter Roeck Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220317162349.739636-4-andre.przywara@arm.com Signed-off-by: Sasha Levin commit 86a8ed8793f8e2c81025b718e4c4e8594d918fcb Author: Rafał Miłecki Date: Wed Mar 30 14:05:27 2022 +0200 ARM: dts: BCM5301X: Update pin controller node name [ Upstream commit 130b5e32ba9d2d2313e39cf3f6d0729bff02b76a ] This fixes: arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dtb: cru-bus@100: 'pin-controller@1c0' does not match any of the regexes: '^clock-controller@[a-f0-9]+$', '^phy@[a-f0-9]+$', '^pinctrl@[a-f0-9]+$', '^syscon@[a-f0-9]+$', '^thermal@[a-f0-9]+$' From schema: Documentation/devicetree/bindings/mfd/brcm,cru.yaml arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dtb: pin-controller@1c0: $nodename:0: 'pin-controller@1c0' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$' From schema: Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml Ref: e7391b021e3f ("dt-bindings: mfd: brcm,cru: Rename pinctrl node") Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 5151f24ac937ff7eb1f078257c66e3c0f0296010 Author: Rafał Miłecki Date: Fri Oct 29 18:05:23 2021 +0200 ARM: dts: BCM5301X: update CRU block description [ Upstream commit 31fd9b79dc580301c53a001482755ba7e88c2809 ] This describes CRU in a way matching documentation and fixes: arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dt.yaml: cru@100: $nodename:0: 'cru@100' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' From schema: /lib/python3.6/site-packages/dtschema/schemas/simple-bus.yaml Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit cd1d22174175ba1b5921c465199f64aa8bb1b8db Author: Christophe JAILLET Date: Sun Mar 20 08:10:30 2022 +0100 memory: samsung: exynos5422-dmc: Avoid some over memory allocation [ Upstream commit 56653827f0d7bc7c2d8bac0e119fd1521fa9990a ] 'dmc->counter' is a 'struct devfreq_event_dev **', so there is some over memory allocation. 'counters_size' should be computed with 'sizeof(struct devfreq_event_dev *)'. Use 'sizeof(*dmc->counter)' instead to fix it. While at it, use devm_kcalloc() instead of devm_kzalloc()+open coded multiplication. Fixes: 6e7674c3c6df ("memory: Add DMC driver for Exynos5422") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/69d7e69346986e2fdb994d4382954c932f9f0993.1647760213.git.christophe.jaillet@wanadoo.fr Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 4cb6687016b4d0237aa89d4b6cb7580e80c42db9 Author: Mario Limonciello Date: Thu Mar 31 22:40:03 2022 -0500 PCI/ACPI: Allow D3 only if Root Port can signal and wake from D3 [ Upstream commit dff6139015dc68e93be3822a7bd406a1d138628b ] acpi_pci_bridge_d3(dev) returns "true" if "dev" is a hotplug bridge that can handle hotplug events while in D3. Previously this meant either: - "dev" has a _PS0 or _PR0 method (acpi_pci_power_manageable()), or - The Root Port above "dev" has a _DSD with a "HotPlugSupportInD3" property with value 1. This did not consider _PRW, which tells us about wakeup GPEs (ACPI v6.4, sec 7.3.13). Without a wakeup GPE, from an ACPI perspective the Root Port has no way of generating wakeup signals, so hotplug events will be lost if we use D3. Similarly, it did not consider _S0W, which tells us the deepest D-state from which a device can wake itself (sec 7.3.20). If _S0W tells us the device cannot wake from D3, hotplug events will again be lost if we use D3. Some platforms, e.g., AMD Yellow Carp, supply "HotPlugSupportInD3" without _PRW or with an _S0W that says the Root Port cannot wake from D3. On those platforms, we previously put bridges in D3hot, hotplug events were lost, and hotplugged devices would not be recognized without manually rescanning. Allow bridges to be put in D3 only if the Root Port can generate wakeup GPEs (wakeup.flags.valid), it can wake from D3 (_S0W), AND it has the "HotPlugSupportInD3" property. Neither Windows 10 nor Windows 11 puts the bridge in D3 when the firmware is configured this way, and this change aligns the handling of the situation to be the same. [bhelgaas: commit log, tidy "HotPlugSupportInD3" check and comment] Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/07_Power_and_Performance_Mgmt/device-power-management-objects.html?highlight=s0w#s0w-s0-device-wake-state Link: https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-pcie-root-ports-supporting-hot-plug-in-d3 Link: https://lore.kernel.org/r/20220401034003.3166-1-mario.limonciello@amd.com Fixes: 26ad34d510a87 ("PCI / ACPI: Whitelist D3 for more PCIe hotplug ports") Signed-off-by: Mario Limonciello Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 364f932433550b93c9a70f528f68ce97bc74392c Author: Allen-KH Cheng Date: Fri Mar 18 22:45:22 2022 +0800 arm64: dts: mt8192: Fix nor_flash status disable typo [ Upstream commit 27f0eb16b0d417c155e96b5d3b89074699944e09 ] Correct nor_flash status disable typo of mt8192 SoC. Fixes: d0a197a0d064a ("arm64: dts: mt8192: add nor_flash device node") Signed-off-by: Allen-KH Cheng Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Miles Chen Reviewed-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20220318144534.17996-11-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit e1d36fb7e70cefa4956cfbb6cb33b1b8cc118cd1 Author: Shawn Lin Date: Tue Mar 15 17:27:06 2022 +0800 arm64: dts: rockchip: Move drive-impedance-ohm to emmc phy on rk3399 [ Upstream commit 4246d0bab2a8685e3d4aec2cb0ef8c526689ce96 ] drive-impedance-ohm is introduced for emmc phy instead of pcie phy. Fixes: fb8b7460c995 ("arm64: dts: rockchip: Define drive-impedance-ohm for RK3399's emmc-phy.") Signed-off-by: Shawn Lin Link: https://lore.kernel.org/r/1647336426-154797-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit a48a7f89494f5335f9e7a799ba9de68c1948f671 Author: Robin Murphy Date: Fri May 20 18:10:13 2022 +0100 dma-direct: don't over-decrypt memory [ Upstream commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 ] The original x86 sev_alloc() only called set_memory_decrypted() on memory returned by alloc_pages_node(), so the page order calculation fell out of that logic. However, the common dma-direct code has several potential allocators, not all of which are guaranteed to round up the underlying allocation to a power-of-two size, so carrying over that calculation for the encryption/decryption size was a mistake. Fix it by rounding to a *number* of pages, rather than an order. Until recently there was an even worse interaction with DMA_DIRECT_REMAP where we could have ended up decrypting part of the next adjacent vmalloc area, only averted by no architecture actually supporting both configs at once. Don't ask how I found that one out... Fixes: c10f07aa27da ("dma/direct: Handle force decryption for DMA coherent buffers in common code") Signed-off-by: Robin Murphy Signed-off-by: Christoph Hellwig Acked-by: David Rientjes Signed-off-by: Sasha Levin commit 5beb74d11eabd745d75bc91947b2721d2bd95deb Author: Christoph Hellwig Date: Tue Nov 9 15:41:01 2021 +0100 dma-direct: always leak memory that can't be re-encrypted [ Upstream commit a90cf30437489343b8386ae87b4827b6d6c3ed50 ] We must never let unencrypted memory go back into the general page pool. So if we fail to set it back to encrypted when freeing DMA memory, leak the memory instead and warn the user. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy Signed-off-by: Sasha Levin commit 9ba801c80c47c1283a570248d8ea3d139fb190d7 Author: Christoph Hellwig Date: Thu Oct 21 09:20:39 2021 +0200 dma-direct: don't call dma_set_decrypted for remapped allocations [ Upstream commit 5570449b6876f215d49ac4db9ccce6ff7aa1e20a ] Remapped allocations handle the encrypted bit through the pgprot passed to vmap, so there is no call dma_set_decrypted. Note that this case is currently entirely theoretical as no valid kernel configuration supports remapped allocations and memory encryption currently. Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 82b3f045aff5b6e40526d48f78b8fd9b0488aa34 Author: Christoph Hellwig Date: Mon Oct 18 13:18:34 2021 +0200 dma-direct: factor out dma_set_{de,en}crypted helpers [ Upstream commit 4d0564785bb03841e4b5c5b31aa4ecd1eb0d01bb ] Factor out helpers the make dealing with memory encryption a little less cumbersome. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy Signed-off-by: Sasha Levin commit 8eb0e5a2659cf7793b675173cbdf9f6ea2be458f Author: liuyacan Date: Mon May 23 12:57:07 2022 +0800 net/smc: postpone sk_refcnt increment in connect() [ Upstream commit 75c1edf23b95a9c66923d9269d8e86e4dbde151f ] Same trigger condition as commit 86434744. When setsockopt runs in parallel to a connect(), and switch the socket into fallback mode. Then the sk_refcnt is incremented in smc_connect(), but its state stay in SMC_INIT (NOT SMC_ACTIVE). This cause the corresponding sk_refcnt decrement in __smc_release() will not be performed. Fixes: 86434744fedf ("net/smc: add fallback check to connect()") Signed-off-by: liuyacan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 23a5767183453bc46b81061ffad3b34435c3068b Author: Randy Dunlap Date: Thu May 19 22:15:23 2022 -0700 net: dsa: restrict SMSC_LAN9303_I2C kconfig [ Upstream commit 0a3ad7d323686fbaae8688326cc5ea0d185c6fca ] Since kconfig 'select' does not follow dependency chains, if symbol KSA selects KSB, then KSA should also depend on the same symbols that KSB depends on, in order to prevent Kconfig warnings and possible build errors. Change NET_DSA_SMSC_LAN9303_I2C and NET_DSA_SMSC_LAN9303_MDIO so that they are limited to VLAN_8021Q if the latter is enabled. This prevents the Kconfig warning: WARNING: unmet direct dependencies detected for NET_DSA_SMSC_LAN9303 Depends on [m]: NETDEVICES [=y] && NET_DSA [=y] && (VLAN_8021Q [=m] || VLAN_8021Q [=m]=n) Selected by [y]: - NET_DSA_SMSC_LAN9303_I2C [=y] && NETDEVICES [=y] && NET_DSA [=y] && I2C [=y] Fixes: 430065e26719 ("net: dsa: lan9303: add VLAN IDs to master device") Signed-off-by: Randy Dunlap Cc: Andrew Lunn Cc: Vivien Didelot Cc: Florian Fainelli Cc: Vladimir Oltean Cc: Juergen Borleis Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Mans Rullgard Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 90920566df881eabda9363278536bb502aa5a391 Author: Christophe JAILLET Date: Sat May 21 08:33:01 2022 +0200 hinic: Avoid some over memory allocation [ Upstream commit 15d221d0c345b76947911a3ac91897ffe2f1cc4e ] 'prod_idx' (atomic_t) is larger than 'shadow_idx' (u16), so some memory is over-allocated. Fixes: b15a9f37be2b ("net-next/hinic: Add wq") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2ba52ad365c118858ef1b49b2a21344903eb5341 Author: Gustavo A. R. Silva Date: Tue Dec 7 22:03:11 2021 -0600 net: huawei: hinic: Use devm_kcalloc() instead of devm_kzalloc() [ Upstream commit 9d922f5df53844228b9f7c62f2593f4f06c0b69b ] Use 2-factor multiplication argument form devm_kcalloc() instead of devm_kzalloc(). Link: https://github.com/KSPP/linux/issues/162 Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20211208040311.GA169838@embeddedor Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d8642575a55d33408549e5a2732855ce0e17293a Author: David Howells Date: Sat May 21 09:03:31 2022 +0100 rxrpc: Fix decision on when to generate an IDLE ACK [ Upstream commit 9a3dedcf18096e8f7f22b8777d78c4acfdea1651 ] Fix the decision on when to generate an IDLE ACK by keeping a count of the number of packets we've received, but not yet soft-ACK'd, and the number of packets we've processed, but not yet hard-ACK'd, rather than trying to keep track of which DATA sequence numbers correspond to those points. We then generate an ACK when either counter exceeds 2. The counters are both cleared when we transcribe the information into any sort of ACK packet for transmission. IDLE and DELAY ACKs are skipped if both counters are 0 (ie. no change). Fixes: 805b21b929e2 ("rxrpc: Send an ACK after every few DATA packets we receive") Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 12098cebf07bb998fd0ab4d4d13ba24e7438e236 Author: David Howells Date: Sat May 21 09:03:24 2022 +0100 rxrpc: Don't let ack.previousPacket regress [ Upstream commit 81524b6312535897707f2942695da1d359a5e56b ] The previousPacket field in the rx ACK packet should never go backwards - it's now the highest DATA sequence number received, not the last on received (it used to be used for out of sequence detection). Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9d5c62e63ae7e7e2c4755e2463d4c91b35b58663 Author: David Howells Date: Sat May 21 09:03:18 2022 +0100 rxrpc: Fix overlapping ACK accounting [ Upstream commit 8940ba3cfe4841928777fd45eaa92051522c7f0c ] Fix accidental overlapping of Rx-phase ACK accounting with Tx-phase ACK accounting through variables shared between the two. call->acks_* members refer to ACKs received in the Tx phase and call->ackr_* members to ACKs sent/to be sent during the Rx phase. Fixes: 1a2391c30c0b ("rxrpc: Fix detection of out of order acks") Signed-off-by: David Howells cc: Jeffrey Altman cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cea2196643b2a67ebd3ea496dade2f32eb2081a7 Author: David Howells Date: Sat May 21 09:03:11 2022 +0100 rxrpc: Don't try to resend the request if we're receiving the reply [ Upstream commit 114af61f88fbe34d641b13922d098ffec4c1be1b ] rxrpc has a timer to trigger resending of unacked data packets in a call. This is not cancelled when a client call switches to the receive phase on the basis that most calls don't last long enough for it to ever expire. However, if it *does* expire after we've started to receive the reply, we shouldn't then go into trying to retransmit or pinging the server to find out if an ack got lost. Fix this by skipping the resend code if we're into receiving the reply to a client call. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b3a9b227d5e7467b8518160ff034ea22bb9de573 Author: David Howells Date: Sat May 21 09:03:04 2022 +0100 rxrpc: Fix listen() setting the bar too high for the prealloc rings [ Upstream commit 88e22159750b0d55793302eeed8ee603f5c1a95c ] AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump up the sysctl), but whilst the preallocation circular buffers have 32 slots in them, one of them has to be a dead slot because we're using CIRC_CNT(). This means that listen(rxrpc_sock, 32) will cause an oops when the socket is closed because rxrpc_service_prealloc_one() allocated one too many calls and rxrpc_discard_prealloc() won't then be able to get rid of them because it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries to abort them, but oopses because call->peer isn't yet set. Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match the ring capacity. BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc] Call Trace: ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc] ? rxrpc_abort_call+0x4c/0x60 [rxrpc] rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc] rxrpc_release+0xc9/0x1c0 [rxrpc] __sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0 Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Marc Dionne Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Link: https://lists.infradead.org/pipermail/linux-afs/2022-March/005079.html Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1047d4ac6677e8fb0cd787da90dec196de5803a5 Author: Adam Wujek Date: Thu May 19 23:34:01 2022 +0000 hwmon: (pmbus) Check PEC support before reading other registers [ Upstream commit d1baf7a3a3177d46a7149858beddb88a9eca7a54 ] Make sure that the support of PEC is determined before the read of other registers. Otherwise the validation of PEC can trigger an error on the read of STATUS_BYTE or STATUS_WORD registers. The problematic scenario is the following. A device with enabled PEC support is up and running and a kernel driver is loaded. Then the driver is unloaded (or device unbound), the HW device is reconfigured externally (e.g. by i2cset) to advertise itself as not supporting PEC. Without the move of the code, at the second load of the driver (or bind) the STATUS_BYTE or STATUS_WORD register is always read with PEC enabled, which is likely to cause a read error resulting with fail of a driver load (or bind). Signed-off-by: Adam Wujek Link: https://lore.kernel.org/r/20220519233334.438621-1-dev_public@wujek.eu Fixes: 75d2b2b06bd84 ("hwmon: (pmbus) disable PEC if not enabled") Fixes: 4e5418f787ec5 ("hwmon: (pmbus_core) Check adapter PEC support") [groeck: Added Fixes: tags, dropped continuation line] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit a459bd84ad41503e301ab9e366b271fb5128af20 Author: Yongzhi Liu Date: Thu May 19 05:09:48 2022 -0700 hv_netvsc: Fix potential dereference of NULL pointer [ Upstream commit eb4c0788964730d12e8dd520bd8f5217ca48321c ] The return value of netvsc_devinfo_get() needs to be checked to avoid use of NULL pointer in case of an allocation failure. Fixes: 0efeea5fb153 ("hv_netvsc: Add the support of hibernation") Signed-off-by: Yongzhi Liu Reviewed-by: Haiyang Zhang Link: https://lore.kernel.org/r/1652962188-129281-1-git-send-email-lyz_cs@pku.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 651c6b2d1dacbddc2fa64738b249e5a42686ebe8 Author: Jakub Kicinski Date: Wed May 18 17:43:05 2022 -0700 net: stmmac: fix out-of-bounds access in a selftest [ Upstream commit fe5c5fc145edcf98a759b895f52b646730eeb7be ] GCC 12 points out that struct tc_action is smaller than struct tcf_action: drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c: In function ‘stmmac_test_rxp’: drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1132:21: warning: array subscript ‘struct tcf_gact[0]’ is partly outside array bounds of ‘unsigned char[272]’ [-Warray-bounds] 1132 | gact->tcf_action = TC_ACT_SHOT; | ^~ Fixes: ccfc639a94f2 ("net: stmmac: selftests: Add a selftest for Flexible RX Parser") Link: https://lore.kernel.org/r/20220519004305.2109708-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 41f3571616acfc7b7db07b6ba54b0c4fe7375e27 Author: Gustavo A. R. Silva Date: Wed Oct 6 13:09:44 2021 -0500 net: stmmac: selftests: Use kcalloc() instead of kzalloc() [ Upstream commit 36371876e000012ae4440fcf3097c2f0ed0f83e7 ] Use 2-factor multiplication argument form kcalloc() instead of kzalloc(). Link: https://github.com/KSPP/linux/issues/162 Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20211006180944.GA913477@embeddedor Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38acee9e1453e7a1ec9fc02ecbc5b1f7a96f0bd1 Author: Alexey Khoroshilov Date: Fri May 20 01:31:26 2022 +0300 ASoC: max98090: Move check for invalid values before casting in max98090_put_enab_tlv() [ Upstream commit f7a344468105ef8c54086dfdc800e6f5a8417d3e ] Validation of signed input should be done before casting to unsigned int. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Alexey Khoroshilov Suggested-by: Mark Brown Fixes: 2fbe467bcbfc ("ASoC: max98090: Reject invalid values in custom control put()") Link: https://lore.kernel.org/r/1652999486-29653-1-git-send-email-khoroshilov@ispras.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a89ca82d6bf2c08d3530e2a7c7613d94e15ce033 Author: Duoming Zhou Date: Wed May 18 19:57:33 2022 +0800 NFC: hci: fix sleep in atomic context bugs in nfc_hci_hcp_message_tx [ Upstream commit b413b0cb008646e9f24ce5253cb3cf7ee217aff6 ] There are sleep in atomic context bugs when the request to secure element of st21nfca is timeout. The root cause is that kzalloc and alloc_skb with GFP_KERNEL parameter and mutex_lock are called in st21nfca_se_wt_timeout which is a timer handler. The call tree shows the execution paths that could lead to bugs: (Interrupt context) st21nfca_se_wt_timeout nfc_hci_send_event nfc_hci_hcp_message_tx kzalloc(..., GFP_KERNEL) //may sleep alloc_skb(..., GFP_KERNEL) //may sleep mutex_lock() //may sleep This patch moves the operations that may sleep into a work item. The work item will run in another kernel thread which is in process context to execute the bottom half of the interrupt. So it could prevent atomic context from sleeping. Fixes: 2130fb97fecf ("NFC: st21nfca: Adding support for secure element") Signed-off-by: Duoming Zhou Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220518115733.62111-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aa5b6d09ff6699ffb39d4f024e95b46c111f50c5 Author: Harini Katakam Date: Wed May 18 22:37:56 2022 +0530 net: macb: Fix PTP one step sync support [ Upstream commit 5cebb40bc9554aafcc492431181f43c6231b0459 ] PTP one step sync packets cannot have CSUM padding and insertion in SW since time stamp is inserted on the fly by HW. In addition, ptp4l version 3.0 and above report an error when skb timestamps are reported for packets that not processed for TX TS after transmission. Add a helper to identify PTP one step sync and fix the above two errors. Add a common mask for PTP header flag field "twoStepflag". Also reset ptp OSS bit when one step is not selected. Fixes: ab91f0a9b5f4 ("net: macb: Add hardware PTP support") Fixes: 653e92a9175e ("net: macb: add support for padding and fcs computation") Signed-off-by: Harini Katakam Reviewed-by: Radhey Shyam Pandey Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220518170756.7752-1-harini.katakam@xilinx.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 37fd61fc7020de778211aa091429d5a7741ecb0e Author: Ulf Hansson Date: Wed May 11 16:57:00 2022 +0200 PM: domains: Fix initialization of genpd's next_wakeup [ Upstream commit 622d9b5577f19a6472db21df042fea8f5fefe244 ] In the genpd governor we walk the list of child-domains to take into account their next_wakeup. If the child-domain itself, doesn't have a governor assigned to it, we can end up using the next_wakeup value before it has been properly initialized. To prevent a possible incorrect behaviour in the governor, let's initialize next_wakeup to KTIME_MAX. Fixes: c79aa080fb0f ("PM: domains: use device's next wakeup to determine domain idle state") Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 85a18d128d18ee88339faee8866d7e20f1a6c518 Author: Yang Yingliang Date: Sat May 14 17:10:53 2022 +0800 ASoC: wm2000: fix missing clk_disable_unprepare() on error in wm2000_anc_transition() [ Upstream commit be2af740e2a9c7134f2d8ab4f104006e110b13de ] Fix the missing clk_disable_unprepare() before return from wm2000_anc_transition() in the error handling case. Fixes: 514cfd6dd725 ("ASoC: wm2000: Integrate with clock API") Signed-off-by: Yang Yingliang Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20220514091053.686416-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cf9c07d8f7e98aeb0e414df477d1fc25e899cf93 Author: Jan Kara Date: Thu May 19 12:52:30 2022 +0200 bfq: Allow current waker to defend against a tentative one [ Upstream commit c5ac56bb6110e42e79d3106866658376b2e48ab9 ] The code in bfq_check_waker() ignores wake up events from the current waker. This makes it more likely we select a new tentative waker although the current one is generating more wake up events. Treat current waker the same way as any other process and allow it to reset the waker detection logic. Fixes: 71217df39dc6 ("block, bfq: make waker-queue detection more robust") Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220519105235.31397-2-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9de82bfc05149e4b58d25097771a120ba5343643 Author: Jan Kara Date: Thu May 19 12:52:29 2022 +0200 bfq: Relax waker detection for shared queues [ Upstream commit f950667356ce90a41b446b726d4595a10cb65415 ] Currently we look for waker only if current queue has no requests. This makes sense for bfq queues with a single process however for shared queues when there is a larger number of processes the condition that queue has no requests is difficult to meet because often at least one process has some request in flight although all the others are waiting for the waker to do the work and this harms throughput. Relax the "no queued request for bfq queue" condition to "the current task has no queued requests yet". For this, we also need to start tracking number of requests in flight for each task. This patch (together with the following one) restores the performance for dbench with 128 clients that regressed with commit c65e6fd460b4 ("bfq: Do not let waker requests skip proper accounting") because this commit makes requests of wakers properly enter BFQ queues and thus these queues become ineligible for the old waker detection logic. Dbench results: Vanilla 5.18-rc3 5.18-rc3 + revert 5.18-rc3 patched Mean 1237.36 ( 0.00%) 950.16 * 23.21%* 988.35 * 20.12%* Numbers are time to complete workload so lower is better. Fixes: c65e6fd460b4 ("bfq: Do not let waker requests skip proper accounting") Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220519105235.31397-1-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3ade442ea5d3512a3c67984489ab4d8a6fb3b29f Author: Miaoqian Lin Date: Tue May 17 09:51:21 2022 +0400 thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe [ Upstream commit 09700c504d8e63faffd2a2235074e8c5d130cb8f ] of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: e20db70dba1c ("thermal: imx_sc: add i.MX system controller thermal support") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220517055121.18092-1-linmq006@gmail.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 21ccc58b671aea924f2481cf5c1cf0ebbfd3552d Author: Yang Yingliang Date: Wed May 11 10:06:05 2022 +0800 thermal/core: Fix memory leak in __thermal_cooling_device_register() [ Upstream commit 98a160e898c0f4a979af9de3ab48b4b1d42d1dbb ] I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888010080000 (size 264312): comm "182", pid 102533, jiffies 4296434960 (age 10.100s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 40 7f 1f b9 ff ff ff ff ........@....... backtrace: [<0000000038b2f4fc>] kmalloc_order_trace+0x1d/0x110 mm/slab_common.c:969 [<00000000ebcb8da5>] __kmalloc+0x373/0x420 include/linux/slab.h:510 [<0000000084137f13>] thermal_cooling_device_setup_sysfs+0x15d/0x2d0 include/linux/slab.h:586 [<00000000352b8755>] __thermal_cooling_device_register+0x332/0xa60 drivers/thermal/thermal_core.c:927 [<00000000fb9f331b>] devm_thermal_of_cooling_device_register+0x6b/0xf0 drivers/thermal/thermal_core.c:1041 [<000000009b8012d2>] max6650_probe.cold+0x557/0x6aa drivers/hwmon/max6650.c:211 [<00000000da0b7e04>] i2c_device_probe+0x472/0xac0 drivers/i2c/i2c-core-base.c:561 If device_register() fails, thermal_cooling_device_destroy_sysfs() need be called to free the memory allocated in thermal_cooling_device_setup_sysfs(). Fixes: 8ea229511e06 ("thermal: Add cooling device's statistics in sysfs") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20220511020605.3096734-1-yangyingliang@huawei.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit ef1235c6514a58f274246cf4a2d5f4e40af539ce Author: Zheng Yongjun Date: Mon Apr 25 09:29:29 2022 +0000 thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe [ Upstream commit e20d136ec7d6f309989c447638365840d3424c8e ] platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. Fixes: 250e211057c72 ("thermal: broadcom: Add Stingray thermal driver") Signed-off-by: Zheng Yongjun Link: https://lore.kernel.org/r/20220425092929.90412-1-zhengyongjun3@huawei.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit c4e1280abead1552e1764684079a43e222ccd163 Author: Stefan Wahren Date: Tue Apr 12 21:54:23 2022 +0200 thermal/drivers/bcm2711: Don't clamp temperature at zero [ Upstream commit 106e0121e243de4da7d634338089a68a8da2abe9 ] The thermal sensor on BCM2711 is capable of negative temperatures, so don't clamp the measurements at zero. Since this was the only use for variable t, drop it. This change based on a patch by Dom Cobley, who also tested the fix. Fixes: 59b781352dc4 ("thermal: Add BCM2711 thermal driver") Signed-off-by: Stefan Wahren Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20220412195423.104511-1-stefan.wahren@i2se.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit d50d1c703bbd8930d11e5bc01e2cc3c8dcda8f4b Author: Nathan Chancellor Date: Fri May 13 08:51:36 2022 +0100 drm/i915: Fix CFI violation with show_dynamic_id() [ Upstream commit 58606220a2f1407a7516c547f09a1ba7b4350a73 ] When an attribute group is created with sysfs_create_group(), the ->sysfs_ops() callback is set to kobj_sysfs_ops, which sets the ->show() callback to kobj_attr_show(). kobj_attr_show() uses container_of() to get the ->show() callback from the attribute it was passed, meaning the ->show() callback needs to be the same type as the ->show() callback in 'struct kobj_attribute'. However, show_dynamic_id() has the type of the ->show() callback in 'struct device_attribute', which causes a CFI violation when opening the 'id' sysfs node under drm/card0/metrics. This happens to work because the layout of 'struct kobj_attribute' and 'struct device_attribute' are the same, so the container_of() cast happens to allow the ->show() callback to still work. Change the type of show_dynamic_id() to match the ->show() callback in 'struct kobj_attributes' and update the type of sysfs_metric_id to match, which resolves the CFI violation. Fixes: f89823c21224 ("drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG interface") Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Reviewed-by: Sami Tolvanen Signed-off-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20220513075136.1027007-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 18fb42db05a0b93ab5dd5eab5315e50eaa3ca620) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit a1bcaea4afcab09f8fc8fad5d0babf9e245b7e39 Author: Abhinav Kumar Date: Wed May 18 15:34:07 2022 -0700 drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path [ Upstream commit 64b22a0da12adb571c01edd671ee43634ebd7e41 ] If there are errors while trying to enable the pm in the bind path, it will lead to unclocked access of hw revision register thereby crashing the device. This will not address why the pm_runtime_get_sync() fails but at the very least we should be able to prevent the crash by handling the error and bailing out earlier. changes in v2: - use pm_runtime_resume_and_get() instead of pm_runtime_get_sync() Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Abhinav Kumar Reviewed-by: Rob Clark Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/486721/ Link: https://lore.kernel.org/r/20220518223407.26147-1-quic_abhinavk@quicinc.com Signed-off-by: Abhinav Kumar Signed-off-by: Sasha Levin commit 3e6a23ce7460c356426494818609822985fa3824 Author: Hangbin Liu Date: Mon May 16 12:00:20 2022 +0800 selftests/bpf: Add missed ima_setup.sh in Makefile [ Upstream commit 70a1b25326dd77e145157ccf1a31c1948032eec4 ] When build bpf test and install it to another folder, e.g. make -j10 install -C tools/testing/selftests/ TARGETS="bpf" \ SKIP_TARGETS="" INSTALL_PATH=/tmp/kselftests The ima_setup.sh is missed in target folder, which makes test_ima failed. Fix it by adding ima_setup.sh to TEST_PROGS_EXTENDED. Fixes: 34b82d3ac105 ("bpf: Add a selftest for bpf_ima_inode_hash") Signed-off-by: Hangbin Liu Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20220516040020.653291-1-liuhangbin@gmail.com Signed-off-by: Sasha Levin commit beb81c13d020ceb7f8693e65464162e5f249218e Author: Dmitry Baryshkov Date: Sat May 7 04:00:20 2022 +0300 drm/msm: don't free the IRQ if it was not requested [ Upstream commit 577e2a9dfc8fba7938aaf75db63fae7e328cc3cb ] As msm_drm_uninit() is called from the msm_drm_init() error path, additional care should be necessary as not to call the free_irq() for the IRQ that was not requested before (because an error occured earlier than the request_irq() call). This fixed the issue reported with the following backtrace: [ 8.571329] Trying to free already-free IRQ 187 [ 8.571339] WARNING: CPU: 0 PID: 76 at kernel/irq/manage.c:1895 free_irq+0x1e0/0x35c [ 8.588746] Modules linked in: pmic_glink pdr_interface fastrpc qrtr_smd snd_soc_hdmi_codec msm fsa4480 gpu_sched drm_dp_aux_bus qrtr i2c_qcom_geni crct10dif_ce qcom_stats qcom_q6v5_pas drm_display_helper gpi qcom_pil_info drm_kms_helper qcom_q6v5 qcom_sysmon qcom_common qcom_glink_smem qcom_rng mdt_loader qmi_helpers phy_qcom_qmp ufs_qcom typec qnoc_sm8350 socinfo rmtfs_mem fuse drm ipv6 [ 8.624154] CPU: 0 PID: 76 Comm: kworker/u16:2 Not tainted 5.18.0-rc5-next-20220506-00033-g6cee8cab6089-dirty #419 [ 8.624161] Hardware name: Qualcomm Technologies, Inc. SM8350 HDK (DT) [ 8.641496] Workqueue: events_unbound deferred_probe_work_func [ 8.647510] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.654681] pc : free_irq+0x1e0/0x35c [ 8.658454] lr : free_irq+0x1e0/0x35c [ 8.662228] sp : ffff800008ab3950 [ 8.665642] x29: ffff800008ab3950 x28: 0000000000000000 x27: ffff16350f56a700 [ 8.672994] x26: ffff1635025df080 x25: ffff16350251badc x24: ffff16350251bb90 [ 8.680343] x23: 0000000000000000 x22: 00000000000000bb x21: ffff16350e8f9800 [ 8.687690] x20: ffff16350251ba00 x19: ffff16350cbd5880 x18: ffffffffffffffff [ 8.695039] x17: 0000000000000000 x16: ffffa2dd12179434 x15: ffffa2dd1431d02d [ 8.702391] x14: 0000000000000000 x13: ffffa2dd1431d028 x12: 662d79646165726c [ 8.709740] x11: ffffa2dd13fd2438 x10: 000000000000000a x9 : 00000000000000bb [ 8.717111] x8 : ffffa2dd13fd23f0 x7 : ffff800008ab3750 x6 : 00000000fffff202 [ 8.724487] x5 : ffff16377e870a18 x4 : 00000000fffff202 x3 : ffff735a6ae1b000 [ 8.731851] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff1635015f8000 [ 8.739217] Call trace: [ 8.741755] free_irq+0x1e0/0x35c [ 8.745198] msm_drm_uninit.isra.0+0x14c/0x294 [msm] [ 8.750548] msm_drm_bind+0x28c/0x5d0 [msm] [ 8.755081] try_to_bring_up_aggregate_device+0x164/0x1d0 [ 8.760657] __component_add+0xa0/0x170 [ 8.764626] component_add+0x14/0x20 [ 8.768337] dp_display_probe+0x2a4/0x464 [msm] [ 8.773242] platform_probe+0x68/0xe0 [ 8.777043] really_probe.part.0+0x9c/0x28c [ 8.781368] __driver_probe_device+0x98/0x144 [ 8.785871] driver_probe_device+0x40/0x140 [ 8.790191] __device_attach_driver+0xb4/0x120 [ 8.794788] bus_for_each_drv+0x78/0xd0 [ 8.798751] __device_attach+0xdc/0x184 [ 8.802713] device_initial_probe+0x14/0x20 [ 8.807031] bus_probe_device+0x9c/0xa4 [ 8.810991] deferred_probe_work_func+0x88/0xc0 [ 8.815667] process_one_work+0x1d0/0x320 [ 8.819809] worker_thread+0x14c/0x444 [ 8.823688] kthread+0x10c/0x110 [ 8.827036] ret_from_fork+0x10/0x20 Reported-by: Bjorn Andersson Fixes: f026e431cf86 ("drm/msm: Convert to Linux IRQ interfaces") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/485422/ Link: https://lore.kernel.org/r/20220507010021.1667700-1-dmitry.baryshkov@linaro.org Signed-off-by: Abhinav Kumar Signed-off-by: Sasha Levin commit 00fcd8552cced7bfcbb6a3eb45f51f89ad69e23e Author: Lai Jiangshan Date: Wed Mar 16 12:16:12 2022 +0800 x86/sev: Annotate stack change in the #VC handler [ Upstream commit c42b145181aafd59ed31ccd879493389e3ea5a08 ] In idtentry_vc(), vc_switch_off_ist() determines a safe stack to switch to, off of the IST stack. Annotate the new stack switch with ENCODE_FRAME_POINTER in case UNWINDER_FRAME_POINTER is used. A stack walk before looks like this: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc7+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl dump_stack kernel_exc_vmm_communication asm_exc_vmm_communication ? native_read_msr ? __x2apic_disable.part.0 ? x2apic_setup ? cpu_init ? trap_init ? start_kernel ? x86_64_start_reservations ? x86_64_start_kernel ? secondary_startup_64_no_verify and with the fix, the stack dump is exact: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc7+ #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl dump_stack kernel_exc_vmm_communication asm_exc_vmm_communication RIP: 0010:native_read_msr Code: ... < snipped regs > ? __x2apic_disable.part.0 x2apic_setup cpu_init trap_init start_kernel x86_64_start_reservations x86_64_start_kernel secondary_startup_64_no_verify [ bp: Test in a SEV-ES guest and rewrite the commit message to explain what exactly this does. ] Fixes: a13644f3a53d ("x86/entry/64: Add entry code for #VC handler") Signed-off-by: Lai Jiangshan Signed-off-by: Borislav Petkov Acked-by: Josh Poimboeuf Link: https://lore.kernel.org/r/20220316041612.71357-1-jiangshanlai@gmail.com Signed-off-by: Sasha Levin commit 33546183c16c7b9650682dc610bedd732d9c6919 Author: Hangyu Hua Date: Mon May 9 14:11:25 2022 +0800 drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() [ Upstream commit 947a844bb3ebff0f4736d244d792ce129f6700d7 ] drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails. Fixes: e172d10a9c4a ("drm/msm/mdp5: Add hardware cursor support") Signed-off-by: Hangyu Hua Link: https://lore.kernel.org/r/20220509061125.18585-1-hbh25y@gmail.com Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit edff4c1af831d0c02e654eed9da7d74174de49d5 Author: Miaoqian Lin Date: Thu May 12 16:19:50 2022 +0400 drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init [ Upstream commit c56de483093d7ad0782327f95dda7da97bc4c315 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. a6xx_gmu_init() passes the node to of_find_device_by_node() and of_dma_configure(), of_find_device_by_node() will takes its reference, of_dma_configure() doesn't need the node after usage. Add missing of_node_put() to avoid refcount leak. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Miaoqian Lin Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20220512121955.56937-1-linmq006@gmail.com Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a11f4f01885a8a138c5fb850ae5915774f5d5136 Author: Eric Biggers Date: Tue May 10 11:32:32 2022 -0700 ext4: reject the 'commit' option on ext2 filesystems [ Upstream commit cb8435dc8ba33bcafa41cf2aa253794320a3b8df ] The 'commit' option is only applicable for ext3 and ext4 filesystems, and has never been accepted by the ext2 filesystem driver, so the ext4 driver shouldn't allow it on ext2 filesystems. This fixes a failure in xfstest ext4/053. Fixes: 8dc0aa8cf0f7 ("ext4: check incompatible mount options while mounting ext2/3") Signed-off-by: Eric Biggers Reviewed-by: Ritesh Harjani Reviewed-by: Lukas Czerner Link: https://lore.kernel.org/r/20220510183232.172615-1-ebiggers@kernel.org Signed-off-by: Sasha Levin commit 9ebbfa73d69909b7c737f599fd4ebd42318fc881 Author: Miaoqian Lin Date: Mon May 16 11:44:33 2022 +0400 regulator: scmi: Fix refcount leak in scmi_regulator_probe [ Upstream commit 68d6c8476fd4f448e70e0ab31ff972838ac41dae ] of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 0fbeae70ee7c ("regulator: add SCMI driver") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220516074433.32433-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 692c8de5bdbc599bd911471412a8666c2aabc409 Author: Jonas Karlman Date: Fri May 13 22:29:12 2022 +0200 media: rkvdec: h264: Fix bit depth wrap in pps packet [ Upstream commit a074aa4760d1dad0bd565c0f66e7250f5f219ab0 ] The luma and chroma bit depth fields in the pps packet are 3 bits wide. 8 is wrongly added to the bit depth values written to these 3 bit fields. Because only the 3 LSB are written, the hardware was configured correctly. Correct this by not adding 8 to the luma and chroma bit depth value. Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Jonas Karlman Signed-off-by: Nicolas Dufresne Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9031ef3866210ca4a6e0f47cb8c522159766d321 Author: Nicolas Dufresne Date: Fri May 13 22:29:11 2022 +0200 media: rkvdec: h264: Fix dpb_valid implementation [ Upstream commit 7ab889f09dfa70e8097ec1b9186fd228124112cb ] The ref builder only provided references that are marked as valid in the dpb. Thus the current implementation of dpb_valid would always set the flag to 1. This is not representing missing frames (this is called 'non-existing' pictures in the spec). In some context, these non-existing pictures still need to occupy a slot in the reference list according to the spec. Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Nicolas Dufresne Reviewed-by: Sebastian Fricke Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3c90fdbac6b2769d3592c91aa6c7ae5c68e5f621 Author: Cai Huoqing Date: Wed Sep 8 12:57:59 2021 +0200 media: staging: media: rkvdec: Make use of the helper function devm_platform_ioremap_resource() [ Upstream commit 5a3683d60e56f4faa9552d3efafd87ef106dd393 ] Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 54d6fdf66dd48367610a049dd0dde1633b668125 Author: Yang Yingliang Date: Tue Mar 30 15:04:46 2021 +0200 media: i2c: ov5648: fix wrong pointer passed to IS_ERR() and PTR_ERR() [ Upstream commit a6dd5265c21c28d0a782befe41a97c347e78f22f ] IS_ERR() and PTR_ERR() use wrong pointer, it should be sensor->dovdd, fix it. Fixes: e43ccb0a045f ("media: i2c: Add support for the OV5648 image sensor") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8329361a3eba8ff899e9c9c3b1f24baa29671b53 Author: Dongliang Mu Date: Fri Apr 22 10:54:05 2022 +0200 media: ov7670: remove ov7670_power_off from ov7670_remove [ Upstream commit 5bf19572e31375368f19edd2dbb2e0789518bb99 ] In ov7670_probe, it always invokes ov7670_power_off() no matter the execution is successful or failed. So we cannot invoke it agiain in ov7670_remove(). Fix this by removing ov7670_power_off from ov7670_remove. Fixes: 030f9f682e66 ("media: ov7670: control clock along with power") Signed-off-by: Dongliang Mu Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 018b0292c180c0fe8d6a085f46448febfa612ab0 Author: Andre Przywara Date: Wed May 11 18:21:29 2022 +0100 kselftest/arm64: bti: force static linking [ Upstream commit d7a49291d786b4400996afe3afcc3ef5eeb6f0ef ] The "bti" selftests are built with -nostdlib, which apparently automatically creates a statically linked binary, which is what we want and need for BTI (to avoid interactions with the dynamic linker). However this is not true when building a PIE binary, which some toolchains (Ubuntu) configure as the default. When compiling btitest with such a toolchain, it will create a dynamically linked binary, which will probably fail some tests, as the dynamic linker might not support BTI: =================== TAP version 13 1..18 not ok 1 nohint_func/call_using_br_x0 not ok 2 nohint_func/call_using_br_x16 not ok 3 nohint_func/call_using_blr .... =================== To make sure we create static binaries, add an explicit -static on the linker command line. This forces static linking even if the toolchain defaults to PIE builds, and fixes btitest runs on BTI enabled machines. Signed-off-by: Andre Przywara Reviewed-by: Mark Brown Fixes: 314bcbf09f14 ("kselftest: arm64: Add BTI tests") Link: https://lore.kernel.org/r/20220511172129.2078337-1-andre.przywara@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 2a3966b950b37a6f10c5f9caee15b4cdcf5a7413 Author: Miaoqian Lin Date: Thu May 12 15:13:30 2022 +0400 ASoC: ti: j721e-evm: Fix refcount leak in j721e_soc_probe_* [ Upstream commit a34840c4eb3278a7c29c9c57a65ce7541c66f9f2 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 6748d0559059 ("ASoC: ti: Add custom machine driver for j721e EVM (CPB and IVI)") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220512111331.44774-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cf31d1ef38399ad107c9d1670ee22768d5296646 Author: Zheng Bin Date: Fri May 13 15:09:22 2022 +0800 net: hinic: add missing destroy_workqueue in hinic_pf_to_mgmt_init [ Upstream commit 382d917bfc1e92339dae3c8a636b2730e8bb5132 ] hinic_pf_to_mgmt_init misses destroy_workqueue in error path, this patch fixes that. Fixes: 6dbb89014dc3 ("hinic: fix sending mailbox timeout in aeq event work") Signed-off-by: Zheng Bin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9b01252e6c205c1e93f0fb00b6030cfa44c0e2bd Author: Eric Dumazet Date: Fri May 13 11:55:42 2022 -0700 sctp: read sk->sk_bound_dev_if once in sctp_rcv() [ Upstream commit a20ea298071f46effa3aaf965bf9bb34c901db3f ] sctp_rcv() reads sk->sk_bound_dev_if twice while the socket is not locked. Another cpu could change this field under us. Fixes: 0fd9a65a76e8 ("[SCTP] Support SO_BINDTODEVICE socket option on incoming packets.") Signed-off-by: Eric Dumazet Cc: Neil Horman Cc: Vlad Yasevich Cc: Marcelo Ricardo Leitner Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d17b01588e0cfaf69af4ed1d3b37556853538148 Author: Geert Uytterhoeven Date: Fri May 13 14:50:28 2022 +0200 m68k: math-emu: Fix dependencies of math emulation support [ Upstream commit ed6bc6bf0a7d75e80eb1df883c09975ebb74e590 ] If CONFIG_M54xx=y, CONFIG_MMU=y, and CONFIG_M68KFPU_EMU=y: {standard input}:272: Error: invalid instruction for this architecture; needs 68000 or higher (68000 [68ec000, 68hc000, 68hc001, 68008, 68302, 68306, 68307, 68322, 68356], 68010, 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], fidoa [fido]) -- statement `sub.b %d1,%d3' ignored {standard input}:609: Error: invalid instruction for this architecture; needs 68020 or higher (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060]) -- statement `bfextu 4(%a1){%d0,#8},%d0' ignored {standard input}:752: Error: operands mismatch -- statement `mulu.l 4(%a0),%d3:%d0' ignored {standard input}:1155: Error: operands mismatch -- statement `divu.l %d0,%d3:%d7' ignored The math emulation support code is intended for 68020 and higher, and uses several instructions or instruction modes not available on coldfire or 68000. Originally, the dependency of M68KFPU_EMU on MMU was fine, as MMU support was only available on 68020 or higher. But this assumption was broken by the introduction of MMU support for M547x and M548x. Drop the dependency on MMU, as the code should work fine on 68020 and up without MMU (which are not yet supported by Linux, though). Add dependencies on M68KCLASSIC (to rule out Coldfire) and FPU (kernel has some type of floating-point support --- be it hardware or software emulated, to rule out anything below 68020). Fixes: 1f7034b9616e6f14 ("m68k: allow ColdFire 547x and 548x CPUs to be built with MMU enabled") Reported-by: kernel test robot Signed-off-by: Geert Uytterhoeven Reviewed-by: Greg Ungerer Link: https://lore.kernel.org/r/18c34695b7c95107f60ccca82a4ff252f3edf477.1652446117.git.geert@linux-m68k.org Signed-off-by: Sasha Levin commit b5518b9b41f1d88afd4ebcfe8b776396489a0ff5 Author: Keith Busch Date: Wed May 4 11:43:25 2022 -0700 nvme: set dma alignment to dword [ Upstream commit 52fde2c07da606f3f120af4f734eadcfb52b04be ] The nvme specification only requires qword alignment for segment descriptors, and the driver already guarantees that. The spec has always allowed user data to be dword aligned, which is what the queue's attribute is for, so relax the alignment requirement to that value. While we could allow byte alignment for some controllers when using SGLs, we still need to support PRP, and that only allows dword. Fixes: 3b2a1ebceba3 ("nvme: set dma alignment to qword") Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ce237c1e252d0dac506c93c9818f8085185355be Author: Niels Dossche Date: Tue Apr 5 19:37:52 2022 +0200 Bluetooth: use hdev lock for accept_list and reject_list in conn req [ Upstream commit fb048cae51bacdfbbda2954af3c213fdb1d484f4 ] All accesses (both reads and modifications) to hdev->{accept,reject}_list are protected by hdev lock, except the ones in hci_conn_request_evt. This can cause a race condition in the form of a list corruption. The solution is to protect these lists in hci_conn_request_evt as well. I was unable to find the exact commit that introduced the issue for the reject list, I was only able to find it for the accept list. Fixes: a55bd29d5227 ("Bluetooth: Add white list lookup for incoming connection requests") Signed-off-by: Niels Dossche Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ab00f8c6b14ed8360fc2c40bd2ec61c6477e2ddb Author: Niels Dossche Date: Thu Apr 7 20:06:52 2022 +0200 Bluetooth: use hdev lock in activate_scan for hci_is_adv_monitoring [ Upstream commit 50a3633ae5e98cf1b80ef5b73c9e341aee9ad896 ] hci_is_adv_monitoring's function documentation states that it must be called under the hdev lock. Paths that leads to an unlocked call are: discov_update => start_discovery => interleaved_discov => active_scan and: discov_update => start_discovery => active_scan The solution is to take the lock in active_scan during the duration of the call to hci_is_adv_monitoring. Fixes: c32d624640fd ("Bluetooth: disable filter dup when scan for adv monitor") Signed-off-by: Niels Dossche Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 65d347cb39e2e6bd0c2a745ad7c928998ebb0162 Author: Ying Hsu Date: Sat Mar 26 07:09:28 2022 +0000 Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout [ Upstream commit 7aa1e7d15f8a5b65f67bacb100d8fc033b21efa2 ] Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/0x30 Link: https://syzkaller.appspot.com/bug?extid=2bef95d3ab4daa10155b Reported-by: syzbot+2bef95d3ab4daa10155b@syzkaller.appspotmail.com Fixes: e1dee2c1de2b ("Bluetooth: fix repeated calls to sco_sock_kill") Signed-off-by: Ying Hsu Reviewed-by: Joseph Hwang Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit dd646f51808e11082ecabefe8ec8f3d4513dd77c Author: Benjamin Gaignard Date: Wed Apr 27 19:39:36 2022 +0200 media: hantro: HEVC: Fix tile info buffer value computation [ Upstream commit d7f4149df818463c1d7094b35db6ebd79f46c7bd ] Use pps->column_width_minus1[j] + 1 as value for the tile info buffer instead of pps->column_width_minus1[j + 1]. The patch fixes DBLK_E_VIXS_2, DBLK_F_VIXS_2, DBLK_G_VIXS_2, SAO_B_MediaTek_5, TILES_A_Cisco_2 and TILES_B_Cisco_1 tests in fluster. Fixes: cb5dd5a0fa51 ("media: hantro: Introduce G2/HEVC decoder") Signed-off-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1207ddc93b9efb3efe8c3c464df79e0e8f07d84e Author: Eugen Hristev Date: Tue May 3 10:44:17 2022 +0200 media: atmel: atmel-sama5d2-isc: fix wrong mask in YUYV format check [ Upstream commit 91f49b80983f7bffdea9498209b2b896231ac776 ] While this does not happen in production, this check should be done versus the mask, as checking with the YCYC value may not include some bits that may be set. It is correct and safe to check the whole mask. Fixes: 123aaf816b95 ("media: atmel: atmel-sama5d2-isc: fix YUYV format") Signed-off-by: Eugen Hristev Reviewed-by: Jacopo Mondi Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a4cd52464bf2bd9b0cbc3fca910dac446f920ab8 Author: Michael Rodin Date: Tue Nov 23 12:50:36 2021 +0100 media: vsp1: Fix offset calculation for plane cropping [ Upstream commit 5f25abec8f21b7527c1223a354d23c270befddb3 ] The vertical subsampling factor is currently not considered in the offset calculation for plane cropping done in rpf_configure_partition. This causes a distortion (shift of the color plane) when formats with the vsub factor larger than 1 are used (e.g. NV12, see vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor for all planes except plane 0 (luminance). Drop generalization of the offset calculation to reduce the binary size. Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support") Signed-off-by: Michael Rodin Signed-off-by: LUU HOAI Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3309c2c574e13b21b44729f5bdbf21f60189b79a Author: Pavel Skripkin Date: Fri Apr 15 23:24:48 2022 +0200 media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init [ Upstream commit 471bec68457aaf981add77b4f590d65dd7da1059 ] Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work. Reported-and-tested-by: syzbot+1a247e36149ffd709a9b@syzkaller.appspotmail.com Fixes: d855497edbfb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18") Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2f6ced0e8fa5cba875f4123d6d088efa4735b422 Author: Miaoqian Lin Date: Fri Mar 18 12:01:01 2022 +0100 media: exynos4-is: Change clk_disable to clk_disable_unprepare [ Upstream commit 9fadab72a6916c7507d7fedcd644859eef995078 ] The corresponding API for clk_prepare_enable is clk_disable_unprepare, other than clk_disable. Fix this by changing clk_disable to clk_disable_unprepare. Fixes: b4155d7d5b2c ("[media] exynos4-is: Ensure fimc-is clocks are not enabled until properly configured") Signed-off-by: Miaoqian Lin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b6db1bbeaf79112bb009ce07bb018ba11f34003b Author: Laurentiu Palcu Date: Wed Mar 9 12:55:06 2022 +0100 media: i2c: rdacm2x: properly set subdev entity function [ Upstream commit d2facee67b4883bb3e7461a0a93fd70d0c7b7261 ] The subdevice entity function was left unset, which produces a warning when probing the device: mxc-md bus@58000000:camera: Entity type for entity rdacm20 19-0051 was not initialized! This patch will set entity function to MEDIA_ENT_F_CAM_SENSOR and leave flags unset. Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver") Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module") Signed-off-by: Laurentiu Palcu Reviewed-by: Jacopo Mondi Reviewed-by: Kieran Bingham Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f0d9105f28439e199b2a18fe5ef26f1dcebe2561 Author: Miaoqian Lin Date: Mon Mar 7 09:16:37 2022 +0100 media: atmel: atmel-isc: Fix PM disable depth imbalance in atmel_isc_probe [ Upstream commit 395829c61a196a0821a703a49c4db3ac51daff73 ] The pm_runtime_enable will decrease power disable depth. If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable(). Fixes: 0a0e265515db ("media: atmel: atmel-isc: split driver into driver base and isc") Signed-off-by: Miaoqian Lin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 204e53586b362a0f1f572f14e888412c9aa426b4 Author: Miaoqian Lin Date: Mon Mar 7 09:08:59 2022 +0100 media: st-delta: Fix PM disable depth imbalance in delta_probe [ Upstream commit 94e3dba710fe0afc772172305444250023fc2d30 ] The pm_runtime_enable will decrease power disable depth. If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable(). Fixes: f386509e4959 ("[media] st-delta: STiH4xx multi-format video decoder v4l2 driver") Signed-off-by: Miaoqian Lin Acked-by: Hugues Fruchet Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0d21276083480b1ca0af87342c1309f06ee23cb3 Author: Felix Fietkau Date: Wed Apr 20 13:20:23 2022 +0200 mt76: do not attempt to reorder received 802.3 packets without agg session [ Upstream commit 3968a66475b40691c37b5e6c76975f699671e10e ] Fixes potential latency / packet drop issues in cases where a BA session has not (yet) been established. Fixes: e195dad14115 ("mt76: add support for 802.3 rx frames") Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 663457f421d41e9d2fcb1e84baf43d1433f80c08 Author: Christophe JAILLET Date: Sun Apr 3 17:40:33 2022 +0200 mt76: mt7921: Fix the error handling path of mt7921_pci_probe() [ Upstream commit 4e90db5e21eb3bb272fe47386dc3506755e209e9 ] In case of error, some resources must be freed, as already done above and below the devm_kmemdup() and __mt7921e_mcu_drv_pmctrl() calls added in the commit in Fixes:. Fixes: 602cc0c9618a ("mt76: mt7921e: fix possible probe failure after reboot") Signed-off-by: Christophe JAILLET Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8ffc866d2f18f5c64733d4a7761fa7ef2011c0c8 Author: Miaoqian Lin Date: Mon Mar 7 08:52:06 2022 +0100 media: exynos4-is: Fix PM disable depth imbalance in fimc_is_probe [ Upstream commit 5c0db68ce0faeb000c3540d095eb272d671a6e03 ] If probe fails then we need to call pm_runtime_disable() to balance out the previous pm_runtime_enable() call. Fixes: 9a761e436843 ("[media] exynos4-is: Add Exynos4x12 FIMC-IS driver") Signed-off-by: Miaoqian Lin Reviewed-by: Krzysztof Kozlowski Reviewed-by: Alim Akhtar Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 819c8af5e57296a23944acce0efe2744ace2a6d6 Author: Christophe JAILLET Date: Sun Mar 6 19:08:07 2022 +0100 media: aspeed: Fix an error handling path in aspeed_video_probe() [ Upstream commit 310fda622bbd38be17fb444f7f049b137af3bc0d ] A dma_free_coherent() call is missing in the error handling path of the probe, as already done in the remove function. In fact, this call is included in aspeed_video_free_buf(). So use the latter both in the error handling path of the probe and in the remove function. It is easier to see the relation with aspeed_video_alloc_buf() this way. Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Signed-off-by: Christophe JAILLET Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 795cc5b2b5a2fd4b1a8e583ad69d52e884a4dba1 Author: Josh Poimboeuf Date: Thu May 12 12:05:27 2022 -0700 scripts/faddr2line: Fix overlapping text section failures [ Upstream commit 1d1a0e7c5100d332583e20b40aa8c0a8ed3d7849 ] There have been some recent reports of faddr2line failures: $ scripts/faddr2line sound/soundcore.ko sound_devnode+0x5/0x35 bad symbol size: base: 0x0000000000000000 end: 0x0000000000000000 $ ./scripts/faddr2line vmlinux.o enter_from_user_mode+0x24 bad symbol size: base: 0x0000000000005fe0 end: 0x0000000000005fe0 The problem is that faddr2line is based on 'nm', which has a major limitation: it doesn't know how to distinguish between different text sections. So if an offset exists in multiple text sections in the object, it may fail. Rewrite faddr2line to be section-aware, by basing it on readelf. Fixes: 67326666e2d4 ("scripts: add script for translating stack dump function offsets") Reported-by: Kaiwan N Billimoria Reported-by: Peter Zijlstra Signed-off-by: Josh Poimboeuf Link: https://lore.kernel.org/r/29ff99f86e3da965b6e46c1cc2d72ce6528c17c3.1652382321.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 7fc8f4717e394f0c9b231cfe37c54744b4f03725 Author: Phil Auld Date: Thu May 12 10:34:39 2022 -0400 kselftest/cgroup: fix test_stress.sh to use OUTPUT dir [ Upstream commit 54de76c0123915e7533ce352de30a1f2d80fe81f ] Running cgroup kselftest with O= fails to run the with_stress test due to hardcoded ./test_core. Find test_core binary using the OUTPUT directory. Fixes: 1a99fcc035fb ("selftests: cgroup: Run test_core under interfering stress") Signed-off-by: Phil Auld Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit d63ffecd11368d1d40dd63330b6dfaeb828b1115 Author: Bart Van Assche Date: Wed May 11 16:51:52 2022 -0700 block: Fix the bio.bi_opf comment [ Upstream commit 5d2ae14276e698c76fa0c8ce870103f343b38263 ] Commit ef295ecf090d modified the Linux kernel such that the bottom bits of the bi_opf member contain the operation instead of the topmost bits. That commit did not update the comment next to bi_opf. Hence this patch. From commit ef295ecf090d: -#define bio_op(bio) ((bio)->bi_opf >> BIO_OP_SHIFT) +#define bio_op(bio) ((bio)->bi_opf & REQ_OP_MASK) Cc: Christoph Hellwig Cc: Ming Lei Fixes: ef295ecf090d ("block: better op and flags encoding") Signed-off-by: Bart Van Assche Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220511235152.1082246-1-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 85d899f396622d3034643bf89615a78f9be7c91a Author: Miaoqian Lin Date: Thu May 12 08:38:28 2022 +0400 ASoC: samsung: Fix refcount leak in aries_audio_probe [ Upstream commit bf4a9b2467b775717d0e9034ad916888e19713a3 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. If extcon_find_edev_by_node() fails, it doesn't call of_node_put() Calling of_node_put() after extcon_find_edev_by_node() to fix this. Fixes: 7a3a7671fa6c ("ASoC: samsung: Add driver for Aries boards") Signed-off-by: Miaoqian Lin Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220512043828.496-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e2fa42e4c231f50bb96d2b97d86eb6a34bee3613 Author: Kuninori Morimoto Date: Tue Dec 14 11:08:41 2021 +0900 ASoC: samsung: Use dev_err_probe() helper [ Upstream commit 27c6eaebcf75e4fac145d17c7fa76bc64b60d24c ] Use the dev_err_probe() helper, instead of open-coding the same operation. Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20211214020843.2225831-21-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6635e6ba1649ee5f68baf59cc01bf0151d0b4fd8 Author: Christoph Hellwig Date: Sat Apr 23 19:20:24 2022 +0200 dma-direct: don't fail on highmem CMA pages in dma_direct_alloc_pages [ Upstream commit 92826e967535db2eb117db227b1191aaf98e4bb3 ] When dma_direct_alloc_pages encounters a highmem page it just gives up currently. But what we really should do is to try memory using the page allocator instead - without this platforms with a global highmem CMA pool will fail all dma_alloc_pages allocations. Fixes: efa70f2fdc84 ("dma-mapping: add a new dma_alloc_pages API") Reported-by: Mark O'Neill Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 639518f8e0d303203bf96159d217c33242da8870 Author: Christoph Hellwig Date: Mon Oct 18 13:08:07 2021 +0200 dma-direct: factor out a helper for DMA_ATTR_NO_KERNEL_MAPPING allocations [ Upstream commit d541ae55d538265861ef729a64d2d816d34ef1e2 ] Split the code for DMA_ATTR_NO_KERNEL_MAPPING allocations into a separate helper to make dma_direct_alloc a little more readable. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy Acked-by: David Rientjes Signed-off-by: Sasha Levin commit 56ab0c01027492cd161c64148e1dc892c56887ad Author: Miaoqian Lin Date: Wed May 11 15:35:05 2022 +0400 regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt [ Upstream commit afaa7b933ef00a2d3262f4d1252087613fb5c06d ] of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore. Fixes: 3784b6d64dc5 ("regulator: pfuze100: add pfuze100 regulator driver") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220511113506.45185-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 24491124406666bf0dcb9ee10c5575c6ce6a1730 Author: Miaoqian Lin Date: Wed May 11 17:37:22 2022 +0400 ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe [ Upstream commit 2be84f73785fa9ed6443e3c5b158730266f1c2ee ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Fixes: 08641c7c74dd ("ASoC: mxs: add device tree support for mxs-saif") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220511133725.39039-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cf760e494ee5fa6bc2dc222f0098c741ad460801 Author: Miaoqian Lin Date: Wed May 11 09:27:40 2022 +0400 ASoC: imx-hdmi: Fix refcount leak in imx_hdmi_probe [ Upstream commit ed46731d8e86c8d65f5fc717671e1f1f6c3146d2 ] of_find_device_by_node() takes reference, we should use put_device() to release it. when devm_kzalloc() fails, it doesn't have a put_device(), it will cause refcount leak. Add missing put_device() to fix this. Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver") Fixes: f670b274f7f6 ("ASoC: imx-hdmi: add put_device() after of_find_device_by_node()") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220511052740.46903-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 922bccdb1796a9e7b989f2bc6d9ada7b499a4329 Author: Miaoqian Lin Date: Wed May 11 10:58:03 2022 +0400 ASoC: fsl: Fix refcount leak in imx_sgtl5000_probe [ Upstream commit 41cd312dfe980af869c3503b4d38e62ed20dd3b7 ] of_find_i2c_device_by_node() takes a reference, In error paths, we should call put_device() to drop the reference to aviod refount leak. Fixes: 81e8e4926167 ("ASoC: fsl: add sgtl5000 clock support for imx-sgtl5000") Signed-off-by: Miaoqian Lin Reviewed-by: Fabio Estevam Link: https://lore.kernel.org/r/20220511065803.3957-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8737b5163f4e8d77f1f19a65ea639dec5606bb50 Author: Kuninori Morimoto Date: Tue Dec 14 11:08:34 2021 +0900 ASoC: fsl: Use dev_err_probe() helper [ Upstream commit 2e6f557ca35aa330dbf31c5e1cc8119eff1526fa ] Use the dev_err_probe() helper, instead of open-coding the same operation. Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20211214020843.2225831-14-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 319d60b74860eafb7963e8d90498dc07030a4ac4 Author: Basavaraj Natikar Date: Mon May 9 18:50:23 2022 +0530 HID: amd_sfh: Modify the hid name [ Upstream commit 10f865cdcf37d26ae5e9595a7b4f9e06538e84e5 ] Modifying the amd-sfh hid name to meaningful name. Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Signed-off-by: Mario Limonciello Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 21e8fc0c574ce21863fff46ea10133c62a18b7a9 Author: Basavaraj Natikar Date: Mon May 9 18:50:22 2022 +0530 HID: amd_sfh: Modify the bus name [ Upstream commit 206c3c2d85de8847fb732a5fb71443bacd287216 ] Modifying the amd-sfh bus name to meaningful name. Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Signed-off-by: Mario Limonciello Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7fef8ec5b1d881dafb1c97547cff4b3bf523fb96 Author: Ajay Singh Date: Wed May 4 16:19:26 2022 +0000 wilc1000: fix crash observed in AP mode with cfg80211_register_netdevice() [ Upstream commit 868f0e28290c7a33e8cb79bfe97ebdcbb756e048 ] Monitor(mon.) interface is used for handling the AP mode and 'ieee80211_ptr' reference is not getting set for it. Like earlier implementation, use register_netdevice() instead of cfg80211_register_netdevice() which expects valid 'ieee80211_ptr' reference to avoid the possible crash. Fixes: 2fe8ef106238 ("cfg80211: change netdev registration/unregistration semantics") Signed-off-by: Ajay Singh Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220504161924.2146601-3-ajay.kathat@microchip.com Signed-off-by: Sasha Levin commit 1eb4f56f8ff9ea6aa31bb799de7b9b36295b7637 Author: Baochen Qiang Date: Mon May 9 14:57:31 2022 +0300 ath11k: Don't check arvif->is_started before sending management frames [ Upstream commit 355333a217541916576351446b5832fec7930566 ] Commit 66307ca04057 ("ath11k: fix mgmt_tx_wmi cmd sent to FW for deleted vdev") wants both of below two conditions are true before sending management frames: 1: ar->allocated_vdev_map & (1LL << arvif->vdev_id) 2: arvif->is_started Actually the second one is not necessary because with the first one we can make sure the vdev is present. Also use ar->conf_mutex to synchronize vdev delete and mgmt. TX. This issue is found in case of Passpoint scenario where ath11k needs to send action frames before vdev is started. Fix it by removing the second condition. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Fixes: 66307ca04057 ("ath11k: fix mgmt_tx_wmi cmd sent to FW for deleted vdev") Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220506013614.1580274-3-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit 84e92386d12d96440af3e0cf12439384ac8c8610 Author: Ravi Bangoria Date: Fri Apr 29 10:44:41 2022 +0530 perf/amd/ibs: Use interrupt regs ip for stack unwinding [ Upstream commit 3d47083b9ff46863e8374ad3bb5edb5e464c75f8 ] IbsOpRip is recorded when IBS interrupt is triggered. But there is a skid from the time IBS interrupt gets triggered to the time the interrupt is presented to the core. Meanwhile processor would have moved ahead and thus IbsOpRip will be inconsistent with rsp and rbp recorded as part of the interrupt regs. This causes issues while unwinding stack using the ORC unwinder as it needs consistent rip, rsp and rbp. Fix this by using rip from interrupt regs instead of IbsOpRip for stack unwinding. Fixes: ee9f8fce99640 ("x86/unwind: Add the ORC unwinder") Reported-by: Dmitry Monakhov Suggested-by: Peter Zijlstra Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20220429051441.14251-1-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit a532b341d704defc82ebf58a789aec52ece07e99 Author: Jerome Marchand Date: Sat May 7 18:16:35 2022 +0200 samples: bpf: Don't fail for a missing VMLINUX_BTF when VMLINUX_H is provided [ Upstream commit ec24704492d8791a52a75a39e3ad762b6e017bc6 ] samples/bpf build currently always fails if it can't generate vmlinux.h from vmlinux, even when vmlinux.h is directly provided by VMLINUX_H variable, which makes VMLINUX_H pointless. Only fails when neither method works. Fixes: 384b6b3bbf0d ("samples: bpf: Add vmlinux.h generation support") Reported-by: CKI Project Reported-by: Veronika Kabatova Signed-off-by: Jerome Marchand Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220507161635.2219052-1-jmarchan@redhat.com Signed-off-by: Sasha Levin commit 0480f70d13c655df30d8e0a1321a75f3c6a9df3c Author: Konrad Dybcio Date: Sat Apr 30 18:37:52 2022 +0200 regulator: qcom_smd: Fix up PM8950 regulator configuration [ Upstream commit b11b3d21a94d66bc05d1142e0b210bfa316c62be ] Following changes have been made: - S5, L4, L18, L20 and L21 were removed (S5 is managed by SPMI, whereas the rest seems not to exist [or at least it's blocked by Sony Loire /MSM8956/ RPM firmware]) - Supply maps have were adjusted to reflect regulator changes. Fixes: e44adca5fa25 ("regulator: qcom_smd: Add PM8950 regulators") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20220430163753.609909-1-konrad.dybcio@somainline.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ca3fd5ff7b80552c1493ba5cd200faa847ba7c4d Author: Viresh Kumar Date: Mon May 9 09:27:37 2022 +0530 Revert "cpufreq: Fix possible race in cpufreq online error path" [ Upstream commit 85f0e42bd65d01b351d561efb38e584d4c596553 ] This reverts commit f346e96267cd76175d6c201b40f770c0116a8a04. The commit tried to fix a possible real bug but it made it even worse. The fix was simply buggy as now an error out to out_offline_policy or out_exit_policy will try to release a semaphore which was never taken in the first place. This works fine only if we failed late, i.e. via out_destroy_policy. Fixes: f346e96267cd ("cpufreq: Fix possible race in cpufreq online error path") Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 10f537219629769498ecb8515e096be213224c24 Author: Yang Yingliang Date: Thu May 5 17:39:54 2022 +0800 spi: spi-fsl-qspi: check return value after calling platform_get_resource_byname() [ Upstream commit a2b331ac11e1cac56f5b7d367e9f3c5796deaaed ] It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Fixes: 858e26a515c2 ("spi: spi-fsl-qspi: Reduce devm_ioremap size to 4 times AHB buffer size") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20220505093954.1285615-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 76f5bd1eed01d4f87768ecd11c5a3e1788997be4 Author: Andreas Gruenbacher Date: Thu May 5 18:19:13 2022 -0700 iomap: iomap_write_failed fix [ Upstream commit b71450e2cc4b3c79f33c5bd276d152af9bd54f79 ] The @lend parameter of truncate_pagecache_range() should be the offset of the last byte of the hole, not the first byte beyond it. Fixes: ae259a9c8593 ("fs: introduce iomap infrastructure") Signed-off-by: Andreas Gruenbacher Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit e7308391df97c1891b642cfb4b9be8a9a0a4ff26 Author: Mark Rutland Date: Wed Apr 27 18:31:16 2022 +0100 arm64: stackleak: fix current_top_of_stack() [ Upstream commit e85094c31ddb794ac41c299a5a7a68243148f829 ] Due to some historical confusion, arm64's current_top_of_stack() isn't what the stackleak code expects. This could in theory result in a number of problems, and practically results in an unnecessary performance hit. We can avoid this by aligning the arm64 implementation with the x86 implementation. The arm64 implementation of current_top_of_stack() was added specifically for stackleak in commit: 0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin") This was intended to be equivalent to the x86 implementation, but the implementation, semantics, and performance characteristics differ wildly: * On x86, current_top_of_stack() returns the top of the current task's task stack, regardless of which stack is in active use. The implementation accesses a percpu variable which the x86 entry code maintains, and returns the location immediately above the pt_regs on the task stack (above which x86 has some padding). * On arm64 current_top_of_stack() returns the top of the stack in active use (i.e. the one which is currently being used). The implementation checks the SP against a number of potentially-accessible stacks, and will BUG() if no stack is found. The core stackleak_erase() code determines the upper bound of stack to erase with: | if (on_thread_stack()) | boundary = current_stack_pointer; | else | boundary = current_top_of_stack(); On arm64 stackleak_erase() is always called on a task stack, and on_thread_stack() should always be true. On x86, stackleak_erase() is mostly called on a trampoline stack, and is sometimes called on a task stack. Currently, this results in a lot of unnecessary code being generated for arm64 for the impossible !on_thread_stack() case. Some of this is inlined, bloating stackleak_erase(), while portions of this are left out-of-line and permitted to be instrumented (which would be a functional problem if that code were reachable). As a first step towards improving this, this patch aligns arm64's implementation of current_top_of_stack() with x86's, always returning the top of the current task's stack. With GCC 11.1.0 this results in the bulk of the unnecessary code being removed, including all of the out-of-line instrumentable code. While I don't believe there's a functional problem in practice I've marked this as a fix since the semantic was clearly wrong, the fix itself is simple, and other code might rely upon this in future. Fixes: 0b3e336601b82c6a ("arm64: Add support for STACKLEAK gcc plugin") Signed-off-by: Mark Rutland Cc: Alexander Popov Cc: Andrew Morton Cc: Andy Lutomirski Cc: Catalin Marinas Cc: Kees Cook Cc: Will Deacon Acked-by: Catalin Marinas Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220427173128.2603085-2-mark.rutland@arm.com Signed-off-by: Sasha Levin commit 29d441903f2272a1386562e27009d0234c893734 Author: Xiaomeng Tong Date: Sat Mar 19 11:22:22 2022 +0100 media: uvcvideo: Fix missing check to determine if element is found in list [ Upstream commit 261f33388c29f6f3c12a724e6d89172b7f6d5996 ] The list iterator will point to a bogus position containing HEAD if the list is empty or the element is not found in list. This case should be checked before any use of the iterator, otherwise it will lead to a invalid memory access. The missing check here is before "pin = iterm->id;", just add check here to fix the security bug. In addition, the list iterator value will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the element is not found in list, considering the (mis)use here: "if (iterm == NULL". Use a new value 'it' as the list iterator, while use the old value 'iterm' as a dedicated pointer to point to the found element, which 1. can fix this bug, due to 'iterm' is NULL only if it's not found. 2. do not need to change all the uses of 'iterm' after the loop. 3. can also limit the scope of the list iterator 'it' *only inside* the traversal loop by simply declaring 'it' inside the loop in the future, as usage of the iterator outside of the list_for_each_entry is considered harmful. https://lkml.org/lkml/2022/2/17/1032 Fixes: d5e90b7a6cd1c ("[media] uvcvideo: Move to video_ioctl2") Signed-off-by: Xiaomeng Tong Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3aece8b03c08ceaf73b5731a8502fb9a5bf912d6 Author: Dan Carpenter Date: Thu May 5 13:28:05 2022 +0300 drm/msm: return an error pointer in msm_gem_prime_get_sg_table() [ Upstream commit cf575e31611eb6dccf08fad02e57e35b2187704d ] The msm_gem_prime_get_sg_table() needs to return error pointers on error. This is called from drm_gem_map_dma_buf() and returning a NULL will lead to a crash in that function. Fixes: ac45146733b0 ("drm/msm: fix msm_gem_prime_get_sg_table()") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/485023/ Link: https://lore.kernel.org/r/YnOmtS5tfENywR9m@kili Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 09bdeedc1fc53e64b8282e1de67752c69e43bdba Author: Jessica Zhang Date: Thu May 5 14:40:51 2022 -0700 drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected [ Upstream commit ca75f6f7c6f89365e40f10f641b15981b1f07c31 ] There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned. To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error. Reported-by: Tomeu Vizoso Signed-off-by: Jessica Zhang Fixes: 7907a0d77cb4 ("drm/msm/mdp5: Use the new private_obj state") Reviewed-by: Rob Clark Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/485181/ Link: https://lore.kernel.org/r/20220505214051.155-2-quic_jesszhan@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 04bef5f1ba8ea6d7c1c8f5f65e0395c62db59cb8 Author: Jessica Zhang Date: Thu May 5 14:40:50 2022 -0700 drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected [ Upstream commit d59be579fa932c46b908f37509f319cbd4ca9a68 ] mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5_pipe_release doesn't check for if an error is returned. Because of this, there is a possibility of mdp5_pipe_release hitting a NULL dereference error. To avoid this, let's have mdp5_pipe_release check if mdp5_get_global_state returns an error and propogate that error. Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_release Reported-by: Tomeu Vizoso Signed-off-by: Jessica Zhang Fixes: 7907a0d77cb4 ("drm/msm/mdp5: Use the new private_obj state") Reviewed-by: Rob Clark Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/485179/ Link: https://lore.kernel.org/r/20220505214051.155-1-quic_jesszhan@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit c063df41227d36bc87a70a7f5049c0d5df170f5f Author: Kuogee Hsieh Date: Tue May 3 09:25:36 2022 -0700 drm/msm/dp: fix event thread stuck in wait_event after kthread_stop() [ Upstream commit 2f9b5b3ae2eb625b75a898212a76f3b8c6d0d2b0 ] Event thread supposed to exit from its while loop after kthread_stop(). However there may has possibility that event thread is pending in the middle of wait_event due to condition checking never become true. To make sure event thread exit its loop after kthread_stop(), this patch OR kthread_should_stop() into wait_event's condition checking so that event thread will exit its loop after kernal_stop(). Changes in v2: -- correct spelling error at commit title Changes in v3: -- remove unnecessary parenthesis -- while(1) to replace while (!kthread_should_stop()) Reported-by: Dmitry Baryshkov Fixes: 570d3e5d28db ("drm/msm/dp: stop event kernel thread when DP unbind") Signed-off-by: Kuogee Hsieh Reviewed-by: Dmitry Baryshkov Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/484576/ Link: https://lore.kernel.org/r/1651595136-24312-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit f5947118e729b30f1a87a7546e3f0b47912eff19 Author: Dmitry Baryshkov Date: Tue May 3 23:43:40 2022 +0300 drm/msm/dsi: fix address for second DSI PHY on SDM660 [ Upstream commit 9208c707650354dff5b164b586837454f7285124 ] Correct a typo in the address of the second DSI PHY in the SDM660 device config. Fixes: 694dd304cc29 ("drm/msm/dsi: Add phy configuration for SDM630/636/660") Cc: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Reviewed-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/484697/ Link: https://lore.kernel.org/r/20220503204340.935532-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 81180f6d74c28ae91c3179715aa98e26fbde1c13 Author: Zev Weiss Date: Wed May 4 21:31:52 2022 -0700 regulator: core: Fix enable_count imbalance with EXCLUSIVE_GET [ Upstream commit c3e3ca05dae37f8f74bb80358efd540911cbc2c8 ] Since the introduction of regulator->enable_count, a driver that did an exclusive get on an already-enabled regulator would end up with enable_count initialized to 0 but rdev->use_count initialized to 1. With that starting point the regulator is effectively stuck enabled, because if the driver attempted to disable it it would fail the enable_count underflow check in _regulator_handle_consumer_disable(). The EXCLUSIVE_GET path in _regulator_get() now initializes enable_count along with rdev->use_count so that the regulator can be disabled without underflowing the former. Signed-off-by: Zev Weiss Fixes: 5451781dadf85 ("regulator: core: Only count load for enabled consumers") Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 75868ee93b1daf78e738544b2fc944aaca11fe81 Author: Tong Tiangen Date: Wed Apr 20 03:04:13 2022 +0000 arm64: fix types in copy_highpage() [ Upstream commit 921d161f15d6b090599f6a8c23f131969edbd1fa ] In copy_highpage() the `kto` and `kfrom` local variables are pointers to struct page, but these are used to hold arbitrary pointers to kernel memory . Each call to page_address() returns a void pointer to memory associated with the relevant page, and copy_page() expects void pointers to this memory. This inconsistency was introduced in commit 2563776b41c3 ("arm64: mte: Tags-aware copy_{user_,}highpage() implementations") and while this doesn't appear to be harmful in practice it is clearly wrong. Correct this by making `kto` and `kfrom` void pointers. Fixes: 2563776b41c3 ("arm64: mte: Tags-aware copy_{user_,}highpage() implementations") Signed-off-by: Tong Tiangen Acked-by: Mark Rutland Reviewed-by: Kefeng Wang Link: https://lore.kernel.org/r/20220420030418.3189040-3-tongtiangen@huawei.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 381a1e274872e3a069775489519e180780bccfd7 Author: Randy Dunlap Date: Mon Mar 14 17:10:45 2022 -0700 x86/mm: Cleanup the control_va_addr_alignment() __setup handler [ Upstream commit 1ef64b1e89e6d4018da46e08ffc32779a31160c7 ] Clean up control_va_addr_alignment(): a. Make '=' required instead of optional (as documented). b. Print a warning if an invalid option value is used. c. Return 1 from the __setup handler when an invalid option value is used. This prevents the kernel from polluting init's (limited) environment space with the entire string. Fixes: dfb09f9b7ab0 ("x86, amd: Avoid cache aliasing penalties on AMD family 15h") Reported-by: Igor Zhbanov Signed-off-by: Randy Dunlap Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru Link: https://lore.kernel.org/r/20220315001045.7680-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 49887ad6ba636ca361834c27d05c00108426f5b9 Author: Krzysztof Kozlowski Date: Sat Apr 23 11:42:27 2022 +0200 irqchip/aspeed-scu-ic: Fix irq_of_parse_and_map() return value [ Upstream commit f03a9670d27d23fe734a456f16e2579b21ec02b4 ] The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO. Fixes: 04f605906ff0 ("irqchip: Add Aspeed SCU interrupt controller") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220423094227.33148-2-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 89a223d81114e461420b9fee83844cb2a9e98461 Author: Krzysztof Kozlowski Date: Sat Apr 23 11:42:26 2022 +0200 irqchip/aspeed-i2c-ic: Fix irq_of_parse_and_map() return value [ Upstream commit 50f0f26e7c8665763d0d7d3372dbcf191f94d077 ] The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO. Fixes: f48e699ddf70 ("irqchip/aspeed-i2c-ic: Add I2C IRQ controller for Aspeed") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220423094227.33148-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit c1cfb6f65238984fe5a5451fc5896f11322d178e Author: Daniel Thompson Date: Tue May 3 14:45:41 2022 +0100 irqchip/exiu: Fix acknowledgment of edge triggered interrupts [ Upstream commit 4efc851c36e389f7ed432edac0149acc5f94b0c7 ] Currently the EXIU uses the fasteoi interrupt flow that is configured by it's parent (irq-gic-v3.c). With this flow the only chance to clear the interrupt request happens during .irq_eoi() and (obviously) this happens after the interrupt handler has run. EXIU requires edge triggered interrupts to be acked prior to interrupt handling. Without this we risk incorrect interrupt dismissal when a new interrupt is delivered after the handler reads and acknowledges the peripheral but before the irq_eoi() takes place. Fix this by clearing the interrupt request from .irq_ack() if we are configured for edge triggered interrupts. This requires adopting the fasteoi-ack flow instead of the fasteoi to ensure the ack gets called. These changes have been tested using the power button on a Developerbox/SC2A11 combined with some hackery in gpio-keys so I can play with the different trigger mode [and an mdelay(500) so I can can check what happens on a double click in both modes]. Fixes: 706cffc1b912 ("irqchip/exiu: Add support for Socionext Synquacer EXIU controller") Signed-off-by: Daniel Thompson Reviewed-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220503134541.2566457-1-daniel.thompson@linaro.org Signed-off-by: Sasha Levin commit 737b14e49070dfed30f7559b7834ca2fb73b9688 Author: Randy Dunlap Date: Sun Mar 13 18:27:25 2022 -0700 x86: Fix return value of __setup handlers [ Upstream commit 12441ccdf5e2f5a01a46e344976cbbd3d46845c9 ] __setup() handlers should return 1 to obsolete_checksetup() in init/main.c to indicate that the boot option has been handled. A return of 0 causes the boot option/value to be listed as an Unknown kernel parameter and added to init's (limited) argument (no '=') or environment (with '=') strings. So return 1 from these x86 __setup handlers. Examples: Unknown kernel command line parameters "apicpmtimer BOOT_IMAGE=/boot/bzImage-517rc8 vdso=1 ring3mwait=disable", will be passed to user space. Run /sbin/init as init process with arguments: /sbin/init apicpmtimer with environment: HOME=/ TERM=linux BOOT_IMAGE=/boot/bzImage-517rc8 vdso=1 ring3mwait=disable Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu") Fixes: 77b52b4c5c66 ("x86: add "debugpat" boot option") Fixes: e16fd002afe2 ("x86/cpufeature: Enable RING3MWAIT for Knights Landing") Fixes: b8ce33590687 ("x86_64: convert to clock events") Reported-by: Igor Zhbanov Signed-off-by: Randy Dunlap Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru Link: https://lore.kernel.org/r/20220314012725.26661-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 20b946ef84961683a7012e84d78f1fad091bb31c Author: Johannes Berg Date: Thu Apr 14 14:04:02 2022 +0200 nl80211: don't hold RTNL in color change request [ Upstream commit 1b550a0bebfc0b69d6ec08fe6eb58953a8aec48a ] It's not necessary to hold the RTNL across color change requests, since all the inner locking needs only the wiphy mutex which we already hold as well. Fixes: 0d2ab3aea50b ("nl80211: add support for BSS coloring") Link: https://lore.kernel.org/r/20220414140402.32e03e8c261b.I5e7dc6bc563a129b938c43298da6bb4e812400a5@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit bd85a268bf824de814f67d1d63ddd7fbe783c883 Author: Christoph Hellwig Date: Mon Apr 18 06:53:07 2022 +0200 virtio_blk: fix the discard_granularity and discard_alignment queue limits [ Upstream commit 62952cc5bccd89b76d710de1d0b43244af0f2903 ] The discard_alignment queue limit is named a bit misleading means the offset into the block device at which the discard granularity starts. On the other hand the discard_sector_alignment from the virtio 1.1 looks similar to what Linux uses as discard granularity (even if not very well described): "discard_sector_alignment can be used by OS when splitting a request based on alignment. " And at least qemu does set it to the discard granularity. So stop setting the discard_alignment and use the virtio discard_sector_alignment to set the discard granularity. Fixes: 1f23816b8eb8 ("virtio_blk: add discard and write zeroes support") Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20220418045314.360785-5-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 18f2967418d031a390a5befe855dd0faa8af70b9 Author: James Clark Date: Wed Mar 9 19:43:13 2022 +0000 perf tools: Use Python devtools for version autodetection rather than runtime [ Upstream commit 630af16eee495f583db5202c3613d1b191f10694 ] This fixes the issue where the build will fail if only the Python2 runtime is installed but the Python3 devtools are installed. Currently the workaround is 'make PYTHON=python3'. Fix it by autodetecting Python based on whether python[x]-config exists rather than just python[x] because both are needed for the build. Then -config is stripped to find the Python runtime. Testing ======= * Auto detect links with Python3 when the v3 devtools are installed and only Python 2 runtime is installed * Auto detect links with Python2 when both devtools are installed * Sensible warning is printed if no Python devtools are installed * 'make PYTHON=x' still automatically sets PYTHON_CONFIG=x-config * 'make PYTHON=x' fails if x-config doesn't exist * 'make PYTHON=python3' overrides Python2 devtools * 'make PYTHON=python2' overrides Python3 devtools * 'make PYTHON_CONFIG=x-config' works * 'make PYTHON=x PYTHON_CONFIG=x' works * 'make PYTHON=missing' reports an error * 'make PYTHON_CONFIG=missing' reports an error Fixes: 79373082fa9de8be ("perf python: Autodetect python3 binary") Signed-off-by: James Clark Cc: Alexander Shishkin Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Link: https://lore.kernel.org/r/20220309194313.3350126-2-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ac3319c4ccf41c650bfebe0761601b6133d014f7 Author: Ian Abbott Date: Wed Apr 27 16:34:46 2022 +0100 spi: cadence-quadspi: fix Direct Access Mode disable for SoCFPGA [ Upstream commit f724c296f2f2cc3f9342b0fc26239635cbed856e ] The Cadence QSPI compatible string required for the SoCFPGA platform changed from the default "cdns,qspi-nor" to "intel,socfpga-qspi" with the introduction of an additional quirk in commit 98d948eb8331 ("spi: cadence-quadspi: fix write completion support"). However, that change did not preserve the previously used quirk for this platform. Reinstate the `CQSPI_DISABLE_DAC_MODE` quirk for the SoCFPGA platform. Fixes: 98d948eb8331 ("spi: cadence-quadspi: fix write completion support") Cc: Dinh Nguyen Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20220427153446.10113-1-abbotti@mev.co.uk Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b54926bd558d97c888c3d2d87886f3c159d3254a Author: Yang Yingliang Date: Fri Apr 22 11:28:54 2022 +0800 drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() [ Upstream commit f8c242908ad15bbd604d3bcb54961b7d454c43f8 ] It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver") Signed-off-by: Yang Yingliang Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422032854.2995175-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit bd14de73644e95ce7279f172f3a42bb121559522 Author: Daniel Latypov Date: Fri Apr 29 11:12:59 2022 -0700 kunit: fix debugfs code to use enum kunit_status, not bool [ Upstream commit 38289a26e1b8a37755f3e07056ca416c1ee2a2e8 ] Commit 6d2426b2f258 ("kunit: Support skipped tests") switched to using `enum kunit_status` to track the result of running a test/suite since we now have more than just pass/fail. This callsite wasn't updated, silently converting to enum to a bool and then back. Fixes: 6d2426b2f258 ("kunit: Support skipped tests") Signed-off-by: Daniel Latypov Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit ee21431e3022320b2abc9f5db3b06ae3f8021ab6 Author: Jagan Teki Date: Thu Nov 11 15:11:03 2021 +0530 drm/panel: panel-simple: Fix proper bpc for AM-1280800N3TZQW-T00H [ Upstream commit 7eafbecd2288c542ea15ea20cf1a7e64a25c21bc ] AM-1280800N3TZQW-T00H panel support 8 bpc not 6 bpc as per recent testing in i.MX8MM platform. Fix it. Fixes: bca684e69c4c ("drm/panel: simple: Add AM-1280800N3TZQW-T00H") Signed-off-by: Jagan Teki Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20211111094103.494831-1-jagan@amarulasolutions.com Signed-off-by: Sasha Levin commit 4d6582938ad3c032b82ebc101f1b7116532348ad Author: Dmitry Baryshkov Date: Sat Apr 30 21:09:17 2022 +0300 drm/msm: add missing include to msm_drv.c [ Upstream commit 8123fe83c3a3448bbfa5b5b1cacfdfe7d076fca6 ] Add explicit include of drm_bridge.h to the msm_drv.c to fix the following warning: drivers/gpu/drm/msm/msm_drv.c:236:17: error: implicit declaration of function 'drm_bridge_remove'; did you mean 'drm_bridge_detach'? [-Werror=implicit-function-declaration] Fixes: d28ea556267c ("drm/msm: properly add and remove internal bridges") Reported-by: kernel test robot Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/484310/ Link: https://lore.kernel.org/r/20220430180917.3819294-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e5d7cb9a18f111aa08bb42c19fa7ad05aa9ce268 Author: Lv Ruyi Date: Mon Apr 25 09:18:31 2022 +0000 drm/msm/hdmi: fix error check return value of irq_of_parse_and_map() [ Upstream commit 03371e4fbdeb7f596cbceacb59e474248b6d95ac ] The irq_of_parse_and_map() function returns 0 on failure, and does not return a negative value anyhow, so never enter this conditional branch. Fixes: f6a8eaca0ea1 ("drm/msm/mdp5: use irqdomains") Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/483294/ Link: https://lore.kernel.org/r/20220425091831.3500487-1-lv.ruyi@zte.com.cn Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 4cd66a8016b872a153bf892fe4258cbc0dacf5b1 Author: Yang Yingliang Date: Fri Apr 22 11:22:27 2022 +0800 drm/msm/hdmi: check return value after calling platform_get_resource_byname() [ Upstream commit a36e506711548df923ceb7ec9f6001375be799a5 ] It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Fixes: c6a57a50ad56 ("drm/msm/hdmi: add hdmi hdcp support (V3)") Signed-off-by: Yang Yingliang Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/482992/ Link: https://lore.kernel.org/r/20220422032227.2991553-1-yangyingliang@huawei.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 212ecbeaf10a196529314525f6a36bed53f690c0 Author: Dmitry Baryshkov Date: Sat Apr 2 02:11:04 2022 +0300 drm/msm/dsi: fix error checks and return values for DSI xmit functions [ Upstream commit f0e7e9ed379c012c4d6b09a09b868accc426223c ] As noticed by Dan ([1] an the followup thread) there are multiple issues with the return values for MSM DSI command transmission callback. In the error case it can easily return a positive value when it should have returned a proper error code. This commits attempts to fix these issues both in TX and in RX paths. [1]: https://lore.kernel.org/linux-arm-msm/20211001123617.GH2283@kili/ Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support") Reported-by: Dan Carpenter Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Tested-by: Marijn Suijten Patchwork: https://patchwork.freedesktop.org/patch/480501/ Link: https://lore.kernel.org/r/20220401231104.967193-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit f7e3daef5e2324e2164e2610ed273e52d3bf0c61 Author: Kuogee Hsieh Date: Tue Apr 26 10:58:59 2022 -0700 drm/msm/dp: do not stop transmitting phy test pattern during DP phy compliance test [ Upstream commit 2788b4efa60c1e03ac10a156f3fdbd3be0f9198c ] At normal operation, transmit phy test pattern has to be terminated before DP controller switch to video ready state. However during phy compliance testing, transmit phy test pattern should not be terminated until end of compliance test which usually indicated by unplugged interrupt. Only stop sending the train pattern in dp_ctrl_on_stream() if we're not doing compliance testing. We also no longer reset 'p_level' and 'v_level' within dp_ctrl_on_link() due to both 'p_level' and 'v_level' are acquired from link status at previous dpcd read and we like to use those level to start link training. Changes in v2: -- add more details commit text -- correct Fixes Changes in v3: -- drop unnecessary braces Fixes: 2e0adc765d88 ("drm/msm/dp: do not end dp link training until video is ready") Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/483564/ Link: https://lore.kernel.org/r/1650995939-28467-3-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit bac5ff8594cb40941e69d6cc0c2659de133778b5 Author: Kuogee Hsieh Date: Tue Apr 26 10:58:58 2022 -0700 drm/msm/dp: reset DP controller before transmit phy test pattern [ Upstream commit 581d69981159b00f0443d171a4b900089f34ccfe ] DP controller state can not switch from video ready state to transmit phy pattern state at run time. DP mainlink has to be teared down followed by reset controller to default state to have DP controller switch to transmit phy test pattern state and start generate specified phy test pattern to sinker once main link setup again. Changes in v2: -- correct Fixes's commit id Fixes: 52352fe2f866 ("drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test run") Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/483563/ Link: https://lore.kernel.org/r/1650995939-28467-2-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 75ec09a929dd653b656f08bf2f530fe9462d917d Author: Lv Ruyi Date: Sun Apr 24 03:24:18 2022 +0000 drm/msm/dp: fix error check return value of irq_of_parse_and_map() [ Upstream commit e92d0d93f86699b7b25c7906613fdc374d66c8ca ] The irq_of_parse_and_map() function returns 0 on failure, and does not return an negative value. Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets") Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/483176/ Link: https://lore.kernel.org/r/20220424032418.3173632-1-lv.ruyi@zte.com.cn Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit d5e7956d8f5bda253d292b1e388da1142a123df9 Author: Kuogee Hsieh Date: Mon Apr 18 14:56:28 2022 -0700 drm/msm/dp: stop event kernel thread when DP unbind [ Upstream commit 570d3e5d28db7a94557fa179167a9fb8642fb8a1 ] Current DP driver implementation, event thread is kept running after DP display is unbind. This patch fix this problem by disabling DP irq and stop event thread to exit gracefully at dp_display_unbind(). Changes in v2: -- start event thread at dp_display_bind() Changes in v3: -- disable all HDP interrupts at unbind -- replace dp_hpd_event_setup() with dp_hpd_event_thread_start() -- replace dp_hpd_event_stop() with dp_hpd_event_thread_stop() -- move init_waitqueue_head(&dp->event_q) to probe() -- move spin_lock_init(&dp->event_lock) to probe() Changes in v4: -- relocate both dp_display_bind() and dp_display_unbind() to bottom of file Changes in v5: -- cancel relocation of both dp_display_bind() and dp_display_unbind() Changes in v6: -- move empty event q to dp_event_thread_start() Changes in v7: -- call ktheread_stop() directly instead of dp_hpd_event_thread_stop() function Changes in v8: -- return error immediately if audio registration failed. Changes in v9: -- return error immediately if event thread create failed. Changes in v10: -- delete extra DRM_ERROR("failed to create DP event thread\n"); Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets") Signed-off-by: Kuogee Hsieh Reported-by: Dmitry Baryshkov Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/482399/ Link: https://lore.kernel.org/r/1650318988-17580-1-git-send-email-quic_khsieh@quicinc.com [DB: fixed Fixes tag] Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit ef4bdaac7cb5416f236613ed9337ff0ea8ee329b Author: Vinod Polimera Date: Mon Apr 25 08:56:53 2022 +0530 drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume [ Upstream commit fa5186b279ecf44b14fb435540d2065be91cb1ed ] BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Vinod Polimera Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/483255/ Link: https://lore.kernel.org/r/1650857213-30075-1-git-send-email-quic_vpolimer@quicinc.com [DB: fixed Fixes tag] Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 4ae67e8494e1ef2445e528ac8c05f3fef2a1219f Author: Yang Jihong Date: Fri Apr 29 17:05:39 2022 +0800 perf tools: Add missing headers needed by util/data.h [ Upstream commit 4d27cf1d9de5becfa4d1efb2ea54dba1b9fc962a ] 'struct perf_data' in util/data.h uses the "u64" data type, which is defined in "linux/types.h". If we only include util/data.h, the following compilation error occurs: util/data.h:38:3: error: unknown type name ‘u64’ u64 version; ^~~ Solution: include "linux/types.h." to add the needed type definitions. Fixes: 258031c017c353e8 ("perf header: Add DIR_FORMAT feature to describe directory data") Signed-off-by: Yang Jihong Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20220429090539.212448-1-yangjihong1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 79c431eefd0812aff461c692f0fa739ffb463bf0 Author: Nicolas Frattaroli Date: Wed Apr 27 19:23:11 2022 +0200 ASoC: rk3328: fix disabling mclk on pclk probe failure [ Upstream commit dd508e324cdde1c06ace08a8143fa50333a90703 ] If preparing/enabling the pclk fails, the probe function should unprepare and disable the previously prepared and enabled mclk, which it doesn't do. This commit rectifies this. Fixes: c32759035ad2 ("ASoC: rockchip: support ACODEC for rk3328") Signed-off-by: Nicolas Frattaroli Reviewed-by: Katsuhiro Suzuki Link: https://lore.kernel.org/r/20220427172310.138638-1-frattaroli.nicolas@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 32f8691dd78902a678bbbe80c4a1aa8786d8ec08 Author: Josh Poimboeuf Date: Mon Apr 25 16:40:02 2022 -0700 x86/speculation: Add missing prototype for unpriv_ebpf_notify() [ Upstream commit 2147c438fde135d6c145a96e373d9348e7076f7f ] Fix the following warnings seen with "make W=1": kernel/sysctl.c:183:13: warning: no previous prototype for ‘unpriv_ebpf_notify’ [-Wmissing-prototypes] 183 | void __weak unpriv_ebpf_notify(int new_state) | ^~~~~~~~~~~~~~~~~~ arch/x86/kernel/cpu/bugs.c:659:6: warning: no previous prototype for ‘unpriv_ebpf_notify’ [-Wmissing-prototypes] 659 | void unpriv_ebpf_notify(int new_state) | ^~~~~~~~~~~~~~~~~~ Fixes: 44a3918c8245 ("x86/speculation: Include unprivileged eBPF status in Spectre v2 mitigation reporting") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/5689d065f739602ececaee1e05e68b8644009608.1650930000.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit e5b1e419cdb6dd8709eb05ed34039a3ded8e6003 Author: Yang Yingliang Date: Tue Apr 26 16:49:12 2022 +0800 mtd: rawnand: intel: fix possible null-ptr-deref in ebu_nand_probe() [ Upstream commit ddf66aefd685fd46500b9917333e1b1e118276dc ] It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Yang Yingliang Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-2-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 0cfee868b89ffa945f3d535ee5c985cb40c5a0f8 Author: Yang Yingliang Date: Tue Apr 26 16:49:11 2022 +0800 mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe() [ Upstream commit a28ed09dafee20da51eb26452950839633afd824 ] It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Signed-off-by: Yang Yingliang Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220426084913.4021868-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 6a97103fe022eaa443ce691ebf2601ebce1625e9 Author: Matthieu Baerts Date: Sat Apr 23 20:24:10 2022 +0200 x86/pm: Fix false positive kmemleak report in msr_build_context() [ Upstream commit b0b592cf08367719e1d1ef07c9f136e8c17f7ec3 ] Since e2a1256b17b1 ("x86/speculation: Restore speculation related MSRs during S3 resume") kmemleak reports this issue: unreferenced object 0xffff888009cedc00 (size 256): comm "swapper/0", pid 1, jiffies 4294693823 (age 73.764s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 48 00 00 00 00 00 00 00 ........H....... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: msr_build_context (include/linux/slab.h:621) pm_check_save_msr (arch/x86/power/cpu.c:520) do_one_initcall (init/main.c:1298) kernel_init_freeable (init/main.c:1370) kernel_init (init/main.c:1504) ret_from_fork (arch/x86/entry/entry_64.S:304) Reproducer: - boot the VM with a debug kernel config (see https://github.com/multipath-tcp/mptcp_net-next/issues/268) - wait ~1 minute - start a kmemleak scan The root cause here is alignment within the packed struct saved_context (from suspend_64.h). Kmemleak only searches for pointers that are aligned (see how pointers are scanned in kmemleak.c), but pahole shows that the saved_msrs struct member and all members after it in the structure are unaligned: struct saved_context { struct pt_regs regs; /* 0 168 */ /* --- cacheline 2 boundary (128 bytes) was 40 bytes ago --- */ u16 ds; /* 168 2 */ ... u64 misc_enable; /* 232 8 */ bool misc_enable_saved; /* 240 1 */ /* Note below odd offset values for the remainder of this struct */ struct saved_msrs saved_msrs; /* 241 16 */ /* --- cacheline 4 boundary (256 bytes) was 1 bytes ago --- */ long unsigned int efer; /* 257 8 */ u16 gdt_pad; /* 265 2 */ struct desc_ptr gdt_desc; /* 267 10 */ u16 idt_pad; /* 277 2 */ struct desc_ptr idt; /* 279 10 */ u16 ldt; /* 289 2 */ u16 tss; /* 291 2 */ long unsigned int tr; /* 293 8 */ long unsigned int safety; /* 301 8 */ long unsigned int return_address; /* 309 8 */ /* size: 317, cachelines: 5, members: 25 */ /* last cacheline: 61 bytes */ } __attribute__((__packed__)); Move misc_enable_saved to the end of the struct declaration so that saved_msrs fits in before the cacheline 4 boundary. The comment above the saved_context declaration says to fix wakeup_64.S file and __save/__restore_processor_state() if the struct is modified: it looks like all the accesses in wakeup_64.S are done through offsets which are computed at build-time. Update that comment accordingly. At the end, the false positive kmemleak report is due to a limitation from kmemleak but it is always good to avoid unaligned members for optimisation purposes. Please note that it looks like this issue is not new, e.g. https://lore.kernel.org/all/9f1bb619-c4ee-21c4-a251-870bd4db04fa@lwfinger.net/ https://lore.kernel.org/all/94e48fcd-1dbd-ebd2-4c91-f39941735909@molgen.mpg.de/ [ bp: Massage + cleanup commit message. ] Fixes: 7a9c2dd08ead ("x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume") Suggested-by: Mat Martineau Signed-off-by: Matthieu Baerts Signed-off-by: Borislav Petkov Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20220426202138.498310-1-matthieu.baerts@tessares.net Signed-off-by: Sasha Levin commit fad41a8f88567f693b0fb79e66a56a5b28fb0803 Author: Chen-Tsung Hsieh Date: Wed Jan 26 15:32:26 2022 +0800 mtd: spi-nor: core: Check written SR value in spi_nor_write_16bit_sr_and_check() [ Upstream commit 70dd83d737d8900b2d98db6dc6b928c596334d37 ] Read back Status Register 1 to ensure that the written byte match the received value and return -EIO if read back test failed. Without this patch, spi_nor_write_16bit_sr_and_check() only check the second half of the 16bit. It causes errors like spi_nor_sr_unlock() return success incorrectly when spi_nor_write_16bit_sr_and_check() doesn't write SR successfully. Fixes: 39d1e3340c73 ("mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()") Signed-off-by: Chen-Tsung Hsieh Signed-off-by: Pratyush Yadav Reviewed-by: Michael Walle Reviewed-by: Tudor Ambarus Acked-by: Pratyush Yadav Link: https://lore.kernel.org/r/20220126073227.3401275-1-chentsung@chromium.org Signed-off-by: Sasha Levin commit 32c7cbb75b368a3e2c2560b078c9778406823f2d Author: Andrii Nakryiko Date: Mon Apr 25 17:45:04 2022 -0700 libbpf: Fix logic for finding matching program for CO-RE relocation [ Upstream commit 966a7509325395c51c5f6d89e7352b0585e4804b ] Fix the bug in bpf_object__relocate_core() which can lead to finding invalid matching BPF program when processing CO-RE relocation. IF matching program is not found, last encountered program will be assumed to be correct program and thus error detection won't detect the problem. Fixes: 9c82a63cf370 ("libbpf: Fix CO-RE relocs against .text section") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220426004511.2691730-4-andrii@kernel.org Signed-off-by: Sasha Levin commit 2324985aa700457738fe737216140fb4f3d3f14a Author: Colin Ian King Date: Tue Apr 26 13:25:31 2022 +0100 selftests/resctrl: Fix null pointer dereference on open failed [ Upstream commit c7b607fa9325ccc94982774c505176677117689c ] Currently if opening /dev/null fails to open then file pointer fp is null and further access to fp via fprintf will cause a null pointer dereference. Fix this by returning a negative error value when a null fp is detected. Detected using cppcheck static analysis: tools/testing/selftests/resctrl/fill_buf.c:124:6: note: Assuming that condition '!fp' is not redundant if (!fp) ^ tools/testing/selftests/resctrl/fill_buf.c:126:10: note: Null pointer dereference fprintf(fp, "Sum: %d ", ret); Fixes: a2561b12fe39 ("selftests/resctrl: Add built in benchmark") Signed-off-by: Colin Ian King Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 4be045434923e549a50846a066a04b7b6c1d6d33 Author: Colin Ian King Date: Sun Apr 24 19:35:12 2022 +0100 drm/v3d: Fix null pointer dereference of pointer perfmon [ Upstream commit ce7a1ecf3f9f1fccaf67295307614511d8e11b13 ] In the unlikely event that pointer perfmon is null the WARN_ON return path occurs after the pointer has already been deferenced. Fix this by only dereferencing perfmon after it has been null checked. Fixes: 26a4dc29b74a ("drm/v3d: Expose performance counters to userspace") Signed-off-by: Colin Ian King Reviewed-by: Juan A. Suarez Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20220424183512.1365683-1-colin.i.king@gmail.com Signed-off-by: Sasha Levin commit 663d326bcf3ad410dcbc10231b405ab5c64b4d32 Author: Kiwoong Kim Date: Thu Mar 31 10:24:05 2022 +0900 scsi: ufs: core: Exclude UECxx from SFR dump list [ Upstream commit ef60031022eb6d972aac86ca26c98c33e1289436 ] Some devices may return invalid or zeroed data during an UIC error condition. In addition, reading these SFRs will clear them. This means the subsequent error handling will not be able to see them and therefore no error handling will be scheduled. Skip reading these SFRs in ufshcd_dump_regs(). Link: https://lore.kernel.org/r/1648689845-33521-1-git-send-email-kwmad.kim@samsung.com Fixes: d67247566450 ("scsi: ufs: Use explicit access size in ufshcd_dump_regs") Signed-off-by: Kiwoong Kim Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f265dea6b8b8ac601a9fd7624ec8a622782022a5 Author: Bart Van Assche Date: Tue Apr 19 15:58:05 2022 -0700 scsi: ufs: qcom: Fix ufs_qcom_resume() [ Upstream commit bee40dc167da159ea5b939c074e1da258610a3d6 ] Clearing hba->is_sys_suspended if ufs_qcom_resume() succeeds is wrong. That variable must only be cleared if all actions involved in a resume succeed. Hence remove the statement that clears hba->is_sys_suspended from ufs_qcom_resume(). Link: https://lore.kernel.org/r/20220419225811.4127248-23-bvanassche@acm.org Fixes: 81c0fc51b7a7 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms") Tested-by: Bean Huo Reviewed-by: Bjorn Andersson Reviewed-by: Bean Huo Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 90e9c14206e3a9e0827203a005d5ab70351ddc1f Author: Dan Carpenter Date: Thu Apr 21 18:03:52 2022 +0300 scsi: iscsi: Fix harmless double shift bug [ Upstream commit 565138ac5f8a5330669a20e5f94759764e9165ec ] These flags are supposed to be bit numbers. Right now they cause a double shift bug where we use BIT(BIT(2)) instead of BIT(2). Fortunately, the bit numbers are small and it's done consistently so it does not cause an issue at run time. Link: https://lore.kernel.org/r/YmFyWHf8nrrx+SHa@kili Fixes: 5bd856256f8c ("scsi: iscsi: Merge suspend fields") Reviewed-by: Mike Christie Reviewed-by: Lee Duncan Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fbe55bc9ab7bebe396babe6e6b62945b24c954a6 Author: Kuogee Hsieh Date: Fri Feb 25 13:23:09 2022 -0800 drm/msm/dpu: adjust display_v_end for eDP and DP [ Upstream commit e18aeea7f5efb9508722c8c7fd4d32e6f8cdfe50 ] The “DP timing” requires the active region to be defined in the bottom-right corner of the frame dimensions which is different with DSI. Therefore both display_h_end and display_v_end need to be adjusted accordingly. However current implementation has only display_h_end adjusted. Signed-off-by: Kuogee Hsieh Fixes: fc3a69ec68d3 ("drm/msm/dpu: intf timing path for displayport") Reviewed-by: Dmitry Baryshkov Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/476277/ Link: https://lore.kernel.org/r/1645824192-29670-2-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 6411d0c45878f159fa414aa8699c2c59738960f0 Author: Dmitry Baryshkov Date: Fri Oct 15 03:11:00 2021 +0300 drm/msm/hdmi: switch to drm_bridge_connector [ Upstream commit caa24223463dfd75702a24daac13c93edb4aafac ] Merge old hdmi_bridge and hdmi_connector implementations. Use drm_bridge_connector instead. Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Link: https://lore.kernel.org/r/20211015001100.4193241-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 181ec5b45a22c0902892e41bb97fc23a01441d8a Author: Bjorn Andersson Date: Sat Oct 16 15:18:38 2021 -0700 drm/msm/dp: Modify prototype of encoder based API [ Upstream commit 167dac97eb46c7b8a15b2195080e191bb0c9ce35 ] Functions in the DisplayPort code that relates to individual instances (encoders) are passed both the struct msm_dp and the struct drm_encoder. But in a situation where multiple DP instances would exist this means that the caller need to resolve which struct msm_dp relates to the struct drm_encoder at hand. Store a reference to the struct msm_dp associated with each dpu_encoder_virt to allow the particular instance to be associate with the encoder in the following patch. Reviewed-by: Abhinav Kumar Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211016221843.2167329-3-bjorn.andersson@linaro.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 9ea7148f61cd225959bbacc0b075db72169c8b59 Author: Yuanchu Xie Date: Mon Apr 18 20:20:17 2022 +0000 selftests/damon: add damon to selftests root Makefile [ Upstream commit 678f0cdc572c5fda940cb038d70eebb8d818adc8 ] Currently the damon selftests are not built with the rest of the selftests. We add damon to the list of targets. Fixes: b348eb7abd09 ("mm/damon: add user space selftests") Reviewed-by: SeongJae Park Signed-off-by: Yuanchu Xie Acked-by: David Rientjes Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6fbd040cae20db81725a7c0d4551db8e46689aa6 Author: Nuno Sá Date: Wed Apr 20 15:02:05 2022 +0200 of: overlay: do not break notify on NOTIFY_{OK|STOP} [ Upstream commit 5f756a2eaa4436d7d3dc1e040147f5e992ae34b5 ] We should not break overlay notifications on NOTIFY_{OK|STOP} otherwise we might break on the first fragment. We should only stop notifications if a *real* errno is returned by one of the listeners. Fixes: a1d19bd4cf1fe ("of: overlay: pr_err from return NOTIFY_OK to overlay apply/remove") Signed-off-by: Nuno Sá Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220420130205.89435-1-nuno.sa@analog.com Signed-off-by: Sasha Levin commit 9b2aa765fb29ddcb67ea760fb8868ef1f8fafefa Author: Luca Ceresoli Date: Thu Apr 21 23:32:51 2022 +0200 spi: rockchip: fix missing error on unsupported SPI_CS_HIGH [ Upstream commit d5d933f09ac326aebad85bfb787cc786ad477711 ] The hardware (except for the ROCKCHIP_SPI_VER2_TYPE2 version) does not support active-high native chip selects. However if such a CS is configured the core does not error as it normally should, because the 'ctlr->use_gpio_descriptors = true' line in rockchip_spi_probe() makes the core set SPI_CS_HIGH in ctlr->mode_bits. In such a case the spi-rockchip driver operates normally but produces an active-low chip select signal without notice. There is no provision in the current core code to handle this situation. Fix by adding a check in the ctlr->setup function (similarly to what spi-atmel.c does). This cannot be done reading the SPI_CS_HIGH but in ctlr->mode_bits because that bit gets always set by the core for master mode (see above). Fixes: eb1262e3cc8b ("spi: spi-rockchip: use num-cs property and ctlr->enable_gpiods") Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20220421213251.1077899-1-luca.ceresoli@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3359a48495ac176c9f8e943cb05e52a611819ceb Author: Jon Lin Date: Wed Feb 16 09:40:26 2022 +0800 spi: rockchip: Preset cs-high and clk polarity in setup progress [ Upstream commit 3a4bf922d42efa4e9a3dc803d1fd786d43e8a501 ] After power up, the cs and clock is in default status, and the cs-high and clock polarity dts property configuration will take no effect until the calling of rockchip_spi_config in the first transmission. So preset them to make sure a correct voltage before the first transmission coming. Signed-off-by: Jon Lin Link: https://lore.kernel.org/r/20220216014028.8123-5-jon.lin@rock-chips.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 523f6fe7b0340c904d495cbbb8a9d27c0d06b57c Author: Jon Lin Date: Wed Feb 16 09:40:25 2022 +0800 spi: rockchip: Stop spi slave dma receiver when cs inactive [ Upstream commit 869f2c94db92f0f1d6acd0dff1c1ebb8160f5e29 ] The spi which's version is higher than ver 2 will automatically enable this feature. If the length of master transmission is uncertain, the RK spi slave is better to automatically stop after cs inactive instead of waiting for xfer_completion forever. Signed-off-by: Jon Lin Link: https://lore.kernel.org/r/20220216014028.8123-4-jon.lin@rock-chips.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit eb57de933e4ad0b5c1dee45b40f452c33cd6c83c Author: Amir Goldstein Date: Fri Apr 22 15:03:14 2022 +0300 fsnotify: fix wrong lockdep annotations [ Upstream commit 623af4f538b5df9b416e1b82f720af7371b4c771 ] Commit 6960b0d909cd ("fsnotify: change locking order") changed some of the mark_mutex locks in direct reclaim path to use: mutex_lock_nested(&group->mark_mutex, SINGLE_DEPTH_NESTING); This change is explained: "...It uses nested locking to avoid deadlock in case we do the final iput() on an inode which still holds marks and thus would take the mutex again when calling fsnotify_inode_delete() in destroy_inode()." The problem is that the mutex_lock_nested() is not a nested lock at all. In fact, it has the opposite effect of preventing lockdep from warning about a very possible deadlock. Due to these wrong annotations, a deadlock that was introduced with nfsd filecache in kernel v5.4 went unnoticed in v5.4.y for over two years until it was reported recently by Khazhismel Kumykov, only to find out that the deadlock was already fixed in kernel v5.5. Fix the wrong lockdep annotations. Cc: Khazhismel Kumykov Fixes: 6960b0d909cd ("fsnotify: change locking order") Link: https://lore.kernel.org/r/20220321112310.vpr7oxro2xkz5llh@quack3.lan/ Link: https://lore.kernel.org/r/20220422120327.3459282-4-amir73il@gmail.com Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 4ab1195c213d5c6736efa576d7baedfae09fdb3e Author: Amir Goldstein Date: Fri Apr 22 15:03:12 2022 +0300 inotify: show inotify mask flags in proc fdinfo [ Upstream commit a32e697cda27679a0327ae2cafdad8c7170f548f ] The inotify mask flags IN_ONESHOT and IN_EXCL_UNLINK are not "internal to kernel" and should be exposed in procfs fdinfo so CRIU can restore them. Fixes: 6933599697c9 ("inotify: hide internal kernel bits from fdinfo") Link: https://lore.kernel.org/r/20220422120327.3459282-2-amir73il@gmail.com Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit f41c9418c5898c01634675150696da290fb86796 Author: Bjørn Mork Date: Mon Mar 28 18:11:08 2022 +0200 mtdblock: warn if opened on NAND [ Upstream commit 96a3295c351da82d7af99b2fc004a3cf9f4716a9 ] Warning on every translated mtd partition results in excessive log noise if this driver is loaded: nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 nand: Macronix MX30LF1G18AC nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits read_bbt: found bbt at block 1023 10 fixed-partitions partitions found on MTD device mt7621-nand Creating 10 MTD partitions on "mt7621-nand": 0x000000000000-0x000000080000 : "Bootloader" mtdblock: MTD device 'Bootloader' is NAND, please consider using UBI block devices instead. 0x000000080000-0x000000100000 : "Config" mtdblock: MTD device 'Config' is NAND, please consider using UBI block devices instead. 0x000000100000-0x000000140000 : "Factory" mtdblock: MTD device 'Factory' is NAND, please consider using UBI block devices instead. 0x000000140000-0x000002000000 : "Kernel" mtdblock: MTD device 'Kernel' is NAND, please consider using UBI block devices instead. 0x000000540000-0x000002000000 : "ubi" mtdblock: MTD device 'ubi' is NAND, please consider using UBI block devices instead. 0x000002140000-0x000004000000 : "Kernel2" mtdblock: MTD device 'Kernel2' is NAND, please consider using UBI block devices instead. 0x000004000000-0x000004100000 : "wwan" mtdblock: MTD device 'wwan' is NAND, please consider using UBI block devices instead. 0x000004100000-0x000005100000 : "data" mtdblock: MTD device 'data' is NAND, please consider using UBI block devices instead. 0x000005100000-0x000005200000 : "rom-d" mtdblock: MTD device 'rom-d' is NAND, please consider using UBI block devices instead. 0x000005200000-0x000005280000 : "reserve" mtdblock: MTD device 'reserve' is NAND, please consider using UBI block devices instead. mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 21 This is more likely to annoy than to help users of embedded distros where this driver is enabled by default. Making the blockdevs available does not imply that they are in use, and warning about bootloader partitions or other devices which obviously never will be mounted is more confusing than helpful. Move the warning to open(), where it will be of more use - actually warning anyone who mounts a file system on NAND using mtdblock. Fixes: e07403a8c6be ("mtdblock: Warn if added for a NAND device") Signed-off-by: Bjørn Mork Reviewed-by: Ezequiel Garcia Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220328161108.87757-1-bjorn@mork.no Signed-off-by: Sasha Levin commit 7784d22f81a29df2ec57ca90d54f93a35cbcd1a2 Author: Colin Ian King Date: Sun Apr 24 21:59:45 2022 +0100 ALSA: pcm: Check for null pointer of pointer substream before dereferencing it [ Upstream commit 011b559be832194f992f73d6c0d5485f5925a10b ] Pointer substream is being dereferenced on the assignment of pointer card before substream is being null checked with the macro PCM_RUNTIME_CHECK. Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the the pointer check before card is assigned. Fixes: d4cfb30fce03 ("ALSA: pcm: Set per-card upper limit of PCM buffer allocations") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20220424205945.1372247-1-colin.i.king@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 260cd3146fc4a3f5af7a14387526332363b4af9d Author: Marek Vasut Date: Wed Apr 6 11:36:27 2022 +0200 drm/panel: simple: Add missing bus flags for Innolux G070Y2-L01 [ Upstream commit 0f73a559f916b618c0c05186bd644c90cc9e9695 ] The DE signal is active high on this display, fill in the missing bus_flags. This aligns panel_desc with its display_timing . Fixes: a5d2ade627dca ("drm/panel: simple: Add support for Innolux G070Y2-L01") Signed-off-by: Marek Vasut Cc: Christoph Fritz Cc: Laurent Pinchart Cc: Maxime Ripard Cc: Sam Ravnborg Cc: Thomas Zimmermann Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20220406093627.18011-1-marex@denx.de Signed-off-by: Sasha Levin commit 1911bc6e6d24a125fd3e88f23548a4a5db747c7a Author: Chen-Yu Tsai Date: Thu Mar 31 09:49:06 2022 +0100 media: hantro: Empty encoder capture buffers by default [ Upstream commit 309373a3571ef7175bd9da0c9b13476a718e8478 ] The payload size for encoder capture buffers is set by the driver upon finishing encoding each frame, based on the encoded length returned from hardware, and whatever header and padding length used. Setting a non-zero default serves no real purpose, and also causes issues if the capture buffer is returned to userspace unused, confusing the application. Instead, always set the payload size to 0 for encoder capture buffers when preparing them. Fixes: 775fec69008d ("media: add Rockchip VPU JPEG encoder driver") Fixes: 082aaecff35f ("media: hantro: Fix .buf_prepare") Signed-off-by: Chen-Yu Tsai Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a4ec75df70575cdf33d9638c7844e729bfe6ce24 Author: Laurentiu Palcu Date: Mon Mar 7 16:46:07 2022 +0000 media: i2c: max9286: fix kernel oops when removing module [ Upstream commit 365ab7ebc24eebb42b9e020aeb440d51af8960cd ] When removing the max9286 module we get a kernel oops: Unable to handle kernel paging request at virtual address 000000aa00000094 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000 [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : i2c_mux_del_adapters+0x24/0xf0 lr : max9286_remove+0x28/0xd0 [max9286] sp : ffff800013a9bbf0 x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000 x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8 x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000 Call trace: i2c_mux_del_adapters+0x24/0xf0 max9286_remove+0x28/0xd0 [max9286] i2c_device_remove+0x40/0x110 __device_release_driver+0x188/0x234 driver_detach+0xc4/0x150 bus_remove_driver+0x60/0xe0 driver_unregister+0x34/0x64 i2c_del_driver+0x58/0xa0 max9286_i2c_driver_exit+0x1c/0x490 [max9286] __arm64_sys_delete_module+0x194/0x260 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xd4/0xfc do_el0_svc+0x2c/0x94 el0_svc+0x28/0x80 el0t_64_sync_handler+0xa8/0x130 el0t_64_sync+0x1a0/0x1a4 The Oops happens because the I2C client data does not point to max9286_priv anymore but to v4l2_subdev. The change happened in max9286_init() which calls v4l2_i2c_subdev_init() later on... Besides fixing the max9286_remove() function, remove the call to i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make the necessary changes to max9286_init() so that it doesn't have to use i2c_get_clientdata() in order to fetch the pointer to priv. Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Laurentiu Palcu Reviewed-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 678c63978e09f681f72b94f0b5f3fc7ab1d4e656 Author: Jacopo Mondi Date: Fri Dec 17 15:30:18 2021 +0100 media: i2c: max9286: Use "maxim,gpio-poc" property [ Upstream commit c9352df7139bc5be6642ebc8a78b40477ab32acd ] The 'maxim,gpio-poc' property is used when the remote camera power-over-coax is controlled by one of the MAX9286 gpio lines, to instruct the driver about which line to use and what the line polarity is. Add to the max9286 driver support for parsing the newly introduced property and use it if available in place of the usual supply, as it is not possible to establish one as consumer of the max9286 gpio controller. If the new property is present, no gpio controller is registered and 'poc-supply' is ignored. In order to maximize code re-use, break out the max9286 gpio handling function so that they can be used by the gpio controller through the gpio-consumer API, or directly by the driver code. Wrap the power up and power down routines to their own function to be able to use either the gpio line directly or the supply. This will make it easier to control the remote camera power at run time. Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d7678a7a55d063a67b5b3432f9ca97c7785bc255 Author: Niklas Söderlund Date: Wed Dec 8 13:17:56 2021 +0100 media: i2c: max9286: Use dev_err_probe() helper [ Upstream commit df78b858e773967112b4444400fb7bb5bd7a9d8a ] Use the dev_err_probe() helper, instead of open-coding the same operation. While at it retrieve the error once and use it from 'ret' instead of retrieving it twice. Link: https://lore.kernel.org/linux-media/20211208121756.3051565-1-niklas.soderlund+renesas@ragnatech.se Suggested-by: Geert Uytterhoeven Signed-off-by: Niklas S\xF6derlund Reviewed-by: Geert Uytterhoeven Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7f6defe0fabc79f29603c6fa3c80e4fe0456a3e9 Author: Dan Carpenter Date: Sat Apr 9 09:12:25 2022 +0300 ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix [ Upstream commit 2dc509305cf956381532792cb8dceef2b1504765 ] The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' Fixes: 4ed1a8d4a257 ("ath9k_htc: use ath9k_cmn_rx_accept") Signed-off-by: Dan Carpenter Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220409061225.GA5447@kili Signed-off-by: Sasha Levin commit 5c7957948c58b1c1528f8821993153fb01c3bbae Author: John Ogness Date: Thu Apr 21 23:28:40 2022 +0206 printk: wake waiters for safe and NMI contexts [ Upstream commit 5341b93dea8c39d7612f7a227015d4b1d5cf30db ] When printk() is called from safe or NMI contexts, it will directly store the record (vprintk_store()) and then defer the console output. However, defer_console_output() only causes console printing and does not wake any waiters of new records. Wake waiters from defer_console_output() so that they also are aware of the new records from safe and NMI contexts. Fixes: 03fc7f9c99c1 ("printk/nmi: Prevent deadlock when accessing the main log buffer in NMI") Signed-off-by: John Ogness Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20220421212250.565456-6-john.ogness@linutronix.de Signed-off-by: Sasha Levin commit 3b336d607b78427b2710ee17cedf61ef53112be7 Author: John Ogness Date: Thu Apr 21 23:28:38 2022 +0206 printk: add missing memory barrier to wake_up_klogd() [ Upstream commit 1f5d783094cf28b4905f51cad846eb5d1db6673e ] It is important that any new records are visible to preparing waiters before the waker checks if the wait queue is empty. Otherwise it is possible that: - there are new records available - the waker sees an empty wait queue and does not wake - the preparing waiter sees no new records and begins to wait This is exactly the problem that the function description of waitqueue_active() warns about. Use wq_has_sleeper() instead of waitqueue_active() because it includes the necessary full memory barrier. Signed-off-by: John Ogness Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20220421212250.565456-4-john.ogness@linutronix.de Signed-off-by: Sasha Levin commit 195cb7826a477fba62c88680155e25c9df78446d Author: John Ogness Date: Fri Feb 11 12:29:37 2022 +0106 printk: use atomic updates for klogd work [ Upstream commit 2ba3673d70178bf07fb75ff25c54bc478add4021 ] The per-cpu @printk_pending variable can be updated from sleepable contexts, such as: get_random_bytes() warn_unseeded_randomness() printk_deferred() defer_console_output() and can be updated from interrupt contexts, such as: handle_irq_event_percpu() __irq_wake_thread() wake_up_process() try_to_wake_up() select_task_rq() select_fallback_rq() printk_deferred() defer_console_output() and can be updated from NMI contexts, such as: vprintk() if (in_nmi()) defer_console_output() Therefore the atomic variant of the updating functions must be used. Replace __this_cpu_xchg() with this_cpu_xchg(). Replace __this_cpu_or() with this_cpu_or(). Reported-by: Sebastian Andrzej Siewior Signed-off-by: John Ogness Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/87iltld4ue.fsf@jogness.linutronix.de Signed-off-by: Sasha Levin commit bf422b68e7727e19b7a9dc5a97e766a9ab0387c7 Author: Schspa Shi Date: Thu Apr 21 03:15:41 2022 +0800 cpufreq: Fix possible race in cpufreq online error path [ Upstream commit f346e96267cd76175d6c201b40f770c0116a8a04 ] When cpufreq online fails, the policy->cpus mask is not cleared and policy->rwsem is released too early, so the driver can be invoked via the cpuinfo_cur_freq sysfs attribute while its ->offline() or ->exit() callbacks are being run. Take policy->clk as an example: static int cpufreq_online(unsigned int cpu) { ... // policy->cpus != 0 at this time down_write(&policy->rwsem); ret = cpufreq_add_dev_interface(policy); up_write(&policy->rwsem); return 0; out_destroy_policy: for_each_cpu(j, policy->real_cpus) remove_cpu_dev_symlink(policy, get_cpu_device(j)); up_write(&policy->rwsem); ... out_exit_policy: if (cpufreq_driver->exit) cpufreq_driver->exit(policy); clk_put(policy->clk); // policy->clk is a wild pointer ... ^ | Another process access __cpufreq_get cpufreq_verify_current_freq cpufreq_generic_get // acces wild pointer of policy->clk; | | out_offline_policy: | cpufreq_policy_free(policy); | // deleted here, and will wait for no body reference cpufreq_policy_put_kobj(policy); } Address this by modifying cpufreq_online() to release policy->rwsem in the error path after the driver callbacks have run and to clear policy->cpus before releasing the semaphore. Fixes: 7106e02baed4 ("cpufreq: release policy->rwsem on error") Signed-off-by: Schspa Shi [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7ba2bb87e9e9bc8ed930d18027d200cd767d5b23 Author: Zheng Yongjun Date: Fri Apr 22 06:26:41 2022 +0000 spi: img-spfi: Fix pm_runtime_get_sync() error checking [ Upstream commit cc470d55343056d6b2a5c32e10e0aad06f324078 ] If the device is already in a runtime PM enabled state pm_runtime_get_sync() will return 1, so a test for negative value should be used to check for errors. Fixes: deba25800a12b ("spi: Add driver for IMG SPFI controller") Signed-off-by: Zheng Yongjun Link: https://lore.kernel.org/r/20220422062641.10486-1-zhengyongjun3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dc4d1f3b53f86a5132b35f2855b042c15d57be5e Author: Chengming Zhou Date: Fri Apr 8 20:19:14 2022 +0800 sched/psi: report zeroes for CPU full at the system level [ Upstream commit 890d550d7dbac7a31ecaa78732aa22be282bb6b8 ] Martin find it confusing when look at the /proc/pressure/cpu output, and found no hint about that CPU "full" line in psi Documentation. % cat /proc/pressure/cpu some avg10=0.92 avg60=0.91 avg300=0.73 total=933490489 full avg10=0.22 avg60=0.23 avg300=0.16 total=358783277 The PSI_CPU_FULL state is introduced by commit e7fcd7622823 ("psi: Add PSI_CPU_FULL state"), which mainly for cgroup level, but also counted at the system level as a side effect. Naturally, the FULL state doesn't exist for the CPU resource at the system level. These "full" numbers can come from CPU idle schedule latency. For example, t1 is the time when task wakeup on an idle CPU, t2 is the time when CPU pick and switch to it. The delta of (t2 - t1) will be in CPU_FULL state. Another case all processes can be stalled is when all cgroups have been throttled at the same time, which unlikely to happen. Anyway, CPU_FULL metric is meaningless and confusing at the system level. So this patch will report zeroes for CPU full at the system level, and update psi Documentation accordingly. Fixes: e7fcd7622823 ("psi: Add PSI_CPU_FULL state") Reported-by: Martin Steigerwald Suggested-by: Johannes Weiner Signed-off-by: Chengming Zhou Signed-off-by: Peter Zijlstra (Intel) Acked-by: Johannes Weiner Link: https://lore.kernel.org/r/20220408121914.82855-1-zhouchengming@bytedance.com Signed-off-by: Sasha Levin commit 36f416fdda1e0055be4bf2c77657b43ef43761a3 Author: Chengming Zhou Date: Fri Apr 8 19:53:08 2022 +0800 sched/fair: Fix cfs_rq_clock_pelt() for throttled cfs_rq [ Upstream commit 64eaf50731ac0a8c76ce2fedd50ef6652aabc5ff ] Since commit 23127296889f ("sched/fair: Update scale invariance of PELT") change to use rq_clock_pelt() instead of rq_clock_task(), we should also use rq_clock_pelt() for throttled_clock_task_time and throttled_clock_task accounting to get correct cfs_rq_clock_pelt() of throttled cfs_rq. And rename throttled_clock_task(_time) to be clock_pelt rather than clock_task. Fixes: 23127296889f ("sched/fair: Update scale invariance of PELT") Signed-off-by: Chengming Zhou Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ben Segall Reviewed-by: Vincent Guittot Link: https://lore.kernel.org/r/20220408115309.81603-1-zhouchengming@bytedance.com Signed-off-by: Sasha Levin commit 60768ffcede23197efbceb391437c9e22d9c7718 Author: Marco Elver Date: Mon Apr 4 13:12:04 2022 +0200 signal: Deliver SIGTRAP on perf event asynchronously if blocked [ Upstream commit 78ed93d72ded679e3caf0758357209887bda885f ] With SIGTRAP on perf events, we have encountered termination of processes due to user space attempting to block delivery of SIGTRAP. Consider this case: ... sigset_t s; sigemptyset(&s); sigaddset(&s, SIGTRAP | ); sigprocmask(SIG_BLOCK, &s, ...); ... When the perf event triggers, while SIGTRAP is blocked, force_sig_perf() will force the signal, but revert back to the default handler, thus terminating the task. This makes sense for error conditions, but not so much for explicitly requested monitoring. However, the expectation is still that signals generated by perf events are synchronous, which will no longer be the case if the signal is blocked and delivered later. To give user space the ability to clearly distinguish synchronous from asynchronous signals, introduce siginfo_t::si_perf_flags and TRAP_PERF_FLAG_ASYNC (opted for flags in case more binary information is required in future). The resolution to the problem is then to (a) no longer force the signal (avoiding the terminations), but (b) tell user space via si_perf_flags if the signal was synchronous or not, so that such signals can be handled differently (e.g. let user space decide to ignore or consider the data imprecise). The alternative of making the kernel ignore SIGTRAP on perf events if the signal is blocked may work for some usecases, but likely causes issues in others that then have to revert back to interception of sigprocmask() (which we want to avoid). [ A concrete example: when using breakpoint perf events to track data-flow, in a region of code where signals are blocked, data-flow can no longer be tracked accurately. When a relevant asynchronous signal is received after unblocking the signal, the data-flow tracking logic needs to know its state is imprecise. ] Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") Reported-by: Dmitry Vyukov Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Acked-by: Geert Uytterhoeven Tested-by: Dmitry Vyukov Link: https://lore.kernel.org/r/20220404111204.935357-1-elver@google.com Signed-off-by: Sasha Levin commit 4c2122a3d07e3da2057853f46f1f43d95449ede6 Author: Nícolas F. R. A. Prado Date: Thu Apr 7 21:39:50 2022 -0400 drm/mediatek: dpi: Use mt8183 output formats for mt8192 [ Upstream commit 7112e0b0a58be8575547eba6596c42710922674f ] The configuration for mt8192 was incorrectly using the output formats from mt8173. Since the output formats for mt8192 are instead the same ones as for mt8183, which require two bus samples per pixel, the pixelclock and DDR edge setting were misconfigured. This made external displays unable to show the image. Fix the issue by correcting the output format for mt8192 to be the same as for mt8183, fixing the usage of external displays for mt8192. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220408013950.674477-1-nfraprado@collabora.com/ Fixes: be63f6e8601f ("drm/mediatek: dpi: Add output bus formats to driver data") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Rex-BC Chen Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit be96baa0c79588084e0d7a4fa21c574cec9a57f4 Author: Wei Yongjun Date: Thu Apr 21 09:03:35 2022 +0000 regulator: da9121: Fix uninit-value in da9121_assign_chip_model() [ Upstream commit bab76514aca36bc513224525d5598da676938218 ] KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access 'regmap' without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if 'chip->subvariant_id' is invalid. Fixes: f3fbd5566f6a ("regulator: da9121: Add device variants") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Adam Ward Link: https://lore.kernel.org/r/20220421090335.1876149-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c731d18a399e69639521226d706fa06a899c12b2 Author: Miaoqian Lin Date: Wed Apr 20 01:16:40 2022 +0000 drm/bridge: Fix error handling in analogix_dp_probe [ Upstream commit 9f15930bb2ef9f031d62ffc49629cbae89137733 ] In the error handling path, the clk_prepare_enable() function call should be balanced by a corresponding 'clk_disable_unprepare()' call, as already done in the remove function. Fixes: 3424e3a4f844 ("drm: bridge: analogix/dp: split exynos dp driver to bridge directory") Signed-off-by: Miaoqian Lin Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220420011644.25730-1-linmq006@gmail.com Signed-off-by: Sasha Levin commit 24f9dfdaece9bd75bb8dbfdba83eddeefdf7dc47 Author: Miaoqian Lin Date: Sat Apr 16 07:37:21 2022 +0000 HID: elan: Fix potential double free in elan_input_configured [ Upstream commit 1af20714fedad238362571620be0bd690ded05b6 ] 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails). Fixes: b7429ea53d6c ("HID: elan: Fix memleak in elan_input_configured") Fixes: 9a6a4193d65b ("HID: Add driver for USB ELAN Touchpad") Signed-off-by: Miaoqian Lin Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2573a45b51764d92b69470d6ae8a64d9a5349bba Author: Jonathan Teh Date: Sun Mar 13 19:48:18 2022 +0000 HID: hid-led: fix maximum brightness for Dream Cheeky [ Upstream commit 116c3f4a78ebe478d5ad5a038baf931e93e7d748 ] Increase maximum brightness for Dream Cheeky to 63. Emperically determined based on testing in kernel 4.4 on this device: Bus 003 Device 002: ID 1d34:0004 Dream Cheeky Webmail Notifier Fixes: 6c7ad07e9e05 ("HID: migrate USB LED driver from usb misc to hid") Signed-off-by: Jonathan Teh Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 3830dbdfb9a4aec680e43ed80b9f23db7a88eac9 Author: Zheyu Ma Date: Mon Apr 11 20:58:08 2022 +0800 mtd: rawnand: denali: Use managed device resources [ Upstream commit 3a745b51cddafade99aaea1b93aad31e9614e230 ] All of the resources used by this driver has managed interfaces, so use them. Otherwise we will get the following splat: [ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000 [ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5 [ 4.473538] nand: No NAND device found [ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410 [ 4.475169] #PF: supervisor write access in kernel mode [ 4.475579] #PF: error_code(0x0002) - not-present page [ 4.478362] RIP: 0010:iowrite32+0x9/0x50 [ 4.486068] Call Trace: [ 4.486269] [ 4.486443] denali_isr+0x15b/0x300 [denali] [ 4.486788] ? denali_direct_write+0x50/0x50 [denali] [ 4.487189] __handle_irq_event_percpu+0x161/0x3b0 [ 4.487571] handle_irq_event+0x7d/0x1b0 [ 4.487884] handle_fasteoi_irq+0x2b0/0x770 [ 4.488219] __common_interrupt+0xc8/0x1b0 [ 4.488549] common_interrupt+0x9a/0xc0 Fixes: 93db446a424c ("mtd: nand: move raw NAND related code to the raw/ subdir") Signed-off-by: Zheyu Ma Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220411125808.958276-1-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 814706376f362217ecf9534c935df6d69432ab7b Author: Tyler Hicks Date: Tue Jan 11 10:38:00 2022 -0600 EDAC/dmc520: Don't print an error for each unconfigured interrupt line [ Upstream commit ad2df24732e8956a45a00894d2163c4ee8fb0e1f ] The dmc520 driver requires that at least one interrupt line, out of the ten possible, is configured. The driver prints an error and returns -EINVAL from its .probe function if there are no interrupt lines configured. Don't print a KERN_ERR level message for each interrupt line that's unconfigured as that can confuse users into thinking that there is an error condition. Before this change, the following KERN_ERR level messages would be reported if only dram_ecc_errc and dram_ecc_errd were configured in the device tree: dmc520 68000000.dmc: IRQ ram_ecc_errc not found dmc520 68000000.dmc: IRQ ram_ecc_errd not found dmc520 68000000.dmc: IRQ failed_access not found dmc520 68000000.dmc: IRQ failed_prog not found dmc520 68000000.dmc: IRQ link_err not dmc520 68000000.dmc: IRQ temperature_event not found dmc520 68000000.dmc: IRQ arch_fsm not found dmc520 68000000.dmc: IRQ phy_request not found Fixes: 1088750d7839 ("EDAC: Add EDAC driver for DMC520") Reported-by: Sinan Kaya Signed-off-by: Tyler Hicks Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220111163800.22362-1-tyhicks@linux.microsoft.com Signed-off-by: Sasha Levin commit 4400e542b80f8c7f70995291e1d9c9d1a132cf56 Author: Arnd Bergmann Date: Wed Apr 6 21:07:09 2022 +0200 drbd: fix duplicate array initializer [ Upstream commit 33cb0917bbe241dd17a2b87ead63514c1b7e5615 ] There are two initializers for P_RETRY_WRITE: drivers/block/drbd/drbd_main.c:3676:22: warning: initialized field overwritten [-Woverride-init] Remove the first one since it was already ignored by the compiler and reorder the list to match the enum definition. As P_ZEROES had no entry, add that one instead. Fixes: 036b17eaab93 ("drbd: Receiving part for the PROTOCOL_UPDATE packet") Fixes: f31e583aa2c2 ("drbd: introduce P_ZEROES (REQ_OP_WRITE_ZEROES on the "wire")") Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Böhmwalder Link: https://lore.kernel.org/r/20220406190715.1938174-2-christoph.boehmwalder@linbit.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ae42074b409fcc6027990142f7790a390674ed95 Author: Christoph Hellwig Date: Fri Apr 15 06:52:32 2022 +0200 target: remove an incorrect unmap zeroes data deduction [ Upstream commit 179d8609d8424529e95021df939ed7b0b82b37f1 ] For block devices, the SCSI target drivers implements UNMAP as calls to blkdev_issue_discard, which does not guarantee zeroing just because Write Zeroes is supported. Note that this does not affect the file backed path which uses fallocate to punch holes. Fixes: 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout") Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20220415045258.199825-2-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c16539ef982c1a6e6d717310f4e6b6ab2be8c2a2 Author: Andy Shevchenko Date: Fri Apr 8 21:48:40 2022 +0300 device property: Allow error pointer to be passed to fwnode APIs [ Upstream commit 002752af7b89b74c64fe6bec8c5fde3d3a7810d8 ] Some of the fwnode APIs might return an error pointer instead of NULL or valid fwnode handle. The result of such API call may be considered optional and hence the test for it is usually done in a form of fwnode = fwnode_find_reference(...); if (IS_ERR(fwnode)) ...error handling... Nevertheless the resulting fwnode may have bumped the reference count and hence caller of the above API is obliged to call fwnode_handle_put(). Since fwnode may be not valid either as NULL or error pointer the check has to be performed there. This approach uglifies the code and adds a point of making a mistake, i.e. forgetting about error point case. To prevent this, allow an error pointer to be passed to the fwnode APIs. Fixes: 83b34afb6b79 ("device property: Introduce fwnode_find_reference()") Reported-by: Nuno Sá Tested-by: Nuno Sá Acked-by: Nuno Sá Reviewed-by: Sakari Ailus Reviewed-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Tested-by: Michael Walle Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ecc7b8dedf73cbc93db2891b62ba0f699caec618 Author: Daniel Scally Date: Sun Nov 28 23:24:55 2021 +0000 device property: Check fwnode->secondary when finding properties [ Upstream commit c097af1d0a8483b44fa30e86b311991d76b6ae67 ] fwnode_property_get_reference_args() searches for named properties against a fwnode_handle, but these could instead be against the fwnode's secondary. If the property isn't found against the primary, check the secondary to see if it's there instead. Reviewed-by: Andy Shevchenko Reviewed-by: Hans de Goede Signed-off-by: Daniel Scally Link: https://lore.kernel.org/r/20211128232455.39332-1-djrscally@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b61f1f3a0ea71ab946392c8dfedc5d327d9111ca Author: Jan Kiszka Date: Fri Mar 4 07:36:37 2022 +0100 efi: Add missing prototype for efi_capsule_setup_info [ Upstream commit aa480379d8bdb33920d68acfd90f823c8af32578 ] Fixes "no previous declaration for 'efi_capsule_setup_info'" warnings under W=1. Fixes: 2959c95d510c ("efi/capsule: Add support for Quark security header") Signed-off-by: Jan Kiszka Link: https://lore.kernel.org/r/c28d3f86-dd72-27d1-e2c2-40971b8da6bd@siemens.com Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 1632be63862f183cd5cf1cc094e698e6ec005dfd Author: Lin Ma Date: Tue Apr 12 13:32:08 2022 +0800 NFC: NULL out the dev->rfkill to prevent UAF [ Upstream commit 1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9 ] Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") assumes the device_is_registered() in function nfc_dev_up() will help to check when the rfkill is unregistered. However, this check only take effect when device_del(&dev->dev) is done in nfc_unregister_device(). Hence, the rfkill object is still possible be dereferenced. The crash trace in latest kernel (5.18-rc2): [ 68.760105] ================================================================== [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] [ 68.760756] dump_stack_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasan_report+0xbe/0x1c0 [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] __lock_acquire+0x3ec1/0x6750 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? register_lock_class+0x18d0/0x18d0 [ 68.760756] lock_acquire+0x1ac/0x4f0 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0 [ 68.760756] ? nla_get_range_signed+0x540/0x540 [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] rfkill_blocked+0xe/0x60 [ 68.760756] nfc_dev_up+0x84/0x260 [ 68.760756] nfc_genl_dev_up+0x90/0xe0 [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230 [ 68.760756] ? security_capable+0x51/0x90 [ 68.760756] genl_rcv_msg+0x280/0x500 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? lock_acquire+0x1ac/0x4f0 [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? netlink_ack+0x9c0/0x9c0 [ 68.760756] ? netlink_deliver_tap+0x136/0xb00 [ 68.760756] genl_rcv+0x1f/0x30 [ 68.760756] netlink_unicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlink_attachskb+0x740/0x740 [ 68.760756] ? __build_skb_around+0x1f4/0x2a0 [ 68.760756] netlink_sendmsg+0x75d/0xc00 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] sock_sendmsg+0xdf/0x110 [ 68.760756] __sys_sendto+0x19e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+0x195/0x4c0 [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0 [ 68.760756] __x64_sys_sendto+0xd8/0x1b0 [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130 [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003 [ 68.760756] [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasan_save_stack+0x1e/0x40 [ 68.760756] __kasan_kmalloc+0x81/0xa0 [ 68.760756] rfkill_alloc+0x7f/0x280 [ 68.760756] nfc_register_device+0xa3/0x1a0 [ 68.760756] nci_register_device+0x77a/0xad0 [ 68.760756] nfcmrvl_nci_register_dev+0x20b/0x2c0 [ 68.760756] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 68.760756] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 68.760756] tty_ioctl+0x764/0x1310 [ 68.760756] __x64_sys_ioctl+0x122/0x190 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] [ 68.760756] Freed by task 314: [ 68.760756] kasan_save_stack+0x1e/0x40 [ 68.760756] kasan_set_track+0x21/0x30 [ 68.760756] kasan_set_free_info+0x20/0x30 [ 68.760756] __kasan_slab_free+0x108/0x170 [ 68.760756] kfree+0xb0/0x330 [ 68.760756] device_release+0x96/0x200 [ 68.760756] kobject_put+0xf9/0x1d0 [ 68.760756] nfc_unregister_device+0x77/0x190 [ 68.760756] nfcmrvl_nci_unregister_dev+0x88/0xd0 [ 68.760756] nci_uart_tty_close+0xdf/0x180 [ 68.760756] tty_ldisc_kill+0x73/0x110 [ 68.760756] tty_ldisc_hangup+0x281/0x5b0 [ 68.760756] __tty_hangup.part.0+0x431/0x890 [ 68.760756] tty_release+0x3a8/0xc80 [ 68.760756] __fput+0x1f0/0x8c0 [ 68.760756] task_work_run+0xc9/0x170 [ 68.760756] exit_to_user_mode_prepare+0x194/0x1a0 [ 68.760756] syscall_exit_to_user_mode+0x19/0x50 [ 68.760756] do_syscall_64+0x48/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae This patch just add the null out of dev->rfkill to make sure such dereference cannot happen. This is safe since the device_lock() already protect the check/write from data race. Fixes: 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") Signed-off-by: Lin Ma Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0377e8f544a382c00270260a97342b0e9676e592 Author: Lv Ruyi Date: Tue Apr 12 08:51:26 2022 +0000 ixp4xx_eth: fix error check return value of platform_get_irq() [ Upstream commit f45ba67eb74ab4b775616af731bdf8944afce3f1 ] platform_get_irq() return negative value on failure, so null check of return value is incorrect. Fix it by comparing whether it is less than zero. Fixes: 9055a2f59162 ("ixp4xx_eth: make ptp support a platform driver") Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20220412085126.2532924-1-lv.ruyi@zte.com.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ffd4ae87a9f62cd93631c4bf1e575a0399136a30 Author: Russell King (Oracle) Date: Mon Apr 11 10:45:56 2022 +0100 net: dsa: mt7530: 1G can also support 1000BASE-X link mode [ Upstream commit 66f862563ed68717dfd84e808ca12705ed275ced ] When using an external PHY connected using RGMII to mt7531 port 5, the PHY can be used to used support 1000BASE-X connections. Moreover, if 1000BASE-T is supported, then we should allow 1000BASE-X as well, since which are supported is a property of the PHY. Therefore, it makes no sense to exclude this from the linkmodes when 1000BASE-T is supported. Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Tested-by: Marek Behún Signed-off-by: Russell King (Oracle) Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 79e852bf8fd07d2595bdde3f273947fe6a1a1e3c Author: Paul E. McKenney Date: Mon Feb 28 17:40:49 2022 -0800 scftorture: Fix distribution of short handler delays [ Upstream commit 8106bddbab5f0ba180e6d693c7c1fc6926d57caa ] The scftorture test module's scf_handler() function is supposed to provide three different distributions of short delays (including "no delay") and one distribution of long delays, if specified by the scftorture.longwait module parameter. However, the second of the two non-zero-wait short delays is disabled due to the first such delay's "goto out" not being enclosed in the "then" clause with the "udelay()". This commit therefore adjusts the code to provide the intended set of delays. Fixes: e9d338a0b179 ("scftorture: Add smp_call_function() torture test") Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit da840f354836d3303400ae5f26a655daed542477 Author: Miaoqian Lin Date: Mon Apr 11 11:10:33 2022 +0000 spi: spi-ti-qspi: Fix return value handling of wait_for_completion_timeout [ Upstream commit 8b1ea69a63eb62f97cef63e6d816b64ed84e8760 ] wait_for_completion_timeout() returns unsigned long not int. It returns 0 if timed out, and positive if completed. The check for <= 0 is ambiguous and should be == 0 here indicating timeout which is the only error case. Fixes: 5720ec0a6d26 ("spi: spi-ti-qspi: Add DMA support for QSPI mmap read") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220411111034.24447-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4cb37f715f601cee5b026c6f9091a466266b5ba5 Author: Jiasheng Jiang Date: Tue Dec 14 18:08:37 2021 +0800 drm: mali-dp: potential dereference of null pointer [ Upstream commit 73c3ed7495c67b8fbdc31cf58e6ca8757df31a33 ] The return value of kzalloc() needs to be checked. To avoid use of null pointer '&state->base' in case of the failure of alloc. Fixes: 99665d072183 ("drm: mali-dp: add malidp_crtc_state struct") Signed-off-by: Jiasheng Jiang Reviewed-by: Brian Starkey Signed-off-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20211214100837.46912-1-jiasheng@iscas.ac.cn Signed-off-by: Sasha Levin commit 7e6ad65b6dc56d693118d150ac59c30276702c18 Author: Zhou Qingyang Date: Wed Dec 1 11:37:03 2021 +0800 drm/komeda: Fix an undefined behavior bug in komeda_plane_add() [ Upstream commit f5e284bb74ab296f98122673c7ecd22028b2c200 ] In komeda_plane_add(), komeda_get_layer_fourcc_list() is assigned to formats and used in drm_universal_plane_init(). drm_universal_plane_init() passes formats to __drm_universal_plane_init(). __drm_universal_plane_init() further passes formats to memcpy() as src parameter, which could lead to an undefined behavior bug on failure of komeda_get_layer_fourcc_list(). Fix this bug by adding a check of formats. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DRM_KOMEDA=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 61f1c4a8ab75 ("drm/komeda: Attach komeda_dev to DRM-KMS") Signed-off-by: Zhou Qingyang Signed-off-by: Liviu Dudau Link: https://lore.kernel.org/dri-devel/20211201033704.32054-1-zhou1615@umn.edu Signed-off-by: Sasha Levin commit 48bd4e97dbfd3828fb29eff3ff4c8399b37f8c70 Author: Johannes Berg Date: Fri Mar 18 13:46:57 2022 +0100 nl80211: show SSID for P2P_GO interfaces [ Upstream commit a75971bc2b8453630e9f85e0beaa4da8db8277a3 ] There's no real reason not to send the SSID to userspace when it requests information about P2P_GO, it is, in that respect, exactly the same as AP interfaces. Fix that. Fixes: 44905265bc15 ("nl80211: don't expose wdev->ssid for most interfaces") Signed-off-by: Johannes Berg Link: https://lore.kernel.org/r/20220318134656.14354ae223f0.Ia25e85a512281b92e1645d4160766a4b1a471597@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c07f6772a058a6b8c8fbefc5b19631c2d21aee05 Author: Paolo Abeni Date: Fri Apr 8 12:45:56 2022 -0700 mptcp: reset the packet scheduler on PRIO change [ Upstream commit 0e203c324752e13d22624ab7ffafe934fa06ab50 ] Similar to the previous patch, for priority changes requested by the local PM. Reported-and-suggested-by: Davide Caratti Fixes: 067065422fcd ("mptcp: add the outgoing MP_PRIO support") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4b92cfc4446d422357cdba85b861264946428f22 Author: Maciej W. Rozycki Date: Thu Mar 31 08:11:10 2022 +0100 x86/PCI: Fix ALi M1487 (IBC) PIRQ router link value interpretation [ Upstream commit 4969e223b109754c2340a26bba9b1cf44f0cba9b ] Fix an issue with commit 1ce849c75534 ("x86/PCI: Add support for the ALi M1487 (IBC) PIRQ router") and correct ALi M1487 (IBC) PIRQ router link value (`pirq' cookie) interpretation according to findings in the BIOS. Credit to Nikolai Zhubr for the detective work as to the bit layout. Fixes: 1ce849c75534 ("x86/PCI: Add support for the ALi M1487 (IBC) PIRQ router") Signed-off-by: Maciej W. Rozycki Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203310013270.44113@angie.orcam.me.uk Signed-off-by: Sasha Levin commit 049a44dfd6df207c2f847a8d8c0edf51039611d9 Author: Andrii Nakryiko Date: Fri Apr 8 11:14:23 2022 -0700 libbpf: Don't error out on CO-RE relos for overriden weak subprogs [ Upstream commit e89d57d938c8fa80c457982154ed6110804814fe ] During BPF static linking, all the ELF relocations and .BTF.ext information (including CO-RE relocations) are preserved for __weak subprograms that were logically overriden by either previous weak subprogram instance or by corresponding "strong" (non-weak) subprogram. This is just how native user-space linkers work, nothing new. But libbpf is over-zealous when processing CO-RE relocation to error out when CO-RE relocation belonging to such eliminated weak subprogram is encountered. Instead of erroring out on this expected situation, log debug-level message and skip the relocation. Fixes: db2b8b06423c ("libbpf: Support CO-RE relocations for multi-prog sections") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220408181425.2287230-2-andrii@kernel.org Signed-off-by: Sasha Levin commit d47f85cc0171a5d3c5bd8cbb8a98983ca3357cbd Author: Maxime Ripard Date: Mon Mar 28 17:36:56 2022 +0200 drm/vc4: txp: Force alpha to be 0xff if it's disabled [ Upstream commit 5453343a88ede8b12812fced81ecd24cb888ccc3 ] If we use a format that has padding instead of the alpha component (such as XRGB8888), it appears that the Transposer will fill the padding to 0, disregarding what was stored in the input buffer padding. This leads to issues with IGT, since it will set the padding to 0xff, but will then compare the CRC of the two frames which will thus fail. Another nice side effect is that it is now possible to just use the buffer as ARGB. Fixes: 008095e065a8 ("drm/vc4: Add support for the transposer block") Signed-off-by: Maxime Ripard Acked-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20220328153659.2382206-4-maxime@cerno.tech Signed-off-by: Sasha Levin commit 01c9020b2e7c85e394879f34851805179ac3d1d8 Author: Maxime Ripard Date: Mon Mar 28 17:36:55 2022 +0200 drm/vc4: txp: Don't set TXP_VSTART_AT_EOF [ Upstream commit 234998df929f14d00cbf2f1e81a7facb69fd9266 ] The TXP_VSTART_AT_EOF will generate a second VSTART signal to the HVS. However, the HVS waits for VSTART to enable the FIFO and will thus start filling the FIFO before the start of the frame. This leads to corruption at the beginning of the first frame, and content from the previous frame at the beginning of the next frames. Since one VSTART is enough, let's get rid of it. Fixes: 008095e065a8 ("drm/vc4: Add support for the transposer block") Signed-off-by: Maxime Ripard Acked-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20220328153659.2382206-3-maxime@cerno.tech Signed-off-by: Sasha Levin commit 0e26a6da02e63b75b629573d13966c36aa6264f0 Author: Maxime Ripard Date: Mon Mar 28 17:36:54 2022 +0200 drm/vc4: hvs: Reset muxes at probe time [ Upstream commit 8514e6b1f40319e31ac4aa3fbf606796786366c9 ] By default, the HVS driver will force the HVS output 3 to be muxed to the HVS channel 2. However, the Transposer can only be assigned to the HVS channel 2, so whenever we try to use the writeback connector, we'll mux its associated output (Output 2) to the channel 2. This leads to both the output 2 and 3 feeding from the same channel, which is explicitly discouraged in the documentation. In order to avoid this, let's reset all the output muxes to their reset value. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard Acked-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20220328153659.2382206-2-maxime@cerno.tech Signed-off-by: Sasha Levin commit fdb3da70ad0297a5910f35c86fd0ff43eafad4a1 Author: Miles Chen Date: Wed Mar 16 07:23:00 2022 +0800 drm/mediatek: Fix mtk_cec_mask() [ Upstream commit 2c5d69b0a141e1e98febe3111e6f4fd8420493a5 ] In current implementation, mtk_cec_mask() writes val into target register and ignores the mask. After talking to our hdmi experts, mtk_cec_mask() should read a register, clean only mask bits, and update (val | mask) bits to the register. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220315232301.2434-1-miles.chen@mediatek.com/ Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Signed-off-by: Miles Chen Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Cc: Zhiqiang Lin Cc: CK Hu Cc: Matthias Brugger Cc: AngeloGioacchino Del Regno Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 08465a1889cb48ec64431e9db745b5be15399251 Author: Maxime Ripard Date: Thu Mar 31 16:37:39 2022 +0200 drm/vc4: hvs: Fix frame count register readout [ Upstream commit b51cd7ad143d2eb31a6df81c2183128920e47c2b ] In order to get the field currently being output, the driver has been using the display FIFO frame count in the HVS, reading a 6-bit field at the offset 12 in the DISPSTATx register. While that field is indeed at that location for the FIFO 1 and 2, the one for the FIFO0 is actually in the DISPSTAT1 register, at the offset 18. Fixes: e538092cb15c ("drm/vc4: Enable precise vblank timestamping for interlaced modes.") Signed-off-by: Maxime Ripard Acked-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20220331143744.777652-3-maxime@cerno.tech Signed-off-by: Sasha Levin commit 7c7a1f717327cc172b8e69518ea3075a8cdbb081 Author: Ammar Faizi Date: Tue Mar 29 17:47:04 2022 +0700 x86/delay: Fix the wrong asm constraint in delay_loop() [ Upstream commit b86eb74098a92afd789da02699b4b0dd3f73b889 ] The asm constraint does not reflect the fact that the asm statement can modify the value of the local variable loops. Which it does. Specifying the wrong constraint may lead to undefined behavior, it may clobber random stuff (e.g. local variable, important temporary value in regs, etc.). This is especially dangerous when the compiler decides to inline the function and since it doesn't know that the value gets modified, it might decide to use it from a register directly without reloading it. Change the constraint to "+a" to denote that the first argument is an input and an output argument. [ bp: Fix typo, massage commit message. ] Fixes: e01b70ef3eb3 ("x86: fix bug in arch/i386/lib/delay.c file, delay_loop function") Signed-off-by: Ammar Faizi Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220329104705.65256-2-ammarfaizi2@gnuweeb.org Signed-off-by: Sasha Levin commit 61a85a20e8df5e0a92cfe169c92425c7bae0753b Author: Miaoqian Lin Date: Mon Apr 4 09:35:25 2022 +0000 ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe [ Upstream commit 05654431a18fe24e5e46a375d98904134628a102 ] This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. Fixes: 8625c1dbd876 ("ASoC: mediatek: Add mt2701-wm8960 machine driver") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220404093526.30004-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 48889eb3cce91d7f58e02bc07277b7f724b7a54a Author: Miaoqian Lin Date: Mon Apr 4 09:29:01 2022 +0000 ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe [ Upstream commit 4f4e0454e226de3bf4efd7e7924d1edc571c52d5 ] Call of_node_put(platform_node) to avoid refcount leak in the error path. Fixes: 94319ba10eca ("ASoC: mediatek: Use platform_of_node for machine drivers") Fixes: 493433785df0 ("ASoC: mediatek: mt8173: fix device_node leak") Signed-off-by: Miaoqian Lin Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220404092903.26725-1-linmq006@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 56846d96cce0e2a8c878ab582f6918bc83f76b22 Author: Kuldeep Singh Date: Tue Mar 29 00:50:06 2022 +0530 spi: qcom-qspi: Add minItems to interconnect-names [ Upstream commit e23d86c49a9c78e8dbe3abff20b30812b26ab427 ] Add minItems constraint to interconnect-names as well. The schema currently tries to match 2 names and fail for DTs with single entry. With the change applied, below interconnect-names values are possible: ['qspi-config'], ['qspi-config', 'qspi-memory'] Fixes: 8f9c291558ea ("dt-bindings: spi: Add interconnect binding for QSPI") Signed-off-by: Kuldeep Singh Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220328192006.18523-1-singh.kuldeep87k@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d5b66645305c6f3a1b2cf75cee4157b07f293309 Author: Chuanhong Guo Date: Sun Mar 20 17:59:57 2022 +0800 mtd: spinand: gigadevice: fix Quad IO for GD5F1GQ5UExxG [ Upstream commit a4f9dd55c5e1bb951db6f1dee20e62e0103f3438 ] Read From Cache Quad IO (EBH) uses 2 dummy bytes on this chip according to page 23 of the datasheet[0]. [0]: https://www.gigadevice.com/datasheet/gd5f1gq5xexxg/ Fixes: 469b99248985 ("mtd: spinand: gigadevice: Support GD5F1GQ5UExxG") Signed-off-by: Chuanhong Guo Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220320100001.247905-2-gch981213@gmail.com Signed-off-by: Sasha Levin commit adb1ff124a2aec9f6c73b47bdf9b4a29b89bb6eb Author: Marek Vasut Date: Thu Mar 31 17:05:00 2022 +0200 drm: bridge: icn6211: Fix HFP_HSW_HBP_HI and HFP_MIN handling [ Upstream commit c0ff7a649d62105a9308cc3ac36e52a4669d9cb4 ] The HFP_HSW_HBP_HI register must be programmed with 2 LSbits of each Horizontal Front Porch/Sync/Back Porch. Currently the driver programs this register to 0, which breaks displays with either value above 255. The HFP_MIN register must be set to the same value as HFP_LI, otherwise there is visible image distortion, usually in the form of missing lines at the bottom of the panel. Fix this by correctly programming the HFP_HSW_HBP_HI and HFP_MIN registers. Acked-by: Maxime Ripard Fixes: ce517f18944e3 ("drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB bridge") Signed-off-by: Marek Vasut Cc: Jagan Teki Cc: Maxime Ripard Cc: Robert Foss Cc: Sam Ravnborg Cc: Thomas Zimmermann To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220331150509.9838-3-marex@denx.de Signed-off-by: Sasha Levin commit 495f08380e84a8469d0579a4cef0999290398472 Author: Marek Vasut Date: Thu Mar 31 17:04:59 2022 +0200 drm: bridge: icn6211: Fix register layout [ Upstream commit 2dcec57b3734029cc1adc5cb872f61e21609eed4 ] The chip register layout has nothing to do with MIPI DCS, the registers incorrectly marked as MIPI DCS in the driver are regular chip registers often with completely different function. Fill in the actual register names and bits from [1] and [2] and add the entire register layout, since the documentation for this chip is hard to come by. [1] https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/gpu/drm/bridge/icn6211.c [2] https://github.com/tdjastrzebski/ICN6211-Configurator Acked-by: Maxime Ripard Fixes: ce517f18944e3 ("drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB bridge") Signed-off-by: Marek Vasut Cc: Jagan Teki Cc: Maxime Ripard Cc: Robert Foss Cc: Sam Ravnborg Cc: Thomas Zimmermann To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220331150509.9838-2-marex@denx.de Signed-off-by: Sasha Levin commit faeb95b4adaab94468a57f9ef74f25bafcc8a427 Author: Lucas Stach Date: Mon Mar 21 11:47:05 2022 +0100 drm/bridge: adv7511: clean up CEC adapter when probe fails [ Upstream commit 7ed2b0dabf7a22874cb30f8878df239ef638eb53 ] When the probe routine fails we also need to clean up the CEC adapter registered in adv7511_cec_init(). Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support") Signed-off-by: Lucas Stach Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220321104705.2804423-1-l.stach@pengutronix.de Signed-off-by: Sasha Levin commit 96db9afa4958bbaee77995eb0c84e08cdcce74ae Author: Jani Nikula Date: Wed Mar 30 20:04:26 2022 +0300 drm/edid: fix invalid EDID extension block filtering [ Upstream commit 3aefc722ff52076407203b6af9713de567993adf ] The invalid EDID block filtering uses the number of valid EDID extensions instead of all EDID extensions for looping the extensions in the copy. This is fine, by coincidence, if all the invalid blocks are at the end of the EDID. However, it's completely broken if there are invalid extensions in the middle; the invalid blocks are included and valid blocks are excluded. Fix it by modifying the base block after, not before, the copy. Fixes: 14544d0937bf ("drm/edid: Only print the bad edid when aborting") Reported-by: Ville Syrjälä Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220330170426.349248-1-jani.nikula@intel.com Signed-off-by: Sasha Levin commit 996409ee9716f1bfc8973930d1a3370804e5a855 Author: Wenli Looi Date: Sun Mar 20 17:30:08 2022 -0600 ath9k: fix ar9003_get_eepmisc [ Upstream commit 9aaff3864b603408c02c629957ae8d8ff5d5a4f2 ] The current implementation is reading the wrong eeprom type. Fixes: d8ec2e2a63e8 ("ath9k: Add an eeprom_ops callback for retrieving the eepmisc value") Signed-off-by: Wenli Looi Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220320233010.123106-5-wlooi@ucalgary.ca Signed-off-by: Sasha Levin commit b0bc3af3f09d781dc621797ed36e3a8275406649 Author: Nicolas Belin Date: Wed Mar 16 14:57:32 2022 +0100 drm: bridge: it66121: Fix the register page length [ Upstream commit 003a1bd6a2a55c16cb2451153533dbedb12bebec ] Set the register page length or window length to 0x100 according to the documentation. Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") Signed-off-by: Nicolas Belin Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20220316135733.173950-3-nbelin@baylibre.com Signed-off-by: Sasha Levin commit 384b9eeb9f2950a7928f321cd2168073cee8d873 Author: Niels Dossche Date: Mon Mar 21 12:58:23 2022 +0200 ath11k: acquire ab->base_lock in unassign when finding the peer by addr [ Upstream commit 2db80f93869d491be57cbc2b36f30d0d3a0e5bde ] ath11k_peer_find_by_addr states via lockdep that ab->base_lock must be held when calling that function in order to protect the list. All callers except ath11k_mac_op_unassign_vif_chanctx have that lock acquired when calling ath11k_peer_find_by_addr. That lock is also not transitively held by a path towards ath11k_mac_op_unassign_vif_chanctx. The solution is to acquire the lock when calling ath11k_peer_find_by_addr inside ath11k_mac_op_unassign_vif_chanctx. I am currently working on a static analyser to detect missing locks and this was a reported case. I manually verified the report by looking at the code, but I do not have real hardware so this is compile tested only. Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390") Signed-off-by: Niels Dossche Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220314215253.92658-1-dossche.niels@gmail.com Signed-off-by: Sasha Levin commit 2525e264ce5b73d4532e22e199026655063866d8 Author: Zack Rusin Date: Fri Mar 18 13:43:28 2022 -0400 drm/vmwgfx: Fix an invalid read [ Upstream commit 10a26e0d5fc3574f63ce8a6cf28381b126317f40 ] vmw_move assumed that buffers to be moved would always be vmw_buffer_object's but after introduction of new placement for mob pages that's no longer the case. The resulting invalid read didn't have any practical consequences because the memory isn't used unless the object actually is a vmw_buffer_object. Fix it by moving the cast to the spot where the results are used. Signed-off-by: Zack Rusin Fixes: f6be23264bba ("drm/vmwgfx: Introduce a new placement for MOB page tables") Reported-by: Chuck Lever III Reviewed-by: Martin Krastev Tested-by: Chuck Lever Link: https://patchwork.freedesktop.org/patch/msgid/20220318174332.440068-2-zack@kde.org Signed-off-by: Sasha Levin commit 97c8a858346491720e771f64e3575b2cda01d523 Author: Noralf Trønnes Date: Wed Nov 24 16:07:52 2021 +0100 dt-bindings: display: sitronix, st7735r: Fix backlight in example [ Upstream commit 471e201f543559e2cb19b182b680ebf04d80ee31 ] The backlight property was lost during conversion to yaml in commit abdd9e3705c8 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema"). Put it back. Fixes: abdd9e3705c8 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema") Signed-off-by: Noralf Trønnes Acked-by: Rob Herring Reviewed-by: Geert Uytterhoeven Acked-by: David Lechner Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-2-noralf@tronnes.org Signed-off-by: Sasha Levin commit 4399781c49b255ea7a5351459ac55f6b6b1f8614 Author: Nikita Yushchenko Date: Sat Dec 25 09:31:51 2021 +0300 drm/bridge_connector: enable HPD by default if supported [ Upstream commit 09077bc3116581f4d1cb961ec359ad56586e370b ] Hotplug events reported by bridge drivers over drm_bridge_hpd_notify() get ignored unless somebody calls drm_bridge_hpd_enable(). When the connector for the bridge is bridge_connector, such a call is done from drm_bridge_connector_enable_hpd(). However drm_bridge_connector_enable_hpd() is never called on init paths, documentation suggests that it is intended for suspend/resume paths. In result, once encoders are switched to bridge_connector, bridge-detected HPD stops working. This patch adds a call to that API on init path. This fixes HDMI HPD with rcar-du + adv7513 case when adv7513 reports HPD events via interrupts. Fixes: c24110a8fd09 ("drm: rcar-du: Use drm_bridge_connector_init() helper") Signed-off-by: Nikita Yushchenko Signed-off-by: Paul Cercueil Tested-by: Kieran Bingham Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20211225063151.2110878-1-nikita.yoush@cogentembedded.com Signed-off-by: Sasha Levin commit 710051ebb77b785d637417564be7fed4c13c6ce0 Author: Linus Torvalds Date: Sat May 28 11:08:48 2022 -0700 drm: fix EDID struct for old ARM OABI format [ Upstream commit 47f15561b69e226bfc034e94ff6dbec51a4662af ] When building the kernel for arm with the "-mabi=apcs-gnu" option, gcc will force alignment of all structures and unions to a word boundary (see also STRUCTURE_SIZE_BOUNDARY and the "-mstructure-size-boundary=XX" option if you're a gcc person), even when the members of said structures do not want or need said alignment. This completely messes up the structure alignment of 'struct edid' on those targets, because even though all the embedded structures are marked with "__attribute__((packed))", the unions that contain them are not. This was exposed by commit f1e4c916f97f ("drm/edid: add EDID block count and size helpers"), but the bug is pre-existing. That commit just made the structure layout problem cause a build failure due to the addition of the BUILD_BUG_ON(sizeof(*edid) != EDID_LENGTH); sanity check in drivers/gpu/drm/drm_edid.c:edid_block_data(). This legacy union alignment should probably not be used in the first place, but we can fix the layout by adding the packed attribute to the union entries even when each member is already packed and it shouldn't matter in a sane build environment. You can see this issue with a trivial test program: union { struct { char c[5]; }; struct { char d; unsigned e; } __attribute__((packed)); } a = { "1234" }; where building this with a normal "gcc -S" will result in the expected 5-byte size of said union: .type a, @object .size a, 5 but with an ARM compiler and the old ABI: arm-linux-gnu-gcc -mabi=apcs-gnu -mfloat-abi=soft -S t.c you get .type a, %object .size a, 8 instead, because even though each member of the union is packed, the union itself still gets aligned. This was reported by Sudip for the spear3xx_defconfig target. Link: https://lore.kernel.org/lkml/YpCUzStDnSgQLNFN@debian/ Reported-by: Sudip Mukherjee Acked-by: Arnd Bergmann Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 96c460687813915dedca9dd7d04ae0e90607fd79 Author: Lad Prabhakar Date: Wed May 25 14:39:28 2022 -0700 Input: gpio-keys - cancel delayed work only in case of GPIO [ Upstream commit cee409bbba0d1bd3fb73064fb480ff365f453b5d ] gpio_keys module can either accept gpios or interrupts. The module initializes delayed work in case of gpios only and is only used if debounce timer is not used, so make sure cancel_delayed_work_sync() is called only when its gpio-backed and debounce_use_hrtimer is false. This fixes the issue seen below when the gpio_keys module is unloaded and an interrupt pin is used instead of GPIO: [ 360.297569] ------------[ cut here ]------------ [ 360.302303] WARNING: CPU: 0 PID: 237 at kernel/workqueue.c:3066 __flush_work+0x414/0x470 [ 360.310531] Modules linked in: gpio_keys(-) [ 360.314797] CPU: 0 PID: 237 Comm: rmmod Not tainted 5.18.0-rc5-arm64-renesas-00116-g73636105874d-dirty #166 [ 360.324662] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT) [ 360.331270] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 360.338318] pc : __flush_work+0x414/0x470 [ 360.342385] lr : __cancel_work_timer+0x140/0x1b0 [ 360.347065] sp : ffff80000a7fba00 [ 360.350423] x29: ffff80000a7fba00 x28: ffff000012b9c5c0 x27: 0000000000000000 [ 360.357664] x26: ffff80000a7fbb80 x25: ffff80000954d0a8 x24: 0000000000000001 [ 360.364904] x23: ffff800009757000 x22: 0000000000000000 x21: ffff80000919b000 [ 360.372143] x20: ffff00000f5974e0 x19: ffff00000f5974e0 x18: ffff8000097fcf48 [ 360.379382] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000053f40 [ 360.386622] x14: ffff800009850e88 x13: 0000000000000002 x12: 000000000000a60c [ 360.393861] x11: 000000000000a610 x10: 0000000000000000 x9 : 0000000000000008 [ 360.401100] x8 : 0101010101010101 x7 : 00000000a473c394 x6 : 0080808080808080 [ 360.408339] x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff80000919b458 [ 360.415578] x2 : ffff8000097577f0 x1 : 0000000000000001 x0 : 0000000000000000 [ 360.422818] Call trace: [ 360.425299] __flush_work+0x414/0x470 [ 360.429012] __cancel_work_timer+0x140/0x1b0 [ 360.433340] cancel_delayed_work_sync+0x10/0x18 [ 360.437931] gpio_keys_quiesce_key+0x28/0x58 [gpio_keys] [ 360.443327] devm_action_release+0x10/0x18 [ 360.447481] release_nodes+0x8c/0x1a0 [ 360.451194] devres_release_all+0x90/0x100 [ 360.455346] device_unbind_cleanup+0x14/0x60 [ 360.459677] device_release_driver_internal+0xe8/0x168 [ 360.464883] driver_detach+0x4c/0x90 [ 360.468509] bus_remove_driver+0x54/0xb0 [ 360.472485] driver_unregister+0x2c/0x58 [ 360.476462] platform_driver_unregister+0x10/0x18 [ 360.481230] gpio_keys_exit+0x14/0x828 [gpio_keys] [ 360.486088] __arm64_sys_delete_module+0x1e0/0x270 [ 360.490945] invoke_syscall+0x40/0xf8 [ 360.494661] el0_svc_common.constprop.3+0xf0/0x110 [ 360.499515] do_el0_svc+0x20/0x78 [ 360.502877] el0_svc+0x48/0xf8 [ 360.505977] el0t_64_sync_handler+0x88/0xb0 [ 360.510216] el0t_64_sync+0x148/0x14c [ 360.513930] irq event stamp: 4306 [ 360.517288] hardirqs last enabled at (4305): [] __cancel_work_timer+0x130/0x1b0 [ 360.526359] hardirqs last disabled at (4306): [] el1_dbg+0x24/0x88 [ 360.534204] softirqs last enabled at (4278): [] _stext+0x4a0/0x5e0 [ 360.542133] softirqs last disabled at (4267): [] irq_exit_rcu+0x18c/0x1b0 [ 360.550591] ---[ end trace 0000000000000000 ]--- Signed-off-by: Lad Prabhakar Link: https://lore.kernel.org/r/20220524135822.14764-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 32e6aea33944f364d51cd263e4cd236393a188b6 Author: Douglas Miller Date: Fri May 20 14:37:06 2022 -0400 RDMA/hfi1: Prevent panic when SDMA is disabled [ Upstream commit 629e052d0c98e46dde9f0824f0aa437f678d9b8f ] If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL. Link: https://lore.kernel.org/r/20220520183706.48973.79803.stgit@awfm-01.cornelisnetworks.com Signed-off-by: Douglas Miller Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9e5b03ca021430edeed4077c1865a903c4073b26 Author: Steve French Date: Mon May 23 20:42:03 2022 -0500 smb3: check for null tcon [ Upstream commit bbdf6cf56c88845fb0b713cbf5c6623c53fe40d8 ] Although unlikely to be null, it is confusing to use a pointer before checking for it to be null so move the use down after null check. Addresses-Coverity: 1517586 ("Null pointer dereferences (REVERSE_INULL)") Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit df6d8b689252c0acc0448d4ae3d33f2d6db048ab Author: Peng Wu Date: Mon Apr 25 08:12:45 2022 +0000 powerpc/iommu: Add missing of_node_put in iommu_init_early_dart [ Upstream commit 57b742a5b8945118022973e6416b71351df512fb ] The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak. Signed-off-by: Peng Wu Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220425081245.21705-1-wupeng58@huawei.com Signed-off-by: Sasha Levin commit 787255e6190a9bc171dbab642344dfb37b0e5ad8 Author: Finn Thain Date: Thu Apr 7 20:11:32 2022 +1000 macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled [ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ] drivers/macintosh/via-pmu-event.o: In function `via_pmu_event': via-pmu-event.c:(.text+0x44): undefined reference to `input_event' via-pmu-event.c:(.text+0x68): undefined reference to `input_event' via-pmu-event.c:(.text+0x94): undefined reference to `input_event' via-pmu-event.c:(.text+0xb8): undefined reference to `input_event' drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init': via-pmu-event.c:(.init.text+0x20): undefined reference to `input_allocate_device' via-pmu-event.c:(.init.text+0xc4): undefined reference to `input_register_device' via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device' make[1]: *** [Makefile:1155: vmlinux] Error 1 make: *** [Makefile:350: __build_one_by_one] Error 2 Don't call into the input subsystem unless CONFIG_INPUT is built-in. Reported-by: kernel test robot Signed-off-by: Finn Thain Tested-by: Randy Dunlap Reviewed-by: Christophe Leroy Acked-by: Randy Dunlap Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fthain@linux-m68k.org Signed-off-by: Sasha Levin commit a4a6a3826943f58c119c35317e1e5aa6146772b2 Author: Lv Ruyi Date: Thu Apr 7 09:00:43 2022 +0000 powerpc/powernv: fix missing of_node_put in uv_init() [ Upstream commit 3ffa9fd471f57f365bc54fc87824c530422f64a5 ] of_find_compatible_node() returns node pointer with refcount incremented, use of_node_put() on it when done. Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220407090043.2491854-1-lv.ruyi@zte.com.cn Signed-off-by: Sasha Levin commit df802880a7f9cd96b921b00639b00871f18a9a57 Author: Lv Ruyi Date: Sat Apr 2 01:34:19 2022 +0000 powerpc/xics: fix refcount leak in icp_opal_init() [ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ] The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done. Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.ruyi@zte.com.cn Signed-off-by: Sasha Levin commit ce29ea35402dd407ea8fa56e3bee676df9bad3b2 Author: Haren Myneni Date: Sat Apr 9 01:44:16 2022 -0700 powerpc/powernv/vas: Assign real address to rx_fifo in vas_rx_win_attr [ Upstream commit c127d130f6d59fa81701f6b04023cf7cd1972fb3 ] In init_winctx_regs(), __pa() is called on winctx->rx_fifo and this function is called to initialize registers for receive and fault windows. But the real address is passed in winctx->rx_fifo for receive windows and the virtual address for fault windows which causes errors with DEBUG_VIRTUAL enabled. Fixes this issue by assigning only real address to rx_fifo in vas_rx_win_attr struct for both receive and fault windows. Reported-by: Michael Ellerman Signed-off-by: Haren Myneni Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/338e958c7ab8f3b266fa794a1f80f99b9671829e.camel@linux.ibm.com Signed-off-by: Sasha Levin commit 5eed36dc775eceae1cfecd7fbbac93d0fd812df3 Author: Vasily Averin Date: Wed May 11 12:46:53 2022 +0300 tracing: incorrect isolate_mote_t cast in mm_vmscan_lru_isolate [ Upstream commit 2b132903de7124dd9a758be0c27562e91a510848 ] Fixes following sparse warnings: CHECK mm/vmscan.c mm/vmscan.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, include/trace/events/vmscan.h): ./include/trace/events/vmscan.h:281:1: sparse: warning: cast to restricted isolate_mode_t ./include/trace/events/vmscan.h:281:1: sparse: warning: restricted isolate_mode_t degrades to integer Link: https://lkml.kernel.org/r/e85d7ff2-fd10-53f8-c24e-ba0458439c1b@openvz.org Signed-off-by: Vasily Averin Acked-by: Steven Rostedt (Google) Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 72f58a176a021ac7802e816ca4bf82ac1f018896 Author: Matthew Wilcox (Oracle) Date: Thu May 12 20:23:01 2022 -0700 alpha: fix alloc_zeroed_user_highpage_movable() [ Upstream commit f9c668d281aa20e38c9bda3b7b0adeb8891aa15e ] Due to a typo, the final argument to alloc_page_vma() didn't refer to a real variable. This only affected CONFIG_NUMA, which was marked BROKEN in 2006 and removed from alpha in 2021. Found due to a refactoring patch. Link: https://lkml.kernel.org/r/20220504182857.4013401-4-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) Reported-by: kernel test robot Reviewed-by: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 6cd8b30790d08bc40e7dfd80ffbaf6cf4bdd0d97 Author: Nicholas Piggin Date: Thu Mar 3 15:33:15 2022 +1000 KVM: PPC: Book3S HV Nested: L2 LPCR should inherit L1 LPES setting [ Upstream commit 2852ebfa10afdcefff35ec72c8da97141df9845c ] The L1 should not be able to adjust LPES mode for the L2. Setting LPES if the L0 needs it clear would cause external interrupts to be sent to L2 and missed by the L0. Clearing LPES when it may be set, as typically happens with XIVE enabled could cause a performance issue despite having no native XIVE support in the guest, because it will cause mediated interrupts for the L2 to be taken in HV mode, which then have to be injected. Signed-off-by: Nicholas Piggin Reviewed-by: Fabiano Rosas Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220303053315.1056880-7-npiggin@gmail.com Signed-off-by: Sasha Levin commit 2cdd5284035322795b0964f899eefba254cfe483 Author: Yicong Yang Date: Mon Apr 4 14:25:39 2022 +0800 PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() [ Upstream commit a91ee0e9fca9d7501286cfbced9b30a33e52740a ] The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com] Link: https://lore.kernel.org/linux-pci/1583489997-17156-1-git-send-email-yangyicong@hisilicon.com/ Also-posted-by: Jay Zhou Signed-off-by: Yicong Yang Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 5ca40fcf0da0ce2b5bc44e7d8b036535955f2e3d Author: Laurent Dufour Date: Wed May 4 12:12:44 2022 +0200 powerpc/rtas: Keep MSR[RI] set when calling RTAS [ Upstream commit b6b1c3ce06ca438eb24e0f45bf0e63ecad0369f5 ] RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32-bit big endian mode (MSR[SF,LE] unset). The change in MSR is done in enter_rtas() in a relatively complex way, since the MSR value could be hardcoded. Furthermore, a panic has been reported when hitting the watchdog interrupt while running in RTAS, this leads to the following stack trace: watchdog: CPU 24 Hard LOCKUP watchdog: CPU 24 TB:997512652051031, last heartbeat TB:997504470175378 (15980ms ago) ... Supported: No, Unreleased kernel CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000 REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default) MSR: 8000000002981000 CR: 48800002 XER: 20040020 CFAR: 000000000000011c IRQMASK: 1 GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010 GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034 GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008 GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40 GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000 NIP [000000001fb41050] 0x1fb41050 LR [000000001fb4104c] 0x1fb4104c Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Oops: Unrecoverable System Reset, sig: 6 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries ... Supported: No, Unreleased kernel CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000 REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default) MSR: 8000000002981000 CR: 48800002 XER: 20040020 CFAR: 000000000000011c IRQMASK: 1 GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010 GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034 GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008 GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40 GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000 NIP [000000001fb41050] 0x1fb41050 LR [000000001fb4104c] 0x1fb4104c Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 3ddec07f638c34a2 ]--- This happens because MSR[RI] is unset when entering RTAS but there is no valid reason to not set it here. RTAS is expected to be called with MSR[RI] as specified in PAPR+ section "7.2.1 Machine State": R1–7.2.1–9. If called with MSR[RI] equal to 1, then RTAS must protect its own critical regions from recursion by setting the MSR[RI] bit to 0 when in the critical regions. Fixing this by reviewing the way MSR is compute before calling RTAS. Now a hardcoded value meaning real mode, 32 bits big endian mode and Recoverable Interrupt is loaded. In the case MSR[S] is set, it will remain set while entering RTAS as only urfid can unset it (thanks Fabiano). In addition a check is added in do_enter_rtas() to detect calls made with MSR[RI] unset, as we are forcing it on later. This patch has been tested on the following machines: Power KVM Guest P8 S822L (host Ubuntu kernel 5.11.0-49-generic) PowerVM LPAR P8 9119-MME (FW860.A1) p9 9008-22L (FW950.00) P10 9080-HEX (FW1010.00) Suggested-by: Nicholas Piggin Signed-off-by: Laurent Dufour Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220504101244.12107-1-ldufour@linux.ibm.com Signed-off-by: Sasha Levin commit 4668e18bc2993959a8f409ced4adf2fd295e0e81 Author: Viresh Kumar Date: Wed May 4 13:51:35 2022 +0530 cpufreq: Avoid unnecessary frequency updates due to mismatch [ Upstream commit f55ae08c89873e140c7cac2a7fa161d31a0d60cf ] For some platforms, the frequency returned by hardware may be slightly different from what is provided in the frequency table. For example, hardware may return 499 MHz instead of 500 MHz. In such cases it is better to avoid getting into unnecessary frequency updates, as we may end up switching policy->cur between the two and sending unnecessary pre/post update notifications, etc. This patch has chosen allows the hardware frequency and table frequency to deviate by 1 MHz for now, we may want to increase it a bit later on if someone still complains. Reported-by: Rex-BC Chen Signed-off-by: Viresh Kumar Tested-by: Jia-wei Chang Reviewed-by: Matthias Brugger Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a3265a9440030068547a20dfee646666f3ca5278 Author: Peng Wu Date: Thu Apr 28 10:43:06 2022 +0000 ARM: hisi: Add missing of_node_put after of_find_compatible_node [ Upstream commit 9bc72e47d4630d58a840a66a869c56b29554cfe4 ] of_find_compatible_node will increment the refcount of the returned device_node. Calling of_node_put() to avoid the refcount leak Signed-off-by: Peng Wu Signed-off-by: Wei Xu Signed-off-by: Sasha Levin commit 80b06c4afc14fc9f7db38dff3ff2a05ca738a58c Author: Krzysztof Kozlowski Date: Tue Apr 26 20:34:43 2022 +0200 ARM: dts: exynos: add atmel,24c128 fallback to Samsung EEPROM [ Upstream commit f038e8186fbc5723d7d38c6fa1d342945107347e ] The Samsung s524ad0xd1 EEPROM should use atmel,24c128 fallback, according to the AT24 EEPROM bindings. Reported-by: Rob Herring Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220426183443.243113-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit 83c329b980bddbc8c6a3d287d91f2103a4d4a860 Author: Peng Wu Date: Fri Apr 29 01:03:56 2022 +0200 ARM: versatile: Add missing of_node_put in dcscb_init [ Upstream commit 23b44f9c649bbef10b45fa33080cd8b4166800ae ] The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak. Signed-off-by: Peng Wu Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220428230356.69418-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit c16b59d445135c8026a04e388d8b2762feaa3b3b Author: Yang Yingliang Date: Fri Apr 29 16:26:37 2022 +0800 pinctrl: renesas: rzn1: Fix possible null-ptr-deref in sh_pfc_map_resources() [ Upstream commit 2f661477c2bb8068194dbba9738d05219f111c6e ] It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20220429082637.1308182-2-yangyingliang@huawei.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 50c292b469d4b5f7a6f1c8dadab4d78c136738f3 Author: OGAWA Hirofumi Date: Fri Apr 29 14:38:02 2022 -0700 fat: add ratelimit to fat*_ent_bread() [ Upstream commit 183c3237c928109d2008c0456dff508baf692b20 ] fat*_ent_bread() can be the cause of too many report on I/O error path. So use fat_msg_ratelimit() instead. Link: https://lkml.kernel.org/r/87bkxogfeq.fsf@mail.parknet.co.jp Signed-off-by: OGAWA Hirofumi Reported-by: qianfan Tested-by: qianfan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit a0f7180a2c1cd4cc4430d7351c4de09b8616f3f7 Author: Hari Bathini Date: Wed Apr 21 23:20:52 2021 +0530 powerpc/fadump: Fix fadump to work with a different endian capture kernel [ Upstream commit b74196af372f7cb4902179009265fe63ac81824f ] Dump capture would fail if capture kernel is not of the endianess as the production kernel, because the in-memory data structure (struct opal_fadump_mem_struct) shared across production kernel and capture kernel assumes the same endianess for both the kernels, which doesn't have to be true always. Fix it by having a well-defined endianess for struct opal_fadump_mem_struct. Signed-off-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/161902744901.86147.14719228311655123526.stgit@hbathini Signed-off-by: Sasha Levin commit de8f0b173d0751b089827fbacfef1d0b4d197014 Author: Janusz Krzysztofik Date: Sun Apr 10 15:07:54 2022 +0200 ARM: OMAP1: clock: Fix UART rate reporting algorithm [ Upstream commit 338d5d476cde853dfd97378d20496baabc2ce3c0 ] Since its introduction to the mainline kernel, omap1_uart_recalc() helper makes incorrect use of clk->enable_bit as a ready to use bitmap mask while it only provides the bit number. Fix it. Signed-off-by: Janusz Krzysztofik Acked-by: Tony Lindgren Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 035ce4ffe0febed53c88229508cf1b57da6b0551 Author: Takashi Iwai Date: Thu Apr 21 08:41:01 2022 +0200 ALSA: usb-audio: Move generic implicit fb quirk entries into quirks.c [ Upstream commit 67d64069bc0867e52e73a1e255b17462005ca9b4 ] Use the new quirk bits to manage the generic implicit fb quirk entries. This makes easier to compare with other devices. Link: https://lore.kernel.org/r/20220421064101.12456-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 07ddf6fbfea1e6d247933d49443705c72e3e7c78 Author: Takashi Iwai Date: Thu Apr 21 08:41:00 2022 +0200 ALSA: usb-audio: Add quirk bits for enabling/disabling generic implicit fb [ Upstream commit 0f1f7a6661394fe4a53db254c346d6aa2dd64397 ] For making easier to test, add the new quirk_flags bits 17 and 18 to enable and disable the generic implicit feedback mode. The bit 17 is equivalent with implicit_fb=1 option, applying the generic implicit feedback sync mode. OTOH, the bit 18 disables the implicit fb mode forcibly. Link: https://lore.kernel.org/r/20220421064101.12456-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4b9185fbdbfb0c22db0425443a642405ec0c902b Author: Joel Selvaraj Date: Wed Mar 30 12:15:04 2022 +0530 arm64: dts: qcom: sdm845-xiaomi-beryllium: fix typo in panel's vddio-supply property [ Upstream commit 1f1c494082a1f10d03ce4ee1485ee96d212e22ff ] vddio is misspelled with a "0" instead of "o". Fix it. Signed-off-by: Joel Selvaraj Reviewed-by: Caleb Connolly Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/BY5PR02MB7009901651E6A8D5ACB0425ED91F9@BY5PR02MB7009.namprd02.prod.outlook.com Signed-off-by: Sasha Levin commit 4b9380d92c66cdc66987f65130789abad5c1af6f Author: Zixuan Fu Date: Mon Apr 11 18:45:34 2022 +0800 fs: jfs: fix possible NULL pointer dereference in dbFree() [ Upstream commit 0d4837fdb796f99369cf7691d33de1b856bcaf1f ] In our fault-injection testing, the variable "nblocks" in dbFree() can be zero when kmalloc_array() fails in dtSearch(). In this case, the variable "mp" in dbFree() would be NULL and then it is dereferenced in "write_metapage(mp)". The failure log is listed as follows: [ 13.824137] BUG: kernel NULL pointer dereference, address: 0000000000000020 ... [ 13.827416] RIP: 0010:dbFree+0x5f7/0x910 [jfs] [ 13.834341] Call Trace: [ 13.834540] [ 13.834713] txFreeMap+0x7b4/0xb10 [jfs] [ 13.835038] txUpdateMap+0x311/0x650 [jfs] [ 13.835375] jfs_lazycommit+0x5f2/0xc70 [jfs] [ 13.835726] ? sched_dynamic_update+0x1b0/0x1b0 [ 13.836092] kthread+0x3c2/0x4a0 [ 13.836355] ? txLockFree+0x160/0x160 [jfs] [ 13.836763] ? kthread_unuse_mm+0x160/0x160 [ 13.837106] ret_from_fork+0x1f/0x30 [ 13.837402] ... This patch adds a NULL check of "mp" before "write_metapage(mp)" is called. Reported-by: TOTE Robot Signed-off-by: Zixuan Fu Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 7cef9274fa1b8506949d74bc45aef072b890824a Author: QintaoShen Date: Thu Mar 24 15:44:03 2022 +0800 soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc [ Upstream commit ba56291e297d28aa6eb82c5c1964fae2d7594746 ] The allocation funciton devm_kcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devm_kcalloc in previous code. Signed-off-by: QintaoShen Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/1648107843-29077-1-git-send-email-unSimple1993@163.com Signed-off-by: Sasha Levin commit eee44c7268421a9fd5bc33662d8751b4cc316301 Author: Gilad Ben-Yossef Date: Wed Apr 6 11:11:39 2022 +0300 crypto: ccree - use fine grained DMA mapping dir [ Upstream commit a260436c98171cd825955a84a7f6e62bc8f4f00d ] Use a fine grained specification of DMA mapping directions in certain cases, allowing both a more optimized operation as well as shushing out a harmless, though persky dma-debug warning. Signed-off-by: Gilad Ben-Yossef Reported-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cb1be1d4be18fe286ba5a67d928598378fd7fbe5 Author: Brian Norris Date: Tue Mar 8 11:08:59 2022 -0800 PM / devfreq: rk3399_dmc: Disable edev on remove() [ Upstream commit 2fccf9e6050e0e3b8b4cd275d41daf7f7fa22804 ] Otherwise we hit an unablanced enable-count when unbinding the DFI device: [ 1279.659119] ------------[ cut here ]------------ [ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c ... [ 1279.659352] Hardware name: Google Kevin (DT) [ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c [ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28 ... [ 1279.659571] Call trace: [ 1279.659582] devfreq_event_remove_edev+0x84/0x8c [ 1279.659590] devm_devfreq_event_release+0x1c/0x28 [ 1279.659602] release_nodes+0x1cc/0x244 [ 1279.659611] devres_release_all+0x44/0x60 [ 1279.659621] device_release_driver_internal+0x11c/0x1ac [ 1279.659629] device_driver_detach+0x20/0x2c [ 1279.659641] unbind_store+0x7c/0xb0 [ 1279.659650] drv_attr_store+0x2c/0x40 [ 1279.659663] sysfs_kf_write+0x44/0x58 [ 1279.659672] kernfs_fop_write_iter+0xf4/0x190 [ 1279.659684] vfs_write+0x2b0/0x2e4 [ 1279.659693] ksys_write+0x80/0xec [ 1279.659701] __arm64_sys_write+0x24/0x30 [ 1279.659714] el0_svc_common+0xf0/0x1d8 [ 1279.659724] do_el0_svc_compat+0x28/0x3c [ 1279.659738] el0_svc_compat+0x10/0x1c [ 1279.659746] el0_sync_compat_handler+0xa8/0xcc [ 1279.659758] el0_sync_compat+0x188/0x1c0 [ 1279.659768] ---[ end trace cec200e5094155b4 ]--- Signed-off-by: Brian Norris Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 5d44a053594cd2a1c88a2c6e688f15796155e7ca Author: Konrad Dybcio Date: Sat Mar 19 18:46:43 2022 +0100 arm64: dts: qcom: msm8994: Fix BLSP[12]_DMA channels count [ Upstream commit 1ae438d26b620979ed004d559c304d31c42173ae ] MSM8994 actually features 24 DMA channels for each BLSP, fix it! Signed-off-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220319174645.340379-14-konrad.dybcio@somainline.org Signed-off-by: Sasha Levin commit 8337956649ee1ab4d589fd3bf746762e5326452f Author: Konrad Dybcio Date: Sat Mar 19 18:46:38 2022 +0100 arm64: dts: qcom: msm8994: Fix the cont_splash_mem address [ Upstream commit 049c46f31a726bf8d202ff1681661513447fac84 ] The default memory map places cont_splash_mem at 3401000, which was overlooked.. Fix it! Signed-off-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220319174645.340379-9-konrad.dybcio@somainline.org Signed-off-by: Sasha Levin commit fccd667c9c574cea38c3144434ad083ffb95a63e Author: Krzysztof Kozlowski Date: Sun Mar 27 11:08:54 2022 -0700 ARM: dts: s5pv210: align DMA channels with dtschema [ Upstream commit 9e916fb9bc3d16066286f19fc9c51d26a6aec6bd ] dtschema expects DMA channels in specific order (tx, rx and tx-sec). The order actually should not matter because dma-names is used however let's make it aligned with dtschema to suppress warnings like: i2s@eee30000: dma-names: ['rx', 'tx', 'tx-sec'] is not valid under any of the given schemas Signed-off-by: Krzysztof Kozlowski Co-developed-by: Jonathan Bakker Signed-off-by: Jonathan Bakker Link: https://lore.kernel.org/r/CY4PR04MB056779A9C50DC95987C5272ACB1C9@CY4PR04MB0567.namprd04.prod.outlook.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 5712f029726e81d5a48860a7ed55526a527aee4d Author: Krzysztof Kozlowski Date: Thu Apr 7 21:30:22 2022 +0200 ARM: dts: socfpga: align interrupt controller node name with dtschema [ Upstream commit c9bdd50d2019f78bf4c1f6a79254c27771901023 ] Fixes dtbs_check warnings like: $nodename:0: 'intc@fffed000' does not match '^interrupt-controller(@[0-9a-f,]+)*$' Signed-off-by: Krzysztof Kozlowski Acked-by: Dinh Nguyen Link: https://lore.kernel.org/r/20220317115705.450427-2-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit 531156e1712f4e0b3140fbbb6d80c5bd0d50f29e Author: Krzysztof Kozlowski Date: Thu Apr 7 21:29:59 2022 +0200 ARM: dts: ox820: align interrupt controller node name with dtschema [ Upstream commit fbcd5ad7a419ad40644a0bb8b4152bc660172d8a ] Fixes dtbs_check warnings like: gic@1000: $nodename:0: 'gic@1000' does not match '^interrupt-controller(@[0-9a-f,]+)*$' Signed-off-by: Krzysztof Kozlowski Acked-by: Neil Armstrong Link: https://lore.kernel.org/r/20220317115705.450427-1-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit b6c6b398629d1fe266554b5c74986eb1db4b5362 Author: Niels Dossche Date: Mon Feb 28 20:51:44 2022 +0100 IB/rdmavt: add missing locks in rvt_ruc_loopback [ Upstream commit 22cbc6c2681a0a4fe76150270426e763d52353a4 ] The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. rvt_error_qp is called form rvt_send_cq, which is called from rvt_qp_complete_swqe, which is called from rvt_send_complete, which is called from rvt_ruc_loopback in two places. Both of these places do not hold r_lock. Fix this by acquiring a spin_lock of r_lock in both of these places. The r_lock acquiring cannot be added in rvt_qp_complete_swqe because some of its other callers already have r_lock acquired. Link: https://lore.kernel.org/r/20220228195144.71946-1-dossche.niels@gmail.com Signed-off-by: Niels Dossche Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ff876b6cf5785e9604cd407022db917734b5d7ad Author: Bodo Stroesser Date: Tue May 17 21:29:13 2022 +0200 scsi: target: tcmu: Avoid holding XArray lock when calling lock_page [ Upstream commit 325d5c5fb216674296f3902a8902b942da3adc5b ] In tcmu_blocks_release(), lock_page() is called to prevent a race causing possible data corruption. Since lock_page() might sleep, calling it while holding XArray lock is a bug. To fix this, replace the xas_for_each() call with xa_for_each_range(). Since the latter does its own handling of XArray locking, the xas_lock() and xas_unlock() calls around the original loop are no longer necessary. The switch to xa_for_each_range() slows down the loop slightly. This is acceptable since tcmu_blocks_release() is not relevant for performance. Link: https://lore.kernel.org/r/20220517192913.21405-1-bostroesser@gmail.com Fixes: bb9b9eb0ae2e ("scsi: target: tcmu: Fix possible data corruption") Reported-by: Dan Carpenter Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b897da780fd4ffa112ad191b73bf14b01f4479b4 Author: Bob Peterson Date: Fri Feb 11 10:50:08 2022 -0500 gfs2: use i_lock spin_lock for inode qadata [ Upstream commit 5fcff61eea9efd1f4b60e89d2d686b5feaea100f ] Before this patch, functions gfs2_qa_get and _put used the i_rw_mutex to prevent simultaneous access to its i_qadata. But i_rw_mutex is now used for many other things, including iomap_begin and end, which causes a conflict according to lockdep. We cannot just remove the lock since simultaneous opens (gfs2_open -> gfs2_open_common -> gfs2_qa_get) can then stomp on each others values for i_qadata. This patch solves the conflict by using the i_lock spin_lock in the inode to prevent simultaneous access. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit da6b6b4eab55853096134872592764dc88c4261a Author: Yonghong Song Date: Mon May 23 08:20:44 2022 -0700 selftests/bpf: fix btf_dump/btf_dump due to recent clang change [ Upstream commit 4050764cbaa25760aab40857f723393c07898474 ] Latest llvm-project upstream had a change of behavior related to qualifiers on function return type ([1]). This caused selftests btf_dump/btf_dump failure. The following example shows what changed. $ cat t.c typedef const char * const (* const (* const fn_ptr_arr2_t[5])())(char * (*)(int)); struct t { int a; fn_ptr_arr2_t l; }; int foo(struct t *arg) { return arg->a; } Compiled with latest upstream llvm15, $ clang -O2 -g -target bpf -S -emit-llvm t.c The related generated debuginfo IR looks like: !16 = !DIDerivedType(tag: DW_TAG_typedef, name: "fn_ptr_arr2_t", file: !1, line: 1, baseType: !17) !17 = !DICompositeType(tag: DW_TAG_array_type, baseType: !18, size: 320, elements: !32) !18 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !19) !19 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !20, size: 64) !20 = !DISubroutineType(types: !21) !21 = !{!22, null} !22 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !23, size: 64) !23 = !DISubroutineType(types: !24) !24 = !{!25, !28} !25 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !26, size: 64) !26 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !27) !27 = !DIBasicType(name: "char", size: 8, encoding: DW_ATE_signed_char) You can see two intermediate const qualifier to pointer are dropped in debuginfo IR. With llvm14, we have following debuginfo IR: !16 = !DIDerivedType(tag: DW_TAG_typedef, name: "fn_ptr_arr2_t", file: !1, line: 1, baseType: !17) !17 = !DICompositeType(tag: DW_TAG_array_type, baseType: !18, size: 320, elements: !34) !18 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !19) !19 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !20, size: 64) !20 = !DISubroutineType(types: !21) !21 = !{!22, null} !22 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !23) !23 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !24, size: 64) !24 = !DISubroutineType(types: !25) !25 = !{!26, !30} !26 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !27) !27 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !28, size: 64) !28 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !29) !29 = !DIBasicType(name: "char", size: 8, encoding: DW_ATE_signed_char) All const qualifiers are preserved. To adapt the selftest to both old and new llvm, this patch removed the intermediate const qualifier in const-to-ptr types, to make the test succeed again. [1] https://reviews.llvm.org/D125919 Reported-by: Mykola Lysenko Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20220523152044.3905809-1-yhs@fb.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f8bd7f369bb86d4d74d490aaa46c95e410697784 Author: Uwe Kleine-König Date: Tue Apr 26 10:06:02 2022 +0200 char: tpm: cr50_i2c: Suppress duplicated error message in .remove() [ Upstream commit e0687fe958f763f1790f22ed5483025b7624e744 ] Returning an error value in an i2c remove callback results in an error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. As tpm_cr50_i2c_remove() emits an error message already and the additional error message by the i2c core doesn't add any useful information, change the return value to zero to suppress this error message. Note that if i2c_clientdata is NULL, there is something really fishy. Assuming no memory corruption happened (then all bets are lost anyhow), tpm_cr50_i2c_remove() is only called after tpm_cr50_i2c_probe() returned successfully. So there was a tpm chip registered before and after tpm_cr50_i2c_remove() its privdata is freed but the associated character device isn't removed. If after that happened userspace accesses the character device it's likely that the freed memory is accessed. For that reason the warning message is made a bit more frightening. Signed-off-by: Uwe Kleine-König Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 4bcd926d787e3112ef4b2f8a573e9354c6c6dbb9 Author: Jakub Kicinski Date: Fri May 20 12:56:05 2022 -0700 eth: tg3: silence the GCC 12 array-bounds warning [ Upstream commit 9dec850fd7c210a04b4707df8e6c95bfafdd6a4b ] GCC 12 currently generates a rather inconsistent warning: drivers/net/ethernet/broadcom/tg3.c:17795:51: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds] 17795 | struct tg3_napi *tnapi = &tp->napi[i]; | ~~~~~~~~^~~ i is guaranteed < tp->irq_max which in turn is either 1 or 5. There are more loops like this one in the driver, but strangely GCC 12 dislikes only this single one. Silence this silliness for now. Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dd07286924134bff9dcf85e59f02c63b197e5af1 Author: David Howells Date: Sat May 21 08:45:55 2022 +0100 afs: Adjust ACK interpretation to try and cope with NAT [ Upstream commit adc9613ff66c26ebaff9814973181ac178beb90b ] If a client's address changes, say if it is NAT'd, this can disrupt an in progress operation. For most operations, this is not much of a problem, but StoreData can be different as some servers modify the target file as the data comes in, so if a store request is disrupted, the file can get corrupted on the server. The problem is that the server doesn't recognise packets that come after the change of address as belonging to the original client and will bounce them, either by sending an OUT_OF_SEQUENCE ACK to the apparent new call if the packet number falls within the initial sequence number window of a call or by sending an EXCEEDS_WINDOW ACK if it falls outside and then aborting it. In both cases, firstPacket will be 1 and previousPacket will be 0 in the ACK information. Fix this by the following means: (1) If a client call receives an EXCEEDS_WINDOW ACK with firstPacket as 1 and previousPacket as 0, assume this indicates that the server saw the incoming packets from a different peer and thus as a different call. Fail the call with error -ENETRESET. (2) Also fail the call if a similar OUT_OF_SEQUENCE ACK occurs if the first packet has been hard-ACK'd. If it hasn't been hard-ACK'd, the ACK packet will cause it to get retransmitted, so the call will just be repeated. (3) Make afs_select_fileserver() treat -ENETRESET as a straight fail of the operation. (4) Prioritise the error code over things like -ECONNRESET as the server did actually respond. (5) Make writeback treat -ENETRESET as a retryable error and make it redirty all the pages involved in a write so that the VM will retry. Note that there is still a circumstance that I can't easily deal with: if the operation is fully received and processed by the server, but the reply is lost due to address change. There's no way to know if the op happened. We can examine the server, but a conflicting change could have been made by a third party - and we can't tell the difference. In such a case, a message like: kAFS: vnode modified {100058:146266} b7->b8 YFS.StoreData64 (op=2646a) will be logged to dmesg on the next op to touch the file and the client will reset the inode state, including invalidating clean parts of the pagecache. Reported-by: Marc Dionne Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Link: http://lists.infradead.org/pipermail/linux-afs/2021-December/004811.html # v1 Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 65b578726d48ee0941f324bb9a1dd15101cbec84 Author: David Howells Date: Sat May 21 08:45:48 2022 +0100 rxrpc, afs: Fix selection of abort codes [ Upstream commit de696c4784f0706884458893c5a6c39b3a3ff65c ] The RX_USER_ABORT code should really only be used to indicate that the user of the rxrpc service (ie. userspace) implicitly caused a call to be aborted - for instance if the AF_RXRPC socket is closed whilst the call was in progress. (The user may also explicitly abort a call and specify the abort code to use). Change some of the points of generation to use other abort codes instead: (1) Abort the call with RXGEN_SS_UNMARSHAL or RXGEN_CC_UNMARSHAL if we see ENOMEM and EFAULT during received data delivery and abort with RX_CALL_DEAD in the default case. (2) Abort with RXGEN_SS_MARSHAL if we get ENOMEM whilst trying to send a reply. (3) Abort with RX_CALL_DEAD if we stop hearing from the peer if we had heard from the peer and abort with RX_CALL_TIMEOUT if we hadn't. (4) Abort with RX_CALL_DEAD if we try to disconnect a call that's not completed successfully or been aborted. Reported-by: Jeffrey Altman Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a6e80df4f02cacadf17b2cb564cb5bb1adf0b05d Author: David Howells Date: Sat May 21 08:45:41 2022 +0100 rxrpc: Return an error to sendmsg if call failed [ Upstream commit 4ba68c5192554876bd8c3afd904e3064d2915341 ] If at the end of rxrpc sendmsg() or rxrpc_kernel_send_data() the call that was being given data was aborted remotely or otherwise failed, return an error rather than returning the amount of data buffered for transmission. The call (presumably) did not complete, so there's not much point continuing with it. AF_RXRPC considers it "complete" and so will be unwilling to do anything else with it - and won't send a notification for it, deeming the return from sendmsg sufficient. Not returning an error causes afs to incorrectly handle a StoreData operation that gets interrupted by a change of address due to NAT reconfiguration. This doesn't normally affect most operations since their request parameters tend to fit into a single UDP packet and afs_make_call() returns before the server responds; StoreData is different as it involves transmission of a lot of data. This can be triggered on a client by doing something like: dd if=/dev/zero of=/afs/example.com/foo bs=1M count=512 at one prompt, and then changing the network address at another prompt, e.g.: ifconfig enp6s0 inet 192.168.6.2 && route add 192.168.6.1 dev enp6s0 Tracing packets on an Auristor fileserver looks something like: 192.168.6.1 -> 192.168.6.3 RX 107 ACK Idle Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.3 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(64538) (64538) 192.168.6.3 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(64538) (64538) 192.168.6.1 -> 192.168.6.3 RX 107 ACK Idle Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.2 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(0) (0) 192.168.6.2 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(0) (0) 192.168.6.1 -> 192.168.6.2 RX 107 ACK Exceeds Window Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.1 -> 192.168.6.2 RX 74 ABORT Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001 192.168.6.1 -> 192.168.6.2 RX 74 ABORT Seq: 29321 Call: 4 Source Port: 7000 Destination Port: 7001 The Auristor fileserver logs code -453 (RXGEN_SS_UNMARSHAL), but the abort code received by kafs is -5 (RX_PROTOCOL_ERROR) as the rx layer sees the condition and generates an abort first and the unmarshal error is a consequence of that at the application layer. Reported-by: Marc Dionne Signed-off-by: David Howells cc: linux-afs@lists.infradead.org Link: http://lists.infradead.org/pipermail/linux-afs/2021-December/004810.html # v1 Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 16195406211b0eadd5ec6cd10fae4a9d8ea1f987 Author: Geert Uytterhoeven Date: Fri May 20 16:32:30 2022 +0200 m68k: atari: Make Atari ROM port I/O write macros return void [ Upstream commit 30b5e6ef4a32ea4985b99200e06d6660a69f9246 ] The macros implementing Atari ROM port I/O writes do not cast away their output, unlike similar implementations for other I/O buses. When they are combined using conditional expressions in the definitions of outb() and friends, this triggers sparse warnings like: drivers/net/appletalk/cops.c:382:17: error: incompatible types in conditional expression (different base types): drivers/net/appletalk/cops.c:382:17: unsigned char drivers/net/appletalk/cops.c:382:17: void Fix this by adding casts to "void". Reported-by: kernel test robot Reported-by: Guenter Roeck Signed-off-by: Geert Uytterhoeven Reviewed-by: Guenter Roeck Reviewed-by: Michael Schmitz Link: https://lore.kernel.org/r/c15bedc83d90a14fffcd5b1b6bfb32b8a80282c5.1653057096.git.geert@linux-m68k.org Signed-off-by: Sasha Levin commit d295f28cb6ebf3668bfd7750e4209ee6a4717b74 Author: Alex Elder Date: Thu May 19 10:12:13 2022 -0500 net: ipa: ignore endianness if there is no header [ Upstream commit 332ef7c814bdd60f08d0d9013d0e1104798b2d23 ] If we program an RX endpoint to have no header (header length is 0), header-related endpoint configuration values are meaningless and are ignored. The only case we support that defines a header is QMAP endpoints. In ipa_endpoint_init_hdr_ext() we set the endianness mask value unconditionally, but it should not be done if there is no header (meaning it is not configured for QMAP). Set the endianness conditionally, and rearrange the logic in that function slightly to avoid testing the qmap flag twice. Delete an incorrect comment in ipa_endpoint_init_aggr(). Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f516847427c186f4c71a369400379ff1a589ebf Author: Borislav Petkov Date: Thu May 19 16:59:13 2022 +0200 x86/microcode: Add explicit CPU vendor dependency [ Upstream commit 9c55d99e099bd7aa6b91fce8718505c35d5dfc65 ] Add an explicit dependency to the respective CPU vendor so that the respective microcode support for it gets built only when that support is enabled. Reported-by: Randy Dunlap Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/8ead0da9-9545-b10d-e3db-7df1a1f219e4@infradead.org Signed-off-by: Sasha Levin commit 28beef47f18bc371022461c24b20efc68be4c992 Author: Vincent Mailhol Date: Wed May 18 20:43:57 2022 +0900 can: mcp251xfd: silence clang's -Wunaligned-access warning [ Upstream commit 1a6dd9996699889313327be03981716a8337656b ] clang emits a -Wunaligned-access warning on union mcp251xfd_tx_ojb_load_buf. The reason is that field hw_tx_obj (not declared as packed) is being packed right after a 16 bits field inside a packed struct: | union mcp251xfd_tx_obj_load_buf { | struct __packed { | struct mcp251xfd_buf_cmd cmd; | /* ^ 16 bits fields */ | struct mcp251xfd_hw_tx_obj_raw hw_tx_obj; | /* ^ not declared as packed */ | } nocrc; | struct __packed { | struct mcp251xfd_buf_cmd_crc cmd; | struct mcp251xfd_hw_tx_obj_raw hw_tx_obj; | __be16 crc; | } crc; | } ____cacheline_aligned; Starting from LLVM 14, having an unpacked struct nested in a packed struct triggers a warning. c.f. [1]. This is a false positive because the field is always being accessed with the relevant put_unaligned_*() function. Adding __packed to the structure declaration silences the warning. [1] https://github.com/llvm/llvm-project/issues/55520 Link: https://lore.kernel.org/all/20220518114357.55452-1-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Reported-by: kernel test robot Tested-by: Nathan Chancellor # build Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 980b79d0be5616b67880582eef620c226c709169 Author: Chaitanya Kulkarni Date: Wed May 18 08:51:38 2022 -0700 nvme: set non-mdts limits in nvme_scan_work [ Upstream commit 78288665b5d0154978fed431985310cb4f166836 ] In current implementation we set the non-mdts limits by calling nvme_init_non_mdts_limits() from nvme_init_ctrl_finish(). This also tries to set the limits for the discovery controller which has no I/O queues resulting in the warning message reported by the nvme_log_error() when running blktest nvme/002: - [ 2005.155946] run blktests nvme/002 at 2022-04-09 16:57:47 [ 2005.192223] loop: module loaded [ 2005.196429] nvmet: adding nsid 1 to subsystem blktests-subsystem-0 [ 2005.200334] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 <------------------------------SNIP----------------------------------> [ 2008.958108] nvmet: adding nsid 1 to subsystem blktests-subsystem-997 [ 2008.962082] nvmet: adding nsid 1 to subsystem blktests-subsystem-998 [ 2008.966102] nvmet: adding nsid 1 to subsystem blktests-subsystem-999 [ 2008.973132] nvmet: creating discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN testhostnqn. *[ 2008.973196] nvme1: Identify(0x6), Invalid Field in Command (sct 0x0 / sc 0x2) MORE DNR* [ 2008.974595] nvme nvme1: new ctrl: "nqn.2014-08.org.nvmexpress.discovery" [ 2009.103248] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" Move the call of nvme_init_non_mdts_limits() to nvme_scan_work() after we verify that I/O queues are created since that is a converging point for each transport where these limits are actually used. 1. FC : nvme_fc_create_association() ... nvme_fc_create_io_queues(ctrl); ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 2. PCIe:- nvme_reset_work() ... nvme_setup_io_queues() nvme_create_io_queues() nvme_alloc_queue() ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 3. RDMA :- nvme_rdma_setup_ctrl ... nvme_rdma_configure_io_queues ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 4. TCP :- nvme_tcp_setup_ctrl ... nvme_tcp_configure_io_queues ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() * nvme_scan_work() ... nvme_validate_or_alloc_ns() nvme_alloc_ns() nvme_update_ns_info() nvme_update_disk_info() nvme_config_discard() <--- blk_queue_max_write_zeroes_sectors() <--- Signed-off-by: Chaitanya Kulkarni Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d9c96e05574f22074f0c8ec108372a8dfecbd3fe Author: Pierre Gondois Date: Wed May 18 11:08:59 2022 +0200 ACPI: CPPC: Assume no transition latency if no PCCT [ Upstream commit 6380b7b2b29da9d9c5ab2d4a265901cd93ba3696 ] The transition_delay_us (struct cpufreq_policy) is currently defined as: Preferred average time interval between consecutive invocations of the driver to set the frequency for this policy. To be set by the scaling driver (0, which is the default, means no preference). The transition_latency represents the amount of time necessary for a CPU to change its frequency. A PCCT table advertises mutliple values: - pcc_nominal: Expected latency to process a command, in microseconds - pcc_mpar: The maximum number of periodic requests that the subspace channel can support, reported in commands per minute. 0 indicates no limitation. - pcc_mrtt: The minimum amount of time that OSPM must wait after the completion of a command before issuing the next command, in microseconds. cppc_get_transition_latency() allows to get the max of them. commit d4f3388afd48 ("cpufreq / CPPC: Set platform specific transition_delay_us") allows to select transition_delay_us based on the platform, and fallbacks to cppc_get_transition_latency() otherwise. If _CPC objects are not using PCC channels (no PPCT table), the transition_delay_us is set to CPUFREQ_ETERNAL, leading to really long periods between frequency updates (~4s). If the desired_reg, where performance requests are written, is in SystemMemory or SystemIo ACPI address space, there is no delay in requests. So return 0 instead of CPUFREQ_ETERNAL, leading to transition_delay_us being set to LATENCY_MULTIPLIER us (1000 us). This patch also adds two macros to check the address spaces. Signed-off-by: Pierre Gondois Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 649689f49ad95d19b121c21e74eaa1fabb140c24 Author: Pierre-Louis Bossart Date: Tue May 17 12:26:47 2022 -0500 ASoC: rt1015p: remove dependency on GPIOLIB [ Upstream commit b390c25c6757b9d56cecdfbf6d55f15fc89a6386 ] commit dcc2c012c7691 ("ASoC: Fix gpiolib dependencies") removed a series of unnecessary dependencies on GPIOLIB when the gpio was optional. A similar simplification seems valid for rt1015p, so remove the dependency as well. This will avoid the following warning WARNING: unmet direct dependencies detected for SND_SOC_RT1015P Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n] Selected by [y]: - SND_SOC_INTEL_SOF_RT5682_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_INTEL_MACH [=y] && (SND_SOC_SOF_HDA_LINK [=y] || SND_SOC_SOF_BAYTRAIL [=n]) && I2C [=y] && ACPI [=y] && (SND_HDA_CODEC_HDMI [=y] && SND_SOC_SOF_HDA_AUDIO_CODEC [=y] && (MFD_INTEL_LPSS [=y] || COMPILE_TEST [=y]) || SND_SOC_SOF_BAYTRAIL [=n] && (X86_INTEL_LPSS [=n] || COMPILE_TEST [=y])) Reported-by: kernel test robot Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20220517172647.468244-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f8ceb9745ba71bac088b459b4689d77515cc2800 Author: Pierre-Louis Bossart Date: Tue May 17 12:26:46 2022 -0500 ASoC: max98357a: remove dependency on GPIOLIB [ Upstream commit 21ca3274333f5c1cbbf9d91e5b33f4f2463859b2 ] commit dcc2c012c7691 ("ASoC: Fix gpiolib dependencies") removed a series of unnecessary dependencies on GPIOLIB when the gpio was optional. A similar simplification seems valid for max98357a, so remove the dependency as well. This will avoid the following warning WARNING: unmet direct dependencies detected for SND_SOC_MAX98357A Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n] Selected by [y]: - SND_SOC_INTEL_SOF_CS42L42_MACH [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_INTEL_MACH [=y] && (SND_SOC_SOF_HDA_LINK [=y] || SND_SOC_SOF_BAYTRAIL [=n]) && I2C [=y] && ACPI [=y] && SND_HDA_CODEC_HDMI [=y] && SND_SOC_SOF_HDA_AUDIO_CODEC [=y] && (MFD_INTEL_LPSS [=y] || COMPILE_TEST [=n]) Reported-by: kernel test robot Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20220517172647.468244-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bdd5770169438fca5575adf7945fb7d0b362610c Author: Nicolas Dufresne Date: Fri May 13 22:29:19 2022 +0200 media: hantro: Stop using H.264 parameter pic_num [ Upstream commit 831410700909f4e29d5af1ef26b8c59fc2d1988e ] The hardware expects FrameNumWrap or long_term_frame_idx. Picture numbers are per field, and are mostly used during the memory management process, which is done in userland. This fixes two ITU conformance tests: - MR6_BT_B - MR8_BT_B Signed-off-by: Nicolas Dufresne Reviewed-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 16cae5d8580263c71a12b837247ce676baf7014f Author: Kwanghoon Son Date: Wed Apr 27 03:16:45 2022 +0200 media: exynos4-is: Fix compile warning [ Upstream commit e080f5c1f2b6d02c02ee5d674e0e392ccf63bbaf ] Declare static on function 'fimc_isp_video_device_unregister'. When VIDEO_EXYNOS4_ISP_DMA_CAPTURE=n, compiler warns about warning: no previous prototype for function [-Wmissing-prototypes] Reported-by: kernel test robot Signed-off-by: Kwanghoon Son Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 660dfa033ccc9afb032015b6dc76e846bba42cfb Author: Fabio Estevam Date: Fri May 13 08:46:12 2022 -0300 net: phy: micrel: Allow probing without .driver_data [ Upstream commit f2ef6f7539c68c6bd6c32323d8845ee102b7c450 ] Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type. Signed-off-by: Fabio Estevam Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220513114613.762810-1-festevam@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5005002b2e12e9ac4b58e59354d38a4106906f87 Author: Sathishkumar S Date: Wed May 11 16:35:59 2022 +0530 drm/amd/pm: update smartshift powerboost calc for smu13 [ Upstream commit cdf4c8ec39872a61a58d62f19b4db80f0f7bc586 ] smartshift apu and dgpu power boost are reported as percentage with respect to their power limits. adjust the units of power before calculating the percentage of boost. Signed-off-by: Sathishkumar S Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c525d3385f6d34d6dcce89ebe019314d83f23873 Author: Sathishkumar S Date: Wed May 11 16:06:12 2022 +0530 drm/amd/pm: update smartshift powerboost calc for smu12 [ Upstream commit 138292f1dc00e7e0724f44769f9da39cf2f3bf0b ] smartshift apu and dgpu power boost are reported as percentage with respect to their power limits. This value[0-100] reflects the boost for the respective device. Signed-off-by: Sathishkumar S Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c2673b86b4195260ba41de97fc9c10d17250ff8e Author: Xie Yongji Date: Tue Mar 22 16:06:39 2022 +0800 nbd: Fix hung on disconnect request if socket is closed before [ Upstream commit 491bf8f236fdeec698fa6744993f1ecf3fafd1a5 ] When userspace closes the socket before sending a disconnect request, the following I/O requests will be blocked in wait_for_reconnect() until dead timeout. This will cause the following disconnect request also hung on blk_mq_quiesce_queue(). That means we have no way to disconnect a nbd device if there are some I/O requests waiting for reconnecting until dead timeout. It's not expected. So let's wake up the thread waiting for reconnecting directly when a disconnect request is sent. Reported-by: Xu Jianhai Signed-off-by: Xie Yongji Reviewed-by: Josef Bacik Link: https://lore.kernel.org/r/20220322080639.142-1-xieyongji@bytedance.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 061a6159cea583f1155f67d1915917a6b9282662 Author: Lin Ma Date: Mon May 16 17:20:35 2022 +0800 ASoC: rt5645: Fix errorenous cleanup order [ Upstream commit 2def44d3aec59e38d2701c568d65540783f90f2f ] There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync. Signed-off-by: Lin Ma Link: https://lore.kernel.org/r/20220516092035.28283-1-linma@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 906c81dba8ee8057523859b5e1a2479e9fd34860 Author: Smith, Kyle Miller (Nimble Kernel) Date: Fri Apr 22 14:40:32 2022 +0000 nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags [ Upstream commit da42761181627e9bdc37d18368b827948a583929 ] In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference. Signed-off-by: Kyle Smith Reviewed-by: Chaitanya Kulkarni Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 48d32e41bbfe3cfa5a9811e3a1959e628e196391 Author: Jason A. Donenfeld Date: Sat Apr 23 21:11:41 2022 +0200 openrisc: start CPU timer early in boot [ Upstream commit 516dd4aacd67a0f27da94f3fe63fe0f4dbab6e2b ] In order to measure the boot process, the timer should be switched on as early in boot as possible. As well, the commit defines the get_cycles macro, like the previous patches in this series, so that generic code is aware that it's implemented by the platform, as is done on other archs. Cc: Thomas Gleixner Cc: Arnd Bergmann Cc: Jonas Bonn Cc: Stefan Kristiansson Acked-by: Stafford Horne Reported-by: Guenter Roeck Signed-off-by: Jason A. Donenfeld Signed-off-by: Sasha Levin commit 6d5deb242874d924beccf7eb3cef04c1c3b0da79 Author: Lukas Wunner Date: Thu May 12 10:42:01 2022 +0200 usbnet: Run unregister_netdev() before unbind() again [ Upstream commit d1408f6b4dd78fb1b9e26bcf64477984e5f85409 ] Commit 2c9d6c2b871d ("usbnet: run unbind() before unregister_netdev()") sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue: https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). Tested-by: Oleksij Rempel # LAN9514/9512/9500 Tested-by: Ferry Toth # LAN9514 Signed-off-by: Lukas Wunner Acked-by: Oliver Neukum Cc: Martyn Welch Cc: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 35121d0bb7adde61c54a62408b5612b034e44af3 Author: Hans Verkuil Date: Fri May 6 09:43:25 2022 +0200 media: cec-adap.c: fix is_configuring state [ Upstream commit 59267fc34f4900dcd2ec3295f6be04b79aee2186 ] If an adapter is trying to claim a free logical address then it is in the 'is_configuring' state. If during that process the cable is disconnected (HPD goes low, which in turn invalidates the physical address), then cec_adap_unconfigure() is called, and that set the is_configuring boolean to false, even though the thread that's trying to claim an LA is still running. Don't touch the is_configuring bool in cec_adap_unconfigure(), it will eventually be cleared by the thread. By making that change the cec_config_log_addr() function also had to change: it was aborting if is_configuring became false (since that is what cec_adap_unconfigure() did), but that no longer works. Instead check if the physical address is invalid. That is a much more appropriate check anyway. This fixes a bug where the the adapter could be disabled even though the device was still configuring. This could cause POLL transmits to time out. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 32c7b04d535a6e5c5174b89b12c6ae230ba8f961 Author: Tetsuo Handa Date: Mon May 2 05:49:04 2022 +0200 media: imon: reorganize serialization [ Upstream commit db264d4c66c0fe007b5d19fd007707cd0697603d ] Since usb_register_dev() from imon_init_display() from imon_probe() holds minor_rwsem while display_open() which holds driver_lock and ictx->lock is called with minor_rwsem held from usb_open(), holding driver_lock or ictx->lock when calling usb_register_dev() causes circular locking dependency problem. Since usb_deregister_dev() from imon_disconnect() holds minor_rwsem while display_open() which holds driver_lock is called with minor_rwsem held, holding driver_lock when calling usb_deregister_dev() also causes circular locking dependency problem. Sean Young explained that the problem is there are imon devices which have two usb interfaces, even though it is one device. The probe and disconnect function of both usb interfaces can run concurrently. Alan Stern responded that the driver and USB cores guarantee that when an interface is probed, both the interface and its USB device are locked. Ditto for when the disconnect callback gets run. So concurrent probing/ disconnection of multiple interfaces on the same device is not possible. Therefore, we don't need locks for handling race between imon_probe() and imon_disconnect(). But we still need to handle race between display_open() /vfd_write()/lcd_write()/display_close() and imon_disconnect(), for disconnect event can happen while file descriptors are in use. Since "struct file"->private_data is set by display_open(), vfd_write()/ lcd_write()/display_close() can assume that "struct file"->private_data is not NULL even after usb_set_intfdata(interface, NULL) was called. Replace insufficiently held driver_lock with refcount_t based management. Add a boolean flag for recording whether imon_disconnect() was already called. Use RCU for accessing this boolean flag and refcount_t. Since the boolean flag for imon_disconnect() is shared, disconnect event on either intf0 or intf1 affects both interfaces. But I assume that this change does not matter, for usually disconnect event would not happen while interfaces are in use. Link: https://syzkaller.appspot.com/bug?extid=c558267ad910fc494497 Reported-by: syzbot Signed-off-by: Tetsuo Handa Tested-by: syzbot Cc: Alan Stern Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 271bea32acc48649131bd3fe5c965d2a8ec46b4b Author: Hans Verkuil Date: Mon May 2 09:17:46 2022 +0200 media: ccs-core.c: fix failure to call clk_disable_unprepare [ Upstream commit eca89cf60b040ee2cae693ea72a0364284f3084c ] Fixes smatch warning: drivers/media/i2c/ccs/ccs-core.c:1676 ccs_power_on() warn: 'sensor->ext_clk' from clk_prepare_enable() not released on lines: 1606. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c16cfcac77ecc3077c516ae512b79031c76945af Author: Benjamin Gaignard Date: Tue May 3 17:19:20 2022 +0200 media: hantro: HEVC: unconditionnaly set pps_{cb/cr}_qp_offset values [ Upstream commit 46c836569196f377f87a3657b330cffaf94bd727 ] Always set pps_cb_qp_offset and pps_cr_qp_offset values in Hantro/G2 register whatever is V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT flag value. The vendor code does the same to set these values. This fixes conformance test CAINIT_G_SHARP_3. Fluster HEVC score is increase by one with this patch. Signed-off-by: Benjamin Gaignard Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a1f2cb0a26133f2c013a42aa8d1b1b2ce691631d Author: Philipp Zabel Date: Tue Apr 26 11:15:55 2022 +0200 media: coda: limit frame interval enumeration to supported encoder frame sizes [ Upstream commit 67e33dd957880879e785cfea83a3aa24bd5c5577 ] Let VIDIOC_ENUM_FRAMEINTERVALS return -EINVAL if userspace queries frame intervals for frame sizes unsupported by the encoder. Fixes the following v4l2-compliance failure: fail: v4l2-test-formats.cpp(123): found frame intervals for invalid size 47x16 fail: v4l2-test-formats.cpp(282): node->codec_mask & STATEFUL_ENCODER test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL [hverkuil: drop incorrect 'For decoder devices, return -ENOTTY.' in the commit log] Signed-off-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit eeb4819e94aa69767b9e5591e70c63e8b7c5786a Author: Hangyu Hua Date: Thu Mar 24 09:37:24 2022 +0100 media: rga: fix possible memory leak in rga_probe [ Upstream commit a71eb6025305192e646040cd76ccacb5bd48a1b5 ] rga->m2m_dev needs to be freed when rga_probe fails. Signed-off-by: Hangyu Hua Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4b6807b1cfb8677d8805a3fa9ee51d7d52d9eceb Author: Felix Fietkau Date: Wed Apr 20 14:29:00 2022 +0200 mt76: fix encap offload ethernet type check [ Upstream commit bc98e7fdd80d215b4b55eea001023231eb8ce12e ] The driver needs to check if the format is 802.2 vs 802.3 in order to set a tx descriptor flag. skb->protocol can't be used, since it may not be properly initialized for packets coming in from a packet socket. Fix misdetection by checking the ethertype from the skb data instead Reported-by: Thibaut VARÈNE Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit bf5572fb3fc42a72c4f9f71e67a11a5fd5ac00f8 Author: Felix Fietkau Date: Fri Mar 25 21:15:15 2022 +0100 mt76: mt7921: accept rx frames with non-standard VHT MCS10-11 [ Upstream commit 3128ea016965ce9f91ddf4e1dd944724462d1698 ] The hardware receives them properly, they should not be dropped Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 03755410a8f668072502c0fdc58760e15ee6358a Author: Dongliang Mu Date: Wed May 11 09:44:52 2022 +0800 rtlwifi: Use pr_warn instead of WARN_ONCE [ Upstream commit ad732da434a2936128769216eddaece3b1af4588 ] This memory allocation failure can be triggered by fault injection or high pressure testing, resulting a WARN. Fix this by replacing WARN with pr_warn. Reported-by: syzkaller Signed-off-by: Dongliang Mu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220511014453.1621366-1-dzm91@hust.edu.cn Signed-off-by: Sasha Levin commit 25929a5a69cf3e58e3e5205e3b95f10acdac8d9f Author: Corey Minyard Date: Fri Apr 15 07:23:32 2022 -0500 ipmi: Fix pr_fmt to avoid compilation issues [ Upstream commit 2ebaf18a0b7fb764bba6c806af99fe868cee93de ] The was it was wouldn't work in some situations, simplify it. What was there was unnecessary complexity. Reported-by: kernel test robot Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 98a0c0dea51d61ab880c6191bd354f65287b3d58 Author: Corey Minyard Date: Fri Apr 1 07:44:53 2022 -0500 ipmi:ssif: Check for NULL msg when handling events and messages [ Upstream commit 7602b957e2404e5f98d9a40b68f1fd27f0028712 ] Even though it's not possible to get into the SSIF_GETTING_MESSAGES and SSIF_GETTING_EVENTS states without a valid message in the msg field, it's probably best to be defensive here and check and print a log, since that means something else went wrong. Also add a default clause to that switch statement to release the lock and print a log, in case the state variable gets messed up somehow. Reported-by: Haowen Bai Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 717c6f4570a6715bc19e8975cad1a90a1e46f4a5 Author: Mario Limonciello Date: Tue May 10 08:11:36 2022 -0500 ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default [ Upstream commit d52848620de00cde4a3a5df908e231b8c8868250 ] ASUS B1400CEAE fails to resume from suspend to idle by default. This was bisected back to commit df4f9bc4fb9c ("nvme-pci: add support for ACPI StorageD3Enable property") but this is a red herring to the problem. Before this commit the system wasn't getting into deepest sleep state. Presumably this commit is allowing entry into deepest sleep state as advertised by firmware, but there are some other problems related to the wakeup. As it is confirmed the system works properly with S3, set the default for this system to S3. Reported-by: Jian-Hong Pan Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742 Signed-off-by: Mario Limonciello Tested-by: Jian-Hong Pan Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e202dad51908c942b307374cfc967800993afc78 Author: Mikulas Patocka Date: Tue May 10 13:17:32 2022 -0400 dma-debug: change allocation mode from GFP_NOWAIT to GFP_ATIOMIC [ Upstream commit 84bc4f1dbbbb5f8aa68706a96711dccb28b518e5 ] We observed the error "cacheline tracking ENOMEM, dma-debug disabled" during a light system load (copying some files). The reason for this error is that the dma_active_cacheline radix tree uses GFP_NOWAIT allocation - so it can't access the emergency memory reserves and it fails as soon as anybody reaches the watermark. This patch changes GFP_NOWAIT to GFP_ATOMIC, so that it can access the emergency memory reserves. Signed-off-by: Mikulas Patocka Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit bab45966325003e92b8ebbc3a9cada1c7141df93 Author: Patrice Chotard Date: Wed May 11 09:46:42 2022 +0200 spi: stm32-qspi: Fix wait_cmd timeout in APM mode [ Upstream commit d83d89ea68b4726700fa87b22db075e4217e691c ] In APM mode, TCF and TEF flags are not set. To avoid timeout in stm32_qspi_wait_cmd(), don't check if TCF/TEF are set. Signed-off-by: Patrice Chotard Reported-by: eberhard.stoll@kontron.de Link: https://lore.kernel.org/r/20220511074644.558874-2-patrice.chotard@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit aeca695a19f8a7a43633b6bb86c82e1dddf2ee02 Author: Hao Jia Date: Sat Apr 30 16:58:42 2022 +0800 sched/core: Avoid obvious double update_rq_clock warning [ Upstream commit 2679a83731d51a744657f718fc02c3b077e47562 ] When we use raw_spin_rq_lock() to acquire the rq lock and have to update the rq clock while holding the lock, the kernel may issue a WARN_DOUBLE_CLOCK warning. Since we directly use raw_spin_rq_lock() to acquire rq lock instead of rq_lock(), there is no corresponding change to rq->clock_update_flags. In particular, we have obtained the rq lock of other CPUs, the rq->clock_update_flags of this CPU may be RQCF_UPDATED at this time, and then calling update_rq_clock() will trigger the WARN_DOUBLE_CLOCK warning. So we need to clear RQCF_UPDATED of rq->clock_update_flags to avoid the WARN_DOUBLE_CLOCK warning. For the sched_rt_period_timer() and migrate_task_rq_dl() cases we simply replace raw_spin_rq_lock()/raw_spin_rq_unlock() with rq_lock()/rq_unlock(). For the {pull,push}_{rt,dl}_task() cases, we add the double_rq_clock_clear_update() function to clear RQCF_UPDATED of rq->clock_update_flags, and call double_rq_clock_clear_update() before double_lock_balance()/double_rq_lock() returns to avoid the WARN_DOUBLE_CLOCK warning. Some call trace reports: Call Trace 1: sched_rt_period_timer+0x10f/0x3a0 ? enqueue_top_rt_rq+0x110/0x110 __hrtimer_run_queues+0x1a9/0x490 hrtimer_interrupt+0x10b/0x240 __sysvec_apic_timer_interrupt+0x8a/0x250 sysvec_apic_timer_interrupt+0x9a/0xd0 asm_sysvec_apic_timer_interrupt+0x12/0x20 Call Trace 2: activate_task+0x8b/0x110 push_rt_task.part.108+0x241/0x2c0 push_rt_tasks+0x15/0x30 finish_task_switch+0xaa/0x2e0 ? __switch_to+0x134/0x420 __schedule+0x343/0x8e0 ? hrtimer_start_range_ns+0x101/0x340 schedule+0x4e/0xb0 do_nanosleep+0x8e/0x160 hrtimer_nanosleep+0x89/0x120 ? hrtimer_init_sleeper+0x90/0x90 __x64_sys_nanosleep+0x96/0xd0 do_syscall_64+0x34/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Call Trace 3: deactivate_task+0x93/0xe0 pull_rt_task+0x33e/0x400 balance_rt+0x7e/0x90 __schedule+0x62f/0x8e0 do_task_dead+0x3f/0x50 do_exit+0x7b8/0xbb0 do_group_exit+0x2d/0x90 get_signal+0x9df/0x9e0 ? preempt_count_add+0x56/0xa0 ? __remove_hrtimer+0x35/0x70 arch_do_signal_or_restart+0x36/0x720 ? nanosleep_copyout+0x39/0x50 ? do_nanosleep+0x131/0x160 ? audit_filter_inodes+0xf5/0x120 exit_to_user_mode_prepare+0x10f/0x1e0 syscall_exit_to_user_mode+0x17/0x30 do_syscall_64+0x40/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Call Trace 4: update_rq_clock+0x128/0x1a0 migrate_task_rq_dl+0xec/0x310 set_task_cpu+0x84/0x1e4 try_to_wake_up+0x1d8/0x5c0 wake_up_process+0x1c/0x30 hrtimer_wakeup+0x24/0x3c __hrtimer_run_queues+0x114/0x270 hrtimer_interrupt+0xe8/0x244 arch_timer_handler_phys+0x30/0x50 handle_percpu_devid_irq+0x88/0x140 generic_handle_domain_irq+0x40/0x60 gic_handle_irq+0x48/0xe0 call_on_irq_stack+0x2c/0x60 do_interrupt_handler+0x80/0x84 Steps to reproduce: 1. Enable CONFIG_SCHED_DEBUG when compiling the kernel 2. echo 1 > /sys/kernel/debug/clear_warn_once echo "WARN_DOUBLE_CLOCK" > /sys/kernel/debug/sched/features echo "NO_RT_PUSH_IPI" > /sys/kernel/debug/sched/features 3. Run some rt/dl tasks that periodically work and sleep, e.g. Create 2*n rt or dl (90% running) tasks via rt-app (on a system with n CPUs), and Dietmar Eggemann reports Call Trace 4 when running on PREEMPT_RT kernel. Signed-off-by: Hao Jia Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Link: https://lore.kernel.org/r/20220430085843.62939-2-jiahao.os@bytedance.com Signed-off-by: Sasha Levin commit cab410da48c257980f9abb9deac757c201f9cba5 Author: Ravi Bangoria Date: Mon May 9 10:19:07 2022 +0530 perf/amd/ibs: Cascade pmu init functions' return value [ Upstream commit 39b2ca75eec8a33e2ffdb8aa0c4840ec3e3b472c ] IBS pmu initialization code ignores return value provided by callee functions. Fix it. Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220509044914.1473-2-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit 69b296597656dff40d6337af1beb0322f21f841d Author: Heiko Carstens Date: Fri May 6 11:33:19 2022 +0200 s390/preempt: disable __preempt_count_add() optimization for PROFILE_ALL_BRANCHES [ Upstream commit 63678eecec57fc51b778be3da35a397931287170 ] gcc 12 does not (always) optimize away code that should only be generated if parameters are constant and within in a certain range. This depends on various obscure kernel config options, however in particular PROFILE_ALL_BRANCHES can trigger this compile error: In function ‘__atomic_add_const’, inlined from ‘__preempt_count_add.part.0’ at ./arch/s390/include/asm/preempt.h:50:3: ./arch/s390/include/asm/atomic_ops.h:80:9: error: impossible constraint in ‘asm’ 80 | asm volatile( \ | ^~~ Workaround this by simply disabling the optimization for PROFILE_ALL_BRANCHES, since the kernel will be so slow, that this optimization won't matter at all. Reported-by: Thomas Richter Reviewed-by: Sven Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 6320ae1b5876c30bf98203b6a5abe8b5c45e6a04 Author: Eric Dumazet Date: Mon May 9 20:57:40 2022 -0700 net: remove two BUG() from skb_checksum_help() [ Upstream commit d7ea0d9df2a6265b2b180d17ebc64b38105968fc ] I have a syzbot report that managed to get a crash in skb_checksum_help() If syzbot can trigger these BUG(), it makes sense to replace them with more friendly WARN_ON_ONCE() since skb_checksum_help() can instead return an error code. Note that syzbot will still crash there, until real bug is fixed. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit db6da340d66b8392dcecca0daa45051a8c1e4963 Author: James Smart Date: Thu May 5 20:55:17 2022 -0700 scsi: lpfc: Alter FPIN stat accounting logic [ Upstream commit e6f51041450282a8668af3a8fc5c7744e81a447c ] When configuring CMF management based on signals instead of FPINs, FPIN alarm and warning statistics are not tracked. Change the behavior so that FPIN alarms and warnings are always tracked regardless of the configured mode. Similar changes are made in the CMF signal stat accounting logic. Upon receipt of a signal, only track signaled alarms and warnings. FPIN stats should not be incremented upon receipt of a signal. Link: https://lore.kernel.org/r/20220506035519.50908-11-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2200453e8910b3d5f0d6f10935008eae53dcbe8b Author: Charles Keepax Date: Wed May 4 18:08:52 2022 +0100 ASoC: tscs454: Add endianness flag in snd_soc_component_driver [ Upstream commit ff69ec96b87dccb3a29edef8cec5d4fefbbc2055 ] The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. A fixup is also required to use the width directly rather than relying on the format in hw_params, now both little and big endian would be supported. It is worth noting this changes the behaviour of S24_LE to use a word length of 24 rather than 32. This would appear to be a correction since the fact S24_LE is stored as 32 bits should not be presented over the bus. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220504170905.332415-26-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit db6d83e09f760531bb57a31fb1e80f0d5b6a68e2 Author: Zhen Lei Date: Fri May 6 19:44:01 2022 +0800 of: Support more than one crash kernel regions for kexec -s [ Upstream commit 8af6b91f58341325bf74ecb0389ddc0039091d84 ] When "crashkernel=X,high" is used, there may be two crash regions: high=crashk_res and low=crashk_low_res. But now the syscall kexec_file_load() only add crashk_res into "linux,usable-memory-range", this may cause the second kernel to have no available dma memory. Fix it like kexec-tools does for option -c, add both 'high' and 'low' regions into the dtb. Signed-off-by: Zhen Lei Acked-by: Rob Herring Acked-by: Baoquan He Link: https://lore.kernel.org/r/20220506114402.365-6-thunder.leizhen@huawei.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 22e0b0b84c538b60bdf8eeceee7ab3cebf4a1a09 Author: Dongliang Mu Date: Fri May 6 15:24:25 2022 +0800 HID: bigben: fix slab-out-of-bounds Write in bigben_probe [ Upstream commit fc4ef9d5724973193bfa5ebed181dba6de3a56db ] There is a slab-out-of-bounds Write bug in hid-bigbenff driver. The problem is the driver assumes the device must have an input but some malicious devices violate this assumption. Fix this by checking hid_device's input is non-empty before its usage. Reported-by: syzkaller Signed-off-by: Dongliang Mu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 4262a0e46b08b274511ed7133363c8d8ad189082 Author: Nícolas F. R. A. Prado Date: Fri Apr 29 16:13:24 2022 -0400 regulator: mt6315: Enforce regulator-compatible, not name [ Upstream commit 6d435a94ba5bb4f2ad381c0828fbae89c66b50fe ] The MT6315 PMIC dt-binding should enforce that one of the valid regulator-compatible is set in each regulator node. However it was mistakenly matching against regulator-name instead. Fix the typo. This not only fixes the compatible verification, but also lifts the regulator-name restriction, so that more meaningful names can be set for each platform. Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20220429201325.2205799-1-nfraprado@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b305469ed00420e53c66064b554531d6fbd98d5b Author: Alice Wong Date: Mon May 2 11:40:18 2022 -0400 drm/amdgpu/ucode: Remove firmware load type check in amdgpu_ucode_free_bo [ Upstream commit ab0cd4a9ae5b4679b714d8dbfedc0901fecdce9f ] When psp_hw_init failed, it will set the load_type to AMDGPU_FW_LOAD_DIRECT. During amdgpu_device_ip_fini, amdgpu_ucode_free_bo checks that load_type is AMDGPU_FW_LOAD_DIRECT and skips deallocating fw_buf causing memory leak. Remove load_type check in amdgpu_ucode_free_bo. Signed-off-by: Alice Wong Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a2c87348acebd9bacedfe20cf82341928751ff91 Author: Alex Deucher Date: Thu Apr 21 01:21:52 2022 -0400 drm/amdgpu/psp: move PSP memory alloc from hw_init to sw_init [ Upstream commit b95b5391684b39695887afb4a13cccee7820f5d6 ] Memory allocations should be done in sw_init. hw_init should just be hardware programming needed to initialize the IP block. This is how most other IP blocks work. Move the GPU memory allocations from psp hw_init to psp sw_init and move the memory free to sw_fini. This also fixes a potential GPU memory leak if psp hw_init fails. Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit da3b69a564547b9262daf1c49c0302721d7a4500 Author: Petr Machata Date: Wed May 4 09:29:06 2022 +0300 mlxsw: Treat LLDP packets as control [ Upstream commit 0106668cd2f91bf913fb78972840dedfba80a3c3 ] When trapping packets for on-CPU processing, Spectrum machines differentiate between control and non-control traps. Traffic trapped through non-control traps is treated as data and kept in shared buffer in pools 0-4. Traffic trapped through control traps is kept in the dedicated control buffer 9. The advantage of marking traps as control is that pressure in the data plane does not prevent the control traffic to be processed. When the LLDP trap was introduced, it was marked as a control trap. But then in commit aed4b5721143 ("mlxsw: spectrum: PTP: Hook into packet receive path"), PTP traps were introduced. Because Ethernet-encapsulated PTP packets look to the Spectrum-1 ASIC as LLDP traffic and are trapped under the LLDP trap, this trap was reconfigured as non-control, in sync with the PTP traps. There is however no requirement that PTP traffic be handled as data. Besides, the usual encapsulation for PTP traffic is UDP, not bare Ethernet, and that is in deployments that even need PTP, which is far less common than LLDP. This is reflected by the default policer, which was not bumped up to the 19Kpps / 24Kpps that is the expected load of a PTP-enabled Spectrum-1 switch. Marking of LLDP trap as non-control was therefore probably misguided. In this patch, change it back to control. Reported-by: Maksym Yaremchuk Signed-off-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1377b79917e9c59962652dbed0ccaad5ede4d910 Author: Petr Machata Date: Wed May 4 09:29:05 2022 +0300 mlxsw: spectrum_dcb: Do not warn about priority changes [ Upstream commit b6b584562cbe7dc357083459d6dd5b171e12cadb ] The idea behind the warnings is that the user would get warned in case when more than one priority is configured for a given DSCP value on a netdevice. The warning is currently wrong, because dcb_ieee_getapp_mask() returns the first matching entry, not all of them, and the warning will then claim that some priority is "current", when in fact it is not. But more importantly, the warning is misleading in general. Consider the following commands: # dcb app flush dev swp19 dscp-prio # dcb app add dev swp19 dscp-prio 24:3 # dcb app replace dev swp19 dscp-prio 24:2 The last command will issue the following warning: mlxsw_spectrum3 0000:07:00.0 swp19: Ignoring new priority 2 for DSCP 24 in favor of current value of 3 The reason is that the "replace" command works by first adding the new value, and then removing all old values. This is the only way to make the replacement without causing the traffic to be prioritized to whatever the chip defaults to. The warning is issued in response to adding the new priority, and then no warning is shown when the old priority is removed. The upshot is that the canonical way to change traffic prioritization always produces a warning about ignoring the new priority, but what gets configured is in fact what the user intended. An option to just emit warning every time that the prioritization changes just to make it clear that it happened is obviously unsatisfactory. Therefore, in this patch, remove the warnings. Reported-by: Maksym Yaremchuk Signed-off-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9bb5de6e0b1a82d2c2631a56006848945c425b68 Author: Mark Brown Date: Thu Apr 28 17:18:32 2022 +0100 ASoC: dapm: Don't fold register value changes into notifications [ Upstream commit ad685980469b9f9b99d4d6ea05f4cb8f57cb2234 ] DAPM tracks and reports the value presented to the user from DAPM controls separately to the register value, these may diverge during initialisation or when an autodisable control is in use. When writing DAPM controls we currently report that a change has occurred if either the DAPM value or the value stored in the register has changed, meaning that if the two are out of sync we may appear to report a spurious event to userspace. Since we use this folded in value for nothing other than the value reported to userspace simply drop the folding in of the register change. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220428161833.3690050-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 77d7fb14890f4dbea2c863d00d52c9946145d93e Author: Mark Bloch Date: Tue Mar 15 11:23:40 2022 +0000 net/mlx5: fs, delete the FTE when there are no rules attached to it [ Upstream commit 7b0c6338597613f465d131bd939a51844a00455a ] When an FTE has no children is means all the rules where removed and the FTE can be deleted regardless of the dests_size value. While dests_size should be 0 when there are no children be extra careful not to leak memory or get firmware syndrome if the proper bookkeeping of dests_size wasn't done. Signed-off-by: Mark Bloch Reviewed-by: Maor Gottlieb Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 87402434ea841699507263a7c8249c383c6b7baf Author: jianghaoran Date: Fri Apr 29 13:38:02 2022 +0800 ipv6: Don't send rs packets to the interface of ARPHRD_TUNNEL [ Upstream commit b52e1cce31ca721e937d517411179f9196ee6135 ] ARPHRD_TUNNEL interface can't process rs packets and will generate TX errors ex: ip tunnel add ethn mode ipip local 192.168.1.1 remote 192.168.1.2 ifconfig ethn x.x.x.x ethn: flags=209 mtu 1480 inet x.x.x.x netmask 255.255.255.255 destination x.x.x.x inet6 fe80::5efe:ac1e:3cdb prefixlen 64 scopeid 0x20 tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 3 dropped 0 overruns 0 carrier 0 collisions 0 Signed-off-by: jianghaoran Link: https://lore.kernel.org/r/20220429053802.246681-1-jianghaoran@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 04be468ec13f4c9e4091c922c83ee920964e17df Author: Xiaoguang Wang Date: Thu Apr 21 10:37:35 2022 +0800 scsi: target: tcmu: Fix possible data corruption [ Upstream commit bb9b9eb0ae2e9d3f6036f0ad907c3a83dcd43485 ] When tcmu_vma_fault() gets a page successfully, before the current context completes page fault procedure, find_free_blocks() may run and call unmap_mapping_range() to unmap the page. Assume that when find_free_blocks() initially completes and the previous page fault procedure starts to run again and completes, then one truncated page has been mapped to userspace. But note that tcmu_vma_fault() has gotten a refcount for the page so any other subsystem won't be able to use the page unless the userspace address is unmapped later. If another command subsequently runs and needs to extend dbi_thresh it may reuse the corresponding slot for the previous page in data_bitmap. Then though we'll allocate new page for this slot in data_area, no page fault will happen because we have a valid map and the real request's data will be lost. Filesystem implementations will also run into this issue but they usually lock the page when vm_operations_struct->fault gets a page and unlock the page after finish_fault() completes. For truncate filesystems lock pages in truncate_inode_pages() to protect against racing wrt. page faults. To fix this possible data corruption scenario we can apply a method similar to the filesystems. For pages that are to be freed, tcmu_blocks_release() locks and unlocks. Make tcmu_vma_fault() also lock found page under cmdr_lock. At the same time, since tcmu_vma_fault() gets an extra page refcount, tcmu_blocks_release() won't free pages if pages are in page fault procedure, which means it is safe to call tcmu_blocks_release() before unmap_mapping_range(). With these changes tcmu_blocks_release() will wait for all page faults to be completed before calling unmap_mapping_range(). And later, if unmap_mapping_range() is called, it will ensure stale mappings are removed. Link: https://lore.kernel.org/r/20220421023735.9018-1-xiaoguang.wang@linux.alibaba.com Reviewed-by: Bodo Stroesser Signed-off-by: Xiaoguang Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 903d01a220ef297f207e338f3aa9df353ea88583 Author: Lv Ruyi Date: Sun Apr 24 03:19:59 2022 +0000 drm: msm: fix error check return value of irq_of_parse_and_map() [ Upstream commit b9e4f1d2b505df8e2439b63e67afaa287c1c43e2 ] The irq_of_parse_and_map() function returns 0 on failure, and does not return an negative value. Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/483175/ Link: https://lore.kernel.org/r/20220424031959.3172406-1-lv.ruyi@zte.com.cn Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 621916afe8cd4f322eb12759b64a2f938d4e551d Author: Alexandru Elisei Date: Mon Apr 25 12:44:41 2022 +0100 arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall [ Upstream commit 3fed9e551417b84038b15117732ea4505eee386b ] If a compat process tries to execute an unknown system call above the __ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() -> arm64_show_signal(). arm64_show_signal() interprets a non-zero value for current->thread.fault_code as an exception syndrome and displays the message associated with the ESR_ELx.EC field (bits 31:26). current->thread.fault_code is set in compat_arm_syscall() -> arm64_notify_die() with the bad syscall number instead of a valid ESR_ELx value. This means that the ESR_ELx.EC field has the value that the user set for the syscall number and the kernel can end up printing bogus exception messages*. For example, for the syscall number 0x68000000, which evaluates to ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error: [ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79 [ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT) [..] which is misleading, as the bad compat syscall has nothing to do with pointer authentication. Stop arm64_show_signal() from printing exception syndrome information by having compat_arm_syscall() set the ESR_ELx value to 0, as it has no meaning for an invalid system call number. The example above now becomes: [ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT) [..] which although shows less information because the syscall number, wrongfully advertised as the ESR value, is missing, it is better than showing plainly wrong information. The syscall number can be easily obtained with strace. *A 32-bit value above or equal to 0x8000_0000 is interpreted as a negative integer in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_END evaluates to true; the syscall will exit to userspace in this case with the ENOSYS error code instead of arm64_notify_die() being called. Signed-off-by: Alexandru Elisei Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20220425114444.368693-3-alexandru.elisei@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit c2272428090d0d215a3f017cbbbad731c07eee53 Author: Abhishek Kumar Date: Wed Apr 27 10:37:33 2022 +0300 ath10k: skip ath10k_halt during suspend for driver state RESTARTING [ Upstream commit b72a4aff947ba807177bdabb43debaf2c66bee05 ] Double free crash is observed when FW recovery(caused by wmi timeout/crash) is followed by immediate suspend event. The FW recovery is triggered by ath10k_core_restart() which calls driver clean up via ath10k_halt(). When the suspend event occurs between the FW recovery, the restart worker thread is put into frozen state until suspend completes. The suspend event triggers ath10k_stop() which again triggers ath10k_halt() The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to be called twice(Note: ath10k_htt_rx_alloc was not called by restart worker thread because of its frozen state), causing the crash. To fix this, during the suspend flow, skip call to ath10k_halt() in ath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING. Also, for driver state ATH10K_STATE_RESTARTING, call ath10k_wait_for_suspend() in ath10k_stop(). This is because call to ath10k_wait_for_suspend() is skipped later in [ath10k_halt() > ath10k_core_stop()] for the driver state ATH10K_STATE_RESTARTING. The frozen restart worker thread will be cancelled during resume when the device comes out of suspend. Below is the crash stack for reference: [ 428.469167] ------------[ cut here ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: events_unbound async_run_entry_fn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dma_free_attrs+0x5f/0x7d [ 428.469320] ath10k_core_stop+0x5b/0x6f [ 428.469336] ath10k_halt+0x126/0x177 [ 428.469352] ath10k_stop+0x41/0x7e [ 428.469387] drv_stop+0x88/0x10e [ 428.469410] __ieee80211_suspend+0x297/0x411 [ 428.469441] rdev_suspend+0x6e/0xd0 [ 428.469462] wiphy_suspend+0xb1/0x105 [ 428.469483] ? name_show+0x2d/0x2d [ 428.469490] dpm_run_callback+0x8c/0x126 [ 428.469511] ? name_show+0x2d/0x2d [ 428.469517] __device_suspend+0x2e7/0x41b [ 428.469523] async_suspend+0x1f/0x93 [ 428.469529] async_run_entry_fn+0x3d/0xd1 [ 428.469535] process_one_work+0x1b1/0x329 [ 428.469541] worker_thread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? pr_cont_work+0x58/0x58 [ 428.469558] ? kthread_blkcg+0x31/0x31 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Co-developed-by: Wen Gong Signed-off-by: Wen Gong Signed-off-by: Abhishek Kumar Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220426221859.v2.1.I650b809482e1af8d0156ed88b5dc2677a0711d46@changeid Signed-off-by: Sasha Levin commit ae488dafe074e420ccf361b2633f7fbc314eaedf Author: Evan Quan Date: Mon Apr 25 10:16:46 2022 +0800 drm/amd/pm: fix the compile warning [ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ] Fix the compile warning below: drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641 kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >= 0) => (0-u32max >= 0)' Reported-by: kernel test robot CC: Alex Deucher Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 978e3d023256bfaf34a0033d40c94e8a8e70cf3c Author: Steven Price Date: Fri Dec 3 10:28:15 2021 +0000 drm/plane: Move range check for format_count earlier [ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ] While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place. Signed-off-by: Steven Price Signed-off-by: Liviu Dudau Link: https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.price@arm.com/ Signed-off-by: Sasha Levin commit 47187f6177917806ebb256a6b32f8de1769fbade Author: Hans de Goede Date: Wed Apr 27 15:49:18 2022 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for the HP Pro Tablet 408 [ Upstream commit ce216cfa84a4e1c23b105e652c550bdeaac9e922 ] Add a quirk for the HP Pro Tablet 408, this BYTCR tablet has no CHAN package in its ACPI tables and uses SSP0-AIF1 rather then SSP0-AIF2 which is the default for BYTCR devices. It also uses DMIC1 for the internal mic rather then the default IN3 and it uses JD2 rather then the default JD1 for jack-detect. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211485 Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220427134918.527381-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 451b9076903a057b7b8d5b24dc84b3e436a1c743 Author: Hari Chandrakanthan Date: Sat Apr 23 12:36:47 2022 +0300 ath11k: disable spectral scan during spectral deinit [ Upstream commit 161c64de239c7018e0295e7e0520a19f00aa32dc ] When ath11k modules are removed using rmmod with spectral scan enabled, crash is observed. Different crash trace is observed for each crash. Send spectral scan disable WMI command to firmware before cleaning the spectral dbring in the spectral_deinit API to avoid this crash. call trace from one of the crash observed: [ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] *pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11k_spectral_process_data+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11k_spectral_process_data [ath11k]) from [<7f917fdc>] (ath11k_dbring_buffer_release_event+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11k_dbring_buffer_release_event [ath11k]) from [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx [ath11k]) from [<7f8fe868>] (ath11k_htc_rx_completion_handler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11k_htc_rx_completion_handler [ath11k]) from [<7f91308c>] (ath11k_ce_per_engine_service+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11k_ce_per_engine_service [ath11k]) from [<7f9a4198>] (ath11k_pci_ce_tasklet+0x28/0x80 [ath11k_pci]) [ 1253.514811] [<7f9a4198>] (ath11k_pci_ce_tasklet [ath11k_pci]) from [<8032227c>] (tasklet_action_common.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (tasklet_action_common.constprop.2) from [<803021e8>] (__do_softirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (__do_softirq) from [<80322610>] (irq_exit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irq_exit) from [<8036a4a4>] (__handle_domain_irq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (__handle_domain_irq) from [<805eb348>] (gic_handle_irq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPL_SILICONZ-1 Signed-off-by: Hari Chandrakanthan Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1649396345-349-1-git-send-email-quic_haric@quicinc.com Signed-off-by: Sasha Levin commit 40cf4ea4d2d497f7732c87d350ba5c3f5e8a43a1 Author: James Smart Date: Tue Apr 26 11:14:19 2022 -0700 scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp() [ Upstream commit 646db1a560f44236b7278b822ca99a1d3b6ea72c ] If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of a received frame, the frame is dropped and resources are leaked. Fix by returning resources when discarding an unhandled frame type. Update lpfc_fc_frame_check() handling of NOP basic link service. Link: https://lore.kernel.org/r/20220426181419.9154-1-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3ab08d7c16531311f80a70e0637e60429af9710f Author: Minghao Chi Date: Wed Apr 20 09:03:52 2022 +0000 scsi: ufs: Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync() [ Upstream commit 75b8715e20a20bc7b4844835e4035543a2674200 ] Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync() and pm_runtime_put_noidle(). This change is just to simplify the code, no actual functional changes. Link: https://lore.kernel.org/r/20220420090353.2588804-1-chi.minghao@zte.com.cn Reported-by: Zeal Robot Signed-off-by: Minghao Chi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7719a8044bf66b9f59818e50b0c7877e1397e7f4 Author: Haohui Mai Date: Mon Apr 25 20:41:38 2022 +0800 drm/amdgpu/sdma: Fix incorrect calculations of the wptr of the doorbells [ Upstream commit 7dba6e838e741caadcf27ef717b6dcb561e77f89 ] This patch fixes the issue where the driver miscomputes the 64-bit values of the wptr of the SDMA doorbell when initializing the hardware. SDMA engines v4 and later on have full 64-bit registers for wptr thus they should be set properly. Older generation hardwares like CIK / SI have only 16 / 20 / 24bits for the WPTR, where the calls of lower_32_bits() will be removed in a following patch. Reviewed-by: Christian König Signed-off-by: Haohui Mai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 942ce0cba14c907eefb954b84045df220c88ebd6 Author: Lv Ruyi Date: Mon Apr 18 10:57:55 2022 +0000 scsi: megaraid: Fix error check return value of register_chrdev() [ Upstream commit c5acd61dbb32b6bda0f3a354108f2b8dcb788985 ] If major equals 0, register_chrdev() returns an error code when it fails. This function dynamically allocates a major and returns its number on success, so we should use "< 0" to check it instead of "!". Link: https://lore.kernel.org/r/20220418105755.2558828-1-lv.ruyi@zte.com.cn Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7eb8e4787b43f499d91f3e4e9dcf905e68b0a312 Author: Vignesh Raghavendra Date: Mon Apr 25 12:01:20 2022 +0530 drivers: mmc: sdhci_am654: Add the quirk to set TESTCD bit [ Upstream commit c7666240ec76422cb7546bd07cc8ae80dc0ccdd2 ] The ARASAN MMC controller on Keystone 3 class of devices need the SDCD line to be connected for proper functioning. Similar to the issue pointed out in sdhci-of-arasan.c driver, commit 3794c542641f ("mmc: sdhci-of-arasan: Set controller to test mode when no CD bit"). In cases where this can't be connected, add a quirk to force the controller into test mode and set the TESTCD bit. Use the flag "ti,fails-without-test-cd", to implement this above quirk when required. Signed-off-by: Vignesh Raghavendra Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20220425063120.10135-3-a-govindraju@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 353298cadbd4c7d8e8a16d6000066414694933c3 Author: Aidan MacDonald Date: Mon Apr 11 16:37:53 2022 +0100 mmc: jz4740: Apply DMA engine limits to maximum segment size [ Upstream commit afadb04f1d6e74b18a253403f5274cde5e3fd7bd ] Do what is done in other DMA-enabled MMC host drivers (cf. host/mmci.c) and limit the maximum segment size based on the DMA engine's capabilities. This is needed to avoid warnings like the following with CONFIG_DMA_API_DEBUG=y. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 21 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment longer than device claims to support [len=98304] [max=65536] CPU: 0 PID: 21 Comm: kworker/0:1H Not tainted 5.18.0-rc1 #19 Workqueue: kblockd blk_mq_run_work_fn Stack : 81575aec 00000004 80620000 80620000 80620000 805e7358 00000009 801537ac 814c832c 806276e3 806e34b4 80620000 81575aec 00000001 81575ab8 09291444 00000000 00000000 805e7358 81575958 ffffffea 8157596c 00000000 636f6c62 6220646b 80387a70 0000000f 6d5f6b6c 80620000 00000000 81575ba4 00000009 805e170c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000 ... Call Trace: [<80107670>] show_stack+0x84/0x120 [<80528cd8>] __warn+0xb8/0xec [<80528d78>] warn_slowpath_fmt+0x6c/0xb8 [<8016f1d4>] debug_dma_map_sg+0x2f4/0x39c [<80169d4c>] __dma_map_sg_attrs+0xf0/0x118 [<8016a27c>] dma_map_sg_attrs+0x14/0x28 [<804f66b4>] jz4740_mmc_prepare_dma_data+0x74/0xa4 [<804f6714>] jz4740_mmc_pre_request+0x30/0x54 [<804f4ff4>] mmc_blk_mq_issue_rq+0x6e0/0x7bc [<804f5590>] mmc_mq_queue_rq+0x220/0x2d4 [<8038b2c0>] blk_mq_dispatch_rq_list+0x480/0x664 [<80391040>] blk_mq_do_dispatch_sched+0x2dc/0x370 [<80391468>] __blk_mq_sched_dispatch_requests+0xec/0x164 [<80391540>] blk_mq_sched_dispatch_requests+0x44/0x94 [<80387900>] __blk_mq_run_hw_queue+0xb0/0xcc [<80134c14>] process_one_work+0x1b8/0x264 [<80134ff8>] worker_thread+0x2ec/0x3b8 [<8013b13c>] kthread+0x104/0x10c [<80101dcc>] ret_from_kernel_thread+0x14/0x1c ---[ end trace 0000000000000000 ]--- Signed-off-by: Aidan MacDonald Link: https://lore.kernel.org/r/20220411153753.50443-1-aidanmacdonald.0x0@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 27f672af28a8e9b783ff7f0eaf7ef2fbd5a2f4ba Author: Heming Zhao Date: Fri Apr 1 10:13:16 2022 +0800 md/bitmap: don't set sb values if can't pass sanity check [ Upstream commit e68cb83a57a458b01c9739e2ad9cb70b04d1e6d2 ] If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed. How to trigger: (faulty injection) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] Reported-by: kernel test robot Reported-by: Dan Carpenter Acked-by: Guoqing Jiang Signed-off-by: Heming Zhao Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 1f0fc1dfb5fdd456657519a97fab83691b96c6a0 Author: Zheyu Ma Date: Sun Apr 10 08:44:09 2022 +0100 media: cx25821: Fix the warning when removing the module [ Upstream commit 2203436a4d24302871617373a7eb21bc17e38762 ] When removing the module, we will get the following warning: [ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]' [ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0 [ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0 [ 14.759589] Call Trace: [ 14.759792] [ 14.759975] unregister_irq_proc+0x14c/0x170 [ 14.760340] irq_free_descs+0x94/0xe0 [ 14.760640] mp_unmap_irq+0xb6/0x100 [ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40 [ 14.761334] acpi_pci_irq_disable+0x1d3/0x320 [ 14.761688] pci_disable_device+0x1ad/0x380 [ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60 [ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821] [ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821] [ 14.763242] pci_device_remove+0x92/0x240 Fix this by freeing the irq before call pci_disable_device(). Signed-off-by: Zheyu Ma Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 98106f100f50c487469903b9cf6d966785fc9cc3 Author: Zheyu Ma Date: Sun Apr 10 08:34:41 2022 +0100 media: pci: cx23885: Fix the error handling in cx23885_initdev() [ Upstream commit e8123311cf06d7dae71e8c5fe78e0510d20cd30b ] When the driver fails to call the dma_set_mask(), the driver will get the following splat: [ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240 [ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590 [ 55.856822] Call Trace: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 This is because the driver has initialized the i2c related resources in cx23885_dev_setup() but not released them in error handling, fix this bug by modifying the error path that jumps after failing to call the dma_set_mask(). Signed-off-by: Zheyu Ma Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9c385b961d4c378228e80f6abea8509cb67feab6 Author: Luca Weiss Date: Fri Jan 14 11:02:26 2022 +0000 media: venus: hfi: avoid null dereference in deinit [ Upstream commit 86594f6af867b5165d2ba7b5a71fae3a5961e56c ] If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary. Signed-off-by: Luca Weiss Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 84bf55461d2bc0a8196145f217bd4781f9d9ee19 Author: Thibaut VARÈNE Date: Sun Apr 17 16:51:45 2022 +0200 ath9k: fix QCA9561 PA bias level [ Upstream commit e999a5da28a0e0f7de242d841ef7d5e48f4646ae ] This patch fixes an invalid TX PA DC bias level on QCA9561, which results in a very low output power and very low throughput as devices are further away from the AP (compared to other 2.4GHz APs). This patch was suggested by Felix Fietkau, who noted[1]: "The value written to that register is wrong, because while the mask definition AR_CH0_TOP2_XPABIASLVL uses a different value for 9561, the shift definition AR_CH0_TOP2_XPABIASLVL_S is hardcoded to 12, which is wrong for 9561." In real life testing, without this patch the 2.4GHz throughput on Yuncore XD3200 is around 10Mbps sitting next to the AP, and closer to practical maximum with the patch applied. [1] https://lore.kernel.org/all/91c58969-c60e-2f41-00ac-737786d435ae@nbd.name Signed-off-by: Thibaut VARÈNE Acked-by: Felix Fietkau Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220417145145.1847-1-hacks+kernel@slashdirt.org Signed-off-by: Sasha Levin commit 4374b8d71ce83a2dea404368073fea676b80c3d6 Author: Kuninori Morimoto Date: Thu Apr 21 02:55:58 2022 +0000 ASoC: rsnd: care return value from rsnd_node_fixed_index() [ Upstream commit d09a7db431c65aaa8303eb456439d1831ca2e6b4 ] Renesas Sound is very complex, and thus it needs to use rsnd_node_fixed_index() to know enabled pin index. It returns error if strange pin was selected, but some codes didn't check it. This patch 1) indicates error message, 2) check return value. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87pmlbgn5t.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 24632913453f5b74d37fd87823d7f7b4919a2854 Author: Kuninori Morimoto Date: Thu Apr 21 02:55:27 2022 +0000 ASoC: rsnd: care default case on rsnd_ssiu_busif_err_status_clear() [ Upstream commit b1384d4c95088d01f4266237faabf165d3d605fc ] commit cfb7b8bf1e2d66 ("ASoC: rsnd: tidyup rsnd_ssiu_busif_err_status_clear()") merged duplicate code, but it didn't care about default case, and causes smatch warnings. smatch warnings: sound/soc/sh/rcar/ssiu.c:112 rsnd_ssiu_busif_err_status_clear() \ error: uninitialized symbol 'offset'. sound/soc/sh/rcar/ssiu.c:114 rsnd_ssiu_busif_err_status_clear() \ error: uninitialized symbol 'shift'. This patch cares it. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87r15rgn6p.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a5ce7051db044290b1a95045ff03c249005a3aa4 Author: Keita Suzuki Date: Tue Apr 19 10:37:19 2022 +0000 drm/amd/pm: fix double free in si_parse_power_table() [ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ] In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated. Signed-off-by: Keita Suzuki Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2bcec28ac0b39834ee4a9e13b38ea1c7ca12ca12 Author: Ulf Hansson Date: Fri Apr 1 16:11:24 2022 +0200 cpuidle: PSCI: Improve support for suspend-to-RAM for PSCI OSI mode [ Upstream commit 171b66e2e2e9d80b93c8cff799e6175074b22297 ] When PSCI OSI mode is supported the syscore flag is set for the CPU devices that becomes attached to their PM domains (genpds). In the suspend-to-idle case, we call dev_pm_genpd_suspend|resume() to allow genpd to properly manage the power-off/on operations (pick an idlestate and manage the on/off notifications). For suspend-to-ram, dev_pm_genpd_suspend|resume() is currently not being called, which causes a problem that the genpd on/off notifiers do not get sent as expected. This prevents the platform-specific operations from being executed, typically needed just before/after the boot CPU is being turned off/on. To deal with this problem, let's register a syscore ops for cpuidle-psci when PSCI OSI mode is being used and call dev_pm_genpd_suspend|resume() from them. In this way, genpd regains control of the PM domain topology and then sends the on/off notifications when it's appropriate. Reported-by: Maulik Shah Suggested-by: Maulik Shah Signed-off-by: Ulf Hansson Tested-by: Maulik Shah Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ae373d66c427812754db5292eb1481b181daf9ce Author: James Smart Date: Tue Apr 12 15:19:57 2022 -0700 scsi: lpfc: Fix call trace observed during I/O with CMF enabled [ Upstream commit d6d45f67a11136cb88a70a29ab22ea6db8ae6bd5 ] The following was seen with CMF enabled: BUG: using smp_processor_id() in preemptible code: systemd-udevd/31711 kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: CPU: 12 PID: 31711 Comm: systemd-udevd kernel: Call Trace: kernel: kernel: dump_stack_lvl+0x44/0x57 kernel: check_preemption_disabled+0xbf/0xe0 kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc] this_cpu_ptr() calls smp_processor_id() in a preemptible context. Fix by using per_cpu_ptr() with raw_smp_processor_id() instead. Link: https://lore.kernel.org/r/20220412222008.126521-16-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7625e81de2164a082810e1f27547d388406da610 Author: James Smart Date: Tue Apr 12 15:19:48 2022 -0700 scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock [ Upstream commit 03cbbd7c2f5ee288f648f4aeedc765a181188553 ] During stress I/O tests with 500+ vports, hard LOCKUP call traces are observed. CPU A: native_queued_spin_lock_slowpath+0x192 _raw_spin_lock_irqsave+0x32 lpfc_handle_fcp_err+0x4c6 lpfc_fcp_io_cmd_wqe_cmpl+0x964 lpfc_sli4_fp_handle_cqe+0x266 __lpfc_sli4_process_cq+0x105 __lpfc_sli4_hba_process_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7f CPU B: native_queued_spin_lock_slowpath+0x5b _raw_spin_lock+0x1c lpfc_abort_handler+0x13e scmd_eh_abort_handler+0x85 process_one_work+0x1a7 worker_thread+0x30 kthread+0x112 ret_from_fork+0x1f Diagram of lockup: CPUA CPUB ---- ---- lpfc_cmd->buf_lock phba->hbalock lpfc_cmd->buf_lock phba->hbalock Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock first before phba->hbalock. Link: https://lore.kernel.org/r/20220412222008.126521-7-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 271725e4028559ae7974d762a8467dc9de412f2e Author: James Smart Date: Tue Apr 12 15:19:44 2022 -0700 scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg() [ Upstream commit e294647b1aed4247fe52851f3a3b2b19ae906228 ] In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard lockup call trace hangs the system. Call Trace: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40 Kernel panic - not syncing: Hard LOCKUP The same CPU tries to claim the phba->port_list_lock twice. Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need to take the phba->port_list_lock within lpfc_dmp_dbg(). Link: https://lore.kernel.org/r/20220412222008.126521-3-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fcd1893ef57b88c1656d92e0be7a4f1f23f461d2 Author: Len Brown Date: Thu Feb 10 21:06:56 2022 -0500 tools/power turbostat: fix ICX DRAM power numbers [ Upstream commit 6397b6418935773a34b533b3348b03f4ce3d7050 ] ICX (and its duplicates) require special hard-coded DRAM RAPL units, rather than using the generic RAPL energy units. Reported-by: Srinivas Pandruvada Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 30be187da5795e222d1b2a083b9b3604068a7dcc Author: Biju Das Date: Mon Apr 11 18:31:15 2022 +0100 spi: spi-rspi: Remove setting {src,dst}_{addr,addr_width} based on DMA direction [ Upstream commit 6f381481a5b236cb53d6de2c49c6ef83a4d0f432 ] The direction field in the DMA config is deprecated. The rspi driver sets {src,dst}_{addr,addr_width} based on the DMA direction and it results in dmaengine_slave_config() failure as RZ DMAC driver validates {src,dst}_addr_width values independent of DMA direction. This patch fixes the issue by passing both {src,dst}_{addr,addr_width} values independent of DMA direction. Signed-off-by: Biju Das Suggested-by: Vinod Koul Reviewed-by: Vinod Koul Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20220411173115.6619-1-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ecfe184509a519cd165fad6228b8fe59d8cbd9e4 Author: Po-Hao Huang Date: Thu Apr 7 17:58:58 2022 +0800 rtw88: 8821c: fix debugfs rssi value [ Upstream commit ece31c93d4d68f7eb8eea4431b052aacdb678de2 ] RSSI value per frame is reported to mac80211 but not maintained in our own statistics, add it back to help us debug. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220407095858.46807-7-pkshih@realtek.com Signed-off-by: Sasha Levin commit 5cc6f623f4818c7d7e9e966a45ebf324901ca9c5 Author: Amadeusz Sławiński Date: Tue Apr 12 11:16:28 2022 +0200 ALSA: jack: Access input_dev under mutex [ Upstream commit 1b6a6fc5280e97559287b61eade2d4b363e836f2 ] It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock. Signed-off-by: Amadeusz Sławiński Reviewed-by: Cezary Rojewski Link: https://lore.kernel.org/r/20220412091628.3056922-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 64e9f4f65c945b8eb6f4b2a7d0312150b4b8d7d8 Author: Haowen Bai Date: Mon Apr 11 09:32:37 2022 +0800 sfc: ef10: Fix assigning negative value to unsigned variable [ Upstream commit b8ff3395fbdf3b79a99d0ef410fc34c51044121e ] fix warning reported by smatch: 251 drivers/net/ethernet/sfc/ef10.c:2259 efx_ef10_tx_tso_desc() warn: assigning (-208) to unsigned variable 'ip_tot_len' Signed-off-by: Haowen Bai Acked-by: Edward Cree Link: https://lore.kernel.org/r/1649640757-30041-1-git-send-email-baihaowen@meizu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2da36b14af94dc736b24941d13217493c117a2c5 Author: Paul E. McKenney Date: Thu Mar 17 09:30:10 2022 -0700 rcu: Make TASKS_RUDE_RCU select IRQ_WORK [ Upstream commit 46e861be589881e0905b9ade3d8439883858721c ] The TASKS_RUDE_RCU does not select IRQ_WORK, which can result in build failures for kernels that do not otherwise select IRQ_WORK. This commit therefore causes the TASKS_RUDE_RCU Kconfig option to select IRQ_WORK. Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit ba722d061bc4b54802d701fc63fc2fd988934603 Author: Padmanabha Srinivasaiah Date: Thu Feb 17 16:25:19 2022 +0100 rcu-tasks: Fix race in schedule and flush work [ Upstream commit f75fd4b9221d93177c50dcfde671b2e907f53e86 ] While booting secondary CPUs, cpus_read_[lock/unlock] is not keeping online cpumask stable. The transient online mask results in below calltrace. [ 0.324121] CPU1: Booted secondary processor 0x0000000001 [0x410fd083] [ 0.346652] Detected PIPT I-cache on CPU2 [ 0.347212] CPU2: Booted secondary processor 0x0000000002 [0x410fd083] [ 0.377255] Detected PIPT I-cache on CPU3 [ 0.377823] CPU3: Booted secondary processor 0x0000000003 [0x410fd083] [ 0.379040] ------------[ cut here ]------------ [ 0.383662] WARNING: CPU: 0 PID: 10 at kernel/workqueue.c:3084 __flush_work+0x12c/0x138 [ 0.384850] Modules linked in: [ 0.385403] CPU: 0 PID: 10 Comm: rcu_tasks_rude_ Not tainted 5.17.0-rc3-v8+ #13 [ 0.386473] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 0.387289] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.388308] pc : __flush_work+0x12c/0x138 [ 0.388970] lr : __flush_work+0x80/0x138 [ 0.389620] sp : ffffffc00aaf3c60 [ 0.390139] x29: ffffffc00aaf3d20 x28: ffffffc009c16af0 x27: ffffff80f761df48 [ 0.391316] x26: 0000000000000004 x25: 0000000000000003 x24: 0000000000000100 [ 0.392493] x23: ffffffffffffffff x22: ffffffc009c16b10 x21: ffffffc009c16b28 [ 0.393668] x20: ffffffc009e53861 x19: ffffff80f77fbf40 x18: 00000000d744fcc9 [ 0.394842] x17: 000000000000000b x16: 00000000000001c2 x15: ffffffc009e57550 [ 0.396016] x14: 0000000000000000 x13: ffffffffffffffff x12: 0000000100000000 [ 0.397190] x11: 0000000000000462 x10: ffffff8040258008 x9 : 0000000100000000 [ 0.398364] x8 : 0000000000000000 x7 : ffffffc0093c8bf4 x6 : 0000000000000000 [ 0.399538] x5 : 0000000000000000 x4 : ffffffc00a976e40 x3 : ffffffc00810444c [ 0.400711] x2 : 0000000000000004 x1 : 0000000000000000 x0 : 0000000000000000 [ 0.401886] Call trace: [ 0.402309] __flush_work+0x12c/0x138 [ 0.402941] schedule_on_each_cpu+0x228/0x278 [ 0.403693] rcu_tasks_rude_wait_gp+0x130/0x144 [ 0.404502] rcu_tasks_kthread+0x220/0x254 [ 0.405264] kthread+0x174/0x1ac [ 0.405837] ret_from_fork+0x10/0x20 [ 0.406456] irq event stamp: 102 [ 0.406966] hardirqs last enabled at (101): [] _raw_spin_unlock_irq+0x78/0xb4 [ 0.408304] hardirqs last disabled at (102): [] el1_dbg+0x24/0x5c [ 0.409410] softirqs last enabled at (54): [] local_bh_enable+0xc/0x2c [ 0.410645] softirqs last disabled at (50): [] local_bh_disable+0xc/0x2c [ 0.411890] ---[ end trace 0000000000000000 ]--- [ 0.413000] smp: Brought up 1 node, 4 CPUs [ 0.413762] SMP: Total of 4 processors activated. [ 0.414566] CPU features: detected: 32-bit EL0 Support [ 0.415414] CPU features: detected: 32-bit EL1 Support [ 0.416278] CPU features: detected: CRC32 instructions [ 0.447021] Callback from call_rcu_tasks_rude() invoked. [ 0.506693] Callback from call_rcu_tasks() invoked. This commit therefore fixes this issue by applying a single-CPU optimization to the RCU Tasks Rude grace-period process. The key point here is that the purpose of this RCU flavor is to force a schedule on each online CPU since some past event. But the rcu_tasks_rude_wait_gp() function runs in the context of the RCU Tasks Rude's grace-period kthread, so there must already have been a context switch on the current CPU since the call to either synchronize_rcu_tasks_rude() or call_rcu_tasks_rude(). So if there is only a single CPU online, RCU Tasks Rude's grace-period kthread does not need to anything at all. It turns out that the rcu_tasks_rude_wait_gp() function's call to schedule_on_each_cpu() causes problems during early boot. During that time, there is only one online CPU, namely the boot CPU. Therefore, applying this single-CPU optimization fixes early-boot instances of this problem. Link: https://lore.kernel.org/lkml/20220210184319.25009-1-treasure4paddy@gmail.com/T/ Suggested-by: Paul E. McKenney Signed-off-by: Padmanabha Srinivasaiah Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit d0d266c2f689d6113fe0d43d1b1fc105157c7443 Author: Saaem Rizvi Date: Mon Mar 28 14:25:16 2022 -0400 drm/amd/display: Disabling Z10 on DCN31 [ Upstream commit 5d5af34072c8b11f60960c3bea57ff9de5877791 ] [WHY] Z10 is should not be enabled by default on DCN31. [HOW] Using DC debug flags to disable Z10 by default on DCN31. Reviewed-by: Eric Yang Acked-by: Pavle Kotarac Signed-off-by: Saaem Rizvi Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3f2dc8106345e34bbf425d00dfb2ce708048b7e2 Author: Liviu Dudau Date: Thu Dec 2 17:00:33 2021 +0000 drm/komeda: return early if drm_universal_plane_init() fails. [ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ] If drm_universal_plane_init() fails early we jump to the common cleanup code that calls komeda_plane_destroy() which in turn could access the uninitalised drm_plane and crash. Return early if an error is detected without going through the common code. Reported-by: Steven Price Reviewed-by: Steven Price Signed-off-by: Liviu Dudau Link: https://lore.kernel.org/dri-devel/20211203100946.2706922-1-liviu.dudau@arm.com Signed-off-by: Sasha Levin commit 042f8d5a13d270e1cbda3cde410a5544b5468306 Author: Peter Seiderer Date: Mon Apr 4 18:54:14 2022 +0200 mac80211: minstrel_ht: fix where rate stats are stored (fixes debugfs output) [ Upstream commit 5c6dd7bd569b54c0d2904125d7366aa93f077f67 ] Using an ath9k card the debugfs output of minstrel_ht looks like the following (note the zero values for the first four rates sum-of success/attempts): best ____________rate__________ ____statistics___ _____last____ ______sum-of________ mode guard # rate [name idx airtime max_tp] [avg(tp) avg(prob)] [retry|suc|att] [#success | #attempts] OFDM 1 DP 6.0M 272 1640 5.2 3.1 53.8 3 0 0 0 0 OFDM 1 C 9.0M 273 1104 7.7 4.6 53.8 4 0 0 0 0 OFDM 1 B 12.0M 274 836 10.0 6.0 53.8 4 0 0 0 0 OFDM 1 A S 18.0M 275 568 14.3 8.5 53.8 5 0 0 0 0 OFDM 1 S 24.0M 276 436 18.1 0.0 0.0 5 0 1 80 1778 OFDM 1 36.0M 277 300 24.9 0.0 0.0 0 0 1 0 107 OFDM 1 S 48.0M 278 236 30.4 0.0 0.0 0 0 0 0 75 OFDM 1 54.0M 279 212 33.0 0.0 0.0 0 0 0 0 72 Total packet count:: ideal 16582 lookaround 885 Average # of aggregated frames per A-MPDU: 1.0 Debugging showed that the rate statistics for the first four rates where stored in the MINSTREL_CCK_GROUP instead of the MINSTREL_OFDM_GROUP because in minstrel_ht_get_stats() the supported check was not honoured as done in various other places, e.g net/mac80211/rc80211_minstrel_ht_debugfs.c: 74 if (!(mi->supported[i] & BIT(j))) 75 continue; With the patch applied the output looks good: best ____________rate__________ ____statistics___ _____last____ ______sum-of________ mode guard # rate [name idx airtime max_tp] [avg(tp) avg(prob)] [retry|suc|att] [#success | #attempts] OFDM 1 D 6.0M 272 1640 5.2 5.2 100.0 3 0 0 1 1 OFDM 1 C 9.0M 273 1104 7.7 7.7 100.0 4 0 0 38 38 OFDM 1 B 12.0M 274 836 10.0 9.9 89.5 4 2 2 372 395 OFDM 1 A P 18.0M 275 568 14.3 14.3 97.2 5 52 53 6956 7181 OFDM 1 S 24.0M 276 436 18.1 0.0 0.0 0 0 1 6 163 OFDM 1 36.0M 277 300 24.9 0.0 0.0 0 0 1 0 35 OFDM 1 S 48.0M 278 236 30.4 0.0 0.0 0 0 0 0 38 OFDM 1 S 54.0M 279 212 33.0 0.0 0.0 0 0 0 0 38 Total packet count:: ideal 7097 lookaround 287 Average # of aggregated frames per A-MPDU: 1.0 Signed-off-by: Peter Seiderer Link: https://lore.kernel.org/r/20220404165414.1036-1-ps.report@gmx.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a425d18a131fe89c61d6a07a441cd4c57b97c31f Author: Kirill A. Shutemov Date: Wed Apr 6 02:29:38 2022 +0300 ACPICA: Avoid cache flush inside virtual machines [ Upstream commit e2efb6359e620521d1e13f69b2257de8ceaa9475 ] While running inside virtual machine, the kernel can bypass cache flushing. Changing sleep state in a virtual machine doesn't affect the host system sleep state and cannot lead to data loss. Before entering sleep states, the ACPI code flushes caches to prevent data loss using the WBINVD instruction. This mechanism is required on bare metal. But, any use WBINVD inside of a guest is worthless. Changing sleep state in a virtual machine doesn't affect the host system sleep state and cannot lead to data loss, so most hypervisors simply ignore it. Despite this, the ACPI code calls WBINVD unconditionally anyway. It's useless, but also normally harmless. In TDX guests, though, WBINVD stops being harmless; it triggers a virtualization exception (#VE). If the ACPI cache-flushing WBINVD were left in place, TDX guests would need handling to recover from the exception. Avoid using WBINVD whenever running under a hypervisor. This both removes the useless WBINVDs and saves TDX from implementing WBINVD handling. Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Dave Hansen Reviewed-by: Dan Williams Reviewed-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20220405232939.73860-30-kirill.shutemov@linux.intel.com Signed-off-by: Sasha Levin commit 063ed7dbf9d3d44ba5fefe6ee638f3666988f9d4 Author: Mike Travis Date: Wed Apr 6 14:51:48 2022 -0500 x86/platform/uv: Update TSC sync state for UV5 [ Upstream commit bb3ab81bdbd53f88f26ffabc9fb15bd8466486ec ] The UV5 platform synchronizes the TSCs among all chassis, and will not proceed to OS boot without achieving synchronization. Previous UV platforms provided a register indicating successful synchronization. This is no longer available on UV5. On this platform TSC_ADJUST should not be reset by the kernel. Signed-off-by: Mike Travis Signed-off-by: Steve Wahl Signed-off-by: Borislav Petkov Reviewed-by: Dimitri Sivanich Acked-by: Thomas Gleixner Link: https://lore.kernel.org/r/20220406195149.228164-3-steve.wahl@hpe.com Signed-off-by: Sasha Levin commit 0781b564048b0d2a4b966d8000498af7d754bad0 Author: Daniel Vetter Date: Tue Apr 5 23:03:31 2022 +0200 fbcon: Consistently protect deferred_takeover with console_lock() [ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ] This shouldn't be a problem in practice since until we've actually taken over the console there's nothing we've registered with the console/vt subsystem, so the exit/unbind path that check this can't do the wrong thing. But it's confusing, so fix it by moving it a tad later. Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Du Cheng Cc: Tetsuo Handa Cc: Claudio Suarez Cc: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-14-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 7665af570b843f699eaf139609f070d910b7c0d6 Author: Niels Dossche Date: Mon Apr 4 01:15:24 2022 +0200 ipv6: fix locking issues with loops over idev->addr_list [ Upstream commit 51454ea42c1ab4e0c2828bb0d4d53957976980de ] idev->addr_list needs to be protected by idev->lock. However, it is not always possible to do so while iterating and performing actions on inet6_ifaddr instances. For example, multiple functions (like addrconf_{join,leave}_anycast) eventually call down to other functions that acquire the idev->lock. The current code temporarily unlocked the idev->lock during the loops, which can cause race conditions. Moving the locks up is also not an appropriate solution as the ordering of lock acquisition will be inconsistent with for example mc_lock. This solution adds an additional field to inet6_ifaddr that is used to temporarily add the instances to a temporary list while holding idev->lock. The temporary list can then be traversed without holding idev->lock. This change was done in two places. In addrconf_ifdown, the list_for_each_entry_safe variant of the list loop is also no longer necessary as there is no deletion within that specific loop. Suggested-by: Paolo Abeni Signed-off-by: Niels Dossche Acked-by: Paolo Abeni Link: https://lore.kernel.org/r/20220403231523.45843-1-dossche.niels@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 48d4a820fd33f012e5f63735a59d15b5a3882882 Author: Haowen Bai Date: Fri Apr 1 15:10:54 2022 +0800 ipw2x00: Fix potential NULL dereference in libipw_xmit() [ Upstream commit e8366bbabe1d207cf7c5b11ae50e223ae6fc278b ] crypt and crypt->ops could be null, so we need to checking null before dereference Signed-off-by: Haowen Bai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1648797055-25730-1-git-send-email-baihaowen@meizu.com Signed-off-by: Sasha Levin commit 9547e5ed9c59bfc16675d831479d0b151f15e2d7 Author: Haowen Bai Date: Fri Mar 25 18:15:15 2022 +0800 b43: Fix assigning negative value to unsigned variable [ Upstream commit 11800d893b38e0e12d636c170c1abc19c43c730c ] fix warning reported by smatch: drivers/net/wireless/broadcom/b43/phy_n.c:585 b43_nphy_adjust_lna_gain_table() warn: assigning (-2) to unsigned variable '*(lna_gain[0])' Signed-off-by: Haowen Bai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1648203315-28093-1-git-send-email-baihaowen@meizu.com Signed-off-by: Sasha Levin commit e7823a60f339d5ce19c4768e2d3264a211f203f7 Author: Haowen Bai Date: Fri Mar 25 18:17:13 2022 +0800 b43legacy: Fix assigning negative value to unsigned variable [ Upstream commit 3f6b867559b3d43a7ce1b4799b755e812fc0d503 ] fix warning reported by smatch: drivers/net/wireless/broadcom/b43legacy/phy.c:1181 b43legacy_phy_lo_b_measure() warn: assigning (-772) to unsigned variable 'fval' Signed-off-by: Haowen Bai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1648203433-8736-1-git-send-email-baihaowen@meizu.com Signed-off-by: Sasha Levin commit 07ea9293330d6598ae451b002c0f576941486be6 Author: Niels Dossche Date: Mon Mar 21 23:55:16 2022 +0100 mwifiex: add mutex lock for call in mwifiex_dfs_chan_sw_work_queue [ Upstream commit 3e12968f6d12a34b540c39cbd696a760cc4616f0 ] cfg80211_ch_switch_notify uses ASSERT_WDEV_LOCK to assert that net_device->ieee80211_ptr->mtx (which is the same as priv->wdev.mtx) is held during the function's execution. mwifiex_dfs_chan_sw_work_queue is one of its callers, which does not hold that lock, therefore violating the assertion. Add a lock around the call. Disclaimer: I am currently working on a static analyser to detect missing locks. This was a reported case. I manually verified the report by looking at the code, so that I do not send wrong information or patches. After concluding that this seems to be a true positive, I created this patch. However, as I do not in fact have this particular hardware, I was unable to test it. Reviewed-by: Brian Norris Signed-off-by: Niels Dossche Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220321225515.32113-1-dossche.niels@gmail.com Signed-off-by: Sasha Levin commit 2485af5ca4bb32132137ac6b0fb5080e0be832f7 Author: Quentin Monnet Date: Mon Apr 4 15:09:44 2022 +0100 selftests/bpf: Fix parsing of prog types in UAPI hdr for bpftool sync [ Upstream commit 4eeebce6ac4ad80ee8243bb847c98e0e55848d47 ] The script for checking that various lists of types in bpftool remain in sync with the UAPI BPF header uses a regex to parse enum bpf_prog_type. If this enum contains a set of values different from the list of program types in bpftool, it complains. This script should have reported the addition, some time ago, of the new BPF_PROG_TYPE_SYSCALL, which was not reported to bpftool's program types list. It failed to do so, because it failed to parse that new type from the enum. This is because the new value, in the BPF header, has an explicative comment on the same line, and the regex does not support that. Let's update the script to support parsing enum values when they have comments on the same line. Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220404140944.64744-1-quentin@isovalent.com Signed-off-by: Sasha Levin commit 3117e7a0de6f82d154542b82a2df369e801508db Author: Nikolay Borisov Date: Thu Mar 31 17:09:49 2022 +0300 selftests/bpf: Fix vfs_link kprobe definition [ Upstream commit e299bcd4d16ff86f46c48df1062c8aae0eca1ed8 ] Since commit 6521f8917082 ("namei: prepare for idmapped mounts") vfs_link's prototype was changed, the kprobe definition in profiler selftest in turn wasn't updated. The result is that all argument after the first are now stored in different registers. This means that self-test has been broken ever since. Fix it by updating the kprobe definition accordingly. Signed-off-by: Nikolay Borisov Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220331140949.1410056-1-nborisov@suse.com Signed-off-by: Sasha Levin commit 32e10aabc287f09a148ff759bb9ce70b01b0012c Author: Liu Zixian Date: Tue Mar 22 17:17:30 2022 +0800 drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes [ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ] drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218 Signed-off-by: Liu Zixian Link: http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixian4@huawei.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 079164db407c204065c4c87b7fc281ece180b056 Author: Zack Rusin Date: Fri Mar 18 13:43:30 2022 -0400 drm/vmwgfx: validate the screen formats [ Upstream commit 8bb75aeb58bd688d70827ae179bd3da57b6d975b ] The kms code wasn't validating the modifiers and was letting through unsupported formats. rgb8 was never properly supported and has no matching svga screen target format so remove it. This fixes format/modifier failures in kms_addfb_basic from IGT. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20220318174332.440068-4-zack@kde.org Signed-off-by: Sasha Levin commit 4475d3c3b224ce8c0790198a13a4e72ff60b1226 Author: Tejas Upadhyay Date: Wed Mar 2 10:02:56 2022 +0530 iommu/vt-d: Add RPLS to quirk list to skip TE disabling [ Upstream commit 0a967f5bfd9134b89681cae58deb222e20840e76 ] The VT-d spec requires (10.4.4 Global Command Register, TE field) that: Hardware implementations supporting DMA draining must drain any in-flight DMA read/write requests queued within the Root-Complex before completing the translation enable command and reflecting the status of the command through the TES field in the Global Status register. Unfortunately, some integrated graphic devices fail to do so after some kind of power state transition. As the result, the system might stuck in iommu_disable_translati on(), waiting for the completion of TE transition. This adds RPLS to a quirk list for those devices and skips TE disabling if the qurik hits. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/4898 Tested-by: Raviteja Goud Talla Cc: Rodrigo Vivi Acked-by: Lu Baolu Signed-off-by: Tejas Upadhyay Reviewed-by: Rodrigo Vivi Signed-off-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20220302043256.191529-1-tejaskumarx.surendrakumar.upadhyay@intel.com Signed-off-by: Sasha Levin commit 08128d6cac4e3eff37e22e75674b40baa0053898 Author: Qu Wenruo Date: Tue Apr 12 20:30:14 2022 +0800 btrfs: fix the error handling for submit_extent_page() for btrfs_do_readpage() commit 10f7f6f879c28f8368d6516ab1ccf3517a1f5d3d upstream. [BUG] Test case generic/475 have a very high chance (almost 100%) to hit a fs hang, where a data page will never be unlocked and hang all later operations. [CAUSE] In btrfs_do_readpage(), if we hit an error from submit_extent_page() we will try to do the cleanup for our current io range, and exit. This works fine for PAGE_SIZE == sectorsize cases, but not for subpage. For subpage btrfs_do_readpage() will lock the full page first, which can contain several different sectors and extents: btrfs_do_readpage() |- begin_page_read() | |- btrfs_subpage_start_reader(); | Now the page will have PAGE_SIZE / sectorsize reader pending, | and the page is locked. | |- end_page_read() for different branches | This function will reduce subpage readers, and when readers | reach 0, it will unlock the page. But when submit_extent_page() failed, we only cleanup the current io range, while the remaining io range will never be cleaned up, and the page remains locked forever. [FIX] Update the error handling of submit_extent_page() to cleanup all the remaining subpage range before exiting the loop. Please note that, now submit_extent_page() can only fail due to sanity check in alloc_new_bio(). Thus regular IO errors are impossible to trigger the error path. CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 80e2340d1f8071e3cd6044dfc14a987dac26d1cd Author: Qu Wenruo Date: Mon Feb 28 15:05:53 2022 +0800 btrfs: repair super block num_devices automatically commit d201238ccd2f30b9bfcfadaeae0972e3a486a176 upstream. [BUG] There is a report that a btrfs has a bad super block num devices. This makes btrfs to reject the fs completely. BTRFS error (device sdd3): super_num_devices 3 mismatch with num_devices 2 found here BTRFS error (device sdd3): failed to read chunk tree: -22 BTRFS error (device sdd3): open_ctree failed [CAUSE] During btrfs device removal, chunk tree and super block num devs are updated in two different transactions: btrfs_rm_device() |- btrfs_rm_dev_item(device) | |- trans = btrfs_start_transaction() | | Now we got transaction X | | | |- btrfs_del_item() | | Now device item is removed from chunk tree | | | |- btrfs_commit_transaction() | Transaction X got committed, super num devs untouched, | but device item removed from chunk tree. | (AKA, super num devs is already incorrect) | |- cur_devices->num_devices--; |- cur_devices->total_devices--; |- btrfs_set_super_num_devices() All those operations are not in transaction X, thus it will only be written back to disk in next transaction. So after the transaction X in btrfs_rm_dev_item() committed, but before transaction X+1 (which can be minutes away), a power loss happen, then we got the super num mismatch. This has been fixed by commit bbac58698a55 ("btrfs: remove device item and update super block in the same transaction"). [FIX] Make the super_num_devices check less strict, converting it from a hard error to a warning, and reset the value to a correct one for the current or next transaction commit. As the number of device items is the critical information where the super block num_devices is only a cached value (and also useful for cross checking), it's safe to automatically update it. Other device related problems like missing device are handled after that and may require other means to resolve, like degraded mount. With this fix, potentially affected filesystems won't fail mount and require the manual repair by btrfs check. Reported-by: Luca Béla Palkovics Link: https://lore.kernel.org/linux-btrfs/CA+8xDSpvdm_U0QLBAnrH=zqDq_cWCOH5TiV46CKmp3igr44okQ@mail.gmail.com/ CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b17dada226ab19b8c9cdb9b96838387ba8a77d42 Author: Qu Wenruo Date: Tue Apr 12 20:30:15 2022 +0800 btrfs: return correct error number for __extent_writepage_io() commit 44e5801fada6925d2bba1987c7b59cbcc9d0d592 upstream. [BUG] If we hit an error from submit_extent_page() inside __extent_writepage_io(), we could still return 0 to the caller, and even trigger the warning in btrfs_page_assert_not_dirty(). [CAUSE] In __extent_writepage_io(), if we hit an error from submit_extent_page(), we will just clean up the range and continue. This is completely fine for regular PAGE_SIZE == sectorsize, as we can only hit one sector in one page, thus after the error we're ensured to exit and @ret will be saved. But for subpage case, we may have other dirty subpage range in the page, and in the next loop, we may succeeded submitting the next range. In that case, @ret will be overwritten, and we return 0 to the caller, while we have hit some error. [FIX] Introduce @has_error and @saved_ret to record the first error we hit, so we will never forget what error we hit. CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 018110b5daa8ed3a3c89e4ad9a7cddbf7e5057e7 Author: Qu Wenruo Date: Tue May 10 15:10:18 2022 +0800 btrfs: add "0x" prefix for unsupported optional features commit d5321a0fa8bc49f11bea0b470800962c17d92d8f upstream. The following error message lack the "0x" obviously: cannot mount because of unsupported optional features (4000) Add the prefix to make it less confusing. This can happen on older kernels that try to mount a filesystem with newer features so it makes sense to backport to older trees. CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Nikolay Borisov Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 83d0ed00cca80d29750572d5e6125f74911ba42c Author: Eric W. Biederman Date: Fri Apr 29 09:23:55 2022 -0500 ptrace: Reimplement PTRACE_KILL by always sending SIGKILL commit 6a2d90ba027adba528509ffa27097cffd3879257 upstream. The current implementation of PTRACE_KILL is buggy and has been for many years as it assumes it's target has stopped in ptrace_stop. At a quick skim it looks like this assumption has existed since ptrace support was added in linux v1.0. While PTRACE_KILL has been deprecated we can not remove it as a quick search with google code search reveals many existing programs calling it. When the ptracee is not stopped at ptrace_stop some fields would be set that are ignored except in ptrace_stop. Making the userspace visible behavior of PTRACE_KILL a noop in those case. As the usual rules are not obeyed it is not clear what the consequences are of calling PTRACE_KILL on a running process. Presumably userspace does not do this as it achieves nothing. Replace the implementation of PTRACE_KILL with a simple send_sig_info(SIGKILL) followed by a return 0. This changes the observable user space behavior only in that PTRACE_KILL on a process not stopped in ptrace_stop will also kill it. As that has always been the intent of the code this seems like a reasonable change. Cc: stable@vger.kernel.org Reported-by: Al Viro Suggested-by: Al Viro Tested-by: Kees Cook Reviewed-by: Oleg Nesterov Link: https://lkml.kernel.org/r/20220505182645.497868-7-ebiederm@xmission.com Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 7400a7e0a7ae1f1cd22250f0bfa1453f59a1d117 Author: Eric W. Biederman Date: Tue Apr 26 16:45:37 2022 -0500 ptrace/xtensa: Replace PT_SINGLESTEP with TIF_SINGLESTEP commit 4a3d2717d140401df7501a95e454180831a0c5af upstream. xtensa is the last user of the PT_SINGLESTEP flag. Changing tsk->ptrace in user_enable_single_step and user_disable_single_step without locking could potentiallly cause problems. So use a thread info flag instead of a flag in tsk->ptrace. Use TIF_SINGLESTEP that xtensa already had defined but unused. Remove the definitions of PT_SINGLESTEP and PT_BLOCKSTEP as they have no more users. Cc: stable@vger.kernel.org Acked-by: Max Filippov Tested-by: Kees Cook Reviewed-by: Oleg Nesterov Link: https://lkml.kernel.org/r/20220505182645.497868-4-ebiederm@xmission.com Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit e1c91672c5c835c849e329a29b2a74f8540cd102 Author: Eric W. Biederman Date: Tue Apr 26 16:30:17 2022 -0500 ptrace/um: Replace PT_DTRACE with TIF_SINGLESTEP commit c200e4bb44e80b343c09841e7caaaca0aac5e5fa upstream. User mode linux is the last user of the PT_DTRACE flag. Using the flag to indicate single stepping is a little confusing and worse changing tsk->ptrace without locking could potentionally cause problems. So use a thread info flag with a better name instead of flag in tsk->ptrace. Remove the definition PT_DTRACE as uml is the last user. Cc: stable@vger.kernel.org Acked-by: Johannes Berg Tested-by: Kees Cook Reviewed-by: Oleg Nesterov Link: https://lkml.kernel.org/r/20220505182645.497868-3-ebiederm@xmission.com Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 260650ddc864e73cacc5f2f610935d76beb4019f Author: Kristen Carlson Accardi Date: Fri May 20 10:42:47 2022 -0700 x86/sgx: Set active memcg prior to shmem allocation commit 0c9782e204d3cc5625b9e8bf4e8625d38dfe0139 upstream. When the system runs out of enclave memory, SGX can reclaim EPC pages by swapping to normal RAM. These backing pages are allocated via a per-enclave shared memory area. Since SGX allows unlimited over commit on EPC memory, the reclaimer thread can allocate a large number of backing RAM pages in response to EPC memory pressure. When the shared memory backing RAM allocation occurs during the reclaimer thread context, the shared memory is charged to the root memory control group, and the shmem usage of the enclave is not properly accounted for, making cgroups ineffective at limiting the amount of RAM an enclave can consume. For example, when using a cgroup to launch a set of test enclaves, the kernel does not properly account for 50% - 75% of shmem page allocations on average. In the worst case, when nearly all allocations occur during the reclaimer thread, the kernel accounts less than a percent of the amount of shmem used by the enclave's cgroup to the correct cgroup. SGX stores a list of mm_structs that are associated with an enclave. Pick one of them during reclaim and charge that mm's memcg with the shmem allocation. The one that gets picked is arbitrary, but this list almost always only has one mm. The cases where there is more than one mm with different memcg's are not worth considering. Create a new function - sgx_encl_alloc_backing(). This function is used whenever a new backing storage page needs to be allocated. Previously the same function was used for page allocation as well as retrieving a previously allocated page. Prior to backing page allocation, if there is a mm_struct associated with the enclave that is requesting the allocation, it is set as the active memory control group. [ dhansen: - fix merge conflict with ELDU fixes - check against actual ksgxd_tsk, not ->mm ] Cc: stable@vger.kernel.org Signed-off-by: Kristen Carlson Accardi Signed-off-by: Dave Hansen Reviewed-by: Shakeel Butt Acked-by: Roman Gushchin Link: https://lkml.kernel.org/r/20220520174248.4918-1-kristen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8765a423a87d74ef24ea02b43b2728fe4039f248 Author: Baoquan He Date: Wed Feb 23 19:32:24 2022 +0800 x86/kexec: fix memory leak of elf header buffer commit b3e34a47f98974d0844444c5121aaff123004e57 upstream. This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat. Link: https://lkml.kernel.org/r/20220223113225.63106-2-bhe@redhat.com Signed-off-by: Baoquan He Acked-by: Dave Young Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7aef4ecc315084e2cab54a307b9b40b380093498 Author: Kan Liang Date: Wed May 25 06:39:52 2022 -0700 perf/x86/intel: Fix event constraints for ICL commit 86dca369075b3e310c3c0adb0f81e513c562b5e4 upstream. According to the latest event list, the event encoding 0x55 INST_DECODED.DECODERS and 0x56 UOPS_DECODED.DEC0 are only available on the first 4 counters. Add them into the event constraints table. Fixes: 6017608936c1 ("perf/x86/intel: Add Icelake support") Signed-off-by: Kan Liang Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220525133952.1660658-1-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit cc0dd4456f9573bf8af9b4d8754433918e809e1e Author: Ammar Faizi Date: Tue Mar 29 17:47:05 2022 +0700 x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails commit e5f28623ceb103e13fc3d7bd45edf9818b227fd0 upstream. In mce_threshold_create_device(), if threshold_create_bank() fails, the previously allocated threshold banks array @bp will be leaked because the call to mce_threshold_remove_device() will not free it. This happens because mce_threshold_remove_device() fetches the pointer through the threshold_banks per-CPU variable but bp is written there only after the bank creation is successful, and not before, when threshold_create_bank() fails. Add a helper which unwinds all the bank creation work previously done and pass into it the previously allocated threshold banks array for freeing. [ bp: Massage. ] Fixes: 6458de97fc15 ("x86/mce/amd: Straighten CPU hotplug path") Co-developed-by: Alviro Iskandar Setiawan Signed-off-by: Alviro Iskandar Setiawan Co-developed-by: Yazen Ghannam Signed-off-by: Yazen Ghannam Signed-off-by: Ammar Faizi Signed-off-by: Borislav Petkov Cc: Link: https://lore.kernel.org/r/20220329104705.65256-3-ammarfaizi2@gnuweeb.org Signed-off-by: Greg Kroah-Hartman commit d9a04bc7d1b836f43bed8057fa09c7bbae4a4108 Author: Michael Niewöhner Date: Tue May 17 20:31:30 2022 +0200 platform/x86: intel-hid: fix _DSM function index handling commit 1620c80bba53af8c547bab34a1d3bc58319fe608 upstream. intel_hid_dsm_fn_mask is a bit mask containing one bit for each function index. Fix the function index check in intel_hid_evaluate_method accordingly, which was missed in commit 97ab4516205e ("platform/x86: intel-hid: fix _DSM function index handling"). Fixes: 97ab4516205e ("platform/x86: intel-hid: fix _DSM function index handling") Cc: stable@vger.kernel.org Signed-off-by: Michael Niewöhner Link: https://lore.kernel.org/r/66f813f5bcc724a0f6dd5adefe6a9728dbe509e3.camel@mniewoehner.de Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit dfe5921112cf5c7be730c88d0d46a6c8cfd13e0c Author: Mathias Nyman Date: Thu May 12 01:04:50 2022 +0300 xhci: Allow host runtime PM as default for Intel Alder Lake N xHCI commit 74f55a62c4c354f43a6d75f77dd184c4f57b9a26 upstream. Alder Lake N TCSS xHCI needs to be runtime suspended whenever possible to allow the TCSS hardware block to enter D3 and thus save energy Cc: stable@kernel.org Suggested-by: Gopal Vamshi Krishna Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20220511220450.85367-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 791f532de70dae10ae037b8c0df31d355fc27952 Author: Ronnie Sahlberg Date: Wed Jun 1 08:48:38 2022 +1000 cifs: when extending a file with falloc we should make files not-sparse commit f66f8b94e7f2f4ac9fffe710be231ca8f25c5057 upstream. as this is the only way to make sure the region is allocated. Fix the conditional that was wrong and only tried to make already non-sparse files non-sparse. Cc: stable@vger.kernel.org Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ce0008a0e410cdd95f0d8cd81b2902ec10a660c4 Author: Ronnie Sahlberg Date: Tue May 31 13:01:17 2022 +1000 cifs: fix potential double free during failed mount commit 8378a51e3f8140f60901fb27208cc7a6e47047b5 upstream. RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799 Cc: stable@vger.kernel.org Signed-off-by: Roberto Bergantinos Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d7b5577272c21614c57bb894211a232107868c98 Author: Konstantin Komarov Date: Fri Oct 22 18:15:36 2021 +0300 fs/ntfs3: Restore ntfs_xattr_get_acl and ntfs_xattr_set_acl functions commit 87e21c99bad763524c953ff4d1a61ee19038ddc2 upstream. Apparently we need to maintain these functions with ntfs_get_acl_ex and ntfs_set_acl_ex. This commit fixes xfstest generic/099 Fixes: 95dd8b2c1ed0 ("fs/ntfs3: Remove unnecessary functions") Reviewed-by: Kari Argillander Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 79f44f05e7562707eab6a8d7d2b685f5ad5d5df4 Author: Konstantin Komarov Date: Fri Oct 22 18:35:43 2021 +0300 fs/ntfs3: Update i_ctime when xattr is added commit 2d44667c306e7806848a3478820f87343feb5421 upstream. Ctime wasn't updated after setfacl command. This commit fixes xfstest generic/307 Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations") Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit d8be98ab88250dc12a98efdb703792a537b0eac3 Author: Christophe JAILLET Date: Thu Nov 11 08:45:44 2021 +0100 fs/ntfs3: Fix some memory leaks in an error handling path of 'log_replay()' commit e589f9b7078e1c0191613cd736f598e81d2390de upstream. All error handling paths lead to 'out' where many resources are freed. Do it as well here instead of a direct return, otherwise 'log', 'ra' and 'log->one_page_buf' (at least) will leak. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Signed-off-by: Christophe JAILLET Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 8bac05d61f26c04c79b8f4c7f37867e2884dfd86 Author: Konstantin Komarov Date: Wed Nov 24 15:08:19 2021 +0300 fs/ntfs3: In function ntfs_set_acl_ex do not change inode->i_mode if called from function ntfs_init_acl commit 9186d472ee780fabf74424756c4c00545166157e upstream. ntfs_init_acl sets mode. ntfs_init_acl calls ntfs_set_acl_ex. ntfs_set_acl_ex must not change this mode. Fixes xfstest generic/444 Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations") Reviewed-by: Joe Perches Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit f45bd2922d66b8195c7c22f19d918eb353cc05ef Author: Konstantin Komarov Date: Mon Oct 25 18:34:06 2021 +0300 fs/ntfs3: Check new size for limits commit 114346978cf61de02832cc3cc68432a3de70fb38 upstream. We must check size before trying to allocate. Size can be set for example by "ulimit -f". Fixes xfstest generic/228 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reviewed-by: Kari Argillander Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit dc05aa14d311aa8fd0d265d042b86dd277a411f7 Author: Konstantin Komarov Date: Fri Oct 22 17:37:52 2021 +0300 fs/ntfs3: Keep preallocated only if option prealloc enabled commit e95113ed4d428219e3395044e29f5713fc446720 upstream. If size of file was reduced, we still kept allocated blocks. This commit makes ntfs3 work as other fs like btrfs. Link: https://bugzilla.kernel.org/show_bug.cgi?id=214719 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: Ganapathi Kamath Tested-by: Ganapathi Kamath Reviewed-by: Kari Argillander Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 3eb42b847e43aba3066a0375c40cc7c5587fc375 Author: Konstantin Komarov Date: Mon Oct 25 18:31:28 2021 +0300 fs/ntfs3: Fix fiemap + fix shrink file size (to remove preallocated space) commit 3880f2b816a7e4ca889b7e8a42e6c62c5706ed36 upstream. Two problems: 1. ntfs3_setattr can't truncate preallocated space; 2. if allocated fragment "cross" valid size, then fragment splits into two parts: - normal part; - unwritten part (here we must return FIEMAP_EXTENT_LAST). Before this commit we returned FIEMAP_EXTENT_LAST for whole fragment. Fixes xfstest generic/092 Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 87e9cd4b869219a4dd65155d22c9c17af46c1e18 Author: Konstantin Komarov Date: Mon Oct 25 18:48:38 2021 +0300 fs/ntfs3: Update valid size if -EIOCBQUEUED commit 52e00ea6b26e45fb8159e3b57cdde8d3f9bdd8e9 upstream. Update valid size if write is still in I/O queue. Fixes xfstest generic/240 Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 0cebad7ee61a4442cb5b7d4fb7a71e93ff1cb4fb Author: Kishon Vijay Abraham I Date: Tue May 10 14:46:29 2022 +0530 usb: core: hcd: Add support for deferring roothub registration commit a44623d9279086c89f631201d993aa332f7c9e66 upstream. It has been observed with certain PCIe USB cards (like Inateck connected to AM64 EVM or J7200 EVM) that as soon as the primary roothub is registered, port status change is handled even before xHC is running leading to cold plug USB devices not detected. For such cases, registering both the root hubs along with the second HCD is required. Add support for deferring roothub registration in usb_add_hcd(), so that both primary and secondary roothubs are registered along with the second HCD. This patch has been added and reverted earier as it triggered a race in usb device enumeration. That race is now fixed in 5.16-rc3, and in stable back to 5.4 commit 6cca13de26ee ("usb: hub: Fix locking issues with address0_mutex") commit 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") CC: stable@vger.kernel.org # 5.4+ Suggested-by: Mathias Nyman Tested-by: Chris Chiu Acked-by: Alan Stern Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20220510091630.16564-2-kishon@ti.com Signed-off-by: Greg Kroah-Hartman commit 5a3eec6f67d37406671e54076640a554253262e0 Author: Albert Wang Date: Wed May 18 14:13:15 2022 +0800 usb: dwc3: gadget: Move null pinter check to proper place commit 3c5880745b4439ac64eccdb040e37fc1cc4c5406 upstream. When dwc3_gadget_ep_cleanup_completed_requests() called to dwc3_gadget_giveback() where the dwc3 lock is released, other thread is able to execute. In this situation, usb_ep_disable() gets the chance to clear endpoint descriptor pointer which leds to the null pointer dereference problem. So needs to move the null pointer check to a proper place. Example call stack: Thread#1: dwc3_thread_interrupt() spin_lock -> dwc3_process_event_buf() -> dwc3_process_event_entry() -> dwc3_endpoint_interrupt() -> dwc3_gadget_endpoint_trbs_complete() -> dwc3_gadget_ep_cleanup_completed_requests() ... -> dwc3_giveback() spin_unlock Thread#2 executes Thread#2: configfs_composite_disconnect() -> __composite_disconnect() -> ffs_func_disable() -> ffs_func_set_alt() -> ffs_func_eps_disable() -> usb_ep_disable() wait for dwc3 spin_lock Thread#1 released lock clear endpoint.desc Fixes: 26288448120b ("usb: dwc3: gadget: Fix null pointer exception") Cc: stable Signed-off-by: Albert Wang Link: https://lore.kernel.org/r/20220518061315.3359198-1-albertccwang@google.com Signed-off-by: Greg Kroah-Hartman commit bf2558bbdce3ab1d6bcba09f354914e4515d0a2b Author: Linus Walleij Date: Mon May 16 11:14:24 2022 +0200 usb: isp1760: Fix out-of-bounds array access commit 26ae2c942b5702f2e43d36b2a4389cfb7d616b6a upstream. Running the driver through kasan gives an interesting splat: BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c Read of size 20 at addr f1db2e64 by task swapper/0/1 (...) isp1760_register from isp1760_plat_probe+0x1d8/0x220 (...) This happens because the loop reading the regmap fields for the different ISP1760 variants look like this: for (i = 0; i < HC_FIELD_MAX; i++) { ... } Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long. However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[], isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are dynamically sized during compilation. Fix this by putting an empty assignment to the [HC_FIELD_MAX] and [DC_FIELD_MAX] array member at the end of each array. This will make the array one member longer than it needs to be, but avoids the risk of overwriting whatever is inside [HC_FIELD_MAX - 1] and is simple and intuitive to read. Also add comments explaining what is going on. Fixes: 1da9e1c06873 ("usb: isp1760: move to regmap for register access") Cc: stable@vger.kernel.org Cc: Rui Miguel Silva Cc: Dietmar Eggemann Reviewed-by: Rui Miguel Silva Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220516091424.391209-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman commit fdcb8a893aec5d32dce8ec487216fa24dc9fe760 Author: Monish Kumar R Date: Fri May 20 18:30:44 2022 +0530 USB: new quirk for Dell Gen 2 devices commit 97fa5887cf283bb75ffff5f6b2c0e71794c02400 upstream. Add USB_QUIRK_NO_LPM and USB_QUIRK_RESET_RESUME quirks for Dell usb gen 2 device to not fail during enumeration. Found this bug on own testing Signed-off-by: Monish Kumar R Cc: stable Link: https://lore.kernel.org/r/20220520130044.17303-1-monish.kumar.r@intel.com Signed-off-by: Greg Kroah-Hartman commit c2dd96835fbb8751ece5f524e03733715cf53e9d Author: Carl Yin(殷张成) Date: Thu May 19 02:34:43 2022 +0000 USB: serial: option: add Quectel BG95 modem commit 33b7af2f459df453feb0d44628d820c47fefe7a8 upstream. The BG95 modem has 3 USB configurations that are configurable via the AT command AT+QCFGEXT="usbnet",["ecm"|"modem"|"rmnet"] which make the modem enumerate with the following interfaces, respectively: "modem": Diag + GNSS + Modem + Modem "ecm" : Diag + GNSS + Modem + ECM "rmnet": Diag + GNSS + Modem + QMI Don't support Full QMI messages (e.g WDS_START_NETWORK_INTERFACE) A detailed description of the USB configuration for each mode follows: +QCFGEXT: "usbnet","modem" -------------------------- T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0700 Rev= 0.00 S: Manufacturer=Quectel, Incorporated S: Product=Quectel LPWA Module S: SerialNumber=884328a2 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +QCFGEXT: "usbnet","ecm" ------------------------ T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0700 Rev= 0.00 S: Manufacturer=Quectel, Incorporated S: Product=Quectel LPWA Module S: SerialNumber=884328a2 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 3 IfCount= 2 Cls=02(comm.) Sub=00 Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms I: If#= 4 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +QCFGEXT: "usbnet","rmnet" -------------------------- T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0700 Rev= 0.00 S: Manufacturer=Quectel, Incorporated S: Product=Quectel LPWA Module S: SerialNumber=884328a2 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Carl Yin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2514cc471b408d405d5ebd6c1d7e2a93768f61c1 Author: Johan Hovold Date: Tue May 17 18:17:36 2022 +0200 USB: serial: pl2303: fix type detection for odd device commit e82e7c6dde91acd6748d672a44dc1980ce239f86 upstream. At least one pl2303 device has a bcdUSB of 1.0.1 which most likely was was intended as 1.1. Allow bcdDevice 1.0.1 but interpret it as 1.1. Fixes: 1e9faef4d26d ("USB: serial: pl2303: fix HX type detection") Cc: stable@vger.kernel.org # 5.13 Link: https://lore.kernel.org/linux-usb/CAJixRzqf4a9-ZKZDgWxicc_BpfdZVE9qqGmkiO7xEstOXUbGvQ@mail.gmail.com Reported-by: Gary van der Merwe Link: https://lore.kernel.org/r/20220517161736.13313-1-johan@kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 11868ca21585561659c2575b0d6508ef8e9c4291 Author: Takashi Iwai Date: Wed May 25 15:12:03 2022 +0200 ALSA: usb-audio: Cancel pending work at closing a MIDI substream commit 0125de38122f0f66bf61336158d12a1aabfe6425 upstream. At closing a USB MIDI output substream, there might be still a pending work, which would eventually access the rawmidi runtime object that is being released. For fixing the race, make sure to cancel the pending work at closing. Reported-by: syzbot+6912c9592caca7ca0e7d@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/000000000000e7e75005dfd07cf6@google.com Link: https://lore.kernel.org/r/20220525131203.11299-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3e7e75378de55d605b6da2da4110ee7ce7367405 Author: Marios Levogiannis Date: Mon May 30 10:41:31 2022 +0300 ALSA: hda/realtek - Fix microphone noise on ASUS TUF B550M-PLUS commit 9bfa7b36343c7d84370bc61c9ed774635b05e4eb upstream. Set microphone pins 0x18 (rear) and 0x19 (front) to VREF_50 to fix the microphone noise on ASUS TUF B550M-PLUS which uses the ALCS1200A codec. The initial value was VREF_80. The same issue is also present on Windows using both the default Windows driver and all tested Realtek drivers before version 6.0.9049.1. Comparing Realtek driver 6.0.9049.1 (the first one without the microphone noise) to Realtek driver 6.0.9047.1 (the last one with the microphone noise) revealed that the fix is the result of setting pins 0x18 and 0x19 to VREF_50. This fix may also work for other boards that have been reported to have the same microphone issue and use the ALC1150 and ALCS1200A codecs, since these codecs are similar and the fix in the Realtek driver on Windows is common for both. However, it is currently enabled only for ASUS TUF B550M-PLUS as this is the only board that could be tested. Signed-off-by: Marios Levogiannis Cc: Link: https://lore.kernel.org/r/20220530074131.12258-1-marios.levogiannis@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 99137afd8445ee99fca8418aca3b885f9bebebff Author: Rik van der Kemp Date: Fri May 27 14:07:26 2022 +0200 ALSA: hda/realtek: Enable 4-speaker output for Dell XPS 15 9520 laptop commit 15dad62f4bdb5dc0f0efde8181d680db9963544c upstream. The 2022-model XPS 15 appears to use the same 4-speakers-on-ALC289 audio setup as the Dell XPS 15 9510, so requires the same quirk to enable woofer output. Tested on my own 9520. [ Move the entry to the right position in the SSID order -- tiwai ] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216035 Cc: Signed-off-by: Rik van der Kemp Link: https://lore.kernel.org/r/181056a137b.d14baf90133058.8425453735588429828@upto11.nl Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0e06c3b43ddc4b5011d935f8ee68abb7f134a9c2 Author: Kailang Yang Date: Tue May 24 16:14:04 2022 +0800 ALSA: hda/realtek - Add new type for ALC245 commit 60571929d06b028800f27b51a7c81de1144944cf upstream. Add new type for ALC245. Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/cef26a7cd3d146eb96a3994ce79e34d2@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7b50d7cc2895cdf017a8f686a5c1a587a4c4be98 Author: Nathan Chancellor Date: Mon May 16 14:45:21 2022 -0700 riscv: Move alternative length validation into subsection commit 61114e734ccb804bc12561ab4020745e02c468c2 upstream. After commit 49b290e430d3 ("riscv: prevent compressed instructions in alternatives"), builds with LLVM's integrated assembler fail: In file included from arch/riscv/mm/init.c:10: In file included from ./include/linux/mm.h:29: In file included from ./include/linux/pgtable.h:6: In file included from ./arch/riscv/include/asm/pgtable.h:108: ./arch/riscv/include/asm/tlbflush.h:23:2: error: expected assembly-time absolute expression ALT_FLUSH_TLB_PAGE(__asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory")); ^ ./arch/riscv/include/asm/errata_list.h:33:5: note: expanded from macro 'ALT_FLUSH_TLB_PAGE' asm(ALTERNATIVE("sfence.vma %0", "sfence.vma", SIFIVE_VENDOR_ID, \ ^ ./arch/riscv/include/asm/alternative-macros.h:187:2: note: expanded from macro 'ALTERNATIVE' _ALTERNATIVE_CFG(old_content, new_content, vendor_id, errata_id, CONFIG_k) ^ ./arch/riscv/include/asm/alternative-macros.h:113:2: note: expanded from macro '_ALTERNATIVE_CFG' __ALTERNATIVE_CFG(old_c, new_c, vendor_id, errata_id, IS_ENABLED(CONFIG_k)) ^ ./arch/riscv/include/asm/alternative-macros.h:110:2: note: expanded from macro '__ALTERNATIVE_CFG' ALT_NEW_CONTENT(vendor_id, errata_id, enable, new_c) ^ ./arch/riscv/include/asm/alternative-macros.h:99:3: note: expanded from macro 'ALT_NEW_CONTENT' ".org . - (889b - 888b) + (887b - 886b)\n" \ ^ :26:6: note: instantiated into assembly here .org . - (889b - 888b) + (887b - 886b) ^ This error happens because LLVM's integrated assembler has a one-pass design, which means it cannot figure out the instruction lengths when the .org directive is outside of the subsection that contains the instructions, which was changed by the .option directives added by the above change. Move the .org directives before the .previous directive so that these directives are always within the same subsection, which resolves the failures and does not introduce any new issues with GNU as. This was done for arm64 in commit 966a0acce2fc ("arm64/alternatives: move length validation inside the subsection") and commit 22315a2296f4 ("arm64: alternatives: Move length validation in alternative_{insn, endif}"). While there is no error from the assembly versions of the macro, they appear to have the same problem so just make the same change there as well so that there are no problems in the future. Link: https://github.com/ClangBuiltLinux/linux/issues/1640 Reported-by: kernel test robot Signed-off-by: Nathan Chancellor Reviewed-by: Heiko Stuebner Tested-by: Heiko Stuebner Link: https://lore.kernel.org/r/20220516214520.3252074-1-nathan@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit c64d777c91e013311a690db24de95b7cd0ffebb6 Author: Tobias Klauser Date: Thu May 5 10:18:15 2022 +0200 riscv: Wire up memfd_secret in UAPI header commit 02d88b40cb2e9614e0117c3385afdce878f0d377 upstream. Move the __ARCH_WANT_MEMFD_SECRET define added in commit 7bb7f2ac24a0 ("arch, mm: wire up memfd_secret system call where relevant") to so __NR_memfd_secret is defined when including in userspace. This allows the memfd_secret selftest to pass on riscv. Signed-off-by: Tobias Klauser Link: https://lore.kernel.org/r/20220505081815.22808-1-tklauser@distanz.ch Fixes: 7bb7f2ac24a0 ("arch, mm: wire up memfd_secret system call where relevant") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 0179777e29d4c20db8aba3e56d90c79d089aa6ed Author: Samuel Holland Date: Fri Apr 29 22:00:23 2022 -0500 riscv: Fix irq_work when SMP is disabled commit 2273272823db6f67d57761df8116ae32e7f05bed upstream. irq_work is triggered via an IPI, but the IPI infrastructure is not included in uniprocessor kernels. As a result, irq_work never runs. Fall back to the tick-based irq_work implementation on uniprocessor configurations. Fixes: 298447928bb1 ("riscv: Support irq_work via self IPIs") Signed-off-by: Samuel Holland Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20220430030025.58405-1-samuel@sholland.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 1b1dfd94b2a520a84732ba4a3be719917b5fb29a Author: Alexandre Ghiti Date: Mon Dec 6 11:46:56 2021 +0100 riscv: Initialize thread pointer before calling C functions commit 35d33c76d68dfacc330a8eb477b51cc647c5a847 upstream. Because of the stack canary feature that reads from the current task structure the stack canary value, the thread pointer register "tp" must be set before calling any C function from head.S: by chance, setup_vm and all the functions that it calls does not seem to be part of the functions where the canary check is done, but in the following commits, some functions will. Fixes: f2c9699f65557a31 ("riscv: Add STACKPROTECTOR supported") Signed-off-by: Alexandre Ghiti Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 87fd2d27c9ead8fc0764acdbd3ab5dd105d5800a Author: Xianting Tian Date: Wed May 18 09:34:28 2022 +0800 RISC-V: Mark IORESOURCE_EXCLUSIVE for reserved mem instead of IORESOURCE_BUSY commit e61bf5c071148c80d091f8e7220b3b9130780ae3 upstream. Commit 00ab027a3b82 ("RISC-V: Add kernel image sections to the resource tree") marked IORESOURCE_BUSY for reserved memory, which caused resource map failed in subsequent operations of related driver, so remove the IORESOURCE_BUSY flag. In order to prohibit userland mapping reserved memory, mark IORESOURCE_EXCLUSIVE for it. The code to reproduce the issue, dts: mem0: memory@a0000000 { reg = <0x0 0xa0000000 0 0x1000000>; no-map; }; &test { status = "okay"; memory-region = <&mem0>; }; code: np = of_parse_phandle(pdev->dev.of_node, "memory-region", 0); ret = of_address_to_resource(np, 0, &r); base = devm_ioremap_resource(&pdev->dev, &r); // base = -EBUSY Fixes: 00ab027a3b82 ("RISC-V: Add kernel image sections to the resource tree") Reported-by: Huaming Jiang Reviewed-by: Guo Ren Reviewed-by: Heiko Stuebner Tested-by: Heiko Stuebner Co-developed-by: Nick Kossifidis Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/20220518013428.1338983-1-xianting.tian@linux.alibaba.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit e639a66ca9b846557dcf90823db99cc858d76e80 Author: Helge Deller Date: Thu Jun 2 13:55:26 2022 +0200 parisc/stifb: Keep track of hardware path of graphics card commit b046f984814af7985f444150ec28716d42d00d9a upstream. Keep the pa_path (hardware path) of the graphics card in sti_struct and use this info to give more useful info which card is currently being used. Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Greg Kroah-Hartman commit 8b8fe78cae1d09229f544f4129b8c87ca7a8f367 Author: Helge Deller Date: Thu Jun 2 13:50:44 2022 +0200 parisc/stifb: Implement fb_is_primary_device() commit cf936af790a3ef5f41ff687ec91bfbffee141278 upstream. Implement fb_is_primary_device() function, so that fbcon detects if this framebuffer belongs to the default graphics card which was used to start the system. Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Greg Kroah-Hartman commit fced6c0622da59939832d7b72e61e6e95925330a Author: Niklas Cassel Date: Thu Apr 14 11:10:18 2022 +0200 binfmt_flat: do not stop relocating GOT entries prematurely on riscv commit 6045ab5fea4c849153ebeb0acb532da5f29d69c4 upstream. bFLT binaries are usually created using elf2flt. The linker script used by elf2flt has defined the .data section like the following for the last 19 years: .data : { _sdata = . ; __data_start = . ; data_start = . ; *(.got.plt) *(.got) FILL(0) ; . = ALIGN(0x20) ; LONG(-1) . = ALIGN(0x20) ; ... } It places the .got.plt input section before the .got input section. The same is true for the default linker script (ld --verbose) on most architectures except x86/x86-64. The binfmt_flat loader should relocate all GOT entries until it encounters a -1 (the LONG(-1) in the linker script). The problem is that the .got.plt input section starts with a GOTPLT header (which has size 16 bytes on elf64-riscv and 8 bytes on elf32-riscv), where the first word is set to -1. See the binutils implementation for riscv [1]. This causes the binfmt_flat loader to stop relocating GOT entries prematurely and thus causes the application to crash when running. Fix this by skipping the whole GOTPLT header, since the whole GOTPLT header is reserved for the dynamic linker. The GOTPLT header will only be skipped for bFLT binaries with flag FLAT_FLAG_GOTPIC set. This flag is unconditionally set by elf2flt if the supplied ELF binary has the symbol _GLOBAL_OFFSET_TABLE_ defined. ELF binaries without a .got input section should thus remain unaffected. Tested on RISC-V Canaan Kendryte K210 and RISC-V QEMU nommu_virt_defconfig. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elfnn-riscv.c;hb=binutils-2_38#l3275 Cc: Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20220414091018.896737-1-niklas.cassel@wdc.com Fixed-by: kernel test robot Link: https://lore.kernel.org/lkml/202204182333.OIUOotK8-lkp@intel.com Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman