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
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()infs/super.c:
if (sb->s_root&&sb->s_bdev&& (sb->s_flags&MS_BORN) &&!(sb->s_flags & MS_RDONLY))
s_bdevis NULL for Btrfs super blocks and subsequentlydo_remount_sb()is never called. I couldn't think of a solution, besides resorting to an uglystrcmp(sb->s_type->name, "btrfs"), without adding a field to structsuper_blockor 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
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()infs/super.c:
if (sb->s_root&&sb->s_bdev&& (sb->s_flags&MS_BORN) &&!(sb->s_flags & MS_RDONLY))
s_bdevis NULL for Btrfs super blocks and subsequentlydo_remount_sb()is never called. I couldn't think of a solution, besides resorting to an uglystrcmp(sb->s_type->name, "btrfs"), without adding a field to structsuper_blockor similar changes.
Thoughts?
Quoted 3 lines
Just a first thought. Is there a possibility to write a dummy value into
sb->s_bdevfor btrfs super blocks. Thus it will not be NULL and everything indo_emergency_remount()infs/super.cwill work as wanted.
Then other code paths testing sb->s_bdev for NULL and assuming a non-NULL sb-
Quoted 1 line
s_bdevis a valid block device would fail.
Flo
-----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()infs/super.c:
if (sb->s_root&&sb->s_bdev&& (sb->s_flags&MS_BORN) && !(sb->s_flags &MS_RDONLY))s_bdevis 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 structsuper_blockor similar changes.
Thoughts?Just a first thought. Is there a possibility to write a dummy value into
sb->s_bdevfor btrfs super blocks. Thus it will not be NULL and everything indo_emergency_remount()infs/super.cwill work as wanted.Then other code paths testing
sb->s_bdevfor NULL and assuming a
non-NULL sb-
Quoted 1 line
Quoted 1 line
s_bdevis 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-----