crash in xfs in current

crash in xfs in current

[Reinoud Koornstra]

Dear Dave and Everyone,

Today I crashed twice in a row in 4.7-rc1.
This was the message and trace:

Jun  6 18:07:34 router-dev kernel: [  134.297442] XFS: Assertion
failed: args->op_flags & XFS_DA_OP_OKNOENT, file:
fs/xfs/libxfs/xfs_dir2_leaf.c, line: 1307
Jun  6 18:07:34 router-dev kernel: [  134.297459] ------------[ cut
here ]------------
Jun  6 18:07:34 router-dev kernel: [  134.297474] kernel BUG at
fs/xfs/xfs_message.c:113!
Jun  6 18:07:34 router-dev kernel: [  134.297485] invalid opcode: 0000 [#1] SMP
Jun  6 18:07:34 router-dev kernel: [  134.297494] Modules linked in:
pl2303 usbserial snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic 8250_dw snd_hda_intel snd_hda_codec snd_hda_core
x86_pkg_temp_thermal snd_hwdep intel_powerclamp
i2c_designware_platform i2c_designware_core snd_pcm snd_seq_midi
snd_seq_midi_event coretemp kvm_intel kvm snd_rawmidi snd_seq
snd_seq_device iwlmvm irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel aes_x86_64 lrw snd_timer
glue_helper ablk_helper snd cryptd iwlwifi input_leds soundcore
serio_raw mei_me mei intel_lpss_acpi intel_lpss_pci acpi_als
intel_lpss shpchp binfmt_misc kfifo_buf industrialio acpi_pad mac_hid
parport_pc ppdev lp parport autofs4 xfs libcrc32c i
915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt
fb_sys_fops hid_generic mxm_wmi r8169 ahci usbhid i2c_hid mii drm
libahci hid wmi video pinctrl_sunrisepoint pinctrl_intel
Jun  6 18:07:34 router-dev kernel: [  134.297712] CPU: 2 PID: 2115
Comm: aptitude Tainted: G     U          4.7.0-rc1-wt+ #8
Jun  6 18:07:34 router-dev kernel: [  134.297728] Hardware name: MSI
MS-7971/Z170A PC MATE (MS-7971), BIOS A.70 01/25/2016
Jun  6 18:07:34 router-dev kernel: [  134.297744] task:
ffff8804165f9e80 ti: ffff8803f7eb8000 task.ti: ffff8803f7eb8000
Jun  6 18:07:34 router-dev kernel: [  134.297759] RIP:
0010:[<ffffffffc0359080>]  [<ffffffffc0359080>] assfail+0x20/0x30
[xfs]
Jun  6 18:07:34 router-dev kernel: [  134.297796] RSP:
0018:ffff8803f7ebbbb8  EFLAGS: 00010246
Jun  6 18:07:34 router-dev kernel: [  134.297808] RAX:
0000000000000000 RBX: ffff8803fd5ce480 RCX: 0000000000000000
Jun  6 18:07:34 router-dev kernel: [  134.297822] RDX:
00000000ffffffc0 RSI: 000000000000000a RDI: ffffffffc038c74a
Jun  6 18:07:34 router-dev kernel: [  134.297837] RBP:
ffff8803f7ebbbb8 R08: 0000000000000000 R09: 0000000000000000
Jun  6 18:07:34 router-dev kernel: [  134.297852] R10:
000000000000000a R11: f000000000000000 R12: ffff8803fd5ce480
Jun  6 18:07:34 router-dev kernel: [  134.297874] R13:
0000000000000062 R14: ffff880035b5c000 R15: ffff8803fd5ce480
Jun  6 18:07:34 router-dev kernel: [  134.297889] FS:
00007ff14ad84780(0000) GS:ffff88046ec80000(0000)
knlGS:0000000000000000
Jun  6 18:07:34 router-dev kernel: [  134.297906] CS:  0010 DS: 0000
ES: 0000 CR0: 0000000080050033
Jun  6 18:07:34 router-dev kernel: [  134.297918] CR2:
000055b4b6869d98 CR3: 00000003f87f3000 CR4: 00000000003406e0
Jun  6 18:07:34 router-dev kernel: [  134.297932] DR0:
0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun  6 18:07:34 router-dev kernel: [  134.297947] DR3:
0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jun  6 18:07:34 router-dev kernel: [  134.297962] Stack:
Jun  6 18:07:34 router-dev kernel: [  134.297967]  ffff8803f7ebbc40
ffffffffc0322277 ffff8803f7ebbc58 00000000ffffffff
Jun  6 18:07:34 router-dev kernel: [  134.297986]  ffff8803ffffffff
ffff880414673840 ffff8803f610b000 0000000000000000
Jun  6 18:07:34 router-dev kernel: [  134.298004]  ffff880452bed380
0000000000000000 ffff003c00a7d2f1 00000000b56d2e47
Jun  6 18:07:34 router-dev kernel: [  134.298022] Call Trace:
Jun  6 18:07:34 router-dev kernel: [  134.298039]
[<ffffffffc0322277>] xfs_dir2_leaf_lookup_int+0x237/0x350 [xfs]
Jun  6 18:07:34 router-dev kernel: [  134.298064]
[<ffffffffc03229e1>] xfs_dir2_leaf_replace+0x41/0x190 [xfs]
Jun  6 18:07:34 router-dev kernel: [  134.298088]
[<ffffffffc031c06c>] xfs_dir_replace+0x18c/0x1b0 [xfs]
Jun  6 18:07:34 router-dev kernel: [  134.298114]
[<ffffffffc035653f>] xfs_rename+0x45f/0x9d0 [xfs]
Jun  6 18:07:34 router-dev kernel: [  134.298128]
[<ffffffff819ccf1f>] ? _raw_write_lock_irqsave+0x2f/0x40
Jun  6 18:07:34 router-dev kernel: [  134.298155]
[<ffffffffc034f892>] xfs_vn_rename+0xb2/0xe0 [xfs]
Jun  6 18:07:34 router-dev kernel: [  134.298169]
[<ffffffff8122e824>] vfs_rename+0x5a4/0x940
Jun  6 18:07:34 router-dev kernel: [  134.298182]
[<ffffffff81354900>] ? security_path_rename+0x90/0xe0
Jun  6 18:07:34 router-dev kernel: [  134.298195]
[<ffffffff81233475>] SyS_rename+0x3d5/0x3f0
Jun  6 18:07:34 router-dev kernel: [  134.298207]
[<ffffffff819cd236>] entry_SYSCALL_64_fastpath+0x1e/0xa8
Jun  6 18:07:34 router-dev kernel: [  134.298221] Code: 00 66 2e 0f 1f
84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 f1 41 89 d0 48 c7 c6 90 84
39 c0 48 89 fa 31 ff 48 89 e5 e8 b0 f8 ff ff <0f> 0b 0f 1f 40 00 66 2e
0f 1f 84 00 00 00 00 00 0f 1f 44 00
00
Jun  6 18:07:34 router-dev kernel: [  134.298312] RIP
[<ffffffffc0359080>] assfail+0x20/0x30 [xfs]
Jun  6 18:07:34 router-dev kernel: [  134.298339]  RSP <ffff8803f7ebbbb8>
Jun  6 18:07:34 router-dev kernel: [  134.303832] ---[ end trace
7894462e3381a043 ]---

0x760b0 is in assfail (fs/xfs/xfs_message.c:113).
108     void
109     assfail(char *expr, char *file, int line)
110     {
111             xfs_emerg(NULL, "Assertion failed: %s, file: %s, line: %d",
112                     expr, file, line);
113             BUG();
114     }
115
116     void
117     xfs_hex_dump(void *p, int length)

Ok, so this function is called.
The line is: ASSERT(args->op_flags & XFS_DA_OP_OKNOENT);
The function that the assert was called was:

/*
* Look up name/hash in the leaf block.
* Fill in indexp with the found index, and dbpp with the data buffer.
* If not found dbpp will be NULL, and ENOENT comes back.
* lbpp will always be filled in with the leaf buffer unless there's an error.
*/
static int                                      /* error */
xfs_dir2_leaf_lookup_int

The assert took place right after this loop:
        /*
        * Loop over all the entries with the right hash value
        * looking to match the name.
        */
       for (lep = &ents[index];
            index < leafhdr.count && be32_to_cpu(lep->hashval) == args->hashval;
            lep++, index++)

I seem to be able to hit this bug rather frequently.
So I put in some instrumentation to print out the flags next time I
hit it and save a core file to another fs.
Is this is known bug to you or?
Thanks,

Reinoud.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Eric Sandeen]

