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: Wed, 02 Oct 2013 22:29:47 +0200 [thread overview]
Message-ID: <524C823B.8020900@gmx.de> (raw)
In-Reply-To: <20130923174129.GA19720-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On 09/23/2013 07:41 PM, J. Bruce Fields wrote:
> On Sun, Sep 22, 2013 at 06:58:29PM +0200, Toralf Förster wrote:
>> 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?
>>>
>> Yes, pre-existing. I'm trying to bisect it, the issue is already in 7d3107d.
>>
>> But every attempt to get the first bad commit before that commit id
>> failed till now. I started many attempts between v3.10 and 7d3107d. I
>> could not reproduce that issue 100% in that interval. In that interval
>> either all tested commits doesn't show the issue or the NFS client hangs
>> during the stop of NFS service infinitely - and counting that as a "bad"
>> commit doesn't work.
>>
>> FWIW a single test case currently takes 2 1/2 hour and even then I do
>> not fully trust the result (except for a bad commit, that's clear.
>
> Well, we should figure out some other way to narrow down the problem....
>
> I was trying to at least work out where exactly this crash was, but I
> don't have a commit 768c9d3.
>
> --b.
>
just for completeness of this thread, that issue could be bisected in
the mean while :
http://thread.gmane.org/gmane.linux.kernel/1569818
>>
>>
>>> --b.
>>>
>>>>
>>>> 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
>
--
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: Wed, 02 Oct 2013 22:29:47 +0200 [thread overview]
Message-ID: <524C823B.8020900@gmx.de> (raw)
In-Reply-To: <20130923174129.GA19720@fieldses.org>
On 09/23/2013 07:41 PM, J. Bruce Fields wrote:
> On Sun, Sep 22, 2013 at 06:58:29PM +0200, Toralf Förster wrote:
>> 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?
>>>
>> Yes, pre-existing. I'm trying to bisect it, the issue is already in 7d3107d.
>>
>> But every attempt to get the first bad commit before that commit id
>> failed till now. I started many attempts between v3.10 and 7d3107d. I
>> could not reproduce that issue 100% in that interval. In that interval
>> either all tested commits doesn't show the issue or the NFS client hangs
>> during the stop of NFS service infinitely - and counting that as a "bad"
>> commit doesn't work.
>>
>> FWIW a single test case currently takes 2 1/2 hour and even then I do
>> not fully trust the result (except for a bad commit, that's clear.
>
> Well, we should figure out some other way to narrow down the problem....
>
> I was trying to at least work out where exactly this crash was, but I
> don't have a commit 768c9d3.
>
> --b.
>
just for completeness of this thread, that issue could be bisected in
the mean while :
http://thread.gmane.org/gmane.linux.kernel/1569818
>>
>>
>>> --b.
>>>
>>>>
>>>> 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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: Wed, 02 Oct 2013 22:29:47 +0200 [thread overview]
Message-ID: <524C823B.8020900@gmx.de> (raw)
In-Reply-To: <20130923174129.GA19720@fieldses.org>
On 09/23/2013 07:41 PM, J. Bruce Fields wrote:
> On Sun, Sep 22, 2013 at 06:58:29PM +0200, Toralf Förster wrote:
>> 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?
>>>
>> Yes, pre-existing. I'm trying to bisect it, the issue is already in 7d3107d.
>>
>> But every attempt to get the first bad commit before that commit id
>> failed till now. I started many attempts between v3.10 and 7d3107d. I
>> could not reproduce that issue 100% in that interval. In that interval
>> either all tested commits doesn't show the issue or the NFS client hangs
>> during the stop of NFS service infinitely - and counting that as a "bad"
>> commit doesn't work.
>>
>> FWIW a single test case currently takes 2 1/2 hour and even then I do
>> not fully trust the result (except for a bad commit, that's clear.
>
> Well, we should figure out some other way to narrow down the problem....
>
> I was trying to at least work out where exactly this crash was, but I
> don't have a commit 768c9d3.
>
> --b.
>
just for completeness of this thread, that issue could be bisected in
the mean while :
http://thread.gmane.org/gmane.linux.kernel/1569818
>>
>>
>>> --b.
>>>
>>>>
>>>> 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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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/
next prev parent reply other threads:[~2013-10-02 20:29 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
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 [this message]
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=524C823B.8020900@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.