February 2024 - Linux-stable-mirror

[PATCH v2] arm64/signal: Don't assume that TIF_SVE means we saved SVE state

by Mark Brown

When we are in a syscall we will only save the FPSIMD subset even though the task still has access to the full register set, and on context switch we will only remove TIF_SVE when loading the register state. This means that the signal handling code should not assume that TIF_SVE means that the register state is stored in SVE format, it should instead check the format that was recorded during save. Fixes: 8c845e273104 ("arm64/sve: Leave SVE enabled on syscall if we don't context switch") Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- Changes in v2: - Rebase onto v6.8-rc2. - Link to v1: https://lore.kernel.org/r/20240119-arm64-sve-signal-regs-v1-1-b9fd61b0289a@… --- arch/arm64/kernel/fpsimd.c | 2 +- arch/arm64/kernel/signal.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index a5dc6f764195..25ceaee6b025 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1635,7 +1635,7 @@ void fpsimd_preserve_current_state(void) void fpsimd_signal_preserve_current_state(void) { fpsimd_preserve_current_state(); - if (test_thread_flag(TIF_SVE)) + if (current->thread.fp_type == FP_STATE_SVE) sve_to_fpsimd(current); } diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 0e8beb3349ea..425b1bc17a3f 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -242,7 +242,7 @@ static int preserve_sve_context(struct sve_context __user *ctx) vl = task_get_sme_vl(current); vq = sve_vq_from_vl(vl); flags |= SVE_SIG_FLAG_SM; - } else if (test_thread_flag(TIF_SVE)) { + } else if (current->thread.fp_type == FP_STATE_SVE) { vq = sve_vq_from_vl(vl); } @@ -878,7 +878,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user, if (system_supports_sve() || system_supports_sme()) { unsigned int vq = 0; - if (add_all || test_thread_flag(TIF_SVE) || + if (add_all || current->thread.fp_type == FP_STATE_SVE || thread_sm_enabled(&current->thread)) { int vl = max(sve_max_vl(), sme_max_vl()); --- base-commit: 41bccc98fb7931d63d03f326a746ac4d429c1dd3 change-id: 20240118-arm64-sve-signal-regs-5711e0d10425 Best regards, -- Mark Brown <broonie(a)kernel.org>

1 year

2
1
0 0

[regression 6.1.67] dlm: cannot start dlm midcomms -97 after backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")

by Salvatore Bonaccorso

Hi Valentin, hi all [This is about a regression reported in Debian for 6.1.67] On Tue, Feb 06, 2024 at 01:00:11PM +0100, Valentin Kleibel wrote: > Package: linux-image-amd64 > Version: 6.1.76+1 > Source: linux > Source-Version: 6.1.76+1 > Severity: important > Control: notfound -1 6.6.15-2 > > Dear Maintainers, > > We discovered a bug affecting dlm that prevents any tcp communications by > dlm when booted with debian kernel 6.1.76-1. > > Dlm startup works (corosync-cpgtool shows the dlm:controld group with all > expected nodes) but as soon as we try to add a lockspace dmesg shows: > ``` > dlm: Using TCP for communications > dlm: cannot start dlm midcomms -97 > ``` > > It seems that commit "dlm: use kernel_connect() and kernel_bind()" > (e9cdebbe) was merged to 6.1. > > Checking the code it seems that the changed function dlm_tcp_listen_bind() > fails with exit code 97 (EAFNOSUPPORT) > It is called from > > dlm/lockspace.c: threads_start() -> dlm_midcomms_start() > dlm/midcomms.c: dlm_midcomms_start() -> dlm_lowcomms_start() > dlm/lowcomms.c: dlm_lowcomms_start() -> dlm_listen_for_all() -> > dlm_proto_ops->listen_bind() = dlm_tcp_listen_bind() > > The error code is returned all the way to threads_start() where the error > message is emmitted. > > Booting with the unsigned kernel from testing (6.6.15-2), which also > contains this commit, works without issues. > > I'm not sure what additional changes are required to get this working or if > rolling back this change is an option. > > We'd be happy to test patches that might fix this issue. Thanks for your report. So we have a 6.1.76 specific regression for the backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()") . Let's loop in the upstream regression list for tracking and people involved for the subsystem to see if the issue can be identified. As it is working for 6.6.15 which includes the commit backport as well it might be very well that a prerequisite is missing. # annotate regression with 6.1.y specific commit #regzbot ^introduced e11dea8f503341507018b60906c4a9e7332f3663 #regzbot link: https://bugs.debian.org/1063338 Any ideas? Regards, Salvatore

1 year

4
8
0 0

[PATCH] drm/buddy: Fix alloc_range() error handling code

by Arunpravin Paneer Selvam

Few users have observed display corruption when they boot the machine to KDE Plasma or playing games. We have root caused the problem that whenever alloc_range() couldn't find the required memory blocks the function was returning SUCCESS in some of the corner cases. The right approach would be if the total allocated size is less than the required size, the function should return -ENOSPC. Cc: <stable(a)vger.kernel.org> # 6.7+ Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097 Tested-by: Mario Limonciello <mario.limonciello(a)amd.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-… Reviewed-by: Matthew Auld <matthew.auld(a)intel.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam(a)amd.com> --- drivers/gpu/drm/drm_buddy.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c index f57e6d74fb0e..c1a99bf4dffd 100644 --- a/drivers/gpu/drm/drm_buddy.c +++ b/drivers/gpu/drm/drm_buddy.c @@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm, } while (1); list_splice_tail(&allocated, blocks); + + if (total_allocated < size) { + err = -ENOSPC; + goto err_free; + } + return 0; err_undo: -- 2.25.1

1 year

1
0
0 0

[for-linus][PATCH 2/2] tracing: Fix wasted memory in saved_cmdlines logic

by Steven Rostedt

From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> While looking at improving the saved_cmdlines cache I found a huge amount of wasted memory that should be used for the cmdlines. The tracing data saves pids during the trace. At sched switch, if a trace occurred, it will save the comm of the task that did the trace. This is saved in a "cache" that maps pids to comms and exposed to user space via the /sys/kernel/tracing/saved_cmdlines file. Currently it only caches by default 128 comms. The structure that uses this creates an array to store the pids using PID_MAX_DEFAULT (which is usually set to 32768). This causes the structure to be of the size of 131104 bytes on 64 bit machines. In hex: 131104 = 0x20020, and since the kernel allocates generic memory in powers of two, the kernel would allocate 0x40000 or 262144 bytes to store this structure. That leaves 131040 bytes of wasted space. Worse, the structure points to an allocated array to store the comm names, which is 16 bytes times the amount of names to save (currently 128), which is 2048 bytes. Instead of allocating a separate array, make the structure end with a variable length string and use the extra space for that. This is similar to a recommendation that Linus had made about eventfs_inode names: https://lore.kernel.org/all/20240130190355.11486-5-torvalds@linux-foundatio… Instead of allocating a separate string array to hold the saved comms, have the structure end with: char saved_cmdlines[]; and round up to the next power of two over sizeof(struct saved_cmdline_buffers) + num_cmdlines * TASK_COMM_LEN It will use this extra space for the saved_cmdline portion. Now, instead of saving only 128 comms by default, by using this wasted space at the end of the structure it can save over 8000 comms and even saves space by removing the need for allocating the other array. Link: https://lore.kernel.org/linux-trace-kernel/20240208105328.7e73f71d@rorschac… Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Vincent Donnefort <vdonnefort(a)google.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Mete Durlu <meted(a)linux.ibm.com> Fixes: 939c7a4f04fcd ("tracing: Introduce saved_cmdlines_size file") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/trace.c | 73 +++++++++++++++++++++----------------------- 1 file changed, 34 insertions(+), 39 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 2a7c6fd934e9..ea6d13ff256c 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2320,7 +2320,7 @@ struct saved_cmdlines_buffer { unsigned *map_cmdline_to_pid; unsigned cmdline_num; int cmdline_idx; - char *saved_cmdlines; + char saved_cmdlines[]; }; static struct saved_cmdlines_buffer *savedcmd; @@ -2334,47 +2334,54 @@ static inline void set_cmdline(int idx, const char *cmdline) strncpy(get_saved_cmdlines(idx), cmdline, TASK_COMM_LEN); } -static int allocate_cmdlines_buffer(unsigned int val, - struct saved_cmdlines_buffer *s) +static void free_saved_cmdlines_buffer(struct saved_cmdlines_buffer *s) +{ + int order = get_order(sizeof(*s) + s->cmdline_num * TASK_COMM_LEN); + + kfree(s->map_cmdline_to_pid); + free_pages((unsigned long)s, order); +} + +static struct saved_cmdlines_buffer *allocate_cmdlines_buffer(unsigned int val) { + struct saved_cmdlines_buffer *s; + struct page *page; + int orig_size, size; + int order; + + /* Figure out how much is needed to hold the given number of cmdlines */ + orig_size = sizeof(*s) + val * TASK_COMM_LEN; + order = get_order(orig_size); + size = 1 << (order + PAGE_SHIFT); + page = alloc_pages(GFP_KERNEL, order); + if (!page) + return NULL; + + s = page_address(page); + memset(s, 0, sizeof(*s)); + + /* Round up to actual allocation */ + val = (size - sizeof(*s)) / TASK_COMM_LEN; + s->cmdline_num = val; + s->map_cmdline_to_pid = kmalloc_array(val, sizeof(*s->map_cmdline_to_pid), GFP_KERNEL); - if (!s->map_cmdline_to_pid) - return -ENOMEM; - - s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL); - if (!s->saved_cmdlines) { - kfree(s->map_cmdline_to_pid); - return -ENOMEM; - } s->cmdline_idx = 0; - s->cmdline_num = val; memset(&s->map_pid_to_cmdline, NO_CMDLINE_MAP, sizeof(s->map_pid_to_cmdline)); memset(s->map_cmdline_to_pid, NO_CMDLINE_MAP, val * sizeof(*s->map_cmdline_to_pid)); - return 0; + return s; } static int trace_create_savedcmd(void) { - int ret; - - savedcmd = kmalloc(sizeof(*savedcmd), GFP_KERNEL); - if (!savedcmd) - return -ENOMEM; - - ret = allocate_cmdlines_buffer(SAVED_CMDLINES_DEFAULT, savedcmd); - if (ret < 0) { - kfree(savedcmd); - savedcmd = NULL; - return -ENOMEM; - } + savedcmd = allocate_cmdlines_buffer(SAVED_CMDLINES_DEFAULT); - return 0; + return savedcmd ? 0 : -ENOMEM; } int is_tracing_stopped(void) @@ -6056,26 +6063,14 @@ tracing_saved_cmdlines_size_read(struct file *filp, char __user *ubuf, return simple_read_from_buffer(ubuf, cnt, ppos, buf, r); } -static void free_saved_cmdlines_buffer(struct saved_cmdlines_buffer *s) -{ - kfree(s->saved_cmdlines); - kfree(s->map_cmdline_to_pid); - kfree(s); -} - static int tracing_resize_saved_cmdlines(unsigned int val) { struct saved_cmdlines_buffer *s, *savedcmd_temp; - s = kmalloc(sizeof(*s), GFP_KERNEL); + s = allocate_cmdlines_buffer(val); if (!s) return -ENOMEM; - if (allocate_cmdlines_buffer(val, s) < 0) { - kfree(s); - return -ENOMEM; - } - preempt_disable(); arch_spin_lock(&trace_cmdline_lock); savedcmd_temp = savedcmd; -- 2.43.0

