All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dan Williams <dan.j.williams@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Max Ramanouski <max8rr8@gmail.com>,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org
Cc: max8rr8@gmail.com, linux-kernel@vger.kernel.org, x86@kernel.org,
	Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH 1/1] x86/ioremap: Use is_vmalloc_addr in iounmap
Date: Thu, 08 Aug 2024 20:44:08 +0200	[thread overview]
Message-ID: <87zfpmyhvr.ffs@tglx> (raw)
In-Reply-To: <66b4f4a522508_c1448294f2@dwillia2-xfh.jf.intel.com.notmuch>

On Thu, Aug 08 2024 at 09:39, Dan Williams wrote:
> Dan Williams wrote:
>> Apologies was trying to quickly reverse engineer how private memory
>> might be different than typical memremap_pages(), but it is indeed the
>> same in this aspect.
>> 
>> So the real difference is that the private memory case tries to
>> allocate physical memory by searching for holes in the iomem_resource
>> starting from U64_MAX. That might explain why only the private memory
>> case is violating assumptions with respect to high_memory spilling into
>> vmalloc space.
>
> Not U64_MAX, but it starts searching for free physical address space
> starting at MAX_PHYSMEM_BITS, see gfr_start().

Wait. MAX_PHYSMEM_BITS is either 46 (4-level) or 52 (5-level), which is
fully covered by the identity map space.

So even if the search starts from top of that space, how do we end up
with high_memory > VMALLOC_START?

That does not make any sense at all.

> That aspect of private memory has always bothered me, but I am not
> sure that is the historical assumption violation you are referring to
> above.

The historical assumption about max_pfn and high_memory is that this is
the end of the actual memory space.

Thanks,

        tglx

  reply	other threads:[~2024-08-08 18:44 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 10:00 [PATCH 1/1] x86/ioremap: Use is_vmalloc_addr in iounmap Max Ramanouski
2024-08-08  6:12 ` Alistair Popple
2024-08-08  6:44   ` John Hubbard
2024-08-12  6:15   ` Christoph Hellwig
2024-08-08 14:18 ` Thomas Gleixner
2024-08-08 15:58   ` Dan Williams
2024-08-08 16:15     ` Thomas Gleixner
2024-08-08 16:32       ` Dan Williams
2024-08-08 16:39         ` Dan Williams
2024-08-08 18:44           ` Thomas Gleixner [this message]
2024-08-08 19:59             ` Dan Williams
2024-08-09  2:28               ` Alistair Popple
2024-08-09  3:55                 ` Dan Williams
2024-08-10 17:45                   ` Thomas Gleixner
2024-08-12  7:41                     ` Alistair Popple
2024-08-12 10:03                       ` Thomas Gleixner
2024-08-12 11:46                         ` Alistair Popple
2024-08-12 12:10                         ` Max R
2024-08-12 13:23                         ` Thomas Gleixner
2024-08-13  1:33                           ` Alistair Popple
2024-08-13  8:20                             ` Thomas Gleixner
2024-08-13 20:37                               ` Thomas Gleixner
2024-08-13 22:29                                 ` x86/kaslr: Expose and use the end of the physical memory address space Thomas Gleixner
2024-08-14  0:26                                   ` Alistair Popple
2024-08-14 14:33                                   ` Dan Williams
2024-08-15 16:11                                   ` Kees Cook
2024-08-15 22:48                                   ` Max R
2024-08-16  9:42                                   ` David Hildenbrand
2024-08-16  9:43                                   ` [tip: x86/urgent] " tip-bot2 for Thomas Gleixner
2024-08-20 20:38                                   ` tip-bot2 for Thomas Gleixner
2024-09-22 22:31                                   ` Guenter Roeck

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=87zfpmyhvr.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=max8rr8@gmail.com \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.