From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 E5A843D561 for ; Sun, 25 Jan 2026 00:24:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769300667; cv=none; b=fksOaL9mNyyPr32ARlpe55TaSCQ10rvsPmY9zA2b1Z0qhQY5DOsVc2cIPhNCXk4kCRQD3beV+HG51d0Q8iXFhNBBfhLZegIRdJErLYt2zf0u6wRKxNXG9AkL3b0rQ+voGDvthdsJNRwFTwJP7V16gAXOCX6w/5ZIA4jpwA0HTs0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769300667; c=relaxed/simple; bh=gzeRpzPJRPPZnxRAg0UXA9IpOe5LB3iZkbOzMdjBeCI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=K6+DLYo3jpGpSKcaRpT7IaeAQTcJPUwXFsDT/y0JZhQPYDQA3G1OwVL7Exur9fXfKy0oH4iO3RR8sSAFdXKCxmMSbKK/2bxo/stdVVhFjlmVHH5iyk3T7oqhuUGLRK/DQlswF9baHprOyoeJTsBRfZnA2nGx6g7Vev0bp4DmoRc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=nxotqrm7; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="nxotqrm7" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2a76b39587aso50085ad.0 for ; Sat, 24 Jan 2026 16:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769300665; x=1769905465; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=IudDhyXqckiiU9bY+b5zRXy/CTYJjY9Rh3P/ajW/06k=; b=nxotqrm7qHcIekiFM6/nn33loH1mELOLubTg/znp7FyIwoG1faUyknvF5SOjBWeXfs I+xA8mwy+8oFoGrhbjTkUcmv9rv69bta3QHNuaKms7H9QnNYcYucukFTmtL1K/R5h2U1 OJS1lMifLLnVztqjih/bYDSQTvZTDCosr93Zm392b3r/c7R+7kmzKhoFxXfGEHzdK/UO CY4/Y6NMs+nOr3DDpl9qsubsmX/mWBo4WwAjDYtYGF7jHE6xUyF+ldHIsevG+t/mF3Pk gXeFVXL9o2fi9WjLPqcYn3QLlZk6pVebIXcT5OdmnPCa/PDTit0AtAu7SOkvvkLDaGsy scVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769300665; x=1769905465; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IudDhyXqckiiU9bY+b5zRXy/CTYJjY9Rh3P/ajW/06k=; b=ETGZew9dIk8ySet9xe20130NCHQbPofBwXq2p/U3cfTgqKjiypAkexENjqXcaDXGQj AczZizduoy0genowzlxhq+w/W+1yll+oTMlCHVdlYeVcHf5MOzSKNrfMw5GQsCF4KGvk egqtT7tw/JdSG95fJMA0TAkOBojICCRnto73az5or0/1CxUeKksSTva0eJB5Gs0Pazy5 JAi8zI4aAbNGeJGvnVwjvmtqwyS3H6oZLlo4CzXSB2uEIsnk+yiKDFcATFZLXmFEgJdQ LmkJd9WbVvXcCpCJNtWzuvRC8pxfazKzlS+QXhpdGmDB4Bxr+c60BEThs6YEJz1OOgcP kJQA== X-Forwarded-Encrypted: i=1; AJvYcCWvLC5iq5RStOl+uF5RP8+J1mMozadlabDG2kRciJ4X/4MNWBwq7XaKnkLDE4Ix5CrsbLbDC7gmKFwvfms=@vger.kernel.org X-Gm-Message-State: AOJu0Yzz+kuwBxPJYQZJzM8CRqXHhTLsXcClI4JSL/LtUnx6USbEmWjC lL7vO9H8HTM0G7sLcqOexQ/vvolMewwOYx2c1+jNkwNoFsT4y54QMw/xrikP9p+1Xg== X-Gm-Gg: AZuq6aLE13bvncMl1uqAoDGKznQ7S/SkL6/rwVLJqxcwDBTUgr/39ntETWGoGF0tAEN Ud4BKnV2Yi4nbeua0+Qz4GZjASsdD5/XglQ2DFzspJoqBeeS/abxF0AkH3M06/e/CnHsC2/u1po GpcTIUG1nJq1wv8/2MlCeun1CvF567UQpD5LQOpgQJpfNNrjA5PLVlGg5/puBWk8feaPf+jNmvL zXPbpxi6AYsz8gvjVzXEQvMhVk6kl432cIalDrmOyv6cuJMUaNPd9a8uzqZuT1/05JtgFPpt4m5 wapvqivc00HoEsuSZObQCfipmFzYdOI8qxIWCogOcdUjaUdrejkoxz92BqjX5310JV35cI4yqQt FIAtpXdDVxFnZQYYBESVIYLnQdigQ05t7SLc2GFFvt8RNeWo/nNbZudvqQw434HqMoIPYeaxHVv qhWJEq15XAUT1wqLdOphvF5KVMsOpAjQgGnNLSCer2jkT1uW8O/SzPqNblUbo2LvoHWZ28qN/5k mcxvMqRA6dHB4LfvQxYapvw3EJSG8C5GnsLZVMqDQ== X-Received: by 2002:a17:903:1aed:b0:294:ecba:c8e with SMTP id d9443c01a7336-2a8449f6bcamr142175ad.3.1769300664762; Sat, 24 Jan 2026 16:24:24 -0800 (PST) Received: from [2a00:79e0:2eb0:8:817c:d8ee:c019:7966] ([2a00:79e0:2eb0:8:817c:d8ee:c019:7966]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a802fb03b4sm53766085ad.82.2026.01.24.16.24.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Jan 2026 16:24:24 -0800 (PST) Date: Sat, 24 Jan 2026 16:24:23 -0800 (PST) From: David Rientjes To: Eric Dumazet cc: Vlastimil Babka , Harry Yoo , Hao Li , Christoph Lameter , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Subject: Re: [PATCH v2] slab: replace cache_from_obj() with inline checks In-Reply-To: Message-ID: <3212f83f-960b-9a8c-2cb8-d617a201f094@google.com> References: <20260121-b4-remove_cache_from_obj-v2-1-7213d36b89d5@suse.cz> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 21 Jan 2026, Eric Dumazet wrote: > > Eric Dumazet has noticed cache_from_obj() is not inlined with clang and > > suggested splitting it into two functions, where the smaller inlined one > > assumes the fastpath is !CONFIG_SLAB_FREELIST_HARDENED. However most > > distros enable it these days and so this would likely add a function > > call to the object free fastpaths. > > > > Instead take a step back and consider that cache_from_obj() is a relict > > from when memcgs created their separate kmem_cache copies, as the > > outdated comment in build_detached_freelist() reminds us. > > > > Meanwhile hardening/debugging had reused cache_from_obj() to validate > > that the freed object really belongs to a slab from the cache we think > > we are freeing from. > > > > In build_detached_freelist() simply remove this, because it did not > > handle the NULL result from cache_from_obj() failure properly, nor > > validate objects (for the NULL slab->slab_cache pointer) when called via > > kfree_bulk(). If anyone is motivated to implement it properly, it should > > be possible in a similar way to kmem_cache_free(). > > > > In kmem_cache_free(), do the hardening/debugging checks directly so they > > are inlined by definition and virt_to_slab(obj) is performed just once. > > In case they failed, call a newly introduced warn_free_bad_obj() that > > performs the warnings outside of the fastpath, and leak the object. > > > > As an intentional change, leak the object when slab->slab_cache differs > > from the cache given to kmem_cache_free(). Previously we would only leak > > when the object is not in a valid slab page or the slab->slab_cache > > pointer is NULL, and otherwise trust the slab->slab_cache over the > > kmem_cache_free() argument. But if those differ, it means something went > > wrong enough that it's best not to continue freeing. > > > > As a result the fastpath should be inlined in all configs and the > > warnings are moved away. > > > > Reported-by: Eric Dumazet > > Closes: https://lore.kernel.org/all/20260115130642.3419324-1-edumazet@google.com/ > > Reviewed-by: Harry Yoo > > Reviewed-by: Hao Li > > Signed-off-by: Vlastimil Babka > > Acked-by: Eric Dumazet > Tested-by: David Rientjes