February 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] xfs: check for dead buffers in xfs_buf_find_insert" 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 07eae0fa67ca4bbb199ad85645e0f9dfaef931cd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025020447-stinking-untying-4604@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 07eae0fa67ca4bbb199ad85645e0f9dfaef931cd Mon Sep 17 00:00:00 2001 From: Christoph Hellwig <hch(a)lst.de> Date: Thu, 16 Jan 2025 07:01:41 +0100 Subject: [PATCH] xfs: check for dead buffers in xfs_buf_find_insert Commit 32dd4f9c506b ("xfs: remove a superflous hash lookup when inserting new buffers") converted xfs_buf_find_insert to use rhashtable_lookup_get_insert_fast and thus an operation that returns the existing buffer when an insert would duplicate the hash key. But this code path misses the check for a buffer with a reference count of zero, which could lead to reusing an about to be freed buffer. Fix this by using the same atomic_inc_not_zero pattern as xfs_buf_insert. Fixes: 32dd4f9c506b ("xfs: remove a superflous hash lookup when inserting new buffers") Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Cc: stable(a)vger.kernel.org # v6.0 Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index d9636bff16ce..183428fbc607 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -655,9 +655,8 @@ xfs_buf_find_insert( spin_unlock(&bch->bc_lock); goto out_free_buf; } - if (bp) { + if (bp && atomic_inc_not_zero(&bp->b_hold)) { /* found an existing buffer */ - atomic_inc(&bp->b_hold); spin_unlock(&bch->bc_lock); error = xfs_buf_find_lock(bp, flags); if (error)

10 months, 1 week

1
0
0 0

[PATCH v2] usb: gadget: f_midi: Fixing wMaxPacketSize exceeded issue during MIDI bind retries

by Selvarasu Ganesan

The current implementation sets the wMaxPacketSize of bulk in/out endpoints to 1024 bytes at the end of the f_midi_bind function. However, in cases where there is a failure in the first midi bind attempt, consider rebinding. This scenario may encounter an f_midi_bind issue due to the previous bind setting the bulk endpoint's wMaxPacketSize to 1024 bytes, which exceeds the ep->maxpacket_limit where configured dwc3 TX/RX FIFO's maxpacket size of 512 bytes for IN/OUT endpoints in support HS speed only. Here the term "rebind" in this context refers to attempting to bind the MIDI function a second time in certain scenarios. The situations where rebinding is considered include: * When there is a failure in the first UDC write attempt, which may be caused by other functions bind along with MIDI. * Runtime composition change : Example : MIDI,ADB to MIDI. Or MIDI to MIDI,ADB. This commit addresses this issue by resetting the wMaxPacketSize before endpoint claim. And here there is no need to reset all values in the usb endpoint descriptor structure, as all members except wMaxPacketSize and bEndpointAddress have predefined values. This ensures that restores the endpoint to its expected configuration, and preventing conflicts with value of ep->maxpacket_limit. It also aligns with the approach used in other function drivers, which treat endpoint descriptors as if they were full speed before endpoint claim. Fixes: 46decc82ffd5 ("usb: gadget: unconditionally allocate hs/ss descriptor in bind operation") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Expanded changelog as per the comment from Greg KH. - Link to v1: https://lore.kernel.org/all/20241208152322.1653-1-selvarasu.g@samsung.com/ --- drivers/usb/gadget/function/f_midi.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c index 837fcdfa3840..9b991cf5b0f8 100644 --- a/drivers/usb/gadget/function/f_midi.c +++ b/drivers/usb/gadget/function/f_midi.c @@ -907,6 +907,15 @@ static int f_midi_bind(struct usb_configuration *c, struct usb_function *f) status = -ENODEV; + /* + * Reset wMaxPacketSize with maximum packet size of FS bulk transfer before + * endpoint claim. This ensures that the wMaxPacketSize does not exceed the + * limit during bind retries where configured dwc3 TX/RX FIFO's maxpacket + * size of 512 bytes for IN/OUT endpoints in support HS speed only. + */ + bulk_in_desc.wMaxPacketSize = cpu_to_le16(64); + bulk_out_desc.wMaxPacketSize = cpu_to_le16(64); + /* allocate instance-specific endpoints */ midi->in_ep = usb_ep_autoconfig(cdev->gadget, &bulk_in_desc); if (!midi->in_ep) -- 2.17.1

