From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932308AbbJNOlk (ORCPT ); Wed, 14 Oct 2015 10:41:40 -0400 Received: from mail.skyhub.de ([78.46.96.112]:51291 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752060AbbJNOlj (ORCPT ); Wed, 14 Oct 2015 10:41:39 -0400 Date: Wed, 14 Oct 2015 16:41:34 +0200 From: Borislav Petkov To: Sai Praneeth Prakhya Cc: linux-efi@vger.kernel.org, matt.fleming@intel.com, linux-kernel@vger.kernel.org, Ricardo Neri , Glenn P Williamson , Ravi Shankar Subject: Re: [PATCH] x86/efi: Fix kernel panic when CONFIG_DEBUG_VIRTUAL is enabled Message-ID: <20151014144134.GA8263@pd.tnic> References: <1444765377-29303-1-git-send-email-sai.praneeth.prakhya@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1444765377-29303-1-git-send-email-sai.praneeth.prakhya@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 13, 2015 at 12:42:57PM -0700, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > When CONFIG_DEBUG_VIRTUAL is turned on, all accesses to __pa(address) > are monitored to see whether address falls in direct mapping or kernel > mapping, make that "... or kernel text mapping (see Documentation/x86/x86_64/mm.txt for details)" for more clarity please. It just took mfleming and me a while to figure out what what is. > if it does not kernel panics. During 1:1 mapping of EFI runtime > services we access addresses which are below 4G and hence when passed as not "below 4G" but "we access virtual adresses which are == physical addresses, thus the 1:1 mapping" - on a box with more than 4G, physical addresses can be above 4G too :) > arguments to __pa() kernel panics as reported by Dave Hansen here > https://lkml.org/lkml/2015/1/27/742. Please quote this mail with the k.org redirector: https://lkml.kernel.org/r/5462999A.7090706@intel.com lkml.org is unreliable. > So, before calling __pa() virtual > addresses should be validated which results in skipping call to > split_page_count() and that should be fine because it is used to keep > track of direct kernel mappings and not 1:1 mappings. I think that should say: "to keep track of everything *but* 1:1 mappings." The 1:1 mappings are EFI-specific thing and the physaddr.c checkers aren't aware of them. Again, IMHO. > Signed-off-by: Sai Praneeth Prakhya > Reported-by: Dave Hansen > Cc: Matt Fleming > Cc: Ricardo Neri > Cc: Glenn P Williamson > Cc: Ravi Shankar > --- > arch/x86/mm/pageattr.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c > index 727158cb3b3c..3a603830503a 100644 > --- a/arch/x86/mm/pageattr.c > +++ b/arch/x86/mm/pageattr.c > @@ -648,9 +648,11 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address, > for (i = 0; i < PTRS_PER_PTE; i++, pfn += pfninc) > set_pte(&pbase[i], pfn_pte(pfn, canon_pgprot(ref_prot))); > > - if (pfn_range_is_mapped(PFN_DOWN(__pa(address)), > - PFN_DOWN(__pa(address)) + 1)) > - split_page_count(level); > + if (virt_addr_valid(address)) { > + if (pfn_range_is_mapped(PFN_DOWN(__pa(address)), > + PFN_DOWN(__pa(address)) + 1)) > + split_page_count(level); Maybe make it a bit more readable: if (virt_addr_valid(address)) { unsigned long pfn = PFN_DOWN(__pa(address)); if (pfn_range_is_mapped(pfn, pfn + 1)) split_page_count(level); } But yeah, patch makes sense to me. Thanks for fixing that! -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.