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

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

[Stephen Rothwell]

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

Hi all,

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

  fs/io_uring.c

between commit:

  4329490a78b6 ("io_uring_enter(): don't leave f.flags uninitialized")

from the vfs tree and commit:

  3e813c902672 ("io_uring: rework io_uring_enter to simplify return value")

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 fs/io_uring.c
index 82a1eac73de7,fd47002e669d..000000000000
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@@ -10840,8 -12060,9 +12060,8 @@@ iopoll_locked
  out:
  	percpu_ref_put(&ctx->refs);
  out_fput:
 -	if (!(flags & IORING_ENTER_REGISTERED_RING))
 -		fdput(f);
 +	fdput(f);
- 	return submitted ? submitted : ret;
+ 	return ret;
  }
  
  #ifdef CONFIG_PROC_FS

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

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

[Jens Axboe]

On 5/22/22 8:28 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   fs/io_uring.c
> 
> between commit:
> 
>   4329490a78b6 ("io_uring_enter(): don't leave f.flags uninitialized")
> 
> from the vfs tree and commit:
> 
>   3e813c902672 ("io_uring: rework io_uring_enter to simplify return value")
> 
> 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.

Fixup looks good, thanks.

-- 
Jens Axboe

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

[Stephen Rothwell]

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

Hi all,

On Mon, 23 May 2022 12:28:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
> 
>   fs/io_uring.c
> 
> between commit:
> 
>   4329490a78b6 ("io_uring_enter(): don't leave f.flags uninitialized")
> 
> from the vfs tree and commit:
> 
>   3e813c902672 ("io_uring: rework io_uring_enter to simplify return value")
> 
> 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/io_uring.c
> index 82a1eac73de7,fd47002e669d..000000000000
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@@ -10840,8 -12060,9 +12060,8 @@@ iopoll_locked
>   out:
>   	percpu_ref_put(&ctx->refs);
>   out_fput:
>  -	if (!(flags & IORING_ENTER_REGISTERED_RING))
>  -		fdput(f);
>  +	fdput(f);
> - 	return submitted ? submitted : ret;
> + 	return ret;
>   }
>   
>   #ifdef CONFIG_PROC_FS


This is now a conflict between Linus' tree and the vfs tree.
-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  io_uring/net.c

between commit:

  de4eda9de2d9 ("use less confusing names for iov_iter direction initializers")

from the vfs tree and commit:

  42385b02baad ("io_uring/net: move mm accounting to a slower path")

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/net.c
index 2818aeefea42,90342dcb6b1d..000000000000
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@@ -1087,7 -1095,8 +1095,8 @@@ int io_send_zc(struct io_kiocb *req, un
  			return ret;
  		msg.sg_from_iter = io_sg_from_iter;
  	} else {
+ 		io_notif_set_extended(zc->notif);
 -		ret = import_single_range(WRITE, zc->buf, zc->len, &iov,
 +		ret = import_single_range(ITER_SOURCE, zc->buf, zc->len, &iov,
  					  &msg.msg_iter);
  		if (unlikely(ret))
  			return ret;

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

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

[Jens Axboe]

On 7/19/22 8:45 PM, Al Viro wrote:
> On Tue, Jul 19, 2022 at 10:52:12AM -0600, Jens Axboe wrote:
>> On 7/17/22 10:58 PM, Al Viro wrote:
>>> On Mon, Jul 18, 2022 at 12:59:32PM +1000, Stephen Rothwell wrote:
>>>> Hi Al,
>>>>
>>>> On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <viro@zeniv.linux.org.uk> wrote:
>>>>>
>>>>> On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
>>>>>
>>>>>> Ones from Keith's branch - #alignment-fixes-rebased in there.  Looks like
>>>>>> one of the commits in it got changed since then - the difference in
>>>>>> __bio_iov_iter_get_pages() (unsigned int i initialization).
>>>>>>
>>>>>> Sigh...  I'll rebase on top of that.  
>>>>>
>>>>> Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
>>>>
>>>> BTW, these still cause a conflict.  As long as you are sharing patches
>>>> (and then adding changes to the same areas), there will be conflicts.
>>>> You need to share commits i.e. a shared branch.
>>>
>>> Sigh...  That was (and is) a branch form Keith's tree.  Commits in block
>>> tree are, AFAICS, cherry-picked from it, with lore links and Jens' s-o-b
>>> added.
>>>
>>> I'm fine with using that, just tell me how to refer to the branch in
>>> question.  Jens?
>>
>> Are you fine with rebasing that one again? Seems the better approach
>> since it's all in one spot. The git location is:
>>
>> git://git.kernel.dk/linux-block for-5.20/block-iter
>>
>> which has all of them, and is the same base as the previous one. Do you
>> want a signed tag, or is the branch fine?
> 
> Grabbed, rebased and force-pushed (identical tree object, so probably
> hadn't fucked it up...)

Great, thanks Al.

-- 
Jens Axboe

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

[Al Viro]

On Tue, Jul 19, 2022 at 10:52:12AM -0600, Jens Axboe wrote:
> On 7/17/22 10:58 PM, Al Viro wrote:
> > On Mon, Jul 18, 2022 at 12:59:32PM +1000, Stephen Rothwell wrote:
> >> Hi Al,
> >>
> >> On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <viro@zeniv.linux.org.uk> wrote:
> >>>
> >>> On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
> >>>
> >>>> Ones from Keith's branch - #alignment-fixes-rebased in there.  Looks like
> >>>> one of the commits in it got changed since then - the difference in
> >>>> __bio_iov_iter_get_pages() (unsigned int i initialization).
> >>>>
> >>>> Sigh...  I'll rebase on top of that.  
> >>>
> >>> Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
> >>
> >> BTW, these still cause a conflict.  As long as you are sharing patches
> >> (and then adding changes to the same areas), there will be conflicts.
> >> You need to share commits i.e. a shared branch.
> > 
> > Sigh...  That was (and is) a branch form Keith's tree.  Commits in block
> > tree are, AFAICS, cherry-picked from it, with lore links and Jens' s-o-b
> > added.
> > 
> > I'm fine with using that, just tell me how to refer to the branch in
> > question.  Jens?
> 
> Are you fine with rebasing that one again? Seems the better approach
> since it's all in one spot. The git location is:
> 
> git://git.kernel.dk/linux-block for-5.20/block-iter
> 
> which has all of them, and is the same base as the previous one. Do you
> want a signed tag, or is the branch fine?

Grabbed, rebased and force-pushed (identical tree object, so probably hadn't
fucked it up...)

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

[Jens Axboe]

On 7/17/22 10:58 PM, Al Viro wrote:
> On Mon, Jul 18, 2022 at 12:59:32PM +1000, Stephen Rothwell wrote:
>> Hi Al,
>>
>> On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <viro@zeniv.linux.org.uk> wrote:
>>>
>>> On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
>>>
>>>> Ones from Keith's branch - #alignment-fixes-rebased in there.  Looks like
>>>> one of the commits in it got changed since then - the difference in
>>>> __bio_iov_iter_get_pages() (unsigned int i initialization).
>>>>
>>>> Sigh...  I'll rebase on top of that.  
>>>
>>> Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
>>
>> BTW, these still cause a conflict.  As long as you are sharing patches
>> (and then adding changes to the same areas), there will be conflicts.
>> You need to share commits i.e. a shared branch.
> 
> Sigh...  That was (and is) a branch form Keith's tree.  Commits in block
> tree are, AFAICS, cherry-picked from it, with lore links and Jens' s-o-b
> added.
> 
> I'm fine with using that, just tell me how to refer to the branch in
> question.  Jens?

Are you fine with rebasing that one again? Seems the better approach
since it's all in one spot. The git location is:

git://git.kernel.dk/linux-block for-5.20/block-iter

which has all of them, and is the same base as the previous one. Do you
want a signed tag, or is the branch fine?

-- 
Jens Axboe

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

[Al Viro]

On Mon, Jul 18, 2022 at 12:59:32PM +1000, Stephen Rothwell wrote:
> Hi Al,
> 
> On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
> > 
> > > Ones from Keith's branch - #alignment-fixes-rebased in there.  Looks like
> > > one of the commits in it got changed since then - the difference in
> > > __bio_iov_iter_get_pages() (unsigned int i initialization).
> > > 
> > > Sigh...  I'll rebase on top of that.  
> > 
> > Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)
> 
> BTW, these still cause a conflict.  As long as you are sharing patches
> (and then adding changes to the same areas), there will be conflicts.
> You need to share commits i.e. a shared branch.

Sigh...  That was (and is) a branch form Keith's tree.  Commits in block
tree are, AFAICS, cherry-picked from it, with lore links and Jens' s-o-b
added.

I'm fine with using that, just tell me how to refer to the branch in
question.  Jens?

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

[Stephen Rothwell]

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

Hi Al,

On Fri, 15 Jul 2022 02:04:02 +0100 Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:
> 
> > Ones from Keith's branch - #alignment-fixes-rebased in there.  Looks like
> > one of the commits in it got changed since then - the difference in
> > __bio_iov_iter_get_pages() (unsigned int i initialization).
> > 
> > Sigh...  I'll rebase on top of that.  
> 
> Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)

BTW, these still cause a conflict.  As long as you are sharing patches
(and then adding changes to the same areas), there will be conflicts.
You need to share commits i.e. a shared branch.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  block/fops.c

between commit:

  91b94c5d6ae5 ("iocb: delay evaluation of IS_SYNC(...) until we want to check IOCB_DSYNC")

from the vfs tree and commit:

  16458cf3bd15 ("block: Use the new blk_opf_t type")

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/fops.c
index 7a40bc87d80f,29066ac5a2fa..000000000000
--- a/block/fops.c
+++ b/block/fops.c
@@@ -32,14 -32,14 +32,14 @@@ static int blkdev_get_block(struct inod
  	return 0;
  }
  
- static unsigned int dio_bio_write_op(struct kiocb *iocb)
+ static blk_opf_t dio_bio_write_op(struct kiocb *iocb)
  {
- 	unsigned int op = REQ_OP_WRITE | REQ_SYNC | REQ_IDLE;
+ 	blk_opf_t opf = REQ_OP_WRITE | REQ_SYNC | REQ_IDLE;
  
  	/* avoid the need for a I/O completion work item */
 -	if (iocb->ki_flags & IOCB_DSYNC)
 +	if (iocb_is_dsync(iocb))
- 		op |= REQ_FUA;
- 	return op;
+ 		opf |= REQ_FUA;
+ 	return opf;
  }
  
  static bool blkdev_dio_unaligned(struct block_device *bdev, loff_t pos,

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

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

[Al Viro]

On Fri, Jul 15, 2022 at 01:52:25AM +0100, Al Viro wrote:

> Ones from Keith's branch - #alignment-fixes-rebased in there.  Looks like
> one of the commits in it got changed since then - the difference in
> __bio_iov_iter_get_pages() (unsigned int i initialization).
> 
> Sigh...  I'll rebase on top of that.

Rebased and pushed out (with copy_pipe_to_iter() fix folded in as well)

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

[Al Viro]

On Thu, Jul 14, 2022 at 10:36:35AM -0600, Jens Axboe wrote:
> On 7/13/22 8:08 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the block tree got a conflict in:
> > 
> >   block/bio.c
> > 
> > between commits:
> > 
> >   35006342b739 ("block: ensure iov_iter advances for added pages")
> >   248022ffae3f ("block: ensure bio_iov_add_page can't fail")
> >   7b1ccdf617ca ("block: fix leaking page ref on truncated direct io")
> >   9a6469060316 ("block: convert to advancing variants of iov_iter_get_pages{,_alloc}()")
> > 
> > from the vfs tree and commits:
> > 
> >   5a044eef1265 ("block: ensure iov_iter advances for added pages")
> >   ac3c48e32c04 ("block: ensure bio_iov_add_page can't fail")
> >   44b6b0b0e980 ("block: fix leaking page ref on truncated direct io")
> > 
> > from the block tree.
> 
> I pinged Al about this the other day, but haven't heard back yet. It's
> not clear to me what block bits he has in his tree. We'll get it sorted
> out.

Ones from Keith's branch - #alignment-fixes-rebased in there.  Looks like
one of the commits in it got changed since then - the difference in
__bio_iov_iter_get_pages() (unsigned int i initialization).

Sigh...  I'll rebase on top of that.

Al, digging through the vicinity of propagate_umount() and cursing himself
and ebiederman in about equal proportions since the last weekend...

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

[Jens Axboe]

On 7/13/22 8:08 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   block/bio.c
> 
> between commits:
> 
>   35006342b739 ("block: ensure iov_iter advances for added pages")
>   248022ffae3f ("block: ensure bio_iov_add_page can't fail")
>   7b1ccdf617ca ("block: fix leaking page ref on truncated direct io")
>   9a6469060316 ("block: convert to advancing variants of iov_iter_get_pages{,_alloc}()")
> 
> from the vfs tree and commits:
> 
>   5a044eef1265 ("block: ensure iov_iter advances for added pages")
>   ac3c48e32c04 ("block: ensure bio_iov_add_page can't fail")
>   44b6b0b0e980 ("block: fix leaking page ref on truncated direct io")
> 
> from the block tree.

I pinged Al about this the other day, but haven't heard back yet. It's
not clear to me what block bits he has in his tree. We'll get it sorted
out.

-- 
Jens Axboe

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

[Stephen Rothwell]

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

Hi all,

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

  block/bio.c

between commits:

  35006342b739 ("block: ensure iov_iter advances for added pages")
  248022ffae3f ("block: ensure bio_iov_add_page can't fail")
  7b1ccdf617ca ("block: fix leaking page ref on truncated direct io")
  9a6469060316 ("block: convert to advancing variants of iov_iter_get_pages{,_alloc}()")

from the vfs tree and commits:

  5a044eef1265 ("block: ensure iov_iter advances for added pages")
  ac3c48e32c04 ("block: ensure bio_iov_add_page can't fail")
  44b6b0b0e980 ("block: fix leaking page ref on truncated direct io")

from the block tree.

Commits 35006342b739 and 5a044eef1265 are the same patch as are
248022ffae3f and ac3c48e32c04.  Commits 7b1ccdf617ca and 44b6b0b0e980
are slightly different.  Then 9a6469060316 touches the same code :-(

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/bio.c
index d3bc05ed0783,6659442eb101..000000000000
--- a/block/bio.c
+++ b/block/bio.c
@@@ -1199,8 -1199,8 +1199,8 @@@ static int __bio_iov_iter_get_pages(str
  	struct bio_vec *bv = bio->bi_io_vec + bio->bi_vcnt;
  	struct page **pages = (struct page **)bv;
  	ssize_t size, left;
- 	unsigned len, i;
+ 	unsigned len, i = 0;
 -	size_t offset;
 +	size_t offset, trim;
  	int ret = 0;
  
  	/*

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

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

[Stephen Rothwell]

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

Hi all,

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

  fs/io_uring.c

between commit:

  164f4064ca81 ("keep iocb_flags() result cached in struct file")

from the vfs tree and commits:

  239b2db7c7ca ("io_uring: move to separate directory")
  9d6c15adf84b ("io_uring: move read/write related opcodes to its own file")

from the block tree.

I fixed it up (I deleted the file and adde the following merge fix patch)
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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 Jul 2022 13:47:50 +1000
Subject: [PATCH] fixup for "keep iocb_flags() result cached in struct file"

interacting with "io_uring: move to separate directory" and
"io_uring: move read/write related opcodes to its own file".

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 io_uring/rw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/io_uring/rw.c b/io_uring/rw.c
index ca0d3a72364a..bc10b8c7cc86 100644
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@ -666,7 +666,7 @@ static int io_rw_init_file(struct io_kiocb *req, fmode_t mode)
 	if (!io_req_ffs_set(req))
 		req->flags |= io_file_get_flags(file) << REQ_F_SUPPORT_NOWAIT_BIT;
 
-	kiocb->ki_flags = iocb_flags(file);
+	kiocb->ki_flags = file->f_iocb_flags;
 	ret = kiocb_set_rw_flags(kiocb, rw->flags);
 	if (unlikely(ret))
 		return ret;
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/block/mtip32xx/mtip32xx.c

between commit:

  c9d86760342f ("fs: do not set no_llseek in fops")

from the vfs tree and commit:

  ec5263f422a3 ("mtip32xx: remove the device_status debugfs file")

from the block tree.

I fixed it up (the former removed a line that was also removed by 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 block tree with the vfs tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/filesystems/porting.rst

between commit:

  14e43bf43561 ("vfs: don't unnecessarily clone write access for writable fds")

from the vfs tree and commits:

  9b2e0016d04c ("bvec/iter: disallow zero-length segment bvecs")
  c42bca92be92 ("bio: don't copy bvec for direct IO")

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 Documentation/filesystems/porting.rst
index c2161de0f4ef,1f8cf8e10b34..000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -872,5 -870,14 +872,21 @@@ its result is kern_unmount() or kern_un
  
  **mandatory**
  
 +mnt_want_write_file() can now only be paired with mnt_drop_write_file(),
 +whereas previously it could be paired with mnt_drop_write() as well.
++
++---
++
++**mandatory**
++
+ zero-length bvec segments are disallowed, they must be filtered out before
+ passed on to an iterator.
+ 
+ ---
+ 
+ **mandatory**
+ 
+ For bvec based itererators bio_iov_iter_get_pages() now doesn't copy bvecs but
+ uses the one provided. Anyone issuing kiocb-I/O should ensure that the bvec and
+ page references stay until I/O has completed, i.e. until ->ki_complete() has
+ been called or returned with non -EIOCBQUEUED code.

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

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

[Jens Axboe]

On 1/19/20 7:45 PM, Jens Axboe wrote:
> On 1/19/20 6:40 PM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> On Thu, 19 Dec 2019 22:34:59 -0700 Jens Axboe <axboe@kernel.dk> wrote:
>>>
>>> On 12/19/19 6:36 PM, Stephen Rothwell wrote:
>>>>
>>>> Today's linux-next merge of the block tree got a conflict in:
>>>>
>>>>   fs/open.c
>>>>
>>>> between commit:
>>>>
>>>>   0a51692d49ec ("open: introduce openat2(2) syscall")
>>>>
>>>> from the vfs tree and commit:
>>>>
>>>>   252270311374 ("fs: make build_open_flags() available internally")
>>>>
>>>> from the block tree.
>>>>
>>>> I fixed it up (see at end, plus the merge fix patch 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.  
>>>
>>> Thanks Stephen, I may just pull in the vfs tree to avoid this conflict.
>>
>> I looks like Al has rewritten the branch you merged from his tree and
>> caused various conflicts in my merge of the block tree today.  I used
>> Al's new versions of the conflicting files.
> 
> That's a bummer. I guess I'll have to rebase on top of the new one. Al,
> is the new one going to be persistent?

Stephen, I rebased and pushed it out, verified that the io_uring bits
are identical to before. So at least this should be painless for you on
next pull.

-- 
Jens Axboe

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

[Jens Axboe]

On 1/19/20 6:40 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Thu, 19 Dec 2019 22:34:59 -0700 Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 12/19/19 6:36 PM, Stephen Rothwell wrote:
>>>
>>> Today's linux-next merge of the block tree got a conflict in:
>>>
>>>   fs/open.c
>>>
>>> between commit:
>>>
>>>   0a51692d49ec ("open: introduce openat2(2) syscall")
>>>
>>> from the vfs tree and commit:
>>>
>>>   252270311374 ("fs: make build_open_flags() available internally")
>>>
>>> from the block tree.
>>>
>>> I fixed it up (see at end, plus the merge fix patch 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.  
>>
>> Thanks Stephen, I may just pull in the vfs tree to avoid this conflict.
> 
> I looks like Al has rewritten the branch you merged from his tree and
> caused various conflicts in my merge of the block tree today.  I used
> Al's new versions of the conflicting files.

That's a bummer. I guess I'll have to rebase on top of the new one. Al,
is the new one going to be persistent?

-- 
Jens Axboe

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

[Stephen Rothwell]

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

Hi Jens,

On Thu, 19 Dec 2019 22:34:59 -0700 Jens Axboe <axboe@kernel.dk> wrote:
>
> On 12/19/19 6:36 PM, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the block tree got a conflict in:
> > 
> >   fs/open.c
> > 
> > between commit:
> > 
> >   0a51692d49ec ("open: introduce openat2(2) syscall")
> > 
> > from the vfs tree and commit:
> > 
> >   252270311374 ("fs: make build_open_flags() available internally")
> > 
> > from the block tree.
> > 
> > I fixed it up (see at end, plus the merge fix patch 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.  
> 
> Thanks Stephen, I may just pull in the vfs tree to avoid this conflict.

I looks like Al has rewritten the branch you merged from his tree and
caused various conflicts in my merge of the block tree today.  I used
Al's new versions of the conflicting files.

-- 
Cheers,
Stephen Rothwell

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

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

[Jens Axboe]

On 12/19/19 6:36 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   fs/open.c
> 
> between commit:
> 
>   0a51692d49ec ("open: introduce openat2(2) syscall")
> 
> from the vfs tree and commit:
> 
>   252270311374 ("fs: make build_open_flags() available internally")
> 
> from the block tree.
> 
> I fixed it up (see at end, plus the merge fix patch 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.

Thanks Stephen, I may just pull in the vfs tree to avoid this conflict.

-- 
Jens Axboe

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

[Stephen Rothwell]

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

Hi all,

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

  fs/open.c

between commit:

  0a51692d49ec ("open: introduce openat2(2) syscall")

from the vfs tree and commit:

  252270311374 ("fs: make build_open_flags() available internally")

from the block tree.

I fixed it up (see at end, plus the merge fix patch 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.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 20 Dec 2019 11:50:51 +1100
Subject: [PATCH] io_uring: fix up for "open: introduce openat2(2) syscall"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/internal.h | 3 ++-
 fs/io_uring.c | 6 ++++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/fs/internal.h b/fs/internal.h
index 166134be439f..dabf747c14fd 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -124,7 +124,8 @@ extern struct file *do_filp_open(int dfd, struct filename *pathname,
 		const struct open_flags *op);
 extern struct file *do_file_open_root(struct dentry *, struct vfsmount *,
 		const char *, const struct open_flags *);
-extern int build_open_flags(int flags, umode_t mode, struct open_flags *op);
+extern struct open_how build_open_how(int flags, umode_t mode);
+extern int build_open_flags(const struct open_how *how, struct open_flags *op);
 
 long do_sys_ftruncate(unsigned int fd, loff_t length, int small);
 long do_faccessat(int dfd, const char __user *filename, int mode);
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 26edb980df02..c756b8fc44c6 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2337,19 +2337,21 @@ static int io_openat(struct io_kiocb *req, struct io_kiocb **nxt,
 		     bool force_nonblock)
 {
 	struct open_flags op;
+	struct open_how how;
 	struct file *file;
 	int ret;
 
 	ret = io_openat_prep(req);
 	if (ret)
 		goto err;
-	ret = build_open_flags(req->open.flags, req->open.mode, &op);
+	how = build_open_how(req->open.flags, req->open.mode);
+	ret = build_open_flags(&how, &op);
 	if (ret)
 		goto err;
 	if (force_nonblock)
 		op.lookup_flags |= LOOKUP_NONBLOCK;
 
-	ret = get_unused_fd_flags(req->open.flags);
+	ret = get_unused_fd_flags(how.flags);
 	if (ret < 0)
 		goto err;
 
-- 
2.24.0

-- 
Cheers,
Stephen Rothwell

diff --cc fs/open.c
index 50a46501bcc9,24cb5d58bbda..000000000000
--- a/fs/open.c
+++ b/fs/open.c
@@@ -955,29 -955,8 +955,29 @@@ struct file *open_with_fake_path(const 
  }
  EXPORT_SYMBOL(open_with_fake_path);
  
 -inline int build_open_flags(int flags, umode_t mode, struct open_flags *op)
 +#define WILL_CREATE(flags)	(flags & (O_CREAT | __O_TMPFILE))
 +#define O_PATH_FLAGS		(O_DIRECTORY | O_NOFOLLOW | O_PATH | O_CLOEXEC)
 +
- static inline struct open_how build_open_how(int flags, umode_t mode)
++inline struct open_how build_open_how(int flags, umode_t mode)
 +{
 +	struct open_how how = {
 +		.flags = flags & VALID_OPEN_FLAGS,
 +		.mode = mode & S_IALLUGO,
 +	};
 +
 +	/* O_PATH beats everything else. */
 +	if (how.flags & O_PATH)
 +		how.flags &= O_PATH_FLAGS;
 +	/* Modes should only be set for create-like flags. */
 +	if (!WILL_CREATE(how.flags))
 +		how.mode = 0;
 +	return how;
 +}
 +
- static inline int build_open_flags(const struct open_how *how,
++inline int build_open_flags(const struct open_how *how,
 +				   struct open_flags *op)
  {
 +	int flags = how->flags;
  	int lookup_flags = 0;
  	int acc_mode = ACC_MODE(flags);
  

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

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

[Jens Axboe]

On 5/29/18 3:40 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Tue, 29 May 2018 08:22:43 -0600 Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 5/29/18 2:12 AM, Christoph Hellwig wrote:
>>> Meh.  Do we really need these switch to octal patches to start
>>> with?  I mean, I personally prefer octal, but just switching around
>>> in random code that isn't otherwise changed creates nothing but churn.  
>>
>> This is exactly why I hesitated doing it, I knew it would end up
>> with conflicts. The main reason was to get rid of the inconsistency,
>> since we had a fair mix of octal and symbolic names.
> 
> But the conflicts are all trivial ...

Yep, that certainly does help.

-- 
Jens Axboe

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

[Stephen Rothwell]

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

Hi Jens,

On Tue, 29 May 2018 08:22:43 -0600 Jens Axboe <axboe@kernel.dk> wrote:
>
> On 5/29/18 2:12 AM, Christoph Hellwig wrote:
> > Meh.  Do we really need these switch to octal patches to start
> > with?  I mean, I personally prefer octal, but just switching around
> > in random code that isn't otherwise changed creates nothing but churn.  
> 
> This is exactly why I hesitated doing it, I knew it would end up
> with conflicts. The main reason was to get rid of the inconsistency,
> since we had a fair mix of octal and symbolic names.

But the conflicts are all trivial ...

-- 
Cheers,
Stephen Rothwell

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

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

[Jens Axboe]

On 5/29/18 2:12 AM, Christoph Hellwig wrote:
> Meh.  Do we really need these switch to octal patches to start
> with?  I mean, I personally prefer octal, but just switching around
> in random code that isn't otherwise changed creates nothing but churn.

This is exactly why I hesitated doing it, I knew it would end up
with conflicts. The main reason was to get rid of the inconsistency,
since we had a fair mix of octal and symbolic names.

-- 
Jens Axboe

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

[Christoph Hellwig]

Meh.  Do we really need these switch to octal patches to start
with?  I mean, I personally prefer octal, but just switching around
in random code that isn't otherwise changed creates nothing but churn.

On Tue, May 29, 2018 at 02:33:57PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   drivers/block/DAC960.c
> 
> between commit:
> 
>   3f3942aca6da ("proc: introduce proc_create_single{,_data}")
> 
> from the vfs tree and commit:
> 
>   5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")
> 
> 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 drivers/block/DAC960.c
> index 6918c3d9482e,7c3887a7e534..000000000000
> --- a/drivers/block/DAC960.c
> +++ b/drivers/block/DAC960.c
> @@@ -6553,11 -6587,9 +6548,11 @@@ static void DAC960_CreateProcEntries(DA
>   		 "c%d", Controller->ControllerNumber);
>   	ControllerProcEntry = proc_mkdir(Controller->ControllerName,
>   					 DAC960_ProcDirectoryEntry);
>  -	proc_create_data("initial_status", 0, ControllerProcEntry, &dac960_initial_status_proc_fops, Controller);
>  -	proc_create_data("current_status", 0, ControllerProcEntry, &dac960_current_status_proc_fops, Controller);
>  +	proc_create_single_data("initial_status", 0, ControllerProcEntry,
>  +			dac960_initial_status_proc_show, Controller);
>  +	proc_create_single_data("current_status", 0, ControllerProcEntry,
>  +			dac960_current_status_proc_show, Controller);
> - 	proc_create_data("user_command", S_IWUSR | S_IRUSR, ControllerProcEntry, &dac960_user_command_proc_fops, Controller);
> + 	proc_create_data("user_command", 0600, ControllerProcEntry, &dac960_user_command_proc_fops, Controller);
>   	Controller->ControllerProcEntry = ControllerProcEntry;
>   }
>   


---end quoted text---

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/block/drbd/drbd_main.c

between commit:

  004fd11db1d6 ("drbd: switch to proc_create_single")

from the vfs tree and commit:

  5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")

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 drivers/block/drbd/drbd_main.c
index c2d154faac02,e6ec831ad472..000000000000
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@@ -3010,8 -3010,7 +3010,8 @@@ static int __init drbd_init(void
  		goto fail;
  
  	err = -ENOMEM;
- 	drbd_proc = proc_create_single("drbd", S_IFREG | S_IRUGO , NULL,
 -	drbd_proc = proc_create_data("drbd", S_IFREG | 0444 , NULL, &drbd_proc_fops, NULL);
++	drbd_proc = proc_create_single("drbd", S_IFREG | 0444 , NULL,
 +			drbd_seq_show);
  	if (!drbd_proc)	{
  		pr_err("unable to register proc file\n");
  		goto fail;

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/block/DAC960.c

between commit:

  3f3942aca6da ("proc: introduce proc_create_single{,_data}")

from the vfs tree and commit:

  5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")

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 drivers/block/DAC960.c
index 6918c3d9482e,7c3887a7e534..000000000000
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@@ -6553,11 -6587,9 +6548,11 @@@ static void DAC960_CreateProcEntries(DA
  		 "c%d", Controller->ControllerNumber);
  	ControllerProcEntry = proc_mkdir(Controller->ControllerName,
  					 DAC960_ProcDirectoryEntry);
 -	proc_create_data("initial_status", 0, ControllerProcEntry, &dac960_initial_status_proc_fops, Controller);
 -	proc_create_data("current_status", 0, ControllerProcEntry, &dac960_current_status_proc_fops, Controller);
 +	proc_create_single_data("initial_status", 0, ControllerProcEntry,
 +			dac960_initial_status_proc_show, Controller);
 +	proc_create_single_data("current_status", 0, ControllerProcEntry,
 +			dac960_current_status_proc_show, Controller);
- 	proc_create_data("user_command", S_IWUSR | S_IRUSR, ControllerProcEntry, &dac960_user_command_proc_fops, Controller);
+ 	proc_create_data("user_command", 0600, ControllerProcEntry, &dac960_user_command_proc_fops, Controller);
  	Controller->ControllerProcEntry = ControllerProcEntry;
  }
  

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

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

[Stephen Rothwell]

Hi all,

On Thu, 2 Feb 2017 13:44:07 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
> 
>   drivers/block/nbd.c
> 
> between commit:
> 
>   c9f2b6aeb922 ("[nbd] pass iov_iter to nbd_xmit()")
> 
> from the vfs tree and commit:
> 
>   09fc54ccc427 ("nbd: move request validity checking into nbd_send_cmd")
>   aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")
> 
> 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 drivers/block/nbd.c
> index 48132b0530fe,0be84a3cb6d7..000000000000
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@@ -265,17 -275,32 +262,32 @@@ static int nbd_send_cmd(struct nbd_devi
>   	u32 type;
>   	u32 tag = blk_mq_unique_tag(req);
>   
>  +	iov_iter_kvec(&from, WRITE | ITER_KVEC, &iov, 1, sizeof(request));
>  +
> - 	if (req_op(req) == REQ_OP_DISCARD)
> + 	switch (req_op(req)) {
> + 	case REQ_OP_DISCARD:
>   		type = NBD_CMD_TRIM;
> - 	else if (req_op(req) == REQ_OP_FLUSH)
> + 		break;
> + 	case REQ_OP_FLUSH:
>   		type = NBD_CMD_FLUSH;
> - 	else if (rq_data_dir(req) == WRITE)
> + 		break;
> + 	case REQ_OP_WRITE:
>   		type = NBD_CMD_WRITE;
> - 	else
> + 		break;
> + 	case REQ_OP_READ:
>   		type = NBD_CMD_READ;
> + 		break;
> + 	default:
> + 		return -EIO;
> + 	}
> + 
> + 	if (rq_data_dir(req) == WRITE &&
> + 	    (nbd->flags & NBD_FLAG_READ_ONLY)) {
> + 		dev_err_ratelimited(disk_to_dev(nbd->disk),
> + 				    "Write on read-only\n");
> + 		return -EIO;
> + 	}
>   
>  -	memset(&request, 0, sizeof(request));
>  -	request.magic = htonl(NBD_REQUEST_MAGIC);
>   	request.type = htonl(type);
>   	if (type != NBD_CMD_FLUSH) {
>   		request.from = cpu_to_be64((u64)blk_rq_pos(req) << 9);

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

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Jens,

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

  drivers/block/nbd.c

between commit:

  c9f2b6aeb922 ("[nbd] pass iov_iter to nbd_xmit()")

from the vfs tree and commit:

  09fc54ccc427 ("nbd: move request validity checking into nbd_send_cmd")
  aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space")

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 drivers/block/nbd.c
index 48132b0530fe,0be84a3cb6d7..000000000000
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@@ -265,17 -275,32 +262,32 @@@ static int nbd_send_cmd(struct nbd_devi
  	u32 type;
  	u32 tag = blk_mq_unique_tag(req);
  
 +	iov_iter_kvec(&from, WRITE | ITER_KVEC, &iov, 1, sizeof(request));
 +
- 	if (req_op(req) == REQ_OP_DISCARD)
+ 	switch (req_op(req)) {
+ 	case REQ_OP_DISCARD:
  		type = NBD_CMD_TRIM;
- 	else if (req_op(req) == REQ_OP_FLUSH)
+ 		break;
+ 	case REQ_OP_FLUSH:
  		type = NBD_CMD_FLUSH;
- 	else if (rq_data_dir(req) == WRITE)
+ 		break;
+ 	case REQ_OP_WRITE:
  		type = NBD_CMD_WRITE;
- 	else
+ 		break;
+ 	case REQ_OP_READ:
  		type = NBD_CMD_READ;
+ 		break;
+ 	default:
+ 		return -EIO;
+ 	}
+ 
+ 	if (rq_data_dir(req) == WRITE &&
+ 	    (nbd->flags & NBD_FLAG_READ_ONLY)) {
+ 		dev_err_ratelimited(disk_to_dev(nbd->disk),
+ 				    "Write on read-only\n");
+ 		return -EIO;
+ 	}
  
 -	memset(&request, 0, sizeof(request));
 -	request.magic = htonl(NBD_REQUEST_MAGIC);
  	request.type = htonl(type);
  	if (type != NBD_CMD_FLUSH) {
  		request.from = cpu_to_be64((u64)blk_rq_pos(req) << 9);

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

[Ming Lei]

On Mon, Dec 12, 2016 at 9:31 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in:
>
>   fs/logfs/dev_bdev.c
>
> between commit:
>
>   6b4fbde3b979 ("logfs: remove from tree")
>
> from the vfs tree and commitis:
>
>   3a83f4677539 ("block: bio: pass bvec table to bio_init()")
>   739a9975468c ("fs: logfs: convert to bio_add_page() in sync_request()")
>   d4f98a89f9cd ("fs: logfs: use bio_add_page() in __bdev_writeseg()")
>   c12484367865 ("fs: logfs: use bio_add_page() in do_erase()")
>   05aea81b4bc9 ("fs: logfs: remove unnecesary check")
>
> from the block tree.
>
> I fixed it up (I removed the file) 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.

Looks every time the logfs changes have been posted in fsdev mail list.

-- 
Ming Lei

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

[Al Viro]

On Mon, Dec 12, 2016 at 12:31:40PM +1100, Stephen Rothwell wrote:

> Al: that vfs tree commit has a bad email address for Christoph in it :-(

Gyah...  OK, will fix (the bulk of the diff, of course, had been regenerated
while commit message came from his old mail; unfortunately, it had been long
gone from my mailbox, so I'd picked it from archives and completely missed
the mangled address).

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

[Stephen Rothwell]

Hi Jens,

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

  fs/logfs/dev_bdev.c

between commit:

  6b4fbde3b979 ("logfs: remove from tree")

from the vfs tree and commitis:

  3a83f4677539 ("block: bio: pass bvec table to bio_init()")
  739a9975468c ("fs: logfs: convert to bio_add_page() in sync_request()")
  d4f98a89f9cd ("fs: logfs: use bio_add_page() in __bdev_writeseg()")
  c12484367865 ("fs: logfs: use bio_add_page() in do_erase()")
  05aea81b4bc9 ("fs: logfs: remove unnecesary check")

from the block tree.

I fixed it up (I removed the file) 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.

Al: that vfs tree commit has a bad email address for Christoph in it :-(

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
fs/configfs/configfs_internal.h between commit 22dc94f27d4b ("configfs:
configfs_create() init callback is never NULL and it never fails") from
the vfs tree and commit b4caecd48005 ("fs: introduce
f_op->mmap_capabilities for nommu mmap support") from the block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/configfs/configfs_internal.h
index 865e41983611,a315677e44d3..000000000000
--- a/fs/configfs/configfs_internal.h
+++ b/fs/configfs/configfs_internal.h
@@@ -69,9 -69,7 +69,7 @@@ extern struct kmem_cache *configfs_dir_
  extern int configfs_is_root(struct config_item *item);
  
  extern struct inode * configfs_new_inode(umode_t mode, struct configfs_dirent *, struct super_block *);
 -extern int configfs_create(struct dentry *, umode_t mode, int (*init)(struct inode *));
 +extern int configfs_create(struct dentry *, umode_t mode, void (*init)(struct inode *));
- extern int configfs_inode_init(void);
- extern void configfs_inode_exit(void);
  
  extern int configfs_create_file(struct config_item *, const struct configfs_attribute *);
  extern int configfs_make_dirent(struct configfs_dirent *,

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

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

[Christoph Hellwig]

On Sun, Feb 01, 2015 at 05:56:19AM +0000, Al Viro wrote:
> FWIW, there's an interesting question about the second commit in there -
> what do we want vfs_iter_{read,write}() to do with *iter in case if it
> has hit this:
>         if (ret == -EIOCBQUEUED)
>                 ret = wait_on_sync_kiocb(&kiocb);
> 
> Do we require ->read_iter() and ->write_iter() on sync kiocb to do all
> advancing the iter before returning -EIOCBQUEUED?  What's more, do we
> ever want to have it returned on sync kiocb?  IOW, is there any point
> in having that wait in callers?

See my "[RFC] split struct kiocb" series to sort out that mess.  For
now none of the callers relies on the iov_iter being advances, so until
then we can simply ignore that problem until then.

> I'm not sure if ep_io() and ep_aio_rwtail() + wait for completion are
> eqiuvalent; ep_read/ep_write are very easy to turn into sync side of
> ->read_iter/->write_iter and if that's equivalent to ep_aio_read/ep_aio_write
> on sync kiocb + waiting for completion, we are fine.

They are very similar, and yes thet should be moved to iter version of
the methods.  I actually started that but then ran into problems with
the aio core that needed addressing first.

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

[Al Viro]

On Thu, Jan 29, 2015 at 05:15:55AM +0000, Al Viro wrote:
> On Wed, Jan 28, 2015 at 06:11:02PM +0100, Christoph Hellwig wrote:
> > On Tue, Jan 27, 2015 at 04:54:22AM +0000, Al Viro wrote:
> > > I don't mind opening a never-rebased branch for generic iov_iter-related stuff;
> > > if you prefer to handle it that way - just tell.  The first two patches
> > > from that series would definitely go there; as for the rest... no preferences
> > > here.
> > 
> > It might make sense to just keep the VFS patches in your tree.
> > The target ones also are something I'd prefer if it goes through Nic
> > with additional review.  In addition they aren't really critical,
> > so if you merge the prep patches now we can feed the rest through
> > the proper trees in the .21 merge window.
> 
> Done.  The first two are in #iov_iter now (merged into #for-next), the
> rest is dropped.  And #iov_iter is in never-rebased mode, so feel free
> to pull it wherever you need it.

FWIW, there's an interesting question about the second commit in there -
what do we want vfs_iter_{read,write}() to do with *iter in case if it
has hit this:
        if (ret == -EIOCBQUEUED)
                ret = wait_on_sync_kiocb(&kiocb);

Do we require ->read_iter() and ->write_iter() on sync kiocb to do all
advancing the iter before returning -EIOCBQUEUED?  What's more, do we
ever want to have it returned on sync kiocb?  IOW, is there any point
in having that wait in callers?

Note that there are _very_ few drivers that ever do that; fs/direct_io.c,
for example, will wait for completion in case of sync kiocb.  AFAICS,
there are exactly two drivers like that: drivers/usb/gadget/legacy/inode.c
and drivers/usb/gadget/function/f_fs.c.  And the latter is very easy to
convert to "waits in case of sync kiocb" - there already are two codepaths
({read,write} and aio_{read,write}) and it's trivial to teach the sync
path to deal with arbitrary iov_iter, with aio side of things doing the
sync variant in case of sync kiocb.  Cheaper, as well, since we don't need
to copy iovec, etc.

I'm not sure if ep_io() and ep_aio_rwtail() + wait for completion are
eqiuvalent; ep_read/ep_write are very easy to turn into sync side of
->read_iter/->write_iter and if that's equivalent to ep_aio_read/ep_aio_write
on sync kiocb + waiting for completion, we are fine.

Comments?

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

[Al Viro]

On Wed, Jan 28, 2015 at 06:11:02PM +0100, Christoph Hellwig wrote:
> On Tue, Jan 27, 2015 at 04:54:22AM +0000, Al Viro wrote:
> > I don't mind opening a never-rebased branch for generic iov_iter-related stuff;
> > if you prefer to handle it that way - just tell.  The first two patches
> > from that series would definitely go there; as for the rest... no preferences
> > here.
> 
> It might make sense to just keep the VFS patches in your tree.
> The target ones also are something I'd prefer if it goes through Nic
> with additional review.  In addition they aren't really critical,
> so if you merge the prep patches now we can feed the rest through
> the proper trees in the .21 merge window.

Done.  The first two are in #iov_iter now (merged into #for-next), the
rest is dropped.  And #iov_iter is in never-rebased mode, so feel free
to pull it wherever you need it.

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

[Christoph Hellwig]

On Tue, Jan 27, 2015 at 04:54:22AM +0000, Al Viro wrote:
> I don't mind opening a never-rebased branch for generic iov_iter-related stuff;
> if you prefer to handle it that way - just tell.  The first two patches
> from that series would definitely go there; as for the rest... no preferences
> here.

It might make sense to just keep the VFS patches in your tree.
The target ones also are something I'd prefer if it goes through Nic
with additional review.  In addition they aren't really critical,
so if you merge the prep patches now we can feed the rest through
the proper trees in the .21 merge window.

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

[Al Viro]

On Mon, Jan 26, 2015 at 09:00:18PM -0700, Jens Axboe wrote:
> On 01/26/2015 08:57 PM, Stephen Rothwell wrote:
> >Hi Jens,
> >
> >Today's linux-next merge of the block tree got a conflict in
> >drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
> >vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
> >("block: loop: improve performance via blk-mq") and several others from
> >the block tree.
> >
> >I have no idea how fixed it up so I just used the version of the file
> >from the block tree (its been there a while).  Please have a chat and
> >figure out how to combine these two large changes.
> 
> Why isn't the loop patch in the block tree? That'd avoid such
> incidents. We could add a dependency for the required VFS patch.

I don't mind opening a never-rebased branch for generic iov_iter-related stuff;
if you prefer to handle it that way - just tell.  The first two patches
from that series would definitely go there; as for the rest... no preferences
here.

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

[Jens Axboe]

On 01/26/2015 08:57 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in
> drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
> vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
> ("block: loop: improve performance via blk-mq") and several others from
> the block tree.
>
> I have no idea how fixed it up so I just used the version of the file
> from the block tree (its been there a while).  Please have a chat and
> figure out how to combine these two large changes.

Why isn't the loop patch in the block tree? That'd avoid such incidents. 
We could add a dependency for the required VFS patch.


-- 
Jens Axboe

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

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
("block: loop: improve performance via blk-mq") and several others from
the block tree.

I have no idea how fixed it up so I just used the version of the file
from the block tree (its been there a while).  Please have a chat and
figure out how to combine these two large changes.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/block/drbd/drbd_proc.c between commit 4dfac87dca02 ("procfs: new
helper - PDE_DATA(inode)") from the vfs tree and commit 193d01532a73
("drbd: add module_put() on error path in drbd_proc_open()") from the
block tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/block/drbd/drbd_proc.c
index 928adb8,30fe0a5..0000000
--- a/drivers/block/drbd/drbd_proc.c
+++ b/drivers/block/drbd/drbd_proc.c
@@@ -313,8 -313,14 +313,14 @@@ static int drbd_seq_show(struct seq_fil
  
  static int drbd_proc_open(struct inode *inode, struct file *file)
  {
- 	if (try_module_get(THIS_MODULE))
- 		return single_open(file, drbd_seq_show, PDE_DATA(inode));
+ 	int err;
+ 
+ 	if (try_module_get(THIS_MODULE)) {
 -		err = single_open(file, drbd_seq_show, PDE(inode)->data);
++		err = single_open(file, drbd_seq_show, PDE_DATA(inode));
+ 		if (err)
+ 			module_put(THIS_MODULE);
+ 		return err;
+ 	}
  	return -ENODEV;
  }
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[H Hartley Sweeten]

On Monday, May 17, 2010 8:04 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in
> fs/fs-writeback.c between commit 1c9539ad0dd1c3c3964ea35d5a355a0ed19c39c7
> ("fs-writeback.c: bitfields should be unsigned") from the vfs tree and
> commit e913fc825dc685a444cb4c1d0f9d32f372f59861 ("writeback: fix
> WB_SYNC_NONE writeback from umount") from the block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc fs/fs-writeback.c
> index 24e85ce,0f62957..0000000
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@@ -42,9 -42,10 +42,10 @@@ struct wb_writeback_args 
>   	long nr_pages;
>   	struct super_block *sb;
>   	enum writeback_sync_modes sync_mode;
>  -	int for_kupdate:1;
>  -	int range_cyclic:1;
>  -	int for_background:1;
>  -	int sb_pinned:1;
>  +	unsigned int for_kupdate:1;
>  +	unsigned int range_cyclic:1;
>  +	unsigned int for_background:1;
> ++	unsigned int sb_pinned:1;
>   };
>   
>   /*

Stephen,

Your fix looks good to me.

Regards,
Hartley

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

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
fs/fs-writeback.c between commit 1c9539ad0dd1c3c3964ea35d5a355a0ed19c39c7
("fs-writeback.c: bitfields should be unsigned") from the vfs tree and
commit e913fc825dc685a444cb4c1d0f9d32f372f59861 ("writeback: fix
WB_SYNC_NONE writeback from umount") from the block tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/fs-writeback.c
index 24e85ce,0f62957..0000000
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@@ -42,9 -42,10 +42,10 @@@ struct wb_writeback_args 
  	long nr_pages;
  	struct super_block *sb;
  	enum writeback_sync_modes sync_mode;
 -	int for_kupdate:1;
 -	int range_cyclic:1;
 -	int for_background:1;
 -	int sb_pinned:1;
 +	unsigned int for_kupdate:1;
 +	unsigned int range_cyclic:1;
 +	unsigned int for_background:1;
++	unsigned int sb_pinned:1;
  };
  
  /*