linux-kernel - Re: linux-next: build failure after merge of the rcu 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20141231014521.GL11609@linux.vnet.ibm.com>
Date:	Tue, 30 Dec 2014 17:45:21 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Pranith Kumar <bobby.prani@...il.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the rcu tree

On Sat, Dec 27, 2014 at 12:20:50PM -0500, Pranith Kumar wrote:
> On Sat, Dec 27, 2014 at 11:24 AM, Pranith Kumar <bobby.prani@...il.com> wrote:
> > On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote:
> >> Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
> >> "select SRCU" to "config PPC" in arch/powerpc/Kconfig.  Are you able
> >> to cross-build powerpc?
> >>
> >
> > ppc 32 seems fine without selecting srcu unconditionally. So I added
> > this select to PPC 64 which should fix this build failure.
> 
> On looking at this further, I was able to figure out the parts on
> ppc64 utilizing KVM and enabled them dependent on CONFIG_KVM being
> enabled. I tested this with a ppc64 allnoconfig and it built
> succesfully (depending on a unrelated patch to enable printk for
> powernv).
> 
> I've sent the patch but it still seems that we will be playing
> whack-a-mole for now with code which uses KVM indepedent of
> CONFIG_KVM. May be fixing it incrementally is a better option than
> lumping all these together?

For PPC64, I suggest starting with something that can be trivially shown
to work, even if it consumes more memory than required.  The PPC64 systems
almost always have an abundance of memory, so having SRCU unnecessarily
built into the system is not all that bad -- and is what happens today
anyway.

Given that starting point, you can then build a more precise patch for
PPC64 on top of the starting-point patch.

Make sense?

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/