linux-kernel - Re: [GIT PULL] MM updates for 6.19-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wj1aw7p-JkWdcJOkQQ279qgppG7_1kxFQAqaak7fEQAjw@mail.gmail.com>
Date: Fri, 5 Dec 2025 13:56:17 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andrew Morton <akpm@...ux-foundation.org>, Ankit Agrawal <ankita@...dia.com>, 
	Alex Williamson <alex@...zbot.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	mm-commits@...r.kernel.org
Subject: Re: [GIT PULL] MM updates for 6.19-rc1

On Wed, 3 Dec 2025 at 21:29, Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> Ankit Agrawal:
>       vfio/nvgrace-gpu: register device memory for poison handling

So I had to look at this one because there was a conflict ("int ret"
had been removed by another commit), and after looking at it I ended
up deciding to revert this patch entirely.

I may be wrong, but that patch looks *COMPETELY* broken.

It did

  nvgrace_gpu_mmap() ->
    nvgrace_gpu_vfio_pci_register_pfn_range() ->
      register_pfn_address_space()

using &nvdev->resmem/usemem, and honestly, that looks mis-designed
from beginning to end.

If somebody maps the same BAR of that device twice, the second call to
nvgrace_gpu_vfio_pci_register_pfn_range() will randomly overwrite a
node (that "region->pfn_address_space.node") that has already been
registered and inserted into the pfn_space_itree interval tree.

You can't *do* things like this!

Maybe I'm  misreading this, and somebody should correct me, but it
really looks like completely broken code to me. It basically seems to
assume that those two bar regions are mapped exactly once, and I don't
see why that would ever be true except by pure accident because you
only have one user.

That may be a common case, but that doesn't make any of this correct.

Again - maybe I'm missing something. If so, that commit can be re-done
with explanations of why it's all correct.

           Linus