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

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

[Bart Van Assche]

On Wed, 2017-12-06 at 20:42 -0800, Paul E. McKenney wrote:
> On Thu, Dec 07, 2017 at 03:25:21PM +1100, Stephen Rothwell wrote:
> > On Thu, 7 Dec 2017 03:59:30 +0000 Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> > > On Thu, 2017-12-07 at 14:57 +1100, Stephen Rothwell wrote:
> > > > After merging the scsi-mkp tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> > > > ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> > > > 
> > > > Caused by commit
> > > > 
> > > >   ac90420f17c9 ("scsi: core: Ensure that the SCSI error handler gets woken up")
> > > > 
> > > > I have used the scsi-mkp tree from next-20171206 for today.  
> > > 
> > > Does that mean I'm the first one who added RCU code to the SCSI core?
> > 
> > The only other uses of init_rcu_head() are in drivers/iommu/intel-svm.c
> > and kernel/irq/irqdesc.c.  destroy_rcu_head() appears to not be used
> > anywhere ...
> 
> The key point is that Bart appears to be the first to try using them in
> a module, for which exports are needed.  Does the patch below help?
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit cde4691a3a4591e7355295dd62610e3262159002
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date:   Wed Dec 6 20:39:38 2017 -0800
> 
>     rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
>     
>     Use of init_rcu_head() and destroy_rcu_head() from modules results in
>     the following build-time error:
>     
>     	ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
>     	ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
>     
>     This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them
>     to be used by GPL-licensed kernel modules.
>     
>     Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
>     Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index 8d591d8411fe..4c4d26e9a67b 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head)
>  {
>  	debug_object_init(head, &rcuhead_debug_descr);
>  }
> +EXPORT_SYMBOL_GPL(init_rcu_head);
>  
>  void destroy_rcu_head(struct rcu_head *head)
>  {
>  	debug_object_free(head, &rcuhead_debug_descr);
>  }
> +EXPORT_SYMBOL_GPL(destroy_rcu_head);
>  
>  static bool rcuhead_is_static_object(void *addr)
>  {

(+linux-scsi)

Hello Paul,

How about changing the commit message into "... fixes a build failure with
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y"? Otherwise the above patch looks fine to me
and fixes the reported build failure on my setup.

However, what's not clear to me is through which tree this patch should be
sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
Martin perhaps queue it in his tree for v4.16-rc1?

Thanks,

Bart.

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

[Paul E. McKenney]

On Thu, Dec 07, 2017 at 05:30:03PM +0000, Bart Van Assche wrote:
> On Wed, 2017-12-06 at 20:42 -0800, Paul E. McKenney wrote:
> > On Thu, Dec 07, 2017 at 03:25:21PM +1100, Stephen Rothwell wrote:
> > > On Thu, 7 Dec 2017 03:59:30 +0000 Bart Van Assche <Bart.VanAssche@wdc.com> wrote:

[ . . . ]

> > commit cde4691a3a4591e7355295dd62610e3262159002
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date:   Wed Dec 6 20:39:38 2017 -0800
> > 
> >     rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
> >     
> >     Use of init_rcu_head() and destroy_rcu_head() from modules results in
> >     the following build-time error:
> >     
> >     	ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> >     	ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> >     
> >     This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them
> >     to be used by GPL-licensed kernel modules.
> >     
> >     Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
> >     Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > 
> > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> > index 8d591d8411fe..4c4d26e9a67b 100644
> > --- a/kernel/rcu/update.c
> > +++ b/kernel/rcu/update.c
> > @@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head)
> >  {
> >  	debug_object_init(head, &rcuhead_debug_descr);
> >  }
> > +EXPORT_SYMBOL_GPL(init_rcu_head);
> >  
> >  void destroy_rcu_head(struct rcu_head *head)
> >  {
> >  	debug_object_free(head, &rcuhead_debug_descr);
> >  }
> > +EXPORT_SYMBOL_GPL(destroy_rcu_head);
> >  
> >  static bool rcuhead_is_static_object(void *addr)
> >  {
> 
> (+linux-scsi)
> 
> Hello Paul,
> 
> How about changing the commit message into "... fixes a build failure with
> CONFIG_DEBUG_OBJECTS_RCU_HEAD=y"? Otherwise the above patch looks fine to me
> and fixes the reported build failure on my setup.

I have updated it as shown below.

> However, what's not clear to me is through which tree this patch should be
> sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
> Martin perhaps queue it in his tree for v4.16-rc1?

I have to defer to you guys on that one.  Left to myself, I will just
push it into the next merge window (as opposed to using my normal process,
which at this point would get it into the one following).

So please let me know how you would like to proceed.

							Thanx, Paul

------------------------------------------------------------------------

commit 193dffdf4354f14b4f3369a85128817e5ba74e58
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Wed Dec 6 20:39:38 2017 -0800

    rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
    
    Use of init_rcu_head() and destroy_rcu_head() from modules results in
    the following build-time error with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y:
    
    	ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
    	ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
    
    This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them
    to be used by GPL-licensed kernel modules.
    
    Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 8d591d8411fe..4c4d26e9a67b 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head)
 {
 	debug_object_init(head, &rcuhead_debug_descr);
 }
+EXPORT_SYMBOL_GPL(init_rcu_head);
 
 void destroy_rcu_head(struct rcu_head *head)
 {
 	debug_object_free(head, &rcuhead_debug_descr);
 }
+EXPORT_SYMBOL_GPL(destroy_rcu_head);
 
 static bool rcuhead_is_static_object(void *addr)
 {

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

[Stephen Rothwell]

Hi all,

On Thu, 7 Dec 2017 09:40:38 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> On Thu, Dec 07, 2017 at 05:30:03PM +0000, Bart Van Assche wrote:
> > However, what's not clear to me is through which tree this patch should be
> > sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
> > Martin perhaps queue it in his tree for v4.16-rc1?  
> 
> I have to defer to you guys on that one.  Left to myself, I will just
> push it into the next merge window (as opposed to using my normal process,
> which at this point would get it into the one following).
> 
> So please let me know how you would like to proceed.

Clearly, it needs to go via Martin's tree as otherwise his tree will
not build in some circumstances ... or if it going to cause problems
for Paul, then it should be in a separate non-rebasing branch (probably
of Paul's tree) that is merged into Pauls main branch and Marin's tree.
-- 
Cheers,
Stephen Rothwell

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

[Paul E. McKenney]

On Fri, Dec 08, 2017 at 07:34:39AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 7 Dec 2017 09:40:38 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > On Thu, Dec 07, 2017 at 05:30:03PM +0000, Bart Van Assche wrote:
> > > However, what's not clear to me is through which tree this patch should be
> > > sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
> > > Martin perhaps queue it in his tree for v4.16-rc1?  
> > 
> > I have to defer to you guys on that one.  Left to myself, I will just
> > push it into the next merge window (as opposed to using my normal process,
> > which at this point would get it into the one following).
> > 
> > So please let me know how you would like to proceed.
> 
> Clearly, it needs to go via Martin's tree as otherwise his tree will
> not build in some circumstances ... or if it going to cause problems
> for Paul, then it should be in a separate non-rebasing branch (probably
> of Paul's tree) that is merged into Pauls main branch and Marin's tree.

It is unlikely to cause problems, so please let it go up where convenient.

Just please let me know.

							Thanx, Paul

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

[Martin K. Petersen]

Stephen,

>> I have to defer to you guys on that one.  Left to myself, I will just
>> push it into the next merge window (as opposed to using my normal
>> process, which at this point would get it into the one following).
>> 
>> So please let me know how you would like to proceed.
>
> Clearly, it needs to go via Martin's tree as otherwise his tree will
> not build in some circumstances ... or if it going to cause problems
> for Paul, then it should be in a separate non-rebasing branch (probably
> of Paul's tree) that is merged into Pauls main branch and Marin's tree.

I'm perfectly OK with taking it through the SCSI tree. Probably the path
of least resistance.

-- 
Martin K. Petersen	Oracle Linux Engineering

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

[Martin K. Petersen]

> I'm perfectly OK with taking it through the SCSI tree. Probably the
> path of least resistance.

Applied to 4.16/scsi-queue and rebased so it sits before Bart's patch.

-- 
Martin K. Petersen	Oracle Linux Engineering

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

[Paul E. McKenney]

On Thu, Dec 07, 2017 at 08:00:50PM -0500, Martin K. Petersen wrote:
> 
> > I'm perfectly OK with taking it through the SCSI tree. Probably the
> > path of least resistance.
> 
> Applied to 4.16/scsi-queue and rebased so it sits before Bart's patch.

Thank you!  I have removed this patch from -rcu.

							Thanx, Paul

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

[John Garry]

On 17/08/2021 10:47, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/byteorder/big_endian.h:5,
>                   from arch/powerpc/include/uapi/asm/byteorder.h:14,
>                   from include/asm-generic/bitops/le.h:7,
>                   from arch/powerpc/include/asm/bitops.h:265,
>                   from include/linux/bitops.h:33,
>                   from include/linux/kernel.h:12,
>                   from include/linux/list.h:9,
>                   from include/linux/module.h:12,
>                   from drivers/scsi/ibmvscsi/ibmvfc.c:10:
> drivers/scsi/ibmvscsi/ibmvfc.c: In function 'ibmvfc_queuecommand':
> drivers/scsi/ibmvscsi/ibmvfc.c:1959:39: error: 'struct scsi_cmnd' has no member named 'tag'
>   1959 |   vfc_cmd->task_tag = cpu_to_be64(cmnd->tag);
>        |                                       ^~
> include/uapi/linux/byteorder/big_endian.h:37:51: note: in definition of macro '__cpu_to_be64'
>     37 | #define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
>        |                                                   ^
> drivers/scsi/ibmvscsi/ibmvfc.c:1959:23: note: in expansion of macro 'cpu_to_be64'
>   1959 |   vfc_cmd->task_tag = cpu_to_be64(cmnd->tag);
>        |                       ^~~~~~~~~~~
> 
> Caused by commit
> 
>    c7c43e3c7147 ("scsi: core: Remove scsi_cmnd.tag")
> 
> I have used the scsi-mkp tree from next-20210816 for today.
> 

sorry... I only built x86 and arm64 allmodconfig. Let me check this.

Thanks

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

[Bart Van Assche]

On 8/17/21 2:51 AM, John Garry wrote:
> sorry... I only built x86 and arm64 allmodconfig. Let me check this.

Build testing for tree-wide changes is tricky. You may want to use a
build bot for such testing. From
https://01.org/lkp/documentation/0-day-test-service:

Q: Which git tree and which mailing list will be tested? How can I
opt-in or opt-out from it?

A: 0-Day monitors hundreds of git trees and tens of mailing lists. You
can obtain detailed tree and mailing list information from the source
code under the lkp-tests/repo directory. If you want to add or remove
your tree from the 0-Day test system, send an email to the LKML,
specifying your git tree URL.

Bart.

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

[John Garry]

On 18/08/2021 04:07, Bart Van Assche wrote:
> On 8/17/21 2:51 AM, John Garry wrote:
>> sorry... I only built x86 and arm64 allmodconfig. Let me check this.
> Build testing for tree-wide changes is tricky. You may want to use a
> build bot for such testing. From
> https://01.org/lkp/documentation/0-day-test-service:
> 
> Q: Which git tree and which mailing list will be tested? How can I
> opt-in or opt-out from it?
> 
> A: 0-Day monitors hundreds of git trees and tens of mailing lists. You
> can obtain detailed tree and mailing list information from the source
> code under the lkp-tests/repo directory. If you want to add or remove
> your tree from the 0-Day test system, send an email to the LKML,
> specifying your git tree URL.

Thanks for the info! Quite useful.

Unfortunately there is code which has internal build switches - like 
qla1280.c and DEBUG_QLA1280, which Martin mentioned - so harder to spot. 
I suppose that's the risk with internal build switches.

Thanks again,
John