Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp10762803rwb; Fri, 25 Nov 2022 07:33:35 -0800 (PST) X-Google-Smtp-Source: AA0mqf7lTT8iOMbSrJ4coC7Q46Im+xSm0TQYqOUdboQUtsJOPjQXpHxtblagQzX0lXE8tcU/oQ8N X-Received: by 2002:a05:6a00:1c8c:b0:574:89a7:9450 with SMTP id y12-20020a056a001c8c00b0057489a79450mr8504117pfw.85.1669390415693; Fri, 25 Nov 2022 07:33:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669390415; cv=none; d=google.com; s=arc-20160816; b=Zmq5zl9xdd/5w0fTbIgkXzP/bxidfbyeOyJh/iKqnqoHOb3YWWl6suSC4+Lkv9lCWZ kBif5XzvktW5eaqtSK74+ua0aocpVnlllUfjXuBx07wTsRFCznF+BLzodvLypjNnFJDH +B44dcNNcZGmZkUw1vSX8G6hrc66E+E0P2dJW41SwqOGMvdeVqVNT+mzvhc5GyWMlXH8 pqLWRWFEisA7iBfoWrFzW6PFWMH3uqU43MRlGfCFYe3QagmxwATQHnB28b6xDaxrKYaO aAcZnZKARjk0jjenwqXpRTYWgIvfwQzzibbxAY8czUq1PfcoFoaqRDq95mUtjLBZkVeM iSQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=hZxVZyzuCq/7TKW0PGUA94kRptUFc8WRLxofFIt0CnI=; b=Fw0YAHYnj2PvWDXIMURGBeMZuuO7SQDaGLdFpG2crhDGK9/+8jGFlP1ibsqBsHcJA+ 9MVWANT7Q9AD9uwfaHvoEze1mVX3AeLEujA56aDjFkWudwhUuk0PI4wdnLD7MUjLPwMA KspO31FFnQHimrNILM0LMSLuaYg3K2L8ninX5op00iKhxUqHmimkp/9NF/QVqW6Q0YbT eWbMO9Vnw5gHV3mEEg4mw8jXrPoCxk7BIbA8jcqoKqWUrx2UiuB9l9vVadbowtHO43I0 /4sxN3CdRy2FSsoehxIraMWWAkahyxsYSM+r8A99ZzqqWGDFAyEyKhud9YsyVC50wYEz bpGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n16-20020a170902e55000b0018907d64909si4455642plf.325.2022.11.25.07.33.24; Fri, 25 Nov 2022 07:33:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229766AbiKYPTn (ORCPT + 85 others); Fri, 25 Nov 2022 10:19:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbiKYPTl (ORCPT ); Fri, 25 Nov 2022 10:19:41 -0500 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B0C6205C6; Fri, 25 Nov 2022 07:19:40 -0800 (PST) Received: by mail-wm1-f52.google.com with SMTP id m7-20020a05600c090700b003cf8a105d9eso3621761wmp.5; Fri, 25 Nov 2022 07:19:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hZxVZyzuCq/7TKW0PGUA94kRptUFc8WRLxofFIt0CnI=; b=Zf6ZF0JD8DwFBVe+6XbLpu/G4brufEOWj+Hp3UPXl5LlZjO1UBhWRFykiw1/WA1xZn AjzoCzEPfmvdXJ3295yivvFhOx2I+RdU1Pa4PEORbnshwtTIRNsCiF9nkV/wAEkVRbsW ybpjegAuJLJNzUouHqmSG0WZYcq6u+MVBbxk/w0LWLPQxlqyInJb2vlLICsPMhSF0rJv HR+ZnT0aBOkge3s/uwXhtLvUATzKRBiNhgA/8U59GSEe2l7OZugVFRMLab2dcecFm0re tf7wOImzxQfY/kfQ8s6eQHl0Py8upE0hL/s9ywEZ3Vqx8CxfHPEcnbCQsO7v+96hm8g6 9uhQ== X-Gm-Message-State: ANoB5pmdJaFHTOOO4uiKJos//ib5PfwCdkAzrWYgYptNN1EeJBWUHvNV NwPvFf3ufBMFBda44K5Jnps= X-Received: by 2002:a05:600c:4b10:b0:3cf:eaf5:77c6 with SMTP id i16-20020a05600c4b1000b003cfeaf577c6mr27241123wmp.56.1669389578960; Fri, 25 Nov 2022 07:19:38 -0800 (PST) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id v17-20020a05600c445100b003c64c186206sm6133436wmn.16.2022.11.25.07.19.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Nov 2022 07:19:38 -0800 (PST) Date: Fri, 25 Nov 2022 15:19:36 +0000 From: Wei Liu To: Michael Kelley Cc: hpa@zytor.com, kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, luto@kernel.org, peterz@infradead.org, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, lpieralisi@kernel.org, robh@kernel.org, kw@linux.com, bhelgaas@google.com, arnd@arndb.de, hch@infradead.org, m.szyprowski@samsung.com, robin.murphy@arm.com, thomas.lendacky@amd.com, brijesh.singh@amd.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, Tianyu.Lan@microsoft.com, kirill.shutemov@linux.intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, dan.j.williams@intel.com, jane.chu@oracle.com, seanjc@google.com, tony.luck@intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, netdev@vger.kernel.org, linux-pci@vger.kernel.org, linux-arch@vger.kernel.org, iommu@lists.linux.dev Subject: Re: [PATCH v4 1/1] x86/ioremap: Fix page aligned size calculation in __ioremap_caller() Message-ID: References: <1669138842-30100-1-git-send-email-mikelley@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1669138842-30100-1-git-send-email-mikelley@microsoft.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 22, 2022 at 09:40:42AM -0800, Michael Kelley wrote: > Current code re-calculates the size after aligning the starting and > ending physical addresses on a page boundary. But the re-calculation > also embeds the masking of high order bits that exceed the size of > the physical address space (via PHYSICAL_PAGE_MASK). If the masking > removes any high order bits, the size calculation results in a huge > value that is likely to immediately fail. > > Fix this by re-calculating the page-aligned size first. Then mask any > high order bits using PHYSICAL_PAGE_MASK. > > Fixes: ffa71f33a820 ("x86, ioremap: Fix incorrect physical address handling in PAE mode") > Acked-by: Dave Hansen > Signed-off-by: Michael Kelley Reviewed-by: Wei Liu > --- > > This patch was previously Patch 1 of a larger series[1]. Breaking > it out separately per discussion with Dave Hansen and Boris Petkov. > > [1] https://lore.kernel.org/linux-hyperv/1668624097-14884-1-git-send-email-mikelley@microsoft.com/ > > arch/x86/mm/ioremap.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c > index 78c5bc6..6453fba 100644 > --- a/arch/x86/mm/ioremap.c > +++ b/arch/x86/mm/ioremap.c > @@ -217,9 +217,15 @@ static void __ioremap_check_mem(resource_size_t addr, unsigned long size, > * Mappings have to be page-aligned > */ > offset = phys_addr & ~PAGE_MASK; > - phys_addr &= PHYSICAL_PAGE_MASK; > + phys_addr &= PAGE_MASK; > size = PAGE_ALIGN(last_addr+1) - phys_addr; > > + /* > + * Mask out any bits not part of the actual physical > + * address, like memory encryption bits. > + */ > + phys_addr &= PHYSICAL_PAGE_MASK; > + > retval = memtype_reserve(phys_addr, (u64)phys_addr + size, > pcm, &new_pcm); > if (retval) { > -- > 1.8.3.1 >