June 2023 - Linux-stable-mirror

Re: [6.3.y 6.1.y 5.15.y] drm/amd/display: fix the system hang while disable PSR

by Thomas Backlund

Den 2023-06-20 kl. 00:16, skrev Limonciello, Mario: > Hi, > > ea2062dd1f03 ("drm/amd/display: fix the system hang while disable PSR") > was tagged for stable, but failed to apply to 6.3.y, 6.1.y and 5.15.y. > > I've looked into the missing dependencies, and here are the dependencies > needed for the stable backport: > > 5.15.y: > ------- > 97ca308925a5 ("drm/amd/display: Add minimal pipe split transition state") > f7511289821f ("drm/amd/display: Use dc_update_planes_and_stream") > 81f743a08f3b ("drm/amd/display: Add wrapper to call planes and stream > update") > ea2062dd1f03 ("drm/amd/display: fix the system hang while disable PSR") > > 6.1.y / 6.3.y > ------------- > ea2062dd1f03 ("drm/amd/display: fix the system hang while disable PSR") > f7511289821f ("drm/amd/display: Use dc_update_planes_and_stream") > 81f743a08f3b ("drm/amd/display: Add wrapper to call planes and stream > update") > ea2062dd1f03 ("drm/amd/display: fix the system hang while disable PSR") > Is there something missing in that series ? We get a report of those patches on top of 6.3.9 failing on AMD STONEY (0x1002:0x98E4 0x1043:0x1FE0 0xEA) with: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1248 at drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:393 dce_aux_transfer_raw+0x731/0x760 [amdgpu] Modules linked in: rfcomm ip6t_REJECT nf_reject_ipv6 xt_comment ip6table_mangle ip6table_nat ip6table_raw ip6table_filter ip6_tables xt_recent ipt_IFWLOG ipt_psd xt_set ip_set_hash_ip ip_set ipt_REJECT nf_reject_ipv4 xt_conntrack xt_hashlimit xt_addrtype xt_mark iptable_mangle iptable_nat xt_CT xt_tcpudp iptable_raw xt_NFLOG nfnetlink_log xt_LOG nf_log_syslog nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_nat nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ccm af_packet qrtr cmac algif_hash algif_skcipher af_alg bnep nls_iso8859_1 nls_cp437 vfat fat dm_mirror dm_region_hash dm_log rtl8723be btcoexist rtl8723_common rtl_pci rtlwifi mac80211 uvcvideo uvc cfg80211 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 kvm_amd btusb btmtk btrtl btbcm btintel ccp kvm videodev bluetooth snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi videobuf2_common asus_nb_wmi mc ecdh_generic ecc snd_hda_codec asus_wmi ledtrig_audio sparse_keymap platform_profile irqbypass wmi_bmof sha1_generic r8169 rfkill libarc4 realtek i2c_piix4 mdio_devres snd_hda_core tpm_crb snd_hwdep libphy snd_pcm snd_timer snd fam15h_power k10temp soundcore tpm_tis tpm_tis_core tpm asus_wireless acpi_cpufreq input_leds joydev evdev sch_fq_codel fuse dm_mod loop configfs efivarfs dmi_sysfs ip_tables x_tables ipv6 crc_ccitt autofs4 sdhci_pci crc32_pclmul crc32c_intel polyval_clmulni cqhci sdhci polyval_generic gf128mul mmc_core xhci_pci xhci_pci_renesas xhci_hcd atkbd ghash_clmulni_intel vivaldi_fmap sha512_ssse3 aesni_intel crypto_simd cryptd serio_raw ehci_pci ehci_hcd sp5100_tco amdgpu i2c_algo_bit drm_ttm_helper ttm iommu_v2 drm_buddy gpu_sched drm_display_helper drm_kms_helper video hid_multitouch drm wmi i2c_hid_acpi i2c_hid 8250_dw cec CPU: 1 PID: 1248 Comm: Xorg Not tainted 6.3.9-desktop-1.mga9 #1 Hardware name: ASUSTeK COMPUTER INC. X441BA/X441BA, BIOS X441BA.310 02/25/2020 RIP: 0010:dce_aux_transfer_raw+0x731/0x760 [amdgpu] Code: 4c 10 00 8b 54 24 0c 89 e8 83 c5 01 41 88 14 04 3b 6c 24 04 72 c9 e9 3e fd ff ff 3c 01 19 c0 83 e0 c0 83 c0 50 e9 72 f9 ff ff <0f> 0b b8 03 00 00 00 e9 77 ff ff ff b8 03 00 00 00 e9 6d ff ff ff RSP: 0018:ffffa52801b8ba48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff934801cdec80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 00000000000098e4 RDI: ffff93480c700000 RBP: ffffa52801b8bac0 R08: 0000000000000000 R09: 000000000000000a R10: 0000000000000001 R11: ffff93480c700010 R12: ffffa52801b8babc R13: 0000000000000000 R14: 0000000000000000 R15: ffff934803816a30 FS: 00007f0dd47f82c0(0000) GS:ffff93480dc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f298f3620d0 CR3: 0000000104d00000 CR4: 00000000001506e0 Call Trace: <TASK> ? dce_aux_transfer_raw+0x731/0x760 [amdgpu] ? __warn+0x7d/0x130 ? dce_aux_transfer_raw+0x731/0x760 [amdgpu] ? report_bug+0x16d/0x1a0 ? handle_bug+0x41/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? dce_aux_transfer_raw+0x731/0x760 [amdgpu] dm_dp_aux_transfer+0xa1/0x160 [amdgpu] drm_dp_dpcd_access+0xad/0x130 [drm_display_helper] drm_dp_dpcd_probe+0x3a/0xf0 [drm_display_helper] drm_dp_dpcd_read+0xbf/0x100 [drm_display_helper] dm_helpers_dp_read_dpcd+0x28/0x50 [amdgpu] amdgpu_dm_update_freesync_caps+0x17b/0x360 [amdgpu] amdgpu_dm_connector_get_modes+0x242/0x4f0 [amdgpu] drm_helper_probe_single_connector_modes+0x18c/0x520 [drm_kms_helper] drm_mode_getconnector+0x390/0x4a0 [drm] ? ____sys_recvmsg+0xdd/0x1a0 ? __pfx_drm_mode_getconnector+0x10/0x10 [drm] drm_ioctl_kernel+0xc1/0x160 [drm] drm_ioctl+0x24c/0x490 [drm] ? __pfx_drm_mode_getconnector+0x10/0x10 [drm] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu] __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f0dd3f68e68 Code: 00 00 48 8d 44 24 08 48 89 54 24 e0 48 89 44 24 c0 48 8d 44 24 d0 48 89 44 24 c8 b8 10 00 00 00 c7 44 24 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 07 89 d0 c3 0f 1f 40 00 48 8b 15 71 ef 0c RSP: 002b:00007ffe6fb5b398 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000009a5ce0 RCX: 00007f0dd3f68e68 RDX: 00007ffe6fb5b3e0 RSI: 00000000c05064a7 RDI: 0000000000000010 RBP: 00007ffe6fb5b3e0 R08: 0000000000000007 R09: 0000000000bea1c0 R10: 0000000000000003 R11: 0000000000000246 R12: 00000000c05064a7 R13: 0000000000000010 R14: 00000000c05064a7 R15: 00007ffe6fb5b3e0 </TASK> ---[ end trace 0000000000000000 ]--- reverting them from the 6.3.9 build is confirmed to fix the issue. here is full boot journals with working 6.3.8 and failing 6.3.9 with those patches applied: https://bugs.mageia.org/attachment.cgi?id=13888 -- Thomas

2 years, 5 months

2
1
0 0

[PATCH v2 0/2] arm64/signal: Fix handling of TPIDR2

by Mark Brown

The restoring of TPIDR2 signal context has been broken since it was merged, fix this and add a test case covering it. This is a result of TPIDR2 context management following a different flow to any of the other state that we provide and the fact that we don't expose TPIDR (which follows the same pattern) to signals. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v2: - Added a feature check for SME to the new test. - Link to v1: https://lore.kernel.org/r/20230621-arm64-fix-tpidr2-signal-restore-v1-0-b6d… --- Mark Brown (2): arm64/signal: Restore TPIDR2 register rather than memory state kselftest/arm64: Add a test case for TPIDR2 restore arch/arm64/kernel/signal.c | 2 +- tools/testing/selftests/arm64/signal/.gitignore | 2 +- .../arm64/signal/testcases/tpidr2_restore.c | 86 ++++++++++++++++++++++ 3 files changed, 88 insertions(+), 2 deletions(-) --- base-commit: 858fd168a95c5b9669aac8db6c14a9aeab446375 change-id: 20230621-arm64-fix-tpidr2-signal-restore-713d93798f99 Best regards, -- Mark Brown <broonie(a)kernel.org>

2 years, 5 months

2
6
0 0

[PATCH V2 net] net: mana: Fix MANA VF unload when host is unresponsive

