All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Dan Williams <dan.j.williams@intel.com>,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, max8rr8@gmail.com,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	jhubbard@nvidia.com, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 1/1] x86/ioremap: Use is_vmalloc_addr in iounmap
Date: Tue, 13 Aug 2024 11:33:24 +1000	[thread overview]
Message-ID: <87bk1x42vk.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <87frr9swmw.ffs@tglx>


Thomas Gleixner <tglx@linutronix.de> writes:

> On Mon, Aug 12 2024 at 12:03, Thomas Gleixner wrote:
>> On Mon, Aug 12 2024 at 17:41, Alistair Popple wrote:
>>> The same applies to the rest of the DIRECT_MAP_END users here. Perhaps
>>> it would be better to define this as DIRECT_MAP_SIZE and calculate this
>>> based off PAGE_OFFSET instead?
>>
>> Duh, yes. I shouldn't try to write patches at 30C :)
>
> We can avoid the calculation and expose the end of the physical address
> space for memory. This time I actually built and ran it :)

To be fair the previous version did actually build and run fine, it just
didn't fix the issue. However this version does so feel free to add:

Tested-by: Alistair Popple <apopple@nvidia.com>

[...]

> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -97,6 +97,10 @@ extern const int mmap_rnd_compat_bits_ma
>  extern int mmap_rnd_compat_bits __read_mostly;
>  #endif
>  
> +#ifndef PHYSMEM_END
> +# define PHYSMEM_END	(1UL << (MAX_PHYSMEM_BITS-PAGE_SHIFT))

However I think this should be:

# define PHYSMEM_END	((1UL << MAX_PHYSMEM_BITS) - 1)

 - Alistair

> +#endif
> +
>  #include <asm/page.h>
>  #include <asm/processor.h>
>  
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -1826,8 +1826,7 @@ static resource_size_t gfr_start(struct
>  	if (flags & GFR_DESCENDING) {
>  		resource_size_t end;
>  
> -		end = min_t(resource_size_t, base->end,
> -			    (1ULL << MAX_PHYSMEM_BITS) - 1);
> +		end = min_t(resource_size_t, base->end, PHYSMEM_END);
>  		return end - size + 1;
>  	}
>  
> @@ -1844,8 +1843,7 @@ static bool gfr_continue(struct resource
>  	 * @size did not wrap 0.
>  	 */
>  	return addr > addr - size &&
> -	       addr <= min_t(resource_size_t, base->end,
> -			     (1ULL << MAX_PHYSMEM_BITS) - 1);
> +	       addr <= min_t(resource_size_t, base->end, PHYSMEM_END);
>  }
>  
>  static resource_size_t gfr_next(resource_size_t addr, resource_size_t size,
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1681,7 +1681,7 @@ struct range __weak arch_get_mappable_ra
>  
>  struct range mhp_get_pluggable_range(bool need_mapping)
>  {
> -	const u64 max_phys = (1ULL << MAX_PHYSMEM_BITS) - 1;
> +	const u64 max_phys = PHYSMEM_END;
>  	struct range mhp_range;
>  
>  	if (need_mapping) {
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -129,7 +129,7 @@ static inline int sparse_early_nid(struc
>  static void __meminit mminit_validate_memmodel_limits(unsigned long *start_pfn,
>  						unsigned long *end_pfn)
>  {
> -	unsigned long max_sparsemem_pfn = 1UL << (MAX_PHYSMEM_BITS-PAGE_SHIFT);
> +	unsigned long max_sparsemem_pfn = (PHYSMEM_END + 1) >> PAGE_SHIFT;
>  
>  	/*
>  	 * Sanity checks - do not allow an architecture to pass


  reply	other threads:[~2024-08-13  1:40 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
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 [this message]
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=87bk1x42vk.fsf@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jhubbard@nvidia.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=max8rr8@gmail.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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.