From: Anand Jain <anand.jain@oracle.com>
To: miaox@cn.fujitsu.com
Cc: linux-btrfs@vger.kernel.org, Chris Mason <chris.mason@oracle.com>
Subject: Re: [PATCH 1/2] btrfs: fix null pointer dereference in clone_fs_devices when name is null
Date: Fri, 04 Jul 2014 19:21:38 +0800 [thread overview]
Message-ID: <53B68E42.1050109@oracle.com> (raw)
In-Reply-To: <53B370A7.6050108@cn.fujitsu.com>
Miao, Chris,
I appreciate your review comments, Miao. I am sorry for the delay,
was stuck on this issue for a long time. more below.
On 02/07/2014 10:38, Miao Xie wrote:
> On Mon, 30 Jun 2014 23:06:54 +0800, Anand Jain wrote:
>>
>>> The primary reason of this problem is that we didn't scan the system and
>>> find all the devices in the filesystem, if we scan the system, we can
>>> mount the filesystem successfully, needn't mount it with degraded option.
>>> so I think the right way to fix is to scan the system and find the device
>>> that is not registered into the fs device list.
>>
>> Thanks for commenting. Right. But I am testing the error
>> scenario. that is, when one of the disk is missing in the system.
>
> In fact, the disk is still in the system, but is not added into btrfs device list
> (we can add it by "btrfs device scan" command), and after you mount the fs with
> degraded option, the fs adds that disk as a missing device, so it doesn't has its
> name.
Correct.
> Though avoiding access a null pointer is right,
yes. that would tightly plug the problem demonstrated in the reproducer
with minimal changes.
> you didn't consider the missing
> device and forgot to set the missing device counter. I think the following code
> is better.
>
> if (orig_dev->missing) {
> device->missing = 1;
> fs_devices->missing_devices++;
> } else {
> ASSERT(orig_dev->name);
> ......
> }
Yes we need to associate the device->missing flag and
device->name==NULL together, not just here but at quite a number of
functions. As such there is no code which would mark
device missing after its being mounted (there were some patch
but those are yet to be reviewed).
So for now this patch will address problem as in the reproducer.
BUT BUT it would enable sections of code (with new parameters) which
was _never_ run before due to this bug. That is in the following
scenario..
- A mounted (missing) degraded seed btrfs FS.
- Add a seed disk.
- For seeding purpose we would "clone a degraded seed FS".
(before this patch - the code will panic here so rest of the
code was never run).
I have very intermittent null pointer deference issue as the code
runs further, (with or without Miao suggested), more precisely at
btrfs_run_dev_stats()
::
list_for_each_entry(device, &fs_devices->devices, dev_list) the list
device is NULL.
looks like its time to comprehensively handle the missing device.
So as of now NACK for this patch. Very Sorry.
Thanks, Anand
> Thanks
> Miao
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-07-04 11:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 9:12 [PATCH 1/2] btrfs: fix null pointer dereference in clone_fs_devices when name is null Anand Jain
2014-06-30 9:12 ` [PATCH 2/2] btrfs: fix null pointer dereference in btrfs_show_devname " Anand Jain
2014-06-30 10:02 ` [PATCH 1/2] btrfs: fix null pointer dereference in clone_fs_devices " Miao Xie
2014-06-30 15:06 ` Anand Jain
2014-07-02 2:38 ` Miao Xie
2014-07-04 11:21 ` Anand Jain [this message]
2014-07-04 11:24 ` Anand Jain
2014-07-07 3:05 ` Miao Xie
2014-07-07 9:20 ` Anand Jain
2014-07-07 9:21 ` Anand Jain
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=53B68E42.1050109@oracle.com \
--to=anand.jain@oracle.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=miaox@cn.fujitsu.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;
as well as URLs for NNTP newsgroup(s).