LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* linux-next: manual merge of the block tree with the vfs tree
@ 2015-01-27  3:57 Stephen Rothwell
  2015-01-27  4:00 ` Jens Axboe
  0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2015-01-27  3:57 UTC (permalink / raw)
  To: Jens Axboe, Al Viro; +Cc: linux-next, linux-kernel, Christoph Hellwig, Ming Lei

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2015-01-27  3:57 linux-next: manual merge of the block tree with the vfs tree Stephen Rothwell
@ 2015-01-27  4:00 ` Jens Axboe
  2015-01-27  4:54   ` Al Viro
  0 siblings, 1 reply; 31+ messages in thread
From: Jens Axboe @ 2015-01-27  4:00 UTC (permalink / raw)
  To: Stephen Rothwell, Al Viro
  Cc: linux-next, linux-kernel, Christoph Hellwig, Ming Lei

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


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2015-01-27  4:00 ` Jens Axboe
@ 2015-01-27  4:54   ` Al Viro
  2015-01-28 17:11     ` Christoph Hellwig
  0 siblings, 1 reply; 31+ messages in thread
From: Al Viro @ 2015-01-27  4:54 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Stephen Rothwell, linux-next, linux-kernel, Christoph Hellwig, Ming Lei

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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2015-01-27  4:54   ` Al Viro
@ 2015-01-28 17:11     ` Christoph Hellwig
  2015-01-29  5:15       ` Al Viro
  0 siblings, 1 reply; 31+ messages in thread
From: Christoph Hellwig @ 2015-01-28 17:11 UTC (permalink / raw)
  To: Al Viro
  Cc: Jens Axboe, Stephen Rothwell, linux-next, linux-kernel,
	Christoph Hellwig, Ming Lei

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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2015-01-28 17:11     ` Christoph Hellwig
@ 2015-01-29  5:15       ` Al Viro
  2015-02-01  5:56         ` Al Viro
  0 siblings, 1 reply; 31+ messages in thread
From: Al Viro @ 2015-01-29  5:15 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Stephen Rothwell, linux-next, linux-kernel, Ming Lei

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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2015-01-29  5:15       ` Al Viro
@ 2015-02-01  5:56         ` Al Viro
  2015-02-02  8:06           ` Christoph Hellwig
  0 siblings, 1 reply; 31+ messages in thread
From: Al Viro @ 2015-02-01  5:56 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Stephen Rothwell, linux-next, linux-kernel, Ming Lei

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?

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2015-02-01  5:56         ` Al Viro
@ 2015-02-02  8:06           ` Christoph Hellwig
  0 siblings, 0 replies; 31+ messages in thread
From: Christoph Hellwig @ 2015-02-02  8:06 UTC (permalink / raw)
  To: Al Viro
  Cc: Christoph Hellwig, Jens Axboe, Stephen Rothwell, linux-next,
	linux-kernel, Ming Lei

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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2022-05-23  2:28 Stephen Rothwell
  2022-05-23  2:58 ` Jens Axboe
@ 2022-05-23 22:54 ` Stephen Rothwell
  1 sibling, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2022-05-23 22:54 UTC (permalink / raw)
  To: Al Viro
  Cc: Jens Axboe, Dylan Yudaken, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2022-05-23  2:28 Stephen Rothwell
@ 2022-05-23  2:58 ` Jens Axboe
  2022-05-23 22:54 ` Stephen Rothwell
  1 sibling, 0 replies; 31+ messages in thread
From: Jens Axboe @ 2022-05-23  2:58 UTC (permalink / raw)
  To: Stephen Rothwell, Al Viro
  Cc: Dylan Yudaken, Linux Kernel Mailing List, Linux Next Mailing List

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


^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2022-05-23  2:28 Stephen Rothwell
  2022-05-23  2:58 ` Jens Axboe
  2022-05-23 22:54 ` Stephen Rothwell
  0 siblings, 2 replies; 31+ messages in thread
From: Stephen Rothwell @ 2022-05-23  2:28 UTC (permalink / raw)
  To: Jens Axboe, Al Viro
  Cc: Dylan Yudaken, Linux Kernel Mailing List, Linux Next Mailing List

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2021-01-27  3:24 Stephen Rothwell
  0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2021-01-27  3:24 UTC (permalink / raw)
  To: Jens Axboe, Al Viro
  Cc: Eric Biggers, Linux Kernel Mailing List, Linux Next Mailing List,
	Pavel Begunkov

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2020-01-20  2:45     ` Jens Axboe
@ 2020-01-20  2:57       ` Jens Axboe
  0 siblings, 0 replies; 31+ messages in thread
From: Jens Axboe @ 2020-01-20  2:57 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List,
	Aleksa Sarai

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


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2020-01-20  1:40   ` Stephen Rothwell
@ 2020-01-20  2:45     ` Jens Axboe
  2020-01-20  2:57       ` Jens Axboe
  0 siblings, 1 reply; 31+ messages in thread
From: Jens Axboe @ 2020-01-20  2:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List,
	Aleksa Sarai

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


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2019-12-20  5:34 ` Jens Axboe
@ 2020-01-20  1:40   ` Stephen Rothwell
  2020-01-20  2:45     ` Jens Axboe
  0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2020-01-20  1:40 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Al Viro, Linux Next Mailing List, Linux Kernel Mailing List,
	Aleksa Sarai

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2019-12-20  1:36 Stephen Rothwell
@ 2019-12-20  5:34 ` Jens Axboe
  2020-01-20  1:40   ` Stephen Rothwell
  0 siblings, 1 reply; 31+ messages in thread
From: Jens Axboe @ 2019-12-20  5:34 UTC (permalink / raw)
  To: Stephen Rothwell, Al Viro
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Aleksa Sarai

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


^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2019-12-20  1:36 Stephen Rothwell
  2019-12-20  5:34 ` Jens Axboe
  0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2019-12-20  1:36 UTC (permalink / raw)
  To: Jens Axboe, Al Viro
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Aleksa Sarai

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2018-05-29 21:40     ` Stephen Rothwell
@ 2018-05-29 22:17       ` Jens Axboe
  0 siblings, 0 replies; 31+ messages in thread
From: Jens Axboe @ 2018-05-29 22:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoph Hellwig, Al Viro, Linux-Next Mailing List,
	Linux Kernel Mailing List, Joe Perches

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2018-05-29 14:22   ` Jens Axboe
@ 2018-05-29 21:40     ` Stephen Rothwell
  2018-05-29 22:17       ` Jens Axboe
  0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2018-05-29 21:40 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Christoph Hellwig, Al Viro, Linux-Next Mailing List,
	Linux Kernel Mailing List, Joe Perches

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2018-05-29  8:12 ` Christoph Hellwig
@ 2018-05-29 14:22   ` Jens Axboe
  2018-05-29 21:40     ` Stephen Rothwell
  0 siblings, 1 reply; 31+ messages in thread
From: Jens Axboe @ 2018-05-29 14:22 UTC (permalink / raw)
  To: Christoph Hellwig, Stephen Rothwell
  Cc: Al Viro, Linux-Next Mailing List, Linux Kernel Mailing List, Joe Perches

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2018-05-29  4:33 Stephen Rothwell
@ 2018-05-29  8:12 ` Christoph Hellwig
  2018-05-29 14:22   ` Jens Axboe
  0 siblings, 1 reply; 31+ messages in thread
From: Christoph Hellwig @ 2018-05-29  8:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Al Viro, Linux-Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, Joe Perches

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---

^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2018-05-29  4:37 Stephen Rothwell
  0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2018-05-29  4:37 UTC (permalink / raw)
  To: Jens Axboe, Al Viro
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Joe Perches,
	Christoph Hellwig

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2018-05-29  4:33 Stephen Rothwell
  2018-05-29  8:12 ` Christoph Hellwig
  0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2018-05-29  4:33 UTC (permalink / raw)
  To: Jens Axboe, Al Viro
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Joe Perches

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2017-02-02  2:44 Stephen Rothwell
@ 2017-02-21 22:14 ` Stephen Rothwell
  0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2017-02-21 22:14 UTC (permalink / raw)
  To: Jens Axboe, Al Viro; +Cc: linux-next, linux-kernel, Christoph Hellwig

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2017-02-02  2:44 Stephen Rothwell
  2017-02-21 22:14 ` Stephen Rothwell
  0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2017-02-02  2:44 UTC (permalink / raw)
  To: Jens Axboe, Al Viro; +Cc: linux-next, linux-kernel, Christoph Hellwig

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);

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2016-12-12  1:31 Stephen Rothwell
  2016-12-12  1:44 ` Al Viro
