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=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham 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 29733C43603 for ; Tue, 10 Dec 2019 12:07:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C4333207FF for ; Tue, 10 Dec 2019 12:07:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="BTApMeZ0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4333207FF 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 2ACA96B2C38; Tue, 10 Dec 2019 07:07:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 25D266B2C39; Tue, 10 Dec 2019 07:07:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1735B6B2C3A; Tue, 10 Dec 2019 07:07:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id F32456B2C38 for ; Tue, 10 Dec 2019 07:07:32 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 933338249980 for ; Tue, 10 Dec 2019 12:07:32 +0000 (UTC) X-FDA: 76249107144.18.turn52_5edbe4a08270d X-HE-Tag: turn52_5edbe4a08270d X-Filterd-Recvd-Size: 7317 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Dec 2019 12:07:31 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id q10so19762581wrm.11 for ; Tue, 10 Dec 2019 04:07:31 -0800 (PST) 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=zMPJ7hiQl32Ct/saDrjCV/lLWCrgVaXSuXJIcr4iB6c=; b=BTApMeZ0p7rj6cAAVu7KXlvsElVkBiwZgsiD1AS6xBdtyakbHidv+qHfdyj/Op6dND +C8+n4d5LWVeRD7S/YU23KBFcrTu4Dfog4gF141kPl26DrRMdkwDeyn2yxAe+zSjqKny 5J3eqW/1VQySKbnyg400QgowQNsDuWmed8AFl07V/QlcEi0/ehS/uKbInLIl2WZzf3VG 0tH0BagHLI/Ajz77B3tsoYYuPoKmAO+VSicJ5zm5P22hdyx6tPy5JpSGrxR4p/N2tCp2 DMq/rPGVNODHgKW96RcBw8jSQWEMfDt854ZV44ZoXRSudjXTMdIOSt61rEzX0vxSamBv dd1g== 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=zMPJ7hiQl32Ct/saDrjCV/lLWCrgVaXSuXJIcr4iB6c=; b=d5b+k56dcpKdP9fnHsp/ZTWGE0ADN8fn4Am+mW7+2k59RhxwijjYl6Y3Wt05FYNEVm X8lrI8A3CSWjgda1c8biOAYsCNeYRHydFPGlBrLsFNxajZFOsfyl88hzLHyvr/CGCzC5 yeKBfQ0rHu1tTSGeAhj4XYSY3mpIFoFFbWUatsui1CHPFysODDFUL3BT57ErgBHiQmhi vjf65+cAUzvQGez3sZ3M7f0e+eZMgeYOaWSxpu2StkIu9xDaO59UWMa3nh6OhH85ajJl r5+dpkUaRhR1juTD2ajAuJWbwVpZCD1600fZRu/bznAAAF6JKY6oLkGo/amVx0rSntCb HdPw== X-Gm-Message-State: APjAAAXZN62u4gP+PorFu8R+CPwRUNTcV/TB+11UBnjEQ19ke5d2e9D5 1s3j/4tTmgh3oytpJb6ChtWeUH3aPsMQTVOO2rgh1YZJlYg= X-Google-Smtp-Source: APXvYqxvTklU5X8dXQcu41+xr8u2wnCYuVsyS3a4Z7xyB1/7PiVDCFICbmF6L3MYlkf4q35nqpN21DTGe9/x6zfZWzc= X-Received: by 2002:adf:f28c:: with SMTP id k12mr2850732wro.360.1575979650290; Tue, 10 Dec 2019 04:07:30 -0800 (PST) MIME-Version: 1.0 References: <20191122112621.204798-1-glider@google.com> <20191122112621.204798-23-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Tue, 10 Dec 2019 13:07:19 +0100 Message-ID: Subject: Re: [PATCH RFC v3 22/36] kmsan: mm: call KMSAN hooks from SLUB code To: Marco Elver Cc: Andrew Morton , Vegard Nossum , Dmitry Vyukov , Linux Memory Management List , Al Viro , Andreas Dilger , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Christoph Hellwig , Christoph Hellwig , "Darrick J. Wong" , "David S. Miller" , Dmitry Torokhov , Eric Biggers , Eric Dumazet , Eric Van Hensbergen , Greg Kroah-Hartman , Harry Wentland , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jason Wang , Jens Axboe , Marek Szyprowski , Mark Rutland , "Martin K. Petersen" , Martin Schwidefsky , Matthew Wilcox , "Michael S. Tsirkin" , Michal Simek , Petr Mladek , Qian Cai , Randy Dunlap , Robin Murphy , Sergey Senozhatsky , Steven Rostedt , Takashi Iwai , "Theodore Ts'o" , Thomas Gleixner , Vasily Gorbik , Wolfram Sang 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 Mon, Dec 2, 2019 at 4:37 PM Marco Elver wrote: > > On Fri, 22 Nov 2019 at 12:27, wrote: > > > > In order to report uninitialized memory coming from heap allocations > > KMSAN has to poison them unless they're created with __GFP_ZERO. > > > > It's handy that we need KMSAN hooks in the places where > > init_on_alloc/init_on_free initialization is performed. > > > > Signed-off-by: Alexander Potapenko > > To: Alexander Potapenko > > Cc: Andrew Morton > > Cc: Vegard Nossum > > Cc: Dmitry Vyukov > > Cc: linux-mm@kvack.org > > --- > > v3: > > - reverted unrelated whitespace changes > > > > Change-Id: I51103b7981d3aabed747d0c85cbdc85568665871 > > --- > > mm/slub.c | 34 +++++++++++++++++++++++++++++----- > > 1 file changed, 29 insertions(+), 5 deletions(-) > > > > diff --git a/mm/slub.c b/mm/slub.c > > index b25c807a111f..b5d2be1ac755 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -21,6 +21,8 @@ > > #include > > #include > > #include > > +#include > > +#include /* KMSAN_INIT_VALUE */ > > #include > > #include > > #include > > @@ -285,17 +287,27 @@ static void prefetch_freepointer(const struct kme= m_cache *s, void *object) > > prefetch(object + s->offset); > > } > > > > +/* > > + * When running under KMSAN, get_freepointer_safe() may return an unin= itialized > > + * pointer value in the case the current thread loses the race for the= next > > + * memory chunk in the freelist. In that case this_cpu_cmpxchg_double(= ) in > > + * slab_alloc_node() will fail, so the uninitialized value won't be us= ed, but > > + * KMSAN will still check all arguments of cmpxchg because of imperfec= t > > + * handling of inline assembly. > > + * To work around this problem, use KMSAN_INIT_VALUE() to force initia= lize the > > + * return value of get_freepointer_safe(). > > + */ > > Isn't this a general problem with cmpxchg? I.e. does other code using > it have the same problem? > > Would it be better to just use KMSAN_INIT_VALUE in cmpxchg, rather > than having the one-off workaround here? I don't think so. It's normally still an error to pass an uninitialized arg to cmpxchg, as in other cases it may be copied to the result. > Thanks, > -- Marco --=20 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