linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Nikolay Borisov <nborisov@suse.com>,
	dsterba@suse.cz, clm@fb.com, dsterba@suse.com, jbacik@fb.com,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: general protection fault in find_device
Date: Tue, 26 Jun 2018 17:17:48 +0800	[thread overview]
Message-ID: <d59c40af-3659-0cc7-58d6-8a2d6568b60d@oracle.com> (raw)
In-Reply-To: <d1bbc78f-da5d-1f87-e9f5-a6bec6650e9a@suse.com>



(Sorry for the delay in replay due to my vacation).

Thanks Nikolay. more below.

On 06/18/2018 09:43 PM, Nikolay Borisov wrote:
> 
> 
> On 18.06.2018 16:32, David Sterba wrote:
>> On Mon, Jun 18, 2018 at 10:03:18AM +0300, Nikolay Borisov wrote:
>>> So this suggests some inconsistency on fs_devices->devices list. On a
>>> quick look indeed it doesn't seem clear what the locking rules for this
>>> list are. In device_list_add in the !device case a device is added with
>>> fs_devices->device_list_Mutex held and using list_add_rcu. In the same
>>> function if we want to read the list ie invoke find_devices (because we
>>> have found an fsid) we are using plain list_for_each_entry (ie not the
>>> _rcu version and i don't see device_list_mutex being held while
>>> iterating the list). Additionally in btrfs_free_extra_devids the
>>> fs_devices->devices list is iterated with uuid_mutex being held and not
>>> device_list_mutex. In open_fs_devices we don't get any protection
>>> whatsoever while reading the list.
>>
>> The uuid_mutex or device_list_mutex is provided by a caller up the
>> stack.
>>
>>> Same thing in
>>> btrfs_find_next_active_device. If the list is supposed to be
>>> RCU-protected then the rules are:
>>>
>>> 1. There needs to be an out of band (ie not RCU) mutual exclusion of
>>> modifiers
>>
>> that's device_list_mutex for fs_devices::devices
>>
>>> 2. Iterating the list should use _rcu list primitives.
>>>
>>> Currently I don't see those 2 invariants being enforced in every code path.
>>
>> Where is it not enforced for example?
> 
> Admittedly I didn't check the whole call chain but for example in
> find_device it's used "naked". Perhaps putting some lockdep_assert in
> various places dealing with fs_devices->devices list would help ?
>>
>> If the device_list_mutex is held, list traversal does not use
>> list_for_each_entry_rcu, otherwise it does (eg the DEV_INFO ioctl or
>> btrfs_show_devname).
>>
>> The problem that triggers this report is IMO in device_list_add that
>> uses the device list unprotected. Anand sent patches for that, but they
>> were titled as 'cleanups' so I skipped them for the merge window.

  Ah. sorry to confuse you. Will consolidate fixes into github
  (also reviewing David's fixes as well) and will use syz to confirm.

Thanks, Anand

>> Candidate fixes are:
>>
>> https://patchwork.kernel.org/patch/10437705/
>> https://patchwork.kernel.org/patch/10437713/
> Yep those 2 definitely look like fixing unlocked accesses to
> fs_devices->devices list


>>
> --
> 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
> 

      reply	other threads:[~2018-06-26  9:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18  5:55 general protection fault in find_device syzbot
2018-06-18  7:03 ` Nikolay Borisov
2018-06-18  8:26   ` Nikolay Borisov
2018-06-18 13:32   ` David Sterba
2018-06-18 13:43     ` Nikolay Borisov
2018-06-26  9:17       ` Anand Jain [this message]

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=d59c40af-3659-0cc7-58d6-8a2d6568b60d@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=dsterba@suse.cz \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=syzkaller-bugs@googlegroups.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).