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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1512667802.2624.20.camel@wdc.com>
Date:   Thu, 7 Dec 2017 17:30:03 +0000
From:   Bart Van Assche <Bart.VanAssche@....com>
To:     "sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
        "paulmck@...ux.vnet.ibm.com" <paulmck@...ux.vnet.ibm.com>
CC:     "josh@...htriplett.org" <josh@...htriplett.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "ptikhomirov@...tuozzo.com" <ptikhomirov@...tuozzo.com>
Subject: Re: linux-next: build failure after merge of the scsi-mkp tree

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@....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@...ux.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@....com>
>     Reported-by: Stephen Rothwell <sfr@...b.auug.org.au>
>     Signed-off-by: Paul E. McKenney <paulmck@...ux.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.