On 6/6/16 8:43 PM, Reinoud Koornstra wrote:
> Dear Dave and Everyone,
> 
> Today I crashed twice in a row in 4.7-rc1.
> This was the message and trace:
> 
> Jun  6 18:07:34 router-dev kernel: [  134.297442] XFS: Assertion failed: args->op_flags & XFS_DA_OP_OKNOENT, file: fs/xfs/libxfs/xfs_dir2_leaf.c, line: 1307

Ok, that ASSERT has been there since 2005 ...

> Jun  6 18:07:34 router-dev kernel: [  134.297459] ------------[ cut here ]------------
> Jun  6 18:07:34 router-dev kernel: [  134.297474] kernel BUG at fs/xfs/xfs_message.c:113!
> Jun  6 18:07:34 router-dev kernel: [  134.297485] invalid opcode: 0000 [#1] SMP
> Jun  6 18:07:34 router-dev kernel: [  134.297494] Modules linked in:

... unlinewrapping...

> Jun  6 18:07:34 router-dev kernel: [  134.297962] Stack:
> Jun  6 18:07:34 router-dev kernel: [  134.297967]  ffff8803f7ebbc40 ffffffffc0322277 ffff8803f7ebbc58 00000000ffffffff
> Jun  6 18:07:34 router-dev kernel: [  134.297986]  ffff8803ffffffff ffff880414673840 ffff8803f610b000 0000000000000000
> Jun  6 18:07:34 router-dev kernel: [  134.298004]  ffff880452bed380 0000000000000000 ffff003c00a7d2f1 00000000b56d2e47
> Jun  6 18:07:34 router-dev kernel: [  134.298022] Call Trace:
> Jun  6 18:07:34 router-dev kernel: [  134.298039] [<ffffffffc0322277>] xfs_dir2_leaf_lookup_int+0x237/0x350 [xfs]
> Jun  6 18:07:34 router-dev kernel: [  134.298064] [<ffffffffc03229e1>] xfs_dir2_leaf_replace+0x41/0x190 [xfs]
> Jun  6 18:07:34 router-dev kernel: [  134.298088] [<ffffffffc031c06c>] xfs_dir_replace+0x18c/0x1b0 [xfs]
> Jun  6 18:07:34 router-dev kernel: [  134.298114] [<ffffffffc035653f>] xfs_rename+0x45f/0x9d0 [xfs]
> Jun  6 18:07:34 router-dev kernel: [  134.298155] [<ffffffffc034f892>] xfs_vn_rename+0xb2/0xe0 [xfs]
> Jun  6 18:07:34 router-dev kernel: [  134.298169] [<ffffffff8122e824>] vfs_rename+0x5a4/0x940
> Jun  6 18:07:34 router-dev kernel: [  134.298195] [<ffffffff81233475>] SyS_rename+0x3d5/0x3f0
> Jun  6 18:07:34 router-dev kernel: [  134.298207] [<ffffffff819cd236>] entry_SYSCALL_64_fastpath+0x1e/0xa8
> Jun  6 18:07:34 router-dev kernel: [  134.298221] Code: 00 66 2e 0f 1f


> I seem to be able to hit this bug rather frequently.
> So I put in some instrumentation to print out the flags next time I
> hit it and save a core file to another fs.
> Is this is known bug to you or?

xfs_dir2_leaf_lookup_int() only hits that ASSERT if it was given
a name to rename, and failed to find the original.  i.e. that should
not happen.

        /*
         * Loop over all the entries with the right hash value
         * looking to match the name.
         */

<do that loop>
<fail to find the hash value for the name>
<then:>

        ASSERT(args->op_flags & XFS_DA_OP_OKNOENT);
        /*
         * Here, we can only be doing a lookup (not a rename or remove).
         * If a case-insensitive match was found earlier, re-read the
         * appropriate data block if required and return it.
         */

A rename should never fail to find the original name.

Did this problem only show up after an update?

Do you have a reproducer?

Have you unmounted and run an "xfs_repair -n" and captured the output
to see if there is any on-disk corruption?

You might gather an xfs_metadump as well, before you do any live
repair that might change the filesystem.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Christoph Hellwig]