1 year

1
1
0 0

[PATCH 1/3] driver core: bus: introduce can_remove()

by Hamza Mahfooz

Currently, drivers have no mechanism to block requests to unbind devices. However, this can cause resource leaks and leave the device in an inconsistent state, such that rebinding the device may cause a hang or otherwise prevent the device from being rebound. So, introduce the can_remove() callback to allow drivers to indicate if it isn't appropriate to remove a device at the given time. Cc: stable(a)vger.kernel.org Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> --- drivers/base/bus.c | 4 ++++ include/linux/device/bus.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/drivers/base/bus.c b/drivers/base/bus.c index daee55c9b2d9..7c259b01ea99 100644 --- a/drivers/base/bus.c +++ b/drivers/base/bus.c @@ -239,6 +239,10 @@ static ssize_t unbind_store(struct device_driver *drv, const char *buf, dev = bus_find_device_by_name(bus, NULL, buf); if (dev && dev->driver == drv) { + if (dev->bus && dev->bus->can_remove && + !dev->bus->can_remove(dev)) + return -EBUSY; + device_driver_detach(dev); err = count; } diff --git a/include/linux/device/bus.h b/include/linux/device/bus.h index 5ef4ec1c36c3..c9d4af0ed3b8 100644 --- a/include/linux/device/bus.h +++ b/include/linux/device/bus.h @@ -46,6 +46,7 @@ struct fwnode_handle; * be called at late_initcall_sync level. If the device has * consumers that are never bound to a driver, this function * will never get called until they do. + * @can_remove: Called before attempting to remove a device from this bus. * @remove: Called when a device removed from this bus. * @shutdown: Called at shut-down time to quiesce the device. * @@ -85,6 +86,7 @@ struct bus_type { int (*uevent)(const struct device *dev, struct kobj_uevent_env *env); int (*probe)(struct device *dev); void (*sync_state)(struct device *dev); + bool (*can_remove)(struct device *dev); void (*remove)(struct device *dev); void (*shutdown)(struct device *dev); -- 2.43.0

