Fix journal not being released during umounting

[RoyWFHuang]

Use kmemleak to detect, we get some leaking issues, it seems from journal system.

using page size: 4096
Tracing module memory allocs... Unload module (or hit Ctrl-C) to end
module 'simplefs' loaded
module 'simplefs' unloaded

3 stacks with outstanding allocations:
256 bytes in 1 allocations from stack
	addr = 0xffff9b6d373c9b00 size = 256
	  0 [<ffffffffa0a92e86>] kmem_cache_alloc_noprof+0x236
	  1 [<ffffffffa0a92e86>] kmem_cache_alloc_noprof+0x236
	  2 [<ffffffffa0b17359>] alloc_empty_file_noaccount+0x29
	  3 [<ffffffffa0b1747f>] alloc_file_pseudo_noaccount+0x9f
	  4 [<ffffffffa0dec7a1>] bdev_file_open_by_dev+0xb1
	  5 [<ffffffffc0fbf687>] simplefs_load_journal+0x57
	  6 [<ffffffffc0fbfde5>] simplefs_fill_super+0x455
	  7 [<ffffffffa0b1a239>] mount_bdev+0xf9
	  8 [<ffffffffc0fbf02b>] simplefs_mount+0x1b
	  9 [<ffffffffa0b7043b>] legacy_get_tree+0x2b
	 10 [<ffffffffa0b17a2a>] vfs_get_tree+0x2a
	 11 [<ffffffffa0b4e400>] do_new_mount+0x1a0
	 12 [<ffffffffa0b4f2bf>] path_mount+0x1df
	 13 [<ffffffffa0b4fa24>] __x64_sys_mount+0x124
	 14 [<ffffffffa060b8b6>] x64_sys_call+0x1ad6
	 15 [<ffffffffa189124e>] do_syscall_64+0x7e
	 16 [<ffffffffa1a0012b>] entry_SYSCALL_64_after_hwframe+0x76
192 bytes in 1 allocations from stack
	addr = 0xffff9b6e9d710540 size = 192
	  0 [<ffffffffa0a933c1>] kmem_cache_alloc_lru_noprof+0x241
	  1 [<ffffffffa0a933c1>] kmem_cache_alloc_lru_noprof+0x241
	  2 [<ffffffffa0b392d4>] __d_alloc+0x34
	  3 [<ffffffffa0b3c696>] d_alloc_pseudo+0x16
	  4 [<ffffffffa0b17447>] alloc_file_pseudo_noaccount+0x67
	  5 [<ffffffffa0dec7a1>] bdev_file_open_by_dev+0xb1
	  6 [<ffffffffc0fbf687>] simplefs_load_journal+0x57
	  7 [<ffffffffc0fbfde5>] simplefs_fill_super+0x455
	  8 [<ffffffffa0b1a239>] mount_bdev+0xf9
	  9 [<ffffffffc0fbf02b>] simplefs_mount+0x1b
	 10 [<ffffffffa0b7043b>] legacy_get_tree+0x2b
	 11 [<ffffffffa0b17a2a>] vfs_get_tree+0x2a
	 12 [<ffffffffa0b4e400>] do_new_mount+0x1a0
	 13 [<ffffffffa0b4f2bf>] path_mount+0x1df
	 14 [<ffffffffa0b4fa24>] __x64_sys_mount+0x124
	 15 [<ffffffffa060b8b6>] x64_sys_call+0x1ad6
	 16 [<ffffffffa189124e>] do_syscall_64+0x7e
	 17 [<ffffffffa1a0012b>] entry_SYSCALL_64_after_hwframe+0x76
32 bytes in 1 allocations from stack
	addr = 0xffff9b6cbc59a860 size = 32
	  0 [<ffffffffa0a92e86>] kmem_cache_alloc_noprof+0x236
	  1 [<ffffffffa0a92e86>] kmem_cache_alloc_noprof+0x236
	  2 [<ffffffffa0d18d3e>] security_file_alloc+0x2e
	  3 [<ffffffffa0b169b4>] init_file+0x34
	  4 [<ffffffffa0b1736f>] alloc_empty_file_noaccount+0x3f
	  5 [<ffffffffa0b1747f>] alloc_file_pseudo_noaccount+0x9f
	  6 [<ffffffffa0dec7a1>] bdev_file_open_by_dev+0xb1
	  7 [<ffffffffc0fbf687>] simplefs_load_journal+0x57
	  8 [<ffffffffc0fbfde5>] simplefs_fill_super+0x455
	  9 [<ffffffffa0b1a239>] mount_bdev+0xf9
	 10 [<ffffffffc0fbf02b>] simplefs_mount+0x1b
	 11 [<ffffffffa0b7043b>] legacy_get_tree+0x2b
	 12 [<ffffffffa0b17a2a>] vfs_get_tree+0x2a
	 13 [<ffffffffa0b4e400>] do_new_mount+0x1a0
	 14 [<ffffffffa0b4f2bf>] path_mount+0x1df
	 15 [<ffffffffa0b4fa24>] __x64_sys_mount+0x124
	 16 [<ffffffffa060b8b6>] x64_sys_call+0x1ad6
	 17 [<ffffffffa189124e>] do_syscall_64+0x7e
	 18 [<ffffffffa1a0012b>] entry_SYSCALL_64_after_hwframe+0x76

[jserv]

Thank @RoyWFHuang for contributing!