From: Shakeel Butt <shakeel.butt@linux.dev>
To: Hao Ge <hao.ge@linux.dev>
Cc: Vlastimil Babka <vbabka@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Hao Li <hao.li@linux.dev>, Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
"Liam R. Howlett" <liam@infradead.org>,
Suren Baghdasaryan <surenb@google.com>,
Kees Cook <kees@kernel.org>, Pedro Falcato <pfalcato@suse.de>,
Danielle Constantino <dcostantino@meta.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Harry Yoo (Oracle)" <harry@kernel.org>
Subject: Re: [PATCH slab/for-next-fixes v3 0/4] mm/slab: fix unbounded recursion in free path with memalloc profiling
Date: Fri, 17 Jul 2026 08:18:21 -0700 [thread overview]
Message-ID: <alpHadRGUeaaMUKJ@linux.dev> (raw)
In-Reply-To: <c993627d-9071-4fb4-b5fe-e0a49ed26abb@linux.dev>
On Fri, Jul 17, 2026 at 09:16:19AM +0800, Hao Ge wrote:
> On 2026/7/17 03:37, Shakeel Butt wrote:
> > On Mon, Jul 13, 2026 at 11:28:48PM +0900, Harry Yoo (Oracle) wrote:
> > > This is a follow-up fix after the recent discussion [1].
> > > See patch 4 for the detailed description on the bug.
> > >
> > > Based on slab/for-next-fixes (af9ea231c0b45) and is available at
> > > git.kernel.org [2].
> > >
> > > Instead preventing cycles by bumping up the allocation size of obj_exts
> > > arrays, it introduces a new kmalloc type called KMALLOC_NO_OBJ_EXT and
> > > disallow formation of cycles between kmalloc types when allocating
> > > obj_exts arrays. obj_exts arrays of normal kmalloc caches are served
> > > from KMALLOC_NO_OBJ_EXT caches (that don't have obj_exts), and all other
> > > obj_exts arrays are served from normal kmalloc caches.
> > >
> > > I tried to reuse SLAB_ALLOC_NO_RECURSE to make kmalloc_slab() select
> > > KMALLOC_NO_OBJ_EXT, but it was not great because it does not allow
> > > sheaves for those caches. So I introduced a new slab alloc flag
> > > SLAB_ALLOC_NO_OBJ_EXT.
> > >
> > > To avoid huge confusion, I had to decouple "disallowing sheaves"
> > > semantics from SLAB_NO_OBJ_EXT and introduced SLAB_NO_SHEAVES.
> > >
> > > While this cannot be directly backported to v6.18 and v6.12 due to lack
> > > of SLAB_ALLOC_* flags and kmalloc_flags(), I don't this will be
> > > particularily challenging to backport it. Instead of a new slab alloc
> > > flag, we can use __GFP_NO_OBJ_EXT to select KMALLOC_NO_OBJ_EXT as
> > > kmalloc caches don't have sheaves in v6.18 anyway.
> > >
> > > [1] https://lore.kernel.org/linux-mm/9a139365-28e6-4f1e-b35b-7f6091e9aa14@kernel.org
> > >
> > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/harry/linux.git/log/?h=kmalloc-no-objext-v3r1
> > >
> > > To: Vlastimil Babka <vbabka@kernel.org>
> > > To: Andrew Morton <akpm@linux-foundation.org>
> > > To: Hao Li <hao.li@linux.dev>
> > > To: Christoph Lameter <cl@gentwo.org>
> > > To: David Rientjes <rientjes@google.com>
> > > To: Roman Gushchin <roman.gushchin@linux.dev>
> > > To: Suren Baghdasaryan <surenb@google.com>
> > > To: Hao Ge <hao.ge@linux.dev>
> > > To: Kees Cook <kees@kernel.org>
> > > To: Pedro Falcato <pfalcato@suse.de>
> > > To: Shakeel Butt <shakeel.butt@linux.dev>
> > > To: Danielle Constantino <dcostantino@meta.com>
> > > To: Liam R. Howlett <liam@infradead.org>
> > > Cc: linux-mm@kvack.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org>
> > I tested next-20260716 which has this series against next-20260707 which does
> > not have the fix. The reproducer were able to trigger the leak/recursion on
> > next-20260707 but not on next-20260716. So, you can add:
>
>
> Hi Shakeel
>
>
> It seems you have a consistent stable reproduction method or test script.
>
> Would you mind sharing it if possible? I'm sorry if this was provided
> earlier and I overlooked it.
>
> I'd like to thoroughly investigate and learn about this problem.
>
> Thank you very much.
>
>
From dcb6ca5c051738d64f7a901402f5f257babbc385 Mon Sep 17 00:00:00 2001
From: Shakeel Butt <shakeel.butt@linux.dev>
Date: Fri, 17 Jul 2026 08:12:11 -0700
Subject: [PATCH] slub: repro unbounded recursion in slub objext array
allocation
Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
---
repro_public/Makefile | 1 +
repro_public/README.md | 128 +++++++++++++++++++++++++
repro_public/repro_objext.c | 180 ++++++++++++++++++++++++++++++++++++
repro_public/run_repro.sh | 26 ++++++
4 files changed, 335 insertions(+)
create mode 100644 repro_public/Makefile
create mode 100644 repro_public/README.md
create mode 100644 repro_public/repro_objext.c
create mode 100755 repro_public/run_repro.sh
diff --git a/repro_public/Makefile b/repro_public/Makefile
new file mode 100644
index 000000000000..0629fc5b6fb7
--- /dev/null
+++ b/repro_public/Makefile
@@ -0,0 +1 @@
+obj-m := repro_objext.o
diff --git a/repro_public/README.md b/repro_public/README.md
new file mode 100644
index 000000000000..21ec3f5c01e6
--- /dev/null
+++ b/repro_public/README.md
@@ -0,0 +1,128 @@
+# Reproducer: SLUB obj_exts free-recursion / cross-cycle leak
+
+With `CONFIG_MEM_ALLOC_PROFILING=y` and profiling enabled, every
+`KMALLOC_NORMAL` slab gets a `slabobj_ext` (obj_exts) array that is itself
+`kmalloc()`'d from a `KMALLOC_NORMAL` cache. `sizeof(struct slabobj_ext) == 16`,
+so with the right slab geometry the arrays reference each other:
+
+- `kmalloc-512` with 64 objs/slab -> array is `64*16 = 1024` bytes -> `kmalloc-1k`
+- `kmalloc-1k` with 32 objs/slab -> array is `32*16 = 512` bytes -> `kmalloc-512`
+
+A `kmalloc-512` slab and a `kmalloc-1k` slab then hold each other's obj_exts
+array (a 2-cycle). Discarding one frees the other's array, which empties and
+discards that slab, and so on:
+
+```
+__free_slab() -> unaccount_slab() -> free_slab_obj_exts() -> kfree()
+ -> discard_slab() -> __free_slab() ...
+```
+
+At production scale this recurses until the 16 KiB kernel stack overflows
+(stack guard page). In a small VM it deterministically manifests as a *leak*:
+the mutually-pinned slabs can never be reclaimed, so `kmalloc-512`/`kmalloc-1k`
+retain thousands of unreclaimable objects after a shrink storm. Same root cause.
+
+Related upstream commits:
+- `4b8736964640` ("mm/slab: add allocation accounting into slab allocation and
+ free paths") — introduced the obj_exts arrays (Fixes:).
+- `280ea9c3154b` ("mm/slab: avoid allocating slabobj_ext array from its own
+ slab") — bumps the size only when the array would come from the *same* cache
+ (`object_size ==`); does NOT break the `kmalloc-512 <-> kmalloc-1k` cross
+ cycle, so it is insufficient.
+
+## Files
+
+- `repro_objext.c` — the reproducer kernel module.
+- `Makefile` — out-of-tree module makefile (`obj-m := repro_objext.o`).
+- `run_repro.sh` — in-guest driver: enables profiling, prints the slab
+ geometry, insmods the module, hammers `shrink`, and reports the leftover
+ object counts (all via `/dev/kmsg` so it survives in `dmesg`).
+
+## Requirements
+
+Kernel `.config`:
+
+```
+CONFIG_MEM_ALLOC_PROFILING=y # trigger: obj_exts on KMALLOC_NORMAL slabs
+CONFIG_MEMCG=y # selects CONFIG_SLAB_OBJ_EXT=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_SLUB is the default allocator
+```
+
+Tools: a kernel build toolchain (`make`, `gcc`/clang, `binutils`, `bison`,
+`flex`, `libelf-dev`, `libssl-dev`, `bc`, `pahole`) and either
+[virtme-ng](https://github.com/arighi/virtme-ng) or `qemu-system-x86_64`.
+
+## Build
+
+```sh
+# 1. Build the kernel under test (with the config options above).
+make -C /path/to/kernel -j"$(nproc)" bzImage modules
+# ('modules' is needed so Module.symvers includes mem_alloc_profiling_key,
+# which kmalloc() references when profiling is compiled in.)
+
+# 2. Build the reproducer module against that kernel.
+make -C /path/to/kernel M="$PWD" modules # produces repro_objext.ko
+```
+
+## Run
+
+Boot the kernel with two boot-cmdline parameters:
+
+```
+slub_min_objects=64 # forces kmalloc-512=64 objs/slab and
+ # kmalloc-1k=32 objs/slab -> the cross-cycle geometry
+sysctl.vm.mem_profiling=1 # enables profiling at boot; a runtime
+ # `echo 1 > /proc/sys/vm/mem_profiling` is REJECTED
+ # unless CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y
+ # or this boot param is set.
+```
+
+With virtme-ng:
+
+```sh
+cd /path/to/kernel
+vng --cpus 8 -m 12G -a "slub_min_objects=64 sysctl.vm.mem_profiling=1" \
+ -- bash /path/to/run_repro.sh /path/to/repro_objext.ko
+```
+
+Or, by hand inside any guest booted with the params above:
+
+```sh
+insmod repro_objext.ko n=2000000 rounds=4 shrink=1 keep=0 shrink_iters=8
+for i in $(seq 1 80); do
+ for c in kmalloc-128 kmalloc-256 kmalloc-512 kmalloc-1k kmalloc-2k kmalloc-4k; do
+ echo 1 > /sys/kernel/slab/$c/shrink 2>/dev/null
+ done
+done
+cat /sys/kernel/slab/kmalloc-512/objects
+cat /sys/kernel/slab/kmalloc-1k/objects
+```
+
+The module returns `-ECANCELED` on purpose (it does all its work in init and
+then unloads itself); the `insmod: Operation canceled` message is expected.
+
+## Expected results
+
+Verify the geometry printed by the driver is `k512 objs=64` and `k1k objs=32`
+and `profiling_runtime=1`; otherwise the cross-cycle is not exercised.
+
+- **Buggy kernel** (cross-cycle not fixed): after the shrink storm,
+ `kmalloc-512`/`kmalloc-1k` stay pinned at thousands of objects (e.g. ~8000),
+ far above the pre-insmod baseline. At production scale/geometry the same
+ condition overflows the kernel stack instead.
+- **Fixed kernel**: object counts return to the pre-insmod baseline (a few
+ hundred); no leak, no recursion.
+
+## Module parameters
+
+| param | default | meaning |
+|----------------|-----------|-----------------------------------------------------------|
+| `n` | 2000000 | objects per size class per round |
+| `rounds` | 4 | warm-up rounds to build obj_exts density |
+| `keep` | 0 | keep 1-in-`keep` objects live per round (0 = free all) |
+| `shrink` | 1 | hammer `kmem_cache_shrink` via sysfs after the churn |
+| `shrink_iters` | 8 | shrink passes per round |
+| `size_lo` | 384 | small request size (-> kmalloc-512) |
+| `size_hi` | 768 | large request size (-> kmalloc-1k) |
diff --git a/repro_public/repro_objext.c b/repro_public/repro_objext.c
new file mode 100644
index 000000000000..01a53693dbef
--- /dev/null
+++ b/repro_public/repro_objext.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * repro_objext.c — reproduce the SLUB obj_exts free-recursion stack overflow.
+ *
+ * Bug: with CONFIG_MEM_ALLOC_PROFILING=y and vm.mem_profiling on,
+ * every KMALLOC_NORMAL slab gets a slabobj_ext (obj_exts) vector allocated from
+ * another KMALLOC_NORMAL slab. sizeof(slabobj_ext)==16, so kmalloc-1k's vector
+ * (objs*16) lands in kmalloc-512 and kmalloc-512's vector lands in kmalloc-1k ->
+ * cross-referencing chains and a kmalloc-1k<->kmalloc-512 2-cycle. When many such
+ * slabs are discarded (per-cpu partial flush __put_partials, or kmem_cache_shrink),
+ * __free_slab()->unaccount_slab()->free_slab_obj_exts()->kfree(vector) empties the
+ * slab that holds the vector, which discards THAT slab, recursing without bound and
+ * overflowing the 16 KiB task stack (VMAP guard page).
+ *
+ * Boot: append `sysctl.vm.mem_profiling=1` (or =1,compressed) to the kernel cmdline,
+ * OR echo 1 > /proc/sys/vm/mem_profiling before insmod.
+ *
+ * WITHOUT fix: "BUG: TASK stack guard page was hit" recursion -> panic/hang/reboot;
+ * "REPRODUCER DONE" is NEVER printed (note: the overflow may also
+ * corrupt the console TX path, so the box may just die silently —
+ * treat a VM that never prints DONE / dies / reboots as a CRASH).
+ * WITH fix: no obj_exts on KMALLOC_NORMAL slabs -> no recursion ->
+ * "REPRODUCER DONE no-crash" printed, insmod returns (module unloads).
+ *
+ * Tunables (module params):
+ * n objects per size class per round (default 2,000,000)
+ * rounds warm-up rounds to build obj_exts density (default 4)
+ * keep keep 1-in-`keep` objects live after each round to leave slabs at low
+ * occupancy (denser cross-referenced partial slabs). 0 = free all.
+ * shrink after the churn, hammer kmem_cache_shrink via
+ * /sys/kernel/slab/<cache>/shrink to force the discard cascade.
+ * sizes_lo/sizes_hi the two kmalloc request sizes (default 768 -> kmalloc-1k,
+ * 384 -> kmalloc-512).
+ */
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/kernel.h>
+#include <linux/fs.h>
+#include <linux/uaccess.h>
+#include <linux/delay.h>
+
+static unsigned long n = 2000000;
+module_param(n, ulong, 0444);
+MODULE_PARM_DESC(n, "objects per size class per round");
+
+static unsigned int rounds = 4;
+module_param(rounds, uint, 0444);
+MODULE_PARM_DESC(rounds, "warm-up rounds");
+
+static unsigned int keep;
+module_param(keep, uint, 0444);
+MODULE_PARM_DESC(keep, "keep 1-in-keep objects live after each round (0=free all)");
+
+static unsigned int shrink = 1;
+module_param(shrink, uint, 0444);
+MODULE_PARM_DESC(shrink, "hammer kmem_cache_shrink via sysfs after churn");
+
+static unsigned int shrink_iters = 8;
+module_param(shrink_iters, uint, 0444);
+MODULE_PARM_DESC(shrink_iters, "how many shrink passes");
+
+static unsigned int size_lo = 384; /* -> kmalloc-512 */
+module_param(size_lo, uint, 0444);
+static unsigned int size_hi = 768; /* -> kmalloc-1k */
+module_param(size_hi, uint, 0444);
+
+static void **a; /* kmalloc-1k (size_hi) */
+static void **b; /* kmalloc-512 (size_lo) */
+
+static void echo_to(const char *path, const char *val)
+{
+ struct file *f;
+ loff_t pos = 0;
+
+ f = filp_open(path, O_WRONLY, 0);
+ if (IS_ERR(f))
+ return;
+ kernel_write(f, val, strlen(val), &pos);
+ filp_close(f, NULL);
+}
+
+/* Force kmem_cache_shrink on the two caches: walks partial lists and discards
+ * empty slabs -> discard_slab -> __free_slab -> free_slab_obj_exts -> kfree.
+ * If the freed obj_exts vectors cross-reference, the recursion fires here. */
+static void do_shrink(void)
+{
+ unsigned int i;
+ char p1[64], p2[64];
+
+ snprintf(p1, sizeof(p1), "/sys/kernel/slab/kmalloc-1k/shrink");
+ snprintf(p2, sizeof(p2), "/sys/kernel/slab/kmalloc-512/shrink");
+ for (i = 0; i < shrink_iters; i++) {
+ echo_to(p1, "1\n");
+ echo_to(p2, "1\n");
+ }
+ /* also the cg variants if present (harmless if absent) */
+ echo_to("/sys/kernel/slab/kmalloc-rnd-08-1k/shrink", "1\n");
+ echo_to("/sys/kernel/slab/kmalloc-rnd-07-512/shrink", "1\n");
+}
+
+static void do_round(unsigned long cnt, bool last)
+{
+ unsigned long i;
+
+ for (i = 0; i < cnt; i++) {
+ a[i] = kmalloc(size_hi, GFP_KERNEL);
+ b[i] = kmalloc(size_lo, GFP_KERNEL);
+ if (a[i])
+ *(volatile char *)a[i] = 1;
+ if (b[i])
+ *(volatile char *)b[i] = 1;
+ }
+ if (last)
+ pr_emerg("REPRODUCER: allocated %lu+%lu objs, starting free-storm (keep=%u)\n",
+ cnt, cnt, keep);
+
+ /* Free-storm. If keep>0, leave 1-in-keep live to keep slabs partial &
+ * densely cross-referenced; those are freed only on the final round. */
+ for (i = 0; i < cnt; i++) {
+ if (keep && (i % keep) == 0)
+ continue; /* leave this one live for now */
+ kfree(a[i]);
+ kfree(b[i]);
+ }
+}
+
+static int __init repro_init(void)
+{
+ unsigned int r;
+ unsigned long i;
+
+ pr_emerg("REPRODUCER START n=%lu rounds=%u keep=%u shrink=%u sizes=%u/%u mem_profiling=%d\n",
+ n, rounds, keep, shrink, size_lo, size_hi,
+ IS_ENABLED(CONFIG_MEM_ALLOC_PROFILING));
+
+ a = vmalloc(n * sizeof(void *));
+ b = vmalloc(n * sizeof(void *));
+ if (!a || !b) {
+ pr_emerg("REPRODUCER: vmalloc failed, reduce n=\n");
+ goto out;
+ }
+
+ for (r = 0; r < rounds; r++) {
+ do_round(n, r == rounds - 1);
+ if (shrink)
+ do_shrink();
+ }
+
+ /* Free everything that was kept live, then shrink hard: this is the
+ * discard-cascade moment most likely to hit the recursion. */
+ if (keep) {
+ pr_emerg("REPRODUCER: freeing kept-live objects then shrinking\n");
+ for (i = 0; i < n; i++) {
+ if ((i % keep) == 0) {
+ kfree(a[i]);
+ kfree(b[i]);
+ }
+ }
+ }
+ if (shrink) {
+ pr_emerg("REPRODUCER: final shrink storm\n");
+ do_shrink();
+ }
+
+ pr_emerg("REPRODUCER DONE no-crash (fix present)\n");
+out:
+ vfree(a);
+ vfree(b);
+ /* Return error so the module unloads itself; the test only needs init. */
+ return -ECANCELED;
+}
+
+static void __exit repro_exit(void) { }
+
+module_init(repro_init);
+module_exit(repro_exit);
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Reproducer for SLUB obj_exts free-recursion stack overflow");
+
diff --git a/repro_public/run_repro.sh b/repro_public/run_repro.sh
new file mode 100755
index 000000000000..08c7e57014bc
--- /dev/null
+++ b/repro_public/run_repro.sh
@@ -0,0 +1,26 @@
+#!/bin/bash
+# Branch reproducer driver. Arg1 = path to repro_objext.ko built against this kernel.
+# All diagnostics go to /dev/kmsg so they survive in the dmesg dump (vng stdout is lossy).
+set +e
+KO="$1"
+L(){ echo "BT| $*" > /dev/kmsg 2>/dev/null; }
+k(){ awk '{print $1}' /sys/kernel/slab/$1/objects 2>/dev/null; }
+g(){ cat /sys/kernel/slab/$1/$2 2>/dev/null; }
+L "===== BRANCHTEST START ====="
+L "uname=$(uname -r)"
+L "cmdline=$(cat /proc/cmdline)"
+echo 1 > /proc/sys/vm/mem_profiling 2>/dev/null
+L "profiling_runtime=$(cat /proc/sys/vm/mem_profiling 2>/dev/null)"
+L "GEOM k512 objs=$(g kmalloc-512 objs_per_slab) ord=$(g kmalloc-512 order) | k1k objs=$(g kmalloc-1k objs_per_slab) ord=$(g kmalloc-1k order) | k2k objs=$(g kmalloc-2k objs_per_slab) | k256 objs=$(g kmalloc-256 objs_per_slab)"
+L "noobjext_caches=$(ls -d /sys/kernel/slab/*no-objext* 2>/dev/null | wc -l)"
+L "BEFORE k512=$(k kmalloc-512) k1k=$(k kmalloc-1k)"
+insmod "$KO" n=2000000 rounds=4 shrink=1 keep=0 shrink_iters=8
+L "insmod_rc=$?"
+# extra external shrink storm to force the discard cascade
+for i in $(seq 1 80); do for c in kmalloc-128 kmalloc-256 kmalloc-512 kmalloc-1k kmalloc-2k kmalloc-4k; do echo 1 > /sys/kernel/slab/$c/shrink 2>/dev/null; done; done
+sleep 1
+L "AFTER k512=$(k kmalloc-512) k1k=$(k kmalloc-1k)"
+L "===== BRANCHTEST END ====="
+echo "=====DMESG DUMP====="
+dmesg | grep -E "BT\||REPRODUCER|stack guard|BUG:|Oops|Call Trace|Kernel panic|guard page"
+echo "=====BRANCHTEST_DONE====="
--
2.53.0-Meta
next prev parent reply other threads:[~2026-07-17 15:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 14:28 [PATCH slab/for-next-fixes v3 0/4] mm/slab: fix unbounded recursion in free path with memalloc profiling Harry Yoo (Oracle)
2026-07-13 14:28 ` [PATCH slab/for-next-fixes v3 1/4] mm/slab: fix a memory leak due to bootstrapping sheaves twice Harry Yoo (Oracle)
2026-07-13 15:30 ` Suren Baghdasaryan
2026-07-16 2:31 ` Harry Yoo
2026-07-13 14:28 ` [PATCH slab/for-next-fixes v3 2/4] mm/slab: decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXT Harry Yoo (Oracle)
2026-07-13 15:37 ` Suren Baghdasaryan
2026-07-13 14:28 ` [PATCH slab/for-next-fixes v3 3/4] lib/alloc_tag: introduce mem_alloc_profiling_permanently_disabled() Harry Yoo (Oracle)
2026-07-13 15:43 ` Suren Baghdasaryan
2026-07-13 16:15 ` Vlastimil Babka (SUSE)
2026-07-13 16:28 ` Harry Yoo
2026-07-14 14:37 ` Suren Baghdasaryan
2026-07-16 2:34 ` Harry Yoo
2026-07-13 14:28 ` [PATCH slab/for-next-fixes v3 4/4] mm/slab: prevent unbounded recursion in free path with new kmalloc type Harry Yoo (Oracle)
2026-07-13 17:08 ` Suren Baghdasaryan
2026-07-14 5:17 ` Harry Yoo
2026-07-14 9:12 ` Vlastimil Babka (SUSE)
2026-07-14 14:27 ` Suren Baghdasaryan
2026-07-14 15:21 ` Vlastimil Babka (SUSE)
2026-07-14 15:42 ` [PATCH slab/for-next-fixes v3 0/4] mm/slab: fix unbounded recursion in free path with memalloc profiling Vlastimil Babka (SUSE)
2026-07-15 7:46 ` Harry Yoo
2026-07-16 18:05 ` Shakeel Butt
2026-07-17 4:09 ` Harry Yoo
2026-07-16 19:37 ` Shakeel Butt
2026-07-17 1:16 ` Hao Ge
2026-07-17 15:18 ` Shakeel Butt [this message]
2026-07-17 4:10 ` Harry Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpHadRGUeaaMUKJ@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=dcostantino@meta.com \
--cc=hao.ge@linux.dev \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=kees@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pfalcato@suse.de \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.