linux-kernel - Re: [PATCH v19 30/30] drm/panfrost: Switch to generic memory shrinker

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: <1cf2b45f-d41b-4b2c-80c8-0b78203f4467@collabora.com>
Date: Thu, 25 Jan 2024 15:04:41 +0300
From: Dmitry Osipenko <dmitry.osipenko@...labora.com>
To: Boris Brezillon <boris.brezillon@...labora.com>
Cc: David Airlie <airlied@...il.com>, Gerd Hoffmann <kraxel@...hat.com>,
 Gurchetan Singh <gurchetansingh@...omium.org>, Chia-I Wu
 <olvaffe@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Christian König <christian.koenig@....com>,
 Qiang Yu <yuq825@...il.com>, Steven Price <steven.price@....com>,
 Emma Anholt <emma@...olt.net>, Melissa Wen <mwen@...lia.com>,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 kernel@...labora.com, virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v19 30/30] drm/panfrost: Switch to generic memory shrinker

On 1/25/24 12:49, Boris Brezillon wrote:
> On Fri,  5 Jan 2024 21:46:24 +0300
> Dmitry Osipenko <dmitry.osipenko@...labora.com> wrote:
> 
>> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
>> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
>> @@ -328,6 +328,7 @@ int panfrost_mmu_map(struct panfrost_gem_mapping *mapping)
>>  	struct panfrost_device *pfdev = to_panfrost_device(obj->dev);
>>  	struct sg_table *sgt;
>>  	int prot = IOMMU_READ | IOMMU_WRITE;
>> +	int ret = 0;
>>  
>>  	if (WARN_ON(mapping->active))
>>  		return 0;
>> @@ -335,15 +336,32 @@ int panfrost_mmu_map(struct panfrost_gem_mapping *mapping)
>>  	if (bo->noexec)
>>  		prot |= IOMMU_NOEXEC;
>>  
>> +	if (!obj->import_attach) {
>> +		/*
>> +		 * Don't allow shrinker to move pages while pages are mapped.
>> +		 * It's fine to move pages afterwards because shrinker will
>> +		 * take care of unmapping pages during eviction.
>> +		 */
> 
> That's not exactly what this shmem_pin() is about, is it? I think it's
> here to meet the drm_gem_shmem_get_pages_sgt() rule stating that pages
> must be pinned while the sgt returned by drm_gem_shmem_get_pages_sgt()
> is manipulated. You actually unpin the GEM just after the mmu_map_sg()
> call, which means pages could very well be reclaimed while the MMU
> still has a mapping referencing those physical pages. And that's fine,
> because what's supposed to protect against that is the fence we
> register to the GEM resv at job submission time.

The comment indeed needs to be improved, thanks.

s/are mapped/in process of mapping creation/

-- 
Best regards,
Dmitry