From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alistair John Strachan <alistair@devzero.co.uk>
Cc: xfs@oss.sgi.com, Jens Axboe <jens.axboe@oracle.com>,
Neil Brown <neilb@suse.de>, Nick Piggin <npiggin@suse.de>
Subject: Re: XFS/md/blkdev warning (was Re: Linux 2.6.26-rc2)
Date: Mon, 12 May 2008 09:47:43 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0805120933310.3019@woody.linux-foundation.org> (raw)
In-Reply-To: <200805121726.15576.alistair@devzero.co.uk>
On Mon, 12 May 2008, Alistair John Strachan wrote:
>
> I've been getting this since -rc1. It's still present in -rc2, so I thought
> I'd bug some people. Everything seems to be working fine.
Hmm. The problem is that blk_remove_plug() does a non-atomic
queue_flag_clear(QUEUE_FLAG_PLUGGED, q);
without holding the queue lock.
Now, sometimes that's ok, because of higher-level locking on the same
queue, so there is no possibility of any races.
And yes, this comes through the raid5 layer, and yes, the raid layer holds
the 'device_lock' on the raid5_conf_t, so it's all safe from other
accesses by that raid5 configuration, but I wonder if at least in theory
somebody could access that same device directly.
So I do suspect that this whole situation with md needs to be resolved
some way. Either the queue is already safe (because of md layer locking),
and in that case maybe the queue lock should be changed to point to that
md layer lock (or that sanity test simply needs to be removed). Or the
queue is unsafe (because non-md users can find it too), and we need to fix
the locking.
Alternatively, we may just need to totally revert the thing that made the
bit operations non-atomic and depend on the locking. This was introduced
by Nick in commit 75ad23bc0fcb4f992a5d06982bf0857ab1738e9e ("block: make
queue flags non-atomic"), and maybe it simply isn't viable.
Anyway, this is not an XFS bug, and no, I do not think you can ever
actually find any problems in real life that comes from this. But we do
need to resolve it one way or another.
(I'm leaving the rest of your report quoted, since I added Nick to the
list of Cc's).
Linus
---
> The taint is from loading a custom (fixed) DSDT which I've been doing for
> ages, and which shouldn't affect this trace.
>
> XFS: correcting sb_features alignment problem
> XFS mounting filesystem md1
> ------------[ cut here ]------------
> WARNING: at include/linux/blkdev.h:443 blk_remove_plug+0x60/0x88()
> Modules linked in:
> Pid: 1, comm: swapper Tainted: G A 2.6.26-rc2-damocles #2
>
> Call Trace:
> [<ffffffff802305be>] warn_on_slowpath+0x58/0x82
> [<ffffffff80250038>] ? find_symbol+0x21e/0x236
> [<ffffffff8025d617>] ? __rmqueue+0x1f/0x1c1
> [<ffffffff8032c02f>] blk_remove_plug+0x60/0x88
> [<ffffffff803eb3ea>] raid5_unplug_device+0x31/0xe6
> [<ffffffff803eb6ba>] get_active_stripe+0x21b/0x4c0
> [<ffffffff802265b3>] ? __wake_up+0x43/0x50
> [<ffffffff80226a66>] ? default_wake_function+0x0/0xf
> [<ffffffff803f14e7>] make_request+0x4d7/0x675
> [<ffffffff8025bc02>] ? mempool_alloc_slab+0x11/0x13
> [<ffffffff802429b2>] ? autoremove_wake_function+0x0/0x38
> [<ffffffff8025bc02>] ? mempool_alloc_slab+0x11/0x13
> [<ffffffff8032b793>] generic_make_request+0x1ec/0x227
> [<ffffffff8025eb5b>] ? __get_free_pages+0x15/0x54
> [<ffffffff8032cd19>] submit_bio+0x112/0x11b
> [<ffffffff8031bb6f>] _xfs_buf_ioapply+0x1eb/0x216
> [<ffffffff8031bbd8>] xfs_buf_iorequest+0x3e/0x65
> [<ffffffff8031f33f>] xfs_bdstrat_cb+0x19/0x3b
> [<ffffffff803181bd>] xfs_bwrite+0x5f/0xc0
> [<ffffffff8030818c>] xlog_bwrite+0x81/0xac
> [<ffffffff80308f29>] xlog_write_log_records+0x1eb/0x228
> [<ffffffff803090a0>] xlog_clear_stale_blocks+0x13a/0x147
> [<ffffffff80309a77>] xlog_find_tail+0x33f/0x3a5
> [<ffffffff8030b221>] xlog_recover+0x19/0x88
> [<ffffffff8030533c>] xfs_log_mount+0xb9/0x10d
> [<ffffffff8030d563>] xfs_mountfs+0x252/0x5a2
> [<ffffffff8031886f>] ? kmem_zalloc+0x11/0x2c
> [<ffffffff8030df35>] ? xfs_mru_cache_create+0x119/0x166
> [<ffffffff80313693>] xfs_mount+0x2a1/0x352
> [<ffffffff80321ca6>] xfs_fs_fill_super+0xc3/0x1f9
> [<ffffffff8027fc1f>] get_sb_bdev+0xfe/0x14d
> [<ffffffff80321be3>] ? xfs_fs_fill_super+0x0/0x1f9
> [<ffffffff8032035a>] xfs_fs_get_sb+0x13/0x15
> [<ffffffff8027f9e2>] vfs_kern_mount+0x52/0x99
> [<ffffffff8027fa86>] do_kern_mount+0x47/0xe2
> [<ffffffff80294d44>] do_new_mount+0x5f/0x92
> [<ffffffff80294f26>] do_mount+0x1af/0x1de
> [<ffffffff8025eb44>] ? __alloc_pages+0xb/0xd
> [<ffffffff80294fde>] sys_mount+0x89/0xd5
> [<ffffffff805cdcdd>] mount_block_root+0xda/0x263
> [<ffffffff805cdebc>] mount_root+0x56/0x5a
> [<ffffffff805cdfdd>] prepare_namespace+0x11d/0x14a
> [<ffffffff805cd845>] kernel_init+0x251/0x267
> [<ffffffff8020c128>] child_rip+0xa/0x12
> [<ffffffff805cd5f4>] ? kernel_init+0x0/0x267
> [<ffffffff8020c11e>] ? child_rip+0x0/0x12
>
> ---[ end trace 693a3c7fd0010c41 ]---
> Ending clean XFS mount for filesystem: md1
>
> --
> Cheers,
> Alistair.
>
> 137/1 Warrender Park Road, Edinburgh, UK.
>
next prev parent reply other threads:[~2008-05-12 16:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LFD.1.10.0805120731480.3188@woody.linux-foundation.org>
2008-05-12 16:26 ` XFS/md/blkdev warning (was Re: Linux 2.6.26-rc2) Alistair John Strachan
2008-05-12 16:40 ` Jens Axboe
2008-05-12 16:47 ` Linus Torvalds [this message]
2008-05-12 16:49 ` Jens Axboe
2008-05-13 1:05 ` [PATCH] Remove blkdev warning triggered by using md Neil Brown
2008-05-17 18:22 ` XFS/md/blkdev warning (was Re: Linux 2.6.26-rc2) Alistair John Strachan
2008-05-17 18:37 ` Linus Torvalds
2008-05-17 18:41 ` Linus Torvalds
2008-05-17 20:09 ` Alistair John Strachan
2008-05-17 21:17 ` Linus Torvalds
2008-05-17 23:12 ` Alistair John Strachan
2008-05-17 23:39 ` Christoph Hellwig
2008-05-18 14:12 ` Alistair John Strachan
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=alpine.LFD.1.10.0805120933310.3019@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=alistair@devzero.co.uk \
--cc=jens.axboe@oracle.com \
--cc=neilb@suse.de \
--cc=npiggin@suse.de \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox