linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Toralf Förster" <toralf.foerster@gmx.de>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: 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>
Subject: Re: [uml-devel] fuzz tested 32 bit user mode linux image hangs at in histfs
Date: Tue, 22 Oct 2013 18:23:52 +0200	[thread overview]
Message-ID: <5266A698.10400@gmx.de> (raw)
In-Reply-To: <CAFLxGvy3NeRKu+KQCCm0j4LS60PYhH0bC8WWjfiPvpstPBjAkA@mail.gmail.com>

On 10/22/2013 06:12 PM, Richard Weinberger wrote:
> On Tue, Oct 22, 2013 at 5:16 PM, Toralf FA?rster <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 back 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=0x21, iter=0x47647c60, flags=12) at lib/radix-tree.c:769
>> 769                                     while (++offset < RADIX_TREE_MAP_SIZE) {
>> #0  radix_tree_next_chunk (root=0x21, iter=0x47647c60, flags=12) at lib/radix-tree.c:769
>> #1  0x080cc13e in find_get_pages (mapping=0x483ed240, start=0, nr_pages=14, pages=0xc) at mm/filemap.c:844
>> #2  0x080d5caa in pagevec_lookup (pvec=0x47647cc4, mapping=0x21, start=33, nr_pages=33) at mm/swap.c:914
>> #3  0x080d609a in truncate_inode_pages_range (mapping=0x483ed240, lstart=0, lend=-1) at mm/truncate.c:241
>> #4  0x080d643f in truncate_inode_pages (mapping=0x21, lstart=51539607585) at mm/truncate.c:358
>> #5  0x08260838 in hostfs_evict_inode (inode=0x483ed188) at fs/hostfs/hostfs_kern.c:242
>> #6  0x0811a8cf in evict (inode=0x483ed188) at fs/inode.c:549
>> #7  0x0811b2ad in iput_final (inode=<optimized out>) at fs/inode.c:1391
>> #8  iput (inode=0x483ed188) at fs/inode.c:1409
>> #9  0x08117648 in dentry_iput (dentry=<optimized out>) at fs/dcache.c:331
>> #10 d_kill (dentry=0x47d6d580, parent=0x47d95d10) at fs/dcache.c:477
>> #11 0x08118068 in dentry_kill (dentry=<optimized out>, unlock_on_failure=<optimized out>) at fs/dcache.c:586
>> #12 dput (dentry=0x47d6d580) at fs/dcache.c:641
>> #13 0x08104903 in __fput (file=0x47471840) at fs/file_table.c:264
>> #14 0x0810496b in ____fput (work=0x47471840) at fs/file_table.c:282
>> #15 0x08094496 in task_work_run () at kernel/task_work.c:123
>> #16 0x0807efd2 in exit_task_work (task=<optimized out>) at include/linux/task_work.h:21
>> #17 do_exit (code=1196535808) at kernel/exit.c:787
>> #18 0x0807f5dd in do_group_exit (exit_code=0) at kernel/exit.c:920
>> #19 0x0807f649 in SYSC_exit_group (error_code=<optimized out>) at kernel/exit.c:931
>> #20 SyS_exit_group (error_code=0) at kernel/exit.c:929
>> #21 0x08062984 in handle_syscall (r=0x4763b1d4) at arch/um/kernel/skas/syscall.c:35
>> #22 0x08074fb5 in handle_trap (local_using_sysemu=<optimized out>, regs=<optimized out>, pid=<optimized out>) at arch/um/os-Linux/skas/process.c:198
>> #23 userspace (regs=0x4763b1d4) 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 the
mean while I don't think so.


>> Last message of trinity's watchdog are :
>>
>> ...
>> [watchdog] exit_reason=2, but 2 children still running.
>> Bailing main loop. Exit reason: Reached maximum syscall count.
>> [watchdog] Reached limit 10001. Telling children to exit.
>> [watchdog] [1516] Watchdog exiting
>>
>>
>> I'm unsure if this is only UML specific, interesting for the fs people or mm or ... ?
>>
>>
>> --
>> MfG/Sincerely
>> Toralf FA?rster
>> pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> User-mode-linux-devel mailing list
>> User-mode-linux-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
> 
> 
> 


-- 
MfG/Sincerely
Toralf FA?rster
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=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2013-10-22 16:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 15:16 fuzz tested 32 bit user mode linux image hangs at in histfs Toralf Förster
2013-10-22 16:12 ` [uml-devel] " Richard Weinberger
2013-10-22 16:23   ` Toralf Förster [this message]
2013-10-22 17:29     ` Richard Weinberger
2013-10-29 17:39       ` [uml-devel] fuzz tested 32 bit user mode linux image hangs at in hostfs Toralf Förster
2013-10-30 19:15       ` [uml-devel] fuzz tested 32 bit user mode linux image hangs in radix_tree_next_chunk() Toralf Förster
2013-11-06 16:06         ` Konstantin Khlebnikov
2013-11-06 21:18           ` Toralf Förster
2013-11-06 21:31             ` Richard Weinberger
2013-11-09 19:07               ` Toralf Förster
2013-11-09 19:33                 ` Richard Weinberger
2013-11-10 15:14               ` Toralf Förster
2013-11-10 15:45                 ` Richard Weinberger
2013-11-17 15:03               ` Toralf Förster
2013-11-22 20:35               ` Toralf Förster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5266A698.10400@gmx.de \
    --to=toralf.foerster@gmx.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=richard.weinberger@gmail.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).