No SysRq remount because sb->s_bdev is NULL

No SysRq remount because sb->s_bdev is NULL

[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

Re: No SysRq remount because sb->s_bdev is NULL

[Andreas Philipp]

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

Re: No SysRq remount because sb->s_bdev is NULL

[Florian Albrechtskirchinger]

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

Re: No SysRq remount because sb->s_bdev is NULL

[Andreas Philipp]

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