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 [email protected]
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;
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?
[Replacing Jens' Oracle address ...]
Hi Christoph,
On Tue, 1 Jun 2010 04:18:23 -0400 Christoph Hellwig <[email protected]> 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 [email protected]
http://www.canb.auug.org.au/~sfr/
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
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 <[email protected]> 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
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.
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
Hi Jens,
On Tue, 1 Jun 2010 10:31:26 +0200 Jens Axboe <[email protected]> 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 [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, Jun 01 2010, Stephen Rothwell wrote:
> Hi Jens,
>
> On Tue, 1 Jun 2010 10:31:26 +0200 Jens Axboe <[email protected]> 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 [email protected] goes directly here so
just use that.
--
Jens Axboe
Hi Jens,
On Tue, 1 Jun 2010 10:53:11 +0200 Jens Axboe <[email protected]> wrote:
>
> Either one will work fine, but [email protected] goes directly here so
> just use that.
OK, thanks
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
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 <[email protected]> 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
HI Jens,
On Tue, 1 Jun 2010 12:45:15 +0200 Jens Axboe <[email protected]> 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 [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, Jun 01 2010, Stephen Rothwell wrote:
> HI Jens,
>
> On Tue, 1 Jun 2010 12:45:15 +0200 Jens Axboe <[email protected]> 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