[PATCH] cifs: fix missing unlock in cifs_file_copychunk_range()

Steve French smfrench at gmail.com
Sat Nov 19 20:04:01 UTC 2022


good catch.

merged into cifs-2.6.git for-next

On Fri, Nov 18, 2022 at 10:09 PM ChenXiaoSong <chenxiaosong2 at huawei.com> wrote:
>
> xfstests generic/013 and generic/476 reported WARNING as follows:
>
>   WARNING: lock held when returning to user space!
>   6.1.0-rc5+ #4 Not tainted
>   ------------------------------------------------
>   fsstress/504233 is leaving the kernel with locks still held!
>   2 locks held by fsstress/504233:
>    #0: ffff888054c38850 (&sb->s_type->i_mutex_key#21){+.+.}-{3:3}, at:
>                         lock_two_nondirectories+0xcf/0xf0
>    #1: ffff8880b8fec750 (&sb->s_type->i_mutex_key#21/4){+.+.}-{3:3}, at:
>                         lock_two_nondirectories+0xb7/0xf0
>
> This will lead to deadlock and hungtask.
>
> Fix this by releasing locks when failed to write out on a file range in
> cifs_file_copychunk_range().
>
> Fixes: 3e3761f1ec7d ("smb3: use filemap_write_and_wait_range instead of filemap_write_and_wait")
> Signed-off-by: ChenXiaoSong <chenxiaosong2 at huawei.com>
> ---
>  fs/cifs/cifsfs.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> index fe220686bba4..712a43161448 100644
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -1281,7 +1281,7 @@ ssize_t cifs_file_copychunk_range(unsigned int xid,
>         rc = filemap_write_and_wait_range(src_inode->i_mapping, off,
>                                           off + len - 1);
>         if (rc)
> -               goto out;
> +               goto unlock;
>
>         /* should we flush first and last page first */
>         truncate_inode_pages(&target_inode->i_data, 0);
> @@ -1297,6 +1297,8 @@ ssize_t cifs_file_copychunk_range(unsigned int xid,
>          * that target is updated on the server
>          */
>         CIFS_I(target_inode)->time = 0;
> +
> +unlock:
>         /* although unlocking in the reverse order from locking is not
>          * strictly necessary here it is a little cleaner to be consistent
>          */
> --
> 2.31.1
>


-- 
Thanks,

Steve



More information about the samba-technical mailing list