[backport request][stable] xfs: xfstests generic/538 failed on xfs

[backport request][stable] xfs: xfstests generic/538 failed on xfs

[Alvin Zheng]

Hi,

     I  was using kernel v4.19.y and found that it cannot pass the 
generic/538 due to data corruption. I notice that upstream has fix this 
issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y 
backport this patch?

Best regards,

Alvin

Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

[Luis Chamberlain]

On Thu, Jun 27, 2019 at 08:10:56PM +0800, Alvin Zheng wrote:
> Hi,
> 
>     I  was using kernel v4.19.y and found that it cannot pass the
> generic/538 due to data corruption. I notice that upstream has fix this
> issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y
> backport this patch?

Hey Alvin,

Thanks for Bringing this to attention.  I'll look into this a bit more.
Time for a new set of stable fixes for v4.19.y. Of course, I welcome
Briant's feedback, but if he's busy I'll still look into it.

  Luis

Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

[Amir Goldstein]

On Thu, Jun 27, 2019 at 6:55 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Thu, Jun 27, 2019 at 08:10:56PM +0800, Alvin Zheng wrote:
> > Hi,
> >
> >     I  was using kernel v4.19.y and found that it cannot pass the
> > generic/538 due to data corruption. I notice that upstream has fix this
> > issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y
> > backport this patch?
>
> Hey Alvin,
>
> Thanks for Bringing this to attention.  I'll look into this a bit more.
> Time for a new set of stable fixes for v4.19.y. Of course, I welcome
> Briant's feedback, but if he's busy I'll still look into it.
>

FWIW, I tested -g quick on xfs with reflink=1,rmapbt=1 and did not
observe any regressions from v4.19.55.

Luis, sorry I forgot to CC you on a request I just sent to consider 4 xfs
patches for stable to fix generic/529 and generic/530:

3b50086f0c0d xfs: don't overflow xattr listent buffer
e1f6ca113815 xfs: rename m_inotbt_nores to m_finobt_nores
15a268d9f263 xfs: reserve blocks for ifree transaction during log recovery
c4a6bf7f6cc7 xfs: don't ever put nlink > 0 inodes on the unlinked list

If you can run those patches through your setup that would be great.

Thanks,
Amir.

Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

[Luis Chamberlain]

On Thu, Jun 27, 2019 at 07:18:40PM +0300, Amir Goldstein wrote:
> On Thu, Jun 27, 2019 at 6:55 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > On Thu, Jun 27, 2019 at 08:10:56PM +0800, Alvin Zheng wrote:
> > > Hi,
> > >
> > >     I  was using kernel v4.19.y and found that it cannot pass the
> > > generic/538 due to data corruption. I notice that upstream has fix this
> > > issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y
> > > backport this patch?
> >
> > Hey Alvin,
> >
> > Thanks for Bringing this to attention.  I'll look into this a bit more.
> > Time for a new set of stable fixes for v4.19.y. Of course, I welcome
> > Briant's feedback, but if he's busy I'll still look into it.
> >
> 
> FWIW, I tested -g quick on xfs with reflink=1,rmapbt=1 and did not
> observe any regressions from v4.19.55.

As you may recall I test all agreed upon configurations. Just one is not
enough.

> Luis, sorry I forgot to CC you on a request I just sent to consider 4 xfs
> patches for stable to fix generic/529 and generic/530:
> 
> 3b50086f0c0d xfs: don't overflow xattr listent buffer
> e1f6ca113815 xfs: rename m_inotbt_nores to m_finobt_nores
> 15a268d9f263 xfs: reserve blocks for ifree transaction during log recovery
> c4a6bf7f6cc7 xfs: don't ever put nlink > 0 inodes on the unlinked list
> 
> If you can run those patches through your setup that would be great.

Sure, it may take 1-2 weeks, just a heads up. If you're OK with waiting
then great. Otherwise I personally cannot vouch for them. What types of
tests did you run and what configurations?

  Luis

Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

