From: Andreas Philipp <philipp.andreas@gmail.com>
To: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
Cc: btrfs <linux-btrfs@vger.kernel.org>,
Andreas Philipp <philipp.andreas@gmail.com>
Subject: Re: No SysRq remount because sb->s_bdev is NULL
Date: Sat, 28 Jul 2012 18:30:36 +0200 [thread overview]
Message-ID: <501413AC.1070900@gmail.com> (raw)
In-Reply-To: <2108513.KBpvBiH5fV@nezir>
-----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-----
prev parent reply other threads:[~2012-07-28 16:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-28 13:41 No SysRq remount because sb->s_bdev is NULL Florian Albrechtskirchinger
2012-07-28 13:46 ` Andreas Philipp
2012-07-28 14:50 ` Florian Albrechtskirchinger
2012-07-28 16:30 ` Andreas Philipp [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=501413AC.1070900@gmail.com \
--to=philipp.andreas@gmail.com \
--cc=falbrechtskirchinger@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.