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

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

[Stephen Rothwell]

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

Hi all,

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

  block/blk.h

between commits:

  19db932fd2b0 ("bdev: make bdev_{release, open_by_dev}() private to block layer")
  09f8289e1b74 ("bdev: make struct bdev_handle private to the block layer")
  d75140abba91 ("bdev: remove bdev pointer from struct bdev_handle")

from the vfs-brauner tree and commits:

  c4e47bbb00da ("block: move cgroup time handling code into blk.h")
  08420cf70cfb ("block: add blk_time_get_ns() and blk_time_get() helpers")
  da4c8c3d0975 ("block: cache current nsec time in struct blk_plug")
  06b23f92af87 ("block: update cached timestamp post schedule/preemption")

from the block 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 block/blk.h
index f02b25f22e8b,913c93838a01..000000000000
--- a/block/blk.h
+++ b/block/blk.h
@@@ -516,8 -517,70 +517,75 @@@ static inline int req_ref_read(struct r
  	return atomic_read(&req->ref);
  }
  
 +void bdev_release(struct file *bdev_file);
 +int bdev_open(struct block_device *bdev, blk_mode_t mode, void *holder,
 +	      const struct blk_holder_ops *hops, struct file *bdev_file);
 +int bdev_permission(dev_t dev, blk_mode_t mode, void *holder);
++
+ static inline u64 blk_time_get_ns(void)
+ {
+ 	struct blk_plug *plug = current->plug;
+ 
+ 	if (!plug)
+ 		return ktime_get_ns();
+ 
+ 	/*
+ 	 * 0 could very well be a valid time, but rather than flag "this is
+ 	 * a valid timestamp" separately, just accept that we'll do an extra
+ 	 * ktime_get_ns() if we just happen to get 0 as the current time.
+ 	 */
+ 	if (!plug->cur_ktime) {
+ 		plug->cur_ktime = ktime_get_ns();
+ 		current->flags |= PF_BLOCK_TS;
+ 	}
+ 	return plug->cur_ktime;
+ }
+ 
+ static inline ktime_t blk_time_get(void)
+ {
+ 	return ns_to_ktime(blk_time_get_ns());
+ }
+ 
+ /*
+  * From most significant bit:
+  * 1 bit: reserved for other usage, see below
+  * 12 bits: original size of bio
+  * 51 bits: issue time of bio
+  */
+ #define BIO_ISSUE_RES_BITS      1
+ #define BIO_ISSUE_SIZE_BITS     12
+ #define BIO_ISSUE_RES_SHIFT     (64 - BIO_ISSUE_RES_BITS)
+ #define BIO_ISSUE_SIZE_SHIFT    (BIO_ISSUE_RES_SHIFT - BIO_ISSUE_SIZE_BITS)
+ #define BIO_ISSUE_TIME_MASK     ((1ULL << BIO_ISSUE_SIZE_SHIFT) - 1)
+ #define BIO_ISSUE_SIZE_MASK     \
+ 	(((1ULL << BIO_ISSUE_SIZE_BITS) - 1) << BIO_ISSUE_SIZE_SHIFT)
+ #define BIO_ISSUE_RES_MASK      (~((1ULL << BIO_ISSUE_RES_SHIFT) - 1))
+ 
+ /* Reserved bit for blk-throtl */
+ #define BIO_ISSUE_THROTL_SKIP_LATENCY (1ULL << 63)
+ 
+ static inline u64 __bio_issue_time(u64 time)
+ {
+ 	return time & BIO_ISSUE_TIME_MASK;
+ }
+ 
+ static inline u64 bio_issue_time(struct bio_issue *issue)
+ {
+ 	return __bio_issue_time(issue->value);
+ }
+ 
+ static inline sector_t bio_issue_size(struct bio_issue *issue)
+ {
+ 	return ((issue->value & BIO_ISSUE_SIZE_MASK) >> BIO_ISSUE_SIZE_SHIFT);
+ }
+ 
+ static inline void bio_issue_init(struct bio_issue *issue,
+ 				       sector_t size)
+ {
+ 	size &= (1ULL << BIO_ISSUE_SIZE_BITS) - 1;
+ 	issue->value = ((issue->value & BIO_ISSUE_RES_MASK) |
+ 			(blk_time_get_ns() & BIO_ISSUE_TIME_MASK) |
+ 			((u64)size << BIO_ISSUE_SIZE_SHIFT));
+ }
+ 
  #endif /* BLK_INTERNAL_H */

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

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

[Jens Axboe]

On 2/5/24 6:48 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   block/blk.h
> 
> between commits:
> 
>   19db932fd2b0 ("bdev: make bdev_{release, open_by_dev}() private to block layer")
>   09f8289e1b74 ("bdev: make struct bdev_handle private to the block layer")
>   d75140abba91 ("bdev: remove bdev pointer from struct bdev_handle")
> 
> from the vfs-brauner tree and commits:
> 
>   c4e47bbb00da ("block: move cgroup time handling code into blk.h")
>   08420cf70cfb ("block: add blk_time_get_ns() and blk_time_get() helpers")
>   da4c8c3d0975 ("block: cache current nsec time in struct blk_plug")
>   06b23f92af87 ("block: update cached timestamp post schedule/preemption")
> 
> from the block 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.

