lkml.org 
[lkml]   [2014]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: f2fs: f2fs unmount hangs if f2fs_init_acl() fails during mkdir syscall
Hi,

06.02.2014 10:02, Jaegeuk Kim пишет:
> Hi,
>
> Thank you for the test and valuable report.
>
> This bug was fixed recently by:
>
> commit 03dea3129d558bf5293a6e9f12777176619ac876
> Author: Jaegeuk Kim <jaegeuk.kim@samsung.com>
> Date: Wed Feb 5 11:16:39 2014 +0900
>
> f2fs: fix to truncate dentry pages in the error case
Now remove_inode_page() succeed, but another assertion failed (tested on
revision e964751c):

[ 1272.747011] kernel BUG at fs/f2fs/inode.c:274!
[ 1272.747011] invalid opcode: 0000 [#1] SMP
[ 1272.747011] Modules linked in: f2fs kedr_fsim_indicator_common(OF)
kedr_fsim_indicator_capable(OF)
kedr_fsim_indicator_kmalloc(OF) kedr_fsim_vmm(OF) kedr_fsim_mem_util(OF)
kedr_fsim_capable(OF)
kedr_fsim_uaccess(OF) kedr_fsim_cmm(OF) kedr_fault_simulation(OF)
kedr(OF) fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntrack
ebtable_nat ebtable_broute bridge stp
llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6
nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security
iptable_raw parport_pc i2c_piix4 e1000
i2c_core microcode parport ata_generic pata_acpi [last unloaded: kedr]
[ 1272.747011] CPU: 0 PID: 14613 Comm: fs-driver-tests Tainted: GF
W O 3.14.0-rc1fs #1
[ 1272.747011] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[ 1272.747011] task: ffff88001e939190 ti: ffff88000d7ec000 task.ti:
ffff88000d7ec000
[ 1272.747011] RIP: 0010:[<ffffffffa01c74a8>] [<ffffffffa01c74a8>]
f2fs_evict_inode+0x178/0x180 [f2fs]
[ 1272.747011] RSP: 0018:ffff88000d7ede50 EFLAGS: 00010202
[ 1272.747011] RAX: 0000000000000001 RBX: ffff88000475cc30 RCX:
ffff88001e9398a0
[ 1272.747011] RDX: 0000000000000002 RSI: 0000000000000000 RDI:
ffff88000475ce10
[ 1272.747011] RBP: ffff88000d7ede68 R08: 00000000ffffffff R09:
0000000000000000
[ 1272.747011] R10: 0000000000000000 R11: 0000000000000001 R12:
ffff88000475cc30
[ 1272.747011] R13: ffff88000f147800 R14: ffffffffa01e7080 R15:
ffff88000f147b80
[ 1272.747011] FS: 00007f1795424740(0000) GS:ffff88003fc00000(0000)
knlGS:0000000000000000
[ 1272.747011] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1272.747011] CR2: 00007fc33bfa9000 CR3: 000000000f14e000 CR4:
00000000000006f0
[ 1272.747011] Stack:
[ 1272.747011] ffff88000475cc30 ffff88000475cdc8 ffffffffa01e7080
ffff88000d7ede90
[ 1272.747011] ffffffff811fde03 ffff88000475cc30 ffff88000475ccb8
ffff88000f147000
[ 1272.747011] ffff88000d7edec0 ffffffff811fe615 ffff88000475cc30
ffff88000f147800
[ 1272.747011] Call Trace:
[ 1272.747011] [<ffffffff811fde03>] evict+0xa3/0x1a0
[ 1272.747011] [<ffffffff811fe615>] iput+0xf5/0x180
[ 1272.747011] [<ffffffffa01c7f63>] f2fs_mkdir+0xf3/0x150 [f2fs]
[ 1272.747011] [<ffffffff811f2a77>] vfs_mkdir+0xb7/0x160
[ 1272.747011] [<ffffffff811f36bf>] SyS_mkdir+0x5f/0xc0
[ 1272.747011] [<ffffffff81680769>] system_call_fastpath+0x16/0x1b
[ 1272.747011] Code: 01 e1 4c 89 e7 e8 39 59 03 e1 5b 41 5c 41 5d 5d c3
31 c0 49 83 bc 24 c8 00 00 00 01 0f 97 c0
eb 8f 4c 89 e7 e8 fa ec ff ff eb 89 <0f> 0b 66 0f 1f 44 00 00 0f 1f 44
00 00 55 48 c7 c0 dc ff ff ff
[ 1272.747011] RIP [<ffffffffa01c74a8>] f2fs_evict_inode+0x178/0x180 [f2fs]
[ 1272.747011] RSP <ffff88000d7ede50>

Failed assertion claims that dirty dentries counter should be zero when
inode is deleted.
This counter is incremented by
mkdir()->
f2fs_add_link()->
init_inode_metadata()->
make_empty_dir()->
set_page_dirty();

but no one decrement it.
May be, this should be done along with truncating directory inode in
error-path of init_inode_metadata() ?


--
Best regards,
Andrey Tsyvarev
Linux Verification Center, ISPRAS
web: http://linuxtesting.org

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2014-02-06 13:41    [W:0.396 / U:2.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site