linux-kernel - Re: [PATCH 1/3] mm: Export vmf_insert_mixed

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: <20250410074228.GA680@lst.de>
Date: Thu, 10 Apr 2025 09:42:28 +0200
From: Christoph Hellwig <hch@....de>
To: Michael Kelley <mhklinux@...look.com>
Cc: Christoph Hellwig <hch@....de>,
	"jayalk@...works.biz" <jayalk@...works.biz>,
	"simona@...ll.ch" <simona@...ll.ch>,
	"deller@....de" <deller@....de>,
	"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
	"kys@...rosoft.com" <kys@...rosoft.com>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>,
	"decui@...rosoft.com" <decui@...rosoft.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"weh@...rosoft.com" <weh@...rosoft.com>,
	"tzimmermann@...e.de" <tzimmermann@...e.de>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite()

On Wed, Apr 09, 2025 at 02:10:26PM +0000, Michael Kelley wrote:
> Hmmm. What's the reference to "as told last time"? I don't think I've had
> this conversation before.

Hmm, there was a conversation about deferred I/O, and I remember the
drm folks even defending their abuse of vmalloc_to_page on dma coherent
memory against the documentation in the most silly way.  Maybe that was
a different discussion of the same thing.

> 
> For the hyperv_fb driver, the memory in question is allocated with a direct call
> to alloc_pages(), not via dma_alloc_coherent(). There's no DMA in this scenario.
> The memory is shared with the Hyper-V host and designated as the memory
> for the virtual framebuffer device. It is then mapped into user space using the
> mmap() system call against /dev/fb0. User space writes to the memory are
> eventually (and I omit the details) picked up by the Hyper-V host and displayed.

Oh, great.

> Is your point that memory dma_alloc_coherent() memory must be treated as
> a black box, and can't be deconstructed into individual pages? If so, that makes
> sense to me.

Yes.

> But must the same treatment be applied to memory from
> alloc_pages()? This is where I need some education.

No, that's just fine.