public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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.
> 

  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