Hi all,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/md/raid0.c: In function 'raid0_handle_discard':
drivers/md/raid0.c:511:26: error: passing argument 1 of 'trace_block_bio_remap' from incompatible pointer type [-Werror=incompatible-pointer-types]
511 | trace_block_bio_remap(bdev_get_queue(rdev->bdev),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| struct request_queue *
In file included from include/trace/events/block.h:11,
from drivers/md/raid0.c:17:
include/trace/events/block.h:458:23: note: expected 'struct bio *' but argument is of type 'struct request_queue *'
458 | TP_PROTO(struct bio *bio, dev_t dev, sector_t from),
| ~~~~~~~~~~~~^~~
include/linux/tracepoint.h:238:34: note: in definition of macro '__DECLARE_TRACE'
238 | static inline void trace_##name(proto) \
| ^~~~~
include/linux/tracepoint.h:411:24: note: in expansion of macro 'PARAMS'
411 | __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
| ^~~~~~
include/linux/tracepoint.h:547:2: note: in expansion of macro 'DECLARE_TRACE'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^~~~~~~~~~~~~
include/linux/tracepoint.h:547:22: note: in expansion of macro 'PARAMS'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^~~~~~
include/trace/events/block.h:456:1: note: in expansion of macro 'TRACE_EVENT'
456 | TRACE_EVENT(block_bio_remap,
| ^~~~~~~~~~~
include/trace/events/block.h:458:2: note: in expansion of macro 'TP_PROTO'
458 | TP_PROTO(struct bio *bio, dev_t dev, sector_t from),
| ^~~~~~~~
drivers/md/raid0.c:512:5: warning: passing argument 2 of 'trace_block_bio_remap' makes integer from pointer without a cast [-Wint-conversion]
512 | discard_bio, disk_devt(mddev->gendisk),
| ^~~~~~~~~~~
| |
| struct bio *
In file included from include/trace/events/block.h:11,
from drivers/md/raid0.c:17:
include/trace/events/block.h:458:34: note: expected 'dev_t' {aka 'unsigned int'} but argument is of type 'struct bio *'
458 | TP_PROTO(struct bio *bio, dev_t dev, sector_t from),
| ~~~~~~^~~
include/linux/tracepoint.h:238:34: note: in definition of macro '__DECLARE_TRACE'
238 | static inline void trace_##name(proto) \
| ^~~~~
include/linux/tracepoint.h:411:24: note: in expansion of macro 'PARAMS'
411 | __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
| ^~~~~~
include/linux/tracepoint.h:547:2: note: in expansion of macro 'DECLARE_TRACE'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^~~~~~~~~~~~~
include/linux/tracepoint.h:547:22: note: in expansion of macro 'PARAMS'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^~~~~~
include/trace/events/block.h:456:1: note: in expansion of macro 'TRACE_EVENT'
456 | TRACE_EVENT(block_bio_remap,
| ^~~~~~~~~~~
include/trace/events/block.h:458:2: note: in expansion of macro 'TP_PROTO'
458 | TP_PROTO(struct bio *bio, dev_t dev, sector_t from),
| ^~~~~~~~
drivers/md/raid0.c:511:4: error: too many arguments to function 'trace_block_bio_remap'
511 | trace_block_bio_remap(bdev_get_queue(rdev->bdev),
| ^~~~~~~~~~~~~~~~~~~~~
In file included from include/trace/events/block.h:11,
from drivers/md/raid0.c:17:
include/linux/tracepoint.h:238:21: note: declared here
238 | static inline void trace_##name(proto) \
| ^~~~~~
include/linux/tracepoint.h:411:2: note: in expansion of macro '__DECLARE_TRACE'
411 | __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
| ^~~~~~~~~~~~~~~
include/linux/tracepoint.h:547:2: note: in expansion of macro 'DECLARE_TRACE'
547 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^~~~~~~~~~~~~
include/trace/events/block.h:456:1: note: in expansion of macro 'TRACE_EVENT'
456 | TRACE_EVENT(block_bio_remap,
| ^~~~~~~~~~~
Caused by commit
1c02fca620f7 ("block: remove the request_queue argument to the block_bio_remap tracepoint")
interacting with commit
57a0f3a81ef2 ("Revert "md: add md_submit_discard_bio() for submitting discard bio"")
from Linus' tree.
I have applied the following merge fix:
From: Stephen Rothwell <[email protected]>
Date: Mon, 14 Dec 2020 15:14:26 +1100
Subject: [PATCH] fixup for "block: remove the request_queue argument to the block_bio_remap tracepoint"
conflicting with
"Revert "md: add md_submit_discard_bio() for submitting discard bio""
Signed-off-by: Stephen Rothwell <[email protected]>
---
drivers/md/raid0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index 8f5b0143d8c6..67f157f2525d 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -508,8 +508,8 @@ static void raid0_handle_discard(struct mddev *mddev, struct bio *bio)
bio_chain(discard_bio, bio);
bio_clone_blkg_association(discard_bio, bio);
if (mddev->gendisk)
- trace_block_bio_remap(bdev_get_queue(rdev->bdev),
- discard_bio, disk_devt(mddev->gendisk),
+ trace_block_bio_remap(discard_bio,
+ disk_devt(mddev->gendisk),
bio->bi_iter.bi_sector);
submit_bio_noacct(discard_bio);
}
--
2.29.2
--
Cheers,
Stephen Rothwell
On 12/14/20 1:09 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 2 Dec 2020 15:01:49 +1100 Stephen Rothwell <[email protected]> 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 <[email protected]>
>> 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 <[email protected]>
>> ---
>> 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
Hi David,
On Mon, 14 Dec 2020 22:36:12 +0100 David Sterba <[email protected]> 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/[email protected]/
I would expect you *both* to at least mention this conflict to Linus ...
--
Cheers,
Stephen Rothwell
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 <[email protected]> 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/[email protected]/
>
> 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."
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/[email protected]/
Hi David,
On Mon, 14 Dec 2020 22:54:46 +0100 David Sterba <[email protected]> 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 <[email protected]> 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/[email protected]/
> >
> > 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