That's a lot of conflicts. Christian, we really should separate some of
these so we can have the shared bits in a shared branch.

-- 
Jens Axboe

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

[Christian Brauner]

On Tue, Feb 06, 2024 at 09:37:33AM -0700, Jens Axboe wrote:
> On 2/5/24 6:48 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the block tree got a conflict in:
> > 
> >   block/blk.h
> > 
> > between commits:
> > 
> >   19db932fd2b0 ("bdev: make bdev_{release, open_by_dev}() private to block layer")
> >   09f8289e1b74 ("bdev: make struct bdev_handle private to the block layer")
> >   d75140abba91 ("bdev: remove bdev pointer from struct bdev_handle")
> > 
> > from the vfs-brauner tree and commits:
> > 
> >   c4e47bbb00da ("block: move cgroup time handling code into blk.h")
> >   08420cf70cfb ("block: add blk_time_get_ns() and blk_time_get() helpers")
> >   da4c8c3d0975 ("block: cache current nsec time in struct blk_plug")
> >   06b23f92af87 ("block: update cached timestamp post schedule/preemption")
> > 
> > from the block 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.
> 
> That's a lot of conflicts. Christian, we really should separate some of
> these so we can have the shared bits in a shared branch.

Yes, happy to do that. Let's quickly sync later today when you're up?

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

[Stephen Rothwell]

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

Hi all,

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

  io_uring/rw.c

between commit:

  80a07849c0b8 ("fs: claw back a few FMODE_* bits")

from the vfs-brauner tree and commit:

  40ffda3dc1a1 ("io_uring/rw: always setup io_async_rw for read/write requests")

