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

[PATCH RFC 2/2] usb: typec: ucsi: increase timeout for PPM reset operations

by Fedor Pchelkin

It is observed that on some systems an initial PPM reset during the boot phase can trigger a timeout: [ 6.482546] ucsi_acpi USBC000:00: failed to reset PPM! [ 6.482551] ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed Still, increasing the timeout value, albeit being the most straightforward solution, eliminates the problem: the initial PPM reset may take up to ~8000-10000ms on some Lenovo laptops. When it is reset after the above period of time (or even if ucsi_reset_ppm() is not called overall), UCSI works as expected. Moreover, if the ucsi_acpi module is loaded/unloaded manually after the system has booted, reading the CCI values and resetting the PPM works perfectly, without any timeout. Thus it's only a boot-time issue. The reason for this behavior is not clear but it may be the consequence of some tricks that the firmware performs or be an actual firmware bug. As a workaround, increase the timeout to avoid failing the UCSI initialization prematurely. Fixes: b1b59e16075f ("usb: typec: ucsi: Increase command completion timeout value") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <boddah8794(a)gmail.com> --- drivers/usb/typec/ucsi/ucsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c index 0fe1476f4c29..7a56d3f840d7 100644 --- a/drivers/usb/typec/ucsi/ucsi.c +++ b/drivers/usb/typec/ucsi/ucsi.c @@ -25,7 +25,7 @@ * difficult to estimate the time it takes for the system to process the command * before it is actually passed to the PPM. */ -#define UCSI_TIMEOUT_MS 5000 +#define UCSI_TIMEOUT_MS 10000 /* * UCSI_SWAP_TIMEOUT_MS - Timeout for role swap requests -- 2.48.1

4 days, 15 hours

4
5
0 0

[PATCH vhost] vdpa/mlx5: Fix oversized null mkey longer than 32bit

by Dragos Tatulea

From: Si-Wei Liu <si-wei.liu(a)oracle.com> create_user_mr() has correct code to count the number of null keys used to fill in a hole for the memory map. However, fill_indir() does not follow the same to cap the range up to the 1GB limit correspondinly. Fill in more null keys for the gaps in between, so that null keys are correctly populated. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Cc: stable(a)vger.kernel.org Signed-off-by: Si-Wei Liu <si-wei.liu(a)oracle.com> Signed-off-by: Dragos Tatulea <dtatulea(a)nvidia.com> --- drivers/vdpa/mlx5/core/mr.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c index 8455f08f5d40..61424342c096 100644 --- a/drivers/vdpa/mlx5/core/mr.c +++ b/drivers/vdpa/mlx5/core/mr.c @@ -190,9 +190,12 @@ static void fill_indir(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *mkey, v klm->bcount = cpu_to_be32(klm_bcount(dmr->end - dmr->start)); preve = dmr->end; } else { + u64 bcount = min_t(u64, dmr->start - preve, MAX_KLM_SIZE); + klm->key = cpu_to_be32(mvdev->res.null_mkey); - klm->bcount = cpu_to_be32(klm_bcount(dmr->start - preve)); - preve = dmr->start; + klm->bcount = cpu_to_be32(klm_bcount(bcount)); + preve += bcount; + goto again; } } -- 2.43.0

4 days, 15 hours

2
2
0 0

[REGRESSION] stable-rc/linux-6.1.y: (build) stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupport...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.1.y: --- stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] in drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.o (drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/issue/maestro:bd2798b6baf3af3d8f6fcf670eac9f5235e8b3… - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: c703a7b9b55f8b3d701c14cd8d841ead509baa08 Log excerpt: ===================================================== drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3795:6: error: stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] 3795 | void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ 1 error generated. ===================================================== # Builds where the incident occurred: ## x86_64_defconfig on (x86_64): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:67b4a3dc50b59caecce1cb05 #kernelci issue maestro:bd2798b6baf3af3d8f6fcf670eac9f5235e8b3a6 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

4 days, 15 hours

1
0
0 0

[PATCH 2/5] ftrace: Do not add duplicate entries in subops manager ops

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> Check if a function is already in the manager ops of a subops. A manager ops contains multiple subops, and if two or more subops are tracing the same function, the manager ops only needs a single entry in its hash. Cc: stable(a)vger.kernel.org Fixes: 4f554e955614f ("ftrace: Add ftrace_set_filter_ips function") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ftrace.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 03b35a05808c..189eb0a12f4b 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -5717,6 +5717,9 @@ __ftrace_match_addr(struct ftrace_hash *hash, unsigned long ip, int remove) return -ENOENT; free_hash_entry(hash, entry); return 0; + } else if (__ftrace_lookup_ip(hash, ip) != NULL) { + /* Already exists */ + return 0; } entry = add_hash_entry(hash, ip); -- 2.47.2

4 days, 15 hours

1
0
0 0

[PATCH 1/5] ftrace: Fix accounting of adding subops to a manager ops

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> Function graph uses a subops and manager ops mechanism to attach to ftrace. The manager ops connects to ftrace and the functions it connects to is defined by a list of subops that it manages. The function hash that defines what the above ops attaches to limits the functions to attach if the hash has any content. If the hash is empty, it means to trace all functions. The creation of the manager ops hash is done by iterating over all the subops hashes. If any of the subops hashes is empty, it means that the manager ops hash must trace all functions as well. The issue is in the creation of the manager ops. When a second subops is attached, a new hash is created by starting it as NULL and adding the subops one at a time. But the NULL ops is mistaken as an empty hash, and once an empty hash is found, it stops the loop of subops and just enables all functions. # echo "f:myevent1 kernel_clone" >> /sys/kernel/tracing/dynamic_events # cat /sys/kernel/tracing/enabled_functions kernel_clone (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 # echo "f:myevent2 schedule_timeout" >> /sys/kernel/tracing/dynamic_events # cat /sys/kernel/tracing/enabled_functions trace_initcall_start_cb (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 run_init_process (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 try_to_run_init_process (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 x86_pmu_show_pmu_cap (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 cleanup_rapl_pmus (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 uncore_free_pcibus_map (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 uncore_types_exit (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 uncore_pci_exit.part.0 (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 kvm_shutdown (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 vmx_dump_msrs (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 vmx_cleanup_l1d_flush (1) tramp: 0xffffffffc0309000 (ftrace_graph_func+0x0/0x60) ->ftrace_graph_func+0x0/0x60 [..] Fix this by initializing the new hash to NULL and if the hash is NULL do not treat it as an empty hash but instead allocate by copying the content of the first sub ops. Then on subsequent iterations, the new hash will not be NULL, but the content of the previous subops. If that first subops attached to all functions, then new hash may assume that the manager ops also needs to attach to all functions. Cc: stable(a)vger.kernel.org Fixes: 5fccc7552ccbc ("ftrace: Add subops logic to allow one ops to manage many") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ftrace.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 728ecda6e8d4..03b35a05808c 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -3220,15 +3220,22 @@ static struct ftrace_hash *copy_hash(struct ftrace_hash *src) * The filter_hash updates uses just the append_hash() function * and the notrace_hash does not. */ -static int append_hash(struct ftrace_hash **hash, struct ftrace_hash *new_hash) +static int append_hash(struct ftrace_hash **hash, struct ftrace_hash *new_hash, + int size_bits) { struct ftrace_func_entry *entry; int size; int i; - /* An empty hash does everything */ - if (ftrace_hash_empty(*hash)) - return 0; + if (*hash) { + /* An empty hash does everything */ + if (ftrace_hash_empty(*hash)) + return 0; + } else { + *hash = alloc_ftrace_hash(size_bits); + if (!*hash) + return -ENOMEM; + } /* If new_hash has everything make hash have everything */ if (ftrace_hash_empty(new_hash)) { @@ -3292,16 +3299,18 @@ static int intersect_hash(struct ftrace_hash **hash, struct ftrace_hash *new_has /* Return a new hash that has a union of all @ops->filter_hash entries */ static struct ftrace_hash *append_hashes(struct ftrace_ops *ops) { - struct ftrace_hash *new_hash; + struct ftrace_hash *new_hash = NULL; struct ftrace_ops *subops; + int size_bits; int ret; - new_hash = alloc_ftrace_hash(ops->func_hash->filter_hash->size_bits); - if (!new_hash) - return NULL; + if (ops->func_hash->filter_hash) + size_bits = ops->func_hash->filter_hash->size_bits; + else + size_bits = FTRACE_HASH_DEFAULT_BITS; list_for_each_entry(subops, &ops->subop_list, list) { - ret = append_hash(&new_hash, subops->func_hash->filter_hash); + ret = append_hash(&new_hash, subops->func_hash->filter_hash, size_bits); if (ret < 0) { free_ftrace_hash(new_hash); return NULL; @@ -3505,7 +3514,8 @@ int ftrace_startup_subops(struct ftrace_ops *ops, struct ftrace_ops *subops, int filter_hash = alloc_and_copy_ftrace_hash(size_bits, ops->func_hash->filter_hash); if (!filter_hash) return -ENOMEM; - ret = append_hash(&filter_hash, subops->func_hash->filter_hash); + ret = append_hash(&filter_hash, subops->func_hash->filter_hash, + size_bits); if (ret < 0) { free_ftrace_hash(filter_hash); return ret; -- 2.47.2

