| Message ID | 2fe68e18d89abb7313392c8da61aaa9881bbe945.1704917721.git.josef@toxicpanda.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs: do not restrict writes to devices | expand |
On Wed, Jan 10, 2024 at 03:16:35PM -0500, Josef Bacik wrote: > This is a version of ead622674df5 ("btrfs: Do not restrict writes to > btrfs devices"), which pushes this restriction closer to where we use > bdev_open_by_path. This was in the mount path, and changed when we > switched to the new mount api, and with that loss we suddenly weren't > able to mount. Move this closer to where we use bdev_open_by_path so > changes on the upper layers don't mess anything up, and then we can > remove this when we merge the bdev holder patches. > > Signed-off-by: Josef Bacik <josef@toxicpanda.com> > --- > - This needs to go in before the new mount API patches when we rebase onto > linus/master for the merge request, otherwise we won't be able to mount file > systems. I've put this at the beginning of the for-next branch in the github > linux tree, which is rebased onto recent linus. But the new mount API has been just merged to master, no way we could reorder the patches. There are like 18 new patches atop the 6.8 pull request branch so that's the next base.
On 1/11/24 04:16, Josef Bacik wrote: > This is a version of ead622674df5 ("btrfs: Do not restrict writes to > btrfs devices"), which pushes this restriction closer to where we use > bdev_open_by_path. > This was in the mount path, and changed when we > switched to the new mount api, New mount api patchset [1]: [1] [PATCH v3 00/19] btrfs: convert to the new mount API Do you have a specific patch here for me to understand the changes you're talking about? > and with that loss we suddenly weren't > able to mount. With the patchset [1] already in the mainline, I am able to mount. It looks like I'm missing something. What is the failing test case? Thanks, Anand > Move this closer to where we use bdev_open_by_path so > changes on the upper layers don't mess anything up, and then we can > remove this when we merge the bdev holder patches. > > Signed-off-by: Josef Bacik <josef@toxicpanda.com> > --- > - This needs to go in before the new mount API patches when we rebase onto > linus/master for the merge request, otherwise we won't be able to mount file > systems. I've put this at the beginning of the for-next branch in the github > linux tree, which is rebased onto recent linus. > > fs/btrfs/volumes.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > index d67785be2c77..9c8de7fad86e 100644 > --- a/fs/btrfs/volumes.c > +++ b/fs/btrfs/volumes.c > @@ -474,6 +474,9 @@ btrfs_get_bdev_and_sb(const char *device_path, blk_mode_t flags, void *holder, > struct block_device *bdev; > int ret; > > + /* No support for restricting writes to btrfs devices yet... */ > + flags &= ~BLK_OPEN_RESTRICT_WRITES; > + > *bdev_handle = bdev_open_by_path(device_path, flags, holder, NULL); > > if (IS_ERR(*bdev_handle)) { > @@ -1322,6 +1325,9 @@ struct btrfs_device *btrfs_scan_one_device(const char *path, blk_mode_t flags, > > lockdep_assert_held(&uuid_mutex); > > + /* No support for restricting writes to btrfs devices yet... */ > + flags &= ~BLK_OPEN_RESTRICT_WRITES; > + > /* > * we would like to check all the supers, but that would make > * a btrfs mount succeed after a mkfs from a different FS.
On Thu, Jan 11, 2024 at 04:59:00PM +0800, Anand Jain wrote: > On 1/11/24 04:16, Josef Bacik wrote: > > This is a version of ead622674df5 ("btrfs: Do not restrict writes to > > btrfs devices"), which pushes this restriction closer to where we use > > bdev_open_by_path. > > > > This was in the mount path, and changed when we > > switched to the new mount api, > > New mount api patchset [1]: > [1] [PATCH v3 00/19] btrfs: convert to the new mount API > > Do you have a specific patch here for me to understand the changes > you're talking about? > > > > and with that loss we suddenly weren't > > able to mount. > > With the patchset [1] already in the mainline, I am able to mount. > It looks like I'm missing something. What is the failing test case? I don't think that mainline fails, I don't know what exactly Josef tested though. There's a big merge diff affc5af36bbb62073b6aaa4f4459b38937ff5331 and there's a manual resolution by Linus moving the BLK_OPEN_RESTRICT_WRITES flags to the device open.
On Thu, Jan 11, 2024 at 04:24:52PM +0100, David Sterba wrote: > On Thu, Jan 11, 2024 at 04:59:00PM +0800, Anand Jain wrote: > > On 1/11/24 04:16, Josef Bacik wrote: > > > This is a version of ead622674df5 ("btrfs: Do not restrict writes to > > > btrfs devices"), which pushes this restriction closer to where we use > > > bdev_open_by_path. > > > > > > > This was in the mount path, and changed when we > > > switched to the new mount api, > > > > New mount api patchset [1]: > > [1] [PATCH v3 00/19] btrfs: convert to the new mount API > > > > Do you have a specific patch here for me to understand the changes > > you're talking about? > > > > > > > and with that loss we suddenly weren't > > > able to mount. > > > > With the patchset [1] already in the mainline, I am able to mount. > > It looks like I'm missing something. What is the failing test case? > > I don't think that mainline fails, I don't know what exactly Josef > tested though. There's a big merge diff > affc5af36bbb62073b6aaa4f4459b38937ff5331 and there's a manual resolution > by Linus moving the BLK_OPEN_RESTRICT_WRITES flags to the device open. The key part of the diff is this: --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@@ -143,92 -141,487 +141,493 @@@ enum ++/* No support for restricting writes to btrfs devices yet... */ ++static inline blk_mode_t btrfs_open_mode(struct fs_context *fc) ++{ ++ return sb_open_mode(fc->sb_flags) & ~BLK_OPEN_RESTRICT_WRITES; ++} + @@@ -2096,6 -1770,309 +1776,309 @@@ static int btrfs_statfs(struct dentry * - blk_mode_t mode = sb_open_mode(fc->sb_flags); ++ blk_mode_t mode = btrfs_open_mode(fc); the remaining changes are independent.
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index d67785be2c77..9c8de7fad86e 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -474,6 +474,9 @@ btrfs_get_bdev_and_sb(const char *device_path, blk_mode_t flags, void *holder, struct block_device *bdev; int ret; + /* No support for restricting writes to btrfs devices yet... */ + flags &= ~BLK_OPEN_RESTRICT_WRITES; + *bdev_handle = bdev_open_by_path(device_path, flags, holder, NULL); if (IS_ERR(*bdev_handle)) { @@ -1322,6 +1325,9 @@ struct btrfs_device *btrfs_scan_one_device(const char *path, blk_mode_t flags, lockdep_assert_held(&uuid_mutex); + /* No support for restricting writes to btrfs devices yet... */ + flags &= ~BLK_OPEN_RESTRICT_WRITES; + /* * we would like to check all the supers, but that would make * a btrfs mount succeed after a mkfs from a different FS.
This is a version of ead622674df5 ("btrfs: Do not restrict writes to btrfs devices"), which pushes this restriction closer to where we use bdev_open_by_path. This was in the mount path, and changed when we switched to the new mount api, and with that loss we suddenly weren't able to mount. Move this closer to where we use bdev_open_by_path so changes on the upper layers don't mess anything up, and then we can remove this when we merge the bdev holder patches. Signed-off-by: Josef Bacik <josef@toxicpanda.com> --- - This needs to go in before the new mount API patches when we rebase onto linus/master for the merge request, otherwise we won't be able to mount file systems. I've put this at the beginning of the for-next branch in the github linux tree, which is rebased onto recent linus. fs/btrfs/volumes.c | 6 ++++++ 1 file changed, 6 insertions(+)