diff mbox series

[v2] cachefiles: fix dentry leak in cachefiles_open_file()

Message ID 20240829083409.3788142-1-libaokun@huaweicloud.com (mailing list archive)
State New
Headers show
Series [v2] cachefiles: fix dentry leak in cachefiles_open_file() | expand

Commit Message

Baokun Li Aug. 29, 2024, 8:34 a.m. UTC
From: Baokun Li <libaokun1@huawei.com>

A dentry leak may be caused when a lookup cookie and a cull are concurrent:

            P1             |             P2
-----------------------------------------------------------
cachefiles_lookup_cookie
  cachefiles_look_up_object
    lookup_one_positive_unlocked
     // get dentry
                            cachefiles_cull
                              inode->i_flags |= S_KERNEL_FILE;
    cachefiles_open_file
      cachefiles_mark_inode_in_use
        __cachefiles_mark_inode_in_use
          can_use = false
          if (!(inode->i_flags & S_KERNEL_FILE))
            can_use = true
	  return false
        return false
        // Returns an error but doesn't put dentry

After that the following WARNING will be triggered when the backend folder
is umounted:

==================================================================
BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img}  still in use (1) [unmount of ext4 sda]
WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70
CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25
RIP: 0010:umount_check+0x5d/0x70
Call Trace:
 <TASK>
 d_walk+0xda/0x2b0
 do_one_tree+0x20/0x40
 shrink_dcache_for_umount+0x2c/0x90
 generic_shutdown_super+0x20/0x160
 kill_block_super+0x1a/0x40
 ext4_kill_sb+0x22/0x40
 deactivate_locked_super+0x35/0x80
 cleanup_mnt+0x104/0x160
==================================================================

Whether cachefiles_open_file() returns true or false, the reference count
obtained by lookup_positive_unlocked() in cachefiles_look_up_object()
should be released.

Therefore release that reference count in cachefiles_look_up_object() to
fix the above issue and simplify the code.

Fixes: 1f08c925e7a3 ("cachefiles: Implement backing file wrangling")
Cc: stable@kernel.org
Signed-off-by: Baokun Li <libaokun1@huawei.com>
---
v1->v2:
	Use of new solution.

v1: https://lore.kernel.org/r/20240826040018.2990763-1-libaokun@huaweicloud.com

 fs/cachefiles/namei.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Comments

David Howells Sept. 16, 2024, 1:05 p.m. UTC | #1
libaokun@huaweicloud.com wrote:

> From: Baokun Li <libaokun1@huawei.com>
> 
> A dentry leak may be caused when a lookup cookie and a cull are concurrent:
> 
>             P1             |             P2
> -----------------------------------------------------------
> cachefiles_lookup_cookie
>   cachefiles_look_up_object
>     lookup_one_positive_unlocked
>      // get dentry
>                             cachefiles_cull
>                               inode->i_flags |= S_KERNEL_FILE;
>     cachefiles_open_file
>       cachefiles_mark_inode_in_use
>         __cachefiles_mark_inode_in_use
>           can_use = false
>           if (!(inode->i_flags & S_KERNEL_FILE))
>             can_use = true
> 	  return false
>         return false
>         // Returns an error but doesn't put dentry
> 
> After that the following WARNING will be triggered when the backend folder
> is umounted:
> 
> ==================================================================
> BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img}  still in use (1) [unmount of ext4 sda]
> WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70
> CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25
> RIP: 0010:umount_check+0x5d/0x70
> Call Trace:
>  <TASK>
>  d_walk+0xda/0x2b0
>  do_one_tree+0x20/0x40
>  shrink_dcache_for_umount+0x2c/0x90
>  generic_shutdown_super+0x20/0x160
>  kill_block_super+0x1a/0x40
>  ext4_kill_sb+0x22/0x40
>  deactivate_locked_super+0x35/0x80
>  cleanup_mnt+0x104/0x160
> ==================================================================
> 
> Whether cachefiles_open_file() returns true or false, the reference count
> obtained by lookup_positive_unlocked() in cachefiles_look_up_object()
> should be released.
> 
> Therefore release that reference count in cachefiles_look_up_object() to
> fix the above issue and simplify the code.
> 
> Fixes: 1f08c925e7a3 ("cachefiles: Implement backing file wrangling")
> Cc: stable@kernel.org
> Signed-off-by: Baokun Li <libaokun1@huawei.com>

Acked-by: David Howells <dhowells@redhat.com>
Christian Brauner Sept. 17, 2024, 9:03 a.m. UTC | #2
On Thu, 29 Aug 2024 16:34:09 +0800, libaokun@huaweicloud.com wrote:
> A dentry leak may be caused when a lookup cookie and a cull are concurrent:
> 
>             P1             |             P2
> -----------------------------------------------------------
> cachefiles_lookup_cookie
>   cachefiles_look_up_object
>     lookup_one_positive_unlocked
>      // get dentry
>                             cachefiles_cull
>                               inode->i_flags |= S_KERNEL_FILE;
>     cachefiles_open_file
>       cachefiles_mark_inode_in_use
>         __cachefiles_mark_inode_in_use
>           can_use = false
>           if (!(inode->i_flags & S_KERNEL_FILE))
>             can_use = true
> 	  return false
>         return false
>         // Returns an error but doesn't put dentry
> 
> [...]

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.fixes

[1/1] cachefiles: fix dentry leak in cachefiles_open_file()
      https://git.kernel.org/vfs/vfs/c/31075a6ed624
diff mbox series

Patch

diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c
index f53977169db4..2b3f9935dbb4 100644
--- a/fs/cachefiles/namei.c
+++ b/fs/cachefiles/namei.c
@@ -595,14 +595,12 @@  static bool cachefiles_open_file(struct cachefiles_object *object,
 	 * write and readdir but not lookup or open).
 	 */
 	touch_atime(&file->f_path);
-	dput(dentry);
 	return true;
 
 check_failed:
 	fscache_cookie_lookup_negative(object->cookie);
 	cachefiles_unmark_inode_in_use(object, file);
 	fput(file);
-	dput(dentry);
 	if (ret == -ESTALE)
 		return cachefiles_create_file(object);
 	return false;
@@ -611,7 +609,6 @@  static bool cachefiles_open_file(struct cachefiles_object *object,
 	fput(file);
 error:
 	cachefiles_do_unmark_inode_in_use(object, d_inode(dentry));
-	dput(dentry);
 	return false;
 }
 
@@ -654,7 +651,9 @@  bool cachefiles_look_up_object(struct cachefiles_object *object)
 		goto new_file;
 	}
 
-	if (!cachefiles_open_file(object, dentry))
+	ret = cachefiles_open_file(object, dentry);
+	dput(dentry);
+	if (!ret)
 		return false;
 
 	_leave(" = t [%lu]", file_inode(object->file)->i_ino);