linux-kernel - Re: [PATCH v4 2/5] drm/nouveau/uvmm: Allow larger pages

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] [day] [month] [year] [list]

Message-ID: <4d07932e-8b53-4ee3-8d08-6f49d433f005@kernel.org>
Date: Wed, 5 Nov 2025 23:50:17 +0100
From: Danilo Krummrich <dakr@...nel.org>
To: Mohamed Ahmed <mohamedahmedegypt2001@...il.com>
Cc: James Jones <jajones@...dia.com>, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, Mary Guillemard <mary@...y.zone>,
 Faith Ekstrand <faith.ekstrand@...labora.com>, Lyude Paul
 <lyude@...hat.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 nouveau@...ts.freedesktop.org
Subject: Re: [PATCH v4 2/5] drm/nouveau/uvmm: Allow larger pages

On 11/4/25 12:53 AM, Mohamed Ahmed wrote:
> Thanks a lot for the shout out! Looking more at things, the logic here
> is actually redundant. It was originally copied over directly from the
> bo allocation code to stay on the safer side (basically the idea back
> then was to make both the bo and vmm sides match exactly). We aren't
> at risk of having an aligned address that is in the wrong memory type
> because the bo allocation code (nouveau_bo.c:321) forces anything that
> has the GART flag to have a page size of 4K. Anything getting a page
> size higher than that is exclusively VRAM only. Additionally,
> currently things marked VRAM only don't get evicted to host memory
> except under high memory pressure and in that case, the context is
> paused until the objects in question are paged back in, so we also
> don't have to worry about memory placement there.
> 
> The memory placement check in the vmm code could be removed but I am
> leaning more towards leaving it as is just to stay on the safer side.

If it is not necessary, please remove it. We should not carry dead code.

> At the same time, it would be more useful to keep it for the future as
> one of the future investigation targets that we want to look into is
> all the memory placement rules because the "only 4K is allowed for
> host memory" limit that nouveau imposes is a source of many pains in
> userspace (originally thought to be a HW thing but seems it's actually
> not), and having the checks on both bo and vmm paths would help
> starting out with that.

Please don't top-post, see also [1].

[1] https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying