November 2024 - Linux-stable-mirror

by Darrick J. Wong

Hi all, Bug fixes for 6.13. If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below. This has been running on the djcloud for months with no problems. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=xf… xfsprogs git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h… --- Commits in this patchset: * xfs: fix off-by-one error in fsmap's end_daddr usage * xfs: metapath scrubber should use the already loaded inodes * xfs: keep quota directory inode loaded * xfs: return a 64-bit block count from xfs_btree_count_blocks * xfs: don't drop errno values when we fail to ficlone the entire range * xfs: separate healthy clearing mask during repair * xfs: set XFS_SICK_INO_SYMLINK_ZAPPED explicitly when zapping a symlink * xfs: mark metadir repair tempfiles with IRECOVERY * xfs: fix null bno_hint handling in xfs_rtallocate_rtg * xfs: fix error bailout in xfs_rtginode_create * xfs: update btree keys correctly when _insrec splits an inode root block * xfs: fix scrub tracepoints when inode-rooted btrees are involved * xfs: unlock inodes when erroring out of xfs_trans_alloc_dir * xfs: only run precommits once per transaction object * xfs: remove recursion in __xfs_trans_commit * xfs: don't lose solo superblock counter update transactions * xfs: don't lose solo dquot update transactions * xfs: separate dquot buffer reads from xfs_dqflush * xfs: clean up log item accesses in xfs_qm_dqflush{,_done} * xfs: attach dquot buffer to dquot log item buffer * xfs: convert quotacheck to attach dquot buffers --- fs/xfs/libxfs/xfs_btree.c | 33 +++++-- fs/xfs/libxfs/xfs_btree.h | 2 fs/xfs/libxfs/xfs_ialloc_btree.c | 4 + fs/xfs/libxfs/xfs_rtgroup.c | 2 fs/xfs/scrub/agheader.c | 6 + fs/xfs/scrub/agheader_repair.c | 6 + fs/xfs/scrub/fscounters.c | 2 fs/xfs/scrub/health.c | 57 +++++++----- fs/xfs/scrub/ialloc.c | 4 - fs/xfs/scrub/metapath.c | 68 +++++--------- fs/xfs/scrub/refcount.c | 2 fs/xfs/scrub/scrub.h | 6 + fs/xfs/scrub/symlink_repair.c | 3 - fs/xfs/scrub/tempfile.c | 10 ++ fs/xfs/scrub/trace.h | 2 fs/xfs/xfs_bmap_util.c | 2 fs/xfs/xfs_dquot.c | 185 ++++++++++++++++++++++++++++++++------ fs/xfs/xfs_dquot.h | 5 + fs/xfs/xfs_dquot_item.c | 51 ++++++++-- fs/xfs/xfs_dquot_item.h | 7 + fs/xfs/xfs_file.c | 8 ++ fs/xfs/xfs_fsmap.c | 38 +++++--- fs/xfs/xfs_inode.h | 2 fs/xfs/xfs_qm.c | 92 +++++++++++++------ fs/xfs/xfs_qm.h | 1 fs/xfs/xfs_quota.h | 7 + fs/xfs/xfs_rtalloc.c | 2 fs/xfs/xfs_trans.c | 58 ++++++------ fs/xfs/xfs_trans_ail.c | 2 fs/xfs/xfs_trans_dquot.c | 31 +++++- 30 files changed, 475 insertions(+), 223 deletions(-)

6 months, 1 week

3
25
0 0

