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 X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8624FC4363D for ; Fri, 2 Oct 2020 07:09:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1796E206DD for ; Fri, 2 Oct 2020 07:09:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="lGd6dHat" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1796E206DD Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 69FC86B007B; Fri, 2 Oct 2020 03:09:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64F336B007D; Fri, 2 Oct 2020 03:09:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 53E276B007E; Fri, 2 Oct 2020 03:09:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id 23F6C6B007B for ; Fri, 2 Oct 2020 03:09:32 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B20078249980 for ; Fri, 2 Oct 2020 07:09:31 +0000 (UTC) X-FDA: 77326109742.26.wheel28_2b06565271a2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id BF6D718049B71 for ; Fri, 2 Oct 2020 07:07:36 +0000 (UTC) X-HE-Tag: wheel28_2b06565271a2 X-Filterd-Recvd-Size: 5617 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Fri, 2 Oct 2020 07:07:36 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id g3so591178edu.6 for ; Fri, 02 Oct 2020 00:07:36 -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=Ye/s+D4VgMKbfo7kHtFUxt4Yo6siN0GRSwJxDl1BL+I=; b=lGd6dHatt84jG23C4UbyRVcWWz0xn0Qrfij2A3wZfpYYjg9fPxAAd7grU5d8oUMsDT 7i3mC0uZujFHrRo5Kn7Ud1Eqj+wbu56Oi9N9sZdoAI4yvulybbON8fDDp7ueDbYsAJu8 K9HpYk48IbvvgxtQtjpQ+sDnTndH6h5h27ukC6sI3FlQpdE1xafysZbwQYl/d6AiQxhr 3cSCz3a9HVxJDlpGlxlK5xpA4oiHDi+nGtJvd+rDTIi8z5xCrPthNReLCeCZyWYox62T AKraMFe1S6O12Elu7j8RB9iXjo4zADGodhyx0ZgiTER3GmnSP48NewOSn33riX4PKmTQ 1COw== 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=Ye/s+D4VgMKbfo7kHtFUxt4Yo6siN0GRSwJxDl1BL+I=; b=ZfnmLgqeNarITozXAmPyvxsMSW8O+enQbUjMunIQwBosf7rBBB8rHsU5wimX9X2Xc7 KsXeh95FsRwgPHHPhfeFzhdxSl3D6TOZEzCk7yhfYD4r9BIYqQi7USmpBYp1aJ4I2yYe ck437sxYeOsKClxQvxJ1iwz7W+yTt9TN8IonXuAcp8WAzz2G3iECrO0ibnP6vhwQ8GRN DzbCNYTB3mTCOccpOruDl0yAFbLIpuqvqBNp7ZuRRdvPFPKNe6RhykAkPOKqZiXjiqTK 0y60WFt0Ntg3NxI1ZNIKpWwekX8q6OsUzmtsr76qFB2XYC07FLjbC96nunlx8K/RnSQj txXw== X-Gm-Message-State: AOAM530vVBj6sqiK4k5pQ+Qt6CIMwGuKyQAFNRieHs0duew6DVkqGfyT +qPt4zTYEvUrCM6MDdzOjkX4a5c1Xk8TllHpEIQe9Q== X-Google-Smtp-Source: ABdhPJzgVIGLadHTIUq/65YztskB32r0plXShVqth5zW5ceX8yhFiQj5pLoO1PgEF7cgm0dwaKz6WJ+SAn/4YSsANOY= X-Received: by 2002:a05:6402:b0e:: with SMTP id bm14mr892264edb.259.1601622454831; Fri, 02 Oct 2020 00:07:34 -0700 (PDT) MIME-Version: 1.0 References: <20200929133814.2834621-1-elver@google.com> <20200929133814.2834621-6-elver@google.com> In-Reply-To: <20200929133814.2834621-6-elver@google.com> From: Jann Horn Date: Fri, 2 Oct 2020 09:07:08 +0200 Message-ID: Subject: Re: [PATCH v4 05/11] mm, kfence: insert KFENCE hooks for SLUB To: Marco Elver , Christoph Lameter Cc: Andrew Morton , Alexander Potapenko , "H . Peter Anvin" , "Paul E . McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jonathan.Cameron@huawei.com, Jonathan Corbet , Joonsoo Kim , Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , sjpark@amazon.com, Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , linux-doc@vger.kernel.org, kernel list , kasan-dev , Linux ARM , Linux-MM Content-Type: text/plain; charset="UTF-8" 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 Tue, Sep 29, 2020 at 3:38 PM Marco Elver wrote: > Inserts KFENCE hooks into the SLUB allocator. [...] > diff --git a/mm/slub.c b/mm/slub.c [...] > @@ -3290,8 +3314,14 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t flags, size_t size, > c = this_cpu_ptr(s->cpu_slab); > > for (i = 0; i < size; i++) { > - void *object = c->freelist; > + void *object = kfence_alloc(s, s->object_size, flags); kfence_alloc() will invoke ->ctor() callbacks if the current slab has them. Is it fine to invoke such callbacks from here, where we're in the middle of a section that disables interrupts to protect against concurrent freelist changes? If someone decides to be extra smart and uses a kmem_cache with a ->ctor that can allocate memory from the same kmem_cache, or something along those lines, this could lead to corruption of the SLUB freelist. But I'm not sure whether that can happen in practice. Still, it might be nicer if you could code this to behave like a fastpath miss: Update c->tid, turn interrupts back on (___slab_alloc() will also do that if it has to call into the page allocator), then let kfence do the actual allocation in a more normal context, then turn interrupts back off and go on. If that's not too complicated? Maybe Christoph Lameter has opinions on whether this is necessary... it admittedly is fairly theoretical. > + if (unlikely(object)) { > + p[i] = object; > + continue; > + } > + > + object = c->freelist; > if (unlikely(!object)) { > /* > * We may have removed an object from c->freelist using