Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: build failure after merge of the block tree
@ 2019-10-28  2:59 Stephen Rothwell
  2019-10-28  3:25 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2019-10-28  2:59 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

Hi all,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/io_uring.c: In function '__io_sqe_files_unregister':
fs/io_uring.c:3010:12: error: invalid storage class for function 'io_sqe_files_unregister'
 3010 | static int io_sqe_files_unregister(struct io_ring_ctx *ctx)
      |            ^~~~~~~~~~~~~~~~~~~~~~~
fs/io_uring.c:3010:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
 3010 | static int io_sqe_files_unregister(struct io_ring_ctx *ctx)
      | ^~~~~~

Caused by commit

  ed9e02e4bad1 ("io_uring: support for larger fixed file sets")

I have used the block tree from next-20191025 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2019-10-28  2:59 linux-next: build failure after merge of the block tree Stephen Rothwell
@ 2019-10-28  3:25 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2019-10-28  3:25 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

On 10/27/19 8:59 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> fs/io_uring.c: In function '__io_sqe_files_unregister':
> fs/io_uring.c:3010:12: error: invalid storage class for function 'io_sqe_files_unregister'
>   3010 | static int io_sqe_files_unregister(struct io_ring_ctx *ctx)
>        |            ^~~~~~~~~~~~~~~~~~~~~~~
> fs/io_uring.c:3010:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
>   3010 | static int io_sqe_files_unregister(struct io_ring_ctx *ctx)
>        | ^~~~~~
> 
> Caused by commit
> 
>    ed9e02e4bad1 ("io_uring: support for larger fixed file sets")
> 
> I have used the block tree from next-20191025 for today.

Ah shoot, forgot to update for-next, I did fix this silly error
yesterday. If you're up for it, pull for-next again in 2 min and I'll
have it updated. If not, I guess it'll be there in the next one. Usually
doesn't matter, only asking because syzbot keeps flagging the same issue
that is also fixed.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2019-07-11 20:17 ` Tejun Heo
@ 2019-07-11 20:36   ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2019-07-11 20:36 UTC (permalink / raw)
  To: Tejun Heo, Stephen Rothwell
  Cc: Jaegeuk Kim, Linux Next Mailing List, Linux Kernel Mailing List, Chao Yu

On 7/11/19 2:17 PM, Tejun Heo wrote:
> Hello,
> 
> Yeah, my patche series raced with 8648de2c581e ("f2fs: add bio cache
> for IPU").  Jens, can you please apply this one too?

I can't really, as that commit isn't in Linus's tree yet. I'll
keep an eye out for what hits mainline, I'll probably ship what
I have on Monday.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2019-07-11  5:15 Stephen Rothwell
@ 2019-07-11 20:17 ` Tejun Heo
  2019-07-11 20:36   ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Tejun Heo @ 2019-07-11 20:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Jaegeuk Kim, Linux Next Mailing List,
	Linux Kernel Mailing List, Chao Yu

Hello,

Yeah, my patche series raced with 8648de2c581e ("f2fs: add bio cache
for IPU").  Jens, can you please apply this one too?

On Thu, Jul 11, 2019 at 03:15:07PM +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 11 Jul 2019 15:13:21 +1000
> Subject: [PATCH] f2fs: fix for wbc_account_io rename
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/f2fs/data.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 323306630f93..4eb2f3920140 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -513,7 +513,7 @@ int f2fs_merge_page_bio(struct f2fs_io_info *fio)
>  	}
>  
>  	if (fio->io_wbc)
> -		wbc_account_io(fio->io_wbc, page, PAGE_SIZE);
> +		wbc_account_cgroup_owner(fio->io_wbc, page, PAGE_SIZE);

  Acked-by: Tejun Heo <tj@kernel.org>

Thanks.

-- 
tejun

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2019-07-11  5:15 Stephen Rothwell
  2019-07-11 20:17 ` Tejun Heo
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2019-07-11  5:15 UTC (permalink / raw)
  To: Jens Axboe, Jaegeuk Kim
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Tejun Heo, Chao Yu

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

Hi all,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/f2fs/data.c: In function 'f2fs_merge_page_bio':
fs/f2fs/data.c:516:3: error: implicit declaration of function 'wbc_account_io'; did you mean 'blk_account_rq'? [-Werror=implicit-function-declaration]
   wbc_account_io(fio->io_wbc, page, PAGE_SIZE);
   ^~~~~~~~~~~~~~
   blk_account_rq

Caused by commit

  34e51a5e1a6e ("blkcg, writeback: Rename wbc_account_io() to wbc_account_cgroup_owner()")

interacting with commit

  8648de2c581e ("f2fs: add bio cache for IPU")

from the f2fs tree.

I added the following merge fix patch or today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 11 Jul 2019 15:13:21 +1000
Subject: [PATCH] f2fs: fix for wbc_account_io rename

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 323306630f93..4eb2f3920140 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -513,7 +513,7 @@ int f2fs_merge_page_bio(struct f2fs_io_info *fio)
 	}
 
 	if (fio->io_wbc)
-		wbc_account_io(fio->io_wbc, page, PAGE_SIZE);
+		wbc_account_cgroup_owner(fio->io_wbc, page, PAGE_SIZE);
 
 	inc_page_count(fio->sbi, WB_DATA_TYPE(page));
 
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2019-07-11  5:04 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2019-07-11  5:04 UTC (permalink / raw)
  To: Jens Axboe, Darrick J. Wong, David Chinner, linux-xfs
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Tejun Heo,
	Christoph Hellwig

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

Hi all,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/xfs/xfs_aops.c: In function 'xfs_add_to_ioend':
fs/xfs/xfs_aops.c:799:2: error: implicit declaration of function 'wbc_account_io'; did you mean 'blk_account_rq'? [-Werror=implicit-function-declaration]
  wbc_account_io(wbc, page, len);
  ^~~~~~~~~~~~~~
  blk_account_rq

Caused by commit

  34e51a5e1a6e ("blkcg, writeback: Rename wbc_account_io() to wbc_account_cgroup_owner()")

interacting with commit

  adfb5fb46af0 ("xfs: implement cgroup aware writeback")

from the xfs tree.

I have applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 11 Jul 2019 15:01:54 +1000
Subject: [PATCH] xfs: fix up for wbc_account_io rename

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xfs/xfs_aops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 761248ee2778..f16d5f196c6b 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -796,7 +796,7 @@ xfs_add_to_ioend(
 	}
 
 	wpc->ioend->io_size += len;
-	wbc_account_io(wbc, page, len);
+	wbc_account_cgroup_owner(wbc, page, len);
 }
 
 STATIC void
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2019-06-21  8:18 ` Christoph Hellwig
@ 2019-06-21  8:36   ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2019-06-21  8:36 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Linux Next Mailing List, Linux Kernel Mailing List

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

Hi Christoph,

On Fri, 21 Jun 2019 10:18:36 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> On Fri, Jun 21, 2019 at 01:56:16PM +1000, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > After merging the block tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > ERROR: "css_next_descendant_pre" [block/bfq.ko] undefined!  
> 
> I think the culprit is "bfq-iosched: move bfq_stat_recursive_sum into the only
> caller" as that starts using css_next_descendant_pre in bfq.
> 
> I'll send a patch to export it.

Thanks.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2019-06-21  3:56 Stephen Rothwell
@ 2019-06-21  8:18 ` Christoph Hellwig
  2019-06-21  8:36   ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2019-06-21  8:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig

On Fri, Jun 21, 2019 at 01:56:16PM +1000, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "css_next_descendant_pre" [block/bfq.ko] undefined!

I think the culprit is "bfq-iosched: move bfq_stat_recursive_sum into the only
caller" as that starts using css_next_descendant_pre in bfq.

I'll send a patch to export it.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2019-06-21  3:56 Stephen Rothwell
  2019-06-21  8:18 ` Christoph Hellwig
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2019-06-21  3:56 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "css_next_descendant_pre" [block/bfq.ko] undefined!

Probably caused by commit

  8060c47ba853 ("block: rename CONFIG_DEBUG_BLK_CGROUP to CONFIG_BFQ_CGROUP_DEBUG")

I have used the block tree from next-20190620 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2019-05-06  5:07 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2019-05-06  5:07 UTC (permalink / raw)
  To: Jens Axboe, Steven Whitehouse, Bob Peterson
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Abhi Das, Andreas Gruenbacher

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/gfs2/lops.c: In function 'gfs2_end_log_read':
fs/gfs2/lops.c:394:49: error: macro "bio_for_each_segment_all" passed 4 arguments, but takes just 3
  bio_for_each_segment_all(bvec, bio, i, iter_all) {
                                                 ^
fs/gfs2/lops.c:394:2: error: 'bio_for_each_segment_all' undeclared (first use in this function); did you mean 'bio_first_page_all'?
  bio_for_each_segment_all(bvec, bio, i, iter_all) {
  ^~~~~~~~~~~~~~~~~~~~~~~~
  bio_first_page_all
fs/gfs2/lops.c:394:2: note: each undeclared identifier is reported only once for each function it appears in
fs/gfs2/lops.c:394:26: error: expected ';' before '{' token
  bio_for_each_segment_all(bvec, bio, i, iter_all) {
                          ^                        ~
                          ;

Caused by commit

  2b070cfe582b ("block: remove the i argument to bio_for_each_segment_all")

interacting with commit

  e21e191994af ("gfs2: read journal in large chunks")

from the gfs2 tree.

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 6 May 2019 14:57:42 +1000
Subject: [PATCH] gfs2: fix for "block: remove the i argument to bio_for_each_segment_all"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/gfs2/lops.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
index 3b3dd2ef53f7..33ab662c9aac 100644
--- a/fs/gfs2/lops.c
+++ b/fs/gfs2/lops.c
@@ -388,10 +388,9 @@ static void gfs2_end_log_read(struct bio *bio)
 {
 	struct page *page;
 	struct bio_vec *bvec;
-	int i;
 	struct bvec_iter_all iter_all;
 
-	bio_for_each_segment_all(bvec, bio, i, iter_all) {
+	bio_for_each_segment_all(bvec, bio, iter_all) {
 		page = bvec->bv_page;
 		if (bio->bi_status) {
 			int err = blk_status_to_errno(bio->bi_status);
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2019-01-16  2:55 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2019-01-16  2:55 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Ming Lei,
	Christoph Hellwig, Omar Sandoval, Eric Biggers

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

Hi all,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/verity/verify.c: In function 'fsverity_verify_bio':
fs/verity/verify.c:272:38: error: macro "bio_for_each_segment_all" requires 4 arguments, but only 3 given
   bio_for_each_segment_all(bv, bio, i)
                                      ^
fs/verity/verify.c:272:3: error: unknown type name 'bio_for_each_segment_all'
   bio_for_each_segment_all(bv, bio, i)
   ^~~~~~~~~~~~~~~~~~~~~~~~
fs/verity/verify.c:273:19: error: expected ')' before '->' token
    SetPageError(bv->bv_page);
                   ^~
                   )
fs/verity/verify.c:277:37: error: macro "bio_for_each_segment_all" requires 4 arguments, but only 3 given
  bio_for_each_segment_all(bv, bio, i) {
                                     ^
fs/verity/verify.c:277:2: error: 'bio_for_each_segment_all' undeclared (first use in this function); did you mean 'bio_first_page_all'?
  bio_for_each_segment_all(bv, bio, i) {
  ^~~~~~~~~~~~~~~~~~~~~~~~
  bio_first_page_all
fs/verity/verify.c:277:2: note: each undeclared identifier is reported only once for each function it appears in
fs/verity/verify.c:277:26: error: expected ';' before '{' token
  bio_for_each_segment_all(bv, bio, i) {
                          ^            ~
                          ;

Caused by commit

  eb754eb2a953 ("block: allow bio_for_each_segment_all() to iterate over multi-page bvec")

interacting with commit

  281bf3cdf27a ("fs-verity: add data verification hooks for ->readpages()")

I have applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Jan 2019 13:53:07 +1100
Subject: [PATCH] fs-verity: fix up for bio_for_each_segment_all() API change

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

diff --git a/fs/verity/verify.c b/fs/verity/verify.c
index e308f22475e8..dbd388ef32e1 100644
--- a/fs/verity/verify.c
+++ b/fs/verity/verify.c
@@ -266,15 +266,16 @@ void fsverity_verify_bio(struct bio *bio)
 	struct ahash_request *req;
 	struct bio_vec *bv;
 	int i;
+	struct bvec_iter_all iter_all;
 
 	req = ahash_request_alloc(vi->hash_alg->tfm, GFP_KERNEL);
 	if (unlikely(!req)) {
-		bio_for_each_segment_all(bv, bio, i)
+		bio_for_each_segment_all(bv, bio, i, iter_all)
 			SetPageError(bv->bv_page);
 		return;
 	}
 
-	bio_for_each_segment_all(bv, bio, i) {
+	bio_for_each_segment_all(bv, bio, i, iter_all) {
 		struct page *page = bv->bv_page;
 
 		if (!PageError(page) && !verify_page(inode, vi, req, page))
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2019-01-16  2:48 Stephen Rothwell
@ 2019-01-16  2:50 ` Ming Lei
  0 siblings, 0 replies; 176+ messages in thread
From: Ming Lei @ 2019-01-16  2:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Omar Sandoval

On Wed, Jan 16, 2019 at 01:48:24PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> fs/gfs2/lops.c: In function 'gfs2_end_log_read':
> fs/gfs2/lops.c:394:39: error: macro "bio_for_each_segment_all" requires 4 arguments, but only 3 given
>   bio_for_each_segment_all(bvec, bio, i) {
>                                        ^
> fs/gfs2/lops.c:394:2: error: 'bio_for_each_segment_all' undeclared (first use in this function); did you mean 'bio_first_page_all'?
>   bio_for_each_segment_all(bvec, bio, i) {
>   ^~~~~~~~~~~~~~~~~~~~~~~~
>   bio_first_page_all
> fs/gfs2/lops.c:394:2: note: each undeclared identifier is reported only once for each function it appears in
> fs/gfs2/lops.c:394:26: error: expected ';' before '{' token
>   bio_for_each_segment_all(bvec, bio, i) {
>                           ^              ~
>                           ;
> 
> Caused by commit
> 
>   eb754eb2a953 ("block: allow bio_for_each_segment_all() to iterate over multi-page bvec")
> 
> One instance of bio_for_each_segment_all() was missed.
> 
> I have applied the following fix patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 16 Jan 2019 13:44:02 +1100
> Subject: [PATCH] block: fix up for bio_for_each_segment_all() API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/gfs2/lops.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
> index ef68bf6232e7..15deefeaafd0 100644
> --- a/fs/gfs2/lops.c
> +++ b/fs/gfs2/lops.c
> @@ -390,8 +390,9 @@ static void gfs2_end_log_read(struct bio *bio)
>  	struct page *page;
>  	struct bio_vec *bvec;
>  	int i;
> +	struct bvec_iter_all iter_all;
>  
> -	bio_for_each_segment_all(bvec, bio, i) {
> +	bio_for_each_segment_all(bvec, bio, i, iter_all) {
>  		page = bvec->bv_page;
>  		if (bio->bi_status) {
>  			int err = blk_status_to_errno(bio->bi_status);

Yeah, we need the fix, and I just posted it minutes ago, sorry for
the trouble, :-(

https://marc.info/?l=linux-block&m=154760499205773&w=2

Thanks,
Ming

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2019-01-16  2:35 Stephen Rothwell
@ 2019-01-16  2:48 ` Ming Lei
  0 siblings, 0 replies; 176+ messages in thread
From: Ming Lei @ 2019-01-16  2:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Anna Schumaker, Trond Myklebust, NFS Mailing List,
	Linux Next Mailing List, Linux Kernel Mailing List

On Wed, Jan 16, 2019 at 01:35:52PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> net/sunrpc/xprtsock.c: In function 'xs_flush_bvec':
> net/sunrpc/xprtsock.c:390:2: error: implicit declaration of function 'for_each_bvec'; did you mean 'for_each_net'? [-Werror=implicit-function-declaration]
>   for_each_bvec(bv, bvec, bi, bi)
>   ^~~~~~~~~~~~~
>   for_each_net
> net/sunrpc/xprtsock.c:390:33: error: expected ';' before 'flush_dcache_page'
>   for_each_bvec(bv, bvec, bi, bi)
>                                  ^
>                                  ;
>    flush_dcache_page(bv.bv_page);
>    ~~~~~~~~~~~~~~~~~              
> 
> Caused by commit
> 
>   f3effe4c1240 ("block: rename bvec helpers")
> 
> interacting with commit
> 
>   6a829eb8619f ("SUNRPC: Fix TCP receive code on archs with flush_dcache_page()")
> 
> from the nfs-anna tree.
> 
> [I love API changes :-(]
> 
> I have applied the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 16 Jan 2019 13:32:59 +1100
> Subject: [PATCH] SUNRPC: merge fix for "block: rename bvec helpers"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  net/sunrpc/xprtsock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> index 7754aa3e434f..47f29cc23f27 100644
> --- a/net/sunrpc/xprtsock.c
> +++ b/net/sunrpc/xprtsock.c
> @@ -387,7 +387,7 @@ xs_flush_bvec(const struct bio_vec *bvec, size_t count, size_t seek)
>  	struct bio_vec bv;
>  
>  	bvec_iter_advance(bvec, &bi, seek & PAGE_MASK);
> -	for_each_bvec(bv, bvec, bi, bi)
> +	for_each_segment(bv, bvec, bi, bi)
>  		flush_dcache_page(bv.bv_page);
>  }
>  #else

This fix is correct, thanks!

Thanks,
Ming

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2019-01-16  2:48 Stephen Rothwell
  2019-01-16  2:50 ` Ming Lei
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2019-01-16  2:48 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Ming Lei,
	Christoph Hellwig, Omar Sandoval

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

Hi all,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/gfs2/lops.c: In function 'gfs2_end_log_read':
fs/gfs2/lops.c:394:39: error: macro "bio_for_each_segment_all" requires 4 arguments, but only 3 given
  bio_for_each_segment_all(bvec, bio, i) {
                                       ^
fs/gfs2/lops.c:394:2: error: 'bio_for_each_segment_all' undeclared (first use in this function); did you mean 'bio_first_page_all'?
  bio_for_each_segment_all(bvec, bio, i) {
  ^~~~~~~~~~~~~~~~~~~~~~~~
  bio_first_page_all
fs/gfs2/lops.c:394:2: note: each undeclared identifier is reported only once for each function it appears in
fs/gfs2/lops.c:394:26: error: expected ';' before '{' token
  bio_for_each_segment_all(bvec, bio, i) {
                          ^              ~
                          ;

Caused by commit

  eb754eb2a953 ("block: allow bio_for_each_segment_all() to iterate over multi-page bvec")

One instance of bio_for_each_segment_all() was missed.

I have applied the following fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Jan 2019 13:44:02 +1100
Subject: [PATCH] block: fix up for bio_for_each_segment_all() API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/gfs2/lops.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
index ef68bf6232e7..15deefeaafd0 100644
--- a/fs/gfs2/lops.c
+++ b/fs/gfs2/lops.c
@@ -390,8 +390,9 @@ static void gfs2_end_log_read(struct bio *bio)
 	struct page *page;
 	struct bio_vec *bvec;
 	int i;
+	struct bvec_iter_all iter_all;
 
-	bio_for_each_segment_all(bvec, bio, i) {
+	bio_for_each_segment_all(bvec, bio, i, iter_all) {
 		page = bvec->bv_page;
 		if (bio->bi_status) {
 			int err = blk_status_to_errno(bio->bi_status);
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2019-01-16  2:35 Stephen Rothwell
  2019-01-16  2:48 ` Ming Lei
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2019-01-16  2:35 UTC (permalink / raw)
  To: Jens Axboe, Anna Schumaker, Trond Myklebust, NFS Mailing List
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Ming Lei

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

Hi all,

After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

net/sunrpc/xprtsock.c: In function 'xs_flush_bvec':
net/sunrpc/xprtsock.c:390:2: error: implicit declaration of function 'for_each_bvec'; did you mean 'for_each_net'? [-Werror=implicit-function-declaration]
  for_each_bvec(bv, bvec, bi, bi)
  ^~~~~~~~~~~~~
  for_each_net
net/sunrpc/xprtsock.c:390:33: error: expected ';' before 'flush_dcache_page'
  for_each_bvec(bv, bvec, bi, bi)
                                 ^
                                 ;
   flush_dcache_page(bv.bv_page);
   ~~~~~~~~~~~~~~~~~              

Caused by commit

  f3effe4c1240 ("block: rename bvec helpers")

interacting with commit

  6a829eb8619f ("SUNRPC: Fix TCP receive code on archs with flush_dcache_page()")

from the nfs-anna tree.

[I love API changes :-(]

I have applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Jan 2019 13:32:59 +1100
Subject: [PATCH] SUNRPC: merge fix for "block: rename bvec helpers"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/sunrpc/xprtsock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 7754aa3e434f..47f29cc23f27 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -387,7 +387,7 @@ xs_flush_bvec(const struct bio_vec *bvec, size_t count, size_t seek)
 	struct bio_vec bv;
 
 	bvec_iter_advance(bvec, &bi, seek & PAGE_MASK);
-	for_each_bvec(bv, bvec, bi, bi)
+	for_each_segment(bv, bvec, bi, bi)
 		flush_dcache_page(bv.bv_page);
 }
 #else
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-26  4:56 Stephen Rothwell
  2018-07-26  8:48 ` Christoph Hellwig
  2018-07-26 12:32 ` Steve Wise
@ 2018-08-15  1:43 ` Stephen Rothwell
  2 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2018-08-15  1:43 UTC (permalink / raw)
  To: Doug Ledford, Jason Gunthorpe
  Cc: Jens Axboe, Linux-Next Mailing List, Linux Kernel Mailing List,
	Steve Wise, Christoph Hellwig

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

Hi all,

On Thu, 26 Jul 2018 14:56:24 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/nvme/target/rdma.c: In function 'nvmet_rdma_find_get_device':
> drivers/nvme/target/rdma.c:894:26: error: 'struct ib_device_attr' has no member named 'max_sge'; did you mean 'max_cqe'?
>      cm_id->device->attrs.max_sge) - 1;
>                           ^
> drivers/nvme/target/rdma.c:893:21: note: in expansion of macro 'max'
>   inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
>                      ^~~
> In file included from include/linux/list.h:9:0,
>                  from include/linux/module.h:9,
>                  from drivers/nvme/host/rdma.c:15:
> drivers/nvme/host/rdma.c: In function 'nvme_rdma_find_get_device':
> drivers/nvme/host/rdma.c:381:23: error: 'struct ib_device_attr' has no member named 'max_sge'; did you mean 'max_cqe'?
>       ndev->dev->attrs.max_sge - 1);
>                        ^
> drivers/nvme/host/rdma.c:380:30: note: in expansion of macro 'min'
>   ndev->num_inline_segments = min(NVME_RDMA_MAX_INLINE_SEGMENTS,
>                               ^~~
> 
> Caused by commits
> 
>   64a741c1eaa8 ("nvme-rdma: support up to 4 segments of inline data")
>   0d5ee2b2ab4f ("nvmet-rdma: support max(16KB, PAGE_SIZE) inline data")
> 
> interacting with commit
> 
>   33023fb85a42 ("IB/core: add max_send_sge and max_recv_sge attributes")
> 
> from the rdma tree.
> 
> I have applied the following merge fix patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 26 Jul 2018 14:32:15 +1000
> Subject: [PATCH] nvme-dma: merge fix up for replacement of max_sge
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/nvme/host/rdma.c   | 2 +-
>  drivers/nvme/target/rdma.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
> index cfa0319fcd1c..368fe5ac0c6b 100644
> --- a/drivers/nvme/host/rdma.c
> +++ b/drivers/nvme/host/rdma.c
> @@ -378,7 +378,7 @@ nvme_rdma_find_get_device(struct rdma_cm_id *cm_id)
>  	}
>  
>  	ndev->num_inline_segments = min(NVME_RDMA_MAX_INLINE_SEGMENTS,
> -					ndev->dev->attrs.max_sge - 1);
> +					ndev->dev->attrs.max_send_sge - 1);
>  	list_add(&ndev->entry, &device_list);
>  out_unlock:
>  	mutex_unlock(&device_list_mutex);
> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> index 86121a7a19b2..8c30ac7d8078 100644
> --- a/drivers/nvme/target/rdma.c
> +++ b/drivers/nvme/target/rdma.c
> @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
>  
>  	inline_page_count = num_pages(port->inline_data_size);
>  	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
> -				cm_id->device->attrs.max_sge) - 1;
> +				cm_id->device->attrs.max_send_sge) - 1;
>  	if (inline_page_count > inline_sge_count) {
>  		pr_warn("inline_data_size %d cannot be supported by device %s. Reducing to %lu.\n",
>  			port->inline_data_size, cm_id->device->name,
> -- 
> 2.18.0

This is now needed (with the max_send_sge -> max_recv_sge update in
drivers/nvme/target/rdma.c patch) when I merge the rdma tree with
Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-31  3:07 Stephen Rothwell
@ 2018-07-31 14:59 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2018-07-31 14:59 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Max Gurtovoy

On 7/30/18 9:07 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> drivers/scsi/sd.o: In function `sd_done':
> sd.c:(.text+0x1050): undefined reference to `t10_pi_complete'
> 
> Presuably caused by commit
> 
>   10c41ddd6132 ("block: move dif_prepare/dif_complete functions to block layer")
> 
> # CONFIG_BLK_DEV_INTEGRITY is not set
> CONFIG_BLK_DEV_SD=y
> 
> I have used the block tree from next-20180730 for today.

Thanks, I fixed it up just now, next one should be fine again.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2018-07-31  3:07 Stephen Rothwell
  2018-07-31 14:59 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2018-07-31  3:07 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Max Gurtovoy

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

Hi Jens,

After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/scsi/sd.o: In function `sd_done':
sd.c:(.text+0x1050): undefined reference to `t10_pi_complete'

Presuably caused by commit

  10c41ddd6132 ("block: move dif_prepare/dif_complete functions to block layer")

# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLK_DEV_SD=y

I have used the block tree from next-20180730 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-26 12:32 ` Steve Wise
@ 2018-07-26 22:16   ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2018-07-26 22:16 UTC (permalink / raw)
  To: Steve Wise
  Cc: Jens Axboe, Doug Ledford, Jason Gunthorpe,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig

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

Hi Steve,

On Thu, 26 Jul 2018 07:32:16 -0500 "Steve Wise" <swise@opengridcomputing.com> wrote:
>
> > diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> > index 86121a7a19b2..8c30ac7d8078 100644
> > --- a/drivers/nvme/target/rdma.c
> > +++ b/drivers/nvme/target/rdma.c
> > @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id
> > *cm_id)
> > 
> >  	inline_page_count = num_pages(port->inline_data_size);
> >  	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
> > -				cm_id->device->attrs.max_sge) - 1;
> > +				cm_id->device->attrs.max_send_sge) - 1;  
> 
> This should actually be max_recv_sge.

Yeah, Christoph pointed that out as well.  I will correct it today.

Thanks
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-26 20:54     ` Bart Van Assche
@ 2018-07-26 21:13       ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2018-07-26 21:13 UTC (permalink / raw)
  To: Bart Van Assche, Christoph Hellwig, Stephen Rothwell
  Cc: Doug Ledford, Jason Gunthorpe, Linux-Next Mailing List,
	Linux Kernel Mailing List, Steve Wise

On 7/26/18 1:54 PM, Bart Van Assche wrote:
> On 07/26/18 10:48, Jens Axboe wrote:
>> On 7/26/18 1:48 AM, Christoph Hellwig wrote:
>>> On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
>>>> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
>>>> index 86121a7a19b2..8c30ac7d8078 100644
>>>> --- a/drivers/nvme/target/rdma.c
>>>> +++ b/drivers/nvme/target/rdma.c
>>>> @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
>>>>   
>>>>   	inline_page_count = num_pages(port->inline_data_size);
>>>>   	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
>>>> -				cm_id->device->attrs.max_sge) - 1;
>>>> +				cm_id->device->attrs.max_send_sge) - 1;
>>>
>>> This should be max_recv_sge.
>>
>> Why do we even have this conflicts to begin with?
> 
> Hello Jens,
> 
> A detailed description of why that change is necessary is available at
> https://www.spinics.net/lists/linux-rdma/msg65954.html. As far as I know
> the entire RDMA community supports that change.

Thanks - I'm not against the change, I just always get a little
suspicious when we have merge conflicts across subsystems. But this
one seems warranted.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-26 17:48   ` Jens Axboe
  2018-07-26 17:56     ` Christoph Hellwig
@ 2018-07-26 20:54     ` Bart Van Assche
  2018-07-26 21:13       ` Jens Axboe
  1 sibling, 1 reply; 176+ messages in thread
From: Bart Van Assche @ 2018-07-26 20:54 UTC (permalink / raw)
  To: Jens Axboe, Christoph Hellwig, Stephen Rothwell
  Cc: Doug Ledford, Jason Gunthorpe, Linux-Next Mailing List,
	Linux Kernel Mailing List, Steve Wise

On 07/26/18 10:48, Jens Axboe wrote:
> On 7/26/18 1:48 AM, Christoph Hellwig wrote:
>> On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
>>> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
>>> index 86121a7a19b2..8c30ac7d8078 100644
>>> --- a/drivers/nvme/target/rdma.c
>>> +++ b/drivers/nvme/target/rdma.c
>>> @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
>>>   
>>>   	inline_page_count = num_pages(port->inline_data_size);
>>>   	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
>>> -				cm_id->device->attrs.max_sge) - 1;
>>> +				cm_id->device->attrs.max_send_sge) - 1;
>>
>> This should be max_recv_sge.
> 
> Why do we even have this conflicts to begin with?

Hello Jens,

A detailed description of why that change is necessary is available at
https://www.spinics.net/lists/linux-rdma/msg65954.html. As far as I know
the entire RDMA community supports that change.

Bart.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* RE: linux-next: build failure after merge of the block tree
  2018-07-26 17:56     ` Christoph Hellwig
@ 2018-07-26 17:59       ` Steve Wise
  0 siblings, 0 replies; 176+ messages in thread
From: Steve Wise @ 2018-07-26 17:59 UTC (permalink / raw)
  To: Christoph Hellwig, Jens Axboe
  Cc: Stephen Rothwell, Doug Ledford, Jason Gunthorpe,
	Linux-Next Mailing List, Linux Kernel Mailing List



> -----Original Message-----
> From: Christoph Hellwig <hch@lst.de>
> Sent: Thursday, July 26, 2018 12:57 PM
> To: Jens Axboe <axboe@kernel.dk>
> Cc: Christoph Hellwig <hch@lst.de>; Stephen Rothwell
> <sfr@canb.auug.org.au>; Doug Ledford <dledford@redhat.com>; Jason
> Gunthorpe <jgg@mellanox.com>; Linux-Next Mailing List <linux-
> next@vger.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; Steve Wise <swise@opengridcomputing.com>
> Subject: Re: linux-next: build failure after merge of the block tree
> 
> On Thu, Jul 26, 2018 at 10:48:21AM -0700, Jens Axboe wrote:
> > >>  	inline_page_count = num_pages(port->inline_data_size);
> > >>  	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
> > >> -				cm_id->device->attrs.max_sge) - 1;
> > >> +				cm_id->device->attrs.max_send_sge) -
1;
> > >
> > > This should be max_recv_sge.
> >
> > Why do we even have this conflicts to begin with?
> 
> Because the nvme code added a new user of max_sges while the RDMA tree
> split it into two separate fields.  We discussed this a while ago when
> the issue came up.

See: https://www.spinics.net/lists/linux-rdma/msg66208.html 

Steve.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-26 17:48   ` Jens Axboe
@ 2018-07-26 17:56     ` Christoph Hellwig
  2018-07-26 17:59       ` Steve Wise
  2018-07-26 20:54     ` Bart Van Assche
  1 sibling, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2018-07-26 17:56 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Christoph Hellwig, Stephen Rothwell, Doug Ledford,
	Jason Gunthorpe, Linux-Next Mailing List,
	Linux Kernel Mailing List, Steve Wise

On Thu, Jul 26, 2018 at 10:48:21AM -0700, Jens Axboe wrote:
> >>  	inline_page_count = num_pages(port->inline_data_size);
> >>  	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
> >> -				cm_id->device->attrs.max_sge) - 1;
> >> +				cm_id->device->attrs.max_send_sge) - 1;
> > 
> > This should be max_recv_sge.
> 
> Why do we even have this conflicts to begin with?

Because the nvme code added a new user of max_sges while the RDMA tree
split it into two separate fields.  We discussed this a while ago when
the issue came up.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-26  8:48 ` Christoph Hellwig
  2018-07-26  8:45   ` Stephen Rothwell
@ 2018-07-26 17:48   ` Jens Axboe
  2018-07-26 17:56     ` Christoph Hellwig
  2018-07-26 20:54     ` Bart Van Assche
  1 sibling, 2 replies; 176+ messages in thread
From: Jens Axboe @ 2018-07-26 17:48 UTC (permalink / raw)
  To: Christoph Hellwig, Stephen Rothwell
  Cc: Doug Ledford, Jason Gunthorpe, Linux-Next Mailing List,
	Linux Kernel Mailing List, Steve Wise

On 7/26/18 1:48 AM, Christoph Hellwig wrote:
> On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
>> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
>> index 86121a7a19b2..8c30ac7d8078 100644
>> --- a/drivers/nvme/target/rdma.c
>> +++ b/drivers/nvme/target/rdma.c
>> @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
>>  
>>  	inline_page_count = num_pages(port->inline_data_size);
>>  	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
>> -				cm_id->device->attrs.max_sge) - 1;
>> +				cm_id->device->attrs.max_send_sge) - 1;
> 
> This should be max_recv_sge.

Why do we even have this conflicts to begin with?


-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* RE: linux-next: build failure after merge of the block tree
  2018-07-26  4:56 Stephen Rothwell
  2018-07-26  8:48 ` Christoph Hellwig
@ 2018-07-26 12:32 ` Steve Wise
  2018-07-26 22:16   ` Stephen Rothwell
  2018-08-15  1:43 ` Stephen Rothwell
  2 siblings, 1 reply; 176+ messages in thread
From: Steve Wise @ 2018-07-26 12:32 UTC (permalink / raw)
  To: Stephen Rothwell, Jens Axboe, Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig

Hey Stephen:

> I have applied the following merge fix patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 26 Jul 2018 14:32:15 +1000
> Subject: [PATCH] nvme-dma: merge fix up for replacement of max_sge
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/nvme/host/rdma.c   | 2 +-
>  drivers/nvme/target/rdma.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
> index cfa0319fcd1c..368fe5ac0c6b 100644
> --- a/drivers/nvme/host/rdma.c
> +++ b/drivers/nvme/host/rdma.c
> @@ -378,7 +378,7 @@ nvme_rdma_find_get_device(struct rdma_cm_id
> *cm_id)
>  	}
> 
>  	ndev->num_inline_segments =
> min(NVME_RDMA_MAX_INLINE_SEGMENTS,
> -					ndev->dev->attrs.max_sge - 1);
> +					ndev->dev->attrs.max_send_sge - 1);
>  	list_add(&ndev->entry, &device_list);
>  out_unlock:
>  	mutex_unlock(&device_list_mutex);
> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> index 86121a7a19b2..8c30ac7d8078 100644
> --- a/drivers/nvme/target/rdma.c
> +++ b/drivers/nvme/target/rdma.c
> @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id
> *cm_id)
> 
>  	inline_page_count = num_pages(port->inline_data_size);
>  	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
> -				cm_id->device->attrs.max_sge) - 1;
> +				cm_id->device->attrs.max_send_sge) - 1;

This should actually be max_recv_sge.

Thanks!

Steve.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-26  4:56 Stephen Rothwell
@ 2018-07-26  8:48 ` Christoph Hellwig
  2018-07-26  8:45   ` Stephen Rothwell
  2018-07-26 17:48   ` Jens Axboe
  2018-07-26 12:32 ` Steve Wise
  2018-08-15  1:43 ` Stephen Rothwell
  2 siblings, 2 replies; 176+ messages in thread
From: Christoph Hellwig @ 2018-07-26  8:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Doug Ledford, Jason Gunthorpe,
	Linux-Next Mailing List, Linux Kernel Mailing List, Steve Wise,
	Christoph Hellwig

On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> index 86121a7a19b2..8c30ac7d8078 100644
> --- a/drivers/nvme/target/rdma.c
> +++ b/drivers/nvme/target/rdma.c
> @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
>  
>  	inline_page_count = num_pages(port->inline_data_size);
>  	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
> -				cm_id->device->attrs.max_sge) - 1;
> +				cm_id->device->attrs.max_send_sge) - 1;

This should be max_recv_sge.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2018-07-26  8:48 ` Christoph Hellwig
@ 2018-07-26  8:45   ` Stephen Rothwell
  2018-07-26 17:48   ` Jens Axboe
  1 sibling, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2018-07-26  8:45 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Doug Ledford, Jason Gunthorpe,
	Linux-Next Mailing List, Linux Kernel Mailing List, Steve Wise

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

Hi Christoph,

On Thu, 26 Jul 2018 10:48:33 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
> > diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> > index 86121a7a19b2..8c30ac7d8078 100644
> > --- a/drivers/nvme/target/rdma.c
> > +++ b/drivers/nvme/target/rdma.c
> > @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
> >  
> >  	inline_page_count = num_pages(port->inline_data_size);
> >  	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
> > -				cm_id->device->attrs.max_sge) - 1;
> > +				cm_id->device->attrs.max_send_sge) - 1;  
> 
> This should be max_recv_sge.

Thanks, I will fix up my resolution for tomorrow.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2018-07-26  4:56 Stephen Rothwell
  2018-07-26  8:48 ` Christoph Hellwig
                   ` (2 more replies)
  0 siblings, 3 replies; 176+ messages in thread
From: Stephen Rothwell @ 2018-07-26  4:56 UTC (permalink / raw)
  To: Jens Axboe, Doug Ledford, Jason Gunthorpe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Steve Wise,
	Christoph Hellwig

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

Hi all,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/nvme/target/rdma.c: In function 'nvmet_rdma_find_get_device':
drivers/nvme/target/rdma.c:894:26: error: 'struct ib_device_attr' has no member named 'max_sge'; did you mean 'max_cqe'?
     cm_id->device->attrs.max_sge) - 1;
                          ^
drivers/nvme/target/rdma.c:893:21: note: in expansion of macro 'max'
  inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
                     ^~~
In file included from include/linux/list.h:9:0,
                 from include/linux/module.h:9,
                 from drivers/nvme/host/rdma.c:15:
drivers/nvme/host/rdma.c: In function 'nvme_rdma_find_get_device':
drivers/nvme/host/rdma.c:381:23: error: 'struct ib_device_attr' has no member named 'max_sge'; did you mean 'max_cqe'?
      ndev->dev->attrs.max_sge - 1);
                       ^
drivers/nvme/host/rdma.c:380:30: note: in expansion of macro 'min'
  ndev->num_inline_segments = min(NVME_RDMA_MAX_INLINE_SEGMENTS,
                              ^~~

Caused by commits

  64a741c1eaa8 ("nvme-rdma: support up to 4 segments of inline data")
  0d5ee2b2ab4f ("nvmet-rdma: support max(16KB, PAGE_SIZE) inline data")

interacting with commit

  33023fb85a42 ("IB/core: add max_send_sge and max_recv_sge attributes")

from the rdma tree.

I have applied the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 26 Jul 2018 14:32:15 +1000
Subject: [PATCH] nvme-dma: merge fix up for replacement of max_sge

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/nvme/host/rdma.c   | 2 +-
 drivers/nvme/target/rdma.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index cfa0319fcd1c..368fe5ac0c6b 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -378,7 +378,7 @@ nvme_rdma_find_get_device(struct rdma_cm_id *cm_id)
 	}
 
 	ndev->num_inline_segments = min(NVME_RDMA_MAX_INLINE_SEGMENTS,
-					ndev->dev->attrs.max_sge - 1);
+					ndev->dev->attrs.max_send_sge - 1);
 	list_add(&ndev->entry, &device_list);
 out_unlock:
 	mutex_unlock(&device_list_mutex);
diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
index 86121a7a19b2..8c30ac7d8078 100644
--- a/drivers/nvme/target/rdma.c
+++ b/drivers/nvme/target/rdma.c
@@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(struct rdma_cm_id *cm_id)
 
 	inline_page_count = num_pages(port->inline_data_size);
 	inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
-				cm_id->device->attrs.max_sge) - 1;
+				cm_id->device->attrs.max_send_sge) - 1;
 	if (inline_page_count > inline_sge_count) {
 		pr_warn("inline_data_size %d cannot be supported by device %s. Reducing to %lu.\n",
 			port->inline_data_size, cm_id->device->name,
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-08-24  8:44   ` Christoph Hellwig
@ 2017-08-24  8:54     ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2017-08-24  8:54 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Linux-Next Mailing List, Linux Kernel Mailing List

Hi Christoph,

On Thu, 24 Aug 2017 10:44:10 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> Keith already sent a patch for this, it was a rebase failure :(

Ah, OK, thanks.

> The documentation one is intentional - the document is completely
> out of data, so doctoring around a bit won't help.  I'll try to find
> some time to replace it with a sane new doc that use the ReST stuff
> to not duplicate the structure. 

Seems like a plan.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-08-24  3:34 ` Stephen Rothwell
@ 2017-08-24  8:44   ` Christoph Hellwig
  2017-08-24  8:54     ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2017-08-24  8:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig

Hi Stephen,

Keith already sent a patch for this, it was a rebase failure :(

The documentation one is intentional - the document is completely
out of data, so doctoring around a bit won't help.  I'll try to find
some time to replace it with a sane new doc that use the ReST stuff
to not duplicate the structure. 

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-08-24  3:32 Stephen Rothwell
@ 2017-08-24  3:34 ` Stephen Rothwell
  2017-08-24  8:44   ` Christoph Hellwig
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2017-08-24  3:34 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig

Hi all,

On Thu, 24 Aug 2017 13:32:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> block/bio-integrity.c: In function '__bio_integrity_endio':
> block/bio-integrity.c:388:51: error: 'struct bio' has no member named 'bi_bdev'
>   struct blk_integrity *bi = bdev_get_integrity(bio->bi_bdev);
>                                                    ^
> 
> Caused by commit
> 
>   74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index")
> 
> interacting with commit
> 
>   c775d2098d35 ("bio-integrity: Fix regression if profile verify_fn is NULL")
> 
> from Linus' tree (before v4.13-rc5).
> 
> This should have been fixed up in commit
> 
>   3b8848b41130 ("Merge branch 'master' into for-next")
> 
> I have used the block tree from next-20170823 for today.

The other remaining reference to bi_bdev is in Documentation/block/biodoc.txt.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2017-08-24  3:32 Stephen Rothwell
  2017-08-24  3:34 ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2017-08-24  3:32 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

block/bio-integrity.c: In function '__bio_integrity_endio':
block/bio-integrity.c:388:51: error: 'struct bio' has no member named 'bi_bdev'
  struct blk_integrity *bi = bdev_get_integrity(bio->bi_bdev);
                                                   ^

Caused by commit

  74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index")

interacting with commit

  c775d2098d35 ("bio-integrity: Fix regression if profile verify_fn is NULL")

from Linus' tree (before v4.13-rc5).

This should have been fixed up in commit

  3b8848b41130 ("Merge branch 'master' into for-next")

I have used the block tree from next-20170823 for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-07-04 15:15 ` Guenter Roeck
@ 2017-07-04 21:40   ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2017-07-04 21:40 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Jens Axboe, Martin Schwidefsky, Heiko Carstens,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Sebastian Ott

Hi Guenter,

On Tue, 4 Jul 2017 08:15:57 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Jun 13, 2017 at 08:54:09PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the block tree, today's linux-next build (s390x
> > s390-defconfig) failed like this:
> > 
> > drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared (first use in this function)
> > drivers/s390/block/scm_blk.c:327:9: error: 'BLK_MQ_RQ_QUEUE_OK' undeclared (first use in this function)
> > 
> > Caused by commit
> > 
> >   fc17b6534eb8 ("blk-mq: switch ->queue_rq return value to blk_status_t")
> > 
> > interacting with commit
> > 
> >   12d907626539 ("s390/scm: convert to blk-mq")
> > 
> > from the s390 tree.
> > 
> > Is the following the correct merge fixup?
> >   
> 
> The failure made int into Linus' tree, but the fix didn't. Is the fix pending
> in some other queue or does it have to be (re-)submitted ?

It will be my in fixes tree today and until it appears in Linus' or the
s390 tree.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-06-13 10:54 Stephen Rothwell
  2017-06-15 14:50 ` Sebastian Ott
@ 2017-07-04 15:15 ` Guenter Roeck
  2017-07-04 21:40   ` Stephen Rothwell
  1 sibling, 1 reply; 176+ messages in thread
From: Guenter Roeck @ 2017-07-04 15:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Martin Schwidefsky, Heiko Carstens,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Sebastian Ott

On Tue, Jun 13, 2017 at 08:54:09PM +1000, Stephen Rothwell wrote:
> Hi Jall,
> 
> After merging the block tree, today's linux-next build (s390x
> s390-defconfig) failed like this:
> 
> drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared (first use in this function)
> drivers/s390/block/scm_blk.c:327:9: error: 'BLK_MQ_RQ_QUEUE_OK' undeclared (first use in this function)
> 
> Caused by commit
> 
>   fc17b6534eb8 ("blk-mq: switch ->queue_rq return value to blk_status_t")
> 
> interacting with commit
> 
>   12d907626539 ("s390/scm: convert to blk-mq")
> 
> from the s390 tree.
> 
> Is the following the correct merge fixup?
> 

The failure made int into Linus' tree, but the fix didn't. Is the fix pending
in some other queue or does it have to be (re-)submitted ?

Guenter

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 13 Jun 2017 20:51:32 +1000
> Subject: [PATCH] s390: fix up for "blk-mq: switch ->queue_rq return value to
>  blk_status_t"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/s390/block/scm_blk.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c
> index 42018a20f2b7..2cd6123c8f18 100644
> --- a/drivers/s390/block/scm_blk.c
> +++ b/drivers/s390/block/scm_blk.c
> @@ -290,7 +290,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
>  	spin_lock(&sq->lock);
>  	if (!scm_permit_request(bdev, req)) {
>  		spin_unlock(&sq->lock);
> -		return BLK_MQ_RQ_QUEUE_BUSY;
> +		return BLK_STS_RESOURCE;
>  	}
>  
>  	scmrq = sq->scmrq;
> @@ -299,7 +299,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
>  		if (!scmrq) {
>  			SCM_LOG(5, "no request");
>  			spin_unlock(&sq->lock);
> -			return BLK_MQ_RQ_QUEUE_BUSY;
> +			return BLK_STS_RESOURCE;
>  		}
>  		scm_request_init(bdev, scmrq);
>  		sq->scmrq = scmrq;
> @@ -315,7 +315,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
>  
>  		sq->scmrq = NULL;
>  		spin_unlock(&sq->lock);
> -		return BLK_MQ_RQ_QUEUE_BUSY;
> +		return BLK_STS_RESOURCE;
>  	}
>  	blk_mq_start_request(req);
>  
> @@ -324,7 +324,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
>  		sq->scmrq = NULL;
>  	}
>  	spin_unlock(&sq->lock);
> -	return BLK_MQ_RQ_QUEUE_OK;
> +	return BLK_STS_OK;
>  }
>  
>  static int scm_blk_init_hctx(struct blk_mq_hw_ctx *hctx, void *data,

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-06-28 15:11     ` Jens Axboe
@ 2017-06-28 21:33       ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2017-06-28 21:33 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Martin K. Petersen, Michael Ellerman, Benjamin Herrenschmidt,
	PowerPC

Hi Jens,

On Wed, 28 Jun 2017 09:11:32 -0600 Jens Axboe <axboe@kernel.dk> wrote:
>
> On 06/28/2017 08:01 AM, Jens Axboe wrote:
> > But put_user() is fine? Just checking here, since the change adds
> > both a u64 put and get user.  

Yes, put_user is fine (it does 2 4 byte moves.  The asm is there to do
the 8 byte get_user, but the surrounding C code uses an unsigned long
for the destination in all cases (some other arches do the same).  I
don't remember why it is like that.

> I just changed all 4, at least that provides some symmetry in how
> we copy things in and out for that set of fcntls.

OK, thanks.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-06-28 14:01   ` Jens Axboe
@ 2017-06-28 15:11     ` Jens Axboe
  2017-06-28 21:33       ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2017-06-28 15:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Martin K. Petersen, Michael Ellerman, Benjamin Herrenschmidt,
	PowerPC

On 06/28/2017 08:01 AM, Jens Axboe wrote:
> On 06/28/2017 06:43 AM, Jens Axboe wrote:
>> On 06/28/2017 02:04 AM, Stephen Rothwell wrote:
>>> Hi Jens,
>>>
>>> After merging the block tree, today's linux-next build (powerpc
>>> allnoconfig) failed like this:
>>>
>>> fs/fcntl.o: In function `do_fcntl': 
>>> fcntl.c:(.text+0x6d4): undefined reference to `__get_user_bad'
>>> fcntl.c:(.text+0x730): undefined reference to `__get_user_bad'
>>>
>>> Probably caused by commit
>>>
>>>   c75b1d9421f8 ("fs: add fcntl() interface for setting/getting write life time hints")
>>>
>>> On powerpc (at least) you cannot use get_user() to fetch anything larger
>>> than "unsigned long" i.e. 32 bits on 32 bit powerpc.
>>>
>>> This has been discussed before (and, I think, a fix attempted).
>>
>> Gah, thanks for letting me know. I'll test your patch and queue it
>> up to fix this issue.
> 
> But put_user() is fine? Just checking here, since the change adds
> both a u64 put and get user.

I just changed all 4, at least that provides some symmetry in how
we copy things in and out for that set of fcntls.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-06-28 12:43 ` Jens Axboe
@ 2017-06-28 14:01   ` Jens Axboe
  2017-06-28 15:11     ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2017-06-28 14:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Martin K. Petersen, Michael Ellerman, Benjamin Herrenschmidt,
	PowerPC

On 06/28/2017 06:43 AM, Jens Axboe wrote:
> On 06/28/2017 02:04 AM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (powerpc
>> allnoconfig) failed like this:
>>
>> fs/fcntl.o: In function `do_fcntl': 
>> fcntl.c:(.text+0x6d4): undefined reference to `__get_user_bad'
>> fcntl.c:(.text+0x730): undefined reference to `__get_user_bad'
>>
>> Probably caused by commit
>>
>>   c75b1d9421f8 ("fs: add fcntl() interface for setting/getting write life time hints")
>>
>> On powerpc (at least) you cannot use get_user() to fetch anything larger
>> than "unsigned long" i.e. 32 bits on 32 bit powerpc.
>>
>> This has been discussed before (and, I think, a fix attempted).
> 
> Gah, thanks for letting me know. I'll test your patch and queue it
> up to fix this issue.

But put_user() is fine? Just checking here, since the change adds
both a u64 put and get user.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-06-28  8:04 Stephen Rothwell
@ 2017-06-28 12:43 ` Jens Axboe
  2017-06-28 14:01   ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2017-06-28 12:43 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Martin K. Petersen, Michael Ellerman, Benjamin Herrenschmidt,
	PowerPC

On 06/28/2017 02:04 AM, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
> 
> fs/fcntl.o: In function `do_fcntl': 
> fcntl.c:(.text+0x6d4): undefined reference to `__get_user_bad'
> fcntl.c:(.text+0x730): undefined reference to `__get_user_bad'
> 
> Probably caused by commit
> 
>   c75b1d9421f8 ("fs: add fcntl() interface for setting/getting write life time hints")
> 
> On powerpc (at least) you cannot use get_user() to fetch anything larger
> than "unsigned long" i.e. 32 bits on 32 bit powerpc.
> 
> This has been discussed before (and, I think, a fix attempted).

Gah, thanks for letting me know. I'll test your patch and queue it
up to fix this issue.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2017-06-28  8:04 Stephen Rothwell
  2017-06-28 12:43 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2017-06-28  8:04 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Martin K. Petersen, Michael Ellerman, Benjamin Herrenschmidt,
	PowerPC

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
allnoconfig) failed like this:

fs/fcntl.o: In function `do_fcntl': 
fcntl.c:(.text+0x6d4): undefined reference to `__get_user_bad'
fcntl.c:(.text+0x730): undefined reference to `__get_user_bad'

Probably caused by commit

  c75b1d9421f8 ("fs: add fcntl() interface for setting/getting write life time hints")

On powerpc (at least) you cannot use get_user() to fetch anything larger
than "unsigned long" i.e. 32 bits on 32 bit powerpc.

This has been discussed before (and, I think, a fix attempted).

For now I have applied the following patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 28 Jun 2017 17:50:31 +1000
Subject: [PATCH] fs: don't read an enum directly from a u64 __user *

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

diff --git a/fs/fcntl.c b/fs/fcntl.c
index 24e233c75a33..19825eb7c40d 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -277,6 +277,7 @@ static long fcntl_rw_hint(struct file *file, unsigned int cmd,
 {
 	struct inode *inode = file_inode(file);
 	u64 *argp = (u64 __user *)arg;
+	u64 h;
 	enum rw_hint hint;
 
 	switch (cmd) {
@@ -285,8 +286,9 @@ static long fcntl_rw_hint(struct file *file, unsigned int cmd,
 			return -EFAULT;
 		return 0;
 	case F_SET_FILE_RW_HINT:
-		if (get_user(hint, argp))
+		if (copy_from_user(&h, argp, sizeof(h)))
 			return -EFAULT;
+		hint = (enum rw_hint)h;
 		if (!rw_hint_valid(hint))
 			return -EINVAL;
 
@@ -299,8 +301,9 @@ static long fcntl_rw_hint(struct file *file, unsigned int cmd,
 			return -EFAULT;
 		return 0;
 	case F_SET_RW_HINT:
-		if (get_user(hint, argp))
+		if (copy_from_user(&h, argp, sizeof(h)))
 			return -EFAULT;
+		hint = (enum rw_hint)h;
 		if (!rw_hint_valid(hint))
 			return -EINVAL;
 
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-06-19  9:00   ` Sebastian Ott
@ 2017-06-20  1:45     ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2017-06-20  1:45 UTC (permalink / raw)
  To: Sebastian Ott
  Cc: Jens Axboe, Martin Schwidefsky, Heiko Carstens,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig

Hi Sebastian,

On Mon, 19 Jun 2017 11:00:23 +0200 (CEST) Sebastian Ott <sebott@linux.vnet.ibm.com> wrote:
>
> Ok, we should also adjust the return code to fix this:
> 
> drivers/s390/block/scm_blk.c:426:2: warning: initialization from incompatible pointer type [enabled by default]
>   .queue_rq = scm_blk_request,
>   ^
> 
> diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c
> index 2cd6123c8f18..4279685901bf 100644
> --- a/drivers/s390/block/scm_blk.c
> +++ b/drivers/s390/block/scm_blk.c
> @@ -278,8 +278,8 @@ struct scm_queue {
>  	spinlock_t lock;
>  };
>  
> -static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
> -			   const struct blk_mq_queue_data *qd)
> +static blk_status_t scm_blk_request(struct blk_mq_hw_ctx *hctx,
> +				    const struct blk_mq_queue_data *qd)
>  {
>  	struct scm_device *scmdev = hctx->queue->queuedata;
>  	struct scm_blk_dev *bdev = dev_get_drvdata(&scmdev->dev);
> 

Good point, I have done that today.  The complete fix up patch now
looks like this:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 13 Jun 2017 20:51:32 +1000
Subject: [PATCH] s390: fix up for "blk-mq: switch ->queue_rq return value to
 blk_status_t"

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

diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c
index 42018a20f2b7..0071febac9e6 100644
--- a/drivers/s390/block/scm_blk.c
+++ b/drivers/s390/block/scm_blk.c
@@ -278,7 +278,7 @@ struct scm_queue {
 	spinlock_t lock;
 };
 
-static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
+static blk_status_t scm_blk_request(struct blk_mq_hw_ctx *hctx,
 			   const struct blk_mq_queue_data *qd)
 {
 	struct scm_device *scmdev = hctx->queue->queuedata;
@@ -290,7 +290,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 	spin_lock(&sq->lock);
 	if (!scm_permit_request(bdev, req)) {
 		spin_unlock(&sq->lock);
-		return BLK_MQ_RQ_QUEUE_BUSY;
+		return BLK_STS_RESOURCE;
 	}
 
 	scmrq = sq->scmrq;
@@ -299,7 +299,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 		if (!scmrq) {
 			SCM_LOG(5, "no request");
 			spin_unlock(&sq->lock);
-			return BLK_MQ_RQ_QUEUE_BUSY;
+			return BLK_STS_RESOURCE;
 		}
 		scm_request_init(bdev, scmrq);
 		sq->scmrq = scmrq;
@@ -315,7 +315,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 
 		sq->scmrq = NULL;
 		spin_unlock(&sq->lock);
-		return BLK_MQ_RQ_QUEUE_BUSY;
+		return BLK_STS_RESOURCE;
 	}
 	blk_mq_start_request(req);
 
@@ -324,7 +324,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 		sq->scmrq = NULL;
 	}
 	spin_unlock(&sq->lock);
-	return BLK_MQ_RQ_QUEUE_OK;
+	return BLK_STS_OK;
 }
 
 static int scm_blk_init_hctx(struct blk_mq_hw_ctx *hctx, void *data,
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-06-15 14:50 ` Sebastian Ott
@ 2017-06-19  9:00   ` Sebastian Ott
  2017-06-20  1:45     ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Sebastian Ott @ 2017-06-19  9:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Martin Schwidefsky, Heiko Carstens,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig

On Thu, 15 Jun 2017, Sebastian Ott wrote:
> On Tue, 13 Jun 2017, Stephen Rothwell wrote:
> > After merging the block tree, today's linux-next build (s390x
> > s390-defconfig) failed like this:
> > 
> > drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared (first use in this function)
> > drivers/s390/block/scm_blk.c:327:9: error: 'BLK_MQ_RQ_QUEUE_OK' undeclared (first use in this function)
> > 
> > Caused by commit
> > 
> >   fc17b6534eb8 ("blk-mq: switch ->queue_rq return value to blk_status_t")
> > 
> > interacting with commit
> > 
> >   12d907626539 ("s390/scm: convert to blk-mq")
> > 
> > from the s390 tree.
> > 
> > Is the following the correct merge fixup?
> 
> Yes, that looks good!

Ok, we should also adjust the return code to fix this:

drivers/s390/block/scm_blk.c:426:2: warning: initialization from incompatible pointer type [enabled by default]
  .queue_rq = scm_blk_request,
  ^

diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c
index 2cd6123c8f18..4279685901bf 100644
--- a/drivers/s390/block/scm_blk.c
+++ b/drivers/s390/block/scm_blk.c
@@ -278,8 +278,8 @@ struct scm_queue {
 	spinlock_t lock;
 };
 
-static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
-			   const struct blk_mq_queue_data *qd)
+static blk_status_t scm_blk_request(struct blk_mq_hw_ctx *hctx,
+				    const struct blk_mq_queue_data *qd)
 {
 	struct scm_device *scmdev = hctx->queue->queuedata;
 	struct scm_blk_dev *bdev = dev_get_drvdata(&scmdev->dev);

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-06-13 10:54 Stephen Rothwell
@ 2017-06-15 14:50 ` Sebastian Ott
  2017-06-19  9:00   ` Sebastian Ott
  2017-07-04 15:15 ` Guenter Roeck
  1 sibling, 1 reply; 176+ messages in thread
From: Sebastian Ott @ 2017-06-15 14:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Martin Schwidefsky, Heiko Carstens,
	Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig

On Tue, 13 Jun 2017, Stephen Rothwell wrote:
> After merging the block tree, today's linux-next build (s390x
> s390-defconfig) failed like this:
> 
> drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared (first use in this function)
> drivers/s390/block/scm_blk.c:327:9: error: 'BLK_MQ_RQ_QUEUE_OK' undeclared (first use in this function)
> 
> Caused by commit
> 
>   fc17b6534eb8 ("blk-mq: switch ->queue_rq return value to blk_status_t")
> 
> interacting with commit
> 
>   12d907626539 ("s390/scm: convert to blk-mq")
> 
> from the s390 tree.
> 
> Is the following the correct merge fixup?

Yes, that looks good!

Thanks,
Sebastian

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2017-06-13 10:54 Stephen Rothwell
  2017-06-15 14:50 ` Sebastian Ott
  2017-07-04 15:15 ` Guenter Roeck
  0 siblings, 2 replies; 176+ messages in thread
From: Stephen Rothwell @ 2017-06-13 10:54 UTC (permalink / raw)
  To: Jens Axboe, Martin Schwidefsky, Heiko Carstens
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Sebastian Ott

Hi Jall,

After merging the block tree, today's linux-next build (s390x
s390-defconfig) failed like this:

drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared (first use in this function)
drivers/s390/block/scm_blk.c:327:9: error: 'BLK_MQ_RQ_QUEUE_OK' undeclared (first use in this function)

Caused by commit

  fc17b6534eb8 ("blk-mq: switch ->queue_rq return value to blk_status_t")

interacting with commit

  12d907626539 ("s390/scm: convert to blk-mq")

from the s390 tree.

Is the following the correct merge fixup?

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 13 Jun 2017 20:51:32 +1000
Subject: [PATCH] s390: fix up for "blk-mq: switch ->queue_rq return value to
 blk_status_t"

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

diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c
index 42018a20f2b7..2cd6123c8f18 100644
--- a/drivers/s390/block/scm_blk.c
+++ b/drivers/s390/block/scm_blk.c
@@ -290,7 +290,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 	spin_lock(&sq->lock);
 	if (!scm_permit_request(bdev, req)) {
 		spin_unlock(&sq->lock);
-		return BLK_MQ_RQ_QUEUE_BUSY;
+		return BLK_STS_RESOURCE;
 	}
 
 	scmrq = sq->scmrq;
@@ -299,7 +299,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 		if (!scmrq) {
 			SCM_LOG(5, "no request");
 			spin_unlock(&sq->lock);
-			return BLK_MQ_RQ_QUEUE_BUSY;
+			return BLK_STS_RESOURCE;
 		}
 		scm_request_init(bdev, scmrq);
 		sq->scmrq = scmrq;
@@ -315,7 +315,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 
 		sq->scmrq = NULL;
 		spin_unlock(&sq->lock);
-		return BLK_MQ_RQ_QUEUE_BUSY;
+		return BLK_STS_RESOURCE;
 	}
 	blk_mq_start_request(req);
 
@@ -324,7 +324,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 		sq->scmrq = NULL;
 	}
 	spin_unlock(&sq->lock);
-	return BLK_MQ_RQ_QUEUE_OK;
+	return BLK_STS_OK;
 }
 
 static int scm_blk_init_hctx(struct blk_mq_hw_ctx *hctx, void *data,
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2017-06-13  4:10 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2017-06-13  4:10 UTC (permalink / raw)
  To: Jens Axboe, David Sterba
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Liu Bo

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/btrfs/inode.c: In function 'btrfs_endio_direct_read':
fs/btrfs/inode.c:8278:7: error: 'struct bio' has no member named 'bi_error'
    bio->bi_error = 0;
       ^

Caused by commit

  4e4cbee93d56 ("block: switch bios to blk_status_t")

interacting with commit

  674d8fe747c8 ("Btrfs: tolerate errors if we have retried successfully")

from the btrfs-kdave tree.

I appled that following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 13 Jun 2017 14:01:24 +1000
Subject: [PATCH] btrfs: merge fix for "block: switch bios to blk_status_t"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/btrfs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index d2ec62ad4998..15af1ef31a45 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8275,7 +8275,7 @@ static void btrfs_endio_direct_read(struct bio *bio)
 	if (dip->flags & BTRFS_DIO_ORIG_BIO_SUBMITTED) {
 		err = btrfs_subio_endio_read(inode, io_bio, err);
 		if (!err)
-			bio->bi_error = 0;
+			bio->bi_status = 0;
 	}
 
 	unlock_extent(&BTRFS_I(inode)->io_tree, dip->logical_offset,
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-05-02  1:37     ` Stephen Rothwell
@ 2017-05-02  1:45       ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2017-05-02  1:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Josef Bacik, Johannes Berg, Linus

On May 1, 2017, at 7:37 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi Jens,
> 
>> On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe <axboe@kernel.dk> wrote:
>> 
>> Indeed, I have warned Linus about it. Thanks Stephen. 
> 
> Thanks.
> 
> BTW, (unusually) I did not see your pull request(s) ...

I CC'ed linux-block, so they showed up there at least. 

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-05-02  1:09   ` Jens Axboe
@ 2017-05-02  1:37     ` Stephen Rothwell
  2017-05-02  1:45       ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2017-05-02  1:37 UTC (permalink / raw)
  To: Jens Axboe
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Josef Bacik, Johannes Berg, Linus

Hi Jens,

On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe <axboe@kernel.dk> wrote:
>
> Indeed, I have warned Linus about it. Thanks Stephen. 

Thanks.

BTW, (unusually) I did not see your pull request(s) ...

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-05-02  1:07 ` Stephen Rothwell
@ 2017-05-02  1:09   ` Jens Axboe
  2017-05-02  1:37     ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2017-05-02  1:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, Networking, Linux-Next Mailing List,
	Linux Kernel Mailing List, Josef Bacik, Johannes Berg, Linus


> On May 1, 2017, at 7:07 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi all,
> 
>> On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> 
>> After merging the block tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>> 
>> drivers/block/nbd.c: In function 'nbd_genl_connect':
>> drivers/block/nbd.c:1662:10: error: too few arguments to function 'nla_parse_nested'
>>    ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>>          ^
>> In file included from include/net/rtnetlink.h:5:0,
>>                 from include/net/sch_generic.h:12,
>>                 from include/linux/filter.h:20,
>>                 from include/net/sock.h:64,
>>                 from drivers/block/nbd.c:32:
>> include/net/netlink.h:754:19: note: declared here
>> static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
>>                   ^
>> drivers/block/nbd.c: In function 'nbd_genl_reconfigure':
>> drivers/block/nbd.c:1818:10: error: too few arguments to function 'nla_parse_nested'
>>    ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>>          ^
>> In file included from include/net/rtnetlink.h:5:0,
>>                 from include/net/sch_generic.h:12,
>>                 from include/linux/filter.h:20,
>>                 from include/net/sock.h:64,
>>                 from drivers/block/nbd.c:32:
>> include/net/netlink.h:754:19: note: declared here
>> static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
>>                   ^
>> 
>> Caused by commits
>> 
>>  e46c7287b1c2 ("nbd: add a basic netlink interface")
>>  b7aa3d39385d ("nbd: add a reconfigure netlink command")
>> 
>> interacting with commit
>> 
>>  fceb6435e852 ("netlink: pass extended ACK struct to parsing functions")
>> 
>> from the net-next tree.
>> 
>> I have applied the following merge fix patch:
>> 
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 18 Apr 2017 12:59:05 +1000
>> Subject: [PATCH] nbd: fix up for nla_parse_nested() API change
>> 
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> drivers/block/nbd.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
>> index b78f23ce2395..5049d19f3940 100644
>> --- a/drivers/block/nbd.c
>> +++ b/drivers/block/nbd.c
>> @@ -1660,7 +1660,7 @@ static int nbd_genl_connect(struct sk_buff *skb, struct genl_info *info)
>>                goto out;
>>            }
>>            ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>> -                           nbd_sock_policy);
>> +                           nbd_sock_policy, NULL);
>>            if (ret != 0) {
>>                printk(KERN_ERR "nbd: error processing sock list\n");
>>                ret = -EINVAL;
>> @@ -1816,7 +1816,7 @@ static int nbd_genl_reconfigure(struct sk_buff *skb, struct genl_info *info)
>>                goto out;
>>            }
>>            ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>> -                           nbd_sock_policy);
>> +                           nbd_sock_policy, NULL);
>>            if (ret != 0) {
>>                printk(KERN_ERR "nbd: error processing sock list\n");
>>                ret = -EINVAL;
>> -- 
>> 2.11.0
> 
> So, this merge fix is now needed when the net-next tree is merged (as
> Linus has merged the block tree).

Indeed, I have warned Linus about it. Thanks Stephen. 

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-04-18  3:02 Stephen Rothwell
@ 2017-05-02  1:07 ` Stephen Rothwell
  2017-05-02  1:09   ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2017-05-02  1:07 UTC (permalink / raw)
  To: Jens Axboe, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Josef Bacik,
	Johannes Berg, Linus

Hi all,

On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/block/nbd.c: In function 'nbd_genl_connect':
> drivers/block/nbd.c:1662:10: error: too few arguments to function 'nla_parse_nested'
>     ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>           ^
> In file included from include/net/rtnetlink.h:5:0,
>                  from include/net/sch_generic.h:12,
>                  from include/linux/filter.h:20,
>                  from include/net/sock.h:64,
>                  from drivers/block/nbd.c:32:
> include/net/netlink.h:754:19: note: declared here
>  static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
>                    ^
> drivers/block/nbd.c: In function 'nbd_genl_reconfigure':
> drivers/block/nbd.c:1818:10: error: too few arguments to function 'nla_parse_nested'
>     ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>           ^
> In file included from include/net/rtnetlink.h:5:0,
>                  from include/net/sch_generic.h:12,
>                  from include/linux/filter.h:20,
>                  from include/net/sock.h:64,
>                  from drivers/block/nbd.c:32:
> include/net/netlink.h:754:19: note: declared here
>  static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
>                    ^
> 
> Caused by commits
> 
>   e46c7287b1c2 ("nbd: add a basic netlink interface")
>   b7aa3d39385d ("nbd: add a reconfigure netlink command")
> 
> interacting with commit
> 
>   fceb6435e852 ("netlink: pass extended ACK struct to parsing functions")
> 
> from the net-next tree.
> 
> I have applied the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 18 Apr 2017 12:59:05 +1000
> Subject: [PATCH] nbd: fix up for nla_parse_nested() API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/block/nbd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index b78f23ce2395..5049d19f3940 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -1660,7 +1660,7 @@ static int nbd_genl_connect(struct sk_buff *skb, struct genl_info *info)
>  				goto out;
>  			}
>  			ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
> -					       nbd_sock_policy);
> +					       nbd_sock_policy, NULL);
>  			if (ret != 0) {
>  				printk(KERN_ERR "nbd: error processing sock list\n");
>  				ret = -EINVAL;
> @@ -1816,7 +1816,7 @@ static int nbd_genl_reconfigure(struct sk_buff *skb, struct genl_info *info)
>  				goto out;
>  			}
>  			ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
> -					       nbd_sock_policy);
> +					       nbd_sock_policy, NULL);
>  			if (ret != 0) {
>  				printk(KERN_ERR "nbd: error processing sock list\n");
>  				ret = -EINVAL;
> -- 
> 2.11.0

So, this merge fix is now needed when the net-next tree is merged (as
Linus has merged the block tree).

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2017-04-18  3:02 Stephen Rothwell
  2017-05-02  1:07 ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2017-04-18  3:02 UTC (permalink / raw)
  To: Jens Axboe, David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Josef Bacik,
	Johannes Berg

Hi all,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/block/nbd.c: In function 'nbd_genl_connect':
drivers/block/nbd.c:1662:10: error: too few arguments to function 'nla_parse_nested'
    ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
          ^
In file included from include/net/rtnetlink.h:5:0,
                 from include/net/sch_generic.h:12,
                 from include/linux/filter.h:20,
                 from include/net/sock.h:64,
                 from drivers/block/nbd.c:32:
include/net/netlink.h:754:19: note: declared here
 static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
                   ^
drivers/block/nbd.c: In function 'nbd_genl_reconfigure':
drivers/block/nbd.c:1818:10: error: too few arguments to function 'nla_parse_nested'
    ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
          ^
In file included from include/net/rtnetlink.h:5:0,
                 from include/net/sch_generic.h:12,
                 from include/linux/filter.h:20,
                 from include/net/sock.h:64,
                 from drivers/block/nbd.c:32:
include/net/netlink.h:754:19: note: declared here
 static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
                   ^

Caused by commits

  e46c7287b1c2 ("nbd: add a basic netlink interface")
  b7aa3d39385d ("nbd: add a reconfigure netlink command")

interacting with commit

  fceb6435e852 ("netlink: pass extended ACK struct to parsing functions")

from the net-next tree.

I have applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 18 Apr 2017 12:59:05 +1000
Subject: [PATCH] nbd: fix up for nla_parse_nested() API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/block/nbd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index b78f23ce2395..5049d19f3940 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1660,7 +1660,7 @@ static int nbd_genl_connect(struct sk_buff *skb, struct genl_info *info)
 				goto out;
 			}
 			ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
-					       nbd_sock_policy);
+					       nbd_sock_policy, NULL);
 			if (ret != 0) {
 				printk(KERN_ERR "nbd: error processing sock list\n");
 				ret = -EINVAL;
@@ -1816,7 +1816,7 @@ static int nbd_genl_reconfigure(struct sk_buff *skb, struct genl_info *info)
 				goto out;
 			}
 			ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
-					       nbd_sock_policy);
+					       nbd_sock_policy, NULL);
 			if (ret != 0) {
 				printk(KERN_ERR "nbd: error processing sock list\n");
 				ret = -EINVAL;
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-01-30  1:53 ` Jens Axboe
  2017-01-30  3:07   ` Jens Axboe
@ 2017-01-30  6:34   ` Christoph Hellwig
  1 sibling, 0 replies; 176+ messages in thread
From: Christoph Hellwig @ 2017-01-30  6:34 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Stephen Rothwell, linux-next, linux-kernel, Christoph Hellwig

On Sun, Jan 29, 2017 at 06:53:42PM -0700, Jens Axboe wrote:
> Huh, I wonder how that snuck past my allmodconfig builds, that looks
> like a clear failure.

I also did tons of test builds and never saw it, not sure why
the NVMe-SCSI code still someone how an implicit include of scsi_cmnd.h.

But in the end it should not be using the defintion anyway, and I sent
a patch on Saturday so that it doesn't:

	[PATCH 1/5] nvme/scsi: don't rely on BLK_MAX_CDB

might make sense to expedite that.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-01-30  1:53 ` Jens Axboe
@ 2017-01-30  3:07   ` Jens Axboe
  2017-01-30  6:34   ` Christoph Hellwig
  1 sibling, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2017-01-30  3:07 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Christoph Hellwig

On 01/29/2017 06:53 PM, Jens Axboe wrote:
> On 01/29/2017 06:43 PM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvme/host/scsi.c: In function 'nvme_scsi_translate':
>> drivers/nvme/host/scsi.c:2350:9: error: 'BLK_MAX_CDB' undeclared (first use in this function)
>>   u8 cmd[BLK_MAX_CDB];
>>          ^
>> drivers/nvme/host/scsi.c:2350:9: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/nvme/host/scsi.c:2350:5: warning: unused variable 'cmd' [-Wunused-variable]
>>   u8 cmd[BLK_MAX_CDB];
>>      ^
>> drivers/nvme/host/scsi.c: In function 'nvme_sg_io':
>> drivers/nvme/host/scsi.c:2454:20: error: 'BLK_MAX_CDB' undeclared (first use in this function)  
>>   if (hdr.cmd_len > BLK_MAX_CDB)
>>                     ^
>>
>> Caused by commit
>>
>>   82ed4db499b8 ("block: split scsi_request out of struct request")
>>
>> I have used the block tree from next-20170125 for today.
> 
> Huh, I wonder how that snuck past my allmodconfig builds, that looks
> like a clear failure.

Fixed, sorry about that.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2017-01-30  1:43 Stephen Rothwell
@ 2017-01-30  1:53 ` Jens Axboe
  2017-01-30  3:07   ` Jens Axboe
  2017-01-30  6:34   ` Christoph Hellwig
  0 siblings, 2 replies; 176+ messages in thread
From: Jens Axboe @ 2017-01-30  1:53 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Christoph Hellwig

On 01/29/2017 06:43 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/nvme/host/scsi.c: In function 'nvme_scsi_translate':
> drivers/nvme/host/scsi.c:2350:9: error: 'BLK_MAX_CDB' undeclared (first use in this function)
>   u8 cmd[BLK_MAX_CDB];
>          ^
> drivers/nvme/host/scsi.c:2350:9: note: each undeclared identifier is reported only once for each function it appears in
> drivers/nvme/host/scsi.c:2350:5: warning: unused variable 'cmd' [-Wunused-variable]
>   u8 cmd[BLK_MAX_CDB];
>      ^
> drivers/nvme/host/scsi.c: In function 'nvme_sg_io':
> drivers/nvme/host/scsi.c:2454:20: error: 'BLK_MAX_CDB' undeclared (first use in this function)  
>   if (hdr.cmd_len > BLK_MAX_CDB)
>                     ^
> 
> Caused by commit
> 
>   82ed4db499b8 ("block: split scsi_request out of struct request")
> 
> I have used the block tree from next-20170125 for today.

Huh, I wonder how that snuck past my allmodconfig builds, that looks
like a clear failure.


-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2017-01-30  1:43 Stephen Rothwell
  2017-01-30  1:53 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2017-01-30  1:43 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Christoph Hellwig

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/nvme/host/scsi.c: In function 'nvme_scsi_translate':
drivers/nvme/host/scsi.c:2350:9: error: 'BLK_MAX_CDB' undeclared (first use in this function)
  u8 cmd[BLK_MAX_CDB];
         ^
drivers/nvme/host/scsi.c:2350:9: note: each undeclared identifier is reported only once for each function it appears in
drivers/nvme/host/scsi.c:2350:5: warning: unused variable 'cmd' [-Wunused-variable]
  u8 cmd[BLK_MAX_CDB];
     ^
drivers/nvme/host/scsi.c: In function 'nvme_sg_io':
drivers/nvme/host/scsi.c:2454:20: error: 'BLK_MAX_CDB' undeclared (first use in this function)  
  if (hdr.cmd_len > BLK_MAX_CDB)
                    ^

Caused by commit

  82ed4db499b8 ("block: split scsi_request out of struct request")

I have used the block tree from next-20170125 for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-12-01  3:02   ` Stephen Rothwell
@ 2016-12-01  3:04     ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2016-12-01  3:04 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Chinner, xfs, linux-next, linux-kernel, Christoph Hellwig

On 11/30/2016 08:02 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Wed, 30 Nov 2016 20:00:36 -0700 Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 11/30/2016 07:55 PM, Stephen Rothwell wrote:
>>>
>>> I love APIs changing :-(  
>>
>> It's a necessary evil...
> 
> Yeah
> 
>> This could have been avoided with the XFS tree pulling in the block
>> changes, but that obviously has other implications. Something to watch
>> for when the XFS tree is sent in for the merge window, however.
> 
> Indeed.  Or the block tree, which ever comes last.

Sure, but I usually try and push in the first few days since other trees
depend on mine. So it's more likely that the XFS tree will run into the
issue.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-12-01  3:00 ` Jens Axboe
@ 2016-12-01  3:02   ` Stephen Rothwell
  2016-12-01  3:04     ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2016-12-01  3:02 UTC (permalink / raw)
  To: Jens Axboe
  Cc: David Chinner, xfs, linux-next, linux-kernel, Christoph Hellwig

Hi Jens,

On Wed, 30 Nov 2016 20:00:36 -0700 Jens Axboe <axboe@kernel.dk> wrote:
>
> On 11/30/2016 07:55 PM, Stephen Rothwell wrote:
> > 
> > I love APIs changing :-(  
> 
> It's a necessary evil...

Yeah

> This could have been avoided with the XFS tree pulling in the block
> changes, but that obviously has other implications. Something to watch
> for when the XFS tree is sent in for the merge window, however.

Indeed.  Or the block tree, which ever comes last.

> > I have applied the following merge fix patch for today.  
> 
> The fix is correct.

Thanks.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-12-01  2:55 Stephen Rothwell
@ 2016-12-01  3:00 ` Jens Axboe
  2016-12-01  3:02   ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2016-12-01  3:00 UTC (permalink / raw)
  To: Stephen Rothwell, David Chinner, xfs
  Cc: linux-next, linux-kernel, Christoph Hellwig

On 11/30/2016 07:55 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/iomap.c: In function 'iomap_dio_zero':
> fs/iomap.c:725:38: error: 'WRITE_ODIRECT' undeclared (first use in this function)
>   bio_set_op_attrs(bio, REQ_OP_WRITE, WRITE_ODIRECT);
>                                       ^
> fs/iomap.c:725:38: note: each undeclared identifier is reported only once for each function it appears in
> fs/iomap.c: In function 'iomap_dio_actor':
> fs/iomap.c:808:40: error: 'WRITE_ODIRECT' undeclared (first use in this function)
>     bio_set_op_attrs(bio, REQ_OP_WRITE, WRITE_ODIRECT);
>                                         ^
> fs/iomap.c: In function 'iomap_dio_rw':
> fs/iomap.c:933:9: error: implicit declaration of function 'blk_poll' [-Werror=implicit-function-declaration]
>         !blk_poll(dio->submit.last_queue,
>          ^
> 
> Caused by commits
> 
>   70fd76140a6c ("block,fs: use REQ_* flags directly")
>   bbd7bb7017d5 ("block: move poll code to blk-mq")
> 
> interacting with commit
> 
>   ff6a9292e6f6 ("iomap: implement direct I/O")
> 
> from the xfs tree.
> 
> I love APIs changing :-(

It's a necessary evil...

This could have been avoided with the XFS tree pulling in the block
changes, but that obviously has other implications. Something to watch
for when the XFS tree is sent in for the merge window, however.

> I have applied the following merge fix patch for today.

The fix is correct.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2016-12-01  2:55 Stephen Rothwell
  2016-12-01  3:00 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2016-12-01  2:55 UTC (permalink / raw)
  To: Jens Axboe, David Chinner, xfs
  Cc: linux-next, linux-kernel, Christoph Hellwig

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/iomap.c: In function 'iomap_dio_zero':
fs/iomap.c:725:38: error: 'WRITE_ODIRECT' undeclared (first use in this function)
  bio_set_op_attrs(bio, REQ_OP_WRITE, WRITE_ODIRECT);
                                      ^
fs/iomap.c:725:38: note: each undeclared identifier is reported only once for each function it appears in
fs/iomap.c: In function 'iomap_dio_actor':
fs/iomap.c:808:40: error: 'WRITE_ODIRECT' undeclared (first use in this function)
    bio_set_op_attrs(bio, REQ_OP_WRITE, WRITE_ODIRECT);
                                        ^
fs/iomap.c: In function 'iomap_dio_rw':
fs/iomap.c:933:9: error: implicit declaration of function 'blk_poll' [-Werror=implicit-function-declaration]
        !blk_poll(dio->submit.last_queue,
         ^

Caused by commits

  70fd76140a6c ("block,fs: use REQ_* flags directly")
  bbd7bb7017d5 ("block: move poll code to blk-mq")

interacting with commit

  ff6a9292e6f6 ("iomap: implement direct I/O")

from the xfs tree.

I love APIs changing :-(

I have applied the following merge fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 1 Dec 2016 13:45:33 +1100
Subject: [PATCH] iomap: fix up for blk_poll and WRITE_ODIRECT change

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

diff --git a/fs/iomap.c b/fs/iomap.c
index fc2446242935..c9d6c1176345 100644
--- a/fs/iomap.c
+++ b/fs/iomap.c
@@ -722,7 +722,7 @@ iomap_dio_zero(struct iomap_dio *dio, struct iomap *iomap, loff_t pos,
 	get_page(page);
 	if (bio_add_page(bio, page, len, 0) != len)
 		BUG();
-	bio_set_op_attrs(bio, REQ_OP_WRITE, WRITE_ODIRECT);
+	bio_set_op_attrs(bio, REQ_OP_WRITE, REQ_SYNC | REQ_IDLE);
 
 	atomic_inc(&dio->ref);
 	return submit_bio(bio);
@@ -805,7 +805,7 @@ iomap_dio_actor(struct inode *inode, loff_t pos, loff_t length,
 		}
 
 		if (dio->flags & IOMAP_DIO_WRITE) {
-			bio_set_op_attrs(bio, REQ_OP_WRITE, WRITE_ODIRECT);
+			bio_set_op_attrs(bio, REQ_OP_WRITE, REQ_SYNC | REQ_IDLE);
 			task_io_account_write(bio->bi_iter.bi_size);
 		} else {
 			bio_set_op_attrs(bio, REQ_OP_READ, 0);
@@ -930,7 +930,7 @@ iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter, struct iomap_ops *ops,
 
 			if (!(iocb->ki_flags & IOCB_HIPRI) ||
 			    !dio->submit.last_queue ||
-			    !blk_poll(dio->submit.last_queue,
+			    !blk_mq_poll(dio->submit.last_queue,
 					dio->submit.cookie))
 				io_schedule();
 		}
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-11-08  3:21 Stephen Rothwell
@ 2016-11-08  3:28 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2016-11-08  3:28 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Ming Lei, Christoph Hellwig

On 11/07/2016 08:21 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> block/blk-flush.c: In function 'flush_data_end_io':
> block/blk-flush.c:369:20: error: 'REQ_STARTED' undeclared (first use in this function)
>   rq->cmd_flags &= ~REQ_STARTED;
>                     ^
>
> Caused by commit
>
>   e806402130c9 ("block: split out request-only flags into a new namespace")
>
> interacting with commit
>
>   94d7dea448fa ("block: flush: fix IO hang in case of flood fua req")
>
> from Linus' tree (v4.9-rc3).
>
> I have applied the following merge fix patch for today (I don't know if
> this is correct, but it does build):

It's correct, it needs to be applied if merging with master. It will
throw a real conflict as well, but this one tends to fly under the radar
since it merges cleanly.

I'll merge master into my for-next so you don't have to carry extra
patches for this.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2016-11-08  3:21 Stephen Rothwell
  2016-11-08  3:28 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2016-11-08  3:21 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Ming Lei, Christoph Hellwig

Hi Jens,

After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

block/blk-flush.c: In function 'flush_data_end_io':
block/blk-flush.c:369:20: error: 'REQ_STARTED' undeclared (first use in this function)
  rq->cmd_flags &= ~REQ_STARTED;
                    ^

Caused by commit

  e806402130c9 ("block: split out request-only flags into a new namespace")

interacting with commit

  94d7dea448fa ("block: flush: fix IO hang in case of flood fua req")

from Linus' tree (v4.9-rc3).

I have applied the following merge fix patch for today (I don't know if
this is correct, but it does build):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 8 Nov 2016 14:08:03 +1100
Subject: [PATCH] block: fixup for "split out request-only flags into a new namespace"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 block/blk-flush.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-flush.c b/block/blk-flush.c
index 0a02e765fa14..0bef7432d725 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -366,7 +366,7 @@ static void flush_data_end_io(struct request *rq, int error)
 	elv_completed_request(q, rq);
 
 	/* for avoiding double accounting */
-	rq->cmd_flags &= ~REQ_STARTED;
+	rq->rq_flags &= ~RQF_STARTED;
 
 	/*
 	 * After populating an empty queue, kick it to avoid stall.  Read
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-09-19  6:18 Stephen Rothwell
  2016-09-19 13:48 ` Christoph Hellwig
@ 2016-09-19 14:22 ` Jens Axboe
  1 sibling, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2016-09-19 14:22 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Christoph Hellwig

On 09/19/2016 12:18 AM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> In file included from block/blk-mq-pci.c:13:0:
> include/linux/blk-mq.h:57:18: error: field 'kobj' has incomplete type
>   struct kobject  kobj;
>                   ^
> include/linux/blk-mq.h:121:2: error: unknown type name 'softirq_done_fn'
>   softirq_done_fn  *complete;
>   ^
> include/linux/blk-mq.h: In function 'blk_mq_rq_from_pdu':
> include/linux/blk-mq.h:253:22: error: invalid application of 'sizeof' to incomplete type 'struct request'
>   return pdu - sizeof(struct request);
>                       ^
> include/linux/blk-mq.h: In function 'blk_mq_rq_to_pdu':
> include/linux/blk-mq.h:257:2: error: invalid use of undefined type 'struct request'
>   return rq + 1;
>   ^
>
> Caused by commit
>
>   973c4e372c8f ("blk-mq: provide a default queue mapping for PCI device")
>
> include/linux/blk-mq.h does not include all the headers files that it
> depends on, and building block/blk-mq-pci.c should depend on CONFIG_BLOCK.
>
> I applied this fix patch (the block/blk-mq-pci.c may not be becessary):

Added, thanks Stephen.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-09-19  6:18 Stephen Rothwell
@ 2016-09-19 13:48 ` Christoph Hellwig
  2016-09-19 14:22 ` Jens Axboe
  1 sibling, 0 replies; 176+ messages in thread
From: Christoph Hellwig @ 2016-09-19 13:48 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Jens Axboe, linux-next, linux-kernel, Christoph Hellwig

Thanks Stephen,

the fix looks good to me:

Reviewed-by: Christoph Hellwig <hch@lst.de>


I had actually seen the error earlier, but for the setups I got builbot
results moving the code to this new pci-dependent file fixed it.  I guess
that didn't went far enough.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2016-09-19  6:18 Stephen Rothwell
  2016-09-19 13:48 ` Christoph Hellwig
  2016-09-19 14:22 ` Jens Axboe
  0 siblings, 2 replies; 176+ messages in thread
From: Stephen Rothwell @ 2016-09-19  6:18 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Christoph Hellwig

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
allnoconfig) failed like this:

In file included from block/blk-mq-pci.c:13:0:
include/linux/blk-mq.h:57:18: error: field 'kobj' has incomplete type
  struct kobject  kobj;
                  ^
include/linux/blk-mq.h:121:2: error: unknown type name 'softirq_done_fn'
  softirq_done_fn  *complete;
  ^
include/linux/blk-mq.h: In function 'blk_mq_rq_from_pdu':
include/linux/blk-mq.h:253:22: error: invalid application of 'sizeof' to incomplete type 'struct request'
  return pdu - sizeof(struct request);
                      ^
include/linux/blk-mq.h: In function 'blk_mq_rq_to_pdu':
include/linux/blk-mq.h:257:2: error: invalid use of undefined type 'struct request'
  return rq + 1;
  ^

Caused by commit

  973c4e372c8f ("blk-mq: provide a default queue mapping for PCI device")

include/linux/blk-mq.h does not include all the headers files that it
depends on, and building block/blk-mq-pci.c should depend on CONFIG_BLOCK.

I applied this fix patch (the block/blk-mq-pci.c may not be becessary):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 19 Sep 2016 15:50:16 +1000
Subject: [PATCH] blk_mq: linux/blk-mq.h does not include all the headers it
 depends on

and building block/blk-mq-pci.o should depend on CONFIG_BLOCK

Fixes: 973c4e372c8f ("blk-mq: provide a default queue mapping for PCI device")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 block/Kconfig      | 5 +++++
 block/Makefile     | 2 +-
 block/blk-mq-pci.c | 2 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/block/Kconfig b/block/Kconfig
index 5136ad4bb6d5..1d4d624492fc 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -125,4 +125,9 @@ config BLOCK_COMPAT
 	depends on BLOCK && COMPAT
 	default y
 
+config BLK_MQ_PCI
+	bool
+	depends on BLOCK && PCI
+	default y
+
 source block/Kconfig.iosched
diff --git a/block/Makefile b/block/Makefile
index 2447a0b1ef9c..37a0d93f97bb 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -22,4 +22,4 @@ obj-$(CONFIG_IOSCHED_CFQ)	+= cfq-iosched.o
 obj-$(CONFIG_BLOCK_COMPAT)	+= compat_ioctl.o
 obj-$(CONFIG_BLK_CMDLINE_PARSER)	+= cmdline-parser.o
 obj-$(CONFIG_BLK_DEV_INTEGRITY) += bio-integrity.o blk-integrity.o t10-pi.o
-obj-$(CONFIG_PCI)		+= blk-mq-pci.o
+obj-$(CONFIG_BLK_MQ_PCI)	+= blk-mq-pci.o
diff --git a/block/blk-mq-pci.c b/block/blk-mq-pci.c
index 33c7bd743c63..966c2169762e 100644
--- a/block/blk-mq-pci.c
+++ b/block/blk-mq-pci.c
@@ -10,6 +10,8 @@
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
  */
+#include <linux/kobject.h>
+#include <linux/blkdev.h>
 #include <linux/blk-mq.h>
 #include <linux/blk-mq-pci.h>
 #include <linux/pci.h>
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-09-16  1:14 Stephen Rothwell
@ 2016-09-16  4:13 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2016-09-16  4:13 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Josef Bacik

On 09/15/2016 07:14 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/block/nbd.c:884:2: error: unknown field 'map_queue' specified in initializer
>   .map_queue = blk_mq_map_queue,
>   ^
> /home/sfr/next/next/drivers/block/nbd.c:884:15: error: 'blk_mq_map_queue' undeclared here (not in a function)
>   .map_queue = blk_mq_map_queue,
>                ^
>
> Caused by commit
>
>   9151bcb4fb38 ("blk-mq: kill unused blk_mq_create_mq_map()")
>
> interacting with commit
>
>   fd8383fd88a2 ("nbd: convert to blkmq")
>
> also in the block tree.

That's my fault, when merged together the nbd part needs an update. I've
pushed out a fix for it.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2016-09-16  1:14 Stephen Rothwell
  2016-09-16  4:13 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2016-09-16  1:14 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Josef Bacik

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/block/nbd.c:884:2: error: unknown field 'map_queue' specified in initializer
  .map_queue = blk_mq_map_queue,
  ^
/home/sfr/next/next/drivers/block/nbd.c:884:15: error: 'blk_mq_map_queue' undeclared here (not in a function)
  .map_queue = blk_mq_map_queue,
               ^

Caused by commit

  9151bcb4fb38 ("blk-mq: kill unused blk_mq_create_mq_map()")

interacting with commit

  fd8383fd88a2 ("nbd: convert to blkmq")

also in the block tree.

I have used the block tree from next-20160915 for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-04-27  9:02           ` Michal Marek
@ 2016-04-27 13:46             ` Nicolas Pitre
  0 siblings, 0 replies; 176+ messages in thread
From: Nicolas Pitre @ 2016-04-27 13:46 UTC (permalink / raw)
  To: Michal Marek
  Cc: Stephen Rothwell, linux-next, linux-kernel, Jens Axboe, Randy Dunlap

On Wed, 27 Apr 2016, Michal Marek wrote:

> On 2016-04-26 22:48, Nicolas Pitre wrote:
> > On Wed, 27 Apr 2016, Stephen Rothwell wrote:
> > 
> >> Hi Nicolas,
> >>
> >> On Tue, 26 Apr 2016 10:40:57 -0400 (EDT) Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >>>
> >>> If you can reproduce this build failure, could you try a make mrproper 
> >>> and attempt it again?  I, too, would like to find an explanation and a 
> >>> way to reproduce.
> >>
> >> I reset my build tree to commit 9d67df654092 ("Merge remote-tracking
> >> branch 'block/for-next'") and the build failed with:
> >>
> >> ERROR: ".local_clock" [drivers/vhost/vhost_net.ko] undefined!
> >> ERROR: ".local_clock" [drivers/misc/cxl/cxl.ko] undefined!
> >>
> >> :-(
> >>
> >> So I did a "make mrproper" and did the build again.
> >>
> >> That built correctly.
> >>
> > [...]
> > 
> > OK!  After digging and diffing through 750 megabytes of make debug logs 
> > I finally found the explanation.  The if_changed directive is useless 
> > against phony targets.
> > 
> > @Stephen: could you replace the revert with the patch below in your tree?
> > 
> > @Michal: could you fold the patch below into commit 2441e78b19 in your tree?
> 
> I prefer not to overwrite the topic branches unless necessary and I
> wanted to credit Stephen, so I committed your patch with a fabricated
> commit message and your signoff (since you wanted to fold it into a
> patch that you had already signed off).

Fine with me.


Nicolas

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-04-26 20:48         ` Nicolas Pitre
  2016-04-26 21:39           ` Stephen Rothwell
@ 2016-04-27  9:02           ` Michal Marek
  2016-04-27 13:46             ` Nicolas Pitre
  1 sibling, 1 reply; 176+ messages in thread
From: Michal Marek @ 2016-04-27  9:02 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Stephen Rothwell, linux-next, linux-kernel, Jens Axboe, Randy Dunlap

On 2016-04-26 22:48, Nicolas Pitre wrote:
> On Wed, 27 Apr 2016, Stephen Rothwell wrote:
> 
>> Hi Nicolas,
>>
>> On Tue, 26 Apr 2016 10:40:57 -0400 (EDT) Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>>>
>>> If you can reproduce this build failure, could you try a make mrproper 
>>> and attempt it again?  I, too, would like to find an explanation and a 
>>> way to reproduce.
>>
>> I reset my build tree to commit 9d67df654092 ("Merge remote-tracking
>> branch 'block/for-next'") and the build failed with:
>>
>> ERROR: ".local_clock" [drivers/vhost/vhost_net.ko] undefined!
>> ERROR: ".local_clock" [drivers/misc/cxl/cxl.ko] undefined!
>>
>> :-(
>>
>> So I did a "make mrproper" and did the build again.
>>
>> That built correctly.
>>
> [...]
> 
> OK!  After digging and diffing through 750 megabytes of make debug logs 
> I finally found the explanation.  The if_changed directive is useless 
> against phony targets.
> 
> @Stephen: could you replace the revert with the patch below in your tree?
> 
> @Michal: could you fold the patch below into commit 2441e78b19 in your tree?

I prefer not to overwrite the topic branches unless necessary and I
wanted to credit Stephen, so I committed your patch with a fabricated
commit message and your signoff (since you wanted to fold it into a
patch that you had already signed off).

Michal

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-04-26 20:48         ` Nicolas Pitre
@ 2016-04-26 21:39           ` Stephen Rothwell
  2016-04-27  9:02           ` Michal Marek
  1 sibling, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2016-04-26 21:39 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Michal Marek, linux-next, linux-kernel, Jens Axboe, Randy Dunlap

Hi Nicolas,

On Tue, 26 Apr 2016 16:48:44 -0400 (EDT) Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>
> OK!  After digging and diffing through 750 megabytes of make debug logs 
> I finally found the explanation.  The if_changed directive is useless 
> against phony targets.

Thanks for working this out.

> @Stephen: could you replace the revert with the patch below in your tree?

Will do, unless Michal beats me to it.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-04-26 15:18       ` Stephen Rothwell
@ 2016-04-26 20:48         ` Nicolas Pitre
  2016-04-26 21:39           ` Stephen Rothwell
  2016-04-27  9:02           ` Michal Marek
  0 siblings, 2 replies; 176+ messages in thread
From: Nicolas Pitre @ 2016-04-26 20:48 UTC (permalink / raw)
  To: Stephen Rothwell, Michal Marek
  Cc: linux-next, linux-kernel, Jens Axboe, Randy Dunlap

On Wed, 27 Apr 2016, Stephen Rothwell wrote:

> Hi Nicolas,
> 
> On Tue, 26 Apr 2016 10:40:57 -0400 (EDT) Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >
> > If you can reproduce this build failure, could you try a make mrproper 
> > and attempt it again?  I, too, would like to find an explanation and a 
> > way to reproduce.
> 
> I reset my build tree to commit 9d67df654092 ("Merge remote-tracking
> branch 'block/for-next'") and the build failed with:
> 
> ERROR: ".local_clock" [drivers/vhost/vhost_net.ko] undefined!
> ERROR: ".local_clock" [drivers/misc/cxl/cxl.ko] undefined!
> 
> :-(
> 
> So I did a "make mrproper" and did the build again.
> 
> That built correctly.
> 
[...]

OK!  After digging and diffing through 750 megabytes of make debug logs 
I finally found the explanation.  The if_changed directive is useless 
against phony targets.

@Stephen: could you replace the revert with the patch below in your tree?

@Michal: could you fold the patch below into commit 2441e78b19 in your tree?

diff --git a/Makefile b/Makefile
index ca46af5cc0..3a7b9a93b2 100644
--- a/Makefile
+++ b/Makefile
@@ -953,7 +953,7 @@ include/generated/autoksyms.h: FORCE
       cmd_link-vmlinux = $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux)
 quiet_cmd_link-vmlinux = LINK    $@
 
-vmlinux: scripts/link-vmlinux.sh vmlinux_prereq FORCE
+vmlinux: scripts/link-vmlinux.sh vmlinux_prereq $(vmlinux-deps) FORCE
 	+$(call if_changed,link-vmlinux)
 
 # Build samples along the rest of the kernel

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-04-26 14:40     ` Nicolas Pitre
  2016-04-26 14:41       ` Jens Axboe
@ 2016-04-26 15:18       ` Stephen Rothwell
  2016-04-26 20:48         ` Nicolas Pitre
  1 sibling, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2016-04-26 15:18 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Michal Marek, linux-next, linux-kernel, Jens Axboe, Randy Dunlap

Hi Nicolas,

On Tue, 26 Apr 2016 10:40:57 -0400 (EDT) Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>
> If you can reproduce this build failure, could you try a make mrproper 
> and attempt it again?  I, too, would like to find an explanation and a 
> way to reproduce.

I reset my build tree to commit 9d67df654092 ("Merge remote-tracking
branch 'block/for-next'") and the build failed with:

ERROR: ".local_clock" [drivers/vhost/vhost_net.ko] undefined!
ERROR: ".local_clock" [drivers/misc/cxl/cxl.ko] undefined!

:-(

So I did a "make mrproper" and did the build again.

That built correctly.

Then I reset the tree to commit b087ce990625 ("Merge remote-tracking
branch 'input/next'"), did a "make mrproper", "make ppc64_defconfig",
"make" and that built correctly.  So I fast forwarded back to the block
tree merge and did "make ppc64_defconfig" and "make" and that failed
with:

ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!

Doing the revert made it build, then doing "reset --hard HEAD^" (i.e.
undoing the revert) also kept the build working.

These builds all have a separate object directory and are powerpc64le
hosted powerpc64be cross builds and use "make -j80".

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-04-26 14:40     ` Nicolas Pitre
@ 2016-04-26 14:41       ` Jens Axboe
  2016-04-26 15:18       ` Stephen Rothwell
  1 sibling, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2016-04-26 14:41 UTC (permalink / raw)
  To: Nicolas Pitre, Stephen Rothwell
  Cc: Michal Marek, linux-next, linux-kernel, Randy Dunlap

On 04/26/2016 08:40 AM, Nicolas Pitre wrote:
> On Tue, 26 Apr 2016, Stephen Rothwell wrote:
>
>> Hi Michal,
>>
>> On Tue, 26 Apr 2016 15:30:01 +0200 Michal Marek <mmarek@suse.cz> wrote:
>>>
>>> On 2016-04-26 05:38, Stephen Rothwell wrote:
>>>> Hi Nicolas,
>>>>
>>>> After merging the block tree, today's linux-next build (powerpc
>>>> ppc64_defconfig) failed like this:
>>>>
>>>> ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
>>>> ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
>>>> ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!
>>>>
>>>> Caused by commit
>>>>
>>>>    089095b8eef9 ("kbuild: better abstract vmlinux sequential prerequisites")
>>>>
>>>> from the kbuild-pite tree.
>>>>
>>>> I have reverted that commit for today.
>>>
>>> I can't reproduce this with today's linux-next and the revert reverted.
>>> Also, CONFIG_TRIM_UNUSED_KSYMS is disabled in the defconfig as expected,
>>> so I have no idea what went wrong.
>>
>> Yeah, I couldn't figure it out either, but the revert made it work for
>> me.  Could it be that I do incremental builds - so today, I would have
>> built commit b087ce990625 ("Merge remote-tracking branch 'input/next'")
>> which worked, then commit 9d67df654092 ("Merge remote-tracking branch
>> 'block/for-next'") which failed.
>>
>> The only suspect code in the block tree has been there since April 13
>> with no build failures.
>>
>> Anyway, I can see how things go tomorrow, but I hate it when things
>> seem fragile like this.
>
> If you can reproduce this build failure, could you try a make mrproper
> and attempt it again?  I, too, would like to find an explanation and a
> way to reproduce.

I just took a look at it, and it doesn't make any sense to me...

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
       [not found]   ` <v3THaCMkCzylcv3TJavAje@videotron.ca>
@ 2016-04-26 14:40     ` Nicolas Pitre
  2016-04-26 14:41       ` Jens Axboe
  2016-04-26 15:18       ` Stephen Rothwell
  0 siblings, 2 replies; 176+ messages in thread
From: Nicolas Pitre @ 2016-04-26 14:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Michal Marek, linux-next, linux-kernel, Jens Axboe, Randy Dunlap

On Tue, 26 Apr 2016, Stephen Rothwell wrote:

> Hi Michal,
> 
> On Tue, 26 Apr 2016 15:30:01 +0200 Michal Marek <mmarek@suse.cz> wrote:
> >
> > On 2016-04-26 05:38, Stephen Rothwell wrote:
> > > Hi Nicolas,
> > > 
> > > After merging the block tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > > 
> > > ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
> > > ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
> > > ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!
> > > 
> > > Caused by commit
> > > 
> > >   089095b8eef9 ("kbuild: better abstract vmlinux sequential prerequisites")
> > > 
> > > from the kbuild-pite tree.
> > > 
> > > I have reverted that commit for today.  
> > 
> > I can't reproduce this with today's linux-next and the revert reverted.
> > Also, CONFIG_TRIM_UNUSED_KSYMS is disabled in the defconfig as expected,
> > so I have no idea what went wrong.
> 
> Yeah, I couldn't figure it out either, but the revert made it work for
> me.  Could it be that I do incremental builds - so today, I would have
> built commit b087ce990625 ("Merge remote-tracking branch 'input/next'")
> which worked, then commit 9d67df654092 ("Merge remote-tracking branch
> 'block/for-next'") which failed.
> 
> The only suspect code in the block tree has been there since April 13
> with no build failures.
> 
> Anyway, I can see how things go tomorrow, but I hate it when things
> seem fragile like this.

If you can reproduce this build failure, could you try a make mrproper 
and attempt it again?  I, too, would like to find an explanation and a 
way to reproduce.


Nicolas

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-04-26 13:30 ` Michal Marek
@ 2016-04-26 13:56   ` Stephen Rothwell
       [not found]   ` <v3THaCMkCzylcv3TJavAje@videotron.ca>
  1 sibling, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2016-04-26 13:56 UTC (permalink / raw)
  To: Michal Marek
  Cc: Nicolas Pitre, linux-next, linux-kernel, Jens Axboe, Randy Dunlap

Hi Michal,

On Tue, 26 Apr 2016 15:30:01 +0200 Michal Marek <mmarek@suse.cz> wrote:
>
> On 2016-04-26 05:38, Stephen Rothwell wrote:
> > Hi Nicolas,
> > 
> > After merging the block tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
> > ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
> > ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!
> > 
> > Caused by commit
> > 
> >   089095b8eef9 ("kbuild: better abstract vmlinux sequential prerequisites")
> > 
> > from the kbuild-pite tree.
> > 
> > I have reverted that commit for today.  
> 
> I can't reproduce this with today's linux-next and the revert reverted.
> Also, CONFIG_TRIM_UNUSED_KSYMS is disabled in the defconfig as expected,
> so I have no idea what went wrong.

Yeah, I couldn't figure it out either, but the revert made it work for
me.  Could it be that I do incremental builds - so today, I would have
built commit b087ce990625 ("Merge remote-tracking branch 'input/next'")
which worked, then commit 9d67df654092 ("Merge remote-tracking branch
'block/for-next'") which failed.

The only suspect code in the block tree has been there since April 13
with no build failures.

Anyway, I can see how things go tomorrow, but I hate it when things
seem fragile like this.
-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2016-04-26  3:38 Stephen Rothwell
@ 2016-04-26 13:30 ` Michal Marek
  2016-04-26 13:56   ` Stephen Rothwell
       [not found]   ` <v3THaCMkCzylcv3TJavAje@videotron.ca>
  0 siblings, 2 replies; 176+ messages in thread
From: Michal Marek @ 2016-04-26 13:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Nicolas Pitre, linux-next, linux-kernel, Jens Axboe, Randy Dunlap

On 2016-04-26 05:38, Stephen Rothwell wrote:
> Hi Nicolas,
> 
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
> ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
> ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!
> 
> Caused by commit
> 
>   089095b8eef9 ("kbuild: better abstract vmlinux sequential prerequisites")
> 
> from the kbuild-pite tree.
> 
> I have reverted that commit for today.

I can't reproduce this with today's linux-next and the revert reverted.
Also, CONFIG_TRIM_UNUSED_KSYMS is disabled in the defconfig as expected,
so I have no idea what went wrong.

Michal

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2016-04-26  3:38 Stephen Rothwell
  2016-04-26 13:30 ` Michal Marek
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2016-04-26  3:38 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: linux-next, linux-kernel, Jens Axboe, Michal Marek, Randy Dunlap

Hi Nicolas,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk.ko] undefined!
ERROR: ".blk_queue_write_cache" [drivers/block/nbd.ko] undefined!

Caused by commit

  089095b8eef9 ("kbuild: better abstract vmlinux sequential prerequisites")

from the kbuild-pite tree.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2016-03-07  3:29 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2016-03-07  3:29 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Ming Lin, Keith Busch

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "nvme_kill_queues" [drivers/nvme/host/nvme.ko] undefined!

Caused by commit

  576d55d62566 ("nvme: split pci module out of core module")

interacting with commit

  69d9a99c258e ("NVMe: Move error handling to failed reset handler")

from Linus' tree.

I applied the merge fix patch below.  Maybe you should do a back merge
of Linus' tree and fix this up as well as the conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 Mar 2016 14:24:19 +1100
Subject: [PATCH] nvme: fix up for "split pci module out of core module"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/nvme/host/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index db47bbda06b3..e2d11d623e33 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1508,6 +1508,7 @@ void nvme_kill_queues(struct nvme_ctrl *ctrl)
 	}
 	mutex_unlock(&ctrl->namespaces_mutex);
 }
+EXPORT_SYMBOL_GPL(nvme_kill_queues);
 
 void nvme_stop_queues(struct nvme_ctrl *ctrl)
 {
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-03 16:42                   ` Christoph Hellwig
@ 2015-12-04 12:16                     ` Matias Bjørling
  0 siblings, 0 replies; 176+ messages in thread
From: Matias Bjørling @ 2015-12-04 12:16 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Mark Brown, Keith Busch, linux-next, linux-kernel,
	linux-block



On 12/03/2015 05:42 PM, Christoph Hellwig wrote:
> On Thu, Dec 03, 2015 at 12:07:23PM +0100, Matias Bjørling wrote:
>> What is the reason to keep the nvme_ns internally to the nvme core?
>>
>> We can definitely move ->nsid and the lba_shift into nvm_dev. Only thing I
>> have is that it moves a small part of nvme logic into the lightnvm core.
>
> It's a structure specific to the NVM command set, and the block device
> use to implement it in Linux.  Similar to how you wouldn't use the SCSI
> disk driver data structures to implement the tape driver for example.
>

Granted. Taking a step back and see how it would look in the 
specification. For that case, the identify geometry should properly 
replace the identify namespace command and extend the controller 
identify with a method to expose identify geometry structures. It falls 
back to that we don't have the appropriate bits in the specification (as 
there isn't a vendor specific command set (CSS) place at the moment). 
I'll rather not (and patches properly won't be accepted) push specific 
meanings to reserved bits in the standard, which then is overruled by 
vendor specific pci id's.

The NVMe and LightNVM still shares some common ground as I/O 
submission/completion still follows normal I/O submissions. The 
Submission/Completion sizes (SQES/CQES), ONCS bits, number of namespaces 
could properly be either abstracted or duplicated in vendor specific bits.

I'll work on getting ->nsid, and lba_shift abstracted away. However, the 
best solution will be to get some bits in the spec and implement it 
appropriately.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-03 11:07                 ` Matias Bjørling
@ 2015-12-03 16:42                   ` Christoph Hellwig
  2015-12-04 12:16                     ` Matias Bjørling
  0 siblings, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2015-12-03 16:42 UTC (permalink / raw)
  To: Matias Bjørling
  Cc: Christoph Hellwig, Jens Axboe, Mark Brown, Keith Busch,
	linux-next, linux-kernel, linux-block

On Thu, Dec 03, 2015 at 12:07:23PM +0100, Matias Bjørling wrote:
> What is the reason to keep the nvme_ns internally to the nvme core?
>
> We can definitely move ->nsid and the lba_shift into nvm_dev. Only thing I 
> have is that it moves a small part of nvme logic into the lightnvm core.

It's a structure specific to the NVM command set, and the block device
use to implement it in Linux.  Similar to how you wouldn't use the SCSI
disk driver data structures to implement the tape driver for example.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-03 10:21               ` Christoph Hellwig
@ 2015-12-03 11:07                 ` Matias Bjørling
  2015-12-03 16:42                   ` Christoph Hellwig
  0 siblings, 1 reply; 176+ messages in thread
From: Matias Bjørling @ 2015-12-03 11:07 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Mark Brown, Keith Busch, linux-next, linux-kernel,
	linux-block

On 12/03/2015 11:21 AM, Christoph Hellwig wrote:
> On Thu, Dec 03, 2015 at 11:09:03AM +0100, Matias Bjørling wrote:
>> Similar to this?
>
> For the interface yes.  Now just get rid of using nvme_ns entirely -
> seems like you just want ns_id and lba_shift, and those should fit
> well into nvm_dev I think.
>

What is the reason to keep the nvme_ns internally to the nvme core?

We can definitely move ->nsid and the lba_shift into nvm_dev. Only thing 
I have is that it moves a small part of nvme logic into the lightnvm core.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-03 10:09             ` Matias Bjørling
@ 2015-12-03 10:21               ` Christoph Hellwig
  2015-12-03 11:07                 ` Matias Bjørling
  0 siblings, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2015-12-03 10:21 UTC (permalink / raw)
  To: Matias Bjørling
  Cc: Christoph Hellwig, Jens Axboe, Mark Brown, Keith Busch,
	linux-next, linux-kernel, linux-block

On Thu, Dec 03, 2015 at 11:09:03AM +0100, Matias Bjørling wrote:
> Similar to this?

For the interface yes.  Now just get rid of using nvme_ns entirely -
seems like you just want ns_id and lba_shift, and those should fit
well into nvm_dev I think.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-03  9:57           ` Christoph Hellwig
@ 2015-12-03 10:09             ` Matias Bjørling
  2015-12-03 10:21               ` Christoph Hellwig
  0 siblings, 1 reply; 176+ messages in thread
From: Matias Bjørling @ 2015-12-03 10:09 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Mark Brown, Keith Busch, linux-next, linux-kernel,
	linux-block



On 12/03/2015 10:57 AM, Christoph Hellwig wrote:
> On Thu, Dec 03, 2015 at 10:52:46AM +0100, Matias Bjørling wrote:
>> The identify geometry command and bad block commands are part of the admin
>> command set. Surely, as all these take a ns id, they can be moved and be
>> accessed naturally through the user queues.
>
> Nah, these admin commands should go through the admin queue - but
> having a request_queue as the argument to the callback just seems rather
> off if it's not the right one.  Why can't you just pass the 'struct nvm_dev'
> instead of the request_queue for these methods?
>

That'll work as well.

Similar to this?

diff --git i/drivers/lightnvm/core.c w/drivers/lightnvm/core.c
index 86ce887..4a8d1fe 100644
--- i/drivers/lightnvm/core.c
+++ w/drivers/lightnvm/core.c
@@ -74,7 +74,7 @@ EXPORT_SYMBOL(nvm_unregister_target);
  void *nvm_dev_dma_alloc(struct nvm_dev *dev, gfp_t mem_flags,
  							dma_addr_t *dma_handler)
  {
-	return dev->ops->dev_dma_alloc(dev->q, dev->ppalist_pool, mem_flags,
+	return dev->ops->dev_dma_alloc(dev, dev->ppalist_pool, mem_flags,
  								dma_handler);
  }
  EXPORT_SYMBOL(nvm_dev_dma_alloc);
@@ -246,7 +246,7 @@ static int nvm_init(struct nvm_dev *dev)
  	if (!dev->q || !dev->ops)
  		return ret;

-	if (dev->ops->identity(dev->q, &dev->identity)) {
+	if (dev->ops->identity(dev, &dev->identity)) {
  		pr_err("nvm: device could not be identified\n");
  		goto err;
  	}
@@ -326,8 +326,7 @@ int nvm_register(struct request_queue *q, char 
*disk_name,
  	}

  	if (dev->ops->max_phys_sect > 1) {
-		dev->ppalist_pool = dev->ops->create_dma_pool(dev->q,
-								"ppalist");
+		dev->ppalist_pool = dev->ops->create_dma_pool(dev, "ppalist");
  		if (!dev->ppalist_pool) {
  			pr_err("nvm: could not create ppa pool\n");
  			ret = -ENOMEM;
diff --git i/drivers/nvme/host/lightnvm.c w/drivers/nvme/host/lightnvm.c
index 762c9a7..15f2acb 100644
--- i/drivers/nvme/host/lightnvm.c
+++ w/drivers/nvme/host/lightnvm.c
@@ -271,9 +271,9 @@ static int init_grps(struct nvm_id *nvm_id, struct 
nvme_nvm_id *nvme_nvm_id)
  	return 0;
  }

-static int nvme_nvm_identity(struct request_queue *q, struct nvm_id 
*nvm_id)
+static int nvme_nvm_identity(struct nvm_dev *nvmdev, struct nvm_id *nvm_id)
  {
-	struct nvme_ns *ns = q->queuedata;
+	struct nvme_ns *ns = nvmdev->q->queuedata;
  	struct nvme_dev *dev = ns->dev;
  	struct nvme_nvm_id *nvme_nvm_id;
  	struct nvme_nvm_command c = {};
@@ -308,10 +308,10 @@ out:
  	return ret;
  }

-static int nvme_nvm_get_l2p_tbl(struct request_queue *q, u64 slba, u32 nlb,
+static int nvme_nvm_get_l2p_tbl(struct nvm_dev *nvmdev, u64 slba, u32 nlb,
  				nvm_l2p_update_fn *update_l2p, void *priv)
  {
-	struct nvme_ns *ns = q->queuedata;
+	struct nvme_ns *ns = nvmdev->q->queuedata;
  	struct nvme_dev *dev = ns->dev;
  	struct nvme_nvm_command c = {};
  	u32 len = queue_max_hw_sectors(dev->admin_q) << 9;
@@ -415,10 +415,10 @@ out:
  	return ret;
  }

-static int nvme_nvm_set_bb_tbl(struct request_queue *q, struct nvm_rq *rqd,
+static int nvme_nvm_set_bb_tbl(struct nvm_dev *nvmdev, struct nvm_rq *rqd,
  								int type)
  {
-	struct nvme_ns *ns = q->queuedata;
+	struct nvme_ns *ns = nvmdev->q->queuedata;
  	struct nvme_dev *dev = ns->dev;
  	struct nvme_nvm_command c = {};
  	int ret = 0;
@@ -463,8 +463,9 @@ static void nvme_nvm_end_io(struct request *rq, int 
error)
  	blk_mq_free_request(rq);
  }

-static int nvme_nvm_submit_io(struct request_queue *q, struct nvm_rq *rqd)
+static int nvme_nvm_submit_io(struct nvm_dev *dev, struct nvm_rq *rqd)
  {
+	struct request_queue *q = dev->q;
  	struct nvme_ns *ns = q->queuedata;
  	struct request *rq;
  	struct bio *bio = rqd->bio;
@@ -502,8 +503,9 @@ static int nvme_nvm_submit_io(struct request_queue 
*q, struct nvm_rq *rqd)
  	return 0;
  }

-static int nvme_nvm_erase_block(struct request_queue *q, struct nvm_rq 
*rqd)
+static int nvme_nvm_erase_block(struct nvm_dev *dev, struct nvm_rq *rqd)
  {
+	struct request_queue *q = dev->q;
  	struct nvme_ns *ns = q->queuedata;
  	struct nvme_nvm_command c = {};

@@ -515,9 +517,9 @@ static int nvme_nvm_erase_block(struct request_queue 
*q, struct nvm_rq *rqd)
  	return nvme_submit_sync_cmd(q, (struct nvme_command *)&c, NULL, 0);
  }

-static void *nvme_nvm_create_dma_pool(struct request_queue *q, char *name)
+static void *nvme_nvm_create_dma_pool(struct nvm_dev *nvmdev, char *name)
  {
-	struct nvme_ns *ns = q->queuedata;
+	struct nvme_ns *ns = nvmdev->q->queuedata;
  	struct nvme_dev *dev = ns->dev;

  	return dma_pool_create(name, dev->dev, PAGE_SIZE, PAGE_SIZE, 0);
@@ -530,7 +532,7 @@ static void nvme_nvm_destroy_dma_pool(void *pool)
  	dma_pool_destroy(dma_pool);
  }

-static void *nvme_nvm_dev_dma_alloc(struct request_queue *q, void *pool,
+static void *nvme_nvm_dev_dma_alloc(struct nvm_dev *dev, void *pool,
  				    gfp_t mem_flags, dma_addr_t *dma_handler)
  {
  	return dma_pool_alloc(pool, mem_flags, dma_handler);
diff --git i/include/linux/lightnvm.h w/include/linux/lightnvm.h
index 935ef38..034117b 100644
--- i/include/linux/lightnvm.h
+++ w/include/linux/lightnvm.h
@@ -183,17 +183,17 @@ struct nvm_block;

  typedef int (nvm_l2p_update_fn)(u64, u32, __le64 *, void *);
  typedef int (nvm_bb_update_fn)(struct ppa_addr, int, u8 *, void *);
-typedef int (nvm_id_fn)(struct request_queue *, struct nvm_id *);
-typedef int (nvm_get_l2p_tbl_fn)(struct request_queue *, u64, u32,
+typedef int (nvm_id_fn)(struct nvm_dev *, struct nvm_id *);
+typedef int (nvm_get_l2p_tbl_fn)(struct nvm_dev *, u64, u32,
  				nvm_l2p_update_fn *, void *);
  typedef int (nvm_op_bb_tbl_fn)(struct nvm_dev *, struct ppa_addr, int,
  				nvm_bb_update_fn *, void *);
-typedef int (nvm_op_set_bb_fn)(struct request_queue *, struct nvm_rq *, 
int);
-typedef int (nvm_submit_io_fn)(struct request_queue *, struct nvm_rq *);
-typedef int (nvm_erase_blk_fn)(struct request_queue *, struct nvm_rq *);
-typedef void *(nvm_create_dma_pool_fn)(struct request_queue *, char *);
+typedef int (nvm_op_set_bb_fn)(struct nvm_dev *, struct nvm_rq *, int);
+typedef int (nvm_submit_io_fn)(struct nvm_dev *, struct nvm_rq *);
+typedef int (nvm_erase_blk_fn)(struct nvm_dev *, struct nvm_rq *);
+typedef void *(nvm_create_dma_pool_fn)(struct nvm_dev *, char *);
  typedef void (nvm_destroy_dma_pool_fn)(void *);
-typedef void *(nvm_dev_dma_alloc_fn)(struct request_queue *, void *, gfp_t,
+typedef void *(nvm_dev_dma_alloc_fn)(struct nvm_dev *, void *, gfp_t,
  								dma_addr_t *);
  typedef void (nvm_dev_dma_free_fn)(void *, void*, dma_addr_t);

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-03  9:52         ` Matias Bjørling
@ 2015-12-03  9:57           ` Christoph Hellwig
  2015-12-03 10:09             ` Matias Bjørling
  0 siblings, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2015-12-03  9:57 UTC (permalink / raw)
  To: Matias Bjørling
  Cc: Jens Axboe, Mark Brown, Keith Busch, linux-next, linux-kernel,
	linux-block

On Thu, Dec 03, 2015 at 10:52:46AM +0100, Matias Bjørling wrote:
> The identify geometry command and bad block commands are part of the admin 
> command set. Surely, as all these take a ns id, they can be moved and be 
> accessed naturally through the user queues.

Nah, these admin commands should go through the admin queue - but
having a request_queue as the argument to the callback just seems rather
off if it's not the right one.  Why can't you just pass the 'struct nvm_dev'
instead of the request_queue for these methods?

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-03  9:06       ` Christoph Hellwig
@ 2015-12-03  9:52         ` Matias Bjørling
  2015-12-03  9:57           ` Christoph Hellwig
  0 siblings, 1 reply; 176+ messages in thread
From: Matias Bjørling @ 2015-12-03  9:52 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, Mark Brown, Keith Busch, linux-next, linux-kernel,
	linux-block

On 12/03/2015 10:06 AM, Christoph Hellwig wrote:
> On Thu, Dec 03, 2015 at 09:39:01AM +0100, Matias Bjørling wrote:
>> A little crazy yes. The reason is that the NVMe admin queues and NVMe user
>> queues are driven by different request queues. Previously this was patched
>> up with having two queues in the lightnvm core. One for admin and another
>> for user. But was later merged into a single queue.
>
> Why?  If you look at the current structure we have the admin queue
> which is always allocated by the Low level driver, although it could and
> should move to the core eventually.  And then we have Command set specific
> request_queues for the I/O queues.  One per NS for NVM currenly, either
> one per NS or one globally for LightNVM, and in Fabrics I currently
> have another magic one :)  Due to the tagset pointer in struct nvme_ctrl
> that's really easy to handle.
>

The identify geometry command and bad block commands are part of the 
admin command set. Surely, as all these take a ns id, they can be moved 
and be accessed naturally through the user queues.

Let me send out a revert for that patch.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-03  8:39     ` Matias Bjørling
@ 2015-12-03  9:06       ` Christoph Hellwig
  2015-12-03  9:52         ` Matias Bjørling
  0 siblings, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2015-12-03  9:06 UTC (permalink / raw)
  To: Matias Bjørling
  Cc: Jens Axboe, Christoph Hellwig, Mark Brown, Keith Busch,
	linux-next, linux-kernel, linux-block

On Thu, Dec 03, 2015 at 09:39:01AM +0100, Matias Bjørling wrote:
> A little crazy yes. The reason is that the NVMe admin queues and NVMe user 
> queues are driven by different request queues. Previously this was patched 
> up with having two queues in the lightnvm core. One for admin and another 
> for user. But was later merged into a single queue.

Why?  If you look at the current structure we have the admin queue
which is always allocated by the Low level driver, although it could and
should move to the core eventually.  And then we have Command set specific
request_queues for the I/O queues.  One per NS for NVM currenly, either
one per NS or one globally for LightNVM, and in Fabrics I currently
have another magic one :)  Due to the tagset pointer in struct nvme_ctrl
that's really easy to handle.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-02 21:07   ` Jens Axboe
  2015-12-02 21:14     ` Keith Busch
@ 2015-12-03  8:39     ` Matias Bjørling
  2015-12-03  9:06       ` Christoph Hellwig
  1 sibling, 1 reply; 176+ messages in thread
From: Matias Bjørling @ 2015-12-03  8:39 UTC (permalink / raw)
  To: Jens Axboe, Christoph Hellwig, Mark Brown
  Cc: Keith Busch, linux-next, linux-kernel, linux-block

On 12/02/2015 10:07 PM, Jens Axboe wrote:
> On 12/02/2015 09:45 AM, Christoph Hellwig wrote:
>> Looks like I didn't test with CONFIG_NVM enabled, and neither did
>> the build bot.
>>
>> Most of this is really weird crazy shit in the lighnvm support, though.
>>
>> Struct nvme_ns is a structure for the NVM I/O command set, and it has
>> no business poking into it.  Second this commit:
>>
>> commit 47b3115ae7b799be8b77b0f024215ad4f68d6460
>> Author: Wenwei Tao <ww.tao0320@gmail.com>
>> Date:   Fri Nov 20 13:47:55 2015 +0100
>>
>>      nvme: lightnvm: use admin queues for admin cmds
>>
>> Does even more crazy stuff.  If a function gets a request_queue parameter
>> passed it'd better use that and not look for another one.

A little crazy yes. The reason is that the NVMe admin queues and NVMe 
user queues are driven by different request queues. Previously this was 
patched up with having two queues in the lightnvm core. One for admin 
and another for user. But was later merged into a single queue.

We can pass both request queues into lightnvm core, but I prefer to 
handle it in some good way in the nvme-lightnvm integration.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-02 21:27       ` Jens Axboe
@ 2015-12-03  7:35         ` Christoph Hellwig
  0 siblings, 0 replies; 176+ messages in thread
From: Christoph Hellwig @ 2015-12-03  7:35 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Keith Busch, Christoph Hellwig, Mark Brown, linux-next,
	linux-kernel, linux-block

On Wed, Dec 02, 2015 at 02:27:40PM -0700, Jens Axboe wrote:
> On 12/02/2015 02:14 PM, Keith Busch wrote:
>> On Wed, Dec 02, 2015 at 02:07:34PM -0700, Jens Axboe wrote:
>>> Christoph, for-4.5/nvme also fails if integrity isn't enabled:
>>
>> I forgot about this since I've merged this in my repo to fix:
>>
>> https://lkml.org/lkml/2015/10/26/546
>>
>> That ok, or should we handle this differently?
>
> I think that should make it compile, but the behavior will be a bit odd. If 
> you pass in meta and integrity isn't enabled, you'll get an ENOMEM error. 
> That seems a bit nonsensical.
>
> We could make bio_integrity_alloc() return an error pointer. That way we 
> could retain the ifdefs in the bip code, and not let it spread to drivers.

This looks reasonable to me.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-02 21:14     ` Keith Busch
@ 2015-12-02 21:27       ` Jens Axboe
  2015-12-03  7:35         ` Christoph Hellwig
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2015-12-02 21:27 UTC (permalink / raw)
  To: Keith Busch
  Cc: Christoph Hellwig, Mark Brown, linux-next, linux-kernel, linux-block

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

On 12/02/2015 02:14 PM, Keith Busch wrote:
> On Wed, Dec 02, 2015 at 02:07:34PM -0700, Jens Axboe wrote:
>> Christoph, for-4.5/nvme also fails if integrity isn't enabled:
>
> I forgot about this since I've merged this in my repo to fix:
>
> https://lkml.org/lkml/2015/10/26/546
>
> That ok, or should we handle this differently?

I think that should make it compile, but the behavior will be a bit odd. 
If you pass in meta and integrity isn't enabled, you'll get an ENOMEM 
error. That seems a bit nonsensical.

We could make bio_integrity_alloc() return an error pointer. That way we 
could retain the ifdefs in the bip code, and not let it spread to drivers.

-- 
Jens Axboe


[-- Attachment #2: int-err.patch --]
[-- Type: text/x-patch, Size: 3002 bytes --]

diff --git a/block/bio-integrity.c b/block/bio-integrity.c
index f6325d573c10..e6ba501eb746 100644
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -66,7 +66,7 @@ struct bio_integrity_payload *bio_integrity_alloc(struct bio *bio,
 	}
 
 	if (unlikely(!bip))
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 
 	memset(bip, 0, sizeof(*bip));
 
@@ -89,7 +89,7 @@ struct bio_integrity_payload *bio_integrity_alloc(struct bio *bio,
 	return bip;
 err:
 	mempool_free(bip, bs->bio_integrity_pool);
-	return NULL;
+	return ERR_PTR(-ENOMEM);
 }
 EXPORT_SYMBOL(bio_integrity_alloc);
 
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index c61bde9921d2..f9c4e80c2441 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -190,8 +190,8 @@ int __nvme_submit_user_cmd(struct request_queue *q, struct nvme_command *cmd,
 			}
 
 			bip = bio_integrity_alloc(bio, GFP_KERNEL, 1);
-			if (!bip) {
-				ret = -ENOMEM;
+			if (IS_ERR(bip)) {
+				ret = PTR_ERR(bip);
 				goto out_free_meta;
 			}
 
diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index f29c69120054..d5891b6ea737 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -613,9 +613,9 @@ iblock_alloc_bip(struct se_cmd *cmd, struct bio *bio)
 	}
 
 	bip = bio_integrity_alloc(bio, GFP_NOIO, cmd->t_prot_nents);
-	if (!bip) {
+	if (IS_ERR(bip)) {
 		pr_err("Unable to allocate bio_integrity_payload\n");
-		return -ENOMEM;
+		return PTR_ERR(bip);
 	}
 
 	bip->bip_iter.bi_size = (cmd->data_length / dev->dev_attrib.block_size) *
diff --git a/include/linux/bio.h b/include/linux/bio.h
index b9b6e046b52e..5349e6816cbb 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -318,16 +318,6 @@ enum bip_flags {
 	BIP_IP_CHECKSUM		= 1 << 4, /* IP checksum */
 };
 
-#if defined(CONFIG_BLK_DEV_INTEGRITY)
-
-static inline struct bio_integrity_payload *bio_integrity(struct bio *bio)
-{
-	if (bio->bi_rw & REQ_INTEGRITY)
-		return bio->bi_integrity;
-
-	return NULL;
-}
-
 /*
  * bio integrity payload
  */
@@ -349,6 +339,16 @@ struct bio_integrity_payload {
 	struct bio_vec		bip_inline_vecs[0];/* embedded bvec array */
 };
 
+#if defined(CONFIG_BLK_DEV_INTEGRITY)
+
+static inline struct bio_integrity_payload *bio_integrity(struct bio *bio)
+{
+	if (bio->bi_rw & REQ_INTEGRITY)
+		return bio->bi_integrity;
+
+	return NULL;
+}
+
 static inline bool bio_integrity_flagged(struct bio *bio, enum bip_flags flag)
 {
 	struct bio_integrity_payload *bip = bio_integrity(bio);
@@ -795,6 +795,18 @@ static inline bool bio_integrity_flagged(struct bio *bio, enum bip_flags flag)
 	return false;
 }
 
+static inline void *bio_integrity_alloc(struct bio * bio, gfp_t gfp,
+								unsigned int nr)
+{
+	return ERR_PTR(-EINVAL);
+}
+
+static inline int bio_integrity_add_page(struct bio *bio, struct page *page,
+					unsigned int len, unsigned int offset)
+{
+	return 0;
+}
+
 #endif /* CONFIG_BLK_DEV_INTEGRITY */
 
 #endif /* CONFIG_BLOCK */

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-02 21:07   ` Jens Axboe
@ 2015-12-02 21:14     ` Keith Busch
  2015-12-02 21:27       ` Jens Axboe
  2015-12-03  8:39     ` Matias Bjørling
  1 sibling, 1 reply; 176+ messages in thread
From: Keith Busch @ 2015-12-02 21:14 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Christoph Hellwig, Mark Brown, linux-next, linux-kernel, linux-block

On Wed, Dec 02, 2015 at 02:07:34PM -0700, Jens Axboe wrote:
> Christoph, for-4.5/nvme also fails if integrity isn't enabled:

I forgot about this since I've merged this in my repo to fix:

https://lkml.org/lkml/2015/10/26/546

That ok, or should we handle this differently?

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-02 16:45 ` Christoph Hellwig
@ 2015-12-02 21:07   ` Jens Axboe
  2015-12-02 21:14     ` Keith Busch
  2015-12-03  8:39     ` Matias Bjørling
  0 siblings, 2 replies; 176+ messages in thread
From: Jens Axboe @ 2015-12-02 21:07 UTC (permalink / raw)
  To: Christoph Hellwig, Mark Brown
  Cc: Keith Busch, linux-next, linux-kernel, linux-block

On 12/02/2015 09:45 AM, Christoph Hellwig wrote:
> Looks like I didn't test with CONFIG_NVM enabled, and neither did
> the build bot.
>
> Most of this is really weird crazy shit in the lighnvm support, though.
>
> Struct nvme_ns is a structure for the NVM I/O command set, and it has
> no business poking into it.  Second this commit:
>
> commit 47b3115ae7b799be8b77b0f024215ad4f68d6460
> Author: Wenwei Tao <ww.tao0320@gmail.com>
> Date:   Fri Nov 20 13:47:55 2015 +0100
>
>      nvme: lightnvm: use admin queues for admin cmds
>
> Does even more crazy stuff.  If a function gets a request_queue parameter
> passed it'd better use that and not look for another one.
>
> Quick patch below, but this code will need some more attention:

Christoph, for-4.5/nvme also fails if integrity isn't enabled:

   CC      drivers/nvme/host/core.o
drivers/nvme/host/core.c: In function ‘__nvme_submit_user_cmd’:
drivers/nvme/host/core.c:192:10: error: implicit declaration of function 
‘bio_integrity_alloc’ [-Werror=implicit-function-declaration]
     bip = bio_integrity_alloc(bio, GFP_KERNEL, 1);
           ^
drivers/nvme/host/core.c:192:8: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
     bip = bio_integrity_alloc(bio, GFP_KERNEL, 1);
         ^
drivers/nvme/host/core.c:198:7: error: dereferencing pointer to 
incomplete type ‘struct bio_integrity_payload’
     bip->bip_iter.bi_size = meta_len;
        ^
drivers/nvme/host/core.c:201:10: error: implicit declaration of function 
‘bio_integrity_add_page’ [-Werror=implicit-function-declaration]
     ret = bio_integrity_add_page(bio, virt_to_page(meta),
           ^


-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-12-02 16:19 Mark Brown
@ 2015-12-02 16:45 ` Christoph Hellwig
  2015-12-02 21:07   ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2015-12-02 16:45 UTC (permalink / raw)
  To: Mark Brown
  Cc: Jens Axboe, Keith Busch, Christoph Hellwig, linux-next,
	linux-kernel, linux-block

Looks like I didn't test with CONFIG_NVM enabled, and neither did
the build bot.

Most of this is really weird crazy shit in the lighnvm support, though.

Struct nvme_ns is a structure for the NVM I/O command set, and it has
no business poking into it.  Second this commit:

commit 47b3115ae7b799be8b77b0f024215ad4f68d6460
Author: Wenwei Tao <ww.tao0320@gmail.com>
Date:   Fri Nov 20 13:47:55 2015 +0100

    nvme: lightnvm: use admin queues for admin cmds

Does even more crazy stuff.  If a function gets a request_queue parameter
passed it'd better use that and not look for another one.

Quick patch below, but this code will need some more attention:

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index d5622f9..09cf0b9 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -276,7 +276,6 @@ static int init_grps(struct nvm_id *nvm_id, struct nvme_nvm_id *nvme_nvm_id)
 static int nvme_nvm_identity(struct request_queue *q, struct nvm_id *nvm_id)
 {
 	struct nvme_ns *ns = q->queuedata;
-	struct nvme_dev *dev = ns->dev;
 	struct nvme_nvm_id *nvme_nvm_id;
 	struct nvme_nvm_command c = {};
 	int ret;
@@ -289,7 +288,7 @@ static int nvme_nvm_identity(struct request_queue *q, struct nvm_id *nvm_id)
 	if (!nvme_nvm_id)
 		return -ENOMEM;
 
-	ret = nvme_submit_sync_cmd(dev->admin_q, (struct nvme_command *)&c,
+	ret = nvme_submit_sync_cmd(ns->ctrl->admin_q, (struct nvme_command *)&c,
 				nvme_nvm_id, sizeof(struct nvme_nvm_id));
 	if (ret) {
 		ret = -EIO;
@@ -314,9 +313,8 @@ static int nvme_nvm_get_l2p_tbl(struct request_queue *q, u64 slba, u32 nlb,
 				nvm_l2p_update_fn *update_l2p, void *priv)
 {
 	struct nvme_ns *ns = q->queuedata;
-	struct nvme_dev *dev = ns->dev;
 	struct nvme_nvm_command c = {};
-	u32 len = queue_max_hw_sectors(dev->admin_q) << 9;
+	u32 len = queue_max_hw_sectors(ns->ctrl->admin_q) << 9;
 	u32 nlb_pr_rq = len / sizeof(u64);
 	u64 cmd_slba = slba;
 	void *entries;
@@ -334,10 +332,10 @@ static int nvme_nvm_get_l2p_tbl(struct request_queue *q, u64 slba, u32 nlb,
 		c.l2p.slba = cpu_to_le64(cmd_slba);
 		c.l2p.nlb = cpu_to_le32(cmd_nlb);
 
-		ret = nvme_submit_sync_cmd(dev->admin_q,
+		ret = nvme_submit_sync_cmd(ns->ctrl->admin_q,
 				(struct nvme_command *)&c, entries, len);
 		if (ret) {
-			dev_err(dev->dev, "L2P table transfer failed (%d)\n",
+			dev_err(ns->ctrl->dev, "L2P table transfer failed (%d)\n",
 									ret);
 			ret = -EIO;
 			goto out;
@@ -362,7 +360,7 @@ static int nvme_nvm_get_bb_tbl(struct request_queue *q, struct ppa_addr ppa,
 				void *priv)
 {
 	struct nvme_ns *ns = q->queuedata;
-	struct nvme_dev *dev = ns->dev;
+	struct nvme_ctrl *ctrl = ns->ctrl;
 	struct nvme_nvm_command c = {};
 	struct nvme_nvm_bb_tbl *bb_tbl;
 	int tblsz = sizeof(struct nvme_nvm_bb_tbl) + nr_blocks;
@@ -376,30 +374,30 @@ static int nvme_nvm_get_bb_tbl(struct request_queue *q, struct ppa_addr ppa,
 	if (!bb_tbl)
 		return -ENOMEM;
 
-	ret = nvme_submit_sync_cmd(dev->admin_q, (struct nvme_command *)&c,
+	ret = nvme_submit_sync_cmd(ctrl->admin_q, (struct nvme_command *)&c,
 								bb_tbl, tblsz);
 	if (ret) {
-		dev_err(dev->dev, "get bad block table failed (%d)\n", ret);
+		dev_err(ctrl->dev, "get bad block table failed (%d)\n", ret);
 		ret = -EIO;
 		goto out;
 	}
 
 	if (bb_tbl->tblid[0] != 'B' || bb_tbl->tblid[1] != 'B' ||
 		bb_tbl->tblid[2] != 'L' || bb_tbl->tblid[3] != 'T') {
-		dev_err(dev->dev, "bbt format mismatch\n");
+		dev_err(ctrl->dev, "bbt format mismatch\n");
 		ret = -EINVAL;
 		goto out;
 	}
 
 	if (le16_to_cpu(bb_tbl->verid) != 1) {
 		ret = -EINVAL;
-		dev_err(dev->dev, "bbt version not supported\n");
+		dev_err(ctrl->dev, "bbt version not supported\n");
 		goto out;
 	}
 
 	if (le32_to_cpu(bb_tbl->tblks) != nr_blocks) {
 		ret = -EINVAL;
-		dev_err(dev->dev, "bbt unsuspected blocks returned (%u!=%u)",
+		dev_err(ctrl->dev, "bbt unsuspected blocks returned (%u!=%u)",
 					le32_to_cpu(bb_tbl->tblks), nr_blocks);
 		goto out;
 	}
@@ -419,7 +417,6 @@ static int nvme_nvm_set_bb_tbl(struct request_queue *q, struct nvm_rq *rqd,
 								int type)
 {
 	struct nvme_ns *ns = q->queuedata;
-	struct nvme_dev *dev = ns->dev;
 	struct nvme_nvm_command c = {};
 	int ret = 0;
 
@@ -429,10 +426,10 @@ static int nvme_nvm_set_bb_tbl(struct request_queue *q, struct nvm_rq *rqd,
 	c.set_bb.nlb = cpu_to_le16(rqd->nr_pages - 1);
 	c.set_bb.value = type;
 
-	ret = nvme_submit_sync_cmd(dev->admin_q, (struct nvme_command *)&c,
+	ret = nvme_submit_sync_cmd(ns->ctrl->admin_q, (struct nvme_command *)&c,
 								NULL, 0);
 	if (ret)
-		dev_err(dev->dev, "set bad block table failed (%d)\n", ret);
+		dev_err(ns->ctrl->dev, "set bad block table failed (%d)\n", ret);
 	return ret;
 }
 
@@ -518,9 +515,8 @@ static int nvme_nvm_erase_block(struct request_queue *q, struct nvm_rq *rqd)
 static void *nvme_nvm_create_dma_pool(struct request_queue *q, char *name)
 {
 	struct nvme_ns *ns = q->queuedata;
-	struct nvme_dev *dev = ns->dev;
 
-	return dma_pool_create(name, dev->dev, PAGE_SIZE, PAGE_SIZE, 0);
+	return dma_pool_create(name, ns->ctrl->dev, PAGE_SIZE, PAGE_SIZE, 0);
 }
 
 static void nvme_nvm_destroy_dma_pool(void *pool)
@@ -573,8 +569,9 @@ void nvme_nvm_unregister(struct request_queue *q, char *disk_name)
 
 int nvme_nvm_ns_supported(struct nvme_ns *ns, struct nvme_id_ns *id)
 {
-	struct nvme_dev *dev = ns->dev;
-	struct pci_dev *pdev = to_pci_dev(dev->dev);
+	struct nvme_ctrl *ctrl = ns->ctrl;
+	/* XXX: this is poking into PCI structures from generic code! */
+	struct pci_dev *pdev = to_pci_dev(ctrl->dev);
 
 	/* QEMU NVMe simulator - PCI ID + Vendor specific bit */
 	if (pdev->vendor == PCI_VENDOR_ID_INTEL && pdev->device == 0x5845 &&

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2015-12-02 16:19 Mark Brown
  2015-12-02 16:45 ` Christoph Hellwig
  0 siblings, 1 reply; 176+ messages in thread
From: Mark Brown @ 2015-12-02 16:19 UTC (permalink / raw)
  To: Jens Axboe, Keith Busch, Christoph Hellwig
  Cc: linux-next, linux-kernel, linux-block

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

Hi Jens,

After merging the block tree, today's linux-next build (x86 allmodconfig)
failed like this:

/home/broonie/next/next/drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_identity':
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:279:27: error: 'struct nvme_ns' has no member named 'dev'
  struct nvme_dev *dev = ns->dev;
                           ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:292:32: error: dereferencing pointer to incomplete type 'struct nvme_dev'
  ret = nvme_submit_sync_cmd(dev->admin_q, (struct nvme_command *)&c,
                                ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_get_l2p_tbl':
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:317:27: error: 'struct nvme_ns' has no member named 'dev'
  struct nvme_dev *dev = ns->dev;
                           ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:319:36: error: dereferencing pointer to incomplete type 'struct nvme_dev'
  u32 len = queue_max_hw_sectors(dev->admin_q) << 9;
                                    ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_get_bb_tbl':
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:365:27: error: 'struct nvme_ns' has no member named 'dev'
  struct nvme_dev *dev = ns->dev;
                           ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:379:32: error: dereferencing pointer to incomplete type 'struct nvme_dev'
  ret = nvme_submit_sync_cmd(dev->admin_q, (struct nvme_command *)&c,
                                ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_set_bb_tbl':
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:422:27: error: 'struct nvme_ns' has no member named 'dev'
  struct nvme_dev *dev = ns->dev;
                           ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:432:32: error: dereferencing pointer to incomplete type 'struct nvme_dev'
  ret = nvme_submit_sync_cmd(dev->admin_q, (struct nvme_command *)&c,
                                ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_create_dma_pool':
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:521:27: error: 'struct nvme_ns' has no member named 'dev'
  struct nvme_dev *dev = ns->dev;
                           ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:523:34: error: dereferencing pointer to incomplete type 'struct nvme_dev'
  return dma_pool_create(name, dev->dev, PAGE_SIZE, PAGE_SIZE, 0);
                                  ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_ns_supported':
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:576:27: error: 'struct nvme_ns' has no member named 'dev'
  struct nvme_dev *dev = ns->dev;
                           ^
In file included from /home/broonie/next/next/include/linux/list.h:8:0,
                 from /home/broonie/next/next/include/linux/pci.h:25,
                 from /home/broonie/next/next/drivers/nvme/host/nvme.h:18,
                 from /home/broonie/next/next/drivers/nvme/host/lightnvm.c:23:
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:577:39: error: dereferencing pointer to incomplete type 'struct nvme_dev'
  struct pci_dev *pdev = to_pci_dev(dev->dev);
                                       ^
/home/broonie/next/next/include/linux/kernel.h:813:49: note: in definition of macro 'container_of'
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
                                                 ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:577:25: note: in expansion of macro 'to_pci_dev'
  struct pci_dev *pdev = to_pci_dev(dev->dev);
                         ^
/home/broonie/next/next/drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_create_dma_pool':
/home/broonie/next/next/drivers/nvme/host/lightnvm.c:524:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
/home/broonie/next/next/scripts/Makefile.build:258: recipe for target 'drivers/nvme/host/lightnvm.o' failed
make[4]: *** [drivers/nvme/host/lightnvm.o] Error 1

Caused by commit 1c63dc66580d4b (nvme: split a new struct nvme_ctrl out of
struct nvme_dev) which replaced dev in struct nvme_ns with ctrl without
updating this user. I used the block tree from the last -next build
(3f3a8a218c2f) instead.

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-10-06  1:43 Stephen Rothwell
  2015-10-06  1:54 ` kbuild test robot
@ 2015-10-06  7:20 ` Ming Lei
  1 sibling, 0 replies; 176+ messages in thread
From: Ming Lei @ 2015-10-06  7:20 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, linux-next, Linux Kernel Mailing List, Christoph Hellwig

On Tue, Oct 6, 2015 at 9:43 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/block/loop.c: In function 'lo_rw_aio_complete':
> drivers/block/loop.c:474:2: error: too few arguments to function 'blk_mq_complete_request'
>   blk_mq_complete_request(rq);
>   ^
> In file included from drivers/block/loop.h:14:0,
>                  from drivers/block/loop.c:79:
> include/linux/blk-mq.h:217:6: note: declared here
>  void blk_mq_complete_request(struct request *rq, int error);
>       ^
>
> Caused by commit
>
>   f4829a9b7a61 ("blk-mq: fix racy updates of rq->errors")
>
> from Linus' tree interacting with commit
>
>   bc07c10a3603 ("block: loop: support DIO & AIO")
>
> from the block tree.
>
> I added the this merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 6 Oct 2015 12:39:41 +1100
> Subject: [PATCH] blk-mq: merge fix for "fix racy updates of rq->errors"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/block/loop.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index c692a3d812e4..9be61ad3163d 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -470,8 +470,7 @@ static void lo_rw_aio_complete(struct kiocb *iocb, long ret, long ret2)
>         else if (ret < 0)
>                 ret = -EIO;
>
> -       rq->errors = ret;
> -       blk_mq_complete_request(rq);
> +       blk_mq_complete_request(rq, ret);

This merge fix looks fine, thanks.

>  }
>
>  static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,
> --
> 2.5.1
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-10-06  1:43 Stephen Rothwell
@ 2015-10-06  1:54 ` kbuild test robot
  2015-10-06  7:20 ` Ming Lei
  1 sibling, 0 replies; 176+ messages in thread
From: kbuild test robot @ 2015-10-06  1:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: kbuild-all, Jens Axboe, linux-next, linux-kernel,
	Christoph Hellwig, Ming Lei

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

Hi Stephen,

[auto build test ERROR on next-20151002 -- if it's inappropriate base, please ignore]

config: i386-randconfig-x006-201540 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/block/loop.c: In function 'lo_rw_aio_complete':
>> drivers/block/loop.c:473:2: error: too many arguments to function 'blk_mq_complete_request'
     blk_mq_complete_request(rq, ret);
     ^
   In file included from drivers/block/loop.h:14:0,
                    from drivers/block/loop.c:79:
   include/linux/blk-mq.h:218:6: note: declared here
    void blk_mq_complete_request(struct request *rq);
         ^

vim +/blk_mq_complete_request +473 drivers/block/loop.c

   467	
   468		if (ret > 0)
   469			ret = 0;
   470		else if (ret < 0)
   471			ret = -EIO;
   472	
 > 473		blk_mq_complete_request(rq, ret);
   474	}
   475	
   476	static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 31011 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2015-10-06  1:43 Stephen Rothwell
  2015-10-06  1:54 ` kbuild test robot
  2015-10-06  7:20 ` Ming Lei
  0 siblings, 2 replies; 176+ messages in thread
From: Stephen Rothwell @ 2015-10-06  1:43 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Christoph Hellwig, Ming Lei

Hi Jens,

After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/block/loop.c: In function 'lo_rw_aio_complete':
drivers/block/loop.c:474:2: error: too few arguments to function 'blk_mq_complete_request'
  blk_mq_complete_request(rq);
  ^
In file included from drivers/block/loop.h:14:0,
                 from drivers/block/loop.c:79:
include/linux/blk-mq.h:217:6: note: declared here
 void blk_mq_complete_request(struct request *rq, int error);
      ^

Caused by commit

  f4829a9b7a61 ("blk-mq: fix racy updates of rq->errors")

from Linus' tree interacting with commit

  bc07c10a3603 ("block: loop: support DIO & AIO")

from the block tree.

I added the this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 6 Oct 2015 12:39:41 +1100
Subject: [PATCH] blk-mq: merge fix for "fix racy updates of rq->errors"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/block/loop.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index c692a3d812e4..9be61ad3163d 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -470,8 +470,7 @@ static void lo_rw_aio_complete(struct kiocb *iocb, long ret, long ret2)
 	else if (ret < 0)
 		ret = -EIO;
 
-	rq->errors = ret;
-	blk_mq_complete_request(rq);
+	blk_mq_complete_request(rq, ret);
 }
 
 static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,
-- 
2.5.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-07-30  4:17 Stephen Rothwell
  2015-07-30  6:19 ` Christoph Hellwig
@ 2015-07-30 14:38 ` Drokin, Oleg
  1 sibling, 0 replies; 176+ messages in thread
From: Drokin, Oleg @ 2015-07-30 14:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, <linux-next, <linux-kernel, Christoph Hellwig,
	Greg KH, Dilger, Andreas


On Jul 30, 2015, at 12:17 AM, Stephen Rothwell wrote:

> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/staging/lustre/lustre/llite/../include/obd_support.h:42:0,
>                 from drivers/staging/lustre/lustre/llite/../include/lustre_cfg.h:225,
>                 from drivers/staging/lustre/lustre/llite/../include/lustre_lib.h:55,
>                 from drivers/staging/lustre/lustre/llite/lloop.c:105:
> drivers/staging/lustre/lustre/llite/lloop.c: In function 'loop_handle_bio':
> drivers/staging/lustre/lustre/llite/../include/linux/lustre_compat25.h:89:35: error: too many arguments to function 'bio_endio'
> #define cfs_bio_endio(a, b, c)    bio_endio((a), (c))
>                                   ^
> drivers/staging/lustre/lustre/llite/lloop.c:379:3: note: in expansion of macro 'cfs_bio_endio'
>   cfs_bio_endio(bio, bio->bi_iter.bi_size, ret);
>   ^
> In file included from include/linux/blkdev.h:18:0,
>                 from drivers/staging/lustre/lustre/llite/lloop.c:91:
> include/linux/bio.h:442:13: note: declared here
> extern void bio_endio(struct bio *);
>             ^
> 
> Caused by commit
> 
>  4246a0b63bd8 ("block: add a bi_error field to struct bio")
> 
> I added the following fix patch, but more is probably required:

It looks like this in itself is enough, but we probably should be good to
kill those cfs_bio_* compat macros while we are at it.
I'll submit a patch, but not sure where to base it on.
If basing on current block tree's linux-next, then I get a bunch of errors about how
kstrto* are undefined, so I cannot really test this yet.

Thanks.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 30 Jul 2015 14:10:57 +1000
> Subject: [PATCH] block: lustre: temporary fix for bio_endio API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/lustre/lustre/include/linux/lustre_compat25.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
> index 513c81f43d6e..1aac5a77c500 100644
> --- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
> +++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
> @@ -86,7 +86,7 @@
> 		vfs_rename(old, old_dir, new, new_dir, NULL, 0)
> 
> #define cfs_bio_io_error(a, b)   bio_io_error((a))
> -#define cfs_bio_endio(a, b, c)    bio_endio((a), (c))
> +#define cfs_bio_endio(a, b, c)    bio_endio((a))
> 
> #define cfs_path_put(nd)     path_put(&(nd)->path)
> 
> -- 
> 2.4.6
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-07-30  6:19 ` Christoph Hellwig
@ 2015-07-30 12:24   ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2015-07-30 12:24 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, linux-next, linux-kernel, Greg KH, Oleg Drokin,
	Andreas Dilger

Hi Christoph,

On Thu, 30 Jul 2015 08:19:51 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> Can you please drop staging and especially lustre from these runs?

One problem with that is that staging is expected to at least build.
and when Linus eventually merges this code in the block tree, he will
do an allmodconfig build and it will fail.  I don't really care about
how things get fixed in the staging tree (as you can see from the patch
I applied to get it to build) and sometimes mostly I just disable an
affected driver.  This was just as easy.

At least this way people know ahead of time that it needs an update.

> Conditions of the staging tree are they don't need to update.

See above - it is expected to build.  Linus himself asked me to make
sure that remains true.

> Nevermind that
> it never should have grown something as big and stale as lustre without
> any prospects of being merged.

You can have that discussion with Greg and the Lustre maintainers. :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2015-07-30  4:17 Stephen Rothwell
@ 2015-07-30  6:19 ` Christoph Hellwig
  2015-07-30 12:24   ` Stephen Rothwell
  2015-07-30 14:38 ` Drokin, Oleg
  1 sibling, 1 reply; 176+ messages in thread
From: Christoph Hellwig @ 2015-07-30  6:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, linux-next, linux-kernel, Christoph Hellwig, Greg KH,
	Oleg Drokin, Andreas Dilger

On Thu, Jul 30, 2015 at 02:17:13PM +1000, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:

Can you please drop staging and especially lustre from these runs?
Conditions of the staging tree are they don't need to update.  Nevermind that
it never should have grown something as big and stale as lustre without
any prospects of being merged.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2015-07-30  4:17 Stephen Rothwell
  2015-07-30  6:19 ` Christoph Hellwig
  2015-07-30 14:38 ` Drokin, Oleg
  0 siblings, 2 replies; 176+ messages in thread
From: Stephen Rothwell @ 2015-07-30  4:17 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Christoph Hellwig, Greg KH,
	Oleg Drokin, Andreas Dilger

Hi Jens,

After merging the block tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/staging/lustre/lustre/llite/../include/obd_support.h:42:0,
                 from drivers/staging/lustre/lustre/llite/../include/lustre_cfg.h:225,
                 from drivers/staging/lustre/lustre/llite/../include/lustre_lib.h:55,
                 from drivers/staging/lustre/lustre/llite/lloop.c:105:
drivers/staging/lustre/lustre/llite/lloop.c: In function 'loop_handle_bio':
drivers/staging/lustre/lustre/llite/../include/linux/lustre_compat25.h:89:35: error: too many arguments to function 'bio_endio'
 #define cfs_bio_endio(a, b, c)    bio_endio((a), (c))
                                   ^
drivers/staging/lustre/lustre/llite/lloop.c:379:3: note: in expansion of macro 'cfs_bio_endio'
   cfs_bio_endio(bio, bio->bi_iter.bi_size, ret);
   ^
In file included from include/linux/blkdev.h:18:0,
                 from drivers/staging/lustre/lustre/llite/lloop.c:91:
include/linux/bio.h:442:13: note: declared here
 extern void bio_endio(struct bio *);
             ^

Caused by commit

  4246a0b63bd8 ("block: add a bi_error field to struct bio")

I added the following fix patch, but more is probably required:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 30 Jul 2015 14:10:57 +1000
Subject: [PATCH] block: lustre: temporary fix for bio_endio API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/lustre/lustre/include/linux/lustre_compat25.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
index 513c81f43d6e..1aac5a77c500 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
@@ -86,7 +86,7 @@
 		vfs_rename(old, old_dir, new, new_dir, NULL, 0)
 
 #define cfs_bio_io_error(a, b)   bio_io_error((a))
-#define cfs_bio_endio(a, b, c)    bio_endio((a), (c))
+#define cfs_bio_endio(a, b, c)    bio_endio((a))
 
 #define cfs_path_put(nd)     path_put(&(nd)->path)
 
-- 
2.4.6

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2015-02-09  4:25 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2015-02-09  4:25 UTC (permalink / raw)
  To: Jens Axboe, Trond Myklebust
  Cc: linux-next, linux-kernel, Tom Haynes, Weston Andros Adamson,
	Tao Peng, Christoph Hellwig

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

fs/nfs/flexfilelayout/flexfilelayout.c: In function 'ff_layout_mark_request_commit':
fs/nfs/flexfilelayout/flexfilelayout.c:1369:47: error: 'struct address_space' has no member named 'backing_dev_info'
   inc_bdi_stat(page_file_mapping(req->wb_page)->backing_dev_info,
                                               ^

Caused by commit b83ae6d42143 ("fs: remove mapping->backing_dev_info")
interacting with commit d67ae825a59d ("pnfs/flexfiles: Add the FlexFile
Layout Driver") from the nfs tree.

I have added this merge fix patch (assuming it is correct, someone
needs to tell Linus about this when the trees get merged):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 9 Feb 2015 15:20:12 +1100
Subject: [PATCH] pnfs/flexfiles: fix FlexFile Layout Driver for removal
 mapping->backing_dev_info

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/nfs/flexfilelayout/flexfilelayout.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c b/fs/nfs/flexfilelayout/flexfilelayout.c
index f29fb7d7e8f8..c22ecaa86c1c 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -1366,7 +1366,7 @@ ff_layout_mark_request_commit(struct nfs_page *req,
 	spin_unlock(cinfo->lock);
 	if (!cinfo->dreq) {
 		inc_zone_page_state(req->wb_page, NR_UNSTABLE_NFS);
-		inc_bdi_stat(page_file_mapping(req->wb_page)->backing_dev_info,
+		inc_bdi_stat(inode_to_bdi(page_file_mapping(req->wb_page)->host),
 			     BDI_RECLAIMABLE);
 		__mark_inode_dirty(req->wb_context->dentry->d_inode,
 				   I_DIRTY_DATASYNC);
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2015-01-21  3:45 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2015-01-21  3:45 UTC (permalink / raw)
  To: Jens Axboe, Greg KH
  Cc: linux-next, linux-kernel, Oleg Drokin, Andreas Dilger, Christoph Hellwig

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/staging/lustre/lustre/llite/llite_lib.c: In function 'll_read_inode2':
drivers/staging/lustre/lustre/llite/llite_lib.c:1774:18: error: 'struct address_space' has no member named 'backing_dev_info'
  inode->i_mapping->backing_dev_info = &s2lsi(inode->i_sb)->lsi_bdi;
                  ^

Caused by commit b83ae6d42143 ("fs: remove mapping->backing_dev_info")
not updating the lustre code in the staging tree.

I have disabled the lustre code for today using the following.  Please
let me know if you fix the lustre code so that I can reenable it.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 21 Jan 2015 14:36:21 +1100
Subject: [PATCH] disable the lustre code for now

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/lustre/lustre/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/lustre/lustre/Kconfig b/drivers/staging/lustre/lustre/Kconfig
index 6725467ef4d0..37dd33f6597e 100644
--- a/drivers/staging/lustre/lustre/Kconfig
+++ b/drivers/staging/lustre/lustre/Kconfig
@@ -1,6 +1,7 @@
 config LUSTRE_FS
 	tristate "Lustre file system client support"
 	depends on INET && m && !MIPS && !XTENSA && !SUPERH
+	depends on BROKEN
 	select LNET
 	select CRYPTO
 	select CRYPTO_CRC32
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2014-11-17  3:44 Stephen Rothwell
@ 2014-11-17 19:51 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2014-11-17 19:51 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On 11/16/2014 08:44 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "blk_mq_free_request" [drivers/block/nvme.ko] undefined!
>
> Caused by commit b94ebc3c7a0f ("NVMe: replace blk_put_request() with
> blk_mq_free_request()").
>
> I have used te block tree from next-20141114 for today.

Thanks Stephen, fixed.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2014-11-17  3:44 Stephen Rothwell
  2014-11-17 19:51 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2014-11-17  3:44 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "blk_mq_free_request" [drivers/block/nvme.ko] undefined!

Caused by commit b94ebc3c7a0f ("NVMe: replace blk_put_request() with
blk_mq_free_request()").

I have used te block tree from next-20141114 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2014-11-11 15:27   ` Jens Axboe
@ 2014-11-14 16:19     ` Fabian Frederick
  0 siblings, 0 replies; 176+ messages in thread
From: Fabian Frederick @ 2014-11-14 16:19 UTC (permalink / raw)
  To: Jens Axboe, Stephen Rothwell; +Cc: linux-kernel, linux-next



> On 11 November 2014 at 16:27 Jens Axboe <axboe@kernel.dk> wrote:
>
>
> On 2014-11-11 04:20, Fabian Frederick wrote:
> >
> >
> >> On 11 November 2014 at 03:12 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >>
> >> Hi Jens,
> >>
> >> After merging the block tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> drivers/built-in.o: In function `cdrom_sysctl_handler':
> >> cdrom_sysctl.c:(.text+0x156d92): undefined reference to `cdrom_mutex'
> >> cdrom_sysctl.c:(.text+0x156da0): undefined reference to `cdrom_autoclose'
> >> cdrom_sysctl.c:(.text+0x156dae): undefined reference to `cdrom_autoeject'
> >> cdrom_sysctl.c:(.text+0x156dbc): undefined reference to `cdrom_debug'
> >> cdrom_sysctl.c:(.text+0x156dca): undefined reference to `cdrom_lockdoor'
> >> cdrom_sysctl.c:(.text+0x156dd8): undefined reference to
> >> `cdrom_check_media_type'
> >> cdrom_sysctl.c:(.text+0x156e0b): undefined reference to `cdrom_list'
> >> cdrom_sysctl.c:(.text+0x156e37): undefined reference to `cdrom_autoclose'
> >> cdrom_sysctl.c:(.text+0x156e57): undefined reference to `cdrom_autoeject'
> >> cdrom_sysctl.c:(.text+0x156e77): undefined reference to
> >> `cdrom_check_media_type'
> >> cdrom_sysctl.c:(.text+0x156ea4): undefined reference to `cdrom_lockdoor'
> >> cdrom_sysctl.c:(.text+0x156eb5): undefined reference to `cdrom_list'
> >> cdrom_sysctl.c:(.text+0x15702e): undefined reference to `cdrom_mutex'
> >> drivers/built-in.o: In function `cdrom_print_info.constprop.0':
> >> cdrom_sysctl.c:(.text+0x1570f3): undefined reference to `cdrom_list'
> >> cdrom_sysctl.c:(.text+0x157189): undefined reference to `cdrom_list'
> >> drivers/built-in.o: In function `cdrom_sysctl_info':
> >> cdrom_sysctl.c:(.text+0x1572c3): undefined reference to `cdrom_mutex'
> >> cdrom_sysctl.c:(.text+0x1576dc): undefined reference to `cdrom_mutex'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x157765): undefined reference to `cdrom_autoclose'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x157781): undefined reference to `cdrom_autoeject'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x15778e): undefined reference to `cdrom_debug'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x15779b): undefined reference to `cdrom_lockdoor'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x1577a8): undefined reference to `cdrom_check_media_type'
> >>
> >> Probably caused by commit d01681d1457c ("cdrom: export sysctl code").
> >> This build has CONFIG_SYSCTL=y, CONFIG_BLK_DEV_IDECD=m,
> >> CONFIG_BLK_DEV_SR=m, CONFIG_PARIDE_PCD=m, CONFIG_CDROM_PKTCDVD=m,
> >> CONFIG_GDROM=n.
> >>
> >> I have used the block tree from next-20141110 for today.
> >> --
> >> Cheers,
> >> Stephen Rothwell                    sfr@canb.auug.org.au
> >
> > Hi Stephen,
> >
> > Problem is in Makefile:
> >
> > obj-$(CONFIG_BLK_DEV_SR) += cdrom.o
> > obj-$(CONFIG_PARIDE_PCD) += cdrom.o
> > obj-$(CONFIG_CDROM_PKTCDVD) += cdrom.o
> > +obj-$(CONFIG_SYSCTL) += cdrom_sysctl.o
> >
> > I tried cdrom-$(CONFIG_SYSCTL)  += cdrom_sysctl.o
> > to add sysctl only when cdrom.o is created
> >
> > but now
> >
> > drivers/scsi/sr_mod.ko
> > drivers/ide/ide-cd_mod.ko
> > drivers/ide/ide-cd_mod.ko
> >
> > can't find cdrom.c functions ...
> >
> > Is there another way to do it ?
>
> The problem is, now you can have cdrom/sr modular, but cdrom_sysctl.o is
> linked in. That's just not going to work. Instead of jumping through
> hoops to make this work, leave the section in cdrom.c and hid it behind a
>
> #if defined(CONFIG_SYSCTL)
> ...
> #endif
>
> at the bottom or something.
>
> --
> Jens Axboe
>

Hi Jens,

   It's already the case in current code so I'll drop this patch.
I've got a small question about another one:
(http://marc.info/?l=linux-kernel&m=141565102708591&w=2)

I was looking if there was a reason for calling

init_cdrom_command with 0 length in dvd_do_auth():

   memset(buf, 0, sizeof(buf));
   init_cdrom_command(&cgc, buf, 0, CGC_DATA_READ)
       
This doesn't impact setup_report_key/setup_send_key
calls -as those functions initialize cgc buflen again
depending on type argument- without DVD_INVALIDATE_AGID:
we call setup_report_key(&cgc, ai->lsa.agid, 0x3f);
where type is used for cmd[10]:

   cgc->cmd[10] = type | (agid << 6);

the switch(type) below doesn't have 0x3f case so we
go directly to

   cgc->cmd[9] = cgc->buflen;

I replaced the 2 lines above with

   init_cdrom_command(&cgc, buf, sizeof(buf), CGC_DATA_READ)

(as memset is already done during init_cdrom_command) but that would
change buflen in that case and subsequent cdo->generic_packet
behaviour or am I missing something ?

Regards,
Fabian

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2014-11-11 11:20 ` Fabian Frederick
@ 2014-11-11 15:27   ` Jens Axboe
  2014-11-14 16:19     ` Fabian Frederick
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2014-11-11 15:27 UTC (permalink / raw)
  To: Fabian Frederick, Stephen Rothwell; +Cc: linux-kernel, linux-next

On 2014-11-11 04:20, Fabian Frederick wrote:
>
>
>> On 11 November 2014 at 03:12 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/built-in.o: In function `cdrom_sysctl_handler':
>> cdrom_sysctl.c:(.text+0x156d92): undefined reference to `cdrom_mutex'
>> cdrom_sysctl.c:(.text+0x156da0): undefined reference to `cdrom_autoclose'
>> cdrom_sysctl.c:(.text+0x156dae): undefined reference to `cdrom_autoeject'
>> cdrom_sysctl.c:(.text+0x156dbc): undefined reference to `cdrom_debug'
>> cdrom_sysctl.c:(.text+0x156dca): undefined reference to `cdrom_lockdoor'
>> cdrom_sysctl.c:(.text+0x156dd8): undefined reference to
>> `cdrom_check_media_type'
>> cdrom_sysctl.c:(.text+0x156e0b): undefined reference to `cdrom_list'
>> cdrom_sysctl.c:(.text+0x156e37): undefined reference to `cdrom_autoclose'
>> cdrom_sysctl.c:(.text+0x156e57): undefined reference to `cdrom_autoeject'
>> cdrom_sysctl.c:(.text+0x156e77): undefined reference to
>> `cdrom_check_media_type'
>> cdrom_sysctl.c:(.text+0x156ea4): undefined reference to `cdrom_lockdoor'
>> cdrom_sysctl.c:(.text+0x156eb5): undefined reference to `cdrom_list'
>> cdrom_sysctl.c:(.text+0x15702e): undefined reference to `cdrom_mutex'
>> drivers/built-in.o: In function `cdrom_print_info.constprop.0':
>> cdrom_sysctl.c:(.text+0x1570f3): undefined reference to `cdrom_list'
>> cdrom_sysctl.c:(.text+0x157189): undefined reference to `cdrom_list'
>> drivers/built-in.o: In function `cdrom_sysctl_info':
>> cdrom_sysctl.c:(.text+0x1572c3): undefined reference to `cdrom_mutex'
>> cdrom_sysctl.c:(.text+0x1576dc): undefined reference to `cdrom_mutex'
>> drivers/built-in.o: In function `cdrom_sysctl_register':
>> (.text+0x157765): undefined reference to `cdrom_autoclose'
>> drivers/built-in.o: In function `cdrom_sysctl_register':
>> (.text+0x157781): undefined reference to `cdrom_autoeject'
>> drivers/built-in.o: In function `cdrom_sysctl_register':
>> (.text+0x15778e): undefined reference to `cdrom_debug'
>> drivers/built-in.o: In function `cdrom_sysctl_register':
>> (.text+0x15779b): undefined reference to `cdrom_lockdoor'
>> drivers/built-in.o: In function `cdrom_sysctl_register':
>> (.text+0x1577a8): undefined reference to `cdrom_check_media_type'
>>
>> Probably caused by commit d01681d1457c ("cdrom: export sysctl code").
>> This build has CONFIG_SYSCTL=y, CONFIG_BLK_DEV_IDECD=m,
>> CONFIG_BLK_DEV_SR=m, CONFIG_PARIDE_PCD=m, CONFIG_CDROM_PKTCDVD=m,
>> CONFIG_GDROM=n.
>>
>> I have used the block tree from next-20141110 for today.
>> --
>> Cheers,
>> Stephen Rothwell                    sfr@canb.auug.org.au
>
> Hi Stephen,
>
> Problem is in Makefile:
>
> obj-$(CONFIG_BLK_DEV_SR) += cdrom.o
> obj-$(CONFIG_PARIDE_PCD) += cdrom.o
> obj-$(CONFIG_CDROM_PKTCDVD) += cdrom.o
> +obj-$(CONFIG_SYSCTL) += cdrom_sysctl.o
>
> I tried cdrom-$(CONFIG_SYSCTL)  += cdrom_sysctl.o
> to add sysctl only when cdrom.o is created
>
> but now
>
> drivers/scsi/sr_mod.ko
> drivers/ide/ide-cd_mod.ko
> drivers/ide/ide-cd_mod.ko
>
> can't find cdrom.c functions ...
>
> Is there another way to do it ?

The problem is, now you can have cdrom/sr modular, but cdrom_sysctl.o is 
linked in. That's just not going to work. Instead of jumping through 
hoops to make this work, leave the section in cdrom.c and hid it behind a

#if defined(CONFIG_SYSCTL)
...
#endif

at the bottom or something.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2014-11-11  2:12 Stephen Rothwell
@ 2014-11-11 11:20 ` Fabian Frederick
  2014-11-11 15:27   ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Fabian Frederick @ 2014-11-11 11:20 UTC (permalink / raw)
  To: Jens Axboe, Stephen Rothwell; +Cc: linux-kernel, linux-next



> On 11 November 2014 at 03:12 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/built-in.o: In function `cdrom_sysctl_handler':
> cdrom_sysctl.c:(.text+0x156d92): undefined reference to `cdrom_mutex'
> cdrom_sysctl.c:(.text+0x156da0): undefined reference to `cdrom_autoclose'
> cdrom_sysctl.c:(.text+0x156dae): undefined reference to `cdrom_autoeject'
> cdrom_sysctl.c:(.text+0x156dbc): undefined reference to `cdrom_debug'
> cdrom_sysctl.c:(.text+0x156dca): undefined reference to `cdrom_lockdoor'
> cdrom_sysctl.c:(.text+0x156dd8): undefined reference to
> `cdrom_check_media_type'
> cdrom_sysctl.c:(.text+0x156e0b): undefined reference to `cdrom_list'
> cdrom_sysctl.c:(.text+0x156e37): undefined reference to `cdrom_autoclose'
> cdrom_sysctl.c:(.text+0x156e57): undefined reference to `cdrom_autoeject'
> cdrom_sysctl.c:(.text+0x156e77): undefined reference to
> `cdrom_check_media_type'
> cdrom_sysctl.c:(.text+0x156ea4): undefined reference to `cdrom_lockdoor'
> cdrom_sysctl.c:(.text+0x156eb5): undefined reference to `cdrom_list'
> cdrom_sysctl.c:(.text+0x15702e): undefined reference to `cdrom_mutex'
> drivers/built-in.o: In function `cdrom_print_info.constprop.0':
> cdrom_sysctl.c:(.text+0x1570f3): undefined reference to `cdrom_list'
> cdrom_sysctl.c:(.text+0x157189): undefined reference to `cdrom_list'
> drivers/built-in.o: In function `cdrom_sysctl_info':
> cdrom_sysctl.c:(.text+0x1572c3): undefined reference to `cdrom_mutex'
> cdrom_sysctl.c:(.text+0x1576dc): undefined reference to `cdrom_mutex'
> drivers/built-in.o: In function `cdrom_sysctl_register':
> (.text+0x157765): undefined reference to `cdrom_autoclose'
> drivers/built-in.o: In function `cdrom_sysctl_register':
> (.text+0x157781): undefined reference to `cdrom_autoeject'
> drivers/built-in.o: In function `cdrom_sysctl_register':
> (.text+0x15778e): undefined reference to `cdrom_debug'
> drivers/built-in.o: In function `cdrom_sysctl_register':
> (.text+0x15779b): undefined reference to `cdrom_lockdoor'
> drivers/built-in.o: In function `cdrom_sysctl_register':
> (.text+0x1577a8): undefined reference to `cdrom_check_media_type'
>
> Probably caused by commit d01681d1457c ("cdrom: export sysctl code").
> This build has CONFIG_SYSCTL=y, CONFIG_BLK_DEV_IDECD=m,
> CONFIG_BLK_DEV_SR=m, CONFIG_PARIDE_PCD=m, CONFIG_CDROM_PKTCDVD=m,
> CONFIG_GDROM=n.
>
> I have used the block tree from next-20141110 for today.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

Hi Stephen,

Problem is in Makefile:

obj-$(CONFIG_BLK_DEV_SR) += cdrom.o
obj-$(CONFIG_PARIDE_PCD) += cdrom.o
obj-$(CONFIG_CDROM_PKTCDVD) += cdrom.o
+obj-$(CONFIG_SYSCTL) += cdrom_sysctl.o

I tried cdrom-$(CONFIG_SYSCTL)  += cdrom_sysctl.o
to add sysctl only when cdrom.o is created

but now

drivers/scsi/sr_mod.ko
drivers/ide/ide-cd_mod.ko
drivers/ide/ide-cd_mod.ko

can't find cdrom.c functions ...

Is there another way to do it ?

Regards,
Fabian

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2014-11-11  2:12 Stephen Rothwell
  2014-11-11 11:20 ` Fabian Frederick
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2014-11-11  2:12 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Fabian Frederick

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/built-in.o: In function `cdrom_sysctl_handler':
cdrom_sysctl.c:(.text+0x156d92): undefined reference to `cdrom_mutex'
cdrom_sysctl.c:(.text+0x156da0): undefined reference to `cdrom_autoclose'
cdrom_sysctl.c:(.text+0x156dae): undefined reference to `cdrom_autoeject'
cdrom_sysctl.c:(.text+0x156dbc): undefined reference to `cdrom_debug'
cdrom_sysctl.c:(.text+0x156dca): undefined reference to `cdrom_lockdoor'
cdrom_sysctl.c:(.text+0x156dd8): undefined reference to `cdrom_check_media_type'
cdrom_sysctl.c:(.text+0x156e0b): undefined reference to `cdrom_list'
cdrom_sysctl.c:(.text+0x156e37): undefined reference to `cdrom_autoclose'
cdrom_sysctl.c:(.text+0x156e57): undefined reference to `cdrom_autoeject'
cdrom_sysctl.c:(.text+0x156e77): undefined reference to `cdrom_check_media_type'
cdrom_sysctl.c:(.text+0x156ea4): undefined reference to `cdrom_lockdoor'
cdrom_sysctl.c:(.text+0x156eb5): undefined reference to `cdrom_list'
cdrom_sysctl.c:(.text+0x15702e): undefined reference to `cdrom_mutex'
drivers/built-in.o: In function `cdrom_print_info.constprop.0':
cdrom_sysctl.c:(.text+0x1570f3): undefined reference to `cdrom_list'
cdrom_sysctl.c:(.text+0x157189): undefined reference to `cdrom_list'
drivers/built-in.o: In function `cdrom_sysctl_info':
cdrom_sysctl.c:(.text+0x1572c3): undefined reference to `cdrom_mutex'
cdrom_sysctl.c:(.text+0x1576dc): undefined reference to `cdrom_mutex'
drivers/built-in.o: In function `cdrom_sysctl_register':
(.text+0x157765): undefined reference to `cdrom_autoclose'
drivers/built-in.o: In function `cdrom_sysctl_register':
(.text+0x157781): undefined reference to `cdrom_autoeject'
drivers/built-in.o: In function `cdrom_sysctl_register':
(.text+0x15778e): undefined reference to `cdrom_debug'
drivers/built-in.o: In function `cdrom_sysctl_register':
(.text+0x15779b): undefined reference to `cdrom_lockdoor'
drivers/built-in.o: In function `cdrom_sysctl_register':
(.text+0x1577a8): undefined reference to `cdrom_check_media_type'

Probably caused by commit d01681d1457c ("cdrom: export sysctl code").
This build has CONFIG_SYSCTL=y, CONFIG_BLK_DEV_IDECD=m,
CONFIG_BLK_DEV_SR=m, CONFIG_PARIDE_PCD=m, CONFIG_CDROM_PKTCDVD=m,
CONFIG_GDROM=n.

I have used the block tree from next-20141110 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2013-11-26  2:30 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2013-11-26  2:30 UTC (permalink / raw)
  To: Jens Axboe, Jaegeuk Kim
  Cc: linux-next, linux-kernel, Kent Overstreet, Chao Yu

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/f2fs/data.c: In function 'submit_read_page':
fs/f2fs/data.c:457:10: error: 'struct bio' has no member named 'bi_sector'
   io->bio->bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
          ^

Caused by commit 4f024f3797c4 ("block: Abstract out bvec iterator") from
the block tree interacting with commit 32cd69ef0893 ("f2fs: add a new
function to support for merging contiguous read") from the f2fs tree.

I added the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 26 Nov 2013 13:19:30 +1100
Subject: [PATCH] f2fs: cope with bvec iterator abstraction

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 728eedb1c0c6..8d31b83bfc89 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -454,7 +454,7 @@ alloc_new:
 	if (io->bio == NULL) {
 		bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
 		io->bio = f2fs_bio_alloc(bdev, bio_blocks);
-		io->bio->bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
+		io->bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
 		io->bio->bi_end_io = read_end_io;
 	}
 
-- 
1.8.4.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2013-11-04  3:23 ` Jens Axboe
  2013-11-04  3:32   ` Jens Axboe
@ 2013-11-04  3:39   ` Stephen Rothwell
  1 sibling, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2013-11-04  3:39 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Kent Overstreet

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

Hi Jens,

On Sun, 3 Nov 2013 20:23:41 -0700 Jens Axboe <axboe@kernel.dk> wrote:
>
> Don't have ppc64 cross compiling handy, but the below should do the

https://www.kernel.org/pub/tools/crosstool/

> trick.

That patch fixes it for me.

Compile-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2013-11-04  3:23 ` Jens Axboe
@ 2013-11-04  3:32   ` Jens Axboe
  2013-11-04  3:39   ` Stephen Rothwell
  1 sibling, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2013-11-04  3:32 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Kent Overstreet

On Sun, Nov 03 2013, Jens Axboe wrote:
> On Mon, Nov 04 2013, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > [I merged the block tree *before* the aio-direct tree today ...]
> > 
> > After merging the block tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > In file included from include/linux/blkdev.h:18:0,
> >                  from drivers/block/ps3disk.c:22:
> > drivers/block/ps3disk.c: In function 'ps3disk_scatter_gather':
> > include/linux/bio.h:239:9: error: incompatible types when assigning to type 'struct bio_vec *' from type 'struct bio_vec'
> >    ((bvl = bio_iter_iovec((bio), (iter))), 1);  \
> >          ^
> > include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
> >   __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> >   ^
> > include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
> >    bio_for_each_segment(bvl, _iter.bio, _iter.iter)
> >    ^
> > drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
> >   rq_for_each_segment(bvec, req, iter) {
> >   ^
> > include/linux/bio.h:239:41: warning: left-hand operand of comma expression has no effect [-Wunused-value]
> >    ((bvl = bio_iter_iovec((bio), (iter))), 1);  \
> >                                          ^
> > include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
> >   __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> >   ^
> > include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
> >    bio_for_each_segment(bvl, _iter.bio, _iter.iter)
> >    ^
> > drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
> >   rq_for_each_segment(bvec, req, iter) {
> >   ^
> > include/linux/bio.h:240:45: error: request for member 'bv_len' in something not a structure or union
> >        bio_advance_iter((bio), &(iter), (bvl).bv_len))
> >                                              ^
> > include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
> >   __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
> >   ^
> > include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
> >    bio_for_each_segment(bvl, _iter.bio, _iter.iter)
> >    ^
> > drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
> >   rq_for_each_segment(bvec, req, iter) {
> >   ^
> > 
> > I am not quite sure which commit caused this (maybe ed2d2f9a8265 ("block:
> > Abstract out bvec iterator")?).  I have used the block tree from
> > next-20131031 again for today.
> 
> Don't have ppc64 cross compiling handy, but the below should do the
> trick.

Checked, works for me. Committed and for-next branch updated.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2013-11-04  3:13 Stephen Rothwell
@ 2013-11-04  3:23 ` Jens Axboe
  2013-11-04  3:32   ` Jens Axboe
  2013-11-04  3:39   ` Stephen Rothwell
  0 siblings, 2 replies; 176+ messages in thread
From: Jens Axboe @ 2013-11-04  3:23 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Kent Overstreet

On Mon, Nov 04 2013, Stephen Rothwell wrote:
> Hi Jens,
> 
> [I merged the block tree *before* the aio-direct tree today ...]
> 
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/blkdev.h:18:0,
>                  from drivers/block/ps3disk.c:22:
> drivers/block/ps3disk.c: In function 'ps3disk_scatter_gather':
> include/linux/bio.h:239:9: error: incompatible types when assigning to type 'struct bio_vec *' from type 'struct bio_vec'
>    ((bvl = bio_iter_iovec((bio), (iter))), 1);  \
>          ^
> include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
>   __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
>   ^
> include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
>    bio_for_each_segment(bvl, _iter.bio, _iter.iter)
>    ^
> drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
>   rq_for_each_segment(bvec, req, iter) {
>   ^
> include/linux/bio.h:239:41: warning: left-hand operand of comma expression has no effect [-Wunused-value]
>    ((bvl = bio_iter_iovec((bio), (iter))), 1);  \
>                                          ^
> include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
>   __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
>   ^
> include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
>    bio_for_each_segment(bvl, _iter.bio, _iter.iter)
>    ^
> drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
>   rq_for_each_segment(bvec, req, iter) {
>   ^
> include/linux/bio.h:240:45: error: request for member 'bv_len' in something not a structure or union
>        bio_advance_iter((bio), &(iter), (bvl).bv_len))
>                                              ^
> include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
>   __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
>   ^
> include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
>    bio_for_each_segment(bvl, _iter.bio, _iter.iter)
>    ^
> drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
>   rq_for_each_segment(bvec, req, iter) {
>   ^
> 
> I am not quite sure which commit caused this (maybe ed2d2f9a8265 ("block:
> Abstract out bvec iterator")?).  I have used the block tree from
> next-20131031 again for today.

Don't have ppc64 cross compiling handy, but the below should do the
trick.


diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index 8d1a19ccff0a..c120d70d3fb3 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -94,7 +94,7 @@ static void ps3disk_scatter_gather(struct ps3_storage_device *dev,
 {
 	unsigned int offset = 0;
 	struct req_iterator iter;
-	struct bio_vec *bvec;
+	struct bio_vec bvec;
 	unsigned int i = 0;
 	size_t size;
 	void *buf;
@@ -105,14 +105,14 @@ static void ps3disk_scatter_gather(struct ps3_storage_device *dev,
 			__func__, __LINE__, i, bio_sectors(iter.bio),
 			iter.bio->bi_iter.bi_sector);
 
-		size = bvec->bv_len;
-		buf = bvec_kmap_irq(bvec, &flags);
+		size = bvec.bv_len;
+		buf = bvec_kmap_irq(&bvec, &flags);
 		if (gather)
 			memcpy(dev->bounce_buf+offset, buf, size);
 		else
 			memcpy(buf, dev->bounce_buf+offset, size);
 		offset += size;
-		flush_kernel_dcache_page(bvec->bv_page);
+		flush_kernel_dcache_page(bvec.bv_page);
 		bvec_kunmap_irq(buf, &flags);
 		i++;
 	}
@@ -129,7 +129,7 @@ static int ps3disk_submit_request_sg(struct ps3_storage_device *dev,
 
 #ifdef DEBUG
 	unsigned int n = 0;
-	struct bio_vec *bv;
+	struct bio_vec bv;
 	struct req_iterator iter;
 
 	rq_for_each_segment(bv, req, iter)

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2013-11-04  3:13 Stephen Rothwell
  2013-11-04  3:23 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2013-11-04  3:13 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Kent Overstreet

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

Hi Jens,

[I merged the block tree *before* the aio-direct tree today ...]

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from include/linux/blkdev.h:18:0,
                 from drivers/block/ps3disk.c:22:
drivers/block/ps3disk.c: In function 'ps3disk_scatter_gather':
include/linux/bio.h:239:9: error: incompatible types when assigning to type 'struct bio_vec *' from type 'struct bio_vec'
   ((bvl = bio_iter_iovec((bio), (iter))), 1);  \
         ^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
  __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
  ^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
   bio_for_each_segment(bvl, _iter.bio, _iter.iter)
   ^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
  rq_for_each_segment(bvec, req, iter) {
  ^
include/linux/bio.h:239:41: warning: left-hand operand of comma expression has no effect [-Wunused-value]
   ((bvl = bio_iter_iovec((bio), (iter))), 1);  \
                                         ^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
  __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
  ^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
   bio_for_each_segment(bvl, _iter.bio, _iter.iter)
   ^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
  rq_for_each_segment(bvec, req, iter) {
  ^
include/linux/bio.h:240:45: error: request for member 'bv_len' in something not a structure or union
       bio_advance_iter((bio), &(iter), (bvl).bv_len))
                                             ^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
  __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
  ^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
   bio_for_each_segment(bvl, _iter.bio, _iter.iter)
   ^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
  rq_for_each_segment(bvec, req, iter) {
  ^

I am not quite sure which commit caused this (maybe ed2d2f9a8265 ("block:
Abstract out bvec iterator")?).  I have used the block tree from
next-20131031 again for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2013-11-01  4:01 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2013-11-01  4:01 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel

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

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/block/loop.c: In function 'lo_rw_aio':
drivers/block/loop.c:243:28: error: 'struct bio' has no member named 'bi_sector'
  loff_t pos = ((loff_t) bio->bi_sector << 9) + lo->lo_offset;
                            ^
drivers/block/loop.c:254:2: error: implicit declaration of function 'bio_iovec_idx' [-Werror=implicit-function-declaration]
  bvec = bio_iovec_idx(bio, bio->bi_idx);
  ^
drivers/block/loop.c:254:31: error: 'struct bio' has no member named 'bi_idx'
  bvec = bio_iovec_idx(bio, bio->bi_idx);
                               ^
drivers/block/loop.c: In function 'lo_discard':
drivers/block/loop.c:476:28: error: 'struct bio' has no member named 'bi_sector'
  loff_t pos = ((loff_t) bio->bi_sector << 9) + lo->lo_offset;
                            ^
drivers/block/loop.c:489:50: error: 'struct bio' has no member named 'bi_size'
  ret = file->f_op->fallocate(file, mode, pos, bio->bi_size);
                                                  ^

Basically caused by in incomplete merge between the block tree and the
aio-direct tree (see my previous email).

I was going to apply a merge fix patch, but I also got these:

In file included from include/linux/blkdev.h:18:0,
                 from drivers/block/ps3disk.c:22:
drivers/block/ps3disk.c: In function 'ps3disk_scatter_gather':
include/linux/bio.h:239:9: error: incompatible types when assigning to type 'struct bio_vec *' from type 'struct bio_vec'
   ((bvl = bio_iter_iovec((bio), (iter))), 1);  \
         ^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
  __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
  ^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
   bio_for_each_segment(bvl, _iter.bio, _iter.iter)
   ^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
  rq_for_each_segment(bvec, req, iter) {
  ^
include/linux/bio.h:239:41: warning: left-hand operand of comma expression has no effect [-Wunused-value]
   ((bvl = bio_iter_iovec((bio), (iter))), 1);  \
                                         ^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
  __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
  ^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
   bio_for_each_segment(bvl, _iter.bio, _iter.iter)
   ^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
  rq_for_each_segment(bvec, req, iter) {
  ^
include/linux/bio.h:240:45: error: request for member 'bv_len' in something not a structure or union
       bio_advance_iter((bio), &(iter), (bvl).bv_len))
                                             ^
include/linux/bio.h:243:2: note: in expansion of macro '__bio_for_each_segment'
  __bio_for_each_segment(bvl, bio, iter, (bio)->bi_iter)
  ^
include/linux/blkdev.h:748:3: note: in expansion of macro 'bio_for_each_segment'
   bio_for_each_segment(bvl, _iter.bio, _iter.iter)
   ^
drivers/block/ps3disk.c:102:2: note: in expansion of macro 'rq_for_each_segment'
  rq_for_each_segment(bvec, req, iter) {
  ^
In file included from block/blk-merge.c:6:0:
block/blk-merge.c: In function '__blk_recalc_rq_segments':
include/linux/bio.h:174:25: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wmaybe-uninitialized]
  ((bvec_to_phys((vec1)) + (vec1)->bv_len) == bvec_to_phys((vec2)))
                         ^
block/blk-merge.c:15:21: note: 'bvprv.bv_len' was declared here
  struct bio_vec bv, bvprv;
                     ^
In file included from block/blk-merge.c:6:0:
include/linux/bio.h:154:55: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
 #define bvec_to_phys(bv) (page_to_phys((bv)->bv_page) + (unsigned long) (bv)->bv_offset)
                                                       ^
block/blk-merge.c:15:21: note: 'bvprv.bv_offset' was declared here
  struct bio_vec bv, bvprv;
                     ^
In file included from arch/powerpc/include/asm/page.h:412:0,
                 from arch/powerpc/include/asm/thread_info.h:34,
                 from include/linux/thread_info.h:54,
                 from include/linux/preempt.h:9,
                 from include/linux/spinlock.h:50,
                 from include/linux/seqlock.h:35,
                 from include/linux/time.h:5,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from block/blk-merge.c:5:
include/asm-generic/memory_model.h:52:52: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wmaybe-uninitialized]
 #define __page_to_pfn(page) (unsigned long)((page) - vmemmap)
                                                    ^
block/blk-merge.c:15:21: note: 'bvprv.bv_page' was declared here
  struct bio_vec bv, bvprv;
                     ^

Some of this may be incomplete merge resolution on my part (help would
be appreciated), but some seems to maybe need more work.

I have used the block tree from next-20131031 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2013-02-06  3:06 Stephen Rothwell
@ 2013-02-06  8:33 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2013-02-06  8:33 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Greg Kroah-Hartman, josh.h.morris,
	Philip J Kelleher

On Wed, Feb 06 2013, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/block/rsxx/core.c:322:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rsxx_pci_probe'
> drivers/block/rsxx/core.c:513:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rsxx_pci_remove'
> drivers/block/rsxx/core.c:610:12: error: 'rsxx_pci_probe' undeclared here (not in a function)
> drivers/block/rsxx/core.c:611:2: error: implicit declaration of function '__devexit_p' [-Werror=implicit-function-declaration]
> drivers/block/rsxx/core.c:611:25: error: 'rsxx_pci_remove' undeclared here (not in a function)
> drivers/block/rsxx/core.c:51:8: warning: 'rsxx_disk_ida' defined but not used [-Wunused-variable]
> drivers/block/rsxx/core.c:52:8: warning: 'rsxx_ida_lock' defined but not used [-Wunused-variable]
> drivers/block/rsxx/core.c:219:13: warning: 'card_event_handler' defined but not used [-Wunused-function]
> drivers/block/rsxx/core.c:311:12: warning: 'rsxx_compatibility_check' defined but not used [-Wunused-function]
> 
> Caused by commit 8722ff8cdbfa ("block: IBM RamSan 70/80 device driver")
> interacting with commit 54b956b90360 ("Remove __dev* markings from
> init.h") from Linus' tree (as of v3.8-rc4).
> 
> I added the following merge fix patch:

Thanks Stephen, I merged it into the for-3.9/drivers branch and updated
for-next.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2013-02-06  3:06 Stephen Rothwell
  2013-02-06  8:33 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2013-02-06  3:06 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Greg Kroah-Hartman, josh.h.morris,
	Philip J Kelleher

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/block/rsxx/core.c:322:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rsxx_pci_probe'
drivers/block/rsxx/core.c:513:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rsxx_pci_remove'
drivers/block/rsxx/core.c:610:12: error: 'rsxx_pci_probe' undeclared here (not in a function)
drivers/block/rsxx/core.c:611:2: error: implicit declaration of function '__devexit_p' [-Werror=implicit-function-declaration]
drivers/block/rsxx/core.c:611:25: error: 'rsxx_pci_remove' undeclared here (not in a function)
drivers/block/rsxx/core.c:51:8: warning: 'rsxx_disk_ida' defined but not used [-Wunused-variable]
drivers/block/rsxx/core.c:52:8: warning: 'rsxx_ida_lock' defined but not used [-Wunused-variable]
drivers/block/rsxx/core.c:219:13: warning: 'card_event_handler' defined but not used [-Wunused-function]
drivers/block/rsxx/core.c:311:12: warning: 'rsxx_compatibility_check' defined but not used [-Wunused-function]

Caused by commit 8722ff8cdbfa ("block: IBM RamSan 70/80 device driver")
interacting with commit 54b956b90360 ("Remove __dev* markings from
init.h") from Linus' tree (as of v3.8-rc4).

I added the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 6 Feb 2013 14:03:13 +1100
Subject: [PATCH] block: remove new __devinit/exit annotations

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/block/rsxx/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index f752191..83dadbe 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -319,7 +319,7 @@ static int rsxx_compatibility_check(struct rsxx_cardinfo *card)
 	return 0;
 }
 
-static int __devinit rsxx_pci_probe(struct pci_dev *dev,
+static int rsxx_pci_probe(struct pci_dev *dev,
 					const struct pci_device_id *id)
 {
 	struct rsxx_cardinfo *card;
@@ -510,7 +510,7 @@ failed_ida_get:
 	return st;
 }
 
-static void __devexit rsxx_pci_remove(struct pci_dev *dev)
+static void rsxx_pci_remove(struct pci_dev *dev)
 {
 	struct rsxx_cardinfo *card = pci_get_drvdata(dev);
 	unsigned long flags;
@@ -608,7 +608,7 @@ static struct pci_driver rsxx_pci_driver = {
 	.name		= DRIVER_NAME,
 	.id_table	= rsxx_pci_ids,
 	.probe		= rsxx_pci_probe,
-	.remove		= __devexit_p(rsxx_pci_remove),
+	.remove		= rsxx_pci_remove,
 	.suspend	= rsxx_pci_suspend,
 	.shutdown	= rsxx_pci_shutdown,
 };
-- 
1.8.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2012-10-10  1:14 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2012-10-10  1:14 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Mikulas Patocka, Michel Lespinasse,
	Andrew Morton

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

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/block_dev.c: In function 'set_blocksize':
fs/block_dev.c:135:2: error: implicit declaration of function 'prio_tree_empty' [-Werror=implicit-function-declaration]

Caused by commit b87570f5d349 ("Fix a crash when block device is read and
block size is changed at the same time") interacting with commit
147e615f83c2 ("prio_tree: remove") which is now in Linus' tree.

I have added the following merge fix patch for today (this is a mash of
tow fix patches that used to be in Andrew's tree):

From: Andrew Morton <akpm@linux-foundation.org>
Subject: fs/block_dev.c:set_blocksize(): use mapping_mapped()

... instead of open-coding it.

Suggested-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

diff -puN fs/block_dev.c~fs-block_devc-set_blocksize-use-mapping_mapped fs/block_dev.c
--- a/fs/block_dev.c~fs-block_devc-set_blocksize-use-mapping_mapped
+++ a/fs/block_dev.c
@@ -132,8 +132,7 @@ int set_blocksize(struct block_device *b
 	/* Check that the block device is not memory mapped */
 	mapping = bdev->bd_inode->i_mapping;
 	mutex_lock(&mapping->i_mmap_mutex);
-	if (!prio_tree_empty(&mapping->i_mmap) ||
-	    !list_empty(&mapping->i_mmap_nonlinear)) {
+	if (mapping_mapped(mapping)) {
 		mutex_unlock(&mapping->i_mmap_mutex);
 		percpu_up_write(&bdev->bd_block_size_semaphore);
 		return -EBUSY;

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2012-09-27  3:27 Stephen Rothwell
@ 2012-09-27  7:37 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2012-09-27  7:37 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Mikulas Patocka, Alasdair G Kergon

On 09/27/2012 05:27 AM, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86
> 64_allmodconfig) failed like this:
> 
> usr/include/linux/fs.h:13: included file 'linux/percpu-rwsem.h' is not exported
> 
> Caused by commit 62ac665ff9fc ("blockdev: turn a rw semaphore into a
> percpu rw semaphore").
> 
> I have used the block tree from next-20120926 for today.  This will also
> affect the device-mapper tree which is based on the block tree (of which I
> will also use the next-20120926 version).

Bah, sorry about that. I have fixed it up now.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2012-09-27  3:27 Stephen Rothwell
  2012-09-27  7:37 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2012-09-27  3:27 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Mikulas Patocka, Alasdair G Kergon

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

Hi Jens,

After merging the block tree, today's linux-next build (x86
64_allmodconfig) failed like this:

usr/include/linux/fs.h:13: included file 'linux/percpu-rwsem.h' is not exported

Caused by commit 62ac665ff9fc ("blockdev: turn a rw semaphore into a
percpu rw semaphore").

I have used the block tree from next-20120926 for today.  This will also
affect the device-mapper tree which is based on the block tree (of which I
will also use the next-20120926 version).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-12-19  9:37 ` Jens Axboe
@ 2011-12-19 16:41   ` Tejun Heo
  0 siblings, 0 replies; 176+ messages in thread
From: Tejun Heo @ 2011-12-19 16:41 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Mon, Dec 19, 2011 at 10:37:57AM +0100, Jens Axboe wrote:
> Missing export, I've fixed it up and pushed out the change. Lets hope
> tomorrows tree is more succesful :-)

Oops, thanks Jens. :)

-- 
tejun

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-12-19  9:48   ` Jens Axboe
@ 2011-12-19 11:32     ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2011-12-19 11:32 UTC (permalink / raw)
  To: Jens Axboe; +Cc: sedat.dilek, Sedat Dilek, linux-next, linux-kernel, Tejun Heo

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

On Mon, 19 Dec 2011 10:48:06 +0100 Jens Axboe <axboe@kernel.dk> wrote:
>
> On 2011-12-19 10:45, Sedat Dilek wrote:
> > Just FYI:
> > 
> > - block           git     git://git.kernel.dk/linux-2.6-block.git#for-next
> > + block           git     git://git.kernel.dk/linux-block.git#for-next
> 
> linux-block.git is the one that should be used, however the 2.6 one is
> just a link to the new one. So old urls work just fine as well, it all
> goes to the same spot.

Thanks, guys. I have switched to that now.

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-12-19  9:45 ` Sedat Dilek
@ 2011-12-19  9:48   ` Jens Axboe
  2011-12-19 11:32     ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2011-12-19  9:48 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Sedat Dilek, Stephen Rothwell, linux-next, linux-kernel, Tejun Heo

On 2011-12-19 10:45, Sedat Dilek wrote:
> Just FYI:
> 
> - block           git     git://git.kernel.dk/linux-2.6-block.git#for-next
> + block           git     git://git.kernel.dk/linux-block.git#for-next

linux-block.git is the one that should be used, however the 2.6 one is
just a link to the new one. So old urls work just fine as well, it all
goes to the same spot.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-12-19  3:19 Stephen Rothwell
  2011-12-19  9:37 ` Jens Axboe
@ 2011-12-19  9:45 ` Sedat Dilek
  2011-12-19  9:48   ` Jens Axboe
  1 sibling, 1 reply; 176+ messages in thread
From: Sedat Dilek @ 2011-12-19  9:45 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Jens Axboe, linux-next, linux-kernel, Tejun Heo

Just FYI:

- block           git     git://git.kernel.dk/linux-2.6-block.git#for-next
+ block           git     git://git.kernel.dk/linux-block.git#for-next

- Sedat -

[1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees#l130
[2] http://git.kernel.dk/?p=linux-block.git;a=shortlog;h=refs/heads/for-next

On Mon, Dec 19, 2011 at 4:19 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "ioc_cgroup_changed" [block/blk-cgroup.ko] undefined!
>
> Caused by commit dc86900e0a8f ("block, cfq: move ioc ioprio/cgroup
> changed handling to cic").
>
> I have used the block tree from next-20111215 again today.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-12-19  3:19 Stephen Rothwell
@ 2011-12-19  9:37 ` Jens Axboe
  2011-12-19 16:41   ` Tejun Heo
  2011-12-19  9:45 ` Sedat Dilek
  1 sibling, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2011-12-19  9:37 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Tejun Heo

On 2011-12-19 04:19, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "ioc_cgroup_changed" [block/blk-cgroup.ko] undefined!
> 
> Caused by commit dc86900e0a8f ("block, cfq: move ioc ioprio/cgroup
> changed handling to cic").
> 
> I have used the block tree from next-20111215 again today.

Missing export, I've fixed it up and pushed out the change. Lets hope
tomorrows tree is more succesful :-)

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-12-19  3:19 Stephen Rothwell
  2011-12-19  9:37 ` Jens Axboe
  2011-12-19  9:45 ` Sedat Dilek
  0 siblings, 2 replies; 176+ messages in thread
From: Stephen Rothwell @ 2011-12-19  3:19 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Tejun Heo

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "ioc_cgroup_changed" [block/blk-cgroup.ko] undefined!

Caused by commit dc86900e0a8f ("block, cfq: move ioc ioprio/cgroup
changed handling to cic").

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-12-16  1:50 Stephen Rothwell
@ 2011-12-16  8:20 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2011-12-16  8:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Tejun Heo, majianpeng

On 2011-12-16 02:50, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> block/cfq-iosched.c: In function 'cfq_init_queue':
> block/cfq-iosched.c:3690:14: error: 'cic_index_lock' undeclared (first use in this function)
> block/cfq-iosched.c:3691:15: error: 'cic_index_ida' undeclared (first use in this function)
> block/cfq-iosched.c:3691:34: error: 'struct cfq_data' has no member named 'cic_index'
> 
> Presumably this was not build tested with CONFIG_CFQ_GROUP_IOSCHED set.
> 
> Caused by commit a73f730d013f ("block, cfq: move cfqd->cic_index to
> q->id") interacting with commit 2984ff38ccf6 ("cfq-iosched: free
> cic_index if blkio_alloc_blkg_stats fails").
> 
> I have used the block tree from next-20111215 for today.

Sorry Stephen, I'll get this merge problem fixed up.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-12-16  1:50 Stephen Rothwell
  2011-12-16  8:20 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-12-16  1:50 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Tejun Heo, majianpeng

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

block/cfq-iosched.c: In function 'cfq_init_queue':
block/cfq-iosched.c:3690:14: error: 'cic_index_lock' undeclared (first use in this function)
block/cfq-iosched.c:3691:15: error: 'cic_index_ida' undeclared (first use in this function)
block/cfq-iosched.c:3691:34: error: 'struct cfq_data' has no member named 'cic_index'

Presumably this was not build tested with CONFIG_CFQ_GROUP_IOSCHED set.

Caused by commit a73f730d013f ("block, cfq: move cfqd->cic_index to
q->id") interacting with commit 2984ff38ccf6 ("cfq-iosched: free
cic_index if blkio_alloc_blkg_stats fails").

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-09-17 11:18 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2011-09-17 11:18 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Sam Bradshaw

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

Hi Jens,

After merging the block tree, today's linux-next build (i386 allmodconfig)
failed like this:

drivers/block/mtip32xx/mtip32xx.c:95: error: expected specifier-qualifier-list before 'compat_ulong_t'
drivers/block/mtip32xx/mtip32xx.c: In function 'exec_drive_taskfile':
drivers/block/mtip32xx/mtip32xx.c:1631: warning: cast from pointer to integer of different size
drivers/block/mtip32xx/mtip32xx.c:1632: warning: cast from pointer to integer of different size
drivers/block/mtip32xx/mtip32xx.c:1633: warning: cast from pointer to integer of different size
drivers/block/mtip32xx/mtip32xx.c:1658: error: 'compat_long_t' undeclared (first use in this function)
drivers/block/mtip32xx/mtip32xx.c:1658: error: (Each undeclared identifier is reported only once
drivers/block/mtip32xx/mtip32xx.c:1658: error: for each function it appears in.)
drivers/block/mtip32xx/mtip32xx.c:1663: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1663: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1663: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1663: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1663: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1663: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1663: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1663: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1668: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1668: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1668: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1668: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1668: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1668: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1668: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1668: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1708: warning: cast from pointer to integer of different size
drivers/block/mtip32xx/mtip32xx.c:1729: warning: cast from pointer to integer of different size
drivers/block/mtip32xx/mtip32xx.c:1871: warning: cast from pointer to integer of different size
drivers/block/mtip32xx/mtip32xx.c:1872: warning: cast from pointer to integer of different size
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: warning: type defaults to 'int' in declaration of '__pu_val'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1922: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1922: error: 'struct mtip_compat_ide_task_request_s' has no member named 'out_size'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: warning: type defaults to 'int' in declaration of '__pu_val'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'
drivers/block/mtip32xx/mtip32xx.c:1927: warning: type defaults to 'int' in declaration of 'type name'
drivers/block/mtip32xx/mtip32xx.c:1927: error: 'struct mtip_compat_ide_task_request_s' has no member named 'in_size'

Caused by commit 49fdf3a7c4cf ("block: Add driver for Micron RealSSD pcie
flash cards").  Sorry I didn't spot it earlier ...

This driver assumes CONFIG_COMPAT is set.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-07-04  3:48 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2011-07-04  3:48 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Johannes Stezenbach, Arnd Bergmann

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

include/linux/fd.h:6: included file 'linux/compat.h' is not exported

Caused by commit 390192b30057 ("compat_ioctl: fix warning caused by
qemu").

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-06-01  6:26 ` Jens Axboe
@ 2011-06-01 13:43   ` Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 176+ messages in thread
From: Konrad Rzeszutek Wilk @ 2011-06-01 13:43 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Stephen Rothwell, linux-next, linux-kernel, Dan Carpenter

On Wed, Jun 01, 2011 at 08:26:29AM +0200, Jens Axboe wrote:
> On 2011-06-01 03:01, Stephen Rothwell wrote:
> > Hi Jens,
> > 
> > After merging the block tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/block/xen-blkback/blkback.c: In function 'xen_blkif_init':
> > drivers/block/xen-blkback/blkback.c:812:6: error: 'blkback' undeclared (first use in this function)
> > 
> > Caused by commit 2a46117c6050 ("xen/blkback: potential null dereference
> > in error handling").
> > 
> > I have used the block tree from next-20110530 for today.
> 
> Damn, sorry Stephen. Konrad, I'm rolling my tree back as not to
> introduce bisection breakage in the tree. JFYI, so rebase yours as well
> and lets try again.

Done. Sorry about that - I pushed the right tree minutes after I sent the git
pull email, but it took forever.... anyhow just pushed it and rebased on your for-linux.
Will send out a seperate email for the git pull.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-06-01  1:01 Stephen Rothwell
@ 2011-06-01  6:26 ` Jens Axboe
  2011-06-01 13:43   ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2011-06-01  6:26 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Dan Carpenter, Konrad Rzeszutek Wilk

On 2011-06-01 03:01, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/block/xen-blkback/blkback.c: In function 'xen_blkif_init':
> drivers/block/xen-blkback/blkback.c:812:6: error: 'blkback' undeclared (first use in this function)
> 
> Caused by commit 2a46117c6050 ("xen/blkback: potential null dereference
> in error handling").
> 
> I have used the block tree from next-20110530 for today.

Damn, sorry Stephen. Konrad, I'm rolling my tree back as not to
introduce bisection breakage in the tree. JFYI, so rebase yours as well
and lets try again.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-06-01  1:01 Stephen Rothwell
  2011-06-01  6:26 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-06-01  1:01 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Dan Carpenter, Konrad Rzeszutek Wilk

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/block/xen-blkback/blkback.c: In function 'xen_blkif_init':
drivers/block/xen-blkback/blkback.c:812:6: error: 'blkback' undeclared (first use in this function)

Caused by commit 2a46117c6050 ("xen/blkback: potential null dereference
in error handling").

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-03-25  4:08 ` Akinobu Mita
@ 2011-03-25  5:25   ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2011-03-25  5:25 UTC (permalink / raw)
  To: Akinobu Mita
  Cc: Jens Axboe, linux-next, linux-kernel, Lars Ellenberg,
	Philipp Reisner, Andrew Morton

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

Hi,

On Fri, 25 Mar 2011 13:08:51 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
>
> Please remove "#include <asm-generic/bitops/le.h>" from this file.

Indeed that is required, or in some circumstances you get these errors
(from a powerpc allyesonfig build):

In file included from drivers/block/drbd/drbd_bitmap.c:32:
include/asm-generic/bitops/le.h:45: error: conflicting types for 'test_bit_le'
arch/powerpc/include/asm/bitops.h:284: note: previous definition of 'test_bit_le' was here
include/asm-generic/bitops/le.h:50: error: redefinition of '__set_bit_le'
arch/powerpc/include/asm/bitops.h:291: note: previous definition of '__set_bit_le' was here
include/asm-generic/bitops/le.h:55: error: redefinition of '__clear_bit_le'
arch/powerpc/include/asm/bitops.h:296: note: previous definition of '__clear_bit_le' was here
include/asm-generic/bitops/le.h:60: error: redefinition of 'test_and_set_bit_le'
arch/powerpc/include/asm/bitops.h:301: note: previous definition of 'test_and_set_bit_le' was here
include/asm-generic/bitops/le.h:65: error: redefinition of 'test_and_clear_bit_le'
arch/powerpc/include/asm/bitops.h:306: note: previous definition of 'test_and_clear_bit_le' was here
include/asm-generic/bitops/le.h:70: error: redefinition of '__test_and_set_bit_le'
arch/powerpc/include/asm/bitops.h:311: note: previous definition of '__test_and_set_bit_le' was here
include/asm-generic/bitops/le.h:75: error: redefinition of '__test_and_clear_bit_le'
arch/powerpc/include/asm/bitops.h:316: note: previous definition of '__test_and_clear_bit_le' was here

This is fixed by reverting commit f0ff1357ce39 ("drbd: need include for
bitops functions declarations").

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-03-25  3:30 Stephen Rothwell
@ 2011-03-25  4:08 ` Akinobu Mita
  2011-03-25  5:25   ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Akinobu Mita @ 2011-03-25  4:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, linux-next, linux-kernel, Lars Ellenberg,
	Philipp Reisner, Andrew Morton

2011/3/25 Stephen Rothwell <sfr@canb.auug.org.au>:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 25 Mar 2011 14:27:57 +1100
> Subject: [PATCH] drbd: update for bitop api changes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/block/drbd/drbd_bitmap.c |   12 ++++++------
>  1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/drbd/drbd_bitmap.c b/drivers/block/drbd/drbd_bitmap.c
> index f0ae63d..eb925fa 100644
> --- a/drivers/block/drbd/drbd_bitmap.c
> +++ b/drivers/block/drbd/drbd_bitmap.c

Please remove "#include <asm-generic/bitops/le.h>" from this file.

> @@ -1184,10 +1184,10 @@ static unsigned long __bm_find_next(struct drbd_conf *mdev, unsigned long bm_fo,
>                        p_addr = __bm_map_pidx(b, bm_bit_to_page_idx(b, bm_fo), km);
>
>                        if (find_zero_bit)
> -                               i = generic_find_next_zero_le_bit(p_addr,
> +                               i = find_next_zero_bit_le(p_addr,
>                                                PAGE_SIZE*8, bm_fo & BITS_PER_PAGE_MASK);
>                        else
> -                               i = generic_find_next_le_bit(p_addr,
> +                               i = find_next_bit_le(p_addr,
>                                                PAGE_SIZE*8, bm_fo & BITS_PER_PAGE_MASK);
>
>                        __bm_unmap(p_addr, km);
> @@ -1287,9 +1287,9 @@ static int __bm_change_bits_to(struct drbd_conf *mdev, const unsigned long s,
>                        last_page_nr = page_nr;
>                }
>                if (val)
> -                       c += (0 == generic___test_and_set_le_bit(bitnr & BITS_PER_PAGE_MASK, p_addr));
> +                       c += (0 == __test_and_set_bit_le(bitnr & BITS_PER_PAGE_MASK, p_addr));
>                else
> -                       c -= (0 != generic___test_and_clear_le_bit(bitnr & BITS_PER_PAGE_MASK, p_addr));
> +                       c -= (0 != __test_and_clear_bit_le(bitnr & BITS_PER_PAGE_MASK, p_addr));
>        }
>        if (p_addr)
>                __bm_unmap(p_addr, km);
> @@ -1438,7 +1438,7 @@ int drbd_bm_test_bit(struct drbd_conf *mdev, const unsigned long bitnr)
>                bm_print_lock_info(mdev);
>        if (bitnr < b->bm_bits) {
>                p_addr = bm_map_pidx(b, bm_bit_to_page_idx(b, bitnr));
> -               i = generic_test_le_bit(bitnr & BITS_PER_PAGE_MASK, p_addr) ? 1 : 0;
> +               i = test_bit_le(bitnr & BITS_PER_PAGE_MASK, p_addr) ? 1 : 0;
>                bm_unmap(p_addr);
>        } else if (bitnr == b->bm_bits) {
>                i = -1;
> @@ -1482,7 +1482,7 @@ int drbd_bm_count_bits(struct drbd_conf *mdev, const unsigned long s, const unsi
>                ERR_IF (bitnr >= b->bm_bits) {
>                        dev_err(DEV, "bitnr=%lu bm_bits=%lu\n", bitnr, b->bm_bits);
>                } else {
> -                       c += (0 != generic_test_le_bit(bitnr - (page_nr << (PAGE_SHIFT+3)), p_addr));
> +                       c += (0 != test_bit_le(bitnr - (page_nr << (PAGE_SHIFT+3)), p_addr));
>                }
>        }
>        if (p_addr)
> --
> 1.7.4.1
>
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
>

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-03-25  3:30 Stephen Rothwell
  2011-03-25  4:08 ` Akinobu Mita
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-03-25  3:30 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Lars Ellenberg, Philipp Reisner,
	Akinobu Mita, Andrew Morton

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/block/drbd/drbd_bitmap.c: In function '__bm_find_next':
drivers/block/drbd/drbd_bitmap.c:1187: error: implicit declaration of function 'generic_find_next_zero_le_bit'
drivers/block/drbd/drbd_bitmap.c:1190: error: implicit declaration of function 'generic_find_next_le_bit'
drivers/block/drbd/drbd_bitmap.c: In function '__bm_change_bits_to':
drivers/block/drbd/drbd_bitmap.c:1290: error: implicit declaration of function 'generic___test_and_set_le_bit'
drivers/block/drbd/drbd_bitmap.c:1292: error: implicit declaration of function 'generic___test_and_clear_le_bit'
drivers/block/drbd/drbd_bitmap.c: In function 'drbd_bm_test_bit':
drivers/block/drbd/drbd_bitmap.c:1441: error: implicit declaration of function 'generic_test_le_bit'

Caused by commit 95a0f10cddbf ("drbd: store in-core bitmap little endian,
regardless of architecture") interacting with commit c4945b9ed472
("asm-generic: rename generic little-endian bitops functions") from
Linus' tree.

I applied the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 25 Mar 2011 14:27:57 +1100
Subject: [PATCH] drbd: update for bitop api changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/block/drbd/drbd_bitmap.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/block/drbd/drbd_bitmap.c b/drivers/block/drbd/drbd_bitmap.c
index f0ae63d..eb925fa 100644
--- a/drivers/block/drbd/drbd_bitmap.c
+++ b/drivers/block/drbd/drbd_bitmap.c
@@ -1184,10 +1184,10 @@ static unsigned long __bm_find_next(struct drbd_conf *mdev, unsigned long bm_fo,
 			p_addr = __bm_map_pidx(b, bm_bit_to_page_idx(b, bm_fo), km);
 
 			if (find_zero_bit)
-				i = generic_find_next_zero_le_bit(p_addr,
+				i = find_next_zero_bit_le(p_addr,
 						PAGE_SIZE*8, bm_fo & BITS_PER_PAGE_MASK);
 			else
-				i = generic_find_next_le_bit(p_addr,
+				i = find_next_bit_le(p_addr,
 						PAGE_SIZE*8, bm_fo & BITS_PER_PAGE_MASK);
 
 			__bm_unmap(p_addr, km);
@@ -1287,9 +1287,9 @@ static int __bm_change_bits_to(struct drbd_conf *mdev, const unsigned long s,
 			last_page_nr = page_nr;
 		}
 		if (val)
-			c += (0 == generic___test_and_set_le_bit(bitnr & BITS_PER_PAGE_MASK, p_addr));
+			c += (0 == __test_and_set_bit_le(bitnr & BITS_PER_PAGE_MASK, p_addr));
 		else
-			c -= (0 != generic___test_and_clear_le_bit(bitnr & BITS_PER_PAGE_MASK, p_addr));
+			c -= (0 != __test_and_clear_bit_le(bitnr & BITS_PER_PAGE_MASK, p_addr));
 	}
 	if (p_addr)
 		__bm_unmap(p_addr, km);
@@ -1438,7 +1438,7 @@ int drbd_bm_test_bit(struct drbd_conf *mdev, const unsigned long bitnr)
 		bm_print_lock_info(mdev);
 	if (bitnr < b->bm_bits) {
 		p_addr = bm_map_pidx(b, bm_bit_to_page_idx(b, bitnr));
-		i = generic_test_le_bit(bitnr & BITS_PER_PAGE_MASK, p_addr) ? 1 : 0;
+		i = test_bit_le(bitnr & BITS_PER_PAGE_MASK, p_addr) ? 1 : 0;
 		bm_unmap(p_addr);
 	} else if (bitnr == b->bm_bits) {
 		i = -1;
@@ -1482,7 +1482,7 @@ int drbd_bm_count_bits(struct drbd_conf *mdev, const unsigned long s, const unsi
 		ERR_IF (bitnr >= b->bm_bits) {
 			dev_err(DEV, "bitnr=%lu bm_bits=%lu\n", bitnr, b->bm_bits);
 		} else {
-			c += (0 != generic_test_le_bit(bitnr - (page_nr << (PAGE_SHIFT+3)), p_addr));
+			c += (0 != test_bit_le(bitnr - (page_nr << (PAGE_SHIFT+3)), p_addr));
 		}
 	}
 	if (p_addr)
-- 
1.7.4.1


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-03-17 10:45       ` Jens Axboe
@ 2011-03-21 23:33         ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2011-03-21 23:33 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Jens Axboe, linux-next, linux-kernel, Jarkko Lavinen

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

Hi Guys,

On Thu, 17 Mar 2011 11:45:35 +0100 Jens Axboe <axboe@kernel.dk> wrote:
>
> On 2011-03-17 11:36, David Woodhouse wrote:
> > On Thu, 2011-03-17 at 10:18 +0000, Jens Axboe wrote:
> >>
> >> Can you point me at the commit in question? Generally,
> >> elv_queue_empty()
> >> can be replaced by blk_peek_request(). 
> > 
> > The interesting commit is this one:
> > http://git.infradead.org/mtd-2.6.git/commitdiff/c7519dbf6
> > 
> > The point of it is to enable this
> > http://git.infradead.org/mtd-2.6.git/commitdiff/a32159024
> 
> OK, can you commit a change just changing that to blk_peek_request()?
> That'll avoid the conflict.

I am still reverting those three commits from the mtd tree ...  David, I
assume that you are going to want to ask Linus to merge the mtd tree at
some point soon?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-03-17 10:36     ` David Woodhouse
@ 2011-03-17 10:45       ` Jens Axboe
  2011-03-21 23:33         ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2011-03-17 10:45 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Stephen Rothwell, linux-next, linux-kernel, Jarkko Lavinen

On 2011-03-17 11:36, David Woodhouse wrote:
> On Thu, 2011-03-17 at 10:18 +0000, Jens Axboe wrote:
>>
>> Can you point me at the commit in question? Generally,
>> elv_queue_empty()
>> can be replaced by blk_peek_request(). 
> 
> The interesting commit is this one:
> http://git.infradead.org/mtd-2.6.git/commitdiff/c7519dbf6
> 
> The point of it is to enable this
> http://git.infradead.org/mtd-2.6.git/commitdiff/a32159024

OK, can you commit a change just changing that to blk_peek_request()?
That'll avoid the conflict.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-03-17 10:18   ` Jens Axboe
@ 2011-03-17 10:36     ` David Woodhouse
  2011-03-17 10:45       ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: David Woodhouse @ 2011-03-17 10:36 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Stephen Rothwell, linux-next, linux-kernel, Jarkko Lavinen

On Thu, 2011-03-17 at 10:18 +0000, Jens Axboe wrote:
> 
> Can you point me at the commit in question? Generally,
> elv_queue_empty()
> can be replaced by blk_peek_request(). 

The interesting commit is this one:
http://git.infradead.org/mtd-2.6.git/commitdiff/c7519dbf6

The point of it is to enable this
http://git.infradead.org/mtd-2.6.git/commitdiff/a32159024

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-03-16 23:32 ` Stephen Rothwell
@ 2011-03-17 10:18   ` Jens Axboe
  2011-03-17 10:36     ` David Woodhouse
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2011-03-17 10:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Jarkko Lavinen, David Woodhouse

On 2011-03-17 00:32, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 14 Mar 2011 16:19:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/mtd/mtd_blkdevs.c: In function 'mtd_blktrans_cease_background':
>> drivers/mtd/mtd_blkdevs.c:127: error: implicit declaration of function 'elv_queue_empty'
>>
>> Caused by commit 7eaceaccab5f ("block: remove per-queue plugging")
>> interacting with commit c7519dbf6f4b ("mtd_blkdevs: Add background
>> processing support") from the mtd tree.
>>
>> I have no idea how to fix this up, so I have reverted the above commit
>> from them mtd tree (along with commits a32159024620 "mtd: Add mtdswap
>> block driver" and 89d8d32060de "mtd: fix printf format warnings, mostly
>> lack of %zd for size_t, in mtdswap" that depend on it).
>>
>> Jens, maybe you could advise the mtd guys.
> 
> Ping?

Can you point me at the commit in question? Generally, elv_queue_empty()
can be replaced by blk_peek_request().

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-03-14  5:19 Stephen Rothwell
@ 2011-03-16 23:32 ` Stephen Rothwell
  2011-03-17 10:18   ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-03-16 23:32 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Jarkko Lavinen, David Woodhouse

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

Hi all,

On Mon, 14 Mar 2011 16:19:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/mtd/mtd_blkdevs.c: In function 'mtd_blktrans_cease_background':
> drivers/mtd/mtd_blkdevs.c:127: error: implicit declaration of function 'elv_queue_empty'
> 
> Caused by commit 7eaceaccab5f ("block: remove per-queue plugging")
> interacting with commit c7519dbf6f4b ("mtd_blkdevs: Add background
> processing support") from the mtd tree.
> 
> I have no idea how to fix this up, so I have reverted the above commit
> from them mtd tree (along with commits a32159024620 "mtd: Add mtdswap
> block driver" and 89d8d32060de "mtd: fix printf format warnings, mostly
> lack of %zd for size_t, in mtdswap" that depend on it).
> 
> Jens, maybe you could advise the mtd guys.

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-03-14  5:19 Stephen Rothwell
  2011-03-16 23:32 ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-03-14  5:19 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Jarkko Lavinen, David Woodhouse

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/mtd/mtd_blkdevs.c: In function 'mtd_blktrans_cease_background':
drivers/mtd/mtd_blkdevs.c:127: error: implicit declaration of function 'elv_queue_empty'

Caused by commit 7eaceaccab5f ("block: remove per-queue plugging")
interacting with commit c7519dbf6f4b ("mtd_blkdevs: Add background
processing support") from the mtd tree.

I have no idea how to fix this up, so I have reverted the above commit
from them mtd tree (along with commits a32159024620 "mtd: Add mtdswap
block driver" and 89d8d32060de "mtd: fix printf format warnings, mostly
lack of %zd for size_t, in mtdswap" that depend on it).

Jens, maybe you could advise the mtd guys.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-03-10  3:08 Stephen Rothwell
@ 2011-03-10  7:15 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2011-03-10  7:15 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On 2011-03-10 04:08, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/target/target_core_iblock.c: In function 'iblock_do_task':
> drivers/target/target_core_iblock.c:425: error: 'struct request_queue' has no member named 'unplug_fn'
> drivers/target/target_core_iblock.c:426: error: 'struct request_queue' has no member named 'unplug_fn'

Ah darn, recent merge. I'll fix this up.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-03-10  3:08 Stephen Rothwell
  2011-03-10  7:15 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-03-10  3:08 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/target/target_core_iblock.c: In function 'iblock_do_task':
drivers/target/target_core_iblock.c:425: error: 'struct request_queue' has no member named 'unplug_fn'
drivers/target/target_core_iblock.c:426: error: 'struct request_queue' has no member named 'unplug_fn'

Caused by commit 622f85400f0b ("block: remove per-queue plugging").  Grep
is your friend :-)

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-03-07  2:39 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2011-03-07  2:39 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Tejun Heo

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

block/blk-flush.c: In function 'flush_end_io':
block/blk-flush.c:217: error: too few arguments to function '__blk_run_queue'
block/blk-flush.c: In function 'flush_data_end_io':
block/blk-flush.c:271: error: too few arguments to function '__blk_run_queue'

Caused by commit ae1b1539622fb46e51b4d13b3f9e5f4c713f86ae ("block:
reimplement FLUSH/FUA to support merge") interacting with commit
1654e7411a1ad4999fe7890ef51d2a2bbb1fcf76 ("block: add @force_kblockd to
__blk_run_queue()") from Linus' tree.  My merge fix up was obviously not
sufficient.

I added this merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 Mar 2011 13:27:04 +1100
Subject: [PATCH] block: update for __blk_run_queue() API update

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

diff --git a/block/blk-flush.c b/block/blk-flush.c
index a867e3f..f9b0228 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -214,7 +214,7 @@ static void flush_end_io(struct request *flush_rq, int error)
 
 	/* after populating an empty queue, kick it to avoid stall */
 	if (queued && was_empty)
-		__blk_run_queue(q);
+		__blk_run_queue(q, false);
 }
 
 /**
@@ -268,7 +268,7 @@ static void flush_data_end_io(struct request *rq, int error)
 
 	/* after populating an empty queue, kick it to avoid stall */
 	if (blk_flush_complete_seq(rq, REQ_FSEQ_DATA, error) && was_empty)
-		__blk_run_queue(q);
+		__blk_run_queue(q, false);
 }
 
 /**
-- 
1.7.4.1

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-01-07 18:04             ` Sedat Dilek
@ 2011-01-07 18:20               ` Sedat Dilek
  0 siblings, 0 replies; 176+ messages in thread
From: Sedat Dilek @ 2011-01-07 18:20 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Stephen Rothwell, Mathieu Desnoyers, linux-next, linux-kernel

On Fri, Jan 7, 2011 at 7:04 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> On Fri, Jan 7, 2011 at 4:08 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> On 2011-01-07 15:22, Stephen Rothwell wrote:
>>> Hi,
>>>
>>> On Fri, 7 Jan 2011 14:19:33 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>>>>
>>>> Hmm, I have pulled-in freshly from linux-2.6-block#for-next after you
>>>> published latest linux-next (next-20110107).
>>>> So, I guessed the (reported) issue is fixed, now.
>>>
>>> No, the commit that caused the warnings was removed when I went back to
>>> using the block tree from next-20110106.  So it will come back unless
>>> fixed.
>>
>> It is fixed in linux-2.6-block#for-next as-of earlier today, so if Sedat
>> pulled from there it should be gone.
>>
>> --
>> Jens Axboe
>>
>>
>
> I guess 0002 should fix it, its not the case (patch + "big diff" attached).
>
> - Sedat -
>
[...]

Missing "blktrace: add missing probe argument to block_bio_complete" patch.

- Sedat -

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-01-07 15:08           ` Jens Axboe
@ 2011-01-07 18:04             ` Sedat Dilek
  2011-01-07 18:20               ` Sedat Dilek
  0 siblings, 1 reply; 176+ messages in thread
From: Sedat Dilek @ 2011-01-07 18:04 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Stephen Rothwell, Mathieu Desnoyers, linux-next, linux-kernel

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

On Fri, Jan 7, 2011 at 4:08 PM, Jens Axboe <axboe@kernel.dk> wrote:
> On 2011-01-07 15:22, Stephen Rothwell wrote:
>> Hi,
>>
>> On Fri, 7 Jan 2011 14:19:33 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>>>
>>> Hmm, I have pulled-in freshly from linux-2.6-block#for-next after you
>>> published latest linux-next (next-20110107).
>>> So, I guessed the (reported) issue is fixed, now.
>>
>> No, the commit that caused the warnings was removed when I went back to
>> using the block tree from next-20110106.  So it will come back unless
>> fixed.
>
> It is fixed in linux-2.6-block#for-next as-of earlier today, so if Sedat
> pulled from there it should be gone.
>
> --
> Jens Axboe
>
>

I guess 0002 should fix it, its not the case (patch + "big diff" attached).

- Sedat -

sd@tbox:~/src/linux-2.6/linux-2.6.37/debian/patches$ LC_ALL=C ls -l
linux-2.6-block-for-next/
total 44
-rw-r--r-- 1 sd sd  5903 Jan  7 10:33
0001-block-add-internal-hd-part-table-references.patch
-rw-r--r-- 1 sd sd  2382 Jan  7 10:33
0002-block-trace-event-block-fix-unassigned-field.patch
-rw-r--r-- 1 sd sd  3400 Jan  7 10:33
0003-block-cfq-don-t-use-atomic_t-for-cfq_queue.patch
-rw-r--r-- 1 sd sd  3387 Jan  7 10:33
0004-block-cfq-don-t-use-atomic_t-for-cfq_group.patch
-rw-r--r-- 1 sd sd   403 Jan  7 10:33 Shortlog
-rw-r--r-- 1 sd sd   527 Jan  7 10:33 diffstat
-rw-r--r-- 1 sd sd 12797 Jan  7 10:33 linux-2.6-block-for-next.patch

[-- Attachment #2: 0002-block-trace-event-block-fix-unassigned-field.patch --]
[-- Type: plain/text, Size: 2382 bytes --]

[-- Attachment #3: linux-2.6-block-for-next.patch --]
[-- Type: plain/text, Size: 12797 bytes --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-01-07 14:22         ` Stephen Rothwell
@ 2011-01-07 15:08           ` Jens Axboe
  2011-01-07 18:04             ` Sedat Dilek
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2011-01-07 15:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: sedat.dilek, Sedat Dilek, Mathieu Desnoyers, linux-next, linux-kernel

On 2011-01-07 15:22, Stephen Rothwell wrote:
> Hi,
> 
> On Fri, 7 Jan 2011 14:19:33 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>>
>> Hmm, I have pulled-in freshly from linux-2.6-block#for-next after you
>> published latest linux-next (next-20110107).
>> So, I guessed the (reported) issue is fixed, now.
> 
> No, the commit that caused the warnings was removed when I went back to
> using the block tree from next-20110106.  So it will come back unless
> fixed.

It is fixed in linux-2.6-block#for-next as-of earlier today, so if Sedat
pulled from there it should be gone.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-01-07 13:19       ` Sedat Dilek
@ 2011-01-07 14:22         ` Stephen Rothwell
  2011-01-07 15:08           ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-01-07 14:22 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Sedat Dilek, Mathieu Desnoyers, Jens Axboe, linux-next, linux-kernel

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

Hi,

On Fri, 7 Jan 2011 14:19:33 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>
> Hmm, I have pulled-in freshly from linux-2.6-block#for-next after you
> published latest linux-next (next-20110107).
> So, I guessed the (reported) issue is fixed, now.

No, the commit that caused the warnings was removed when I went back to
using the block tree from next-20110106.  So it will come back unless
fixed.

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-01-07 12:17     ` Stephen Rothwell
@ 2011-01-07 13:19       ` Sedat Dilek
  2011-01-07 14:22         ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Sedat Dilek @ 2011-01-07 13:19 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Mathieu Desnoyers, Jens Axboe, linux-next, linux-kernel

On Fri, Jan 7, 2011 at 1:17 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi All,
>
> On Fri, 7 Jan 2011 11:52:08 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>>
>> JFYI:
>> I pulled in patches from linux-2.6-block#for-next (up to commit
>> 6573422f81efa3bd71848dc584c35d4318d3de0b):
>> "Merge branch 'for-2.6.38/core' into for-next"
>> ...into linux-next (next-20110107) and now I get:
>>
>> $ grep block build_linux-next_next20110107.dileks.2.log
>> 30886 blocks
>>   CC      fs/block_dev.o
>>   CC      mm/memblock.o
>>   CC      kernel/power/block_io.o
>> /home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/kernel/trace/blktrace.c:999:2:
>> warning: passing argument 1 of ‘register_trace_block_bio_complete’
>> from incompatible pointer type
>> /home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/include/trace/events/block.h:240:1:
>> note: expected ‘void (*)(void *, struct request_queue *, struct bio *,
>> int)’ but argument is of type ‘void (*)(void *, struct request_queue
>> *, struct bio *)’
>> /home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/kernel/trace/blktrace.c:1038:2:
>> warning: passing argument 1 of ‘unregister_trace_block_bio_complete’
>> from incompatible pointer type
>> /home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/include/trace/events/block.h:240:1:
>> note: expected ‘void (*)(void *, struct request_queue *, struct bio *,
>> int)’ but argument is of type ‘void (*)(void *, struct request_queue
>> *, struct bio *)’
>
> I reported that separately today and Mathieu Desnoyers (cc'd) has said
> that he will supply a patch.
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>

Hmm, I have pulled-in freshly from linux-2.6-block#for-next after you
published latest linux-next (next-20110107).
So, I guessed the (reported) issue is fixed, now.

- Sedat -

[1] http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=b7908c1035af7652cd613991b54dbff9c8b6bd3a

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-01-07 10:52   ` Sedat Dilek
@ 2011-01-07 12:17     ` Stephen Rothwell
  2011-01-07 13:19       ` Sedat Dilek
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-01-07 12:17 UTC (permalink / raw)
  To: sedat.dilek
  Cc: Mathieu Desnoyers, Sedat Dilek, Jens Axboe, linux-next, linux-kernel

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

Hi All,

On Fri, 7 Jan 2011 11:52:08 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>
> JFYI:
> I pulled in patches from linux-2.6-block#for-next (up to commit
> 6573422f81efa3bd71848dc584c35d4318d3de0b):
> "Merge branch 'for-2.6.38/core' into for-next"
> ...into linux-next (next-20110107) and now I get:
> 
> $ grep block build_linux-next_next20110107.dileks.2.log
> 30886 blocks
>   CC      fs/block_dev.o
>   CC      mm/memblock.o
>   CC      kernel/power/block_io.o
> /home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/kernel/trace/blktrace.c:999:2:
> warning: passing argument 1 of ‘register_trace_block_bio_complete’
> from incompatible pointer type
> /home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/include/trace/events/block.h:240:1:
> note: expected ‘void (*)(void *, struct request_queue *, struct bio *,
> int)’ but argument is of type ‘void (*)(void *, struct request_queue
> *, struct bio *)’
> /home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/kernel/trace/blktrace.c:1038:2:
> warning: passing argument 1 of ‘unregister_trace_block_bio_complete’
> from incompatible pointer type
> /home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/include/trace/events/block.h:240:1:
> note: expected ‘void (*)(void *, struct request_queue *, struct bio *,
> int)’ but argument is of type ‘void (*)(void *, struct request_queue
> *, struct bio *)’

I reported that separately today and Mathieu Desnoyers (cc'd) has said
that he will supply a patch.

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-01-07  7:32 ` Jens Axboe
@ 2011-01-07 10:52   ` Sedat Dilek
  2011-01-07 12:17     ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Sedat Dilek @ 2011-01-07 10:52 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Fri, Jan 7, 2011 at 8:32 AM, Jens Axboe <axboe@kernel.dk> wrote:
> On 2011-01-07 01:05, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> arch/powerpc/platforms/built-in.o: In function `.pmf_get_function':
>> (.text+0x723c): undefined reference to `.kref_get'
>> arch/powerpc/platforms/built-in.o: In function `.pmf_unregister_driver':
>> (.text+0x72c8): undefined reference to `.kref_get'
>> arch/powerpc/platforms/built-in.o: In function `.pmf_do_functions':
>> (.text+0x793c): undefined reference to `.kref_get'
>> arch/powerpc/platforms/built-in.o: In function `.__pmf_find_function':
>> (.text+0x7c80): undefined reference to `.kref_get'
>> arch/powerpc/platforms/built-in.o: In function `.pmf_register_driver':
>> (.text+0x8044): undefined reference to `.kref_get'
>> arch/powerpc/platforms/built-in.o:(.text+0x8310): more undefined references to `.kref_get' follow
>> lib/lib.a(kref.o):(__ksymtab+0x10): undefined reference to `kref_get'
>> drivers/built-in.o: In function `.get_current_tty':
>> (.text+0x60970): undefined reference to `.kref_get'
>> drivers/built-in.o: In function `.__proc_set_tty':
>> tty_io.c:(.text+0x61624): undefined reference to `.kref_get'
>> drivers/built-in.o: In function `.tty_init_dev':
>> (.text+0x64d2c): undefined reference to `.kref_get'
>> drivers/built-in.o: In function `.tty_open':
>> tty_io.c:(.text+0x64ee4): undefined reference to `.kref_get'
>> tty_io.c:(.text+0x64f20): undefined reference to `.kref_get'
>> drivers/built-in.o:tty_io.c:(.text+0x64f58): more undefined references to `.kref_get' follow
>>
>> Caused by commit 15454034cb3021d8bb9d21b4f35072a809197fdd ("block: add
>> internal hd part table references") which removes kref_get() instead of
>> kref_test_and_get()!
>>
>> This really wasn't tested, right?
>
> Irk, it was tested and booted, but apparently I merged the first bad
> version of the patch.
>
>> I have used the block tree from next-20110106 for today.
>
> Thanks, I'll get this fixed up now.
>
>
> --
> Jens Axboe
>

JFYI:
I pulled in patches from linux-2.6-block#for-next (up to commit
6573422f81efa3bd71848dc584c35d4318d3de0b):
"Merge branch 'for-2.6.38/core' into for-next"
...into linux-next (next-20110107) and now I get:

$ grep block build_linux-next_next20110107.dileks.2.log
30886 blocks
  CC      fs/block_dev.o
  CC      mm/memblock.o
  CC      kernel/power/block_io.o
/home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/kernel/trace/blktrace.c:999:2:
warning: passing argument 1 of ‘register_trace_block_bio_complete’
from incompatible pointer type
/home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/include/trace/events/block.h:240:1:
note: expected ‘void (*)(void *, struct request_queue *, struct bio *,
int)’ but argument is of type ‘void (*)(void *, struct request_queue
*, struct bio *)’
/home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/kernel/trace/blktrace.c:1038:2:
warning: passing argument 1 of ‘unregister_trace_block_bio_complete’
from incompatible pointer type
/home/sd/src/linux-2.6/linux-2.6.37/debian/build/source_i386_none/include/trace/events/block.h:240:1:
note: expected ‘void (*)(void *, struct request_queue *, struct bio *,
int)’ but argument is of type ‘void (*)(void *, struct request_queue
*, struct bio *)’
  CC      arch/x86/mm/memblock.o
  CC      block/elevator.o
  CC      block/blk-core.o
  CC      block/blk-tag.o
  CC      block/blk-sysfs.o
  CC      block/blk-flush.o
  CC      block/blk-settings.o
  CC      block/blk-ioc.o
  CC      block/blk-map.o
  CC      block/blk-exec.o
  CC      block/blk-merge.o
  CC      block/blk-softirq.o
  CC      block/blk-timeout.o
  CC      block/blk-iopoll.o
  CC      block/blk-lib.o
  CC      block/ioctl.o
  CC      block/genhd.o
  CC      block/scsi_ioctl.o
  CC      block/bsg.o
  CC      block/blk-cgroup.o
  CC      block/noop-iosched.o
  CC      block/deadline-iosched.o
  CC      block/cfq-iosched.o
  CC      block/blk-integrity.o
  LD      block/built-in.o

- Sedat -

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2011-01-07  0:05 Stephen Rothwell
@ 2011-01-07  7:32 ` Jens Axboe
  2011-01-07 10:52   ` Sedat Dilek
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2011-01-07  7:32 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On 2011-01-07 01:05, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/built-in.o: In function `.pmf_get_function':
> (.text+0x723c): undefined reference to `.kref_get'
> arch/powerpc/platforms/built-in.o: In function `.pmf_unregister_driver':
> (.text+0x72c8): undefined reference to `.kref_get'
> arch/powerpc/platforms/built-in.o: In function `.pmf_do_functions':
> (.text+0x793c): undefined reference to `.kref_get'
> arch/powerpc/platforms/built-in.o: In function `.__pmf_find_function':
> (.text+0x7c80): undefined reference to `.kref_get'
> arch/powerpc/platforms/built-in.o: In function `.pmf_register_driver':
> (.text+0x8044): undefined reference to `.kref_get'
> arch/powerpc/platforms/built-in.o:(.text+0x8310): more undefined references to `.kref_get' follow
> lib/lib.a(kref.o):(__ksymtab+0x10): undefined reference to `kref_get'
> drivers/built-in.o: In function `.get_current_tty':
> (.text+0x60970): undefined reference to `.kref_get'
> drivers/built-in.o: In function `.__proc_set_tty':
> tty_io.c:(.text+0x61624): undefined reference to `.kref_get'
> drivers/built-in.o: In function `.tty_init_dev':
> (.text+0x64d2c): undefined reference to `.kref_get'
> drivers/built-in.o: In function `.tty_open':
> tty_io.c:(.text+0x64ee4): undefined reference to `.kref_get'
> tty_io.c:(.text+0x64f20): undefined reference to `.kref_get'
> drivers/built-in.o:tty_io.c:(.text+0x64f58): more undefined references to `.kref_get' follow
> 
> Caused by commit 15454034cb3021d8bb9d21b4f35072a809197fdd ("block: add
> internal hd part table references") which removes kref_get() instead of
> kref_test_and_get()!
> 
> This really wasn't tested, right?

Irk, it was tested and booted, but apparently I merged the first bad
version of the patch.

> I have used the block tree from next-20110106 for today.

Thanks, I'll get this fixed up now.


-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2011-01-07  0:05 Stephen Rothwell
  2011-01-07  7:32 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2011-01-07  0:05 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel

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

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/platforms/built-in.o: In function `.pmf_get_function':
(.text+0x723c): undefined reference to `.kref_get'
arch/powerpc/platforms/built-in.o: In function `.pmf_unregister_driver':
(.text+0x72c8): undefined reference to `.kref_get'
arch/powerpc/platforms/built-in.o: In function `.pmf_do_functions':
(.text+0x793c): undefined reference to `.kref_get'
arch/powerpc/platforms/built-in.o: In function `.__pmf_find_function':
(.text+0x7c80): undefined reference to `.kref_get'
arch/powerpc/platforms/built-in.o: In function `.pmf_register_driver':
(.text+0x8044): undefined reference to `.kref_get'
arch/powerpc/platforms/built-in.o:(.text+0x8310): more undefined references to `.kref_get' follow
lib/lib.a(kref.o):(__ksymtab+0x10): undefined reference to `kref_get'
drivers/built-in.o: In function `.get_current_tty':
(.text+0x60970): undefined reference to `.kref_get'
drivers/built-in.o: In function `.__proc_set_tty':
tty_io.c:(.text+0x61624): undefined reference to `.kref_get'
drivers/built-in.o: In function `.tty_init_dev':
(.text+0x64d2c): undefined reference to `.kref_get'
drivers/built-in.o: In function `.tty_open':
tty_io.c:(.text+0x64ee4): undefined reference to `.kref_get'
tty_io.c:(.text+0x64f20): undefined reference to `.kref_get'
drivers/built-in.o:tty_io.c:(.text+0x64f58): more undefined references to `.kref_get' follow

Caused by commit 15454034cb3021d8bb9d21b4f35072a809197fdd ("block: add
internal hd part table references") which removes kref_get() instead of
kref_test_and_get()!

This really wasn't tested, right?

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-12-23  1:53 Stephen Rothwell
@ 2010-12-23 22:36 ` Nicholas A. Bellinger
  0 siblings, 0 replies; 176+ messages in thread
From: Nicholas A. Bellinger @ 2010-12-23 22:36 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, linux-next, linux-kernel, Tejun Heo, James Bottomley,
	Christoph Hellwig

On Thu, 2010-12-23 at 12:53 +1100, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/target/target_core_iblock.c: In function 'iblock_create_virtdevice':
> drivers/target/target_core_iblock.c:155: error: implicit declaration of function 'open_bdev_exclusive'
> drivers/target/target_core_iblock.c:156: warning: assignment makes pointer from integer without a cast
> drivers/target/target_core_iblock.c: In function 'iblock_free_device':
> drivers/target/target_core_iblock.c:223: error: implicit declaration of function 'close_bdev_exclusive'
> drivers/target/target_core_pscsi.c: In function 'pscsi_create_type_disk':
> drivers/target/target_core_pscsi.c:463: error: implicit declaration of function 'open_bdev_exclusive'
> drivers/target/target_core_pscsi.c:464: warning: assignment makes pointer from integer without a cast
> drivers/target/target_core_pscsi.c:474: error: implicit declaration of function 'close_bdev_exclusive'
> 
> Caused by commit 759026ddf4bdcfc68d1d330c7a5a9aee026a77c3 ("[SCSI]
> target: Add LIO target core v4.0.0-rc6") from the scsi tree interacting
> with commits e525fd89d380c4a94c0d63913a1dd1a593ed25e7 ("block: make
> blkdev_get/put() handle exclusive access") and
> d4d77629953eabd3c14f6fa5746f6b28babfc55f ("block: clean up blkdev_get()
> wrappers and their users") from the block tree.
> 
> We have better ways of deprecating/replacing interfaces ...
> 
> I have added the following fix up patch for today ... and can carry it as
> necessary, though someone needs to remember to tell Linus when the latter
> of the block and scsi trees get merged.
> 

Hi Stephen and James,

Thank you for catching and fixing this breakage.  Please carry this
patch for now, and I will get this merged into my upstream tree when I
pull .38-rc1 from Linus.  The patch is fine so feel free to add my:

Acked-by: Nicholas A. Bellinger <nab@linux-iscsi.org>

Also now that drivers/target/ code is on the linux-next radar, I will
begin regularly build testing against a 'for-linux-next' branch to catch
any future issues before they appear on your side.

Thank you and warmest regards,

--nab

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 23 Dec 2010 12:34:11 +1100
> Subject: [PATCH] scsi: fix for open/close_bdev_exclusive going away
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/target/target_core_iblock.c |    6 +++---
>  drivers/target/target_core_pscsi.c  |   12 ++++++------
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
> index e99bfc2..0d55188 100644
> --- a/drivers/target/target_core_iblock.c
> +++ b/drivers/target/target_core_iblock.c
> @@ -152,8 +152,8 @@ static struct se_device *iblock_create_virtdevice(
>  	printk(KERN_INFO  "IBLOCK: Claiming struct block_device: %s\n",
>  			ib_dev->ibd_udev_path);
>  
> -	bd = open_bdev_exclusive(ib_dev->ibd_udev_path,
> -			FMODE_WRITE|FMODE_READ, ib_dev);
> +	bd = blkdev_get_by_path(ib_dev->ibd_udev_path,
> +			FMODE_WRITE|FMODE_READ|FMODE_EXCL, ib_dev);
>  	if (!(bd))
>  		goto failed;
>  	/*
> @@ -220,7 +220,7 @@ static void iblock_free_device(void *p)
>  {
>  	struct iblock_dev *ib_dev = p;
>  
> -	close_bdev_exclusive(ib_dev->ibd_bd, FMODE_WRITE|FMODE_READ);
> +	blkdev_put(ib_dev->ibd_bd, FMODE_WRITE|FMODE_READ|FMODE_EXCL);
>  	bioset_free(ib_dev->ibd_bio_set);
>  	kfree(ib_dev);
>  }
> diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
> index 6a7495b..05924d1 100644
> --- a/drivers/target/target_core_pscsi.c
> +++ b/drivers/target/target_core_pscsi.c
> @@ -460,10 +460,10 @@ static struct se_device *pscsi_create_type_disk(
>  	 * Claim exclusive struct block_device access to struct scsi_device
>  	 * for TYPE_DISK using supplied udev_path
>  	 */
> -	bd = open_bdev_exclusive(se_dev->se_dev_udev_path,
> -				FMODE_WRITE|FMODE_READ, pdv);
> +	bd = blkdev_get_by_path(se_dev->se_dev_udev_path,
> +				FMODE_WRITE|FMODE_READ|FMODE_EXCL, pdv);
>  	if (!(bd)) {
> -		printk("pSCSI: open_bdev_exclusive() failed\n");
> +		printk("pSCSI: blkdev_get_by_path() failed\n");
>  		scsi_device_put(sd);
>  		return NULL;
>  	}
> @@ -471,7 +471,7 @@ static struct se_device *pscsi_create_type_disk(
>  
>  	dev = pscsi_add_device_to_list(hba, se_dev, pdv, sd, dev_flags);
>  	if (!(dev)) {
> -		close_bdev_exclusive(pdv->pdv_bd, FMODE_WRITE|FMODE_READ);
> +		blkdev_put(pdv->pdv_bd, FMODE_WRITE|FMODE_READ|FMODE_EXCL);
>  		scsi_device_put(sd);
>  		return NULL;
>  	}
> @@ -680,8 +680,8 @@ static void pscsi_free_device(void *p)
>  		 * struct scsi_device with TYPE_DISK from pscsi_create_type_disk()
>  		 */
>  		if ((sd->type == TYPE_DISK) && pdv->pdv_bd) {
> -			close_bdev_exclusive(pdv->pdv_bd,
> -					FMODE_WRITE|FMODE_READ);
> +			blkdev_put(pdv->pdv_bd,
> +					FMODE_WRITE|FMODE_READ|FMODE_EXCL);
>  			pdv->pdv_bd = NULL;
>  		}
>  		/*
> 

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-12-23  1:53 Stephen Rothwell
  2010-12-23 22:36 ` Nicholas A. Bellinger
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-12-23  1:53 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Tejun Heo, Nicholas Bellinger, James Bottomley

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/target/target_core_iblock.c: In function 'iblock_create_virtdevice':
drivers/target/target_core_iblock.c:155: error: implicit declaration of function 'open_bdev_exclusive'
drivers/target/target_core_iblock.c:156: warning: assignment makes pointer from integer without a cast
drivers/target/target_core_iblock.c: In function 'iblock_free_device':
drivers/target/target_core_iblock.c:223: error: implicit declaration of function 'close_bdev_exclusive'
drivers/target/target_core_pscsi.c: In function 'pscsi_create_type_disk':
drivers/target/target_core_pscsi.c:463: error: implicit declaration of function 'open_bdev_exclusive'
drivers/target/target_core_pscsi.c:464: warning: assignment makes pointer from integer without a cast
drivers/target/target_core_pscsi.c:474: error: implicit declaration of function 'close_bdev_exclusive'

Caused by commit 759026ddf4bdcfc68d1d330c7a5a9aee026a77c3 ("[SCSI]
target: Add LIO target core v4.0.0-rc6") from the scsi tree interacting
with commits e525fd89d380c4a94c0d63913a1dd1a593ed25e7 ("block: make
blkdev_get/put() handle exclusive access") and
d4d77629953eabd3c14f6fa5746f6b28babfc55f ("block: clean up blkdev_get()
wrappers and their users") from the block tree.

We have better ways of deprecating/replacing interfaces ...

I have added the following fix up patch for today ... and can carry it as
necessary, though someone needs to remember to tell Linus when the latter
of the block and scsi trees get merged.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 23 Dec 2010 12:34:11 +1100
Subject: [PATCH] scsi: fix for open/close_bdev_exclusive going away

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/target/target_core_iblock.c |    6 +++---
 drivers/target/target_core_pscsi.c  |   12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index e99bfc2..0d55188 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -152,8 +152,8 @@ static struct se_device *iblock_create_virtdevice(
 	printk(KERN_INFO  "IBLOCK: Claiming struct block_device: %s\n",
 			ib_dev->ibd_udev_path);
 
-	bd = open_bdev_exclusive(ib_dev->ibd_udev_path,
-			FMODE_WRITE|FMODE_READ, ib_dev);
+	bd = blkdev_get_by_path(ib_dev->ibd_udev_path,
+			FMODE_WRITE|FMODE_READ|FMODE_EXCL, ib_dev);
 	if (!(bd))
 		goto failed;
 	/*
@@ -220,7 +220,7 @@ static void iblock_free_device(void *p)
 {
 	struct iblock_dev *ib_dev = p;
 
-	close_bdev_exclusive(ib_dev->ibd_bd, FMODE_WRITE|FMODE_READ);
+	blkdev_put(ib_dev->ibd_bd, FMODE_WRITE|FMODE_READ|FMODE_EXCL);
 	bioset_free(ib_dev->ibd_bio_set);
 	kfree(ib_dev);
 }
diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
index 6a7495b..05924d1 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -460,10 +460,10 @@ static struct se_device *pscsi_create_type_disk(
 	 * Claim exclusive struct block_device access to struct scsi_device
 	 * for TYPE_DISK using supplied udev_path
 	 */
-	bd = open_bdev_exclusive(se_dev->se_dev_udev_path,
-				FMODE_WRITE|FMODE_READ, pdv);
+	bd = blkdev_get_by_path(se_dev->se_dev_udev_path,
+				FMODE_WRITE|FMODE_READ|FMODE_EXCL, pdv);
 	if (!(bd)) {
-		printk("pSCSI: open_bdev_exclusive() failed\n");
+		printk("pSCSI: blkdev_get_by_path() failed\n");
 		scsi_device_put(sd);
 		return NULL;
 	}
@@ -471,7 +471,7 @@ static struct se_device *pscsi_create_type_disk(
 
 	dev = pscsi_add_device_to_list(hba, se_dev, pdv, sd, dev_flags);
 	if (!(dev)) {
-		close_bdev_exclusive(pdv->pdv_bd, FMODE_WRITE|FMODE_READ);
+		blkdev_put(pdv->pdv_bd, FMODE_WRITE|FMODE_READ|FMODE_EXCL);
 		scsi_device_put(sd);
 		return NULL;
 	}
@@ -680,8 +680,8 @@ static void pscsi_free_device(void *p)
 		 * struct scsi_device with TYPE_DISK from pscsi_create_type_disk()
 		 */
 		if ((sd->type == TYPE_DISK) && pdv->pdv_bd) {
-			close_bdev_exclusive(pdv->pdv_bd,
-					FMODE_WRITE|FMODE_READ);
+			blkdev_put(pdv->pdv_bd,
+					FMODE_WRITE|FMODE_READ|FMODE_EXCL);
 			pdv->pdv_bd = NULL;
 		}
 		/*

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-10-11  3:18 Stephen Rothwell
@ 2010-10-23  2:51 ` Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2010-10-23  2:51 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: linux-next, linux-kernel, Lukas Czerner, Jens Axboe,
	Christoph Hellwig, Linus

Hi Ted,

On Mon, 11 Oct 2010 14:18:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from init/do_mounts.h:2,
>                  from init/do_mounts_md.c:5:
> include/linux/blkdev.h: In function 'sb_issue_zeroout':
> include/linux/blkdev.h:900: error: too many arguments to function 'blkdev_issue_zeroout'
> 
> Caused by commit dd3932eddf428571762596e17b65f5dc92ca361b ("block: remove
> BLKDEV_IFL_WAIT") interacting with commit
> 3be0ead7b05f0caaeb2f56b9902985b8120ef0cf ("Add helper function for
> blkdev_issue_zeroout (sb_issue_discard)") from the ext4 tree.
> 
> I applied the following merge fixup patch which I can carry as necessary
> (unless there is a better solution).

This fix (below) will now be necessary when the ext4 tree is merged with
Linus' tree.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 Oct 2010 13:50:22 +1100
Subject: [PATCH] ext4: merge fix for blkdev_issue_zeroout API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/ext4/extents.c      |    3 +--
 fs/ext4/ialloc.c       |    5 +----
 fs/ext4/resize.c       |    5 ++---
 include/linux/blkdev.h |    4 ++--
 4 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index a0e6230..a130f02 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2545,8 +2545,7 @@ static int ext4_ext_zeroout(struct inode *inode, struct ext4_extent *ex)
 	ee_len    = ext4_ext_get_actual_len(ex);
 	ee_pblock = ext_pblock(ex);
 
-	ret = sb_issue_zeroout(inode->i_sb, ee_pblock, ee_len,
-			       GFP_NOFS, BLKDEV_IFL_WAIT);
+	ret = sb_issue_zeroout(inode->i_sb, ee_pblock, ee_len, GFP_NOFS);
 	if (ret > 0)
 		ret = 0;
 
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 87d228a..f7e25aa 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -1238,7 +1238,6 @@ extern int ext4_init_inode_table(struct super_block *sb, ext4_group_t group,
 	handle_t *handle;
 	ext4_fsblk_t blk;
 	int num, ret = 0, used_blks = 0;
-	unsigned long flags = BLKDEV_IFL_WAIT;
 
 	/* This should not happen, but just to be sure check this */
 	if (sb->s_flags & MS_RDONLY) {
@@ -1303,9 +1302,7 @@ extern int ext4_init_inode_table(struct super_block *sb, ext4_group_t group,
 
 	ext4_debug("going to zero out inode table in group %d\n",
 		   group);
-	if (barrier)
-		flags |= BLKDEV_IFL_BARRIER;
-	ret = sb_issue_zeroout(sb, blk, num, GFP_NOFS, flags);
+	ret = sb_issue_zeroout(sb, blk, num, GFP_NOFS);
 	if (ret < 0)
 		goto err_out;
 
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 2f5e347..998a462 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -229,7 +229,7 @@ static int setup_new_group_blocks(struct super_block *sb,
 	ext4_debug("clear inode table blocks %#04llx -> %#04llx\n",
 			block, sbi->s_itb_per_group);
 	err = sb_issue_zeroout(sb, gdblocks + start + 1, reserved_gdb,
-			       GFP_NOFS, BLKDEV_IFL_WAIT);
+			       GFP_NOFS);
 	if (err)
 		goto exit_bh;
 
@@ -244,8 +244,7 @@ static int setup_new_group_blocks(struct super_block *sb,
 	block = input->inode_table;
 	ext4_debug("clear inode table blocks %#04llx -> %#04llx\n",
 			block, sbi->s_itb_per_group);
-	err = sb_issue_zeroout(sb, block, sbi->s_itb_per_group,
-			       GFP_NOFS, BLKDEV_IFL_WAIT);
+	err = sb_issue_zeroout(sb, block, sbi->s_itb_per_group, GFP_NOFS);
 	if (err)
 		goto exit_bh;
 
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index a1dec60..1095272 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -892,12 +892,12 @@ static inline int sb_issue_discard(struct super_block *sb, sector_t block,
 				    gfp_mask, flags);
 }
 static inline int sb_issue_zeroout(struct super_block *sb, sector_t block,
-		sector_t nr_blocks, gfp_t gfp_mask, unsigned long flags)
+		sector_t nr_blocks, gfp_t gfp_mask)
 {
 	return blkdev_issue_zeroout(sb->s_bdev,
 				    block << (sb->s_blocksize_bits - 9),
 				    nr_blocks << (sb->s_blocksize_bits - 9),
-				    gfp_mask, flags);
+				    gfp_mask);
 }
 
 extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
-- 
1.7.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-10-11  3:18 Stephen Rothwell
  2010-10-23  2:51 ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-10-11  3:18 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Lukas Czerner, Theodore Ts'o,
	Christoph Hellwig

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from init/do_mounts.h:2,
                 from init/do_mounts_md.c:5:
include/linux/blkdev.h: In function 'sb_issue_zeroout':
include/linux/blkdev.h:900: error: too many arguments to function 'blkdev_issue_zeroout'

Caused by commit dd3932eddf428571762596e17b65f5dc92ca361b ("block: remove
BLKDEV_IFL_WAIT") interacting with commit
3be0ead7b05f0caaeb2f56b9902985b8120ef0cf ("Add helper function for
blkdev_issue_zeroout (sb_issue_discard)") from the ext4 tree.

I applied the following merge fixup patch which I can carry as necessary
(unless there is a better solution).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 Oct 2010 13:50:22 +1100
Subject: [PATCH] ext4: merge fix for blkdev_issue_zeroout API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/ext4/extents.c      |    3 +--
 fs/ext4/ialloc.c       |    5 +----
 fs/ext4/resize.c       |    5 ++---
 include/linux/blkdev.h |    4 ++--
 4 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index a0e6230..a130f02 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2545,8 +2545,7 @@ static int ext4_ext_zeroout(struct inode *inode, struct ext4_extent *ex)
 	ee_len    = ext4_ext_get_actual_len(ex);
 	ee_pblock = ext_pblock(ex);
 
-	ret = sb_issue_zeroout(inode->i_sb, ee_pblock, ee_len,
-			       GFP_NOFS, BLKDEV_IFL_WAIT);
+	ret = sb_issue_zeroout(inode->i_sb, ee_pblock, ee_len, GFP_NOFS);
 	if (ret > 0)
 		ret = 0;
 
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 87d228a..f7e25aa 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -1238,7 +1238,6 @@ extern int ext4_init_inode_table(struct super_block *sb, ext4_group_t group,
 	handle_t *handle;
 	ext4_fsblk_t blk;
 	int num, ret = 0, used_blks = 0;
-	unsigned long flags = BLKDEV_IFL_WAIT;
 
 	/* This should not happen, but just to be sure check this */
 	if (sb->s_flags & MS_RDONLY) {
@@ -1303,9 +1302,7 @@ extern int ext4_init_inode_table(struct super_block *sb, ext4_group_t group,
 
 	ext4_debug("going to zero out inode table in group %d\n",
 		   group);
-	if (barrier)
-		flags |= BLKDEV_IFL_BARRIER;
-	ret = sb_issue_zeroout(sb, blk, num, GFP_NOFS, flags);
+	ret = sb_issue_zeroout(sb, blk, num, GFP_NOFS);
 	if (ret < 0)
 		goto err_out;
 
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 2f5e347..998a462 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -229,7 +229,7 @@ static int setup_new_group_blocks(struct super_block *sb,
 	ext4_debug("clear inode table blocks %#04llx -> %#04llx\n",
 			block, sbi->s_itb_per_group);
 	err = sb_issue_zeroout(sb, gdblocks + start + 1, reserved_gdb,
-			       GFP_NOFS, BLKDEV_IFL_WAIT);
+			       GFP_NOFS);
 	if (err)
 		goto exit_bh;
 
@@ -244,8 +244,7 @@ static int setup_new_group_blocks(struct super_block *sb,
 	block = input->inode_table;
 	ext4_debug("clear inode table blocks %#04llx -> %#04llx\n",
 			block, sbi->s_itb_per_group);
-	err = sb_issue_zeroout(sb, block, sbi->s_itb_per_group,
-			       GFP_NOFS, BLKDEV_IFL_WAIT);
+	err = sb_issue_zeroout(sb, block, sbi->s_itb_per_group, GFP_NOFS);
 	if (err)
 		goto exit_bh;
 
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index a1dec60..1095272 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -892,12 +892,12 @@ static inline int sb_issue_discard(struct super_block *sb, sector_t block,
 				    gfp_mask, flags);
 }
 static inline int sb_issue_zeroout(struct super_block *sb, sector_t block,
-		sector_t nr_blocks, gfp_t gfp_mask, unsigned long flags)
+		sector_t nr_blocks, gfp_t gfp_mask)
 {
 	return blkdev_issue_zeroout(sb->s_bdev,
 				    block << (sb->s_blocksize_bits - 9),
 				    nr_blocks << (sb->s_blocksize_bits - 9),
-				    gfp_mask, flags);
+				    gfp_mask);
 }
 
 extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
-- 
1.7.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-09-17  1:37 Stephen Rothwell
@ 2010-09-17  3:19 ` Christoph Hellwig
  0 siblings, 0 replies; 176+ messages in thread
From: Christoph Hellwig @ 2010-09-17  3:19 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, linux-next, linux-kernel, Christoph Hellwig, Jan Kara

On Fri, Sep 17, 2010 at 11:37:38AM +1000, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/ocfs2/file.c: In function 'ocfs2_sync_file':
> fs/ocfs2/file.c:191: error: 'BLKDEV_IFL_WAIT' undeclared (first use in this function)
> fs/ocfs2/file.c:191: error: too many arguments to function 'blkdev_issue_flush'
> 
> Caused by commit dd3932eddf428571762596e17b65f5dc92ca361b ("block: remove
> BLKDEV_IFL_WAIT") interacting with commit
> 04eda1a18019bb387dc7e97ee99979dd88dc608a ("ocfs2: Flush drive's caches on
> fdatasync") that entered Linus' tree before v2.6.36-rc4.


Justremove the last argument for blkdev_issue_flush and it'll be fine.
Unfortunately Jens' for-next branch which I based the patch again
doesn't include the ocfs2 commit yet.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-09-17  1:37 Stephen Rothwell
  2010-09-17  3:19 ` Christoph Hellwig
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-09-17  1:37 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Christoph Hellwig, Jan Kara

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

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/ocfs2/file.c: In function 'ocfs2_sync_file':
fs/ocfs2/file.c:191: error: 'BLKDEV_IFL_WAIT' undeclared (first use in this function)
fs/ocfs2/file.c:191: error: too many arguments to function 'blkdev_issue_flush'

Caused by commit dd3932eddf428571762596e17b65f5dc92ca361b ("block: remove
BLKDEV_IFL_WAIT") interacting with commit
04eda1a18019bb387dc7e97ee99979dd88dc608a ("ocfs2: Flush drive's caches on
fdatasync") that entered Linus' tree before v2.6.36-rc4.

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-08-09  1:28 Stephen Rothwell
@ 2010-08-09  1:50 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2010-08-09  1:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Daniel Stodden, Jeremy Fitzhardinge

On 08/08/2010 09:28 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/block/xen-blkfront.c: In function 'blkif_release':
> drivers/block/xen-blkfront.c:1238: error: label 'out' used but not defined
> 
> Caused by commit acfca3c622a009fb62b566604452ab9fb3a11019 ("blkfront:
> Remove obsolete info->users").  I assume something went wrong in the
> rebase ...
> 
> I have used the block tree from next-20100807 for today.

Oops, fixed up.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-08-09  1:28 Stephen Rothwell
  2010-08-09  1:50 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-08-09  1:28 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Daniel Stodden, Jeremy Fitzhardinge

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/block/xen-blkfront.c: In function 'blkif_release':
drivers/block/xen-blkfront.c:1238: error: label 'out' used but not defined

Caused by commit acfca3c622a009fb62b566604452ab9fb3a11019 ("blkfront:
Remove obsolete info->users").  I assume something went wrong in the
rebase ...

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-08-05  1:47 Stephen Rothwell
@ 2010-08-05  6:35 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2010-08-05  6:35 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Tejun Heo

On 2010-08-05 03:47, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> usr/include/linux/fs.h:11: included file 'linux/blk_types.h' is not exported
> 
> Caused by commit 9d3dbbcd9a84518ff5e32ffe671d06a48cf84fd9 ("bio, fs:
> separate out bio_types.h and define READ/WRITE constants in terms of
> BIO_RW_* flags").
> 
> I used the block tree from next-20100804 for today.

Thanks Stephen, I fixed this one up now and pushed it out.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-08-05  1:47 Stephen Rothwell
  2010-08-05  6:35 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-08-05  1:47 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Tejun Heo

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

usr/include/linux/fs.h:11: included file 'linux/blk_types.h' is not exported

Caused by commit 9d3dbbcd9a84518ff5e32ffe671d06a48cf84fd9 ("bio, fs:
separate out bio_types.h and define READ/WRITE constants in terms of
BIO_RW_* flags").

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-08-03  3:12 Stephen Rothwell
  2010-08-03  7:46 ` Jens Axboe
@ 2010-08-03  8:26 ` Christoph Hellwig
  1 sibling, 0 replies; 176+ messages in thread
From: Christoph Hellwig @ 2010-08-03  8:26 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, linux-next, linux-kernel, Christoph Hellwig,
	Yehuda Sadeh, Sage Weil

On Tue, Aug 03, 2010 at 01:12:02PM +1000, Stephen Rothwell wrote:
> I applied the following merge fix patch (Christoph, I assume that this
> should be directly applicable to the ceph tree, right?):

Yes, it looks good.

> -		if (!blk_fs_request(rq) && !blk_barrier_rq(rq)) {
> +		if ((rq->cmd_type != REQ_TYPE_FS) &&
> +		    !(rq->cmd_flags & REQ_HARDBARRIER)) {
>  			__blk_end_request_all(rq, 0);
>  			goto next;

Although these days barriers are REQ_TYPE_FS anyway, so the second check
is superflous.

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-08-03  3:12 Stephen Rothwell
@ 2010-08-03  7:46 ` Jens Axboe
  2010-08-03  8:26 ` Christoph Hellwig
  1 sibling, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2010-08-03  7:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Christoph Hellwig, Yehuda Sadeh, Sage Weil

On 2010-08-03 05:12, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> fs/ceph/rbd.c: In function 'rbd_rq_fn':
> fs/ceph/rbd.c:1101: error: implicit declaration of function 'blk_fs_request'
> fs/ceph/rbd.c:1101: error: implicit declaration of function 'blk_barrier_rq'
> 
> Caused by commit fc734ac98dbce1e3d3e1e1359524c279a336ac49 ("block: remove
> wrappers for request type/flags") interacting with commit
> e7fdb915217126d23ff2aafb2d5fdce21b763df1 ("ceph-rbd: rados block device")
> from the ceph tree.
> 
> I applied the following merge fix patch (Christoph, I assume that this
> should be directly applicable to the ceph tree, right?):

Yep, that'll work and should be applicable to ceph even when run outside
of the block tree merge.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-08-03  3:12 Stephen Rothwell
  2010-08-03  7:46 ` Jens Axboe
  2010-08-03  8:26 ` Christoph Hellwig
  0 siblings, 2 replies; 176+ messages in thread
From: Stephen Rothwell @ 2010-08-03  3:12 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Christoph Hellwig, Yehuda Sadeh, Sage Weil

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/ceph/rbd.c: In function 'rbd_rq_fn':
fs/ceph/rbd.c:1101: error: implicit declaration of function 'blk_fs_request'
fs/ceph/rbd.c:1101: error: implicit declaration of function 'blk_barrier_rq'

Caused by commit fc734ac98dbce1e3d3e1e1359524c279a336ac49 ("block: remove
wrappers for request type/flags") interacting with commit
e7fdb915217126d23ff2aafb2d5fdce21b763df1 ("ceph-rbd: rados block device")
from the ceph tree.

I applied the following merge fix patch (Christoph, I assume that this
should be directly applicable to the ceph tree, right?):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 3 Aug 2010 13:08:18 +1000
Subject: [PATCH] ceph: update for removal of request flag wrappers

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

diff --git a/fs/ceph/rbd.c b/fs/ceph/rbd.c
index 86c8b06..1fa2634 100644
--- a/fs/ceph/rbd.c
+++ b/fs/ceph/rbd.c
@@ -1098,7 +1098,8 @@ static void rbd_rq_fn(struct request_queue *q)
 		dout("fetched request\n");
 
 		/* filter out block requests we don't understand */
-		if (!blk_fs_request(rq) && !blk_barrier_rq(rq)) {
+		if ((rq->cmd_type != REQ_TYPE_FS) &&
+		    !(rq->cmd_flags & REQ_HARDBARRIER)) {
 			__blk_end_request_all(rq, 0);
 			goto next;
 		}
-- 
1.7.1

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-05-18 10:20   ` Stephen Rothwell
@ 2010-05-18 10:50     ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2010-05-18 10:50 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Andrew Morton

On Tue, May 18 2010, Stephen Rothwell wrote:
> On Tue, 18 May 2010 10:56:13 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> >
> > Thanks, it looks like a merge/commit error on for-next alone, for-2.6.35
> > is fine. I'll make sure this gets fixed up now.
> 
> So why is for-2.6.35 different from for-next?

Because I had a for-linus branch at one point which was headed for
2.6.34 (which has been merged now) which was changed and merged with
for-2.6.35 to form for-next. But now it should just be a copy.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-05-18  8:56 ` Jens Axboe
@ 2010-05-18 10:20   ` Stephen Rothwell
  2010-05-18 10:50     ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-05-18 10:20 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Andrew Morton

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

On Tue, 18 May 2010 10:56:13 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> Thanks, it looks like a merge/commit error on for-next alone, for-2.6.35
> is fine. I'll make sure this gets fixed up now.

So why is for-2.6.35 different from for-next?

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

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-05-18  3:37 Stephen Rothwell
@ 2010-05-18  8:56 ` Jens Axboe
  2010-05-18 10:20   ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Jens Axboe @ 2010-05-18  8:56 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Andrew Morton

On Tue, May 18 2010, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> block/blk-core.c: In function 'laptop_mode_timer_fn':
> block/blk-core.c:503: error: too few arguments to function 'bdi_start_writeback'
> 
> Caused by commit e913fc825dc685a444cb4c1d0f9d32f372f59861 ("writeback:
> fix WB_SYNC_NONE writeback from umount") from the block tree interacting
> with commit 42bd225c0ba7c95af39293d39a950c48e7e5cb23 (""laptop-mode: Make
> flushes per-device" fix") also from the block tree.  The merge
> 6205ed4658a0df8c2879519977bbed6853014016 should have changed the code in
> block/blk-core.c that moved from mm/page-writeback.c.
> 
> Mind you, I think that the change to laptop_mode_timer_fn in commit
> e913fc825dc685a444cb4c1d0f9d32f372f59861 was wrong anyway (the 0 should
> have been added at the end, surely).
> 
> I have used the block tree from next-20100517 for today.

Thanks, it looks like a merge/commit error on for-next alone, for-2.6.35
is fine. I'll make sure this gets fixed up now.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-05-18  3:37 Stephen Rothwell
  2010-05-18  8:56 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-05-18  3:37 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Andrew Morton

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

Hi Jens,

After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

block/blk-core.c: In function 'laptop_mode_timer_fn':
block/blk-core.c:503: error: too few arguments to function 'bdi_start_writeback'

Caused by commit e913fc825dc685a444cb4c1d0f9d32f372f59861 ("writeback:
fix WB_SYNC_NONE writeback from umount") from the block tree interacting
with commit 42bd225c0ba7c95af39293d39a950c48e7e5cb23 (""laptop-mode: Make
flushes per-device" fix") also from the block tree.  The merge
6205ed4658a0df8c2879519977bbed6853014016 should have changed the code in
block/blk-core.c that moved from mm/page-writeback.c.

Mind you, I think that the change to laptop_mode_timer_fn in commit
e913fc825dc685a444cb4c1d0f9d32f372f59861 was wrong anyway (the 0 should
have been added at the end, surely).

I have used the block tree from next-20100517 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 --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-04-29  3:52 Stephen Rothwell
@ 2010-04-29  7:31 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2010-04-29  7:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Dmitry Monakhov, Jiro SEKIBA, Ryusuke Konishi

On Thu, Apr 29 2010, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (powerpc ppc64_defconfig)
> failed like this:
> 
> fs/nilfs2/the_nilfs.c: In function 'nilfs_discard_segments':
> fs/nilfs2/the_nilfs.c:673: error: 'DISCARD_FL_BARRIER' undeclared (first use in this function)
> 
> Caused by commit fbd9b09a177a481eda256447c881f014f29034fe ("blkdev:
> generalize flags for blkdev_issue_fn functions") interacting with commit
> e902ec9906e844f4613fa6190c6fa65f162dc86e ("nilfs2: issue discard request
> after cleaning segments") (which netered Linus' tree on about March 4 -
> before v2.6.34-rc1).
> 
> I applied the following patch for today (but have no way to test it).

It's correct, I'll merge this.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-04-29  3:52 Stephen Rothwell
  2010-04-29  7:31 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-04-29  3:52 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, linux-kernel, Dmitry Monakhov, Jiro SEKIBA, Ryusuke Konishi

Hi Jens,

After merging the block tree, today's linux-next build (powerpc ppc64_defconfig)
failed like this:

fs/nilfs2/the_nilfs.c: In function 'nilfs_discard_segments':
fs/nilfs2/the_nilfs.c:673: error: 'DISCARD_FL_BARRIER' undeclared (first use in this function)

Caused by commit fbd9b09a177a481eda256447c881f014f29034fe ("blkdev:
generalize flags for blkdev_issue_fn functions") interacting with commit
e902ec9906e844f4613fa6190c6fa65f162dc86e ("nilfs2: issue discard request
after cleaning segments") (which netered Linus' tree on about March 4 -
before v2.6.34-rc1).

I applied the following patch for today (but have no way to test it).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 29 Apr 2010 13:35:14 +1000
Subject: [PATCH] nilfs: fix for block layer API change

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

diff --git a/fs/nilfs2/the_nilfs.c b/fs/nilfs2/the_nilfs.c
index 33871f7..7081588 100644
--- a/fs/nilfs2/the_nilfs.c
+++ b/fs/nilfs2/the_nilfs.c
@@ -670,7 +670,7 @@ int nilfs_discard_segments(struct the_nilfs *nilfs, __u64 *segnump,
 						   start * sects_per_block,
 						   nblocks * sects_per_block,
 						   GFP_NOFS,
-						   DISCARD_FL_BARRIER);
+						   BLKDEV_IFL_BARRIER);
 			if (ret < 0)
 				return ret;
 			nblocks = 0;
@@ -680,7 +680,7 @@ int nilfs_discard_segments(struct the_nilfs *nilfs, __u64 *segnump,
 		ret = blkdev_issue_discard(nilfs->ns_bdev,
 					   start * sects_per_block,
 					   nblocks * sects_per_block,
-					   GFP_NOFS, DISCARD_FL_BARRIER);
+					   GFP_NOFS, BLKDEV_IFL_BARRIER);
 	return ret;
 }
 
-- 
1.7.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-04-28  3:52 Stephen Rothwell
@ 2010-04-28  5:34 ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2010-04-28  5:34 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

On Wed, Apr 28 2010, Stephen Rothwell wrote:
> Hi Jens,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> include/linux/coda_psdev.h:4: included file 'linux/backing-dev.h' is not exported
> 
> Caused by commit 5163d90076729413cb882d3dd5c3d3cfb5b9f035 ("coda: add bdi
> backing to mount session").
> 
> I have used the version of the block tree from next-20100427 for today.

Thanks Stephen, I'll fix it up.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-04-28  3:52 Stephen Rothwell
  2010-04-28  5:34 ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-04-28  3:52 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

include/linux/coda_psdev.h:4: included file 'linux/backing-dev.h' is not exported

Caused by commit 5163d90076729413cb882d3dd5c3d3cfb5b9f035 ("coda: add bdi
backing to mount session").

I have used the version of the block tree from next-20100427 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 --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-04-15  6:16   ` Stephen Rothwell
@ 2010-04-15  6:56     ` Jens Axboe
  0 siblings, 0 replies; 176+ messages in thread
From: Jens Axboe @ 2010-04-15  6:56 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Divyesh Shah, linux-next, linux-kernel, Gui Jianfeng

On Thu, Apr 15 2010, Stephen Rothwell wrote:
> Hi Divyesh,
> 
> On Wed, 14 Apr 2010 22:23:25 -0700 Divyesh Shah <dpshah@google.com> wrote:
> >
> >      These errors seem to show up because the 2 symbols aren't
> > exported and hence when building as a module we don't have access to
> > these symbols. I'll send a patch to fix that shortly. Sorry for the
> > build breakage.
> 
> Thanks.

for-next is now updated.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-04-15  5:23 ` Divyesh Shah
@ 2010-04-15  6:16   ` Stephen Rothwell
  2010-04-15  6:56     ` Jens Axboe
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-04-15  6:16 UTC (permalink / raw)
  To: Divyesh Shah; +Cc: Jens Axboe, linux-next, linux-kernel, Gui Jianfeng

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

Hi Divyesh,

On Wed, 14 Apr 2010 22:23:25 -0700 Divyesh Shah <dpshah@google.com> wrote:
>
>      These errors seem to show up because the 2 symbols aren't
> exported and hence when building as a module we don't have access to
> these symbols. I'll send a patch to fix that shortly. Sorry for the
> build breakage.

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

^ permalink raw reply	[flat|nested] 176+ messages in thread

* Re: linux-next: build failure after merge of the block tree
  2010-04-15  2:42 Stephen Rothwell
@ 2010-04-15  5:23 ` Divyesh Shah
  2010-04-15  6:16   ` Stephen Rothwell
  0 siblings, 1 reply; 176+ messages in thread
From: Divyesh Shah @ 2010-04-15  5:23 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Jens Axboe, linux-next, linux-kernel, Gui Jianfeng

On Wed, Apr 14, 2010 at 7:42 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "get_gendisk" [block/blk-cgroup.ko] undefined!
> ERROR: "sched_clock" [block/blk-cgroup.ko] undefined!

Hi Stephen,
     These errors seem to show up because the 2 symbols aren't
exported and hence when building as a module we don't have access to
these symbols. I'll send a patch to fix that shortly. Sorry for the
build breakage.

-Divyesh

>
> Probably caused by commits 34d0f179d6dd711d3fc13c0820a456c59aae8048
> ("io-controller: Add a new interface "weight_device" for IO-Controller"),
> 9195291e5f05e01d67f9a09c756b8aca8f009089 ("blkio: Increment the blkio
> cgroup stats for real now") and 812df48d127365ffd0869aa139738f572a86759c
> ("blkio: Add more debug-only per-cgroup stats").
>
> I have used the version of the block tree from next-20100414 for today.
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-04-15  2:42 Stephen Rothwell
  2010-04-15  5:23 ` Divyesh Shah
  0 siblings, 1 reply; 176+ messages in thread
From: Stephen Rothwell @ 2010-04-15  2:42 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Gui Jianfeng, Divyesh Shah

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "get_gendisk" [block/blk-cgroup.ko] undefined!
ERROR: "sched_clock" [block/blk-cgroup.ko] undefined!

Probably caused by commits 34d0f179d6dd711d3fc13c0820a456c59aae8048
("io-controller: Add a new interface "weight_device" for IO-Controller"),
9195291e5f05e01d67f9a09c756b8aca8f009089 ("blkio: Increment the blkio
cgroup stats for real now") and 812df48d127365ffd0869aa139738f572a86759c
("blkio: Add more debug-only per-cgroup stats").

I have used the version of the block tree from next-20100414 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 --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

* linux-next: build failure after merge of the block tree
@ 2010-02-23  2:26 Stephen Rothwell
  0 siblings, 0 replies; 176+ messages in thread
From: Stephen Rothwell @ 2010-02-23  2:26 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, dann frazier

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

Hi Jens,

After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:

usr/include/linux/cciss_ioctl.h:6: included file 'linux/cciss_defs.h' is not exported

Caused by commit 429c42c9d246f5bda868495c09974312a0177328 ("cciss:
Consolidate duplicate bits in cciss_cmd.h & cciss_ioctl.h").

I have used the block tree from next-20100222 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 --]

^ permalink raw reply	[flat|nested] 176+ messages in thread

end of thread, back to index

Thread overview: 176+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-28  2:59 linux-next: build failure after merge of the block tree Stephen Rothwell
2019-10-28  3:25 ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2019-07-11  5:15 Stephen Rothwell
2019-07-11 20:17 ` Tejun Heo
2019-07-11 20:36   ` Jens Axboe
2019-07-11  5:04 Stephen Rothwell
2019-06-21  3:56 Stephen Rothwell
2019-06-21  8:18 ` Christoph Hellwig
2019-06-21  8:36   ` Stephen Rothwell
2019-05-06  5:07 Stephen Rothwell
2019-01-16  2:55 Stephen Rothwell
2019-01-16  2:48 Stephen Rothwell
2019-01-16  2:50 ` Ming Lei
2019-01-16  2:35 Stephen Rothwell
2019-01-16  2:48 ` Ming Lei
2018-07-31  3:07 Stephen Rothwell
2018-07-31 14:59 ` Jens Axboe
2018-07-26  4:56 Stephen Rothwell
2018-07-26  8:48 ` Christoph Hellwig
2018-07-26  8:45   ` Stephen Rothwell
2018-07-26 17:48   ` Jens Axboe
2018-07-26 17:56     ` Christoph Hellwig
2018-07-26 17:59       ` Steve Wise
2018-07-26 20:54     ` Bart Van Assche
2018-07-26 21:13       ` Jens Axboe
2018-07-26 12:32 ` Steve Wise
2018-07-26 22:16   ` Stephen Rothwell
2018-08-15  1:43 ` Stephen Rothwell
2017-08-24  3:32 Stephen Rothwell
2017-08-24  3:34 ` Stephen Rothwell
2017-08-24  8:44   ` Christoph Hellwig
2017-08-24  8:54     ` Stephen Rothwell
2017-06-28  8:04 Stephen Rothwell
2017-06-28 12:43 ` Jens Axboe
2017-06-28 14:01   ` Jens Axboe
2017-06-28 15:11     ` Jens Axboe
2017-06-28 21:33       ` Stephen Rothwell
2017-06-13 10:54 Stephen Rothwell
2017-06-15 14:50 ` Sebastian Ott
2017-06-19  9:00   ` Sebastian Ott
2017-06-20  1:45     ` Stephen Rothwell
2017-07-04 15:15 ` Guenter Roeck
2017-07-04 21:40   ` Stephen Rothwell
2017-06-13  4:10 Stephen Rothwell
2017-04-18  3:02 Stephen Rothwell
2017-05-02  1:07 ` Stephen Rothwell
2017-05-02  1:09   ` Jens Axboe
2017-05-02  1:37     ` Stephen Rothwell
2017-05-02  1:45       ` Jens Axboe
2017-01-30  1:43 Stephen Rothwell
2017-01-30  1:53 ` Jens Axboe
2017-01-30  3:07   ` Jens Axboe
2017-01-30  6:34   ` Christoph Hellwig
2016-12-01  2:55 Stephen Rothwell
2016-12-01  3:00 ` Jens Axboe
2016-12-01  3:02   ` Stephen Rothwell
2016-12-01  3:04     ` Jens Axboe
2016-11-08  3:21 Stephen Rothwell
2016-11-08  3:28 ` Jens Axboe
2016-09-19  6:18 Stephen Rothwell
2016-09-19 13:48 ` Christoph Hellwig
2016-09-19 14:22 ` Jens Axboe
2016-09-16  1:14 Stephen Rothwell
2016-09-16  4:13 ` Jens Axboe
2016-04-26  3:38 Stephen Rothwell
2016-04-26 13:30 ` Michal Marek
2016-04-26 13:56   ` Stephen Rothwell
     [not found]   ` <v3THaCMkCzylcv3TJavAje@videotron.ca>
2016-04-26 14:40     ` Nicolas Pitre
2016-04-26 14:41       ` Jens Axboe
2016-04-26 15:18       ` Stephen Rothwell
2016-04-26 20:48         ` Nicolas Pitre
2016-04-26 21:39           ` Stephen Rothwell
2016-04-27  9:02           ` Michal Marek
2016-04-27 13:46             ` Nicolas Pitre
2016-03-07  3:29 Stephen Rothwell
2015-12-02 16:19 Mark Brown
2015-12-02 16:45 ` Christoph Hellwig
2015-12-02 21:07   ` Jens Axboe
2015-12-02 21:14     ` Keith Busch
2015-12-02 21:27       ` Jens Axboe
2015-12-03  7:35         ` Christoph Hellwig
2015-12-03  8:39     ` Matias Bjørling
2015-12-03  9:06       ` Christoph Hellwig
2015-12-03  9:52         ` Matias Bjørling
2015-12-03  9:57           ` Christoph Hellwig
2015-12-03 10:09             ` Matias Bjørling
2015-12-03 10:21               ` Christoph Hellwig
2015-12-03 11:07                 ` Matias Bjørling
2015-12-03 16:42                   ` Christoph Hellwig
2015-12-04 12:16                     ` Matias Bjørling
2015-10-06  1:43 Stephen Rothwell
2015-10-06  1:54 ` kbuild test robot
2015-10-06  7:20 ` Ming Lei
2015-07-30  4:17 Stephen Rothwell
2015-07-30  6:19 ` Christoph Hellwig
2015-07-30 12:24   ` Stephen Rothwell
2015-07-30 14:38 ` Drokin, Oleg
2015-02-09  4:25 Stephen Rothwell
2015-01-21  3:45 Stephen Rothwell
2014-11-17  3:44 Stephen Rothwell
2014-11-17 19:51 ` Jens Axboe
2014-11-11  2:12 Stephen Rothwell
2014-11-11 11:20 ` Fabian Frederick
2014-11-11 15:27   ` Jens Axboe
2014-11-14 16:19     ` Fabian Frederick
2013-11-26  2:30 Stephen Rothwell
2013-11-04  3:13 Stephen Rothwell
2013-11-04  3:23 ` Jens Axboe
2013-11-04  3:32   ` Jens Axboe
2013-11-04  3:39   ` Stephen Rothwell
2013-11-01  4:01 Stephen Rothwell
2013-02-06  3:06 Stephen Rothwell
2013-02-06  8:33 ` Jens Axboe
2012-10-10  1:14 Stephen Rothwell
2012-09-27  3:27 Stephen Rothwell
2012-09-27  7:37 ` Jens Axboe
2011-12-19  3:19 Stephen Rothwell
2011-12-19  9:37 ` Jens Axboe
2011-12-19 16:41   ` Tejun Heo
2011-12-19  9:45 ` Sedat Dilek
2011-12-19  9:48   ` Jens Axboe
2011-12-19 11:32     ` Stephen Rothwell
2011-12-16  1:50 Stephen Rothwell
2011-12-16  8:20 ` Jens Axboe
2011-09-17 11:18 Stephen Rothwell
2011-07-04  3:48 Stephen Rothwell
2011-06-01  1:01 Stephen Rothwell
2011-06-01  6:26 ` Jens Axboe
2011-06-01 13:43   ` Konrad Rzeszutek Wilk
2011-03-25  3:30 Stephen Rothwell
2011-03-25  4:08 ` Akinobu Mita
2011-03-25  5:25   ` Stephen Rothwell
2011-03-14  5:19 Stephen Rothwell
2011-03-16 23:32 ` Stephen Rothwell
2011-03-17 10:18   ` Jens Axboe
2011-03-17 10:36     ` David Woodhouse
2011-03-17 10:45       ` Jens Axboe
2011-03-21 23:33         ` Stephen Rothwell
2011-03-10  3:08 Stephen Rothwell
2011-03-10  7:15 ` Jens Axboe
2011-03-07  2:39 Stephen Rothwell
2011-01-07  0:05 Stephen Rothwell
2011-01-07  7:32 ` Jens Axboe
2011-01-07 10:52   ` Sedat Dilek
2011-01-07 12:17     ` Stephen Rothwell
2011-01-07 13:19       ` Sedat Dilek
2011-01-07 14:22         ` Stephen Rothwell
2011-01-07 15:08           ` Jens Axboe
2011-01-07 18:04             ` Sedat Dilek
2011-01-07 18:20               ` Sedat Dilek
2010-12-23  1:53 Stephen Rothwell
2010-12-23 22:36 ` Nicholas A. Bellinger
2010-10-11  3:18 Stephen Rothwell
2010-10-23  2:51 ` Stephen Rothwell
2010-09-17  1:37 Stephen Rothwell
2010-09-17  3:19 ` Christoph Hellwig
2010-08-09  1:28 Stephen Rothwell
2010-08-09  1:50 ` Jens Axboe
2010-08-05  1:47 Stephen Rothwell
2010-08-05  6:35 ` Jens Axboe
2010-08-03  3:12 Stephen Rothwell
2010-08-03  7:46 ` Jens Axboe
2010-08-03  8:26 ` Christoph Hellwig
2010-05-18  3:37 Stephen Rothwell
2010-05-18  8:56 ` Jens Axboe
2010-05-18 10:20   ` Stephen Rothwell
2010-05-18 10:50     ` Jens Axboe
2010-04-29  3:52 Stephen Rothwell
2010-04-29  7:31 ` Jens Axboe
2010-04-28  3:52 Stephen Rothwell
2010-04-28  5:34 ` Jens Axboe
2010-04-15  2:42 Stephen Rothwell
2010-04-15  5:23 ` Divyesh Shah
2010-04-15  6:16   ` Stephen Rothwell
2010-04-15  6:56     ` Jens Axboe
2010-02-23  2:26 Stephen Rothwell

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git