From: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
To: Andreas Philipp <philipp.andreas@gmail.com>
Cc: btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: No SysRq remount because sb->s_bdev is NULL
Date: Sat, 28 Jul 2012 16:50:38 +0200 [thread overview]
Message-ID: <2108513.KBpvBiH5fV@nezir> (raw)
In-Reply-To: <5013ED4A.3070609@gmail.com>
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
next prev parent reply other threads:[~2012-07-28 14:50 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 [this message]
2012-07-28 16:30 ` Andreas Philipp
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=2108513.KBpvBiH5fV@nezir \
--to=falbrechtskirchinger@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=philipp.andreas@gmail.com \
/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.