10 months, 1 week

2
1
0 0

[PATCH 6.1] nvme: fix metadata handling in nvme-passthrough

by Hagar Hemdan

From: Puranjay Mohan <pjy(a)amazon.com> [ Upstream commit 7c2fd76048e95dd267055b5f5e0a48e6e7c81fd9 ] On an NVMe namespace that does not support metadata, it is possible to send an IO command with metadata through io-passthru. This allows issues like [1] to trigger in the completion code path. nvme_map_user_request() doesn't check if the namespace supports metadata before sending it forward. It also allows admin commands with metadata to be processed as it ignores metadata when bdev == NULL and may report success. Reject an IO command with metadata when the NVMe namespace doesn't support it and reject an admin command if it has metadata. [1] https://lore.kernel.org/all/mb61pcylvnym8.fsf@amazon.com/ Suggested-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Anuj Gupta <anuj20.g(a)samsung.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> [ Minor changes to make it work on 6.1 ] Signed-off-by: Puranjay Mohan <pjy(a)amazon.com> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> --- Resend as all stables contain the fix except 6.1. --- drivers/nvme/host/ioctl.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/ioctl.c b/drivers/nvme/host/ioctl.c index 875dee6ecd40..19a7f0160618 100644 --- a/drivers/nvme/host/ioctl.c +++ b/drivers/nvme/host/ioctl.c @@ -3,6 +3,7 @@ * Copyright (c) 2011-2014, Intel Corporation. * Copyright (c) 2017-2021 Christoph Hellwig. */ +#include <linux/blk-integrity.h> #include <linux/ptrace.h> /* for force_successful_syscall_return */ #include <linux/nvme_ioctl.h> #include <linux/io_uring.h> @@ -171,10 +172,15 @@ static int nvme_map_user_request(struct request *req, u64 ubuffer, struct request_queue *q = req->q; struct nvme_ns *ns = q->queuedata; struct block_device *bdev = ns ? ns->disk->part0 : NULL; + bool supports_metadata = bdev && blk_get_integrity(bdev->bd_disk); + bool has_metadata = meta_buffer && meta_len; struct bio *bio = NULL; void *meta = NULL; int ret; + if (has_metadata && !supports_metadata) + return -EINVAL; + if (ioucmd && (ioucmd->flags & IORING_URING_CMD_FIXED)) { struct iov_iter iter; @@ -198,7 +204,7 @@ static int nvme_map_user_request(struct request *req, u64 ubuffer, if (bdev) bio_set_dev(bio, bdev); - if (bdev && meta_buffer && meta_len) { + if (has_metadata) { meta = nvme_add_user_metadata(req, meta_buffer, meta_len, meta_seed); if (IS_ERR(meta)) { -- 2.40.1

10 months, 1 week

3
2
0 0

[PATCH v2] kbuild: switch from lz4c to lz4 for compression

by Parth Pancholi

From: Parth Pancholi <parth.pancholi(a)toradex.com> Replace lz4c with lz4 for kernel image compression. Although lz4 and lz4c are functionally similar, lz4c has been deprecated upstream since 2018. Since as early as Ubuntu 16.04 and Fedora 25, lz4 and lz4c have been packaged together, making it safe to update the requirement from lz4c to lz4. Consequently, some distributions and build systems, such as OpenEmbedded, have fully transitioned to using lz4. OpenEmbedded core adopted this change in commit fe167e082cbd ("bitbake.conf: require lz4 instead of lz4c"), causing compatibility issues when building the mainline kernel in the latest OpenEmbedded environment, as seen in the errors below. This change also updates the LZ4 compression commands to make it backward compatible by replacing stdin and stdout with the '-' option, due to some unclear reason, the stdout keyword does not work for lz4 and '-' works for both. In addition, this modifies the legacy '-c1' with '-9' which is also compatible with both. This fixes the mainline kernel build failures with the latest master OpenEmbedded builds associated with the mentioned compatibility issues. LZ4 arch/arm/boot/compressed/piggy_data /bin/sh: 1: lz4c: not found ... ... ERROR: oe_runmake failed Cc: stable(a)vger.kernel.org Link: https://github.com/lz4/lz4/pull/553 Suggested-by: Francesco Dolcini <francesco.dolcini(a)toradex.com> Signed-off-by: Parth Pancholi <parth.pancholi(a)toradex.com> --- v2: correct the compression command line to make it compatible with lz4 v1: https://lore.kernel.org/all/20241112150006.265900-1-parth105105@gmail.com/ --- Makefile | 2 +- scripts/Makefile.lib | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 79192a3024bf..7630f763f5b2 100644 --- a/Makefile +++ b/Makefile @@ -508,7 +508,7 @@ KGZIP = gzip KBZIP2 = bzip2 KLZOP = lzop LZMA = lzma -LZ4 = lz4c +LZ4 = lz4 XZ = xz ZSTD = zstd diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 01a9f567d5af..fe5e132fcea8 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -371,10 +371,10 @@ quiet_cmd_lzo_with_size = LZO $@ cmd_lzo_with_size = { cat $(real-prereqs) | $(KLZOP) -9; $(size_append); } > $@ quiet_cmd_lz4 = LZ4 $@ - cmd_lz4 = cat $(real-prereqs) | $(LZ4) -l -c1 stdin stdout > $@ + cmd_lz4 = cat $(real-prereqs) | $(LZ4) -l -9 - - > $@ quiet_cmd_lz4_with_size = LZ4 $@ - cmd_lz4_with_size = { cat $(real-prereqs) | $(LZ4) -l -c1 stdin stdout; \ + cmd_lz4_with_size = { cat $(real-prereqs) | $(LZ4) -l -9 - -; \ $(size_append); } > $@ # U-Boot mkimage -- 2.34.1

10 months, 1 week

6
9
0 0

[PATCH v2 0/4] alpha: stack fixes

by Ivan Kokshaysky

This series fixes oopses on Alpha/SMP observed since kernel v6.9. [1] Thanks to Magnus Lindholm for identifying that remarkably longstanding bug. The problem is that GCC expects 16-byte alignment of the incoming stack since early 2004, as Maciej found out [2]: Having actually dug speculatively I can see that the psABI was changed in GCC 3.5 with commit e5e10fb4a350 ("re PR target/14539 (128-bit long double improperly aligned)") back in Mar 2004, when the stack pointer alignment was increased from 8 bytes to 16 bytes, and arch/alpha/kernel/entry.S has various suspicious stack pointer adjustments, starting with SP_OFF which is not a whole multiple of 16. Also, as Magnus noted, "ALPHA Calling Standard" [3] required the same: D.3.1 Stack Alignment This standard requires that stacks be octaword aligned at the time a new procedure is invoked. However: - the "normal" kernel stack is always misaligned by 8 bytes, thanks to the odd number of 64-bit words in 'struct pt_regs', which is the very first thing pushed onto the kernel thread stack; - syscall, fault, interrupt etc. handlers may, or may not, receive aligned stack depending on numerous factors. Somehow we got away with it until recently, when we ended up with a stack corruption in kernel/smp.c:smp_call_function_single() due to its use of 32-byte aligned local data and the compiler doing clever things allocating it on the stack. Patches 1-2 are preparatory; 3 - the main fix; 4 - fixes remaining special cases. Ivan. [1] https://lore.kernel.org/rcu/CA+=Fv5R9NG+1SHU9QV9hjmavycHKpnNyerQ=Ei90G98ukR… [2] https://lore.kernel.org/rcu/alpine.DEB.2.21.2501130248010.18889@angie.orcam… [3] https://bitsavers.org/pdf/dec/alpha/Alpha_Calling_Standard_Rev_2.0_19900427… --- Changes in v2: - patch #1: provide empty 'struct pt_regs' to fix compile failure in libbpf, reported by John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de>; update comment and commit message accordingly; - cc'ed <stable(a)vger.kernel.org> as older kernels ought to be fixed as well. --- Ivan Kokshaysky (4): alpha/uapi: do not expose kernel-only stack frame structures alpha: replace hardcoded stack offsets with autogenerated ones alpha: make stack 16-byte aligned (most cases) alpha: align stack for page fault and user unaligned trap handlers arch/alpha/include/asm/ptrace.h | 64 ++++++++++++++++++++++++++- arch/alpha/include/uapi/asm/ptrace.h | 65 ++-------------------------- arch/alpha/kernel/asm-offsets.c | 4 ++ arch/alpha/kernel/entry.S | 24 +++++----- arch/alpha/kernel/traps.c | 2 +- arch/alpha/mm/fault.c | 4 +- 6 files changed, 83 insertions(+), 80 deletions(-) -- 2.39.5

