linux-next: manual merge of the vfs-brauner tree with the btrfs tree

linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 10743 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got lots of conflicts
against the btrfs tree.  This is because the vfs-braunter tree has merged
a previous version of the btrfs tree and now the btrfs tree has rebased
and changed several commits.

You cannot merge another tree in linux-next unless the otehr tree is
guaranteed not to rebase (or have commits rewritten in it).

The following commits are duplicates between the two trees (same patch
but different commit) and there are also some that are slightly different
patches:

  00e27794611a ("btrfs: qgroup: use qgroup_iterator to replace tmp ulist in qgroup_update_refcnt()")
  0170b5c5e607 ("btrfs: reduce size of prelim_ref::level")
  01c41e751fcb ("btrfs: call btrfs_close_devices from ->kill_sb")
  025e4dc521e1 ("btrfs: remove refs_to_drop argument from __btrfs_free_extent()")
  0266c8c65c81 ("btrfs: use a single variable for return value at lookup_inline_extent_backref()")
  096833591c4b ("btrfs: qgroup: iterate qgroups without memory allocation for qgroup_reserve()")
  0bd5b51b99fa ("btrfs: always open the device read-only in btrfs_scan_one_device")
  0c516db11952 ("btrfs: remove redundant root argument from btrfs_update_inode_item()")
  0c612f9e77cc ("btrfs: stop doing excessive space reservation for csum deletion")
  0d9436739af2 ("btrfs: scan but don't register device on single device filesystem")
  0e3380da547b ("btrfs: don't arbitrarily slow down delalloc if we're committing")
  1172a0c18f3b ("btrfs: remove pointless initialization at btrfs_delayed_refs_rsv_release()")
  1488ae026122 ("btrfs: sysfs: add simple_quota incompat feature entry")
  18030a255de2 ("btrfs: move extent_buffer::lock_owner to debug section")
  1a5bda4c5bac ("btrfs: relocation: use more natural types for tree_block bitfields")
  1e4f604b274f ("btrfs: return -EUCLEAN if extent item is missing when searching inline backref")
  1fbf413f4346 ("btrfs: use a single variable for return value at run_delayed_extent_op()")
  206536cd2851 ("btrfs: reject devices with CHANGING_FSID_V2")
  2263c3dadd27 ("btrfs: remove redundant root argument from btrfs_update_inode()")
  23030f1872bd ("btrfs: map uncontinuous extent buffer pages into virtual address space")
  244c627c729d ("btrfs: move btrfs_extref_hash into inode-item.h")
  254cedfd09da ("btrfs: remove stale comment from btrfs_free_extent()")
  256a88a21f59 ("btrfs: mark transaction id check as unlikely at btrfs_mark_buffer_dirty()")
  25ec25120282 ("btrfs: zoned: factor out single bg handling from btrfs_load_block_group_zone_info")
  28a4901d0247 ("btrfs: comment about fsid and metadata_uuid relationship")
  2c5a947f8f7a ("btrfs: tree-checker: add support for raid stripe tree")
  2fe808177f98 ("btrfs: qgroup: use qgroup_iterator in __qgroup_excl_accounting()")
  37282c19f15b ("btrfs: relocation: switch bitfields to bool in reloc_control")
  37adfa983dde ("btrfs: qgroup: use qgroup_iterator in qgroup_convert_meta()")
  39e02b54f663 ("btrfs: qgroup: remove unused helpers for ulist aux data")
  3a2ccead18f6 ("btrfs: check-integrity: remove CONFIG_BTRFS_FS_CHECK_INTEGRITY option")
  3cf06838fab9 ("btrfs: remove pointless 'ref_root' variable from run_delayed_data_ref()")
  3dbaabf131ab ("btrfs: sysfs: expose quota mode via sysfs")
  401f89cc5c1e ("btrfs: reduce parameters of btrfs_pin_reserved_extent")
  4146050f0535 ("btrfs: utilize the physically/virtually continuous extent buffer memory")
  41dd41a59eef ("btrfs: split btrfs_fs_devices.opened")
  41f394848b0c ("btrfs: qgroup: introduce quota mode")
  44d518b3a2f3 ("btrfs: rename tree_ref and data_ref owning_root")
  44ef1e5b86ea ("btrfs: record simple quota deltas in delayed refs")
  4b58a2dbb970 ("btrfs: add raid stripe tree to features enabled with debug config")
  55f696fe8f18 ("btrfs: track original extent owner in head_ref")
  58d8cff02f7c ("btrfs: relocation: open code mapping_tree_init")
  5d2c6a3f6a5a ("btrfs: track data relocation with simple quota")
  5f5ff8f0d9ce ("btrfs: remove redundant root argument from maybe_insert_hole()")
  6261fa6c858f ("btrfs: reduce size of struct btrfs_ref")
  655df68dc47d ("btrfs: scrub: implement raid stripe tree support")
  667904274890 ("btrfs: qgroup: prealloc btrfs_qgroup_list for __add_relation_rb()")
  686b6a24fc74 ("btrfs: make extent_io_tree_release() more efficient")
  7181df86dc94 ("btrfs: check-integrity: remove btrfsic_unmount() function")
  775b26e4ccaa ("btrfs: remove redundant root argument from btrfs_delayed_update_inode()")
  78b5f8cf81a6 ("btrfs: make sure we cache next state in find_first_extent_bit()")
  7913ec811cb3 ("btrfs: reformat remaining kdoc style comments")
  7a2841ae12d7 ("btrfs: qgroup: track metadata relocation COW with simple quota")
  7b2f8e075d2b ("btrfs: tracepoints: add events for raid stripe tree")
  7ba59aa76414 ("btrfs: zoned: factor out DUP bg handling from btrfs_load_block_group_zone_info")
  7d2d132d7377 ("btrfs: qgroup: pre-allocate btrfs_qgroup to reduce GFP_ATOMIC usage")
  7e4ea691953d ("btrfs: add btrfs_delayed_ref_head declaration to extent-tree.h")
  81652d9abb4c ("btrfs: sipmlify uuid parameters of alloc_fs_devices()")
  847de878cd77 ("btrfs: create qgroup earlier in snapshot creation")
  8764e2b05fa2 ("btrfs: update comment for reservation of metadata space for delayed items")
  88303e09efeb ("btrfs: qgroup: add new quota mode for simple quotas")
  88d6b34c273b ("btrfs: add fscrypt related dependencies to respective headers")
  89a134e82379 ("btrfs: drop __must_check annotations")
  8c4c87fee0cb ("btrfs: initialize key where it's used when running delayed data ref")
  8c8c0668bc06 ("btrfs: remove redundant root argument from btrfs_update_inode_fallback()")
  8dbfbc8212b6 ("btrfs: remove unnecessary logic when running new delayed references")
  8f46ee177f9e ("btrfs: qgroup: only set QUOTA_ENABLED when done reading qgroups")
  8fccdeee3260 ("btrfs: use btrfs_crit at btrfs_mark_buffer_dirty()")
  90911b16854e ("btrfs: update stale comment at extent_io_tree_release()")
  974ea1e1dced ("btrfs: include linux/iomap.h in file.c")
  9823506bbabc ("btrfs: collapse wait_on_state() to its caller wait_extent_bit()")
  99fea7429097 ("btrfs: relocation: use enum for stages")
  9a8264cbc207 ("btrfs: remove refs_to_add argument from __btrfs_inc_extent_ref()")
  9af116141f5e ("btrfs: check-integrity: remove btrfsic_check_bio() function")
  a13fc1494581 ("btrfs: relocation: constify parameters where possible")
  a51d5aa50249 ("btrfs: move btrfs_defrag_root() to defrag.{c,h}")
  a5526bfa5317 ("btrfs: reserve space for delayed refs on a per ref basis")
  aa1cbbaaceb4 ("btrfs: add helper for inline owner ref lookup")
  adcbff903c0a ("btrfs: new inline ref storing owning subvol of data extents")
  ae3c53e03eaf ("btrfs: qgroup: check generation when recording simple quota delta")
  af2851c7e85c ("btrfs: qgroup: use qgroup_iterator in btrfs_qgroup_free_refroot()")
  b07a0f7efc15 ("btrfs: pass a space_info argument to btrfs_reserve_metadata_bytes()")
  b10a83023f61 ("btrfs: remove the refcount warning/check at btrfs_put_delayed_ref()")
  b1668d4289b5 ("btrfs: remove pointless loop from btrfs_update_block_group()")
  b17b48262238 ("btrfs: include linux/security.h in super.c")
  b464b68ffa11 ("btrfs: simplify check for extent item overrun at lookup_inline_extent_backref()")
  b4a664ad7058 ("btrfs: move btrfs_name_hash to dir-item.h")
  ba41e3f24f38 ("btrfs: zoned: introduce a zone_info struct in btrfs_load_block_group_zone_info")
  ba76f99bc974 ("btrfs: reduce parameters of btrfs_pin_extent_for_log_replay")
  bd07fb48543d ("btrfs: remove useless comment from btrfs_pin_extent_for_log_replay()")
  bd2397cfa662 ("btrfs: zoned: factor out per-zone logic from btrfs_load_block_group_zone_info")
  be4ccd3db6ad ("btrfs: remove redundant root argument from fixup_inode_link_count()")
  bf7009433d2c ("btrfs: move btrfs_crc32c_final into free-space-cache.c")
  c20943e2cfda ("btrfs: include trace header in where necessary")
  c43c08fdc78e ("btrfs: reduce size and reorder compression members in struct btrfs_inode")
  c461ca14b76e ("btrfs: remove incomplete metadata_uuid conversion fixup logic")
  c51cdcd1ba63 ("btrfs: make wait_extent_bit() static")
  c703dc4d72a6 ("btrfs: move functions comments from qgroup.h to qgroup.c")
  d056274031e5 ("btrfs: simplify error check condition at btrfs_dirty_inode()")
  d08ef7486357 ("btrfs: do not require EXTENT_NOWAIT for btrfs_redirty_list_add()")
  d1432a9acc60 ("btrfs: include asm/unaligned.h in accessors.h")
  d387ae42784d ("btrfs: remove noinline from btrfs_update_inode()")
  d6540ef346d1 ("btrfs: make extent state merges more efficient during insertions")
  d74100792148 ("btrfs: track owning root in btrfs_ref")
  d8897d7d197e ("btrfs: check-integrity: remove btrfsic_mount() function")
  da64d31c6820 ("btrfs: remove the need_raid_map parameter from btrfs_map_block()")
  da9b993b494f ("btrfs: add helper for recording simple quota deltas")
  dd20d5749497 ("btrfs: remove btrfs_crc32c wrapper")
  dd3800cf0f2b ("btrfs: zoned: support RAID0/1/10 on top of raid stripe tree")
  dd99b78be273 ("btrfs: open block devices after superblock creation")
  de2aa50f1af4 ("btrfs: abort transaction on generation mismatch when marking eb as dirty")
  e0a95452557f ("btrfs: read raid stripe tree from disk")
  e52ee3a64a18 ("btrfs: warn on tree blocks which are not nodesize aligned")
  e6aece34f28c ("btrfs: remove pointless memory barrier from extent_io_tree_release()")
  e79beb802f47 ("btrfs: qgroup: use qgroup_iterator_nested to in qgroup_update_refcnt()")
  e9ff4ac68dd9 ("btrfs: always reserve space for delayed refs when starting transaction")
  ed8c68fb0cad ("btrfs: sysfs: announce presence of raid-stripe-tree")
  f25fab65bfff ("btrfs: qgroup: simple quota auto hierarchy for nested subvolumes")
  f359f7ce2037 ("btrfs: relocation: return bool from btrfs_should_ignore_reloc_root")
  f4164e6df0d7 ("btrfs: use the super_block as holder when mounting file systems")
  f47602f7605d ("btrfs: allow to run delayed refs by bytes to be released instead of count")
  f4e65ababe47 ("btrfs: use extent_io_tree_release() to empty dirty log pages")
  f8fdb685b8d9 ("btrfs: switch btrfs_backref_cache::is_reloc to bool")
  f92547da557f ("btrfs: merge ordered work callbacks in btrfs_work into one")
  fa5cf2ac4d06 ("btrfs: reduce arguments of helpers space accounting root item")
  fdd5252afbc3 ("btrfs: remove extraneous includes from ctree.h")