FAILED: patch "[PATCH] smb: client: fix UAF in smb2_reconnect_server()" 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 24a9799aa8efecd0eb55a75e35f9d8e6400063aa # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024040834-magazine-audience-8aa4@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()") 7257bcf3bdc7 ("cifs: cifs_chan_is_iface_active should be called with chan_lock held") 27e1fd343f80 ("cifs: after disabling multichannel, mark tcon for reconnect") fa1d0508bdd4 ("cifs: account for primary channel in the interface list") a6d8fb54a515 ("cifs: distribute channels across interfaces based on speed") c37ed2d7d098 ("smb: client: remove extra @chan_count check in __cifs_put_smb_ses()") ff7d80a9f271 ("cifs: fix session state transition to avoid use-after-free issue") 38c8a9a52082 ("smb: move client and server files to common directory fs/smb") 943fb67b0902 ("cifs: missing lock when updating session status") bc962159e8e3 ("cifs: avoid race conditions with parallel reconnects") 1bcd548d935a ("cifs: prevent data race in cifs_reconnect_tcon()") e77978de4765 ("cifs: update ip_addr for ses only for primary chan setup") 3c0070f54b31 ("cifs: prevent data race in smb2_reconnect()") 05844bd661d9 ("cifs: print last update time for interface list") 25cf01b7c920 ("cifs: set correct status of tcon ipc when reconnecting") abdb1742a312 ("cifs: get rid of mount options string parsing") 9fd29a5bae6e ("cifs: use fs_context for automounts") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 24a9799aa8efecd0eb55a75e35f9d8e6400063aa Mon Sep 17 00:00:00 2001 From: Paulo Alcantara <pc(a)manguebit.com> Date: Mon, 1 Apr 2024 14:13:10 -0300 Subject: [PATCH] smb: client: fix UAF in smb2_reconnect_server() The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING. To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down. The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc: kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Cc: stable(a)vger.kernel.org Signed-off-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/connect.c b/fs/smb/client/connect.c index 9b85b5341822..ee29bc57300c 100644 --- a/fs/smb/client/connect.c +++ b/fs/smb/client/connect.c @@ -232,7 +232,13 @@ cifs_mark_tcp_ses_conns_for_reconnect(struct TCP_Server_Info *server, spin_lock(&cifs_tcp_ses_lock); list_for_each_entry_safe(ses, nses, &pserver->smb_ses_list, smb_ses_list) { - /* check if iface is still active */ + spin_lock(&ses->ses_lock); + if (ses->ses_status == SES_EXITING) { + spin_unlock(&ses->ses_lock); + continue; + } + spin_unlock(&ses->ses_lock); + spin_lock(&ses->chan_lock); if (cifs_ses_get_chan_index(ses, server) == CIFS_INVAL_CHAN_INDEX) { @@ -1963,31 +1969,6 @@ cifs_setup_ipc(struct cifs_ses *ses, struct smb3_fs_context *ctx) return rc; } -/** - * cifs_free_ipc - helper to release the session IPC tcon - * @ses: smb session to unmount the IPC from - * - * Needs to be called everytime a session is destroyed. - * - * On session close, the IPC is closed and the server must release all tcons of the session. - * No need to send a tree disconnect here. - * - * Besides, it will make the server to not close durable and resilient files on session close, as - * specified in MS-SMB2 3.3.5.6 Receiving an SMB2 LOGOFF Request. - */ -static int -cifs_free_ipc(struct cifs_ses *ses) -{ - struct cifs_tcon *tcon = ses->tcon_ipc; - - if (tcon == NULL) - return 0; - - tconInfoFree(tcon); - ses->tcon_ipc = NULL; - return 0; -} - static struct cifs_ses * cifs_find_smb_ses(struct TCP_Server_Info *server, struct smb3_fs_context *ctx) { @@ -2019,48 +2000,52 @@ cifs_find_smb_ses(struct TCP_Server_Info *server, struct smb3_fs_context *ctx) void __cifs_put_smb_ses(struct cifs_ses *ses) { struct TCP_Server_Info *server = ses->server; + struct cifs_tcon *tcon; unsigned int xid; size_t i; + bool do_logoff; int rc; - spin_lock(&ses->ses_lock); - if (ses->ses_status == SES_EXITING) { - spin_unlock(&ses->ses_lock); - return; - } - spin_unlock(&ses->ses_lock); - - cifs_dbg(FYI, "%s: ses_count=%d\n", __func__, ses->ses_count); - cifs_dbg(FYI, - "%s: ses ipc: %s\n", __func__, ses->tcon_ipc ? ses->tcon_ipc->tree_name : "NONE"); - spin_lock(&cifs_tcp_ses_lock); - if (--ses->ses_count > 0) { + spin_lock(&ses->ses_lock); + cifs_dbg(FYI, "%s: id=0x%llx ses_count=%d ses_status=%u ipc=%s\n", + __func__, ses->Suid, ses->ses_count, ses->ses_status, + ses->tcon_ipc ? ses->tcon_ipc->tree_name : "none"); + if (ses->ses_status == SES_EXITING || --ses->ses_count > 0) { + spin_unlock(&ses->ses_lock); spin_unlock(&cifs_tcp_ses_lock); return; } - spin_lock(&ses->ses_lock); - if (ses->ses_status == SES_GOOD) - ses->ses_status = SES_EXITING; - spin_unlock(&ses->ses_lock); - spin_unlock(&cifs_tcp_ses_lock); - /* ses_count can never go negative */ WARN_ON(ses->ses_count < 0); - spin_lock(&ses->ses_lock); - if (ses->ses_status == SES_EXITING && server->ops->logoff) { - spin_unlock(&ses->ses_lock); - cifs_free_ipc(ses); + spin_lock(&ses->chan_lock); + cifs_chan_clear_need_reconnect(ses, server); + spin_unlock(&ses->chan_lock); + + do_logoff = ses->ses_status == SES_GOOD && server->ops->logoff; + ses->ses_status = SES_EXITING; + tcon = ses->tcon_ipc; + ses->tcon_ipc = NULL; + spin_unlock(&ses->ses_lock); + spin_unlock(&cifs_tcp_ses_lock); + + /* + * On session close, the IPC is closed and the server must release all + * tcons of the session. No need to send a tree disconnect here. + * + * Besides, it will make the server to not close durable and resilient + * files on session close, as specified in MS-SMB2 3.3.5.6 Receiving an + * SMB2 LOGOFF Request. + */ + tconInfoFree(tcon); + if (do_logoff) { xid = get_xid(); rc = server->ops->logoff(xid, ses); if (rc) cifs_server_dbg(VFS, "%s: Session Logoff failure rc=%d\n", __func__, rc); _free_xid(xid); - } else { - spin_unlock(&ses->ses_lock); - cifs_free_ipc(ses); } spin_lock(&cifs_tcp_ses_lock);

