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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 579DFC433DF for ; Tue, 30 Jun 2020 09:40:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 21EEF206A1 for ; Tue, 30 Jun 2020 09:40:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JLlGmGr7"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="fqd4DR/Z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 21EEF206A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ivXMm5fuGfSBsqixbFEhD3GooXsBtcP3mAAhx1pjr7g=; b=JLlGmGr7X05AiIVROFFLa5XgO 5VnebHncYuf44ZQ6gD5KptNSSm5BgfXS/1JeWnqUV2wKm6g8Zcu6ZOzgqtUCTh0r8Wz4U3EWnMV02 /kuZ1fwHisY5vr0IuBEZ1TQApBTr6eznvEodO2ItPb0MEIb4gXTh+Gj00dMtiH1L06CW9ksMzgTu4 8a0yax01w+pEedLrje5gDvOk4ZchHobdLC+i3ZnXjyG6PHqzY0qiaxH4apsLDj7nGH9D3tjNBbdE9 I/XFfwaK70dPKDr5gwSrK2RvbyRa6y+Ipncdjwqh8SErE+0iu3lxMDYij88YmLRoXAJbQrvAGw8sB eCcoG19tA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqCjB-0007Ml-4C; Tue, 30 Jun 2020 09:38:57 +0000 Received: from mail-ej1-x641.google.com ([2a00:1450:4864:20::641]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqCj8-0007Le-91 for linux-arm-kernel@lists.infradead.org; Tue, 30 Jun 2020 09:38:56 +0000 Received: by mail-ej1-x641.google.com with SMTP id p20so19788322ejd.13 for ; Tue, 30 Jun 2020 02:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fmaWewzOpMepreT+cZhaZQ/NoiEUDZB/QrMGwxTrguE=; b=fqd4DR/ZXKjVFJqlqkxgGkeKozrhDtfqip/UH630ap0643vddNW98/9BTK5+rb4hIi 2Dd7pj1+AFK7C/qB76S2gNPGV62niUOGJmjFIIj1whWZmy0Cs+vrHMBzhJq04uQzVw8N suMGFZ/NJmFnrAisY0HMq7kKPQMQlNPZ1vnDyNvBwpK7Cq8MMZb9qmy0TEt8N/yFZ6qx eOBA5jbM1jLRf4i/X3LRNFz8LtuP3x+G2o7YrFnq9KzBrM6s5SDz00TJlHStoo3zm4D3 rPkrDzi0o8MU0Rk9YlJ29NRBJX6fnKPvKEwkwnsPKsU53j90/dgtPjjhX0Dx1tyzNxdt ER4g== 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=fmaWewzOpMepreT+cZhaZQ/NoiEUDZB/QrMGwxTrguE=; b=gmZVz736lgkAdpwz497+ZgRv9VAakCipByv5zPxQSHn556Ee7fbGBULI8RWEi9P6u6 1YT70nw4HDymv6xQ1H8h7kpL9O8qhEngbVzKWEQ/rcMvOG4uW41mQ1qFdXwHWBJ3iKbw Mdtdhv32VvDSO0ADJX2Tag/LJWxHrvGUvOm2CMtw1O3ce4uD/TpkTGMQzeflkKI0zJEb 9Ng6OdikX+/GSbBfmipLZqQZjly6RcPuI+dkNge5KgDdJvrK4XbZjZDtkiSWT0XmIBuc PXuxYJSO2SqqbnF1tY0YPJX5+U05EL+rUYwL60qIXoKv2k6gvmQanj+AdDXl1HuSRv8w H6XA== X-Gm-Message-State: AOAM5339H6Wq7WleI1/bKUik5wbj8ctI0ghpzP+5LQiwUVMFNng8JDT5 0IJ2e9p20Dzq6PJ4qJV+emGLe6o6+e+HxjpyfueCVA== X-Google-Smtp-Source: ABdhPJw7mdlhyB247Pba2ps9INXxwUS5jpSXDEdV4O+v/3kR+gyuyICeQcXQzPb1CbL2rYGpgSJaZ0cdcDRO8coir/o= X-Received: by 2002:a17:906:c943:: with SMTP id fw3mr17214298ejb.55.1593509932782; Tue, 30 Jun 2020 02:38:52 -0700 (PDT) MIME-Version: 1.0 References: <20200615090247.5218-1-linus.walleij@linaro.org> <20200615090247.5218-5-linus.walleij@linaro.org> <20200629143751.GV1551@shell.armlinux.org.uk> In-Reply-To: <20200629143751.GV1551@shell.armlinux.org.uk> From: Linus Walleij Date: Tue, 30 Jun 2020 11:38:41 +0200 Message-ID: Subject: Re: [PATCH 4/5 v10] ARM: Initialize the mapping of KASan shadow memory To: Russell King - ARM Linux admin X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Fainelli , Arnd Bergmann , Abbott Liu , kasan-dev , Mike Rapoport , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , Will Deacon , Ard Biesheuvel , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 29, 2020 at 4:37 PM Russell King - ARM Linux admin wrote: > On Mon, Jun 29, 2020 at 04:07:06PM +0200, Linus Walleij wrote: > > Asking for help here! > > > > I have a problem with populating PTEs for the LPAE usecase using > > Versatile Express Cortex A15 (TC1) in QEMU. > > > > In this loop of the patch: > > > > On Mon, Jun 15, 2020 at 11:05 AM Linus Walleij wrote: > > > > > +static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr, > > > + unsigned long end, int node, bool early) > > > +{ > > > + unsigned long next; > > > + pte_t *ptep = pte_offset_kernel(pmdp, addr); > > > > (...) > > > > > + do { > > > + next = pmd_addr_end(addr, end); > > > + kasan_pte_populate(pmdp, addr, next, node, early); > > > + } while (pmdp++, addr = next, addr != end && pmd_none(READ_ONCE(*pmdp))); > > > > I first populate the PMD for 0x6ee00000 .. 0x6f000000 > > and this works fine, and the PTEs are all initialized. > > pte_offset_kernel() returns something reasonable. > > (0x815F5000). > > > > Next the kernel processes the PMD for > > 0x6f000000 .. 0x6f200000 and now I run into trouble, > > because pte_offset_kernel() suddenly returns a NULL > > pointer 0x00000000. > > That means there is no PTE table allocated which covers 0x6f000000. > > "pmdp" points at the previous level's table entry that points at the > pte, and all pte_offset*() does is load that entry, convert it to a > pte_t pointer type, and point it to the appropriate entry for the > address. So, pte_offset*() is an accessor that takes a pointer to > the preceding level's entry for "addr", and returns a pointer to > the pte_t entry in the last level of page table for "addr". > > It is the responsibility of the caller to pte_offset*() to ensure > either by explicit tests, or prior knowledge, that pmd_val(*pmdp) > is a valid PTE table entry. > > Since generic kernel code can't use "prior knowledge", it has to do > the full checks (see, mm/vmalloc.c vunmap_pte_range() and higher > levels etc using pmd_none_or_clear_bad() for example - whether you > can use _clear_bad() depends whether you intend to clear "bad" entries. > Beware that the 1MB sections on non-LPAE will appear as "bad" entries > since we can't "walk" them to PTE level, and they're certainly not > "none" entries.) Spot on! I figured it out quickly with this hint. Essentially I have some loops like this: pmd_t *pmdp = pmd_offset(pudp, addr); if (pmd_none(*pmdp)) { void *p = early ? kasan_early_shadow_pte : kasan_alloc_block(PAGE_SIZE, node); .... } do { pmd_populate_kernel(&init_mm, pmdp, p); flush_pmd_entry(pmdp); next = pmd_addr_end(addr, end); kasan_pte_populate(pmdp, addr, next, node, early); } while (pmdp++, addr = next, addr != end && pmd_none(READ_ONCE(*pmdp))); I just had to move the i (pmd_node(*pmdp)) inside the loop and it all starts working fine. What confuses me is that arm64 does it this way (checking pmdp outside the loop) for all levels of the cache and it works (I suppose?) for them, but I suspect it is formally wrong. I'll rewrite with the check inside the loop at all levels and retest and resend, then I hope this starts to work and look reasonable, finally. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel