Hi Andrey,
On 02/11/2014 04:29 PM, Andrey Tsyvarev wrote:
> Hi,
>
>> It turns out that make_bad_inode prior to iput sets i_mode to a regular
>> file, so that f2fs_evict_inode -> truncate_inode_pages ->
>> f2fs_invalidate_data_page doesn't decrement dirty_dents.
>>
> It seems that remove_dirty_dir_inode() call should also be added to the
> error-path of
> init_inode_metadata, because its functionality is also based on inode->i_mode
> field
> which is changed by make_bad_inode().
It seems that your opinion is correct. remove_dirty_dir_inode() will not clean
up the
dir_inode_entry because make_bad_inode() sets i_mode to S_IFREG in the fail
path of
init_inode_metadata, and it leads to the following "memory leak".
BTW, have you tested the case that added remove_dirty_dir_inode() into the fail
path
of init_inode_metadata?
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index e095a4f..d5a2c9e 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -375,6 +375,7 @@ put_error:
/* once the failed inode becomes a bad inode, i_mode is S_IFREG */
truncate_inode_pages(&inode->i_data, 0);
truncate_blocks(inode, 0);
+ remove_dirty_dir_inode(inode);
error:
remove_inode_page(inode);
return ERR_PTR(err);
Regards,
Gu
>
> Otherwise memory leak is reported when f2fs module is unloaded:
>
> [ 231.378192] BUG f2fs_dirty_dir_entry (Tainted: GF O): Objects
> remaining in f2fs_dirty_dir_entry on kmem_cache_close()
> [ 231.378193]
> -----------------------------------------------------------------------------
>
> [ 231.378194] Disabling lock debugging due to kernel taint
> [ 231.378195] INFO: Slab 0xffffea0000437200 objects=102 used=1
> fp=0xffff880010dc8fc8 flags=0x3fffc000000080
> [ 231.378197] CPU: 0 PID: 2605 Comm: rmmod Tainted: GF B O
> 3.14.0-rc1fs #4
> [ 231.378198] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
> VirtualBox 12/01/2006
> [ 231.378199] ffff88000e5e3200 ffff88000cc9bd40 ffffffff8166fd7e
> ffffea0000437200
> [ 231.378202] ffff88000cc9be28 ffffffff811c3fdf ffff88003fc10066
> ffffffff0cc9bda0
> [ 231.378203] ffffffff00000020 ffff88000cc9be38 ffff88000cc9bde0
> 656a624f00000296
> [ 231.378205] Call Trace:
> [ 231.378210] [<ffffffff8166fd7e>] dump_stack+0x45/0x56
> [ 231.378213] [<ffffffff811c3fdf>] slab_err+0xaf/0xc0
> [ 231.378215] [<ffffffff811c84a3>] ? kmem_cache_close+0x133/0x340
> [ 231.378216] [<ffffffff811c6b55>] ? __kmalloc+0x1f5/0x250
> [ 231.378218] [<ffffffff811c84c3>] kmem_cache_close+0x153/0x340
> [ 231.378221] [<ffffffff81193417>] ? kmem_cache_destroy+0x27/0xf0
> [ 231.378223] [<ffffffff811c86c4>] __kmem_cache_shutdown+0x14/0x80
> [ 231.378224] [<ffffffff81193431>] kmem_cache_destroy+0x41/0xf0
> [ 231.378229] [<ffffffffa01eab91>] destroy_checkpoint_caches+0x21/0x30
> [f2fs]
> [ 231.378232] [<ffffffffa01facda>] exit_f2fs_fs+0x28/0x34e [f2fs]
> [ 231.378235] [<ffffffff810ffe32>] SyS_delete_module+0x152/0x1f0
> [ 231.378237] [<ffffffff8111d85c>] ? __audit_syscall_entry+0x9c/0xf0
> [ 231.378239] [<ffffffff81680729>] system_call_fastpath+0x16/0x1b
> [ 231.378242] INFO: Object 0xffff880010dc8000 @offset=0
> [ 231.378245] kmem_cache_destroy f2fs_dirty_dir_entry: Slab cache still has
> objects
> [ 231.378247] CPU: 0 PID: 2605 Comm: rmmod Tainted: GF B O
> 3.14.0-rc1fs #4
> [ 231.378247] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
> VirtualBox 12/01/2006
> [ 231.378248] ffff88000e5e3268 ffff88000cc9beb8 ffffffff8166fd7e
> ffff88000e5e3200
> [ 231.378250] ffff88000cc9bed8 ffffffff811934cf 0000000000000000
> ffffffffa0204f60
> [ 231.378251] ffff88000cc9bee8 ffffffffa01eab91 ffff88000cc9bef8
> ffffffffa01facda
> [ 231.378253] Call Trace:
> [ 231.378255] [<ffffffff8166fd7e>] dump_stack+0x45/0x56
> [ 231.378256] [<ffffffff811934cf>] kmem_cache_destroy+0xdf/0xf0
> [ 231.378259] [<ffffffffa01eab91>] destroy_checkpoint_caches+0x21/0x30
> [f2fs]
> [ 231.378262] [<ffffffffa01facda>] exit_f2fs_fs+0x28/0x34e [f2fs]
> [ 231.378263] [<ffffffff810ffe32>] SyS_delete_module+0x152/0x1f0
> [ 231.378265] [<ffffffff8111d85c>] ? __audit_syscall_entry+0x9c/0xf0
> [ 231.378266] [<ffffffff81680729>] system_call_fastpath+0x16/0x1b
>
>
> Stack of allocation (obtained with KEDR, which is also used for fault
> simulation):
>
> [ 231.414875] [leak_check] Address: 0xffff880010dc8000, size: 24; stack
> trace of the allocation:
> [ 231.414886] [leak_check] [<ffffffffa01e9d72>] set_dirty_dir_page+0x62/0xe0
> [f2fs]
> [ 231.414893] [leak_check] [<ffffffffa01ec9be>]
> f2fs_set_data_page_dirty+0x4e/0x90 [f2fs]
> [ 231.414898] [leak_check] [<ffffffff8117b02a>] set_page_dirty+0x3a/0x60
> [ 231.414904] [leak_check] [<ffffffffa01dfeb2>] __f2fs_add_link+0x732/0x7d0
> [f2fs]
> [ 231.414909] [leak_check] [<ffffffffa01e2f1b>] f2fs_mkdir+0xbb/0x150 [f2fs]
> [ 231.414914] [leak_check] [<ffffffff811f2a37>] vfs_mkdir+0xb7/0x160
> [ 231.414918] [leak_check] [<ffffffff811f367f>] SyS_mkdir+0x5f/0xc0
> [ 231.414923] [leak_check] [<ffffffff81680729>]
> system_call_fastpath+0x16/0x1b
> [ 231.414931] [leak_check] [<ffffffffffffffff>] 0xffffffffffffffff
>
>
> P.S. It was required to add 'slub_debug' kernel options for make SLUB output
> correct cache name,
> otherwise cache "f2fs_dirty_dir_entry" was merged into "free_nid" one. It was
> surprise for me,
> that's why patch investigation took so long time.
>
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
