Hi Paul,
After merging the rcu tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
from arch/powerpc/kernel/setup_64.c:68:
include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
struct srcu_struct srcu;
^
include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
struct srcu_struct irq_srcu;
^
Caused by commit f01a973369dd ("srcu: Isolate srcu sections using
CONFIG_SRCU"). Please stop readding that commit after until it is
fixed :-(
I have reverted that commit for today (again :-().
--
Cheers,
Stephen Rothwell [email protected]
On Fri, Dec 26, 2014 at 06:51:20PM +1100, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the rcu tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
> from arch/powerpc/kernel/setup_64.c:68:
> include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type
> struct srcu_struct srcu;
> ^
> include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type
> struct srcu_struct irq_srcu;
> ^
>
> Caused by commit f01a973369dd ("srcu: Isolate srcu sections using
> CONFIG_SRCU"). Please stop readding that commit after until it is
> fixed :-(
>
> I have reverted that commit for today (again :-().
Hello, Stephen,
Please accept my apologies for the hassle! I had removed that commit
for the duration of the merge window, and forgotten about it when I
re-added all my non-3.19 commits. :-/
Could you please send your .config? Or let me know whether it has
CONFIG_KVM=n?
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?
Thanx, Paul
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.
I will send the updated patch once I've done some basic tests. Sorry
for the delay!
--
Pranith
On Sat, Dec 27, 2014 at 11:24 AM, Pranith Kumar <[email protected]> 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?
--
Pranith
On Sat, Dec 27, 2014 at 12:20:50PM -0500, Pranith Kumar wrote:
> On Sat, Dec 27, 2014 at 11:24 AM, Pranith Kumar <[email protected]> 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