- Linux-stable-mirror - lists.linaro.org

[PATCH v6] usb: typec: ucsi: Get connector status after enable notifications

by Hsin-Te Yuan

Originally, the notification for connector change will be enabled after the first read of the connector status. Therefore, if the event happens during this window, it will be missing and make the status unsynced. Get the connector status only after enabling the notification for connector change to ensure the status is synced. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable(a)vger.kernel.org # v4.13+ Signed-off-by: Hsin-Te Yuan <yuanhsinte(a)chromium.org> --- Changes in v6: - Free the locks in error path. - Link to v5: https://lore.kernel.org/r/20251205-ucsi-v5-1-488eb89bc9b8@chromium.org Changes in v5: - Hold the lock of each connector during the initialization to avoid race condition between initialization and other event handler - Add Fixes tag - Link to v4: https://lore.kernel.org/r/20251125-ucsi-v4-1-8c94568ddaa5@chromium.org Changes in v4: - Handle a single connector in ucsi_init_port() and call it in a loop - Link to v3: https://lore.kernel.org/r/20251121-ucsi-v3-1-b1047ca371b8@chromium.org Changes in v3: - Seperate the status checking part into a new function called ucsi_init_port() and call it after enabling the notifications - Link to v2: https://lore.kernel.org/r/20251118-ucsi-v2-1-d314d50333e2@chromium.org Changes in v2: - Remove unnecessary braces. - Link to v1: https://lore.kernel.org/r/20251117-ucsi-v1-1-1dcbc5ea642b@chromium.org --- drivers/usb/typec/ucsi/ucsi.c | 131 +++++++++++++++++++++++------------------- 1 file changed, 73 insertions(+), 58 deletions(-) diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c index 3f568f790f39b0271667e80816270274b8dd3008..3a0471fa4cc980c0512bc71776e3984e6cd2cdb7 100644 --- a/drivers/usb/typec/ucsi/ucsi.c +++ b/drivers/usb/typec/ucsi/ucsi.c @@ -1560,11 +1560,70 @@ static struct fwnode_handle *ucsi_find_fwnode(struct ucsi_connector *con) return NULL; } +static void ucsi_init_port(struct ucsi *ucsi, struct ucsi_connector *con) +{ + enum usb_role u_role = USB_ROLE_NONE; + int ret; + + /* Get the status */ + ret = ucsi_get_connector_status(con, false); + if (ret) { + dev_err(ucsi->dev, "con%d: failed to get status\n", con->num); + return; + } + + if (ucsi->ops->connector_status) + ucsi->ops->connector_status(con); + + switch (UCSI_CONSTAT(con, PARTNER_TYPE)) { + case UCSI_CONSTAT_PARTNER_TYPE_UFP: + case UCSI_CONSTAT_PARTNER_TYPE_CABLE_AND_UFP: + u_role = USB_ROLE_HOST; + fallthrough; + case UCSI_CONSTAT_PARTNER_TYPE_CABLE: + typec_set_data_role(con->port, TYPEC_HOST); + break; + case UCSI_CONSTAT_PARTNER_TYPE_DFP: + u_role = USB_ROLE_DEVICE; + typec_set_data_role(con->port, TYPEC_DEVICE); + break; + default: + break; + } + + /* Check if there is already something connected */ + if (UCSI_CONSTAT(con, CONNECTED)) { + typec_set_pwr_role(con->port, UCSI_CONSTAT(con, PWR_DIR)); + ucsi_register_partner(con); + ucsi_pwr_opmode_change(con); + ucsi_port_psy_changed(con); + if (con->ucsi->cap.features & UCSI_CAP_GET_PD_MESSAGE) + ucsi_get_partner_identity(con); + if (con->ucsi->cap.features & UCSI_CAP_CABLE_DETAILS) + ucsi_check_cable(con); + } + + /* Only notify USB controller if partner supports USB data */ + if (!(UCSI_CONSTAT(con, PARTNER_FLAG_USB))) + u_role = USB_ROLE_NONE; + + ret = usb_role_switch_set_role(con->usb_role_sw, u_role); + if (ret) + dev_err(ucsi->dev, "con:%d: failed to set usb role:%d\n", + con->num, u_role); + + if (con->partner && UCSI_CONSTAT(con, PWR_OPMODE) == UCSI_CONSTAT_PWR_OPMODE_PD) { + ucsi_register_device_pdos(con); + ucsi_get_src_pdos(con); + ucsi_check_altmodes(con); + ucsi_check_connector_capability(con); + } +} + static int ucsi_register_port(struct ucsi *ucsi, struct ucsi_connector *con) { struct typec_capability *cap = &con->typec_cap; enum typec_accessory *accessory = cap->accessory; - enum usb_role u_role = USB_ROLE_NONE; u64 command; char *name; int ret; @@ -1659,62 +1718,6 @@ static int ucsi_register_port(struct ucsi *ucsi, struct ucsi_connector *con) goto out; } - /* Get the status */ - ret = ucsi_get_connector_status(con, false); - if (ret) { - dev_err(ucsi->dev, "con%d: failed to get status\n", con->num); - goto out; - } - - if (ucsi->ops->connector_status) - ucsi->ops->connector_status(con); - - switch (UCSI_CONSTAT(con, PARTNER_TYPE)) { - case UCSI_CONSTAT_PARTNER_TYPE_UFP: - case UCSI_CONSTAT_PARTNER_TYPE_CABLE_AND_UFP: - u_role = USB_ROLE_HOST; - fallthrough; - case UCSI_CONSTAT_PARTNER_TYPE_CABLE: - typec_set_data_role(con->port, TYPEC_HOST); - break; - case UCSI_CONSTAT_PARTNER_TYPE_DFP: - u_role = USB_ROLE_DEVICE; - typec_set_data_role(con->port, TYPEC_DEVICE); - break; - default: - break; - } - - /* Check if there is already something connected */ - if (UCSI_CONSTAT(con, CONNECTED)) { - typec_set_pwr_role(con->port, UCSI_CONSTAT(con, PWR_DIR)); - ucsi_register_partner(con); - ucsi_pwr_opmode_change(con); - ucsi_port_psy_changed(con); - if (con->ucsi->cap.features & UCSI_CAP_GET_PD_MESSAGE) - ucsi_get_partner_identity(con); - if (con->ucsi->cap.features & UCSI_CAP_CABLE_DETAILS) - ucsi_check_cable(con); - } - - /* Only notify USB controller if partner supports USB data */ - if (!(UCSI_CONSTAT(con, PARTNER_FLAG_USB))) - u_role = USB_ROLE_NONE; - - ret = usb_role_switch_set_role(con->usb_role_sw, u_role); - if (ret) { - dev_err(ucsi->dev, "con:%d: failed to set usb role:%d\n", - con->num, u_role); - ret = 0; - } - - if (con->partner && UCSI_CONSTAT(con, PWR_OPMODE) == UCSI_CONSTAT_PWR_OPMODE_PD) { - ucsi_register_device_pdos(con); - ucsi_get_src_pdos(con); - ucsi_check_altmodes(con); - ucsi_check_connector_capability(con); - } - trace_ucsi_register_port(con->num, con); out: @@ -1823,16 +1826,28 @@ static int ucsi_init(struct ucsi *ucsi) goto err_unregister; } + /* Delay other interactions with each connector until ucsi_init_port is done */ + for (i = 0; i < ucsi->cap.num_connectors; i++) + mutex_lock(&connector[i].lock); + /* Enable all supported notifications */ ntfy = ucsi_get_supported_notifications(ucsi); command = UCSI_SET_NOTIFICATION_ENABLE | ntfy; ret = ucsi_send_command(ucsi, command, NULL, 0); - if (ret < 0) + if (ret < 0) { + for (i = 0; i < ucsi->cap.num_connectors; i++) + mutex_unlock(&connector[i].lock); goto err_unregister; + } ucsi->connector = connector; ucsi->ntfy = ntfy; + for (i = 0; i < ucsi->cap.num_connectors; i++) { + ucsi_init_port(ucsi, &connector[i]); + mutex_unlock(&connector[i].lock); + } + mutex_lock(&ucsi->ppm_lock); ret = ucsi->ops->read_cci(ucsi, &cci); mutex_unlock(&ucsi->ppm_lock); --- base-commit: 2061f18ad76ecaddf8ed17df81b8611ea88dbddd change-id: 20251117-ucsi-c2dfe8c006d7 Best regards, -- Hsin-Te Yuan <yuanhsinte(a)chromium.org>

1 week, 3 days

2
1
0 0

[PATCH v3] gpio: regmap: Fix memleak in gpio_remap_register

by Wentao Guan

We should call gpiochip_remove(chip) to free the resource alloced by gpiochip_add_data(chip, gpio) after the err path. Fixes: 553b75d4bfe9 ("gpio: regmap: Allow to allocate regmap-irq device") Fixes: ae495810cffe ("gpio: regmap: add the .fixed_direction_output configuration parameter") CC: stable(a)vger.kernel.org Co-developed-by: WangYuli <wangyl5933(a)chinaunicom.cn> Signed-off-by: WangYuli <wangyl5933(a)chinaunicom.cn> Signed-off-by: Wentao Guan <guanwentao(a)uniontech.com> --- changelog in v3: Add dependency fixes tag which suggested by Andy Shevchenko. changelog in v2: 1. format commit message. 2. rebase to mainline now. --- --- drivers/gpio/gpio-regmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c index f4267af00027e..c64805dcb9f88 100644 --- a/drivers/gpio/gpio-regmap.c +++ b/drivers/gpio/gpio-regmap.c @@ -328,7 +328,7 @@ struct gpio_regmap *gpio_regmap_register(const struct gpio_regmap_config *config config->regmap_irq_line, config->regmap_irq_flags, 0, config->regmap_irq_chip, &gpio->irq_chip_data); if (ret) - goto err_free_bitmap; + goto err_remove_gpiochip; irq_domain = regmap_irq_get_domain(gpio->irq_chip_data); } else -- 2.20.1

1 week, 3 days

3
2
0 0

[PATCH v3 2/3] kasan: Refactor pcpu kasan vmalloc unpoison

by Maciej Wieczor-Retman

From: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> A KASAN tag mismatch, possibly causing a kernel panic, can be observed on systems with a tag-based KASAN enabled and with multiple NUMA nodes. It was reported on arm64 and reproduced on x86. It can be explained in the following points: 1. There can be more than one virtual memory chunk. 2. Chunk's base address has a tag. 3. The base address points at the first chunk and thus inherits the tag of the first chunk. 4. The subsequent chunks will be accessed with the tag from the first chunk. 5. Thus, the subsequent chunks need to have their tag set to match that of the first chunk. Refactor code by reusing __kasan_unpoison_vmalloc in a new helper in preparation for the actual fix. Changelog v1 (after splitting of from the KASAN series): - Rewrite first paragraph of the patch message to point at the user impact of the issue. - Move helper to common.c so it can be compiled in all KASAN modes. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: <stable(a)vger.kernel.org> # 6.1+ Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> --- Changelog v3: - Redo the patch after applying Andrey's comments to align the code more with what's already in include/linux/kasan.h Changelog v2: - Redo the whole patch so it's an actual refactor. include/linux/kasan.h | 15 +++++++++++++++ mm/kasan/common.c | 17 +++++++++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 33 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index 6d7972bb390c..cde493cb7702 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -615,6 +615,16 @@ static __always_inline void kasan_poison_vmalloc(const void *start, __kasan_poison_vmalloc(start, size); } +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags); +static __always_inline void +kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ + if (kasan_enabled()) + __kasan_unpoison_vmap_areas(vms, nr_vms, flags); +} + #else /* CONFIG_KASAN_VMALLOC */ static inline void kasan_populate_early_vm_area_shadow(void *start, @@ -639,6 +649,11 @@ static inline void *kasan_unpoison_vmalloc(const void *start, static inline void kasan_poison_vmalloc(const void *start, unsigned long size) { } +static __always_inline void +kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ } + #endif /* CONFIG_KASAN_VMALLOC */ #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ diff --git a/mm/kasan/common.c b/mm/kasan/common.c index d4c14359feaf..1ed6289d471a 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -28,6 +28,7 @@ #include <linux/string.h> #include <linux/types.h> #include <linux/bug.h> +#include <linux/vmalloc.h> #include "kasan.h" #include "../slab.h" @@ -582,3 +583,19 @@ bool __kasan_check_byte(const void *address, unsigned long ip) } return true; } + +#ifdef CONFIG_KASAN_VMALLOC +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, + kasan_vmalloc_flags_t flags) +{ + unsigned long size; + void *addr; + int area; + + for (area = 0 ; area < nr_vms ; area++) { + size = vms[area]->size; + addr = vms[area]->addr; + vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags); + } +} +#endif diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 22a73a087135..33e705ccafba 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4872,9 +4872,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets, * With hardware tag-based KASAN, marking is skipped for * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc(). */ - for (area = 0; area < nr_vms; area++) - vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr, - vms[area]->size, KASAN_VMALLOC_PROT_NORMAL); + kasan_unpoison_vmap_areas(vms, nr_vms, KASAN_VMALLOC_PROT_NORMAL); kfree(vas); return vms; -- 2.52.0

1 week, 3 days

3
2
0 0

6.17.9 / 6.18 AMDGPU DMCUB Error

by Neil Gammie

Hello all, please forgive me if this issue is already known, but I couldn't find any reference to it with regard to the 6.17.9 kernel. Anyway, when updating from 6.17.8 to 6.17.9, the following error is raised on every boot: Dec 04 14:44:20 P14s kernel: amdgpu: Topology: Add dGPU node [0x1638:0x1002] Dec 04 14:44:20 P14s kernel: kfd kfd: amdgpu: added device 1002:1638 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: Runtime PM not available Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: [drm] Using custom brightness curve Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: [drm] Registered 4 planes with drm panic Dec 04 14:44:20 P14s kernel: [drm] Initialized amdgpu 3.64.0 for 0000:07:00.0 on minor 1 Dec 04 14:44:20 P14s kernel: fbcon: amdgpudrmfb (fb0) is primary device Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data Dec 04 14:44:21 P14s kernel: amdgpu 0000:07:00.0: [drm] fb0: amdgpudrmfb frame buffer device Setup is as follows: Hardware: ThinkPad P14s Gen 2 AMD Processor: AMD Ryzen™ 7 PRO 5850U OS: Arch Linux AMD Firmware: linux-firmware-amdgpu 20251125 Running a bisection gives the following: git bisect start # status: waiting for both good and bad commits # good: [8ac42a63c561a8b4cccfe84ed8b97bb057e6ffae] Linux 6.17.8 git bisect good 8ac42a63c561a8b4cccfe84ed8b97bb057e6ffae # status: waiting for bad commit, 1 good commit known # bad: [1bfd0faa78d09eb41b81b002e0292db0f3e75de0] Linux 6.17.9 git bisect bad 1bfd0faa78d09eb41b81b002e0292db0f3e75de0 # bad: [92ef36a75fbb56a02a16b141fe684f64fb2b1cb9] lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN git bisect bad 92ef36a75fbb56a02a16b141fe684f64fb2b1cb9 # bad: [aaba523dd7b6106526c24b1fd9b5fc35e5aaa88d] sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto git bisect bad aaba523dd7b6106526c24b1fd9b5fc35e5aaa88d # bad: [b3b288206a1ea7e21472f8d1c7834ebface9bb33] drm/amdkfd: fix suspend/resume all calls in mes based eviction path git bisect bad b3b288206a1ea7e21472f8d1c7834ebface9bb33 # good: [ac486718d6cc96e07bc67094221e682ba5ea6f76] drm/amd/pm: Use pm_display_cfg in legacy DPM (v2) git bisect good ac486718d6cc96e07bc67094221e682ba5ea6f76 # bad: [1009f007b3afba93082599e263b3807d05177d53] RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid rfence errors git bisect bad 1009f007b3afba93082599e263b3807d05177d53 # bad: [ccd8af579101ca68f1fba8c9e055554202381cab] drm/amd: Disable ASPM on SI git bisect bad ccd8af579101ca68f1fba8c9e055554202381cab # bad: [e95425b6df29cc88fac7d0d77aa38a5a131dbf45] drm/amd/pm: Disable MCLK switching on SI at high pixel clocks git bisect bad e95425b6df29cc88fac7d0d77aa38a5a131dbf45 # bad: [5ee434b55134c24df7ad426d40fe28c6542fab4d] drm/amd/display: Disable fastboot on DCE 6 too git bisect bad 5ee434b55134c24df7ad426d40fe28c6542fab4d # first bad commit: [5ee434b55134c24df7ad426d40fe28c6542fab4d] drm/amd/display: Disable fastboot on DCE 6 too The error still occurs in 6.18, but reverting the above bad commit removes it. Although an error is reported, the system still boots to the graphical interface and appears to function normally, although I have neither benchmarked graphics performance or used the system for an extended period after the error has been flagged. Yours faithfully, Neil Gammie

1 week, 3 days

1
0
0 0

[PATCH 6.1.y] ksmbd: fix out-of-bounds in parse_sec_desc()

by Rajani Kantha

From: Namjae Jeon <linkinjeon(a)kernel.org> commit d6e13e19063db24f94b690159d0633aaf72a0f03 upstream. If osidoffset, gsidoffset and dacloffset could be greater than smb_ntsd struct size. If it is smaller, It could cause slab-out-of-bounds. And when validating sid, It need to check it included subauth array size. Cc: stable(a)vger.kernel.org Reported-by: Norbert Szetei <norbert(a)doyensec.com> Tested-by: Norbert Szetei <norbert(a)doyensec.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Rajani Kantha <681739313(a)139.com> --- fs/smb/server/smbacl.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/fs/smb/server/smbacl.c b/fs/smb/server/smbacl.c index 90c5e3edbf46..5c05f0e8b6ea 100644 --- a/fs/smb/server/smbacl.c +++ b/fs/smb/server/smbacl.c @@ -815,6 +815,13 @@ static int parse_sid(struct smb_sid *psid, char *end_of_acl) return -EINVAL; } + if (!psid->num_subauth) + return 0; + + if (psid->num_subauth > SID_MAX_SUB_AUTHORITIES || + end_of_acl < (char *)psid + 8 + sizeof(__le32) * psid->num_subauth) + return -EINVAL; + return 0; } @@ -856,6 +863,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, pntsd->type = cpu_to_le16(DACL_PRESENT); if (pntsd->osidoffset) { + if (le32_to_cpu(pntsd->osidoffset) < sizeof(struct smb_ntsd)) + return -EINVAL; + rc = parse_sid(owner_sid_ptr, end_of_acl); if (rc) { pr_err("%s: Error %d parsing Owner SID\n", __func__, rc); @@ -871,6 +881,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, } if (pntsd->gsidoffset) { + if (le32_to_cpu(pntsd->gsidoffset) < sizeof(struct smb_ntsd)) + return -EINVAL; + rc = parse_sid(group_sid_ptr, end_of_acl); if (rc) { pr_err("%s: Error %d mapping Owner SID to gid\n", @@ -892,6 +905,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, pntsd->type |= cpu_to_le16(DACL_PROTECTED); if (dacloffset) { + if (dacloffset < sizeof(struct smb_ntsd)) + return -EINVAL; + parse_dacl(user_ns, dacl_ptr, end_of_acl, owner_sid_ptr, group_sid_ptr, fattr); } -- 2.17.1

1 week, 3 days

1
0
0 0

[PATCH 6.1] net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()

by Chen Yu

From: Vladimir Oltean <vladimir.oltean(a)nxp.com> [ Upstream commit 5f2b28b79d2d1946ee36ad8b3dc0066f73c90481 ] There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page. Fixes: 6666cebc5e30 ("net: dsa: sja1105: Add support for VLAN operations") Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250318115716.2124395-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Chen Yu <xnguchen(a)sina.cn> --- drivers/net/dsa/sja1105/sja1105_static_config.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/dsa/sja1105/sja1105_static_config.c index baba204ad62f..2ac91fe2a79b 100644 --- a/drivers/net/dsa/sja1105/sja1105_static_config.c +++ b/drivers/net/dsa/sja1105/sja1105_static_config.c @@ -1921,8 +1921,10 @@ int sja1105_table_delete_entry(struct sja1105_table *table, int i) if (i > table->entry_count) return -ERANGE; - memmove(entries + i * entry_size, entries + (i + 1) * entry_size, - (table->entry_count - i) * entry_size); + if (i + 1 < table->entry_count) { + memmove(entries + i * entry_size, entries + (i + 1) * entry_size, + (table->entry_count - i - 1) * entry_size); + } table->entry_count--; -- 2.17.1

1 week, 3 days

1
0
0 0

[PATCH v2 1/3] dm-pcache: advance slot index before writing slot

by Dongsheng Yang

In dm-pcache, in order to ensure crash-consistency, a dual-copy scheme is used to alternately update metadata, and there is a slot index that records the current slot. However, in the write path the current implementation writes directly to the current slot indexed by slot index, and then advances the slot — which ends up overwriting the existing slot, violating the crash-consistency guarantee. This patch fixes that behavior, preventing metadata from being overwritten incorrectly. In addition, this patch add a missing pmem_wmb() after memcpy_flushcache(). Signed-off-by: Dongsheng Yang <dongsheng.yang(a)linux.dev> Reviewed-by: Zheng Gu <cengku(a)gmail.com> Cc: stable(a)vger.kernel.org # 6.18 --- drivers/md/dm-pcache/cache.c | 8 ++++---- drivers/md/dm-pcache/cache_segment.c | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/md/dm-pcache/cache.c b/drivers/md/dm-pcache/cache.c index 698697a7a73c..d4385d76ac36 100644 --- a/drivers/md/dm-pcache/cache.c +++ b/drivers/md/dm-pcache/cache.c @@ -21,10 +21,10 @@ static void cache_info_write(struct pcache_cache *cache) cache_info->header.crc = pcache_meta_crc(&cache_info->header, sizeof(struct pcache_cache_info)); + cache->info_index = (cache->info_index + 1) % PCACHE_META_INDEX_MAX; memcpy_flushcache(get_cache_info_addr(cache), cache_info, sizeof(struct pcache_cache_info)); - - cache->info_index = (cache->info_index + 1) % PCACHE_META_INDEX_MAX; + pmem_wmb(); } static void cache_info_init_default(struct pcache_cache *cache); @@ -93,10 +93,10 @@ void cache_pos_encode(struct pcache_cache *cache, pos_onmedia.header.seq = seq; pos_onmedia.header.crc = cache_pos_onmedia_crc(&pos_onmedia); + *index = (*index + 1) % PCACHE_META_INDEX_MAX; + memcpy_flushcache(pos_onmedia_addr, &pos_onmedia, sizeof(struct pcache_cache_pos_onmedia)); pmem_wmb(); - - *index = (*index + 1) % PCACHE_META_INDEX_MAX; } int cache_pos_decode(struct pcache_cache *cache, diff --git a/drivers/md/dm-pcache/cache_segment.c b/drivers/md/dm-pcache/cache_segment.c index f0b58980806e..ae57cc261422 100644 --- a/drivers/md/dm-pcache/cache_segment.c +++ b/drivers/md/dm-pcache/cache_segment.c @@ -26,11 +26,11 @@ static void cache_seg_info_write(struct pcache_cache_segment *cache_seg) seg_info->header.seq++; seg_info->header.crc = pcache_meta_crc(&seg_info->header, sizeof(struct pcache_segment_info)); + cache_seg->info_index = (cache_seg->info_index + 1) % PCACHE_META_INDEX_MAX; + seg_info_addr = get_seg_info_addr(cache_seg); memcpy_flushcache(seg_info_addr, seg_info, sizeof(struct pcache_segment_info)); pmem_wmb(); - - cache_seg->info_index = (cache_seg->info_index + 1) % PCACHE_META_INDEX_MAX; mutex_unlock(&cache_seg->info_lock); } @@ -129,10 +129,10 @@ static void cache_seg_ctrl_write(struct pcache_cache_segment *cache_seg) cache_seg_gen.header.crc = pcache_meta_crc(&cache_seg_gen.header, sizeof(struct pcache_cache_seg_gen)); + cache_seg->gen_index = (cache_seg->gen_index + 1) % PCACHE_META_INDEX_MAX; + memcpy_flushcache(get_cache_seg_gen_addr(cache_seg), &cache_seg_gen, sizeof(struct pcache_cache_seg_gen)); pmem_wmb(); - - cache_seg->gen_index = (cache_seg->gen_index + 1) % PCACHE_META_INDEX_MAX; } static void cache_seg_ctrl_init(struct pcache_cache_segment *cache_seg) -- 2.43.0

1 week, 3 days

1
2
0 0

[PATCH AUTOSEL 6.18-6.17] crypto: ccp - Add support for PCI device 0x115A

by Sasha Levin

From: "Mario Limonciello (AMD)" <superm1(a)kernel.org> [ Upstream commit 9fc6290117259a8dbf8247cb54559df62fd1550f ] PCI device 0x115A is similar to pspv5, except it doesn't have platform access mailbox support. Signed-off-by: Mario Limonciello (AMD) <superm1(a)kernel.org> Acked-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Comprehensive Analysis ### 1. COMMIT MESSAGE ANALYSIS **Subject:** `crypto: ccp - Add support for PCI device 0x115A` **Key Information:** - PCI device 0x115A is a new AMD security processor variant - The commit message states it's "similar to pspv5, except it doesn't have platform access mailbox support" - Signed off by Mario Limonciello (AMD engineer) and Tom Lendacky (AMD) - Merged by Herbert Xu (crypto maintainer) **Tags Present:** - `Signed-off-by`: 3 (proper sign-off chain) - `Acked-by`: Tom Lendacky (driver maintainer acknowledgment) - **NO** `Cc: stable(a)vger.kernel.org` tag - **NO** `Fixes:` tag (this is expected - it's not fixing a bug, it's enabling hardware) ### 2. CODE CHANGE ANALYSIS The commit adds: **A) New `pspv7` structure (~10 lines):** ```c static const struct psp_vdata pspv7 = { .tee = &teev2, .cmdresp_reg = 0x10944, .cmdbuff_addr_lo_reg = 0x10948, .cmdbuff_addr_hi_reg = 0x1094c, .bootloader_info_reg = 0x109ec, .feature_reg = 0x109fc, .inten_reg = 0x10510, .intsts_reg = 0x10514, }; ``` This is **identical to pspv5** except it omits the `.platform_access = &pa_v2` field. This is the explicit difference mentioned in the commit message. **B) New `dev_vdata[9]` entry (~6 lines):** ```c { /* 9 */ .bar = 2, #ifdef CONFIG_CRYPTO_DEV_SP_PSP .psp_vdata = &pspv7, #endif }, ``` **C) New PCI device ID entry (1 line):** ```c { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] }, ``` ### 3. CLASSIFICATION **This is a NEW DEVICE ID addition** - one of the explicitly allowed exceptions for stable kernel backports. The commit: - Does NOT add new features or APIs - Does NOT change existing behavior - Only enables existing PSP driver functionality on new hardware - Uses established patterns already in the driver ### 4. SCOPE AND RISK ASSESSMENT **Change size:** ~17 lines total - Small, contained data-only change - No logic changes whatsoever - Follows identical patterns used by existing pspv1-pspv6 structures **Risk assessment: VERY LOW** - The driver already handles NULL `platform_access` - verified in `psp- dev.c`: ```c if (psp->vdata->platform_access) { ret = platform_access_dev_init(psp); ... } ``` - Several existing structures (pspv1, pspv4, pspv6) already omit `platform_access` - The `teev2` structure referenced already exists since v6.5 - All register offsets are identical to pspv5 ### 5. USER IMPACT **Who is affected:** - Users with AMD PCI device 0x115A (new AMD security processor variant) - Without this patch, this hardware is completely non-functional **Severity:** HIGH for affected users - enables critical security hardware (TPM-like functionality) ### 6. STABILITY INDICATORS **Positive signals:** - Acked by Tom Lendacky (the original driver author and AMD maintainer) - Follows exact same pattern as 10+ previous device ID additions in this driver - Same author (Mario Limonciello) has successfully added similar devices before (0x17E0, 0x156E, etc.) ### 7. DEPENDENCY CHECK **Required in stable tree:** - `teev2` structure - added in v6.5 (commit 4aa0931be8f0a) - Verified present in v6.6 and later **Recent related commits:** - 52e8ae868a824: "Add missing bootloader info reg for pspv5" (May 2025) - 72942d6538564: "Add missing tee info reg for teev2" (May 2025) The pspv7 structure in this commit already includes the `bootloader_info_reg` correctly, so it was created after these fixes. ### 8. COMPARISON WITH SIMILAR COMMITS This commit follows the exact same pattern as: - `bb4185e595e47`: "Add support for PCI device 0x156E" - Added pspv6 + dev_vdata[8] + PCI ID - `4aa0931be8f0a`: "Add support for PCI device 0x17E0" - Added pspv5/teev2 + dev_vdata[7] + PCI ID - `6cb345939b8cc`: "Add support for PCI device 0x1134" - Added PCI ID only - `63935e2ee1f2a`: "Add support for PCI device 0x17D8" - Added PCI ID only These similar device ID additions are routinely considered for stable trees. --- ## Final Assessment **Should this be backported?** **YES**, for the following reasons: 1. **Falls under the NEW DEVICE ID exception** - explicitly allowed per stable kernel rules for enabling real hardware 2. **Trivial, data-only change** - ~17 lines, no logic changes 3. **Uses existing, proven infrastructure** - teev2 exists, NULL platform_access handling exists 4. **Follows established patterns** - identical to 10+ previous similar commits in this driver 5. **Zero risk of regression** - only affects users with the specific 0x115A device 6. **Enables real hardware** - without this, users with this AMD security processor cannot use it at all 7. **Properly reviewed** - Acked by AMD maintainer, merged by crypto subsystem maintainer **Concerns:** - Requires stable tree to have v6.6+ (for teev2 structure) - May need the bootloader_info_reg fixes backported first for consistency (commits 52e8ae868a824 and 72942d6538564) The change is obviously correct, well-tested (used same patterns as existing code), and enables hardware support that users need. This is exactly the type of device ID addition that stable trees accept. **YES** drivers/crypto/ccp/sp-pci.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c index e7bb803912a6d..8891ceee1d7d0 100644 --- a/drivers/crypto/ccp/sp-pci.c +++ b/drivers/crypto/ccp/sp-pci.c @@ -459,6 +459,17 @@ static const struct psp_vdata pspv6 = { .intsts_reg = 0x10514, /* P2CMSG_INTSTS */ }; +static const struct psp_vdata pspv7 = { + .tee = &teev2, + .cmdresp_reg = 0x10944, /* C2PMSG_17 */ + .cmdbuff_addr_lo_reg = 0x10948, /* C2PMSG_18 */ + .cmdbuff_addr_hi_reg = 0x1094c, /* C2PMSG_19 */ + .bootloader_info_reg = 0x109ec, /* C2PMSG_59 */ + .feature_reg = 0x109fc, /* C2PMSG_63 */ + .inten_reg = 0x10510, /* P2CMSG_INTEN */ + .intsts_reg = 0x10514, /* P2CMSG_INTSTS */ +}; + #endif static const struct sp_dev_vdata dev_vdata[] = { @@ -525,6 +536,13 @@ static const struct sp_dev_vdata dev_vdata[] = { .psp_vdata = &pspv6, #endif }, + { /* 9 */ + .bar = 2, +#ifdef CONFIG_CRYPTO_DEV_SP_PSP + .psp_vdata = &pspv7, +#endif + }, + }; static const struct pci_device_id sp_pci_table[] = { { PCI_VDEVICE(AMD, 0x1537), (kernel_ulong_t)&dev_vdata[0] }, @@ -539,6 +557,7 @@ static const struct pci_device_id sp_pci_table[] = { { PCI_VDEVICE(AMD, 0x17E0), (kernel_ulong_t)&dev_vdata[7] }, { PCI_VDEVICE(AMD, 0x156E), (kernel_ulong_t)&dev_vdata[8] }, { PCI_VDEVICE(AMD, 0x17D8), (kernel_ulong_t)&dev_vdata[8] }, + { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] }, /* Last entry must be zero */ { 0, } }; -- 2.51.0

1 week, 3 days

1
2
0 0

[PATCH] hwmon: (dell-smm): Fix off-by-one error in dell_smm_is_visible()

by Armin Wolf

The documentation states that on machines supporting only global fan mode control, the pwmX_enable attributes should only be created for the first fan channel (pwm1_enable, aka channel 0). Fix the off-by-one error caused by the fact that fan channels have a zero-based index. Cc: stable(a)vger.kernel.org Fixes: 1c1658058c99 ("hwmon: (dell-smm) Add support for automatic fan mode") Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> --- drivers/hwmon/dell-smm-hwmon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c index 683baf361c4c..a34753fc2973 100644 --- a/drivers/hwmon/dell-smm-hwmon.c +++ b/drivers/hwmon/dell-smm-hwmon.c @@ -861,9 +861,9 @@ static umode_t dell_smm_is_visible(const void *drvdata, enum hwmon_sensor_types if (auto_fan) { /* * The setting affects all fans, so only create a - * single attribute. + * single attribute for the first fan channel. */ - if (channel != 1) + if (channel != 0) return 0; /* -- 2.39.5

1 week, 3 days

2
1
0 0

[PATCH] hwmon: (w83791d) Convert macros to functions to avoid TOCTOU

by Gui-Dong Han

The macro FAN_FROM_REG evaluates its arguments multiple times. When used in lockless contexts involving shared driver data, this leads to Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially causing divide-by-zero errors. Convert the macro to a static function. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions. Additionally, in store_fan_div, move the calculation of the minimum limit inside the update lock. This ensures that the read-modify-write sequence operates on consistent data. Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts. Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z… Fixes: 9873964d6eb2 ("[PATCH] HWMON: w83791d: New hardware monitoring driver for the Winbond W83791D") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> --- Based on the discussion in the link, I will submit a series of patches to address TOCTOU issues in the hwmon subsystem by converting macros to functions or adjusting locking where appropriate. --- drivers/hwmon/w83791d.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/hwmon/w83791d.c b/drivers/hwmon/w83791d.c index ace854b370a0..996e36951f9d 100644 --- a/drivers/hwmon/w83791d.c +++ b/drivers/hwmon/w83791d.c @@ -218,9 +218,14 @@ static u8 fan_to_reg(long rpm, int div) return clamp_val((1350000 + rpm * div / 2) / (rpm * div), 1, 254); } -#define FAN_FROM_REG(val, div) ((val) == 0 ? -1 : \ - ((val) == 255 ? 0 : \ - 1350000 / ((val) * (div)))) +static int fan_from_reg(int val, int div) +{ + if (val == 0) + return -1; + if (val == 255) + return 0; + return 1350000 / (val * div); +} /* for temp1 which is 8-bit resolution, LSB = 1 degree Celsius */ #define TEMP1_FROM_REG(val) ((val) * 1000) @@ -521,7 +526,7 @@ static ssize_t show_##reg(struct device *dev, struct device_attribute *attr, \ struct w83791d_data *data = w83791d_update_device(dev); \ int nr = sensor_attr->index; \ return sprintf(buf, "%d\n", \ - FAN_FROM_REG(data->reg[nr], DIV_FROM_REG(data->fan_div[nr]))); \ + fan_from_reg(data->reg[nr], DIV_FROM_REG(data->fan_div[nr]))); \ } show_fan_reg(fan); @@ -585,10 +590,10 @@ static ssize_t store_fan_div(struct device *dev, struct device_attribute *attr, if (err) return err; + mutex_lock(&data->update_lock); /* Save fan_min */ - min = FAN_FROM_REG(data->fan_min[nr], DIV_FROM_REG(data->fan_div[nr])); + min = fan_from_reg(data->fan_min[nr], DIV_FROM_REG(data->fan_div[nr])); - mutex_lock(&data->update_lock); data->fan_div[nr] = div_to_reg(nr, val); switch (nr) { -- 2.43.0

1 week, 3 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror