From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 033733A9851 for ; Thu, 14 May 2026 08:22:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778746973; cv=none; b=YVcDrNDsPT0Hi/SfRdfas3VVkwktUJSU9xy4XnQYpKFGla/2Y9PQfUuZvg3Df9P6KFzas3QIMS4GKgGsbm3NOGWuENOggkG1ubh6eyQfvnOjTJBslW2h4CZPkKiYiqnd8WX6G+4cvPVDXw5/8rCyQLD48Gpg0MYCtt5mvYoyrfs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778746973; c=relaxed/simple; bh=3WjDEzCHsM60UDSdPtY66/xViUYjVkKVnCvLEkxbKG8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MeRGsL3GA17Q0W+9K8uR2LUTfZ+Vm09PROmBZMOm5V9HlVZ0VcS7dWe/MRuat2KKH+JqJI46Ja1Kr8iTN7zOLjM9Pdx0Q0eEQgKDHNt/UjMP8ZMwSR9+CNKjp3c1XS7d26M3v7ddiZns6WZB2FEaC6qBoDVWEKq5W5X7AhOmWjY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jsBzbse7; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jsBzbse7" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4891d7164ddso41880865e9.3 for ; Thu, 14 May 2026 01:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778746970; x=1779351770; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=jnnqbs2N6v6CmeDw57e03ve8ioJE3EIg9PporZt60VY=; b=jsBzbse74tGfrnjDhmHYu9SXtq2DJ6g/z5074656Zu/s2BfB0mS3jiL36gfNpdtRJw lAj7RWTmmk2NczHARYwE3FJ+2bz+cLlN9G2V2R6Vusl55TbgG2AUM+ZvnqGF6QfeEHec ESfT3lMpDLbeZwUnkTua/rY+ksxEzbLC7rWtTiE4ena39cijI3koGQU6l5h78QWatU96 87I9Ifg6dQuDqMjk3NZanKuabqVIVNmHlHjcxugww4WbrSnJyUxyqajdHnwrPjNDtATW 8elV7rIq5CpXwexbpZyZkK0ZMUHvOekzXtF6JoCIwejCnO7KY7Xg2SuzvBMZEZAC1ARZ FIsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778746970; x=1779351770; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=jnnqbs2N6v6CmeDw57e03ve8ioJE3EIg9PporZt60VY=; b=M0bTEpcQcusuaEmmdUzbZxqL2j4VzYccSq60O1nlGMgySiMUMyfohSnQZln6/XPPjo bOoSaiwQwTJQNM2qkbC08O49q2gGFgVDnZlP4cXNtAXQwRk3tub7q4Fbm+iWTuuhf+R4 0gSYZ0ac+Xk+dxs7Qe8mV0y3FcEN2dMw3iPQUxen3XQ9/JSKQZLjXt9g04o6d/pfnJjA PJCBE774o2xuWpOpwI6IjBve3quvLoyaqsNZe/6loIkkC46F2FDgZHRq5gRgKJphfffV 1SaAgc4JTACkY89LWZ0qqh6LF8fQZQ2wLulM+4eFdJnPwgxrH+WeBfUwxZoVfA7/Zaba Wvqg== X-Forwarded-Encrypted: i=1; AFNElJ+S/XSdBkT5+oXAheRmJ8je8XON38rTZ1uunohHPnloD3+atphdw/bwKjQu946wTu5jO56QUaJI0hWRUak=@vger.kernel.org X-Gm-Message-State: AOJu0YyEN3a408dMpJqGdVhFNlcNOljaC1ys2uPcYkmUVQanGPojo47H Sx5BT5/NmIrAzLvSiuMhGCDc096m8BvnteGnYc5/ByERGPLS8ONznrQz X-Gm-Gg: Acq92OG+G1jNLzq+tHXas5ZVaOtWBVspK9DBFo/UhrKz8uMnO51pZWb6MtBBf2CWfW0 0cy4k0sJBdJhY9qmBWtC3Px9EwA3xmmEwqhgSNVwMYwTlekM8q7K9Bzmv9sz8fubRWzRfj/tEiw j7GE5A49JZKMuFM6NmUFx4F8sCN29LxcB4Xxh5NUZyVj2I/2x5mIuhnW+OtlMzELHwhOfU465Of 54Cm+qtEO0aOOdzLnCblz4hEUbjKYsmBTuoCaOg8r9jQyyR6EE6W3Lkb/s79ZH8IT0BKbYfoyJL HfOsLT7CHPGCwVERzRgzDfmIgPtgQA4NHtqyDk5Tymde4FnvuxoqhyuMC6a+AFNvp8oF80w4jY0 1bYt+H4A4JQrcNl1GnLEaKikMJPpCEi/JHxVrHnUKDTDRi7DYms9EoV0FJBPPL/NOsPN54mafG7 OqpJvng9LzjBaDkqs22wV7yfJdIi7NFfujHYEQW9Fx82jYr55wicGC67A+/CRN X-Received: by 2002:a05:600c:45c8:b0:48d:35e:84a0 with SMTP id 5b1f17b1804b1-48fcea151fbmr93519065e9.28.1778746970041; Thu, 14 May 2026 01:22:50 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fd64a22a9sm49882335e9.8.2026.05.14.01.22.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2026 01:22:49 -0700 (PDT) Date: Thu, 14 May 2026 09:22:46 +0100 From: David Laight To: Marco Elver Cc: Vlastimil Babka , Andrew Morton , "Gustavo A. R. Silva" , "Liam R. Howlett" , Andrey Konovalov , Bill Wendling , David Hildenbrand , David Rientjes , Dmitry Vyukov , Jann Horn , Justin Stitt , KP Singh , Kees Cook , Lorenzo Stoakes , Matteo Rizzo , Michal Hocko , Mike Rapoport , Nathan Chancellor , Nick Desaulniers , Roman Gushchin , Suren Baghdasaryan , linux-hardening@vger.kernel.org, Nicolas Schier , Dennis Zhou , Tejun Heo , Christoph Lameter , Harry Yoo , Hao Li , "Liam R. Howlett" , Alexander Potapenko , Miguel Ojeda , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, llvm@lists.linux.dev Subject: Re: [PATCH v4 2/3] slab: improve KMALLOC_PARTITION_RANDOM randomness Message-ID: <20260514092246.12b7d1ee@pumpkin> In-Reply-To: <20260511200136.3201646-2-elver@google.com> References: <20260511200136.3201646-1-elver@google.com> <20260511200136.3201646-2-elver@google.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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 Content-Transfer-Encoding: 7bit On Mon, 11 May 2026 22:00:49 +0200 Marco Elver wrote: > When using CONFIG_KMALLOC_PARTITION_RANDOM, _RET_IP_ was previously used > to identify the allocation site. _RET_IP_, however, evaluates to the > caller's parent's instruction pointer rather than the actual allocation > site; this would lead to collisions where a function performs multiple > allocations. > > With the generalization to kmalloc_token_t, we now generate the token at > the outermost macro, and using _THIS_IP_ would fix this for all cases. > > Unfortunately, the generic implementation of _THIS_IP_ relies on taking > the address of a local label, which is considered broken by both GCC [1] > and Clang [2] because label addresses are only expected to be used with > computed gotos. While the generic version more or less works today, it > is known to be brittle. For example, Clang -O2 always returns 1 when > this function is inlined: > > static inline unsigned long get_ip(void) > { return ({ __label__ __here; __here: (unsigned long)&&__here; }); } > > To provide a reliable unique identifier without breaking architectures > relying on the generic _THIS_IP_, introduce _CODE_LOCATION_: it resolves > to _THIS_IP_ where architectures provide a safe implementation, and > falls back to a zero-cost static marker where _THIS_IP_ is broken. Doesn't that mean that all the other uses of _THIS_IP_ (which seem to mostly be tracking lock requests) are basically broken on everything except x86-64. Would it be better to actually fit that? It isn't as though it is hard asm, you just need to look at how gcc generates PIC references to static data. -- David