[Amir Goldstein]

On Fri, Jun 28, 2019 at 12:35 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Thu, Jun 27, 2019 at 07:18:40PM +0300, Amir Goldstein wrote:
> > On Thu, Jun 27, 2019 at 6:55 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > >
> > > On Thu, Jun 27, 2019 at 08:10:56PM +0800, Alvin Zheng wrote:
> > > > Hi,
> > > >
> > > >     I  was using kernel v4.19.y and found that it cannot pass the
> > > > generic/538 due to data corruption. I notice that upstream has fix this
> > > > issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y
> > > > backport this patch?
> > >
> > > Hey Alvin,
> > >
> > > Thanks for Bringing this to attention.  I'll look into this a bit more.
> > > Time for a new set of stable fixes for v4.19.y. Of course, I welcome
> > > Briant's feedback, but if he's busy I'll still look into it.
> > >
> >
> > FWIW, I tested -g quick on xfs with reflink=1,rmapbt=1 and did not
> > observe any regressions from v4.19.55.
>
> As you may recall I test all agreed upon configurations. Just one is not
> enough.

Of course. It's just a heads up that testing looks sane so far.

>
> > Luis, sorry I forgot to CC you on a request I just sent to consider 4 xfs
> > patches for stable to fix generic/529 and generic/530:
> >
> > 3b50086f0c0d xfs: don't overflow xattr listent buffer
> > e1f6ca113815 xfs: rename m_inotbt_nores to m_finobt_nores
> > 15a268d9f263 xfs: reserve blocks for ifree transaction during log recovery
> > c4a6bf7f6cc7 xfs: don't ever put nlink > 0 inodes on the unlinked list
> >
> > If you can run those patches through your setup that would be great.
>
> Sure, it may take 1-2 weeks, just a heads up. If you're OK with waiting
> then great. Otherwise I personally cannot vouch for them. What types of
> tests did you run and what configurations?
>

So far I tested, -g quick with reflink=1,rmapbt=1.

Sasha wrote that more results will be in tomorrow...

Thanks,
Amir.

Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

[Luis Chamberlain]

On Fri, Jun 28, 2019 at 07:46:34AM +0300, Amir Goldstein wrote:
> On Fri, Jun 28, 2019 at 12:35 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > On Thu, Jun 27, 2019 at 07:18:40PM +0300, Amir Goldstein wrote:
> > > On Thu, Jun 27, 2019 at 6:55 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > >
> > > > On Thu, Jun 27, 2019 at 08:10:56PM +0800, Alvin Zheng wrote:
> > > > > Hi,
> > > > >
> > > > >     I  was using kernel v4.19.y and found that it cannot pass the
> > > > > generic/538 due to data corruption. I notice that upstream has fix this
> > > > > issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y
> > > > > backport this patch?
> > > >
> > > > Hey Alvin,
> > > >
> > > > Thanks for Bringing this to attention.  I'll look into this a bit more.
> > > > Time for a new set of stable fixes for v4.19.y. Of course, I welcome
> > > > Briant's feedback, but if he's busy I'll still look into it.
> > > >
> > >
> > > FWIW, I tested -g quick on xfs with reflink=1,rmapbt=1 and did not
> > > observe any regressions from v4.19.55.
> >
> > As you may recall I test all agreed upon configurations. Just one is not
> > enough.
> 
> Of course. It's just a heads up that testing looks sane so far.
> 
> >
> > > Luis, sorry I forgot to CC you on a request I just sent to consider 4 xfs
> > > patches for stable to fix generic/529 and generic/530:
> > >
> > > 3b50086f0c0d xfs: don't overflow xattr listent buffer
> > > e1f6ca113815 xfs: rename m_inotbt_nores to m_finobt_nores
> > > 15a268d9f263 xfs: reserve blocks for ifree transaction during log recovery
> > > c4a6bf7f6cc7 xfs: don't ever put nlink > 0 inodes on the unlinked list
> > >
> > > If you can run those patches through your setup that would be great.
> >
> > Sure, it may take 1-2 weeks, just a heads up. If you're OK with waiting
> > then great. Otherwise I personally cannot vouch for them. What types of
> > tests did you run and what configurations?
> >
> 
> So far I tested, -g quick with reflink=1,rmapbt=1.
> 
> Sasha wrote that more results will be in tomorrow...

I'd rather be cautious, how about we wait until I also confirm
no regressions as well. In this case since we already have candidates
you identified, and Darrick vouchces for, I can just jump start the
process and deal with both manually reviewing each of these changes
and also confirming no regressions are in place on my tests as well.

Then we'd have at least 3 XFS pair of eyeballs reviewing and at least
2 full independent tests vouching for these.

  Luis

Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

[Amir Goldstein]

On Sat, Jun 29, 2019 at 12:50 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Fri, Jun 28, 2019 at 07:46:34AM +0300, Amir Goldstein wrote:
> > On Fri, Jun 28, 2019 at 12:35 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > >
> > > On Thu, Jun 27, 2019 at 07:18:40PM +0300, Amir Goldstein wrote:
> > > > On Thu, Jun 27, 2019 at 6:55 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > > >
> > > > > On Thu, Jun 27, 2019 at 08:10:56PM +0800, Alvin Zheng wrote:
> > > > > > Hi,
> > > > > >
> > > > > >     I  was using kernel v4.19.y and found that it cannot pass the
> > > > > > generic/538 due to data corruption. I notice that upstream has fix this
> > > > > > issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y
> > > > > > backport this patch?
> > > > >
> > > > > Hey Alvin,
> > > > >
> > > > > Thanks for Bringing this to attention.  I'll look into this a bit more.
> > > > > Time for a new set of stable fixes for v4.19.y. Of course, I welcome
> > > > > Briant's feedback, but if he's busy I'll still look into it.
> > > > >
> > > >
> > > > FWIW, I tested -g quick on xfs with reflink=1,rmapbt=1 and did not
> > > > observe any regressions from v4.19.55.
> > >
> > > As you may recall I test all agreed upon configurations. Just one is not
> > > enough.
> >
> > Of course. It's just a heads up that testing looks sane so far.
> >
> > >
> > > > Luis, sorry I forgot to CC you on a request I just sent to consider 4 xfs
> > > > patches for stable to fix generic/529 and generic/530:
> > > >
> > > > 3b50086f0c0d xfs: don't overflow xattr listent buffer
> > > > e1f6ca113815 xfs: rename m_inotbt_nores to m_finobt_nores
> > > > 15a268d9f263 xfs: reserve blocks for ifree transaction during log recovery
> > > > c4a6bf7f6cc7 xfs: don't ever put nlink > 0 inodes on the unlinked list
> > > >
> > > > If you can run those patches through your setup that would be great.
> > >
> > > Sure, it may take 1-2 weeks, just a heads up. If you're OK with waiting
> > > then great. Otherwise I personally cannot vouch for them. What types of
> > > tests did you run and what configurations?
> > >
> >
> > So far I tested, -g quick with reflink=1,rmapbt=1.

FYI, -g auto found no regression with reflink=1,rmapbt=1.

> >
> > Sasha wrote that more results will be in tomorrow...
>
> I'd rather be cautious, how about we wait until I also confirm
> no regressions as well. In this case since we already have candidates
> you identified, and Darrick vouchces for, I can just jump start the
> process and deal with both manually reviewing each of these changes
> and also confirming no regressions are in place on my tests as well.
>
> Then we'd have at least 3 XFS pair of eyeballs reviewing and at least
> 2 full independent tests vouching for these.
>

Sure, that'd be great. How long does your full run take?

Thanks,
Amir.

Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

[Luis Chamberlain]

