All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Richard Weinberger <richard.weinberger@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [BUG] reproducable ubifs reboot assert and corruption
Date: Wed, 29 Jan 2014 08:30:45 +0100	[thread overview]
Message-ID: <52E8AE25.8080502@nod.at> (raw)
In-Reply-To: <20140129053238.GA6035@gmail.com>

Am 29.01.2014 06:32, schrieb Andrew Ruder:
> Ok, I've got some more useful information.  I have been adding
> a multitude of WARN_ON's and prink's all over the remount code and have
> come up with the attached log.
> 
> A little bit of explanation:
> 
> Line 1: sync_filesystem (from do_remount_sb)
> Line 188: sync_filesystem ends
> Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur
> during sync_filesystem.  Before each warning I print the inode pointer.
> Line 197: read-only remount has completely finished (this message is
> from userspace post remount)
> Line 199: a sync is called, there are apparently dirty inodes in our
> now-readonly ubifs filesystem
> Line 215: failed assert that occurs because the writeback triggers for
> inode 0xd75b9450 (see line 41, it got in with a sys_write while we were
> running our sync_filesystem in do_remount_sb)
> 
> Does this help?  It looks like there is a race condition between the
> writeback code and the remount read-only.  Nothing is done to lock out
> writes during the first half of the do_remount_sb and some stuff makes
> it into the writeback worker queue while we are busy syncing the
> filesystem only to trigger later when ubifs has decided it is
> read-only...
> 
> Note: I only barely know what I am talking about - filesystems still not
> my forte :)

BTW: Can you please share your .config?

Thanks,
//richard

WARNING: multiple messages have this Message-ID (diff)
From: richard@nod.at (Richard Weinberger)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG] reproducable ubifs reboot assert and corruption
Date: Wed, 29 Jan 2014 08:30:45 +0100	[thread overview]
Message-ID: <52E8AE25.8080502@nod.at> (raw)
In-Reply-To: <20140129053238.GA6035@gmail.com>

Am 29.01.2014 06:32, schrieb Andrew Ruder:
> Ok, I've got some more useful information.  I have been adding
> a multitude of WARN_ON's and prink's all over the remount code and have
> come up with the attached log.
> 
> A little bit of explanation:
> 
> Line 1: sync_filesystem (from do_remount_sb)
> Line 188: sync_filesystem ends
> Line 43, 64, 81, 98, 114, 135, 156, 173: write operations that occur
> during sync_filesystem.  Before each warning I print the inode pointer.
> Line 197: read-only remount has completely finished (this message is
> from userspace post remount)
> Line 199: a sync is called, there are apparently dirty inodes in our
> now-readonly ubifs filesystem
> Line 215: failed assert that occurs because the writeback triggers for
> inode 0xd75b9450 (see line 41, it got in with a sys_write while we were
> running our sync_filesystem in do_remount_sb)
> 
> Does this help?  It looks like there is a race condition between the
> writeback code and the remount read-only.  Nothing is done to lock out
> writes during the first half of the do_remount_sb and some stuff makes
> it into the writeback worker queue while we are busy syncing the
> filesystem only to trigger later when ubifs has decided it is
> read-only...
> 
> Note: I only barely know what I am talking about - filesystems still not
> my forte :)

BTW: Can you please share your .config?

Thanks,
//richard

  parent reply	other threads:[~2014-01-29  7:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22  5:15 [BUG] reproducable ubifs reboot assert and corruption Andrew Ruder
2014-01-24 13:31 ` Andrew Ruder
2014-01-24 13:31   ` Andrew Ruder
2014-01-24 13:31   ` Andrew Ruder
2014-01-25 15:02 ` Richard Weinberger
2014-01-27 16:39   ` Andrew Ruder
2014-01-27 16:39     ` Andrew Ruder
2014-01-27 16:39     ` Andrew Ruder
2014-01-29  5:32     ` Andrew Ruder
2014-01-29  5:32       ` Andrew Ruder
2014-01-29  7:17       ` Richard Weinberger
2014-01-29  7:17         ` Richard Weinberger
2014-01-29 15:39         ` Andrew Ruder
2014-01-29 15:39           ` Andrew Ruder
2014-01-29 15:39           ` Andrew Ruder
2014-01-29  7:30       ` Richard Weinberger [this message]
2014-01-29  7:30         ` Richard Weinberger
2014-01-29  9:12         ` Andrea Adami
2014-01-29 15:46         ` Andrew Ruder
2014-01-29 15:46           ` Andrew Ruder
2014-01-29 15:46           ` Andrew Ruder
2014-01-29 15:56           ` Richard Weinberger
2014-01-29 15:56             ` Richard Weinberger
2014-01-29 19:13             ` Andrew Ruder
2014-01-29 19:13               ` Andrew Ruder
2014-01-29 19:56               ` Richard Weinberger
2014-01-29 19:56                 ` Richard Weinberger

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=52E8AE25.8080502@nod.at \
    --to=richard@nod.at \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.weinberger@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.