linux-kernel - Re: [PATCH 2/8] drm/gem: Introduce drm_gem_get_unmapped

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: <cd9084e1-16d9-4fd6-9c64-1876d53d5225@collabora.com>
Date: Tue, 30 Sep 2025 18:09:37 +0200
From: Loïc Molinari <loic.molinari@...labora.com>
To: Boris Brezillon <boris.brezillon@...labora.com>
Cc: 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>,
 Jani Nikula <jani.nikula@...ux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>, Tvrtko Ursulin
 <tursulin@...ulin.net>, Rob Herring <robh@...nel.org>,
 Steven Price <steven.price@....com>, Liviu Dudau <liviu.dudau@....com>,
 Melissa Wen <mwen@...lia.com>, Maíra Canal
 <mcanal@...lia.com>, Hugh Dickins <hughd@...gle.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Al Viro
 <viro@...iv.linux.org.uk>, Mikołaj Wasiak
 <mikolaj.wasiak@...el.com>, Christian Brauner <brauner@...nel.org>,
 Nitin Gote <nitin.r.gote@...el.com>, Andi Shyti
 <andi.shyti@...ux.intel.com>, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
 linux-mm@...ck.org, kernel@...labora.com
Subject: Re: [PATCH 2/8] drm/gem: Introduce drm_gem_get_unmapped_area() fop

On 30/09/2025 12:30, Boris Brezillon wrote:
> On Mon, 29 Sep 2025 22:03:10 +0200
>
> Loïc Molinari <loic.molinari@...labora.com> wrote:
>> +unsigned long drm_gem_get_unmapped_area(struct file *filp, unsigned long uaddr,
>> +					unsigned long len, unsigned long pgoff,
>> +					unsigned long flags)
>> +{
>> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> +	struct drm_gem_object *obj;
>> +	unsigned long ret;
>> +
>> +	obj = drm_gem_object_lookup_from_offset(filp, pgoff, len >> PAGE_SHIFT);
>> +	if (IS_ERR(obj))
>> +		return mm_get_unmapped_area(current->mm, filp, uaddr, len, 0,
>> +					    flags);
>> +
>> +	ret = shmem_get_unmapped_area(obj->filp, uaddr, len, 0, flags);
>> +
>> +	drm_gem_object_put(obj);
>> +
>> +	return ret;
>> +#else
>> +	return mm_get_unmapped_area(current->mm, filp, uaddr, len, 0, flags);
> 
> Looks like the above code covers the non-THP case too, do we really need
> to specialize for !CONFIG_TRANSPARENT_HUGEPAGE here?

It does cover the !CONFIG_TRANSPARENT_HUGEPAGE case 
(shmem_get_unmapped_area() would just call and return the 
mm_get_unmapped_area() address) but the idea here is to avoid the GEM 
object lookup cost by calling mm_get_unmapped_area() directly.

>> +#endif
>> +}
>> +EXPORT_SYMBOL(drm_gem_get_unmapped_area);

Loïc