From: Nikolay Borisov <nborisov@suse.com>
To: dsterba@suse.cz, Anand Jain <anand.jain@oracle.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 0/2] fix bug in btrfs_init_new_device()
Date: Wed, 27 Sep 2017 17:26:41 +0300 [thread overview]
Message-ID: <f81f53d2-a314-426a-b21b-457e116a7405@suse.com> (raw)
In-Reply-To: <20170927142224.GJ31640@twin.jikos.cz>
On 27.09.2017 17:22, David Sterba wrote:
> On Tue, Sep 26, 2017 at 03:14:27PM +0300, Nikolay Borisov wrote:
>>
>>
>> On 26.09.2017 11:47, Anand Jain wrote:
>>> 1/2 fixes a bug which failed to reset writable when sprouting failed
>>> 2/2 fixes BUG_ON in btrfs_init_new_device()
>>>
>>> Anand Jain (2):
>>> btrfs: undo writable when sprouting fails
>>> btrfs: fix BUG_ON in btrfs_init_new_device()
>>
>> Reviewed-by: Nikolay Borisov <nborisov@suse.com>
>
> Please note that this would lead to unexpected unlocks of uuid_mutex and
> sb::s_umount:
>
> 2465 ret = btrfs_commit_transaction(trans);
> 2466
> 2467 if (seeding_dev) {
> 2468 mutex_unlock(&uuid_mutex);
> 2469 up_write(&sb->s_umount);
>
> first unlocks
>
> 2470
> 2471 if (ret) /* transaction commit */
> 2472 return ret;
> 2473
> 2474 ret = btrfs_relocate_sys_chunks(fs_info);
> 2475 if (ret < 0)
> 2476 btrfs_handle_fs_error(fs_info, ret,
> 2477 "Failed to relocate sys chunks after device initialization. This can be fixed using the \"btrfs balance\"
> 2478 trans = btrfs_attach_transaction(root);
> 2479 if (IS_ERR(trans)) {
> 2480 if (PTR_ERR(trans) == -ENOENT)
> 2481 return 0;
> 2482 return PTR_ERR(trans);
> ^^^^
>
> this becomes goto 2494
>
> 2483 }
> 2484 ret = btrfs_commit_transaction(trans);
> 2485 }
> 2486
> 2487 /* Update ctime/mtime for libblkid */
> 2488 update_dev_time(device_path);
> 2489 return ret;
> 2490
> 2491 error_trans:
> 2492 btrfs_end_transaction(trans);
> 2493 rcu_string_free(device->name);
> 2494 btrfs_sysfs_rm_device_link(fs_info->fs_devices, device);
>
> here
>
> 2495 kfree(device);
> 2496 error:
> 2497 blkdev_put(bdev, FMODE_EXCL);
> 2498 if (seeding_dev) {
> 2499 mutex_unlock(&uuid_mutex);
> 2500 up_write(&sb->s_umount);
>
> and unlocking again
>
> 2501 }
> 2502 return ret;
>
> So the in-place returns had a meaning but are quite confusing.
I concur and had missed that ;(. I saw that you suggested Anand to
overhaul the overall error handling in this function and I believe this
would be the best course of action.
>
next prev parent reply other threads:[~2017-09-27 14:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-26 8:47 [PATCH v3 0/2] fix bug in btrfs_init_new_device() Anand Jain
2017-09-26 8:47 ` [PATCH v3 1/2] btrfs: undo writable when sprouting fails Anand Jain
2017-09-26 8:47 ` [PATCH v3 2/2] btrfs: fix BUG_ON in btrfs_init_new_device() Anand Jain
2017-09-26 12:14 ` [PATCH v3 0/2] fix bug " Nikolay Borisov
2017-09-27 14:22 ` David Sterba
2017-09-27 14:26 ` Nikolay Borisov [this message]
2017-09-28 6:55 ` Anand Jain
-- strict thread matches above, loose matches on Subject: below --
2017-09-26 8:41 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=f81f53d2-a314-426a-b21b-457e116a7405@suse.com \
--to=nborisov@suse.com \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/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).