From: =?UTF-8?B?VG9yYWxmIEbDtnJzdGVy?= <toralf.foerster@gmx.de>
Subject: Re: [uml-devel] fuzz tested 32 bit user mode linux image hangs at
 in hostfs
Date: Tue, 29 Oct 2013 18:39:09 +0100
Message-ID: <526FF2BD.8030808@gmx.de>
References: <526696BF.6050909@gmx.de> <CAFLxGvy3NeRKu+KQCCm0j4LS60PYhH0bC8WWjfiPvpstPBjAkA@mail.gmail.com> <5266A698.10400@gmx.de> <5266B60A.1000005@nod.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
 Linux Kernel <linux-kernel@vger.kernel.org>,
 linux-fsdevel <linux-fsdevel@vger.kernel.org>,
 "linux-mm@kvack.org" <linux-mm@kvack.org>,
 UML devel <user-mode-linux-devel@lists.sourceforge.net>
To: Richard Weinberger <richard@nod.at>
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <5266B60A.1000005@nod.at>
Sender: owner-linux-mm@kvack.org
List-Id: linux-fsdevel.vger.kernel.org

On 10/22/2013 07:29 PM, Richard Weinberger wrote:
> Am 22.10.2013 18:23, schrieb Toralf F=C3=B6rster:
>> On 10/22/2013 06:12 PM, Richard Weinberger wrote:
>>> On Tue, Oct 22, 2013 at 5:16 PM, Toralf F=C3=B6rster <toralf.foerster=
@gmx.de> wrote:
>>>>
>>>> When I fuzz testing a 32 bit UML at a 32 bit host (guest 3.12.-rc6-x=
, host 3.11.6) with trinity
>>>> and use hostfs for the victom files for trinity. then trintiy often =
hangs while trying to finish.
>>>>
>>>> At the host I do have 1 process eating 100% CPU power of 1 core. A b=
ack trace of thet linux process at the hosts gives :
>>>>
>>>> tfoerste@n22 ~ $ sudo gdb /usr/local/bin/linux-v3.12-rc6-57-g69c88dc=
 16749 -n -batch -ex bt
>>>> radix_tree_next_chunk (root=3D0x21, iter=3D0x47647c60, flags=3D12) a=
t lib/radix-tree.c:769
>>>> 769                                     while (++offset < RADIX_TREE=
_MAP_SIZE) {
>>>> #0  radix_tree_next_chunk (root=3D0x21, iter=3D0x47647c60, flags=3D1=
2) at lib/radix-tree.c:769
>>>> #1  0x080cc13e in find_get_pages (mapping=3D0x483ed240, start=3D0, n=
r_pages=3D14, pages=3D0xc) at mm/filemap.c:844
>>>> #2  0x080d5caa in pagevec_lookup (pvec=3D0x47647cc4, mapping=3D0x21,=
 start=3D33, nr_pages=3D33) at mm/swap.c:914
>>>> #3  0x080d609a in truncate_inode_pages_range (mapping=3D0x483ed240, =
lstart=3D0, lend=3D-1) at mm/truncate.c:241
>>>> #4  0x080d643f in truncate_inode_pages (mapping=3D0x21, lstart=3D515=
39607585) at mm/truncate.c:358
>>>> #5  0x08260838 in hostfs_evict_inode (inode=3D0x483ed188) at fs/host=
fs/hostfs_kern.c:242
>>>> #6  0x0811a8cf in evict (inode=3D0x483ed188) at fs/inode.c:549
>>>> #7  0x0811b2ad in iput_final (inode=3D<optimized out>) at fs/inode.c=
:1391
>>>> #8  iput (inode=3D0x483ed188) at fs/inode.c:1409
>>>> #9  0x08117648 in dentry_iput (dentry=3D<optimized out>) at fs/dcach=
e.c:331
>>>> #10 d_kill (dentry=3D0x47d6d580, parent=3D0x47d95d10) at fs/dcache.c=
:477
>>>> #11 0x08118068 in dentry_kill (dentry=3D<optimized out>, unlock_on_f=
ailure=3D<optimized out>) at fs/dcache.c:586
>>>> #12 dput (dentry=3D0x47d6d580) at fs/dcache.c:641
>>>> #13 0x08104903 in __fput (file=3D0x47471840) at fs/file_table.c:264
>>>> #14 0x0810496b in ____fput (work=3D0x47471840) at fs/file_table.c:28=
2
>>>> #15 0x08094496 in task_work_run () at kernel/task_work.c:123
>>>> #16 0x0807efd2 in exit_task_work (task=3D<optimized out>) at include=
/linux/task_work.h:21
>>>> #17 do_exit (code=3D1196535808) at kernel/exit.c:787
>>>> #18 0x0807f5dd in do_group_exit (exit_code=3D0) at kernel/exit.c:920
>>>> #19 0x0807f649 in SYSC_exit_group (error_code=3D<optimized out>) at =
kernel/exit.c:931
>>>> #20 SyS_exit_group (error_code=3D0) at kernel/exit.c:929
>>>> #21 0x08062984 in handle_syscall (r=3D0x4763b1d4) at arch/um/kernel/=
skas/syscall.c:35
>>>> #22 0x08074fb5 in handle_trap (local_using_sysemu=3D<optimized out>,=
 regs=3D<optimized out>, pid=3D<optimized out>) at arch/um/os-Linux/skas/=
process.c:198
>>>> #23 userspace (regs=3D0x4763b1d4) at arch/um/os-Linux/skas/process.c=
:431
>>>> #24 0x0805f750 in fork_handler () at arch/um/kernel/process.c:160
>>>> #25 0x00000000 in ?? ()
>>>>
>>>
>>> That trace is identical to the one you reported yesterday.
>>> But this time no nfs is in the game, right?
>>>
>>
>> Right - I could narrow down it in the meanwhile to hostfs only. First =
I
>> argued if NFS sometimes might force the issue to happen later but in t=
he
>> mean while I don't think so.
>=20
> It looks like we never find a way out of the while(1) in
> radix_tree_next_chunk().
>=20
> Thanks,
> //richard
>=20

But today I found a proof that it is not only fs/hostfs specific :


tfoerste@n22 ~ $ sudo gdb /home/tfoerste/devel/linux/linux 22692 -n -batc=
h -ex bt
0x08298fcc in radix_tree_next_chunk (root=3D0x25, iter=3D0x3ba6fc4c, flag=
s=3D6) at lib/radix-tree.c:770
770                                             if (node->slots[offset])
#0  0x08298fcc in radix_tree_next_chunk (root=3D0x25, iter=3D0x3ba6fc4c, =
flags=3D6) at lib/radix-tree.c:770
#1  0x080cc20e in find_get_pages (mapping=3D0x3b0d61dc, start=3D0, nr_pag=
es=3D14, pages=3D0x6) at mm/filemap.c:844
#2  0x080d5d7a in pagevec_lookup (pvec=3D0x3ba6fcb0, mapping=3D0x25, star=
t=3D37, nr_pages=3D37) at mm/swap.c:914
#3  0x080d616a in truncate_inode_pages_range (mapping=3D0x3b0d61dc, lstar=
t=3D0, lend=3D-1) at mm/truncate.c:241
#4  0x080d650f in truncate_inode_pages (mapping=3D0x25, lstart=3D25769803=
813) at mm/truncate.c:358
#5  0x08205b08 in nfs4_evict_inode (inode=3D0x3b0d6124) at fs/nfs/nfs4sup=
er.c:101
#6  0x0811a99f in evict (inode=3D0x3b0d6124) at fs/inode.c:549
#7  0x0811b37d in iput_final (inode=3D<optimized out>) at fs/inode.c:1391
#8  iput (inode=3D0x3b0d6124) at fs/inode.c:1409
#9  0x081d6014 in nfs_dentry_iput (dentry=3D0x6, inode=3D0x3b0d6124) at f=
s/nfs/dir.c:1255
#10 0x08117705 in dentry_iput (dentry=3D<optimized out>) at fs/dcache.c:3=
29
#11 d_kill (dentry=3D0x4508a000, parent=3D0x47adf790) at fs/dcache.c:477
#12 0x08118138 in dentry_kill (dentry=3D<optimized out>, unlock_on_failur=
e=3D<optimized out>) at fs/dcache.c:586
#13 dput (dentry=3D0x4508a000) at fs/dcache.c:641
#14 0x081049d3 in __fput (file=3D0x3baf3000) at fs/file_table.c:264
#15 0x08104a3b in ____fput (work=3D0x3baf3000) at fs/file_table.c:282
#16 0x08094496 in task_work_run () at kernel/task_work.c:123
#17 0x0807efd2 in exit_task_work (task=3D<optimized out>) at include/linu=
x/task_work.h:21
#18 do_exit (code=3D1167823872) at kernel/exit.c:787
#19 0x0807f5dd in do_group_exit (exit_code=3D0) at kernel/exit.c:920
#20 0x0807f649 in SYSC_exit_group (error_code=3D<optimized out>) at kerne=
l/exit.c:931
#21 SyS_exit_group (error_code=3D0) at kernel/exit.c:929
#22 0x08062984 in handle_syscall (r=3D0x459741d4) at arch/um/kernel/skas/=
syscall.c:35
#23 0x08074fb5 in handle_trap (local_using_sysemu=3D<optimized out>, regs=
=3D<optimized out>, pid=3D<optimized out>) at arch/um/os-Linux/skas/proce=
ss.c:198
#24 userspace (regs=3D0x459741d4) at arch/um/os-Linux/skas/process.c:431
#25 0x0805f750 in fork_handler () at arch/um/kernel/process.c:160
#26 0x00000000 in ?? ()


But it happened rarely and I did not found a scenario to easily reproduce=
 it till now.

--=20
MfG/Sincerely
Toralf F=C3=B6rster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=3Dmailto:"dont@kvack.org"> email@kvack.org </a>