public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: 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 16:18:49 +0200	[thread overview]
Message-ID: <87le17yu5y.ffs@tglx> (raw)
In-Reply-To: <20230810100011.14552-1-max8rr8@gmail.com>

On Thu, Aug 10 2023 at 13:00, Max Ramanouski wrote:

> On systems that use HMM (most notably amdgpu driver)
> high_memory can jump over VMALLOC_START. That causes
> some iounmap to exit early. This in addition to leaking,
> causes problems with rebinding devices to vfio_pci from
> other drivers with error of conflicting memtypes,
> as they aren't freed in iounmap.
>
> Replace comparison against high_memory with is_vmalloc_addr to
> fix the issue and make x86 iounmap implementation more similar
> to generic one, it also uses is_vmalloc_addr to validate pointer.

So this lacks a Fixes tag and some deep analysis of similar potential
problems. While at it please use func() notation for functions. In the
middle of a sentence iounmap does not immediately stand out, but
iounmap() does. It's documented ...

This add_pages() hackery in pagemap_range() is really nasty as it ends
up violating historical assumptions about max_pfn and high_memory.

Dan, who did the analysis of this when the device private memory muck
was added?

Clearly floppy.h has the same issue. It probably does not matter much,
but it's far from correct. memtype_kernel_map_sync() looks fishy too.

Thanks,

        tglx

  parent reply	other threads:[~2024-08-08 14:18 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 [this message]
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
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=87le17yu5y.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox