All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Sasha Levin <sashal@kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	stable <stable@vger.kernel.org>
Subject: Re: [STABLE 4.19] fixes for xfs memory and fs corruption
Date: Thu, 27 Jun 2019 10:08:09 -0700	[thread overview]
Message-ID: <20190627170809.GD5179@magnolia> (raw)
In-Reply-To: <CAOQ4uximAfJjNdunY2xK_1DwC2G7v31XWbv64AdO9nYdExUsVw@mail.gmail.com>

On Thu, Jun 27, 2019 at 07:12:48PM +0300, Amir Goldstein wrote:
> Darrick,
> 
> Can I have your blessing on the choice of these upstream commits
> as stable candidates?
> I did not observe any xfstests regressions when testing v4.19.55
> with these patches applied.

All four commits look reasonable to me. :)

--D

> Sasha,
> 
> Can you run these patches though your xfstests setup?
> They fix nasty bugs.
> 
> Make sure to update xfsprogs to very latest, because
> generic/530 used to blow up (OOM) my test machine...
> 
> >
> > The first patch fixes a memory corruption that syzkaller found in the
> > attr listent code;
> 
> 3b50086f0c0d xfs: don't overflow xattr listent buffer
> 
> > see "generic: posix acl extended attribute memory
> > corruption test" for the relevant regression test.
> 
> Fixed generic/529
> 
> >
> > Patches 2 fixes problems found in XFS's unlinked inode recovery code
> > that were unearthed by some new testcases.  We're logging nlink==1 temp
> > files on the iunlinked list (and then the vfs sets nlink to 0 without
> > telling us) which means that we leak them in recovery if we crash
> > immediately after the committing the creation of the temp file.
> >
> > Patch 3 fixes the problem that ifree during recovery can expand the
> > finobt but we need to force the ifree code to reserve blocks for the
> > transaction because perag reservations aren't set up yet.
> 
> 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
> 
> >
> > See "[PATCH v2 2/2] generic: check the behavior of programs opening a
> > lot of O_TMPFILE files" for the regression test.
> >
> 
> Fixes generic/530
> 
> Thanks,
> Amir.

  reply	other threads:[~2019-06-27 17:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 20:50 [PATCH 1/3] xfs: don't overflow xattr listent buffer Darrick J. Wong
2019-02-13 20:50 ` [PATCH 2/3] xfs: don't ever put nlink > 0 inodes on the unlinked list Darrick J. Wong
2019-02-14  8:15   ` Christoph Hellwig
2019-02-14 16:03     ` Darrick J. Wong
2019-02-14 21:41   ` Christoph Hellwig
2019-02-13 20:50 ` [PATCH 3/3] xfs: reserve blocks for ifree transaction during log recovery Darrick J. Wong
2019-02-14  8:17   ` Christoph Hellwig
2019-02-14 15:58     ` Darrick J. Wong
2019-02-13 20:58 ` [PATCH 1/3] xfs: don't overflow xattr listent buffer Darrick J. Wong
2019-06-27 16:12   ` [STABLE 4.19] fixes for xfs memory and fs corruption Amir Goldstein
2019-06-27 17:08     ` Darrick J. Wong [this message]
2019-06-27 23:32     ` Sasha Levin
2019-07-03  2:47       ` Sasha Levin
2019-02-14  8:11 ` [PATCH 1/3] xfs: don't overflow xattr listent buffer Christoph Hellwig

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=20190627170809.GD5179@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=amir73il@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.