[PATCH v1 0/3] Modify memfd_luo code

[PATCH v1 0/3] Modify memfd_luo code

[Chenghao Duan]

I found several modifiable points while reading the code. Please review.

Chenghao Duan (3):
  mm/memfd_luo: optimize shmem_recalc_inode calls in retrieve path
  mm/memfd_luo: remove unnecessary memset in zero-size memfd path
  mm/memfd_luo: use i_size_write() to set inode size during retrieve

 mm/memfd_luo.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

-- 
2.25.1

[PATCH v1 1/3] mm/memfd_luo: optimize shmem_recalc_inode calls in retrieve path

[Chenghao Duan]

Move shmem_recalc_inode() out of the loop in memfd_luo_retrieve_folios()
to improve performance when restoring large memfds.

Currently, shmem_recalc_inode() is called for each folio during restore,
which is O(n) expensive operations. This patch collects the number of
successfully added folios and calls shmem_recalc_inode() once after the
loop completes, reducing complexity to O(1).

Additionally, fix the error path to also call shmem_recalc_inode() for
the folios that were successfully added before the error occurred.

Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
---
 mm/memfd_luo.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
index b8edb9f981d7..5ddd3657d8be 100644
--- a/mm/memfd_luo.c
+++ b/mm/memfd_luo.c
@@ -397,6 +397,7 @@ static int memfd_luo_retrieve_folios(struct file *file,
 	struct folio *folio;
 	int err = -EIO;
 	long i;
+	u64 nr_added = 0;
 
 	for (i = 0; i < nr_folios; i++) {
 		const struct memfd_luo_folio_ser *pfolio = &folios_ser[i];
@@ -448,12 +449,15 @@ static int memfd_luo_retrieve_folios(struct file *file,
 			goto unlock_folio;
 		}
 
-		shmem_recalc_inode(inode, 1, 0);
+		nr_added++;
 		folio_add_lru(folio);
 		folio_unlock(folio);
 		folio_put(folio);
 	}
 
+	if (nr_added)
+		shmem_recalc_inode(inode, nr_added, 0);
+
 	return 0;
 
 unlock_folio:
@@ -472,6 +476,9 @@ static int memfd_luo_retrieve_folios(struct file *file,
 			folio_put(folio);
 	}
 
+	if (nr_added)
+		shmem_recalc_inode(inode, nr_added, 0);
+
 	return err;
 }
 
-- 
2.25.1

[PATCH v1 2/3] mm/memfd_luo: remove unnecessary memset in zero-size memfd path

[Chenghao Duan]

The memset(kho_vmalloc, 0, sizeof(*kho_vmalloc)) call in the zero-size
file handling path is unnecessary because the allocation of the ser
structure already uses the __GFP_ZERO flag, ensuring the memory is
already zero-initialized.

Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
---
 mm/memfd_luo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
index 5ddd3657d8be..413df8c75c1d 100644
--- a/mm/memfd_luo.c
+++ b/mm/memfd_luo.c
@@ -103,7 +103,6 @@ static int memfd_luo_preserve_folios(struct file *file,
 	if (!size) {
 		*nr_foliosp = 0;
 		*out_folios_ser = NULL;
-		memset(kho_vmalloc, 0, sizeof(*kho_vmalloc));
 		return 0;
 	}
 
-- 
2.25.1

[PATCH v1 3/3] mm/memfd_luo: use i_size_write() to set inode size during retrieve

[Chenghao Duan]

Use i_size_write() instead of directly assigning to inode->i_size
when restoring the memfd size in memfd_luo_retrieve().

No functional change intended.

Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
---
 mm/memfd_luo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
index 413df8c75c1d..5e5971f25c68 100644
--- a/mm/memfd_luo.c
+++ b/mm/memfd_luo.c
@@ -500,7 +500,7 @@ static int memfd_luo_retrieve(struct liveupdate_file_op_args *args)
 	}
 
 	vfs_setpos(file, ser->pos, MAX_LFS_FILESIZE);
-	file->f_inode->i_size = ser->size;
+	i_size_write(file_inode(file), ser->size);
 
 	if (ser->nr_folios) {
 		folios_ser = kho_restore_vmalloc(&ser->folios);
-- 
2.25.1

Re: [PATCH v1 1/3] mm/memfd_luo: optimize shmem_recalc_inode calls in retrieve path

[Pasha Tatashin]

On Wed, Mar 18, 2026 at 9:29 PM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
>
> Move shmem_recalc_inode() out of the loop in memfd_luo_retrieve_folios()
> to improve performance when restoring large memfds.
>
> Currently, shmem_recalc_inode() is called for each folio during restore,
> which is O(n) expensive operations. This patch collects the number of
> successfully added folios and calls shmem_recalc_inode() once after the
> loop completes, reducing complexity to O(1).
>
> Additionally, fix the error path to also call shmem_recalc_inode() for
> the folios that were successfully added before the error occurred.
>
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> ---
>  mm/memfd_luo.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index b8edb9f981d7..5ddd3657d8be 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -397,6 +397,7 @@ static int memfd_luo_retrieve_folios(struct file *file,
>         struct folio *folio;
>         int err = -EIO;
>         long i;
> +       u64 nr_added = 0;

nit: I perfer RCT for local variables order, but it is not followed in
this file anyway.

>
>         for (i = 0; i < nr_folios; i++) {
>                 const struct memfd_luo_folio_ser *pfolio = &folios_ser[i];
> @@ -448,12 +449,15 @@ static int memfd_luo_retrieve_folios(struct file *file,
>                         goto unlock_folio;
>                 }
>
> -               shmem_recalc_inode(inode, 1, 0);
> +               nr_added++;
>                 folio_add_lru(folio);
>                 folio_unlock(folio);
>                 folio_put(folio);
>         }
>
> +       if (nr_added)
> +               shmem_recalc_inode(inode, nr_added, 0);
> +
>         return 0;
>
>  unlock_folio:
> @@ -472,6 +476,9 @@ static int memfd_luo_retrieve_folios(struct file *file,
>                         folio_put(folio);
>         }
>
> +       if (nr_added)
> +               shmem_recalc_inode(inode, nr_added, 0);
> +

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>

Re: [PATCH v1 2/3] mm/memfd_luo: remove unnecessary memset in zero-size memfd path

[Pasha Tatashin]

On Wed, Mar 18, 2026 at 9:29 PM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
>
> The memset(kho_vmalloc, 0, sizeof(*kho_vmalloc)) call in the zero-size
> file handling path is unnecessary because the allocation of the ser
> structure already uses the __GFP_ZERO flag, ensuring the memory is
> already zero-initialized.
>
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> ---
>  mm/memfd_luo.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index 5ddd3657d8be..413df8c75c1d 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -103,7 +103,6 @@ static int memfd_luo_preserve_folios(struct file *file,
>         if (!size) {
>                 *nr_foliosp = 0;
>                 *out_folios_ser = NULL;
> -               memset(kho_vmalloc, 0, sizeof(*kho_vmalloc));
>                 return 0;
>         }
>
> --
> 2.25.1
>

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>

Re: [PATCH v1 3/3] mm/memfd_luo: use i_size_write() to set inode size during retrieve

[Pasha Tatashin]

On Wed, Mar 18, 2026 at 9:29 PM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
>
> Use i_size_write() instead of directly assigning to inode->i_size
> when restoring the memfd size in memfd_luo_retrieve().
>
> No functional change intended.
>
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> ---
>  mm/memfd_luo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index 413df8c75c1d..5e5971f25c68 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -500,7 +500,7 @@ static int memfd_luo_retrieve(struct liveupdate_file_op_args *args)
>         }
>
>         vfs_setpos(file, ser->pos, MAX_LFS_FILESIZE);
> -       file->f_inode->i_size = ser->size;
> +       i_size_write(file_inode(file), ser->size);

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>

I think, smp_store_release() here is not striclty necessary, but makes
sense to use the right function for consistency.

Thanks,
Pasha

Re: [PATCH v1 3/3] mm/memfd_luo: use i_size_write() to set inode size during retrieve

[Pratyush Yadav]

On Thu, Mar 19 2026, Chenghao Duan wrote:

> Use i_size_write() instead of directly assigning to inode->i_size
> when restoring the memfd size in memfd_luo_retrieve().

The commit message can be improved. It only explains _what_ the patch
does. Readers can see that by looking at the code. So it just repeats
information that is already there.

To be fair, for more complex patches explaining the what does make sense
since it might not always be obvious. But what is almost always be a lot
more useful is to explain _why_ this change is made.

I intentionally assigned i_size directly here. The reason for that being
that no one has access to the inode yet so there is no need for the
smp_store_release() since there won't be racy accesses. So my first
reaction on reading this was to check if I missed some sort of race
condition. I don't see any, but this is exactly the kind of thing the
commit message should say.

So please, explain why you made this change. The reason can be as simple
as "for consistency", but there should be one so reviewers aren't left
guessing.

>
> No functional change intended.
>
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> ---
>  mm/memfd_luo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index 413df8c75c1d..5e5971f25c68 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -500,7 +500,7 @@ static int memfd_luo_retrieve(struct liveupdate_file_op_args *args)
>  	}
>  
>  	vfs_setpos(file, ser->pos, MAX_LFS_FILESIZE);
> -	file->f_inode->i_size = ser->size;
> +	i_size_write(file_inode(file), ser->size);

For the code change, I am neutral. I don't suppose it makes much of a
difference, but if people think this is cleaner fine by me.

>  
>  	if (ser->nr_folios) {
>  		folios_ser = kho_restore_vmalloc(&ser->folios);

-- 
Regards,
Pratyush Yadav

Re: [PATCH v1 1/3] mm/memfd_luo: optimize shmem_recalc_inode calls in retrieve path

[Pratyush Yadav]

On Thu, Mar 19 2026, Pasha Tatashin wrote:

> On Wed, Mar 18, 2026 at 9:29 PM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
>>
>> Move shmem_recalc_inode() out of the loop in memfd_luo_retrieve_folios()
>> to improve performance when restoring large memfds.
>>
>> Currently, shmem_recalc_inode() is called for each folio during restore,
>> which is O(n) expensive operations. This patch collects the number of
>> successfully added folios and calls shmem_recalc_inode() once after the
>> loop completes, reducing complexity to O(1).
>>
>> Additionally, fix the error path to also call shmem_recalc_inode() for
>> the folios that were successfully added before the error occurred.
>>
>> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
>> ---
>>  mm/memfd_luo.c | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
>> index b8edb9f981d7..5ddd3657d8be 100644
>> --- a/mm/memfd_luo.c
>> +++ b/mm/memfd_luo.c
>> @@ -397,6 +397,7 @@ static int memfd_luo_retrieve_folios(struct file *file,
>>         struct folio *folio;
>>         int err = -EIO;
>>         long i;
>> +       u64 nr_added = 0;
>
> nit: I perfer RCT for local variables order, but it is not followed in
> this file anyway.

It is though, for the most part. I also prefer this so as much as I
could I followed it, but sometimes if you want to assign variables at
declaration, it isn't always possible.

Anyway, RCT would be nice to have indeed.

[...]

-- 
Regards,
Pratyush Yadav

Re: [PATCH v1 1/3] mm/memfd_luo: optimize shmem_recalc_inode calls in retrieve path

[Pratyush Yadav]

On Thu, Mar 19 2026, Chenghao Duan wrote:

> Move shmem_recalc_inode() out of the loop in memfd_luo_retrieve_folios()
> to improve performance when restoring large memfds.
>
> Currently, shmem_recalc_inode() is called for each folio during restore,
> which is O(n) expensive operations. This patch collects the number of
> successfully added folios and calls shmem_recalc_inode() once after the
> loop completes, reducing complexity to O(1).
>
> Additionally, fix the error path to also call shmem_recalc_inode() for
> the folios that were successfully added before the error occurred.
>
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> ---
>  mm/memfd_luo.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index b8edb9f981d7..5ddd3657d8be 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -397,6 +397,7 @@ static int memfd_luo_retrieve_folios(struct file *file,
>  	struct folio *folio;
>  	int err = -EIO;
>  	long i;
> +	u64 nr_added = 0;
>  
>  	for (i = 0; i < nr_folios; i++) {
>  		const struct memfd_luo_folio_ser *pfolio = &folios_ser[i];
> @@ -448,12 +449,15 @@ static int memfd_luo_retrieve_folios(struct file *file,
>  			goto unlock_folio;
>  		}
>  
> -		shmem_recalc_inode(inode, 1, 0);
> +		nr_added++;

https://sashiko.dev/#/patchset/20260319012845.29570-1-duanchenghao%40kylinos.cn

AI review picked up a real bug here:

    Since memfd files can use large folios, should nr_added track the
    number of pages instead of the number of folios?

    shmem_recalc_inode() expects the number of pages. Passing the number
    of folios might under-account blocks and bypass tmpfs limits or
    quotas.

    Also, shmem_inode_acct_blocks() earlier in the loop is hardcoded to
    1, which might have the same issue.

If THP is being used, we should account for nr_pages instead of
nr_folios. Can you please also add a fix for this with your series? Just
so we fix the bugs the code already has before refactoring it.

>  		folio_add_lru(folio);
>  		folio_unlock(folio);
>  		folio_put(folio);
>  	}
>  
> +	if (nr_added)
> +		shmem_recalc_inode(inode, nr_added, 0);

Nit: it is very very likely that nr_added > 0. And shmem_recalc_inode()
can deal with 0 nr_added. So please drop this if check and call it
directly.

Other than this, the patch LGTM. Thanks for working on this!

> +
>  	return 0;
>  
>  unlock_folio:
> @@ -472,6 +476,9 @@ static int memfd_luo_retrieve_folios(struct file *file,
>  			folio_put(folio);
>  	}
>  
> +	if (nr_added)
> +		shmem_recalc_inode(inode, nr_added, 0);
> +
>  	return err;
>  }

-- 
Regards,
Pratyush Yadav

Re: [PATCH v1 2/3] mm/memfd_luo: remove unnecessary memset in zero-size memfd path

[Pratyush Yadav]

On Thu, Mar 19 2026, Chenghao Duan wrote:

> The memset(kho_vmalloc, 0, sizeof(*kho_vmalloc)) call in the zero-size
> file handling path is unnecessary because the allocation of the ser
> structure already uses the __GFP_ZERO flag, ensuring the memory is
> already zero-initialized.
>
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>

Reviewed-by: Pratyush Yadav <pratyush@kernel.org>

[...]

-- 
Regards,
Pratyush Yadav

Re: [PATCH v1 3/3] mm/memfd_luo: use i_size_write() to set inode size during retrieve

[Mike Rapoport]

On Fri, Mar 20, 2026 at 09:51:01AM +0000, Pratyush Yadav wrote:
> On Thu, Mar 19 2026, Chenghao Duan wrote:
> 
> > Use i_size_write() instead of directly assigning to inode->i_size
> > when restoring the memfd size in memfd_luo_retrieve().
> 
> The commit message can be improved. It only explains _what_ the patch
> does. Readers can see that by looking at the code. So it just repeats
> information that is already there.
> 
> To be fair, for more complex patches explaining the what does make sense
> since it might not always be obvious. But what is almost always be a lot
> more useful is to explain _why_ this change is made.
> 
> I intentionally assigned i_size directly here. The reason for that being
> that no one has access to the inode yet so there is no need for the
> smp_store_release() since there won't be racy accesses. So my first
> reaction on reading this was to check if I missed some sort of race
> condition. I don't see any, but this is exactly the kind of thing the
> commit message should say.
> 
> So please, explain why you made this change. The reason can be as simple
> as "for consistency", but there should be one so reviewers aren't left
> guessing.
> 
> >
> > No functional change intended.
> >
> > Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> > ---
> >  mm/memfd_luo.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> > index 413df8c75c1d..5e5971f25c68 100644
> > --- a/mm/memfd_luo.c
> > +++ b/mm/memfd_luo.c
> > @@ -500,7 +500,7 @@ static int memfd_luo_retrieve(struct liveupdate_file_op_args *args)
> >  	}
> >  
> >  	vfs_setpos(file, ser->pos, MAX_LFS_FILESIZE);
> > -	file->f_inode->i_size = ser->size;
> > +	i_size_write(file_inode(file), ser->size);
> 
> For the code change, I am neutral. I don't suppose it makes much of a
> difference, but if people think this is cleaner fine by me.

I'd also add a comment here explaining that i_size_write() is for
consistency :)
 
> >  
> >  	if (ser->nr_folios) {
> >  		folios_ser = kho_restore_vmalloc(&ser->folios);
> 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.

Re: [PATCH v1 2/3] mm/memfd_luo: remove unnecessary memset in zero-size memfd path

[Mike Rapoport]

On Thu, Mar 19, 2026 at 09:28:44AM +0800, Chenghao Duan wrote:
> The memset(kho_vmalloc, 0, sizeof(*kho_vmalloc)) call in the zero-size
> file handling path is unnecessary because the allocation of the ser
> structure already uses the __GFP_ZERO flag, ensuring the memory is
> already zero-initialized.
> 
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
>  mm/memfd_luo.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index 5ddd3657d8be..413df8c75c1d 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -103,7 +103,6 @@ static int memfd_luo_preserve_folios(struct file *file,
>  	if (!size) {
>  		*nr_foliosp = 0;
>  		*out_folios_ser = NULL;
> -		memset(kho_vmalloc, 0, sizeof(*kho_vmalloc));
>  		return 0;
>  	}
>  
> -- 
> 2.25.1
> 

-- 
Sincerely yours,
Mike.