linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <Anand.Jain@oracle.com>
To: linux-btrfs@vger.kernel.org
Cc: wangsl.fnst@cn.fujitsu.com, Anand Jain <Anand.Jain@oracle.com>
Subject: [PATCH 1/1] btrfs: looping 'mkfs.btrfs -f <dev>' may fail with EBUSY
Date: Thu, 12 Jun 2014 14:25:00 +0800	[thread overview]
Message-ID: <1402554300-13931-1-git-send-email-Anand.Jain@oracle.com> (raw)

The thread holding the O_EXCL flag seems to be BTRFS_IOC_SCAN_DEV ioctl,
which in turn calls btrfs_scan_one_device() to open dev with the O_EXCL flag.

But btrfs_scan_one_device() does not write anything to the disk.
and it is called by
      . An intermediary step (not the final open_ctree) in the
        mount thread to read the SB and
      . btrfs-control ioctls viz BTRFS_IOC_SCAN_DEV and
        BTRFS_IOC_DEVICES_READY
they don't need the O_EXCL.

test script: (run this in a loop)
static int test_skip_this_disk(char *path)
{
    int fd;
    char c;

    printf("%s ", path);
    fd = open(path, O_RDWR|O_EXCL);
    if (fd < 0) {
        printf("Open failed\n");
        return 1;
    }
    /*fflush(stdout);
    printf("Open Fine press enter\n");
    scanf("%c", &c);*/
    close(fd);
    return 0;
}

main(int arg, char **argv)
{
    int i;

    if (arg == 1) {
        printf("usage: %s <dev-with-btrfs-sb> .. \n", argv[0]);
        exit(1);
    }

    for (i = 1; i < arg; i++)
        test_skip_this_disk(argv[i]);
}

dump stack after the userland close(fd)

dump_stack+0x9/0x60
btrfs_scan_one_device+0x18d/0x1f0 [btrfs]
btrfs_control_ioctl+0xb9/0x210 [btrfs]
do_vfs_ioctl+0x84/0x4c0
inode_has_perm+0x28/0x30
file_has_perm+0x8a/0xa0
SyS_ioctl+0x91/0xa0
system_call_fastpath+0x16/0x1b

Signed-off-by: Anand Jain <Anand.Jain@oracle.com>
---
 fs/btrfs/volumes.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 636faa0..c186b5e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -914,7 +914,6 @@ int btrfs_scan_one_device(const char *path, fmode_t flags, void *holder,
 	 * later supers, using BTRFS_SUPER_MIRROR_MAX instead
 	 */
 	bytenr = btrfs_sb_offset(0);
-	flags |= FMODE_EXCL;
 	mutex_lock(&uuid_mutex);
 
 	bdev = blkdev_get_by_path(path, flags, holder);
-- 
1.8.5.3


             reply	other threads:[~2014-06-12  6:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12  6:25 Anand Jain [this message]
2014-07-02  3:36 ` [PATCH 1/1] btrfs: looping 'mkfs.btrfs -f <dev>' may fail with EBUSY Wang Shilong

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=1402554300-13931-1-git-send-email-Anand.Jain@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wangsl.fnst@cn.fujitsu.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).