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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 241FFC2D0EA for ; Wed, 25 Mar 2020 17:43:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EDA27208CA for ; Wed, 25 Mar 2020 17:43:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EDA27208CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 95C936B00BE; Wed, 25 Mar 2020 13:43:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E55D6B00BF; Wed, 25 Mar 2020 13:43:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7AD406B00C0; Wed, 25 Mar 2020 13:43:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by kanga.kvack.org (Postfix) with ESMTP id 612D66B00BE for ; Wed, 25 Mar 2020 13:43:34 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 44ED7180DE7CE for ; Wed, 25 Mar 2020 17:43:34 +0000 (UTC) X-FDA: 76634606748.18.crush41_1f1cdd8be8d34 X-HE-Tag: crush41_1f1cdd8be8d34 X-Filterd-Recvd-Size: 5123 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Mar 2020 17:43:33 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id s1so4286864wrv.5 for ; Wed, 25 Mar 2020 10:43:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=QRRCzuLbEpTHV8fbDDkEetzQ64bmOKTlo6U1gyT4C1o=; b=Nj1Mm4qms/oH0r690O2CXFVnwmrtjfVLYTGDdDY1Iv/7VwEawHoKNfOtmJJx8vW/zh tKY6Zg+xH8UajsCH+rvPzzb05+Eu0Th9TbW2AjSZOosbsgD3ZkLakaieawcOMqDBF3BP gGX8T3e4UYHZ8QrmsDXJqWW/TJMy/UX1jAivYN196hQKP/DxbEyiZRtzXJIf/fWfDHiL 2AvRWsK3jtmX0DQPkSh9/WxhspY7R62/zPgOa+U4aL1YemlngSqfPIzbIpTb9GE/hs7X dgHJe8Gc8lc6FAoT/c+xOEY904QgIqo01V8oijVmYphYQt4h5Y+imqMgrkavOs5+5JNS fnmg== X-Gm-Message-State: ANhLgQ1Os8i87vI5X3hWlSo7hEmniGF7OF4RIzZr/UTNdNmOWQ8HQSJs uoaKpgPjFc+z67VcWcC5Eag= X-Google-Smtp-Source: ADFU+vuaZ8P6htHeU+KdhlHztypmcapfX6ao367TH+m5v8RIkS7GJ7bgLEPK4wYsdS0LkCWGCAh/5g== X-Received: by 2002:adf:a348:: with SMTP id d8mr4609479wrb.83.1585158212475; Wed, 25 Mar 2020 10:43:32 -0700 (PDT) Received: from localhost (ip-37-188-135-150.eurotel.cz. [37.188.135.150]) by smtp.gmail.com with ESMTPSA id s131sm9896340wmf.35.2020.03.25.10.43.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2020 10:43:31 -0700 (PDT) Date: Wed, 25 Mar 2020 18:43:29 +0100 From: Michal Hocko To: Alexander Potapenko Cc: 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 , 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 Subject: Re: [PATCH v5 03/38] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW Message-ID: <20200325174329.GH19542@dhcp22.suse.cz> References: <20200325161249.55095-1-glider@google.com> <20200325161249.55095-4-glider@google.com> <20200325161952.GF19542@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 25-03-20 18:26:34, Alexander Potapenko wrote: > On Wed, Mar 25, 2020 at 5:19 PM Michal Hocko wrote: > > > > On Wed 25-03-20 17:12:14, glider@google.com wrote: > > > This flag is to be used by KMSAN runtime to mark that newly created > > > memory pages don't need KMSAN metadata backing them. > > > > I really dislike an idea of the gfp flag. If you need some form of > > exclusion for kmsan allocations then follow the pattern of memalloc_no{fs,io}_{save,restore} > > History tells us that single usecase gfp flags are too tempting to abuse > > and using incorrectly. > > Great idea, will do! > Guess PF_ flags isn't a scarce resource? task_struct is a monster data structure and there are surely holes you can fit your flag in. All you need is to just store it somewhere and then check for it wherever you hook your infrastructure into the page or slab allocator. The primary thing is to avoid a gfp flag. Thanks! -- Michal Hocko SUSE Labs