From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs: clear sb->s_fs_info on mount failure
Date: Fri, 11 May 2018 09:46:44 -0400 [thread overview]
Message-ID: <20180511134644.GA105683@bfoster.bfoster> (raw)
In-Reply-To: <20180511020943.10132-3-david@fromorbit.com>
On Fri, May 11, 2018 at 12:09:43PM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> We recently had an oops reported on a 4.14 kernel in
> xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage
> and so the m_perag_tree lookup walked into lala land.
>
> Essentially, the machine was under memory pressure when the mount
> was being run, xfs_fs_fill_super() failed after allocating the
> xfs_mount and attaching it to sb->s_fs_info. It then cleaned up and
> freed the xfs_mount, but the sb->s_fs_info field still pointed to
> the freed memory. Hence when the superblock shrinker then ran
> it fell off the bad pointer.
>
> With the superblock shrinker problem fixed at teh VFS level, this
> stale s_fs_info pointer is still a problem - we use it
> unconditionally in ->put_super when the superblock is being torn
> down, and hence we can still trip over it after a ->fill_super
> call failure. Hence we need to clear s_fs_info if
> xfs-fs_fill_super() fails, and we need to check if it's valid in
> the places it can potentially be dereferenced after a ->fill_super
> failure.
>
> Signed-Off-By: Dave Chinner <dchinner@redhat.com>
> ---
> fs/xfs/xfs_super.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index a523eaeb3f29..d7e51b08919c 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -1772,6 +1772,7 @@ xfs_fs_fill_super(
> out_close_devices:
> xfs_close_devices(mp);
> out_free_fsname:
> + sb->s_fs_info = NULL;
> xfs_free_fsname(mp);
> kfree(mp);
> out:
> @@ -1789,6 +1790,10 @@ xfs_fs_put_super(
> {
> struct xfs_mount *mp = XFS_M(sb);
>
> + /* if ->fill_super failed, we have no mount to tear down */
> + if (!sb->s_fs_info)
> + return;
> +
I'd still prefer we use either XFS_M() or ->s_fs_info consistently in
this function, but that's a nit:
Reviewed-by: Brian Foster <bfoster@redhat.com>
> xfs_notice(mp, "Unmounting Filesystem");
> xfs_filestream_unmount(mp);
> xfs_unmountfs(mp);
> @@ -1798,6 +1803,8 @@ xfs_fs_put_super(
> xfs_destroy_percpu_counters(mp);
> xfs_destroy_mount_workqueues(mp);
> xfs_close_devices(mp);
> +
> + sb->s_fs_info = NULL;
> xfs_free_fsname(mp);
> kfree(mp);
> }
> @@ -1817,6 +1824,9 @@ xfs_fs_nr_cached_objects(
> struct super_block *sb,
> struct shrink_control *sc)
> {
> + /* Paranoia: catch incorrect calls during mount setup or teardown */
> + if (WARN_ON_ONCE(!sb->s_fs_info))
> + return 0;
> return xfs_reclaim_inodes_count(XFS_M(sb));
> }
>
> --
> 2.17.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2018-05-11 13:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 2:09 [PATCH 0/2] xfs: handle mount failures more cleanly Dave Chinner
2018-05-11 2:09 ` [PATCH 1/2] xfs: add mount delay debug option Dave Chinner
2018-05-12 0:28 ` Darrick J. Wong
2018-05-11 2:09 ` [PATCH 2/2] xfs: clear sb->s_fs_info on mount failure Dave Chinner
2018-05-11 13:46 ` Brian Foster [this message]
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=20180511134644.GA105683@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@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.