From: Jan Kara <jack@suse.cz>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH 0/2 v2] vfs: Fix crashes when reading /proc/mounts
Date: Mon, 21 Jan 2019 17:58:30 +0100 [thread overview]
Message-ID: <20190121165830.GE21694@quack2.suse.cz> (raw)
In-Reply-To: <20181218134642.21219-1-jack@suse.cz>
Ping Al?
On Tue 18-12-18 14:46:40, Jan Kara wrote:
> Hello,
>
> this is a second revision of the patch series which aims at fixing possible
> races between functions formatting output for /proc/mounts and friends and
> remount. Especially ->show_options functions of filesystems are not counting
> with the fact that options can change under them and thus races can result in
> bogus output or outright crashes (like was the case with ext4 handling of quota
> mount option, or udf could crash when printing charset name, or xfs when
> printing log device name etc.).
>
> Since v1, I have changed the logic so that all the locking & restart magic
> happens in m_show() so that we don't bail back to traverse(), then m_start(),
> and then back to m_show(). Al, is it better this way?
>
> I was not able to get rid of the hold_sb() helper which you didn't like much as
> namespace_sem is private to fs/namespace.c and we need to drop it after
> acquiring sb reference and before blocking on sb->s_umount semaphore. So
> hold_sb() still looked like the least painful solution.
>
> Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2019-01-21 16:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 13:46 [PATCH 0/2 v2] vfs: Fix crashes when reading /proc/mounts Jan Kara
2018-12-18 13:46 ` [PATCH 1/2] vfs: Provide function to grab superblock reference Jan Kara
2018-12-18 13:46 ` [PATCH 2/2] proc: Protect readers of /proc/mounts from remount Jan Kara
2019-01-21 16:58 ` Jan Kara [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=20190121165830.GE21694@quack2.suse.cz \
--to=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.