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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <030a4195-ed20-4f5f-8841-ea5385bb4a8c@deltatee.com>
Date: Mon, 27 Oct 2025 10:30:52 -0600
From: Logan Gunthorpe <logang@...tatee.com>
To: Koichiro Den <den@...inux.co.jp>, ntb@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Cc: jdmason@...zu.us, dave.jiang@...el.com, allenbh@...il.com
Subject: Re: [PATCH 1/4] NTB: ntb_transport: Handle remapped contiguous region
 in vmalloc space



On 2025-10-26 18:43, Koichiro Den wrote:
> The RX buffer virtual address may reside in vmalloc space depending on
> the allocation path, where virt_to_page() is invalid.
> 
> Use a helper that chooses vmalloc_to_page() or virt_to_page() as
> appropriate. This is safe since the buffer is guaranteed to be
> physically contiguous.

I think this statement needs some explanation.

vmalloc memory is generally not contiguous and using vmalloc_to_page()
like this seems very questionable.

I did a very quick look and found that "offset" may come from
dma_alloc_attrs() which can also return coherent memory that would be in
vmalloc space and would be contiguous.

However, in my cursory look, it appears that the kernel address returned
by dma_alloc_attrs() is eventually passed to dma_map_page() in order to
obtain the dma address a second time. This is really ugly, and almost
certainly not expected by the dma layer.

This requires a bit of a change, but it seems to me that if
dma_alloc_attrs() is used, the dma address it returns should be used
directly and a second map should be avoided completely. Then we wouldn't
need the unusual use of vmalloc_to_page().

At the very least, I think these issues need to be mentioned in the
commit message.

Logan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