On 11.09.20 12:32, Stefan Hajnoczi wrote:
> On Wed, Sep 09, 2020 at 08:46:01PM +0200, Max Reitz wrote:
>> @@ -176,13 +177,22 @@ static ssize_t
>> fuse_conn_congestion_threshold_write(struct file *file,
>>
>> spin_lock(&fc->bg_lock);
>> fc->congestion_threshold = val;
>> - if (fc->sb) {
>> +
>> + /*
>> + * Get any fuse_mount belonging to this fuse_conn; s_bdi is
>> + * shared between all of them
>> + */
>> + if (!list_empty(&fc->mounts))
>> + first_fm = list_first_entry(&fc->mounts, struct fuse_mount,
>> + fc_entry);
> ...
>> @@ -263,14 +273,20 @@ static struct dentry *fuse_ctl_add_dentry(struct
>> dentry *parent,
>> int fuse_ctl_add_conn(struct fuse_conn *fc)
>> {
>> struct dentry *parent;
>> + struct fuse_mount *first_fm;
>> char name[32];
>>
>> if (!fuse_control_sb)
>> return 0;
>>
>> + if (list_empty(&fc->mounts))
>> + return 0;
>> +
>> + first_fm = list_first_entry(&fc->mounts, struct fuse_mount, fc_entry);
>> + sprintf(name, "%u", first_fm->dev);
>
> How does locking work for struct fuse_mount? Are there any locking rules
> that can be documented?Hm. I just hoped the largely mechanical conversion of fuse_conn to fuse_mount would ensure nothing breaks. There are locks protecting the superblock and fuse_conn as a whole (which basically includes the associated fuse_mounts). I suspect we could get better (i.e., finer) granularity by giving each fuse_mount its own lock, and then releasing the fuse_conn lock while we switch over to the fuse_mount lock. That seems bug-prone, though, and probably doesn’t even help performance that much. I mean, in the most common case, you won’t have submounts, so each fuse_conn has exactly one fuse_mount, so having a separate lock for the latter won’t help. Max
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