On Mon, Jun 06, 2016 at 11:39:59PM -0500, Eric Sandeen wrote:
> xfs_dir2_leaf_lookup_int() only hits that ASSERT if it was given
> a name to rename, and failed to find the original.  i.e. that should
> not happen.
> 
>         /*
>          * Loop over all the entries with the right hash value
>          * looking to match the name.
>          */
> 
> <do that loop>
> <fail to find the hash value for the name>
> <then:>
> 
>         ASSERT(args->op_flags & XFS_DA_OP_OKNOENT);
>         /*
>          * Here, we can only be doing a lookup (not a rename or remove).
>          * If a case-insensitive match was found earlier, re-read the
>          * appropriate data block if required and return it.
>          */
> 
> A rename should never fail to find the original name.

FYI, this looks very much the same like the Bug Daniel reported, which
I tried to help debugging in person over the weekend.  His backtrace
points to cancelling a dirty transaction after xfs_dir_replace failed,
which most likely comes from the failing lookup, except that he probably
doen't have XFS_DEBUG enabled.

Given that 4.7-rc1 comes with the new shared locks for lookups, and
there are very little other changes I wonder if there is any relation
It would be good if Reinoud and/or Daniel can confirm that Linux 4.6
is ok.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Daniel Wagner]

> Given that 4.7-rc1 comes with the new shared locks for lookups, and
> there are very little other changes I wonder if there is any relation
> It would be good if Reinoud and/or Daniel can confirm that Linux 4.6
> is ok.

I try to reproduce it on 4.6. My steps do not always trigger the crash.
So I can't be really sure if 4.6 doesn't show it, it does not happen.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

On Tue, Jun 7, 2016 at 1:51 AM, Daniel Wagner <wagi@monom.org> wrote:
>> Given that 4.7-rc1 comes with the new shared locks for lookups, and
>> there are very little other changes I wonder if there is any relation
>> It would be good if Reinoud and/or Daniel can confirm that Linux 4.6
>> is ok.
>
> I try to reproduce it on 4.6. My steps do not always trigger the crash.
> So I can't be really sure if 4.6 doesn't show it, it does not happen.

I have never been able to trigger this in 4.6 and it's my failsafe
reboot (4.6.0).
In 4.7-rc1 it's just a matter of time before I hit it.
I do a lot of transactions, using git, extraction of tar.xz etc normally.
I am normally able to trigger this by a move of a big directory.
It gets stuck there, a kill -9 doesn't either.
So 4.6 is my safehaven to any xfs operation.
Thanks,

Reinoud.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

On Tue, Jun 7, 2016 at 12:27 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Jun 06, 2016 at 11:39:59PM -0500, Eric Sandeen wrote:
>> xfs_dir2_leaf_lookup_int() only hits that ASSERT if it was given
>> a name to rename, and failed to find the original.  i.e. that should
>> not happen.
>>
>>         /*
>>          * Loop over all the entries with the right hash value
>>          * looking to match the name.
>>          */
>>
>> <do that loop>
>> <fail to find the hash value for the name>
>> <then:>
>>
>>         ASSERT(args->op_flags & XFS_DA_OP_OKNOENT);
>>         /*
>>          * Here, we can only be doing a lookup (not a rename or remove).
>>          * If a case-insensitive match was found earlier, re-read the
>>          * appropriate data block if required and return it.
>>          */
>>
>> A rename should never fail to find the original name.
>
> FYI, this looks very much the same like the Bug Daniel reported, which
> I tried to help debugging in person over the weekend.  His backtrace
> points to cancelling a dirty transaction after xfs_dir_replace failed,
> which most likely comes from the failing lookup, except that he probably
> doen't have XFS_DEBUG enabled.

In my case, it looks like that the lookup failed.
First you try to find the xfs_buf, lbp if the pointer to that buffer.
Then you try to find the leaf entry with the same hash value.
Then you look over the entries with the hash value and look if the names match.
Hopefully XFS_CMP_EXACT is returned.
What I do NOT get is why this flag needs to be set: XFS_DA_OP_OKNOENT
I see it being set in xfs_attr_{get, set, remove}, but I am not able
to see that anywhere in the path of this function.
In each of these xfs_attrs I see locks acquired and locked released,
no problem, other than that it's assumed the you obtain the lock.
If the beginning checks during the lock process don't work out you ASSERT.

>
> Given that 4.7-rc1 comes with the new shared locks for lookups, and
> there are very little other changes I wonder if there is any relation
> It would be good if Reinoud and/or Daniel can confirm that Linux 4.6
> is ok.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Daniel Wagner]

>> I try to reproduce it on 4.6. My steps do not always trigger the crash.
>> So I can't be really sure if 4.6 doesn't show it, it does not happen.
> 
> I have never been able to trigger this in 4.6 and it's my failsafe
> reboot (4.6.0).
> In 4.7-rc1 it's just a matter of time before I hit it.
> I do a lot of transactions, using git, extraction of tar.xz etc normally.

This rings a bell. I though the lockperf tests triggered it. Before I
compiled a new kernel I did a 'git checkout' step.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

[-- Attachment #1.1: Type: text/plain, Size: 1480 bytes --]

On Jun 7, 2016 4:52 AM, "Daniel Wagner" <wagi@monom.org> wrote:
>
> >> I try to reproduce it on 4.6. My steps do not always trigger the crash.
> >> So I can't be really sure if 4.6 doesn't show it, it does not happen.
> >
> > I have never been able to trigger this in 4.6 and it's my failsafe
> > reboot (4.6.0).
> > In 4.7-rc1 it's just a matter of time before I hit it.
> > I do a lot of transactions, using git, extraction of tar.xz etc
normally.
>
> This rings a bell. I though the lockperf tests triggered it. Before I
> compiled a new kernel I did a 'git checkout' step.

Yeah, could well be. During big git operations I get into this and while I
was trying to compile GCC 6.1.0 and I was moving mpfc dir into gcc/mpfc for
example. The move never completed. I do use git to get the latest kernel
sources for wireless testing. With the 4.6.0 I didn't hit problems. Ever
since I started using 4.7 I kept crashing on asserts in xfs. :) As I hit
this frequently I can instrument. I did write some instrumentation to
display the args flags before the assert, but from Eric's work, it doesn't
seem these are important at all as it might be a locking issue. I will say
that it sounds most likely a locking issue to me , because sometimes I just
hang in an fs operation and it never completes. Even trying to kill the mv
operation doesn't work. I can try to reproduce tomorrow and either reach
the assert or get stuck in a lock in which case trace-cmd might help.
Thanks,

Reinoud.

[-- Attachment #1.2: Type: text/html, Size: 1756 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Christoph Hellwig]

On Tue, Jun 07, 2016 at 12:52:39PM +0200, Daniel Wagner wrote:
> >> I try to reproduce it on 4.6. My steps do not always trigger the crash.
> >> So I can't be really sure if 4.6 doesn't show it, it does not happen.
> > 
> > I have never been able to trigger this in 4.6 and it's my failsafe
> > reboot (4.6.0).
> > In 4.7-rc1 it's just a matter of time before I hit it.
> > I do a lot of transactions, using git, extraction of tar.xz etc normally.
> 
> This rings a bell. I though the lockperf tests triggered it. Before I
> compiled a new kernel I did a 'git checkout' step.

Thanks for testing this to both of you.  Can you try to build a kernel
from git commit 555b67e4e729ca544bb4028ab12e532c68b70ddb - this is the
XFS pull request that Dave sent to Linux for Linux 4.7-rc, so it has
all the XFS changes relative to 4.6, but none of the others like the VFS
changes.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

Hi Christoph,

Now my git log show this:

commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
Merge: 544ad71 ad438c4
Author: Dave Chinner <david@fromorbit.com>
Date:   Fri May 20 10:34:00 2016 +1000

   Merge branch 'xfs-4.7-inode-reclaim' into for-next

commit 544ad71fc8e20fb3a6f50f00d487751492cd8409
Merge: 2a4ad58 e6b3bb7
Author: Dave Chinner <david@fromorbit.com>
Date:   Fri May 20 10:33:38 2016 +1000

   Merge branch 'xfs-4.7-error-cfg' into for-next

commit 2a4ad5894c819978dca5595396d54d51c3aca694
Merge: a7792aa 6e3e6d5
Author: Dave Chinner <david@fromorbit.com>
Date:   Fri May 20 10:33:17 2016 +1000

   Merge branch 'xfs-4.7-misc-fixes' into for-next

commit a7792aad644a259375002db8c9d9e03fd50bf509
Merge: 5b911354 3ab3ffc
Author: Dave Chinner <david@fromorbit.com>
Date:   Fri May 20 10:32:35 2016 +1000

Is this correct?
If so, let me build and test.
Building it already as we speak, but it would be nice if you could
confirm I'm actually testing the right thing.
Though, wouldn't it be good to repro and get a core file as well?
Or would the test of this commit narrow down the possibilities as well?
Thanks,

Reinoud.

On Tue, Jun 7, 2016 at 7:44 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, Jun 07, 2016 at 12:52:39PM +0200, Daniel Wagner wrote:
>> >> I try to reproduce it on 4.6. My steps do not always trigger the crash.
>> >> So I can't be really sure if 4.6 doesn't show it, it does not happen.
>> >
>> > I have never been able to trigger this in 4.6 and it's my failsafe
>> > reboot (4.6.0).
>> > In 4.7-rc1 it's just a matter of time before I hit it.
>> > I do a lot of transactions, using git, extraction of tar.xz etc normally.
>>
>> This rings a bell. I though the lockperf tests triggered it. Before I
>> compiled a new kernel I did a 'git checkout' step.
>
> Thanks for testing this to both of you.  Can you try to build a kernel
> from git commit 555b67e4e729ca544bb4028ab12e532c68b70ddb - this is the
> XFS pull request that Dave sent to Linux for Linux 4.7-rc, so it has
> all the XFS changes relative to 4.6, but none of the others like the VFS
> changes.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

On Tue, Jun 7, 2016 at 5:40 PM, Reinoud Koornstra
<reinoudkoornstra@gmail.com> wrote:
> Hi Christoph,
>
> Now my git log show this:
>
> commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
> Merge: 544ad71 ad438c4
> Author: Dave Chinner <david@fromorbit.com>
> Date:   Fri May 20 10:34:00 2016 +1000
>
>    Merge branch 'xfs-4.7-inode-reclaim' into for-next
>
> commit 544ad71fc8e20fb3a6f50f00d487751492cd8409
> Merge: 2a4ad58 e6b3bb7
> Author: Dave Chinner <david@fromorbit.com>
> Date:   Fri May 20 10:33:38 2016 +1000
>
>    Merge branch 'xfs-4.7-error-cfg' into for-next
>
> commit 2a4ad5894c819978dca5595396d54d51c3aca694
> Merge: a7792aa 6e3e6d5
> Author: Dave Chinner <david@fromorbit.com>
> Date:   Fri May 20 10:33:17 2016 +1000
>
>    Merge branch 'xfs-4.7-misc-fixes' into for-next
>
> commit a7792aad644a259375002db8c9d9e03fd50bf509
> Merge: 5b911354 3ab3ffc
> Author: Dave Chinner <david@fromorbit.com>
> Date:   Fri May 20 10:32:35 2016 +1000
>
> Is this correct?
> If so, let me build and test.
> Building it already as we speak, but it would be nice if you could
> confirm I'm actually testing the right thing.
> Though, wouldn't it be good to repro and get a core file as well?
> Or would the test of this commit narrow down the possibilities as well?
> Thanks,
>
> Reinoud.
>

Ouch, forgive me for not responding inline previously.
For what it's worth, i've compiled the kernel and are running it as we speak.
Will do testing and let you know.
Thanks,

Reinoud.

> On Tue, Jun 7, 2016 at 7:44 AM, Christoph Hellwig <hch@infradead.org> wrote:
>> On Tue, Jun 07, 2016 at 12:52:39PM +0200, Daniel Wagner wrote:
>>> >> I try to reproduce it on 4.6. My steps do not always trigger the crash.
>>> >> So I can't be really sure if 4.6 doesn't show it, it does not happen.
>>> >
>>> > I have never been able to trigger this in 4.6 and it's my failsafe
>>> > reboot (4.6.0).
>>> > In 4.7-rc1 it's just a matter of time before I hit it.
>>> > I do a lot of transactions, using git, extraction of tar.xz etc normally.
>>>
>>> This rings a bell. I though the lockperf tests triggered it. Before I
>>> compiled a new kernel I did a 'git checkout' step.
>>
>> Thanks for testing this to both of you.  Can you try to build a kernel
>> from git commit 555b67e4e729ca544bb4028ab12e532c68b70ddb - this is the
>> XFS pull request that Dave sent to Linux for Linux 4.7-rc, so it has
>> all the XFS changes relative to 4.6, but none of the others like the VFS
>> changes.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

On Tue, Jun 7, 2016 at 10:16 PM, Reinoud Koornstra
<reinoudkoornstra@gmail.com> wrote:
> On Tue, Jun 7, 2016 at 5:40 PM, Reinoud Koornstra
> <reinoudkoornstra@gmail.com> wrote:
>> Hi Christoph,
>>
>> Now my git log show this:
>>
>> commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
>> Merge: 544ad71 ad438c4
>> Author: Dave Chinner <david@fromorbit.com>
>> Date:   Fri May 20 10:34:00 2016 +1000
>>
>>    Merge branch 'xfs-4.7-inode-reclaim' into for-next
>>
>> commit 544ad71fc8e20fb3a6f50f00d487751492cd8409
>> Merge: 2a4ad58 e6b3bb7
>> Author: Dave Chinner <david@fromorbit.com>
>> Date:   Fri May 20 10:33:38 2016 +1000
>>
>>    Merge branch 'xfs-4.7-error-cfg' into for-next
>>
>> commit 2a4ad5894c819978dca5595396d54d51c3aca694
>> Merge: a7792aa 6e3e6d5
>> Author: Dave Chinner <david@fromorbit.com>
>> Date:   Fri May 20 10:33:17 2016 +1000
>>
>>    Merge branch 'xfs-4.7-misc-fixes' into for-next
>>
>> commit a7792aad644a259375002db8c9d9e03fd50bf509
>> Merge: 5b911354 3ab3ffc
>> Author: Dave Chinner <david@fromorbit.com>
>> Date:   Fri May 20 10:32:35 2016 +1000
>>
>> Is this correct?
>> If so, let me build and test.
>> Building it already as we speak, but it would be nice if you could
>> confirm I'm actually testing the right thing.
>> Though, wouldn't it be good to repro and get a core file as well?
>> Or would the test of this commit narrow down the possibilities as well?
>> Thanks,
>>
>> Reinoud.
>>
>
> Ouch, forgive me for not responding inline previously.
> For what it's worth, i've compiled the kernel and are running it as we speak.
> Will do testing and let you know.

Ok, going back to commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
brings the kernel back to 4.6-rc1.
With that kernel I crash all over the place, so that's something I cannot run.
Is there a way to get the 4.7-rc1 or rc2 without the commits for XFS?

Reinoud.


> Thanks,
>
> Reinoud.
>
>> On Tue, Jun 7, 2016 at 7:44 AM, Christoph Hellwig <hch@infradead.org> wrote:
>>> On Tue, Jun 07, 2016 at 12:52:39PM +0200, Daniel Wagner wrote:
>>>> >> I try to reproduce it on 4.6. My steps do not always trigger the crash.
>>>> >> So I can't be really sure if 4.6 doesn't show it, it does not happen.
>>>> >
>>>> > I have never been able to trigger this in 4.6 and it's my failsafe
>>>> > reboot (4.6.0).
>>>> > In 4.7-rc1 it's just a matter of time before I hit it.
>>>> > I do a lot of transactions, using git, extraction of tar.xz etc normally.
>>>>
>>>> This rings a bell. I though the lockperf tests triggered it. Before I
>>>> compiled a new kernel I did a 'git checkout' step.
>>>
>>> Thanks for testing this to both of you.  Can you try to build a kernel
>>> from git commit 555b67e4e729ca544bb4028ab12e532c68b70ddb - this is the
>>> XFS pull request that Dave sent to Linux for Linux 4.7-rc, so it has
>>> all the XFS changes relative to 4.6, but none of the others like the VFS
>>> changes.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Christoph Hellwig]

