Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp234989pxk; Fri, 11 Sep 2020 05:35:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwj3oLPFH1yRgDTmUEk+F7LY8XNaCUzir93bCy7KhM8QaBg93sJx8T+B0hvP4YQoVh3UrgX X-Received: by 2002:a50:fb18:: with SMTP id d24mr1741387edq.149.1599827748255; Fri, 11 Sep 2020 05:35:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599827748; cv=none; d=google.com; s=arc-20160816; b=lxYCMukuznDQNwFFtobW4A26uQ0kUfhIOwa9kUvk8JKP0rhNah/hbCKDQBPVktXdvj y8Z9yu7MrhWsKaBkGBtg+KoUjRyKI6z8fl0GFPyNozwsfal3TMpgcHq2k0hrLcU1k3u9 EPIM8nJ1zOCVJSsSuYvUDdqzCXo52Cmtv5UUtM+WMHRsf1bacS50lT7d3O65xkVXHOjt qS8iB42MbYFNzxF/hXmsHLs5UWGrKcxS+n6EMyz/jd7eevmw9H86Qbh6fUv4YfAdKjhN X+0YDFXmGdZ3jU0ig3GvxAARrrs2+RSbqmY2nvOONv5/4U8+wk3S+bu2a3WaBSvcfSJw 4tMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=zszRmbpQKBS0800usmmxgfyOo7qtmKwLO7PwkfuP3F8=; b=EjHoOUbgSh+FJENX4AIix5FwJaSIdtIuJrEKA829NsQnAC2PZkZu5/lqnvB9zx39wZ T5We2Zj6wwPe+rM+/aoO7SwmRAlpGOW+4AsVAhkEdgZp7T2k7emgp6DZc70Ny4+iZ4U+ DLnT4rYVDGM0jigeDSkgAHQvAkGyQBDoMgRUeNkaRIrIaSuI9pONZQvUXDsDiEl9jPBK DTJ7fqXYGLUIMS+krhdu5tdsVA6O7noWCr+yTpMwr50pGMlYzHw8Em31/fbx0aYRit7y DoxaTQzv4wytxvRzxmsYkQjPbKlZLSykc8wUZU3qha0FS8HJNtf12LKc4RbRzwjDKN2x 6CFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=AmQEQaDw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qt8si1153373ejb.159.2020.09.11.05.35.24; Fri, 11 Sep 2020 05:35:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=AmQEQaDw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725909AbgIKMaw (ORCPT + 99 others); Fri, 11 Sep 2020 08:30:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725895AbgIKMYW (ORCPT ); Fri, 11 Sep 2020 08:24:22 -0400 Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A510C061756 for ; Fri, 11 Sep 2020 05:24:20 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id w25so6931933otk.8 for ; Fri, 11 Sep 2020 05:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zszRmbpQKBS0800usmmxgfyOo7qtmKwLO7PwkfuP3F8=; b=AmQEQaDwdqKJEzBUQY5LjoMckUpmTiNa/rA3A6EyryNH5Q3YCUm/WD8+II8tBEbfkf ReuQdzPVdnmecQIYWueOlcTfY17HwKnj4IID2x0dAsR1+kMv5MZDWlDpFMRzo+CGyGlR Bh7iwTMpNIbD/tZDMU/CQZghNGaAT3u//6VOnELzpB5Iteowtb2ourR3U9ycUtkHxTdq isLv7eIX/+kCQVTyqdbwaDg36ceXn+sm9A9EYIy/fCtX3t9dECkFwtRofM+QmtZQ4Vs1 8iSSuDyWJCmPXzF9i8yDc/n8I7BXKUh0deZFZEAnx5CahcEDu1FpOzw+UfmtxzcQ3sKu M1BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zszRmbpQKBS0800usmmxgfyOo7qtmKwLO7PwkfuP3F8=; b=aIeyiVSKVvUZkVZWoFjD4B6wUhAXdja7CWElcnWyOP4/SG09Q4l4WtPRmFD+3fJc91 wQxwhsmFfUYWkIiNovZE6VX0HdbZhKeUv2YRF0zZAXPt8UEWYiwJn7QwGwwIBBxYFNjE MX+NXI8AbzxbAm5Sej7/KWysEPpfVXD5+Y4jBn3wlvuGF+8yVWJtMODt9e3g/cP1eUBr adshi8af5p5t34MkqSJscmAWgKQEYk+BaSnfzwBMZTLviidiooF0CLpVRIOWsgDBbSNJ dTOYYiq2SEChvvtFAH6DTXqYBCrCb1ViwvgbDR90BNZqAe/xmy3F50uKQxl3kJ2i4sfU gF5w== X-Gm-Message-State: AOAM533HVZXAGWQJxKXqpIybAzLX1SGWkvG59piAxRY0C49T0ZWvXs+l JflD41VfuJwli+J6yV3sxgep4XsgERbaoT5nWJSSKA== X-Received: by 2002:a05:6830:1e8c:: with SMTP id n12mr1091647otr.17.1599827058228; Fri, 11 Sep 2020 05:24:18 -0700 (PDT) MIME-Version: 1.0 References: <20200907134055.2878499-1-elver@google.com> <20200907134055.2878499-5-elver@google.com> In-Reply-To: From: Marco Elver Date: Fri, 11 Sep 2020 14:24:06 +0200 Message-ID: Subject: Re: [PATCH RFC 04/10] mm, kfence: insert KFENCE hooks for SLAB To: Dmitry Vyukov Cc: Alexander Potapenko , Andrew Morton , Catalin Marinas , Christoph Lameter , David Rientjes , Joonsoo Kim , Mark Rutland , Pekka Enberg , "H. Peter Anvin" , "Paul E. McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Dave Hansen , Eric Dumazet , Greg Kroah-Hartman , Ingo Molnar , Jann Horn , Jonathan Corbet , Kees Cook , Peter Zijlstra , Qian Cai , Thomas Gleixner , Will Deacon , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , LKML , kasan-dev , Linux ARM , Linux-MM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 11 Sep 2020 at 09:17, Dmitry Vyukov wrote: > > On Mon, Sep 7, 2020 at 3:41 PM Marco Elver wrote: > > > > From: Alexander Potapenko > > > > Inserts KFENCE hooks into the SLAB allocator. > > > > We note the addition of the 'orig_size' argument to slab_alloc*() > > functions, to be able to pass the originally requested size to KFENCE. > > When KFENCE is disabled, there is no additional overhead, since these > > functions are __always_inline. > > > > Co-developed-by: Marco Elver > > Signed-off-by: Marco Elver > > Signed-off-by: Alexander Potapenko > > --- > > mm/slab.c | 46 ++++++++++++++++++++++++++++++++++------------ > > mm/slab_common.c | 6 +++++- > > 2 files changed, 39 insertions(+), 13 deletions(-) > > > > diff --git a/mm/slab.c b/mm/slab.c > > index 3160dff6fd76..30aba06ae02b 100644 > > --- a/mm/slab.c > > +++ b/mm/slab.c > > @@ -100,6 +100,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -3206,7 +3207,7 @@ static void *____cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, > > } > > > > static __always_inline void * > > -slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid, > > +slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid, size_t orig_size, > > unsigned long caller) > > { > > unsigned long save_flags; > > @@ -3219,6 +3220,10 @@ slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid, > > if (unlikely(!cachep)) > > return NULL; > > > > + ptr = kfence_alloc(cachep, orig_size, flags); > > + if (unlikely(ptr)) > > + goto out_hooks; > > + > > cache_alloc_debugcheck_before(cachep, flags); > > local_irq_save(save_flags); > > > > @@ -3251,6 +3256,7 @@ slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid, > > if (unlikely(slab_want_init_on_alloc(flags, cachep)) && ptr) > > memset(ptr, 0, cachep->object_size); > > > > +out_hooks: > > slab_post_alloc_hook(cachep, objcg, flags, 1, &ptr); > > return ptr; > > } > > @@ -3288,7 +3294,7 @@ __do_cache_alloc(struct kmem_cache *cachep, gfp_t flags) > > #endif /* CONFIG_NUMA */ > > > > static __always_inline void * > > -slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller) > > +slab_alloc(struct kmem_cache *cachep, gfp_t flags, size_t orig_size, unsigned long caller) > > { > > unsigned long save_flags; > > void *objp; > > @@ -3299,6 +3305,10 @@ slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller) > > if (unlikely(!cachep)) > > return NULL; > > > > + objp = kfence_alloc(cachep, orig_size, flags); > > + if (unlikely(objp)) > > + goto leave; > > + > > cache_alloc_debugcheck_before(cachep, flags); > > local_irq_save(save_flags); > > objp = __do_cache_alloc(cachep, flags); > > @@ -3309,6 +3319,7 @@ slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller) > > if (unlikely(slab_want_init_on_alloc(flags, cachep)) && objp) > > memset(objp, 0, cachep->object_size); > > > > +leave: > > slab_post_alloc_hook(cachep, objcg, flags, 1, &objp); > > return objp; > > } > > @@ -3414,6 +3425,11 @@ static void cache_flusharray(struct kmem_cache *cachep, struct array_cache *ac) > > static __always_inline void __cache_free(struct kmem_cache *cachep, void *objp, > > unsigned long caller) > > { > > + if (kfence_free(objp)) { > > + kmemleak_free_recursive(objp, cachep->flags); > > + return; > > + } > > + > > /* Put the object into the quarantine, don't touch it for now. */ > > if (kasan_slab_free(cachep, objp, _RET_IP_)) > > return; > > @@ -3479,7 +3495,7 @@ void ___cache_free(struct kmem_cache *cachep, void *objp, > > */ > > void *kmem_cache_alloc(struct kmem_cache *cachep, gfp_t flags) > > { > > - void *ret = slab_alloc(cachep, flags, _RET_IP_); > > + void *ret = slab_alloc(cachep, flags, cachep->object_size, _RET_IP_); > > > It's kinda minor, but since we are talking about malloc fast path: > will passing 0 instead of cachep->object_size (here and everywhere > else) and then using cachep->object_size on the slow path if 0 is > passed as size improve codegen? It doesn't save us much, maybe 1 instruction based on what I'm looking at right now. The main worry I have is that the 'orig_size' argument is now part of slab_alloc, and changing its semantics may cause problems in future if it's no longer just passed to kfence_alloc(). Today, we can do the 'size = size ?: cache->object_size' trick inside kfence_alloc(), but at the cost breaking the intuitive semantics of slab_alloc's orig_size argument for future users. Is it worth it? Thanks, -- Marco