linux-kernel - Re: [PATCH 06/15] MIPS: CM: Fix mips_cm_max_vp

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160203154634.GC30470@NP-P-BURTON>
Date:	Wed, 3 Feb 2016 15:46:34 +0000
From:	Paul Burton <paul.burton@...tec.com>
To:	James Hogan <james.hogan@...tec.com>
CC:	<linux-mips@...ux-mips.org>, Ralf Baechle <ralf@...ux-mips.org>,
	"Matt Redfearn" <matt.redfearn@...tec.com>,
	<linux-kernel@...r.kernel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	Markos Chandras <markos.chandras@...tec.com>
Subject: Re: [PATCH 06/15] MIPS: CM: Fix mips_cm_max_vp_width for UP kernels

On Wed, Feb 03, 2016 at 02:58:59PM +0000, James Hogan wrote:
> On Wed, Feb 03, 2016 at 03:15:26AM +0000, Paul Burton wrote:
> > Fix mips_cm_max_vp_width for UP kernels where it previously referenced
> > smp_num_siblings, which is not declared for UP kernels. This led to
> > build errors such as the following:
> > 
> >   drivers/built-in.o: In function `$L446':
> >   irq-mips-gic.c:(.text+0x1994): undefined reference to `smp_num_siblings'
> >   drivers/built-in.o:irq-mips-gic.c:(.text+0x199c): more undefined references to `smp_num_siblings' follow
> > 
> > On UP kernels simply return 1, leaving the reference to smp_num_siblings
> > in place only for SMP kernels.
> > 
> > Signed-off-by: Paul Burton <paul.burton@...tec.com>
> 
> Need tagging for stable v4.3+?

It happens that there were no uses of mips_cm_max_vp_width in UP
kernels, but some are added later in this series (the next patch for
instance). So I don't see a need to backport to stable branches. Sorry
that could have been clearer.

> I do wonder if this should be handled in the header files though...

As in you don't think it should be handled in headers? It seems like the
logical place to do it to me...

Or do you mean smp_num_siblings should be defined as 1 for UP kernels? I
did consider that approach, but thought this possibly more semantically
correct since smp isn't in use at all so neither is smp_num_siblings.

Thanks,
    Paul

> Cheers
> James
> 
> > ---
> > 
> >  arch/mips/include/asm/mips-cm.h | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/mips/include/asm/mips-cm.h b/arch/mips/include/asm/mips-cm.h
> > index 1395bbc..3fdb6c9 100644
> > --- a/arch/mips/include/asm/mips-cm.h
> > +++ b/arch/mips/include/asm/mips-cm.h
> > @@ -462,7 +462,10 @@ static inline unsigned int mips_cm_max_vp_width(void)
> >  	if (mips_cm_revision() >= CM_REV_CM3)
> >  		return read_gcr_sys_config2() & CM_GCR_SYS_CONFIG2_MAXVPW_MSK;
> >  
> > -	return smp_num_siblings;
> > +	if (config_enabled(CONFIG_SMP))
> > +		return smp_num_siblings;
> > +
> > +	return 1;
> >  }
> >  
> >  /**
> > -- 
> > 2.7.0
> > 
> >