Linux-stable-mirror July 2025

linux-stable-mirror@lists.linaro.org

532 participants
1246 discussions

[PATCH 2/2] netfs: Fix race between cache write completion and ALL_QUEUED being set

by David Howells

When netfslib is issuing subrequests, the subrequests start processing immediately and may complete before we reach the end of the issuing function. At the end of the issuing function we set NETFS_RREQ_ALL_QUEUED to indicate to the collector that we aren't going to issue any more subreqs and that it can do the final notifications and cleanup. Now, this isn't a problem if the request is synchronous (NETFS_RREQ_OFFLOAD_COLLECTION is unset) as the result collection will be done in-thread and we're guaranteed an opportunity to run the collector. However, if the request is asynchronous, collection is primarily triggered by the termination of subrequests queuing it on a workqueue. Now, a race can occur here if the app thread sets ALL_QUEUED after the last subrequest terminates. This can happen most easily with the copy2cache code (as used by Ceph) where, in the collection routine of a read request, an asynchronous write request is spawned to copy data to the cache. Folios are added to the write request as they're unlocked, but there may be a delay before ALL_QUEUED is set as the write subrequests may complete before we get there. If all the write subreqs have finished by the ALL_QUEUED point, no further events happen and the collection never happens, leaving the request hanging. Fix this by queuing the collector after setting ALL_QUEUED. This is a bit heavy-handed and it may be sufficient to do it only if there are no extant subreqs. Also add a tracepoint to cross-reference both requests in a copy-to-request operation and add a trace to the netfs_rreq tracepoint to indicate the setting of ALL_QUEUED. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Reported-by: Max Kellermann <max.kellermann(a)ionos.com> Link: https://lore.kernel.org/r/CAKPOu+8z_ijTLHdiCYGU_Uk7yYD=shxyGLwfe-L7AV3DhebS… Signed-off-by: David Howells <dhowells(a)redhat.com> cc: Paulo Alcantara <pc(a)manguebit.org> cc: Viacheslav Dubeyko <slava(a)dubeyko.com> cc: Alex Markuze <amarkuze(a)redhat.com> cc: Ilya Dryomov <idryomov(a)gmail.com> cc: netfs(a)lists.linux.dev cc: ceph-devel(a)vger.kernel.org cc: linux-fsdevel(a)vger.kernel.org cc: stable(a)vger.kernel.org --- fs/netfs/read_pgpriv2.c | 4 ++++ include/trace/events/netfs.h | 30 ++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/fs/netfs/read_pgpriv2.c b/fs/netfs/read_pgpriv2.c index 080d2a6a51d9..8097bc069c1d 100644 --- a/fs/netfs/read_pgpriv2.c +++ b/fs/netfs/read_pgpriv2.c @@ -111,6 +111,7 @@ static struct netfs_io_request *netfs_pgpriv2_begin_copy_to_cache( goto cancel_put; __set_bit(NETFS_RREQ_OFFLOAD_COLLECTION, &creq->flags); + trace_netfs_copy2cache(rreq, creq); trace_netfs_write(creq, netfs_write_trace_copy_to_cache); netfs_stat(&netfs_n_wh_copy_to_cache); rreq->copy_to_cache = creq; @@ -155,6 +156,9 @@ void netfs_pgpriv2_end_copy_to_cache(struct netfs_io_request *rreq) netfs_issue_write(creq, &creq->io_streams[1]); smp_wmb(); /* Write lists before ALL_QUEUED. */ set_bit(NETFS_RREQ_ALL_QUEUED, &creq->flags); + trace_netfs_rreq(rreq, netfs_rreq_trace_end_copy_to_cache); + if (list_empty_careful(&creq->io_streams[1].subrequests)) + netfs_wake_collector(creq); netfs_put_request(creq, netfs_rreq_trace_put_return); creq->copy_to_cache = NULL; diff --git a/include/trace/events/netfs.h b/include/trace/events/netfs.h index 73e96ccbe830..64a382fbc31a 100644 --- a/include/trace/events/netfs.h +++ b/include/trace/events/netfs.h @@ -55,6 +55,7 @@ EM(netfs_rreq_trace_copy, "COPY ") \ EM(netfs_rreq_trace_dirty, "DIRTY ") \ EM(netfs_rreq_trace_done, "DONE ") \ + EM(netfs_rreq_trace_end_copy_to_cache, "END-C2C") \ EM(netfs_rreq_trace_free, "FREE ") \ EM(netfs_rreq_trace_ki_complete, "KI-CMPL") \ EM(netfs_rreq_trace_recollect, "RECLLCT") \ @@ -559,6 +560,35 @@ TRACE_EVENT(netfs_write, __entry->start, __entry->start + __entry->len - 1) ); +TRACE_EVENT(netfs_copy2cache, + TP_PROTO(const struct netfs_io_request *rreq, + const struct netfs_io_request *creq), + + TP_ARGS(rreq, creq), + + TP_STRUCT__entry( + __field(unsigned int, rreq) + __field(unsigned int, creq) + __field(unsigned int, cookie) + __field(unsigned int, ino) + ), + + TP_fast_assign( + struct netfs_inode *__ctx = netfs_inode(rreq->inode); + struct fscache_cookie *__cookie = netfs_i_cookie(__ctx); + __entry->rreq = rreq->debug_id; + __entry->creq = creq->debug_id; + __entry->cookie = __cookie ? __cookie->debug_id : 0; + __entry->ino = rreq->inode->i_ino; + ), + + TP_printk("R=%08x CR=%08x c=%08x i=%x ", + __entry->rreq, + __entry->creq, + __entry->cookie, + __entry->ino) + ); + TRACE_EVENT(netfs_collect, TP_PROTO(const struct netfs_io_request *wreq),

5 months, 3 weeks

[PATCH V3] efi/tpm: Fix the issue where the CC platforms event log header can't be correctly identified

by yangge1116＠126.com

From: Ge Yang <yangge1116(a)126.com> Since commit d228814b1913 ("efi/libstub: Add get_event_log() support for CC platforms") reuses TPM2 support code for the CC platforms, when launching a TDX virtual machine with coco measurement enabled, the following error log is generated: [Firmware Bug]: Failed to parse event in TPM Final Events Log Call Trace: efi_config_parse_tables() efi_tpm_eventlog_init() tpm2_calc_event_log_size() __calc_tpm2_event_size() The pcr_idx value in the Intel TDX log header is 1, causing the function __calc_tpm2_event_size() to fail to recognize the log header, ultimately leading to the "Failed to parse event in TPM Final Events Log" error. According to UEFI Specification 2.10, Section 38.4.1: For TDX, TPM PCR 0 maps to MRTD, so the log header uses TPM PCR 1 instead. To successfully parse the TDX event log header, the check for a pcr_idx value of 0 must be skipped. According to Table 6 in Section 10.2.1 of the TCG PC Client Specification, the index field does not require the PCR index to be fixed at zero. Therefore, skipping the check for a pcr_idx value of 0 for CC platforms is safe. Link: https://uefi.org/specs/UEFI/2.10/38_Confidential_Computing.html#intel-trust… Link: https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… Fixes: d228814b1913 ("efi/libstub: Add get_event_log() support for CC platforms") Signed-off-by: Ge Yang <yangge1116(a)126.com> Cc: stable(a)vger.kernel.org --- V3: - fix build error V2: - limit the fix for CC only suggested by Jarkko and Sathyanarayanan drivers/char/tpm/eventlog/tpm2.c | 4 +++- drivers/firmware/efi/libstub/tpm.c | 13 +++++++++---- drivers/firmware/efi/tpm.c | 4 +++- include/linux/tpm_eventlog.h | 14 +++++++++++--- 4 files changed, 26 insertions(+), 9 deletions(-) diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c index 37a0580..30ef47c 100644 --- a/drivers/char/tpm/eventlog/tpm2.c +++ b/drivers/char/tpm/eventlog/tpm2.c @@ -18,6 +18,7 @@ #include <linux/module.h> #include <linux/slab.h> #include <linux/tpm_eventlog.h> +#include <linux/cc_platform.h> #include "../tpm.h" #include "common.h" @@ -36,7 +37,8 @@ static size_t calc_tpm2_event_size(struct tcg_pcr_event2_head *event, struct tcg_pcr_event *event_header) { - return __calc_tpm2_event_size(event, event_header, false); + return __calc_tpm2_event_size(event, event_header, false, + cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT)); } static void *tpm2_bios_measurements_start(struct seq_file *m, loff_t *pos) diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c index a5c6c4f..9728060 100644 --- a/drivers/firmware/efi/libstub/tpm.c +++ b/drivers/firmware/efi/libstub/tpm.c @@ -50,7 +50,8 @@ void efi_enable_reset_attack_mitigation(void) static void efi_retrieve_tcg2_eventlog(int version, efi_physical_addr_t log_location, efi_physical_addr_t log_last_entry, efi_bool_t truncated, - struct efi_tcg2_final_events_table *final_events_table) + struct efi_tcg2_final_events_table *final_events_table, + bool is_cc_event) { efi_guid_t linux_eventlog_guid = LINUX_EFI_TPM_EVENT_LOG_GUID; efi_status_t status; @@ -87,7 +88,8 @@ static void efi_retrieve_tcg2_eventlog(int version, efi_physical_addr_t log_loca last_entry_size = __calc_tpm2_event_size((void *)last_entry_addr, (void *)(long)log_location, - false); + false, + is_cc_event); } else { last_entry_size = sizeof(struct tcpa_event) + ((struct tcpa_event *) last_entry_addr)->event_size; @@ -123,7 +125,8 @@ static void efi_retrieve_tcg2_eventlog(int version, efi_physical_addr_t log_loca header = data + offset + final_events_size; event_size = __calc_tpm2_event_size(header, (void *)(long)log_location, - false); + false, + is_cc_event); /* If calc fails this is a malformed log */ if (!event_size) break; @@ -157,6 +160,7 @@ void efi_retrieve_eventlog(void) efi_tcg2_protocol_t *tpm2 = NULL; efi_bool_t truncated; efi_status_t status; + bool is_cc_event = false; status = efi_bs_call(locate_protocol, &tpm2_guid, NULL, (void **)&tpm2); if (status == EFI_SUCCESS) { @@ -186,11 +190,12 @@ void efi_retrieve_eventlog(void) final_events_table = get_efi_config_table(EFI_CC_FINAL_EVENTS_TABLE_GUID); + is_cc_event = true; } if (status != EFI_SUCCESS || !log_location) return; efi_retrieve_tcg2_eventlog(version, log_location, log_last_entry, - truncated, final_events_table); + truncated, final_events_table, is_cc_event); } diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c index cdd4310..ca8535d 100644 --- a/drivers/firmware/efi/tpm.c +++ b/drivers/firmware/efi/tpm.c @@ -12,6 +12,7 @@ #include <linux/init.h> #include <linux/memblock.h> #include <linux/tpm_eventlog.h> +#include <linux/cc_platform.h> int efi_tpm_final_log_size; EXPORT_SYMBOL(efi_tpm_final_log_size); @@ -23,7 +24,8 @@ static int __init tpm2_calc_event_log_size(void *data, int count, void *size_inf while (count > 0) { header = data + size; - event_size = __calc_tpm2_event_size(header, size_info, true); + event_size = __calc_tpm2_event_size(header, size_info, true, + cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT)); if (event_size == 0) return -1; size += event_size; diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h index 891368e..b3380c9 100644 --- a/include/linux/tpm_eventlog.h +++ b/include/linux/tpm_eventlog.h @@ -143,6 +143,7 @@ struct tcg_algorithm_info { * @event: Pointer to the event whose size should be calculated * @event_header: Pointer to the initial event containing the digest lengths * @do_mapping: Whether or not the event needs to be mapped + * @is_cc_event: Whether or not the event is from a CC platform * * The TPM2 event log format can contain multiple digests corresponding to * separate PCR banks, and also contains a variable length of the data that @@ -159,7 +160,8 @@ struct tcg_algorithm_info { static __always_inline u32 __calc_tpm2_event_size(struct tcg_pcr_event2_head *event, struct tcg_pcr_event *event_header, - bool do_mapping) + bool do_mapping, + bool is_cc_event) { struct tcg_efi_specid_event_head *efispecid; struct tcg_event_field *event_field; @@ -201,8 +203,14 @@ static __always_inline u32 __calc_tpm2_event_size(struct tcg_pcr_event2_head *ev count = event->count; event_type = event->event_type; - /* Verify that it's the log header */ - if (event_header->pcr_idx != 0 || + /* + * Verify that it's the log header. According to the TCG PC Client + * Specification, when identifying a log header, the check for a + * pcr_idx value of 0 is not required. For CC platforms, skipping + * this check during log header is necessary; otherwise, the CC + * platform's log header may fail to be recognized. + */ + if ((!is_cc_event && event_header->pcr_idx != 0) || event_header->event_type != NO_ACTION || memcmp(event_header->digest, zero_digest, sizeof(zero_digest))) { size = 0; -- 2.7.4

5 months, 3 weeks

[PATCH 2/2] nvmem: imx: Swap only the first 6 bytes of the MAC address

by Christian Eggers

Since commit 55d4980ce55b ("nvmem: core: support specifying both: cell raw data & post read lengths"), the aligned length (e.g. '8' instead of '6') is passed to the read_post_process callback. This causes that the 2 bytes following the MAC address in the ocotp are swapped to the beginning of the address. As a result, an invalid MAC address is returned and to make it even worse, this address can be equal on boards with the same OUI vendor prefix. Fixes: 55d4980ce55b ("nvmem: core: support specifying both: cell raw data & post read lengths") Signed-off-by: Christian Eggers <ceggers(a)arri.de> Cc: stable(a)vger.kernel.org --- Tested on i.MX6ULL, but I assume that this is also required for. imx-ocotp-ele.c (i.MX93). drivers/nvmem/imx-ocotp-ele.c | 5 +++-- drivers/nvmem/imx-ocotp.c | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/nvmem/imx-ocotp-ele.c b/drivers/nvmem/imx-ocotp-ele.c index 83617665c8d7..07830785ebf1 100644 --- a/drivers/nvmem/imx-ocotp-ele.c +++ b/drivers/nvmem/imx-ocotp-ele.c @@ -6,6 +6,7 @@ */ #include <linux/device.h> +#include <linux/if_ether.h> #include <linux/io.h> #include <linux/module.h> #include <linux/nvmem-provider.h> @@ -119,8 +120,8 @@ static int imx_ocotp_cell_pp(void *context, const char *id, int index, /* Deal with some post processing of nvmem cell data */ if (id && !strcmp(id, "mac-address")) - for (i = 0; i < bytes / 2; i++) - swap(buf[i], buf[bytes - i - 1]); + for (i = 0; i < ETH_ALEN / 2; i++) + swap(buf[i], buf[ETH_ALEN - i - 1]); return 0; } diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 22cc77908018..4dd3b0f94de2 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -16,6 +16,7 @@ #include <linux/clk.h> #include <linux/device.h> +#include <linux/if_ether.h> #include <linux/io.h> #include <linux/module.h> #include <linux/nvmem-provider.h> @@ -228,8 +229,8 @@ static int imx_ocotp_cell_pp(void *context, const char *id, int index, /* Deal with some post processing of nvmem cell data */ if (id && !strcmp(id, "mac-address")) - for (i = 0; i < bytes / 2; i++) - swap(buf[i], buf[bytes - i - 1]); + for (i = 0; i < ETH_ALEN / 2; i++) + swap(buf[i], buf[ETH_ALEN - i - 1]); return 0; } -- 2.43.0

5 months, 3 weeks

[PATCH 1/2] nvmem: imx: assign nvmem_cell_info::raw_len

by Christian Eggers

Avoid getting error messages at startup like the following on i.MX6ULL: nvmem imx-ocotp0: cell mac-addr raw len 6 unaligned to nvmem word size 4 nvmem imx-ocotp0: cell mac-addr raw len 6 unaligned to nvmem word size 4 This shouldn't cause any functional change as this alignment would otherwise be done in nvmem_cell_info_to_nvmem_cell_entry_nodup(). Fixes: 4327479e559c ("nvmem: core: verify cell's raw_len") Signed-off-by: Christian Eggers <ceggers(a)arri.de> Cc: stable(a)vger.kernel.org --- Tested on i.MX6ULL, but I assume that this is also required for imx-ocotp-ele.c (i.MX93). drivers/nvmem/imx-ocotp-ele.c | 1 + drivers/nvmem/imx-ocotp.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/nvmem/imx-ocotp-ele.c b/drivers/nvmem/imx-ocotp-ele.c index ca6dd71d8a2e..83617665c8d7 100644 --- a/drivers/nvmem/imx-ocotp-ele.c +++ b/drivers/nvmem/imx-ocotp-ele.c @@ -128,6 +128,7 @@ static int imx_ocotp_cell_pp(void *context, const char *id, int index, static void imx_ocotp_fixup_dt_cell_info(struct nvmem_device *nvmem, struct nvmem_cell_info *cell) { + cell->raw_len = round_up(cell->bytes, 4); cell->read_post_process = imx_ocotp_cell_pp; } diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 79dd4fda0329..22cc77908018 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -586,6 +586,7 @@ MODULE_DEVICE_TABLE(of, imx_ocotp_dt_ids); static void imx_ocotp_fixup_dt_cell_info(struct nvmem_device *nvmem, struct nvmem_cell_info *cell) { + cell->raw_len = round_up(cell->bytes, 4); cell->read_post_process = imx_ocotp_cell_pp; } -- 2.43.0

5 months, 3 weeks

[PATCH] isofs: Verify inode mode when loading from disk

by Jan Kara

Verify that the inode mode is sane when loading it from the disk to avoid complaints from VFS about setting up invalid inodes. Reported-by: syzbot+895c23f6917da440ed0d(a)syzkaller.appspotmail.com CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/isofs/inode.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) I plan to merge this fix through my tree. diff --git a/fs/isofs/inode.c b/fs/isofs/inode.c index d5da9817df9b..33e6a620c103 100644 --- a/fs/isofs/inode.c +++ b/fs/isofs/inode.c @@ -1440,9 +1440,16 @@ static int isofs_read_inode(struct inode *inode, int relocated) inode->i_op = &page_symlink_inode_operations; inode_nohighmem(inode); inode->i_data.a_ops = &isofs_symlink_aops; - } else + } else if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode) || + S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode)) { /* XXX - parse_rock_ridge_inode() had already set i_rdev. */ init_special_inode(inode, inode->i_mode, inode->i_rdev); + } else { + printk(KERN_DEBUG "ISOFS: Invalid file type 0%04o for inode %lu.\n", + inode->i_mode, inode->i_ino); + ret = -EIO; + goto fail; + } ret = 0; out: -- 2.43.0

5 months, 3 weeks

[PATCH v1 1/1] Documentation: ACPI: Fix parent device references

by Andy Shevchenko

The _CRS resources in many cases want to have ResourceSource field to be a type of ACPI String. This means that to compile properly we need to enclosure the name path into double quotes. This will in practice defer the interpretation to a run-time stage, However, this may be interpreted differently on different OSes and ACPI interpreter implementations. In particular ACPICA might not correctly recognize the leading '^' (caret) character and will not resolve the relative name path properly. On top of that, this piece may be used in SSDTs which are loaded after the DSDT and on itself may also not resolve relative name paths outside of their own scopes. With this all said, fix documentation to use fully-qualified name paths always to avoid any misinterpretations, which is proven to work. Fixes: 8eb5c87a92c0 ("i2c: add ACPI support for I2C mux ports") Reported-by: Yevhen Kondrashyn <e.kondrashyn(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- Rafael, I prefer, if no objections, to push this as v6.16-rc6 material since the reported issue was detected on old (v5.10.y) and still LTS kernel. Would be nice for people to not trap to it in older kernels. Documentation/firmware-guide/acpi/i2c-muxes.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/firmware-guide/acpi/i2c-muxes.rst b/Documentation/firmware-guide/acpi/i2c-muxes.rst index 3a8997ccd7c4..f366539acd79 100644 --- a/Documentation/firmware-guide/acpi/i2c-muxes.rst +++ b/Documentation/firmware-guide/acpi/i2c-muxes.rst @@ -14,7 +14,7 @@ Consider this topology:: | | | 0x70 |--CH01--> i2c client B (0x50) +------+ +------+ -which corresponds to the following ASL:: +which corresponds to the following ASL (in the scope of \_SB):: Device (SMB1) { @@ -24,7 +24,7 @@ which corresponds to the following ASL:: Name (_HID, ...) Name (_CRS, ResourceTemplate () { I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED, - AddressingMode7Bit, "^SMB1", 0x00, + AddressingMode7Bit, "\\_SB.SMB1", 0x00, ResourceConsumer,,) } @@ -37,7 +37,7 @@ which corresponds to the following ASL:: Name (_HID, ...) Name (_CRS, ResourceTemplate () { I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, - AddressingMode7Bit, "^CH00", 0x00, + AddressingMode7Bit, "\\_SB.SMB1.CH00", 0x00, ResourceConsumer,,) } } @@ -52,7 +52,7 @@ which corresponds to the following ASL:: Name (_HID, ...) Name (_CRS, ResourceTemplate () { I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, - AddressingMode7Bit, "^CH01", 0x00, + AddressingMode7Bit, "\\_SB.SMB1.CH01", 0x00, ResourceConsumer,,) } } -- 2.47.2

5 months, 3 weeks

[PATCH 1/7] arm64: dts: imx8mm-venice-gw700x: Increase HS400 USDHC clock speed

by Tim Harvey

The IMX8M reference manuals indicate in the USDHC Clock generator section that the clock rate for DDR is 1/2 the input clock therefore HS400 rates clocked at 200Mhz require a 400Mhz SDHC clock. This showed about a 1.5x improvement in read performance for the eMMC's used on the various imx8m{m,n,p}-venice boards. Fixes: 6f30b27c5ef5 ("arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits") Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> --- arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi index 5a3b1142ddf4..37db4f0dd505 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi @@ -418,6 +418,8 @@ &usdhc3 { pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; + assigned-clocks = <&clk IMX8MM_CLK_USDHC3>; + assigned-clock-rates = <400000000>; bus-width = <8>; non-removable; status = "okay"; -- 2.25.1

5 months, 3 weeks

[PATCH] arm64: dts: ti: k3-am62a7-sk: fix pinmux for main_uart1

by Bryan Brattlof