10 months, 1 week

5
17
0 0

[PATCH v8 02/13] drm/bridge: cdns-dsi: Fix phy de-init and flag it so

by Aradhya Bhatia

From: Aradhya Bhatia <a-bhatia1(a)ti.com> The driver code doesn't have a Phy de-initialization path as yet, and so it does not clear the phy_initialized flag while suspending. This is a problem because after resume the driver looks at this flag to determine if a Phy re-initialization is required or not. It is in fact required because the hardware is resuming from a suspend, but the driver does not carry out any re-initialization causing the D-Phy to not work at all. Call the counterparts of phy_init() and phy_power_on(), that are phy_exit() and phy_power_off(), from _bridge_post_disable(), and clear the flags so that the Phy can be initialized again when required. Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework") Cc: Stable List <stable(a)vger.kernel.org> Signed-off-by: Aradhya Bhatia <a-bhatia1(a)ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia(a)linux.dev> --- drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c index 2f897ea5e80a..b0a1a6774ea6 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -680,6 +680,11 @@ static void cdns_dsi_bridge_post_disable(struct drm_bridge *bridge) struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge); struct cdns_dsi *dsi = input_to_dsi(input); + dsi->phy_initialized = false; + dsi->link_initialized = false; + phy_power_off(dsi->dphy); + phy_exit(dsi->dphy); + pm_runtime_put(dsi->base.dev); } @@ -1152,7 +1157,6 @@ static int __maybe_unused cdns_dsi_suspend(struct device *dev) clk_disable_unprepare(dsi->dsi_sys_clk); clk_disable_unprepare(dsi->dsi_p_clk); reset_control_assert(dsi->dsi_p_rst); - dsi->link_initialized = false; return 0; } -- 2.34.1

10 months, 1 week

3
2
0 0

Publish Your Research in e-Informatica Software Engineering Journal (IF=1.2, Open Access & Free of Charge)

by e-Informatica Software Engineering Journal

Dear Prof./Dr. Table, e-Informatica Software Engineering Journal (EISEJ) is an established, peer-reviewed, ISI JCR-indexed journal with an Impact Factor (IF=1.2, 5 Year IF=1.3) calculated by Clarivate and a free-of-charge, open-access publishing model that accepts papers in Software Engineering, including the intersection of data science (AI/ML) and Software Engineering. Since you have published your research results at premier software engineering conferences, such as MSR24, we believe that EISEJ can serve as an excellent platform to share your impactful work further, connecting it with a broad, engaged audience and enhancing your visibility even more. Why choose EISEJ for your next publication? - Reputation and Trust: Indexed in ISI Web of Science (IF=1.2, 5 Year IF=1.3), Scopus (CiteScore'23=2.6, CiteScoreTracker'24=3.3 and growing), DBLP, DOAJ, and Google Scholar, demonstrating our global reach and credibility. - No Author Fees: Publish your work under a CC-BY license without any costs, making your research accessible worldwide. - Global Reach and Recognition: Internationally renowned Editorial Board: https://www.e-informatyka.pl/index.php/einformatica/editorial-board/ . - Efficient Publishing Process: Benefit from continuous, rapid publishing with immediate online availability post-acceptance. - No Restrictions on Paper Length: We welcome comprehensive work without word or page limits. What We Publish: In addition to regular research papers, EISEJ is an ideal venue for: - Systematic reviews, mapping studies, and survey research studies, and supporting tools, see, e.g., [1] Norsaremah Salleh, Emilia Mendes, Fabiana Mendes, Charitha Dissanayake Lekamlage and Kai Petersen, "Value-based Software Engineering: A Systematic Mapping Study", In e-Informatica Software Engineering Journal, vol. 17, no. 1, pp. 230106, 2023. DOI: 10.37190/e-Inf230106. [2] Chris Marshall, Barbara Kitchenham and Pearl Brereton, "Tool Features to Support Systematic Reviews in Software Engineering – A Cross Domain Study", In e-Informatica Software Engineering Journal, vol. 12, no. 1, pp. 79–115, 2018. DOI: 10.5277/e-Inf180104. - Guidelines, see, e.g., [3] Miroslaw Staron, "Guidelines for Conducting Action Research Studies in Software Engineering", In e-Informatica Software Engineering Journal, vol. 19, no. 1, pp. 250105, 2025. DOI: 10.37190/e-Inf250105. [4] Muhammad Usman, Nauman Bin Ali and Claes Wohlin, "A Quality Assessment Instrument for Systematic Literature Reviews in Software Engineering", In e-Informatica Software Engineering Journal, vol. 17, no. 1, pp. 230105, 2023. DOI: 10.37190/e-Inf230105. - Research agendas and vision papers, see, e.g., [5] Michael Unterkalmsteiner, Pekka Abrahamsson, XiaoFeng Wang, Anh Nguyen-Duc, Syed Shah, Sohaib Shahid Bajwa, Guido H. Baltes, Kieran Conboy, Eoin Cullina, Denis Dennehy, Henry Edison, Carlos Fernandez-Sanchez, Juan Garbajosa, Tony Gorschek, Eriks Klotins, Laura Hokkanen, Fabio Kon, Ilaria Lunesu, Michele Marchesi, Lorraine Morgan, Markku Oivo, Christoph Selig, Pertti Seppänen, Roger Sweetman, Pasi Tyrväinen, Christina Ungerer and Agustin Yagüe, "Software Startups – A Research Agenda", In e-Informatica Software Engineering Journal, vol. 10, no. 1, pp. 89–124, 2016. DOI: 10.5277/e-Inf160105. [6] Einav Peretz-Andersson and Richard Torkar, "Empirical AI Transformation Research: A Systematic Mapping Study and Future Agenda", In e-Informatica Software Engineering Journal, vol. 16, no. 1, pp. 220108, 2022. DOI: 10.37190/e-Inf220108. - Interdisciplinary work at the intersection of Software Engineering and AI/ML, see, e.g., [7] Mirosław Ochodek and Miroslaw Staron, "ACoRA – A Platform for Automating Code Review Tasks", In e-Informatica Software Engineering Journal, vol. 19, no. 1, pp. 250102, 2025. DOI: 10.37190/e-Inf250102. We are also open to proposals for special sections that reflect the latest trends and challenges in the field. If you have ideas for collaboration or suggestions on how we can better meet researchers’ needs, we welcome your feedback at e-informatica(a)pwr.edu.pl . Explore our journal at: https://www.e-informatyka.pl/ , and start your submission process at https://mc.manuscriptcentral.com/e-InformaticaSEJ . We recommend using our latest LaTeX template available at https://www.e-informatyka.pl/index.php/einformatica/authors-guide/paper-sub… With best regards, Lech Madeyski & Miroslaw Ochodek Editors-in-Chief, e-Informatica Software Engineering Journal (EISEJ) --- EISEJ is indexed by: - ISI WoS with Impact Factor (IF=1.2, 5 Year IF=1.3) calculated by Clarivate: https://jcr.clarivate.com/jcr-jp/journal-profile?journal=E-INFORMATICA&year… - Scopus (with CiteScore=2.6): https://www.scopus.com/sourceid/21100259509 - DBLP: https://dblp.uni-trier.de/db/journals/eInformatica/index.html - Directory of Open Access Journals (DOAJ): https://www.doaj.org/toc/2084-4840 - Google Scholar: https://scholar.google.pl/citations?user=8-uDLDoAAAAJ&hl --- Opt out: If you do not want to receive further e-mails from us, please use this link: https://listmonk.e-informatyka.pl/subscription/c3d88966-bba6-42ee-af4c-3eab…

10 months, 1 week

1
0
0 0

