From: Marco Stornelli <marco.stornelli@gmail.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Linux FS Maling List <linux-fsdevel@vger.kernel.org>,
Linux Kernel Maling List <linux-kernel@vger.kernel.org>,
Alexander Stein <alexander.stein@systec-electronic.com>
Subject: Re: [RFC] [PATCH] vfs: remount all file-systems R/O on emergency remount.
Date: Fri, 24 Aug 2012 15:20:39 +0200 [thread overview]
Message-ID: <50377FA7.50708@gmail.com> (raw)
In-Reply-To: <1345793166-14230-1-git-send-email-dedekind1@gmail.com>
Il 24/08/2012 09:26, Artem Bityutskiy ha scritto:
> From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
>
> Currently the emergency remount (triggered by Sysrq-u) re-mounting only
> those file-systems R/O, which have an associated block device (sb->s_bdev).
> This does not work for file-systems like UBIFS and JFFS2 which work on top
> of MTD devices (character devices) and always have sb->s_bdev = NULL.
>
> This also does not work for tmpfs.
>
> Most probably the intention was to avoid re-mounting R/O file-systems like
> procfs, sysfs, cgroup, and debugfs. However, I do not really see why not
> to remount them R/O as well in case of emergency.
>
> This patch removes the 'sb->s_bdev != NULL' check from
> 'do_emergency_remount()', so _all_ file-systems will be re-mounted R/O.
>
> Tested in Fedora - all file-systems (ext4, ubifs, procfs, sysfs, cgroup, and
> debugfs) become R/O on Sysrq-u with this patch.
>
> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Does it make sense to remount r/o for example debugfs in this case?
Maybe if there is something wrong I want enable something to catch debug
info. Similar things for other pseudo-fs. Sure, the s_bdev seems a
strong check. We could add a new flag to know if the emergency remount
should be happen. It would give us the fs granularity, and maybe it
could be turned on/off with the mount.
Marco
next prev parent reply other threads:[~2012-08-24 13:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-24 7:26 [RFC] [PATCH] vfs: remount all file-systems R/O on emergency remount Artem Bityutskiy
2012-08-24 13:20 ` Marco Stornelli [this message]
2012-08-24 13:38 ` Artem Bityutskiy
2012-08-24 13:51 ` Marco Stornelli
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=50377FA7.50708@gmail.com \
--to=marco.stornelli@gmail.com \
--cc=alexander.stein@systec-electronic.com \
--cc=dedekind1@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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.