On Tue, Jun 07, 2016 at 10:40:11PM -0600, Reinoud Koornstra wrote:
> >> Is this correct?

That's correct!

> >> If so, let me build and test.
> >> Building it already as we speak, but it would be nice if you could
> >> confirm I'm actually testing the right thing.
> >> Though, wouldn't it be good to repro and get a core file as well?
> >> Or would the test of this commit narrow down the possibilities as well?
> >> Thanks,
> >>
> >> Reinoud.
> >>
> >
> > Ouch, forgive me for not responding inline previously.
> > For what it's worth, i've compiled the kernel and are running it as we speak.
> > Will do testing and let you know.
> 
> Ok, going back to commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
> brings the kernel back to 4.6-rc1.
> With that kernel I crash all over the place, so that's something I cannot run.

Oh.  What kinds of crashes?

> Is there a way to get the 4.7-rc1 or rc2 without the commits for XFS?

I can't think of a good way unfortunately.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Daniel Wagner]

> Thanks for testing this to both of you.  Can you try to build a kernel
> from git commit 555b67e4e729ca544bb4028ab12e532c68b70ddb - this is the
> XFS pull request that Dave sent to Linux for Linux 4.7-rc, so it has
> all the XFS changes relative to 4.6, but none of the others like the VFS
> changes.

For some reason, I can't reproduce it with 4.7-rc1 right now. still
trying...

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Dave Chinner]

On Tue, Jun 07, 2016 at 10:40:11PM -0600, Reinoud Koornstra wrote:
> On Tue, Jun 7, 2016 at 10:16 PM, Reinoud Koornstra
> <reinoudkoornstra@gmail.com> wrote:
> > On Tue, Jun 7, 2016 at 5:40 PM, Reinoud Koornstra
> > <reinoudkoornstra@gmail.com> wrote:
> >> Hi Christoph,
> >>
> >> Now my git log show this:
> >>
> >> commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
> >> Merge: 544ad71 ad438c4
> >> Author: Dave Chinner <david@fromorbit.com>
> >> Date:   Fri May 20 10:34:00 2016 +1000
> >>
> >>    Merge branch 'xfs-4.7-inode-reclaim' into for-next
> >>
> >> commit 544ad71fc8e20fb3a6f50f00d487751492cd8409
> >> Merge: 2a4ad58 e6b3bb7
> >> Author: Dave Chinner <david@fromorbit.com>
> >> Date:   Fri May 20 10:33:38 2016 +1000
> >>
> >>    Merge branch 'xfs-4.7-error-cfg' into for-next
> >>
> >> commit 2a4ad5894c819978dca5595396d54d51c3aca694
> >> Merge: a7792aa 6e3e6d5
> >> Author: Dave Chinner <david@fromorbit.com>
> >> Date:   Fri May 20 10:33:17 2016 +1000
> >>
> >>    Merge branch 'xfs-4.7-misc-fixes' into for-next
> >>
> >> commit a7792aad644a259375002db8c9d9e03fd50bf509
> >> Merge: 5b911354 3ab3ffc
> >> Author: Dave Chinner <david@fromorbit.com>
> >> Date:   Fri May 20 10:32:35 2016 +1000
> >>
> >> Is this correct?
> >> If so, let me build and test.
> >> Building it already as we speak, but it would be nice if you could
> >> confirm I'm actually testing the right thing.
> >> Though, wouldn't it be good to repro and get a core file as well?
> >> Or would the test of this commit narrow down the possibilities as well?
> >> Thanks,
> >>
> >> Reinoud.
> >>
> >
> > Ouch, forgive me for not responding inline previously.
> > For what it's worth, i've compiled the kernel and are running it as we speak.
> > Will do testing and let you know.
> 
> Ok, going back to commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
> brings the kernel back to 4.6-rc1.
> With that kernel I crash all over the place, so that's something I cannot run.
> Is there a way to get the 4.7-rc1 or rc2 without the commits for XFS?

