From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F0474611E2 for ; Tue, 20 Jan 2026 18:47:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768934871; cv=none; b=MXUGsDNKEGUY8tIuWG7MMQkBSN8vSkgytFKmD9dU2UidtQBpYsKNkg7rVfKP+MkSlFgILG1yjO6M8gn/JZ8QOsLOTb6uny41MerZepJzfcreARwxBNi2Yqo/RexQ6OA4+E30z2k0iE1XFjCN7fmzuqCE96glTwkrXKAdLsjd5hw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768934871; c=relaxed/simple; bh=CDhyY+lp92Rh286QAW/XP/ZhroygHch5zAJeleD2L8g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YtQ7NFJKME5gH/UT/U9VqzJGxW7lHS0Wwum3dmSJ2PNHv7EGnDs5DMVXWrwkQlIH3G3lu7JsVVhOidrxNoJ/nlmCx1REDQPaX8yzJ+/DA0xIn4TeNcrROyIznt3Vnh7v4AW+cBz10piOjONep0DUBakcNpXXQfX7TbCBMsFkp0g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.210.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ot1-f52.google.com with SMTP id 46e09a7af769-7d148ddb583so74229a34.0 for ; Tue, 20 Jan 2026 10:47:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768934868; x=1769539668; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cyvv5bVOKq5q2ikgZwkotwgP6l+kB/mtu+tHV4I/d8o=; b=o5rAIzZpDR5qA5gu+tUV4qXgAD1QdP/s2t4tWV2XwB3FJkhiue0e9Ob7uML1RRNq/3 mf4m9DIkw7TzvP4kCtMZ83Oq7iTvq0oFtZtWcnC76AQ2mFFDtyBhcxZ1yQE7sIKFzG0T RGAxsPv0/oDkn3VWEJuggTsNM2wyahJA7+axZ2QcHWG1DCvH1sKCYNC+oqwLb5Tsvqz1 JFBS0QBI8XL9BGcR+X/xjrjTtX1gtqB9Hrqtd67kGugJQpBgbOLC2ssB1t491ZQebEC5 NrWUCt9E74vGhaNM8aiaRUyI74oerJTZwE40xz+Lg6Q20Ok8QgO/rJ9Mi3a1jeJz9eZf GgUw== X-Forwarded-Encrypted: i=1; AJvYcCUIOT/X1hSDdhxBG+ntJQKluxbc/dPF+Jlgj8N9djfJQ5nvaU8sRrQn5BICpE3FkuZ22eqetAXB5cot9rWupA==@lists.linux.dev X-Gm-Message-State: AOJu0Yw9oBIhPUrnBdD9FzC/EX7QkrA9z1JfylUiMeFxqfw8XTna+44Z Ksd/ELk4uXnOXe7Bong4T8VhaBFsrDmS64ffVwLJg3WYpgqK/yGBNGFA X-Gm-Gg: AY/fxX7QocSGFH4h/mNcdmVTUGk1PWlBvLstMlG6u4pUteKFYJiM9Zec0lOAy5iuFHV b/K2W/O+HN2priekTNT+MVVErh6234K5a7wbtieuutpAWRuHzKBBS6mGcJkTqTRRvWdljv7xsa+ OT4unJVv3VjRvdCAW5CuFndtMJYNKLKrGpF8cRpv/x4ZnEq+7w8ASj4JlaA2gVn2c+Cx0JVXGhK Gul7ztTcCjUzQJ5zujnGxhc03zWDrTdYLzNWxc2G7d/N/OMajUu88ujHiGEzgvZOMYwR+KTSNG8 UTp1t53KwqOro2mLA2YQB8aFi0xYwwarIewEy2nx55eBwFu692XSYqVr8Fu6efSC3K8EQyGpT8V zgMFKov3JFrg3PDsbJCE7KqHnViEOzq6ictmGMdiVcn1k6GAQcddGbeJbsBj2YpK8HmcKliClIq K3xg== X-Received: by 2002:a05:6830:3986:b0:7cf:da97:57d6 with SMTP id 46e09a7af769-7d140a3d3c9mr1655270a34.6.1768934867912; Tue, 20 Jan 2026 10:47:47 -0800 (PST) Received: from gmail.com ([2a03:2880:10ff:52::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7cfdf0e956esm8985236a34.10.2026.01.20.10.47.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 10:47:47 -0800 (PST) Date: Tue, 20 Jan 2026 10:47:45 -0800 From: Breno Leitao To: Vlastimil Babka Cc: Harry Yoo , Petr Tesarik , Christoph Lameter , David Rientjes , Roman Gushchin , Hao Li , Andrew Morton , Uladzislau Rezki , "Liam R. Howlett" , Suren Baghdasaryan , Sebastian Andrzej Siewior , Alexei Starovoitov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, bpf@vger.kernel.org, kasan-dev@googlegroups.com Subject: Re: [PATCH v3 05/21] slab: add sheaves to most caches Message-ID: References: <20260116-sheaves-for-all-v3-0-5595cb000772@suse.cz> <20260116-sheaves-for-all-v3-5-5595cb000772@suse.cz> Precedence: bulk X-Mailing-List: linux-rt-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260116-sheaves-for-all-v3-5-5595cb000772@suse.cz> Hello Vlastimil, On Fri, Jan 16, 2026 at 03:40:25PM +0100, Vlastimil Babka wrote: > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -7863,6 +7863,48 @@ static void set_cpu_partial(struct kmem_cache *s) > #endif > } > > +static unsigned int calculate_sheaf_capacity(struct kmem_cache *s, > + struct kmem_cache_args *args) > + > +{ > + unsigned int capacity; > + size_t size; > + > + > + if (IS_ENABLED(CONFIG_SLUB_TINY) || s->flags & SLAB_DEBUG_FLAGS) > + return 0; > + > + /* bootstrap caches can't have sheaves for now */ > + if (s->flags & SLAB_NO_OBJ_EXT) > + return 0; I've been testing this on my arm64 environment with some debug patches, and the machine became unbootable. I am wondering if you should avoid SLAB_NOLEAKTRACE as well. I got the impression it is hitting this infinite loop: -> slab allocation -> kmemleak_alloc() -> kmem_cache_alloc(object_cache) -> alloc_from_pcs() / __pcs_replace_empty_main() -> alloc_full_sheaf() -> kzalloc() -> kmemleak_alloc() -> ... (infinite recursion) What about something as: diff --git a/mm/slub.c b/mm/slub.c index 26804859821a..0a6481aaa744 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -7445,8 +7445,13 @@ static unsigned int calculate_sheaf_capacity(struct kmem_cache *s, if (IS_ENABLED(CONFIG_SLUB_TINY) || s->flags & SLAB_DEBUG_FLAGS) return 0; - /* bootstrap caches can't have sheaves for now */ - if (s->flags & SLAB_NO_OBJ_EXT) + /* + * bootstrap caches can't have sheaves for now (SLAB_NO_OBJ_EXT). + * SLAB_NOLEAKTRACE caches (e.g., kmemleak's object_cache) must not + * have sheaves to avoid recursion when sheaf allocation triggers + * kmemleak tracking. + */ + if (s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE)) return 0;