1 year

5
11
0 0

[for-linus][PATCH 1/2] ftrace: Fix DIRECT_CALLS to use SAVE_REGS by default

by Steven Rostedt

From: "Masami Hiramatsu (Google)" <mhiramat(a)kernel.org> The commit 60c8971899f3 ("ftrace: Make DIRECT_CALLS work WITH_ARGS and !WITH_REGS") changed DIRECT_CALLS to use SAVE_ARGS when there are multiple ftrace_ops at the same function, but since the x86 only support to jump to direct_call from ftrace_regs_caller, when we set the function tracer on the same target function on x86, ftrace-direct does not work as below (this actually works on arm64.) At first, insmod ftrace-direct.ko to put a direct_call on 'wake_up_process()'. # insmod kernel/samples/ftrace/ftrace-direct.ko # less trace ... <idle>-0 [006] ..s1. 564.686958: my_direct_func: waking up rcu_preempt-17 <idle>-0 [007] ..s1. 564.687836: my_direct_func: waking up kcompactd0-63 <idle>-0 [006] ..s1. 564.690926: my_direct_func: waking up rcu_preempt-17 <idle>-0 [006] ..s1. 564.696872: my_direct_func: waking up rcu_preempt-17 <idle>-0 [007] ..s1. 565.191982: my_direct_func: waking up kcompactd0-63 Setup a function filter to the 'wake_up_process' too, and enable it. # cd /sys/kernel/tracing/ # echo wake_up_process > set_ftrace_filter # echo function > current_tracer # less trace ... <idle>-0 [006] ..s3. 686.180972: wake_up_process <-call_timer_fn <idle>-0 [006] ..s3. 686.186919: wake_up_process <-call_timer_fn <idle>-0 [002] ..s3. 686.264049: wake_up_process <-call_timer_fn <idle>-0 [002] d.h6. 686.515216: wake_up_process <-kick_pool <idle>-0 [002] d.h6. 686.691386: wake_up_process <-kick_pool Then, only function tracer is shown on x86. But if you enable 'kprobe on ftrace' event (which uses SAVE_REGS flag) on the same function, it is shown again. # echo 'p wake_up_process' >> dynamic_events # echo 1 > events/kprobes/p_wake_up_process_0/enable # echo > trace # less trace ... <idle>-0 [006] ..s2. 2710.345919: p_wake_up_process_0: (wake_up_process+0x4/0x20) <idle>-0 [006] ..s3. 2710.345923: wake_up_process <-call_timer_fn <idle>-0 [006] ..s1. 2710.345928: my_direct_func: waking up rcu_preempt-17 <idle>-0 [006] ..s2. 2710.349931: p_wake_up_process_0: (wake_up_process+0x4/0x20) <idle>-0 [006] ..s3. 2710.349934: wake_up_process <-call_timer_fn <idle>-0 [006] ..s1. 2710.349937: my_direct_func: waking up rcu_preempt-17 To fix this issue, use SAVE_REGS flag for multiple ftrace_ops flag of direct_call by default. Link: https://lore.kernel.org/linux-trace-kernel/170484558617.178953.159051694939… Fixes: 60c8971899f3 ("ftrace: Make DIRECT_CALLS work WITH_ARGS and !WITH_REGS") Cc: stable(a)vger.kernel.org Cc: Florent Revest <revest(a)chromium.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Tested-by: Mark Rutland <mark.rutland(a)arm.com> [arm64] Acked-by: Jiri Olsa <jolsa(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ftrace.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index b01ae7d36021..c060d5b47910 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -5325,7 +5325,17 @@ static LIST_HEAD(ftrace_direct_funcs); static int register_ftrace_function_nolock(struct ftrace_ops *ops); +/* + * If there are multiple ftrace_ops, use SAVE_REGS by default, so that direct + * call will be jumped from ftrace_regs_caller. Only if the architecture does + * not support ftrace_regs_caller but direct_call, use SAVE_ARGS so that it + * jumps from ftrace_caller for multiple ftrace_ops. + */ +#ifndef HAVE_DYNAMIC_FTRACE_WITH_REGS #define MULTI_FLAGS (FTRACE_OPS_FL_DIRECT | FTRACE_OPS_FL_SAVE_ARGS) +#else +#define MULTI_FLAGS (FTRACE_OPS_FL_DIRECT | FTRACE_OPS_FL_SAVE_REGS) +#endif static int check_direct_multi(struct ftrace_ops *ops) { -- 2.43.0

1 year

1
0
0 0

[PATCH v3] soc: qcom: mdt_loader: Add Upperbounds check for program header access

by Auditya Bhattaram

hash_index is evaluated by looping phdrs till QCOM_MDT_TYPE_HASH is found. Add an upperbound check to phdrs to access within elf size. Fixes: 64fb5eb87d58 ("soc: qcom: mdt_loader: Allow hash to reside in any segment") Cc: <stable(a)vger.kernel.org> Signed-off-by: Auditya Bhattaram <quic_audityab(a)quicinc.com> --- Changes in v3: - Corrected wrong patch versioning in the Subject. - Added error prints for Invalid access. Link to v2 https://lore.kernel.org/linux-arm-msm/9773d189-c896-d5c5-804c-e086c24987b4@… Link to v1 https://lore.kernel.org/linux-arm-msm/5d7a3b97-d840-4863-91a0-32c1d8e7532f@… --- drivers/soc/qcom/mdt_loader.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c index 6f177e46fa0f..61e2377cc5c3 100644 --- a/drivers/soc/qcom/mdt_loader.c +++ b/drivers/soc/qcom/mdt_loader.c @@ -145,6 +145,11 @@ void *qcom_mdt_read_metadata(const struct firmware *fw, size_t *data_len, if (phdrs[0].p_type == PT_LOAD) return ERR_PTR(-EINVAL); + if (((size_t)(phdrs + ehdr->e_phnum)) > ((size_t)ehdr + fw->size)) { + dev_err(dev, "Invalid phdrs access: %s\n", fw_name); + return ERR_PTR(-EINVAL); + } + for (i = 1; i < ehdr->e_phnum; i++) { if ((phdrs[i].p_flags & QCOM_MDT_TYPE_MASK) == QCOM_MDT_TYPE_HASH) { hash_segment = i; -- 2.17.1

1 year

2
2
0 0

[PATCH v4] mm/zswap: invalidate old entry when store fail or !zswap_enabled

by chengming.zhou＠linux.dev

