Florian Albrechtskirchinger
2012-Jul-28 13:41 UTC
No SysRq remount because sb->s_bdev is NULL
Hi,
During a SysRq emergency remount Btrfs mounts are not remounted. I tracked the
issue down to this line in do_emergency_remount() in fs/super.c:
if (sb->s_root && sb->s_bdev && (sb->s_flags &
MS_BORN) &&
!(sb->s_flags & MS_RDONLY))
s_bdev is NULL for Btrfs super blocks and subsequently do_remount_sb() is
never called. I couldn''t think of a solution, besides resorting to an
ugly
strcmp(sb->s_type->name, "btrfs"), without adding a field to
struct super_block
or similar changes.
Thoughts?
Flo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Just a first thought. Is there a possibility to write a dummy value into sb->s_bdev for btrfs super blocks. Thus it will not be NULL and everything in do_emergency_remount() in fs/super.c will work as wanted. Thanks, Andreas On 28.07.2012 15:41, Florian Albrechtskirchinger wrote:> Hi, > > During a SysRq emergency remount Btrfs mounts are not remounted. I tracked the > issue down to this line in do_emergency_remount() in fs/super.c: > if (sb->s_root && sb->s_bdev && (sb->s_flags & MS_BORN) && > !(sb->s_flags & MS_RDONLY)) > s_bdev is NULL for Btrfs super blocks and subsequently do_remount_sb() is > never called. I couldn''t think of a solution, besides resorting to an ugly > strcmp(sb->s_type->name, "btrfs"), without adding a field to struct super_block > or similar changes. > Thoughts? > > Flo > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Florian Albrechtskirchinger
2012-Jul-28 14:50 UTC
Re: No SysRq remount because sb->s_bdev is NULL
On Saturday, July 28, 2012 15:46:50 Andreas Philipp wrote:> On 28.07.2012 15:41, Florian Albrechtskirchinger wrote: > > During a SysRq emergency remount Btrfs mounts are not remounted. I tracked > > the issue down to this line in do_emergency_remount() in fs/super.c: > > if (sb->s_root && sb->s_bdev && (sb->s_flags & MS_BORN) && > > !(sb->s_flags & MS_RDONLY)) > > s_bdev is NULL for Btrfs super blocks and subsequently do_remount_sb() is > > never called. I couldn''t think of a solution, besides resorting to an ugly > > strcmp(sb->s_type->name, "btrfs"), without adding a field to struct > > super_block or similar changes. > > Thoughts? > > Just a first thought. Is there a possibility to write a dummy value into > sb->s_bdev for btrfs super blocks. Thus it will not be NULL and > everything in do_emergency_remount() in fs/super.c will work as wanted.Then other code paths testing sb->s_bdev for NULL and assuming a non-NULL sb->s_bdev is a valid block device would fail.Flo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28.07.2012 16:50, Florian Albrechtskirchinger wrote:> On Saturday, July 28, 2012 15:46:50 Andreas Philipp wrote: >> On 28.07.2012 15:41, Florian Albrechtskirchinger wrote: >>> During a SysRq emergency remount Btrfs mounts are not remounted. Itracked>>> the issue down to this line in do_emergency_remount() in fs/super.c: >>> if (sb->s_root && sb->s_bdev && (sb->s_flags & MS_BORN) && >>> !(sb->s_flags & MS_RDONLY)) >>> s_bdev is NULL for Btrfs super blocks and subsequentlydo_remount_sb() is>>> never called. I couldn''t think of a solution, besides resorting toan ugly>>> strcmp(sb->s_type->name, "btrfs"), without adding a field to struct >>> super_block or similar changes. >>> Thoughts? >> >> Just a first thought. Is there a possibility to write a dummy value into >> sb->s_bdev for btrfs super blocks. Thus it will not be NULL and >> everything in do_emergency_remount() in fs/super.c will work as wanted. > > Then other code paths testing sb->s_bdev for NULL and assuming anon-NULL sb->> s_bdev is a valid block device would fail.Sorry, I thought that there are separate checks whether the value of sb->s_bdev is a valid block device. Thanks, Andreas>> > > Flo-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQFBOrAAoJEIW3W1BiBxU7xCsH/RzDyJR7MneXLtDBQIQC43XS +jdaMrUIjEjBhs390iJJWebg5H6690XEO/wSM36ZMkHi0fSeJ7dC4WKjTtLyTkAB ok2+1Qix2LcqWxGSr9TC5OAjli3A8bl2Iy+P3bObfVOYnaTS781+ALl2PopiyZva ineLrXzGiUQoT059BK456ckceNkQ31YTbuwAEVP85ZdC4Bk8UviUYdoVtsFBb2aH 4UnHgnGdrPhz6BqIbxhrfTLNsNbnGskQ8MrxogRChv+P1SRKHslBKTLCvXugH5t4 iwrXtm1gtpFDWkmiMfYN6HpV/vGIrqstUns7zj/kYVbC2c0u4QGBSZLhy9S7UF4=1I+D -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html