From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marco Stornelli Subject: Re: [RFC] [PATCH] vfs: remount all file-systems R/O on emergency remount. Date: Fri, 24 Aug 2012 15:20:39 +0200 Message-ID: <50377FA7.50708@gmail.com> References: <1345793166-14230-1-git-send-email-dedekind1@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Al Viro , Linux FS Maling List , Linux Kernel Maling List , Alexander Stein To: Artem Bityutskiy Return-path: In-Reply-To: <1345793166-14230-1-git-send-email-dedekind1@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Il 24/08/2012 09:26, Artem Bityutskiy ha scritto: > From: Artem Bityutskiy > > 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 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