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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 63834C2D0E5 for ; Wed, 25 Mar 2020 18:30:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 03A5520777 for ; Wed, 25 Mar 2020 18:30:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="plLH54uH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03A5520777 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 51A506B00C2; Wed, 25 Mar 2020 14:30:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CA426B00C3; Wed, 25 Mar 2020 14:30:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E1816B00CA; Wed, 25 Mar 2020 14:30:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id 2738F6B00C2 for ; Wed, 25 Mar 2020 14:30:23 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E241D824805A for ; Wed, 25 Mar 2020 18:30:22 +0000 (UTC) X-FDA: 76634724684.08.wing07_3490b6d6bb1e X-HE-Tag: wing07_3490b6d6bb1e X-Filterd-Recvd-Size: 7117 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Mar 2020 18:30:22 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id m17so4435349wrw.11 for ; Wed, 25 Mar 2020 11:30:22 -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=cynoTBAdiNEB3coggKzQoXHODDRkqp6A6k7GyE4EpPw=; b=plLH54uHZvbHU+aW2NDcpBezjBwu92kd6+CcIo41v3oWh3KxJz+TSd5sXAa1VyJd1l LZE0HyHd1oc4zhi6qT5LsnAxh38XYshSL2M6nGs8eKBK1eTDF+0ZUHLp5gkIlpIvYkmc BjTajNAr1TNCkhPCxws85tWtipsRYMMHbhOiil4huBH64TnLhKF66opp+XgRcBhshrr9 qfe3IIAlb5tKTSu8FL+TTXW/I5DrtrmbVteX19KePwH3taOX/Dc5Ko+Xf6iyB47/Eu5X UI8qIWXBze62kSrKj3zVG8+a5LdjH7qku+7W9jTvQUpLrOhx0XrrOEIe1dLA/cKK+Gl4 QQ2A== 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=cynoTBAdiNEB3coggKzQoXHODDRkqp6A6k7GyE4EpPw=; b=dPPZSVSG1sR84XBKNGG0uK5QGDxjSsg1sO87wx85M5N16zJQahwteN33qWFGNc7kec /L5FBaKNIfKX+8b6XsfYCn3k91K7UGX9jwU8sTxZz6lCY1KQpPSQN9MA/b1UHso8vr5z 2EwN9dpGHuKMH3sDvSOMr4eaEXBb0MlVN+/nV3DgNLInpzhLqEt/Bnso+D3CQPQwX1sQ 66jWdHTrbNa8IHFkEs8pZ93Q4U9DUkPP6uGNhXA+OygRbkAAVjCfgZTqQvNrgReS+XQL r+2ygX/fZJJpxuIBiMI1Sw37YxAWkQpYAr2mk8ySu8paTym3cp2HBIbSxesCm8wO7uy2 uTEg== X-Gm-Message-State: ANhLgQ1o55W193d+RiHAFgaohMIlVBJsi1UQu/p/Ftky3caOMXUJcUcR 3aifx0tNWhpPCHbiH0vVDbqHtzRGglqknUrf9hi7Pg== X-Google-Smtp-Source: ADFU+vt5abmDH6c9niy5vM51DjkNKpDciB/v2vZ2Uu8tZPY9tMdn0NLLgIkYsq3v0Oxf2JH1Y8E8iJWd8zMN/NuIZJ4= X-Received: by 2002:a05:6000:100f:: with SMTP id a15mr4636013wrx.382.1585161020734; Wed, 25 Mar 2020 11:30:20 -0700 (PDT) MIME-Version: 1.0 References: <20200325161249.55095-1-glider@google.com> <20200325161249.55095-4-glider@google.com> <20200325161952.GF19542@dhcp22.suse.cz> <20200325174916.GC22483@bombadil.infradead.org> <20200325180941.GD22483@bombadil.infradead.org> In-Reply-To: <20200325180941.GD22483@bombadil.infradead.org> From: Alexander Potapenko Date: Wed, 25 Mar 2020 19:30:09 +0100 Message-ID: Subject: Re: [PATCH v5 03/38] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW To: Matthew Wilcox Cc: Michal Hocko , Vegard Nossum , Andrew Morton , Dmitry Vyukov , Marco Elver , Andrey Konovalov , Linux Memory Management List , Al Viro , Andreas Dilger , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Christoph Hellwig , Christoph Hellwig , "Darrick J. Wong" , David 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 , "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 Wed, Mar 25, 2020 at 7:09 PM Matthew Wilcox wrote: > > On Wed, Mar 25, 2020 at 07:03:32PM +0100, Alexander Potapenko wrote: > > > I would suggest using bits in the section labelled: > > > > > > /* Unserialized, strictly 'current' */ > > > > The main problem is that |current| is unavailable in the interrupt > > context, so we'll also need to: > > - disable interrupts when preparing for a KMSAN internal memory > > allocation - sounds costly, huh? > > - store the context flag in a per-cpu variable in the case |current| > > is unavailable. > > It's not /unavailable/ ... it's whatever task happens to be running at > the time the interrupt is triggered. You can borrow its task_struct. That didn't come to my mind, interesting! > You'll have to save off the current value of the flag before setting it, > just like memalloc_nofs_save() does. > But this does rather call into question whether Michal's advice to use > task_struct is good advice to begin with. For memalloc_nofs/noio, > it works well this way because allocations in interrupt context are > inherently at a more restrictive context than task level. It's not clear > to me what this kmsan GFP flag is being used for, and whether allocations > that happen in interrupt context should inherit the kmsan setting. The idea behind this flag is as follows. KMSAN must allocate metadata pages for every allocation performed by alloc_pages(). Metadata allocations are also done via alloc_pages(), and for those no further metadata needs to be allocated. Thus the GFP flag is used to prevent the recursion in alloc_pages(). It is theoretically possible that a less restrictive allocation (without __GFP_NO_KMSAN_SHADOW) happens in an interrupt on top of a task performing a more restrictive allocation (with __GFP_NO_KMSAN_SHADOW). > I will have to read these patches more carefully to determine that; > I was really just responding to the "where can I find some free bits" > part of the question. Thanks for clarification. --=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