On Sat, Jun 29, 2019 at 10:41:35AM +0300, Amir Goldstein wrote:
> On Sat, Jun 29, 2019 at 12:50 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > On Fri, Jun 28, 2019 at 07:46:34AM +0300, Amir Goldstein wrote:
> > > On Fri, Jun 28, 2019 at 12:35 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > >
> > > > On Thu, Jun 27, 2019 at 07:18:40PM +0300, Amir Goldstein wrote:
> > > > > On Thu, Jun 27, 2019 at 6:55 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > > > >
> > > > > > On Thu, Jun 27, 2019 at 08:10:56PM +0800, Alvin Zheng wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > >     I  was using kernel v4.19.y and found that it cannot pass the
> > > > > > > generic/538 due to data corruption. I notice that upstream has fix this
> > > > > > > issue with commit 2032a8a27b5cc0f578d37fa16fa2494b80a0d00a. Will v4.19.y
> > > > > > > backport this patch?
> > > > > >
> > > > > > Hey Alvin,
> > > > > >
> > > > > > Thanks for Bringing this to attention.  I'll look into this a bit more.
> > > > > > Time for a new set of stable fixes for v4.19.y. Of course, I welcome
> > > > > > Briant's feedback, but if he's busy I'll still look into it.
> > > > > >
> > > > >
> > > > > FWIW, I tested -g quick on xfs with reflink=1,rmapbt=1 and did not
> > > > > observe any regressions from v4.19.55.
> > > >
> > > > As you may recall I test all agreed upon configurations. Just one is not
> > > > enough.
> > >
> > > Of course. It's just a heads up that testing looks sane so far.
> > >
> > > >
> > > > > Luis, sorry I forgot to CC you on a request I just sent to consider 4 xfs
> > > > > patches for stable to fix generic/529 and generic/530:
> > > > >
> > > > > 3b50086f0c0d xfs: don't overflow xattr listent buffer
> > > > > e1f6ca113815 xfs: rename m_inotbt_nores to m_finobt_nores
> > > > > 15a268d9f263 xfs: reserve blocks for ifree transaction during log recovery
> > > > > c4a6bf7f6cc7 xfs: don't ever put nlink > 0 inodes on the unlinked list
> > > > >
> > > > > If you can run those patches through your setup that would be great.
> > > >
> > > > Sure, it may take 1-2 weeks, just a heads up. If you're OK with waiting
> > > > then great. Otherwise I personally cannot vouch for them. What types of
> > > > tests did you run and what configurations?
> > > >
> > >
> > > So far I tested, -g quick with reflink=1,rmapbt=1.
> 
> FYI, -g auto found no regression with reflink=1,rmapbt=1.
> 
> > >
> > > Sasha wrote that more results will be in tomorrow...
> >
> > I'd rather be cautious, how about we wait until I also confirm
> > no regressions as well. In this case since we already have candidates
> > you identified, and Darrick vouchces for, I can just jump start the
> > process and deal with both manually reviewing each of these changes
> > and also confirming no regressions are in place on my tests as well.
> >
> > Then we'd have at least 3 XFS pair of eyeballs reviewing and at least
> > 2 full independent tests vouching for these.
> >
> 
> Sure, that'd be great. How long does your full run take?

Not long, its just I wanted to also add xunit processing support onto
oscheck as well. I'll start on that now, hopefully it'll all be done
and tested by end of next week.

  Luis

Re: [backport request][stable] xfs: xfstests generic/538 failed on xfs

[Luis Chamberlain]

On Tue, Jul 2, 2019 at 12:34 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> On Sat, Jun 29, 2019 at 10:41:35AM +0300, Amir Goldstein wrote:
> that'd be great. How long does your full run take?
>
> Not long, its just I wanted to also add xunit processing support onto
> oscheck as well. I'll start on that now, hopefully it'll all be done
> and tested by end of next week.

I'm now at a point where oscheck .. is looking sharp, and has xunit
processing and even an automatic way to expand our expunge list.... :)

So it will be super easy for me to test this now, in about two days
max I should have results.

  Luis