From: Hong Guan <hguan(a)ti.com> The &main_uart1, which is reserved for TIFS firmware traces, is routed to the onboard FT4232 via a FET swich which is connected to pin A21 and B21 of the SoC and not E17 and C17. Fix it. Fixes: cf39ff15cc01a ("arm64: dts: ti: k3-am62a7-sk: Describe main_uart1 and wkup_uart") Cc: stable(a)vger.kernel.org Signed-off-by: Hong Guan <hguan(a)ti.com> [bb(a)ti.com: expanded commit message] Signed-off-by: Bryan Brattlof <bb(a)ti.com> --- arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts index 3a8b45272526037b364e6e39886fcc9199114105..f11284b3fe8e23b4c48d8d2f3a7202e80dc57370 100644 --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts @@ -301,8 +301,8 @@ AM62AX_IOPAD(0x1cc, PIN_OUTPUT, 0) /* (D15) UART0_TXD */ main_uart1_pins_default: main-uart1-default-pins { pinctrl-single,pins = < - AM62AX_IOPAD(0x01e8, PIN_INPUT, 1) /* (C17) I2C1_SCL.UART1_RXD */ - AM62AX_IOPAD(0x01ec, PIN_OUTPUT, 1) /* (E17) I2C1_SDA.UART1_TXD */ + AM62AX_IOPAD(0x01ac, PIN_INPUT, 2) /* (B21) MCASP0_AFSR.UART1_RXD */ + AM62AX_IOPAD(0x01b0, PIN_OUTPUT, 2) /* (A21) MCASP0_ACLKR.UART1_TXD */ AM62AX_IOPAD(0x0194, PIN_INPUT, 2) /* (C19) MCASP0_AXR3.UART1_CTSn */ AM62AX_IOPAD(0x0198, PIN_OUTPUT, 2) /* (B19) MCASP0_AXR2.UART1_RTSn */ >; --- base-commit: 036cc33070b35754f45da50d81f8c3c85191c8b7 change-id: 20250707-uart-fixes-6efe27a1afe4 Best regards, -- Bryan Brattlof <bb(a)ti.com>

5 months, 3 weeks

[PATCH v2] ext4: inline: convert when mmap is called, not when page is written

by Thadeu Lima de Souza Cascardo

inline data handling has a race between writing and writing to a memory map. When ext4_page_mkwrite is called, it calls ext4_convert_inline_data, which destroys the inline data, but if block allocation fails, restores the inline data. In that process, we could have: CPU1 CPU2 destroy_inline_data write_begin (does not see inline data) restory_inline_data write_end (sees inline data) This leads to bugs like the one below, as write_begin did not prepare for the case of inline data, which is expected by the write_end side of it. ------------[ cut here ]------------ kernel BUG at fs/ext4/inline.c:235! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 UID: 0 PID: 5838 Comm: syz-executor110 Not tainted 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:ext4_write_inline_data fs/ext4/inline.c:235 [inline] RIP: 0010:ext4_write_inline_data_end+0xdc7/0xdd0 fs/ext4/inline.c:774 Code: 47 1d 8c e8 4b 3a 91 ff 90 0f 0b e8 63 7a 47 ff 48 8b 7c 24 10 48 c7 c6 e0 47 1d 8c e8 32 3a 91 ff 90 0f 0b e8 4a 7a 47 ff 90 <0f> 0b 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffc900031c7320 EFLAGS: 00010293 RAX: ffffffff8257f9a6 RBX: 000000000000005a RCX: ffff888012968000 RDX: 0000000000000000 RSI: 000000000000005a RDI: 000000000000005b RBP: ffffc900031c7448 R08: ffffffff8257ef87 R09: 1ffff11006806070 R10: dffffc0000000000 R11: ffffed1006806071 R12: 000000000000005a R13: dffffc0000000000 R14: ffff888076b65bd8 R15: 000000000000005b FS: 00007f5c6bacf6c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000a00 CR3: 0000000073fb6000 CR4: 0000000000350ef0 Call Trace: <TASK> generic_perform_write+0x6f8/0x990 mm/filemap.c:4070 ext4_buffered_write_iter+0xc5/0x350 fs/ext4/file.c:299 ext4_file_write_iter+0x892/0x1c50 iter_file_splice_write+0xbfc/0x1510 fs/splice.c:743 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0x11d/0x220 fs/splice.c:1164 splice_direct_to_actor+0x588/0xc80 fs/splice.c:1108 do_splice_direct_actor fs/splice.c:1207 [inline] do_splice_direct+0x289/0x3e0 fs/splice.c:1233 do_sendfile+0x564/0x8a0 fs/read_write.c:1363 __do_sys_sendfile64 fs/read_write.c:1424 [inline] __se_sys_sendfile64+0x17c/0x1e0 fs/read_write.c:1410 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5c6bb18d09 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f5c6bacf218 EFLAGS: 00000246 ORIG_RAX: 0000000000000028 RAX: ffffffffffffffda RBX: 00007f5c6bba0708 RCX: 00007f5c6bb18d09 RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000004 RBP: 00007f5c6bba0700 R08: 0000000000000000 R09: 0000000000000000 R10: 000080001d00c0d0 R11: 0000000000000246 R12: 00007f5c6bb6d620 R13: 00007f5c6bb6d0c0 R14: 0031656c69662f2e R15: 8088e3ad122bc192 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- This happens because ext4_page_mkwrite is not protected by the inode_lock. The xattr semaphore is not sufficient to protect inline data handling in a sane way, so we need to rely on the inode_lock. Adding the inode_lock to ext4_page_mkwrite is not an option, otherwise lock-ordering problems with mmap_lock may arise. The conversion inside ext4_page_mkwrite was introduced at commit 7b4cc9787fe3 ("ext4: evict inline data when writing to memory map"). This fixes a documented bug in the commit message, which suggests some alternative fixes. Convert inline data when mmap is called, instead of doing it only when the mmapped page is written to. Using the inode_lock there does not lead to lock-ordering issues. The drawback is that inline conversion will happen when the file is mmapped, even though the page will not be written to. Fixes: 7b4cc9787fe3 ("ext4: evict inline data when writing to memory map") Reported-by: syzbot+0c89d865531d053abb2d(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0c89d865531d053abb2d Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> Cc: stable(a)vger.kernel.org --- Changes in v2: - Convert inline data at mmap time, avoiding data loss. - Link to v1: https://lore.kernel.org/r/20250519-ext4_inline_page_mkwrite-v1-1-865d9a62b5… --- fs/ext4/file.c | 6 ++++++ fs/ext4/inode.c | 4 ---- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/ext4/file.c b/fs/ext4/file.c index beb078ee4811d6092e362e37307e7d87e5276cbc..f2380471df5d99500e49fdc639fa3e56143c328f 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -819,6 +819,12 @@ static int ext4_file_mmap(struct file *file, struct vm_area_struct *vma) if (!daxdev_mapping_supported(vma, dax_dev)) return -EOPNOTSUPP; + inode_lock(inode); + ret = ext4_convert_inline_data(inode); + inode_unlock(inode); + if (ret) + return ret; + file_accessed(file); if (IS_DAX(file_inode(file))) { vma->vm_ops = &ext4_dax_vm_ops; diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 94c7d2d828a64e42ded09c82497ed7617071aa19..895ecda786194b29d32c9c49785d56a1a84e2096 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -6222,10 +6222,6 @@ vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf) filemap_invalidate_lock_shared(mapping); - err = ext4_convert_inline_data(inode); - if (err) - goto out_ret; - /* * On data journalling we skip straight to the transaction handle: * there's no delalloc; page truncated will be checked later; the --- base-commit: 4a95bc121ccdaee04c4d72f84dbfa6b880a514b6 change-id: 20250519-ext4_inline_page_mkwrite-c42ca1f02295 Best regards, -- Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com>

5 months, 3 weeks

[RFC V1 PATCH mm-hotfixes 2/3] x86/mm: define p*d_populate_kernel() and top-level page table sync

by Harry Yoo

During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK> It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access vmemmap / direct mapping area before the sync. As suggested by Dave Hansen, define x86_64 versions of {pgd,p4d}_populate_kernel() and arch_sync_kernel_pagetables(), and explicitly perform top-level page table synchronization in {pgd,p4d}_populate_kernel(). Top level page tables are synchronized in pgd_pouplate_kernel() for 5-level paging and in p4d_populate_kernel() for 4-level paging. arch_sync_kernel_pagetables(addr) synchronizes the top level page table entry for address. It calls sync_kernel_pagetables_{l4,l5} depending on the page table levels and installs the page entry in all page tables in the system to make it visible to all tasks. Note that sync_kernel_pagetables_{l4,l5} are simply versions of sync_global_pgds_{l4,l5} that synchronizes only a single page table entry for specified address, instead of for all page table entries corresponding to a range. No functional difference intended between sync_global_pgds_* and sync_kernel_pagetables_* other than that. This also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 <TASK> vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...] Cc: <stable(a)vger.kernel.org> Fixes: 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") Fixes: faf1c0008a33 ("x86/vmemmap: optimize for consecutive sections in partial populated PMDs") Closes: https://lore.kernel.org/linux-mm/20250311114420.240341-1-gwan-gyeong.mun@in… [1] Suggested-by: Dave Hansen <dave.hansen(a)linux.intel.com> Signed-off-by: Harry Yoo <harry.yoo(a)oracle.com> --- arch/x86/include/asm/pgalloc.h | 22 ++++++++++ arch/x86/mm/init_64.c | 80 ++++++++++++++++++++++++++++++++++ 2 files changed, 102 insertions(+) diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h index c88691b15f3c..d66f2db54b16 100644 --- a/arch/x86/include/asm/pgalloc.h +++ b/arch/x86/include/asm/pgalloc.h @@ -10,6 +10,7 @@ #define __HAVE_ARCH_PTE_ALLOC_ONE #define __HAVE_ARCH_PGD_FREE +#define __HAVE_ARCH_SYNC_KERNEL_PGTABLE #include <asm-generic/pgalloc.h> static inline int __paravirt_pgd_alloc(struct mm_struct *mm) { return 0; } @@ -114,6 +115,17 @@ static inline void p4d_populate(struct mm_struct *mm, p4d_t *p4d, pud_t *pud) set_p4d(p4d, __p4d(_PAGE_TABLE | __pa(pud))); } +void arch_sync_kernel_pagetables(unsigned long addr); + +static inline void p4d_populate_kernel(unsigned long addr, + p4d_t *p4d, pud_t *pud) +{ + paravirt_alloc_pud(&init_mm, __pa(pud) >> PAGE_SHIFT); + set_p4d(p4d, __p4d(_PAGE_TABLE | __pa(pud))); + if (!pgtable_l5_enabled()) + arch_sync_kernel_pagetables(addr); +} + static inline void p4d_populate_safe(struct mm_struct *mm, p4d_t *p4d, pud_t *pud) { paravirt_alloc_pud(mm, __pa(pud) >> PAGE_SHIFT); @@ -137,6 +149,16 @@ static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, p4d_t *p4d) set_pgd(pgd, __pgd(_PAGE_TABLE | __pa(p4d))); } +static inline void pgd_populate_kernel(unsigned long addr, + pgd_t *pgd, p4d_t *p4d) +{ + if (!pgtable_l5_enabled()) + return; + paravirt_alloc_p4d(&init_mm, __pa(p4d) >> PAGE_SHIFT); + set_pgd(pgd, __pgd(_PAGE_TABLE | __pa(p4d))); + arch_sync_kernel_pagetables(addr); +} + static inline void pgd_populate_safe(struct mm_struct *mm, pgd_t *pgd, p4d_t *p4d) { if (!pgtable_l5_enabled()) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index fdb6cab524f0..cbddbef434d5 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -223,6 +223,86 @@ static void sync_global_pgds(unsigned long start, unsigned long end) sync_global_pgds_l4(start, end); } +static void sync_kernel_pagetables_l4(unsigned long addr) +{ + pgd_t *pgd_ref = pgd_offset_k(addr); + const p4d_t *p4d_ref; + struct page *page; + + VM_WARN_ON_ONCE(pgtable_l5_enabled()); + /* + * With folded p4d, pgd_none() is always false, we need to + * handle synchronization on p4d level. + */ + MAYBE_BUILD_BUG_ON(pgd_none(*pgd_ref)); + p4d_ref = p4d_offset(pgd_ref, addr); + + if (p4d_none(*p4d_ref)) + return; + + spin_lock(&pgd_lock); + list_for_each_entry(page, &pgd_list, lru) { + pgd_t *pgd; + p4d_t *p4d; + spinlock_t *pgt_lock; + + pgd = (pgd_t *)page_address(page) + pgd_index(addr); + p4d = p4d_offset(pgd, addr); + /* the pgt_lock only for Xen */ + pgt_lock = &pgd_page_get_mm(page)->page_table_lock; + spin_lock(pgt_lock); + + if (!p4d_none(*p4d_ref) && !p4d_none(*p4d)) + BUG_ON(p4d_pgtable(*p4d) + != p4d_pgtable(*p4d_ref)); + + if (p4d_none(*p4d)) + set_p4d(p4d, *p4d_ref); + + spin_unlock(pgt_lock); + } + spin_unlock(&pgd_lock); +} + +static void sync_kernel_pagetables_l5(unsigned long addr) +{ + const pgd_t *pgd_ref = pgd_offset_k(addr); + struct page *page; + + VM_WARN_ON_ONCE(!pgtable_l5_enabled()); + + if (pgd_none(*pgd_ref)) + return; + + spin_lock(&pgd_lock); + list_for_each_entry(page, &pgd_list, lru) { + pgd_t *pgd; + spinlock_t *pgt_lock; + + pgd = (pgd_t *)page_address(page) + pgd_index(addr); + /* the pgt_lock only for Xen */ + pgt_lock = &pgd_page_get_mm(page)->page_table_lock; + spin_lock(pgt_lock); + + if (!pgd_none(*pgd_ref) && !pgd_none(*pgd)) + BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref)); + + if (pgd_none(*pgd)) + set_pgd(pgd, *pgd_ref); + + spin_unlock(pgt_lock); + } + spin_unlock(&pgd_lock); +} + +void arch_sync_kernel_pagetables(unsigned long addr) +{ + if (pgtable_l5_enabled()) + sync_kernel_pagetables_l5(addr); + else + sync_kernel_pagetables_l4(addr); +} + /* * NOTE: This function is marked __ref because it calls __init function * (alloc_bootmem_pages). It's safe to do it ONLY when after_bootmem == 0. -- 2.43.0

5 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025