I have dropped the vfs-brauner tree for today as there is no way I can
sort them out in a reasonable time.  Please sort this out between
yourselves.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Christian Brauner]

> I have dropped the vfs-brauner tree for today as there is no way I can
> sort them out in a reasonable time.  Please sort this out between
> yourselves.

I'll fix that up!

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

Hi Christian,

On Mon, 9 Oct 2023 18:15:53 +0200 Christian Brauner <brauner@kernel.org> wrote:
>
> > I have dropped the vfs-brauner tree for today as there is no way I can
> > sort them out in a reasonable time.  Please sort this out between
> > yourselves.  
> 
> I'll fix that up!

The btrfs tree
(git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git#for-next)
has moved again.  I don't know (yet) if this will cause conflicts
again, but there is a good chance that it will.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

Hi all,

On Wed, 11 Oct 2023 08:37:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 9 Oct 2023 18:15:53 +0200 Christian Brauner <brauner@kernel.org> wrote:
> >  
> > > I have dropped the vfs-brauner tree for today as there is no way I can
> > > sort them out in a reasonable time.  Please sort this out between
> > > yourselves.    
> > 
> > I'll fix that up!  
> 
> The btrfs tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git#for-next)
> has moved again.  I don't know (yet) if this will cause conflicts
> again, but there is a good chance that it will.

Yeah, I got those conflicts again, so dropped your tree again.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[David Sterba]

On Wed, Oct 11, 2023 at 08:37:54AM +1100, Stephen Rothwell wrote:
> Hi Christian,
> 
> On Mon, 9 Oct 2023 18:15:53 +0200 Christian Brauner <brauner@kernel.org> wrote:
> >
> > > I have dropped the vfs-brauner tree for today as there is no way I can
> > > sort them out in a reasonable time.  Please sort this out between
> > > yourselves.  
> > 
> > I'll fix that up!
> 
> The btrfs tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git#for-next)
> has moved again.  I don't know (yet) if this will cause conflicts
> again, but there is a good chance that it will.

I'm updating the for-next snapshost a few times a week but as this would
cause too much work for the VFS merges I'll do one more push but remove
anything that is not finalized for 6.7 merge window.

This should provide a stable base. I may need to push some fixes but
this could be done via the next-fixes branch so that it would not
interfere with auto-merging of the regular for-next.

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[David Sterba]

On Wed, Oct 11, 2023 at 11:20:04AM +0200, David Sterba wrote:
> On Wed, Oct 11, 2023 at 08:37:54AM +1100, Stephen Rothwell wrote:
> > Hi Christian,
> > 
> > On Mon, 9 Oct 2023 18:15:53 +0200 Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > > I have dropped the vfs-brauner tree for today as there is no way I can
> > > > sort them out in a reasonable time.  Please sort this out between
> > > > yourselves.  
> > > 
> > > I'll fix that up!
> > 
> > The btrfs tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git#for-next)
> > has moved again.  I don't know (yet) if this will cause conflicts
> > again, but there is a good chance that it will.
> 
> I'm updating the for-next snapshost a few times a week but as this would
> cause too much work for the VFS merges I'll do one more push but remove
> anything that is not finalized for 6.7 merge window.
> 
> This should provide a stable base. I may need to push some fixes but
> this could be done via the next-fixes branch so that it would not
> interfere with auto-merging of the regular for-next.

The branch for-next at git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git
has been pushed with top commit c6e8f898f56fae2cb5bc4396bec480f23cd8b066
and I won't update it (expecting until the merge window).

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[David Sterba]

On Thu, Oct 12, 2023 at 05:42:10PM +0200, David Sterba wrote:
> On Wed, Oct 11, 2023 at 11:20:04AM +0200, David Sterba wrote:
> > On Wed, Oct 11, 2023 at 08:37:54AM +1100, Stephen Rothwell wrote:
> > > Hi Christian,
> > > 
> > > On Mon, 9 Oct 2023 18:15:53 +0200 Christian Brauner <brauner@kernel.org> wrote:
> > > >
> > > > > I have dropped the vfs-brauner tree for today as there is no way I can
> > > > > sort them out in a reasonable time.  Please sort this out between
> > > > > yourselves.  
> > > > 
> > > > I'll fix that up!
> > > 
> > > The btrfs tree
> > > (git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git#for-next)
> > > has moved again.  I don't know (yet) if this will cause conflicts
> > > again, but there is a good chance that it will.
> > 
> > I'm updating the for-next snapshost a few times a week but as this would
> > cause too much work for the VFS merges I'll do one more push but remove
> > anything that is not finalized for 6.7 merge window.
> > 
> > This should provide a stable base. I may need to push some fixes but
> > this could be done via the next-fixes branch so that it would not
> > interfere with auto-merging of the regular for-next.
> 
> The branch for-next at git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git
> has been pushed with top commit c6e8f898f56fae2cb5bc4396bec480f23cd8b066
> and I won't update it (expecting until the merge window).

I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
There are some fixes I don't want to miss from the 6.7 pull request.
There should be minimal change to the VFS tree conflict resolution so
the diff should be reusable.

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

Hi David,

On Mon, 23 Oct 2023 19:55:13 +0200 David Sterba <dsterba@suse.cz> wrote:
>
> I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
> There are some fixes I don't want to miss from the 6.7 pull request.
> There should be minimal change to the VFS tree conflict resolution so
> the diff should be reusable.

So, why did you not just merge in v6.6-rc7 (or better yet, the branch
that contains the fix(es) that Linus merged) and then apply your new
commits on top of that?  All the commits that were in the btrfs tree
have been rebased unchanged.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

upcoming merge window: Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Christian Brauner]

On Tue, Oct 24, 2023 at 08:25:43AM +1100, Stephen Rothwell wrote:
> Hi David,
> 
> On Mon, 23 Oct 2023 19:55:13 +0200 David Sterba <dsterba@suse.cz> wrote:
> >
> > I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
> > There are some fixes I don't want to miss from the 6.7 pull request.
> > There should be minimal change to the VFS tree conflict resolution so
> > the diff should be reusable.
> 
> So, why did you not just merge in v6.6-rc7 (or better yet, the branch
> that contains the fix(es) that Linus merged) and then apply your new
> commits on top of that?  All the commits that were in the btrfs tree
> have been rebased unchanged.

Please reconsider that and follow Stephen's suggestion. I'm sending pull
requests this week and it'd be really annoying having to rebase
vfs.super right before sending them.

We let you carry the required patches in btrfs on your insistence even
though this effectively blocked two patchsets for a whole cycle and then
merged in btrfs into vfs.super for that. Rebasing on such short notice
is really not very nice.

I'm going to wait with the rebase for a bit.

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[David Sterba]

On Tue, Oct 24, 2023 at 08:25:43AM +1100, Stephen Rothwell wrote:
> Hi David,
> 
> On Mon, 23 Oct 2023 19:55:13 +0200 David Sterba <dsterba@suse.cz> wrote:
> >
> > I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
> > There are some fixes I don't want to miss from the 6.7 pull request.
> > There should be minimal change to the VFS tree conflict resolution so
> > the diff should be reusable.
> 
> So, why did you not just merge in v6.6-rc7 (or better yet, the branch
> that contains the fix(es) that Linus merged) and then apply your new
> commits on top of that?  All the commits that were in the btrfs tree
> have been rebased unchanged.

I don't back merge Linus' branches nor the fixes that I send, that's
against what I understand is the recommended practice. The development
queue gets rebased on top of the rc, in that way it's clean and
eventually drops patches sent independently merged to the master branch.

What you suggest I don't even visualize, like keep my previous frozen
branch on rc5, merge rc7 and then merge some other branch with the
recent fix? Or create another one with just additional patches (there
were like 10)? That looks as if the btrfs tree would be quite busy but
in fact it's not, the linear series makes a lot of things easier.
For example I add Reviewed-by, CC: stable@ or other tags, fix typos or
fix whitespace as long as there's another sync point before the code
freeze.

My workflow has been working well but now there's a huge pile of
conflicting VFS changes that require other trees to effectively stop
taking new patches or require back merges from Linus.

I've assumed that linux-next can deal with rebases and eventual conflict
resolutions stay applicable in some way and that one more sync a week
before merge window is enough time for everybody to sync.

Re: upcoming merge window: Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[David Sterba]

On Tue, Oct 24, 2023 at 10:59:39AM +0200, Christian Brauner wrote:
> On Tue, Oct 24, 2023 at 08:25:43AM +1100, Stephen Rothwell wrote:
> > Hi David,
> > 
> > On Mon, 23 Oct 2023 19:55:13 +0200 David Sterba <dsterba@suse.cz> wrote:
> > >
> > > I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
> > > There are some fixes I don't want to miss from the 6.7 pull request.
> > > There should be minimal change to the VFS tree conflict resolution so
> > > the diff should be reusable.
> > 
> > So, why did you not just merge in v6.6-rc7 (or better yet, the branch
> > that contains the fix(es) that Linus merged) and then apply your new
> > commits on top of that?  All the commits that were in the btrfs tree
> > have been rebased unchanged.
> 
> Please reconsider that and follow Stephen's suggestion. I'm sending pull
> requests this week and it'd be really annoying having to rebase
> vfs.super right before sending them.
> 
> We let you carry the required patches in btrfs on your insistence even
> though this effectively blocked two patchsets for a whole cycle

I hope I explained my reasons already under that series, core btrfs
changes should not go via VFS tree.

> and then
> merged in btrfs into vfs.super for that. Rebasing on such short notice
> is really not very nice.

Like said in the my other reply, the amount of VFS changes asks for
stopping taking new patches to btrfs and not continuing the patch
workflow that I've been doing. I understand that the inter-tree
dependencies are never easy so it's about finding some common way and
splitting the work over more releases eventually.

A resync of our branches a week before merge window, when there are no
significant changes on my side does not sound like too short notice, but
you can feel otherwise of course.

> I'm going to wait with the rebase for a bit.

Ok, don't rebase. I'll push to linux-next the previous snapshot and will
find a way how to deliver the new patches.

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Hi David,

On Tue, 24 Oct 2023 17:32:29 +0200 David Sterba <dsterba@suse.cz> wrote:
>
> On Tue, Oct 24, 2023 at 08:25:43AM +1100, Stephen Rothwell wrote:
> > 
> > On Mon, 23 Oct 2023 19:55:13 +0200 David Sterba <dsterba@suse.cz> wrote:  
> > >
> > > I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
> > > There are some fixes I don't want to miss from the 6.7 pull request.
> > > There should be minimal change to the VFS tree conflict resolution so
> > > the diff should be reusable.  
> > 
> > So, why did you not just merge in v6.6-rc7 (or better yet, the branch
> > that contains the fix(es) that Linus merged) and then apply your new
> > commits on top of that?  All the commits that were in the btrfs tree
> > have been rebased unchanged.  
> 
> I don't back merge Linus' branches nor the fixes that I send, that's
> against what I understand is the recommended practice. The development
> queue gets rebased on top of the rc, in that way it's clean and
> eventually drops patches sent independently merged to the master branch.

Please read Documentation/maintainer/rebasing-and-merging.rst

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: upcoming merge window: Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Christian Brauner]

