Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 2/22/21 6:42 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/io_uring.c: In function 'io_sq_thread':
> fs/io_uring.c:6787:3: error: implicit declaration of function 
> 'io_ctx_disable_sqo_submit' [-Werror=implicit-function-declaration]
>  6787 |   io_ctx_disable_sqo_submit(ctx);
>   |   ^
> 
> Caused by commit
> 
>   a6afa091d06a ("io_uring: move SQPOLL thread io-wq forked worker")
> 
> I have used the block tree from next-20210222 for today.

You got very unlucky, that bad commit only lasted for about 1-2 min.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Tue, 2 Feb 2021 14:16:18 +1100 Stephen Rothwell  
wrote:
>
> On Tue, 2 Feb 2021 13:57:14 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the block tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > block/bio.c: In function 'bio_add_zone_append_page':
> > block/bio.c:860:31: error: 'struct bio' has no member named 'bi_disk'
> >   860 |  struct request_queue *q = bio->bi_disk->queue;
> >   |   ^~
> > 
> > Caused by commit
> > 
> >   309dca309fc3 ("block: store a block_device pointer in struct bio")
> > 
> > interacting with commit
> > 
> >   9f678097f3de ("block: add bio_add_zone_append_page")

Now

  ae29333fa644 ("block: add bio_add_zone_append_page")

> > 
> > from the btrfs tree.
> > 
> > I applied the following merge fix up for today.
> > 
> > From: Stephen Rothwell 
> > Date: Tue, 2 Feb 2021 13:54:29 +1100
> > Subject: [PATCH] block: bio: fix up for bi_disk removal
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  block/bio.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/block/bio.c b/block/bio.c
> > index bf3ab1b5c844..e3b9d3e0a196 100644
> > --- a/block/bio.c
> > +++ b/block/bio.c
> > @@ -857,7 +857,7 @@ EXPORT_SYMBOL(bio_add_pc_page);
> >  int bio_add_zone_append_page(struct bio *bio, struct page *page,
> >  unsigned int len, unsigned int offset)
> >  {
> > -   struct request_queue *q = bio->bi_disk->queue;
> > +   struct request_queue *q = bio->bi_bdev->bd_disk->queue;
> > bool same_page = false;
> >  
> > if (WARN_ON_ONCE(bio_op(bio) != REQ_OP_ZONE_APPEND))
> > -- 
> > 2.29.2  
> 
> This then lead to the following in my x86_64 allmodconfig build:
> 
> fs/btrfs/zoned.c: In function 'btrfs_record_physical_zoned':
> fs/btrfs/zoned.c:1286:21: error: 'struct bio' has no member named 'bi_disk'
>  1286 |  ordered->disk = bio->bi_disk;
>   | ^~
> fs/btrfs/zoned.c:1287:23: error: 'struct bio' has no member named 'bi_partno'
>  1287 |  ordered->partno = bio->bi_partno;
>   |   ^~
> 
> Do to the above block tree commit interacting with commit
> 
>   bccc13e5fe0c ("btrfs: use ZONE_APPEND write for ZONED btrfs")

Now

  d8e3fb106f39 ("btrfs: zoned: use ZONE_APPEND write for zoned mode")

> 
> from the btrfs tree.
> 
> For which I applied the following merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Tue, 2 Feb 2021 14:08:44 +1100
> Subject: [PATCH] block: btrfs: another fix up for bi_disk removal
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/btrfs/zoned.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
> index 334a54be587d..4829ffc5275b 100644
> --- a/fs/btrfs/zoned.c
> +++ b/fs/btrfs/zoned.c
> @@ -1283,8 +1283,8 @@ void btrfs_record_physical_zoned(struct inode *inode, 
> u64 file_offset,
>   return;
>  
>   ordered->physical = physical;
> - ordered->disk = bio->bi_disk;
> - ordered->partno = bio->bi_partno;
> + ordered->disk = bio->bi_bdev->bd_disk;
> + ordered->partno = bio->bi_bdev->bd_partno;
>  
>   btrfs_put_ordered_extent(ordered);
>  }
> -- 
> 2.29.2

With the merge window about to open, this is a reminder that this
conflict still exists.

I am still applying both these merge fix ups.

-- 
Cheers,
Stephen Rothwell


pgpbITJjgFGak.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Christoph Hellwig]

Both fixups look good to me, thanks.

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Tue, 2 Feb 2021 13:57:14 +1100 Stephen Rothwell  
wrote:
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> block/bio.c: In function 'bio_add_zone_append_page':
> block/bio.c:860:31: error: 'struct bio' has no member named 'bi_disk'
>   860 |  struct request_queue *q = bio->bi_disk->queue;
>   |   ^~
> 
> Caused by commit
> 
>   309dca309fc3 ("block: store a block_device pointer in struct bio")
> 
> interacting with commit
> 
>   9f678097f3de ("block: add bio_add_zone_append_page")
> 
> from the btrfs tree.
> 
> I applied the following merge fix up for today.
> 
> From: Stephen Rothwell 
> Date: Tue, 2 Feb 2021 13:54:29 +1100
> Subject: [PATCH] block: bio: fix up for bi_disk removal
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  block/bio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/block/bio.c b/block/bio.c
> index bf3ab1b5c844..e3b9d3e0a196 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -857,7 +857,7 @@ EXPORT_SYMBOL(bio_add_pc_page);
>  int bio_add_zone_append_page(struct bio *bio, struct page *page,
>unsigned int len, unsigned int offset)
>  {
> - struct request_queue *q = bio->bi_disk->queue;
> + struct request_queue *q = bio->bi_bdev->bd_disk->queue;
>   bool same_page = false;
>  
>   if (WARN_ON_ONCE(bio_op(bio) != REQ_OP_ZONE_APPEND))
> -- 
> 2.29.2

This then lead to the following in my x86_64 allmodconfig build:

fs/btrfs/zoned.c: In function 'btrfs_record_physical_zoned':
fs/btrfs/zoned.c:1286:21: error: 'struct bio' has no member named 'bi_disk'
 1286 |  ordered->disk = bio->bi_disk;
  | ^~
fs/btrfs/zoned.c:1287:23: error: 'struct bio' has no member named 'bi_partno'
 1287 |  ordered->partno = bio->bi_partno;
  |   ^~

Do to the above block tree commit interacting with commit

  bccc13e5fe0c ("btrfs: use ZONE_APPEND write for ZONED btrfs")

from the btrfs tree.

For which I applied the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 2 Feb 2021 14:08:44 +1100
Subject: [PATCH] block: btrfs: another fix up for bi_disk removal

Signed-off-by: Stephen Rothwell 
---
 fs/btrfs/zoned.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
index 334a54be587d..4829ffc5275b 100644
--- a/fs/btrfs/zoned.c
+++ b/fs/btrfs/zoned.c
@@ -1283,8 +1283,8 @@ void btrfs_record_physical_zoned(struct inode *inode, u64 
file_offset,
return;
 
ordered->physical = physical;
-   ordered->disk = bio->bi_disk;
-   ordered->partno = bio->bi_partno;
+   ordered->disk = bio->bi_bdev->bd_disk;
+   ordered->partno = bio->bi_bdev->bd_partno;
 
btrfs_put_ordered_extent(ordered);
 }
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell


pgp5okwMSKyUZ.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi David,

On Mon, 14 Dec 2020 22:54:46 +0100 David Sterba  wrote:
>
> On Tue, Dec 15, 2020 at 08:43:00AM +1100, Stephen Rothwell wrote:
> > 
> > On Mon, 14 Dec 2020 22:36:12 +0100 David Sterba  wrote:  
> > >
> > > On Mon, Dec 14, 2020 at 01:12:46PM -0700, Jens Axboe wrote:  
> > > > On 12/14/20 1:09 PM, Stephen Rothwell wrote:
> > > > > Just a reminder that I am still applying the above merge fix.
> > > > 
> > > > I sent in my core changes, but they haven't been pulled yet. So I guess
> > > > we're dealing with a timing situation... David, did you send in the 
> > > > btrfs
> > > > pull yet?
> > > 
> > > Yes
> > > https://lore.kernel.org/lkml/cover.1607955523.git.dste...@suse.com/  
> > 
> > I would expect you *both* to at least mention this conflict to Linus ...  
> 
> 2nd paragraph in the mail
> 
> "There are no merge conflicts against current master branch, in past
>  weeks some conflicts emerged in linux-next but IIRC were trivial."

No worries then, thanks.

-- 
Cheers,
Stephen Rothwell


pgpB0LzklpMg3.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[David Sterba]

On Tue, Dec 15, 2020 at 08:43:00AM +1100, Stephen Rothwell wrote:
> Hi David,
> 
> On Mon, 14 Dec 2020 22:36:12 +0100 David Sterba  wrote:
> >
> > On Mon, Dec 14, 2020 at 01:12:46PM -0700, Jens Axboe wrote:
> > > On 12/14/20 1:09 PM, Stephen Rothwell wrote:  
> > > > Just a reminder that I am still applying the above merge fix.  
> > > 
> > > I sent in my core changes, but they haven't been pulled yet. So I guess
> > > we're dealing with a timing situation... David, did you send in the btrfs
> > > pull yet?  
> > 
> > Yes
> > https://lore.kernel.org/lkml/cover.1607955523.git.dste...@suse.com/
> 
> I would expect you *both* to at least mention this conflict to Linus ...

2nd paragraph in the mail

"There are no merge conflicts against current master branch, in past
 weeks some conflicts emerged in linux-next but IIRC were trivial."

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi David,

On Mon, 14 Dec 2020 22:36:12 +0100 David Sterba  wrote:
>
> On Mon, Dec 14, 2020 at 01:12:46PM -0700, Jens Axboe wrote:
> > On 12/14/20 1:09 PM, Stephen Rothwell wrote:  
> > > Just a reminder that I am still applying the above merge fix.  
> > 
> > I sent in my core changes, but they haven't been pulled yet. So I guess
> > we're dealing with a timing situation... David, did you send in the btrfs
> > pull yet?  
> 
> Yes
> https://lore.kernel.org/lkml/cover.1607955523.git.dste...@suse.com/

I would expect you *both* to at least mention this conflict to Linus ...

-- 
Cheers,
Stephen Rothwell


pgpSbwMvP5lXB.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[David Sterba]

On Mon, Dec 14, 2020 at 01:12:46PM -0700, Jens Axboe wrote:
> On 12/14/20 1:09 PM, Stephen Rothwell wrote:
> > Just a reminder that I am still applying the above merge fix.
> 
> I sent in my core changes, but they haven't been pulled yet. So I guess
> we're dealing with a timing situation... David, did you send in the btrfs
> pull yet?

Yes
https://lore.kernel.org/lkml/cover.1607955523.git.dste...@suse.com/

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Mon, 7 Dec 2020 14:09:51 +1100 Stephen Rothwell  
wrote:
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/io_uring.c: In function 'io_shutdown':
> fs/io_uring.c:3782:9: error: too many arguments to function 'sock_from_file'
>  3782 |  sock = sock_from_file(req->file, );
>   | ^~
> In file included from fs/io_uring.c:63:
> include/linux/net.h:243:16: note: declared here
>   243 | struct socket *sock_from_file(struct file *file);
>   |^~
> 
> Caused by commit
> 
>   36f4fa6886a8 ("io_uring: add support for shutdown(2)")
> 
> interacting with commit
> 
>   dba4a9256bb4 ("net: Remove the err argument from sock_from_file")
> 
> from the bpf-next tree.
> 
> I have applied the following merge fix patch.
> 
> From: Stephen Rothwell 
> Date: Mon, 7 Dec 2020 14:04:10 +1100
> Subject: [PATCH] fixup for "net: Remove the err argument from sock_from_file"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/io_uring.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index cd997264dbab..91d08408f1fe 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -3779,9 +3779,9 @@ static int io_shutdown(struct io_kiocb *req, bool 
> force_nonblock)
>   if (force_nonblock)
>   return -EAGAIN;
>  
> - sock = sock_from_file(req->file, );
> + sock = sock_from_file(req->file);
>   if (unlikely(!sock))
> - return ret;
> + return -ENOTSOCK;
>  
>   ret = __sys_shutdown_sock(sock, req->shutdown.how);
>   io_req_complete(req, ret);

Just a reminder that I am still applying this merge fix.

-- 
Cheers,
Stephen Rothwell


pgppo7pcnA0H2.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Wed, 2 Dec 2020 15:01:49 +1100 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> fs/btrfs/zoned.c: In function 'btrfs_get_dev_zone_info':
> fs/btrfs/zoned.c:168:21: error: 'struct block_device' has no member named 
> 'bd_part'; did you mean 'bd_partno'?
>   168 |  nr_sectors = bdev->bd_part->nr_sects;
>   | ^~~
>   | bd_partno
> fs/btrfs/zoned.c: In function 'btrfs_sb_log_location_bdev':
> fs/btrfs/zoned.c:508:21: error: 'struct block_device' has no member named 
> 'bd_part'; did you mean 'bd_partno'?
>   508 |  nr_sectors = bdev->bd_part->nr_sects;
>   | ^~~
>   | bd_partno
> fs/btrfs/zoned.c: In function 'btrfs_reset_sb_log_zones':
> fs/btrfs/zoned.c:606:21: error: 'struct block_device' has no member named 
> 'bd_part'; did you mean 'bd_partno'?
>   606 |  nr_sectors = bdev->bd_part->nr_sects;
>   | ^~~
>   | bd_partno
> 
> Caused by commits
> 
>   a782483cc1f8 ("block: remove the nr_sects field in struct hd_struct")
>   0d02129e76ed ("block: merge struct block_device and struct hd_struct")
> 
> interacting with commits
> 
>   ab3ea6d0e65c ("btrfs: get zone information of zoned block devices")
>   1a4b440a1c2b ("btrfs: implement log-structured superblock for ZONED mode")
> 
> from the btrfs tree.
> 
> I applied the following merge fix patch (which may, or may not, be
> correct but fixes the build).
> 
> From: Stephen Rothwell 
> Date: Wed, 2 Dec 2020 14:55:04 +1100
> Subject: [PATCH] fixup for "block: merge struct block_device and struct
>  hd_struct"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/btrfs/zoned.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
> index 155545180046..c38846659019 100644
> --- a/fs/btrfs/zoned.c
> +++ b/fs/btrfs/zoned.c
> @@ -165,7 +165,7 @@ int btrfs_get_dev_zone_info(struct btrfs_device *device)
>   if (!zone_info)
>   return -ENOMEM;
>  
> - nr_sectors = bdev->bd_part->nr_sects;
> + nr_sectors = bdev_nr_sectors(bdev);
>   zone_sectors = bdev_zone_sectors(bdev);
>   /* Check if it's power of 2 (see is_power_of_2) */
>   ASSERT(zone_sectors != 0 && (zone_sectors & (zone_sectors - 1)) == 0);
> @@ -505,7 +505,7 @@ int btrfs_sb_log_location_bdev(struct block_device *bdev, 
> int mirror, int rw,
>   return -EINVAL;
>   zone_size = zone_sectors << SECTOR_SHIFT;
>   zone_sectors_shift = ilog2(zone_sectors);
> - nr_sectors = bdev->bd_part->nr_sects;
> + nr_sectors = bdev_nr_sectors(bdev);
>   nr_zones = nr_sectors >> zone_sectors_shift;
>  
>   sb_zone = sb_zone_number(zone_sectors_shift + SECTOR_SHIFT, mirror);
> @@ -603,7 +603,7 @@ int btrfs_reset_sb_log_zones(struct block_device *bdev, 
> int mirror)
>  
>   zone_sectors = bdev_zone_sectors(bdev);
>   zone_sectors_shift = ilog2(zone_sectors);
> - nr_sectors = bdev->bd_part->nr_sects;
> + nr_sectors = bdev_nr_sectors(bdev);
>   nr_zones = nr_sectors >> zone_sectors_shift;
>  
>   sb_zone = sb_zone_number(zone_sectors_shift + SECTOR_SHIFT, mirror);

Just a reminder that I am still applying the above merge fix.

-- 
Cheers,
Stephen Rothwell


pgphVZ2lavzJG.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 12/14/20 1:09 PM, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 2 Dec 2020 15:01:49 +1100 Stephen Rothwell  
> wrote:
>>
>> Hi all,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> fs/btrfs/zoned.c: In function 'btrfs_get_dev_zone_info':
>> fs/btrfs/zoned.c:168:21: error: 'struct block_device' has no member named 
>> 'bd_part'; did you mean 'bd_partno'?
>>   168 |  nr_sectors = bdev->bd_part->nr_sects;
>>   | ^~~
>>   | bd_partno
>> fs/btrfs/zoned.c: In function 'btrfs_sb_log_location_bdev':
>> fs/btrfs/zoned.c:508:21: error: 'struct block_device' has no member named 
>> 'bd_part'; did you mean 'bd_partno'?
>>   508 |  nr_sectors = bdev->bd_part->nr_sects;
>>   | ^~~
>>   | bd_partno
>> fs/btrfs/zoned.c: In function 'btrfs_reset_sb_log_zones':
>> fs/btrfs/zoned.c:606:21: error: 'struct block_device' has no member named 
>> 'bd_part'; did you mean 'bd_partno'?
>>   606 |  nr_sectors = bdev->bd_part->nr_sects;
>>   | ^~~
>>   | bd_partno
>>
>> Caused by commits
>>
>>   a782483cc1f8 ("block: remove the nr_sects field in struct hd_struct")
>>   0d02129e76ed ("block: merge struct block_device and struct hd_struct")
>>
>> interacting with commits
>>
>>   ab3ea6d0e65c ("btrfs: get zone information of zoned block devices")
>>   1a4b440a1c2b ("btrfs: implement log-structured superblock for ZONED mode")
>>
>> from the btrfs tree.
>>
>> I applied the following merge fix patch (which may, or may not, be
>> correct but fixes the build).
>>
>> From: Stephen Rothwell 
>> Date: Wed, 2 Dec 2020 14:55:04 +1100
>> Subject: [PATCH] fixup for "block: merge struct block_device and struct
>>  hd_struct"
>>
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  fs/btrfs/zoned.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
>> index 155545180046..c38846659019 100644
>> --- a/fs/btrfs/zoned.c
>> +++ b/fs/btrfs/zoned.c
>> @@ -165,7 +165,7 @@ int btrfs_get_dev_zone_info(struct btrfs_device *device)
>>  if (!zone_info)
>>  return -ENOMEM;
>>  
>> -nr_sectors = bdev->bd_part->nr_sects;
>> +nr_sectors = bdev_nr_sectors(bdev);
>>  zone_sectors = bdev_zone_sectors(bdev);
>>  /* Check if it's power of 2 (see is_power_of_2) */
>>  ASSERT(zone_sectors != 0 && (zone_sectors & (zone_sectors - 1)) == 0);
>> @@ -505,7 +505,7 @@ int btrfs_sb_log_location_bdev(struct block_device 
>> *bdev, int mirror, int rw,
>>  return -EINVAL;
>>  zone_size = zone_sectors << SECTOR_SHIFT;
>>  zone_sectors_shift = ilog2(zone_sectors);
>> -nr_sectors = bdev->bd_part->nr_sects;
>> +nr_sectors = bdev_nr_sectors(bdev);
>>  nr_zones = nr_sectors >> zone_sectors_shift;
>>  
>>  sb_zone = sb_zone_number(zone_sectors_shift + SECTOR_SHIFT, mirror);
>> @@ -603,7 +603,7 @@ int btrfs_reset_sb_log_zones(struct block_device *bdev, 
>> int mirror)
>>  
>>  zone_sectors = bdev_zone_sectors(bdev);
>>  zone_sectors_shift = ilog2(zone_sectors);
>> -nr_sectors = bdev->bd_part->nr_sects;
>> +nr_sectors = bdev_nr_sectors(bdev);
>>  nr_zones = nr_sectors >> zone_sectors_shift;
>>  
>>  sb_zone = sb_zone_number(zone_sectors_shift + SECTOR_SHIFT, mirror);
> 
> Just a reminder that I am still applying the above merge fix.

I sent in my core changes, but they haven't been pulled yet. So I guess
we're dealing with a timing situation... David, did you send in the btrfs
pull yet?

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Florent Revest]

On Mon, 2020-12-07 at 14:09 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/io_uring.c: In function 'io_shutdown':
> fs/io_uring.c:3782:9: error: too many arguments to function
> 'sock_from_file'
>  3782 |  sock = sock_from_file(req->file, );
>   | ^~
> In file included from fs/io_uring.c:63:
> include/linux/net.h:243:16: note: declared here
>   243 | struct socket *sock_from_file(struct file *file);
>   |^~
> 
> Caused by commit
> 
>   36f4fa6886a8 ("io_uring: add support for shutdown(2)")
> 
> interacting with commit
> 
>   dba4a9256bb4 ("net: Remove the err argument from sock_from_file")
> 
> from the bpf-next tree.
> 
> I have applied the following merge fix patch.
> 
> From: Stephen Rothwell 
> Date: Mon, 7 Dec 2020 14:04:10 +1100
> Subject: [PATCH] fixup for "net: Remove the err argument from
> sock_from_file"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  fs/io_uring.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index cd997264dbab..91d08408f1fe 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -3779,9 +3779,9 @@ static int io_shutdown(struct io_kiocb *req,
> bool force_nonblock)
>   if (force_nonblock)
>   return -EAGAIN;
>  
> - sock = sock_from_file(req->file, );
> + sock = sock_from_file(req->file);
>   if (unlikely(!sock))
> - return ret;
> + return -ENOTSOCK;
>  
>   ret = __sys_shutdown_sock(sock, req->shutdown.how);
>   io_req_complete(req, ret);
> -- 
> 2.29.2


Thanks Stephen, this looks good to me.

Re: linux-next: build failure after merge of the block tree

[Christoph Hellwig]

On Wed, Dec 02, 2020 at 03:01:49PM +1100, Stephen Rothwell wrote:
> I applied the following merge fix patch (which may, or may not, be
> correct but fixes the build).

The fixes are exactly what I would have done.  Thanks!

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 7/15/20 9:22 AM, Geert Uytterhoeven wrote:
> Hi Jens,
> 
>> On Wed, Jul 15, 2020 at 5:08 PM Jens Axboe  wrote:
>>> On 7/15/20 3:24 AM, Geert Uytterhoeven wrote:
 On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell  
 wrote:
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> block/blk-timeout.c: In function 'blk_round_jiffies':
> block/blk-timeout.c:96:14: error: 'CONFIG_HZ_ROUGH_MASK' undeclared 
> (first use in this function)
>96 |  return (j + CONFIG_HZ_ROUGH_MASK) + 1;
>   |  ^~~~
>
> Caused by commit
>
>   91ba0f529364 ("block: relax jiffies rounding for timeouts")
>
> CONFIG_HZ_ROUGH_MASK is not defined for this build even though
> CONFIG_HZ_100 is set. The arm arch does not include kernel/Kconfig.hz.
>
> I have reverted that commit for today.

 (as I don't have the original patch in my email, I'm commenting here)

 +config HZ_ROUGH_MASK
 +   int
 +   default 127 if HZ_100
 +   default 255 if HZ_250 || HZ_300
 +   default 1023 if HZ_1000

 What about other HZ_* values?
>>>
>>> Which other ones do we have?
>>
>> $ git grep "\> arch/alpha/Kconfig: default HZ_128 if ALPHA_QEMU
>> arch/alpha/Kconfig: default HZ_1200 if ALPHA_RAWHIDE
>> arch/alpha/Kconfig: default HZ_1024
> 
> And ARC allows you to enter any integer value:
> 
> config HZ
> int "Timer Frequency"
> default 100
> 
> So probably you want to derive something from the integer value itself.
> 
> Note that not all architectures include kernel/Kconfig.hz.

I've dropped the dependency on Kconfig solving it, and just made it
an initcall setup to generate the mask. That should work on all archs
and not be dependent on fixed HZ settings.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Geert Uytterhoeven]

Hi Jens,

> On Wed, Jul 15, 2020 at 5:08 PM Jens Axboe  wrote:
> > On 7/15/20 3:24 AM, Geert Uytterhoeven wrote:
> > > On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell  
> > > wrote:
> > >> After merging the block tree, today's linux-next build (arm
> > >> multi_v7_defconfig) failed like this:
> > >>
> > >> block/blk-timeout.c: In function 'blk_round_jiffies':
> > >> block/blk-timeout.c:96:14: error: 'CONFIG_HZ_ROUGH_MASK' undeclared 
> > >> (first use in this function)
> > >>96 |  return (j + CONFIG_HZ_ROUGH_MASK) + 1;
> > >>   |  ^~~~
> > >>
> > >> Caused by commit
> > >>
> > >>   91ba0f529364 ("block: relax jiffies rounding for timeouts")
> > >>
> > >> CONFIG_HZ_ROUGH_MASK is not defined for this build even though
> > >> CONFIG_HZ_100 is set. The arm arch does not include kernel/Kconfig.hz.
> > >>
> > >> I have reverted that commit for today.
> > >
> > > (as I don't have the original patch in my email, I'm commenting here)
> > >
> > > +config HZ_ROUGH_MASK
> > > +   int
> > > +   default 127 if HZ_100
> > > +   default 255 if HZ_250 || HZ_300
> > > +   default 1023 if HZ_1000
> > >
> > > What about other HZ_* values?
> >
> > Which other ones do we have?
>
> $ git grep "\ arch/alpha/Kconfig: default HZ_128 if ALPHA_QEMU
> arch/alpha/Kconfig: default HZ_1200 if ALPHA_RAWHIDE
> arch/alpha/Kconfig: default HZ_1024

And ARC allows you to enter any integer value:

config HZ
int "Timer Frequency"
default 100

So probably you want to derive something from the integer value itself.

Note that not all architectures include kernel/Kconfig.hz.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: linux-next: build failure after merge of the block tree

[Geert Uytterhoeven]

Hi Jens,

On Wed, Jul 15, 2020 at 5:08 PM Jens Axboe  wrote:

> On 7/15/20 3:24 AM, Geert Uytterhoeven wrote:
> > On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell  
> > wrote:
> >> After merging the block tree, today's linux-next build (arm
> >> multi_v7_defconfig) failed like this:
> >>
> >> block/blk-timeout.c: In function 'blk_round_jiffies':
> >> block/blk-timeout.c:96:14: error: 'CONFIG_HZ_ROUGH_MASK' undeclared (first 
> >> use in this function)
> >>96 |  return (j + CONFIG_HZ_ROUGH_MASK) + 1;
> >>   |  ^~~~
> >>
> >> Caused by commit
> >>
> >>   91ba0f529364 ("block: relax jiffies rounding for timeouts")
> >>
> >> CONFIG_HZ_ROUGH_MASK is not defined for this build even though
> >> CONFIG_HZ_100 is set. The arm arch does not include kernel/Kconfig.hz.
> >>
> >> I have reverted that commit for today.
> >
> > (as I don't have the original patch in my email, I'm commenting here)
> >
> > +config HZ_ROUGH_MASK
> > +   int
> > +   default 127 if HZ_100
> > +   default 255 if HZ_250 || HZ_300
> > +   default 1023 if HZ_1000
> >
> > What about other HZ_* values?
>
> Which other ones do we have?

$ git grep "\

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 7/15/20 3:24 AM, Geert Uytterhoeven wrote:
> On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell  
> wrote:
>> After merging the block tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> block/blk-timeout.c: In function 'blk_round_jiffies':
>> block/blk-timeout.c:96:14: error: 'CONFIG_HZ_ROUGH_MASK' undeclared (first 
>> use in this function)
>>96 |  return (j + CONFIG_HZ_ROUGH_MASK) + 1;
>>   |  ^~~~
>>
>> Caused by commit
>>
>>   91ba0f529364 ("block: relax jiffies rounding for timeouts")
>>
>> CONFIG_HZ_ROUGH_MASK is not defined for this build even though
>> CONFIG_HZ_100 is set. The arm arch does not include kernel/Kconfig.hz.
>>
>> I have reverted that commit for today.
> 
> (as I don't have the original patch in my email, I'm commenting here)
> 
> +config HZ_ROUGH_MASK
> +   int
> +   default 127 if HZ_100
> +   default 255 if HZ_250 || HZ_300
> +   default 1023 if HZ_1000
> 
> What about other HZ_* values?

Which other ones do we have?

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 7/14/20 8:14 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> block/blk-timeout.c: In function 'blk_round_jiffies':
> block/blk-timeout.c:96:14: error: 'CONFIG_HZ_ROUGH_MASK' undeclared (first 
> use in this function)
>96 |  return (j + CONFIG_HZ_ROUGH_MASK) + 1;
>   |  ^~~~
> 
> Caused by commit
> 
>   91ba0f529364 ("block: relax jiffies rounding for timeouts")
> 
> CONFIG_HZ_ROUGH_MASK is not defined for this build even though
> CONFIG_HZ_100 is set. The arm arch does not include kernel/Kconfig.hz.
> 
> I have reverted that commit for today.

Thanks, I'll take a look.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Geert Uytterhoeven]

On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell  wrote:
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> block/blk-timeout.c: In function 'blk_round_jiffies':
> block/blk-timeout.c:96:14: error: 'CONFIG_HZ_ROUGH_MASK' undeclared (first 
> use in this function)
>96 |  return (j + CONFIG_HZ_ROUGH_MASK) + 1;
>   |  ^~~~
>
> Caused by commit
>
>   91ba0f529364 ("block: relax jiffies rounding for timeouts")
>
> CONFIG_HZ_ROUGH_MASK is not defined for this build even though
> CONFIG_HZ_100 is set. The arm arch does not include kernel/Kconfig.hz.
>
> I have reverted that commit for today.

(as I don't have the original patch in my email, I'm commenting here)

+config HZ_ROUGH_MASK
+   int
+   default 127 if HZ_100
+   default 255 if HZ_250 || HZ_300
+   default 1023 if HZ_1000

What about other HZ_* values?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 5/25/20 10:36 PM, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 25 May 2020 13:03:44 -0600 Jens Axboe  wrote:
>>
>> On 5/24/20 11:08 PM, Stephen Rothwell wrote:
>>>
>>> After merging the block tree, today's linux-next build (arm
>>> multi_v7_defconfig) failed like this:
>>>
>>> mm/filemap.c: In function 'generic_file_buffered_read':
>>> mm/filemap.c:2075:9: error: 'written' undeclared (first use in this 
>>> function); did you mean 'writeb'?
>>>  2075 | if (written) {
>>>   | ^~~
>>>   | writeb
>>>
>>> Caused by commit
>>>
>>>   23d513106fd8 ("mm: support async buffered reads in 
>>> generic_file_buffered_read()")
>>>
>>> from the block tree interacting with commit
>>>
>>>   6e66f10f2cac ("fs: export generic_file_buffered_read()")
>>>
>>> from the btrfs tree.
>>>
>>> [Aside: that btrfs tree commit talks about "correct the comments and 
>>> variable
>>> names", but changes "written" to "copied" in the function definition
>>> but to "already_read" in the header file declaration ...]
>>>
>>> I ave applied the following merge fix patch:  
>>
>> Looks like a frivolous change... Thanks for fixing this up Stephen.
> 
> The variable name change has been removed from the btrfs tree.

Thanks - I'd encourage that name changing late in the merge window
instead. The change is obviously fine, but a) it should not be done in
an unrelated change, and b) it can be done without risking causing silly
merge issues.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Mon, 25 May 2020 13:03:44 -0600 Jens Axboe  wrote:
>
> On 5/24/20 11:08 PM, Stephen Rothwell wrote:
> > 
> > After merging the block tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > mm/filemap.c: In function 'generic_file_buffered_read':
> > mm/filemap.c:2075:9: error: 'written' undeclared (first use in this 
> > function); did you mean 'writeb'?
> >  2075 | if (written) {
> >   | ^~~
> >   | writeb
> > 
> > Caused by commit
> > 
> >   23d513106fd8 ("mm: support async buffered reads in 
> > generic_file_buffered_read()")
> > 
> > from the block tree interacting with commit
> > 
> >   6e66f10f2cac ("fs: export generic_file_buffered_read()")
> > 
> > from the btrfs tree.
> > 
> > [Aside: that btrfs tree commit talks about "correct the comments and 
> > variable
> > names", but changes "written" to "copied" in the function definition
> > but to "already_read" in the header file declaration ...]
> > 
> > I ave applied the following merge fix patch:  
> 
> Looks like a frivolous change... Thanks for fixing this up Stephen.

The variable name change has been removed from the btrfs tree.

-- 
Cheers,
Stephen Rothwell


pgpmwOAytud2n.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 5/24/20 11:08 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> mm/filemap.c: In function 'generic_file_buffered_read':
> mm/filemap.c:2075:9: error: 'written' undeclared (first use in this 
> function); did you mean 'writeb'?
>  2075 | if (written) {
>   | ^~~
>   | writeb
> 
> Caused by commit
> 
>   23d513106fd8 ("mm: support async buffered reads in 
> generic_file_buffered_read()")
> 
> from the block tree interacting with commit
> 
>   6e66f10f2cac ("fs: export generic_file_buffered_read()")
> 
> from the btrfs tree.
> 
> [Aside: that btrfs tree commit talks about "correct the comments and variable
> names", but changes "written" to "copied" in the function definition
> but to "already_read" in the header file declaration ...]
> 
> I ave applied the following merge fix patch:

Looks like a frivolous change... Thanks for fixing this up Stephen.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 5/22/20 5:32 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
> 
> fs/libfs.c: In function 'generic_file_fsync':
> fs/libfs.c:1116:9: error: too few arguments to function 'blkdev_issue_flush'
>  1116 |  return blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL);
>   | ^~
> In file included from fs/libfs.c:7:
> include/linux/blkdev.h:1875:19: note: declared here
>  1875 | static inline int blkdev_issue_flush(struct block_device *bdev, gfp_t 
> gfp_mask,
>   |   ^~
> 
> Caused by commit
> 
>   c64644ce363b ("block: remove the error_sector argument to 
> blkdev_issue_flush")

Gah, I'll fold in the fix. Thanks Stephen.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 5/14/20 2:57 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
> 
> In file included from include/linux/blk-cgroup.h:23,
>  from include/linux/writeback.h:14,
>  from include/linux/memcontrol.h:22,
>  from include/linux/swap.h:9,
>  from include/linux/suspend.h:5,
>  from arch/x86/kernel/asm-offsets.c:13:
> include/linux/blkdev.h: In function 'blk_io_schedule':
> include/linux/blkdev.h:1857:26: error: 'sysctl_hung_task_timeout_secs' 
> undeclared (first use in this function)
>  1857 |  unsigned long timeout = sysctl_hung_task_timeout_secs * HZ / 2;
>   |  ^
> 
> Caused by commit
> 
>   e6249cdd46e4 ("block: add blk_io_schedule() for avoiding task hung in sync 
> dio")
> 
> linux/sched/sysctl.h was not included since CONFIG_BLOCK is not defined.
> I have applied the following patch for today.

Sorry about that, it's fixed in the current tree.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 5/11/20 9:17 AM, Christoph Hellwig wrote:
> On Mon, May 11, 2020 at 09:06:41AM -0600, Jens Axboe wrote:
>> On 5/10/20 10:27 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the block tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> drivers/block/aoe/aoeblk.c: In function 'aoeblk_gdalloc':
>>> drivers/block/aoe/aoeblk.c:410:21: error: 'struct backing_dev_info' has no 
>>> member named 'name'
>>>   410 |  q->backing_dev_info->name = "aoe";
>>>   | ^~
>>>
>>> Caused by commit
>>>
>>>   1cd925d58385 ("bdi: remove the name field in struct backing_dev_info")
>>
>> Gah, thanks Stephen. This series is looking less and less impressive,
>> fallout for both 5.7 and 5.8, in terms of build testing (none).
> 
> And the sad part is that it has been sitting out there exposed to the
> buildbot for weeks.  Sigh.

Indeed, I do wish the build bot was a bit more expedient (as in 24h turn
around would be good), and reliable. Seems hit or miss, don't fully trust
it and this series is an example of why.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Christoph Hellwig]

On Mon, May 11, 2020 at 09:06:41AM -0600, Jens Axboe wrote:
> On 5/10/20 10:27 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the block tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/block/aoe/aoeblk.c: In function 'aoeblk_gdalloc':
> > drivers/block/aoe/aoeblk.c:410:21: error: 'struct backing_dev_info' has no 
> > member named 'name'
> >   410 |  q->backing_dev_info->name = "aoe";
> >   | ^~
> > 
> > Caused by commit
> > 
> >   1cd925d58385 ("bdi: remove the name field in struct backing_dev_info")
> 
> Gah, thanks Stephen. This series is looking less and less impressive,
> fallout for both 5.7 and 5.8, in terms of build testing (none).

And the sad part is that it has been sitting out there exposed to the
buildbot for weeks.  Sigh.

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 5/10/20 10:27 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/block/aoe/aoeblk.c: In function 'aoeblk_gdalloc':
> drivers/block/aoe/aoeblk.c:410:21: error: 'struct backing_dev_info' has no 
> member named 'name'
>   410 |  q->backing_dev_info->name = "aoe";
>   | ^~
> 
> Caused by commit
> 
>   1cd925d58385 ("bdi: remove the name field in struct backing_dev_info")

Gah, thanks Stephen. This series is looking less and less impressive,
fallout for both 5.7 and 5.8, in terms of build testing (none).

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 5/7/20 11:28 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/kernel.h:15,
>  from include/linux/list.h:9,
>  from include/linux/module.h:12,
>  from block/bfq-iosched.c:116:
> block/bfq-iosched.c: In function 'bfq_set_next_ioprio_data':
> block/bfq-iosched.c:4980:5: error: implicit declaration of function 
> 'bdi_dev_name'; did you mean 'blkg_dev_name'? 
> [-Werror=implicit-function-declaration]
>  4980 | bdi_dev_name(bfqq->bfqd->queue->backing_dev_info),
>   | ^~~~
> 
> Caused by commit
> 
>   0f6438fca125 ("bdi: use bdi_dev_name() to get device name")
> 
> I have applied the following patch for today.

Thanks Stephen, I have added it.

-- 
Jens Axboe

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Tejun Heo]

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 
> Date: Thu, 11 Jul 2019 15:13:21 +1000
> Subject: [PATCH] f2fs: fix for wbc_account_io rename
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  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 

Thanks.

-- 
tejun

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Christoph,

On Fri, 21 Jun 2019 10:18:36 +0200 Christoph Hellwig  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


pgpnVfPeX5GiE.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

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

Re: linux-next: build failure after merge of the block tree

[Ming Lei]

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 
> 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 
> ---
>  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=154760499205773=2

Thanks,
Ming

Re: linux-next: build failure after merge of the block tree

[Ming Lei]

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 
> Date: Wed, 16 Jan 2019 13:32:59 +1100
> Subject: [PATCH] SUNRPC: merge fix for "block: rename bvec helpers"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  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, , 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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Thu, 26 Jul 2018 14:56:24 +1000 Stephen Rothwell  
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 
> 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 
> ---
>  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(>entry, _list);
>  out_unlock:
>   mutex_unlock(_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


pgp8nEyBD3iLU.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Thu, 26 Jul 2018 14:56:24 +1000 Stephen Rothwell  
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 
> 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 
> ---
>  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(>entry, _list);
>  out_unlock:
>   mutex_unlock(_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


pgp8nEyBD3iLU.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Steve,

On Thu, 26 Jul 2018 07:32:16 -0500 "Steve Wise"  
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


pgpKL7mBr19Lj.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Steve,

On Thu, 26 Jul 2018 07:32:16 -0500 "Steve Wise"  
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


pgpKL7mBr19Lj.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Bart Van Assche]

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.

Re: linux-next: build failure after merge of the block tree

[Bart Van Assche]

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.

RE: linux-next: build failure after merge of the block tree

[Steve Wise]

> -Original Message-
> From: Christoph Hellwig 
> Sent: Thursday, July 26, 2018 12:57 PM
> To: Jens Axboe 
> Cc: Christoph Hellwig ; Stephen Rothwell
> ; Doug Ledford ; Jason
> Gunthorpe ; Linux-Next Mailing List  n...@vger.kernel.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; Steve Wise 
> 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.

RE: linux-next: build failure after merge of the block tree

[Steve Wise]

> -Original Message-
> From: Christoph Hellwig 
> Sent: Thursday, July 26, 2018 12:57 PM
> To: Jens Axboe 
> Cc: Christoph Hellwig ; Stephen Rothwell
> ; Doug Ledford ; Jason
> Gunthorpe ; Linux-Next Mailing List  n...@vger.kernel.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; Steve Wise 
> 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.

Re: linux-next: build failure after merge of the block tree

[Christoph Hellwig]

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.

Re: linux-next: build failure after merge of the block tree

[Christoph Hellwig]

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.

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

RE: linux-next: build failure after merge of the block tree

[Steve Wise]

Hey Stephen:

> I have applied the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> 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 
> ---
>  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(>entry, _list);
>  out_unlock:
>   mutex_unlock(_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.

RE: linux-next: build failure after merge of the block tree

[Steve Wise]

Hey Stephen:

> I have applied the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> 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 
> ---
>  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(>entry, _list);
>  out_unlock:
>   mutex_unlock(_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.

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Christoph,

On Thu, 26 Jul 2018 10:48:33 +0200 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.

Thanks, I will fix up my resolution for tomorrow.

-- 
Cheers,
Stephen Rothwell


pgpHneJJ2496S.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Christoph,

On Thu, 26 Jul 2018 10:48:33 +0200 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.

Thanks, I will fix up my resolution for tomorrow.

-- 
Cheers,
Stephen Rothwell


pgpHneJJ2496S.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the block tree

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

Re: linux-next: build failure after merge of the block tree

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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Christoph,

On Thu, 24 Aug 2017 10:44:10 +0200 Christoph Hellwig  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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Christoph,

On Thu, 24 Aug 2017 10:44:10 +0200 Christoph Hellwig  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

Re: linux-next: build failure after merge of the block tree

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

Re: linux-next: build failure after merge of the block tree

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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Thu, 24 Aug 2017 13:32:03 +1000 Stephen Rothwell  
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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Thu, 24 Aug 2017 13:32:03 +1000 Stephen Rothwell  
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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Guenter,

On Tue, 4 Jul 2017 08:15:57 -0700 Guenter Roeck  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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Guenter,

On Tue, 4 Jul 2017 08:15:57 -0700 Guenter Roeck  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

Re: linux-next: build failure after merge of the block tree

[Guenter Roeck]

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 
> 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 
> ---
>  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(>lock);
>   if (!scm_permit_request(bdev, req)) {
>   spin_unlock(>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(>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(>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(>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,

Re: linux-next: build failure after merge of the block tree

[Guenter Roeck]

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 
> 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 
> ---
>  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(>lock);
>   if (!scm_permit_request(bdev, req)) {
>   spin_unlock(>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(>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(>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(>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,

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Jens,

On Wed, 28 Jun 2017 09:11:32 -0600 Jens Axboe  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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Jens,

On Wed, 28 Jun 2017 09:11:32 -0600 Jens Axboe  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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Sebastian,

On Mon, 19 Jun 2017 11:00:23 +0200 (CEST) Sebastian Ott 
 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(>dev);
> 

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

From: Stephen Rothwell 
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 
---
 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(>lock);
if (!scm_permit_request(bdev, req)) {
spin_unlock(>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(>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(>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(>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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Sebastian,

On Mon, 19 Jun 2017 11:00:23 +0200 (CEST) Sebastian Ott 
 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(>dev);
> 

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

From: Stephen Rothwell 
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 
---
 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(>lock);
if (!scm_permit_request(bdev, req)) {
spin_unlock(>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(>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(>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(>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

Re: linux-next: build failure after merge of the block tree

[Sebastian Ott]

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(>dev);

Re: linux-next: build failure after merge of the block tree

[Sebastian Ott]

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(>dev);

Re: linux-next: build failure after merge of the block tree

[Sebastian Ott]

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

Re: linux-next: build failure after merge of the block tree

[Sebastian Ott]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On May 1, 2017, at 7:37 PM, Stephen Rothwell  wrote:
> 
> Hi Jens,
> 
>> On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe  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. 

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On May 1, 2017, at 7:37 PM, Stephen Rothwell  wrote:
> 
> Hi Jens,
> 
>> On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe  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. 

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Jens,

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

Thanks.

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

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Jens,

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

Thanks.

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

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

> On May 1, 2017, at 7:07 PM, Stephen Rothwell  wrote:
> 
> Hi all,
> 
>> On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell  
>> 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 
>> 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 
>> ---
>> 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. 

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

> On May 1, 2017, at 7:07 PM, Stephen Rothwell  wrote:
> 
> Hi all,
> 
>> On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell  
>> 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 
>> 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 
>> ---
>> 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. 

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell  
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 
> 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 
> ---
>  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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi all,

On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell  
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 
> 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 
> ---
>  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

Re: linux-next: build failure after merge of the block tree

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

Re: linux-next: build failure after merge of the block tree

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 11/30/2016 08:02 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Wed, 30 Nov 2016 20:00:36 -0700 Jens Axboe  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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

On 11/30/2016 08:02 PM, Stephen Rothwell wrote:
> Hi Jens,
> 
> On Wed, 30 Nov 2016 20:00:36 -0700 Jens Axboe  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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Jens,

On Wed, 30 Nov 2016 20:00:36 -0700 Jens Axboe  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

Re: linux-next: build failure after merge of the block tree

[Stephen Rothwell]

Hi Jens,

On Wed, 30 Nov 2016 20:00:36 -0700 Jens Axboe  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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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

Re: linux-next: build failure after merge of the block tree

[Jens Axboe]

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