UBIFS is not remounted read-only from within do_emergency_remount

[Artem Bityutskiy]

On Tue, 2012-07-31 at 13:24 +0200, Alexander Stein wrote:
> upon testing do_emergency_remount from a power fail interrupt (using the 
> workqueue of course), we noticed UBIFS is not remounted read-only afterwards.
> The current code in do_emergency_remount checks if the kernel actually needs 
> to remount a filesystem using the following code:
> > if (sb->s_root && sb->s_bdev && (sb->s_flags & MS_BORN) &&
> >     !(sb->s_flags & MS_RDONLY)) {
> >         /*
> >          * What lock protects sb->s_flags??
> >          */
> >         do_remount_sb(sb, MS_RDONLY, NULL, 1);
> > }
> 
> I'm not in the details of this part of the kernel, but I suspect that sb-
> >s_bdev is NULL for UBIFS as it has no block device, but the character device 
> /dev/ubiX_Y instead. I have the information from a collegue that removing the 
> check for testing purposes for sb->s_bdev mounts UBIFS read-only.
> Any comments/ideas how to remount UBIFS as read-only from 
> do_emergency_remount?

I think this check is there to prevent file-systems like sysfs, tmpfs,
procfs, cgroup and debugfs from re-mounting R/O. If we just remove the
'sb->s_bdev' check - they all become R/O as well. For me it sounds OK,
but I've never used this functionality, so not sure.


-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120824/c8f1e0a9/attachment.sig>