4 days, 15 hours

1
0
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) ./arch/mips/include/asm/syscall.h:66:28: error: ‘struct pt_regs’ h...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- ./arch/mips/include/asm/syscall.h:66:28: error: ‘struct pt_regs’ has no member named ‘args’ in arch/mips/kernel/ptrace.o (arch/mips/kernel/ptrace.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/issue/maestro:609e973861db59e6d6e75d96a9f0f0a24ba09b… - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 46b505f46fed8d28d9f0cf8e2aace766b99e48ce Log excerpt: ===================================================== In file included from arch/mips/kernel/ptrace.c:45: ./arch/mips/include/asm/syscall.h: In function ‘mips_get_syscall_arg’: ./arch/mips/include/asm/syscall.h:66:28: error: ‘struct pt_regs’ has no member named ‘args’ 66 | *arg = regs->args[n]; | ^~ ===================================================== # Builds where the incident occurred: ## 32r2el_defconfig on (mips): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:67b4a28b50b59caecce1c871 #kernelci issue maestro:609e973861db59e6d6e75d96a9f0f0a24ba09ba0 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

4 days, 17 hours

1
0
0 0

[PATCH v3] ACPI: platform-profile: Fix CFI violation when accessing sysfs files

by Nathan Chancellor

When an attribute group is created with sysfs_create_group(), the ->sysfs_ops() callback is set to kobj_sysfs_ops, which sets the ->show() and ->store() callbacks to kobj_attr_show() and kobj_attr_store() respectively. These functions use container_of() to get the respective callback from the passed attribute, meaning that these callbacks need to be the same type as the callbacks in 'struct kobj_attribute'. However, the platform_profile sysfs functions have the type of the ->show() and ->store() callbacks in 'struct device_attribute', which results a CFI violation when accessing platform_profile or platform_profile_choices under /sys/firmware/acpi because the types do not match: CFI failure at kobj_attr_show+0x19/0x30 (target: platform_profile_choices_show+0x0/0x140; expected type: 0x7a69590c) There is no functional issue from the type mismatch because the layout of 'struct kobj_attribute' and 'struct device_attribute' are the same, so the container_of() cast does not break anything aside from CFI. Change the type of platform_profile_choices_show() and platform_profile_{show,store}() to match the callbacks in 'struct kobj_attribute' and update the attribute variables to match, which resolves the CFI violation. Cc: stable(a)vger.kernel.org Fixes: a2ff95e018f1 ("ACPI: platform: Add platform profile support") Reported-by: John Rowley <lkml(a)johnrowley.me> Closes: https://github.com/ClangBuiltLinux/linux/issues/2047 Tested-by: John Rowley <lkml(a)johnrowley.me> Reviewed-by: Sami Tolvanen <samitolvanen(a)google.com> Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- Changes in v3: - Rebase on 6.14-rc1, which includes updates to the driver to address Greg's previous concerns but this change is still needed for the legacy sysfs interface. v2 can be used for the stable backport. - Link to v2: https://lore.kernel.org/r/20241118-acpi-platform_profile-fix-cfi-violation-… Changes in v2: - Rebase on linux-pm/acpi - Pick up Sami's reviewed-by tag - Adjust wording around why there is no functional issue from the mismatched types - Link to v1: https://lore.kernel.org/r/20240819-acpi-platform_profile-fix-cfi-violation-… --- drivers/acpi/platform_profile.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/acpi/platform_profile.c b/drivers/acpi/platform_profile.c index fc92e43d0fe9..1b6317f759f9 100644 --- a/drivers/acpi/platform_profile.c +++ b/drivers/acpi/platform_profile.c @@ -260,14 +260,14 @@ static int _aggregate_choices(struct device *dev, void *data) /** * platform_profile_choices_show - Show the available profile choices for legacy sysfs interface - * @dev: The device + * @kobj: The kobject * @attr: The attribute * @buf: The buffer to write to * * Return: The number of bytes written */ -static ssize_t platform_profile_choices_show(struct device *dev, - struct device_attribute *attr, +static ssize_t platform_profile_choices_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) { unsigned long aggregate[BITS_TO_LONGS(PLATFORM_PROFILE_LAST)]; @@ -333,14 +333,14 @@ static int _store_and_notify(struct device *dev, void *data) /** * platform_profile_show - Show the current profile for legacy sysfs interface - * @dev: The device + * @kobj: The kobject * @attr: The attribute * @buf: The buffer to write to * * Return: The number of bytes written */ -static ssize_t platform_profile_show(struct device *dev, - struct device_attribute *attr, +static ssize_t platform_profile_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) { enum platform_profile_option profile = PLATFORM_PROFILE_LAST; @@ -362,15 +362,15 @@ static ssize_t platform_profile_show(struct device *dev, /** * platform_profile_store - Set the profile for legacy sysfs interface - * @dev: The device + * @kobj: The kobject * @attr: The attribute * @buf: The buffer to read from * @count: The number of bytes to read * * Return: The number of bytes read */ -static ssize_t platform_profile_store(struct device *dev, - struct device_attribute *attr, +static ssize_t platform_profile_store(struct kobject *kobj, + struct kobj_attribute *attr, const char *buf, size_t count) { unsigned long choices[BITS_TO_LONGS(PLATFORM_PROFILE_LAST)]; @@ -401,12 +401,12 @@ static ssize_t platform_profile_store(struct device *dev, return count; } -static DEVICE_ATTR_RO(platform_profile_choices); -static DEVICE_ATTR_RW(platform_profile); +static struct kobj_attribute attr_platform_profile_choices = __ATTR_RO(platform_profile_choices); +static struct kobj_attribute attr_platform_profile = __ATTR_RW(platform_profile); static struct attribute *platform_profile_attrs[] = { - &dev_attr_platform_profile_choices.attr, - &dev_attr_platform_profile.attr, + &attr_platform_profile_choices.attr, + &attr_platform_profile.attr, NULL }; --- base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b change-id: 20240819-acpi-platform_profile-fix-cfi-violation-de278753bd5f Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

4 days, 17 hours

4
5
0 0

Re: Patch "s390/qeth: move netif_napi_add_tx() and napi_enable() from under BH" has been added to the 6.13-stable tree

by Alexandra Winter

On 18.02.25 13:36, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > s390/qeth: move netif_napi_add_tx() and napi_enable() from under BH > > to the 6.13-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > s390-qeth-move-netif_napi_add_tx-and-napi_enable-fro.patch > and it can be found in the queue-6.13 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > Hello Sasha, this is a fix for a regression that was introduced with v6.14-rc1. So I do not think it needs to go into 6.13 stable tree. But it does not hurt either. > > > commit 48eda8093b86b426078bd245a9b4fbc5d057c436 > Author: Alexandra Winter <wintera(a)linux.ibm.com> > Date: Wed Feb 12 17:36:59 2025 +0100 > > s390/qeth: move netif_napi_add_tx() and napi_enable() from under BH > > [ Upstream commit 0d0b752f2497471ddd2b32143d167d42e18a8f3c ] > > Like other drivers qeth is calling local_bh_enable() after napi_schedule() > to kick-start softirqs [0]. > Since netif_napi_add_tx() and napi_enable() now take the netdev_lock() > mutex [1], move them out from under the BH protection. Same solution as in > commit a60558644e20 ("wifi: mt76: move napi_enable() from under BH") > > Fixes: 1b23cdbd2bbc ("net: protect netdev->napi_list with netdev_lock()") > Link: https://lore.kernel.org/netdev/20240612181900.4d9d18d0@kernel.org/ [0] > Link: https://lore.kernel.org/netdev/20250115035319.559603-1-kuba@kernel.org/ [1] > Signed-off-by: Alexandra Winter <wintera(a)linux.ibm.com> > Acked-by: Joe Damato <jdamato(a)fastly.com> > Link: https://patch.msgid.link/20250212163659.2287292-1-wintera@linux.ibm.com > Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c > index a3adaec5504e4..20328d695ef92 100644 > --- a/drivers/s390/net/qeth_core_main.c > +++ b/drivers/s390/net/qeth_core_main.c > @@ -7050,14 +7050,16 @@ int qeth_open(struct net_device *dev) > card->data.state = CH_STATE_UP; > netif_tx_start_all_queues(dev); > > - local_bh_disable(); > qeth_for_each_output_queue(card, queue, i) { > netif_napi_add_tx(dev, &queue->napi, qeth_tx_poll); > napi_enable(&queue->napi); > - napi_schedule(&queue->napi); > } > - > napi_enable(&card->napi); > + > + local_bh_disable(); > + qeth_for_each_output_queue(card, queue, i) { > + napi_schedule(&queue->napi); > + } > napi_schedule(&card->napi); > /* kick-start the NAPI softirq: */ > local_bh_enable();

4 days, 18 hours

2
3
0 0

FAILED: patch "[PATCH] Revert "net: skb: introduce and use a single page frag cache"" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x 011b0335903832facca86cd8ed05d7d8d94c9c76 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025021859-renewal-onto-1877@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 011b0335903832facca86cd8ed05d7d8d94c9c76 Mon Sep 17 00:00:00 2001 From: Paolo Abeni <pabeni(a)redhat.com> Date: Thu, 6 Feb 2025 22:28:48 +0100 Subject: [PATCH] Revert "net: skb: introduce and use a single page frag cache" This reverts commit dbae2b062824 ("net: skb: introduce and use a single page frag cache"). The intended goal of such change was to counter a performance regression introduced by commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny skbs"). Unfortunately, the blamed commit introduces another regression for the virtio_net driver. Such a driver calls napi_alloc_skb() with a tiny size, so that the whole head frag could fit a 512-byte block. The single page frag cache uses a 1K fragment for such allocation, and the additional overhead, under small UDP packets flood, makes the page allocator a bottleneck. Thanks to commit bf9f1baa279f ("net: add dedicated kmem_cache for typical/small skb->head"), this revert does not re-introduce the original regression. Actually, in the relevant test on top of this revert, I measure a small but noticeable positive delta, just above noise level. The revert itself required some additional mangling due to the introduction of the SKB_HEAD_ALIGN() helper and local lock infra in the affected code. Suggested-by: Eric Dumazet <edumazet(a)google.com> Fixes: dbae2b062824 ("net: skb: introduce and use a single page frag cache") Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://patch.msgid.link/e649212fde9f0fdee23909ca0d14158d32bb7425.173887729… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index c0a86afb85da..365f0e2098d1 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -4115,7 +4115,6 @@ void netif_receive_skb_list(struct list_head *head); gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb); void napi_gro_flush(struct napi_struct *napi, bool flush_old); struct sk_buff *napi_get_frags(struct napi_struct *napi); -void napi_get_frags_check(struct napi_struct *napi); gro_result_t napi_gro_frags(struct napi_struct *napi); static inline void napi_free_frags(struct napi_struct *napi) diff --git a/net/core/dev.c b/net/core/dev.c index b91658e8aedb..55e356a68db6 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6920,6 +6920,23 @@ netif_napi_dev_list_add(struct net_device *dev, struct napi_struct *napi) list_add_rcu(&napi->dev_list, higher); /* adds after higher */ } +/* Double check that napi_get_frags() allocates skbs with + * skb->head being backed by slab, not a page fragment. + * This is to make sure bug fixed in 3226b158e67c + * ("net: avoid 32 x truesize under-estimation for tiny skbs") + * does not accidentally come back. + */ +static void napi_get_frags_check(struct napi_struct *napi) +{ + struct sk_buff *skb; + + local_bh_disable(); + skb = napi_get_frags(napi); + WARN_ON_ONCE(skb && skb->head_frag); + napi_free_frags(napi); + local_bh_enable(); +} + void netif_napi_add_weight_locked(struct net_device *dev, struct napi_struct *napi, int (*poll)(struct napi_struct *, int), diff --git a/net/core/skbuff.c b/net/core/skbuff.c index a441613a1e6c..6a99c453397f 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -220,67 +220,9 @@ static void skb_under_panic(struct sk_buff *skb, unsigned int sz, void *addr) #define NAPI_SKB_CACHE_BULK 16 #define NAPI_SKB_CACHE_HALF (NAPI_SKB_CACHE_SIZE / 2) -#if PAGE_SIZE == SZ_4K - -#define NAPI_HAS_SMALL_PAGE_FRAG 1 -#define NAPI_SMALL_PAGE_PFMEMALLOC(nc) ((nc).pfmemalloc) - -/* specialized page frag allocator using a single order 0 page - * and slicing it into 1K sized fragment. Constrained to systems - * with a very limited amount of 1K fragments fitting a single - * page - to avoid excessive truesize underestimation - */ - -struct page_frag_1k { - void *va; - u16 offset; - bool pfmemalloc; -}; - -static void *page_frag_alloc_1k(struct page_frag_1k *nc, gfp_t gfp) -{ - struct page *page; - int offset; - - offset = nc->offset - SZ_1K; - if (likely(offset >= 0)) - goto use_frag; - - page = alloc_pages_node(NUMA_NO_NODE, gfp, 0); - if (!page) - return NULL; - - nc->va = page_address(page); - nc->pfmemalloc = page_is_pfmemalloc(page); - offset = PAGE_SIZE - SZ_1K; - page_ref_add(page, offset / SZ_1K); - -use_frag: - nc->offset = offset; - return nc->va + offset; -} -#else - -/* the small page is actually unused in this build; add dummy helpers - * to please the compiler and avoid later preprocessor's conditionals - */ -#define NAPI_HAS_SMALL_PAGE_FRAG 0 -#define NAPI_SMALL_PAGE_PFMEMALLOC(nc) false - -struct page_frag_1k { -}; - -static void *page_frag_alloc_1k(struct page_frag_1k *nc, gfp_t gfp_mask) -{ - return NULL; -} - -#endif - struct napi_alloc_cache { local_lock_t bh_lock; struct page_frag_cache page; - struct page_frag_1k page_small; unsigned int skb_count; void *skb_cache[NAPI_SKB_CACHE_SIZE]; }; @@ -290,23 +232,6 @@ static DEFINE_PER_CPU(struct napi_alloc_cache, napi_alloc_cache) = { .bh_lock = INIT_LOCAL_LOCK(bh_lock), }; -/* Double check that napi_get_frags() allocates skbs with - * skb->head being backed by slab, not a page fragment. - * This is to make sure bug fixed in 3226b158e67c - * ("net: avoid 32 x truesize under-estimation for tiny skbs") - * does not accidentally come back. - */ -void napi_get_frags_check(struct napi_struct *napi) -{ - struct sk_buff *skb; - - local_bh_disable(); - skb = napi_get_frags(napi); - WARN_ON_ONCE(!NAPI_HAS_SMALL_PAGE_FRAG && skb && skb->head_frag); - napi_free_frags(napi); - local_bh_enable(); -} - void *__napi_alloc_frag_align(unsigned int fragsz, unsigned int align_mask) { struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache); @@ -813,10 +738,8 @@ struct sk_buff *napi_alloc_skb(struct napi_struct *napi, unsigned int len) /* If requested length is either too small or too big, * we use kmalloc() for skb->head allocation. - * When the small frag allocator is available, prefer it over kmalloc - * for small fragments */ - if ((!NAPI_HAS_SMALL_PAGE_FRAG && len <= SKB_WITH_OVERHEAD(1024)) || + if (len <= SKB_WITH_OVERHEAD(1024) || len > SKB_WITH_OVERHEAD(PAGE_SIZE) || (gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) { skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX | SKB_ALLOC_NAPI, @@ -826,32 +749,16 @@ struct sk_buff *napi_alloc_skb(struct napi_struct *napi, unsigned int len) goto skb_success; } + len = SKB_HEAD_ALIGN(len); + if (sk_memalloc_socks()) gfp_mask |= __GFP_MEMALLOC; local_lock_nested_bh(&napi_alloc_cache.bh_lock); nc = this_cpu_ptr(&napi_alloc_cache); - if (NAPI_HAS_SMALL_PAGE_FRAG && len <= SKB_WITH_OVERHEAD(1024)) { - /* we are artificially inflating the allocation size, but - * that is not as bad as it may look like, as: - * - 'len' less than GRO_MAX_HEAD makes little sense - * - On most systems, larger 'len' values lead to fragment - * size above 512 bytes - * - kmalloc would use the kmalloc-1k slab for such values - * - Builds with smaller GRO_MAX_HEAD will very likely do - * little networking, as that implies no WiFi and no - * tunnels support, and 32 bits arches. - */ - len = SZ_1K; - data = page_frag_alloc_1k(&nc->page_small, gfp_mask); - pfmemalloc = NAPI_SMALL_PAGE_PFMEMALLOC(nc->page_small); - } else { - len = SKB_HEAD_ALIGN(len); - - data = page_frag_alloc(&nc->page, len, gfp_mask); - pfmemalloc = page_frag_cache_is_pfmemalloc(&nc->page); - } + data = page_frag_alloc(&nc->page, len, gfp_mask); + pfmemalloc = page_frag_cache_is_pfmemalloc(&nc->page); local_unlock_nested_bh(&napi_alloc_cache.bh_lock); if (unlikely(!data))

4 days, 19 hours

2
2
0 0

[PATCH 0/2] vsock: fix use-after free and null-ptr-deref

by Luigi Leonardi

Hi all, This series contains two patches that are already available upstream: - The first commit fixes a use-after-free[1], but introduced a null-ptr-deref[2]. - The second commit fixes it. [3] I suggested waiting for both of them to be merged upstream and then applying them togheter to stable[4]. It should be applied to: - 6.13.y - 6.12.y - 6.6.y I will send another series for - 6.1.y - 5.15.y - 5.10.y because of conflicts. [1]https://lore.kernel.org/all/20250128-vsock-transport-vs-autobind-v3-0-1cf… [2]https://lore.kernel.org/all/67a09300.050a0220.d7c5a.008b.GAE@google.com/ [3]https://lore.kernel.org/all/20250210-vsock-linger-nullderef-v3-0-ef6244d0… [4]https://lore.kernel.org/all/2025020644-unwitting-scary-3c0d@gregkh/ Thanks, Luigi --- Michal Luczaj (2): vsock: Keep the binding until socket destruction vsock: Orphan socket after transport release net/vmw_vsock/af_vsock.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- base-commit: a1856aaa2ca74c88751f7d255dfa0c8c50fcc1ca change-id: 20250214-linux-rolling-stable-d73f0bed815d Best regards, -- Luigi Leonardi <leonardi(a)redhat.com>

4 days, 19 hours

3
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror