[PATCH] btrfs: fix the folio leak on S390 hardware acceleration

[PATCH] btrfs: fix the folio leak on S390 hardware acceleration

[Qu Wenruo]

[BUG]
After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration
buffer preparation"), we no longer release the folio of the page cache
of folio returned by btrfs_compress_filemap_get_folio() for S390
hardware accerlation path.

[CAUSE]
Before that commit, we call kumap_local() and folio_put() after handling
each folio.

Although the timing is not ideal (it release previous folio at the
beginning of the loop, and rely on some extra cleanup out of the loop),
it at least handles the folio release correctly.

Meanwhile the refactored code is easier to read, it lacks the call to
release the filemap folio.

[FIX]
Add the missing folio_put() for copy_data_into_buffer().

Cc: linux-s390@vger.kernel.orgaa60fe12b4f49f49fc73e5023f8675e2df1f7805
Fixes: aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation")
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/zlib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/btrfs/zlib.c b/fs/btrfs/zlib.c
index 6caba8be7c84..10ed48d4a846 100644
--- a/fs/btrfs/zlib.c
+++ b/fs/btrfs/zlib.c
@@ -139,6 +139,7 @@ static int copy_data_into_buffer(struct address_space *mapping,
 		data_in = kmap_local_folio(folio, offset);
 		memcpy(workspace->buf + cur - filepos, data_in, copy_length);
 		kunmap_local(data_in);
+		folio_put(folio);
 		cur += copy_length;
 	}
 	return 0;
-- 
2.52.0

Re: [PATCH] btrfs: fix the folio leak on S390 hardware acceleration

[Boris Burkov]

On Mon, Jan 19, 2026 at 04:24:04PM +1030, Qu Wenruo wrote:
> [BUG]
> After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration
> buffer preparation"), we no longer release the folio of the page cache
> of folio returned by btrfs_compress_filemap_get_folio() for S390
> hardware accerlation path.
> 
> [CAUSE]
> Before that commit, we call kumap_local() and folio_put() after handling
> each folio.
> 
> Although the timing is not ideal (it release previous folio at the
> beginning of the loop, and rely on some extra cleanup out of the loop),
> it at least handles the folio release correctly.
> 
> Meanwhile the refactored code is easier to read, it lacks the call to
> release the filemap folio.
> 
> [FIX]
> Add the missing folio_put() for copy_data_into_buffer().
> 
> Cc: linux-s390@vger.kernel.orgaa60fe12b4f49f49fc73e5023f8675e2df1f7805
> Fixes: aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation")

Reviewed-by: Boris Burkov <boris@bur.io>

> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>  fs/btrfs/zlib.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/btrfs/zlib.c b/fs/btrfs/zlib.c
> index 6caba8be7c84..10ed48d4a846 100644
> --- a/fs/btrfs/zlib.c
> +++ b/fs/btrfs/zlib.c
> @@ -139,6 +139,7 @@ static int copy_data_into_buffer(struct address_space *mapping,
>  		data_in = kmap_local_folio(folio, offset);
>  		memcpy(workspace->buf + cur - filepos, data_in, copy_length);
>  		kunmap_local(data_in);
> +		folio_put(folio);
>  		cur += copy_length;
>  	}
>  	return 0;
> -- 
> 2.52.0
> 

Re: [PATCH] btrfs: fix the folio leak on S390 hardware acceleration

[Qu Wenruo]

Adding S390 to the mailing list, I got the incorrect address in the 
initial patch.

Much appreciated if S390 people can give it a test.

Thanks,
Qu


在 2026/1/19 16:24, Qu Wenruo 写道:
> [BUG]
> After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration
> buffer preparation"), we no longer release the folio of the page cache
> of folio returned by btrfs_compress_filemap_get_folio() for S390
> hardware accerlation path.
> 
> [CAUSE]
> Before that commit, we call kumap_local() and folio_put() after handling
> each folio.
> 
> Although the timing is not ideal (it release previous folio at the
> beginning of the loop, and rely on some extra cleanup out of the loop),
> it at least handles the folio release correctly.
> 
> Meanwhile the refactored code is easier to read, it lacks the call to
> release the filemap folio.
> 
> [FIX]
> Add the missing folio_put() for copy_data_into_buffer().
> 
> Cc: linux-s390@vger.kernel.orgaa60fe12b4f49f49fc73e5023f8675e2df1f7805
> Fixes: aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation")
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>   fs/btrfs/zlib.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/fs/btrfs/zlib.c b/fs/btrfs/zlib.c
> index 6caba8be7c84..10ed48d4a846 100644
> --- a/fs/btrfs/zlib.c
> +++ b/fs/btrfs/zlib.c
> @@ -139,6 +139,7 @@ static int copy_data_into_buffer(struct address_space *mapping,
>   		data_in = kmap_local_folio(folio, offset);
>   		memcpy(workspace->buf + cur - filepos, data_in, copy_length);
>   		kunmap_local(data_in);
> +		folio_put(folio);
>   		cur += copy_length;
>   	}
>   	return 0;

Re: [PATCH] btrfs: fix the folio leak on S390 hardware acceleration

[Heiko Carstens]