by souradeep chakrabarti

From: Souradeep Chakrabarti <schakrabarti(a)linux.microsoft.com> This patch addresses the VF unload issue, where mana_dealloc_queues() gets stuck in infinite while loop, because of host unresponsiveness. It adds a timeout in the while loop, to fix it. Also this patch adds a new attribute in mana_context, which gets set when mana_hwc_send_request() hits a timeout because of host unresponsiveness. This flag then helps to avoid the timeouts in successive calls. Signed-off-by: Souradeep Chakrabarti <schakrabarti(a)linux.microsoft.com> --- V1 -> V2: * Added net branch * Removed the typecasting to (struct mana_context*) of void pointer * Repositioned timeout variable in mana_dealloc_queues() * Repositioned vf_unload_timeout in mana_context struct, to utilise the 6 bytes hole --- .../net/ethernet/microsoft/mana/gdma_main.c | 4 +++- .../net/ethernet/microsoft/mana/hw_channel.c | 12 ++++++++++- drivers/net/ethernet/microsoft/mana/mana_en.c | 21 +++++++++++++++++-- include/net/mana/mana.h | 2 ++ 4 files changed, 35 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c index 8f3f78b68592..6411f01be0d9 100644 --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c @@ -946,10 +946,12 @@ int mana_gd_deregister_device(struct gdma_dev *gd) struct gdma_context *gc = gd->gdma_context; struct gdma_general_resp resp = {}; struct gdma_general_req req = {}; + struct mana_context *ac; int err; if (gd->pdid == INVALID_PDID) return -EINVAL; + ac = gd->driver_data; mana_gd_init_req_hdr(&req.hdr, GDMA_DEREGISTER_DEVICE, sizeof(req), sizeof(resp)); @@ -957,7 +959,7 @@ int mana_gd_deregister_device(struct gdma_dev *gd) req.hdr.dev_id = gd->dev_id; err = mana_gd_send_request(gc, sizeof(req), &req, sizeof(resp), &resp); - if (err || resp.hdr.status) { + if ((err || resp.hdr.status) && !ac->vf_unload_timeout) { dev_err(gc->dev, "Failed to deregister device: %d, 0x%x\n", err, resp.hdr.status); if (!err) diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c index 9d1507eba5b9..492cb2c6e2cb 100644 --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c @@ -1,8 +1,10 @@ // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause /* Copyright (c) 2021, Microsoft Corporation. */ +#include "asm-generic/errno.h" #include <net/mana/gdma.h> #include <net/mana/hw_channel.h> +#include <net/mana/mana.h> static int mana_hwc_get_msg_index(struct hw_channel_context *hwc, u16 *msg_id) { @@ -786,12 +788,19 @@ int mana_hwc_send_request(struct hw_channel_context *hwc, u32 req_len, struct hwc_wq *txq = hwc->txq; struct gdma_req_hdr *req_msg; struct hwc_caller_ctx *ctx; + struct mana_context *ac; u32 dest_vrcq = 0; u32 dest_vrq = 0; u16 msg_id; int err; mana_hwc_get_msg_index(hwc, &msg_id); + ac = hwc->gdma_dev->driver_data; + if (ac->vf_unload_timeout) { + dev_err(hwc->dev, "HWC: vport is already unloaded.\n"); + err = -ETIMEDOUT; + goto out; + } tx_wr = &txq->msg_buf->reqs[msg_id]; @@ -825,9 +834,10 @@ int mana_hwc_send_request(struct hw_channel_context *hwc, u32 req_len, goto out; } - if (!wait_for_completion_timeout(&ctx->comp_event, 30 * HZ)) { + if (!wait_for_completion_timeout(&ctx->comp_event, 5 * HZ)) { dev_err(hwc->dev, "HWC: Request timed out!\n"); err = -ETIMEDOUT; + ac->vf_unload_timeout = true; goto out; } diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index d907727c7b7a..cb2080b3a00c 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -2329,7 +2329,10 @@ static int mana_dealloc_queues(struct net_device *ndev) { struct mana_port_context *apc = netdev_priv(ndev); struct gdma_dev *gd = apc->ac->gdma_dev; + unsigned long timeout; struct mana_txq *txq; + struct sk_buff *skb; + struct mana_cq *cq; int i, err; if (apc->port_is_up) @@ -2348,13 +2351,26 @@ static int mana_dealloc_queues(struct net_device *ndev) * * Drain all the in-flight TX packets */ + + timeout = jiffies + 120 * HZ; for (i = 0; i < apc->num_queues; i++) { txq = &apc->tx_qp[i].txq; - - while (atomic_read(&txq->pending_sends) > 0) + while (atomic_read(&txq->pending_sends) > 0 && + time_before(jiffies, timeout)) { usleep_range(1000, 2000); + } } + for (i = 0; i < apc->num_queues; i++) { + txq = &apc->tx_qp[i].txq; + cq = &apc->tx_qp[i].tx_cq; + while (atomic_read(&txq->pending_sends)) { + skb = skb_dequeue(&txq->pending_skbs); + mana_unmap_skb(skb, apc); + napi_consume_skb(skb, cq->budget); + atomic_sub(1, &txq->pending_sends); + } + } /* We're 100% sure the queues can no longer be woken up, because * we're sure now mana_poll_tx_cq() can't be running. */ @@ -2605,6 +2621,7 @@ int mana_probe(struct gdma_dev *gd, bool resuming) } } + ac->vf_unload_timeout = false; err = add_adev(gd); out: if (err) diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h index 9eef19972845..5f5affdca1eb 100644 --- a/include/net/mana/mana.h +++ b/include/net/mana/mana.h @@ -358,6 +358,8 @@ struct mana_context { u16 num_ports; + bool vf_unload_timeout; + struct mana_eq *eqs; struct net_device *ports[MAX_PORTS_IN_MANA_DEV]; -- 2.34.1

2 years, 5 months

4
3
0 0

FAILED: patch "[PATCH] writeback: fix dereferencing NULL mapping->host on" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 54abe19e00cfcc5a72773d15cd00ed19ab763439 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062330-bulb-sadden-dffe@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 54abe19e00cfcc5a72773d15cd00ed19ab763439 Mon Sep 17 00:00:00 2001 From: Rafael Aquini <aquini(a)redhat.com> Date: Tue, 6 Jun 2023 19:36:13 -0400 Subject: [PATCH] writeback: fix dereferencing NULL mapping->host on writeback_page_template When commit 19343b5bdd16 ("mm/page-writeback: introduce tracepoint for wait_on_page_writeback()") repurposed the writeback_dirty_page trace event as a template to create its new wait_on_page_writeback trace event, it ended up opening a window to NULL pointer dereference crashes due to the (infrequent) occurrence of a race where an access to a page in the swap-cache happens concurrently with the moment this page is being written to disk and the tracepoint is enabled: BUG: kernel NULL pointer dereference, address: 0000000000000040 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000010ec0a067 P4D 800000010ec0a067 PUD 102353067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1320 Comm: shmem-worker Kdump: loaded Not tainted 6.4.0-rc5+ #13 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230301gitf80f052277c8-1.fc37 03/01/2023 RIP: 0010:trace_event_raw_event_writeback_folio_template+0x76/0xf0 Code: 4d 85 e4 74 5c 49 8b 3c 24 e8 06 98 ee ff 48 89 c7 e8 9e 8b ee ff ba 20 00 00 00 48 89 ef 48 89 c6 e8 fe d4 1a 00 49 8b 04 24 <48> 8b 40 40 48 89 43 28 49 8b 45 20 48 89 e7 48 89 43 30 e8 a2 4d RSP: 0000:ffffaad580b6fb60 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff90e38035c01c RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff90e38035c044 RBP: ffff90e38035c024 R08: 0000000000000002 R09: 0000000000000006 R10: ffff90e38035c02e R11: 0000000000000020 R12: ffff90e380bac000 R13: ffffe3a7456d9200 R14: 0000000000001b81 R15: ffffe3a7456d9200 FS: 00007f2e4e8a15c0(0000) GS:ffff90e3fbc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000040 CR3: 00000001150c6003 CR4: 0000000000170ee0 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x76/0x170 ? kernelmode_fixup_or_oops+0x84/0x110 ? exc_page_fault+0x65/0x150 ? asm_exc_page_fault+0x22/0x30 ? trace_event_raw_event_writeback_folio_template+0x76/0xf0 folio_wait_writeback+0x6b/0x80 shmem_swapin_folio+0x24a/0x500 ? filemap_get_entry+0xe3/0x140 shmem_get_folio_gfp+0x36e/0x7c0 ? find_busiest_group+0x43/0x1a0 shmem_fault+0x76/0x2a0 ? __update_load_avg_cfs_rq+0x281/0x2f0 __do_fault+0x33/0x130 do_read_fault+0x118/0x160 do_pte_missing+0x1ed/0x2a0 __handle_mm_fault+0x566/0x630 handle_mm_fault+0x91/0x210 do_user_addr_fault+0x22c/0x740 exc_page_fault+0x65/0x150 asm_exc_page_fault+0x22/0x30 This problem arises from the fact that the repurposed writeback_dirty_page trace event code was written assuming that every pointer to mapping (struct address_space) would come from a file-mapped page-cache object, thus mapping->host would always be populated, and that was a valid case before commit 19343b5bdd16. The swap-cache address space (swapper_spaces), however, doesn't populate its ->host (struct inode) pointer, thus leading to the crashes in the corner-case aforementioned. commit 19343b5bdd16 ended up breaking the assignment of __entry->name and __entry->ino for the wait_on_page_writeback tracepoint -- both dependent on mapping->host carrying a pointer to a valid inode. The assignment of __entry->name was fixed by commit 68f23b89067f ("memcg: fix a crash in wb_workfn when a device disappears"), and this commit fixes the remaining case, for __entry->ino. Link: https://lkml.kernel.org/r/20230606233613.1290819-1-aquini@redhat.com Fixes: 19343b5bdd16 ("mm/page-writeback: introduce tracepoint for wait_on_page_writeback()") Signed-off-by: Rafael Aquini <aquini(a)redhat.com> Reviewed-by: Yafang Shao <laoar.shao(a)gmail.com> Cc: Aristeu Rozanski <aris(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/include/trace/events/writeback.h b/include/trace/events/writeback.h index 86b2a82da546..54e353c9f919 100644 --- a/include/trace/events/writeback.h +++ b/include/trace/events/writeback.h @@ -68,7 +68,7 @@ DECLARE_EVENT_CLASS(writeback_folio_template, strscpy_pad(__entry->name, bdi_dev_name(mapping ? inode_to_bdi(mapping->host) : NULL), 32); - __entry->ino = mapping ? mapping->host->i_ino : 0; + __entry->ino = (mapping && mapping->host) ? mapping->host->i_ino : 0; __entry->index = folio->index; ),

2 years, 5 months

2
1
0 0

[PATCH 1/2] mtd: spinand: toshiba: Fix ecc_get_status

by Olivier Maignial

Reading ECC status is failing. tx58cxgxsxraix_ecc_get_status() is using on-stack buffer for SPINAND_GET_FEATURE_OP() output. It is not suitable for DMA needs of spi-mem. Fix this by using the spi-mem operations dedicated buffer spinand->scratchbuf. See spinand->scratchbuf: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/inc… spi_mem_check_op(): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… Fixes: 10949af1681d Cc: stable(a)vger.kernel.org Signed-off-by: Olivier Maignial <olivier.maignial(a)hotmail.fr> --- drivers/mtd/nand/spi/toshiba.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/spi/toshiba.c b/drivers/mtd/nand/spi/toshiba.c index 7380b1ebaccd..a80427c13121 100644 --- a/drivers/mtd/nand/spi/toshiba.c +++ b/drivers/mtd/nand/spi/toshiba.c @@ -73,7 +73,7 @@ static int tx58cxgxsxraix_ecc_get_status(struct spinand_device *spinand, { struct nand_device *nand = spinand_to_nand(spinand); u8 mbf = 0; - struct spi_mem_op op = SPINAND_GET_FEATURE_OP(0x30, &mbf); + struct spi_mem_op op = SPINAND_GET_FEATURE_OP(0x30, spinand->scratchbuf); switch (status & STATUS_ECC_MASK) { case STATUS_ECC_NO_BITFLIPS: @@ -92,7 +92,7 @@ static int tx58cxgxsxraix_ecc_get_status(struct spinand_device *spinand, if (spi_mem_exec_op(spinand->spimem, &op)) return nanddev_get_ecc_conf(nand)->strength; - mbf >>= 4; + mbf = *(spinand->scratchbuf) >> 4; if (WARN_ON(mbf > nanddev_get_ecc_conf(nand)->strength || !mbf)) return nanddev_get_ecc_conf(nand)->strength; -- 2.34.1

2 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] writeback: fix dereferencing NULL mapping->host on" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 54abe19e00cfcc5a72773d15cd00ed19ab763439 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062333-security-reenact-e4a6@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 54abe19e00cfcc5a72773d15cd00ed19ab763439 Mon Sep 17 00:00:00 2001 From: Rafael Aquini <aquini(a)redhat.com> Date: Tue, 6 Jun 2023 19:36:13 -0400 Subject: [PATCH] writeback: fix dereferencing NULL mapping->host on writeback_page_template When commit 19343b5bdd16 ("mm/page-writeback: introduce tracepoint for wait_on_page_writeback()") repurposed the writeback_dirty_page trace event as a template to create its new wait_on_page_writeback trace event, it ended up opening a window to NULL pointer dereference crashes due to the (infrequent) occurrence of a race where an access to a page in the swap-cache happens concurrently with the moment this page is being written to disk and the tracepoint is enabled: BUG: kernel NULL pointer dereference, address: 0000000000000040 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000010ec0a067 P4D 800000010ec0a067 PUD 102353067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1320 Comm: shmem-worker Kdump: loaded Not tainted 6.4.0-rc5+ #13 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230301gitf80f052277c8-1.fc37 03/01/2023 RIP: 0010:trace_event_raw_event_writeback_folio_template+0x76/0xf0 Code: 4d 85 e4 74 5c 49 8b 3c 24 e8 06 98 ee ff 48 89 c7 e8 9e 8b ee ff ba 20 00 00 00 48 89 ef 48 89 c6 e8 fe d4 1a 00 49 8b 04 24 <48> 8b 40 40 48 89 43 28 49 8b 45 20 48 89 e7 48 89 43 30 e8 a2 4d RSP: 0000:ffffaad580b6fb60 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff90e38035c01c RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff90e38035c044 RBP: ffff90e38035c024 R08: 0000000000000002 R09: 0000000000000006 R10: ffff90e38035c02e R11: 0000000000000020 R12: ffff90e380bac000 R13: ffffe3a7456d9200 R14: 0000000000001b81 R15: ffffe3a7456d9200 FS: 00007f2e4e8a15c0(0000) GS:ffff90e3fbc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000040 CR3: 00000001150c6003 CR4: 0000000000170ee0 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x76/0x170 ? kernelmode_fixup_or_oops+0x84/0x110 ? exc_page_fault+0x65/0x150 ? asm_exc_page_fault+0x22/0x30 ? trace_event_raw_event_writeback_folio_template+0x76/0xf0 folio_wait_writeback+0x6b/0x80 shmem_swapin_folio+0x24a/0x500 ? filemap_get_entry+0xe3/0x140 shmem_get_folio_gfp+0x36e/0x7c0 ? find_busiest_group+0x43/0x1a0 shmem_fault+0x76/0x2a0 ? __update_load_avg_cfs_rq+0x281/0x2f0 __do_fault+0x33/0x130 do_read_fault+0x118/0x160 do_pte_missing+0x1ed/0x2a0 __handle_mm_fault+0x566/0x630 handle_mm_fault+0x91/0x210 do_user_addr_fault+0x22c/0x740 exc_page_fault+0x65/0x150 asm_exc_page_fault+0x22/0x30 This problem arises from the fact that the repurposed writeback_dirty_page trace event code was written assuming that every pointer to mapping (struct address_space) would come from a file-mapped page-cache object, thus mapping->host would always be populated, and that was a valid case before commit 19343b5bdd16. The swap-cache address space (swapper_spaces), however, doesn't populate its ->host (struct inode) pointer, thus leading to the crashes in the corner-case aforementioned. commit 19343b5bdd16 ended up breaking the assignment of __entry->name and __entry->ino for the wait_on_page_writeback tracepoint -- both dependent on mapping->host carrying a pointer to a valid inode. The assignment of __entry->name was fixed by commit 68f23b89067f ("memcg: fix a crash in wb_workfn when a device disappears"), and this commit fixes the remaining case, for __entry->ino. Link: https://lkml.kernel.org/r/20230606233613.1290819-1-aquini@redhat.com Fixes: 19343b5bdd16 ("mm/page-writeback: introduce tracepoint for wait_on_page_writeback()") Signed-off-by: Rafael Aquini <aquini(a)redhat.com> Reviewed-by: Yafang Shao <laoar.shao(a)gmail.com> Cc: Aristeu Rozanski <aris(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/include/trace/events/writeback.h b/include/trace/events/writeback.h index 86b2a82da546..54e353c9f919 100644 --- a/include/trace/events/writeback.h +++ b/include/trace/events/writeback.h @@ -68,7 +68,7 @@ DECLARE_EVENT_CLASS(writeback_folio_template, strscpy_pad(__entry->name, bdi_dev_name(mapping ? inode_to_bdi(mapping->host) : NULL), 32); - __entry->ino = mapping ? mapping->host->i_ino : 0; + __entry->ino = (mapping && mapping->host) ? mapping->host->i_ino : 0; __entry->index = folio->index; ),

2 years, 5 months

2
1
0 0

FAILED: patch "[PATCH] io_uring/poll: serialize poll linked timer start with poll" failed to apply to 6.3-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.3-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.3.y git checkout FETCH_HEAD git cherry-pick -x ef7dfac51d8ed961b742218f526bd589f3900a59 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062306-omen-dance-80f0@gregkh' --subject-prefix 'PATCH 6.3.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ef7dfac51d8ed961b742218f526bd589f3900a59 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Sat, 17 Jun 2023 19:50:24 -0600 Subject: [PATCH] io_uring/poll: serialize poll linked timer start with poll removal We selectively grab the ctx->uring_lock for poll update/removal, but we really should grab it from the start to fully synchronize with linked timeouts. Normally this is indeed the case, but if requests are forced async by the application, we don't fully cover removal and timer disarm within the uring_lock. Make this simpler by having consistent locking state for poll removal. Cc: stable(a)vger.kernel.org # 6.1+ Reported-by: Querijn Voet <querijnqyn(a)gmail.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/poll.c b/io_uring/poll.c index c90e47dc1e29..a78b8af7d9ab 100644 --- a/io_uring/poll.c +++ b/io_uring/poll.c @@ -977,8 +977,9 @@ int io_poll_remove(struct io_kiocb *req, unsigned int issue_flags) struct io_hash_bucket *bucket; struct io_kiocb *preq; int ret2, ret = 0; - struct io_tw_state ts = {}; + struct io_tw_state ts = { .locked = true }; + io_ring_submit_lock(ctx, issue_flags); preq = io_poll_find(ctx, true, &cd, &ctx->cancel_table, &bucket); ret2 = io_poll_disarm(preq); if (bucket) @@ -990,12 +991,10 @@ int io_poll_remove(struct io_kiocb *req, unsigned int issue_flags) goto out; } - io_ring_submit_lock(ctx, issue_flags); preq = io_poll_find(ctx, true, &cd, &ctx->cancel_table_locked, &bucket); ret2 = io_poll_disarm(preq); if (bucket) spin_unlock(&bucket->lock); - io_ring_submit_unlock(ctx, issue_flags); if (ret2) { ret = ret2; goto out; @@ -1019,7 +1018,7 @@ found: if (poll_update->update_user_data) preq->cqe.user_data = poll_update->new_user_data; - ret2 = io_poll_add(preq, issue_flags); + ret2 = io_poll_add(preq, issue_flags & ~IO_URING_F_UNLOCKED); /* successfully updated, don't complete poll request */ if (!ret2 || ret2 == -EIOCBQUEUED) goto out; @@ -1027,9 +1026,9 @@ found: req_set_fail(preq); io_req_set_res(preq, -ECANCELED, 0); - ts.locked = !(issue_flags & IO_URING_F_UNLOCKED); io_req_task_complete(preq, &ts); out: + io_ring_submit_unlock(ctx, issue_flags); if (ret < 0) { req_set_fail(req); return ret;

2 years, 5 months

2
1
0 0

FAILED: patch "[PATCH] io_uring/poll: serialize poll linked timer start with poll" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x ef7dfac51d8ed961b742218f526bd589f3900a59 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062307-taco-nurture-70a2@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ef7dfac51d8ed961b742218f526bd589f3900a59 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Sat, 17 Jun 2023 19:50:24 -0600 Subject: [PATCH] io_uring/poll: serialize poll linked timer start with poll removal We selectively grab the ctx->uring_lock for poll update/removal, but we really should grab it from the start to fully synchronize with linked timeouts. Normally this is indeed the case, but if requests are forced async by the application, we don't fully cover removal and timer disarm within the uring_lock. Make this simpler by having consistent locking state for poll removal. Cc: stable(a)vger.kernel.org # 6.1+ Reported-by: Querijn Voet <querijnqyn(a)gmail.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/poll.c b/io_uring/poll.c index c90e47dc1e29..a78b8af7d9ab 100644 --- a/io_uring/poll.c +++ b/io_uring/poll.c @@ -977,8 +977,9 @@ int io_poll_remove(struct io_kiocb *req, unsigned int issue_flags) struct io_hash_bucket *bucket; struct io_kiocb *preq; int ret2, ret = 0; - struct io_tw_state ts = {}; + struct io_tw_state ts = { .locked = true }; + io_ring_submit_lock(ctx, issue_flags); preq = io_poll_find(ctx, true, &cd, &ctx->cancel_table, &bucket); ret2 = io_poll_disarm(preq); if (bucket) @@ -990,12 +991,10 @@ int io_poll_remove(struct io_kiocb *req, unsigned int issue_flags) goto out; } - io_ring_submit_lock(ctx, issue_flags); preq = io_poll_find(ctx, true, &cd, &ctx->cancel_table_locked, &bucket); ret2 = io_poll_disarm(preq); if (bucket) spin_unlock(&bucket->lock); - io_ring_submit_unlock(ctx, issue_flags); if (ret2) { ret = ret2; goto out; @@ -1019,7 +1018,7 @@ found: if (poll_update->update_user_data) preq->cqe.user_data = poll_update->new_user_data; - ret2 = io_poll_add(preq, issue_flags); + ret2 = io_poll_add(preq, issue_flags & ~IO_URING_F_UNLOCKED); /* successfully updated, don't complete poll request */ if (!ret2 || ret2 == -EIOCBQUEUED) goto out; @@ -1027,9 +1026,9 @@ found: req_set_fail(preq); io_req_set_res(preq, -ECANCELED, 0); - ts.locked = !(issue_flags & IO_URING_F_UNLOCKED); io_req_task_complete(preq, &ts); out: + io_ring_submit_unlock(ctx, issue_flags); if (ret < 0) { req_set_fail(req); return ret;

2 years, 5 months

2
1
0 0

Re: [PATCH 5.10 00/89] 5.10.185-rc1 review

by Tim Lewis

Is it intentional and acceptable for dmesg to now log 14 "Failed to create debugfs directory" messages? I assume it's related to "regulator: Fix error checking for debugfs_create_dir". dmesg 398 lines: diff ./5.10.184-rc1-dirty.txt ./5.10.185-rc1-dirty.txt 19a20 > 12V: Failed to create debugfs directory 20a22 > 5V: Failed to create debugfs directory 69a72 > FLASH_1V8: Failed to create debugfs directory 72a76 > HUB_5V: Failed to create debugfs directory 121a126,127 > TFLASH_VDD: Failed to create debugfs directory > TF_IO: Failed to create debugfs directory 122a129 > USB_PWR_EN: Failed to create debugfs directory 123a131 > VCC_1V8: Failed to create debugfs directory 124a133 > VCC_3V3: Failed to create debugfs directory 125a135 > VDDAO_1V8: Failed to create debugfs directory 126a137 > VDDAO_3V3: Failed to create debugfs directory 127a139 > VDDCPU: Failed to create debugfs directory 278a291,292 > regulator-dummy: Failed to create debugfs directory > regulator: Failed to create debugfs directory kselftest 270 tests: diff ./out_5.10.184-rc1-dirty.txt ./out_5.10.185-rc1-dirty.txt ltp 865 tests: diff ./out_5.10.184-rc1-dirty.txt ./out_5.10.185-rc1-dirty.txt

2 years, 5 months

2
2
0 0

Request for "ip_tunnels: allow VXLAN/GENEVE to inherit TOS/TTL from VLAN" in v5.4 / v5.15

by Nicolas Dichtel

Hi, I would like to request for cherry-picking commit 7074732c8fae ("ip_tunnels: allow VXLAN/GENEVE to inherit TOS/TTL from VLAN") in linux-5.15.y and linux-5.4.y branches. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… This commit has lived since a long time in upstream (11 months), the potential regressions seems low. The cherry-pick is straightforward. It fixes the vxlan tos inherit option when vlan frames are encapsulated in vxlan. The kernel 5.4 and 5.15 are used by a lot of vendors, having this patch will fix this bug. Regards, Nicolas

2 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2023