From: Dong Aisheng <b29396@freescale.com>
To: Jan Kara <jack@suse.cz>
Cc: Dong Aisheng <dongas86@gmail.com>, <tj@kernel.org>,
<viro@zeniv.linux.org.uk>, <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.or>,
<r64343@freescale.com>
Subject: Re: WARNING: at fs/fs-writeback.c when plug out SD card after system suspend/resume
Date: Fri, 5 Dec 2014 10:54:29 +0800 [thread overview]
Message-ID: <20141205025416.GA16771@shlinux1.ap.freescale.net> (raw)
In-Reply-To: <20141204124139.GC8569@quack.suse.cz>
On Thu, Dec 04, 2014 at 01:41:39PM +0100, Jan Kara wrote:
> On Thu 04-12-14 11:43:17, Dong Aisheng wrote:
> > Hi ALL,
> >
> > We met an filesystem issue when do stable kernel upgrade from 3.10.31 to
> > 3.10.53. And we found it's caused by the following commit bf0972039 which
> > introduced in 3.10.53.
> > After applying this patch, after system suspend/resume, plug out a SD card
> > will cause the following WARNING if SD card has a filesystem mounted.
> > If revert it, no such WARNING shows.
> >
> > I also tried the latest linux-next tree, it also has such issue.
> >
> > Looks the patch is used to fixing a potential system crashing.
> > We're not sure whether this WARNING is as expected and reasonable
> > or a BUG because there's no such WARNING before this patch.
> >
> > Can someone explain about it?
> The warning happens because bdi disappeared from under filesystem (likely
> it was even freed) but filesystem still has references to it. Previously,
> we were just silenly using freed memory, now we warn about it because we
> now clear the BDI_registered bit before freeing the bdi.
>
> So for now the best advice I can give you is: Don't remove device from
> under mounted filesystem (even when the system is suspended). I may easily
> crash your machine.
>
> We should fix bdi lifetime issues by making bdi live as long as the
> filesystem on top of it but someone has to find time to do that...
>
Thanks for the explanation.
BTW, FYI, it seems ext4 and vfat do not have such WARNING after a few
simple tests, looks like it just happens on ext3.
Regards
Dong Aisheng
> Honza
>
> > Reproduce step is as follows:
> > root@imx6qdlsolo:~# mmc2: mmc_rescan_try_freq: trying to init card at 400000 Hz
> > mmc2: Problem setting current limit!
> > mmc2: new ultra high speed DDR50 SDHC card at address aaaa
> > mmcblk2: mmc2:aaaa SL32G 29.7 GiB
> > mmcblk2: p1 p2
> > wm8962 3-001a: Failed to get supply 'DCVDD': -517
> > wm8962 3-001a: Failed to request supplies: -517
> > i2c 3-001a: Driver wm8962 requests probe deferral
> > kjournald starting. Commit interval 5 seconds
> > EXT3-fs (mmcblk2p2): using internal journal
> > EXT3-fs (mmcblk2p2): recovery complete
> > EXT3-fs (mmcblk2p2): mounted filesystem with ordered data mode
> > FAT-fs (mmcblk2p1): Volume was not properly unmounted. Some data may
> > be corrupt. Please run fsck.
> >
> > root@imx6qdlsolo:~#
> > root@imx6qdlsolo:~# echo mem > /sys/power/state
> > PM: Syncing filesystems ... done.
> > Freezing user space processes ... (elapsed 0.01 seconds) done.
> > Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> > Suspending console(s) (use no_console_suspend to debug)
> > PM: suspend of devices complete after 45.436 msecs
> > PM: suspend devices took 0.050 seconds
> > PM: late suspend of devices complete after 0.599 msecs
> > PM: noirq suspend of devices complete after 0.704 msecs
> > Disabling non-boot CPUs ...
> > Turn off M/F mix!
> > PM: noirq resume of devices complete after 0.380 msecs
> > PM: early resume of devices complete after 0.498 msecs
> > imx-sdma 20ec000.sdma: loaded firmware 1.1
> > mmc2: Problem setting current limit!
> > PM: resume of devices complete after 409.704 msecs
> > PM: resume devices took 0.410 seconds
> > Restarting tasks ... done.
> > root@imx6qdlsolo:~#
> > root@imx6qdlsolo:~# libphy: 2188000.ethernet:01 - Link is Up - 100/Full
> > mmc2: card aaaa removed
> > ------------[ cut here ]------------
> > WARNING: at fs/fs-writeback.c:1196 __mark_inode_dirty+0x1d0/0x1d4()
> > bdi-block not registered
> > Modules linked in:
> > CPU: 0 PID: 927 Comm: umount Not tainted 3.10.53-02602-g89aa41e #751
> > [<80013b00>] (unwind_backtrace+0x0/0xf4) from [<80011524>]
> > (show_stack+0x10/0x14)
> > [<80011524>] (show_stack+0x10/0x14) from [<8002c290>]
> > (warn_slowpath_common+0x54/0x6c)
> > [<8002c290>] (warn_slowpath_common+0x54/0x6c) from [<8002c2d8>]
> > (warn_slowpath_fmt+0x30/0x40)
> > [<8002c2d8>] (warn_slowpath_fmt+0x30/0x40) from [<800e8bbc>]
> > (__mark_inode_dirty+0x1d0/0x1d4)
> > [<800e8bbc>] (__mark_inode_dirty+0x1d0/0x1d4) from [<80131ba8>]
> > (ext3_put_super+0x20c/0x23c)
> > [<80131ba8>] (ext3_put_super+0x20c/0x23c) from [<800c88e0>]
> > (generic_shutdown_super+0x58/0xc4)
> > [<800c88e0>] (generic_shutdown_super+0x58/0xc4) from [<800c8b14>]
> > (kill_block_super+0x18/0x68)
> > [<800c8b14>] (kill_block_super+0x18/0x68) from [<800c8e60>]
> > (deactivate_locked_super+0x48/0x64)
> > [<800c8e60>] (deactivate_locked_super+0x48/0x64) from [<800e271c>]
> > (SyS_umount+0x94/0x38c)
> > [<800e271c>] (SyS_umount+0x94/0x38c) from [<8000e080>]
> > (ret_fast_syscall+0x0/0x30)
> > ---[ end trace a52c980ef229d9da ]---
> > EXT3-fs (mmcblk2p2): I/O error while writing superblock
> >
> > Caused by following commit:
> > commit bf0972039ddc483a9cb79edae73076c635876568
> > Author: Jan Kara <jack@suse.cz>
> > Date: Thu Apr 3 14:46:23 2014 -0700
> >
> > bdi: avoid oops on device removal
> >
> > commit 5acda9d12dcf1ad0d9a5a2a7c646de3472fa7555 upstream.
> >
> > After commit 839a8e8660b6 ("writeback: replace custom worker pool
> > implementation with unbound workqueue") when device is removed while we
> > are writing to it we crash in bdi_writeback_workfn() ->
> > set_worker_desc() because bdi->dev is NULL.
> >
> > This can happen because even though bdi_unregister() cancels all pending
> > flushing work, nothing really prevents new ones from being queued from
> > balance_dirty_pages() or other places.
> >
> > Fix the problem by clearing BDI_registered bit in bdi_unregister() and
> > checking it before scheduling of any flushing work.
> >
> > Fixes: 839a8e8660b6777e7fe4e80af1a048aebe2b5977
> >
> > Reviewed-by: Tejun Heo <tj@kernel.org>
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > Cc: Derek Basehore <dbasehore@chromium.org>
> > Cc: Jens Axboe <axboe@kernel.dk>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > Regards
> > Dong Aisheng
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
next prev parent reply other threads:[~2014-12-05 3:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 3:43 WARNING: at fs/fs-writeback.c when plug out SD card after system suspend/resume Dong Aisheng
2014-12-04 12:41 ` Jan Kara
2014-12-04 13:09 ` Christoph Hellwig
2014-12-04 13:36 ` Ulf Hansson
2014-12-04 14:08 ` Jan Kara
2014-12-04 14:16 ` Tejun Heo
2014-12-04 14:31 ` Jan Kara
2014-12-05 2:54 ` Dong Aisheng [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-12-04 3:46 Dong Aisheng
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=20141205025416.GA16771@shlinux1.ap.freescale.net \
--to=b29396@freescale.com \
--cc=dongas86@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.or \
--cc=r64343@freescale.com \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).