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 95B89C4363A for ; Mon, 5 Oct 2020 09:29:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 26F8020796 for ; Mon, 5 Oct 2020 09:29:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="RD6Sa7SS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 26F8020796 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 3E6696B005D; Mon, 5 Oct 2020 05:29:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 397C36B0062; Mon, 5 Oct 2020 05:29:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23B5F6B0068; Mon, 5 Oct 2020 05:29:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id EB37A6B005D for ; Mon, 5 Oct 2020 05:29:31 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 87B04C5A0 for ; Mon, 5 Oct 2020 09:29:31 +0000 (UTC) X-FDA: 77337348942.19.coal92_030212c271bd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 67EED1AD1B4 for ; Mon, 5 Oct 2020 09:29:31 +0000 (UTC) X-HE-Tag: coal92_030212c271bd X-Filterd-Recvd-Size: 6704 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 09:29:30 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id k18so8023967wmj.5 for ; Mon, 05 Oct 2020 02:29:30 -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:content-transfer-encoding; bh=NkkZ0AZItfPzXXyiWUs3wdbhFkdEuozzWE5YN7fX2Ds=; b=RD6Sa7SS02XMmSEITYc+16rUxDLnGebQGiPycqS2AHIUGt1HKXcbyFJO2j0zhLR3ZV MYcG6n/KPVssa/d74T6uHaLPmzw2YIJ1RxZv5UH86MyTQlbgSGwcY3lCojdvHOvoyLYr 3InQKiPVQXm4doK9Npsgmpq0pyMNNUx9LU9zwy/R4Ti81NIxZHdTsUYc32lFcxjUghCM zJUY/Iu5ON7FYBKZ9+lmmO5Sk7FYh54C7wOC7bqTUUXmPugywv4W1v8BMeNvxBdNZqK5 TkRXl7IBaL10uym0Pw2B4bUGB1dniXKZJs8Nz3qozzlnsaxB/V2jYceXHMtovB6Oemp3 S4+A== 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:content-transfer-encoding; bh=NkkZ0AZItfPzXXyiWUs3wdbhFkdEuozzWE5YN7fX2Ds=; b=Ljt8fT2c4VKiLlfpzGk/ZkNKpa6MOo25ShyIm9vl78laikvvWHDEktXiVPvW9jMXvJ 6WSsF3+pIj0UJRZCk1zxJD9CCsJEnszOECWPppzLaP9IhS0FIBtWaDrPDLLI/iZBP+to FbK9o6a2A6/wmG2NeQHo0VDVXVW7W3uBZovJXXq1p8XjZScnd8M8YJfl9Tk1dBPTErOb t8rUa/BhsINt3Ikm4DWSjoQif+Lmp634mHJOOzwp0Q09ASLTFxJSEKDLCWGlmSkqNW9D m2p41tNp5vm6Yg9/gy9luprdGQaIpEoPgIYuamsVWGS0WfVGQ6NusSVBPaTMVd1Vjh8z u5mA== X-Gm-Message-State: AOAM5336aXoB+qJrjrhc9m2/GcvSbfPyiEic8lh86DbnRUAjwLJ392Xm BeHfYuFYjGVkBwTyDNSptwv/kzIM1ye2p9XILLK2nA== X-Google-Smtp-Source: ABdhPJzdTHCSzPEmyky+jVTYpmIeNA4gwh4eafVoKki6ciFaZTe6pNy41Z81p02iQGgR8m4sm1feM4sG9bAxg7oIc+Q= X-Received: by 2002:a7b:cd93:: with SMTP id y19mr15306469wmj.112.1601890169505; Mon, 05 Oct 2020 02:29:29 -0700 (PDT) MIME-Version: 1.0 References: <20200929133814.2834621-1-elver@google.com> <20200929133814.2834621-6-elver@google.com> In-Reply-To: From: Alexander Potapenko Date: Mon, 5 Oct 2020 11:29:18 +0200 Message-ID: Subject: Re: [PATCH v4 05/11] mm, kfence: insert KFENCE hooks for SLUB To: Jann Horn Cc: Marco Elver , Christoph Lameter , Andrew Morton , "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 , Jonathan Corbet , Joonsoo Kim , Kees Cook , Mark Rutland , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , kernel list , kasan-dev , Linux ARM , Linux-MM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Fri, Oct 2, 2020 at 9:07 AM Jann Horn wrote: > > 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 =3D this_cpu_ptr(s->cpu_slab); > > > > for (i =3D 0; i < size; i++) { > > - void *object =3D c->freelist; > > + void *object =3D 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. >From cache_init_objs_debug() in mm/slab.c: /* * Constructors are not allowed to allocate memory from the= same * cache which they are a constructor for. Otherwise, dead= lock. * They must also be threaded. */ So, no, it is not allowed to allocate from the same cache in the constructo= r. > 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] =3D object; > > + continue; > > + } > > + > > + object =3D c->freelist; > > if (unlikely(!object)) { > > /* > > * We may have removed an object from c->freeli= st using -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg