linux-next: block tree build failure

linux-next: block tree build failure

[Stephen Rothwell]

Hi Jens,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

drivers/md/dm.c: In function 'dm_merge_bvec':
drivers/md/dm.c:976: error: 'struct request_queue' has no member named 'max_hw_sectors'

Caused by commit 025146e13b63483add912706c101fb0fb6f015cc ("block: Move
queue limits to an embedded struct") from the block tree interacting with
commit c8f4b88baca86491a6125cf9373a75e04b22ff8b
("dm-avoid-unsupported-spanning-of-md-stripe-boundaries") from the
device-mapper tree.

Another sudden API change ...

The correct way:
	add new accessor implemented in terms of old API that is a noop
	push that to Linus
	fixup all the references to the old API (telling the users)
	wait for other users (if any) to use new accessor
	remove old API

We have done this several times ...  Linus is will to take the "add new
accessor" patches basically any time.

So I added this patch:

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 7b939fa..ea9a9e6 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -973,7 +973,7 @@ static int dm_merge_bvec(struct request_queue *q,
 	 * entries.  So always set max_size to 0, and the code below allows
 	 * just one page.
 	 */
-	else if (q->max_hw_sectors <= PAGE_SIZE >> 9)
+	else if (queue_max_hw_sectors(q) <= PAGE_SIZE >> 9)
 		max_size = 0;
 
 out_table:

But now I get:

drivers/md/dm-table.c: In function 'device_area_is_valid':
drivers/md/dm-table.c:390: error: 'struct io_restrictions' has no member named 'hardsect_size'
drivers/md/dm-table.c:414: error: 'struct io_restrictions' has no member named 'hardsect_size'
drivers/md/dm-table.c: In function 'validate_hardsect_alignment':
drivers/md/dm-table.c:738: error: 'struct io_restrictions' has no member named 'hardsect_size'
drivers/md/dm-table.c:765: error: 'struct io_restrictions' has no member named 'hardsect_size'
drivers/md/dm-table.c:777: error: 'struct io_restrictions' has no member named 'hardsect_size'

This is caused by commit e1defc4ff0cf57aca6c5e3ff99fa503f5943c1f1
("block: Do away with the notion of hardsect_size") from the block tree
interacting with commits cc1018ae8a413b595a1f0f822928dd9e81a75e59
("dm-table-ensure-targets-are-aligned-to-hardsect_size") and
64b184139ca6cd3d53dc45d7782c8be50b3e0331
("dm-table-validate-device-hardsect_size") from the device-mapper tree.

So I added the following patch as well.

diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index d38b911..8f734ad 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -387,7 +387,7 @@ static int device_area_is_valid(struct dm_target *ti, struct block_device *bdev,
 			     sector_t start, sector_t len)
 {
 	sector_t dev_size = bdev->bd_inode->i_size >> SECTOR_SHIFT;
-	unsigned short hardsect_size_sectors = ti->limits.hardsect_size >>
+	unsigned short hardsect_size_sectors = ti->limits.logical_block_size >>
 					       SECTOR_SHIFT;
 	char b[BDEVNAME_SIZE];
 
@@ -414,7 +414,7 @@ static int device_area_is_valid(struct dm_target *ti, struct block_device *bdev,
 		DMWARN("%s: len=%llu not aligned to h/w sector size %hu of %s",
 		       dm_device_name(ti->table->md),
 		       (unsigned long long)len,
-		       ti->limits.hardsect_size, bdevname(bdev, b));
+		       ti->limits.logical_block_size, bdevname(bdev, b));
 		return 0;
 	}
 
@@ -735,7 +735,7 @@ static int validate_hardsect_alignment(struct dm_table *table)
 	 * (in units of 512-byte sectors).
 	 */
 	unsigned short device_hardsect_size_sects =
-			    table->limits.hardsect_size >> SECTOR_SHIFT;
+			    table->limits.logical_block_size >> SECTOR_SHIFT;
 
 	/*
 	 * Offset of the start of the next table entry, mod hardsect_size.
@@ -762,7 +762,7 @@ static int validate_hardsect_alignment(struct dm_table *table)
 		 * table entry are they compatible with its hardsect_size?
 		 */
 		if (remaining < ti->len &&
-		    remaining & ((ti->limits.hardsect_size >>
+		    remaining & ((ti->limits.logical_block_size >>
 				  SECTOR_SHIFT) - 1))
 			break;	/* Error */
 
@@ -779,7 +779,7 @@ static int validate_hardsect_alignment(struct dm_table *table)
 		       dm_device_name(table->md), i,
 		       (unsigned long long) ti->begin,
 		       (unsigned long long) ti->len,
-		       table->limits.hardsect_size);
+		       table->limits.logical_block_size);
 		return -EINVAL;
 	}
 

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

Re: linux-next: block tree build failure

[Martin K. Petersen]

>>>>> "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au> writes:

Stephen> Caused by commit 025146e13b63483add912706c101fb0fb6f015cc
Stephen> ("block: Move queue limits to an embedded struct") from the
Stephen> block tree interacting with commit
Stephen> c8f4b88baca86491a6125cf9373a75e04b22ff8b
Stephen> ("dm-avoid-unsupported-spanning-of-md-stripe-boundaries") from
Stephen> the device-mapper tree.

Stephen> This is caused by commit
Stephen> e1defc4ff0cf57aca6c5e3ff99fa503f5943c1f1 ("block: Do away with
Stephen> the notion of hardsect_size") from the block tree interacting
Stephen> with commits cc1018ae8a413b595a1f0f822928dd9e81a75e59
Stephen> ("dm-table-ensure-targets-are-aligned-to-hardsect_size") and
Stephen> 64b184139ca6cd3d53dc45d7782c8be50b3e0331
Stephen> ("dm-table-validate-device-hardsect_size") from the
Stephen> device-mapper tree.

Bummer. I wasn't aware Alasdair had taken those patches into his DM tree
yet.  I thought he was waiting for my block layer patches to land.

The accessor function patch in my patch series was explicitly put in
place to enable changing the API without affecting users.  And we've
tried to be careful about staging these patches in the right order
throughout all the involved trees.

Sorry about the slip-up :|

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Martin,

On Mon, 25 May 2009 01:38:26 -0400 "Martin K. Petersen" <martin.petersen@oracle.com> wrote:
>
> The accessor function patch in my patch series was explicitly put in
> place to enable changing the API without affecting users.  And we've
> tried to be careful about staging these patches in the right order
> throughout all the involved trees.

What you really need is to have the patches that introduce the accessors
in a tree common to all the possible users of them.  In practise this
often means Linus' tree - in which case the patches should introduce noop
versions of the accessors.  If that is possible, Linus is quite happy to
take those patches after which all the other users can take the
conversions into their own tree and everyone is happy.  :-)

Currently the patches that introduce the accessors only exist in the
block tree ...

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

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

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

block/blk-core.c: In function '__make_request':
block/blk-core.c:1179: error: expected ';' before 'return'

Caused by commit 6cf2a6c8d01514e86a8d38e4eeed402378b635dc ("Restore
barrier support for md and probably other virtual devices") which I have
reverted for today.

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

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

Re: linux-next: block tree build failure

[NeilBrown]

On Fri, June 26, 2009 12:53 pm, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> block/blk-core.c: In function '__make_request':
> block/blk-core.c:1179: error: expected ';' before 'return'
>
> Caused by commit 6cf2a6c8d01514e86a8d38e4eeed402378b635dc ("Restore
> barrier support for md and probably other virtual devices") which I have
> reverted for today.

Arg, that's my fault - sorry.

+               bio_endio(bio, -EOPNOTSUPP)
+                       return 0;

should of course be

+               bio_endio(bio, -EOPNOTSUPP);
+               return 0;

NeilBrown

Re: linux-next: block tree build failure

[Jens Axboe]

On Fri, Jun 26 2009, NeilBrown wrote:
> On Fri, June 26, 2009 12:53 pm, Stephen Rothwell wrote:
> > Hi Jens,
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > block/blk-core.c: In function '__make_request':
> > block/blk-core.c:1179: error: expected ';' before 'return'
> >
> > Caused by commit 6cf2a6c8d01514e86a8d38e4eeed402378b635dc ("Restore
> > barrier support for md and probably other virtual devices") which I have
> > reverted for today.
> 
> Arg, that's my fault - sorry.
> 
> +               bio_endio(bio, -EOPNOTSUPP)
> +                       return 0;
> 
> should of course be
> 
> +               bio_endio(bio, -EOPNOTSUPP);
> +               return 0;

I was certain I ran it through a compile cycle, sorry about that
Stephen. And Neil sending uncompiled patches, very uncool. Did you even
test it? I've pulled it for now.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Neil Brown]

On Friday June 26, jens.axboe@oracle.com wrote:
> On Fri, Jun 26 2009, NeilBrown wrote:
> > On Fri, June 26, 2009 12:53 pm, Stephen Rothwell wrote:
> > > Hi Jens,
> > >
> > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > >
> > > block/blk-core.c: In function '__make_request':
> > > block/blk-core.c:1179: error: expected ';' before 'return'
> > >
> > > Caused by commit 6cf2a6c8d01514e86a8d38e4eeed402378b635dc ("Restore
> > > barrier support for md and probably other virtual devices") which I have
> > > reverted for today.
> > 
> > Arg, that's my fault - sorry.
> > 
> > +               bio_endio(bio, -EOPNOTSUPP)
> > +                       return 0;
> > 
> > should of course be
> > 
> > +               bio_endio(bio, -EOPNOTSUPP);
> > +               return 0;
> 
> I was certain I ran it through a compile cycle, sorry about that
> Stephen. And Neil sending uncompiled patches, very uncool. Did you even
> test it? I've pulled it for now.

I tested this time.
Without the patch a 'mount -o journal=1 /dev/md0 /mnt'
followed by writing to /mnt/something produces

Jun 26 15:34:18 dell kernel: JBD: barrier-based sync failed on md0 - disabling barriers

in the kernel logs.
With the patch, it doesn't.

Comment updated slightly too.

NeilBrown

Author: NeilBrown <neilb@suse.de>
Date:   Fri Jun 26 15:41:35 2009 +1000

Restore barrier support for md and probably other virtual devices.

The next_ordered flag is only meaningful for devices that use __make_request.
So move the test against next_ordered out of generic code and in to
__make_request

Since this test was added, barriers have not worked on md or any
devices that don't use __make_request and so don't bother to set
next_ordered.  (dm explicitly sets something other than
QUEUE_ORDERED_NONE since
  commit 99360b4c18f7675b50d283301d46d755affe75fd
but notes in the comments that it is otherwise meaningless).

Cc: Ken Milmore <ken.milmore@googlemail.com>
Cc: stable@kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/block/blk-core.c b/block/blk-core.c
index b06cf5c..2283116 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1172,6 +1172,11 @@ static int __make_request(struct request_queue *q, struct bio *bio)
 	const int unplug = bio_unplug(bio);
 	int rw_flags;
 
+	if (bio_barrier(bio) && bio_has_data(bio) &&
+	    (q->next_ordered == QUEUE_ORDERED_NONE)) {
+		bio_endio(bio, -EOPNOTSUPP);
+		return 0;
+	}
 	/*
 	 * low level driver can indicate that it wants pages above a
 	 * certain limit bounced to low memory (ie for highmem, or even
@@ -1472,11 +1477,6 @@ static inline void __generic_make_request(struct bio *bio)
 			err = -EOPNOTSUPP;
 			goto end_io;
 		}
-		if (bio_barrier(bio) && bio_has_data(bio) &&
-		    (q->next_ordered == QUEUE_ORDERED_NONE)) {
-			err = -EOPNOTSUPP;
-			goto end_io;
-		}
 
 		ret = q->make_request_fn(q, bio);
 	} while (ret);

Re: linux-next: block tree build failure

[Jens Axboe]

On Fri, Jun 26 2009, Neil Brown wrote:
> On Friday June 26, jens.axboe@oracle.com wrote:
> > On Fri, Jun 26 2009, NeilBrown wrote:
> > > On Fri, June 26, 2009 12:53 pm, Stephen Rothwell wrote:
> > > > Hi Jens,
> > > >
> > > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > > >
> > > > block/blk-core.c: In function '__make_request':
> > > > block/blk-core.c:1179: error: expected ';' before 'return'
> > > >
> > > > Caused by commit 6cf2a6c8d01514e86a8d38e4eeed402378b635dc ("Restore
> > > > barrier support for md and probably other virtual devices") which I have
> > > > reverted for today.
> > > 
> > > Arg, that's my fault - sorry.
> > > 
> > > +               bio_endio(bio, -EOPNOTSUPP)
> > > +                       return 0;
> > > 
> > > should of course be
> > > 
> > > +               bio_endio(bio, -EOPNOTSUPP);
> > > +               return 0;
> > 
> > I was certain I ran it through a compile cycle, sorry about that
> > Stephen. And Neil sending uncompiled patches, very uncool. Did you even
> > test it? I've pulled it for now.
> 
> I tested this time.
> Without the patch a 'mount -o journal=1 /dev/md0 /mnt'
> followed by writing to /mnt/something produces
> 
> Jun 26 15:34:18 dell kernel: JBD: barrier-based sync failed on md0 - disabling barriers
> 
> in the kernel logs.
> With the patch, it doesn't.
> 
> Comment updated slightly too.

Applied this one. But please in the future do let me know if you haven't
tested or even compiled a patch. When I get an official looking patch
like the previous one, I'll usually apply it directly. Breaking the
build is baaaad.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

Hi Jens,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

fs/sync.c: In function 'sys_sync':
fs/sync.c:121: error: implicit declaration of function 'wakeup_pdflush'

Caused by commit 1728603e84b339be5d5abd392ed3ec5936253863 ("writeback:
switch to per-bdi threads for flushing data") from the block tree
interacting with commit 3beab0b42413e83a7907db7176b54c840fc75a81
("sys_sync(): fix 16% performance regression in ffsb create_4k test")
from Linus' tree.

I added the following patch as part of the block tree merge for today.  I
have no idea if it is correct.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 7 Jul 2009 13:34:26 +1000
Subject: [PATCH] block: pdflush fixup

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

diff --git a/fs/sync.c b/fs/sync.c
index 3422ba6..bf03fc7 100644
--- a/fs/sync.c
+++ b/fs/sync.c
@@ -118,7 +118,7 @@ restart:
  */
 SYSCALL_DEFINE0(sync)
 {
-	wakeup_pdflush(0);
+	wakeup_flusher_threads(0);
 	sync_filesystems(0);
 	sync_filesystems(1);
 	if (unlikely(laptop_mode))
-- 
1.6.3.3

Re: linux-next: block tree build failure

[Jens Axboe]

On Tue, Jul 07 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> fs/sync.c: In function 'sys_sync':
> fs/sync.c:121: error: implicit declaration of function 'wakeup_pdflush'
> 
> Caused by commit 1728603e84b339be5d5abd392ed3ec5936253863 ("writeback:
> switch to per-bdi threads for flushing data") from the block tree
> interacting with commit 3beab0b42413e83a7907db7176b54c840fc75a81
> ("sys_sync(): fix 16% performance regression in ffsb create_4k test")
> from Linus' tree.
> 
> I added the following patch as part of the block tree merge for today.  I
> have no idea if it is correct.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 7 Jul 2009 13:34:26 +1000
> Subject: [PATCH] block: pdflush fixup
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/sync.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/sync.c b/fs/sync.c
> index 3422ba6..bf03fc7 100644
> --- a/fs/sync.c
> +++ b/fs/sync.c
> @@ -118,7 +118,7 @@ restart:
>   */
>  SYSCALL_DEFINE0(sync)
>  {
> -	wakeup_pdflush(0);
> +	wakeup_flusher_threads(0);
>  	sync_filesystems(0);
>  	sync_filesystems(1);
>  	if (unlikely(laptop_mode))

That is correct! I have just now updated for-next as well, so your next
pull should lose this fixup.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

On Tue, 7 Jul 2009 08:38:46 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> That is correct! I have just now updated for-next as well, so your next
> pull should lose this fixup.

Excellent, thanks.

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

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

Re: linux-next: block tree build failure

[Christoph Hellwig]

On Tue, Jul 07, 2009 at 01:49:08PM +1000, Stephen Rothwell wrote:
> interacting with commit 3beab0b42413e83a7907db7176b54c840fc75a81
> ("sys_sync(): fix 16% performance regression in ffsb create_4k test")
> from Linus' tree.

Where the fuck is that patch coming from?  For one that's a horrible
patch subject and second I can't see it anywhere on -fsdevel.  We
removed that bdflush wakeup for a reason, and if it causes problems
those need to be discussed and fixed properly instead of papering over
it.

Re: linux-next: block tree build failure

[Christoph Hellwig]

On Tue, Jul 07, 2009 at 08:38:46AM +0200, Jens Axboe wrote:
> >  SYSCALL_DEFINE0(sync)
> >  {
> > -	wakeup_pdflush(0);
> > +	wakeup_flusher_threads(0);
> >  	sync_filesystems(0);
> >  	sync_filesystems(1);
> >  	if (unlikely(laptop_mode))
> 
> That is correct! I have just now updated for-next as well, so your next
> pull should lose this fixup.

It's not correct at all.  We'll how have various flusher threads doing
async syncs, just to wait for them again synchronously.  The right thing
to do here is to queue up the data integrity sync to per-bdi threads and
execute those in parallel.

Re: linux-next: block tree build failure

[Jens Axboe]

On Tue, Jul 07 2009, Christoph Hellwig wrote:
> On Tue, Jul 07, 2009 at 08:38:46AM +0200, Jens Axboe wrote:
> > >  SYSCALL_DEFINE0(sync)
> > >  {
> > > -	wakeup_pdflush(0);
> > > +	wakeup_flusher_threads(0);
> > >  	sync_filesystems(0);
> > >  	sync_filesystems(1);
> > >  	if (unlikely(laptop_mode))
> > 
> > That is correct! I have just now updated for-next as well, so your next
> > pull should lose this fixup.
> 
> It's not correct at all.  We'll how have various flusher threads doing
> async syncs, just to wait for them again synchronously.  The right thing
> to do here is to queue up the data integrity sync to per-bdi threads and
> execute those in parallel.

Sorry, I didn't judge the validity of the original patch, merely that
the wakeup_pdflush() -> wakeup_flusher_threads() is the correct patch in
the context of the per-bdi flushing.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Christoph,

On Tue, 7 Jul 2009 09:55:42 -0400 Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Jul 07, 2009 at 01:49:08PM +1000, Stephen Rothwell wrote:
> > interacting with commit 3beab0b42413e83a7907db7176b54c840fc75a81
> > ("sys_sync(): fix 16% performance regression in ffsb create_4k test")
> > from Linus' tree.
> 
> Where the fuck is that patch coming from?  For one that's a horrible
> patch subject and second I can't see it anywhere on -fsdevel.  We
> removed that bdflush wakeup for a reason, and if it causes problems
> those need to be discussed and fixed properly instead of papering over
> it.

http://lkml.org/lkml/2009/6/29/52

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

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

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

On Tue, 7 Jul 2009 08:38:46 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> That is correct! I have just now updated for-next as well, so your next
> pull should lose this fixup.

Except you left the call to wakeup_pdflush(0) in there ...  I will fix
that up while Christoph's concerns are addressed.

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

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

Re: linux-next: block tree build failure

[Jens Axboe]

On Wed, Jul 08 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Tue, 7 Jul 2009 08:38:46 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> >
> > That is correct! I have just now updated for-next as well, so your next
> > pull should lose this fixup.
> 
> Except you left the call to wakeup_pdflush(0) in there ...  I will fix
> that up while Christoph's concerns are addressed.

Oops, belt and suspenders and all that... Sorry, fixing it up now.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next build (x86_64 allmodconfig) failed like this:

fs/ubifs/budget.c: In function 'shrink_liability':
fs/ubifs/budget.c:74: warning: passing argument 1 of 'generic_sync_sb_inodes' from incompatible pointer type
include/linux/fs.h:2085: note: expected 'struct writeback_control *' but argument is of type 'struct super_block *'
fs/ubifs/budget.c:74: error: too many arguments to function 'generic_sync_sb_inodes'
fs/ubifs/budget.c:86: warning: passing argument 1 of 'generic_sync_sb_inodes' from incompatible pointer type
include/linux/fs.h:2085: note: expected 'struct writeback_control *' but argument is of type 'struct super_block *'
fs/ubifs/budget.c:86: error: too many arguments to function 'generic_sync_sb_inodes'

Caused by commit 2fa24dd6ef3c67be20fde192f67fe519ea8a4b91 ("writeback:
switch to per-bdi threads for flushing data").

I have used the version of the block tree from next-20090831 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Alasdair,

On Tue, 1 Sep 2009 14:59:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I have used the version of the block tree from next-20090831 for today.

Which means that I have had to use yesterday's version of the
device-mapper tree as well (since it is based on the block tree).

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

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

Re: linux-next: block tree build failure

[Jens Axboe]

On Tue, Sep 01 2009, Stephen Rothwell wrote:
> Hi Alasdair,
> 
> On Tue, 1 Sep 2009 14:59:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I have used the version of the block tree from next-20090831 for today.
> 
> Which means that I have had to use yesterday's version of the
> device-mapper tree as well (since it is based on the block tree).

Ah darn, sorry about that. I'll get that updated in about an hours time
and do a full compile.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Jens Axboe]

On Tue, Sep 01 2009, Jens Axboe wrote:
> On Tue, Sep 01 2009, Stephen Rothwell wrote:
> > Hi Alasdair,
> > 
> > On Tue, 1 Sep 2009 14:59:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > I have used the version of the block tree from next-20090831 for today.
> > 
> > Which means that I have had to use yesterday's version of the
> > device-mapper tree as well (since it is based on the block tree).
> 
> Ah darn, sorry about that. I'll get that updated in about an hours time
> and do a full compile.

This is resolved now.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

On Tue, 1 Sep 2009 10:13:25 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> This is resolved now.

Thanks.

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

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

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/block/aoe/aoeblk.c: In function 'aoeblk_gdalloc':
drivers/block/aoe/aoeblk.c:271: error: request for member 'backing_dev_info' in something not a structure or union

Caused by commit 7cd6134162529e6b7f9eaa5d72b1ef8fe3b355c9 ("writeback:
add name to backing_dev_info"). 'q->blkq' changed to be a pointer in
commit 7135a71b19be1faf48b7148d77844d03bc0717d6 ("aoe: allocate unused
request_queue for sysfs").

Please be a bit more careful with rebases.

I have used the version of the block tree from next-20090910 for today.

-- 
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: block tree build failure

[Jens Axboe]

On Fri, Sep 11 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/block/aoe/aoeblk.c: In function 'aoeblk_gdalloc':
> drivers/block/aoe/aoeblk.c:271: error: request for member 'backing_dev_info' in something not a structure or union
> 
> Caused by commit 7cd6134162529e6b7f9eaa5d72b1ef8fe3b355c9 ("writeback:
> add name to backing_dev_info"). 'q->blkq' changed to be a pointer in
> commit 7135a71b19be1faf48b7148d77844d03bc0717d6 ("aoe: allocate unused
> request_queue for sysfs").
> 
> Please be a bit more careful with rebases.

Sorry, I thought I had double checked it... Will fix it now.

> I have used the version of the block tree from next-20090910 for today.

No problem.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/block/aoe/aoeblk.c: In function 'aoeblk_make_request':
drivers/block/aoe/aoeblk.c:175: error: implicit declaration of function 'bio_barrier'

Caused by commit c1db2f19f1302e894fe9db818e08fb03e4a84df9 ("aoe: end
barrier bios with EOPNOTSUPP") interacting with commit
1f98a13f623e0ef666690a18c1250335fc6d7ef1 ("bio: first step in sanitizing
the bio->bi_rw flag testing").

I have used the version of the block tree from next-20090910 for today.
-- 
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: block tree build failure

[Jens Axboe]

On Mon, Sep 14 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/block/aoe/aoeblk.c: In function 'aoeblk_make_request':
> drivers/block/aoe/aoeblk.c:175: error: implicit declaration of function 'bio_barrier'
> 
> Caused by commit c1db2f19f1302e894fe9db818e08fb03e4a84df9 ("aoe: end
> barrier bios with EOPNOTSUPP") interacting with commit
> 1f98a13f623e0ef666690a18c1250335fc6d7ef1 ("bio: first step in sanitizing
> the bio->bi_rw flag testing").
> 
> I have used the version of the block tree from next-20090910 for today.

Fixed.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/block/drbd/drbd_tracing.c:29:26: error: linux/marker.h: No such file or directory

Caused by commit 95eaef1cbc63f73df4ff8559dd66b1d29b462535 ("Replaced our
own tracing stuff with Linux's tracepoints") from the block/drbd trees
interacting with commit fc5377668c3d808e1d53c4aee152c836f55c3490
("tracing: Remove markers") from Linus' tree.

I have no idea what the correct thing to do is here, so I have reverted
the merge of the drbd tree into the block tree and will have to drop the
drbd tree for today.
-- 
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: block tree build failure

[Lars Ellenberg]

On Wed, Sep 23, 2009 at 02:51:00PM +1000, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/block/drbd/drbd_tracing.c:29:26: error: linux/marker.h: No such file or directory
> 
> Caused by commit 95eaef1cbc63f73df4ff8559dd66b1d29b462535 ("Replaced our
> own tracing stuff with Linux's tracepoints") from the block/drbd trees
> interacting with commit fc5377668c3d808e1d53c4aee152c836f55c3490
> ("tracing: Remove markers") from Linus' tree.
> 
> I have no idea what the correct thing to do is here, so I have reverted
> the merge of the drbd tree into the block tree and will have to drop the
> drbd tree for today.

We'll have a look.
A quick fix should be to just disable CONFIG_DRBD_TRACE.

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Lars,

On Wed, 23 Sep 2009 09:11:52 +0200 Lars Ellenberg <lars.ellenberg@linbit.com> wrote:
>
> We'll have a look.

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: block tree build failure

[Lars Ellenberg]

On Wed, Sep 23, 2009 at 09:11:52AM +0200, Lars Ellenberg wrote:
> On Wed, Sep 23, 2009 at 02:51:00PM +1000, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > drivers/block/drbd/drbd_tracing.c:29:26: error: linux/marker.h: No such file or directory
> > 
> > Caused by commit 95eaef1cbc63f73df4ff8559dd66b1d29b462535 ("Replaced our
> > own tracing stuff with Linux's tracepoints") from the block/drbd trees
> > interacting with commit fc5377668c3d808e1d53c4aee152c836f55c3490
> > ("tracing: Remove markers") from Linus' tree.
> > 
> > I have no idea what the correct thing to do is here, so I have reverted
> > the merge of the drbd tree into the block tree and will have to drop the
> > drbd tree for today.
> 
> We'll have a look.

Sorry that it took me so long to have that look.
We can simply drop that include, we don't even use it.

diff --git a/drivers/block/drbd/drbd_tracing.c
b/drivers/block/drbd/drbd_tracing.c
index aefe986..d18d4f7 100644
--- a/drivers/block/drbd/drbd_tracing.c
+++ b/drivers/block/drbd/drbd_tracing.c
@@ -26,7 +26,6 @@
 #include <linux/module.h>
 #include <linux/drbd.h>
 #include <linux/ctype.h>
-#include <linux/marker.h>
 #include "drbd_int.h"
 #include "drbd_tracing.h"
 #include <linux/drbd_tag_magic.h>


Will be visible in our tree shortly.
Thanks,

	Lars

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Lars,

On Wed, 23 Sep 2009 13:12:25 +0200 Lars Ellenberg <lars.ellenberg@linbit.com> wrote:
>
> Sorry that it took me so long to have that look.
> We can simply drop that include, we don't even use it.

OK, great.  I guess Jens needs to remerge your tree.

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

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

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/block/drbd/drbd_req.c: In function '_drbd_start_io_acct':
drivers/block/drbd/drbd_req.c:43: error: lvalue required as increment operand
drivers/block/drbd/drbd_req.c: In function '_drbd_end_io_acct':
drivers/block/drbd/drbd_req.c:56: error: lvalue required as decrement operand

This is back again :-(

I have used the block tree from next-20091006 for today.  I also had to
use the device-mapper tree from next-20091006 since that is based on the
block tree.
-- 
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: block tree build failure

[Jens Axboe]

On Wed, Oct 07 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/block/drbd/drbd_req.c: In function '_drbd_start_io_acct':
> drivers/block/drbd/drbd_req.c:43: error: lvalue required as increment operand
> drivers/block/drbd/drbd_req.c: In function '_drbd_end_io_acct':
> drivers/block/drbd/drbd_req.c:56: error: lvalue required as decrement operand
> 
> This is back again :-(
> 
> I have used the block tree from next-20091006 for today.  I also had to
> use the device-mapper tree from next-20091006 since that is based on the
> block tree.

Irk darn, I fixed this up. Sorry about that, Stephen. It was due to the
in_flight counter being reverted for -rc3 and now back functional in my
upstream branch.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/block/drbd/drbd_req.c: In function '_drbd_start_io_acct':
drivers/block/drbd/drbd_req.c:43: error: lvalue required as increment operand
drivers/block/drbd/drbd_req.c: In function '_drbd_end_io_acct':
drivers/block/drbd/drbd_req.c:56: error: lvalue required as decrement operand

This is the dual in_flight changes breaking again ... I have used the
block tree from next-20091026 for today.
-- 
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: block tree build failure

[Jens Axboe]

On Tue, Oct 27 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/block/drbd/drbd_req.c: In function '_drbd_start_io_acct':
> drivers/block/drbd/drbd_req.c:43: error: lvalue required as increment operand
> drivers/block/drbd/drbd_req.c: In function '_drbd_end_io_acct':
> drivers/block/drbd/drbd_req.c:56: error: lvalue required as decrement operand
> 
> This is the dual in_flight changes breaking again ... I have used the
> block tree from next-20091026 for today.

Sorry, not sure why that problem seems so persistent, I just merged the
newer bits in. Will fix it.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

On Tue, 27 Oct 2009 06:31:09 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> Sorry, not sure why that problem seems so persistent, I just merged the
> newer bits in. Will fix it.

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

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

Today's linux-next build (x86_64 allmodconfig) failed like this:

block/built-in.o: In function `blkiocg_destroy':
blk-cgroup.c:(.text+0x1bd48): undefined reference to `cfq_unlink_blkio_group'
block/built-in.o: In function `blkiocg_weight_write':
blk-cgroup.c:(.text+0x1c0d2): undefined reference to `cfq_update_blkio_group_weight'

Caused by commits b1c3576961847da26c91b1e97f226bb66be5fa3f ("blkio: Take
care of cgroup deletion and cfq group reference counting") and
f8d461d692c341add957fb973fb5ee1f62039dc7 ("blkio: Propagate cgroup weight
updation to cfq groups").

When adding code that is CONFIG dependent, please build test it with and
without the relevant CONFIG setting (in this case
CONFIG_CFQ_GROUP_IOSCHED).  Also put the extern declarations of global
functions into a header file.

I have used the version of the block tree from next-20091203 for today.
-- 
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: block tree build failure

[Jens Axboe]

On Fri, Dec 04 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> block/built-in.o: In function `blkiocg_destroy':
> blk-cgroup.c:(.text+0x1bd48): undefined reference to `cfq_unlink_blkio_group'
> block/built-in.o: In function `blkiocg_weight_write':
> blk-cgroup.c:(.text+0x1c0d2): undefined reference to `cfq_update_blkio_group_weight'
> 
> Caused by commits b1c3576961847da26c91b1e97f226bb66be5fa3f ("blkio: Take
> care of cgroup deletion and cfq group reference counting") and
> f8d461d692c341add957fb973fb5ee1f62039dc7 ("blkio: Propagate cgroup weight
> updation to cfq groups").
> 
> When adding code that is CONFIG dependent, please build test it with and
> without the relevant CONFIG setting (in this case
> CONFIG_CFQ_GROUP_IOSCHED).  Also put the extern declarations of global
> functions into a header file.

The problem looks like a circular dependency betwen BLK_CGROUP and CFQ.
The Kconfig dependencies doesn't express that blk-cgroup also calls into
cfq, so you can't have cfq=m (cfq doesn't even export those functions).
It looks pretty messy, to be honest. I'll see if I can fix it up.

> I have used the version of the block tree from next-20091203 for today.

Thanks.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Jens Axboe]

On Fri, Dec 04 2009, Jens Axboe wrote:
> On Fri, Dec 04 2009, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > block/built-in.o: In function `blkiocg_destroy':
> > blk-cgroup.c:(.text+0x1bd48): undefined reference to `cfq_unlink_blkio_group'
> > block/built-in.o: In function `blkiocg_weight_write':
> > blk-cgroup.c:(.text+0x1c0d2): undefined reference to `cfq_update_blkio_group_weight'
> > 
> > Caused by commits b1c3576961847da26c91b1e97f226bb66be5fa3f ("blkio: Take
> > care of cgroup deletion and cfq group reference counting") and
> > f8d461d692c341add957fb973fb5ee1f62039dc7 ("blkio: Propagate cgroup weight
> > updation to cfq groups").
> > 
> > When adding code that is CONFIG dependent, please build test it with and
> > without the relevant CONFIG setting (in this case
> > CONFIG_CFQ_GROUP_IOSCHED).  Also put the extern declarations of global
> > functions into a header file.
> 
> The problem looks like a circular dependency betwen BLK_CGROUP and CFQ.
> The Kconfig dependencies doesn't express that blk-cgroup also calls into
> cfq, so you can't have cfq=m (cfq doesn't even export those functions).
> It looks pretty messy, to be honest. I'll see if I can fix it up.

I pushed out the quick fix, just disallowing cfq=m and blk cgroup in
Kconfig. So it should work now.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

On Fri, 4 Dec 2009 14:54:22 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> I pushed out the quick fix, just disallowing cfq=m and blk cgroup in
> Kconfig. So it should work now.

Great, 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: block tree build failure

[Jens Axboe]

On Sat, Dec 05 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Fri, 4 Dec 2009 14:54:22 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
> >
> > I pushed out the quick fix, just disallowing cfq=m and blk cgroup in
> > Kconfig. So it should work now.
> 
> Great, thanks.

And later on a proper solution was also implemented, that is what is
currently in the tree since last night.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

Hi Jens,

Today's linux-next build (powerpc allyesconfig) failed like this:

block/blk-cgroup.c: In function 'blkiocg_create':
block/blk-cgroup.c:285: error: implicit declaration of function 'ERR_PTR'
block/blk-cgroup.c:285: warning: return makes pointer from integer without a cast
block/blk-cgroup.c:289: warning: return makes pointer from integer without a cast

Caused by commit 31e4c28d95e64f2d5d3c497a3ecf37c62de635b4 ("blkio:
Introduce blkio controller cgroup interface").

I applied this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 Dec 2009 19:29:39 +1100
Subject: [PATCH] block: include linux/err.h to use ERR_PTR

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 block/blk-cgroup.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 3ad497f..1fa2654 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -14,6 +14,7 @@
 #include <linux/seq_file.h>
 #include <linux/kdev_t.h>
 #include <linux/module.h>
+#include <linux/err.h>
 #include "blk-cgroup.h"
 
 static DEFINE_SPINLOCK(blkio_list_lock);
-- 
1.6.5.3


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

Re: linux-next: block tree build failure

[Jens Axboe]

On Mon, Dec 07 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> block/blk-cgroup.c: In function 'blkiocg_create':
> block/blk-cgroup.c:285: error: implicit declaration of function 'ERR_PTR'
> block/blk-cgroup.c:285: warning: return makes pointer from integer without a cast
> block/blk-cgroup.c:289: warning: return makes pointer from integer without a cast
> 
> Caused by commit 31e4c28d95e64f2d5d3c497a3ecf37c62de635b4 ("blkio:
> Introduce blkio controller cgroup interface").
> 
> I applied this patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 7 Dec 2009 19:29:39 +1100
> Subject: [PATCH] block: include linux/err.h to use ERR_PTR
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  block/blk-cgroup.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index 3ad497f..1fa2654 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -14,6 +14,7 @@
>  #include <linux/seq_file.h>
>  #include <linux/kdev_t.h>
>  #include <linux/module.h>
> +#include <linux/err.h>
>  #include "blk-cgroup.h"
>  
>  static DEFINE_SPINLOCK(blkio_list_lock);

Thanks Stephen, I merged your patch and updated the branches.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

On Mon, 7 Dec 2009 09:49:03 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> Thanks Stephen, I merged your patch and updated the branches.

I presume that you build tested as well - or do you trust me ;-)

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: block tree build failure

[Jens Axboe]

On Mon, Dec 07 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Mon, 7 Dec 2009 09:49:03 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
> >
> > Thanks Stephen, I merged your patch and updated the branches.
> 
> I presume that you build tested as well - or do you trust me ;-)

In this case I trust you, since you say you tested it and I do consider
you a credible source :-). I did compile locally, as a santity check.
Adding a header I consider pretty low risk.

-- 
Jens Axboe