6 months, 2 weeks

6
12
0 0

[PATCH v5 1/6] PCI: dwc: ep: iATU registers must be written after the BAR_MASK

by Niklas Cassel

The DWC Databook description for the LWR_TARGET_RW and LWR_TARGET_HW fields in the IATU_LWR_TARGET_ADDR_OFF_INBOUND_i registers state that: "Field size depends on log2(BAR_MASK+1) in BAR match mode." I.e. only the upper bits are writable, and the number of writable bits is dependent on the configured BAR_MASK. If we do not write the BAR_MASK before writing the iATU registers, we are relying the reset value of the BAR_MASK being larger than the requested size of the first set_bar() call. The reset value of the BAR_MASK is SoC dependent. Thus, if the first set_bar() call requests a size that is larger than the reset value of the BAR_MASK, the iATU will try to write to read-only bits, which will cause the iATU to end up redirecting to a physical address that is different from the address that was intended. Thus, we should always write the iATU registers after writing the BAR_MASK. Cc: stable(a)vger.kernel.org Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- .../pci/controller/dwc/pcie-designware-ep.c | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index f3ac7d46a855..bad588ef69a4 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -222,19 +222,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, if ((flags & PCI_BASE_ADDRESS_MEM_TYPE_64) && (bar & 1)) return -EINVAL; - reg = PCI_BASE_ADDRESS_0 + (4 * bar); - - if (!(flags & PCI_BASE_ADDRESS_SPACE)) - type = PCIE_ATU_TYPE_MEM; - else - type = PCIE_ATU_TYPE_IO; - - ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); - if (ret) - return ret; - if (ep->epf_bar[bar]) - return 0; + goto config_atu; + + reg = PCI_BASE_ADDRESS_0 + (4 * bar); dw_pcie_dbi_ro_wr_en(pci); @@ -246,9 +237,20 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, dw_pcie_ep_writel_dbi(ep, func_no, reg + 4, 0); } - ep->epf_bar[bar] = epf_bar; dw_pcie_dbi_ro_wr_dis(pci); +config_atu: + if (!(flags & PCI_BASE_ADDRESS_SPACE)) + type = PCIE_ATU_TYPE_MEM; + else + type = PCIE_ATU_TYPE_IO; + + ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); + if (ret) + return ret; + + ep->epf_bar[bar] = epf_bar; + return 0; } -- 2.47.0

6 months, 2 weeks

3
4
0 0

Re: [PATCH v5.10.277] wifi: mac80211: Avoid address calculations via out of bounds array indexing

by Greg KH

On Mon, Oct 28, 2024 at 05:00:02PM +0530, Hardik Gohil wrote: > On Mon, Oct 21, 2024 at 3:10 PM Greg KH <gregkh(a)linuxfoundation.org> wrote: > > > > On Sat, Oct 19, 2024 at 11:06:40AM +0530, Hardik Gohil wrote: > > > From: Kenton Groombridge <concord(a)gentoo.org> > > > > > > [ Upstream commit 2663d0462eb32ae7c9b035300ab6b1523886c718 ] > > > > We can't take patches for 5.10 that are not already in 5.15. Please fix > > up and resend for ALL relevent trees. > > > > thanks, > > > > greg k-h > > I have just confirmed those are applicable to v5.15 and v5.10. > > Request to add those patches. Please send tested backports. thanks, greg k-h

6 months, 2 weeks

3
5
0 0

[PATCH] drm/panel: st7701: Add prepare_prev_first flag to drm_panel

by Marek Vasut

The DSI host must be enabled for the panel to be initialized in prepare(). Set the prepare_prev_first flag to guarantee this. This fixes the panel operation on NXP i.MX8MP SoC / Samsung DSIM DSI host. Fixes: 849b2e3ff969 ("drm/panel: Add Sitronix ST7701 panel driver") Signed-off-by: Marek Vasut <marex(a)denx.de> --- Cc: Chris Morgan <macromorgan(a)hotmail.com> Cc: David Airlie <airlied(a)gmail.com> Cc: Hironori KIKUCHI <kikuchan98(a)gmail.com> Cc: Jagan Teki <jagan(a)amarulasolutions.com> Cc: Jessica Zhang <quic_jesszhan(a)quicinc.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Neil Armstrong <neil.armstrong(a)linaro.org> Cc: Simona Vetter <simona(a)ffwll.ch> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: dri-devel(a)lists.freedesktop.org Cc: stable(a)vger.kernel.org # v6.2+ --- Note that the prepare_prev_first flag was added in Linux 6.2.y commit 5ea6b1702781 ("drm/panel: Add prepare_prev_first flag to drm_panel"), hence the CC stable v6.2+, even if the Fixes tag points to a commit in Linux 5.1.y . --- drivers/gpu/drm/panel/panel-sitronix-st7701.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7701.c b/drivers/gpu/drm/panel/panel-sitronix-st7701.c index eef03d04e0cd2..1f72ef7ca74c9 100644 --- a/drivers/gpu/drm/panel/panel-sitronix-st7701.c +++ b/drivers/gpu/drm/panel/panel-sitronix-st7701.c @@ -1177,6 +1177,7 @@ static int st7701_probe(struct device *dev, int connector_type) return dev_err_probe(dev, ret, "Failed to get orientation\n"); drm_panel_init(&st7701->panel, dev, &st7701_funcs, connector_type); + st7701->panel.prepare_prev_first = true; /** * Once sleep out has been issued, ST7701 IC required to wait 120ms -- 2.45.2

6 months, 2 weeks

3
2
0 0

[PATCH v2] sched/topology: Enable topology_span_sane check only for debug builds

by Saurabh Sengar

