Re: [PATCH v2 2/4] btrfs: Update per-profile available space when device size/used space get updated

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Josef Bacik <josef@toxicpanda.com>, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 2/4] btrfs: Update per-profile available space when device size/used space get updated
Date: Fri, 3 Jan 2020 17:52:29 +0800	[thread overview]
Message-ID: <5ec1095b-b62b-a267-392a-63e6a3f1eeb3@gmx.com> (raw)
In-Reply-To: <c4f6ddfb-c52c-d376-4cef-26aebec4e288@toxicpanda.com>

[-- Attachment #1.1: Type: text/plain, Size: 1550 bytes --]

On 2020/1/3 上午12:17, Josef Bacik wrote:
> On 1/2/20 6:27 AM, Qu Wenruo wrote:
>> There are 4 locations where device size or used space get updated:
>> - Chunk allocation
>> - Chunk removal
>> - Device grow
>> - Device shrink
>>
>> Now also update per-profile available space at those timings.
>>
>> For __btrfs_alloc_chunk() we can't acquire device_list_mutex as in
>> btrfs_finish_chunk_alloc() we could hold device_list_mutex and cause
>> dead lock.
>>
> 
> These are protecting two different things though, holding the
> chunk_mutex doesn't keep things from being removed from the device list.

Further looking into the lock schema, Nikolay's comment is right,
chunk_mutex protects alloc_list (rw devices).

Device won't disappear from alloc_list, as in btrfs_rm_device() we took
chunk_mutex before removing writeable device.

In fact, device_list_mutex is unrelated to alloc_list.

So other calc_per_profile_avaiable() call sites are in fact not safe, I
shouldn't take device_list_mutex, but chunk_mutex which are much easier
to get.

> 
> Looking at patch 1 can't we just do the device list traversal under RCU
> and then not have to worry about the locking at all?  Thanks,

I guess we need SRCU, since in __btrfs_alloc_chunk() context we need to
sleep for search dev extent tree.

And I'm not confident enough for some corner case, maybe some RCU sync
case would cause unexpected performance degrade as the RCU sync can be
more expensive than simple mutex lock.

Thanks,
Qu

> 
> Josef

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]