In your Linus git tree:

$ git remote add xfsdev git://git.kernel.org/git/dgc/linux-xfs.git
$ git remote update
$ git checkout -b xfsdev-merge v4.6
$ git merge xfsdev/xfs-for-linus-4.7-rc1

And that should give you the XFS changes for 4.7-rc1 in a vanilla 4.6
tree. This merge is one of the things I test (i.e. send to my test
machiens for a round of xfstests and other stress) before sending a
pull request to Linus, so it should work just fine.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

On Wed, Jun 8, 2016 at 8:22 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Jun 07, 2016 at 10:40:11PM -0600, Reinoud Koornstra wrote:
>> On Tue, Jun 7, 2016 at 10:16 PM, Reinoud Koornstra
>> <reinoudkoornstra@gmail.com> wrote:
>> > On Tue, Jun 7, 2016 at 5:40 PM, Reinoud Koornstra
>> > <reinoudkoornstra@gmail.com> wrote:
>> >> Hi Christoph,
>> >>
>> >> Now my git log show this:
>> >>
>> >> commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
>> >> Merge: 544ad71 ad438c4
>> >> Author: Dave Chinner <david@fromorbit.com>
>> >> Date:   Fri May 20 10:34:00 2016 +1000
>> >>
>> >>    Merge branch 'xfs-4.7-inode-reclaim' into for-next
>> >>
>> >> commit 544ad71fc8e20fb3a6f50f00d487751492cd8409
>> >> Merge: 2a4ad58 e6b3bb7
>> >> Author: Dave Chinner <david@fromorbit.com>
>> >> Date:   Fri May 20 10:33:38 2016 +1000
>> >>
>> >>    Merge branch 'xfs-4.7-error-cfg' into for-next
>> >>
>> >> commit 2a4ad5894c819978dca5595396d54d51c3aca694
>> >> Merge: a7792aa 6e3e6d5
>> >> Author: Dave Chinner <david@fromorbit.com>
>> >> Date:   Fri May 20 10:33:17 2016 +1000
>> >>
>> >>    Merge branch 'xfs-4.7-misc-fixes' into for-next
>> >>
>> >> commit a7792aad644a259375002db8c9d9e03fd50bf509
>> >> Merge: 5b911354 3ab3ffc
>> >> Author: Dave Chinner <david@fromorbit.com>
>> >> Date:   Fri May 20 10:32:35 2016 +1000
>> >>
>> >> Is this correct?
>> >> If so, let me build and test.
>> >> Building it already as we speak, but it would be nice if you could
>> >> confirm I'm actually testing the right thing.
>> >> Though, wouldn't it be good to repro and get a core file as well?
>> >> Or would the test of this commit narrow down the possibilities as well?
>> >> Thanks,
>> >>
>> >> Reinoud.
>> >>
>> >
>> > Ouch, forgive me for not responding inline previously.
>> > For what it's worth, i've compiled the kernel and are running it as we speak.
>> > Will do testing and let you know.
>>
>> Ok, going back to commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
>> brings the kernel back to 4.6-rc1.
>> With that kernel I crash all over the place, so that's something I cannot run.
>> Is there a way to get the 4.7-rc1 or rc2 without the commits for XFS?
>
> In your Linus git tree:
>
> $ git remote add xfsdev git://git.kernel.org/git/dgc/linux-xfs.git
> $ git remote update
> $ git checkout -b xfsdev-merge v4.6
> $ git merge xfsdev/xfs-for-linus-4.7-rc1

Tried to do this:

reinoud@router-dev:~/Downloads/kernel_current$  git remote add xfsdev
git://git.kernel.org/git/dgc/linux-xfs.git
reinoud@router-dev:~/Downloads/kernel_current$  git remote update
Fetching origin
Fetching xfsdev
fatal: remote error: access denied or repository not exported:
/git/dgc/linux-xfs.git
error: Could not fetch xfsdev

I don't think I have access to git.kernel.org in terms of pushing. :)
Or am I doing something else wrong.
Forgive the trivial question.

Btw, I started in the most current linus git tree.... or should I git
4.6.y and then do your suggestions?

Thanks,

Reinoud.

>
> And that should give you the XFS changes for 4.7-rc1 in a vanilla 4.6
> tree. This merge is one of the things I test (i.e. send to my test
> machiens for a round of xfstests and other stress) before sending a
> pull request to Linus, so it should work just fine.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Eric Sandeen]

On 6/8/16 9:53 PM, Reinoud Koornstra wrote:

>> In your Linus git tree:
>>
>> $ git remote add xfsdev git://git.kernel.org/git/dgc/linux-xfs.git
>> $ git remote update
>> $ git checkout -b xfsdev-merge v4.6
>> $ git merge xfsdev/xfs-for-linus-4.7-rc1
> 
> Tried to do this:
> 
> reinoud@router-dev:~/Downloads/kernel_current$  git remote add xfsdev
> git://git.kernel.org/git/dgc/linux-xfs.git

I think that should be:

git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git

-Eric

