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 DFA56C433F5 for ; Wed, 23 Feb 2022 19:06:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F2CE8D004A; Wed, 23 Feb 2022 14:06:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A1B18D0011; Wed, 23 Feb 2022 14:06:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 369B48D004A; Wed, 23 Feb 2022 14:06:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 13C588D0011 for ; Wed, 23 Feb 2022 14:06:16 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B15272113F for ; Wed, 23 Feb 2022 19:06:15 +0000 (UTC) X-FDA: 79174975110.05.CBCA3B3 Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf12.hostedemail.com (Postfix) with ESMTP id BF5834000E for ; Wed, 23 Feb 2022 19:06:14 +0000 (UTC) Received: by mail-yb1-f180.google.com with SMTP id e140so49965351ybh.9 for ; Wed, 23 Feb 2022 11:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+uyB8qTyiqJA+8KT+MhYk3e+WJLsuNUugcYRMD4HHtc=; b=XTcWUGqndSazCKYxvr5wfdVygp3PD8Q+5T/UmHtdzhxxiTh5N0vinkFlZN7MwnJGpP PU/JSqVsObIVHE4Z/SRkI8lffvP1P9yocTbN/3F92cqvJYJsyiKWKImrpxxGoSZjr4Ie DUK217WdtiEiy9Nj4AoJKGq1X+z0e4+9Tt3tL6dmFhfYS1kjuCuGA/Ug/xbccbpC6vrA Z53QhfSqKz3YXtd70RcRkvZ8Y55npfAz2z5C5JqthTUdPFibChxuIHynA7xg/4pvipww BNZheB27YegwfPK8nG3lG4IprMGjj/5oHGx8knm/KwgJ4Pc6Kob30ACxLMw1M3CHIagD 0uiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+uyB8qTyiqJA+8KT+MhYk3e+WJLsuNUugcYRMD4HHtc=; b=caeMSg19qsdP/IEPwVcKJovfVvw6PaNU1Hh2R7R9JsDG/DkRAKIaSbbdFewrBcKEYr JWL6FC/2TudPx8MhX3cQyOcW3D1QMjJuzG4L1YM5s+SlvZTmMoD2ClD5yJwexemmReRe NCo2CQjhf0trVl5wpj+wzaWXbFEy39N/c5+YUSLpOwdVn+boVAuOwKFKP23PPGWz4/fT GUITYRchlhnQUN3rxEmpMUsA3wM2rJyiZi45OVZf/yHRJdlSL9iPdxw2VV7Ja2RxID14 8BxfGxTFnv6ze0WBQcVaYuc6fXYN91swN43xDS8JZeHFdU4iWOxXiqMRKHvlxEsAD3F4 Wjug== X-Gm-Message-State: AOAM530Bk+hFWyJaV1/Uh4WSxSKKSLDZE/ov/l465navFzn47uGkGTe9 VU++9BK1i5+/BkPnysIa3Ffd49zQdkb0J+oxUwfHiA== X-Google-Smtp-Source: ABdhPJzG+wZcj7IS5on1+GCgo2bfFUsCtjBnQs0QuELu2SkLfouEYImHnsLEqFHCrRSqVeoTZx4SqMYfZAhMCx7LVsU= X-Received: by 2002:a25:a4e8:0:b0:61e:1eb6:19bd with SMTP id g95-20020a25a4e8000000b0061e1eb619bdmr1094373ybi.168.1645643174054; Wed, 23 Feb 2022 11:06:14 -0800 (PST) MIME-Version: 1.0 References: <20220221105336.522086-1-42.hyeyoo@gmail.com> <20220221105336.522086-2-42.hyeyoo@gmail.com> <4d42fcec-ff59-2e37-4d8f-a58e641d03c8@suse.cz> In-Reply-To: <4d42fcec-ff59-2e37-4d8f-a58e641d03c8@suse.cz> From: Marco Elver Date: Wed, 23 Feb 2022 20:06:02 +0100 Message-ID: Subject: Re: [PATCH 1/5] mm/sl[au]b: Unify __ksize() To: Vlastimil Babka Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, Roman Gushchin , Andrew Morton , linux-kernel@vger.kernel.org, Joonsoo Kim , David Rientjes , Christoph Lameter , Pekka Enberg , Kees Cook , kasan-dev , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XTcWUGqn; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of elver@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=elver@google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BF5834000E X-Stat-Signature: yk8eook5kaz5f3ehjfbqmwme49na4p4w X-HE-Tag: 1645643174-933957 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: On Wed, 23 Feb 2022 at 19:39, Vlastimil Babka wrote: > On 2/21/22 11:53, Hyeonggon Yoo wrote: > > Only SLOB need to implement __ksize() separately because SLOB records > > size in object header for kmalloc objects. Unify SLAB/SLUB's __ksize(). > > > > Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > --- > > mm/slab.c | 23 ----------------------- > > mm/slab_common.c | 29 +++++++++++++++++++++++++++++ > > mm/slub.c | 16 ---------------- > > 3 files changed, 29 insertions(+), 39 deletions(-) > > > > diff --git a/mm/slab.c b/mm/slab.c > > index ddf5737c63d9..eb73d2499480 100644 > > --- a/mm/slab.c > > +++ b/mm/slab.c > > @@ -4199,27 +4199,4 @@ void __check_heap_object(const void *ptr, unsigned long n, > > } > > #endif /* CONFIG_HARDENED_USERCOPY */ > > > > -/** > > - * __ksize -- Uninstrumented ksize. > > - * @objp: pointer to the object > > - * > > - * Unlike ksize(), __ksize() is uninstrumented, and does not provide the same > > - * safety checks as ksize() with KASAN instrumentation enabled. > > - * > > - * Return: size of the actual memory used by @objp in bytes > > - */ > > -size_t __ksize(const void *objp) > > -{ > > - struct kmem_cache *c; > > - size_t size; > > > > - BUG_ON(!objp); > > - if (unlikely(objp == ZERO_SIZE_PTR)) > > - return 0; > > - > > - c = virt_to_cache(objp); > > - size = c ? c->object_size : 0; > > This comes from commit a64b53780ec3 ("mm/slab: sanity-check page type when > looking up cache") by Kees and virt_to_cache() is an implicit check for > folio slab flag ... > > > - > > - return size; > > -} > > -EXPORT_SYMBOL(__ksize); > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > index 23f2ab0713b7..488997db0d97 100644 > > --- a/mm/slab_common.c > > +++ b/mm/slab_common.c > > @@ -1245,6 +1245,35 @@ void kfree_sensitive(const void *p) > > } > > EXPORT_SYMBOL(kfree_sensitive); > > > > +#ifndef CONFIG_SLOB > > +/** > > + * __ksize -- Uninstrumented ksize. > > + * @objp: pointer to the object > > + * > > + * Unlike ksize(), __ksize() is uninstrumented, and does not provide the same > > + * safety checks as ksize() with KASAN instrumentation enabled. > > + * > > + * Return: size of the actual memory used by @objp in bytes > > + */ > > +size_t __ksize(const void *object) > > +{ > > + struct folio *folio; > > + > > + if (unlikely(object == ZERO_SIZE_PTR)) > > + return 0; > > + > > + folio = virt_to_folio(object); > > + > > +#ifdef CONFIG_SLUB > > + if (unlikely(!folio_test_slab(folio))) > > + return folio_size(folio); > > +#endif > > + > > + return slab_ksize(folio_slab(folio)->slab_cache); > > ... and here in the common version you now for SLAB trust that the folio > will be a slab folio, thus undoing the intention of that commit. Maybe > that's not good and we should keep the folio_test_slab() for both cases? > Although maybe it's also strange that prior this patch, SLAB would return 0 > if the test fails, and SLUB would return folio_size(). Probably because with > SLUB this can be a large kmalloc here and with SLAB not. So we could keep > doing that in the unified version, or KASAN devs (CC'd) could advise > something better? Is this a definitive failure case? My opinion here is that returning 0 from ksize() in case of failure will a) provide a way to check for error, and b) if the size is used unconditionally to compute an address may be the more graceful failure mode (see comment added in 0d4ca4c9bab39 for what happens if we see invalid memory per KASAN being accessed).