From: Stefan Priebe <s.priebe@profihost.ag>
To: Jeff Mahoney <jeffm@suse.com>, Chris Mason <clm@fb.com>,
Christoph Hellwig <hch@lst.de>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"<linux-fsdevel@vger.kernel.org>" <linux-fsdevel@vger.kernel.org>,
linux-kernel.bfrz@manchmal.in-ulm.de
Subject: Re: btrfs regression since 4.X kernel NULL pointer dereference
Date: Fri, 11 Sep 2015 06:55:45 +0200 [thread overview]
Message-ID: <55F25ED1.3060107@profihost.ag> (raw)
In-Reply-To: <55F20276.1050209@suse.com>
Am 11.09.2015 um 00:21 schrieb Jeff Mahoney:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/31/15 8:06 PM, Chris Mason wrote:
>> On Mon, Aug 31, 2015 at 07:32:09PM +0200, Stefan Priebe -
>> Profihost AG wrote:
>>>> Am 25.08.2015 um 15:51 schrieb Chris Mason <clm@fb.com>:
>>>>
>>>>> On Tue, Aug 25, 2015 at 11:00:30AM +0200, Christoph Hellwig
>>>>> wrote: I think this is btrfs using a struct block_device
>>>>> that doesn't have a valid queue pointer in it's gendisk for
>>>>> ->s_bdev. And there are some fishy looking ->s_bdev
>>>>> assignments in the code which I suspect are related to it:
>>>>>
>>>>> fs/btrfs/dev-replace.c: if (fs_info->sb->s_bdev ==
>>>>> src_device->bdev) fs/btrfs/dev-replace.c: fs_info->sb->s_bdev
>>>>> = tgt_device->bdev; fs/btrfs/volumes.c: if (device->bdev ==
>>>>> root->fs_info->sb->s_bdev) fs/btrfs/volumes.c:
>>>>> root->fs_info->sb->s_bdev = next_device->bdev;
>>>>> fs/btrfs/volumes.c: if (tgtdev->bdev ==
>>>>> fs_info->sb->s_bdev) fs/btrfs/volumes.c: fs_info->sb->s_bdev
>>>>> = next_device->bdev;
>>>>
>>>> We've had trouble with this in the past, I'll take a look.
>>>
>>> Any news?
>>
>> Haven't been able to reproduce yet, I'll try again in the morning.
>
> I'm unable to reproduce it as well and I'm hearing about people
> hitting it in different forums.
>
> Can you describe your storage configuration? There's a gendisk
> without a queue sneaking in somehow. There are some spots in dm where
> the mddev gets a new queue assigned to it but the old queue associated
> with the gendisk is left behind so that's not it.
I'm hitting this inside a debian buil VM using schroot. So the disk is a
simple plain qemu emulated scsi disk (virtio-pci-scsi).
> If you're able to
> reproduce it reliably with this configuration, that's certainly
> interesting. I'm wondering if the case is that vgcfgbackup is
> iterating over devices and causing something that might not have been
> previously scanned to be scanned and added to the btrfs device list.
I'm not the guy from the kernel bug report - so i'm only using debian
schroot not vgcfgbackup.
I can trigger it 100% by using schroot with sbuild using debian or ubuntu.
> Are there any messages above the oops indicating when a device is
> added? Could you post your complete dmesg somewhere?
Sure:
http://pastebin.com/raw.php?i=bG6bZUPA
Thanks!
Greets,
Stefan
> Thanks,
>
> - -Jeff
>
> - --
> Jeff Mahoney
> SUSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>
> iQIcBAEBAgAGBQJV8gJ2AAoJEB57S2MheeWyEP4QALvIXZGIqkXhUBZEYvLC+rnD
> Q79chLpbt8x52xtFoav78i3nG24SMXV5NbhFlGNnr6xt/CQtKSzBuDyJ+nigkyy+
> bTtHbwkMqNddrqKJ3r928nKwz1IOyU4J58l7hGyC0owSA3mDxyI7+yS16OXFwc1S
> 6lxtV4ljf6nqobA+rVyC3n3BU6CF1aL45V2FpM/m4OHL/Xqv97Xg2tGlysnk8RPD
> dRvz5fs2T75B0eBsK4xWHKEgKKWdVYaKqlySRXUJQpnNJTlJltW5HzL8RnR47brt
> LLaOCD4jcLlEtGhTi6wEN6BlEYbgDx/1yjQs5zxLG0vbTUi5ZcTeT82d5+Hh4WMD
> HyLfE4pwFUZXTHvcIoQ51wPLS/tWMVJXnleQKBrDT+WcsKPr5yuwUZpwfrOBfjol
> Qan13/mIcmvFsz2yVWnoZJWU5osnhe+frBsVFlIFLNXp50QVXk+WvruPDOsoY2eQ
> J8L20LhY5e0dgJseXWkAAy68mJ0/rrkX0iAdiED/WEsBdjy7QuOomJqPyQQEPplm
> d+tIkDR77Biajket2tNEXK1m14f7QvFUFojI0NwegcmZT3iJ7BBWD6wjxIvh3KqE
> LqHIcTaECU9XSg9x9E3N416hCbclC9xeosxaJB1iN+EvpaD7CBA+V+onkNMN6Fu4
> J0aVUYlZuLcqkEs/BuNL
> =BRtR
> -----END PGP SIGNATURE-----
>
next prev parent reply other threads:[~2015-09-11 4:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-22 17:29 btrfs regression since 4.X kernel NULL pointer dereference Stefan Priebe
2015-08-25 9:00 ` Christoph Hellwig
2015-08-25 9:44 ` Stefan Priebe - Profihost AG
2015-08-25 13:51 ` Chris Mason
2015-08-31 17:32 ` Stefan Priebe - Profihost AG
2015-09-01 0:06 ` Chris Mason
2015-09-01 4:41 ` Stefan Priebe
2015-09-11 23:21 ` Christoph Biedl
2015-09-10 22:21 ` Jeff Mahoney
2015-09-11 4:55 ` Stefan Priebe [this message]
2015-09-11 18:55 ` Jeff Mahoney
2015-09-11 19:05 ` Jeff Mahoney
2015-09-11 23:31 ` Stefan Priebe
2015-09-11 19:34 ` Chris Mason
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=55F25ED1.3060107@profihost.ag \
--to=s.priebe@profihost.ag \
--cc=clm@fb.com \
--cc=hch@lst.de \
--cc=jeffm@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel.bfrz@manchmal.in-ulm.de \
/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.