Re: [PATCH for v5.15 1/2] btrfs: don't hold CPU for too long when defragging a file

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Feb 16, 2022 at 03:09:07PM +0800, Qu Wenruo wrote:
> commit 2d192fc4c1abeb0d04d1c8cd54405ff4a0b0255b upstream.

This commit is already in 5.15.22.

> 
> There is a user report about "btrfs filesystem defrag" causing 120s
> timeout problem.
> 
> For btrfs_defrag_file() it will iterate all file extents if called from
> defrag ioctl, thus it can take a long time.
> 
> There is no reason not to release the CPU during such a long operation.
> 
> Add cond_resched() after defragged one cluster.
> 
> CC: stable@vger.kernel.org # 5.15
> Link: https://lore.kernel.org/linux-btrfs/10e51417-2203-f0a4-2021-86c8511cc367@gmx.com
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: David Sterba <dsterba@suse.com>
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
>  fs/btrfs/ioctl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 6a863b3f6de0..38a1b68c7851 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -1581,6 +1581,7 @@ int btrfs_defrag_file(struct inode *inode, struct file *file,
>  				last_len = 0;
>  			}
>  		}
> +		cond_resched();
>  	}
>  
>  	ret = defrag_count;
> -- 
> 2.35.1
> 

The original commit looks nothing like this commit at all.  Are you sure
you got this correct?

confused,

greg k-h