From: Chengming Zhou <zhouchengming(a)bytedance.com> We may encounter duplicate entry in the zswap_store(): 1. swap slot that freed to per-cpu swap cache, doesn't invalidate the zswap entry, then got reused. This has been fixed. 2. !exclusive load mode, swapin folio will leave its zswap entry on the tree, then swapout again. This has been removed. 3. one folio can be dirtied again after zswap_store(), so need to zswap_store() again. This should be handled correctly. So we must invalidate the old duplicate entry before insert the new one, which actually doesn't have to be done at the beginning of zswap_store(). And this is a normal situation, we shouldn't WARN_ON(1) in this case, so delete it. (The WARN_ON(1) seems want to detect swap entry UAF problem? But not very necessary here.) The good point is that we don't need to lock tree twice in the store success path. Note we still need to invalidate the old duplicate entry in the store failure path, otherwise the new data in swapfile could be overwrite by the old data in zswap pool when lru writeback. We have to do this even when !zswap_enabled since zswap can be disabled anytime. If the folio store success before, then got dirtied again but zswap disabled, we won't invalidate the old duplicate entry in the zswap_store(). So later lru writeback may overwrite the new data in swapfile. Fixes: 42c06a0e8ebe ("mm: kill frontswap") Cc: <stable(a)vger.kernel.org> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Acked-by: Yosry Ahmed <yosryahmed(a)google.com> Acked-by: Chris Li <chrisl(a)kernel.org> Signed-off-by: Chengming Zhou <zhouchengming(a)bytedance.com> --- v4: - VM_WARN_ON generate no code when !CONFIG_DEBUG_VM, change to use WARN_ON. v3: - Fix a few grammatical problems in comments, per Yosry. v2: - Change the duplicate entry invalidation loop to if, since we hold the lock, we won't find it once we invalidate it, per Yosry. - Add Fixes tag. --- mm/zswap.c | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index cd67f7f6b302..62fe307521c9 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1518,18 +1518,8 @@ bool zswap_store(struct folio *folio) return false; if (!zswap_enabled) - return false; + goto check_old; - /* - * If this is a duplicate, it must be removed before attempting to store - * it, otherwise, if the store fails the old page won't be removed from - * the tree, and it might be written back overriding the new data. - */ - spin_lock(&tree->lock); - entry = zswap_rb_search(&tree->rbroot, offset); - if (entry) - zswap_invalidate_entry(tree, entry); - spin_unlock(&tree->lock); objcg = get_obj_cgroup_from_folio(folio); if (objcg && !obj_cgroup_may_zswap(objcg)) { memcg = get_mem_cgroup_from_objcg(objcg); @@ -1608,14 +1598,12 @@ bool zswap_store(struct folio *folio) /* map */ spin_lock(&tree->lock); /* - * A duplicate entry should have been removed at the beginning of this - * function. Since the swap entry should be pinned, if a duplicate is - * found again here it means that something went wrong in the swap - * cache. + * The folio may have been dirtied again, invalidate the + * possibly stale entry before inserting the new entry. */ - while (zswap_rb_insert(&tree->rbroot, entry, &dupentry) == -EEXIST) { - WARN_ON(1); + if (zswap_rb_insert(&tree->rbroot, entry, &dupentry) == -EEXIST) { zswap_invalidate_entry(tree, dupentry); + WARN_ON(zswap_rb_insert(&tree->rbroot, entry, &dupentry)); } if (entry->length) { INIT_LIST_HEAD(&entry->lru); @@ -1638,6 +1626,17 @@ bool zswap_store(struct folio *folio) reject: if (objcg) obj_cgroup_put(objcg); +check_old: + /* + * If the zswap store fails or zswap is disabled, we must invalidate the + * possibly stale entry which was previously stored at this offset. + * Otherwise, writeback could overwrite the new data in the swapfile. + */ + spin_lock(&tree->lock); + entry = zswap_rb_search(&tree->rbroot, offset); + if (entry) + zswap_invalidate_entry(tree, entry); + spin_unlock(&tree->lock); return false; shrink: -- 2.40.1

1 year

5
8
0 0

+ mm-zswap-invalidate-duplicate-entry-when-zswap_enabled.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/zswap: invalidate duplicate entry when !zswap_enabled has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-zswap-invalidate-duplicate-entry-when-zswap_enabled.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Chengming Zhou <zhouchengming(a)bytedance.com> Subject: mm/zswap: invalidate duplicate entry when !zswap_enabled Date: Thu, 8 Feb 2024 02:32:54 +0000 We have to invalidate any duplicate entry even when !zswap_enabled since zswap can be disabled anytime. If the folio store success before, then got dirtied again but zswap disabled, we won't invalidate the old duplicate entry in the zswap_store(). So later lru writeback may overwrite the new data in swapfile. Link: https://lkml.kernel.org/r/20240208023254.3873823-1-chengming.zhou@linux.dev Fixes: 42c06a0e8ebe ("mm: kill frontswap") Signed-off-by: Chengming Zhou <zhouchengming(a)bytedance.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Yosry Ahmed <yosryahmed(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/zswap.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/mm/zswap.c~mm-zswap-invalidate-duplicate-entry-when-zswap_enabled +++ a/mm/zswap.c @@ -1516,7 +1516,7 @@ bool zswap_store(struct folio *folio) if (folio_test_large(folio)) return false; - if (!zswap_enabled || !tree) + if (!tree) return false; /* @@ -1531,6 +1531,10 @@ bool zswap_store(struct folio *folio) zswap_invalidate_entry(tree, dupentry); } spin_unlock(&tree->lock); + + if (!zswap_enabled) + return false; + objcg = get_obj_cgroup_from_folio(folio); if (objcg && !obj_cgroup_may_zswap(objcg)) { memcg = get_mem_cgroup_from_objcg(objcg); _ Patches currently in -mm which might be from zhouchengming(a)bytedance.com are mm-zswap-invalidate-duplicate-entry-when-zswap_enabled.patch mm-zswap-make-sure-each-swapfile-always-have-zswap-rb-tree.patch mm-zswap-split-zswap-rb-tree.patch mm-zswap-fix-race-between-lru-writeback-and-swapoff.patch mm-list_lru-remove-list_lru_putback.patch mm-zswap-add-more-comments-in-shrink_memcg_cb.patch mm-zswap-invalidate-zswap-entry-when-swap-entry-free.patch mm-zswap-stop-lru-list-shrinking-when-encounter-warm-region.patch mm-zswap-remove-duplicate_entry-debug-value.patch mm-zswap-only-support-zswap_exclusive_loads_enabled.patch mm-zswap-zswap-entry-doesnt-need-refcount-anymore.patch

1 year

1
0
0 0

+ fs-proc-task_mmu-add-display-flag-for-vm_mayoverlay.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: fs/proc/task_mmu: add display flag for VM_MAYOVERLAY has been added to the -mm mm-hotfixes-unstable branch. Its filename is fs-proc-task_mmu-add-display-flag-for-vm_mayoverlay.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Anshuman Khandual <anshuman.khandual(a)arm.com> Subject: fs/proc/task_mmu: add display flag for VM_MAYOVERLAY Date: Thu, 8 Feb 2024 14:18:05 +0530 VM_UFFD_MISSING flag is mutually exclussive with VM_MAYOVERLAY flag as they both use the same bit position i.e 0x00000200 in the vm_flags. Let's update show_smap_vma_flags() to display the correct flags depending on CONFIG_MMU. Link: https://lkml.kernel.org/r/20240208084805.1252337-1-anshuman.khandual@arm.com Fixes: b6b7a8faf05c ("mm/nommu: don't use VM_MAYSHARE for MAP_PRIVATE mappings") Signed-off-by: Anshuman Khandual <anshuman.khandual(a)arm.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/fs/proc/task_mmu.c~fs-proc-task_mmu-add-display-flag-for-vm_mayoverlay +++ a/fs/proc/task_mmu.c @@ -681,7 +681,11 @@ static void show_smap_vma_flags(struct s [ilog2(VM_HUGEPAGE)] = "hg", [ilog2(VM_NOHUGEPAGE)] = "nh", [ilog2(VM_MERGEABLE)] = "mg", +#ifdef CONFIG_MMU [ilog2(VM_UFFD_MISSING)]= "um", +#else + [ilog2(VM_MAYOVERLAY)] = "ov", +#endif /* CONFIG_MMU */ [ilog2(VM_UFFD_WP)] = "uw", #ifdef CONFIG_ARM64_MTE [ilog2(VM_MTE)] = "mt", _ Patches currently in -mm which might be from anshuman.khandual(a)arm.com are fs-proc-task_mmu-add-display-flag-for-vm_mayoverlay.patch mm-cma-dont-treat-bad-input-arguments-for-cma_alloc-as-its-failure.patch mm-cma-drop-config_cma_debug.patch mm-cma-make-max_cma_areas-=-config_cma_areas.patch mm-cma-add-sysfs-file-release_pages_success.patch

1 year

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2024