linux-kernel - Re: [RFC PATCH 1/7] shmem: Introduce non-blocking allocation of shmem 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250225134325.72a071b6@collabora.com>
Date: Tue, 25 Feb 2025 13:43:25 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Adrián Larumbe <adrian.larumbe@...labora.com>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, Steven
 Price <steven.price@....com>, Rob Herring <robh@...nel.org>, Hugh Dickins
 <hughd@...gle.com>, kernel@...labora.com, linux-mm@...ck.org
Subject: Re: [RFC PATCH 1/7] shmem: Introduce non-blocking allocation of
 shmem pages

On Tue, 18 Feb 2025 23:25:31 +0000
Adrián Larumbe <adrian.larumbe@...labora.com> wrote:

> With the future goal of preventing deadlocks with the shrinker when reclaiming
> GEM-allocated memory, a variant of shmem_read_mapping_page_gfp() that does not
> sleep when enough memory isn't available, therefore potentially triggering the
> shrinker on same driver, is introduced.
> 
> Signed-off-by: Adrián Larumbe <adrian.larumbe@...labora.com>
> ---
>  include/linux/shmem_fs.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index 0b273a7b9f01..5735728aeda2 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -167,6 +167,13 @@ static inline struct page *shmem_read_mapping_page(
>  					mapping_gfp_mask(mapping));
>  }
>  
> +static inline struct page *shmem_read_mapping_page_nonblocking(
> +				struct address_space *mapping, pgoff_t index)
> +{
> +	return shmem_read_mapping_page_gfp(mapping, index,
> +					mapping_gfp_mask(mapping) | GFP_NOWAIT);
> +}

Just my 2 cents, but I'm not entirely sure it's worth adding a helper
for the non-blocking case given we can pretty easily call
shmem_read_mapping_page_gfp() with the GFP_NOWAIT addition where needed.

> +
>  static inline bool shmem_file(struct file *file)
>  {
>  	if (!IS_ENABLED(CONFIG_SHMEM))