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 7A799C4363D for ; Fri, 2 Oct 2020 07:07:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 268BC2072E for ; Fri, 2 Oct 2020 07:07:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="lGd6dHat" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726229AbgJBHHh (ORCPT ); Fri, 2 Oct 2020 03:07:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbgJBHHg (ORCPT ); Fri, 2 Oct 2020 03:07:36 -0400 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D6EFC0613D0 for ; Fri, 2 Oct 2020 00:07:36 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id c8so599359edv.5 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=PL1b/9Vfp2FXF50xKHWkZBBFPrRxRGsGZ5e7CNOeRJhIEWNevOa9Jh9LuV+rtmd1T+ IOKNKqSydPRxTiE9xNXaEPOv425qZIpIKY7SPMJ3CNj7MJ8ddxAoGO578baZu0D3yOTl ae/q0bWJLMsUxP2BteXFGY1M9qcNTLv82pLoAJfryEDlK2/oFDBfcujeX47g87fUm/uU 5SY36nhZ+CbJIR301bF7ZAi7XoBtlFdP/mElbS2sOSP6fffJX6SzDw8vO6eDvFPCO0EE XtXC2lxjH3tOpb8X6ODCv4CMxtHU07faalt8Fiv06DiBL+BWFbkZGMhpBkqh4MCkhBvU xhGA== X-Gm-Message-State: AOAM530dx+v6LwmPk766BRuO+T+3E25MQf547Sc/IVqN2jF7ugSp+5sy /Uf+TK0gpMHw2Gvg6PFVJdcArva9wffynLF+8iQodw== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 1C239C4363D for ; Fri, 2 Oct 2020 07:09:11 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A6CD6206DD for ; Fri, 2 Oct 2020 07:09:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AQi0ZsdQ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="lGd6dHat" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6CD6206DD Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=l+RGajdJx1z+JL6xb066Yaw89UzW5KVH2nvsQcPqh8I=; b=AQi0ZsdQ0m4PNiEOqDOS/5OlY jQErSZgu5AWhj2N12P5MLzBj2M2fuGOtWaNHsoXVJKqoQaJuVL49O2fvBI4c7yhHyKrNuQsJ+wAEq lei1dBMFKeZUmBwzjNSXZhkZmlRLxNB1PkAj5RNJ2a8i+HRVqFIglzqKDtL7EGj3oRGl1dsHdgrBx /BvXZAWOCnDtWJsWbbrX7Jh92Noe6ExnoqACg8onVKZPp5YH1EG1Hd5MSIsDB2I1c0O2l5vgH6mfY VuEF6t/aLXEqtk0u8uZaqCz0Ek0Ijgl8NyVf1q2BoujVmM0HiyKB2c95oOtDXvgx9WS3B375hdbZP DSqhkTZqw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOFAJ-0005on-OT; Fri, 02 Oct 2020 07:07:39 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOFAG-0005ng-Up for linux-arm-kernel@lists.infradead.org; Fri, 02 Oct 2020 07:07:37 +0000 Received: by mail-ed1-x542.google.com with SMTP id dn5so581717edb.10 for ; Fri, 02 Oct 2020 00:07:35 -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=HmB8GyrRMhn+AJs27MySh1hEckjfUKLatE1WoAQ3sAK92t6FK0mKsgfBxBMs6NWS+/ N1cfeagGzRA3GY2GEX0xtI+QkLfl0390tXB7+YV+Akmru7huAV4mDC3vozUrW883VoJo LG31zOGGUTcC7A9/cHJmKoLez0U8PY1Rq12VVohqp3x8HLA71/v5OKyNk8maWVtiTQ+d 2FpgHFdSJ1iKCO2On/OCvfvBdWYiQxsUytTrsrDjrRPXu3Ec0d9U0gZBAcP5h5ymyLT7 ZBsAwu7zeuCD8wTtb7JN1x4XZxakSHGQRBApbCsOswjtT+gjgwBVoZMbox+yBTnPiUBo snCg== X-Gm-Message-State: AOAM533lgSUXmMamHQJdOInHoYDA2OSaGV4bsMc1JSNtp5IudDJx6y0v vwUf0gjDWE0KtC8+/qP/drEHiTycf4Jx/FKvF79hbQ== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201002_030737_052156_81E2F253 X-CRM114-Status: GOOD ( 18.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Hillf Danton , linux-doc@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Dave Hansen , Linux-MM , Eric Dumazet , Alexander Potapenko , "H . Peter Anvin" , Will Deacon , sjpark@amazon.com, Jonathan Corbet , the arch/x86 maintainers , kasan-dev , Ingo Molnar , Vlastimil Babka , David Rientjes , Andrey Ryabinin , Kees Cook , "Paul E . McKenney" , Andrey Konovalov , Borislav Petkov , Andy Lutomirski , Jonathan.Cameron@huawei.com, Thomas Gleixner , Joonsoo Kim , Dmitry Vyukov , Linux ARM , Greg Kroah-Hartman , kernel list , Pekka Enberg , Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel