linux-kernel - Re: [PATCH 6/8] drm/panthor: Introduce huge tmpfs mount point option

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: <f9f92476-c218-40d0-bb45-382252e2f288@collabora.com>
Date: Sat, 4 Oct 2025 11:39:24 +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 6/8] drm/panthor: Introduce huge tmpfs mount point option

On 30/09/2025 18:52, Boris Brezillon wrote:
> On Tue, 30 Sep 2025 18:31:11 +0200
> Loïc Molinari <loic.molinari@...labora.com> wrote:
> 
>> On 30/09/2025 12:34, Boris Brezillon wrote:
>>> On Mon, 29 Sep 2025 22:03:14 +0200
>>> Loïc Molinari <loic.molinari@...labora.com> wrote:
>>>    
>>>> diff --git a/drivers/gpu/drm/panthor/panthor_device.h b/drivers/gpu/drm/panthor/panthor_device.h
>>>> index 4fc7cf2aeed5..54ca61567426 100644
>>>> --- a/drivers/gpu/drm/panthor/panthor_device.h
>>>> +++ b/drivers/gpu/drm/panthor/panthor_device.h
>>>> @@ -135,6 +135,9 @@ struct panthor_device {
>>>>    	/** @devfreq: Device frequency scaling management data. */
>>>>    	struct panthor_devfreq *devfreq;
>>>>    
>>>> +	/** @huge_mnt: tmpfs mount point with Transparent Hugepage enabled. */
>>>> +	struct vfsmount *huge_mnt;
>>>
>>> Now that we have a helper to create a huge mountpoint, wouldn't it
>>> make sense to have this field in drm_device instead of having each
>>> driver add a huge_mnt field to their <driver>_device object.
>>
>> Not sure this should be enforced for all DRM drivers since most of them
>> don't create separate huge mountpoints (only 4 for now including this
>> patchset) and I guess some maintainers might prefer to depend on the
>> sysfs interace to enable huge pages.
> 
> I'm not saying we should create the huge mountpoint by default, but if
> this is a generic helper, it makes sense to also manage this mountpoint
> internally. In the end, it'd be a small price to pay for drivers that
> don't need it (the size of a pointer in the drm_device object), and
> with this in place, driver wouldn't even have to call
> drm_gem_shmem_huge_mnt_free() manually (can be automated with a
> drmm_add_action_or_reset() calling kern_unmount() inside
> drm_gem_shmem_huge_mnt_create()).

Ok. I've just sent a v3 of the series with the huge vfsmount stored in 
the drm_device struct. This also allowed to get rid of some of the 
*_with_mnt helpers.

> 
>>
>>>> +
>>>>    	/** @unplug: Device unplug related fields. */
>>>>    	struct {
>>>>    		/** @lock: Lock used to serialize unplug operations. */
>>>    
>>
>> Loïc
> 

Loïc