All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toralf Förster" <toralf.foerster-Mmb7MZpHnFY@public.gmane.org>
To: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
Cc: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
	Linux NFS mailing list
	<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"user-mode-linux-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"
	<user-mode-linux-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux Kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"J. Bruce Fields"
	<bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: Issues with a rather unusual configured NFS server
Date: Tue, 10 Sep 2013 17:51:08 +0200	[thread overview]
Message-ID: <522F3FEC.7080406@gmx.de> (raw)
In-Reply-To: <20130910140937.GD16011-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>

On 09/10/2013 04:09 PM, J. Bruce Fields wrote:
> On Sat, Sep 07, 2013 at 10:44:00PM +0200, Toralf Förster wrote:
>> Today I run latest git tree with a patched UML (this patch + one for xterm issues) and got 2 times a core dump
>> when I fuzzy test an UML machine with a nearly identical scenario as already described but just shutdowned
>> both UML images instead of shooting one of it in the head.
> 
> This is a slightly different test case, so for now it sounds like this
> could be a preexisting problem, not a regression?
> 
> --b.

If I found a test case I'll bisect it - but currently it does no longer
happen during normal operations w/ current git.#

(
Well, if I kill the NFS client during shutdown, then I get often a core
dump with the mentioned back trace but I think this doesn't count :-D
)

>>
>> I'll probably need time to figure out a test case, but just as a pre-info here's the back trace:
>>
>> tfoerste@n22 ~ $ gdb --core=/mnt/ramdisk/core /usr/local/bin/linux-v3.11-7550-g768c9d3 -n -batch -ex bt
>>
>> warning: core file may not match specified executable file.
>> [New LWP 7470]
>> [New LWP 7479]
>> [New LWP 7477]
>> [New LWP 7478]
>> Core was generated by `/usr/local/bin/linux-v3.11-7550-g768c9d3 earlyprintk ubda=/home/tfoerste/virtua'.
>> Program terminated with signal 6, Aborted.
>> #0  0xb77be424 in __kernel_vsyscall ()
>> #0  0xb77be424 in __kernel_vsyscall ()
>> #1  0x083aada5 in kill ()
>> #2  0x0807163d in uml_abort () at arch/um/os-Linux/util.c:93
>> #3  0x08071925 in os_dump_core () at arch/um/os-Linux/util.c:138
>> #4  0x080613a7 in panic_exit (self=0x85b1518 <panic_exit_notifier>, unused1=0, unused2=0x85e76e0 <buf.15920>) at arch/um/kernel/um_arch.c:240
>> #5  0x0809a398 in notifier_call_chain (nl=0x0, val=0, v=0x85e76e0 <buf.15920>, nr_to_call=-2, nr_calls=0x0) at kernel/notifier.c:93
>> #6  0x0809a4e3 in __atomic_notifier_call_chain (nr_calls=<optimized out>, nr_to_call=<optimized out>, v=<optimized out>, val=<optimized out>, nh=<optimized out>) at kernel/notifier.c:182
>> #7  atomic_notifier_call_chain (nh=0x85e76c4 <panic_notifier_list>, val=0, v=0x85e76e0 <buf.15920>) at kernel/notifier.c:191
>> #8  0x08408628 in panic (fmt=0x0) at kernel/panic.c:128
>> #9  0x081131c9 in shrink_dcache_for_umount_subtree (dentry=0x428028f0) at fs/dcache.c:941
>> #10 0x08113948 in shrink_dcache_for_umount (sb=0x463b8000) at fs/dcache.c:1002
>> #11 0x08101677 in generic_shutdown_super (sb=0x463b8000) at fs/super.c:404
>> #12 0x08102395 in kill_anon_super (sb=0x0) at fs/super.c:875
>> #13 0x081d3ff8 in nfs_kill_super (s=0x0) at fs/nfs/super.c:2598
>> #14 0x0810153a in deactivate_locked_super (s=0x463b8000) at fs/super.c:294
>> #15 0x081015d1 in deactivate_super (s=0x463b8000) at fs/super.c:319
>> #16 0x08119c0c in mntfree (mnt=<optimized out>) at fs/namespace.c:891
>> #17 mntput_no_expire (mnt=0x0) at fs/namespace.c:929
>> #18 0x0811b195 in SYSC_umount (flags=<optimized out>, name=<optimized out>) at fs/namespace.c:1335
>> #19 SyS_umount (name=134633856, flags=2) at fs/namespace.c:1305
>> #20 0x080618e2 in handle_syscall (r=0x498be5d4) at arch/um/kernel/skas/syscall.c:35
>> #21 0x08073c0d in handle_trap (local_using_sysemu=<optimized out>, regs=<optimized out>, pid=<optimized out>) at arch/um/os-Linux/skas/process.c:198
>> #22 userspace (regs=0x498be5d4) at arch/um/os-Linux/skas/process.c:431
>> #23 0x0805e65c in fork_handler () at arch/um/kernel/process.c:160
>> #24 0x00000000 in ?? ()
>>
>>
>>
>> -- 
>> MfG/Sincerely
>> Toralf Förster
>> pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
> 


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Toralf Förster" <toralf.foerster@gmx.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jan Kara <jack@suse.cz>,
	Linux NFS mailing list <linux-nfs@vger.kernel.org>,
	"user-mode-linux-devel@lists.sourceforge.net"
	<user-mode-linux-devel@lists.sourceforge.net>,
	linux-ext4@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@redhat.com>
Subject: Re: Issues with a rather unusual configured NFS server
Date: Tue, 10 Sep 2013 17:51:08 +0200	[thread overview]
Message-ID: <522F3FEC.7080406@gmx.de> (raw)
In-Reply-To: <20130910140937.GD16011@fieldses.org>

On 09/10/2013 04:09 PM, J. Bruce Fields wrote:
> On Sat, Sep 07, 2013 at 10:44:00PM +0200, Toralf Förster wrote:
>> Today I run latest git tree with a patched UML (this patch + one for xterm issues) and got 2 times a core dump
>> when I fuzzy test an UML machine with a nearly identical scenario as already described but just shutdowned
>> both UML images instead of shooting one of it in the head.
> 
> This is a slightly different test case, so for now it sounds like this
> could be a preexisting problem, not a regression?
> 
> --b.

If I found a test case I'll bisect it - but currently it does no longer
happen during normal operations w/ current git.#

(
Well, if I kill the NFS client during shutdown, then I get often a core
dump with the mentioned back trace but I think this doesn't count :-D
)

>>
>> I'll probably need time to figure out a test case, but just as a pre-info here's the back trace:
>>
>> tfoerste@n22 ~ $ gdb --core=/mnt/ramdisk/core /usr/local/bin/linux-v3.11-7550-g768c9d3 -n -batch -ex bt
>>
>> warning: core file may not match specified executable file.
>> [New LWP 7470]
>> [New LWP 7479]
>> [New LWP 7477]
>> [New LWP 7478]
>> Core was generated by `/usr/local/bin/linux-v3.11-7550-g768c9d3 earlyprintk ubda=/home/tfoerste/virtua'.
>> Program terminated with signal 6, Aborted.
>> #0  0xb77be424 in __kernel_vsyscall ()
>> #0  0xb77be424 in __kernel_vsyscall ()
>> #1  0x083aada5 in kill ()
>> #2  0x0807163d in uml_abort () at arch/um/os-Linux/util.c:93
>> #3  0x08071925 in os_dump_core () at arch/um/os-Linux/util.c:138
>> #4  0x080613a7 in panic_exit (self=0x85b1518 <panic_exit_notifier>, unused1=0, unused2=0x85e76e0 <buf.15920>) at arch/um/kernel/um_arch.c:240
>> #5  0x0809a398 in notifier_call_chain (nl=0x0, val=0, v=0x85e76e0 <buf.15920>, nr_to_call=-2, nr_calls=0x0) at kernel/notifier.c:93
>> #6  0x0809a4e3 in __atomic_notifier_call_chain (nr_calls=<optimized out>, nr_to_call=<optimized out>, v=<optimized out>, val=<optimized out>, nh=<optimized out>) at kernel/notifier.c:182
>> #7  atomic_notifier_call_chain (nh=0x85e76c4 <panic_notifier_list>, val=0, v=0x85e76e0 <buf.15920>) at kernel/notifier.c:191
>> #8  0x08408628 in panic (fmt=0x0) at kernel/panic.c:128
>> #9  0x081131c9 in shrink_dcache_for_umount_subtree (dentry=0x428028f0) at fs/dcache.c:941
>> #10 0x08113948 in shrink_dcache_for_umount (sb=0x463b8000) at fs/dcache.c:1002
>> #11 0x08101677 in generic_shutdown_super (sb=0x463b8000) at fs/super.c:404
>> #12 0x08102395 in kill_anon_super (sb=0x0) at fs/super.c:875
>> #13 0x081d3ff8 in nfs_kill_super (s=0x0) at fs/nfs/super.c:2598
>> #14 0x0810153a in deactivate_locked_super (s=0x463b8000) at fs/super.c:294
>> #15 0x081015d1 in deactivate_super (s=0x463b8000) at fs/super.c:319
>> #16 0x08119c0c in mntfree (mnt=<optimized out>) at fs/namespace.c:891
>> #17 mntput_no_expire (mnt=0x0) at fs/namespace.c:929
>> #18 0x0811b195 in SYSC_umount (flags=<optimized out>, name=<optimized out>) at fs/namespace.c:1335
>> #19 SyS_umount (name=134633856, flags=2) at fs/namespace.c:1305
>> #20 0x080618e2 in handle_syscall (r=0x498be5d4) at arch/um/kernel/skas/syscall.c:35
>> #21 0x08073c0d in handle_trap (local_using_sysemu=<optimized out>, regs=<optimized out>, pid=<optimized out>) at arch/um/os-Linux/skas/process.c:198
>> #22 userspace (regs=0x498be5d4) at arch/um/os-Linux/skas/process.c:431
>> #23 0x0805e65c in fork_handler () at arch/um/kernel/process.c:160
>> #24 0x00000000 in ?? ()
>>
>>
>>
>> -- 
>> MfG/Sincerely
>> Toralf Förster
>> pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
> 


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

WARNING: multiple messages have this Message-ID (diff)
From: "Toralf Förster" <toralf.foerster@gmx.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jan Kara <jack@suse.cz>,
	Linux NFS mailing list <linux-nfs@vger.kernel.org>,
	"user-mode-linux-devel@lists.sourceforge.net"
	<user-mode-linux-devel@lists.sourceforge.net>,
	linux-ext4@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@redhat.com>
Subject: Re: Issues with a rather unusual configured NFS server
Date: Tue, 10 Sep 2013 17:51:08 +0200	[thread overview]
Message-ID: <522F3FEC.7080406@gmx.de> (raw)
In-Reply-To: <20130910140937.GD16011@fieldses.org>

On 09/10/2013 04:09 PM, J. Bruce Fields wrote:
> On Sat, Sep 07, 2013 at 10:44:00PM +0200, Toralf Förster wrote:
>> Today I run latest git tree with a patched UML (this patch + one for xterm issues) and got 2 times a core dump
>> when I fuzzy test an UML machine with a nearly identical scenario as already described but just shutdowned
>> both UML images instead of shooting one of it in the head.
> 
> This is a slightly different test case, so for now it sounds like this
> could be a preexisting problem, not a regression?
> 
> --b.

If I found a test case I'll bisect it - but currently it does no longer
happen during normal operations w/ current git.#

(
Well, if I kill the NFS client during shutdown, then I get often a core
dump with the mentioned back trace but I think this doesn't count :-D
)

