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=-11.4 required=3.0 tests=BAYES_00,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 6017FC4363A for ; Mon, 5 Oct 2020 16:01:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C1A6F2075A for ; Mon, 5 Oct 2020 16:01:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GK57Nxy/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C1A6F2075A 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 1197E6B008A; Mon, 5 Oct 2020 12:01:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CAE76B008C; Mon, 5 Oct 2020 12:01:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAEEB6B0092; Mon, 5 Oct 2020 12:01:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id BDB8E6B008A for ; Mon, 5 Oct 2020 12:01:13 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 59492180AD811 for ; Mon, 5 Oct 2020 16:01:13 +0000 (UTC) X-FDA: 77338336026.27.money12_5e0f409271bf Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id D7EA83D66B for ; Mon, 5 Oct 2020 16:01:11 +0000 (UTC) X-HE-Tag: money12_5e0f409271bf X-Filterd-Recvd-Size: 5653 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 16:01:10 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id n18so2383846wrs.5 for ; Mon, 05 Oct 2020 09:01:10 -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=F38mYIS/X8WyXHWOLkz8wuYqStbWhqnLSCK7WusSBkg=; b=GK57Nxy/OTB2bIJciaPrbDjU2sHiyot+50pQ2m5FW7HuIwHGJhv3j2yy9HQYKMargZ LOSnHsb3W0lqhzu46Zz2ljmS2ivy+eEYiqizC1IVLU4/FEAWpyW6T4O55G+z/pSBwDm/ K49lhz4Cg8Y5R04yvR84W0GYJ45F01wM6S9p/DMEwSOlnb1peLFlwL51ujSgMzOY4/6i Ic4X/u3t9NZkAMMr9AXCDwFy359DRdr8slvGR9AOiQMTsA8TEIzdon5Afqyviv8OL3DI UrID089P1T2Kj6UAZjIWXe5uxnWuq5smjmloM/nDyS+tDmK/T5WavOHy1VUUmpSxuDeN 2TdA== 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=F38mYIS/X8WyXHWOLkz8wuYqStbWhqnLSCK7WusSBkg=; b=TzLb6URa+Wc4AYxN9s3pgAy8lVRxWC3n1si7YCW6yV/0fiDShRX2hqcQtbGun4C/tl CxK2X0zZGpTCd6I3W7t6zXZ06/oEvc/DD82OkNPG5j02GW81HarR04MHYlXnFUlXsU3A KavgO+077DUjqBJOvVS3EzgeWIseMC8BnNIpY/lOwfgoV494CpUJdt3tCLoTCV/T+joy spPYx4FgjYpb+68QNBZHATVFGM3fwcfWZx+X0ndsGVIqLg2Aw9lYjoultdc2l+m4XBYw orjKR3kfT751QgXx1dazzWmRDcLfVXE/dwIC85rSiy+yAgz/YRY4xDR/7PJJOCOHV9/F 2VyA== X-Gm-Message-State: AOAM533peJ3rX3zN+tndtrjMIfX9qGSgtNR+bYsuK3YzX8rq5oXzFOcK CO1I71kAKm5UaXvvDAtzTadunQniF6kjHFYRGjZ+rA== X-Google-Smtp-Source: ABdhPJxqK7BunDKr3q1TD4Lm3VUncdK+5sIvfkPRcNilb6WHgWFEJqYzsuqa09MZ/AYjykQNbq7vnfoSU2sjAJbERC0= X-Received: by 2002:adf:f101:: with SMTP id r1mr66271wro.314.1601913669054; Mon, 05 Oct 2020 09:01:09 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-2-elver@google.com> <20200929142411.GC53442@C02TD0UTHF1T.local> <20200929150549.GE53442@C02TD0UTHF1T.local> In-Reply-To: <20200929150549.GE53442@C02TD0UTHF1T.local> From: Alexander Potapenko Date: Mon, 5 Oct 2020 18:00:57 +0200 Message-ID: Subject: Re: [PATCH v3 01/10] mm: add Kernel Electric-Fence infrastructure To: Mark Rutland Cc: Marco Elver , Andrew Morton , "H. Peter Anvin" , "Paul E. McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jann Horn , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , Kees Cook , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , LKML , kasan-dev , Linux ARM , Linux Memory Management List 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 5:06 PM Mark Rutland wrote: > > On Tue, Sep 29, 2020 at 04:51:29PM +0200, Marco Elver wrote: > > On Tue, 29 Sep 2020 at 16:24, Mark Rutland wrote: > > [...] > > > > > > From other sub-threads it sounds like these addresses are not part of > > > the linear/direct map. Having kmalloc return addresses outside of the > > > linear map is going to break anything that relies on virt<->phys > > > conversions, and is liable to make DMA corrupt memory. There were > > > problems of that sort with VMAP_STACK, and this is why kvmalloc() is > > > separate from kmalloc(). > > > > > > Have you tested with CONFIG_DEBUG_VIRTUAL? I'd expect that to scream. > > > > > > I strongly suspect this isn't going to be safe unless you always use an > > > in-place carevout from the linear map (which could be the linear alias > > > of a static carevout). > > > > That's an excellent point, thank you! Indeed, on arm64, a version with > > naive static-pool screams with CONFIG_DEBUG_VIRTUAL. > > > > We'll try to put together an arm64 version using a carveout as you suggest. > > Great, thanks! > > Just to be clear, the concerns for DMA and virt<->phys conversions also > apply to x86 (the x86 virt<->phys conversion behaviour is more forgiving > in the common case, but still has cases that can go wrong). To clarify, shouldn't kmalloc/kmem_cache allocations used with DMA be allocated with explicit GFP_DMA? If so, how practical would it be to just skip such allocations in KFENCE allocator?