@ 2016-12-12  2:00 ` Ming Lei
  1 sibling, 0 replies; 31+ messages in thread
From: Ming Lei @ 2016-12-12  2:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Al Viro, linux-next, Linux Kernel Mailing List,
	Christoph Hellwig

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: linux-next: manual merge of the block tree with the vfs tree
  2016-12-12  1:31 Stephen Rothwell
@ 2016-12-12  1:44 ` Al Viro
  2016-12-12  2:00 ` Ming Lei
  1 sibling, 0 replies; 31+ messages in thread
From: Al Viro @ 2016-12-12  1:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, linux-next, linux-kernel, Ming Lei, Christoph Hellwig

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).

^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2016-12-12  1:31 Stephen Rothwell
  2016-12-12  1:44 ` Al Viro
  2016-12-12  2:00 ` Ming Lei
  0 siblings, 2 replies; 31+ messages in thread
From: Stephen Rothwell @ 2016-12-12  1:31 UTC (permalink / raw)
  To: Jens Axboe, Al Viro; +Cc: linux-next, linux-kernel, Ming Lei, Christoph Hellwig

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2015-02-09  3:55 Stephen Rothwell
  0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2015-02-09  3:55 UTC (permalink / raw)
  To: Jens Axboe, Al Viro; +Cc: linux-next, linux-kernel, Christoph Hellwig

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2013-04-04  2:16 Stephen Rothwell
  0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2013-04-04  2:16 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Al Viro, Alexey Khoroshilov,
	Philipp Reisner, Lars Ellenberg

[-- 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 --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* RE: linux-next: manual merge of the block tree with the vfs tree
  2010-05-18  3:04 Stephen Rothwell
@ 2010-05-18 15:37 ` H Hartley Sweeten
  0 siblings, 0 replies; 31+ messages in thread
From: H Hartley Sweeten @ 2010-05-18 15:37 UTC (permalink / raw)
  To: Stephen Rothwell, Jens Axboe; +Cc: linux-next, linux-kernel, Al Viro

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* linux-next: manual merge of the block tree with the vfs tree
@ 2010-05-18  3:04 Stephen Rothwell
  2010-05-18 15:37 ` H Hartley Sweeten
  0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2010-05-18  3:04 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, H Hartley Sweeten, Al Viro

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;
  };
  
  /*

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2022-05-23 22:54 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-27  3:57 linux-next: manual merge of the block tree with the vfs tree Stephen Rothwell
2015-01-27  4:00 ` Jens Axboe
2015-01-27  4:54   ` Al Viro
2015-01-28 17:11     ` Christoph Hellwig
2015-01-29  5:15       ` Al Viro
2015-02-01  5:56         ` Al Viro
2015-02-02  8:06           ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2022-05-23  2:28 Stephen Rothwell
2022-05-23  2:58 ` Jens Axboe
2022-05-23 22:54 ` Stephen Rothwell
2021-01-27  3:24 Stephen Rothwell
2019-12-20  1:36 Stephen Rothwell
2019-12-20  5:34 ` Jens Axboe
2020-01-20  1:40   ` Stephen Rothwell
2020-01-20  2:45     ` Jens Axboe
2020-01-20  2:57       ` Jens Axboe
2018-05-29  4:37 Stephen Rothwell
2018-05-29  4:33 Stephen Rothwell
2018-05-29  8:12 ` Christoph Hellwig
2018-05-29 14:22   ` Jens Axboe
2018-05-29 21:40     ` Stephen Rothwell
2018-05-29 22:17       ` Jens Axboe
2017-02-02  2:44 Stephen Rothwell
2017-02-21 22:14 ` Stephen Rothwell
2016-12-12  1:31 Stephen Rothwell
2016-12-12  1:44 ` Al Viro
2016-12-12  2:00 ` Ming Lei
2015-02-09  3:55 Stephen Rothwell
2013-04-04  2:16 Stephen Rothwell
2010-05-18  3:04 Stephen Rothwell
2010-05-18 15:37 ` H Hartley Sweeten

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).