From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29244C2BBCA for ; Fri, 28 Jun 2024 09:07:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B50456B00B0; Fri, 28 Jun 2024 05:07:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFF246B00B1; Fri, 28 Jun 2024 05:07:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C7248D0001; Fri, 28 Jun 2024 05:07:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7D6176B00B0 for ; Fri, 28 Jun 2024 05:07:02 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0F8871417F7 for ; Fri, 28 Jun 2024 09:07:02 +0000 (UTC) X-FDA: 82279717884.29.D826DF9 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf10.hostedemail.com (Postfix) with ESMTP id 33C98C0005 for ; Fri, 28 Jun 2024 09:06:59 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=gAVeQNlM; spf=pass (imf10.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719565611; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=E9XuEmOGKQmnl44REDZJmwUjYzwybPJMiDqkTMARv5k=; b=mp8cTLZr3EqkEHZVahWBfymR8+xJkxNLUk9k9T6o65qFawiHB4GWbeSY0dMSUEuFbuxrZB um/DwlsW/Tr38YHVDAR9c2Cc34tDvMC6S9WJIeE7rpFIBs3PjrOkGa9ILDS/SwISmDWL+u ls5rTbjo2IQf+ovUQskw7UZIIZRAEKo= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=gAVeQNlM; spf=pass (imf10.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719565611; a=rsa-sha256; cv=none; b=BuCWcEYhO3XoOonSJUebTJmQrOCi19snwfjq7yKHprqqlOkBEzbtlm/GIT7pXcvB1mA37X s9CK+MAYqGj4Jtmr71RaABcsZM+rxBgmFtiP63dxN9Xt4qJV5+JeG3T6w86aAxBQEZeBQu s3hfAK+9RfiuprIhovu1ZGeWlYv61nI= Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4256f102e89so1972285e9.0 for ; Fri, 28 Jun 2024 02:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719565618; x=1720170418; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E9XuEmOGKQmnl44REDZJmwUjYzwybPJMiDqkTMARv5k=; b=gAVeQNlM2XdFzRvygmCeLD/Is2Fd/mhaIZh1T5bO31CKfunBLpLlZFo31/VDNUMIng /jBKD0M+llJvZVnRwCyZuOuoF2o5Ffcq4sgYB88DeEQkhGxZFB2PABMPE8VLF4QQbUUT 5w2h9eAuSBCkeSZwET1q7A6It+LiCmslsfgNudYJx/Yf5xY+yAqPB44OBBLgt1jWG4xG zeZTy5lp3rXNTv/925VrbCfjLBjYR8WtIW0tT5QokhWsGUq+2aQfAtuzdyWFrwDGZOTE 4scit/FdU/QzUTC6lpxeQbmeugslzoLTjvySa1iTWbwAoH5YsnIyCn5FscS6zg5Zf+3X xP1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719565618; x=1720170418; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=E9XuEmOGKQmnl44REDZJmwUjYzwybPJMiDqkTMARv5k=; b=l9m3juz3que7+G4iyhZ1BYsC1CnQBwEiZcP+4ZfF0nTuUtPEuirnmWHvCoW7Q9smLh YYYYumVtqjFXwgERqFILgM/h1nljqJyJ/cxKRL5tND04c5wI/5gqpGHCWIJ2ZTzktAXy BfSSWbZpQg6B0V0+1vsFNOIj5TKJDkcz2ASkOQUmArL3FXSh90dGzLb635WcAEmwAIFR aAxaoYnzMgX3XMtTTNIPByADG5sMac0DX/cL9OQf4L9ghj0pH0a1MUNLIAUq642cDrXc QsPjLBFuvE+XLbWWi/lqImQnBChK9xvK8utI3yHn3aMnhsR9SxQY+4ztrT65DlbgKBsD K6Mw== X-Forwarded-Encrypted: i=1; AJvYcCXBjq5YqezZm+BaXsG/RW8GuenQ1QpqrGVa37/ETLbTypgz82VEH5ZjH/7jH+tOzJ4KHzFip5GywC+Yy1WH6j5jKCs= X-Gm-Message-State: AOJu0YxnRAgZ/5MIsHaUiZUfzTo+C089WY3q07p2TeGlW06cm4TX4fuD g7UVaMHHycqTdcyZBmHwnV31RSFPROp8/eLnPWNhKgYVBKE2iJt9F0MDDqm6wTNseoHCMd37SIr u0otOfg3WQXBD/ye/z3ElG5y+PExJTs6pPLyz X-Google-Smtp-Source: AGHT+IH7t15ZxEn2LETHAyDOXDZSewj9x0ofxPVWbHBdCjBgMBIveOKBhoflOM22vJXoMJ9CySG9QwFCPP9ol/FJosc= X-Received: by 2002:a05:6000:dcd:b0:35f:1c34:adfc with SMTP id ffacd0b85a97d-366e96bf06bmr10949760f8f.67.1719565618293; Fri, 28 Jun 2024 02:06:58 -0700 (PDT) MIME-Version: 1.0 References: <20240619192131.do.115-kees@kernel.org> <20240619193357.1333772-4-kees@kernel.org> <202406201147.8152CECFF@keescook> <1917c5a5-62af-4017-8cd0-80446d9f35d3@suse.cz> In-Reply-To: From: Alice Ryhl Date: Fri, 28 Jun 2024 11:06:45 +0200 Message-ID: Subject: Re: [PATCH v5 4/6] mm/slab: Introduce kmem_buckets_create() and family To: Vlastimil Babka Cc: Boqun Feng , Kees Cook , "GONG, Ruiqi" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , jvoisin , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Xiu Jianfeng , Suren Baghdasaryan , Kent Overstreet , Jann Horn , Matteo Rizzo , Thomas Graf , Herbert Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, netdev@vger.kernel.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 33C98C0005 X-Stat-Signature: 8qdo4pyytwp7m683jashg5apn3sper6u X-HE-Tag: 1719565619-722053 X-HE-Meta: U2FsdGVkX1+eFRLq03ul+f+EGlhBOheXucS97N3tR8feCeHPeiwDsF6nbaFw7fxWwJYDCES2ONKV12mXU0Nj7YEFOmZPpKN0frV1y+uYcO0yx+AneJdTOgNit+xcxNtu+9yNPBnDchOeY8ERUWpRfpbNOm4RUK8vFbJUuQxZGn7mcdd7YEcbP8sMIHSDSdGgiPbYI2N9NipthzTXed5sS8ZbEbPe50vyzMMMaRAQbZ2I8KnJicUQivODXykTHr+D+ggwqKgkbllaZz9PKBWItpwgGb9bL1Op/S0ic3Jdj1duC7TLR0CeabXsQTPFwWKi3ZRFDr2Fwa8G/urx/sxyoA3MUtvKSZnntHT1Jp2sGrAqrph0oWEfE4cSBIEHarg0mHU3GYVb2xQJUgiFPubVr0sHV5sI58UP0TuM6sgq99vTaQXEyUh2rPeuo1+9VT38crfdyNUhjJYp5kHJC9utIVyy2wIpfpuE8YtPi/906ocurjaC6ZCfQ8OTb0V9MDy6tburclg/e3GzbyDV/ShV7DO82zqPbCmFIZ407HvS0mS1nFDKq7MpQsl1GSz6tS1EuSnGXZqL04/gBLBLv+zfsGViaw5PktWb9+5KmZOCksnptkFBVyYhzQV/nZikDck1c/651WqAcBDoWA21iOCVzKn3nwzoxaGIFAdY56o3SDcja2NjhQYbUnyV6ybH5E0Rogi5JjXnlEorHwr5ULtaZ5//qARDaVBGfdCpbmQ80XcTJctcPEBWPt/3EYJ36Yl+FnC/Z7iOSBQytTnOO8XtMsNQf38e5588smKXFpBmxDCUlvXoRlVyQmcFZkZqMYnA8UDo5jgh9AXCQZ+pbbRBcghX62DkD802WIZFPnVe1+kVs+/MvhqssUS3vP3FcS6QR3YHgiqJHKUDVpJxSFEgqLQYCV2NzkH0kADPbl7cdLV/4VMzrz4ffBowHQABabWaTCFqLp6ORNb/l5VOIli p/AJ7soB Wp2legG/pkVnQXVwxX3cx8zXjds/52n+wiKCfAMs1is4DF4HwTgpy8WAJHz++JCUWqBmUL83cGdSqkpPP5y3E7ocdpDilhjR1QIDoeWAuQBFiniGy/javKdf8d0KxCWeLAhqE4EMfmYOLaR/gitSovJBlmJmSqE/1kHD+oRLCzoI19j7dHTRloL22o9SdB7xZnhycwJdSBLji59K0Cv8kfXyK3yV4DXPxID+yHEb1kWNAT4xOXcIkhwaVN94b32FgifH5IhqHVMkI/NUjuR2gWFE+SjlatV1bBUTn/e04APQVljGitE+8YBBn3ejQN18X/itcqfE2VSQXQfB3qNDOUSmOVszXgOaQ3mEyqsS8dYPRbPOKB/OZWJzv4Qbe3K5wyccXctAD+UEDarXWKq4bhaxexw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jun 28, 2024 at 10:40=E2=80=AFAM Vlastimil Babka w= rote: > > On 6/28/24 7:35 AM, Boqun Feng wrote: > > On Thu, Jun 20, 2024 at 10:43:39PM +0200, Vlastimil Babka wrote: > >> On 6/20/24 8:54 PM, Kees Cook wrote: > >> > On Thu, Jun 20, 2024 at 03:56:27PM +0200, Vlastimil Babka wrote: > >> >> > @@ -549,6 +549,11 @@ void *kmem_cache_alloc_lru_noprof(struct kme= m_cache *s, struct list_lru *lru, > >> >> > > >> >> > void kmem_cache_free(struct kmem_cache *s, void *objp); > >> >> > > >> >> > +kmem_buckets *kmem_buckets_create(const char *name, unsigned int= align, > >> >> > + slab_flags_t flags, > >> >> > + unsigned int useroffset, unsign= ed int usersize, > >> >> > + void (*ctor)(void *)); > >> >> > >> >> I'd drop the ctor, I can't imagine how it would be used with variab= le-sized > >> >> allocations. > >> > > >> > I've kept it because for "kmalloc wrapper" APIs, e.g. devm_kmalloc()= , > >> > there is some "housekeeping" that gets done explicitly right now tha= t I > >> > think would be better served by using a ctor in the future. These AP= Is > >> > are variable-sized, but have a fixed size header, so they have a > >> > "minimum size" that the ctor can still operate on, etc. > >> > > >> >> Probably also "align" doesn't make much sense since we're just > >> >> copying the kmalloc cache sizes and its implicit alignment of any > >> >> power-of-two allocations. > >> > > >> > Yeah, that's probably true. I kept it since I wanted to mirror > >> > kmem_cache_create() to make this API more familiar looking. > >> > >> Rust people were asking about kmalloc alignment (but I forgot the deta= ils) > > > > It was me! The ask is whether we can specify the alignment for the > > allocation API, for example, requesting a size=3D96 and align=3D32 memo= ry, > > or the allocation API could do a "best alignment", for example, > > allocating a size=3D96 will give a align=3D32 memory. As far as I > > understand, kmalloc() doesn't support this. > > Hm yeah we only have guarantees for power-or-2 allocations. > > >> so maybe this could be useful for them? CC rust-for-linux. > >> > > > > I took a quick look as what kmem_buckets is, and seems to me that align > > doesn't make sense here (and probably not useful in Rust as well) > > because a kmem_buckets is a set of kmem_caches, each has its own object > > size, making them share the same alignment is probably not what you > > want. But I could be missing something. > > How flexible do you need those alignments to be? Besides the power-of-two > guarantees, we currently have only two odd sizes with 96 and 192. If thos= e > were guaranteed to be aligned 32 bytes, would that be sufficient? Also do > you ever allocate anything smaller than 32 bytes then? > > To summarize, if Rust's requirements can be summarized by some rules and > it's not completely ad-hoc per-allocation alignment requirement (or if it > is, does it have an upper bound?) we could perhaps figure out the creatio= n > of rust-specific kmem_buckets to give it what's needed? Rust's allocator API can take any size and alignment as long as: 1. The alignment is a power of two. 2. The size is non-zero. 3. When you round up the size to the next multiple of the alignment, then it must not overflow the signed type isize / ssize_t. What happens right now is that when Rust wants an allocation with a higher alignment than ARCH_SLAB_MINALIGN, then it will increase size until it becomes a power of two so that the power-of-two guarantee gives a properly aligned allocation. Alice