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

[RFC] updated DM table alignment validation patches [Was: Re: linux-next: block tree build failure]

[Mike Snitzer]

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

On Mon, May 25 2009 at  1:54am -0400,
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

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

I've refreshed the DM linux-next patches that were off Martin's radar;
they are available here (and are also attached):

http://people.redhat.com/msnitzer/patches/dm-topology/dm-table-ensure-targets-are-aligned-to-logical_block_size.patch
http://people.redhat.com/msnitzer/patches/dm-topology/dm-table-validate-device-logical_block_size.patch

These updated patches still seem useful (as negative checks independent
of the topology code).

There is more work that is needed in DM and LVM2 userspace in order to
properly support and utilize the new topology infrastructure.  So I'm
also taking a much closer look at the needed changes now and should have
it sorted out in the coming days.

Mike



[-- Attachment #2: dm-table-ensure-targets-are-aligned-to-logical_block_size.patch --]
[-- Type: text/plain, Size: 2872 bytes --]

From: Mike Snitzer <snitzer@redhat.com>

Ensure I/O is aligned to the logical block size of target devices.

Rename check_device_area() to device_area_is_valid() for clarity and
establish the device limits including the logical block size prior to
calling it.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>

---
 drivers/md/dm-table.c |   54 +++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 41 insertions(+), 13 deletions(-)

Index: linux-2.6/drivers/md/dm-table.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-table.c
+++ linux-2.6/drivers/md/dm-table.c
@@ -385,15 +385,42 @@ static void close_dev(struct dm_dev_inte
 /*
  * If possible, this checks an area of a destination device is valid.
  */
-static int check_device_area(struct dm_dev_internal *dd, sector_t start,
-			     sector_t len)
+static int device_area_is_valid(struct dm_target *ti, struct block_device *bdev,
+			     sector_t start, sector_t len)
 {
-	sector_t dev_size = dd->dm_dev.bdev->bd_inode->i_size >> SECTOR_SHIFT;
+	sector_t dev_size = bdev->bd_inode->i_size >> SECTOR_SHIFT;
+	unsigned short logical_block_size_sectors =
+		ti->limits.logical_block_size >> SECTOR_SHIFT;
+	char b[BDEVNAME_SIZE];
 
 	if (!dev_size)
 		return 1;
 
-	return ((start < dev_size) && (len <= (dev_size - start)));
+	if ((start >= dev_size) || (start + len > dev_size)) {
+		DMWARN("%s: %s too small for target",
+		       dm_device_name(ti->table->md), bdevname(bdev, b));
+		return 0;
+	}
+
+	if (logical_block_size_sectors <= 1)
+		return 1;
+
+	if (start & (logical_block_size_sectors - 1)) {
+		DMWARN("%s: start=%llu not aligned to h/w sector of %s",
+		       dm_device_name(ti->table->md),
+		       (unsigned long long)start, bdevname(bdev, b));
+		return 0;
+	}
+
+	if (len & (logical_block_size_sectors - 1)) {
+		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.logical_block_size, bdevname(bdev, b));
+		return 0;
+	}
+
+	return 1;
 }
 
 /*
@@ -479,14 +506,7 @@ static int __table_get_device(struct dm_
 	}
 	atomic_inc(&dd->count);
 
-	if (!check_device_area(dd, start, len)) {
-		DMWARN("device %s too small for target", path);
-		dm_put_device(ti, &dd->dm_dev);
-		return -EINVAL;
-	}
-
 	*result = &dd->dm_dev;
-
 	return 0;
 }
 
@@ -555,8 +575,16 @@ int dm_get_device(struct dm_target *ti, 
 	int r = __table_get_device(ti->table, ti, path,
 				   start, len, mode, result);
 
-	if (!r)
-		dm_set_device_limits(ti, (*result)->bdev);
+	if (r)
+		return r;
+
+	dm_set_device_limits(ti, (*result)->bdev);
+
+	if (!device_area_is_valid(ti, (*result)->bdev, start, len)) {
+		dm_put_device(ti, *result);
+		*result = NULL;
+		return -EINVAL;
+	}
 
 	return r;
 }

[-- Attachment #3: dm-table-validate-device-logical_block_size.patch --]
[-- Type: text/plain, Size: 3175 bytes --]

From: Mike Snitzer <snitzer@redhat.com>

Impose necessary and sufficient conditions on a devices's table such
that any incoming bio which respects its logical_block_size can be
processed successfully.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>

---
 drivers/md/dm-table.c |   69 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

Index: linux-2.6/drivers/md/dm-table.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-table.c
+++ linux-2.6/drivers/md/dm-table.c
@@ -723,6 +723,71 @@ static void check_for_valid_limits(struc
 		rs->bounce_pfn = -1;
 }
 
+/*
+ * Impose necessary and sufficient conditions on a devices's table such
+ * that any incoming bio which respects its logical_block_size can be
+ * processed successfully.  If it falls across the boundary between
+ * two or more targets, the size of each piece it gets split into must
+ * be compatible with the logical_block_size of the target processing it.
+ */
+static int validate_hardware_logical_block_alignment(struct dm_table *table)
+{
+	/*
+	 * This function uses arithmetic modulo the logical_block_size
+	 * (in units of 512-byte sectors).
+	 */
+	unsigned short device_logical_block_size_sects =
+		table->limits.logical_block_size >> SECTOR_SHIFT;
+
+	/*
+	 * Offset of the start of the next table entry, mod logical_block_size.
+	 */
+	unsigned short next_target_start = 0;
+
+	/*
+	 * Given an aligned bio that extends beyond the end of a
+	 * target, how many sectors must the next target handle?
+	 */
+	unsigned short remaining = 0;
+
+	struct dm_target *uninitialized_var(ti);
+	unsigned i = 0;
+
+	/*
+	 * Check each entry in the table in turn.
+	 */
+	while (i < dm_table_get_num_targets(table)) {
+		ti = dm_table_get_target(table, i++);
+
+		/*
+		 * If the remaining sectors fall entirely within this
+		 * table entry are they compatible with its logical_block_size?
+		 */
+		if (remaining < ti->len &&
+		    remaining & ((ti->limits.logical_block_size >>
+				  SECTOR_SHIFT) - 1))
+			break;	/* Error */
+
+		next_target_start =
+		    (unsigned short) ((next_target_start + ti->len) &
+				      (device_logical_block_size_sects - 1));
+		remaining = next_target_start ?
+		    device_logical_block_size_sects - next_target_start : 0;
+	}
+
+	if (remaining) {
+		DMWARN("%s: table line %u (start sect %llu len %llu) "
+		       "not aligned to hardware logical block size %hu",
+		       dm_device_name(table->md), i,
+		       (unsigned long long) ti->begin,
+		       (unsigned long long) ti->len,
+		       table->limits.logical_block_size);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 int dm_table_add_target(struct dm_table *t, const char *type,
 			sector_t start, sector_t len, char *params)
 {
@@ -822,6 +887,10 @@ int dm_table_complete(struct dm_table *t
 
 	check_for_valid_limits(&t->limits);
 
+	r = validate_hardware_logical_block_alignment(t);
+	if (r)
+		return r;
+
 	/* how many indexes will the btree have ? */
 	leaf_nodes = dm_div_up(t->num_targets, KEYS_PER_NODE);
 	t->depth = 1 + int_log(leaf_nodes, CHILDREN_PER_NODE);

[-- Attachment #4: Type: text/plain, Size: 0 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

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

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

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

[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

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

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

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

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 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.1: Type: text/plain, Size: 688 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-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: block tree build failure

[Stephen Rothwell]

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

Hi Lars,

On Wed, 23 Sep 2009 13:12:25 +0200 Lars Ellenberg <lars.ellenberg-63ez5xqkn6Bhl2p70BpVqQ@public.gmane.orgm> 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-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: 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: 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 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.

linux-next: block tree build failure

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 733 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-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: 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: 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 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: 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

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

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

[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

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

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

[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

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

[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

[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

[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

[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

[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

[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

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

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

[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

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

[Tejun Heo]

Hello, James.

James Bottomley wrote:
>> Ah... poor wording from me.  I meant the one based on merging and
>> monotonic commit accumulation without rebasing.
> 
> But that's not really possible here ... the only way to combine the two
> incompatible trees now while maintaining bisectability is to hide a non
> trivial patch in the merge point ... that's the worst practice of all.

With proper commit message, I don't think straight merge would be that
bad.  The amount of conflicting code isn't that large.  But we're
talking about two extremes here.  Straight merging at one end and
keeping temporary tree till the merge into Linus's tree happens.

The problem with floating the block tree till the final merge is that
it might make SCSI happy but SCSI isn't the only consumer.  It just
doesn't scale.

I don't really care about the specific merge order as long as there
can be a mid synchronization point from which everyone can go on again
and there are three trees involved and if there's any way to get a
stable merge point from SCSI, things will work nicely.

Thanks.

-- 
tejun

Re: linux-next: block tree build failure

[James Bottomley]

On Fri, 2009-05-15 at 11:47 +0900, Tejun Heo wrote:
> Hello, James.
> 
> James Bottomley wrote:
> > No ... postmerge trees are held by maintainers for irreconcilable tree
> > conflicts.  You run your standard tree, which can fire at any time in
> > the merge window and your postmerge one which pulls in the entangled
> > tree and adds your patches on top.   This can only go after the
> > conflicting subsystem has also been pulled into linus head.
> >
> >> Out of curiousity, is there any reason not to use more standard git
> >> workflow?
> > 
> > This is a standard workflow ...
> 
> Ah... poor wording from me.  I meant the one based on merging and
> monotonic commit accumulation without rebasing.

But that's not really possible here ... the only way to combine the two
incompatible trees now while maintaining bisectability is to hide a non
trivial patch in the merge point ... that's the worst practice of all.

James

Re: linux-next: block tree build failure

[Tejun Heo]

Hello, James.

James Bottomley wrote:
> No ... postmerge trees are held by maintainers for irreconcilable tree
> conflicts.  You run your standard tree, which can fire at any time in
> the merge window and your postmerge one which pulls in the entangled
> tree and adds your patches on top.   This can only go after the
> conflicting subsystem has also been pulled into linus head.
>
>> Out of curiousity, is there any reason not to use more standard git
>> workflow?
> 
> This is a standard workflow ...

Ah... poor wording from me.  I meant the one based on merging and
monotonic commit accumulation without rebasing.

> it's how we've pretty much always sorted out entanglements ... at
> least it's between me and Jens, which are two git trees ... I've had
> to run post merge trees against gregkh's quilt before now.
>
>> Developers (kernel devs at least) are now pretty comfortable with
>> git and trees merging and splitting off.  I can't really see much
>> value in rebasing these days.
> 
> That depends.  It's not unusual for patches to get dropped or moved
> around in my trees (I try not to do it often) which can't be done
> without rebasing.  That pretty much precludes merging because I need a
> cleanly rebaseable change set.

The only benefit I can see for rebasing these days is cosmetic cleanup
of commit history.  Well, fixing history could help bisection at times
but still I don't think it's anything substantial.  Anyways, it's your
tree and your call.

Jens, how do you wanna proceed here?  And is there anything I can do
to help?

Thanks.

-- 
tejun

Re: linux-next: block tree build failure

[James Bottomley]

On Fri, 2009-05-15 at 09:45 +0900, Tejun Heo wrote:
> Hello, James.
> 
> James Bottomley wrote:
> > On Wed, 2009-05-13 at 18:21 +0900, Tejun Heo wrote:
> >>> I have reverted commit b1f744937f1be3e6d3009382a755679133cf782d
> >>> ("block: move completion related functions back to blk-core.c") and
> >>> applied the following patch (which I realise is probably not
> >>> correct) for today.  Maybe someone can come up with a better
> >>> solution for the scsi guys and me.
> >> Hmmm... is there a SCSI tree which won't be rebased?  Then I can pull
> >> blk tree into it and SCSI tree can go on from that point on.
> > 
> > Not really ... especially now there's a proposal to redo the mvsas
> > patch.  However, block can run a postmerge tree with the changes in
> > them.
> 
> Aieee... Yeah, I guess I can maintain temporary merge tip for blk and
> scsi (that's what you're talking about, right?).

No ... postmerge trees are held by maintainers for irreconcilable tree
conflicts.  You run your standard tree, which can fire at any time in
the merge window and your postmerge one which pulls in the entangled
tree and adds your patches on top.   This can only go after the
conflicting subsystem has also been pulled into linus head.

>   Out of curiousity,
> is there any reason not to use more standard git workflow?

This is a standard workflow ... it's how we've pretty much always sorted
out entanglements ... at least it's between me and Jens, which are two
git trees ... I've had to run post merge trees against gregkh's quilt
before now.

>   Developers
> (kernel devs at least) are now pretty comfortable with git and trees
> merging and splitting off.  I can't really see much value in rebasing
> these days.

That depends.  It's not unusual for patches to get dropped or moved
around in my trees (I try not to do it often) which can't be done
without rebasing.  That pretty much precludes merging because I need a
cleanly rebaseable change set.

James

Re: linux-next: block tree build failure

[Tejun Heo]

Hello, James.

James Bottomley wrote:
> On Wed, 2009-05-13 at 18:21 +0900, Tejun Heo wrote:
>>> I have reverted commit b1f744937f1be3e6d3009382a755679133cf782d
>>> ("block: move completion related functions back to blk-core.c") and
>>> applied the following patch (which I realise is probably not
>>> correct) for today.  Maybe someone can come up with a better
>>> solution for the scsi guys and me.
>> Hmmm... is there a SCSI tree which won't be rebased?  Then I can pull
>> blk tree into it and SCSI tree can go on from that point on.
> 
> Not really ... especially now there's a proposal to redo the mvsas
> patch.  However, block can run a postmerge tree with the changes in
> them.

Aieee... Yeah, I guess I can maintain temporary merge tip for blk and
scsi (that's what you're talking about, right?).  Out of curiousity,
is there any reason not to use more standard git workflow?  Developers
(kernel devs at least) are now pretty comfortable with git and trees
merging and splitting off.  I can't really see much value in rebasing
these days.

Thanks.

-- 
tejun

Re: linux-next: block tree build failure

[James Bottomley]

On Wed, 2009-05-13 at 18:21 +0900, Tejun Heo wrote:
> > I have reverted commit b1f744937f1be3e6d3009382a755679133cf782d
> > ("block: move completion related functions back to blk-core.c") and
> > applied the following patch (which I realise is probably not
> > correct) for today.  Maybe someone can come up with a better
> > solution for the scsi guys and me.
> 
> Hmmm... is there a SCSI tree which won't be rebased?  Then I can pull
> blk tree into it and SCSI tree can go on from that point on.

Not really ... especially now there's a proposal to redo the mvsas
patch.  However, block can run a postmerge tree with the changes in
them.

James

Re: linux-next: block tree build failure

[Tejun Heo]

Hello,

Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> drivers/scsi/scsi_transport_fc.c: In function 'fc_bsg_jobdone':
> drivers/scsi/scsi_transport_fc.c:3428: error: 'struct request' has no member named 'data_len'
> drivers/scsi/scsi_transport_fc.c:3434: error: 'struct request' has no member named 'data_len'
> drivers/scsi/scsi_transport_fc.c:3437: error: implicit declaration of function 'blk_end_bidi_request'
> drivers/scsi/scsi_transport_fc.c: In function 'fc_bsg_map_buffer':
> drivers/scsi/scsi_transport_fc.c:3499: error: 'struct request' has no member named 'data_len'
> drivers/scsi/scsi_transport_fc.c: In function 'fc_bsg_request_handler':
> drivers/scsi/scsi_transport_fc.c:3765: error: implicit declaration of function 'elv_next_request'
> drivers/scsi/scsi_transport_fc.c:3765: warning: assignment makes pointer from integer without a cast
> drivers/scsi/scsi_transport_fc.c:3772: error: implicit declaration of function 'blkdev_dequeue_request'
> 
> Caused by commit 1bfe9caaff367601134c14fc428017419f628f7d ("[SCSI] FC
> Pass Thru support") from the scsi tree interacting with commits
> a2dec7b36364a5cc564c4d76cf16d2e7d33f5c05 ("block: hide request sector and
> data_len"), 9934c8c04561413609d2bc38c6b9f268cba774a4 ("block:
> implement and enforce request peek/start/fetch") and
> b1f744937f1be3e6d3009382a755679133cf782d ("block: move completion related
> functions back to blk-core.c") from the block tree.
> 
> Removing old interfaces is a particularly unfriendly thing to do within
> the same time frame as creating replacements.  Better would be to
> deprecate them or reimplement them in terms of the new interfaces if
> possible.

One of the goals of the API change was to break any user which
accesses block layer internals directly to enforce proper
encapsulation because there were too many abusers.  Sorry about the
trouble.

> I have reverted commit b1f744937f1be3e6d3009382a755679133cf782d
> ("block: move completion related functions back to blk-core.c") and
> applied the following patch (which I realise is probably not
> correct) for today.  Maybe someone can come up with a better
> solution for the scsi guys and me.

Hmmm... is there a SCSI tree which won't be rebased?  Then I can pull
blk tree into it and SCSI tree can go on from that point on.

Thanks.

-- 
tejun

linux-next: block tree build failure

[Stephen Rothwell]

Hi Jens,

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

drivers/scsi/scsi_transport_fc.c: In function 'fc_bsg_jobdone':
drivers/scsi/scsi_transport_fc.c:3428: error: 'struct request' has no member named 'data_len'
drivers/scsi/scsi_transport_fc.c:3434: error: 'struct request' has no member named 'data_len'
drivers/scsi/scsi_transport_fc.c:3437: error: implicit declaration of function 'blk_end_bidi_request'
drivers/scsi/scsi_transport_fc.c: In function 'fc_bsg_map_buffer':
drivers/scsi/scsi_transport_fc.c:3499: error: 'struct request' has no member named 'data_len'
drivers/scsi/scsi_transport_fc.c: In function 'fc_bsg_request_handler':
drivers/scsi/scsi_transport_fc.c:3765: error: implicit declaration of function 'elv_next_request'
drivers/scsi/scsi_transport_fc.c:3765: warning: assignment makes pointer from integer without a cast
drivers/scsi/scsi_transport_fc.c:3772: error: implicit declaration of function 'blkdev_dequeue_request'

Caused by commit 1bfe9caaff367601134c14fc428017419f628f7d ("[SCSI] FC
Pass Thru support") from the scsi tree interacting with commits
a2dec7b36364a5cc564c4d76cf16d2e7d33f5c05 ("block: hide request sector and
data_len"), 9934c8c04561413609d2bc38c6b9f268cba774a4 ("block:
implement and enforce request peek/start/fetch") and
b1f744937f1be3e6d3009382a755679133cf782d ("block: move completion related
functions back to blk-core.c") from the block tree.

Removing old interfaces is a particularly unfriendly thing to do within
the same time frame as creating replacements.  Better would be to
deprecate them or reimplement them in terms of the new interfaces if
possible.

I have reverted commit b1f744937f1be3e6d3009382a755679133cf782d ("block:
move completion related functions back to blk-core.c") and applied the
following patch (which I realise is probably not correct) for today.
Maybe someone can come up with a better solution for the scsi guys and me.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 13 May 2009 13:54:48 +1000
Subject: [PATCH] scsi/block: fixup scsi_transport_fc for block changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/scsi_transport_fc.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 4df8c3c..c8b8fb7 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -3425,13 +3425,13 @@ fc_bsg_jobdone(struct fc_bsg_job *job)
 		job->req->sense_len = job->reply_len;
 
 	/* we assume all request payload was transferred, residual == 0 */
-	req->data_len = 0;
+	req->__data_len = 0;
 
 	if (rsp) {
 		rsp_len = blk_rq_bytes(rsp);
 		BUG_ON(job->reply->reply_payload_rcv_len > rsp_len);
 		/* set reply (bidi) residual */
-		rsp->data_len = (rsp_len - job->reply->reply_payload_rcv_len);
+		rsp->__data_len = (rsp_len - job->reply->reply_payload_rcv_len);
 	}
 
 	blk_end_bidi_request(req, err, req_len, rsp_len);
@@ -3496,7 +3496,7 @@ fc_bsg_map_buffer(struct fc_bsg_buffer *buf, struct request *req)
 		return -ENOMEM;
 	sg_init_table(buf->sg_list, req->nr_phys_segments);
 	buf->sg_cnt = blk_rq_map_sg(req->q, req, buf->sg_list);
-	buf->payload_len = req->data_len;
+	buf->payload_len = blk_rq_bytes(req);
 	return 0;
 }
 
@@ -3762,14 +3762,14 @@ fc_bsg_request_handler(struct request_queue *q, struct Scsi_Host *shost,
 		return;
 
 	while (!blk_queue_plugged(q)) {
-		req = elv_next_request(q);
+		req = blk_peek_request(q);
 		if (!req)
 			break;
 
 		if (rport && (rport->port_state == FC_PORTSTATE_BLOCKED))
 				break;
 
-		blkdev_dequeue_request(req);
+		blk_start_request(req);
 
 		if (rport && (rport->port_state != FC_PORTSTATE_ONLINE)) {
 			req->errors = -ENXIO;
-- 
1.6.3

Re: linux-next: block tree build failure

[Jens Axboe]

On Tue, Apr 14 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Tue, 14 Apr 2009 08:21:31 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> >
> > Sorry about that, was a 5-day easter weekend here. It's fixed up now,
> > I've updated for-next and for-akpm accordingly.
> 
> Thanks.  (Its nice to have 3 (or 4) Sundays, isn't it :-))

If combined with nice spring weather, it comes highly recommended ;-)

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

On Tue, 14 Apr 2009 08:21:31 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> Sorry about that, was a 5-day easter weekend here. It's fixed up now,
> I've updated for-next and for-akpm accordingly.

Thanks.  (Its nice to have 3 (or 4) Sundays, isn't it :-))

-- 
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, Apr 14 2009, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Thu, 9 Apr 2009 13:37:16 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > usr/include/linux/fs.h:11: included file 'linux/rwtypes.h' is not exported
> > make[4]: *** [usr/include/linux/.check] Error 1
> > 
> > Caused by commit 93fe0305df9344f57edfa0444f8764b34ea74f9b ("Document and
> > move the various READ/WRITE types") which I have reverted for today.
> 
> This is still there, so today I have used the block tree from
> next-20090408.

Sorry about that, was a 5-day easter weekend here. It's fixed up now,
I've updated for-next and for-akpm accordingly.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

On Thu, 9 Apr 2009 13:37:16 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> usr/include/linux/fs.h:11: included file 'linux/rwtypes.h' is not exported
> make[4]: *** [usr/include/linux/.check] Error 1
> 
> Caused by commit 93fe0305df9344f57edfa0444f8764b34ea74f9b ("Document and
> move the various READ/WRITE types") which I have reverted for today.

This is still there, so today I have used the block tree from
next-20090408.

-- 
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: 460 bytes --]

Hi Jens,

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

usr/include/linux/fs.h:11: included file 'linux/rwtypes.h' is not exported
make[4]: *** [usr/include/linux/.check] Error 1

Caused by commit 93fe0305df9344f57edfa0444f8764b34ea74f9b ("Document and
move the various READ/WRITE types") 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

[Ingo Molnar]

* Jens Axboe <jens.axboe@oracle.com> wrote:

> On Wed, Nov 26 2008, Ingo Molnar wrote:
> > 
> > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > > the other direction (you merging ftrace bits) doesnt look too hot, 
> > > > you'd have to pick up:
> > > > 
> > > >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> > > 
> > > Lets do that, it's just a single patch here from Arnaldo. I have 
> > > attached it to this email.
> > 
> > thanks, here's the conversion to tracepoints below. Stephen, you 
> > might want to pick up the blk tree straight away plus the fix 
> > below.
> 
> I already pruned the patch from for-next and updated it, so you 
> should not have any conflicts with or without this being merged.

ok, thanks. The next ftrace-next update will have this.

	Ingo

Re: linux-next: block tree build failure

[Ingo Molnar]

* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> * Ingo Molnar (mingo@elte.hu) wrote:
> > 
> > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > > the other direction (you merging ftrace bits) doesnt look too hot, 
> > > > you'd have to pick up:
> > > > 
> > > >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> > > 
> > > Lets do that, it's just a single patch here from Arnaldo. I have 
> > > attached it to this email.
> > 
> > thanks, here's the conversion to tracepoints below. Stephen, you might 
> > want to pick up the blk tree straight away plus the fix below.
> 
> I guess the only difference between your implementation and mine is 
> that you define all the tracepoints in block/blktrace.c, while I 
> define them in the various files where they are used. I don't feel 
> very strongly opinioned about any of the two alternatives.

usage site build attribute must be the same as definition site 
attribute. So blktrace.c is not a good place - we will fail the build 
in the !CONFIG_BLK_DEV_IO_TRACE case. I'll apply your spread-out 
definition variant.

	Ingo

Re: linux-next: block tree build failure

[Mathieu Desnoyers]

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > > the other direction (you merging ftrace bits) doesnt look too hot, 
> > > you'd have to pick up:
> > > 
> > >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> > 
> > Lets do that, it's just a single patch here from Arnaldo. I have 
> > attached it to this email.
> 
> thanks, here's the conversion to tracepoints below. Stephen, you might 
> want to pick up the blk tree straight away plus the fix below.
> 

I guess the only difference between your implementation and mine is that
you define all the tracepoints in block/blktrace.c, while I define them
in the various files where they are used. I don't feel very strongly
opinioned about any of the two alternatives.

Mathieu

> 	Ingo
> 
> --------------->
> From 65ae5a3c622e707dbf7630397e94b7e2e9cd0ea5 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@elte.hu>
> Date: Wed, 26 Nov 2008 11:59:56 +0100
> Subject: [PATCH] blktrace: port to tracepoints, update
> 
> Port to the new tracepoints API: split DEFINE_TRACE() and DECLARE_TRACE()
> sites.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  block/blktrace.c      |   18 ++++++++++
>  include/trace/block.h |   84 +++++++++++++++++++++++++++++--------------------
>  2 files changed, 68 insertions(+), 34 deletions(-)
> 
> diff --git a/block/blktrace.c b/block/blktrace.c
> index b0a2cae..1dba3fb 100644
> --- a/block/blktrace.c
> +++ b/block/blktrace.c
> @@ -35,6 +35,24 @@ static atomic_t blk_probes_ref = ATOMIC_INIT(0);
>  static int blk_register_tracepoints(void);
>  static void blk_unregister_tracepoints(void);
>  
> +DEFINE_TRACE(block_bio_backmerge);
> +DEFINE_TRACE(block_bio_bounce);
> +DEFINE_TRACE(block_bio_complete);
> +DEFINE_TRACE(block_bio_frontmerge);
> +DEFINE_TRACE(block_bio_queue);
> +DEFINE_TRACE(block_getrq);
> +DEFINE_TRACE(block_plug);
> +DEFINE_TRACE(block_remap);
> +DEFINE_TRACE(block_rq_abort);
> +DEFINE_TRACE(block_rq_complete);
> +DEFINE_TRACE(block_rq_insert);
> +DEFINE_TRACE(block_rq_issue);
> +DEFINE_TRACE(block_rq_requeue);
> +DEFINE_TRACE(block_sleeprq);
> +DEFINE_TRACE(block_split);
> +DEFINE_TRACE(block_unplug_io);
> +DEFINE_TRACE(block_unplug_timer);
> +
>  /*
>   * Send out a notify message.
>   */
> diff --git a/include/trace/block.h b/include/trace/block.h
> index 3cc2675..25c6a1f 100644
> --- a/include/trace/block.h
> +++ b/include/trace/block.h
> @@ -4,57 +4,73 @@
>  #include <linux/blkdev.h>
>  #include <linux/tracepoint.h>
>  
> -DEFINE_TRACE(block_rq_abort,
> +DECLARE_TRACE(block_rq_abort,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_rq_insert,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_rq_insert,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_rq_issue,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_rq_issue,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_rq_requeue,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_rq_requeue,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_rq_complete,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_rq_complete,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_bio_bounce,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_bio_bounce,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_bio_complete,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_bio_complete,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_bio_backmerge,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_bio_backmerge,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_bio_frontmerge,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_bio_frontmerge,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_bio_queue,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_bio_queue,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_getrq,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_getrq,
>  	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
> -	TPARGS(q, bio, rw));
> -DEFINE_TRACE(block_sleeprq,
> +		TPARGS(q, bio, rw));
> +
> +DECLARE_TRACE(block_sleeprq,
>  	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
> -	TPARGS(q, bio, rw));
> -DEFINE_TRACE(block_plug,
> +		TPARGS(q, bio, rw));
> +
> +DECLARE_TRACE(block_plug,
>  	TPPROTO(struct request_queue *q),
> -	TPARGS(q));
> -DEFINE_TRACE(block_unplug_timer,
> +		TPARGS(q));
> +
> +DECLARE_TRACE(block_unplug_timer,
>  	TPPROTO(struct request_queue *q),
> -	TPARGS(q));
> -DEFINE_TRACE(block_unplug_io,
> +		TPARGS(q));
> +
> +DECLARE_TRACE(block_unplug_io,
>  	TPPROTO(struct request_queue *q),
> -	TPARGS(q));
> -DEFINE_TRACE(block_split,
> +		TPARGS(q));
> +
> +DECLARE_TRACE(block_split,
>  	TPPROTO(struct request_queue *q, struct bio *bio, unsigned int pdu),
> -	TPARGS(q, bio, pdu));
> -DEFINE_TRACE(block_remap,
> +		TPARGS(q, bio, pdu));
> +
> +DECLARE_TRACE(block_remap,
>  	TPPROTO(struct request_queue *q, struct bio *bio, dev_t dev,
>  		sector_t from, sector_t to),
> -	TPARGS(q, bio, dev, from, to));
> +		TPARGS(q, bio, dev, from, to));
>  
>  #endif

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: linux-next: block tree build failure

[Jens Axboe]

On Wed, Nov 26 2008, Ingo Molnar wrote:
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > > the other direction (you merging ftrace bits) doesnt look too hot, 
> > > you'd have to pick up:
> > > 
> > >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> > 
> > Lets do that, it's just a single patch here from Arnaldo. I have 
> > attached it to this email.
> 
> thanks, here's the conversion to tracepoints below. Stephen, you might 
> want to pick up the blk tree straight away plus the fix below.

I already pruned the patch from for-next and updated it, so you should
not have any conflicts with or without this being merged.


-- 
Jens Axboe

Re: linux-next: block tree build failure

[Ingo Molnar]

* Jens Axboe <jens.axboe@oracle.com> wrote:

> > the other direction (you merging ftrace bits) doesnt look too hot, 
> > you'd have to pick up:
> > 
> >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> 
> Lets do that, it's just a single patch here from Arnaldo. I have 
> attached it to this email.

thanks, here's the conversion to tracepoints below. Stephen, you might 
want to pick up the blk tree straight away plus the fix below.

	Ingo

--------------->
>From 65ae5a3c622e707dbf7630397e94b7e2e9cd0ea5 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Wed, 26 Nov 2008 11:59:56 +0100
Subject: [PATCH] blktrace: port to tracepoints, update

Port to the new tracepoints API: split DEFINE_TRACE() and DECLARE_TRACE()
sites.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 block/blktrace.c      |   18 ++++++++++
 include/trace/block.h |   84 +++++++++++++++++++++++++++++--------------------
 2 files changed, 68 insertions(+), 34 deletions(-)

diff --git a/block/blktrace.c b/block/blktrace.c
index b0a2cae..1dba3fb 100644
--- a/block/blktrace.c
+++ b/block/blktrace.c
@@ -35,6 +35,24 @@ static atomic_t blk_probes_ref = ATOMIC_INIT(0);
 static int blk_register_tracepoints(void);
 static void blk_unregister_tracepoints(void);
 
+DEFINE_TRACE(block_bio_backmerge);
+DEFINE_TRACE(block_bio_bounce);
+DEFINE_TRACE(block_bio_complete);
+DEFINE_TRACE(block_bio_frontmerge);
+DEFINE_TRACE(block_bio_queue);
+DEFINE_TRACE(block_getrq);
+DEFINE_TRACE(block_plug);
+DEFINE_TRACE(block_remap);
+DEFINE_TRACE(block_rq_abort);
+DEFINE_TRACE(block_rq_complete);
+DEFINE_TRACE(block_rq_insert);
+DEFINE_TRACE(block_rq_issue);
+DEFINE_TRACE(block_rq_requeue);
+DEFINE_TRACE(block_sleeprq);
+DEFINE_TRACE(block_split);
+DEFINE_TRACE(block_unplug_io);
+DEFINE_TRACE(block_unplug_timer);
+
 /*
  * Send out a notify message.
  */
diff --git a/include/trace/block.h b/include/trace/block.h
index 3cc2675..25c6a1f 100644
--- a/include/trace/block.h
+++ b/include/trace/block.h
@@ -4,57 +4,73 @@
 #include <linux/blkdev.h>
 #include <linux/tracepoint.h>
 
-DEFINE_TRACE(block_rq_abort,
+DECLARE_TRACE(block_rq_abort,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_insert,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_rq_insert,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_issue,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_rq_issue,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_requeue,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_rq_requeue,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_complete,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_rq_complete,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_bio_bounce,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_bio_bounce,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_complete,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_bio_complete,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_backmerge,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_bio_backmerge,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_frontmerge,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_bio_frontmerge,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_queue,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_bio_queue,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_getrq,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_getrq,
 	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
-	TPARGS(q, bio, rw));
-DEFINE_TRACE(block_sleeprq,
+		TPARGS(q, bio, rw));
+
+DECLARE_TRACE(block_sleeprq,
 	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
-	TPARGS(q, bio, rw));
-DEFINE_TRACE(block_plug,
+		TPARGS(q, bio, rw));
+
+DECLARE_TRACE(block_plug,
 	TPPROTO(struct request_queue *q),
-	TPARGS(q));
-DEFINE_TRACE(block_unplug_timer,
+		TPARGS(q));
+
+DECLARE_TRACE(block_unplug_timer,
 	TPPROTO(struct request_queue *q),
-	TPARGS(q));
-DEFINE_TRACE(block_unplug_io,
+		TPARGS(q));
+
+DECLARE_TRACE(block_unplug_io,
 	TPPROTO(struct request_queue *q),
-	TPARGS(q));
-DEFINE_TRACE(block_split,
+		TPARGS(q));
+
+DECLARE_TRACE(block_split,
 	TPPROTO(struct request_queue *q, struct bio *bio, unsigned int pdu),
-	TPARGS(q, bio, pdu));
-DEFINE_TRACE(block_remap,
+		TPARGS(q, bio, pdu));
+
+DECLARE_TRACE(block_remap,
 	TPPROTO(struct request_queue *q, struct bio *bio, dev_t dev,
 		sector_t from, sector_t to),
-	TPARGS(q, bio, dev, from, to));
+		TPARGS(q, bio, dev, from, to));
 
 #endif

Re: linux-next: block tree build failure

[Jens Axboe]

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

On Wed, Nov 26 2008, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Jens,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > In file included from block/blk-core.c:31:
> > include/trace/block.h:9:15: error: macro "DEFINE_TRACE" passed 3 arguments, but takes just 1
> > In file included from block/blk-core.c:31:
> > include/trace/block.h:7: warning: data definition has no type or storage class
> > include/trace/block.h:7: warning: type defaults to 'int' in declaration of 'DEFINE_TRACE'
> > 
> > and many more.  This is caused by commit 
> > 714d010b5c249c2e9282515e0a2309a61ababbf4 ("blktrace: port to 
> > tracepoints") interacting with commit 
> > 7e066fb870fcd1025ec3ba7bbde5d541094f4ce1 ("tracepoints: add 
> > DECLARE_TRACE () and DEFINE_TRACE()") which entered linux-next for 
> > the first time today via the ftrace tree. This latter commit has 
> > changed the tracepoints API.
> > 
> > I will drop the block tree for today.  I am not sure of the way forward.
> 
> hm, i think that might be interaction between ftrace tree updates and 
> blktrace?
> 
> Jens, would it be fine with you if we created a new 
> tip/tracing/blktrace branch and picked up your changes and kept it all 
> uptodate and merged with the ftrace tree? It should merge fine with 
> other bits of the block tree, right? (the tracepoints are in rather 
> stable spots of the code i think)
> 
> the other direction (you merging ftrace bits) doesnt look too hot, 
> you'd have to pick up:
> 
>    95 files changed, 5308 insertions(+), 1603 deletions(-)

Lets do that, it's just a single patch here from Arnaldo. I have
attached it to this email.

-- 
Jens Axboe


[-- Attachment #2: 0001-blktrace-port-to-tracepoints.patch --]
[-- Type: text/x-patch, Size: 28109 bytes --]

>From 714d010b5c249c2e9282515e0a2309a61ababbf4 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Thu, 30 Oct 2008 08:34:33 +0100
Subject: [PATCH] blktrace: port to tracepoints

This was a forward port of work done by Mathieu Desnoyers, I changed it to
encode the 'what' parameter on the tracepoint name, so that one can register
interest in specific events and not on classes of events to then check the
'what' parameter.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
---
 block/Kconfig                |    1 +
 block/blk-core.c             |   33 ++---
 block/blktrace.c             |  332 +++++++++++++++++++++++++++++++++++++++++-
 block/elevator.c             |    7 +-
 drivers/md/dm.c              |    6 +-
 fs/bio.c                     |    3 +-
 include/linux/blktrace_api.h |  172 +---------------------
 include/trace/block.h        |   60 ++++++++
 mm/bounce.c                  |    3 +-
 9 files changed, 418 insertions(+), 199 deletions(-)
 create mode 100644 include/trace/block.h

diff --git a/block/Kconfig b/block/Kconfig
index 1ab7c15..290b219 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -47,6 +47,7 @@ config BLK_DEV_IO_TRACE
 	depends on SYSFS
 	select RELAY
 	select DEBUG_FS
+	select TRACEPOINTS
 	help
 	  Say Y here if you want to be able to trace the block layer actions
 	  on a given queue. Tracing allows you to see any traffic happening
diff --git a/block/blk-core.c b/block/blk-core.c
index 10e8a64..04267d6 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -28,6 +28,7 @@
 #include <linux/task_io_accounting_ops.h>
 #include <linux/blktrace_api.h>
 #include <linux/fault-inject.h>
+#include <trace/block.h>
 
 #include "blk.h"
 
@@ -205,7 +206,7 @@ void blk_plug_device(struct request_queue *q)
 
 	if (!queue_flag_test_and_set(QUEUE_FLAG_PLUGGED, q)) {
 		mod_timer(&q->unplug_timer, jiffies + q->unplug_delay);
-		blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
+		trace_block_plug(q);
 	}
 }
 EXPORT_SYMBOL(blk_plug_device);
@@ -292,9 +293,7 @@ void blk_unplug_work(struct work_struct *work)
 	struct request_queue *q =
 		container_of(work, struct request_queue, unplug_work);
 
-	blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
-				q->rq.count[READ] + q->rq.count[WRITE]);
-
+	trace_block_unplug_io(q);
 	q->unplug_fn(q);
 }
 
@@ -302,9 +301,7 @@ void blk_unplug_timeout(unsigned long data)
 {
 	struct request_queue *q = (struct request_queue *)data;
 
-	blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_TIMER, NULL,
-				q->rq.count[READ] + q->rq.count[WRITE]);
-
+	trace_block_unplug_timer(q);
 	kblockd_schedule_work(q, &q->unplug_work);
 }
 
@@ -314,9 +311,7 @@ void blk_unplug(struct request_queue *q)
 	 * devices don't necessarily have an ->unplug_fn defined
 	 */
 	if (q->unplug_fn) {
-		blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
-					q->rq.count[READ] + q->rq.count[WRITE]);
-
+		trace_block_unplug_io(q);
 		q->unplug_fn(q);
 	}
 }
@@ -822,7 +817,7 @@ rq_starved:
 	if (ioc_batching(q, ioc))
 		ioc->nr_batch_requests--;
 
-	blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
+	trace_block_getrq(q, bio, rw);
 out:
 	return rq;
 }
@@ -848,7 +843,7 @@ static struct request *get_request_wait(struct request_queue *q, int rw_flags,
 		prepare_to_wait_exclusive(&rl->wait[rw], &wait,
 				TASK_UNINTERRUPTIBLE);
 
-		blk_add_trace_generic(q, bio, rw, BLK_TA_SLEEPRQ);
+		trace_block_sleeprq(q, bio, rw);
 
 		__generic_unplug_device(q);
 		spin_unlock_irq(q->queue_lock);
@@ -928,7 +923,7 @@ void blk_requeue_request(struct request_queue *q, struct request *rq)
 {
 	blk_delete_timer(rq);
 	blk_clear_rq_complete(rq);
-	blk_add_trace_rq(q, rq, BLK_TA_REQUEUE);
+	trace_block_rq_requeue(q, rq);
 
 	if (blk_rq_tagged(rq))
 		blk_queue_end_tag(q, rq);
@@ -1167,7 +1162,7 @@ static int __make_request(struct request_queue *q, struct bio *bio)
 		if (!ll_back_merge_fn(q, req, bio))
 			break;
 
-		blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);
+		trace_block_bio_backmerge(q, bio);
 
 		req->biotail->bi_next = bio;
 		req->biotail = bio;
@@ -1186,7 +1181,7 @@ static int __make_request(struct request_queue *q, struct bio *bio)
 		if (!ll_front_merge_fn(q, req, bio))
 			break;
 
-		blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);
+		trace_block_bio_frontmerge(q, bio);
 
 		bio->bi_next = req->bio;
 		req->bio = bio;
@@ -1269,7 +1264,7 @@ static inline void blk_partition_remap(struct bio *bio)
 		bio->bi_sector += p->start_sect;
 		bio->bi_bdev = bdev->bd_contains;
 
-		blk_add_trace_remap(bdev_get_queue(bio->bi_bdev), bio,
+		trace_block_remap(bdev_get_queue(bio->bi_bdev), bio,
 				    bdev->bd_dev, bio->bi_sector,
 				    bio->bi_sector - p->start_sect);
 	}
@@ -1441,10 +1436,10 @@ end_io:
 			goto end_io;
 
 		if (old_sector != -1)
-			blk_add_trace_remap(q, bio, old_dev, bio->bi_sector,
+			trace_block_remap(q, bio, old_dev, bio->bi_sector,
 					    old_sector);
 
-		blk_add_trace_bio(q, bio, BLK_TA_QUEUE);
+		trace_block_bio_queue(q, bio);
 
 		old_sector = bio->bi_sector;
 		old_dev = bio->bi_bdev->bd_dev;
@@ -1656,7 +1651,7 @@ static int __end_that_request_first(struct request *req, int error,
 	int total_bytes, bio_nbytes, next_idx = 0;
 	struct bio *bio;
 
-	blk_add_trace_rq(req->q, req, BLK_TA_COMPLETE);
+	trace_block_rq_complete(req->q, req);
 
 	/*
 	 * for a REQ_TYPE_BLOCK_PC request, we want to carry any eventual
diff --git a/block/blktrace.c b/block/blktrace.c
index 85049a7..b0a2cae 100644
--- a/block/blktrace.c
+++ b/block/blktrace.c
@@ -23,10 +23,18 @@
 #include <linux/mutex.h>
 #include <linux/debugfs.h>
 #include <linux/time.h>
+#include <trace/block.h>
 #include <asm/uaccess.h>
 
 static unsigned int blktrace_seq __read_mostly = 1;
 
+/* Global reference count of probes */
+static DEFINE_MUTEX(blk_probe_mutex);
+static atomic_t blk_probes_ref = ATOMIC_INIT(0);
+
+static int blk_register_tracepoints(void);
+static void blk_unregister_tracepoints(void);
+
 /*
  * Send out a notify message.
  */
@@ -119,7 +127,7 @@ static u32 ddir_act[2] __read_mostly = { BLK_TC_ACT(BLK_TC_READ), BLK_TC_ACT(BLK
  * The worker for the various blk_add_trace*() types. Fills out a
  * blk_io_trace structure and places it in a per-cpu subbuffer.
  */
-void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
+static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
 		     int rw, u32 what, int error, int pdu_len, void *pdu_data)
 {
 	struct task_struct *tsk = current;
@@ -177,8 +185,6 @@ void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
 	local_irq_restore(flags);
 }
 
-EXPORT_SYMBOL_GPL(__blk_add_trace);
-
 static struct dentry *blk_tree_root;
 static DEFINE_MUTEX(blk_tree_mutex);
 static unsigned int root_users;
@@ -237,6 +243,10 @@ static void blk_trace_cleanup(struct blk_trace *bt)
 	free_percpu(bt->sequence);
 	free_percpu(bt->msg_data);
 	kfree(bt);
+	mutex_lock(&blk_probe_mutex);
+	if (atomic_dec_and_test(&blk_probes_ref))
+		blk_unregister_tracepoints();
+	mutex_unlock(&blk_probe_mutex);
 }
 
 int blk_trace_remove(struct request_queue *q)
@@ -428,6 +438,14 @@ int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
 	bt->pid = buts->pid;
 	bt->trace_state = Blktrace_setup;
 
+	mutex_lock(&blk_probe_mutex);
+	if (atomic_add_return(1, &blk_probes_ref) == 1) {
+		ret = blk_register_tracepoints();
+		if (ret)
+			goto probe_err;
+	}
+	mutex_unlock(&blk_probe_mutex);
+
 	ret = -EBUSY;
 	old_bt = xchg(&q->blk_trace, bt);
 	if (old_bt) {
@@ -436,6 +454,9 @@ int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
 	}
 
 	return 0;
+probe_err:
+	atomic_dec(&blk_probes_ref);
+	mutex_unlock(&blk_probe_mutex);
 err:
 	if (dir)
 		blk_remove_tree(dir);
@@ -562,3 +583,308 @@ void blk_trace_shutdown(struct request_queue *q)
 		blk_trace_remove(q);
 	}
 }
+
+/*
+ * blktrace probes
+ */
+
+/**
+ * blk_add_trace_rq - Add a trace for a request oriented action
+ * @q:		queue the io is for
+ * @rq:		the source request
+ * @what:	the action
+ *
+ * Description:
+ *     Records an action against a request. Will log the bio offset + size.
+ *
+ **/
+static void blk_add_trace_rq(struct request_queue *q, struct request *rq,
+				    u32 what)
+{
+	struct blk_trace *bt = q->blk_trace;
+	int rw = rq->cmd_flags & 0x03;
+
+	if (likely(!bt))
+		return;
+
+	if (blk_discard_rq(rq))
+		rw |= (1 << BIO_RW_DISCARD);
+
+	if (blk_pc_request(rq)) {
+		what |= BLK_TC_ACT(BLK_TC_PC);
+		__blk_add_trace(bt, 0, rq->data_len, rw, what, rq->errors,
+				sizeof(rq->cmd), rq->cmd);
+	} else  {
+		what |= BLK_TC_ACT(BLK_TC_FS);
+		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9,
+				rw, what, rq->errors, 0, NULL);
+	}
+}
+
+static void blk_add_trace_rq_abort(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_ABORT);
+}
+
+static void blk_add_trace_rq_insert(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+}
+
+static void blk_add_trace_rq_issue(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+}
+
+static void blk_add_trace_rq_requeue(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_REQUEUE);
+}
+
+static void blk_add_trace_rq_complete(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_COMPLETE);
+}
+
+/**
+ * blk_add_trace_bio - Add a trace for a bio oriented action
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @what:	the action
+ *
+ * Description:
+ *     Records an action against a bio. Will log the bio offset + size.
+ *
+ **/
+static void blk_add_trace_bio(struct request_queue *q, struct bio *bio,
+				     u32 what)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (likely(!bt))
+		return;
+
+	__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what,
+			!bio_flagged(bio, BIO_UPTODATE), 0, NULL);
+}
+
+static void blk_add_trace_bio_bounce(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_BOUNCE);
+}
+
+static void blk_add_trace_bio_complete(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_COMPLETE);
+}
+
+static void blk_add_trace_bio_backmerge(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);
+}
+
+static void blk_add_trace_bio_frontmerge(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);
+}
+
+static void blk_add_trace_bio_queue(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_QUEUE);
+}
+
+static void blk_add_trace_getrq(struct request_queue *q, struct bio *bio, int rw)
+{
+	if (bio)
+		blk_add_trace_bio(q, bio, BLK_TA_GETRQ);
+	else {
+		struct blk_trace *bt = q->blk_trace;
+
+		if (bt)
+			__blk_add_trace(bt, 0, 0, rw, BLK_TA_GETRQ, 0, 0, NULL);
+	}
+}
+
+
+static void blk_add_trace_sleeprq(struct request_queue *q, struct bio *bio, int rw)
+{
+	if (bio)
+		blk_add_trace_bio(q, bio, BLK_TA_SLEEPRQ);
+	else {
+		struct blk_trace *bt = q->blk_trace;
+
+		if (bt)
+			__blk_add_trace(bt, 0, 0, rw, BLK_TA_SLEEPRQ, 0, 0, NULL);
+	}
+}
+
+static void blk_add_trace_plug(struct request_queue *q)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (bt)
+		__blk_add_trace(bt, 0, 0, 0, BLK_TA_PLUG, 0, 0, NULL);
+}
+
+static void blk_add_trace_unplug_io(struct request_queue *q)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (bt) {
+		unsigned int pdu = q->rq.count[READ] + q->rq.count[WRITE];
+		__be64 rpdu = cpu_to_be64(pdu);
+
+		__blk_add_trace(bt, 0, 0, 0, BLK_TA_UNPLUG_IO, 0,
+				sizeof(rpdu), &rpdu);
+	}
+}
+
+static void blk_add_trace_unplug_timer(struct request_queue *q)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (bt) {
+		unsigned int pdu = q->rq.count[READ] + q->rq.count[WRITE];
+		__be64 rpdu = cpu_to_be64(pdu);
+
+		__blk_add_trace(bt, 0, 0, 0, BLK_TA_UNPLUG_TIMER, 0,
+				sizeof(rpdu), &rpdu);
+	}
+}
+
+static void blk_add_trace_split(struct request_queue *q, struct bio *bio,
+				unsigned int pdu)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (bt) {
+		__be64 rpdu = cpu_to_be64(pdu);
+
+		__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw,
+				BLK_TA_SPLIT, !bio_flagged(bio, BIO_UPTODATE),
+				sizeof(rpdu), &rpdu);
+	}
+}
+
+/**
+ * blk_add_trace_remap - Add a trace for a remap operation
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @dev:	target device
+ * @from:	source sector
+ * @to:		target sector
+ *
+ * Description:
+ *     Device mapper or raid target sometimes need to split a bio because
+ *     it spans a stripe (or similar). Add a trace for that action.
+ *
+ **/
+static void blk_add_trace_remap(struct request_queue *q, struct bio *bio,
+				       dev_t dev, sector_t from, sector_t to)
+{
+	struct blk_trace *bt = q->blk_trace;
+	struct blk_io_trace_remap r;
+
+	if (likely(!bt))
+		return;
+
+	r.device = cpu_to_be32(dev);
+	r.device_from = cpu_to_be32(bio->bi_bdev->bd_dev);
+	r.sector = cpu_to_be64(to);
+
+	__blk_add_trace(bt, from, bio->bi_size, bio->bi_rw, BLK_TA_REMAP,
+			!bio_flagged(bio, BIO_UPTODATE), sizeof(r), &r);
+}
+
+/**
+ * blk_add_driver_data - Add binary message with driver-specific data
+ * @q:		queue the io is for
+ * @rq:		io request
+ * @data:	driver-specific data
+ * @len:	length of driver-specific data
+ *
+ * Description:
+ *     Some drivers might want to write driver-specific data per request.
+ *
+ **/
+void blk_add_driver_data(struct request_queue *q,
+			 struct request *rq,
+			 void *data, size_t len)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (likely(!bt))
+		return;
+
+	if (blk_pc_request(rq))
+		__blk_add_trace(bt, 0, rq->data_len, 0, BLK_TA_DRV_DATA,
+				rq->errors, len, data);
+	else
+		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9,
+				0, BLK_TA_DRV_DATA, rq->errors, len, data);
+}
+EXPORT_SYMBOL_GPL(blk_add_driver_data);
+
+static int blk_register_tracepoints(void)
+{
+	int ret;
+
+	ret = register_trace_block_rq_abort(blk_add_trace_rq_abort);
+	WARN_ON(ret);
+	ret = register_trace_block_rq_insert(blk_add_trace_rq_insert);
+	WARN_ON(ret);
+	ret = register_trace_block_rq_issue(blk_add_trace_rq_issue);
+	WARN_ON(ret);
+	ret = register_trace_block_rq_requeue(blk_add_trace_rq_requeue);
+	WARN_ON(ret);
+	ret = register_trace_block_rq_complete(blk_add_trace_rq_complete);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_bounce(blk_add_trace_bio_bounce);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_complete(blk_add_trace_bio_complete);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_backmerge(blk_add_trace_bio_backmerge);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_frontmerge(blk_add_trace_bio_frontmerge);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_queue(blk_add_trace_bio_queue);
+	WARN_ON(ret);
+	ret = register_trace_block_getrq(blk_add_trace_getrq);
+	WARN_ON(ret);
+	ret = register_trace_block_sleeprq(blk_add_trace_sleeprq);
+	WARN_ON(ret);
+	ret = register_trace_block_plug(blk_add_trace_plug);
+	WARN_ON(ret);
+	ret = register_trace_block_unplug_timer(blk_add_trace_unplug_timer);
+	WARN_ON(ret);
+	ret = register_trace_block_unplug_io(blk_add_trace_unplug_io);
+	WARN_ON(ret);
+	ret = register_trace_block_split(blk_add_trace_split);
+	WARN_ON(ret);
+	ret = register_trace_block_remap(blk_add_trace_remap);
+	WARN_ON(ret);
+	return 0;
+}
+
+static void blk_unregister_tracepoints(void)
+{
+	unregister_trace_block_remap(blk_add_trace_remap);
+	unregister_trace_block_split(blk_add_trace_split);
+	unregister_trace_block_unplug_io(blk_add_trace_unplug_io);
+	unregister_trace_block_unplug_timer(blk_add_trace_unplug_timer);
+	unregister_trace_block_plug(blk_add_trace_plug);
+	unregister_trace_block_sleeprq(blk_add_trace_sleeprq);
+	unregister_trace_block_getrq(blk_add_trace_getrq);
+	unregister_trace_block_bio_queue(blk_add_trace_bio_queue);
+	unregister_trace_block_bio_frontmerge(blk_add_trace_bio_frontmerge);
+	unregister_trace_block_bio_backmerge(blk_add_trace_bio_backmerge);
+	unregister_trace_block_bio_complete(blk_add_trace_bio_complete);
+	unregister_trace_block_bio_bounce(blk_add_trace_bio_bounce);
+	unregister_trace_block_rq_complete(blk_add_trace_rq_complete);
+	unregister_trace_block_rq_requeue(blk_add_trace_rq_requeue);
+	unregister_trace_block_rq_issue(blk_add_trace_rq_issue);
+	unregister_trace_block_rq_insert(blk_add_trace_rq_insert);
+	unregister_trace_block_rq_abort(blk_add_trace_rq_abort);
+
+	tracepoint_synchronize_unregister();
+}
diff --git a/block/elevator.c b/block/elevator.c
index 9ac82dd..530fcfe 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -33,6 +33,7 @@
 #include <linux/compiler.h>
 #include <linux/delay.h>
 #include <linux/blktrace_api.h>
+#include <trace/block.h>
 #include <linux/hash.h>
 #include <linux/uaccess.h>
 
@@ -586,7 +587,7 @@ void elv_insert(struct request_queue *q, struct request *rq, int where)
 	unsigned ordseq;
 	int unplug_it = 1;
 
-	blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+	trace_block_rq_insert(q, rq);
 
 	rq->q = q;
 
@@ -772,7 +773,7 @@ struct request *elv_next_request(struct request_queue *q)
 			 * not be passed by new incoming requests
 			 */
 			rq->cmd_flags |= REQ_STARTED;
-			blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+			trace_block_rq_issue(q, rq);
 		}
 
 		if (!q->boundary_rq || q->boundary_rq == rq) {
@@ -921,7 +922,7 @@ void elv_abort_queue(struct request_queue *q)
 	while (!list_empty(&q->queue_head)) {
 		rq = list_entry_rq(q->queue_head.next);
 		rq->cmd_flags |= REQ_QUIET;
-		blk_add_trace_rq(q, rq, BLK_TA_ABORT);
+		trace_block_rq_abort(q, rq);
 		__blk_end_request(rq, -EIO, blk_rq_bytes(rq));
 	}
 }
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index c99e472..d23fda1 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -21,6 +21,7 @@
 #include <linux/idr.h>
 #include <linux/hdreg.h>
 #include <linux/blktrace_api.h>
+#include <trace/block.h>
 
 #define DM_MSG_PREFIX "core"
 
@@ -504,8 +505,7 @@ static void dec_pending(struct dm_io *io, int error)
 		end_io_acct(io);
 
 		if (io->error != DM_ENDIO_REQUEUE) {
-			blk_add_trace_bio(io->md->queue, io->bio,
-					  BLK_TA_COMPLETE);
+			trace_block_bio_complete(io->md->queue, io->bio);
 
 			bio_endio(io->bio, io->error);
 		}
@@ -598,7 +598,7 @@ static void __map_bio(struct dm_target *ti, struct bio *clone,
 	if (r == DM_MAPIO_REMAPPED) {
 		/* the bio has been remapped so dispatch it */
 
-		blk_add_trace_remap(bdev_get_queue(clone->bi_bdev), clone,
+		trace_block_remap(bdev_get_queue(clone->bi_bdev), clone,
 				    tio->io->bio->bi_bdev->bd_dev,
 				    clone->bi_sector, sector);
 
diff --git a/fs/bio.c b/fs/bio.c
index 77a55bc..060859c 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -26,6 +26,7 @@
 #include <linux/mempool.h>
 #include <linux/workqueue.h>
 #include <linux/blktrace_api.h>
+#include <trace/block.h>
 #include <scsi/sg.h>		/* for struct sg_iovec */
 
 static struct kmem_cache *bio_slab __read_mostly;
@@ -1263,7 +1264,7 @@ struct bio_pair *bio_split(struct bio *bi, int first_sectors)
 	if (!bp)
 		return bp;
 
-	blk_add_trace_pdu_int(bdev_get_queue(bi->bi_bdev), BLK_TA_SPLIT, bi,
+	trace_block_split(bdev_get_queue(bi->bi_bdev), bi,
 				bi->bi_sector + first_sectors);
 
 	BUG_ON(bi->bi_vcnt != 1);
diff --git a/include/linux/blktrace_api.h b/include/linux/blktrace_api.h
index bdf505d..1dba349 100644
--- a/include/linux/blktrace_api.h
+++ b/include/linux/blktrace_api.h
@@ -160,7 +160,6 @@ struct blk_trace {
 
 extern int blk_trace_ioctl(struct block_device *, unsigned, char __user *);
 extern void blk_trace_shutdown(struct request_queue *);
-extern void __blk_add_trace(struct blk_trace *, sector_t, int, int, u32, int, int, void *);
 extern int do_blk_trace_setup(struct request_queue *q,
 	char *name, dev_t dev, struct blk_user_trace_setup *buts);
 extern void __trace_note_message(struct blk_trace *, const char *fmt, ...);
@@ -186,168 +185,8 @@ extern void __trace_note_message(struct blk_trace *, const char *fmt, ...);
 	} while (0)
 #define BLK_TN_MAX_MSG		128
 
-/**
- * blk_add_trace_rq - Add a trace for a request oriented action
- * @q:		queue the io is for
- * @rq:		the source request
- * @what:	the action
- *
- * Description:
- *     Records an action against a request. Will log the bio offset + size.
- *
- **/
-static inline void blk_add_trace_rq(struct request_queue *q, struct request *rq,
-				    u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-	int rw = rq->cmd_flags & 0x03;
-
-	if (likely(!bt))
-		return;
-
-	if (blk_discard_rq(rq))
-		rw |= (1 << BIO_RW_DISCARD);
-
-	if (blk_pc_request(rq)) {
-		what |= BLK_TC_ACT(BLK_TC_PC);
-		__blk_add_trace(bt, 0, rq->data_len, rw, what, rq->errors, sizeof(rq->cmd), rq->cmd);
-	} else  {
-		what |= BLK_TC_ACT(BLK_TC_FS);
-		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9, rw, what, rq->errors, 0, NULL);
-	}
-}
-
-/**
- * blk_add_trace_bio - Add a trace for a bio oriented action
- * @q:		queue the io is for
- * @bio:	the source bio
- * @what:	the action
- *
- * Description:
- *     Records an action against a bio. Will log the bio offset + size.
- *
- **/
-static inline void blk_add_trace_bio(struct request_queue *q, struct bio *bio,
-				     u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-
-	if (likely(!bt))
-		return;
-
-	__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what, !bio_flagged(bio, BIO_UPTODATE), 0, NULL);
-}
-
-/**
- * blk_add_trace_generic - Add a trace for a generic action
- * @q:		queue the io is for
- * @bio:	the source bio
- * @rw:		the data direction
- * @what:	the action
- *
- * Description:
- *     Records a simple trace
- *
- **/
-static inline void blk_add_trace_generic(struct request_queue *q,
-					 struct bio *bio, int rw, u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-
-	if (likely(!bt))
-		return;
-
-	if (bio)
-		blk_add_trace_bio(q, bio, what);
-	else
-		__blk_add_trace(bt, 0, 0, rw, what, 0, 0, NULL);
-}
-
-/**
- * blk_add_trace_pdu_int - Add a trace for a bio with an integer payload
- * @q:		queue the io is for
- * @what:	the action
- * @bio:	the source bio
- * @pdu:	the integer payload
- *
- * Description:
- *     Adds a trace with some integer payload. This might be an unplug
- *     option given as the action, with the depth at unplug time given
- *     as the payload
- *
- **/
-static inline void blk_add_trace_pdu_int(struct request_queue *q, u32 what,
-					 struct bio *bio, unsigned int pdu)
-{
-	struct blk_trace *bt = q->blk_trace;
-	__be64 rpdu = cpu_to_be64(pdu);
-
-	if (likely(!bt))
-		return;
-
-	if (bio)
-		__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what, !bio_flagged(bio, BIO_UPTODATE), sizeof(rpdu), &rpdu);
-	else
-		__blk_add_trace(bt, 0, 0, 0, what, 0, sizeof(rpdu), &rpdu);
-}
-
-/**
- * blk_add_trace_remap - Add a trace for a remap operation
- * @q:		queue the io is for
- * @bio:	the source bio
- * @dev:	target device
- * @from:	source sector
- * @to:		target sector
- *
- * Description:
- *     Device mapper or raid target sometimes need to split a bio because
- *     it spans a stripe (or similar). Add a trace for that action.
- *
- **/
-static inline void blk_add_trace_remap(struct request_queue *q, struct bio *bio,
-				       dev_t dev, sector_t from, sector_t to)
-{
-	struct blk_trace *bt = q->blk_trace;
-	struct blk_io_trace_remap r;
-
-	if (likely(!bt))
-		return;
-
-	r.device = cpu_to_be32(dev);
-	r.device_from = cpu_to_be32(bio->bi_bdev->bd_dev);
-	r.sector = cpu_to_be64(to);
-
-	__blk_add_trace(bt, from, bio->bi_size, bio->bi_rw, BLK_TA_REMAP, !bio_flagged(bio, BIO_UPTODATE), sizeof(r), &r);
-}
-
-/**
- * blk_add_driver_data - Add binary message with driver-specific data
- * @q:		queue the io is for
- * @rq:		io request
- * @data:	driver-specific data
- * @len:	length of driver-specific data
- *
- * Description:
- *     Some drivers might want to write driver-specific data per request.
- *
- **/
-static inline void blk_add_driver_data(struct request_queue *q,
-				       struct request *rq,
-				       void *data, size_t len)
-{
-	struct blk_trace *bt = q->blk_trace;
-
-	if (likely(!bt))
-		return;
-
-	if (blk_pc_request(rq))
-		__blk_add_trace(bt, 0, rq->data_len, 0, BLK_TA_DRV_DATA,
-				rq->errors, len, data);
-	else
-		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9,
-				0, BLK_TA_DRV_DATA, rq->errors, len, data);
-}
-
+extern void blk_add_driver_data(struct request_queue *q, struct request *rq,
+				void *data, size_t len);
 extern int blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
 			   char __user *arg);
 extern int blk_trace_startstop(struct request_queue *q, int start);
@@ -356,13 +195,8 @@ extern int blk_trace_remove(struct request_queue *q);
 #else /* !CONFIG_BLK_DEV_IO_TRACE */
 #define blk_trace_ioctl(bdev, cmd, arg)		(-ENOTTY)
 #define blk_trace_shutdown(q)			do { } while (0)
-#define blk_add_trace_rq(q, rq, what)		do { } while (0)
-#define blk_add_trace_bio(q, rq, what)		do { } while (0)
-#define blk_add_trace_generic(q, rq, rw, what)	do { } while (0)
-#define blk_add_trace_pdu_int(q, what, bio, pdu)	do { } while (0)
-#define blk_add_trace_remap(q, bio, dev, f, t)	do {} while (0)
-#define blk_add_driver_data(q, rq, data, len)	do {} while (0)
 #define do_blk_trace_setup(q, name, dev, buts)	(-ENOTTY)
+#define blk_add_driver_data(q, rq, data, len)	do {} while (0)
 #define blk_trace_setup(q, name, dev, arg)	(-ENOTTY)
 #define blk_trace_startstop(q, start)		(-ENOTTY)
 #define blk_trace_remove(q)			(-ENOTTY)
diff --git a/include/trace/block.h b/include/trace/block.h
new file mode 100644
index 0000000..3cc2675
--- /dev/null
+++ b/include/trace/block.h
@@ -0,0 +1,60 @@
+#ifndef _TRACE_BLOCK_H
+#define _TRACE_BLOCK_H
+
+#include <linux/blkdev.h>
+#include <linux/tracepoint.h>
+
+DEFINE_TRACE(block_rq_abort,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_rq_insert,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_rq_issue,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_rq_requeue,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_rq_complete,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_bio_bounce,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_bio_complete,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_bio_backmerge,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_bio_frontmerge,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_bio_queue,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_getrq,
+	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
+	TPARGS(q, bio, rw));
+DEFINE_TRACE(block_sleeprq,
+	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
+	TPARGS(q, bio, rw));
+DEFINE_TRACE(block_plug,
+	TPPROTO(struct request_queue *q),
+	TPARGS(q));
+DEFINE_TRACE(block_unplug_timer,
+	TPPROTO(struct request_queue *q),
+	TPARGS(q));
+DEFINE_TRACE(block_unplug_io,
+	TPPROTO(struct request_queue *q),
+	TPARGS(q));
+DEFINE_TRACE(block_split,
+	TPPROTO(struct request_queue *q, struct bio *bio, unsigned int pdu),
+	TPARGS(q, bio, pdu));
+DEFINE_TRACE(block_remap,
+	TPPROTO(struct request_queue *q, struct bio *bio, dev_t dev,
+		sector_t from, sector_t to),
+	TPARGS(q, bio, dev, from, to));
+
+#endif
diff --git a/mm/bounce.c b/mm/bounce.c
index 06722c4..bd1caaa 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -14,6 +14,7 @@
 #include <linux/hash.h>
 #include <linux/highmem.h>
 #include <linux/blktrace_api.h>
+#include <trace/block.h>
 #include <asm/tlbflush.h>
 
 #define POOL_SIZE	64
@@ -222,7 +223,7 @@ static void __blk_queue_bounce(struct request_queue *q, struct bio **bio_orig,
 	if (!bio)
 		return;
 
-	blk_add_trace_bio(q, *bio_orig, BLK_TA_BOUNCE);
+	trace_block_bio_bounce(q, *bio_orig);
 
 	/*
 	 * at least one page was bounced, fill in possible non-highmem
-- 
1.6.0.4.771.gef3b3

Re: linux-next: block tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Jens,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> In file included from block/blk-core.c:31:
> include/trace/block.h:9:15: error: macro "DEFINE_TRACE" passed 3 arguments, but takes just 1
> In file included from block/blk-core.c:31:
> include/trace/block.h:7: warning: data definition has no type or storage class
> include/trace/block.h:7: warning: type defaults to 'int' in declaration of 'DEFINE_TRACE'
> 
> and many more.  This is caused by commit 
> 714d010b5c249c2e9282515e0a2309a61ababbf4 ("blktrace: port to 
> tracepoints") interacting with commit 
> 7e066fb870fcd1025ec3ba7bbde5d541094f4ce1 ("tracepoints: add 
> DECLARE_TRACE () and DEFINE_TRACE()") which entered linux-next for 
> the first time today via the ftrace tree. This latter commit has 
> changed the tracepoints API.
> 
> I will drop the block tree for today.  I am not sure of the way forward.

hm, i think that might be interaction between ftrace tree updates and 
blktrace?

Jens, would it be fine with you if we created a new 
tip/tracing/blktrace branch and picked up your changes and kept it all 
uptodate and merged with the ftrace tree? It should merge fine with 
other bits of the block tree, right? (the tracepoints are in rather 
stable spots of the code i think)

the other direction (you merging ftrace bits) doesnt look too hot, 
you'd have to pick up:

   95 files changed, 5308 insertions(+), 1603 deletions(-)

	Ingo

linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens,

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

In file included from block/blk-core.c:31:
include/trace/block.h:9:15: error: macro "DEFINE_TRACE" passed 3 arguments, but takes just 1
In file included from block/blk-core.c:31:
include/trace/block.h:7: warning: data definition has no type or storage class
include/trace/block.h:7: warning: type defaults to 'int' in declaration of 'DEFINE_TRACE'

and many more.  This is caused by commit
714d010b5c249c2e9282515e0a2309a61ababbf4 ("blktrace: port to
tracepoints") interacting with commit
7e066fb870fcd1025ec3ba7bbde5d541094f4ce1 ("tracepoints: add DECLARE_TRACE
() and DEFINE_TRACE()") which entered linux-next for the first time today
via the ftrace tree. This latter commit has changed the tracepoints API.

I will drop the block tree for today.  I am not sure of the way forward.
-- 
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 Sun, Nov 09 2008, malahal@us.ibm.com wrote:
> Stephen Rothwell [sfr@canb.auug.org.au] wrote:
> > Hi Jens,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > block/blk-timeout.c: In function 'blk_rq_timed_out_timer':
> > block/blk-timeout.c:140: error: 'next_set' undeclared (first use in this function)
> > 
> > Caused by commit 66f067c93b0eefc8613fd7a91cd6853e2bf48806 ("block:
> > optimizations in blk_rq_timed_out_timer()").  Clearly not even
> > compiled ...
> > 
> 
> I compiled the code with the following patch on i386 arch. Should work
> on powerpc too!
> 
> Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
> 
> 
> diff -r b824bf5f19d4 block/blk-timeout.c
> --- a/block/blk-timeout.c	Sun Nov 09 20:15:10 2008 -0800
> +++ b/block/blk-timeout.c	Sun Nov 09 20:18:07 2008 -0800
> @@ -137,7 +137,7 @@
>  	 * bump ->deadline to 1 so we can detect if the timer was ever added
>  	 * or not. See comment in blk_add_timer()
>  	 */
> -	if (next_set)
> +	if (next)
>  		mod_timer(&q->timeout, round_jiffies_up(next));
>  
>  	spin_unlock_irqrestore(q->queue_lock, flags);

Duh thanks, I'll rebase and fix it!

-- 
Jens Axboe

Re: linux-next: block tree build failure

[malahal]

Stephen Rothwell [sfr@canb.auug.org.au] wrote:
> Hi Jens,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> block/blk-timeout.c: In function 'blk_rq_timed_out_timer':
> block/blk-timeout.c:140: error: 'next_set' undeclared (first use in this function)
> 
> Caused by commit 66f067c93b0eefc8613fd7a91cd6853e2bf48806 ("block:
> optimizations in blk_rq_timed_out_timer()").  Clearly not even
> compiled ...
> 

I compiled the code with the following patch on i386 arch. Should work
on powerpc too!

Signed-off-by: Malahal Naineni <malahal@us.ibm.com>


diff -r b824bf5f19d4 block/blk-timeout.c
--- a/block/blk-timeout.c	Sun Nov 09 20:15:10 2008 -0800
+++ b/block/blk-timeout.c	Sun Nov 09 20:18:07 2008 -0800
@@ -137,7 +137,7 @@
 	 * bump ->deadline to 1 so we can detect if the timer was ever added
 	 * or not. See comment in blk_add_timer()
 	 */
-	if (next_set)
+	if (next)
 		mod_timer(&q->timeout, round_jiffies_up(next));
 
 	spin_unlock_irqrestore(q->queue_lock, flags);

Re: linux-next: block tree build failure

[malahal]

The original patch is split into two commits and Jen missed to change
'next_set' to 'next' in the first commit! Just changing the 'next_set'
to 'next' should work. I will send a patch very soon.

--Malahal.

Stephen Rothwell [sfr@canb.auug.org.au] wrote:
> Hi Jens,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> block/blk-timeout.c: In function 'blk_rq_timed_out_timer':
> block/blk-timeout.c:140: error: 'next_set' undeclared (first use in this function)
> 
> Caused by commit 66f067c93b0eefc8613fd7a91cd6853e2bf48806 ("block:
> optimizations in blk_rq_timed_out_timer()").  Clearly not even
> compiled ...
> 
> I have dropped the block tree for today.
> -- 
> 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 Thu, Sep 18 2008, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> fs/bio-integrity.c: At top level:
> fs/bio-integrity.c:211: error: conflicting types for 'bdev_get_integrity'
> fs/bio-integrity.c:155: error: previous implicit declaration of 'bdev_get_integrity' was here
> 
> Introduced by commit 1fd75f9b2e1c273ab145c9bf3e7a8afcbd8be87a ("block:
> cleanup some of the integrity stuff in blkdev.h").  I applied the
> following patch.

Woops, sorry about that. I'll update the patch, thanks.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

Hi Jens,

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

fs/bio-integrity.c: At top level:
fs/bio-integrity.c:211: error: conflicting types for 'bdev_get_integrity'
fs/bio-integrity.c:155: error: previous implicit declaration of 'bdev_get_integrity' was here

Introduced by commit 1fd75f9b2e1c273ab145c9bf3e7a8afcbd8be87a ("block:
cleanup some of the integrity stuff in blkdev.h").  I applied the
following patch.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 18 Sep 2008 12:59:18 +1000
Subject: [PATCH] block: bdev_get_integrity needs to be defined earlier

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

diff --git a/fs/bio-integrity.c b/fs/bio-integrity.c
index 78e5b56..ba4ada0 100644
--- a/fs/bio-integrity.c
+++ b/fs/bio-integrity.c
@@ -150,6 +150,11 @@ int bio_integrity_add_page(struct bio *bio, struct page *page,
 }
 EXPORT_SYMBOL(bio_integrity_add_page);
 
+static struct blk_integrity *bdev_get_integrity(struct block_device *bdev)
+{
+	return bdev->bd_disk->integrity;
+}
+
 static int bdev_integrity_enabled(struct block_device *bdev, int rw)
 {
 	struct blk_integrity *bi = bdev_get_integrity(bdev);
@@ -207,11 +212,6 @@ static inline unsigned int bio_integrity_hw_sectors(struct blk_integrity *bi,
 	return sectors;
 }
 
-static struct blk_integrity *bdev_get_integrity(struct block_device *bdev)
-{
-	return bdev->bd_disk->integrity;
-}
-
 /**
  * bio_integrity_tag_size - Retrieve integrity tag space
  * @bio:	bio to inspect
-- 
1.5.6.5

Re: linux-next: block tree build failure

[Jens Axboe]

On Sun, Sep 14 2008, Alex Dubov wrote:
> 
> 
> 
> --- On Sun, 9/14/08, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Subject: linux-next: block tree build failure
> > To: "Jens Axboe" <jens.axboe@oracle.com>
> > Cc: linux-next@vger.kernel.org, "Alex Dubov" <oakad@yahoo.com>, "Tejun Heo" <tj@kernel.org>
> > Date: Sunday, September 14, 2008, 10:18 PM
> > Hi Jens,
> > 
> > Today's linux-next build (x86_64 allmodconfig) failed
> > like this:
> > 
> > drivers/memstick/core/mspro_block.c: In function
> > 'mspro_block_disk_release':
> > drivers/memstick/core/mspro_block.c:200: error:
> > 'MEMSTICK_PART_SHIFT' undeclared (first use in this
> > function)
> > 
> 
> That's funny. My last patch replaced all occurrences of this macro.

Doh it's me, fixed up the git merge conflict wrong. Thanks for the
report.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Alex Dubov]

--- On Sun, 9/14/08, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Subject: linux-next: block tree build failure
> To: "Jens Axboe" <jens.axboe@oracle.com>
> Cc: linux-next@vger.kernel.org, "Alex Dubov" <oakad@yahoo.com>, "Tejun Heo" <tj@kernel.org>
> Date: Sunday, September 14, 2008, 10:18 PM
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed
> like this:
> 
> drivers/memstick/core/mspro_block.c: In function
> 'mspro_block_disk_release':
> drivers/memstick/core/mspro_block.c:200: error:
> 'MEMSTICK_PART_SHIFT' undeclared (first use in this
> function)
> 

That's funny. My last patch replaced all occurrences of this macro.



      

linux-next: block tree build failure

[Stephen Rothwell]

Hi Jens,

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

drivers/memstick/core/mspro_block.c: In function 'mspro_block_disk_release':
drivers/memstick/core/mspro_block.c:200: error: 'MEMSTICK_PART_SHIFT' undeclared (first use in this function)

Caused by the interaction of commit
1f773dd9deada2ad7efdd71577beb59fae80cdef ("block: don't depend on
consecutive minor space") from the block tree with commit
8e82f8c34b1759ae0d80fe96101746ec51fb1ba4 ("memstick: fix MSProHG 8-bit
interface mode support") form Linus' tree.

The latter removed the definition of MEMSTICK_PART_SHIFT while the former
added a reference.  I added the following patch.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 15 Sep 2008 15:13:07 +1000
Subject: [PATCH] block: fix build of mspro_block

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

diff --git a/drivers/memstick/core/mspro_block.c b/drivers/memstick/core/mspro_block.c
index 055c5f9..82bf649 100644
--- a/drivers/memstick/core/mspro_block.c
+++ b/drivers/memstick/core/mspro_block.c
@@ -197,7 +197,7 @@ static int mspro_block_bd_open(struct inode *inode, struct file *filp)
 static int mspro_block_disk_release(struct gendisk *disk)
 {
 	struct mspro_block_data *msb = disk->private_data;
-	int disk_id = MINOR(disk_devt(disk)) >> MEMSTICK_PART_SHIFT;
+	int disk_id = MINOR(disk_devt(disk)) >> MSPRO_BLOCK_PART_SHIFT;
 
 	mutex_lock(&mspro_block_disk_lock);
 
-- 
1.5.6.5

Re: linux-next: block tree build failure

[Andrew Morton]

On Wed, 03 Sep 2008 19:29:28 +0200 Tejun Heo <tj@kernel.org> wrote:

> Andrew Morton wrote:
> > On Wed, 03 Sep 2008 18:27:12 +0200 Tejun Heo <tj@kernel.org> wrote:
> > 
> >> Andrew Morton wrote:
> >>> @@ -674,6 +674,8 @@ static void *disk_seqf_next(struct seq_f
> >>>  	struct device *dev;
> >>>  
> >>>  	(*pos)++;
> >>> +	if (seqf->private == NULL)
> >>> +		return NULL;
> >>>  	dev = class_dev_iter_next(seqf->private);
> >>>  	if (dev)
> >>>  		return dev_to_disk(dev);
> >> Ehh... next can't be called with NULL private.
> > 
> > My computer disagreed ;)
> > 
> >>  Where can I take a look
> >> at the merged tree?  There have been two separate changes to that area
> >> of code.  Ad-hoc behavior fix for 2.6.27 and general clean up scheduled
> >> for 2.6.28 and the two use seqf->private for different purposes.  Maybe
> >> the two got mixed up?
> > 
> > It's linux-next-20080903
> 
> Hmmm... Can't see how it can happen and can't reproduce it either.
> seqf->private is initialized from disk_seqf_start().  If allocation
> fails, it returns ERR_PTR(-ENOMEM).  On error return from start, both
> seq_file::seq_read and seq_file::traverse() immediately calls ->stop()
> and fails, so ->next can't really be called with null ->private.
> 
> Just to make sure, I made disk_seqf_start() fail and it works (or
> rather fails) as expected.

I must have screwed up my kernel versions.  next-20080903 is OK.

Re: linux-next: block tree build failure

[Tejun Heo]

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

Andrew Morton wrote:
> On Wed, 03 Sep 2008 18:27:12 +0200 Tejun Heo <tj@kernel.org> wrote:
> 
>> Andrew Morton wrote:
>>> @@ -674,6 +674,8 @@ static void *disk_seqf_next(struct seq_f
>>>  	struct device *dev;
>>>  
>>>  	(*pos)++;
>>> +	if (seqf->private == NULL)
>>> +		return NULL;
>>>  	dev = class_dev_iter_next(seqf->private);
>>>  	if (dev)
>>>  		return dev_to_disk(dev);
>> Ehh... next can't be called with NULL private.
> 
> My computer disagreed ;)
> 
>>  Where can I take a look
>> at the merged tree?  There have been two separate changes to that area
>> of code.  Ad-hoc behavior fix for 2.6.27 and general clean up scheduled
>> for 2.6.28 and the two use seqf->private for different purposes.  Maybe
>> the two got mixed up?
> 
> It's linux-next-20080903

Hmmm... Can't see how it can happen and can't reproduce it either.
seqf->private is initialized from disk_seqf_start().  If allocation
fails, it returns ERR_PTR(-ENOMEM).  On error return from start, both
seq_file::seq_read and seq_file::traverse() immediately calls ->stop()
and fails, so ->next can't really be called with null ->private.

Just to make sure, I made disk_seqf_start() fail and it works (or
rather fails) as expected.

Argggghh... strange.  Can you please try the attached patch and post
the log?

Thanks.

-- 
tejun

[-- Attachment #2: genhd-next-dbg.patch --]
[-- Type: text/x-patch, Size: 1367 bytes --]

diff --git a/block/genhd.c b/block/genhd.c
index ed926b7..b76c56b 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -655,8 +655,11 @@ static void *disk_seqf_start(struct seq_file *seqf, loff_t *pos)
 	struct device *dev;
 
 	iter = kmalloc(sizeof(*iter), GFP_KERNEL);
-	if (!iter)
+	if (!iter) {
+		printk("XXX disk_seqf_start: -ENOMEM\n");
 		return ERR_PTR(-ENOMEM);
+	}
+	printk("XXX disk_seqf_start: iter=%p pos=%lld\n", iter, (long long)*pos);
 
 	seqf->private = iter;
 	class_dev_iter_init(iter, &block_class, NULL, &disk_type);
@@ -673,6 +676,8 @@ static void *disk_seqf_next(struct seq_file *seqf, void *v, loff_t *pos)
 {
 	struct device *dev;
 
+	printk("XXX disk_seqf_next: iter=%p pos=%lld\n",
+	       seqf->private, (long long)*pos);
 	(*pos)++;
 	dev = class_dev_iter_next(seqf->private);
 	if (dev)
@@ -685,6 +690,7 @@ static void disk_seqf_stop(struct seq_file *seqf, void *v)
 {
 	struct class_dev_iter *iter = seqf->private;
 
+	printk("XXX disk_seqf_stop: iter=%p\n", seqf->private);
 	/* stop is called even after start failed :-( */
 	if (iter) {
 		class_dev_iter_exit(iter);
@@ -697,7 +703,7 @@ static void *show_partition_start(struct seq_file *seqf, loff_t *pos)
 	static void *p;
 
 	p = disk_seqf_start(seqf, pos);
-	if (!IS_ERR(p) && p)
+	if (!IS_ERR(p) && p && !*pos)
 		seq_puts(seqf, "major minor  #blocks  name\n\n");
 	return p;
 }

Re: linux-next: block tree build failure

[Andrew Morton]

On Wed, 03 Sep 2008 18:27:12 +0200 Tejun Heo <tj@kernel.org> wrote:

> Andrew Morton wrote:
> > @@ -674,6 +674,8 @@ static void *disk_seqf_next(struct seq_f
> >  	struct device *dev;
> >  
> >  	(*pos)++;
> > +	if (seqf->private == NULL)
> > +		return NULL;
> >  	dev = class_dev_iter_next(seqf->private);
> >  	if (dev)
> >  		return dev_to_disk(dev);
> 
> Ehh... next can't be called with NULL private.

My computer disagreed ;)

>  Where can I take a look
> at the merged tree?  There have been two separate changes to that area
> of code.  Ad-hoc behavior fix for 2.6.27 and general clean up scheduled
> for 2.6.28 and the two use seqf->private for different purposes.  Maybe
> the two got mixed up?

It's linux-next-20080903

Re: linux-next: block tree build failure

[Tejun Heo]

Andrew Morton wrote:
> @@ -674,6 +674,8 @@ static void *disk_seqf_next(struct seq_f
>  	struct device *dev;
>  
>  	(*pos)++;
> +	if (seqf->private == NULL)
> +		return NULL;
>  	dev = class_dev_iter_next(seqf->private);
>  	if (dev)
>  		return dev_to_disk(dev);

Ehh... next can't be called with NULL private.  Where can I take a look
at the merged tree?  There have been two separate changes to that area
of code.  Ad-hoc behavior fix for 2.6.27 and general clean up scheduled
for 2.6.28 and the two use seqf->private for different purposes.  Maybe
the two got mixed up?

Thanks.

-- 
tejun

Re: linux-next: block tree build failure

[Andrew Morton]

On Wed, 3 Sep 2008 09:07:24 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:

> On Wed, Sep 03 2008, Andrew Morton wrote:
> > On Wed, 3 Sep 2008 08:34:21 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > On Wed, Sep 03 2008, Stephen Rothwell wrote:
> > > > Hi Jens,
> > > > 
> > > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > > > 
> > > > block/genhd.c: In function 'show_partition':
> > > > block/genhd.c:718: error: 'struct hd_struct' has no member named 'private'
> > > > block/genhd.c:719: warning: passing argument 1 of 'seq_puts' from incompatible pointer type
> > > > block/genhd.c:720: error: 'struct hd_struct' has no member named 'private'
> > > > 
> > > > Caused by the merge because commit
> > > > ddef43a843f620c6742a06633739887a901ec06b ("block: restore original
> > > > behavior of /proc/partition when there's no partition") added references
> > > > to the 'private' member.  I removed the offending section of code (see
> > > > below) assuming the fix referred to in the comment has be done in the
> > > > block tree.
> > > 
> > > I'm in the very midst of updating to latest -git, I'll push it out in 5
> > > minutes or so. It'll also solve the two latest conflicts you saw.
> > > 
> > 
> > I get a nasty git reject around disk_seqf_next() from -next-20080902
> > and have yet to find a fix which doesn't oops all over the place. 
> > 
> > Am presently discommoded.  Please let this be fixed in -next-20080903 :(
> 
> I've updated for-2.6.28 (and thus for-next and for-akpm), we also had a
> couple of merge errors that resulted in bad bisect compiles. So I think
> it should be ok now.
> 

It's still oopsing all over the place.

From: Andrew Morton <akpm@linux-foundation.org>

BUG: unable to handle kernel NULL pointer dereference at 00000000
IP: [<c03cb7fb>] klist_next+0xb/0xb0
*pde = 00000000 
Oops: 0000 [#1] SMP 
last sysfs file: 
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:

Pid: 1262, comm: mount Not tainted (2.6.27-rc5 #6)
EIP: 0060:[<c03cb7fb>] EFLAGS: 00010286 CPU: 0
EIP is at klist_next+0xb/0xb0
EAX: 00000000 EBX: 00000000 ECX: f61d7f2c EDX: f6aa0700
ESI: 00000000 EDI: f6aa0700 EBP: f61d7ef8 ESP: f61d7ee4
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process mount (pid: 1262, ti=f61d6000 task=f667b6b0 task.ti=f61d6000)
Stack: f61d7f00 fffffff4 00000000 f64b5b40 f6aa0700 f61d7f04 c02d03a7 c03f42dc 
       f61d7f0c c027fcc2 f61d7f48 c01a7e1e 00000400 b7fa6000 f65406d8 f64b5b60 
       00000000 0000003b 00000001 00000000 00000000 00000000 f7012da0 fffffffb 
Call Trace:
 [<c02d03a7>] ? class_dev_iter_next+0x17/0x40
 [<c027fcc2>] ? disk_seqf_next+0x12/0x20
 [<c01a7e1e>] ? seq_read+0x1ee/0x2d0
 [<c01a7c30>] ? seq_read+0x0/0x2d0
 [<c01c4a8c>] ? proc_reg_read+0x5c/0x90
 [<c018f574>] ? vfs_read+0x94/0x150
 [<c028db28>] ? copy_to_user+0x48/0x60
 [<c01c4a30>] ? proc_reg_read+0x0/0x90
 [<c018f96d>] ? sys_read+0x3d/0x70
 [<c010318d>] ? sysenter_do_call+0x12/0x31
 =======================
Code: 55 83 c0 0c 89 e5 ba 90 b9 3c c0 e8 30 d3 eb ff 5d c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 57 56 89 c6 53 83 ec 08 <8b> 00 8b 7e 04 8b 50 28 89 55 f0 e8 95 30 01 00 85 ff 74 71 8b 
EIP: [<c03cb7fb>] klist_next+0xb/0xb0 SS:ESP 0068:f61d7ee4


Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 block/genhd.c |    2 ++
 1 file changed, 2 insertions(+)

diff -puN block/genhd.c~a block/genhd.c
--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -674,6 +674,8 @@ static void *disk_seqf_next(struct seq_f
 	struct device *dev;
 
 	(*pos)++;
+	if (seqf->private == NULL)
+		return NULL;
 	dev = class_dev_iter_next(seqf->private);
 	if (dev)
 		return dev_to_disk(dev);
_

Re: linux-next: block tree build failure

[Stephen Rothwell]

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

Hi Jens, Andrew,

On Wed, 3 Sep 2008 09:07:24 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> On Wed, Sep 03 2008, Andrew Morton wrote:
> > 
> > I get a nasty git reject around disk_seqf_next() from -next-20080902
> > and have yet to find a fix which doesn't oops all over the place. 
> > 
> > Am presently discommoded.  Please let this be fixed in -next-20080903 :(
> 
> I've updated for-2.6.28 (and thus for-next and for-akpm), we also had a
> couple of merge errors that resulted in bad bisect compiles. So I think
> it should be ok now.

OK, I have reverted the previous merge of the block tree and merged the
new one (makes the linux-next tree look a little strange today, but
hopefully helps Andrew out).

I haven't released this yet (it will be -20080903 obviously) as I am
still build testing ...

-- 
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, Sep 03 2008, Andrew Morton wrote:
> On Wed, 3 Sep 2008 08:34:21 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > On Wed, Sep 03 2008, Stephen Rothwell wrote:
> > > Hi Jens,
> > > 
> > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > > 
> > > block/genhd.c: In function 'show_partition':
> > > block/genhd.c:718: error: 'struct hd_struct' has no member named 'private'
> > > block/genhd.c:719: warning: passing argument 1 of 'seq_puts' from incompatible pointer type
> > > block/genhd.c:720: error: 'struct hd_struct' has no member named 'private'
> > > 
> > > Caused by the merge because commit
> > > ddef43a843f620c6742a06633739887a901ec06b ("block: restore original
> > > behavior of /proc/partition when there's no partition") added references
> > > to the 'private' member.  I removed the offending section of code (see
> > > below) assuming the fix referred to in the comment has be done in the
> > > block tree.
> > 
> > I'm in the very midst of updating to latest -git, I'll push it out in 5
> > minutes or so. It'll also solve the two latest conflicts you saw.
> > 
> 
> I get a nasty git reject around disk_seqf_next() from -next-20080902
> and have yet to find a fix which doesn't oops all over the place. 
> 
> Am presently discommoded.  Please let this be fixed in -next-20080903 :(

I've updated for-2.6.28 (and thus for-next and for-akpm), we also had a
couple of merge errors that resulted in bad bisect compiles. So I think
it should be ok now.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Andrew Morton]

On Wed, 3 Sep 2008 08:34:21 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:

> On Wed, Sep 03 2008, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > block/genhd.c: In function 'show_partition':
> > block/genhd.c:718: error: 'struct hd_struct' has no member named 'private'
> > block/genhd.c:719: warning: passing argument 1 of 'seq_puts' from incompatible pointer type
> > block/genhd.c:720: error: 'struct hd_struct' has no member named 'private'
> > 
> > Caused by the merge because commit
> > ddef43a843f620c6742a06633739887a901ec06b ("block: restore original
> > behavior of /proc/partition when there's no partition") added references
> > to the 'private' member.  I removed the offending section of code (see
> > below) assuming the fix referred to in the comment has be done in the
> > block tree.
> 
> I'm in the very midst of updating to latest -git, I'll push it out in 5
> minutes or so. It'll also solve the two latest conflicts you saw.
> 

I get a nasty git reject around disk_seqf_next() from -next-20080902
and have yet to find a fix which doesn't oops all over the place. 

Am presently discommoded.  Please let this be fixed in -next-20080903 :(

Re: linux-next: block tree build failure

[Jens Axboe]

On Wed, Sep 03 2008, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> block/genhd.c: In function 'show_partition':
> block/genhd.c:718: error: 'struct hd_struct' has no member named 'private'
> block/genhd.c:719: warning: passing argument 1 of 'seq_puts' from incompatible pointer type
> block/genhd.c:720: error: 'struct hd_struct' has no member named 'private'
> 
> Caused by the merge because commit
> ddef43a843f620c6742a06633739887a901ec06b ("block: restore original
> behavior of /proc/partition when there's no partition") added references
> to the 'private' member.  I removed the offending section of code (see
> below) assuming the fix referred to in the comment has be done in the
> block tree.

I'm in the very midst of updating to latest -git, I'll push it out in 5
minutes or so. It'll also solve the two latest conflicts you saw.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

Hi Jens,

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

block/genhd.c: In function 'show_partition':
block/genhd.c:718: error: 'struct hd_struct' has no member named 'private'
block/genhd.c:719: warning: passing argument 1 of 'seq_puts' from incompatible pointer type
block/genhd.c:720: error: 'struct hd_struct' has no member named 'private'

Caused by the merge because commit
ddef43a843f620c6742a06633739887a901ec06b ("block: restore original
behavior of /proc/partition when there's no partition") added references
to the 'private' member.  I removed the offending section of code (see
below) assuming the fix referred to in the comment has be done in the
block tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --git a/block/genhd.c b/block/genhd.c
index 48326f9..0bc4a3e 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -709,17 +709,6 @@ static int show_partition(struct seq_file *seqf, void *v)
 	struct hd_struct *part;
 	char buf[BDEVNAME_SIZE];
 
-	/*
-	 * Print header if start told us to do.  This is to preserve
-	 * the original behavior of not printing header if no
-	 * partition exists.  This hackery will be removed later with
-	 * class iteration clean up.
-	 */
-	if (part->private) {
-		seq_puts(part, "major minor  #blocks  name\n\n");
-		part->private = NULL;
-	}
-
 	/* Don't show non-partitionable removeable devices or empty devices */
 	if (!get_capacity(sgp) || (!disk_partitionable(sgp) &&
 				   (sgp->flags & GENHD_FL_REMOVABLE)))

Re: linux-next: block tree build failure

[Jens Axboe]

On Fri, Aug 29 2008, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/scsi/sg.c: In function 'sg_write_xfer':
> drivers/scsi/sg.c:1862: error: 'iovec_count' undeclared (first use in this function)
> drivers/scsi/sg.c: In function 'sg_remove_scat':
> drivers/scsi/sg.c:1877: error: 'page' undeclared (first use in this function)
> 
> Introduced by commit d9b1190ebc3060e3a6ac1dd8cc3121390d7d71cd ("sg:
> convert the indirect IO path to use the block layer").
> 
> I applied the following patch (which is probably not correct).

Noticed that one too, I'll update the guilty patch.

-- 
Jens Axboe

linux-next: block tree build failure

[Stephen Rothwell]

Hi Jens,

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

drivers/scsi/sg.c: In function 'sg_write_xfer':
drivers/scsi/sg.c:1862: error: 'iovec_count' undeclared (first use in this function)
drivers/scsi/sg.c: In function 'sg_remove_scat':
drivers/scsi/sg.c:1877: error: 'page' undeclared (first use in this function)

Introduced by commit d9b1190ebc3060e3a6ac1dd8cc3121390d7d71cd ("sg:
convert the indirect IO path to use the block layer").

I applied the following patch (which is probably not correct).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 29 Aug 2008 15:05:44 +1000
Subject: [PATCH] block: scsi sg fixes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/sg.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 277680b..6cb2445 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1859,8 +1859,8 @@ sg_write_xfer(Sg_request * srp)
 	     && ((SG_FLAG_NO_DXFER | SG_FLAG_MMAP_IO) & hp->flags)))
 		return 0;
 
-	SCSI_LOG_TIMEOUT(4, printk("sg_write_xfer: num_xfer=%d, iovec_count=%d, k_use_sg=%d\n",
-			  num_xfer, iovec_count, schp->k_use_sg));
+	SCSI_LOG_TIMEOUT(4, printk("sg_write_xfer: num_xfer=%d, k_use_sg=%d\n",
+			  num_xfer, schp->k_use_sg));
 
 	return 0;
 }
@@ -1875,8 +1875,8 @@ sg_remove_scat(Sg_scatter_hold * schp)
 
 			for (k = 0; k < schp->k_use_sg && schp->pages[k]; k++) {
 				SCSI_LOG_TIMEOUT(5, printk(
-				    "sg_remove_scat: k=%d, pg=0x%p\n",
-				    k, page));
+				    "sg_remove_scat: k=%d\n",
+				    k));
 				__free_pages(schp->pages[k], schp->page_order);
 			}
 
-- 
1.5.6.5

Re: linux-next: block tree build failure

[Jens Axboe]

On Fri, Jun 27 2008, Jens Axboe wrote:
> On Fri, Jun 27 2008, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > block/cmd-filter.c: In function 'rcf_set_defaults':
> > block/cmd-filter.c:245: error: 'MAINTENANCE_IN_CMD' undeclared (first use in this function)
> > 
> > Caused by commit e072328e626899abc7179842c0e3f4de68e368c9 ("cmdfilter:
> > extend default read filter") which I have reverted.

Fixed now, shame on Adel for not even compiling a patch he sends for
submission and shame on me for not double checking.

> > We also got lots of:
> > 
> > include/linux/blkdev.h:942: warning: passing argument 2 of 'constant_test_bit' from incompatible pointer type
> > 
> > from the x86_64 allmodconfig build because the flags element of struct
> > blk_integrity is an unsigned short and the bitop routines take a pointer
> > to an unsigned long.
> > 
> > I have reverted commit 1b769a557d6ed0d348656ddad4450525a1b6fdcb ("block:
> > Block layer data integrity support") (and the three that depended on that
> > one: 99b454690844b97c1e550c1609ba7397d506f924 ("block: Data integrity
> > infrastructure documentation"), cacd33a92c8f98041188ea99bdcc12f37ea8fcef
> > ("block: integrity checkpatch cleanups") and
> > 40ea047969676270e47d515468d7f849a9b37fec ("block: integrity cleanups"). 
> 
> I'll fix up these immediately! The flags clearly need to be unsigned
> long, don't know how that got by.

Fixed that by getting rid of the *_bit() operations, there's no need for
atomic bitops.

So everything should be OK now, sorry for the trouble.

-- 
Jens Axboe

Re: linux-next: block tree build failure

[Jens Axboe]

On Fri, Jun 27 2008, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> block/cmd-filter.c: In function 'rcf_set_defaults':
> block/cmd-filter.c:245: error: 'MAINTENANCE_IN_CMD' undeclared (first use in this function)
> 
> Caused by commit e072328e626899abc7179842c0e3f4de68e368c9 ("cmdfilter:
> extend default read filter") which I have reverted.
> 
> We also got lots of:
> 
> include/linux/blkdev.h:942: warning: passing argument 2 of 'constant_test_bit' from incompatible pointer type
> 
> from the x86_64 allmodconfig build because the flags element of struct
> blk_integrity is an unsigned short and the bitop routines take a pointer
> to an unsigned long.
> 
> I have reverted commit 1b769a557d6ed0d348656ddad4450525a1b6fdcb ("block:
> Block layer data integrity support") (and the three that depended on that
> one: 99b454690844b97c1e550c1609ba7397d506f924 ("block: Data integrity
> infrastructure documentation"), cacd33a92c8f98041188ea99bdcc12f37ea8fcef
> ("block: integrity checkpatch cleanups") and
> 40ea047969676270e47d515468d7f849a9b37fec ("block: integrity cleanups"). 

I'll fix up these immediately! The flags clearly need to be unsigned
long, don't know how that got by.

-- 
Jens Axboe