from the block 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 io_uring/rw.c
index d9dfde1142a1,3134a6ece1be..000000000000
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@@ -1021,13 -1003,13 +1004,13 @@@ int io_write(struct io_kiocb *req, unsi
  	if (force_nonblock) {
  		/* If the file doesn't support async, just async punt */
  		if (unlikely(!io_file_supports_nowait(req)))
- 			goto copy_iov;
+ 			goto ret_eagain;
  
 -		/* File path supports NOWAIT for non-direct_IO only for block devices. */
 +		/* Check if we can support NOWAIT. */
  		if (!(kiocb->ki_flags & IOCB_DIRECT) &&
 -			!(kiocb->ki_filp->f_mode & FMODE_BUF_WASYNC) &&
 -			(req->flags & REQ_F_ISREG))
 +		    !(req->file->f_op->fop_flags & FOP_BUFFER_WASYNC) &&
 +		    (req->flags & REQ_F_ISREG))
- 			goto copy_iov;
+ 			goto ret_eagain;
  
  		kiocb->ki_flags |= IOCB_NOWAIT;
  	} else {

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

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

[Stephen Rothwell]

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

Hi all,

FIXME: Add owner of second tree to To:
       Add author(s)/SOB of conflicting commits.

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

  block/ioctl.c

between commit:

  695eaf683e8e ("blk_ioctl_{discard,zeroout}(): we only want ->bd_inode->i_mapping here...")

from the vfs-brauner tree and commits:

  719c15a75ebf ("blk-lib: check for kill signal in ioctl BLKDISCARD")
  fb4271f2bfac ("Merge branch 'for-6.10/block' into for-next")

from the block 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 block/ioctl.c
index 3b31c09941dc,c0f1b6583a9a..000000000000
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@@ -95,8 -95,13 +95,12 @@@ static int compat_blkpg_ioctl(struct bl
  static int blk_ioctl_discard(struct block_device *bdev, blk_mode_t mode,
  		unsigned long arg)
  {
+ 	unsigned int bs_mask = bdev_logical_block_size(bdev) - 1;
  	uint64_t range[2];
  	uint64_t start, len, end;
 -	struct inode *inode = bdev->bd_inode;
+ 	struct bio *prev = NULL, *bio;
+ 	sector_t sector, nr_sects;
+ 	struct blk_plug plug;
  	int err;
  
  	if (!(mode & BLK_OPEN_WRITE))
@@@ -124,9 -131,34 +130,34 @@@
  	err = truncate_bdev_range(bdev, mode, start, start + len - 1);
  	if (err)
  		goto fail;
- 	err = blkdev_issue_discard(bdev, start >> 9, len >> 9, GFP_KERNEL);
+ 
+ 	sector = start >> SECTOR_SHIFT;
+ 	nr_sects = len >> SECTOR_SHIFT;
+ 
+ 	blk_start_plug(&plug);
+ 	while (1) {
+ 		if (fatal_signal_pending(current)) {
+ 			if (prev)
+ 				bio_await_chain(prev);
+ 			err = -EINTR;
+ 			goto out_unplug;
+ 		}
+ 		bio = blk_alloc_discard_bio(bdev, &sector, &nr_sects,
+ 				GFP_KERNEL);
+ 		if (!bio)
+ 			break;
+ 		prev = bio_chain_and_submit(prev, bio);
+ 	}
+ 	if (prev) {
+ 		err = submit_bio_wait(prev);
+ 		if (err == -EOPNOTSUPP)
+ 			err = 0;
+ 		bio_put(prev);
+ 	}
+ out_unplug:
+ 	blk_finish_plug(&plug);
  fail:
 -	filemap_invalidate_unlock(inode->i_mapping);
 +	filemap_invalidate_unlock(bdev->bd_mapping);
  	return err;
  }
  

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

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

[Christoph Hellwig]

Thanks Stephen,

the merge looks good to me.

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

[Mark Brown]

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

Hi all,

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

  fs/stat.c

between commit:

  0ef625bba6fb2 ("vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)")

from the vfs-brauner tree and commit:

  0f9ca80fa4f96 ("fs: Add initial atomic write support info to statx")
  9abcfbd235f59 ("block: Add atomic write support for statx")

from the block 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.

diff --cc fs/stat.c
index 6f65b3456cadb,bd0698dfd7b36..0000000000000
--- a/fs/stat.c
+++ b/fs/stat.c
@@@ -214,43 -245,6 +245,45 @@@ int getname_statx_lookup_flags(int flag
  	return lookup_flags;
  }
  
 +static int vfs_statx_path(struct path *path, int flags, struct kstat *stat,
 +			  u32 request_mask)
 +{
 +	int error = vfs_getattr(path, stat, request_mask, flags);
++	struct inode *backing_inode;
 +
 +	if (request_mask & STATX_MNT_ID_UNIQUE) {
 +		stat->mnt_id = real_mount(path->mnt)->mnt_id_unique;
 +		stat->result_mask |= STATX_MNT_ID_UNIQUE;
 +	} else {
 +		stat->mnt_id = real_mount(path->mnt)->mnt_id;
 +		stat->result_mask |= STATX_MNT_ID;
 +	}
 +
 +	if (path_mounted(path))
 +		stat->attributes |= STATX_ATTR_MOUNT_ROOT;
 +	stat->attributes_mask |= STATX_ATTR_MOUNT_ROOT;
 +
- 	/* Handle STATX_DIOALIGN for block devices. */
- 	if (request_mask & STATX_DIOALIGN) {
- 		struct inode *inode = d_backing_inode(path->dentry);
- 
- 		if (S_ISBLK(inode->i_mode))
- 			bdev_statx_dioalign(inode, stat);
- 	}
++	/*
++	 * If this is a block device inode, override the filesystem
++	 * attributes with the block device specific parameters that need to be
++	 * obtained from the bdev backing inode.
++	 */
++	backing_inode = d_backing_inode(path->dentry);
++	if (S_ISBLK(backing_inode->i_mode))
++		bdev_statx(backing_inode, stat, request_mask);
 +
 +	return error;
 +}
 +
 +static int vfs_statx_fd(int fd, int flags, struct kstat *stat,
 +			  u32 request_mask)
 +{
 +	CLASS(fd_raw, f)(fd);
 +	if (!f.file)
 +		return -EBADF;
 +	return vfs_statx_path(&f.file->f_path, flags, stat, request_mask);
 +}
 +
  /**
   * vfs_statx - Get basic and extra attributes by filename
   * @dfd: A file descriptor representing the base dir for a relative filename

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

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

[Mark Brown]

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

Hi all,

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

  include/linux/fs.h

between commit:

  1bc6d4452d5c9 ("fs: new helper vfs_empty_path()")

from the vfs-brauner tree and commit:

  c34fc6f26ab86 ("fs: Initial atomic write support")

from the block 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.

diff --cc include/linux/fs.h
index dc9f9c4b2572d,db26b4a70c628..0000000000000
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@@ -3626,21 -3627,6 +3640,23 @@@ extern int vfs_fadvise(struct file *fil
  extern int generic_fadvise(struct file *file, loff_t offset, loff_t len,
  			   int advice);
  
 +static inline bool vfs_empty_path(int dfd, const char __user *path)
 +{
 +	char c;
 +
 +	if (dfd < 0)
 +		return false;
 +
 +	/* We now allow NULL to be used for empty path. */
 +	if (!path)
 +		return true;
 +
 +	if (unlikely(get_user(c, path)))
 +		return false;
 +
 +	return !c;
 +}
 +
+ bool generic_atomic_write_valid(struct iov_iter *iter, loff_t pos);
+ 
  #endif /* _LINUX_FS_H */

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

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

[Christian Brauner]

On Fri, Jun 28, 2024 at 06:59:39PM GMT, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   fs/stat.c
> 
> between commit:
> 
>   0ef625bba6fb2 ("vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)")
> 
> from the vfs-brauner tree and commit:
> 
>   0f9ca80fa4f96 ("fs: Add initial atomic write support info to statx")
>   9abcfbd235f59 ("block: Add atomic write support for statx")
> 
> from the block tree.

Jens,

Can you give me the fs bits and I'll put them in a shared branch we can
both pull in?

> 
> 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.
> 
> diff --cc fs/stat.c
> index 6f65b3456cadb,bd0698dfd7b36..0000000000000
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@@ -214,43 -245,6 +245,45 @@@ int getname_statx_lookup_flags(int flag
>   	return lookup_flags;
>   }
>   
>  +static int vfs_statx_path(struct path *path, int flags, struct kstat *stat,
>  +			  u32 request_mask)
>  +{
>  +	int error = vfs_getattr(path, stat, request_mask, flags);
> ++	struct inode *backing_inode;
>  +
>  +	if (request_mask & STATX_MNT_ID_UNIQUE) {
>  +		stat->mnt_id = real_mount(path->mnt)->mnt_id_unique;
>  +		stat->result_mask |= STATX_MNT_ID_UNIQUE;
>  +	} else {
>  +		stat->mnt_id = real_mount(path->mnt)->mnt_id;
>  +		stat->result_mask |= STATX_MNT_ID;
>  +	}
>  +
>  +	if (path_mounted(path))
>  +		stat->attributes |= STATX_ATTR_MOUNT_ROOT;
>  +	stat->attributes_mask |= STATX_ATTR_MOUNT_ROOT;
>  +
> - 	/* Handle STATX_DIOALIGN for block devices. */
> - 	if (request_mask & STATX_DIOALIGN) {
> - 		struct inode *inode = d_backing_inode(path->dentry);
> - 
> - 		if (S_ISBLK(inode->i_mode))
> - 			bdev_statx_dioalign(inode, stat);
> - 	}
> ++	/*
> ++	 * If this is a block device inode, override the filesystem
> ++	 * attributes with the block device specific parameters that need to be
> ++	 * obtained from the bdev backing inode.
> ++	 */
> ++	backing_inode = d_backing_inode(path->dentry);
> ++	if (S_ISBLK(backing_inode->i_mode))
> ++		bdev_statx(backing_inode, stat, request_mask);
>  +
>  +	return error;
>  +}
>  +
>  +static int vfs_statx_fd(int fd, int flags, struct kstat *stat,
>  +			  u32 request_mask)
>  +{
>  +	CLASS(fd_raw, f)(fd);
>  +	if (!f.file)
>  +		return -EBADF;
>  +	return vfs_statx_path(&f.file->f_path, flags, stat, request_mask);
>  +}
>  +
>   /**
>    * vfs_statx - Get basic and extra attributes by filename
>    * @dfd: A file descriptor representing the base dir for a relative filename

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

[Jens Axboe]

On 6/29/24 4:05 AM, Christian Brauner wrote:
> On Fri, Jun 28, 2024 at 06:59:39PM GMT, Mark Brown wrote:
>> Hi all,
>>
>> Today's linux-next merge of the block tree got a conflict in:
>>
>>   fs/stat.c
>>
>> between commit:
>>
>>   0ef625bba6fb2 ("vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)")
>>
>> from the vfs-brauner tree and commit:
>>
>>   0f9ca80fa4f96 ("fs: Add initial atomic write support info to statx")
>>   9abcfbd235f59 ("block: Add atomic write support for statx")
>>
>> from the block tree.
> 
> Jens,
> 
> Can you give me the fs bits and I'll put them in a shared branch we can
> both pull in?

It's pretty far down in my tree at this point, so I think we'll just
have to live with this conflict. At least it's not a complicated one to
resolve.

-- 
Jens Axboe

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

[Stephen Rothwell]

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

Hi all,

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

  io_uring/rw.c

between commit:

  56749ed317e2 ("fs, iomap: remove IOCB_DIO_CALLER_COMP")

from the vfs-brauner tree and commit:

  c33e779aba68 ("io_uring: add wrapper type for io_req_tw_func_t arg")

from the block 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 io_uring/rw.c
index 6310a3d08409,a7b568c3dfe8..000000000000
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@@ -566,8 -567,18 +566,10 @@@ static inline int io_fixup_rw_res(struc
  	return res;
  }
  
- void io_req_rw_complete(struct io_kiocb *req, io_tw_token_t tw)
+ void io_req_rw_complete(struct io_tw_req tw_req, io_tw_token_t tw)
  {
+ 	struct io_kiocb *req = tw_req.req;
 -	struct io_rw *rw = io_kiocb_to_cmd(req, struct io_rw);
 -	struct kiocb *kiocb = &rw->kiocb;
 -
 -	if ((kiocb->ki_flags & IOCB_DIO_CALLER_COMP) && kiocb->dio_complete) {
 -		long res = kiocb->dio_complete(rw->kiocb.private);
 -
 -		io_req_set_res(req, io_fixup_rw_res(req, res), 0);
 -	}
+ 
  	io_req_io_end(req);
  
  	if (req->flags & (REQ_F_BUFFER_SELECTED|REQ_F_BUFFER_RING))

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

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

[Mark Brown]

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

Hi all,

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

  block/t10-pi.c

between commit:

  179c2a24466b2 ("block: prepare generation / verification helpers for fs usage")

from the vfs-brauner tree and commit:

  7f0bc835bd428 ("blk-integrity: support arbitrary buffer alignment")

from the block 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.

I don't have a huge degree of confidence in this merge as the block
change was quite large and the code is entirely unfamiliar to me.

diff --cc block/t10-pi.c
index d27be6041fd31,3a564c0e2fe80..0000000000000
--- a/block/t10-pi.c
+++ b/block/t10-pi.c
@@@ -372,83 -267,283 +267,284 @@@ static void blk_integrity_set(struct bl
  	}
  }
  
+ static blk_status_t blk_integrity_interval(struct blk_integrity_iter *iter,
+ 					   bool verify)
+ {
+ 	blk_status_t ret = BLK_STS_OK;
+ 	union pi_tuple tuple;
+ 	void *ptuple = &tuple;
+ 	struct bio_vec pbv;
+ 
+ 	blk_integrity_csum_offset(iter);
+ 	pbv = bvec_iter_bvec(iter->bip->bip_vec, iter->prot_iter);
+ 	if (pbv.bv_len >= iter->bi->pi_tuple_size) {
+ 		ptuple = bvec_kmap_local(&pbv);
+ 		bvec_iter_advance_single(iter->bip->bip_vec, &iter->prot_iter,
+ 				iter->bi->metadata_size - iter->bi->pi_offset);
+ 	} else if (verify) {
+ 		blk_integrity_copy_to_tuple(iter->bip, &iter->prot_iter,
+ 				ptuple, iter->bi->pi_tuple_size);
+ 	}
+ 
+ 	if (verify)
+ 		ret = blk_integrity_verify(iter, ptuple);
+ 	else
+ 		blk_integrity_set(iter, ptuple);
+ 
+ 	if (likely(ptuple != &tuple)) {
+ 		kunmap_local(ptuple);
+ 	} else if (!verify) {
+ 		blk_integrity_copy_from_tuple(iter->bip, &iter->prot_iter,
+ 				ptuple, iter->bi->pi_tuple_size);
+ 	}
+ 
+ 	iter->interval_remaining = 1 << iter->bi->interval_exp;
+ 	iter->csum = 0;
+ 	iter->seed++;
+ 	return ret;
+ }
+ 
 -static void blk_integrity_iterate(struct bio *bio, struct bvec_iter *data_iter,
 -				  bool verify)
++static blk_status_t blk_integrity_iterate(struct bio *bio, struct bvec_iter *data_iter,
++					  bool verify)
+ {
+ 	struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk);
+ 	struct bio_integrity_payload *bip = bio_integrity(bio);
+ 	struct blk_integrity_iter iter = {
+ 		.bio = bio,
+ 		.bip = bip,
+ 		.bi = bi,
+ 		.data_iter = *data_iter,
+ 		.prot_iter = bip->bip_iter,
+ 		.interval_remaining = 1 << bi->interval_exp,
+ 		.seed = data_iter->bi_sector,
+ 		.csum = 0,
+ 	};
+ 	blk_status_t ret = BLK_STS_OK;
+ 
+ 	while (iter.data_iter.bi_size && ret == BLK_STS_OK) {
+ 		struct bio_vec bv = bvec_iter_bvec(iter.bio->bi_io_vec,
+ 						   iter.data_iter);
+ 		void *kaddr = bvec_kmap_local(&bv);
+ 		void *data = kaddr;
+ 		unsigned int len;
+ 
+ 		bvec_iter_advance_single(iter.bio->bi_io_vec, &iter.data_iter,
+ 					 bv.bv_len);
+ 		while (bv.bv_len && ret == BLK_STS_OK) {
+ 			len = min(iter.interval_remaining, bv.bv_len);
+ 			blk_calculate_guard(&iter, data, len);
+ 			bv.bv_len -= len;
+ 			data += len;
+ 			iter.interval_remaining -= len;
+ 			if (!iter.interval_remaining)
+ 				ret = blk_integrity_interval(&iter, verify);
+ 		}
+ 		kunmap_local(kaddr);
+ 	}
+ 
 -	if (ret)
 -		bio->bi_status = ret;
++	return ret;
+ }
+ 
 -void blk_integrity_generate(struct bio *bio)
 +void bio_integrity_generate(struct bio *bio)
  {
  	struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk);
- 	struct bio_integrity_payload *bip = bio_integrity(bio);
- 	struct blk_integrity_iter iter;
- 	struct bvec_iter bviter;
- 	struct bio_vec bv;
  
- 	iter.disk_name = bio->bi_bdev->bd_disk->disk_name;
- 	iter.interval = 1 << bi->interval_exp;
- 	iter.seed = bio->bi_iter.bi_sector;
- 	iter.prot_buf = bvec_virt(bip->bip_vec);
- 	bio_for_each_segment(bv, bio, bviter) {
- 		void *kaddr = bvec_kmap_local(&bv);
- 
- 		iter.data_buf = kaddr;
- 		iter.data_size = bv.bv_len;
- 		switch (bi->csum_type) {
- 		case BLK_INTEGRITY_CSUM_CRC64:
- 			ext_pi_crc64_generate(&iter, bi);
- 			break;
- 		case BLK_INTEGRITY_CSUM_CRC:
- 		case BLK_INTEGRITY_CSUM_IP:
- 			t10_pi_generate(&iter, bi);
- 			break;
- 		default:
- 			break;
- 		}
- 		kunmap_local(kaddr);
+ 	switch (bi->csum_type) {
+ 	case BLK_INTEGRITY_CSUM_CRC64:
+ 	case BLK_INTEGRITY_CSUM_CRC:
+ 	case BLK_INTEGRITY_CSUM_IP:
+ 		blk_integrity_iterate(bio, &bio->bi_iter, false);
+ 		break;
+ 	default:
+ 		break;
  	}
  }
  
 -void blk_integrity_verify_iter(struct bio *bio, struct bvec_iter *saved_iter)
 +blk_status_t bio_integrity_verify(struct bio *bio, struct bvec_iter *saved_iter)
  {
  	struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk);
- 	struct bio_integrity_payload *bip = bio_integrity(bio);
- 	struct blk_integrity_iter iter;
- 	struct bvec_iter bviter;
- 	struct bio_vec bv;
  
- 	/*
- 	 * At the moment verify is called bi_iter has been advanced during split
- 	 * and completion, so use the copy created during submission here.
- 	 */
- 	iter.disk_name = bio->bi_bdev->bd_disk->disk_name;
- 	iter.interval = 1 << bi->interval_exp;
- 	iter.seed = saved_iter->bi_sector;
- 	iter.prot_buf = bvec_virt(bip->bip_vec);
- 	__bio_for_each_segment(bv, bio, bviter, *saved_iter) {
- 		void *kaddr = bvec_kmap_local(&bv);
- 		blk_status_t ret = BLK_STS_OK;
- 
- 		iter.data_buf = kaddr;
- 		iter.data_size = bv.bv_len;
- 		switch (bi->csum_type) {
- 		case BLK_INTEGRITY_CSUM_CRC64:
- 			ret = ext_pi_crc64_verify(&iter, bi);
- 			break;
- 		case BLK_INTEGRITY_CSUM_CRC:
- 		case BLK_INTEGRITY_CSUM_IP:
- 			ret = t10_pi_verify(&iter, bi);
- 			break;
- 		default:
- 			break;
- 		}
- 		kunmap_local(kaddr);
- 
- 		if (ret)
- 			return ret;
+ 	switch (bi->csum_type) {
+ 	case BLK_INTEGRITY_CSUM_CRC64:
+ 	case BLK_INTEGRITY_CSUM_CRC:
+ 	case BLK_INTEGRITY_CSUM_IP:
 -		blk_integrity_iterate(bio, saved_iter, true);
++		return blk_integrity_iterate(bio, saved_iter, true);
+ 		break;
+ 	default:
+ 		break;
  	}
 +
 +	return BLK_STS_OK;
  }
  
- void blk_integrity_prepare(struct request *rq)
+ /*
+  * Advance @iter past the protection offset for protection formats that
+  * contain front padding on the metadata region.
+  */
+ static void blk_pi_advance_offset(struct blk_integrity *bi,
+ 				  struct bio_integrity_payload *bip,
+ 				  struct bvec_iter *iter)
+ {
+ 	unsigned int offset = bi->pi_offset;
+ 
+ 	while (offset > 0) {
+ 		struct bio_vec bv = mp_bvec_iter_bvec(bip->bip_vec, *iter);
+ 		unsigned int len = min(bv.bv_len, offset);
+ 
+ 		bvec_iter_advance_single(bip->bip_vec, iter, len);
+ 		offset -= len;
+ 	}
+ }
+ 
+ static void *blk_tuple_remap_begin(union pi_tuple *tuple,
+ 				   struct blk_integrity *bi,
+ 				   struct bio_integrity_payload *bip,
+ 				   struct bvec_iter *iter)
+ {
+ 	struct bvec_iter titer;
+ 	struct bio_vec pbv;
+ 
+ 	blk_pi_advance_offset(bi, bip, iter);
+ 	pbv = bvec_iter_bvec(bip->bip_vec, *iter);
+ 	if (likely(pbv.bv_len >= bi->pi_tuple_size))
+ 		return bvec_kmap_local(&pbv);
+ 
+ 	/*
+ 	 * We need to preserve the state of the original iter for the
+ 	 * copy_from_tuple at the end, so make a temp iter for here.
+ 	 */
+ 	titer = *iter;
+ 	blk_integrity_copy_to_tuple(bip, &titer, tuple, bi->pi_tuple_size);
+ 	return tuple;
+ }
+ 
+ static void blk_tuple_remap_end(union pi_tuple *tuple, void *ptuple,
+ 				struct blk_integrity *bi,
+ 				struct bio_integrity_payload *bip,
+ 				struct bvec_iter *iter)
+ {
+ 	unsigned int len = bi->metadata_size - bi->pi_offset;
+ 
+ 	if (likely(ptuple != tuple)) {
+ 		kunmap_local(ptuple);
+ 	} else {
+ 		blk_integrity_copy_from_tuple(bip, iter, ptuple,
+ 				bi->pi_tuple_size);
+ 		len -= bi->pi_tuple_size;
+ 	}
+ 
+ 	bvec_iter_advance(bip->bip_vec, iter, len);
+ }
+ 
+ static void blk_set_ext_unmap_ref(struct crc64_pi_tuple *pi, u64 virt,
+ 				  u64 ref_tag)
+ {
+ 	u64 ref = get_unaligned_be48(&pi->ref_tag);
+ 
+ 	if (ref == lower_48_bits(ref_tag) && ref != lower_48_bits(virt))
+ 		put_unaligned_be48(virt, pi->ref_tag);
+ }
+ 
+ static void blk_set_t10_unmap_ref(struct t10_pi_tuple *pi, u32 virt,
+ 				  u32 ref_tag)
+ {
+ 	u32 ref = get_unaligned_be32(&pi->ref_tag);
+ 
+ 	if (ref == ref_tag && ref != virt)
+ 		put_unaligned_be32(virt, &pi->ref_tag);
+ }
+ 
+ static void blk_reftag_remap_complete(struct blk_integrity *bi,
+ 				      union pi_tuple *tuple, u64 virt, u64 ref)
+ {
+ 	switch (bi->csum_type) {
+ 	case BLK_INTEGRITY_CSUM_CRC64:
+ 		blk_set_ext_unmap_ref(&tuple->crc64_pi, virt, ref);
+ 		break;
+ 	case BLK_INTEGRITY_CSUM_CRC:
+ 	case BLK_INTEGRITY_CSUM_IP:
+ 		blk_set_t10_unmap_ref(&tuple->t10_pi, virt, ref);
+ 		break;
+ 	default:
+ 		WARN_ON_ONCE(1);
+ 		break;
+ 	}
+ }
+ 
+ static void blk_set_ext_map_ref(struct crc64_pi_tuple *pi, u64 virt,
+ 				u64 ref_tag)
+ {
+ 	u64 ref = get_unaligned_be48(&pi->ref_tag);
+ 
+ 	if (ref == lower_48_bits(virt) && ref != ref_tag)
+ 		put_unaligned_be48(ref_tag, pi->ref_tag);
+ }
+ 
+ static void blk_set_t10_map_ref(struct t10_pi_tuple *pi, u32 virt, u32 ref_tag)
+ {
+ 	u32 ref = get_unaligned_be32(&pi->ref_tag);
+ 
+ 	if (ref == virt && ref != ref_tag)
+ 		put_unaligned_be32(ref_tag, &pi->ref_tag);
+ }
+ 
+ static void blk_reftag_remap_prepare(struct blk_integrity *bi,
+ 				     union pi_tuple *tuple,
+ 				     u64 virt, u64 ref)
+ {
+ 	switch (bi->csum_type) {
+ 	case BLK_INTEGRITY_CSUM_CRC64:
+ 		blk_set_ext_map_ref(&tuple->crc64_pi, virt, ref);
+ 		break;
+ 	case BLK_INTEGRITY_CSUM_CRC:
+ 	case BLK_INTEGRITY_CSUM_IP:
+ 		blk_set_t10_map_ref(&tuple->t10_pi, virt, ref);
+ 		break;
+ 	default:
+ 		WARN_ON_ONCE(1);
+ 		break;
+ 	}
+ }
+ 
+ static void __blk_reftag_remap(struct bio *bio, struct blk_integrity *bi,
+ 			       unsigned *intervals, u64 *ref, bool prep)
+ {
+ 	struct bio_integrity_payload *bip = bio_integrity(bio);
+ 	struct bvec_iter iter = bip->bip_iter;
+ 	u64 virt = bip_get_seed(bip);
+ 	union pi_tuple *ptuple;
+ 	union pi_tuple tuple;
+ 
+ 	if (prep && bip->bip_flags & BIP_MAPPED_INTEGRITY) {
+ 		*ref += bio->bi_iter.bi_size >> bi->interval_exp;
+ 		return;
+ 	}
+ 
+ 	while (iter.bi_size && *intervals) {
+ 		ptuple = blk_tuple_remap_begin(&tuple, bi, bip, &iter);
+ 
+ 		if (prep)
+ 			blk_reftag_remap_prepare(bi, ptuple, virt, *ref);
+ 		else
+ 			blk_reftag_remap_complete(bi, ptuple, virt, *ref);
+ 
+ 		blk_tuple_remap_end(&tuple, ptuple, bi, bip, &iter);
+ 		(*intervals)--;
+ 		(*ref)++;
+ 		virt++;
+ 	}
+ 
+ 	if (prep)
+ 		bip->bip_flags |= BIP_MAPPED_INTEGRITY;
+ }
+ 
+ static void blk_integrity_remap(struct request *rq, unsigned int nr_bytes,
+ 				bool prep)
  {
  	struct blk_integrity *bi = &rq->q->limits.integrity;
+ 	u64 ref = blk_rq_pos(rq) >> (bi->interval_exp - SECTOR_SHIFT);
+ 	unsigned intervals = nr_bytes >> bi->interval_exp;
+ 	struct bio *bio;
  
  	if (!(bi->flags & BLK_INTEGRITY_REF_TAG))
  		return;

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

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

[Christoph Hellwig]

On Thu, Mar 05, 2026 at 01:44:28PM +0000, Mark Brown wrote:
> 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.
> 
> I don't have a huge degree of confidence in this merge as the block
> change was quite large and the code is entirely unfamiliar to me.

I'm familiar with the code and looking at this I have a hard time
understanding the merge.  I think we need to get both of these changes
into the same branch somehow to properly audit and test it.

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

[Mark Brown]

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

On Thu, Mar 05, 2026 at 03:54:28PM +0100, Christoph Hellwig wrote:
> On Thu, Mar 05, 2026 at 01:44:28PM +0000, Mark Brown wrote:

> > I don't have a huge degree of confidence in this merge as the block
> > change was quite large and the code is entirely unfamiliar to me.

> I'm familiar with the code and looking at this I have a hard time
> understanding the merge.  I think we need to get both of these changes
> into the same branch somehow to properly audit and test it.

Thanks for taking a look, like I said above I did fear that was the
case unfortunately.  Your suggestion sounds like the safest way forward
to me, let me know if there's an updated change I should carry.

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

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

[Keith Busch]

On Thu, Mar 05, 2026 at 03:54:28PM +0100, Christoph Hellwig wrote:
> On Thu, Mar 05, 2026 at 01:44:28PM +0000, Mark Brown wrote:
> > 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.
> > 
> > I don't have a huge degree of confidence in this merge as the block
> > change was quite large and the code is entirely unfamiliar to me.
> 
> I'm familiar with the code and looking at this I have a hard time
> understanding the merge.  I think we need to get both of these changes
> into the same branch somehow to properly audit and test it.

Yeah, one of us should have to rebase to the other. Since mine is just a
single patch on the one colliding file, I think it easiest if I just
rebase my data alignment updates to the vfs integrity branch, then send
upstream through there. Let me know if there's an alternate preference.

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

[Christoph Hellwig]

On Thu, Mar 05, 2026 at 10:34:02AM -0700, Keith Busch wrote:
> Yeah, one of us should have to rebase to the other. Since mine is just a
> single patch on the one colliding file, I think it easiest if I just
> rebase my data alignment updates to the vfs integrity branch, then send
> upstream through there. Let me know if there's an alternate preference.

Yes, I think that would work best.

Jens: is this okay with you?

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

[Jens Axboe]

On 3/6/26 7:22 AM, Christoph Hellwig wrote:
> On Thu, Mar 05, 2026 at 10:34:02AM -0700, Keith Busch wrote:
>> Yeah, one of us should have to rebase to the other. Since mine is just a
>> single patch on the one colliding file, I think it easiest if I just
>> rebase my data alignment updates to the vfs integrity branch, then send
>> upstream through there. Let me know if there's an alternate preference.
> 
> Yes, I think that would work best.
> 
> Jens: is this okay with you?

I think the mistake here is the fact that the integrity stuff got
ingested wholesale on the VFS side. That should've been split. So
why don't we redo that part? I stage the first 7 in a branch off
-rc1, Christian pulls those in, and stages the ntfs3/iomap/xfs
on top. That's how it should've been done so let's please just do
that now, rather than make an even bigger mess of this.

-- 
Jens Axboe

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

[Jens Axboe]

On 3/9/26 7:45 AM, Jens Axboe wrote:
> On 3/6/26 7:22 AM, Christoph Hellwig wrote:
>> On Thu, Mar 05, 2026 at 10:34:02AM -0700, Keith Busch wrote:
>>> Yeah, one of us should have to rebase to the other. Since mine is just a
>>> single patch on the one colliding file, I think it easiest if I just
>>> rebase my data alignment updates to the vfs integrity branch, then send
>>> upstream through there. Let me know if there's an alternate preference.
>>
>> Yes, I think that would work best.
>>
>> Jens: is this okay with you?
> 
> I think the mistake here is the fact that the integrity stuff got
> ingested wholesale on the VFS side. That should've been split. So
> why don't we redo that part? I stage the first 7 in a branch off
> -rc1, Christian pulls those in, and stages the ntfs3/iomap/xfs
> on top. That's how it should've been done so let's please just do
> that now, rather than make an even bigger mess of this.

Done:

for-7.1/block-integrity

then I can either drop Keith's patch from for-7.1/block (rebasing that
tree), and then Keith can send a new one on top of for-7.1/block which
can pull in the above branch as well.

-- 
Jens Axboe

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

[Jens Axboe]

On 3/9/26 7:48 AM, Jens Axboe wrote:
> On 3/9/26 7:45 AM, Jens Axboe wrote:
>> On 3/6/26 7:22 AM, Christoph Hellwig wrote:
>>> On Thu, Mar 05, 2026 at 10:34:02AM -0700, Keith Busch wrote:
>>>> Yeah, one of us should have to rebase to the other. Since mine is just a
>>>> single patch on the one colliding file, I think it easiest if I just
>>>> rebase my data alignment updates to the vfs integrity branch, then send
>>>> upstream through there. Let me know if there's an alternate preference.
>>>
>>> Yes, I think that would work best.
>>>
>>> Jens: is this okay with you?
>>
>> I think the mistake here is the fact that the integrity stuff got
>> ingested wholesale on the VFS side. That should've been split. So
>> why don't we redo that part? I stage the first 7 in a branch off
>> -rc1, Christian pulls those in, and stages the ntfs3/iomap/xfs
>> on top. That's how it should've been done so let's please just do
>> that now, rather than make an even bigger mess of this.
> 
> Done:
> 
> for-7.1/block-integrity
> 
> then I can either drop Keith's patch from for-7.1/block (rebasing that
> tree), and then Keith can send a new one on top of for-7.1/block which
> can pull in the above branch as well.

Keith, current for-7.1/block is now updated too, I dropped your patch
and while doing so also rebased it to -rc3, as we might as well on a
rebase. for-7.1/block-integrity is pulled into that, and Christian
already acked out-of-band on redoing the fs side of this on top of
that same shared branch.

-- 
Jens Axboe

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

[Christoph Hellwig]

Hі,

it looks like the for-7.1/block-integrity and the vfs-7.1.integrity
based on it are branched off 7.0-rc1 and thus miss the iomap fixes
in 7.0-rc3 and thus create a conflict in linux-next.  Can we fix
this, especially as the main for-7.1/block branch is based on 7.0-rc3
anyway?