linux-next: manual merge of the drbd tree with Linus' tree

linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
mutex_unlock") from Linus' tree and commits
0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.

I fixed it up (see below) and can carry the fix for a while.
-- 
Cheers,
Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org

diff --cc fs/pipe.c
index db6eaab,bdd3f96..0000000
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@@ -1174,23 -1162,30 +1168,34 @@@ long pipe_fcntl(struct file *file, unsi
  	mutex_lock(&pipe->inode->i_mutex);
  
  	switch (cmd) {
- 	case F_SETPIPE_SZ:
- 		if (!capable(CAP_SYS_ADMIN) && arg > pipe_max_pages) {
- 			ret = -EINVAL;
+ 	case F_SETPIPE_SZ: {
+ 		unsigned long nr_pages;
+ 
+ 		/*
+ 		 * Currently the array must be a power-of-2 size, so adjust
+ 		 * upwards if needed.
+ 		 */
+ 		nr_pages = (arg + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ 		nr_pages = roundup_pow_of_two(nr_pages);
+ 
 -		if (!capable(CAP_SYS_ADMIN) && nr_pages > pipe_max_pages)
 -			return -EPERM;
++		if (!capable(CAP_SYS_ADMIN) && nr_pages > pipe_max_pages) {
++			ret = -EPERM;
 +			goto out;
 +		}
+ 
  		/*
  		 * The pipe needs to be at least 2 pages large to
  		 * guarantee POSIX behaviour.
  		 */
- 		if (arg < 2) {
 -		if (nr_pages < 2)
 -			return -EINVAL;
++		if (nr_pages < 2) {
 +			ret = -EINVAL;
 +			goto out;
 +		}
- 		ret = pipe_set_size(pipe, arg);
+ 		ret = pipe_set_size(pipe, nr_pages);
  		break;
+ 		}
  	case F_GETPIPE_SZ:
- 		ret = pipe->buffers;
+ 		ret = pipe->buffers * PAGE_SIZE;
  		break;
  	default:
  		ret = -EINVAL;

linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
mutex_unlock") from Linus' tree and commits
0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.

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

diff --cc fs/pipe.c
index db6eaab,bdd3f96..0000000
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@@ -1174,23 -1162,30 +1168,34 @@@ long pipe_fcntl(struct file *file, unsi
  	mutex_lock(&pipe->inode->i_mutex);
  
  	switch (cmd) {
- 	case F_SETPIPE_SZ:
- 		if (!capable(CAP_SYS_ADMIN) && arg > pipe_max_pages) {
- 			ret = -EINVAL;
+ 	case F_SETPIPE_SZ: {
+ 		unsigned long nr_pages;
+ 
+ 		/*
+ 		 * Currently the array must be a power-of-2 size, so adjust
+ 		 * upwards if needed.
+ 		 */
+ 		nr_pages = (arg + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ 		nr_pages = roundup_pow_of_two(nr_pages);
+ 
 -		if (!capable(CAP_SYS_ADMIN) && nr_pages > pipe_max_pages)
 -			return -EPERM;
++		if (!capable(CAP_SYS_ADMIN) && nr_pages > pipe_max_pages) {
++			ret = -EPERM;
 +			goto out;
 +		}
+ 
  		/*
  		 * The pipe needs to be at least 2 pages large to
  		 * guarantee POSIX behaviour.
  		 */
- 		if (arg < 2) {
 -		if (nr_pages < 2)
 -			return -EINVAL;
++		if (nr_pages < 2) {
 +			ret = -EINVAL;
 +			goto out;
 +		}
- 		ret = pipe_set_size(pipe, arg);
+ 		ret = pipe_set_size(pipe, nr_pages);
  		break;
+ 		}
  	case F_GETPIPE_SZ:
- 		ret = pipe->buffers;
+ 		ret = pipe->buffers * PAGE_SIZE;
  		break;
  	default:
  		ret = -EINVAL;

[Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
mutex_unlock") from Linus' tree and commits
0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.

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

diff --cc fs/pipe.c
index db6eaab,bdd3f96..0000000
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@@ -1174,23 -1162,30 +1168,34 @@@ long pipe_fcntl(struct file *file, unsi
  	mutex_lock(&pipe->inode->i_mutex);
  
  	switch (cmd) {
- 	case F_SETPIPE_SZ:
- 		if (!capable(CAP_SYS_ADMIN) && arg > pipe_max_pages) {
- 			ret = -EINVAL;
+ 	case F_SETPIPE_SZ: {
+ 		unsigned long nr_pages;
+ 
+ 		/*
+ 		 * Currently the array must be a power-of-2 size, so adjust
+ 		 * upwards if needed.
+ 		 */
+ 		nr_pages = (arg + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ 		nr_pages = roundup_pow_of_two(nr_pages);
+ 
 -		if (!capable(CAP_SYS_ADMIN) && nr_pages > pipe_max_pages)
 -			return -EPERM;
++		if (!capable(CAP_SYS_ADMIN) && nr_pages > pipe_max_pages) {
++			ret = -EPERM;
 +			goto out;
 +		}
+ 
  		/*
  		 * The pipe needs to be at least 2 pages large to
  		 * guarantee POSIX behaviour.
  		 */
- 		if (arg < 2) {
 -		if (nr_pages < 2)
 -			return -EINVAL;
++		if (nr_pages < 2) {
 +			ret = -EINVAL;
 +			goto out;
 +		}
- 		ret = pipe_set_size(pipe, arg);
+ 		ret = pipe_set_size(pipe, nr_pages);
  		break;
+ 		}
  	case F_GETPIPE_SZ:
- 		ret = pipe->buffers;
+ 		ret = pipe->buffers * PAGE_SIZE;
  		break;
  	default:
  		ret = -EINVAL;

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Christoph Hellwig]

On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> mutex_unlock") from Linus' tree and commits
> 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> 
> I fixed it up (see below) and can carry the fix for a while.

Why is the drbd tree touching fs/pipe.c anyway?

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Christoph Hellwig]

On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> mutex_unlock") from Linus' tree and commits
> 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> 
> I fixed it up (see below) and can carry the fix for a while.

Why is the drbd tree touching fs/pipe.c anyway?

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 1104 bytes --]

[Replacing Jens' Oracle address ...]

Hi Christoph,

On Tue, 1 Jun 2010 04:18:23 -0400 Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>
> On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > mutex_unlock") from Linus' tree and commits
> > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > 
> > I fixed it up (see below) and can carry the fix for a while.
> 
> Why is the drbd tree touching fs/pipe.c anyway?

It is based on the block tree.  I assume that it is currently based on a
version of the block tree that Jens has not yet pushed into
linux-next.  :-(

-- 
Cheers,
Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
http://www.canb.auug.org.au/~sfr/

[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
drbd-dev mailing list
drbd-dev-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org
http://lists.linbit.com/mailman/listinfo/drbd-dev

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

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

[Replacing Jens' Oracle address ...]

Hi Christoph,

On Tue, 1 Jun 2010 04:18:23 -0400 Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > mutex_unlock") from Linus' tree and commits
> > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > 
> > I fixed it up (see below) and can carry the fix for a while.
> 
> Why is the drbd tree touching fs/pipe.c anyway?

It is based on the block tree.  I assume that it is currently based on a
version of the block tree that Jens has not yet pushed into
linux-next.  :-(

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

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

[Replacing Jens' Oracle address ...]

Hi Christoph,

On Tue, 1 Jun 2010 04:18:23 -0400 Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > mutex_unlock") from Linus' tree and commits
> > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > 
> > I fixed it up (see below) and can carry the fix for a while.
> 
> Why is the drbd tree touching fs/pipe.c anyway?

It is based on the block tree.  I assume that it is currently based on a
version of the block tree that Jens has not yet pushed into
linux-next.  :-(

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Stephen Rothwell wrote:
> [Replacing Jens' Oracle address ...]
> 
> Hi Christoph,
> 
> On Tue, 1 Jun 2010 04:18:23 -0400 Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > > mutex_unlock") from Linus' tree and commits
> > > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > > 
> > > I fixed it up (see below) and can carry the fix for a while.
> > 
> > Why is the drbd tree touching fs/pipe.c anyway?
> 
> It is based on the block tree.  I assume that it is currently based on a
> version of the block tree that Jens has not yet pushed into
> linux-next.  :-(

Just checked, and it is indeed for-next that is behind... Will update
it.

-- 
Jens Axboe

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Stephen Rothwell wrote:
> [Replacing Jens' Oracle address ...]
> 
> Hi Christoph,
> 
> On Tue, 1 Jun 2010 04:18:23 -0400 Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > > mutex_unlock") from Linus' tree and commits
> > > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > > 
> > > I fixed it up (see below) and can carry the fix for a while.
> > 
> > Why is the drbd tree touching fs/pipe.c anyway?
> 
> It is based on the block tree.  I assume that it is currently based on a
> version of the block tree that Jens has not yet pushed into
> linux-next.  :-(

Just checked, and it is indeed for-next that is behind... Will update
it.

-- 
Jens Axboe

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

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

Hi Jens,

On Tue, 1 Jun 2010 10:31:26 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
>
> Just checked, and it is indeed for-next that is behind... Will update
> it.

Thanks.

BTW, what email address should I now use for you?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

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

Hi Jens,

On Tue, 1 Jun 2010 10:31:26 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
>
> Just checked, and it is indeed for-next that is behind... Will update
> it.

Thanks.

BTW, what email address should I now use for you?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Tue, 1 Jun 2010 10:31:26 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
> >
> > Just checked, and it is indeed for-next that is behind... Will update
> > it.
> 
> Thanks.
> 
> BTW, what email address should I now use for you?

Either one will work fine, but axboe@kernel.dk goes directly here so
just use that.

-- 
Jens Axboe

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Tue, 1 Jun 2010 10:31:26 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
> >
> > Just checked, and it is indeed for-next that is behind... Will update
> > it.
> 
> Thanks.
> 
> BTW, what email address should I now use for you?

Either one will work fine, but axboe@kernel.dk goes directly here so
just use that.

-- 
Jens Axboe

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

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

Hi Jens,

On Tue, 1 Jun 2010 10:53:11 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
>
> Either one will work fine, but axboe@kernel.dk goes directly here so
> just use that.

OK, thanks

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

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

Hi Jens,

On Tue, 1 Jun 2010 10:53:11 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
>
> Either one will work fine, but axboe@kernel.dk goes directly here so
> just use that.

OK, thanks

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Stephen Rothwell wrote:
> [Replacing Jens' Oracle address ...]
> 
> Hi Christoph,
> 
> On Tue, 1 Jun 2010 04:18:23 -0400 Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > > mutex_unlock") from Linus' tree and commits
> > > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > > 
> > > I fixed it up (see below) and can carry the fix for a while.
> > 
> > Why is the drbd tree touching fs/pipe.c anyway?
> 
> It is based on the block tree.  I assume that it is currently based on a
> version of the block tree that Jens has not yet pushed into
> linux-next.  :-(

So the pipe patches were the same, the problem was that a fix for a
missing pipe_unlock() had gone into mainline and for-linus/for-next
weren't synced up to that. I'm guessing you pull drbd before for-next
and that is why it showed up there.

BTW, I would recommend moving for-next from the block tree up before any
potential other trees being based off it if that is the case.

-- 
Jens Axboe

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Stephen Rothwell wrote:
> [Replacing Jens' Oracle address ...]
> 
> Hi Christoph,
> 
> On Tue, 1 Jun 2010 04:18:23 -0400 Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > > mutex_unlock") from Linus' tree and commits
> > > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > > 
> > > I fixed it up (see below) and can carry the fix for a while.
> > 
> > Why is the drbd tree touching fs/pipe.c anyway?
> 
> It is based on the block tree.  I assume that it is currently based on a
> version of the block tree that Jens has not yet pushed into
> linux-next.  :-(

So the pipe patches were the same, the problem was that a fix for a
missing pipe_unlock() had gone into mainline and for-linus/for-next
weren't synced up to that. I'm guessing you pull drbd before for-next
and that is why it showed up there.

BTW, I would recommend moving for-next from the block tree up before any
potential other trees being based off it if that is the case.

-- 
Jens Axboe

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

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

HI Jens,

On Tue, 1 Jun 2010 12:45:15 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
>
> So the pipe patches were the same, the problem was that a fix for a
> missing pipe_unlock() had gone into mainline and for-linus/for-next
> weren't synced up to that. I'm guessing you pull drbd before for-next
> and that is why it showed up there.

Actually, I merge the drbd tree after the block tree and this fell to the
drbd tree only because your for-next branch had not been updated (and I
don't merge your for-linus branch).

> BTW, I would recommend moving for-next from the block tree up before any
> potential other trees being based off it if that is the case.

That is already true.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Stephen Rothwell]

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

HI Jens,

On Tue, 1 Jun 2010 12:45:15 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
>
> So the pipe patches were the same, the problem was that a fix for a
> missing pipe_unlock() had gone into mainline and for-linus/for-next
> weren't synced up to that. I'm guessing you pull drbd before for-next
> and that is why it showed up there.

Actually, I merge the drbd tree after the block tree and this fell to the
drbd tree only because your for-next branch had not been updated (and I
don't merge your for-linus branch).

> BTW, I would recommend moving for-next from the block tree up before any
> potential other trees being based off it if that is the case.

That is already true.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Stephen Rothwell wrote:
> HI Jens,
> 
> On Tue, 1 Jun 2010 12:45:15 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
> >
> > So the pipe patches were the same, the problem was that a fix for a
> > missing pipe_unlock() had gone into mainline and for-linus/for-next
> > weren't synced up to that. I'm guessing you pull drbd before for-next
> > and that is why it showed up there.
> 
> Actually, I merge the drbd tree after the block tree and this fell to the
> drbd tree only because your for-next branch had not been updated (and I
> don't merge your for-linus branch).

Ah I see, then it all adds up.

> > BTW, I would recommend moving for-next from the block tree up before any
> > potential other trees being based off it if that is the case.
> 
> That is already true.

Good!

-- 
Jens Axboe

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Stephen Rothwell wrote:
> HI Jens,
> 
> On Tue, 1 Jun 2010 12:45:15 +0200 Jens Axboe <jaxboe@fusionio.com> wrote:
> >
> > So the pipe patches were the same, the problem was that a fix for a
> > missing pipe_unlock() had gone into mainline and for-linus/for-next
> > weren't synced up to that. I'm guessing you pull drbd before for-next
> > and that is why it showed up there.
> 
> Actually, I merge the drbd tree after the block tree and this fell to the
> drbd tree only because your for-next branch had not been updated (and I
> don't merge your for-linus branch).

Ah I see, then it all adds up.

> > BTW, I would recommend moving for-next from the block tree up before any
> > potential other trees being based off it if that is the case.
> 
> That is already true.

Good!

-- 
Jens Axboe

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Christoph Hellwig wrote:
> On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > mutex_unlock") from Linus' tree and commits
> > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > 
> > I fixed it up (see below) and can carry the fix for a while.
> 
> Why is the drbd tree touching fs/pipe.c anyway?

A quick guess would be that it's based off for-linus in the block tree,
which has a patch or two in that area. Why it would conflict and simply
not note that it's the same change, perhaps a rebase or something? Not
sure.

-- 
Jens Axboe

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Christoph Hellwig wrote:
> On Tue, Jun 01, 2010 at 02:13:24PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drbd tree got a conflict in fs/pipe.c
> > between commit cc967be54710d97c05229b2e5ba2d00df84ddd64 ("fs: Add missing
> > mutex_unlock") from Linus' tree and commits
> > 0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b ("pipe: F_SETPIPE_SZ should
> > return -EPERM for non-root") and b9598db3401282bb27b4aef77e3eee12015f7f29
> > ("pipe: make F_{GET,SET}PIPE_SZ deal with byte sizes") from the drbd tree.
> > 
> > I fixed it up (see below) and can carry the fix for a while.
> 
> Why is the drbd tree touching fs/pipe.c anyway?

A quick guess would be that it's based off for-linus in the block tree,
which has a patch or two in that area. Why it would conflict and simply
not note that it's the same change, perhaps a rebase or something? Not
sure.

-- 
Jens Axboe

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Christoph Hellwig]

Talking about the block tree: can we please get the two writeback
reverts in?  -rc1 is copletly unsuable under heavy I/O loads as it
stands.

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Christoph Hellwig]

Talking about the block tree: can we please get the two writeback
reverts in?  -rc1 is copletly unsuable under heavy I/O loads as it
stands.

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Christoph Hellwig]

Talking about the block tree: can we please get the two writeback
reverts in?  -rc1 is copletly unsuable under heavy I/O loads as it
stands.

Re: linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Christoph Hellwig wrote:
> Talking about the block tree: can we please get the two writeback
> reverts in?  -rc1 is copletly unsuable under heavy I/O loads as it
> stands.

Yes, it'll go out today, it was supposed to land in -rc1 :/

-- 
Jens Axboe

Re: [Drbd-dev] linux-next: manual merge of the drbd tree with Linus' tree

[Jens Axboe]

On Tue, Jun 01 2010, Christoph Hellwig wrote:
> Talking about the block tree: can we please get the two writeback
> reverts in?  -rc1 is copletly unsuable under heavy I/O loads as it
> stands.

Yes, it'll go out today, it was supposed to land in -rc1 :/

-- 
Jens Axboe