Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New found memleak in zpl_mount #5490

Closed
tuxoko opened this issue Dec 15, 2016 · 1 comment
Closed

New found memleak in zpl_mount #5490

tuxoko opened this issue Dec 15, 2016 · 1 comment
Labels
Component: Memory Management kernel memory management
Milestone

Comments

@tuxoko
Copy link
Contributor

tuxoko commented Dec 15, 2016

http://build.zfsonlinux.org/builders/Ubuntu%2016.04%20x86_64%20Kmemleak%20%28TEST%29/builds/15/steps/shell_11/logs/kmemleak

unreferenced object 0xffff9a7d8a6d6f00 (size 96):
  comm "mount.zfs", pid 24858, jiffies 4299365401 (age 422.536s)
  hex dump (first 32 bytes):
    c0 fd 70 9b 7d 9a ff ff 00 f6 70 9b 7d 9a ff ff  ..p.}.....p.}...
    00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00  ................
  backtrace:
    [<ffffffff99c7028a>] kmemleak_alloc+0x7a/0x100
    [<ffffffff993158ec>] __kmalloc_node+0x26c/0x510
    [<ffffffffc09a29e6>] spl_kmem_zalloc+0x156/0x2a0 [spl]
    [<ffffffffc0c45169>] zfs_mntopts_alloc+0x29/0x40 [zfs]
    [<ffffffffc0c8114b>] zpl_mount+0x2b/0xb0 [zfs]
    [<ffffffff9935a4d8>] mount_fs+0x48/0x220
    [<ffffffff99387d47>] vfs_kern_mount+0x87/0x180
    [<ffffffff9938b281>] do_mount+0x281/0x1520
    [<ffffffff9938c9fd>] SyS_mount+0xdd/0x160
    [<ffffffff99c7ee76>] entry_SYSCALL_64_fastpath+0x1e/0xa8
    [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff9a7d9b70fdc0 (size 64):
  comm "mount.zfs", pid 24858, jiffies 4299365401 (age 422.536s)
  hex dump (first 32 bytes):
    74 65 73 74 70 6f 6f 6c 2e 31 33 36 32 2f 74 65  testpool.1362/te
    73 74 66 73 2e 31 33 36 32 2f 75 73 65 64 74 65  stfs.1362/usedte
  backtrace:
    [<ffffffff99c7028a>] kmemleak_alloc+0x7a/0x100
    [<ffffffff99314523>] __kmalloc+0x263/0x3e0
    [<ffffffffc09a2516>] strdup+0x56/0xb0 [spl]
    [<ffffffffc0c80bde>] zpl_parse_options+0x4e/0x590 [zfs]
    [<ffffffffc0c81166>] zpl_mount+0x46/0xb0 [zfs]
    [<ffffffff9935a4d8>] mount_fs+0x48/0x220
    [<ffffffff99387d47>] vfs_kern_mount+0x87/0x180
    [<ffffffff9938b281>] do_mount+0x281/0x1520
    [<ffffffff9938c9fd>] SyS_mount+0xdd/0x160
    [<ffffffff99c7ee76>] entry_SYSCALL_64_fastpath+0x1e/0xa8
    [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff9a7d9b70f600 (size 64):
  comm "mount.zfs", pid 24858, jiffies 4299365401 (age 422.616s)
  hex dump (first 32 bytes):
    2f 76 61 72 2f 74 6d 70 2f 74 65 73 74 64 69 72  /var/tmp/testdir
    31 33 36 32 2f 75 73 65 64 74 65 73 74 2d 73 6e  1362/usedtest-sn
  backtrace:
    [<ffffffff99c7028a>] kmemleak_alloc+0x7a/0x100
    [<ffffffff99314523>] __kmalloc+0x263/0x3e0
    [<ffffffff9962656c>] match_strdup+0x2c/0x80
    [<ffffffffc0c80c89>] zpl_parse_options+0xf9/0x590 [zfs]
    [<ffffffffc0c81166>] zpl_mount+0x46/0xb0 [zfs]
    [<ffffffff9935a4d8>] mount_fs+0x48/0x220
    [<ffffffff99387d47>] vfs_kern_mount+0x87/0x180
    [<ffffffff9938b281>] do_mount+0x281/0x1520
    [<ffffffff9938c9fd>] SyS_mount+0xdd/0x160
    [<ffffffff99c7ee76>] entry_SYSCALL_64_fastpath+0x1e/0xa8
    [<ffffffffffffffff>] 0xffffffffffffffff

@behlendorf behlendorf added the Component: Memory Management kernel memory management label Dec 15, 2016
@behlendorf behlendorf added this to the 0.7.0 milestone Dec 15, 2016
@behlendorf
Copy link
Contributor

The issue here appears to be if zfs_domount() fails early and it was passed a zfs_mntopts_t those mount options are never freed. We should update the code such that on error the zfs_domount() caller must free the mount options.

behlendorf pushed a commit to behlendorf/zfs that referenced this issue Feb 2, 2017
zfs_sb_create would normally takes ownership of zmo, and it will be freed in
zfs_sb_free. However, when zfs_sb_create fails we need to explicit free it.

Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: Chunwei Chen <[email protected]>
Closes openzfs#5490 
Closes openzfs#5496
behlendorf pushed a commit to behlendorf/zfs that referenced this issue Feb 2, 2017
zfs_sb_create would normally takes ownership of zmo, and it will be freed in
zfs_sb_free. However, when zfs_sb_create fails we need to explicit free it.

Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: Chunwei Chen <[email protected]>
Closes openzfs#5490
Closes openzfs#5496
Requires-builders: style
behlendorf pushed a commit that referenced this issue Feb 3, 2017
zfs_sb_create would normally takes ownership of zmo, and it will be freed in
zfs_sb_free. However, when zfs_sb_create fails we need to explicit free it.

Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: Chunwei Chen <[email protected]>
Closes #5490
Closes #5496
wli5 pushed a commit to wli5/zfs that referenced this issue Feb 28, 2017
zfs_sb_create would normally takes ownership of zmo, and it will be freed in
zfs_sb_free. However, when zfs_sb_create fails we need to explicit free it.

Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: Chunwei Chen <[email protected]>
Closes openzfs#5490 
Closes openzfs#5496
wli5 pushed a commit to wli5/zfs that referenced this issue Feb 28, 2017
zfs_sb_create would normally takes ownership of zmo, and it will be freed in
zfs_sb_free. However, when zfs_sb_create fails we need to explicit free it.

Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: Chunwei Chen <[email protected]>
Closes openzfs#5490
Closes openzfs#5496
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Memory Management kernel memory management
Projects
None yet
Development

No branches or pull requests

2 participants