[PATCH] arm64: Handle .ARM.attributes section in linker scripts

by Nathan Chancellor

A recent LLVM commit [1] started generating an .ARM.attributes section similar to the one that exists for 32-bit, which results in orphan section warnings (or errors if CONFIG_WERROR is enabled) from the linker because it is not handled in the arm64 linker scripts. ld.lld: error: arch/arm64/kernel/vdso/vgettimeofday.o:(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: arch/arm64/kernel/vdso/vgetrandom.o:(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/vsprintf.o):(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/win_minmax.o):(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/xarray.o):(.ARM.attributes) is being placed in '.ARM.attributes' Add this new section to the necessary linker scripts to resolve the warnings. Cc: stable(a)vger.kernel.org Fixes: b3e5d80d0c48 ("arm64/build: Warn on orphan section placement") Link: https://github.com/llvm/llvm-project/commit/ee99c4d4845db66c4daa2373352133f… [1] Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- arch/arm64/kernel/vdso/vdso.lds.S | 1 + arch/arm64/kernel/vmlinux.lds.S | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S index 4ec32e86a8da..f8418a3a2758 100644 --- a/arch/arm64/kernel/vdso/vdso.lds.S +++ b/arch/arm64/kernel/vdso/vdso.lds.S @@ -75,6 +75,7 @@ SECTIONS DWARF_DEBUG ELF_DETAILS + .ARM.attributes 0 : { *(.ARM.attributes) } /DISCARD/ : { *(.data .data.* .gnu.linkonce.d.* .sdata*) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index f84c71f04d9e..c94942e9eb46 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -335,6 +335,7 @@ SECTIONS STABS_DEBUG DWARF_DEBUG ELF_DETAILS + .ARM.attributes 0 : { *(.ARM.attributes) } HEAD_SYMBOLS --- base-commit: 1dd3393696efba1598aa7692939bba99d0cffae3 change-id: 20250123-arm64-handle-arm-attributes-in-linker-script-82aee25313ac Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

10 months, 1 week

2
1
0 0

Request to apply 961b4b5e86bf to LTS kernels

by Chuck Lever

Hi - May I request that you apply 961b4b5e86bf ("NFSD: Reset cb_seq_status after NFS4ERR_DELAY") to all LTS kernels that don't have it? I've checked that it applies cleanly to at least v6.1 and run it through NFSD CI. It should not be a problem to apply it elsewhere. -- Chuck Lever

10 months, 1 week

2
1
0 0

[PATCH] arm64: kprobe: fix an error in single stepping support

by 1534428646＠qq.com

From: "Yiren Xie" <1534428646(a)qq.com> It is obvious a conflict between the code and the comment. The function aarch64_insn_is_steppable is used to check if a mrs instruction can be safe in single-stepping environment, in the comment it says only reading DAIF bits by mrs is safe in single-stepping environment, and other mrs instructions are not. So aarch64_insn_is_steppable should returen "TRUE" if the mrs instruction being single stepped is reading DAIF bits. And have verified using a kprobe kernel module which reads the DAIF bits by function arch_local_irq_save with offset setting to 0x4, confirmed that without this modification, it encounters "kprobe_init: register_kprobe failed, returned -22" error while inserting the kprobe kernel module. and with this modification, it can read the DAIF bits in single-stepping environment. Fixes: 2dd0e8d2d2a1 ("arm64: Kprobes with single stepping support") Cc: stable(a)vger.kernel.org Signed-off-by: Yiren Xie <1534428646(a)qq.com> --- arch/arm64/kernel/probes/decode-insn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c index 6438bf62e753..22383eb1c22c 100644 --- a/arch/arm64/kernel/probes/decode-insn.c +++ b/arch/arm64/kernel/probes/decode-insn.c @@ -40,7 +40,7 @@ static bool __kprobes aarch64_insn_is_steppable(u32 insn) */ if (aarch64_insn_is_mrs(insn)) return aarch64_insn_extract_system_reg(insn) - != AARCH64_INSN_SPCLREG_DAIF; + == AARCH64_INSN_SPCLREG_DAIF; /* * The HINT instruction is steppable only if it is in whitelist -- 2.34.1

10 months, 1 week

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025