public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Anand Jain <anand.jain@oracle.com>, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/3] btrfs-progs: fix the stray fd close in open_ctree_fs_info()
Date: Thu, 8 Feb 2024 07:35:35 +1030	[thread overview]
Message-ID: <31d07ebd-0147-4761-85fb-5d07e67a6b0e@gmx.com> (raw)
In-Reply-To: <d8484431-72b7-4fe4-a4dc-264f82af7c22@oracle.com>



On 2024/2/8 03:06, Anand Jain wrote:
>
>> index c053319200cb..05323b2cd393 100644
>> --- a/kernel-shared/disk-io.c
>> +++ b/kernel-shared/disk-io.c
>> @@ -913,6 +913,7 @@ struct btrfs_fs_info *btrfs_new_fs_info(int
>> writable, u64 sb_bytenr)
>>       fs_info->metadata_alloc_profile = (u64)-1;
>>       fs_info->system_alloc_profile = fs_info->metadata_alloc_profile;
>>       fs_info->nr_global_roots = 1;
>> +    fs_info->initial_fd = -1;
>>       return fs_info;
>> @@ -1690,7 +1691,10 @@ struct btrfs_fs_info *open_ctree_fs_info(struct
>> open_ctree_args *oca)
>>           return NULL;
>>       }
>
>
>>       info = __open_ctree_fd(fp, oca);
>> -    close(fp);
>> +    if (info)
>
>
>> +        info->initial_fd = fp;
>
> Why not do this in __open_ctree_fd()?

Because we want to keep open()/close() in the same layer when possible.

> then in the parent function, __open_ctree_fd you could:
>
>      if (!info)
>          close(fp);
>
>
>> +    else
>> +        close(fp);
>
>>       return info;
>>   }
>> @@ -2297,6 +2301,8 @@ skip_commit:
>>       btrfs_release_all_roots(fs_info);
>>       ret = btrfs_close_devices(fs_info->fs_devices);
>> +    if (fs_info->initial_fd >= 0)
>> +        close(fs_info->initial_fd);
>>       btrfs_cleanup_all_caches(fs_info);
>>       btrfs_free_fs_info(fs_info);
>>       if (!err)
>
>
> Essentially this patch converts the following nested open close
>
>
> fd1 open
> fd1 write zero
> fd1 write temp-sb
> fd2 open
> fd2 read super
> fd3 open devices
> fd2 close
> fd1 write temp-sb-to-remaining-dev-if-any
> fd3 write good-sb
> fd3 close
> fd1 close
>
> to
>
> [1]
> fd1 open
> fd1 write zero
> fd1 write temp-sb
> fd2 open
> fd2 read super
> fd3 open devices
> fd1 write temp-sb-to-remaining-dev-if-any
> fd3 write good-sb
> fd3 close
> fd2 close
> fd1 close
>
>
> However the patch
>    [PATCH RFC] btrfs-progs: mkfs: optimize file descriptor usage in
> mkfs.btrfs
>
>
> achieved: (And reduced one less fd)
>
> fd1 open
> fd1 write zero
> fd1 write temp-sb
> fd1 read super
> fd2 open devices
> fd1 write temp-sb-to-remaining-dev-if-any
> fd2 write good-sb
> fd2 close
> fd1 close

The problem we are hitting don't care how many fds we opened or
whatever, as long as the final close is later than the final fs commit.

>
>
> This patch saves the temporary fd (which is a helper fd to read the sb.
> fd2 in [1]) into a new member fs_info::initial_fd, does not make much
> sense to me. This fix is a kind of a quick, patchy solution rather
> than a ground-up clean design, imo.

Nope, your version needs all caller of open_ctree_fs_info() to converted
to the new interface.

This one keeps the interface untouched and still solves the problem.

Yes, this can be enhanced, but not in the way you did.

The proper way is to make open_ctree_fs_info() to not to rely on any
external fd, but really make open_ctree_fs_info() to only open fds for
its devices.

This would make open_ctree_fs_info() to get rid of __open_ctree_fd()
completely.
That would be a large work and does not provide really much benefit
compared to the current workaround.

Thanks,
Qu

>
> Thx. Anand
>
>

  reply	other threads:[~2024-02-07 21:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02  0:59 [PATCH 0/3] btrfs-progs: hunt down the stray fd close causing race with udev scan Qu Wenruo
2024-02-02  0:59 ` [PATCH 1/3] btrfs-progs: rescue: properly close the fs for clear-ino-cache Qu Wenruo
2024-02-02  8:48   ` Anand Jain
2024-02-02  0:59 ` [PATCH 2/3] btrfs-progs: tune: fix the missing close() Qu Wenruo
2024-02-02  9:01   ` Anand Jain
2024-02-02  0:59 ` [PATCH 3/3] btrfs-progs: fix the stray fd close in open_ctree_fs_info() Qu Wenruo
2024-02-07 16:36   ` Anand Jain
2024-02-07 21:05     ` Qu Wenruo [this message]
2024-02-08  2:53       ` Anand Jain
2024-02-07  9:52 ` [PATCH 0/3] btrfs-progs: hunt down the stray fd close causing race with udev scan David Sterba

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=31d07ebd-0147-4761-85fb-5d07e67a6b0e@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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