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

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

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

On 5/29/18 3:40 PM, Stephen Rothwell wrote: > Hi Jens, > > On Tue, 29 May 2018 08:22:43 -0600 Jens Axboe 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

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

On 5/29/18 3:40 PM, Stephen Rothwell wrote: > Hi Jens, > > On Tue, 29 May 2018 08:22:43 -0600 Jens Axboe 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

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

Hi Jens, On Tue, 29 May 2018 08:22:43 -0600 Jens Axboe 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

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

Hi Jens, On Tue, 29 May 2018 08:22:43 -0600 Jens Axboe 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

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

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

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

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

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

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

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

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: manual merge of the block tree with the vfs tree

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

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

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

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

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

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

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

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

Hi all, On Thu, 2 Feb 2017 13:44:07 +1100 Stephen Rothwell 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:

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

Hi all, On Thu, 2 Feb 2017 13:44:07 +1100 Stephen Rothwell 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

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

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:

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

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:

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

On Mon, Dec 12, 2016 at 9:31 AM, Stephen Rothwell 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: > >

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

On Mon, Dec 12, 2016 at 9:31 AM, Stephen Rothwell 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

On Sun, Feb 01, 2015 at 05:56:19AM +, 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 =

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

On Sun, Feb 01, 2015 at 05:56:19AM +, 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 =

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

On Thu, Jan 29, 2015 at 05:15:55AM +, 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 +, Al Viro wrote: > > > I don't mind opening a never-rebased branch for generic iov_iter-related > > > stuff; > > > if you

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

On Thu, Jan 29, 2015 at 05:15:55AM +, 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 +, Al Viro wrote: I don't mind opening a never-rebased branch for generic iov_iter-related stuff; if you prefer to handle

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

On Wed, Jan 28, 2015 at 06:11:02PM +0100, Christoph Hellwig wrote: > On Tue, Jan 27, 2015 at 04:54:22AM +, 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 > >

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

On Tue, Jan 27, 2015 at 04:54:22AM +, 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 >

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

On Tue, Jan 27, 2015 at 04:54:22AM +, 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.

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

On Wed, Jan 28, 2015 at 06:11:02PM +0100, Christoph Hellwig wrote: On Tue, Jan 27, 2015 at 04:54:22AM +, 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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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