On Tue, Oct 24, 2023 at 05:46:20PM +0200, David Sterba wrote:
> On Tue, Oct 24, 2023 at 10:59:39AM +0200, Christian Brauner wrote:
> > On Tue, Oct 24, 2023 at 08:25:43AM +1100, Stephen Rothwell wrote:
> > > Hi David,
> > > 
> > > On Mon, 23 Oct 2023 19:55:13 +0200 David Sterba <dsterba@suse.cz> wrote:
> > > >
> > > > I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
> > > > There are some fixes I don't want to miss from the 6.7 pull request.
> > > > There should be minimal change to the VFS tree conflict resolution so
> > > > the diff should be reusable.
> > > 
> > > So, why did you not just merge in v6.6-rc7 (or better yet, the branch
> > > that contains the fix(es) that Linus merged) and then apply your new
> > > commits on top of that?  All the commits that were in the btrfs tree
> > > have been rebased unchanged.
> > 
> > Please reconsider that and follow Stephen's suggestion. I'm sending pull
> > requests this week and it'd be really annoying having to rebase
> > vfs.super right before sending them.
> > 
> > We let you carry the required patches in btrfs on your insistence even
> > though this effectively blocked two patchsets for a whole cycle
> 
> I hope I explained my reasons already under that series, core btrfs
> changes should not go via VFS tree.
> 
> > and then
> > merged in btrfs into vfs.super for that. Rebasing on such short notice
> > is really not very nice.
> 
> Like said in the my other reply, the amount of VFS changes asks for
> stopping taking new patches to btrfs and not continuing the patch
> workflow that I've been doing. I understand that the inter-tree
> dependencies are never easy so it's about finding some common way and
> splitting the work over more releases eventually.
> 
> A resync of our branches a week before merge window, when there are no

Pull requests for VFS and a bunch of other trees are going out the week
before the merge window opens. This has been requested multiple times.
It's mentioned in almost every kernel release mail that pull requests
should go out early.

So you rebasing a week before the merge window means rebasing
right before the pr is sent for us. You might send pull requests later
and are free to do so of course but you made us depend on your tree so
we need some stability. That's why the rebase is problematic here.

> significant changes on my side does not sound like too short notice, but
> you can feel otherwise of course.
> 
> > I'm going to wait with the rebase for a bit.
> 
> Ok, don't rebase. I'll push to linux-next the previous snapshot and will
> find a way how to deliver the new patches.

Thanks! So I know you have your workflow and that's obviously fine but
rebasing when other major trees depend on your tree is a problem and I
believe Stephen has already linked to our official "Rebasing and
merging" documentation:

"- Do not reparent a tree without a good reason to do so.  Just being on a
   newer base or avoiding a merge with an upstream repository is not
   generally a good reason."

[...]

"A frequent cause of merge-window trouble is when Linus is presented with a
patch series that has clearly been reparented, often to a random commit,
shortly before the pull request was sent.  The chances of such a series
having been adequately tested are relatively low - as are the chances of
the pull request being acted upon."

So I'll make sure to point out that we're depending on the btrfs tree
and I have a clear merge commit explaining why we're pulling it in. All
of that would be invalidated if you're rebasing. So not rebasing really
helps us a lot.

I specifically put Linus in Cc so hopefully everyone is aware up front
and there are no unnecessary suprises during the merge window.

upcoming merge window: Where did the patches we had intended to depend on go? vfs-brauner tree with the btrfs tree

[Christian Brauner]

On Wed, Oct 25, 2023 at 03:19:11PM +0200, Christian Brauner wrote:
> On Tue, Oct 24, 2023 at 05:46:20PM +0200, David Sterba wrote:
> > On Tue, Oct 24, 2023 at 10:59:39AM +0200, Christian Brauner wrote:
> > > On Tue, Oct 24, 2023 at 08:25:43AM +1100, Stephen Rothwell wrote:
> > > > Hi David,
> > > > 
> > > > On Mon, 23 Oct 2023 19:55:13 +0200 David Sterba <dsterba@suse.cz> wrote:
> > > > >
> > > > > I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
> > > > > There are some fixes I don't want to miss from the 6.7 pull request.
> > > > > There should be minimal change to the VFS tree conflict resolution so
> > > > > the diff should be reusable.
> > > > 
> > > > So, why did you not just merge in v6.6-rc7 (or better yet, the branch
> > > > that contains the fix(es) that Linus merged) and then apply your new
> > > > commits on top of that?  All the commits that were in the btrfs tree
> > > > have been rebased unchanged.
> > > 
> > > Please reconsider that and follow Stephen's suggestion. I'm sending pull
> > > requests this week and it'd be really annoying having to rebase
> > > vfs.super right before sending them.
> > > 
> > > We let you carry the required patches in btrfs on your insistence even
> > > though this effectively blocked two patchsets for a whole cycle
> > 
> > I hope I explained my reasons already under that series, core btrfs
> > changes should not go via VFS tree.
> > 
> > > and then
> > > merged in btrfs into vfs.super for that. Rebasing on such short notice
> > > is really not very nice.
> > 
> > Like said in the my other reply, the amount of VFS changes asks for
> > stopping taking new patches to btrfs and not continuing the patch
> > workflow that I've been doing. I understand that the inter-tree
> > dependencies are never easy so it's about finding some common way and
> > splitting the work over more releases eventually.
> > 
> > A resync of our branches a week before merge window, when there are no
> 
> Pull requests for VFS and a bunch of other trees are going out the week
> before the merge window opens. This has been requested multiple times.
> It's mentioned in almost every kernel release mail that pull requests
> should go out early.
> 
> So you rebasing a week before the merge window means rebasing
> right before the pr is sent for us. You might send pull requests later
> and are free to do so of course but you made us depend on your tree so
> we need some stability. That's why the rebase is problematic here.
> 
> > significant changes on my side does not sound like too short notice, but
> > you can feel otherwise of course.
> > 
> > > I'm going to wait with the rebase for a bit.
> > 
> > Ok, don't rebase. I'll push to linux-next the previous snapshot and will
> > find a way how to deliver the new patches.
> 
> Thanks! So I know you have your workflow and that's obviously fine but
> rebasing when other major trees depend on your tree is a problem and I
> believe Stephen has already linked to our official "Rebasing and
> merging" documentation:
> 
> "- Do not reparent a tree without a good reason to do so.  Just being on a
>    newer base or avoiding a merge with an upstream repository is not
>    generally a good reason."
> 
> [...]
> 
> "A frequent cause of merge-window trouble is when Linus is presented with a
> patch series that has clearly been reparented, often to a random commit,
> shortly before the pull request was sent.  The chances of such a series
> having been adequately tested are relatively low - as are the chances of
> the pull request being acted upon."
> 
> So I'll make sure to point out that we're depending on the btrfs tree
> and I have a clear merge commit explaining why we're pulling it in. All
> of that would be invalidated if you're rebasing. So not rebasing really
> helps us a lot.
> 
> I specifically put Linus in Cc so hopefully everyone is aware up front
> and there are no unnecessary suprises during the merge window.

So now I'm confused.

I prepared the vfs-6.7.super pull request yesterday and was about to
write the pull request message earlier and was about to send it out. And
I did the usual checklist and takinga another close look at all the
patches:

Where are the patches that you insisted go through the btrfs tree and
that made us merge in the btrfs/for-next tree into vfs.super?

commit d6b5ffd5520a ("btrfs: use the super_block as holder when mounting file systems")
commit 6d0eb684ad4a ("btrfs: open block devices after superblock creation")
commit 8f05745a1bf9 ("btrfs: split btrfs_fs_devices.opened")
commit 987b157f182e ("btrfs: call btrfs_close_devices from ->kill_sb")
commit b87aed6ff4c3 ("btrfs: always open the device read-only in btrfs_scan_one_device")

They were in btrfs/for-next on October 10, then you rebased and whatever
is in btrfs/for-next that we merged in doesn't contain any of these
patches. The top commit I have and that's visible in your repo is:
c6e8f898f56f ("btrfs: open code timespec64 in struct btrfs_inode")

So what happened and why weren't we told any of this as we did point out
that we want to depend on this?

I'm rebasing vfs.super onto plain v6.6-rc7 and dropping the btrfs merge
completely as this is now completely pointless and it doesn't feely very
transparent.

If the btrfs tree somehow ends up bringing in these changes then that's
fine. We've reworked locking requirements this cycle and so we will be
fine without these changes.

But you're actively blocking Jan from making progress with restricting
writers to a block device because they are required for that for the
second merge window.

And I hope we won't be repeating this cycle's churn again coming cycle.

And btw, as mentioned multiple times and reported upstream
https://lore.kernel.org/linux-btrfs/20230908-merklich-bebauen-11914a630db4@brauner
btrfs is broken when freezing block devices through the block layer
(e.g., device mapper). Something we also can't fix without these
patches.

linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/btrfs/disk-io.c

between commits:

  4a63bd0ffbd2 ("btrfs: convert super block writes to folio in wait_dev_supers()")
  545799bb1bb9 ("btrfs: count super block write errors in device instead of tracking folio error state")

from the btrfs tree and commit:

  db3102368e1b ("use ->bd_mapping instead of ->bd_inode->i_mapping")

from the vfs-brauner tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/disk-io.c
index e8aca9f0e692,f10e894b0bf5..000000000000
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@@ -3739,9 -3738,10 +3739,9 @@@ static int write_dev_supers(struct btrf
  			    struct btrfs_super_block *sb, int max_mirrors)
  {
  	struct btrfs_fs_info *fs_info = device->fs_info;
- 	struct address_space *mapping = device->bdev->bd_inode->i_mapping;
+ 	struct address_space *mapping = device->bdev->bd_mapping;
  	SHASH_DESC_ON_STACK(shash, fs_info->csum_shash);
  	int i;
 -	int errors = 0;
  	int ret;
  	u64 bytenr, bytenr_orig;
  
@@@ -3857,21 -3855,30 +3857,21 @@@ static int wait_dev_supers(struct btrfs
  		    device->commit_total_bytes)
  			break;
  
- 		folio = filemap_get_folio(device->bdev->bd_inode->i_mapping,
 -		page = find_get_page(device->bdev->bd_mapping,
 -				     bytenr >> PAGE_SHIFT);
 -		if (!page) {
 -			errors++;
 -			if (i == 0)
 -				primary_failed = true;
++		folio = filemap_get_folio(device->bdev->bd_mapping,
 +					  bytenr >> PAGE_SHIFT);
 +		/* If the folio has been removed, then we know it completed. */
 +		if (IS_ERR(folio))
  			continue;
 -		}
 -		/* Page is submitted locked and unlocked once the IO completes */
 -		wait_on_page_locked(page);
 -		if (PageError(page)) {
 -			errors++;
 -			if (i == 0)
 -				primary_failed = true;
 -		}
 +		ASSERT(folio_order(folio) == 0);
  
 -		/* Drop our reference */
 -		put_page(page);
 -
 -		/* Drop the reference from the writing run */
 -		put_page(page);
 +		/* Folio will be unlocked once the write completes. */
 +		folio_wait_locked(folio);
 +		folio_put(folio);
  	}
  
 -	/* log error, force error return */
 +	errors += atomic_read(&device->sb_write_errors);
 +	if (errors >= BTRFS_SUPER_PRIMARY_WRITE_ERROR)
 +		primary_failed = true;
  	if (primary_failed) {
  		btrfs_err(device->fs_info, "error writing primary super block to device %llu",
  			  device->devid);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/btrfs/disk-io.c

between commit:

  5c855642bbb9 ("btrfs: Use a folio in wait_dev_supers()")

from the btrfs tree and commit:

  db3102368e1b ("use ->bd_mapping instead of ->bd_inode->i_mapping")

from the vfs-brauner tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/disk-io.c
index 6b3720b13939,f10e894b0bf5..000000000000
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@@ -3739,9 -3738,10 +3739,9 @@@ static int write_dev_supers(struct btrf
  			    struct btrfs_super_block *sb, int max_mirrors)
  {
  	struct btrfs_fs_info *fs_info = device->fs_info;
- 	struct address_space *mapping = device->bdev->bd_inode->i_mapping;
+ 	struct address_space *mapping = device->bdev->bd_mapping;
  	SHASH_DESC_ON_STACK(shash, fs_info->csum_shash);
  	int i;
 -	int errors = 0;
  	int ret;
  	u64 bytenr, bytenr_orig;
  
@@@ -3855,19 -3855,29 +3855,19 @@@ static int wait_dev_supers(struct btrfs
  		    device->commit_total_bytes)
  			break;
  
- 		folio = filemap_get_folio(device->bdev->bd_inode->i_mapping,
 -		page = find_get_page(device->bdev->bd_mapping,
++		folio = filemap_get_folio(device->bdev->bd_mapping,
  				     bytenr >> PAGE_SHIFT);
 -		if (!page) {
 -			errors++;
 -			if (i == 0)
 -				primary_failed = true;
 +		/* If the folio has been removed, then we know it completed */
 +		if (IS_ERR(folio))
  			continue;
 -		}
 -		/* Page is submitted locked and unlocked once the IO completes */
 -		wait_on_page_locked(page);
 -		if (PageError(page)) {
 -			errors++;
 -			if (i == 0)
 -				primary_failed = true;
 -		}
 -
 -		/* Drop our reference */
 -		put_page(page);
 -
 -		/* Drop the reference from the writing run */
 -		put_page(page);
 +		/* Folio is unlocked once the IO completes */
 +		folio_wait_locked(folio);
 +		folio_put(folio);
  	}
  
 +	errors += atomic_read(&device->sb_wb_errors);
 +	if (errors >= BTRFS_DEV_PRIMARY_ERROR)
 +		primary_failed = true;
  	/* log error, force error return */
  	if (primary_failed) {
  		btrfs_err(device->fs_info, "error writing primary super block to device %llu",

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 8990 bytes --]

Hi all,

On Thu, 7 Dec 2023 10:32:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/btrfs/extent_io.c
> 
> between commits:
> 
>   16aee93de711 ("btrfs: migrate to use folio private instead of page private")
>   042eab832c43 ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method")
> 
> from the btrfs tree and commit:
> 
>   600f111ef51d ("fs: Rename mapping private members")
> 
> from the vfs-brauner tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc fs/btrfs/extent_io.c
> index 5cae7884e8d9,3431a53bf3fd..000000000000
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@@ -881,13 -870,13 +881,13 @@@ static int attach_extent_buffer_page(st
>   	 * will not race with any other ebs.
>   	 */
>   	if (page->mapping)
> - 		lockdep_assert_held(&page->mapping->private_lock);
> + 		lockdep_assert_held(&page->mapping->i_private_lock);
>   
>   	if (fs_info->nodesize >= PAGE_SIZE) {
>  -		if (!PagePrivate(page))
>  -			attach_page_private(page, eb);
>  +		if (!folio_test_private(folio))
>  +			folio_attach_private(folio, eb);
>   		else
>  -			WARN_ON(page->private != (unsigned long)eb);
>  +			WARN_ON(folio_get_private(folio) != eb);
>   		return 0;
>   	}
>   
> @@@ -1750,9 -1736,9 +1750,9 @@@ static int submit_eb_subpage(struct pag
>   		 * Take private lock to ensure the subpage won't be detached
>   		 * in the meantime.
>   		 */
> - 		spin_lock(&page->mapping->private_lock);
> + 		spin_lock(&page->mapping->i_private_lock);
>  -		if (!PagePrivate(page)) {
>  +		if (!folio_test_private(folio)) {
> - 			spin_unlock(&page->mapping->private_lock);
> + 			spin_unlock(&page->mapping->i_private_lock);
>   			break;
>   		}
>   		spin_lock_irqsave(&subpage->lock, flags);
> @@@ -1826,9 -1811,9 +1826,9 @@@ static int submit_eb_page(struct page *
>   	if (btrfs_sb(page->mapping->host->i_sb)->nodesize < PAGE_SIZE)
>   		return submit_eb_subpage(page, wbc);
>   
> - 	spin_lock(&mapping->private_lock);
> + 	spin_lock(&mapping->i_private_lock);
>  -	if (!PagePrivate(page)) {
>  +	if (!folio_test_private(folio)) {
> - 		spin_unlock(&mapping->private_lock);
> + 		spin_unlock(&mapping->i_private_lock);
>   		return 0;
>   	}
>   
> @@@ -3070,13 -3054,12 +3070,13 @@@ static int extent_buffer_under_io(cons
>   
>   static bool page_range_has_eb(struct btrfs_fs_info *fs_info, struct page *page)
>   {
>  +	struct folio *folio = page_folio(page);
>   	struct btrfs_subpage *subpage;
>   
> - 	lockdep_assert_held(&page->mapping->private_lock);
> + 	lockdep_assert_held(&page->mapping->i_private_lock);
>   
>  -	if (PagePrivate(page)) {
>  -		subpage = (struct btrfs_subpage *)page->private;
>  +	if (folio_test_private(folio)) {
>  +		subpage = folio_get_private(folio);
>   		if (atomic_read(&subpage->eb_refs))
>   			return true;
>   		/*
> @@@ -3093,18 -3076,17 +3093,18 @@@ static void detach_extent_buffer_page(s
>   {
>   	struct btrfs_fs_info *fs_info = eb->fs_info;
>   	const bool mapped = !test_bit(EXTENT_BUFFER_UNMAPPED, &eb->bflags);
>  +	struct folio *folio = page_folio(page);
>   
>   	/*
>  -	 * For mapped eb, we're going to change the page private, which should
>  +	 * For mapped eb, we're going to change the folio private, which should
> - 	 * be done under the private_lock.
> + 	 * be done under the i_private_lock.
>   	 */
>   	if (mapped)
> - 		spin_lock(&page->mapping->private_lock);
> + 		spin_lock(&page->mapping->i_private_lock);
>   
>  -	if (!PagePrivate(page)) {
>  +	if (!folio_test_private(folio)) {
>   		if (mapped)
> - 			spin_unlock(&page->mapping->private_lock);
> + 			spin_unlock(&page->mapping->i_private_lock);
>   		return;
>   	}
>   
> @@@ -3120,11 -3103,14 +3120,11 @@@
>   			BUG_ON(test_bit(EXTENT_BUFFER_DIRTY, &eb->bflags));
>   			BUG_ON(PageDirty(page));
>   			BUG_ON(PageWriteback(page));
>  -			/*
>  -			 * We need to make sure we haven't be attached
>  -			 * to a new eb.
>  -			 */
>  -			detach_page_private(page);
>  +			/* We need to make sure we haven't be attached to a new eb. */
>  +			folio_detach_private(folio);
>   		}
>   		if (mapped)
> - 			spin_unlock(&page->mapping->private_lock);
> + 			spin_unlock(&page->mapping->i_private_lock);
>   		return;
>   	}
>   
> @@@ -3588,8 -3513,8 +3588,8 @@@ struct extent_buffer *alloc_extent_buff
>   	num_pages = num_extent_pages(eb);
>   
>   	/*
>  -	 * Preallocate page->private for subpage case, so that we won't
>  +	 * Preallocate folio private for subpage case, so that we won't
> - 	 * allocate memory with private_lock nor page lock hold.
> + 	 * allocate memory with i_private_lock nor page lock hold.
>   	 *
>   	 * The memory will be freed by attach_extent_buffer_page() or freed
>   	 * manually if we exit earlier.
> @@@ -3602,31 -3527,24 +3602,31 @@@
>   		}
>   	}
>   
>  -	for (i = 0; i < num_pages; i++, index++) {
>  -		p = find_or_create_page(mapping, index, GFP_NOFS|__GFP_NOFAIL);
>  -		if (!p) {
>  -			exists = ERR_PTR(-ENOMEM);
>  -			btrfs_free_subpage(prealloc);
>  -			goto free_eb;
>  -		}
>  +	/* Allocate all pages first. */
>  +	ret = btrfs_alloc_page_array(num_pages, eb->pages, __GFP_NOFAIL);
>  +	if (ret < 0) {
>  +		btrfs_free_subpage(prealloc);
>  +		goto out;
>  +	}
>   
>  -		spin_lock(&mapping->i_private_lock);
>  -		exists = grab_extent_buffer(fs_info, p);
>  -		if (exists) {
>  -			spin_unlock(&mapping->i_private_lock);
>  -			unlock_page(p);
>  -			put_page(p);
>  -			mark_extent_buffer_accessed(exists, p);
>  -			btrfs_free_subpage(prealloc);
>  -			goto free_eb;
>  +	/* Attach all pages to the filemap. */
>  +	for (int i = 0; i < num_pages; i++) {
>  +		struct page *p;
>  +
>  +		ret = attach_eb_page_to_filemap(eb, i, &existing_eb);
>  +		if (ret > 0) {
>  +			ASSERT(existing_eb);
>  +			goto out;
>   		}
>  +		attached++;
>  +
>  +		/*
>  +		 * Only after attach_eb_page_to_filemap(), eb->pages[] is
>  +		 * reliable, as we may choose to reuse the existing page cache
>  +		 * and free the allocated page.
>  +		 */
>  +		p = eb->pages[i];
> - 		spin_lock(&mapping->private_lock);
> ++		spin_lock(&mapping->i_private_lock);
>   		/* Should not fail, as we have preallocated the memory */
>   		ret = attach_extent_buffer_page(eb, p, prealloc);
>   		ASSERT(!ret);
> @@@ -3640,17 -3558,10 +3640,17 @@@
>   		 * Thus needs no special handling in error path.
>   		 */
>   		btrfs_page_inc_eb_refs(fs_info, p);
> - 		spin_unlock(&mapping->private_lock);
> + 		spin_unlock(&mapping->i_private_lock);
>   
>   		WARN_ON(btrfs_page_test_dirty(fs_info, p, eb->start, eb->len));
>  -		eb->pages[i] = p;
>  +
>  +		/*
>  +		 * Check if the current page is physically contiguous with previous eb
>  +		 * page.
>  +		 */
>  +		if (i && eb->pages[i - 1] + 1 != p)
>  +			page_contig = false;
>  +
>   		if (!btrfs_page_test_uptodate(fs_info, p, eb->start, eb->len))
>   			uptodate = 0;
>   
> @@@ -4713,11 -4560,11 +4713,11 @@@ static int try_release_subpage_extent_b
>   		release_extent_buffer(eb);
>   	}
>   	/*
>  -	 * Finally to check if we have cleared page private, as if we have
>  -	 * released all ebs in the page, the page private should be cleared now.
>  +	 * Finally to check if we have cleared folio private, as if we have
>  +	 * released all ebs in the page, the folio private should be cleared now.
>   	 */
> - 	spin_lock(&page->mapping->private_lock);
> + 	spin_lock(&page->mapping->i_private_lock);
>  -	if (!PagePrivate(page))
>  +	if (!folio_test_private(page_folio(page)))
>   		ret = 1;
>   	else
>   		ret = 0;
> @@@ -4735,12 -4581,12 +4735,12 @@@ int try_release_extent_buffer(struct pa
>   		return try_release_subpage_extent_buffer(page);
>   
>   	/*
>  -	 * We need to make sure nobody is changing page->private, as we rely on
>  -	 * page->private as the pointer to extent buffer.
>  +	 * We need to make sure nobody is changing folio private, as we rely on
>  +	 * folio private as the pointer to extent buffer.
>   	 */
> - 	spin_lock(&page->mapping->private_lock);
> + 	spin_lock(&page->mapping->i_private_lock);
>  -	if (!PagePrivate(page)) {
>  +	if (!folio_test_private(folio)) {
> - 		spin_unlock(&page->mapping->private_lock);
> + 		spin_unlock(&page->mapping->i_private_lock);
>   		return 1;
>   	}
>   

This is now a conflict between the btrfs tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3558 bytes --]

Hi all,

On Thu, 30 Nov 2023 07:50:21 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 29 Nov 2023 12:09:30 +0100 Jan Kara <jack@suse.cz> wrote:
> >
> > On Tue 28-11-23 14:33:44, Nathan Chancellor wrote:  
> > > Hi Stephen (and other maintainers),
> > > 
> > > On Mon, Nov 27, 2023 at 09:20:01AM +1100, Stephen Rothwell wrote:    
> > > > Hi all,
> > > > 
> > > > Today's linux-next merge of the vfs-brauner tree got a conflict in:
> > > > 
> > > >   fs/btrfs/super.c
> > > > 
> > > > between commit:
> > > > 
> > > >   2f2cfead5107 ("btrfs: remove old mount API code")
> > > > 
> > > > from the btrfs tree and commit:
> > > > 
> > > >   ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
> > > > 
> > > > from the vfs-brauner tree.
> > > > 
> > > > I fixed it up (the former removed the funtion updated by the latter, but
> > > > a further fix may be required to implement the intent of the latter?)    
> > > 
> > > Yes, the lack of ead622674df5 appears to cause issues with mounting
> > > btrfs volumes on at least next-20231128 due to the presence of commit
> > > 6f861765464f ("fs: Block writes to mounted block devices"). In QEMU, I
> > > can see:
> > > 
> > >   :: running early hook [udev]
> > >   Warning: /lib/modules/6.7.0-rc3-next-20231128/modules.devname not found - ignoring
> > >   Starting systemd-udevd version 252.5-1-arch
> > >   :: running hook [udev]
> > >   :: Triggering uevents...
> > >   :: running hook [keymap]
> > >   :: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
> > >   done.
> > >   :: performing fsck on '/dev/vda2'
> > >   :: mounting '/dev/vda2' on real root
> > >   mount: /new_root: wrong fs type, bad option, bad superblock on /dev/vda2, missing codepage or helper program, or other error.
> > >          dmesg(1) may have more information after failed mount system call.
> > >   You are now being dropped into an emergency shell.
> > >   sh: can't access tty; job control turned off
> > >   [rootfs ]#
> > > 
> > > The following diff allows my VM to boot properly but I am not sure if
> > > there is a better or more proper fix (I am already out of my element
> > > heh). If a proper merge solution cannot be found quickly, can
> > > 6f861765464f be reverted in the meantime so that all my machines with
> > > btrfs can boot properly? :)
> > > 
> > > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> > > index 99d10a25a579..23db0306b8ef 100644
> > > --- a/fs/btrfs/super.c
> > > +++ b/fs/btrfs/super.c
> > > @@ -299,6 +299,7 @@ static int btrfs_parse_param(struct fs_context *fc,
> > >  	case Opt_device: {
> > >  		struct btrfs_device *device;
> > >  		blk_mode_t mode = sb_open_mode(fc->sb_flags);
> > > +		mode &= ~BLK_OPEN_RESTRICT_WRITES;
> > >  
> > >  		mutex_lock(&uuid_mutex);
> > >  		device = btrfs_scan_one_device(param->string, mode, false);
> > > @@ -1801,6 +1802,8 @@ static int btrfs_get_tree_super(struct fs_context *fc)
> > >  	blk_mode_t mode = sb_open_mode(fc->sb_flags);
> > >  	int ret;
> > >  
> > > +	mode &= ~BLK_OPEN_RESTRICT_WRITES;
> > > +
> > >  	btrfs_ctx_to_info(fs_info, ctx);
> > >  	mutex_lock(&uuid_mutex);    
> > 
> > This looks like the proper resolution. Basically btrfs needs to strip
> > BLK_OPEN_RESTRICT_WRITES from the mode provided by sb_open_mode(). Thanks
> > for writing it!  
> 
> I have added this patch as a merge fix from today.

This is now a conflict between the btrfs tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 8310 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/btrfs/extent_io.c

between commits:

  16aee93de711 ("btrfs: migrate to use folio private instead of page private")
  042eab832c43 ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method")

from the btrfs tree and commit:

  600f111ef51d ("fs: Rename mapping private members")

from the vfs-brauner tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/extent_io.c
index 5cae7884e8d9,3431a53bf3fd..000000000000
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@@ -881,13 -870,13 +881,13 @@@ static int attach_extent_buffer_page(st
  	 * will not race with any other ebs.
  	 */
  	if (page->mapping)
- 		lockdep_assert_held(&page->mapping->private_lock);
+ 		lockdep_assert_held(&page->mapping->i_private_lock);
  
  	if (fs_info->nodesize >= PAGE_SIZE) {
 -		if (!PagePrivate(page))
 -			attach_page_private(page, eb);
 +		if (!folio_test_private(folio))
 +			folio_attach_private(folio, eb);
  		else
 -			WARN_ON(page->private != (unsigned long)eb);
 +			WARN_ON(folio_get_private(folio) != eb);
  		return 0;
  	}
  
@@@ -1750,9 -1736,9 +1750,9 @@@ static int submit_eb_subpage(struct pag
  		 * Take private lock to ensure the subpage won't be detached
  		 * in the meantime.
  		 */
- 		spin_lock(&page->mapping->private_lock);
+ 		spin_lock(&page->mapping->i_private_lock);
 -		if (!PagePrivate(page)) {
 +		if (!folio_test_private(folio)) {
- 			spin_unlock(&page->mapping->private_lock);
+ 			spin_unlock(&page->mapping->i_private_lock);
  			break;
  		}
  		spin_lock_irqsave(&subpage->lock, flags);
@@@ -1826,9 -1811,9 +1826,9 @@@ static int submit_eb_page(struct page *
  	if (btrfs_sb(page->mapping->host->i_sb)->nodesize < PAGE_SIZE)
  		return submit_eb_subpage(page, wbc);
  
- 	spin_lock(&mapping->private_lock);
+ 	spin_lock(&mapping->i_private_lock);
 -	if (!PagePrivate(page)) {
 +	if (!folio_test_private(folio)) {
- 		spin_unlock(&mapping->private_lock);
+ 		spin_unlock(&mapping->i_private_lock);
  		return 0;
  	}
  
@@@ -3070,13 -3054,12 +3070,13 @@@ static int extent_buffer_under_io(cons
  
  static bool page_range_has_eb(struct btrfs_fs_info *fs_info, struct page *page)
  {
 +	struct folio *folio = page_folio(page);
  	struct btrfs_subpage *subpage;
  
- 	lockdep_assert_held(&page->mapping->private_lock);
+ 	lockdep_assert_held(&page->mapping->i_private_lock);
  
 -	if (PagePrivate(page)) {
 -		subpage = (struct btrfs_subpage *)page->private;
 +	if (folio_test_private(folio)) {
 +		subpage = folio_get_private(folio);
  		if (atomic_read(&subpage->eb_refs))
  			return true;
  		/*
@@@ -3093,18 -3076,17 +3093,18 @@@ static void detach_extent_buffer_page(s
  {
  	struct btrfs_fs_info *fs_info = eb->fs_info;
  	const bool mapped = !test_bit(EXTENT_BUFFER_UNMAPPED, &eb->bflags);
 +	struct folio *folio = page_folio(page);
  
  	/*
 -	 * For mapped eb, we're going to change the page private, which should
 +	 * For mapped eb, we're going to change the folio private, which should
- 	 * be done under the private_lock.
+ 	 * be done under the i_private_lock.
  	 */
  	if (mapped)
- 		spin_lock(&page->mapping->private_lock);
+ 		spin_lock(&page->mapping->i_private_lock);
  
 -	if (!PagePrivate(page)) {
 +	if (!folio_test_private(folio)) {
  		if (mapped)
- 			spin_unlock(&page->mapping->private_lock);
+ 			spin_unlock(&page->mapping->i_private_lock);
  		return;
  	}
  
@@@ -3120,11 -3103,14 +3120,11 @@@
  			BUG_ON(test_bit(EXTENT_BUFFER_DIRTY, &eb->bflags));
  			BUG_ON(PageDirty(page));
  			BUG_ON(PageWriteback(page));
 -			/*
 -			 * We need to make sure we haven't be attached
 -			 * to a new eb.
 -			 */
 -			detach_page_private(page);
 +			/* We need to make sure we haven't be attached to a new eb. */
 +			folio_detach_private(folio);
  		}
  		if (mapped)
- 			spin_unlock(&page->mapping->private_lock);
+ 			spin_unlock(&page->mapping->i_private_lock);
  		return;
  	}
  
@@@ -3588,8 -3513,8 +3588,8 @@@ struct extent_buffer *alloc_extent_buff
  	num_pages = num_extent_pages(eb);
  
  	/*
 -	 * Preallocate page->private for subpage case, so that we won't
 +	 * Preallocate folio private for subpage case, so that we won't
- 	 * allocate memory with private_lock nor page lock hold.
+ 	 * allocate memory with i_private_lock nor page lock hold.
  	 *
  	 * The memory will be freed by attach_extent_buffer_page() or freed
  	 * manually if we exit earlier.
@@@ -3602,31 -3527,24 +3602,31 @@@
  		}
  	}
  
 -	for (i = 0; i < num_pages; i++, index++) {
 -		p = find_or_create_page(mapping, index, GFP_NOFS|__GFP_NOFAIL);
 -		if (!p) {
 -			exists = ERR_PTR(-ENOMEM);
 -			btrfs_free_subpage(prealloc);
 -			goto free_eb;
 -		}
 +	/* Allocate all pages first. */
 +	ret = btrfs_alloc_page_array(num_pages, eb->pages, __GFP_NOFAIL);
 +	if (ret < 0) {
 +		btrfs_free_subpage(prealloc);
 +		goto out;
 +	}
  
 -		spin_lock(&mapping->i_private_lock);
 -		exists = grab_extent_buffer(fs_info, p);
 -		if (exists) {
 -			spin_unlock(&mapping->i_private_lock);
 -			unlock_page(p);
 -			put_page(p);
 -			mark_extent_buffer_accessed(exists, p);
 -			btrfs_free_subpage(prealloc);
 -			goto free_eb;
 +	/* Attach all pages to the filemap. */
 +	for (int i = 0; i < num_pages; i++) {
 +		struct page *p;
 +
 +		ret = attach_eb_page_to_filemap(eb, i, &existing_eb);
 +		if (ret > 0) {
 +			ASSERT(existing_eb);
 +			goto out;
  		}
 +		attached++;
 +
 +		/*
 +		 * Only after attach_eb_page_to_filemap(), eb->pages[] is
 +		 * reliable, as we may choose to reuse the existing page cache
 +		 * and free the allocated page.
 +		 */
 +		p = eb->pages[i];
- 		spin_lock(&mapping->private_lock);
++		spin_lock(&mapping->i_private_lock);
  		/* Should not fail, as we have preallocated the memory */
  		ret = attach_extent_buffer_page(eb, p, prealloc);
  		ASSERT(!ret);
@@@ -3640,17 -3558,10 +3640,17 @@@
  		 * Thus needs no special handling in error path.
  		 */
  		btrfs_page_inc_eb_refs(fs_info, p);
- 		spin_unlock(&mapping->private_lock);
+ 		spin_unlock(&mapping->i_private_lock);
  
  		WARN_ON(btrfs_page_test_dirty(fs_info, p, eb->start, eb->len));
 -		eb->pages[i] = p;
 +
 +		/*
 +		 * Check if the current page is physically contiguous with previous eb
 +		 * page.
 +		 */
 +		if (i && eb->pages[i - 1] + 1 != p)
 +			page_contig = false;
 +
  		if (!btrfs_page_test_uptodate(fs_info, p, eb->start, eb->len))
  			uptodate = 0;
  
@@@ -4713,11 -4560,11 +4713,11 @@@ static int try_release_subpage_extent_b
  		release_extent_buffer(eb);
  	}
  	/*
 -	 * Finally to check if we have cleared page private, as if we have
 -	 * released all ebs in the page, the page private should be cleared now.
 +	 * Finally to check if we have cleared folio private, as if we have
 +	 * released all ebs in the page, the folio private should be cleared now.
  	 */
- 	spin_lock(&page->mapping->private_lock);
+ 	spin_lock(&page->mapping->i_private_lock);
 -	if (!PagePrivate(page))
 +	if (!folio_test_private(page_folio(page)))
  		ret = 1;
  	else
  		ret = 0;
@@@ -4735,12 -4581,12 +4735,12 @@@ int try_release_extent_buffer(struct pa
  		return try_release_subpage_extent_buffer(page);
  
  	/*
 -	 * We need to make sure nobody is changing page->private, as we rely on
 -	 * page->private as the pointer to extent buffer.
 +	 * We need to make sure nobody is changing folio private, as we rely on
 +	 * folio private as the pointer to extent buffer.
  	 */
- 	spin_lock(&page->mapping->private_lock);
+ 	spin_lock(&page->mapping->i_private_lock);
 -	if (!PagePrivate(page)) {
 +	if (!folio_test_private(folio)) {
- 		spin_unlock(&page->mapping->private_lock);
+ 		spin_unlock(&page->mapping->i_private_lock);
  		return 1;
  	}
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]

Hi all,

On Wed, 29 Nov 2023 12:09:30 +0100 Jan Kara <jack@suse.cz> wrote:
>
> On Tue 28-11-23 14:33:44, Nathan Chancellor wrote:
> > Hi Stephen (and other maintainers),
> > 
> > On Mon, Nov 27, 2023 at 09:20:01AM +1100, Stephen Rothwell wrote:  
> > > Hi all,
> > > 
> > > Today's linux-next merge of the vfs-brauner tree got a conflict in:
> > > 
> > >   fs/btrfs/super.c
> > > 
> > > between commit:
> > > 
> > >   2f2cfead5107 ("btrfs: remove old mount API code")
> > > 
> > > from the btrfs tree and commit:
> > > 
> > >   ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
> > > 
> > > from the vfs-brauner tree.
> > > 
> > > I fixed it up (the former removed the funtion updated by the latter, but
> > > a further fix may be required to implement the intent of the latter?)  
> > 
> > Yes, the lack of ead622674df5 appears to cause issues with mounting
> > btrfs volumes on at least next-20231128 due to the presence of commit
> > 6f861765464f ("fs: Block writes to mounted block devices"). In QEMU, I
> > can see:
> > 
> >   :: running early hook [udev]
> >   Warning: /lib/modules/6.7.0-rc3-next-20231128/modules.devname not found - ignoring
> >   Starting systemd-udevd version 252.5-1-arch
> >   :: running hook [udev]
> >   :: Triggering uevents...
> >   :: running hook [keymap]
> >   :: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
> >   done.
> >   :: performing fsck on '/dev/vda2'
> >   :: mounting '/dev/vda2' on real root
> >   mount: /new_root: wrong fs type, bad option, bad superblock on /dev/vda2, missing codepage or helper program, or other error.
> >          dmesg(1) may have more information after failed mount system call.
> >   You are now being dropped into an emergency shell.
> >   sh: can't access tty; job control turned off
> >   [rootfs ]#
> > 
> > The following diff allows my VM to boot properly but I am not sure if
> > there is a better or more proper fix (I am already out of my element
> > heh). If a proper merge solution cannot be found quickly, can
> > 6f861765464f be reverted in the meantime so that all my machines with
> > btrfs can boot properly? :)
> > 
> > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> > index 99d10a25a579..23db0306b8ef 100644
> > --- a/fs/btrfs/super.c
> > +++ b/fs/btrfs/super.c
> > @@ -299,6 +299,7 @@ static int btrfs_parse_param(struct fs_context *fc,
> >  	case Opt_device: {
> >  		struct btrfs_device *device;
> >  		blk_mode_t mode = sb_open_mode(fc->sb_flags);
> > +		mode &= ~BLK_OPEN_RESTRICT_WRITES;
> >  
> >  		mutex_lock(&uuid_mutex);
> >  		device = btrfs_scan_one_device(param->string, mode, false);
> > @@ -1801,6 +1802,8 @@ static int btrfs_get_tree_super(struct fs_context *fc)
> >  	blk_mode_t mode = sb_open_mode(fc->sb_flags);
> >  	int ret;
> >  
> > +	mode &= ~BLK_OPEN_RESTRICT_WRITES;
> > +
> >  	btrfs_ctx_to_info(fs_info, ctx);
> >  	mutex_lock(&uuid_mutex);  
> 
> This looks like the proper resolution. Basically btrfs needs to strip
> BLK_OPEN_RESTRICT_WRITES from the mode provided by sb_open_mode(). Thanks
> for writing it!

I have added this patch as a merge fix from today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Jan Kara]

On Tue 28-11-23 14:33:44, Nathan Chancellor wrote:
> Hi Stephen (and other maintainers),
> 
> On Mon, Nov 27, 2023 at 09:20:01AM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the vfs-brauner tree got a conflict in:
> > 
> >   fs/btrfs/super.c
> > 
> > between commit:
> > 
> >   2f2cfead5107 ("btrfs: remove old mount API code")
> > 
> > from the btrfs tree and commit:
> > 
> >   ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
> > 
> > from the vfs-brauner tree.
> > 
> > I fixed it up (the former removed the funtion updated by the latter, but
> > a further fix may be required to implement the intent of the latter?)
> 
> Yes, the lack of ead622674df5 appears to cause issues with mounting
> btrfs volumes on at least next-20231128 due to the presence of commit
> 6f861765464f ("fs: Block writes to mounted block devices"). In QEMU, I
> can see:
> 
>   :: running early hook [udev]
>   Warning: /lib/modules/6.7.0-rc3-next-20231128/modules.devname not found - ignoring
>   Starting systemd-udevd version 252.5-1-arch
>   :: running hook [udev]
>   :: Triggering uevents...
>   :: running hook [keymap]
>   :: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
>   done.
>   :: performing fsck on '/dev/vda2'
>   :: mounting '/dev/vda2' on real root
>   mount: /new_root: wrong fs type, bad option, bad superblock on /dev/vda2, missing codepage or helper program, or other error.
>          dmesg(1) may have more information after failed mount system call.
>   You are now being dropped into an emergency shell.
>   sh: can't access tty; job control turned off
>   [rootfs ]#
> 
> The following diff allows my VM to boot properly but I am not sure if
> there is a better or more proper fix (I am already out of my element
> heh). If a proper merge solution cannot be found quickly, can
> 6f861765464f be reverted in the meantime so that all my machines with
> btrfs can boot properly? :)
> 
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 99d10a25a579..23db0306b8ef 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -299,6 +299,7 @@ static int btrfs_parse_param(struct fs_context *fc,
>  	case Opt_device: {
>  		struct btrfs_device *device;
>  		blk_mode_t mode = sb_open_mode(fc->sb_flags);
> +		mode &= ~BLK_OPEN_RESTRICT_WRITES;
>  
>  		mutex_lock(&uuid_mutex);
>  		device = btrfs_scan_one_device(param->string, mode, false);
> @@ -1801,6 +1802,8 @@ static int btrfs_get_tree_super(struct fs_context *fc)
>  	blk_mode_t mode = sb_open_mode(fc->sb_flags);
>  	int ret;
>  
> +	mode &= ~BLK_OPEN_RESTRICT_WRITES;
> +
>  	btrfs_ctx_to_info(fs_info, ctx);
>  	mutex_lock(&uuid_mutex);

This looks like the proper resolution. Basically btrfs needs to strip
BLK_OPEN_RESTRICT_WRITES from the mode provided by sb_open_mode(). Thanks
for writing it!

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Nathan Chancellor]

Hi Stephen (and other maintainers),

On Mon, Nov 27, 2023 at 09:20:01AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/btrfs/super.c
> 
> between commit:
> 
>   2f2cfead5107 ("btrfs: remove old mount API code")
> 
> from the btrfs tree and commit:
> 
>   ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")
> 
> from the vfs-brauner tree.
> 
> I fixed it up (the former removed the funtion updated by the latter, but
> a further fix may be required to implement the intent of the latter?)

Yes, the lack of ead622674df5 appears to cause issues with mounting
btrfs volumes on at least next-20231128 due to the presence of commit
6f861765464f ("fs: Block writes to mounted block devices"). In QEMU, I
can see:

  :: running early hook [udev]
  Warning: /lib/modules/6.7.0-rc3-next-20231128/modules.devname not found - ignoring
  Starting systemd-udevd version 252.5-1-arch
  :: running hook [udev]
  :: Triggering uevents...
  :: running hook [keymap]
  :: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
  done.
  :: performing fsck on '/dev/vda2'
  :: mounting '/dev/vda2' on real root
  mount: /new_root: wrong fs type, bad option, bad superblock on /dev/vda2, missing codepage or helper program, or other error.
         dmesg(1) may have more information after failed mount system call.
  You are now being dropped into an emergency shell.
  sh: can't access tty; job control turned off
  [rootfs ]#

The following diff allows my VM to boot properly but I am not sure if
there is a better or more proper fix (I am already out of my element
heh). If a proper merge solution cannot be found quickly, can
6f861765464f be reverted in the meantime so that all my machines with
btrfs can boot properly? :)

Cheers,
Nathan

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 99d10a25a579..23db0306b8ef 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -299,6 +299,7 @@ static int btrfs_parse_param(struct fs_context *fc,
 	case Opt_device: {
 		struct btrfs_device *device;
 		blk_mode_t mode = sb_open_mode(fc->sb_flags);
+		mode &= ~BLK_OPEN_RESTRICT_WRITES;
 
 		mutex_lock(&uuid_mutex);
 		device = btrfs_scan_one_device(param->string, mode, false);
@@ -1801,6 +1802,8 @@ static int btrfs_get_tree_super(struct fs_context *fc)
 	blk_mode_t mode = sb_open_mode(fc->sb_flags);
 	int ret;
 
+	mode &= ~BLK_OPEN_RESTRICT_WRITES;
+
 	btrfs_ctx_to_info(fs_info, ctx);
 	mutex_lock(&uuid_mutex);
 

linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/btrfs/super.c

between commit:

  2f2cfead5107 ("btrfs: remove old mount API code")

from the btrfs tree and commit:

  ead622674df5 ("btrfs: Do not restrict writes to btrfs devices")

from the vfs-brauner tree.

I fixed it up (the former removed the funtion updated by the latter, but
a further fix may be required to implement the intent of the latter?) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 7344 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got conflicts in:

  fs/btrfs/extent_io.c
  fs/btrfs/subpage.c

between commit:

  16aee93de711 ("btrfs: migrate to use folio private instead of page private")

from the btrfs tree and commit:

  600f111ef51d ("fs: Rename mapping private members")

from the vfs-brauner tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/extent_io.c
index 40cf80af88b1,3431a53bf3fd..000000000000
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@@ -878,13 -870,13 +878,13 @@@ static int attach_extent_buffer_page(st
  	 * will not race with any other ebs.
  	 */
  	if (page->mapping)
- 		lockdep_assert_held(&page->mapping->private_lock);
+ 		lockdep_assert_held(&page->mapping->i_private_lock);
  
  	if (fs_info->nodesize >= PAGE_SIZE) {
 -		if (!PagePrivate(page))
 -			attach_page_private(page, eb);
 +		if (!folio_test_private(folio))
 +			folio_attach_private(folio, eb);
  		else
 -			WARN_ON(page->private != (unsigned long)eb);
 +			WARN_ON(folio_get_private(folio) != eb);
  		return 0;
  	}
  
@@@ -1748,9 -1736,9 +1748,9 @@@ static int submit_eb_subpage(struct pag
  		 * Take private lock to ensure the subpage won't be detached
  		 * in the meantime.
  		 */
- 		spin_lock(&page->mapping->private_lock);
+ 		spin_lock(&page->mapping->i_private_lock);
 -		if (!PagePrivate(page)) {
 +		if (!folio_test_private(folio)) {
- 			spin_unlock(&page->mapping->private_lock);
+ 			spin_unlock(&page->mapping->i_private_lock);
  			break;
  		}
  		spin_lock_irqsave(&subpage->lock, flags);
@@@ -1824,9 -1811,9 +1824,9 @@@ static int submit_eb_page(struct page *
  	if (btrfs_sb(page->mapping->host->i_sb)->nodesize < PAGE_SIZE)
  		return submit_eb_subpage(page, wbc);
  
- 	spin_lock(&mapping->private_lock);
+ 	spin_lock(&mapping->i_private_lock);
 -	if (!PagePrivate(page)) {
 +	if (!folio_test_private(folio)) {
- 		spin_unlock(&mapping->private_lock);
+ 		spin_unlock(&mapping->i_private_lock);
  		return 0;
  	}
  
@@@ -3067,13 -3054,12 +3067,13 @@@ static int extent_buffer_under_io(cons
  
  static bool page_range_has_eb(struct btrfs_fs_info *fs_info, struct page *page)
  {
 +	struct folio *folio = page_folio(page);
  	struct btrfs_subpage *subpage;
  
- 	lockdep_assert_held(&page->mapping->private_lock);
+ 	lockdep_assert_held(&page->mapping->i_private_lock);
  
 -	if (PagePrivate(page)) {
 -		subpage = (struct btrfs_subpage *)page->private;
 +	if (folio_test_private(folio)) {
 +		subpage = folio_get_private(folio);
  		if (atomic_read(&subpage->eb_refs))
  			return true;
  		/*
@@@ -3090,18 -3076,17 +3090,18 @@@ static void detach_extent_buffer_page(s
  {
  	struct btrfs_fs_info *fs_info = eb->fs_info;
  	const bool mapped = !test_bit(EXTENT_BUFFER_UNMAPPED, &eb->bflags);
 +	struct folio *folio = page_folio(page);
  
  	/*
 -	 * For mapped eb, we're going to change the page private, which should
 +	 * For mapped eb, we're going to change the folio private, which should
- 	 * be done under the private_lock.
+ 	 * be done under the i_private_lock.
  	 */
  	if (mapped)
- 		spin_lock(&page->mapping->private_lock);
+ 		spin_lock(&page->mapping->i_private_lock);
  
 -	if (!PagePrivate(page)) {
 +	if (!folio_test_private(folio)) {
  		if (mapped)
- 			spin_unlock(&page->mapping->private_lock);
+ 			spin_unlock(&page->mapping->i_private_lock);
  		return;
  	}
  
@@@ -3117,11 -3103,14 +3117,11 @@@
  			BUG_ON(test_bit(EXTENT_BUFFER_DIRTY, &eb->bflags));
  			BUG_ON(PageDirty(page));
  			BUG_ON(PageWriteback(page));
 -			/*
 -			 * We need to make sure we haven't be attached
 -			 * to a new eb.
 -			 */
 -			detach_page_private(page);
 +			/* We need to make sure we haven't be attached to a new eb. */
 +			folio_detach_private(folio);
  		}
  		if (mapped)
- 			spin_unlock(&page->mapping->private_lock);
+ 			spin_unlock(&page->mapping->i_private_lock);
  		return;
  	}
  
@@@ -3526,8 -3513,8 +3526,8 @@@ struct extent_buffer *alloc_extent_buff
  	num_pages = num_extent_pages(eb);
  
  	/*
 -	 * Preallocate page->private for subpage case, so that we won't
 +	 * Preallocate folio private for subpage case, so that we won't
- 	 * allocate memory with private_lock nor page lock hold.
+ 	 * allocate memory with i_private_lock nor page lock hold.
  	 *
  	 * The memory will be freed by attach_extent_buffer_page() or freed
  	 * manually if we exit earlier.
@@@ -4638,11 -4560,11 +4638,11 @@@ static int try_release_subpage_extent_b
  		release_extent_buffer(eb);
  	}
  	/*
 -	 * Finally to check if we have cleared page private, as if we have
 -	 * released all ebs in the page, the page private should be cleared now.
 +	 * Finally to check if we have cleared folio private, as if we have
 +	 * released all ebs in the page, the folio private should be cleared now.
  	 */
- 	spin_lock(&page->mapping->private_lock);
+ 	spin_lock(&page->mapping->i_private_lock);
 -	if (!PagePrivate(page))
 +	if (!folio_test_private(page_folio(page)))
  		ret = 1;
  	else
  		ret = 0;
@@@ -4660,12 -4581,12 +4660,12 @@@ int try_release_extent_buffer(struct pa
  		return try_release_subpage_extent_buffer(page);
  
  	/*
 -	 * We need to make sure nobody is changing page->private, as we rely on
 -	 * page->private as the pointer to extent buffer.
 +	 * We need to make sure nobody is changing folio private, as we rely on
 +	 * folio private as the pointer to extent buffer.
  	 */
- 	spin_lock(&page->mapping->private_lock);
+ 	spin_lock(&page->mapping->i_private_lock);
 -	if (!PagePrivate(page)) {
 +	if (!folio_test_private(folio)) {
- 		spin_unlock(&page->mapping->private_lock);
+ 		spin_unlock(&page->mapping->i_private_lock);
  		return 1;
  	}
  
diff --cc fs/btrfs/subpage.c
index caf0013f2545,2347cf15278b..000000000000
--- a/fs/btrfs/subpage.c
+++ b/fs/btrfs/subpage.c
@@@ -202,10 -199,10 +202,10 @@@ void btrfs_page_inc_eb_refs(const struc
  	if (!btrfs_is_subpage(fs_info, page))
  		return;
  
 -	ASSERT(PagePrivate(page) && page->mapping);
 +	ASSERT(folio_test_private(folio) && page->mapping);
- 	lockdep_assert_held(&page->mapping->private_lock);
+ 	lockdep_assert_held(&page->mapping->i_private_lock);
  
 -	subpage = (struct btrfs_subpage *)page->private;
 +	subpage = folio_get_private(folio);
  	atomic_inc(&subpage->eb_refs);
  }
  
@@@ -218,10 -214,10 +218,10 @@@ void btrfs_page_dec_eb_refs(const struc
  	if (!btrfs_is_subpage(fs_info, page))
  		return;
  
 -	ASSERT(PagePrivate(page) && page->mapping);
 +	ASSERT(folio_test_private(folio) && page->mapping);
- 	lockdep_assert_held(&page->mapping->private_lock);
+ 	lockdep_assert_held(&page->mapping->i_private_lock);
  
 -	subpage = (struct btrfs_subpage *)page->private;
 +	subpage = folio_get_private(folio);
  	ASSERT(atomic_read(&subpage->eb_refs));
  	atomic_dec(&subpage->eb_refs);
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the vfs-brauner tree with the btrfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/btrfs/inode.c

between commit:

  ea6aa58a9229 ("btrfs: copy dir permission and time when creating a stub subvolume")

from the btrfs tree and commit:

  2a9462de4352 ("btrfs: convert to ctime accessor functions")

from the vfs-brauner tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/inode.c
index 06c9ad527458,db7e1a19bb67..000000000000
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@@ -5558,12 -5757,9 +5555,11 @@@ static struct inode *new_simple_dir(str
  	inode->i_opflags &= ~IOP_XATTR;
  	inode->i_fop = &simple_dir_operations;
  	inode->i_mode = S_IFDIR | S_IRUGO | S_IWUSR | S_IXUGO;
- 	inode->i_mtime = current_time(inode);
+ 	inode->i_mtime = inode_set_ctime_current(inode);
 -	inode->i_atime = inode->i_mtime;
 +	inode->i_atime = dir->i_atime;
- 	inode->i_ctime = dir->i_ctime;
  	BTRFS_I(inode)->i_otime = inode->i_mtime;
 +	inode->i_uid = dir->i_uid;
 +	inode->i_gid = dir->i_gid;
  
  	return inode;
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]