> reinoud@router-dev:~/Downloads/kernel_current$  git remote update
> Fetching origin
> Fetching xfsdev
> fatal: remote error: access denied or repository not exported:
> /git/dgc/linux-xfs.git
> error: Could not fetch xfsdev
> 
> I don't think I have access to git.kernel.org in terms of pushing. :)
> Or am I doing something else wrong.
> Forgive the trivial question.
> 
> Btw, I started in the most current linus git tree.... or should I git
> 4.6.y and then do your suggestions?
> 
> Thanks,
> 
> Reinoud.
> 
>>
>> And that should give you the XFS changes for 4.7-rc1 in a vanilla 4.6
>> tree. This merge is one of the things I test (i.e. send to my test
>> machiens for a round of xfstests and other stress) before sending a
>> pull request to Linus, so it should work just fine.
>>
>> Cheers,
>>
>> Dave.
>> --
>> Dave Chinner
>> david@fromorbit.com
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

On Wed, Jun 8, 2016 at 8:56 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> On 6/8/16 9:53 PM, Reinoud Koornstra wrote:
>
>>> In your Linus git tree:
>>>
>>> $ git remote add xfsdev git://git.kernel.org/git/dgc/linux-xfs.git
>>> $ git remote update
>>> $ git checkout -b xfsdev-merge v4.6
>>> $ git merge xfsdev/xfs-for-linus-4.7-rc1
>>
>> Tried to do this:
>>
>> reinoud@router-dev:~/Downloads/kernel_current$  git remote add xfsdev
>> git://git.kernel.org/git/dgc/linux-xfs.git
>
> I think that should be:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git

Ok That worked better indeed. :)

reinoud@router-dev:~/Downloads/kernel_current$ git remote add xfsdev
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git
reinoud@router-dev:~/Downloads/kernel_current$ git remote update
Fetching origin
Fetching xfsdev
remote: Counting objects: 139, done.
[SNIP]
reinoud@router-dev:~/Downloads/kernel_current$ git checkout -b xfsdev-merge v4.6
Checking out files: 100% (9437/9437), done.
Switched to a new branch 'xfsdev-merge'
reinoud@router-dev:~/Downloads/kernel_current$ git merge
xfsdev/xfs-for-linus-4.7-rc1
merge: xfsdev/xfs-for-linus-4.7-rc1 - not something we can merge
So i tried this:

reinoud@router-dev:~/Downloads/kernel_current$ git merge xfs-for-linus-4.7-rc1
Auto-merging fs/xfs/xfs_super.c
Auto-merging fs/xfs/xfs_pnfs.c
Auto-merging fs/xfs/xfs_mount.h
Auto-merging fs/xfs/xfs_mount.c
Auto-merging fs/xfs/xfs_file.c
Auto-merging fs/xfs/xfs_bmap_util.c
Auto-merging fs/xfs/xfs_aops.c
Auto-merging fs/xfs/libxfs/xfs_bmap.c
Auto-merging fs/namei.c
Merge made by the 'recursive' strategy.
The terminal did hang .... in 4.6
I killed the git operation and did it again and now it says it's up to date.

reinoud@router-dev:~/Downloads/kernel_current$ git merge xfs-for-linus-4.7-rc1
Already up-to-date.
reinoud@router-dev:~/Downloads/kernel_current$ git status
On branch xfsdev-merge

Is this correct, can I now build and test?

>
> -Eric
>
>> reinoud@router-dev:~/Downloads/kernel_current$  git remote update
>> Fetching origin
>> Fetching xfsdev
>> fatal: remote error: access denied or repository not exported:
>> /git/dgc/linux-xfs.git
>> error: Could not fetch xfsdev
>>
>> I don't think I have access to git.kernel.org in terms of pushing. :)
>> Or am I doing something else wrong.
>> Forgive the trivial question.
>>
>> Btw, I started in the most current linus git tree.... or should I git
>> 4.6.y and then do your suggestions?
>>
>> Thanks,
>>
>> Reinoud.
>>
>>>
>>> And that should give you the XFS changes for 4.7-rc1 in a vanilla 4.6
>>> tree. This merge is one of the things I test (i.e. send to my test
>>> machiens for a round of xfstests and other stress) before sending a
>>> pull request to Linus, so it should work just fine.
>>>
>>> Cheers,
>>>
>>> Dave.
>>> --
>>> Dave Chinner
>>> david@fromorbit.com
>>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Reinoud Koornstra]

On Wed, Jun 8, 2016 at 9:42 PM, Reinoud Koornstra
<reinoudkoornstra@gmail.com> wrote:
> On Wed, Jun 8, 2016 at 8:56 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
>> On 6/8/16 9:53 PM, Reinoud Koornstra wrote:
>>
>>>> In your Linus git tree:
>>>>
>>>> $ git remote add xfsdev git://git.kernel.org/git/dgc/linux-xfs.git
>>>> $ git remote update
>>>> $ git checkout -b xfsdev-merge v4.6
>>>> $ git merge xfsdev/xfs-for-linus-4.7-rc1
>>>
>>> Tried to do this:
>>>
>>> reinoud@router-dev:~/Downloads/kernel_current$  git remote add xfsdev
>>> git://git.kernel.org/git/dgc/linux-xfs.git
>>
>> I think that should be:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git
>
> Ok That worked better indeed. :)

I've tested the way you and Dave described.
Indeed, I do not see the issues appearing in that xfsdev tree.
So it works good there.
For verification, I tried when I was upon this state (so this is a good state):


reinoud@router-dev:~/Downloads/kernel_current$ git log | more
commit f56c2f323f026bd9cf942f34f8a634ccd88b6ed7
Merge: 2dcd0af 555b67e
Author: Reinoud Koornstra <reinoudkoornstra@gmail.com>
Date:   Wed Jun 8 21:31:32 2016 -0600

   Merge tag 'xfs-for-linus-4.7-rc1' into xfsdev-merge

   xfs: update for 4.7-rc1

   Merge local tree

   Changes in this update:
   o fixes for mount line parsing, sparse warnings, read-only compat
     feature remount behaviour
   o allow fast path symlink lookups for inline symlinks.
   o attribute listing cleanups
   o writeback goes direct to bios rather than indirecting through
     bufferheads
   o transaction allocation cleanup
   o optimised kmem_realloc
   o added configurable error handling for metadata write errors,
     changed default error handling behaviour from "retry forever" to
     "retry until unmount then fail"
   o fixed several inode cluster writeback lookup vs reclaim race
     conditions
   o fixed inode cluster writeback checking wrong inode after lookup
   o fixed bugs where struct xfs_inode freeing wasn't actually RCU safe
   o cleaned up inode reclaim tagging

