Skip to contentSkip to conversation

No SysRq remount because sb->s_bdev is NULL

DISCUSSION Florian Albrechtskirchinger 2 participants 4 messages Jul 28, 2012 Btrfs file system

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

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

Quoted 17 lines · Florian Albrechtskirchinger

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
Quoted 11 lines · On Saturday, July 28, 2012 15:46:50 Andreas Philipp wrote:
Quoted 9 lines · Florian Albrechtskirchinger

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?

Quoted 3 lines

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-

Quoted 1 line

s_bdev is a valid block device would fail.

Flo

#3 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 3 lines · Florian Albrechtskirchinger
Quoted 2 lines · On Saturday, July 28, 2012 15:46:50 Andreas Philipp wrote:
Quoted 1 line · Florian Albrechtskirchinger

During a SysRq emergency remount Btrfs mounts are not remounted. I

tracked

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

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

Quoted 1 line
Quoted 1 line
Quoted 1 line

never called. I couldn't think of a solution, besides resorting to

an ugly

Quoted 9 lines
Quoted 7 lines
Quoted 3 lines

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-

Quoted 1 line
Quoted 1 line

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

Quoted 3 lines
Quoted 1 line

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-----