linux-next: build failure after merge of Linus' tree

linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

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

Hi all,

[reported by the kernelci.org bot]

For some time, building Linus' tree, the linux-next build (mips
mtx1_defconfig) fails like this:

ERROR: modpost: "sysrq_toggle_support" [drivers/tty/serial/serial_core.ko] undefined!
ERROR: modpost: "sysrq_mask" [drivers/tty/serial/serial_core.ko] undefined!

Caused by commit

  68af43173d3f ("serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE")

-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

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

Hi all,

After merging Linus' tree, today's linux-next build (sparc64
defconfig) failed like this:

drivers/block/sunvdc.c: In function 'vdc_queue_drain':
drivers/block/sunvdc.c:1130:9: error: too many arguments to function 'blk_mq_unquiesce_queue'
 1130 |         blk_mq_unquiesce_queue(q, memflags);
      |         ^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/block/sunvdc.c:10:
include/linux/blk-mq.h:895:6: note: declared here
  895 | void blk_mq_unquiesce_queue(struct request_queue *q);
      |      ^~~~~~~~~~~~~~~~~~~~~~
drivers/block/sunvdc.c:1131:9: error: too few arguments to function 'blk_mq_unfreeze_queue'
 1131 |         blk_mq_unfreeze_queue(q);
      |         ^~~~~~~~~~~~~~~~~~~~~
In file included from drivers/block/sunvdc.c:10:
include/linux/blk-mq.h:914:1: note: declared here
  914 | blk_mq_unfreeze_queue(struct request_queue *q, unsigned int memflags)
      | ^~~~~~~~~~~~~~~~~~~~~

Caused by commit

  1e1a9cecfab3 ("block: force noio scope in blk_mq_freeze_queue")

I have applied the following fix:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 3 Feb 2025 12:47:17 +1100
Subject: [PATCH] drivers/block/sunvdc.c: update the correct AIP call

My sparc64 defconfig build failed like this:

drivers/block/sunvdc.c: In function 'vdc_queue_drain':
drivers/block/sunvdc.c:1130:9: error: too many arguments to function 'blk_mq_unquiesce_queue'
 1130 |         blk_mq_unquiesce_queue(q, memflags);
      |         ^~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/block/sunvdc.c:10:
include/linux/blk-mq.h:895:6: note: declared here
  895 | void blk_mq_unquiesce_queue(struct request_queue *q);
      |      ^~~~~~~~~~~~~~~~~~~~~~
drivers/block/sunvdc.c:1131:9: error: too few arguments to function 'blk_mq_unfreeze_queue'
 1131 |         blk_mq_unfreeze_queue(q);
      |         ^~~~~~~~~~~~~~~~~~~~~
In file included from drivers/block/sunvdc.c:10:
include/linux/blk-mq.h:914:1: note: declared here
  914 | blk_mq_unfreeze_queue(struct request_queue *q, unsigned int memflags)
      | ^~~~~~~~~~~~~~~~~~~~~

Fixes: 1e1a9cecfab3 ("block: force noio scope in blk_mq_freeze_queue")
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/block/sunvdc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/sunvdc.c b/drivers/block/sunvdc.c
index 33b3bc99d532..282f81616a78 100644
--- a/drivers/block/sunvdc.c
+++ b/drivers/block/sunvdc.c
@@ -1127,8 +1127,8 @@ static void vdc_queue_drain(struct vdc_port *port)
 
 	spin_lock_irq(&port->vio.lock);
 	port->drain = 0;
-	blk_mq_unquiesce_queue(q, memflags);
-	blk_mq_unfreeze_queue(q);
+	blk_mq_unquiesce_queue(q);
+	blk_mq_unfreeze_queue(q, memflags);
 }
 
 static void vdc_ldc_reset_timer_work(struct work_struct *work)
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of Linus' tree

[Jens Axboe]

On 2/2/25 6:59 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging Linus' tree, today's linux-next build (sparc64
> defconfig) failed like this:
> 
> drivers/block/sunvdc.c: In function 'vdc_queue_drain':
> drivers/block/sunvdc.c:1130:9: error: too many arguments to function 'blk_mq_unquiesce_queue'
>  1130 |         blk_mq_unquiesce_queue(q, memflags);
>       |         ^~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/block/sunvdc.c:10:
> include/linux/blk-mq.h:895:6: note: declared here
>   895 | void blk_mq_unquiesce_queue(struct request_queue *q);
>       |      ^~~~~~~~~~~~~~~~~~~~~~
> drivers/block/sunvdc.c:1131:9: error: too few arguments to function 'blk_mq_unfreeze_queue'
>  1131 |         blk_mq_unfreeze_queue(q);
>       |         ^~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/block/sunvdc.c:10:
> include/linux/blk-mq.h:914:1: note: declared here
>   914 | blk_mq_unfreeze_queue(struct request_queue *q, unsigned int memflags)
>       | ^~~~~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   1e1a9cecfab3 ("block: force noio scope in blk_mq_freeze_queue")
> 
> I have applied the following fix:

Thanks Stephen, I've applied it to the block tree for 6.14.

-- 
Jens Axboe

linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

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

Hi all,

After merging Linus' tree, today's linux-next build (x86_64
allmodconfig) failed (very quickly) like this:

error: unknown unstable option: `patchable-function-entry`

Presumably exposed by commit

  1f9c4a996756 ("Kbuild: make MODVERSIONS support depend on not being a compile test build")

Which allowed the rust parts of the build to happen in my x86_64
allmodconfig build.

This is a cross build on a PowerPC LE host.

$ rustc --version
rustc 1.80.1
$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 14.2.0-1) 14.2.0

I have reverted these commits for today:

  a2f115470520 ("kasan: rust: Add KASAN smoke test via UAF")
  e3117404b411 ("kbuild: rust: Enable KASAN support")
  f64e2f3a66e3 ("rust: kasan: Rust does not support KHWASAN")
  c42297438aee ("kbuild: rust: Define probing macros for rustc")
  cc1d98f9fe30 ("kasan: simplify and clarify Makefile")
  ca627e636551 ("rust: cfi: add support for CFI_CLANG with Rust")

Basically for the latter one (as a guess).

And the build works.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of Linus' tree

[Alice Ryhl]

On Thu, Sep 26, 2024 at 2:04 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging Linus' tree, today's linux-next build (x86_64
> allmodconfig) failed (very quickly) like this:
>
> error: unknown unstable option: `patchable-function-entry`
>
> Presumably exposed by commit
>
>   1f9c4a996756 ("Kbuild: make MODVERSIONS support depend on not being a compile test build")
>
> Which allowed the rust parts of the build to happen in my x86_64
> allmodconfig build.
>
> This is a cross build on a PowerPC LE host.
>
> $ rustc --version
> rustc 1.80.1
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 14.2.0-1) 14.2.0
>
> I have reverted these commits for today:
>
>   a2f115470520 ("kasan: rust: Add KASAN smoke test via UAF")
>   e3117404b411 ("kbuild: rust: Enable KASAN support")
>   f64e2f3a66e3 ("rust: kasan: Rust does not support KHWASAN")
>   c42297438aee ("kbuild: rust: Define probing macros for rustc")
>   cc1d98f9fe30 ("kasan: simplify and clarify Makefile")
>   ca627e636551 ("rust: cfi: add support for CFI_CLANG with Rust")
>
> Basically for the latter one (as a guess).
>
> And the build works.

Sorry about that! The fix is here:
https://lore.kernel.org/all/20240925141944.277936-1-ojeda@kernel.org/

Alice

Re: linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

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

Hi Alice,

On Thu, 26 Sep 2024 09:36:56 +0200 Alice Ryhl <aliceryhl@google.com> wrote:
>
> Sorry about that! The fix is here:
> https://lore.kernel.org/all/20240925141944.277936-1-ojeda@kernel.org/

Thanks.  I will replace the reverts in my fixes tree with that until it
is applied to Linus' tree.
-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: build failure after merge of Linus' tree

[Miguel Ojeda]

On Thu, Sep 26, 2024 at 10:13 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Thanks.  I will replace the reverts in my fixes tree with that until it
> is applied to Linus' tree.

Thanks! I will apply it to rust-fixes now, so in principle you will
get it through that branch for tomorrow, in case it helps.

Cheers,
Miguel

Re: linux-next: build failure after merge of Linus' tree

[Sedat Dilek]

On Thu, Sep 26, 2024 at 10:24 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Sep 26, 2024 at 10:13 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Thanks.  I will replace the reverts in my fixes tree with that until it
> > is applied to Linus' tree.
>
> Thanks! I will apply it to rust-fixes now, so in principle you will
> get it through that branch for tomorrow, in case it helps.
>
> Cheers,
> Miguel
>

Do you offer a (an optimized - optimized for kernel-builds) prebuilt
RUST toolchain - preferable for x86-64 hosts - like Nathan +
LLVM/Clang folk offer (see [1],[2])?
Maybe I have missed in [3] or overlooked.

INFO: I use LLVM/Clang-19 from [2] for my latest Linux v6.11 builds.
It's faster (20-25% in build-time) than distro LLVM toolchain (here:
Debian/unstable AMD64).

[ Provocative ]
Can I REALLY use a RUST-compiled Linux-kernel on BARE METAL?
Do I need special hardware?
Do you have a working in sense of bootable linux-config file?
^^ This is a real question - not interested in any "technical preview".
^^ You do NOT need to answer all this!
[ /Provocative ]

Thanks.

BR,
-Sedat-

[1] https://mirrors.edge.kernel.org/pub/tools/llvm/
[2] https://mirrors.edge.kernel.org/pub/tools/llvm/files/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rust/

Re: linux-next: build failure after merge of Linus' tree

[Miguel Ojeda]

On Thu, Sep 26, 2024 at 2:49 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> Do you offer a (an optimized - optimized for kernel-builds) prebuilt
> RUST toolchain - preferable for x86-64 hosts - like Nathan +
> LLVM/Clang folk offer (see [1],[2])?

Yes, Nathan himself provides those! :)

    https://mirrors.edge.kernel.org/pub/tools/llvm/rust/

He may comment further -- I think the Rust compiler itself is not
built (yet?) with PGO etc. like he does for the LLVM side.

As usual -- thanks Nathan!

> Maybe I have missed in [3] or overlooked.

If you go into the Quick Start guide from your link, you will see it
linked at the top:

    https://docs.kernel.org/rust/quick-start.html

I also mentioned these in LPC's Kernel Summit track (sorry, no
video/stream yet, as far as I understand):
https://lpc.events/event/18/contributions/1912/

> [ Provocative ]
> Can I REALLY use a RUST-compiled Linux-kernel on BARE METAL?
> Do I need special hardware?
> Do you have a working in sense of bootable linux-config file?
> ^^ This is a real question - not interested in any "technical preview".
> ^^ You do NOT need to answer all this!

I am not sure what you mean -- people has been using Linux with Rust
enabled in real hardware for quite a while, e.g. Android and Asahi,
plus others are upcoming (Fedora, as far as I know), and I regularly
test in CI that the kernel boots in QEMU for several architectures and
configs that we already have in-tree.

I also regularly test in CI that the kernel can be built with
`rustup`'s binaries, with several distro toolchains and with Nathan's
toolchains too.

Cheers,
Miguel

Re: linux-next: build failure after merge of Linus' tree

[Sedat Dilek]

On Thu, Sep 26, 2024 at 2:58 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Sep 26, 2024 at 2:49 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >
> > Do you offer a (an optimized - optimized for kernel-builds) prebuilt
> > RUST toolchain - preferable for x86-64 hosts - like Nathan +
> > LLVM/Clang folk offer (see [1],[2])?
>
> Yes, Nathan himself provides those! :)
>
>     https://mirrors.edge.kernel.org/pub/tools/llvm/rust/
>

Thanks for the link!
OK, I darkly remember seeing this somewhere.

> He may comment further -- I think the Rust compiler itself is not
> built (yet?) with PGO etc. like he does for the LLVM side.
>
> As usual -- thanks Nathan!
>
> > Maybe I have missed in [3] or overlooked.
>
> If you go into the Quick Start guide from your link, you will see it
> linked at the top:
>
>     https://docs.kernel.org/rust/quick-start.html
>
> I also mentioned these in LPC's Kernel Summit track (sorry, no
> video/stream yet, as far as I understand):
> https://lpc.events/event/18/contributions/1912/
>
> > [ Provocative ]
> > Can I REALLY use a RUST-compiled Linux-kernel on BARE METAL?
> > Do I need special hardware?
> > Do you have a working in sense of bootable linux-config file?
> > ^^ This is a real question - not interested in any "technical preview".
> > ^^ You do NOT need to answer all this!
>
> I am not sure what you mean -- people has been using Linux with Rust
> enabled in real hardware for quite a while, e.g. Android and Asahi,
> plus others are upcoming (Fedora, as far as I know), and I regularly
> test in CI that the kernel boots in QEMU for several architectures and
> configs that we already have in-tree.
>

Asahi or Fedora-Asahi?
Do you have a link to a Linux-Live-System or maybe a pointer to a kernel-config?

> I also regularly test in CI that the kernel can be built with
> `rustup`'s binaries, with several distro toolchains and with Nathan's
> toolchains too.
>

Is it possible to download a built VM (rustup-binary) and test in QEMU
for example?

I have NO experiences with RUST - but it looks like things/development
moved further.

Before I wanted to test gendwarfksyms-v3 from Sami.

Best regards and wishes,
-sed@-

Re: linux-next: build failure after merge of Linus' tree

[Miguel Ojeda]

On Thu, Sep 26, 2024 at 4:44 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> Thanks for the link!

You're welcome!

> Asahi or Fedora-Asahi?
> Do you have a link to a Linux-Live-System or maybe a pointer to a kernel-config?
>
> Is it possible to download a built VM (rustup-binary) and test in QEMU
> for example?

You should be able to build and boot your own kernels with Rust
enabled like you would normally do, as long as the requirements are
met.

But Rust for Linux is not a Linux distribution, if that is what you are asking.

Regarding Asahi and other users/distributions, I would suggest asking
them directly if you are interested in their setup.

For help on setting things up etc., I would suggest asking in our
Zulip -- please see https://rust-for-linux.com/contact.

Thanks!

Cheers,
Miguel

linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

Hi all,

With Linus' tree, today's linux-next build (powerpc allyesconfig) failed
like this:

drivers/infiniband/sw/built-in.o:(.opd+0x1698): multiple definition of `copy_data'
drivers/infiniband/hw/built-in.o:(.opd+0xe5f8): first defined here
drivers/infiniband/sw/built-in.o:(.opd+0x1320): multiple definition of `rxe_av_from_attr'
drivers/infiniband/hw/built-in.o:(.opd+0xe280): first defined here
drivers/infiniband/sw/built-in.o:(.opd+0x18d8): multiple definition of `rxe_do_task'
drivers/infiniband/hw/built-in.o:(.opd+0xe838): first defined here

and lots of others.

Caused by commit

  8700e3e7c485 ("Soft RoCE driver")

(which was never in linux-next :-()

I just disabled teh driver for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 8 Aug 2016 11:52:53 +1000
Subject: [PATCH] Disable the Soft RoCE driver

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/infiniband/Kconfig     | 1 -
 drivers/infiniband/sw/Makefile | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index 0c2e55c5354b..53ef194c5be1 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -86,7 +86,6 @@ source "drivers/infiniband/ulp/iser/Kconfig"
 source "drivers/infiniband/ulp/isert/Kconfig"
 
 source "drivers/infiniband/sw/rdmavt/Kconfig"
-source "drivers/infiniband/sw/rxe/Kconfig"
 
 source "drivers/infiniband/hw/hfi1/Kconfig"
 
diff --git a/drivers/infiniband/sw/Makefile b/drivers/infiniband/sw/Makefile
index 8b095b27db87..988b6a0101a4 100644
--- a/drivers/infiniband/sw/Makefile
+++ b/drivers/infiniband/sw/Makefile
@@ -1,2 +1 @@
 obj-$(CONFIG_INFINIBAND_RDMAVT)		+= rdmavt/
-obj-$(CONFIG_RDMA_RXE)			+= rxe/
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of Linus' tree

[Doug Ledford]

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

On 8/7/2016 9:58 PM, Stephen Rothwell wrote:
> Hi all,
> 
> With Linus' tree, today's linux-next build (powerpc allyesconfig) failed
> like this:
> 
> drivers/infiniband/sw/built-in.o:(.opd+0x1698): multiple definition of `copy_data'
> drivers/infiniband/hw/built-in.o:(.opd+0xe5f8): first defined here
> drivers/infiniband/sw/built-in.o:(.opd+0x1320): multiple definition of `rxe_av_from_attr'
> drivers/infiniband/hw/built-in.o:(.opd+0xe280): first defined here

This looks very suspicious.  I think you are picking up two copies of
the rxe code.  One from Linus tree and one from probably Leon's tree.
The thing is, the rxe driver is an entirely software RoCE driver.  So,
after I picked it up, I moved it from drivers/infiniband/hw to
drivers/infiniband/sw where it more correctly belongs.  Leon's tree
doesn't have that move, and since you pull Leon's tree into your -next
process, with the allyesconfig you are trying to build two copies of it
and put them both statically into the kernel, hence all of the double
definitions.  Leon needs to drop his copy of the rxe driver and let the
one in Linus' tree be the only one in existence.

> drivers/infiniband/sw/built-in.o:(.opd+0x18d8): multiple definition of `rxe_do_task'
> drivers/infiniband/hw/built-in.o:(.opd+0xe838): first defined here
> 
> and lots of others.
> 
> Caused by commit
> 
>   8700e3e7c485 ("Soft RoCE driver")
> 
> (which was never in linux-next :-()

The code was, just not that specific commit.  I both moved the code to
infiniband/sw and also squashed it all down to one commit.  After I did
the move/squash, I got 0day and local testing to make sure I didn't
break it in the move, but I didn't get linux next as I knew it had
already been through that and a move/squash should not break anything
that linux next is testing/checking.

Leon, please drop your rxe code out of your linux-next area so we can
eliminate this issue (or replace it with the final commit I submitted).

> I just disabled teh driver for today:

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 8 Aug 2016 11:52:53 +1000
> Subject: [PATCH] Disable the Soft RoCE driver
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/infiniband/Kconfig     | 1 -
>  drivers/infiniband/sw/Makefile | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
> index 0c2e55c5354b..53ef194c5be1 100644
> --- a/drivers/infiniband/Kconfig
> +++ b/drivers/infiniband/Kconfig
> @@ -86,7 +86,6 @@ source "drivers/infiniband/ulp/iser/Kconfig"
>  source "drivers/infiniband/ulp/isert/Kconfig"
>  
>  source "drivers/infiniband/sw/rdmavt/Kconfig"
> -source "drivers/infiniband/sw/rxe/Kconfig"
>  
>  source "drivers/infiniband/hw/hfi1/Kconfig"
>  
> diff --git a/drivers/infiniband/sw/Makefile b/drivers/infiniband/sw/Makefile
> index 8b095b27db87..988b6a0101a4 100644
> --- a/drivers/infiniband/sw/Makefile
> +++ b/drivers/infiniband/sw/Makefile
> @@ -1,2 +1 @@
>  obj-$(CONFIG_INFINIBAND_RDMAVT)		+= rdmavt/
> -obj-$(CONFIG_RDMA_RXE)			+= rxe/
> 


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: 0E572FDD


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

Re: linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

Hi Doug,

On Mon, 8 Aug 2016 11:37:33 -0400 Doug Ledford <dledford@redhat.com> wrote:
>
> On 8/7/2016 9:58 PM, Stephen Rothwell wrote:
> > 
> > With Linus' tree, today's linux-next build (powerpc allyesconfig) failed
> > like this:
> > 
> > drivers/infiniband/sw/built-in.o:(.opd+0x1698): multiple definition of `copy_data'
> > drivers/infiniband/hw/built-in.o:(.opd+0xe5f8): first defined here
> > drivers/infiniband/sw/built-in.o:(.opd+0x1320): multiple definition of `rxe_av_from_attr'
> > drivers/infiniband/hw/built-in.o:(.opd+0xe280): first defined here  
> 
> This looks very suspicious.  I think you are picking up two copies of
> the rxe code.  One from Linus tree and one from probably Leon's tree.

Actually the second copy is from your tree
(git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git#for-next),
Leon's trees are empty (relative to Linus' tree).  I guess when you
rebased and squashed things, you forgot to reset your for-next tag, so
I got the old version of your tree as well as the rebased version via
Linus' tree.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of Linus' tree

[Doug Ledford]

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

On 8/8/2016 5:53 PM, Stephen Rothwell wrote:
> Hi Doug,
> 
> On Mon, 8 Aug 2016 11:37:33 -0400 Doug Ledford <dledford@redhat.com> wrote:
>>
>> On 8/7/2016 9:58 PM, Stephen Rothwell wrote:
>>>
>>> With Linus' tree, today's linux-next build (powerpc allyesconfig) failed
>>> like this:
>>>
>>> drivers/infiniband/sw/built-in.o:(.opd+0x1698): multiple definition of `copy_data'
>>> drivers/infiniband/hw/built-in.o:(.opd+0xe5f8): first defined here
>>> drivers/infiniband/sw/built-in.o:(.opd+0x1320): multiple definition of `rxe_av_from_attr'
>>> drivers/infiniband/hw/built-in.o:(.opd+0xe280): first defined here  
>>
>> This looks very suspicious.  I think you are picking up two copies of
>> the rxe code.  One from Linus tree and one from probably Leon's tree.
> 
> Actually the second copy is from your tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git#for-next),
> Leon's trees are empty (relative to Linus' tree).  I guess when you
> rebased and squashed things, you forgot to reset your for-next tag, so
> I got the old version of your tree as well as the rebased version via
> Linus' tree.
> 

Doh!  My apologies, that would certainly explain it.  I'll reset my
for-next tag.


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: 0E572FDD


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

Re: linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

Hi Doug,

On Mon, 8 Aug 2016 19:30:57 -0400 Doug Ledford <dledford@redhat.com> wrote:
>
> Doh!  My apologies, that would certainly explain it.  I'll reset my
> for-next tag.

Thanks.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of Linus' tree

[Leon Romanovsky]

On Mon, Aug 8, 2016 at 6:37 PM, Doug Ledford <dledford@redhat.com> wrote:
> On 8/7/2016 9:58 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> With Linus' tree, today's linux-next build (powerpc allyesconfig) failed
>> like this:
>>
>> drivers/infiniband/sw/built-in.o:(.opd+0x1698): multiple definition of `copy_data'
>> drivers/infiniband/hw/built-in.o:(.opd+0xe5f8): first defined here
>> drivers/infiniband/sw/built-in.o:(.opd+0x1320): multiple definition of `rxe_av_from_attr'
>> drivers/infiniband/hw/built-in.o:(.opd+0xe280): first defined here
>
> This looks very suspicious.  I think you are picking up two copies of
> the rxe code.  One from Linus tree and one from probably Leon's tree.
> The thing is, the rxe driver is an entirely software RoCE driver.  So,
> after I picked it up, I moved it from drivers/infiniband/hw to
> drivers/infiniband/sw where it more correctly belongs.  Leon's tree
> doesn't have that move, and since you pull Leon's tree into your -next
> process, with the allyesconfig you are trying to build two copies of it
> and put them both statically into the kernel, hence all of the double
> definitions.  Leon needs to drop his copy of the rxe driver and let the
> one in Linus' tree be the only one in existence.

Doug,
Just to be clear on this point and on my flow.
I'm resetting my ->next branches on the same day of your email
announcement of acceptance.

Thanks

Re: linux-next: build failure after merge of Linus' tree

[Doug Ledford]

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

On 8/9/2016 4:54 AM, Leon Romanovsky wrote:
> On Mon, Aug 8, 2016 at 6:37 PM, Doug Ledford <dledford@redhat.com> wrote:
>> On 8/7/2016 9:58 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> With Linus' tree, today's linux-next build (powerpc allyesconfig) failed
>>> like this:
>>>
>>> drivers/infiniband/sw/built-in.o:(.opd+0x1698): multiple definition of `copy_data'
>>> drivers/infiniband/hw/built-in.o:(.opd+0xe5f8): first defined here
>>> drivers/infiniband/sw/built-in.o:(.opd+0x1320): multiple definition of `rxe_av_from_attr'
>>> drivers/infiniband/hw/built-in.o:(.opd+0xe280): first defined here
>>
>> This looks very suspicious.  I think you are picking up two copies of
>> the rxe code.  One from Linus tree and one from probably Leon's tree.
>> The thing is, the rxe driver is an entirely software RoCE driver.  So,
>> after I picked it up, I moved it from drivers/infiniband/hw to
>> drivers/infiniband/sw where it more correctly belongs.  Leon's tree
>> doesn't have that move, and since you pull Leon's tree into your -next
>> process, with the allyesconfig you are trying to build two copies of it
>> and put them both statically into the kernel, hence all of the double
>> definitions.  Leon needs to drop his copy of the rxe driver and let the
>> one in Linus' tree be the only one in existence.
> 
> Doug,
> Just to be clear on this point and on my flow.
> I'm resetting my ->next branches on the same day of your email
> announcement of acceptance.

Ok, thanks for the clarification.  As it turned out, I needed to reset
my for-next tag.


-- 
Doug Ledford <dledford@redhat.com>
    GPG Key ID: 0E572FDD


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

linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

Hi Linus,

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

lib/string.c: In function 'strscpy':
lib/string.c:209:4: error: implicit declaration of function 'zero_bytemask' [-Werror=implicit-function-declaration]
    *(unsigned long *)(dest+res) = c & zero_bytemask(data);
    ^

Caused by commit

  30035e45753b ("string: provide strscpy()")

but only exposed by commit

  19c22f3a29fa ("word-at-a-time.h: fix some Kbuild files")

BIG_ENDIAN powerpc doesn't have a definition for this function ...

Isn't this why we have linux-next ... to find this stuff early?  :-(

Oh, well, I have applied the following (that just copies zero_bytemask
from asm-generic.  I have done no testing beyond compiling.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Oct 2015 09:29:26 +1100
Subject: [PATCH] word-at-a-time.h: powerpc: implement define zero_bytemask

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/include/asm/word-at-a-time.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/include/asm/word-at-a-time.h b/arch/powerpc/include/asm/word-at-a-time.h
index 5b3a903adae6..4f9b6b93c18f 100644
--- a/arch/powerpc/include/asm/word-at-a-time.h
+++ b/arch/powerpc/include/asm/word-at-a-time.h
@@ -40,6 +40,8 @@ static inline bool has_zero(unsigned long val, unsigned long *data, const struct
 	return (val + c->high_bits) & ~rhs;
 }
 
+#define zero_bytemask(mask) (~1ul << __fls(mask))
+
 #else
 
 #ifdef CONFIG_64BIT
-- 
2.5.1

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