commit 555b67e4e729ca544bb4028ab12e532c68b70ddb
Merge: 544ad71 ad438c4
Author: Dave Chinner <david@fromorbit.com>
Date:   Fri May 20 10:34:00 2016 +1000

   Merge branch 'xfs-4.7-inode-reclaim' into for-next

commit 544ad71fc8e20fb3a6f50f00d487751492cd8409
Merge: 2a4ad58 e6b3bb7
Author: Dave Chinner <david@fromorbit.com>
Date:   Fri May 20 10:33:38 2016 +1000

   Merge branch 'xfs-4.7-error-cfg' into for-next

commit 2a4ad5894c819978dca5595396d54d51c3aca694
Merge: a7792aa 6e3e6d5
Author: Dave Chinner <david@fromorbit.com>
Date:   Fri May 20 10:33:17 2016 +1000

   Merge branch 'xfs-4.7-misc-fixes' into for-next

Thanks, Reinoud.

>
> reinoud@router-dev:~/Downloads/kernel_current$ git remote add xfsdev
> git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git
> reinoud@router-dev:~/Downloads/kernel_current$ git remote update
> Fetching origin
> Fetching xfsdev
> remote: Counting objects: 139, done.
> [SNIP]
> reinoud@router-dev:~/Downloads/kernel_current$ git checkout -b xfsdev-merge v4.6
> Checking out files: 100% (9437/9437), done.
> Switched to a new branch 'xfsdev-merge'
> reinoud@router-dev:~/Downloads/kernel_current$ git merge
> xfsdev/xfs-for-linus-4.7-rc1
> merge: xfsdev/xfs-for-linus-4.7-rc1 - not something we can merge
> So i tried this:
>
> reinoud@router-dev:~/Downloads/kernel_current$ git merge xfs-for-linus-4.7-rc1
> Auto-merging fs/xfs/xfs_super.c
> Auto-merging fs/xfs/xfs_pnfs.c
> Auto-merging fs/xfs/xfs_mount.h
> Auto-merging fs/xfs/xfs_mount.c
> Auto-merging fs/xfs/xfs_file.c
> Auto-merging fs/xfs/xfs_bmap_util.c
> Auto-merging fs/xfs/xfs_aops.c
> Auto-merging fs/xfs/libxfs/xfs_bmap.c
> Auto-merging fs/namei.c
> Merge made by the 'recursive' strategy.
> The terminal did hang .... in 4.6
> I killed the git operation and did it again and now it says it's up to date.
>
> reinoud@router-dev:~/Downloads/kernel_current$ git merge xfs-for-linus-4.7-rc1
> Already up-to-date.
> reinoud@router-dev:~/Downloads/kernel_current$ git status
> On branch xfsdev-merge
>
> Is this correct, can I now build and test?
>
>>
>> -Eric
>>
>>> reinoud@router-dev:~/Downloads/kernel_current$  git remote update
>>> Fetching origin
>>> Fetching xfsdev
>>> fatal: remote error: access denied or repository not exported:
>>> /git/dgc/linux-xfs.git
>>> error: Could not fetch xfsdev
>>>
>>> I don't think I have access to git.kernel.org in terms of pushing. :)
>>> Or am I doing something else wrong.
>>> Forgive the trivial question.
>>>
>>> Btw, I started in the most current linus git tree.... or should I git
>>> 4.6.y and then do your suggestions?
>>>
>>> Thanks,
>>>
>>> Reinoud.
>>>
>>>>
>>>> And that should give you the XFS changes for 4.7-rc1 in a vanilla 4.6
>>>> tree. This merge is one of the things I test (i.e. send to my test
>>>> machiens for a round of xfstests and other stress) before sending a
>>>> pull request to Linus, so it should work just fine.
>>>>
>>>> Cheers,
>>>>
>>>> Dave.
>>>> --
>>>> Dave Chinner
>>>> david@fromorbit.com
>>>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Dave Chinner]

On Tue, Jun 14, 2016 at 11:40:23PM -0600, Reinoud Koornstra wrote:
> On Wed, Jun 8, 2016 at 9:42 PM, Reinoud Koornstra
> <reinoudkoornstra@gmail.com> wrote:
> > On Wed, Jun 8, 2016 at 8:56 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> >> On 6/8/16 9:53 PM, Reinoud Koornstra wrote:
> >>
> >>>> In your Linus git tree:
> >>>>
> >>>> $ git remote add xfsdev git://git.kernel.org/git/dgc/linux-xfs.git
> >>>> $ git remote update
> >>>> $ git checkout -b xfsdev-merge v4.6
> >>>> $ git merge xfsdev/xfs-for-linus-4.7-rc1
> >>>
> >>> Tried to do this:
> >>>
> >>> reinoud@router-dev:~/Downloads/kernel_current$  git remote add xfsdev
> >>> git://git.kernel.org/git/dgc/linux-xfs.git
> >>
> >> I think that should be:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git
> >
> > Ok That worked better indeed. :)
> 
> I've tested the way you and Dave described.
> Indeed, I do not see the issues appearing in that xfsdev tree.
> So it works good there.
> For verification, I tried when I was upon this state (so this is a good state):

Ok, that's good to hear. Now for some more testing: Al Viro just
pushed some fixes to the parallel lookup code that may fix this
problem. Al asked this question:

| Can that be triggered on 4e82901 + cherry-pick of e7d6ef979?
| Same for 9f541801 + e7d6ef979?

Those commits are all in the current Linus tree - would you be
able to test them? (i.e. check out tree to 4e82901, then just
cherry pick the single commit (e7d6ef979) on top of that).

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: crash in xfs in current

[Daniel Wagner]

> Ok, that's good to hear. Now for some more testing: Al Viro just
> pushed some fixes to the parallel lookup code that may fix this
> problem. Al asked this question:
> 
> | Can that be triggered on 4e82901 + cherry-pick of e7d6ef979?
> | Same for 9f541801 + e7d6ef979?
> 
> Those commits are all in the current Linus tree - would you be
> able to test them? (i.e. check out tree to 4e82901, then just
> cherry pick the single commit (e7d6ef979) on top of that).

Finally I found some time to do some testing.

In one shell, git did some checkouts:

  while true; do git checkout master && git checkout b4.0; done

While in the other shell I just rebuild a kernel:

  while true; do make clean && make -j200; done

4e82901              crashed after 10 minutes
4e82901 + e7d6ef979  no crash after 4 hours
9f541801             no crash after 2 hours
9f541801 + e7d6ef979 no crash after 12 hours

cheers,
daniel

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs