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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250930185216.0219a542@fedora>
Date: Tue, 30 Sep 2025 18:52:16 +0200
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Loïc Molinari <loic.molinari@...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 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()).

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