From: "Toralf Förster" <toralf.foerster@gmx.de>
To: Dave Jones <davej@redhat.com>
Cc: trinity@vger.kernel.org
Subject: Re: is -1 really too "large" ?
Date: Mon, 21 Oct 2013 22:39:12 +0200 [thread overview]
Message-ID: <526590F0.6020101@gmx.de> (raw)
In-Reply-To: <20131021195210.GA28909@redhat.com>
On 10/21/2013 09:52 PM, Dave Jones wrote:
> On Mon, Oct 21, 2013 at 08:40:20PM +0200, Toralf Förster wrote:
> > got today :
> >
> > run trinity at Mon Oct 21 20:38:27 CEST 2013 28#-1 M=/mnt/nfsv4
> >
> > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs0000000000004924000000cb': Device or resource busy
> > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs0000000000003fdd000000a9': Device or resource busy
> > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs00000000000034230000007a': Device or resource busy
> > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs0000000000002d320000006b': Device or resource busy
> > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs0000000000001a7c00000035': Device or resource busy
> > rm: cannot remove '/mnt/nfsv4/victims/v1/v2/.nfs00000000000017600000002a': Device or resource busy
> > Trinity v1.3pre Dave Jones <davej@redhat.com>
> > Done parsing arguments.
> > Marking all syscalls as enabled.
> > [init] Enabled 351 syscalls. Disabled 0 syscalls.
> > [init] Using pid_max = 32768
> > [init] Started watchdog process, PID is 15311
> > [main] Main thread is alive.
> > [main] Generating file descriptors
> > [main] Something went wrong during nftw(/mnt/nfsv4/victims/v1/v2). (-1:Value too large for defined data type)
>
> So NFS returned -EOVERFLOW. Not sure why it would do that, but I'm goingto guess it
> came from nftw internally doing an lseek. lseek's man page suggests..
>
> EOVERFLOW
> The resulting file offset cannot be represented in an off_t.
>
> 64bit server and 32 bit client perhaps ?
>
I do only run 32 bit Gentoo Linux (both at host and as user mode linux client).
FWIW in this particular test case I run both an NFS service and a NFS client software at the same UML image do find a reliable rest case to reproduce this hang/cpu burner of one of the linux processes at the host :
tfoerste@n22 ~ $ sudo gdb /home/tfoerste/devel/linux/linux 23921 -n -batch -ex bt
0x08298edc in radix_tree_next_chunk (root=0x14, iter=0x46cc7c60, flags=12) at lib/radix-tree.c:770
770 if (node->slots[offset])
#0 0x08298edc in radix_tree_next_chunk (root=0x14, iter=0x46cc7c60, flags=12) at lib/radix-tree.c:770
#1 0x080cc11e in find_get_pages (mapping=0x46ef9b00, start=0, nr_pages=14, pages=0xc) at mm/filemap.c:844
#2 0x080d5c8a in pagevec_lookup (pvec=0x46cc7cc4, mapping=0x14, start=20, nr_pages=20) at mm/swap.c:914
#3 0x080d607a in truncate_inode_pages_range (mapping=0x46ef9b00, lstart=0, lend=-1) at mm/truncate.c:241
#4 0x080d641f in truncate_inode_pages (mapping=0x14, lstart=51539607572) at mm/truncate.c:358
#5 0x08260818 in hostfs_evict_inode (inode=0x46ef9a48) at fs/hostfs/hostfs_kern.c:242
#6 0x0811a8af in evict (inode=0x46ef9a48) at fs/inode.c:549
#7 0x0811b28d in iput_final (inode=<optimized out>) at fs/inode.c:1391
#8 iput (inode=0x46ef9a48) at fs/inode.c:1409
#9 0x08117628 in dentry_iput (dentry=<optimized out>) at fs/dcache.c:331
#10 d_kill (dentry=0x4915d6e0, parent=0x49171dc0) at fs/dcache.c:477
#11 0x08118048 in dentry_kill (dentry=<optimized out>, unlock_on_failure=<optimized out>) at fs/dcache.c:586
#12 dput (dentry=0x4915d6e0) at fs/dcache.c:641
#13 0x081048e3 in __fput (file=0x46cfe900) at fs/file_table.c:264
#14 0x0810494b in ____fput (work=0x46cfe900) 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=1213106688) 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=0x46f493d4) 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=0x46f493d4) at arch/um/os-Linux/skas/process.c:431
#24 0x0805f750 in fork_handler () at arch/um/kernel/process.c:160
#25 0x5a5a5a5a in ?? ()
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
prev parent reply other threads:[~2013-10-21 20:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 18:40 is -1 really too "large" ? Toralf Förster
2013-10-21 19:52 ` Dave Jones
2013-10-21 20:39 ` Toralf Förster [this message]
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=526590F0.6020101@gmx.de \
--to=toralf.foerster@gmx.de \
--cc=davej@redhat.com \
--cc=trinity@vger.kernel.org \
/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