On a x86 system under test with 1780 CPUs, topology_span_sane() takes around 8 seconds cumulatively for all the iterations. It is an expensive operation which does the sanity of non-NUMA topology masks. CPU topology is not something which changes very frequently hence make this check optional for the systems where the topology is trusted and need faster bootup. Restrict this to sched_verbose kernel cmdline option so that this penalty can be avoided for the systems who wants to avoid it. Cc: stable(a)vger.kernel.org Fixes: ccf74128d66c ("sched/topology: Assert non-NUMA topology masks don't (partially) overlap") Signed-off-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> --- [V2] - Use kernel cmdline param instead of compile time flag. kernel/sched/topology.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 9748a4c8d668..4ca63bff321d 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -2363,6 +2363,13 @@ static bool topology_span_sane(struct sched_domain_topology_level *tl, { int i = cpu + 1; + /* Skip the topology sanity check for non-debug, as it is a time-consuming operatin */ + if (!sched_debug_verbose) { + pr_info_once("%s: Skipping topology span sanity check. Use `sched_verbose` boot parameter to enable it.\n", + __func__); + return true; + } + /* NUMA levels are allowed to overlap */ if (tl->flags & SDTL_OVERLAP) return true; -- 2.43.0

6 months, 2 weeks

4
3
0 0

[PATCH 1/2] arm64: dts: mediatek: mt8183: Disable DPI display output by default

by Chen-Yu Tsai

This reverts commit 377548f05bd0905db52a1d50e5b328b9b4eb049d. Most SoC dtsi files have the display output interfaces disabled by default, and only enabled on boards that utilize them. The MT8183 has it backwards: the display outputs are left enabled by default, and only disabled at the board level. Reverse the situation for the DPI output so that it follows the normal scheme. For ease of backporting the DSI output is handled in a separate patch. Fixes: 009d855a26fd ("arm64: dts: mt8183: add dpi node to mt8183") Fixes: 377548f05bd0 ("arm64: dts: mediatek: mt8183-kukui: Disable DPI display interface") Cc: <stable(a)vger.kernel.org> Signed-off-by: Chen-Yu Tsai <wenst(a)chromium.org> --- arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 ----- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 + 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi index 07ae3c8e897b..22924f61ec9e 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi @@ -290,11 +290,6 @@ dsi_out: endpoint { }; }; -&dpi0 { - /* TODO Re-enable after DP to Type-C port muxing can be described */ - status = "disabled"; -}; - &gic { mediatek,broken-save-restore-fw; }; diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi index 1afeeb1155f5..8f31fc9050ec 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi @@ -1845,6 +1845,7 @@ dpi0: dpi@14015000 { <&mmsys CLK_MM_DPI_MM>, <&apmixedsys CLK_APMIXED_TVDPLL>; clock-names = "pixel", "engine", "pll"; + status = "disabled"; port { dpi_out: endpoint { }; -- 2.47.0.163.g1226f6d8fa-goog

6 months, 2 weeks

3
5
0 0

+ zram-panic-when-use-ext4-over-zram.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: zram: fix panic when using ext4 over zram has been added to the -mm mm-hotfixes-unstable branch. Its filename is zram-panic-when-use-ext4-over-zram.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: caiqingfu <caiqingfu(a)ruijie.com.cn> Subject: zram: fix panic when using ext4 over zram Date: Fri, 29 Nov 2024 19:57:35 +0800 [ 52.073080 ] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 52.073511 ] Modules linked in: [ 52.074094 ] CPU: 0 UID: 0 PID: 3825 Comm: a.out Not tainted 6.12.0-07749-g28eb75e178d3-dirty #3 [ 52.074672 ] Hardware name: linux,dummy-virt (DT) [ 52.075128 ] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 52.075619 ] pc : obj_malloc+0x5c/0x160 [ 52.076402 ] lr : zs_malloc+0x200/0x570 [ 52.076630 ] sp : ffff80008dd335f0 [ 52.076797 ] x29: ffff80008dd335f0 x28: ffff000004104a00 x27: ffff000004dfc400 [ 52.077319 ] x26: 000000000000ca18 x25: ffff00003fcaf0e0 x24: ffff000006925cf0 [ 52.077785 ] x23: 0000000000000c0a x22: ffff0000032ee780 x21: ffff000006925cf0 [ 52.078257 ] x20: 0000000000088000 x19: 0000000000000000 x18: 0000000000fffc18 [ 52.078701 ] x17: 00000000fffffffd x16: 0000000000000803 x15: 00000000fffffffe [ 52.079203 ] x14: 000000001824429d x13: ffff000006e84000 x12: ffff000006e83fec [ 52.079711 ] x11: ffff000006e83000 x10: 00000000000002a5 x9 : ffff000006e83ff3 [ 52.080269 ] x8 : 0000000000000001 x7 : 0000000017e80000 x6 : 0000000000017e80 [ 52.080724 ] x5 : 0000000000000003 x4 : ffff00000402a5e8 x3 : 0000000000000066 [ 52.081081 ] x2 : ffff000006925cf0 x1 : ffff00000402a5e8 x0 : ffff000004104a00 [ 52.081595 ] Call trace: [ 52.081925 ] obj_malloc+0x5c/0x160 (P) [ 52.082220 ] zs_malloc+0x200/0x570 (L) [ 52.082504 ] zs_malloc+0x200/0x570 [ 52.082716 ] zram_submit_bio+0x788/0x9e8 [ 52.083017 ] __submit_bio+0x1c4/0x338 [ 52.083343 ] submit_bio_noacct_nocheck+0x128/0x2c0 [ 52.083518 ] submit_bio_noacct+0x1c8/0x308 [ 52.083722 ] submit_bio+0xa8/0x14c [ 52.083942 ] submit_bh_wbc+0x140/0x1bc [ 52.084088 ] __block_write_full_folio+0x23c/0x5f0 [ 52.084232 ] block_write_full_folio+0x134/0x21c [ 52.084524 ] write_cache_pages+0x64/0xd4 [ 52.084778 ] blkdev_writepages+0x50/0x8c [ 52.085040 ] do_writepages+0x80/0x2b0 [ 52.085292 ] filemap_fdatawrite_wbc+0x6c/0x90 [ 52.085597 ] __filemap_fdatawrite_range+0x64/0x94 [ 52.085900 ] filemap_fdatawrite+0x1c/0x28 [ 52.086158 ] sync_bdevs+0x170/0x17c [ 52.086374 ] ksys_sync+0x6c/0xb8 [ 52.086597 ] __arm64_sys_sync+0x10/0x20 [ 52.086847 ] invoke_syscall+0x44/0x100 [ 52.087230 ] el0_svc_common.constprop.0+0x40/0xe0 [ 52.087550 ] do_el0_svc+0x1c/0x28 [ 52.087690 ] el0_svc+0x30/0xd0 [ 52.087818 ] el0t_64_sync_handler+0xc8/0xcc [ 52.088046 ] el0t_64_sync+0x198/0x19c [ 52.088500 ] Code: 110004a5 6b0500df f9401273 54000160 (f9401664) [ 52.089097 ] ---[ end trace 0000000000000000 ]--- When using ext4 on zram, the following panic occasionally occurs under high memory usage The reason is that when the handle is obtained using the slow path, it will be re-compressed. If the data in the page changes, the compressed length may exceed the previous one. Overflow occurred when writing to zs_object, which then caused the panic. Comment the fast path and force the slow path. Adding a large number of read and write file systems can quickly reproduce it. The solution is to re-obtain the handle after re-compression if the length is different from the previous one. Link: https://lkml.kernel.org/r/20241129115735.136033-1-baicaiaichibaicai@gmail.c… Signed-off-by: caiqingfu <caiqingfu(a)ruijie.com.cn> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/block/zram/zram_drv.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/block/zram/zram_drv.c~zram-panic-when-use-ext4-over-zram +++ a/drivers/block/zram/zram_drv.c @@ -1633,6 +1633,7 @@ static int zram_write_page(struct zram * unsigned long alloced_pages; unsigned long handle = -ENOMEM; unsigned int comp_len = 0; + unsigned int last_comp_len = 0; void *src, *dst, *mem; struct zcomp_strm *zstrm; unsigned long element = 0; @@ -1664,6 +1665,11 @@ compress_again: if (comp_len >= huge_class_size) comp_len = PAGE_SIZE; + + if (last_comp_len && (last_comp_len != comp_len)) { + zs_free(zram->mem_pool, handle); + handle = (unsigned long)ERR_PTR(-ENOMEM); + } /* * handle allocation has 2 paths: * a) fast path is executed with preemption disabled (for @@ -1692,8 +1698,10 @@ compress_again: if (IS_ERR_VALUE(handle)) return PTR_ERR((void *)handle); - if (comp_len != PAGE_SIZE) + if (comp_len != PAGE_SIZE) { + last_comp_len = comp_len; goto compress_again; + } /* * If the page is not compressible, you need to acquire the * lock and execute the code below. The zcomp_stream_get() _ Patches currently in -mm which might be from caiqingfu(a)ruijie.com.cn are zram-panic-when-use-ext4-over-zram.patch

6 months, 2 weeks

2
4
0 0

[PATCH v9 1/9] HID: hid-sensor-hub: don't use stale platform-data on remove

by Heiko Stuebner

The hid-sensor-hub creates the individual device structs and transfers them to the created mfd platform-devices via the platform_data in the mfd_cell. Before e651a1da442a ("HID: hid-sensor-hub: Allow parallel synchronous reads") the sensor-hub was managing access centrally, with one "completion" in the hub's data structure, which needed to be finished on removal at the latest. The mentioned commit then moved this central management to each hid sensor device, resulting on a completion in each struct hid_sensor_hub_device. The remove procedure was adapted to go through all sensor devices and finish any pending "completion". What this didn't take into account was, platform_device_add_data() that is used by mfd_add{_hotplug}_devices() does a kmemdup on the submitted platform-data. So the data the platform-device gets is a copy of the original data, meaning that the device worked on a different completion than what sensor_hub_remove() currently wants to access. To fix that, use device_for_each_child() to go through each child-device similar to how mfd_remove_devices() unregisters the devices later and with that get the live platform_data to finalize the correct completion. Fixes: e651a1da442a ("HID: hid-sensor-hub: Allow parallel synchronous reads") Cc: stable(a)vger.kernel.org Acked-by: Benjamin Tissoires <bentiss(a)kernel.org> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> --- drivers/hid/hid-sensor-hub.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c index 7bd86eef6ec7..4c94c03cb573 100644 --- a/drivers/hid/hid-sensor-hub.c +++ b/drivers/hid/hid-sensor-hub.c @@ -730,23 +730,30 @@ static int sensor_hub_probe(struct hid_device *hdev, return ret; } +static int sensor_hub_finalize_pending_fn(struct device *dev, void *data) +{ + struct hid_sensor_hub_device *hsdev = dev->platform_data; + + if (hsdev->pending.status) + complete(&hsdev->pending.ready); + + return 0; +} + static void sensor_hub_remove(struct hid_device *hdev) { struct sensor_hub_data *data = hid_get_drvdata(hdev); unsigned long flags; - int i; hid_dbg(hdev, " hardware removed\n"); hid_hw_close(hdev); hid_hw_stop(hdev); + spin_lock_irqsave(&data->lock, flags); - for (i = 0; i < data->hid_sensor_client_cnt; ++i) { - struct hid_sensor_hub_device *hsdev = - data->hid_sensor_hub_client_devs[i].platform_data; - if (hsdev->pending.status) - complete(&hsdev->pending.ready); - } + device_for_each_child(&hdev->dev, NULL, + sensor_hub_finalize_pending_fn); spin_unlock_irqrestore(&data->lock, flags); + mfd_remove_devices(&hdev->dev); mutex_destroy(&data->mutex); } -- 2.45.2

6 months, 2 weeks

5
10
0 0

[PATCH 6.6 0/1] cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value

by Anastasia Belova

NULL-dereference is possible in amd_pstate_adjust_perf in 6.6 stable release. The problem has been fixed by the following upstream patch that was adapted to 6.6. The patch couldn't be applied clearly but the changes made are minor. Found by Linux Verification Center (linuxtesting.org) with SVACE.

6 months, 2 weeks

1
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024