LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Will Deacon <will@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [GIT PULL] arm64 fix for 5.14
Date: Tue, 31 Aug 2021 21:16:28 +0200	[thread overview]
Message-ID: <0a41af61-783c-e31d-abc1-73169dad9ff4@redhat.com> (raw)
In-Reply-To: <20210831133117.GD31712@willie-the-truck>

On 31.08.21 15:31, Will Deacon wrote:
> [+David]
> 
> On Fri, Aug 27, 2021 at 10:16:27AM -0700, Linus Torvalds wrote:
>> On Fri, Aug 27, 2021 at 10:10 AM Christoph Hellwig <hch@lst.de> wrote:
>>>
>>> They CCed me on their earlier discussion, but I did not catch up on it
>>> until you responded to the pull request  If I understood it correct it
>>> was about a platform device mapping a MMIO region (like a PCI bar),
>>> but something about section alignment cause pfn_valid to mistrigger.
>>
>> Yeah, so I can easily see the maxpfn numbers can easily end up being
>> rounded up to a whole memory section etc.
>>
>> I think my suggested solution should JustWork(tm) - exactly because if
>> the area is then in that "this pfn is valid" area, it will
>> double-check the actual underlying page.
> 
> I think the pitfall there is that the 'struct page' might well exist,
> but isn't necessarily initialised with anything meaningful. I remember
> seeing something like that in the past (I think for "no-map" memory) and
> David's reply here:
> 
> https://lore.kernel.org/r/aff3942e-b9ce-5bae-8214-0e5d89cd071c@redhat.com
> 
> hints that there are still gotchas with looking at the page flags for
> pages if the memory is offline or ZONE_DEVICE.
> 
> Don't get me wrong, I'd really like to use the generic code here as I
> think it would help to set expectations around what pfn_valid() actually
> means, I'm just less keen on the try-it-and-see-what-breaks approach
> given how sensitive it is to the layout of the physical memory map.
> 
>> That said, I think x86 avoids the problem another way - by just making
>> sure max_pfn is exact. That works too, as long as there are no holes
>> in the RAM map that might be used for PCI BAR's.
>>
>> So I think arm could fix it that way too, depending on their memory layout.
> 
> The physical memory map is the wild west, unfortunately. It's one of the
> things where everybody does something different and it's very common to see
> disjoint banks of memory placed seemingly randomly around.

The resource tree is usually the best place to really identify what's 
system RAM and what's not IIRC. memblock should work on applicable archs 
as well. Identifying ZONE_DEVICE ranges reliably is a different story ...

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2021-08-31 19:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26 13:17 Will Deacon
2021-08-26 18:41 ` Linus Torvalds
2021-08-27  7:40   ` Christoph Hellwig
2021-08-27 17:03     ` Linus Torvalds
2021-08-27 17:10       ` Christoph Hellwig
2021-08-27 17:16         ` Linus Torvalds
2021-08-31 13:31           ` Will Deacon
2021-08-31 19:16             ` David Hildenbrand [this message]
2021-08-31 16:56           ` Catalin Marinas
2021-08-26 18:52 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a41af61-783c-e31d-abc1-73169dad9ff4@redhat.com \
    --to=david@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=hch@lst.de \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    --subject='Re: [GIT PULL] arm64 fix for 5.14' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).