>>
>> I'll probably need time to figure out a test case, but just as a pre-info here's the back trace:
>>
>> tfoerste@n22 ~ $ gdb --core=/mnt/ramdisk/core /usr/local/bin/linux-v3.11-7550-g768c9d3 -n -batch -ex bt
>>
>> warning: core file may not match specified executable file.
>> [New LWP 7470]
>> [New LWP 7479]
>> [New LWP 7477]
>> [New LWP 7478]
>> Core was generated by `/usr/local/bin/linux-v3.11-7550-g768c9d3 earlyprintk ubda=/home/tfoerste/virtua'.
>> Program terminated with signal 6, Aborted.
>> #0  0xb77be424 in __kernel_vsyscall ()
>> #0  0xb77be424 in __kernel_vsyscall ()
>> #1  0x083aada5 in kill ()
>> #2  0x0807163d in uml_abort () at arch/um/os-Linux/util.c:93
>> #3  0x08071925 in os_dump_core () at arch/um/os-Linux/util.c:138
>> #4  0x080613a7 in panic_exit (self=0x85b1518 <panic_exit_notifier>, unused1=0, unused2=0x85e76e0 <buf.15920>) at arch/um/kernel/um_arch.c:240
>> #5  0x0809a398 in notifier_call_chain (nl=0x0, val=0, v=0x85e76e0 <buf.15920>, nr_to_call=-2, nr_calls=0x0) at kernel/notifier.c:93
>> #6  0x0809a4e3 in __atomic_notifier_call_chain (nr_calls=<optimized out>, nr_to_call=<optimized out>, v=<optimized out>, val=<optimized out>, nh=<optimized out>) at kernel/notifier.c:182
>> #7  atomic_notifier_call_chain (nh=0x85e76c4 <panic_notifier_list>, val=0, v=0x85e76e0 <buf.15920>) at kernel/notifier.c:191
>> #8  0x08408628 in panic (fmt=0x0) at kernel/panic.c:128
>> #9  0x081131c9 in shrink_dcache_for_umount_subtree (dentry=0x428028f0) at fs/dcache.c:941
>> #10 0x08113948 in shrink_dcache_for_umount (sb=0x463b8000) at fs/dcache.c:1002
>> #11 0x08101677 in generic_shutdown_super (sb=0x463b8000) at fs/super.c:404
>> #12 0x08102395 in kill_anon_super (sb=0x0) at fs/super.c:875
>> #13 0x081d3ff8 in nfs_kill_super (s=0x0) at fs/nfs/super.c:2598
>> #14 0x0810153a in deactivate_locked_super (s=0x463b8000) at fs/super.c:294
>> #15 0x081015d1 in deactivate_super (s=0x463b8000) at fs/super.c:319
>> #16 0x08119c0c in mntfree (mnt=<optimized out>) at fs/namespace.c:891
>> #17 mntput_no_expire (mnt=0x0) at fs/namespace.c:929
>> #18 0x0811b195 in SYSC_umount (flags=<optimized out>, name=<optimized out>) at fs/namespace.c:1335
>> #19 SyS_umount (name=134633856, flags=2) at fs/namespace.c:1305
>> #20 0x080618e2 in handle_syscall (r=0x498be5d4) at arch/um/kernel/skas/syscall.c:35
>> #21 0x08073c0d in handle_trap (local_using_sysemu=<optimized out>, regs=<optimized out>, pid=<optimized out>) at arch/um/os-Linux/skas/process.c:198
>> #22 userspace (regs=0x498be5d4) at arch/um/os-Linux/skas/process.c:431
>> #23 0x0805e65c in fork_handler () at arch/um/kernel/process.c:160
>> #24 0x00000000 in ?? ()
>>
>>
>>
>> -- 
>> MfG/Sincerely
>> Toralf Förster
>> pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
> 


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
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/


  parent reply	other threads:[~2013-09-10 15:51 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-11  9:48 Issues with a rather unusual configured NFS server Toralf Förster
2013-08-11  9:48 ` [uml-devel] " Toralf Förster
2013-08-11  9:48 ` Toralf Förster
     [not found] ` <52075E01.7030506-Mmb7MZpHnFY@public.gmane.org>