On Wed, Jan 21, 2026 at 09:22:47AM +1030, Qu Wenruo wrote:
> Adding S390 to the mailing list, I got the incorrect address in the initial
> patch.
> 
> Much appreciated if S390 people can give it a test.
> 
> Thanks,
> Qu
> 
> 在 2026/1/19 16:24, Qu Wenruo 写道:
> > [BUG]
> > After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration
> > buffer preparation"), we no longer release the folio of the page cache
> > of folio returned by btrfs_compress_filemap_get_folio() for S390
> > hardware accerlation path.
> > 
> > [CAUSE]
> > Before that commit, we call kumap_local() and folio_put() after handling
> > each folio.
> > 
> > Although the timing is not ideal (it release previous folio at the
> > beginning of the loop, and rely on some extra cleanup out of the loop),
> > it at least handles the folio release correctly.
> > 
> > Meanwhile the refactored code is easier to read, it lacks the call to
> > release the filemap folio.
> > 
> > [FIX]
> > Add the missing folio_put() for copy_data_into_buffer().
> > 
> > Cc: linux-s390@vger.kernel.orgaa60fe12b4f49f49fc73e5023f8675e2df1f7805
> > Fixes: aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation")
> > Signed-off-by: Qu Wenruo <wqu@suse.com>
> > ---
> >   fs/btrfs/zlib.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/fs/btrfs/zlib.c b/fs/btrfs/zlib.c
> > index 6caba8be7c84..10ed48d4a846 100644
> > --- a/fs/btrfs/zlib.c
> > +++ b/fs/btrfs/zlib.c
> > @@ -139,6 +139,7 @@ static int copy_data_into_buffer(struct address_space *mapping,
> >   		data_in = kmap_local_folio(folio, offset);
> >   		memcpy(workspace->buf + cur - filepos, data_in, copy_length);
> >   		kunmap_local(data_in);
> > +		folio_put(folio);
> >   		cur += copy_length;
> >   	}
> >   	return 0;

Mikhail, can you have a look at this, please?

Re: [PATCH] btrfs: fix the folio leak on S390 hardware acceleration

[Mikhail Zaslonko]

Hello Qu,

Sorry for the late response. 
I ran some test on s390 including folio-leak verification. LGTM.

Tested-by:   Mikhail Zaslonko <zaslonko@linux.ibm.com>


On 20-Jan-26 23:52, Qu Wenruo wrote:
> Adding S390 to the mailing list, I got the incorrect address in the initial patch.
> 
> Much appreciated if S390 people can give it a test.
> 
> Thanks,
> Qu
> 
> 
> 在 2026/1/19 16:24, Qu Wenruo 写道:
>> [BUG]
>> After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration
>> buffer preparation"), we no longer release the folio of the page cache
>> of folio returned by btrfs_compress_filemap_get_folio() for S390
>> hardware accerlation path.
>>
>> [CAUSE]
>> Before that commit, we call kumap_local() and folio_put() after handling
>> each folio.
>>
>> Although the timing is not ideal (it release previous folio at the
>> beginning of the loop, and rely on some extra cleanup out of the loop),
>> it at least handles the folio release correctly.
>>
>> Meanwhile the refactored code is easier to read, it lacks the call to
>> release the filemap folio.
>>
>> [FIX]
>> Add the missing folio_put() for copy_data_into_buffer().
>>
>> Cc: linux-s390@vger.kernel.orgaa60fe12b4f49f49fc73e5023f8675e2df1f7805
>> Fixes: aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation")
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>   fs/btrfs/zlib.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/fs/btrfs/zlib.c b/fs/btrfs/zlib.c
>> index 6caba8be7c84..10ed48d4a846 100644
>> --- a/fs/btrfs/zlib.c
>> +++ b/fs/btrfs/zlib.c
>> @@ -139,6 +139,7 @@ static int copy_data_into_buffer(struct address_space *mapping,
>>           data_in = kmap_local_folio(folio, offset);
>>           memcpy(workspace->buf + cur - filepos, data_in, copy_length);
>>           kunmap_local(data_in);
>> +        folio_put(folio);
>>           cur += copy_length;
>>       }
>>       return 0;
> 
> 

Re: [PATCH] btrfs: fix the folio leak on S390 hardware acceleration

[David Sterba]

On Thu, Feb 05, 2026 at 11:54:21PM +0100, Mikhail Zaslonko wrote:
> Hello Qu,
> 
> Sorry for the late response. 
> I ran some test on s390 including folio-leak verification. LGTM.
> 
> Tested-by:   Mikhail Zaslonko <zaslonko@linux.ibm.com>

Thanks for testing, the patch has been merged to 6.19.

Re: [PATCH] btrfs: fix the folio leak on S390 hardware acceleration

[David Sterba]

On Mon, Jan 19, 2026 at 04:24:04PM +1030, Qu Wenruo wrote:
> [BUG]
> After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration
> buffer preparation"), we no longer release the folio of the page cache
> of folio returned by btrfs_compress_filemap_get_folio() for S390
> hardware accerlation path.
> 
> [CAUSE]
> Before that commit, we call kumap_local() and folio_put() after handling
> each folio.
> 
> Although the timing is not ideal (it release previous folio at the
> beginning of the loop, and rely on some extra cleanup out of the loop),
> it at least handles the folio release correctly.
> 
> Meanwhile the refactored code is easier to read, it lacks the call to
> release the filemap folio.
> 
> [FIX]
> Add the missing folio_put() for copy_data_into_buffer().
> 
> Cc: linux-s390@vger.kernel.orgaa60fe12b4f49f49fc73e5023f8675e2df1f7805
> Fixes: aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation")
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Reviewed-by: David Sterba <dsterba@suse.com>