linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] [PATCH] vfs: remount all file-systems R/O on emergency remount.
@ 2012-08-24  7:26 Artem Bityutskiy
  2012-08-24 13:20 ` Marco Stornelli
  0 siblings, 1 reply; 4+ messages in thread
From: Artem Bityutskiy @ 2012-08-24  7:26 UTC (permalink / raw)
  To: Al Viro; +Cc: Linux FS Maling List, Linux Kernel Maling List, Alexander Stein

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>
---
 fs/super.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/super.c b/fs/super.c
index 0902cfa..95cf173 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -812,7 +812,7 @@ static void do_emergency_remount(struct work_struct *work)
 		sb->s_count++;
 		spin_unlock(&sb_lock);
 		down_write(&sb->s_umount);
-		if (sb->s_root && sb->s_bdev && (sb->s_flags & MS_BORN) &&
+		if (sb->s_root && (sb->s_flags & MS_BORN) &&
 		    !(sb->s_flags & MS_RDONLY)) {
 			/*
 			 * What lock protects sb->s_flags??
-- 
1.7.10.4


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [RFC] [PATCH] vfs: remount all file-systems R/O on emergency remount.
  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
  2012-08-24 13:38   ` Artem Bityutskiy
  0 siblings, 1 reply; 4+ messages in thread
From: Marco Stornelli @ 2012-08-24 13:20 UTC (permalink / raw)
  To: Artem Bityutskiy
  Cc: Al Viro, Linux FS Maling List, Linux Kernel Maling List,
	Alexander Stein

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] [PATCH] vfs: remount all file-systems R/O on emergency remount.
  2012-08-24 13:20 ` Marco Stornelli
@ 2012-08-24 13:38   ` Artem Bityutskiy
  2012-08-24 13:51     ` Marco Stornelli
  0 siblings, 1 reply; 4+ messages in thread
From: Artem Bityutskiy @ 2012-08-24 13:38 UTC (permalink / raw)
  To: Marco Stornelli
  Cc: Al Viro, Linux FS Maling List, Linux Kernel Maling List,
	Alexander Stein

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

On Fri, 2012-08-24 at 15:20 +0200, Marco Stornelli wrote:
> 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.

May be. Or may be you are in situation that you really want all
processes top modifying anything in debugfs. This depends on the
"emergency" you deal with. You can always re-mount debugfs back to rw by
hands using something like:

	mount -t debufs -o remount,rw none /sys/kernel/debug

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] [PATCH] vfs: remount all file-systems R/O on emergency remount.
  2012-08-24 13:38   ` Artem Bityutskiy
@ 2012-08-24 13:51     ` Marco Stornelli
  0 siblings, 0 replies; 4+ messages in thread
From: Marco Stornelli @ 2012-08-24 13:51 UTC (permalink / raw)
  To: dedekind1
  Cc: Al Viro, Linux FS Maling List, Linux Kernel Maling List,
	Alexander Stein

Il 24/08/2012 15:38, Artem Bityutskiy ha scritto:
> On Fri, 2012-08-24 at 15:20 +0200, Marco Stornelli wrote:
>> 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.
>
> May be. Or may be you are in situation that you really want all
> processes top modifying anything in debugfs. This depends on the
> "emergency" you deal with. You can always re-mount debugfs back to rw by
> hands using something like:
>
> 	mount -t debufs -o remount,rw none /sys/kernel/debug
>

Obviously :) Maybe it's the sign that we want let the user decide what 
to do if the "default behavior" is not ok.

Note: has ubifs got the field s_mtd != null? Maybe to solve the specific 
problem we could just write (sb->s_bdev != NULL || sb->s_mtd != NULL).

Marco

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-08-24 13:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2012-08-24 13:38   ` Artem Bityutskiy
2012-08-24 13:51     ` Marco Stornelli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).