2013-08-12 14:36   ` Jan Kara
2013-08-12 14:36     ` Jan Kara
2013-08-12 14:36     ` Jan Kara
2013-08-13 21:53     ` J. Bruce Fields
2013-08-13 21:53       ` J. Bruce Fields
2013-08-14 16:44       ` Toralf Förster
2013-08-14 16:44         ` Toralf Förster
2013-08-27 18:06       ` J. Bruce Fields
2013-08-27 18:06         ` J. Bruce Fields
2013-08-27 18:06         ` J. Bruce Fields
2013-08-28 17:21         ` Toralf Förster
2013-08-28 17:21           ` Toralf Förster
2013-08-29  9:57           ` [uml-devel] " richard -rw- weinberger
2013-08-29  9:57             ` richard -rw- weinberger
2013-08-29 13:30             ` J. Bruce Fields
2013-08-29 13:30               ` J. Bruce Fields
     [not found]               ` <20130829133010.GA14773-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2013-08-30 14:10                 ` Toralf Förster
2013-08-30 14:10                   ` Toralf Förster
2013-08-30 14:10                   ` Toralf Förster
2013-08-30 14:25                   ` J. Bruce Fields
2013-08-30 14:25                     ` J. Bruce Fields
2013-08-30 14:36                   ` Richard Weinberger
2013-08-30 14:36                     ` Richard Weinberger
2013-09-01 16:09                     ` Toralf Förster
2013-09-01 21:15                       ` Richard Weinberger
2013-09-02 16:53                         ` Toralf Förster
2013-09-02 16:56                           ` Richard Weinberger
     [not found]             ` <CAFLxGvyK5+nB9TgW1uPho9KGwQrWQHx=wEpj+o-mZcN92bWAOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-30 18:27               ` Michael Richardson
2013-08-30 18:27                 ` Michael Richardson
2013-09-07 20:44           ` Toralf Förster
2013-09-07 20:44             ` Toralf Förster
2013-09-07 20:44             ` Toralf Förster
     [not found]             ` <522B9010.8070902-Mmb7MZpHnFY@public.gmane.org>
2013-09-07 20:51               ` [uml-devel] " richard -rw- weinberger
2013-09-07 20:51                 ` richard -rw- weinberger
2013-09-07 20:51                 ` richard -rw- weinberger
2013-09-10 14:09               ` J. Bruce Fields
2013-09-10 14:09                 ` J. Bruce Fields
2013-09-10 14:09                 ` J. Bruce Fields
     [not found]                 ` <20130910140937.GD16011-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2013-09-10 15:51                   ` Toralf Förster [this message]
2013-09-10 15:51                     ` Toralf Förster
2013-09-10 15:51                     ` Toralf Förster
2013-09-22 16:58                   ` Toralf Förster
2013-09-22 16:58                     ` Toralf Förster
2013-09-22 16:58                     ` Toralf Förster
2013-09-23 17:41                     ` J. Bruce Fields
2013-09-23 17:41                       ` J. Bruce Fields
2013-09-23 17:41                       ` J. Bruce Fields
     [not found]                       ` <20130923174129.GA19720-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2013-10-02 20:29                         ` Toralf Förster
2013-10-02 20:29                           ` Toralf Förster
2013-10-02 20:29                           ` Toralf Förster
  -- strict thread matches above, loose matches on Subject: below --
2013-09-27 14:53 Marc Meledandri
2013-09-28 15:37 Marc Meledandri
2013-10-01 14:34 ` J. Bruce Fields
2013-10-02  1:24   ` Marc Meledandri
2013-10-02 14:04     ` J. Bruce Fields

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=522F3FEC.7080406@gmx.de \
    --to=toralf.foerster-mmb7mzphnfy@public.gmane.org \
    --cc=bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org \
    --cc=jack-AlSwsSmVLrQ@public.gmane.org \
    --cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=user-mode-linux-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.