[GIT PULL] xfs: fixes for 5.3-rc5

[GIT PULL] xfs: fixes for 5.3-rc5

[Darrick J. Wong]

Hi Linus,

Here are a few more bug fixes that trickled in since -rc3.  It's
survived the usual xfstests runs and merges cleanly with this morning's
master.  Please let me know if anything strange happens.

--D

The following changes since commit afa1d96d1430c2138c545fb76e6dcb21222098d4:

  xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling() (2019-07-30 11:28:20 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.3-fixes-2

for you to fetch changes up to 8612de3f7ba6e900465e340516b8313806d27b2d:

  xfs: don't crash on null attr fork xfs_bmapi_read (2019-08-12 09:32:44 -0700)

----------------------------------------------------------------
Changes since last update:
- Fix crashes when the attr fork isn't present due to errors but inode
  inactivation tries to zap the attr data anyway.
- Convert more directory corruption debugging asserts to actual
  EFSCORRUPTED returns instead of blowing up later on.
- Don't fail writeback just because we ran out of memory allocating
  metadata log data.

----------------------------------------------------------------
Darrick J. Wong (2):
      xfs: remove more ondisk directory corruption asserts
      xfs: don't crash on null attr fork xfs_bmapi_read

Tetsuo Handa (1):
      fs: xfs: xfs_log: Don't use KM_MAYFAIL at xfs_log_reserve().

 fs/xfs/libxfs/xfs_bmap.c      | 29 +++++++++++++++++++++--------
 fs/xfs/libxfs/xfs_da_btree.c  | 19 ++++++++++++-------
 fs/xfs/libxfs/xfs_dir2_node.c |  3 ++-
 fs/xfs/xfs_log.c              |  5 +----
 4 files changed, 36 insertions(+), 20 deletions(-)

Re: [GIT PULL] xfs: fixes for 5.3-rc5

[Linus Torvalds]

Pulled. Just a quick note:

On Thu, Aug 15, 2019 at 10:13 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> - Convert more directory corruption debugging asserts to actual
>   EFSCORRUPTED returns instead of blowing up later on.

The proper error code looks like an obvious improvement, but I do
wonder if there should be some (ratelimited) system logging too?

I've seen a lot of programs that don't report errors very clearly and
might just silently stop running and as a sysadmin I'd think I'd
rather have something in the system logs than users saying "my app
crashes at startup"/

Maybe the logging ends up being there already - just done later. It
wasn't obvious from the patch, and I didn't check the whole callchain
(only direct callers).

                  Linus

Re: [GIT PULL] xfs: fixes for 5.3-rc5

[Darrick J. Wong]

On Thu, Aug 15, 2019 at 12:38:33PM -0700, Linus Torvalds wrote:
> Pulled. Just a quick note:
> 
> On Thu, Aug 15, 2019 at 10:13 AM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > - Convert more directory corruption debugging asserts to actual
> >   EFSCORRUPTED returns instead of blowing up later on.
> 
> The proper error code looks like an obvious improvement, but I do
> wonder if there should be some (ratelimited) system logging too?
> 
> I've seen a lot of programs that don't report errors very clearly and
> might just silently stop running and as a sysadmin I'd think I'd
> rather have something in the system logs than users saying "my app
> crashes at startup"/
> 
> Maybe the logging ends up being there already - just done later. It
> wasn't obvious from the patch, and I didn't check the whole callchain
> (only direct callers).

Metadata update failures hitting EFSCORRUPTED will leave a fair amount
of spew in dmesg both when we find the corrupt metadata and the update
transaction is aborted (which takes the filesystem down).  Read errors
get logged if we spot an error within a block but aren't consistently
logged when we discover problems between separate metadata objects.

FWIW I've wondered off and on if the VFS syscalls should be generating
some kind of audit trail when something returns an error message to
userspace?

--D

>                   Linus

Re: [GIT PULL] xfs: fixes for 5.3-rc5

[Linus Torvalds]

On Thu, Aug 15, 2019 at 1:05 PM Darrick J. Wong <darrick.wong@oracle.com> wrote:
>
> FWIW I've wondered off and on if the VFS syscalls should be generating
> some kind of audit trail when something returns an error message to
> userspace?

I don't think it makes sense for any random errors. ENOENT / EPERM /
EACCES / EISDIR etc are generally part of normal operation and
expected.

Things like actual filesystem corruption is different, but we haven't
really had good patterns for it. And I'd hate to add something like a
test for -EFSCORRUPTED when it's so rare. It makes more sense to do
any special handling when that is actually detected (when you might
want to do other things too, like make the filesystem be read-only or
whatever)

             Linus

Re: [GIT PULL] xfs: fixes for 5.3-rc5

[pr-tracker-bot]

The pull request you sent on Thu, 15 Aug 2019 10:13:47 -0700:

> git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.3-fixes-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a69e90512d9def6bd8064d84cff9ffd8b15eaa1b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker