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=-2.5 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,USER_AGENT_SANE_1 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 25D6CC433E0 for ; Mon, 29 Jun 2020 14:42:43 +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 E4AD523E1F for ; Mon, 29 Jun 2020 14:42:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1KgJeQjA"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="n8pI6Aqb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4AD523E1F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0MF4kkyfrTUJ+yOZpSUlU6/gN5i47HpytoSFHmauJxE=; b=1KgJeQjAwXCCFdBA5Z6/WKtqJ z85VCbbMI8eFWHuzSc5FZDdDysMyM7i5oCa13yqFvI5ou2oiKogInu9KSJddNIfaZAkCDwdg8M7dL 2aJNfF+DVYIcIVN1LhVsTsdlGdT7QInS815cvNqOX17w/La0+9YpAyNzIGPuYPetUS8N1Jtq6Y7Xv g1RtMQHvp3Z6Z9KNHvBPWg5ZZ0QIpWX2HIIUxwPWYGSyQ3H9NUCjgIWAwprjMpdQPllYDLBkMzHj3 PDAnyHm43zXk4FWvBFcoIu3iU+AYbqKOr0yeFpSsoNADqYJFjtqTvTpuKlf8Gm8SEa99M3BD7ao5T jyKnfT8eQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jpuy3-0005lP-B4; Mon, 29 Jun 2020 14:41:07 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jpuy0-0005LW-DV for linux-arm-kernel@lists.infradead.org; Mon, 29 Jun 2020 14:41:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ImkFE8JbJAI6KDvvRlrXlVaOSFSsL9bPvC0VRq8yxjs=; b=n8pI6AqbpieQqmdTXPZ1LbZ2S QeXU8rAtDmichiTyzUHgVhnt2R8Gt4gIWbDUqQLzzJoV3NJ8ON5r/ub7oKcZIHFyYSRhzhofvgz6T TDUuuzWVM1ZwM/GgaDBzrDIQA7Xzr8r2/yECFXK53lURdu8RNg8VW7lRwS8f50gIluJRE/BBJJGSt RQxTWjA1/UpjXEhMBwzWu4gX+YHqx4rFe7ABCJrt2ZTatME45cMsatmSo8dy9VOzXD9PHr+NLMLWk U+XSwuJUXFcJakPQOpYOjUXKrasKMppbH9l4pZuHw2vvXfCFCSm4VJBQdbsTdPhS5tgb3IyNWPaIf Hnyk5LivQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:33122) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jpuuw-0007kd-Iz; Mon, 29 Jun 2020 15:37:54 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jpuut-0007Br-Q1; Mon, 29 Jun 2020 15:37:51 +0100 Date: Mon, 29 Jun 2020 15:37:51 +0100 From: Russell King - ARM Linux admin To: Linus Walleij Subject: Re: [PATCH 4/5 v10] ARM: Initialize the mapping of KASan shadow memory Message-ID: <20200629143751.GV1551@shell.armlinux.org.uk> References: <20200615090247.5218-1-linus.walleij@linaro.org> <20200615090247.5218-5-linus.walleij@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 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.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel