Re: [PATCH v3] selftests: powerpc: Fix CPU affinity for child process

[Kamalesh Babulal]

On 6/9/20 1:44 PM, Harish wrote:
> On systems with large number of cpus, test fails trying to set
> affinity by calling sched_setaffinity() with smaller size for
> affinity mask. This patch fixes it by making sure that the size of
> allocated affinity mask is dependent on the number of CPUs as
> reported by get_nprocs().
> 
> Fixes: 00b7ec5c9cf3 ("selftests/powerpc: Import Anton's context_switch2 
> benchmark")
> Reported-by: Shirisha Ganta 
> Signed-off-by: Sandipan Das 
> Signed-off-by: Harish 

LGTM,

Reviewed-by: Kamalesh Babulal 

-- 
Kamalesh

Re: [PATCH v2] selftests: powerpc: Fix CPU affinity for child process

[Kamalesh Babulal]

On 6/9/20 9:10 AM, Harish wrote:
> On systems with large number of cpus, test fails trying to set
> affinity for child process by calling sched_setaffinity() with 
> smaller size for cpuset. This patch fixes it by making sure that
> the size of allocated cpu set is dependent on the number of CPUs
> as reported by get_nprocs().
> 
> Fixes: 00b7ec5c9cf3 ("selftests/powerpc: Import Anton's context_switch2 
> benchmark")
> Reported-by: Shirisha Ganta 
> Signed-off-by: Harish 
> Signed-off-by: Sandipan Das 
> ---
>  .../powerpc/benchmarks/context_switch.c| 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/testing/selftests/powerpc/benchmarks/context_switch.c 
> b/tools/testing/selftests/powerpc/benchmarks/context_switch.c
> index a2e8c9da7fa5..de6c49d6f88f 100644
> --- a/tools/testing/selftests/powerpc/benchmarks/context_switch.c
> +++ b/tools/testing/selftests/powerpc/benchmarks/context_switch.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -104,8 +105,9 @@ static void start_thread_on(void *(*fn)(void *), void 
> *arg, unsigned long cpu)
> 
>  static void start_process_on(void *(*fn)(void *), void *arg, unsigned long 
> cpu)
>  {
> - int pid;
> - cpu_set_t cpuset;
> + int pid, ncpus;
> + cpu_set_t *cpuset;
> + size_t size;
> 
>   pid = fork();
>   if (pid == -1) {
> @@ -116,12 +118,16 @@ static void start_process_on(void *(*fn)(void *), void 
> *arg, unsigned long cpu)
>   if (pid)
>   return;
> 
> - CPU_ZERO();
> - CPU_SET(cpu, );
> + size = CPU_ALLOC_SIZE(ncpus);
> + ncpus = get_nprocs();
> + cpuset = CPU_ALLOC(ncpus);

CPU_ALLOC() allocation failure needs to be checked, like malloc() allocations.

> + CPU_ZERO_S(size, cpuset);
> + CPU_SET_S(cpu, size, cpuset);
> 
> - if (sched_setaffinity(0, sizeof(cpuset), )) {
> + if (sched_setaffinity(0, size, cpuset)) {
>   perror("sched_setaffinity");
> - exit(1);
> + CPU_FREE(cpuset);
> + exit(-1);
>   }

once the cpu affinity is set, you probably want to free the cpuset mask.

> 
>   fn(arg);
> 
-- 
Kamalesh

Re: [PATCH] selftests: powerpc: Fix online CPU selection

[Kamalesh Babulal]

On 6/8/20 8:12 PM, Sandipan Das wrote:
> The size of the cpu set must be large enough for systems
> with a very large number of CPUs. Otherwise, tests which
> try to determine the first online CPU by calling
> sched_getaffinity() will fail. This makes sure that the
> size of the allocated cpu set is dependent on the number
> of CPUs as reported by get_nprocs().
> 
> Fixes: 3752e453f6ba ("selftests/powerpc: Add tests of PMU EBBs")
> Reported-by: Shirisha Ganta 
> Signed-off-by: Sandipan Das 

LGTM,

Reviewed-by: Kamalesh Babulal 

-- 
Kamalesh

Re: [PATCH v5 0/5] Track and expose idle PURR and SPURR ticks

[Kamalesh Babulal]

On 4/7/20 2:17 PM, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" 
> 
> Hi,
> 
> This is the fifth version of the patches to track and expose idle PURR
> and SPURR ticks. These patches are required by tools such as lparstat
> to compute system utilization for capacity planning purposes.
> 
> The previous versions can be found here:
> v4: https://lkml.org/lkml/2020/3/27/323
> v3: https://lkml.org/lkml/2020/3/11/331
> v2: https://lkml.org/lkml/2020/2/21/21
> v1: https://lore.kernel.org/patchwork/cover/1159341/
> 
> They changes from v4 are:
> 
>- As suggested by Naveen, moved the functions read_this_idle_purr()
>  and read_this_idle_spurr() from Patch 2 and Patch 3 respectively
>  to Patch 4 where it is invoked.
> 
>- Dropped Patch 6 which cached the values of purr, spurr,
>  idle_purr, idle_spurr in order to minimize the number of IPIs
>  sent.
> 
>- Updated the dates for the idle_purr, idle_spurr in the
>  Documentation Patch 5.
> 
> Motivation:
> ===
> On PSeries LPARs, the data centers planners desire a more accurate
> view of system utilization per resource such as CPU to plan the system
> capacity requirements better. Such accuracy can be obtained by reading
> PURR/SPURR registers for CPU resource utilization.
> 
> Tools such as lparstat which are used to compute the utilization need
> to know [S]PURR ticks when the cpu was busy or idle. The [S]PURR
> counters are already exposed through sysfs.  We already account for
> PURR ticks when we go to idle so that we can update the VPA area. This
> patchset extends support to account for SPURR ticks when idle, and
> expose both via per-cpu sysfs files.
> 
> These patches are required for enhancement to the lparstat utility
> that compute the CPU utilization based on PURR and SPURR which can be
> found here :
> https://groups.google.com/forum/#!topic/powerpc-utils-devel/fYRo69xO9r4
> 
> 
> With the patches, when lparstat is run on a LPAR running CPU-Hogs,
> =
> sudo ./src/lparstat -E 1 3
> 
> System Configuration
> type=Dedicated mode=Capped smt=8 lcpu=2 mem=4834112 kB cpus=0 ent=2.00 
> 
> ---Actual--- -Normalized-
> %busy  %idle   Frequency %busy  %idle
> -- --  - -- --
> 1  99.99   0.00  3.35GHz[111%] 110.99   0.00
> 2 100.00   0.00  3.35GHz[111%] 111.01   0.00
> 3 100.00   0.00  3.35GHz[111%] 111.00   0.00
> 
> With patches, when lparstat is run on and idle LPAR
> =
> System Configuration
> type=Dedicated mode=Capped smt=8 lcpu=2 mem=4834112 kB cpus=0 ent=2.00 
> ---Actual--- -Normalized-
> %busy  %idle   Frequency %busy  %idle
> -- --  - -- --
> 1   0.15  99.84  2.17GHz[ 72%]   0.11  71.89
> 2   0.24  99.76  2.11GHz[ 70%]   0.18  69.82
> 3   0.24  99.75  2.11GHz[ 70%]   0.18  69.81
> 
> Gautham R. Shenoy (5):
>   powerpc: Move idle_loop_prolog()/epilog() functions to header file
>   powerpc/idle: Store PURR snapshot in a per-cpu global variable
>   powerpc/pseries: Account for SPURR ticks on idle CPUs
>   powerpc/sysfs: Show idle_purr and idle_spurr for every CPU
>   Documentation: Document sysfs interfaces purr, spurr, idle_purr,
> idle_spurr
> 
>  Documentation/ABI/testing/sysfs-devices-system-cpu | 39 +
>  arch/powerpc/include/asm/idle.h| 93 
> ++
>  arch/powerpc/kernel/sysfs.c| 82 ++-
>  arch/powerpc/platforms/pseries/setup.c |  8 +-
>  drivers/cpuidle/cpuidle-pseries.c  | 39 ++---
>  5 files changed, 224 insertions(+), 37 deletions(-)
>  create mode 100644 arch/powerpc/include/asm/idle.h
> 

Hi Gautham,

Thanks for working on it, I tested it using the lparstat patches posted at:
https://groups.google.com/forum/#!topic/powerpc-utils-devel/_imHP1Guw3c

On idle system:
===
sudo ./src/lparstat -E 1 3

System Configuration
type=Dedicated mode=Capped smt=8 lcpu=2 mem=4324928 kB cpus=0 ent=2.00 

---Actual--- -Normalized-
%busy  %idle   Frequency %busy  %idle
-- --  - -- --
  0.27  99.74  2.11GHz[ 70%]   0.24  69.76
  0.57  99.43  2.17GHz[ 72%]   0.43  71.57
  0.52  99.47  2.11GHz[ 70%]   0.38  69.62


On system running N while(1) (N == online cpus)
===
sudo ./src/lparstat -E 1 3

System Configuration
type=Dedicated mode=Capped smt=8 lcpu=2 mem=4324928 kB cpus=0 ent=2.00 

---Actual--- -Normalized-
%busy  %idle   Frequency %busy  %idle
-- --  - -- --
 99.99   0.00  3.35GHz[111%] 110.99   0.00
100.00   0.00  3.35GHz[111%] 111.00   0.00
100.00   0.00  3.35GHz[111%] 111.00   0.00


For the series:
Reviewed-and-Tested-by: Kamalesh Babulal 

-- 
Kamalesh

Re: [PATCH v2 0/5] Track and expose idle PURR and SPURR ticks

[Kamalesh Babulal]

On 2/21/20 10:48 AM, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" 

[...]

> 
> Gautham R. Shenoy (5):
>   powerpc: Move idle_loop_prolog()/epilog() functions to header file
>   powerpc/idle: Add accessor function to always read latest idle PURR
>   powerpc/pseries: Account for SPURR ticks on idle CPUs
>   powerpc/sysfs: Show idle_purr and idle_spurr for every CPU
>   Documentation: Document sysfs interfaces purr, spurr, idle_purr,
> idle_spurr
> 
>  Documentation/ABI/testing/sysfs-devices-system-cpu | 39 ++
>  arch/powerpc/include/asm/idle.h| 88 
> ++
>  arch/powerpc/kernel/sysfs.c| 54 -
>  arch/powerpc/platforms/pseries/setup.c |  8 +-
>  drivers/cpuidle/cpuidle-pseries.c  | 39 ++
>  5 files changed, 191 insertions(+), 37 deletions(-)
>  create mode 100644 arch/powerpc/include/asm/idle.h
> 

For the whole series:

Tested-by: Kamalesh Babulal 

-- 
Kamalesh

Re: [PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks

[Kamalesh Babulal]

On 12/6/19 2:44 PM, Naveen N. Rao wrote:
> Naveen N. Rao wrote:
>> Hi Nathan,
>>
>> Nathan Lynch wrote:
>>> Hi Kamalesh,
>>>
>>> Kamalesh Babulal  writes:
>>>> On 12/5/19 3:54 AM, Nathan Lynch wrote:
>>>>> "Gautham R. Shenoy"  writes:
>>>>>>
>>>>>> Tools such as lparstat which are used to compute the utilization need
>>>>>> to know [S]PURR ticks when the cpu was busy or idle. The [S]PURR
>>>>>> counters are already exposed through sysfs.  We already account for
>>>>>> PURR ticks when we go to idle so that we can update the VPA area. This
>>>>>> patchset extends support to account for SPURR ticks when idle, and
>>>>>> expose both via per-cpu sysfs files.
>>>>>
>>>>> Does anything really want to use PURR instead of SPURR? Seems like we
>>>>> should expose only SPURR idle values if possible.
>>>>>
>>>>
>>>> lparstat is one of the consumers of PURR idle metric
>>>> (https://groups.google.com/forum/#!topic/powerpc-utils-devel/fYRo69xO9r4). 
>>>> Agree, on the argument that system utilization metrics based on SPURR
>>>> accounting is accurate in comparison to PURR, which isn't proportional to
>>>> CPU frequency.  PURR has been traditionally used to understand the system
>>>> utilization, whereas SPURR is used for understanding how much capacity is
>>>> left/exceeding in the system based on the current power saving mode.
>>>
>>> I'll phrase my question differently: does SPURR complement or supercede
>>> PURR? You seem to be saying they serve different purposes. If PURR is
>>> actually useful rather then vestigial then I have no objection to
>>> exposing idle_purr.
>>
>> SPURR complements PURR, so we need both. SPURR/PURR ratio helps provide an 
>> indication of the available headroom in terms of core resources, at maximum 
>> frequency.
> 
> Re-reading this today morning, I realize that this isn't entirely accurate. 
> SPURR alone is sufficient to understand core resource utilization.
> 
> Kamalesh is using PURR to display non-normalized utilization values (under 
> 'actual' column), as reported by lparstat on AIX. I am not entirely sure if 
> it is ok to derive these based on the SPURR busy/idle ratio.

Both idle_purr and idle_spurr complement each other and we need to expose both 
of them.
It will improve the accounting accuracy of tools currently consuming 
system-wide PURR
and/or SPURR numbers to report system usage.  Deriving one from another, from my
experience makes it hard for tools or any custom scripts to give an accurate 
system view.
One tool I am aware of is lparstat, which uses PURR based metrics.

-- 
Kamalesh

Re: [PATCH FIX] KVM: PPC: Book3S HV: Release lock on page-out failure path

[Kamalesh Babulal]

On 1/22/20 10:25 AM, Bharata B Rao wrote:
> When migrate_vma_setup() fails in kvmppc_svm_page_out(),
> release kvm->arch.uvmem_lock before returning.
> 
> Fixes: ca9f4942670 ("KVM: PPC: Book3S HV: Support for running secure guests")
> Signed-off-by: Bharata B Rao 

Reviewed-by: Kamalesh Babulal 

-- 
Kamalesh

Re: [PATCH v2] selftests: vm: Fix 64-bit test builds for powerpc64le

[Kamalesh Babulal]

On 1/20/20 7:29 PM, Sandipan Das wrote:
> Some tests are built only for 64-bit systems. This makes
> sure that these tests are built for both big and little
> endian variants of powerpc64.
> 
> Fixes: 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit 
> arch")
> Signed-off-by: Sandipan Das 

I was about to suggest, the missing change in run_vmtests script in your V1.

Reviewed-by: Kamalesh Babulal 


-- 
Kamalesh

Re: [PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks

[Kamalesh Babulal]

On 12/5/19 3:54 AM, Nathan Lynch wrote:
> "Gautham R. Shenoy"  writes:
>> From: "Gautham R. Shenoy" 
>>
>> On PSeries LPARs, the data centers planners desire a more accurate
>> view of system utilization per resource such as CPU to plan the system
>> capacity requirements better. Such accuracy can be obtained by reading
>> PURR/SPURR registers for CPU resource utilization.
>>
>> Tools such as lparstat which are used to compute the utilization need
>> to know [S]PURR ticks when the cpu was busy or idle. The [S]PURR
>> counters are already exposed through sysfs.  We already account for
>> PURR ticks when we go to idle so that we can update the VPA area. This
>> patchset extends support to account for SPURR ticks when idle, and
>> expose both via per-cpu sysfs files.
> 
> Does anything really want to use PURR instead of SPURR? Seems like we
> should expose only SPURR idle values if possible.
> 

lparstat is one of the consumers of PURR idle metric
(https://groups.google.com/forum/#!topic/powerpc-utils-devel/fYRo69xO9r4). 
Agree, on the argument that system utilization metrics based on SPURR
accounting is accurate in comparison to PURR, which isn't proportional to
CPU frequency.  PURR has been traditionally used to understand the system
utilization, whereas SPURR is used for understanding how much capacity is
left/exceeding in the system based on the current power saving mode.

-- 
Kamalesh

Re: [PATCH 1/3] powerpc/pseries: Account for SPURR ticks on idle CPUs

[Kamalesh Babulal]

On 11/27/19 5:31 PM, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" 
> 
> On PSeries LPARs, to compute the utilization, tools such as lparstat
> need to know the [S]PURR ticks when the CPUs were busy or idle.
> 
> In the pseries cpuidle driver, we keep track of the idle PURR ticks in
> the VPA variable "wait_state_cycles". This patch extends the support
> to account for the idle SPURR ticks.

Thanks for working on it.

> 
> Signed-off-by: Gautham R. Shenoy 

Reviewed-by: Kamalesh Babulal 

Re: [PATCH 2/3] powerpc/sysfs: Show idle_purr and idle_spurr for every CPU

[Kamalesh Babulal]

On 11/27/19 5:31 PM, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" 
> 
> On Pseries LPARs, to calculate utilization, we need to know the
> [S]PURR ticks when the CPUs were busy or idle.
> 
> The total PURR and SPURR ticks are already exposed via the per-cpu
> sysfs files /sys/devices/system/cpu/cpuX/purr and
> /sys/devices/system/cpu/cpuX/spurr.
> 
> This patch adds support for exposing the idle PURR and SPURR ticks via
> /sys/devices/system/cpu/cpuX/idle_purr and
> /sys/devices/system/cpu/cpuX/idle_spurr.

The patch looks good to me, with a minor file mode nit pick mentioned below.

> 
> Signed-off-by: Gautham R. Shenoy 
> ---
>  arch/powerpc/kernel/sysfs.c | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 80a676d..42ade55 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -1044,6 +1044,36 @@ static ssize_t show_physical_id(struct device *dev,
>  }
>  static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
> 
> +static ssize_t idle_purr_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + struct cpu *cpu = container_of(dev, struct cpu, dev);
> + unsigned int cpuid = cpu->dev.id;
> + struct lppaca *cpu_lppaca_ptr = paca_ptrs[cpuid]->lppaca_ptr;
> + u64 idle_purr_cycles = be64_to_cpu(cpu_lppaca_ptr->wait_state_cycles);
> +
> + return sprintf(buf, "%llx\n", idle_purr_cycles);
> +}
> +static DEVICE_ATTR_RO(idle_purr);

per cpu purr/spurr sysfs file is created with file mode 0400. Using
DEVICE_ATTR_RO for their idle_* variants will create sysfs files with 0444 as
their file mode, you should probably use DEVICE_ATTR() with file mode 0400 to
have consist permission for both variants.

-- 
Kamalesh

Re: [PATCH] powerpc/modules: remove unused mod_arch_specific.toc field

[Kamalesh Babulal]

On Friday 25 May 2018 09:18 AM, Josh Poimboeuf wrote:

The toc field in the mod_arch_specific struct isn't actually used
anywhere, so remove it.

Also the ftrace-specific fields are now common between 32-bit and
64-bit, so simplify the struct definition a bit by moving them out of
the __powerpc64__ #ifdef.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

Re: [PATCH v4.2] powerpc/modules: Don't try to restore r2 after a sibling call

[Kamalesh Babulal]

On Thursday 16 November 2017 11:15 PM, Josh Poimboeuf wrote:

On Thu, Nov 16, 2017 at 06:39:03PM +0530, Naveen N. Rao wrote:

Josh Poimboeuf wrote:

On Wed, Nov 15, 2017 at 02:58:33PM +0530, Naveen N. Rao wrote:

+int instr_is_link_branch(unsigned int instr)
+{
+   return (instr_is_branch_iform(instr) || instr_is_branch_bform(instr)) &&
+  (instr & BRANCH_SET_LINK);
+}
+


Nitpicking here, but since we're not considering the other branch forms,
perhaps this can be renamed to instr_is_link_relative_branch() (or maybe
instr_is_relative_branch_link()), just so we're clear :)


My understanding is that the absolute/relative bit isn't a "form", but
rather a bit that can be set for either the b-form (conditional) or the
i-form (unconditional).  And the above function isn't checking the
absolute bit, so it isn't necessarily a relative branch.  Or did I miss
something?


Ah, good point. I was coming from the fact that we are only considering the
i-form and b-form branches and not the lr/ctr/tar based branches, which are
always absolute branches, but can also set the link register.


Hm, RISC is more complicated than I realized ;-)


Thinking about this more, aren't we only interested in relative branches
here (for relocations), so can we actually filter out the absolute branches?
Something like this?

int instr_is_relative_branch_link(unsigned int instr)
{
return ((instr_is_branch_iform(instr) || instr_is_branch_bform(instr)) 
&&
   !(instr & BRANCH_ABSOLUTE) && (instr & BRANCH_SET_LINK));


Yeah, makes sense to me.  Here's another try (also untested).  If this
looks ok, Kamalesh would you mind testing again?

8<

From: Josh Poimboeuf <jpoim...@redhat.com>
Subject: [PATCH v4.2] powerpc/modules: Don't try to restore r2 after a sibling 
call

When attempting to load a livepatch module, I got the following error:

  module_64: patch_module: Expect noop after relocate, got 3c82

The error was triggered by the following code in
unregister_netdevice_queue():

  14c:   00 00 00 48 b   14c <unregister_netdevice_queue+0x14c>
 14c: R_PPC64_REL24  net_set_todo
  150:   00 00 82 3c addis   r4,r2,0

GCC didn't insert a nop after the branch to net_set_todo() because it's
a sibling call, so it never returns.  The nop isn't needed after the
branch in that case.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


Reviewed-and-tested-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>


---
 arch/powerpc/include/asm/code-patching.h |  1 +
 arch/powerpc/kernel/module_64.c  | 12 +++-
 arch/powerpc/lib/code-patching.c |  5 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/code-patching.h 
b/arch/powerpc/include/asm/code-patching.h
index abef812de7f8..2c895e8d07f7 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -33,6 +33,7 @@ int patch_branch(unsigned int *addr, unsigned long target, 
int flags);
 int patch_instruction(unsigned int *addr, unsigned int instr);

 int instr_is_relative_branch(unsigned int instr);
+int instr_is_relative_link_branch(unsigned int instr);
 int instr_is_branch_to_addr(const unsigned int *instr, unsigned long addr);
 unsigned long branch_target(const unsigned int *instr);
 unsigned int translate_branch(const unsigned int *dest,
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 759104b99f9f..180c16f04063 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -487,7 +487,17 @@ static bool is_early_mcount_callsite(u32 *instruction)
restore r2. */
 static int restore_r2(u32 *instruction, struct module *me)
 {
-   if (is_early_mcount_callsite(instruction - 1))
+   u32 *prev_insn = instruction - 1;
+
+   if (is_early_mcount_callsite(prev_insn))
+   return 1;
+
+   /*
+* Make sure the branch isn't a sibling call.  Sibling calls aren't
+* "link" branches and they don't return, so they don't need the r2
+* restore afterwards.
+*/
+   if (!instr_is_relative_link_branch(*prev_insn))
return 1;

if (*instruction != PPC_INST_NOP) {
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index c9de03e0c1f1..d81aab7441f7 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -304,6 +304,11 @@ int instr_is_relative_branch(unsigned int instr)
return instr_is_branch_iform(instr) || instr_is_branch_bform(instr);
 }

+int instr_is_relative_link_branch(unsigned int instr)
+{
+   return instr_is_relative_branch(instr) && (instr & BRANCH_SET_LINK);
+}
+
 static unsigned long branch_iform_target(const unsigned int *instr)
 {
signed long imm;

Re: [PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

[Kamalesh Babulal]

On Tuesday 14 November 2017 09:23 PM, Josh Poimboeuf wrote:

On Tue, Nov 14, 2017 at 03:59:21PM +0530, Naveen N. Rao wrote:

Kamalesh Babulal wrote:

From: Josh Poimboeuf <jpoim...@redhat.com>

When attempting to load a livepatch module, I got the following error:

  module_64: patch_module: Expect noop after relocate, got 3c82

The error was triggered by the following code in
unregister_netdevice_queue():

  14c:   00 00 00 48 b   14c <unregister_netdevice_queue+0x14c>
 14c: R_PPC64_REL24  net_set_todo
  150:   00 00 82 3c addis   r4,r2,0

GCC didn't insert a nop after the branch to net_set_todo() because it's
a sibling call, so it never returns.  The nop isn't needed after the
branch in that case.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>
Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
---
 arch/powerpc/kernel/module_64.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 39b01fd..9e5391f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -489,6 +489,10 @@ static int restore_r2(u32 *instruction, struct module *me)
if (is_early_mcount_callsite(instruction - 1))
return 1;

+   /* Sibling calls don't return, so they don't need to restore r2 */
+   if (instruction[-1] == PPC_INST_BRANCH)
+   return 1;
+


This looks quite fragile, unless we know for sure that gcc will _always_
emit this instruction form for sibling calls with relocations.

As an alternative, does it make sense to do the following check instead?
if ((instr_is_branch_iform(insn) || instr_is_branch_bform(insn))
&& !(insn & 0x1))


Yes, good point.  How about something like this?

(completely untested because I don't have access to a box at the moment)


Reviewed-and-tested-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>




diff --git a/arch/powerpc/include/asm/code-patching.h 
b/arch/powerpc/include/asm/code-patching.h
index abef812de7f8..302e4368debc 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -33,6 +33,7 @@ int patch_branch(unsigned int *addr, unsigned long target, 
int flags);
 int patch_instruction(unsigned int *addr, unsigned int instr);

 int instr_is_relative_branch(unsigned int instr);
+int instr_is_link_branch(unsigned int instr);
 int instr_is_branch_to_addr(const unsigned int *instr, unsigned long addr);
 unsigned long branch_target(const unsigned int *instr);
 unsigned int translate_branch(const unsigned int *dest,
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 9cb007bc7075..b5148a206b4d 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -487,11 +487,13 @@ static bool is_early_mcount_callsite(u32 *instruction)
restore r2. */
 static int restore_r2(u32 *instruction, struct module *me)
 {
-   if (is_early_mcount_callsite(instruction - 1))
+   u32 *prev_insn = instruction - 1;
+
+   if (is_early_mcount_callsite(prev_insn))
return 1;

/* Sibling calls don't return, so they don't need to restore r2 */
-   if (instruction[-1] == PPC_INST_BRANCH)
+   if (!instr_is_link_branch(*prev_insn))
return 1;

if (*instruction != PPC_INST_NOP) {
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index c9de03e0c1f1..4727fafd37e4 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -304,6 +304,12 @@ int instr_is_relative_branch(unsigned int instr)
return instr_is_branch_iform(instr) || instr_is_branch_bform(instr);
 }

+int instr_is_link_branch(unsigned int instr)
+{
+   return (instr_is_branch_iform(instr) || instr_is_branch_bform(instr)) &&
+  (instr & BRANCH_SET_LINK);
+}
+
 static unsigned long branch_iform_target(const unsigned int *instr)
 {
signed long imm;




--
cheers,
Kamalesh.

[PATCH v4 3/3] powerpc/modules: Improve restore_r2() error message

[Kamalesh Babulal]

From: Josh Poimboeuf <jpoim...@redhat.com>

Print the function address associated with the restore_r2() error to
make it easier to debug the problem.

Also clarify the wording a bit.

Before:

  module_64: patch_foo: Expect noop after relocate, got 3c82

After:

  module_64: patch_foo: Expected noop after call, got 7c630034 at 
netdev_has_upper_dev+0x54/0xb0 [patch_foo]

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>
Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
---
 arch/powerpc/kernel/module_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 9e5391f..dad3ea5 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -494,8 +494,8 @@ static int restore_r2(u32 *instruction, struct module *me)
return 1;
 
if (*instruction != PPC_INST_NOP) {
-   pr_err("%s: Expect noop after relocate, got %08x\n",
-  me->name, *instruction);
+   pr_err("%s: Expected noop after call, got %08x at %pS\n",
+   me->name, *instruction, instruction);
return 0;
}
/* ld r2,R2_STACK_OFFSET(r1) */
-- 
2.9.3

[PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

[Kamalesh Babulal]

From: Josh Poimboeuf <jpoim...@redhat.com>

When attempting to load a livepatch module, I got the following error:

  module_64: patch_module: Expect noop after relocate, got 3c82

The error was triggered by the following code in
unregister_netdevice_queue():

  14c:   00 00 00 48 b   14c <unregister_netdevice_queue+0x14c>
 14c: R_PPC64_REL24  net_set_todo
  150:   00 00 82 3c addis   r4,r2,0

GCC didn't insert a nop after the branch to net_set_todo() because it's
a sibling call, so it never returns.  The nop isn't needed after the
branch in that case.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>
Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
---
 arch/powerpc/kernel/module_64.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 39b01fd..9e5391f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -489,6 +489,10 @@ static int restore_r2(u32 *instruction, struct module *me)
if (is_early_mcount_callsite(instruction - 1))
return 1;
 
+   /* Sibling calls don't return, so they don't need to restore r2 */
+   if (instruction[-1] == PPC_INST_BRANCH)
+   return 1;
+
if (*instruction != PPC_INST_NOP) {
pr_err("%s: Expect noop after relocate, got %08x\n",
   me->name, *instruction);
-- 
2.9.3

[PATCH v4 1/3] kernel/modules: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

Livepatch re-uses module loader function apply_relocate_add() to write
relocations, instead of managing them by arch-dependent
klp_write_module_reloc() function.

apply_relocate_add() doesn't understand livepatch symbols (marked with
SHN_LIVEPATCH symbol section index) and assumes them to be local symbols
by default for R_PPC64_REL24 relocation type. It fails with an error,
when trying to calculate offset with local_entry_offset():

 module_64: kpatch_meminfo: REL24 -1152921504897399800 out of range!

Whereas livepatch symbols are essentially SHN_UNDEF, should be
called via stub used for global calls. This issue can be fixed by
teaching apply_relocate_add() to handle both SHN_UNDEF/SHN_LIVEPATCH
symbols via the same stub. This patch extends SHN_UNDEF code to handle
livepatch symbols too.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
CC: Balbir Singh <bsinghar...@gmail.com>
Cc: Naveen N. Rao <naveen.n@linux.vnet.ibm.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Jessica Yu <j...@kernel.org>
Cc: Ananth N Mavinakayanahalli <ana...@linux.vnet.ibm.com>
Cc: Aravinda Prasad <aravi...@linux.vnet.ibm.com>
Cc: Torsten Duwe <d...@lst.de>
---
 arch/powerpc/kernel/module_64.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..39b01fd 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -613,7 +613,8 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
 
case R_PPC_REL24:
/* FIXME: Handle weak symbols here --RR */
-   if (sym->st_shndx == SHN_UNDEF) {
+   if (sym->st_shndx == SHN_UNDEF ||
+   sym->st_shndx == SHN_LIVEPATCH) {
/* External: go via stub */
value = stub_for_addr(sechdrs, value, me);
if (!value)
-- 
2.9.3

[PATCH v4 0/3] ppc64le: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

This patchset drop the approach of creating new stub type for livepatch
symbols and offloads the issue of handling local function becoming global
to kpatch tool via gcc-plugin.

In function restore_r2(), a check for sibling call is added and also
improves the error message on unexpected op-code.

v4:
 - Drop creation of stubs for livepatch symbols and offload solution
   to kpatch tool.
 - Introduce check for sibling call, when restoring r2 after branch. (Josh)
 - Improve error message in restore_r2(). (Josh)

v3:
 - Defined FUNC_DESC_OFFSET to calculate func_desc offset from
   struct ppc64le_klp_stub_entry.
 - Replaced BUG_ON() with WARN_ON() in klp_stub_for_addr().
 - Major commit message re-write.

v2:
 - Changed klp_stub construction to re-use livepatch_handler and
   additional patch code required for klp_stub, instead of duplicating it.
 - Minor comments and commit body edit.

Josh Poimboeuf (2):
  powerpc/modules: Don't try to restore r2 after a sibling call
  powerpc/modules: Improve restore_r2() error message

Kamalesh Babulal (1):
  kernel/modules: Add REL24 relocation support of livepatch symbols

 arch/powerpc/kernel/module_64.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

-- 
2.9.3

Re: [PATCH v3] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

On Monday 13 November 2017 02:08 PM, Balbir Singh wrote:

On Fri, Nov 10, 2017 at 2:28 PM, Josh Poimboeuf  wrote:

On Fri, Nov 10, 2017 at 01:06:25PM +1100, Balbir Singh wrote:

On Fri, Nov 10, 2017 at 2:19 AM, Josh Poimboeuf  wrote:

FWIW, I think it won't matter anyway.  I'm currently pursuing the option
of inserting nops after local calls, because it has less runtime
complexity than using a stub.

I think I've figured out a way to do it with a GCC plugin, but if that
doesn't work I'll try the asm listing sed approach suggested by Michael.



A plugin that runs for the new kernel with the patch? Just for
specific files involved in the patch?


The plugin will affect the code generation of all functions in the patch
module.  So all calls in all replacement functions will have the nops.

Here's a prototype (not yet fully tested):

  
https://github.com/jpoimboe/kpatch/blob/TODO-ppc-fix/kpatch-build/gcc-plugins/ppc64le-plugin.c





[...]


I'd have to look closer, but I wonder what happens if a
function has no global entry
point

(See http://mpe.github.io/posts/2016/05/23/kernel-live-patching-for-ppc64le/)
section
Understanding the TOC & entry points and the example of int_to_scsilun()



int_to_scsilun() is accessed via global entry point, but the TOC setup
part in the function prologue is skipped as the function doesn't have a
need to save/restore TOC. The reason begin, it doesn't calls any global
functions, thus the r2 register is not clobbered.

As per my understanding, the plug-in inserts a nop instruction after
branch to a function called via localentry a.k.a call to local
function. In case of int_to_scsilun(), the plug-in will not modify the
function in any way, as there are no local calls also made by the
int_to_scsilun().

--
cheers,
Kamalesh.

Re: [PATCH v3] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

On Tuesday 31 October 2017 07:49 PM, Naveen N . Rao wrote:

Hi Kamalesh,
Sorry for the late review. Overall, the patch looks good to me. So:
Acked-by: Naveen N. Rao 

However, I have a few minor comments which can be addressed in a
subsequent patch.



Thanks for the review.

[...]


diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..005aaea 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c


[...]


@@ -239,10 +257,19 @@ static void relaswap(void *_x, void *_y, int size)

 /* Get size of potential trampolines required. */
 static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
-   const Elf64_Shdr *sechdrs)
+   const Elf64_Shdr *sechdrs,
+   struct module *me)
 {
/* One extra reloc so it's always 0-funcaddr terminated */
unsigned long relocs = 1;


You might want to get rid of 'relocs' above and simply use the below
two.


+   /*
+* size of livepatch stub is 28 instructions, whereas the
+* non-livepatch stub requires 7 instructions. Account for
+* different stub sizes and track the livepatch relocation
+* count in me->arch.klp_relocs.
+*/
+   unsigned long sec_relocs = 0;
+   unsigned long klp_relocs = 0;


You should also initialize this to 1 (similar to relocs above) for use
in the iterators below. Or, update the iterators to use
me->arch.klp_relocs (1)


relocs is Sum(sec_relocs), whereas per section relocation count is 
assigned to sec_relocs.  If the section is livepatch section, then it
added to klp_relocs or else to relocs. sec_relocs acts like a temp 
variable to hold the current section relocation count.





unsigned i;

/* Every relocated section... */
@@ -262,9 +289,14 @@ static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
 sechdrs[i].sh_size / sizeof(Elf64_Rela),
 sizeof(Elf64_Rela), relacmp, relaswap);

-   relocs += count_relocs((void *)sechdrs[i].sh_addr,
+   sec_relocs = count_relocs((void *)sechdrs[i].sh_addr,
   sechdrs[i].sh_size
   / sizeof(Elf64_Rela));


How about also capturing 'sec_relocs' in 'struct mod_arch_specific'? (2)
That will help simplify a lot of the calculations here and elsewhere.
Note that there are many other places where the number of stubs is
derived looking at 'sh_size', which is incorrect since we now have klp
stubs as well (create_ftrace_stub() for instance).


+   relocs += sec_relocs;
+#ifdef CONFIG_LIVEPATCH
+   if (sechdrs[i].sh_flags & SHF_RELA_LIVEPATCH)
+   klp_relocs += sec_relocs;
+#endif


If a module has SHF_RELA_LIVEPATCH, but the kernel is compiled without
CONFIG_LIVEPATCH, should we refuse to load the kernel module?


Yes, the module load will fail.



You might want to consider removing the above #ifdef and processing some
of these flags regardless of CONFIG_LIVEPATCH.


ifdef guard, can be replaced with check for SHF_RELA_LIVEPATCH in 
section flag.





}
}

@@ -273,6 +305,15 @@ static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
relocs++;
 #endif

+   relocs -= klp_relocs;
+#ifdef CONFIG_LIVEPATCH
+   me->arch.klp_relocs = klp_relocs;
+
+   pr_debug("Looks like a total of %lu stubs, (%lu) livepatch stubs, 
max\n",

   ^
   (%lu livepatch stubs)

Just wondering why the brackets are the way they are...


Makes it better to use the brackets like you suggested.





+   relocs, klp_relocs);
+   return (relocs * sizeof(struct ppc64_stub_entry) +
+   klp_relocs * sizeof(struct ppc64le_klp_stub_entry));
+#endif
pr_debug("Looks like a total of %lu stubs, max\n", relocs);
return relocs * sizeof(struct ppc64_stub_entry);
 }


[...]



+#ifdef CONFIG_LIVEPATCH
+static unsigned long klp_stub_for_addr(const Elf64_Shdr *sechdrs,
+  unsigned long addr,
+  struct module *me)
+{
+   struct ppc64le_klp_stub_entry *klp_stubs;
+   unsigned int num_klp_stubs = me->arch.klp_relocs;
+   unsigned int i, num_stubs;
+
+   num_stubs = (sechdrs[me->arch.stubs_section].sh_size -
+   (num_klp_stubs * sizeof(*klp_stubs))) /
+   sizeof(struct ppc64_stub_entry);


(2) This can be simplified if we have me->arch.sec_relocs.


Having it will make the calculation look simple:
num_stubs = (me->arch.sec_relocs * size(struct ppc64_stub_entry).





+
+   /*
+* Create livepatch stubs after the 

Re: [PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

On Saturday 21 October 2017 06:29 AM, Balbir Singh wrote:

On Fri, 2017-10-20 at 14:07 +0200, Torsten Duwe wrote:

On Wed, Oct 18, 2017 at 11:47:35AM +0530, Kamalesh Babulal wrote:


Consider a trivial patch, supplied to kpatch tool for generating a
livepatch module:

--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -132,7 +132,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
seq_printf(m, "VmallocTotal:   %8lu kB\n",
   (unsigned long)VMALLOC_TOTAL >> 10);
show_val_kb(m, "VmallocUsed:", 0ul);
-   show_val_kb(m, "VmallocChunk:   ", 0ul);
+   show_val_kb(m, "VMALLOCCHUNK:   ", 0ul);



Am I assuming correctly that "kpatch tool" simply recompiles all code the
way it would get compiled in a regular kernel build?


kpatch is open source and is available on github. This patch is specific
to the way kpatch works


My understanding is
that live patching modules need to be carefully prepared, which involves
source code reorganisation and recompilation. In that process, you can
easily declare show_val_kb() extern, and get the suitable instruction sequence
for the call.


Yes, we agree. For the current versions of kpatch, which involve a process of
applying the patch and building the kernel without and with the patch and doing
an elf diff (programatically), we cannot deviate from that process as it's
architecture independent. This patch solves arch specific issues related
to that process.


Yes, that's the essence of the kpatch tool on building livepatchable
kernel module, by doing an elf diff on the kernel with and without the
patch applied. show_val_kb() is a simple example, consider more complex
patch(s), if they need to be prepared manually as suggested. It beats
the whole purpose of a kpatch tool, which programmatically prepares a
livepatch module with close to no manual preparation required. It's
the architecture limitation, which is addressed in this patch.

This patch is outcome of long discussion at kpatch
https://github.com/dynup/kpatch/pull/650

--
cheers,
Kamalesh.

Re: [PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

On Tuesday 17 October 2017 08:17 PM, Torsten Duwe wrote:
> On Fri, Oct 06, 2017 at 11:27:42AM +0530, Kamalesh Babulal wrote:
>>
>> Consider the livepatch sequence[1]. Where function A calls B, B is the
>> function which has been livepatched and the call to function B is
>> redirected to patched version P. P calls the function C in M2, whereas
>> C was local to the function B and have became SHN_UNDEF in function P.
>> Local call becoming global.
>>
>>   ++++++  ++
>>   ||   +++--->||  +-->||
>>   |  A |   ||  B ||  F |  |   |  P |
>>   ||   ||||+--+   ||
>>   |+---+||||<-+   ||
>>   ||<--+   ++   C|||  |   ||
>>   ||   |   | +->||||  |   ||<---+
>>   | K / M1 |   |   | |  | K / M2 |  +-+ Kernel |  +---+ Mod3   +--+ |
>>   ++   |   | |  ++  | ++  ++  | |
>>|   | |  | | |
>>+---+-+--+ | |
>>| || |
>>| ++ |
>>++
>>
>>
>> Handling such call with regular stub, triggers another error:
>>
>> module_64: kpatch_meminfo: Expect noop after relocate, got 3d22
>>
>> Every branch to SHN_UNDEF is followed by a nop instruction, that gets
>> overwritten by an instruction to restore TOC with r2 value that get
>> stored onto the stack, before calling the function via global entry
>> point.
>>
>> Given that C was local to function B, it does not store/restore TOC as
>> they are not expected to be clobbered for functions called via local
>> entry point.
> 
> Can you please provide example source code of Mod3 and C? If P calls C, this
> is a regular global call, the TOC is saved by the stub and restored after the
> call instruction. Why do you think this is not the case? 
> 

Consider a trivial patch, supplied to kpatch tool for generating a
livepatch module:

--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -132,7 +132,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
seq_printf(m, "VmallocTotal:   %8lu kB\n",
   (unsigned long)VMALLOC_TOTAL >> 10);
show_val_kb(m, "VmallocUsed:", 0ul);
-   show_val_kb(m, "VmallocChunk:   ", 0ul);
+   show_val_kb(m, "VMALLOCCHUNK:   ", 0ul);

 #ifdef CONFIG_MEMORY_FAILURE
seq_printf(m, "HardwareCorrupted: %5lu kB\n",

# readelf -s -W ./fs/proc/meminfo.o
Symbol table '.symtab' contains 54 entries:
Num: Value Size Type Bind  Vis Ndx Name
...
23:  0x50  224  FUNC LOCAL DEFAULT [: 8] 1 show_val_kb
...

# objdump -dr ./fs/proc/meminfo.o
0140 :
 204:   01 00 00 48 bl  204 <meminfo_proc_show+0xc4>
204: R_PPC64_REL24  si_mem_available
 208:   00 00 00 60 nop
 ...
 220:   01 00 00 48 bl  220 <meminfo_proc_show+0xe0>
220: R_PPC64_REL24  show_val_kb
 224:   88 00 a1 e8 ld  r5,136(r1)
 228:   00 00 82 3c addis   r4,r2,0

show_val_kb() is called by meminfo_proc_show() frequently to print memory
statistics, is also defined in meminfo.o. Which means both the functions
share the same TOC base and is accessed via local entry point by
calculating the offset with respect to current TOC.

A nop instruction is only excepted after every branch to a global call.
That gets overwritten by an instruction to restore TOC with r2 value of
callee. Given function show_val_kb() is local to meminfo_proc_show(),
any call to show_val_kb() doesn't requires setting up/restoring TOC as
they are not expected to be clobbered for local function call (via local
entry point).

kpatch identifies the patched function to be meminfo_proc_show() and copies
it into livepatch module, along with required symbols and livepatch hooks
but doesn't copies show_val_kb(). The reason being, it can be called like
any other global function and is marked with SHN_LIVEPATCH symbol section
index. show_val_kb() which is local to meminfo_proc_show(), is global to
patched version of meminfo_proc_show().

Symbol table '.symtab' contains 91 entries:
Num: Value Size Type Bind  Vis Ndx Name
...
82:  0x0   0FUNC LOCAL DEFAULT OS [0xff20] .klp.sym.vmlinux.show_val_kb,1
...

apply_relocate_add() should be modified to handle show_val_kb() via global
entry poin

[PATCH v3] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

Livepatch re-uses module loader function apply_relocate_add() to write
relocations, instead of managing them by arch-dependent
klp_write_module_reloc() function.

apply_relocate_add() doesn't understand livepatch symbols (marked with
SHN_LIVEPATCH symbol section index) and assumes them to be local symbols
by default for R_PPC64_REL24 relocation type. It fails with an error,
when trying to calculate offset with local_entry_offset():

module_64: kpatch_meminfo: REL24 -1152921504897399800 out of range!

Whereas livepatch symbols are essentially SHN_UNDEF, should be
called via stub used for global calls. This issue can be fixed by
teaching apply_relocate_add() to handle both SHN_UNDEF/SHN_LIVEPATCH
symbols via the same stub. It isn't a complete fix, as it will fail for
local calls becoming global.

Consider a livepatch sequence[1] below, where function A calls B, B is
livepatched function and any calls to function B is redirected to
patched version P. Now, livepatched function P calls function C in M2,
whereas C was local to function B and global to function P.

  ++++++  ++
  ||   +++--->||  +-->||
  |  A |   ||  B ||  F |  |   |  P |
  ||   ||||+--+   ||
  |+---+||||<-+   ||
  ||<--+   ++   C|||  |   ||
  ||   |   | +->||||  |   ||<---+
  | K / M1 |   |   | |  | K / M2 |  +-+ Kernel |  +---+ Mod3   +--+ |
  ++   |   | |  ++  | ++  ++  | |
   |   | |  | | |
   +---+-+--+ | |
   | || |
   | ++ |
   ++

Handling such call with existing stub, triggers another error:

module_64: kpatch_meminfo: Expect noop after relocate, got 3d22

Reason being, ppc64le ABI v2 expects a nop instruction after every
branch to a global call. That gets overwritten by an instruction to
restore TOC with r2 value of callee. Given function C was local to
function B, it does not store/restore TOC as they are not expected to be
clobbered for functions called via local entry point.

The current stub can be extended to re-store TOC and have a single stub
for both SHN_UNDEF/SHN_LIVEPATCH symbols. Constructing a single stub proves
to be an overhead for non-livepatch calls, with additional instructions
to restore TOC.

A new stub to call livepatch symbols with an intermediate stack to
store/restore, TOC/LR between livepatched function and global function
will work for most of the cases but will fail when arguments are passed
via stack between functions.

This issue has been already solved by introduction of livepatch_handler,
which runs in _mcount context by introducing livepatch stack growing
upwards from the base of the regular stack, eliminating the need for an
intermediate stack.

Current approach is to setup klp_stub mimicking the functionality of
entry_64.S::livepatch_handler to store/restore TOC/LR values, other than
the stub setup and branch. This patch also introduces new
ppc64le_klp_stub_entry[], along with the helpers to find/allocate
livepatch stub.

[1] ASCII diagram adopted from:
http://mpe.github.io/posts/2016/05/23/kernel-live-patching-for-ppc64le/

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Reviewed-by: Balbir Singh <bsinghar...@gmail.com>
Cc: Naveen N. Rao <naveen.n@linux.vnet.ibm.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Jessica Yu <j...@kernel.org>
Cc: Ananth N Mavinakayanahalli <ana...@linux.vnet.ibm.com>
Cc: Aravinda Prasad <aravi...@linux.vnet.ibm.com>
Cc: Torsten Duwe <d...@lst.de>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: live-patch...@vger.kernel.org
---
v3:
 - Defined FUNC_DESC_OFFSET to calculate func_desc offset from
   struct ppc64le_klp_stub_entry.
 - Replaced BUG_ON() with WARN_ON() in klp_stub_for_addr().
 - Major commit message re-write.

v2:
 - Changed klp_stub construction to re-use livepatch_handler and
   additional patch code required for klp_stub, instead of duplicating it.
 - Minor comments and commit body edit.

 arch/powerpc/include/asm/module.h  |   4 +
 arch/powerpc/kernel/module_64.c| 139 -
 arch/powerpc/kernel/trace/ftrace_64_mprofile.S |  31 ++
 3 files changed, 171 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/module.h 
b/arch/powerpc/include/asm/module.h
index 6c0132c..de22c4c 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -44,6 +44,10 @@ struct mod_arch_specific {
unsigned long 

Re: [PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

On Friday 06 October 2017 11:13 AM, Kamalesh Babulal wrote:

On Thursday 05 October 2017 06:13 PM, Torsten Duwe wrote:

On Wed, Oct 04, 2017 at 11:25:16AM -0400, Kamalesh Babulal wrote:


Both the failures with REL24 livepatch symbols relocation, can be
resolved by constructing a new livepatch stub. The newly setup klp_stub
mimics the functionality of entry_64.S::livepatch_handler introduced by
commit 85baa095497f ("powerpc/livepatch: Add live patching support on
ppc64le").


So, do I get his right that this patch is based on your June 13 proposal
"powerpc/modules: Introduce new stub code for SHN_LIVEPATCH symbols" ?
I guess you lost many of us already at that point. What is the new, much
bigger stub code needed for? Stub code should do only the very bare
minimum,
all common functionality is handled in the kernel main object.

What exactly is the problem you're trying to solve, what is to be
achieved?


Thanks for the review.

With apply_relocate_add() writing out relocations for livepatch symbols
too. R_PPC_REL24: Doesn't handle SHN_LIVEPATCH symbols and ends up being
treated as local symbol and calls local_entry_offset(). Which triggers
an error:

module_64: kpatch_meminfo: REL24 -1152921504897399800 out of range!

Whereas SHN_LIVEPATCH symbols are essentially SHN_UNDEF, should be
called via external stub. This issue can be fixed by handling both
SHN_UNDEF and SHN_LIVEPATCH via same external stub. It isn't a complete
fix, because it will fail with local calls becoming global.

Consider the livepatch sequence[1]. Where function A calls B, B is the
function which has been livepatched and the call to function B is
redirected to patched version P. P calls the function C in M2, whereas C
was local to the function B and have became SHN_UNDEF in function P.
Local call becoming global.

  ++++++  ++
  ||   +++--->||  +-->||
  |  A |   ||  B ||  F |  |   |  P |
  ||   ||||+--+   ||
  |+---+||||<-+   ||
  ||<--+   ++   C|||  |   ||
  ||   |   | +->||||  |   ||<---+
  | K / M1 |   |   | |  | K / M2 |  +-+ Kernel |  +---+ Mod3   +--+ |
  ++   |   | |  ++  | ++  ++  | |
   |   | |  | | |
   +---+-+--+ | |
   | || |
   | ++ |
   ++

Handling such call with regular stub, triggers another error:

module_64: kpatch_meminfo: Expect noop after relocate, got 3d22

Every branch to SHN_UNDEF is followed by a nop instruction, that gets
overwritten by an instruction to restore TOC with r2 value that get
stored onto the stack, before calling the function via global entry point.

Given that C was local to function B, it does not store/restore TOC as
they are not expected to be clobbered for functions called via local
entry point.

Current stub can be extended to re-store TOC and have a single stub for
both SHN_UNDEF/SHN_LIVEPATCH symbols. Constructing a single stub is an
overhead for non livepatch calla, as it adds extra instructions for TOC
restore.

Idea was to create a new stub for SHN_LIVEPATCH symbols. Which would
also restore the TOC on the return to livepatched function, by
introducing an intermediate stack between function P and function C.
This was the earlier proposal made in June.

It will work for most of the cases but will not work, when arguments to
C as passes through stack. This issue has been already solved by
introduction of livepatch_handler, which runs in _mcount context by
creating a livepatch stack to store/restore TOC/LR. It avoids the need
for an intermediate stack.

Current approach, creates a hybrid stub. Which is a combination of
regular stub (stub setup code) +  livepatch_handler (stores/restores
TOC/LR with livepatch stack).



Torsten, Did you get a chance to read the problem statement and solution 
proposed. Looking forward for your comments.





+
+/*
+ * Patch the code required to load the trampoline address into r11,
+ * function global entry point into r12, ctr.
+ */
+entry->jump[klp_stub_idx++] = (PPC_INST_ADDIS | ___PPC_RT(11) |
+___PPC_RA(2) | PPC_HA(reladdr));
+
+entry->jump[klp_stub_idx++] = (PPC_INST_ADDI | ___PPC_RT(11) |
+ ___PPC_RA(11) | PPC_LO(reladdr));
+
+entry->jump[klp_stub_idx++] = (PPC_INST_LD | ___PPC_RT(12) |
+ ___PPC_RA(11) | 128);

 ^^^
Also, I was a bit puzzled by this constant, BTW.
Can you #define a meanin

Re: [PATCH] powerpc/modules: Use WARN_ON() in stub_for_addr()

[Kamalesh Babulal]

On Wednesday 11 October 2017 09:42 AM, Michael Ellerman wrote:
> Kamalesh Babulal <kamal...@linux.vnet.ibm.com> writes:
> 
>> Use WARN_ON(), while running out of stubs in stub_for_addr()
>> and abort loading of the module instead of BUG_ON().
> 
> Thanks. This looks good in principle. Have you actually tested it to
> make sure we do in fact gracefully fail the module load?
> 

Thanks for the review. I tested with little hackish version of this patch:

+   if (!strncmp(me->name, "live", 4))
+   j = 100;
+   for (i = 0; stub_func_addr(stubs[i].funcdata); i+=j) {
+   if (WARN_ON(i >= num_stubs))
+   return 0;

and it fails gracefully.

# modprobe livepatch-sample
modprobe: ERROR: could not insert 'livepatch_sample': Unknown symbol in module, 
or unknown parameter (see dmesg)

# echo $?
1

# dmesg 
[ cut here ]
WARNING: CPU: 2 PID: 2836 at arch/powerpc/kernel/module_64.c:526 
apply_relocate_add+0x71c/0xb00

-- 
cheers,
Kamalesh.

[PATCH] powerpc/modules: Use WARN_ON() in stub_for_addr()

[Kamalesh Babulal]

Use WARN_ON(), while running out of stubs in stub_for_addr()
and abort loading of the module instead of BUG_ON().

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
---
 arch/powerpc/kernel/module_64.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..759104b 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -429,7 +429,8 @@ static unsigned long stub_for_addr(const Elf64_Shdr 
*sechdrs,
/* Find this stub, or if that fails, the next avail. entry */
stubs = (void *)sechdrs[me->arch.stubs_section].sh_addr;
for (i = 0; stub_func_addr(stubs[i].funcdata); i++) {
-   BUG_ON(i >= num_stubs);
+   if (WARN_ON(i >= num_stubs))
+   return 0;
 
if (stub_func_addr(stubs[i].funcdata) == func_addr(addr))
return (unsigned long)[i];
-- 
2.7.4

Re: [PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

On Thursday 05 October 2017 06:13 PM, Torsten Duwe wrote:

On Wed, Oct 04, 2017 at 11:25:16AM -0400, Kamalesh Babulal wrote:


Both the failures with REL24 livepatch symbols relocation, can be
resolved by constructing a new livepatch stub. The newly setup klp_stub
mimics the functionality of entry_64.S::livepatch_handler introduced by
commit 85baa095497f ("powerpc/livepatch: Add live patching support on
ppc64le").


So, do I get his right that this patch is based on your June 13 proposal
"powerpc/modules: Introduce new stub code for SHN_LIVEPATCH symbols" ?
I guess you lost many of us already at that point. What is the new, much
bigger stub code needed for? Stub code should do only the very bare minimum,
all common functionality is handled in the kernel main object.

What exactly is the problem you're trying to solve, what is to be achieved?


Resending the reply, sorry about the word wrapping in the previous mail.

Thanks for the review.

With apply_relocate_add() writing out relocations for livepatch symbols
too. R_PPC_REL24: Doesn't handle SHN_LIVEPATCH symbols and ends up
being treated as local symbol and calls local_entry_offset(). Which
triggers an error:

module_64: kpatch_meminfo: REL24 -1152921504897399800 out of range!

Whereas SHN_LIVEPATCH symbols are essentially SHN_UNDEF, should be
called via external stub. This issue can be fixed by handling both
SHN_UNDEF and SHN_LIVEPATCH via same external stub. It isn't a complete
fix, because it will fail with local calls becoming global.

Consider the livepatch sequence[1]. Where function A calls B, B is the
function which has been livepatched and the call to function B is
redirected to patched version P. P calls the function C in M2, whereas
C was local to the function B and have became SHN_UNDEF in function P.
Local call becoming global.

  ++++++  ++
  ||   +++--->||  +-->||
  |  A |   ||  B ||  F |  |   |  P |
  ||   ||||+--+   ||
  |+---+||||<-+   ||
  ||<--+   ++   C|||  |   ||
  ||   |   | +->||||  |   ||<---+
  | K / M1 |   |   | |  | K / M2 |  +-+ Kernel |  +---+ Mod3   +--+ |
  ++   |   | |  ++  | ++  ++  | |
   |   | |  | | |
   +---+-+--+ | |
   | || |
   | ++ |
   ++


Handling such call with regular stub, triggers another error:

module_64: kpatch_meminfo: Expect noop after relocate, got 3d22

Every branch to SHN_UNDEF is followed by a nop instruction, that gets
overwritten by an instruction to restore TOC with r2 value that get
stored onto the stack, before calling the function via global entry
point.

Given that C was local to function B, it does not store/restore TOC as
they are not expected to be clobbered for functions called via local
entry point.

Current stub can be extended to re-store TOC and have a single stub for
both SHN_UNDEF/SHN_LIVEPATCH symbols. Constructing a single stub is an
overhead for non livepatch calla, as it adds extra instructions for TOC
restore.

Idea was to create a new stub for SHN_LIVEPATCH symbols. Which would
also restore the TOC on the return to livepatched function, by
introducing an intermediate stack between function P and function C.
This was the earlier proposal made in June.

It will work for most of the cases but will not work, when arguments to
C as passes through stack. This issue has been already solved by
introduction of livepatch_handler, which runs in _mcount context by
creating a livepatch stack to store/restore TOC/LR. It avoids the need
for an intermediate stack.

Current approach, creates a hybrid stub. Which is a combination of
regular stub (stub setup code) +  livepatch_handler (stores/restores
TOC/LR with livepatch stack).




+
+   /*
+* Patch the code required to load the trampoline address into r11,
+* function global entry point into r12, ctr.
+*/
+   entry->jump[klp_stub_idx++] = (PPC_INST_ADDIS | ___PPC_RT(11) |
+   ___PPC_RA(2) | PPC_HA(reladdr));
+
+   entry->jump[klp_stub_idx++] = (PPC_INST_ADDI | ___PPC_RT(11) |
+___PPC_RA(11) | PPC_LO(reladdr));
+
+   entry->jump[klp_stub_idx++] = (PPC_INST_LD | ___PPC_RT(12) |
+___PPC_RA(11) | 128);

 ^^^
Also, I was a bit puzzled by this constant, BTW.
Can you #define a meanin

Re: [PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

On Thursday 05 October 2017 06:13 PM, Torsten Duwe wrote:

On Wed, Oct 04, 2017 at 11:25:16AM -0400, Kamalesh Babulal wrote:


Both the failures with REL24 livepatch symbols relocation, can be
resolved by constructing a new livepatch stub. The newly setup klp_stub
mimics the functionality of entry_64.S::livepatch_handler introduced by
commit 85baa095497f ("powerpc/livepatch: Add live patching support on
ppc64le").


So, do I get his right that this patch is based on your June 13 proposal
"powerpc/modules: Introduce new stub code for SHN_LIVEPATCH symbols" ?
I guess you lost many of us already at that point. What is the new, much
bigger stub code needed for? Stub code should do only the very bare minimum,
all common functionality is handled in the kernel main object.

What exactly is the problem you're trying to solve, what is to be achieved?


Thanks for the review.

With apply_relocate_add() writing out relocations for livepatch symbols 
too. R_PPC_REL24: Doesn't handle SHN_LIVEPATCH symbols and ends up being 
treated as local symbol and calls local_entry_offset(). Which triggers 
an error:


module_64: kpatch_meminfo: REL24 -1152921504897399800 out of range!

Whereas SHN_LIVEPATCH symbols are essentially SHN_UNDEF, should be 
called via external stub. This issue can be fixed by handling both 
SHN_UNDEF and SHN_LIVEPATCH via same external stub. It isn't a complete 
fix, because it will fail with local calls becoming global.


Consider the livepatch sequence[1]. Where function A calls B, B is the
function which has been livepatched and the call to function B is 
redirected to patched version P. P calls the function C in M2, whereas C 
was local to the function B and have became SHN_UNDEF in function P. 
Local call becoming global.


  ++++++  ++
  ||   +++--->||  +-->||
  |  A |   ||  B ||  F |  |   |  P |
  ||   ||||+--+   ||
  |+---+||||<-+   ||
  ||<--+   ++   C|||  |   ||
  ||   |   | +->||||  |   ||<---+
  | K / M1 |   |   | |  | K / M2 |  +-+ Kernel |  +---+ Mod3   +--+ |
  ++   |   | |  ++  | ++  ++  | |
   |   | |  | | |
   +---+-+--+ | |
   | || |
   | ++ |
   ++

Handling such call with regular stub, triggers another error:

module_64: kpatch_meminfo: Expect noop after relocate, got 3d22

Every branch to SHN_UNDEF is followed by a nop instruction, that gets
overwritten by an instruction to restore TOC with r2 value that get 
stored onto the stack, before calling the function via global entry point.


Given that C was local to function B, it does not store/restore TOC as 
they are not expected to be clobbered for functions called via local 
entry point.


Current stub can be extended to re-store TOC and have a single stub for 
both SHN_UNDEF/SHN_LIVEPATCH symbols. Constructing a single stub is an 
overhead for non livepatch calla, as it adds extra instructions for TOC 
restore.


Idea was to create a new stub for SHN_LIVEPATCH symbols. Which would 
also restore the TOC on the return to livepatched function, by 
introducing an intermediate stack between function P and function C. 
This was the earlier proposal made in June.


It will work for most of the cases but will not work, when arguments to 
C as passes through stack. This issue has been already solved by 
introduction of livepatch_handler, which runs in _mcount context by 
creating a livepatch stack to store/restore TOC/LR. It avoids the need 
for an intermediate stack.


Current approach, creates a hybrid stub. Which is a combination of 
regular stub (stub setup code) +  livepatch_handler (stores/restores 
TOC/LR with livepatch stack).





+
+   /*
+* Patch the code required to load the trampoline address into r11,
+* function global entry point into r12, ctr.
+*/
+   entry->jump[klp_stub_idx++] = (PPC_INST_ADDIS | ___PPC_RT(11) |
+   ___PPC_RA(2) | PPC_HA(reladdr));
+
+   entry->jump[klp_stub_idx++] = (PPC_INST_ADDI | ___PPC_RT(11) |
+___PPC_RA(11) | PPC_LO(reladdr));
+
+   entry->jump[klp_stub_idx++] = (PPC_INST_LD | ___PPC_RT(12) |
+___PPC_RA(11) | 128);

 ^^^
Also, I was a bit puzzled by this constant, BTW.
Can you #define a meaning to this, perhaps?


Naveen too pointed

[PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

With commit 425595a7fc20 ("livepatch: reuse module loader code to
write relocations") livepatch uses module loader to write relocations
of livepatch symbols, instead of managing them by arch-dependent
klp_write_module_reloc() function.

livepatch module managed relocation entries are written to sections
marked with SHF_RELA_LIVEPATCH flag and livepatch symbols within the
section are marked with SHN_LIVEPATCH symbol section index. When the
livepatching module is loaded, the livepatch symbols are resolved
before calling apply_relocate_add() to apply the relocations.

R_PPC64_REL24 relocation type resolves to a function address, those may
be local to the livepatch module or available in kernel/other modules.
For every such non-local function, apply_relocate_add() constructs a
stub (a.k.a trampoline) to branch to a function. Stub code is
responsible to save toc onto the stack, before calling the function via
the global entry point. A NOP instruction is expected after every non
local function branch, i.e. after the REL24 relocation. Which in-turn
is replaced by toc restore instruction by apply_relocate_add().

Functions those were local to livepatched function previously, may have
become global now or they might be out of range with current TOC base.
During module load, apply_relocate_add() fails for such global
functions, as it expect's a nop after a branch. Which does't exist for a
non-local function accessed via local entry point.

For example, consider the following livepatch relocations (the example
is from livepatch module generated by kpatch tool):

Relocation section '.klp.rela.vmlinux..text.meminfo_proc_show' at offset
0x84530 contains 44 entries:

Offset Info Type  Symbol's Value   Symbol's Name + Addend
......  R_PPC64_REL24 0x0 .klp.sym.vmlinux.si_swapinfo,0 + 0
......  R_PPC64_REL24 0x0 .klp.sym.vmlinux.total_swapcache_pages,0 + 0
......  R_PPC64_REL24 0x0 .klp.sym.vmlinux.show_val_kb,1 + 0
[...]

1. .klp.sym.vmlinux.si_swapinfo and .klp.sym.vmlinux.total_swapcache_pages
   are not available within the livepatch module TOC range.

2. .klp.sym.vmlinux.show_val_kb livepatch symbol was previously local
   but now global w.r.t module call fs/proc/meminfo.c::meminfo_proc_show()

While the livepatch module is loaded the livepatch symbols mentioned in
case 1 will fail with an error:
module_64: kpatch_meminfo: REL24 -1152921504751525976 out of range!

and livepatch symbols mentioned in case 2 with fail with an error:
module_64: kpatch_meminfo: Expect noop after relocate, got 3d22

Both the failures with REL24 livepatch symbols relocation, can be
resolved by constructing a new livepatch stub. The newly setup klp_stub
mimics the functionality of entry_64.S::livepatch_handler introduced by
commit 85baa095497f ("powerpc/livepatch: Add live patching support on
ppc64le").

Which introduces a "livepatch stack" growing upwards from the base of
the regular stack and is used to store/restore TOC/LR values, other than
the stub setup and branch. The additional instructions sequences to
handle klp_stub increases the stub size and current ppc64_stub_insn[]
is not sufficient to hold them. This patch also introduces new
ppc64le_klp_stub_entry[], along with the helpers to find/allocate
livepatch stub.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Cc: Balbir Singh <bsinghar...@gmail.com>
Cc: Naveen N. Rao <naveen.n@linux.vnet.ibm.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Jessica Yu <j...@kernel.org>
Cc: Ananth N Mavinakayanahalli <ana...@linux.vnet.ibm.com>
Cc: Aravinda Prasad <aravi...@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: live-patch...@vger.kernel.org
---
This patch applies on top of livepatch_handler fix posted at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-September/163824.html

v2:
 - Changed klp_stub construction to re-use livepatch_handler and
   additional patch code required for klp_stub, instead of duplicating it.
 - Minor comments and commit body edits.

 arch/powerpc/include/asm/module.h  |   4 +
 arch/powerpc/kernel/module_64.c| 135 -
 arch/powerpc/kernel/trace/ftrace_64_mprofile.S |  31 ++
 3 files changed, 167 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/module.h 
b/arch/powerpc/include/asm/module.h
index 6c0132c7212f..de22c4c7aebc 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -44,6 +44,10 @@ struct mod_arch_specific {
unsigned long toc;
unsigned long tramp;
 #endif
+#ifdef CONFIG_LIVEPATCH
+   /* Count of kernel livepatch relocations */
+   unsigned long klp_relocs;
+#endif
 
 #else /* powerpc64 */
/* Indices of PLT sections within module. */
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f89685b67..5be955e59162 100644
--- a/arch/powerpc/kernel/module_64

Re: [PATCH] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

On Tuesday 03 October 2017 03:00 PM, Naveen N . Rao wrote:

Hi Naveen,

[snip]
> 
> A few small nits focusing on just the trampoline...
> 
>> diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S 
>> b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
>> index c98e90b..708a96d 100644
>> --- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
>> +++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
>> @@ -249,6 +249,83 @@ livepatch_handler:
>>
>>  /* Return to original caller of live patched function */
>>  blr
>> +
>> +/*
>> + * This livepatch stub code, called from livepatch module to jump into
>> + * kernel or other modules. It replicates the livepatch_handler code,
>> + * with an expection of jumping to the trampoline instead of patched
>> + * function.
>> + */
>> +.global klp_stub_insn
>> +klp_stub_insn:
>> +CURRENT_THREAD_INFO(r12, r1)
>> +
>> +/* Allocate 3 x 8 bytes */
>> +ld  r11, TI_livepatch_sp(r12)
>> +addir11, r11, 24
>> +std r11, TI_livepatch_sp(r12)
>> +
>> +/* Save toc & real LR on livepatch stack */
>> +std r2,  -24(r11)
>> +mflrr12
>> +std r12, -16(r11)
>> +
>> +/* Store stack end marker */
>> +lis r12, STACK_END_MAGIC@h
>> +ori r12, r12, STACK_END_MAGIC@l
>> +std r12, -8(r11)
> 
> Seeing as this is the same as livepatch_handler() except for this part 
> in the middle, does it make sense to reuse livepatch_handler() with 
> appropriate labels added for your use?  You could patch in the below 5 
> instructions using the macros from ppc-opcode.h...

Thanks for the review. The current upstream livepatch_handler code
is a bit different. I have posted a bug fix to 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-September/163824.html
which alters the livepatch_handler to have similar code. It's
a good idea to re-use the livepatch_handler code. I will re-spin
v2 with based on top of bug fix posted earlier.

> 
>> +
>> +/*
>> + * Stub memory is allocated dynamically, during the module load.
>> + * Load TOC relative address into r11. module_64.c::klp_stub_for_addr()
>> + * identifies the available free stub slot and loads the address into
>> + * r11 with two instructions.
>> + *
>> + * addis r11, r2, stub_address@ha
>> + * addi  r11, r11, stub_address@l
>> + */
>> +.global klp_stub_entry
>> +klp_stub_entry:
>> +addis   r11, r2, 0
>> +addir11, r11, 0
>> +
>> +/* Load the r12 with called function address from entry->funcdata */
>> +ld  r12, 128(r11)
>> +
>> +/* Move r12 into ctr for global entry and branch there */
>> +mtctr   r12
>> +bctrl
>> +
>> +/*
>> + * Now we are returning to the patched function. We are free to
>> + * use r11, r12 and we can use r2 until we restore it.
>> + */
>> +CURRENT_THREAD_INFO(r12, r1)
>> +
>> +ld  r11, TI_livepatch_sp(r12)
>> +
>> +/* Check stack marker hasn't been trashed */
>> +lis r2,  STACK_END_MAGIC@h
>> +ori r2,  r2, STACK_END_MAGIC@l
>> +ld  r12, -8(r11)
>> +2:  tdner12, r2
>> +EMIT_BUG_ENTRY 2b, __FILE__, __LINE__ - 1, 0
> 
> If you plan to keep this trampoline separate from livepatch_handler(), 
> note that the above bug entry is not required since you copy only the 
> text of this trampoline elsewhere and you won't have an associated bug 
> entry for that new stub address.
> 

Agree, klp_stub_entry trampoline will go away in v2. 

-- 
cheers,
Kamalesh.

[PATCH] kernel/module_64.c: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

With commit 425595a7fc20 ("livepatch: reuse module loader code to
write relocations") livepatch uses module loader to write relocations
of livepatch symbols, instead of managing them by arch-dependent
klp_write_module_reloc() function.

livepatch module managed relocation entries are written to sections
marked with SHF_RELA_LIVEPATCH flag and livepatch symbols within the
section are marked with SHN_LIVEPATCH symbol section index. When the
livepatching module is loaded, the livepatch symbols are resolved
before calling apply_relocate_add() to apply the relocations.

R_PPC64_REL24 relocation type resolves to a function address, those may
be local to the livepatch module or available in kernel/other modules.
For every such non-local function, apply_relocate_add() constructs a stub
(a.k.a trampoline) to branch to a function. Stub code is responsible
to save toc onto the stack, before calling the function via the global
entry point. A NOP instruction is expected after every non local function
branch, i.e. after the REL24 relocation. Which in-turn is replaced by
toc restore instruction by apply_relocate_add().

livepatch symbols with R_PPC64_REL24 relocation type, may not be
reachable within current TOC range or might not have a NOP instruction
following a branch. Latter symbols are the local symbols, whose became
global to the livepatched function. As per ABIv2, local functions are
accessed via local entry point, which is relative to current module's
toc value.

For example, consider the following livepatch relocations (the example is
from livepatch module generated by kpatch tool):

Relocation section '.klp.rela.vmlinux..text.meminfo_proc_show' at offset 
0x84530 contains 44 entries:
Offset Info Type  Symbol's Value   Symbol's 
Name + Addend
0054  0056000a R_PPC64_REL24   
.klp.sym.vmlinux.si_swapinfo,0 + 0
007c  0057000a R_PPC64_REL24   
.klp.sym.vmlinux.total_swapcache_pages,0 + 0
00e8  0058000a R_PPC64_REL24   
.klp.sym.vmlinux.show_val_kb,1 + 0
[...]

1. .klp.sym.vmlinux.si_swapinfo and .klp.sym.vmlinux.total_swapcache_pages
   are not available within the livepatch module TOC range.

2. .klp.sym.vmlinux.show_val_kb livepatch symbol was previously local
   but now global to fs/proc/meminfo.c::meminfo_proc_show().

While the livepatch module is loaded the livepatch symbols mentioned in
case 1 will fail with an error:
[   74.485405] module_64: kpatch_meminfo_string: REL24 -1152921504751525976 out 
of range!

and livepatch symbols mentioned in case 2 with fail with an error:
[   24.568425] module_64: kpatch_meminfo_string: Expect noop after relocate, 
got 3d22

Both the failures with REL24 livepatch symbols relocation, can be resolved
by constructing a new livepatch stub. The newly setup klp_stub mimics the
functionality of entry_64.S::livepatch_handler introduced by commit
85baa095497f ("powerpc/livepatch: Add live patching support on ppc64le").

Which introduces a "livepatch stack" growing upwards from the base of
the regular stack and is used to store/restore TOC/LR values, other than
the stub setup and branch. The additional instructions sequences to handle
klp_stub increases the stub size and current ppc64_stub_insn[] is not
sufficient to hold them. This patch also introduces new
ppc64le_klp_stub_entry[], along with the helpers to find/allocate
livepatch stub.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Cc: Balbir Singh <bsinghar...@gmail.com>
Cc: Naveen N. Rao <naveen.n@linux.vnet.ibm.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Jessica Yu <j...@kernel.org>
Cc: Ananth N Mavinakayanahalli <ana...@linux.vnet.ibm.com>
Cc: Aravinda Prasad <aravi...@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: live-patch...@vger.kernel.org
---
 arch/powerpc/include/asm/module.h  |   4 +
 arch/powerpc/kernel/module_64.c| 119 -
 arch/powerpc/kernel/trace/ftrace_64_mprofile.S |  77 
 3 files changed, 197 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/module.h 
b/arch/powerpc/include/asm/module.h
index 6c0132c..46d5eb0 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -44,6 +44,10 @@ struct mod_arch_specific {
unsigned long toc;
unsigned long tramp;
 #endif
+#ifdef CONFIG_LIVEPATCH
+   unsigned long klp_relocs;   /* Count of kernel livepatch 
relocations */
+#endif
+
 
 #else /* powerpc64 */
/* Indices of PLT sections within module. */
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..08e75ff 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -140,6 +140,25 @@ static u32 ppc64_stub_insns[] = {
0x4e800420  /* bct

Re: [PATCH] powerpc/livepatch: Fix livepatch stack access

[Kamalesh Babulal]

On Thursday 21 September 2017 10:25 PM, Naveen N . Rao wrote:

On 2017/09/21 09:00PM, Balbir Singh wrote:

On Thu, Sep 21, 2017 at 8:02 PM, Michael Ellerman <m...@ellerman.id.au> wrote:

Kamalesh Babulal <kamal...@linux.vnet.ibm.com> writes:


While running stress test with livepatch module loaded, kernel
bug was triggered.

cpu 0x5: Vector: 400 (Instruction Access) at [c000eb9d3b60]
pc: c000eb9d3e30
lr: c000eb9d3e30
sp: c000eb9d3de0
   msr: 80001280b033
  current = 0xc000dbd38700
  paca= 0xcfe01400   softe: 0irq_happened: 0x01
pid   = 8618, comm = make
Linux version 4.13.0+ (root@ubuntu) (gcc version 6.3.0 20170406 (Ubuntu 
6.3.0-12ubuntu2)) #1 SMP Wed Sep 13 03:49:27 EDT 2017

5:mon> t
[c000eb9d3de0] c000eb9d3e30 (unreliable)
[c000eb9d3e30] c0008ab4 hardware_interrupt_common+0x114/0x120
 --- Exception: 501 (Hardware Interrupt) at c0053040 
livepatch_handler+0x4c/0x74
[c000eb9d4120] 57ac6e9d (unreliable)
[d89d9f78] 2e0965747962382e
SP (965747962342e09) is in userspace

When an interrupt is served in between the livepatch_handler execution,
there are chances of the livepatch_stack/task task getting corrupted.


Ouch. That's pretty broken by me.



I was worried more about preemption as I said in the review comment earlier,
this is new. It looks like we restored the wrong r1 on returning from
the interrupt
context? It would be nice to see any pt_regs changes due to the interrupt.
Did the interrupt handling code called something that needed live-patching?


The problem is just that the livepatch stack grows up, rather than down.
So, when this stack is used during interrupt handling, we'll clobber
part of this stack.

There aren't any pt_regs changes due to this afaics. Just the livepatch
stack being over-written.




Fix the corruption by using r11 register for livepatch stack manipulation,
instead of shuffling task stack and livepatch stack into r1 register.
Using r11 register also avoids disabling/enabling irq's while setting
up the livepatch stack.


I'm trying to think if there's some reason I didn't use r11. But I can't
remember anything specific. I suspect I just didn't check the ABI


We can't use r11, this is ftrace with regs, we've restore registers before
calling livepatch_handler, I don't think we can clobber r11, but I might
be sleep deprived and missing something


r11 is volatile and meant for usage in function linkage. With
-mprofile-kernel, we've just entered the new function and haven't
touched r11 yet. So, it appears to me that we can definetely use/clobber
it, along with r0 and r12.



Misread the question from Balbir. livepatch_handler is called in mcount
context, which is very early in the function execution. r11 might
have live values used by the calling function, those are restored by
ftrace code but the called/calling function cannot rely on it, after
a function call as pointed out by Naveen.

In non-ftrace context, r11 is also used/clobbered between function calls 
to load the stub address.


--
cheers,
Kamalesh.

Re: [PATCH] powerpc/livepatch: Fix livepatch stack access

[Kamalesh Babulal]

On Thursday 21 September 2017 04:30 PM, Balbir Singh wrote:

On Thu, Sep 21, 2017 at 8:02 PM, Michael Ellerman <m...@ellerman.id.au> wrote:

Kamalesh Babulal <kamal...@linux.vnet.ibm.com> writes:


While running stress test with livepatch module loaded, kernel
bug was triggered.

cpu 0x5: Vector: 400 (Instruction Access) at [c000eb9d3b60]
pc: c000eb9d3e30
lr: c000eb9d3e30
sp: c000eb9d3de0
   msr: 80001280b033
  current = 0xc000dbd38700
  paca= 0xcfe01400   softe: 0irq_happened: 0x01
pid   = 8618, comm = make
Linux version 4.13.0+ (root@ubuntu) (gcc version 6.3.0 20170406 (Ubuntu 
6.3.0-12ubuntu2)) #1 SMP Wed Sep 13 03:49:27 EDT 2017

5:mon> t
[c000eb9d3de0] c000eb9d3e30 (unreliable)
[c000eb9d3e30] c0008ab4 hardware_interrupt_common+0x114/0x120
 --- Exception: 501 (Hardware Interrupt) at c0053040 
livepatch_handler+0x4c/0x74
[c000eb9d4120] 57ac6e9d (unreliable)
[d89d9f78] 2e0965747962382e
SP (965747962342e09) is in userspace

When an interrupt is served in between the livepatch_handler execution,
there are chances of the livepatch_stack/task task getting corrupted.


Ouch. That's pretty broken by me.



I was worried more about preemption as I said in the review comment earlier,
this is new. It looks like we restored the wrong r1 on returning from
the interrupt
context?


Yes, consider the example in the mail thread. Where the r0 is temporary 
used to hold the stack pointer value before loading r1 with the 
livepatch_sp (current->thread_info + 24). An interrupt occurs while the 
livepatch stack is being setup to store or restore the LR/TOC value of 
the calling function.


do_IRQ -> call_do_irq's first instruction mflr r0, over-writes the stack 
value with LR value. Consecutive instruction referring to r1 in 
call_do_irq are actually referring to the livepatch_sp instead of task 
stack. On the return to livepatch_handler, stack is restored from r0 
value (which has been over-written with LR value in call_do_irq). Any 
access therefore made to the stack is to a wrong address.



It would be nice to see any pt_regs changes due to the interrupt.
Did the interrupt handling code called something that needed live-patching?



AFAIK, the livepatch_sp value for softirq_ctx/hardirq_ctx are 
initialized, as it's part of thread_info. Am I missing something here.






Fix the corruption by using r11 register for livepatch stack manipulation,
instead of shuffling task stack and livepatch stack into r1 register.
Using r11 register also avoids disabling/enabling irq's while setting
up the livepatch stack.




The r11 is restored before calling the livepatch_handler by ftrace_caller:

/* Load CTR with the possibly modified NIP */
mtctr   r15

/* Restore gprs */
REST_GPR(0,r1)
REST_10GPRS(2,r1)
REST_10GPRS(12,r1)
REST_10GPRS(22,r1)

[...]

#ifdef CONFIG_LIVEPATCH
/*
 * Based on the cmpd or cmpdi above, if the NIP was altered and 
we're

 * not on a kprobe/jprobe, then handle livepatch.
 */
bne-livepatch_handler
#endif


--
cheers,
Kamalesh.

[PATCH] powerpc/livepatch: Fix livepatch stack access

[Kamalesh Babulal]

While running stress test with livepatch module loaded, kernel
bug was triggered.

cpu 0x5: Vector: 400 (Instruction Access) at [c000eb9d3b60]
pc: c000eb9d3e30
lr: c000eb9d3e30
sp: c000eb9d3de0
   msr: 80001280b033
  current = 0xc000dbd38700
  paca= 0xcfe01400   softe: 0irq_happened: 0x01
pid   = 8618, comm = make
Linux version 4.13.0+ (root@ubuntu) (gcc version 6.3.0 20170406 (Ubuntu 
6.3.0-12ubuntu2)) #1 SMP Wed Sep 13 03:49:27 EDT 2017

5:mon> t
[c000eb9d3de0] c000eb9d3e30 (unreliable)
[c000eb9d3e30] c0008ab4 hardware_interrupt_common+0x114/0x120
 --- Exception: 501 (Hardware Interrupt) at c0053040 
livepatch_handler+0x4c/0x74
[c000eb9d4120] 57ac6e9d (unreliable)
[d89d9f78] 2e0965747962382e
SP (965747962342e09) is in userspace

When an interrupt is served in between the livepatch_handler execution,
there are chances of the livepatch_stack/task task getting corrupted.

CPU 1
 =
Task A  Interrupt Handler
=   =
livepatch_handler:
 mr r0, r1
 ld r1, TI_livepatch_sp(r12)
hardware_interrupt_common
|_do_IRQ
  |_ call_do_irq:
mflr r0
std  r0,16(r1)
stdu 
r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r4)
...
lis r2, STACK_END_MAGIC@h
ori r2, r2, STACK_END_MAGIC@l
ld  r12, -8(r1)  <- livepatch stack is corrupted.

Fix the corruption by using r11 register for livepatch stack manipulation,
instead of shuffling task stack and livepatch stack into r1 register.
Using r11 register also avoids disabling/enabling irq's while setting
up the livepatch stack.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Cc: Balbir Singh <bsinghar...@gmail.com>
Cc: Naveen N. Rao <naveen.n@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 45 +-
 1 file changed, 15 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S 
b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
index c98e90b..b4e2b71 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
@@ -181,34 +181,25 @@ _GLOBAL(ftrace_stub)
 *  - we have no stack frame and can not allocate one
 *  - LR points back to the original caller (in A)
 *  - CTR holds the new NIP in C
-*  - r0 & r12 are free
-*
-* r0 can't be used as the base register for a DS-form load or store, so
-* we temporarily shuffle r1 (stack pointer) into r0 and then put it 
back.
+*  - r0, r11 & r12 are free
 */
 livepatch_handler:
CURRENT_THREAD_INFO(r12, r1)

-   /* Save stack pointer into r0 */
-   mr  r0, r1
-
/* Allocate 3 x 8 bytes */
-   ld  r1, TI_livepatch_sp(r12)
-   addir1, r1, 24
-   std r1, TI_livepatch_sp(r12)
+   ld  r11, TI_livepatch_sp(r12)
+   addir11, r11, 24
+   std r11, TI_livepatch_sp(r12)

/* Save toc & real LR on livepatch stack */
-   std r2,  -24(r1)
+   std r2,  -24(r11)
mflrr12
-   std r12, -16(r1)
+   std r12, -16(r11)

/* Store stack end marker */
lis r12, STACK_END_MAGIC@h
ori r12, r12, STACK_END_MAGIC@l
-   std r12, -8(r1)
-
-   /* Restore real stack pointer */
-   mr  r1, r0
+   std r12, -8(r11)

/* Put ctr in r12 for global entry and branch there */
mfctr   r12
@@ -216,36 +207,30 @@ livepatch_handler:

/*
 * Now we are returning from the patched function to the original
-* caller A. We are free to use r0 and r12, and we can use r2 until we
+* caller A. We are free to use r11, r12 and we can use r2 until we
 * restore it.
 */

CURRENT_THREAD_INFO(r12, r1)

-   /* Save stack pointer into r0 */
-   mr  r0, r1
-
-   ld  r1, TI_livepatch_sp(r12)
+   ld  r11, TI_livepatch_sp(r12)

/* Check stack marker hasn't been trashed */
lis r2,  STACK_END_MAGIC@h
ori r2,  r2, STACK_END_MAGIC@l
-   ld  r12, -8(r1)
+   ld  r12, -8(r11)
 1: tdner12, r2
EMIT_BUG_ENTRY 1b, __FILE__, __LINE__ - 1, 0

/* Restore LR & toc from livepatch stack */
-   ld  r12, -16(r1)
+   ld  r12, -16(r11)
mtlrr12
-   ld  r2,  -24(r1)
+   ld  r2,  -24(r11)

/* Pop livepatch stack frame */
-   CURRENT_THREAD_INFO(r12, r0)
-   subir1, r1, 24

Re: [PATCH 3/5] powerpc/kprobes: Fix warnings from __this_cpu_read() on preempt kernels

[Kamalesh Babulal]

On Thursday 14 September 2017 02:50 AM, Naveen N. Rao wrote:

Kamalesh pointed out that we are getting the below call traces with
livepatched functions when we enable CONFIG_PREEMPT:

[  495.470721] BUG: using __this_cpu_read() in preemptible [] code: 
cat/8394
[  495.471167] caller is is_current_kprobe_addr+0x30/0x90
[  495.471171] CPU: 4 PID: 8394 Comm: cat Tainted: G  K 
4.13.0-rc7-nnr+ #95
[  495.471173] Call Trace:
[  495.471178] [c0008fd9b960] [c09f039c] dump_stack+0xec/0x160 
(unreliable)
[  495.471184] [c0008fd9b9a0] [c059169c] 
check_preemption_disabled+0x15c/0x170
[  495.471187] [c0008fd9ba30] [c0046460] 
is_current_kprobe_addr+0x30/0x90
[  495.471191] [c0008fd9ba60] [c004e9a0] ftrace_call+0x1c/0xb8
[  495.471195] [c0008fd9bc30] [c0376fd8] seq_read+0x238/0x5c0
[  495.471199] [c0008fd9bcd0] [c03cfd78] proc_reg_read+0x88/0xd0
[  495.471203] [c0008fd9bd00] [c033e5d4] __vfs_read+0x44/0x1b0
[  495.471206] [c0008fd9bd90] [c03402ec] vfs_read+0xbc/0x1b0
[  495.471210] [c0008fd9bde0] [c0342138] SyS_read+0x68/0x110
[  495.471214] [c0008fd9be30] [c000bc6c] system_call+0x58/0x6c

Commit c05b8c4474c030 ("powerpc/kprobes: Skip livepatch_handler() for
jprobes") introduced a helper is_current_kprobe_addr() to help determine
if the current function has been livepatched or if it has a jprobe
installed, both of which modify the NIP.

In the case of a jprobe, kprobe_ftrace_handler() disables pre-emption
before calling into setjmp_pre_handler() which returns without disabling
pre-emption. This is done to ensure that the jprobe handler won't
disappear beneath us if the jprobe is unregistered between the
setjmp_pre_handler() and the subsequent longjmp_break_handler() called
from the jprobe handler. Due to this, we can use __this_cpu_read() in
is_current_kprobe_addr() with the pre-emption check as we know that
pre-emption will be disabled.

However, if this function has been livepatched, we are still doing this
check and when we do so, pre-emption won't necessarily be disabled. This
results in the call trace shown above.

Fix this by only invoking is_current_kprobe_addr() when pre-emption is
disabled. And since we now guard this within a pre-emption check, we can
instead use raw_cpu_read() to get the current_kprobe value skipping the
check done by __this_cpu_read().

Fixes: c05b8c4474c030 ("powerpc/kprobes: Skip livepatch_handler() for jprobes")
Reported-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Signed-off-by: Naveen N. Rao <naveen.n@linux.vnet.ibm.com>


Thanks, the call traces are not seen anymore with the patch.

Tested-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>




---
 arch/powerpc/kernel/kprobes.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index e848fe2c93fb..db40b13fd3d1 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -45,8 +45,12 @@ struct kretprobe_blackpoint kretprobe_blacklist[] = {{NULL, 
NULL}};

 int is_current_kprobe_addr(unsigned long addr)
 {
-   struct kprobe *p = kprobe_running();
-   return (p && (unsigned long)p->addr == addr) ? 1 : 0;
+   if (!preemptible()) {
+   struct kprobe *p = raw_cpu_read(current_kprobe);
+   return (p && (unsigned long)p->addr == addr) ? 1 : 0;
+   }
+
+   return 0;
 }

 bool arch_within_kprobe_blacklist(unsigned long addr)

Re: [PATCH 1/5] powerpc/kprobes: Some cosmetic updates to try_to_emulate()

[Kamalesh Babulal]

On Thursday 14 September 2017 02:50 AM, Naveen N. Rao wrote:

1. This is only used in kprobes.c, so make it static.
2. Remove the un-necessary (ret == 0) comparison in the else clause.

Signed-off-by: Naveen N. Rao <naveen.n@linux.vnet.ibm.com>


Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>


---
 arch/powerpc/kernel/kprobes.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 367494dc67d9..c2a6ab38a67f 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -239,7 +239,7 @@ void arch_prepare_kretprobe(struct kretprobe_instance *ri, 
struct pt_regs *regs)
 }
 NOKPROBE_SYMBOL(arch_prepare_kretprobe);

-int try_to_emulate(struct kprobe *p, struct pt_regs *regs)
+static int try_to_emulate(struct kprobe *p, struct pt_regs *regs)
 {
int ret;
unsigned int insn = *p->ainsn.insn;
@@ -261,7 +261,7 @@ int try_to_emulate(struct kprobe *p, struct pt_regs *regs)
 */
printk("Can't step on instruction %x\n", insn);
BUG();
-   } else if (ret == 0)
+   } else
/* This instruction can't be boosted */
p->ainsn.boostable = -1;

[RESEND PATCH] powerpc/modules: Introduce new stub code for SHN_LIVEPATCH symbols

[Kamalesh Babulal]

R_PPC64_REL24 relocation type is used for a function call, where the
function symbol address is resolved and stub code (a.k.a trampoline)
is constructed to jump into the global entry of the function. The
caller is responsible for setting up the TOC of the called function
before branching and NOP is expected after every branch, which gets
replaced with an instruction to restore the callers TOC from the
stack on return.

SHN_LIVEPATCH symbols with R_PPC64_REL24 relocation type might not
adhere to nop instruction after a branch. The reason being called
function was local to the callee and the instruction sequence
generated does not stores and restores the TOC value onto the stack
of the calling function, which is right. The calling function instead
uses the localentry (function entry + 0x8) to jump into the function
and returns without the need for store/restoring the TOC, as both of
the functions were in the same compilation unit.

When such functions become global because they are livepatched and
every call to the function, re-directs the callee to the patched
version in the module. Every branch from the livepatch module, to
previously local function turns out to be a jump into the kernel
code but with the code sequence remains that of the localentry. This
leads to error while trying to access the function with an assumption,
of being local to the calling function:

insmod: ERROR: could not insert module ./kpatch-meminfo-string.ko: Invalid 
module format

Jun 13 02:10:47 ubuntu kernel: [   37.774292] module_64: kpatch_meminfo_string: 
REL24 -1152921504749690968 out of range!

SHN_LIVEPATCH symbols + R_PPC64_REL24 type relocations can be handled
by introducing a new stub code sequence, instead of regular module stub
code. Where stub takes care of storing and restoring the Link Register/TOC
onto the stack of the livepatched function and restores them upon
return from the called function.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Balbir Singh <bsinghar...@gmail.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Jessica Yu <j...@kernel.org>
Cc: Ananth N Mavinakayanahalli <ana...@linux.vnet.ibm.com>
Cc: Aravinda Prasad <aravi...@linux.vnet.ibm.com>
Cc: live-patch...@vger.kernel.org
---
Resending the patch with minor editing of commit message and have added
more developers to cc list.

 arch/powerpc/kernel/module_64.c | 55 -
 1 file changed, 44 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..52ded0f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -102,10 +102,16 @@ static unsigned int local_entry_offset(const Elf64_Sym 
*sym)
jump, actually, to reset r2 (TOC+0x8000). */
 struct ppc64_stub_entry
 {
-   /* 28 byte jump instruction sequence (7 instructions). We only
-* need 6 instructions on ABIv2 but we always allocate 7 so
-* so we don't have to modify the trampoline load instruction. */
-   u32 jump[7];
+   /* 28 byte jump instruction sequence (7 instructions) and only
+* 6 instructions are needed on ABIv2 to create trampoline.
+* Trampoline for livepatch symbol needs extra 7 instructions
+* to save and restore LR, TOC values.
+*
+* To accommodate extra instructions required for livepatch
+* entry, we allocate 15 instructions so we don't have to
+* modify the trampoline load instruction.
+*/
+   u32 jump[15];
/* Used by ftrace to identify stubs */
u32 magic;
/* Data for the above code */
@@ -131,7 +137,7 @@ static u32 ppc64_stub_insns[] = {
0x396b, /* addir11,r11,  */
/* Save current r2 value in magic place on the stack. */
0xf841|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
-   0xe98b0020, /* ld  r12,32(r11) */
+   0xe98b0040, /* ld  r12,64(r11) */
 #ifdef PPC64_ELF_ABI_v1
/* Set up new r2 from function descriptor */
0xe84b0028, /* ld  r2,40(r11) */
@@ -140,6 +146,24 @@ static u32 ppc64_stub_insns[] = {
0x4e800420  /* bctr */
 };
 
+static u32 ppc64_klp_stub_insns[] = {
+   0x3d62, /* addis   r11,r2,*/
+   0x396b, /* addir11,r11,*/
+   0x7c0802a6, /* mflrr0   */
+   0xf8010010, /* std r0,16(r1)*/
+   /* Save current r2 value in magic place on the stack. */
+   0xf841|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
+   0xe98b0040, /* ld  r12,64(r11)  */
+   0xf821ffe1, /* stdu

Re: [PATCH] powerpc/modules: Introduce new stub code for SHN_LIVEPATCH symbols

[Kamalesh Babulal]

Hi Michael,

Any thoughts/suggestions on the approach ?


On Tuesday 13 June 2017 12:20 PM, Kamalesh Babulal wrote:

R_PPC64_REL24 relocation type is used for a function call, where the
function symbol address is resolved and stub code (a.k.a trampoline)
is constructed to jump into the global entry of the function. The
caller is responsible for setting up the TOC of the called function
before branching and NOP is expected after every branch, which gets
replaced with an instruction to restore the callers TOC from the
stack on return.

SHN_LIVEPATCH symbols with R_PPC64_REL24 relocation type might not
adhere to nop instruction after a branch. The reason being called
function was local to the callee and the instruction sequence
generated does not stores and restores the TOC value onto the stack
of the calling function, which is right instead uses the localentry
(function entry + 0x8) to jump into the function and returns without
the need for store/restoring the TOC, as both of the functions were
in the same compilation unit.

When such functions become global because they are livepatched and
every call to the function, re-directs the callee to the patched
version in the module. Every branch from the livepatch module, to
previously local function turns out to jump into the kernel code
but with the code, sequence remains that of the localentry. This
leads to error while trying to access the function with assumption.

insmod: ERROR: could not insert module ./kpatch-meminfo-string.ko: Invalid 
module format

Jun 13 02:10:47 ubuntu kernel: [   37.774292] module_64: kpatch_meminfo_string: 
REL24 -1152921504749690968 out of range!

SHN_LIVEPATCH symbols + R_PPC64_REL24 type relocation should be handled
by introducing a new stub code sequence, instead of regular stub code.
Where stub takes care of storing and restoring the Link Register/TOC
onto the stack of the livepatched function and restores them upon
return from the called function.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Balbir Singh <bsinghar...@gmail.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Jessica Yu <j...@kernel.org>
Cc: live-patch...@vger.kernel.org
---
 arch/powerpc/kernel/module_64.c | 55 -
 1 file changed, 44 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..52ded0f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -102,10 +102,16 @@ static unsigned int local_entry_offset(const Elf64_Sym 
*sym)
jump, actually, to reset r2 (TOC+0x8000). */
 struct ppc64_stub_entry
 {
-   /* 28 byte jump instruction sequence (7 instructions). We only
-* need 6 instructions on ABIv2 but we always allocate 7 so
-* so we don't have to modify the trampoline load instruction. */
-   u32 jump[7];
+   /* 28 byte jump instruction sequence (7 instructions) and only
+* 6 instructions are needed on ABIv2 to create trampoline.
+* Trampoline for livepatch symbol needs extra 7 instructions
+* to save and restore LR, TOC values.
+*
+* To accommodate extra instructions required for livepatch
+* entry, we allocate 15 instructions so we don't have to
+* modify the trampoline load instruction.
+*/
+   u32 jump[15];
/* Used by ftrace to identify stubs */
u32 magic;
/* Data for the above code */
@@ -131,7 +137,7 @@ static u32 ppc64_stub_insns[] = {
0x396b, /* addir11,r11,  */
/* Save current r2 value in magic place on the stack. */
0xf841|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
-   0xe98b0020, /* ld  r12,32(r11) */
+   0xe98b0040, /* ld  r12,64(r11) */
 #ifdef PPC64_ELF_ABI_v1
/* Set up new r2 from function descriptor */
0xe84b0028, /* ld  r2,40(r11) */
@@ -140,6 +146,24 @@ static u32 ppc64_stub_insns[] = {
0x4e800420  /* bctr */
 };

+static u32 ppc64_klp_stub_insns[] = {
+   0x3d62, /* addis   r11,r2,  */
+   0x396b, /* addir11,r11,  */
+   0x7c0802a6, /* mflrr0   */
+   0xf8010010, /* std r0,16(r1)*/
+   /* Save current r2 value in magic place on the stack. */
+   0xf841|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
+   0xe98b0040, /* ld  r12,64(r11)  */
+   0xf821ffe1, /* stdur1,-32(r1)   */
+   0x7d8903a6, /* mtctr   r12  */
+   0x4e800421, /* bctrl*/
+   0x38210020,  

Re: [PATCH] recordmcount.pl: Add ppc64le to list of supported architectures

[Kamalesh Babulal]

On Wednesday 14 June 2017 10:23 AM, Michael Ellerman wrote:

I don't get this, the arch should always be powerpc.

Right. Something else is fubar for that to happen, we should fix
whatever it is.


Agree, ARCH over-ruling by reading the underlying architecture will
not work, as the expectation is to have ARCH=powerpc for all of the 
powerpc platform. Sorry for the noise, kindly ignore this patch.


--
cheers,
Kamalesh.

Re: [PATCH] recordmcount.pl: Add ppc64le to list of supported architectures

[Kamalesh Babulal]

On Wednesday 14 June 2017 04:22 AM, Balbir Singh wrote:

On Tue, Jun 13, 2017 at 4:49 PM, Kamalesh Babulal <
kamal...@linux.vnet.ibm.com> wrote:


Module make on ppc64le, fails with:

make -C /root/kernel/linux M=/root/.kpatch/tmp/patch
kpatch-data-read-mostly.ko
make[1]: Entering directory '/root/kernel/linux'
  CC [M]  /root/.kpatch/tmp/patch/patch-hook.o
Arch ppc64le is not supported with CONFIG_FTRACE_MCOUNT_RECORD at
./scripts/recordmcount.pl line 379.

Fix it by adding 'ppc64le' to list of supported architectures
in recordmcount.pl script.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Balbir Singh <bsinghar...@gmail.com>
---
 scripts/recordmcount.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 1633c3e..683b8b5 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -264,7 +264,7 @@ if ($arch eq "x86_64") {
 $ld .= " -m shlelf_linux";
 $objcopy .= " -O elf32-sh-linux";

-} elsif ($arch eq "powerpc") {
+} elsif ($arch eq "powerpc" || $arch eq "ppc64le") {



I don't get this, the arch should always be powerpc. Where did you get the
ppc64le
from? Am I missing anything?

Balbir Singh.



Thanks for the review. True, the top level Makefile derives the ARCH 
from SUBARCH where ppc64le is replaced by powerpc. Out of tree module 
build fails, where the ARCH gets overruled to underlying arch type.


--
cheers,
Kamalesh.

[PATCH] powerpc/modules: Introduce new stub code for SHN_LIVEPATCH symbols

[Kamalesh Babulal]

R_PPC64_REL24 relocation type is used for a function call, where the
function symbol address is resolved and stub code (a.k.a trampoline)
is constructed to jump into the global entry of the function. The
caller is responsible for setting up the TOC of the called function
before branching and NOP is expected after every branch, which gets
replaced with an instruction to restore the callers TOC from the
stack on return.

SHN_LIVEPATCH symbols with R_PPC64_REL24 relocation type might not
adhere to nop instruction after a branch. The reason being called
function was local to the callee and the instruction sequence
generated does not stores and restores the TOC value onto the stack
of the calling function, which is right instead uses the localentry
(function entry + 0x8) to jump into the function and returns without
the need for store/restoring the TOC, as both of the functions were
in the same compilation unit.

When such functions become global because they are livepatched and
every call to the function, re-directs the callee to the patched
version in the module. Every branch from the livepatch module, to
previously local function turns out to jump into the kernel code
but with the code, sequence remains that of the localentry. This
leads to error while trying to access the function with assumption.

insmod: ERROR: could not insert module ./kpatch-meminfo-string.ko: Invalid 
module format

Jun 13 02:10:47 ubuntu kernel: [   37.774292] module_64: kpatch_meminfo_string: 
REL24 -1152921504749690968 out of range!

SHN_LIVEPATCH symbols + R_PPC64_REL24 type relocation should be handled
by introducing a new stub code sequence, instead of regular stub code.
Where stub takes care of storing and restoring the Link Register/TOC
onto the stack of the livepatched function and restores them upon
return from the called function.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Balbir Singh <bsinghar...@gmail.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Jessica Yu <j...@kernel.org>
Cc: live-patch...@vger.kernel.org
---
 arch/powerpc/kernel/module_64.c | 55 -
 1 file changed, 44 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..52ded0f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -102,10 +102,16 @@ static unsigned int local_entry_offset(const Elf64_Sym 
*sym)
jump, actually, to reset r2 (TOC+0x8000). */
 struct ppc64_stub_entry
 {
-   /* 28 byte jump instruction sequence (7 instructions). We only
-* need 6 instructions on ABIv2 but we always allocate 7 so
-* so we don't have to modify the trampoline load instruction. */
-   u32 jump[7];
+   /* 28 byte jump instruction sequence (7 instructions) and only
+* 6 instructions are needed on ABIv2 to create trampoline.
+* Trampoline for livepatch symbol needs extra 7 instructions
+* to save and restore LR, TOC values.
+*
+* To accommodate extra instructions required for livepatch
+* entry, we allocate 15 instructions so we don't have to
+* modify the trampoline load instruction.
+*/
+   u32 jump[15];
/* Used by ftrace to identify stubs */
u32 magic;
/* Data for the above code */
@@ -131,7 +137,7 @@ static u32 ppc64_stub_insns[] = {
0x396b, /* addir11,r11,  */
/* Save current r2 value in magic place on the stack. */
0xf841|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
-   0xe98b0020, /* ld  r12,32(r11) */
+   0xe98b0040, /* ld  r12,64(r11) */
 #ifdef PPC64_ELF_ABI_v1
/* Set up new r2 from function descriptor */
0xe84b0028, /* ld  r2,40(r11) */
@@ -140,6 +146,24 @@ static u32 ppc64_stub_insns[] = {
0x4e800420  /* bctr */
 };
 
+static u32 ppc64_klp_stub_insns[] = {
+   0x3d62, /* addis   r11,r2,*/
+   0x396b, /* addir11,r11,*/
+   0x7c0802a6, /* mflrr0   */
+   0xf8010010, /* std r0,16(r1)*/
+   /* Save current r2 value in magic place on the stack. */
+   0xf841|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
+   0xe98b0040, /* ld  r12,64(r11)  */
+   0xf821ffe1, /* stdur1,-32(r1)   */
+   0x7d8903a6, /* mtctr   r12  */
+   0x4e800421, /* bctrl*/
+   0x38210020, /* addir1,r1,32 */
+   0xe8010010, /* ld  r0,16(r1)   

[PATCH] recordmcount.pl: Add ppc64le to list of supported architectures

[Kamalesh Babulal]

Module make on ppc64le, fails with:

make -C /root/kernel/linux M=/root/.kpatch/tmp/patch kpatch-data-read-mostly.ko
make[1]: Entering directory '/root/kernel/linux'
  CC [M]  /root/.kpatch/tmp/patch/patch-hook.o
Arch ppc64le is not supported with CONFIG_FTRACE_MCOUNT_RECORD at 
./scripts/recordmcount.pl line 379.

Fix it by adding 'ppc64le' to list of supported architectures
in recordmcount.pl script.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Balbir Singh <bsinghar...@gmail.com>
---
 scripts/recordmcount.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 1633c3e..683b8b5 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -264,7 +264,7 @@ if ($arch eq "x86_64") {
 $ld .= " -m shlelf_linux";
 $objcopy .= " -O elf32-sh-linux";
 
-} elsif ($arch eq "powerpc") {
+} elsif ($arch eq "powerpc" || $arch eq "ppc64le") {
 $local_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\.?\\S+)";
 # See comment in the sparc64 section for why we use '\w'.
 $function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?\\w*?)>:";
-- 
2.7.4

Re: [PATCH v3 12/15] livepatch: store function sizes

[Kamalesh Babulal]

On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:

For the consistency model we'll need to know the sizes of the old and
new functions to determine if they're on the stacks of any tasks.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

--
cheers,
Kamalesh.

Re: [PATCH v3 04/15] livepatch/x86: add TIF_PATCH_PENDING thread flag

[Kamalesh Babulal]

On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:

Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for x86_64.  The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.

The bit is placed in the _TIF_ALLWORK_MASK macro, which results in
exit_to_usermode_loop() calling klp_update_patch_state() when it's set.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

--
cheers,
Kamalesh.

Re: [PATCH v3 09/15] livepatch: remove unnecessary object loaded check

[Kamalesh Babulal]

On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:

klp_patch_object()'s callers already ensure that the object is loaded,
so its call to klp_is_object_loaded() is unnecessary.

This will also make it possible to move the patching code into a
separate file.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

--
cheers,
Kamalesh.

Re: [PATCH v3 10/15] livepatch: move patching functions into patch.c

[Kamalesh Babulal]

On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:

Move functions related to the actual patching of functions and objects
into a new patch.c file.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

--
cheers,
Kamalesh.

Re: [PATCH v3 08/15] livepatch: separate enabled and patched states

[Kamalesh Babulal]

On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:

Once we have a consistency model, patches and their objects will be
enabled and disabled at different times.  For example, when a patch is
disabled, its loaded objects' funcs can remain registered with ftrace
indefinitely until the unpatching operation is complete and they're no
longer in use.

It's less confusing if we give them different names: patches can be
enabled or disabled; objects (and their funcs) can be patched or
unpatched:

- Enabled means that a patch is logically enabled (but not necessarily
  fully applied).

- Patched means that an object's funcs are registered with ftrace and
  added to the klp_ops func stack.

Also, since these states are binary, represent them with booleans
instead of ints.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

--
cheers,
Kamalesh.

Re: [PATCH v3 02/15] x86/entry: define _TIF_ALLWORK_MASK flags explicitly

[Kamalesh Babulal]

On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:

The _TIF_ALLWORK_MASK macro automatically includes the least-significant
16 bits of the thread_info flags, which is less than obvious and tends
to create confusion and surprises when reading or modifying the code.

Define the flags explicitly.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


For the version with swapped _TIF_SINGLESTEP and _TIF_NEED_RESCHED
flags.

Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

--
cheers,
Kamalesh.

Re: [PATCH v3 05/15] livepatch/powerpc: add TIF_PATCH_PENDING thread flag

[Kamalesh Babulal]

On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:

Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for powerpc.  The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.

The bit is included in the _TIF_USER_WORK_MASK macro so that
do_notify_resume() and klp_update_patch_state() get called when the bit
is set.

Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>


Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

--
cheers,
Kamalesh.

[PATCH] powerpc/livepatch: Remove klp_write_module_reloc() stub

[Kamalesh Babulal]

commit 425595a7fc20 ("livepatch: reuse module loader code
to write relocations") offloads livepatch module relocation
write to arch specific module loader code.

Remove unused klp_write_module_reloc() function stub.

Signed-off-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/livepatch.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/powerpc/include/asm/livepatch.h 
b/arch/powerpc/include/asm/livepatch.h
index a402f7f..47a03b9 100644
--- a/arch/powerpc/include/asm/livepatch.h
+++ b/arch/powerpc/include/asm/livepatch.h
@@ -28,13 +28,6 @@ static inline int klp_check_compiler_support(void)
return 0;
 }
 
-static inline int klp_write_module_reloc(struct module *mod, unsigned long
-   type, unsigned long loc, unsigned long value)
-{
-   /* This requires infrastructure changes; we need the loadinfos. */
-   return -ENOSYS;
-}
-
 static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
 {
regs->nip = ip;
-- 
2.7.4

Re: [PATCH HACK 1/6] livepatch-test: Add more cases

[Kamalesh Babulal]

* Balbir Singh <bsinghar...@gmail.com> [2016-03-26 18:11:22]:

> On Fri, Mar 25, 2016 at 3:37 AM, Kamalesh Babulal
> <kamal...@linux.vnet.ibm.com> wrote:
> > * Michael Ellerman <m...@ellerman.id.au> [2016-03-24 22:04:00]:
> >
> >> Not for merging.
> >>
> >
> > Hi Michael,
> >
> > Loading the livepatch sample module, trigger following warning
> >
> 
> The #if IS_MODULE(CONFIG_SCSI) code is buggy, you probably have
> CONFIG_SCSI=y, make it M or you can fix the code yourself. I had the
> same issue while testing
> 
> BTW, the tests worked fine with the changes proposed by Michael.
> 

Thanks, It helped. I was able to load the sample livepatch module
with proposed changes.

Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH HACK 1/6] livepatch-test: Add more cases

[Kamalesh Babulal]

* Michael Ellerman  [2016-03-24 22:04:00]:

> Not for merging.
> 

Hi Michael,

Loading the livepatch sample module, trigger following warning

Mar 24 21:44:59 ubuntu kernel: [   40.467580] sysfs: cannot create duplicate 
filename '/kernel/livepatch/livepatch_sample/vmlinux'
Mar 24 21:44:59 ubuntu kernel: [   40.467601] [ cut here 
]
Mar 24 21:44:59 ubuntu kernel: [   40.467603] WARNING: at fs/sysfs/dir.c:31
Mar 24 21:44:59 ubuntu kernel: [   40.467604] Modules linked in: 
livepatch_sample(+) rtc_generic autofs4 ibmvscsi
Mar 24 21:44:59 ubuntu kernel: [   40.467610] CPU: 5 PID: 1479 Comm: modprobe 
Not tainted 4.5.0+ #2
Mar 24 21:44:59 ubuntu kernel: [   40.467612] task: c00039a1b800 ti: 
c0003767c000 task.ti: c0003767c000
Mar 24 21:44:59 ubuntu kernel: [   40.467614] NIP: c038bddc LR: 
c038bdd8 CTR: c0557b20
Mar 24 21:44:59 ubuntu kernel: [   40.467615] REGS: c0003767f4b0 TRAP: 0700 
  Not tainted  (4.5.0+)
Mar 24 21:44:59 ubuntu kernel: [   40.467616] MSR: 800102029033 
  CR: 28222442  XER: 2000
Mar 24 21:44:59 ubuntu kernel: [   40.467624] CFAR: c0a65fac SOFTE: 1 
Mar 24 21:44:59 ubuntu kernel: [   40.467624] GPR00: c038bdd8 
c0003767f730 c14c3d00 0054 
Mar 24 21:44:59 ubuntu kernel: [   40.467624] GPR04: c0003fe49c58 
c0003fe5b4d8 0064 010f 
Mar 24 21:44:59 ubuntu kernel: [   40.467624] GPR08: 0007 
c0ecb274 3ef8 7461706576696c2f 
Mar 24 21:44:59 ubuntu kernel: [   40.467624] GPR12: 2200 
cfe80f00 d155c498 c0003767fdb0 
Mar 24 21:44:59 ubuntu kernel: [   40.467624] GPR16: 003d 
c13cc318  c0cf1510 
Mar 24 21:44:59 ubuntu kernel: [   40.467624] GPR20: c13cc328 
c1478f28 d1570cb8 d1570c98 
Mar 24 21:44:59 ubuntu kernel: [   40.467624] GPR24: c0cc0070 
c1478f50  d1570cb8 
Mar 24 21:44:59 ubuntu kernel: [   40.467624] GPR28: d15708d0 
c0003c750870 c0cbfe68 c0003a73 
Mar 24 21:44:59 ubuntu kernel: [   40.467642] NIP [c038bddc] 
sysfs_warn_dup+0x8c/0xc0
Mar 24 21:44:59 ubuntu kernel: [   40.467645] LR [c038bdd8] 
sysfs_warn_dup+0x88/0xc0
Mar 24 21:44:59 ubuntu kernel: [   40.467645] Call Trace:
Mar 24 21:44:59 ubuntu kernel: [   40.467648] [c0003767f730] 
[c038bdd8] sysfs_warn_dup+0x88/0xc0 (unreliable)
Mar 24 21:44:59 ubuntu kernel: [   40.467650] [c0003767f7b0] 
[c038bfac] sysfs_create_dir_ns+0xdc/0x100
Mar 24 21:44:59 ubuntu kernel: [   40.467652] [c0003767f7f0] 
[c054b354] kobject_add_internal+0xe4/0x420
Mar 24 21:44:59 ubuntu kernel: [   40.467654] [c0003767f880] 
[c054ba34] kobject_init_and_add+0x64/0xa0
Mar 24 21:44:59 ubuntu kernel: [   40.467657] [c0003767f900] 
[c0135e8c] klp_register_patch+0x1ac/0x3b0
Mar 24 21:44:59 ubuntu kernel: [   40.467659] [c0003767f9e0] 
[d1570354] livepatch_init+0x34/0xc0 [livepatch_sample]
Mar 24 21:44:59 ubuntu kernel: [   40.467661] [c0003767fa10] 
[c000b5ac] do_one_initcall+0x12c/0x2a0
Mar 24 21:44:59 ubuntu kernel: [   40.467664] [c0003767fae0] 
[c0a6647c] do_init_module+0x98/0x254
Mar 24 21:44:59 ubuntu kernel: [   40.467666] [c0003767fb70] 
[c0163178] load_module+0x22c8/0x2a80
Mar 24 21:44:59 ubuntu kernel: [   40.467668] [c0003767fd40] 
[c0163c90] SyS_finit_module+0x110/0x170
Mar 24 21:44:59 ubuntu kernel: [   40.467670] [c0003767fe30] 
[c0009204] system_call+0x38/0xb4
Mar 24 21:44:59 ubuntu kernel: [   40.467671] Instruction dump:
Mar 24 21:44:59 ubuntu kernel: [   40.467672] 4182001c 7fe4fb78 38a01000 
7fa3eb78 4bffa3bd 6000 7c641b78 3c62ff82 
Mar 24 21:44:59 ubuntu kernel: [   40.467676] 7fc5f378 386392c0 486da175 
6000 <0fe0> 7fe3fb78 4bf16c95 6000 
Mar 24 21:44:59 ubuntu kernel: [   40.467680] ---[ end trace 77c74eaaf32878c5 
]---
Mar 24 21:44:59 ubuntu kernel: [   40.467681] kobject_add_internal failed for 
vmlinux with -EEXIST, don't try to register things with the same name in the 
same directory.
Mar 24 21:44:59 ubuntu kernel: [   40.467694] [ cut here 
]
Mar 24 21:44:59 ubuntu kernel: [   40.467696] WARNING: at lib/kobject.c:240
Mar 24 21:44:59 ubuntu kernel: [   40.467697] Modules linked in: 
livepatch_sample(+) rtc_generic autofs4 ibmvscsi
Mar 24 21:44:59 ubuntu kernel: [   40.467700] CPU: 5 PID: 1479 Comm: modprobe 
Tainted: GW   4.5.0+ #2
Mar 24 21:44:59 ubuntu kernel: [   40.467702] task: c00039a1b800 ti: 
c0003767c000 task.ti: c0003767c000
Mar 24 21:44:59 ubuntu kernel: [   40.467703] NIP: c054b5ec LR: 
c054b5e8 CTR: c0557b20
Mar 24 21:44:59 ubuntu kernel: [   40.467704] REGS: c0003767f570 TRAP: 0700 
  Tainted: G   

Re: [PATCH/RFC] ppc64 livepatch: frameless klp_return_helper using odd TOC

[Kamalesh Babulal]

* Torsten Duwe <d...@lst.de> [2016-03-24 11:27:57]:

> On Thu, Mar 24, 2016 at 03:44:55PM +0530, Kamalesh Babulal wrote:
> > * Torsten Duwe <d...@lst.de> [2016-03-23 16:58:58]:
> > 
> > > 
> > > Since nobody liked the extra stack frame nor its workarounds, here is
> > > the next attempt. Assumptions:
> > > 
> > > 1. Heuristics are bad. The better they are, the more subtly the
> > >way they might fail.
> > > 
> > > 2. The TOC pointer is usually dividable by 4, if not by 8. An odd
> > >value never occurs.
> > > 
> > > Conclusively, this patch unambiguously creates an odd TOC value when
> > > an ftraced function's global entry point is used. Ftrace_caller will
> > > then immediately fix it, and alongside gather the information whether
> > > the made call was local or global.
> > > 
> > > In case of live patching this information is furthermore used to decide
> > > whether a klp_return_helper needs to be inserted or not.
> > > CAVEAT: any frameless klp_return_helper does not play well with
> > > sibling calls! There's an emergency exit that might work, at worst
> > > it will cause an oops, but it surely avoids a lockup.
> > > At least the live patching modules on ppc64le will need to be compiled
> > > using the -fno-optimize-sibling-calls compiler flag!
> > > 
> > > Thanks go to Michael Matz and Richard Biener for reassurance about
> > > heuristics and pointers to the compiler flag.
> > > 
> > > Signed-off-by: Torsten Duwe <d...@suse.de>
> > 
> > Hi Torsten,
> > 
> > Should this patch be applied over Petr Mladek's v4 ?
> 
> Yes. Just omit the changes it makes to entry_64.S and use this instead.

Thanks, I was able to successfully execute basic livepatch sample module test.


Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH/RFC] ppc64 livepatch: frameless klp_return_helper using odd TOC

[Kamalesh Babulal]

* Torsten Duwe  [2016-03-23 16:58:58]:

> 
> Since nobody liked the extra stack frame nor its workarounds, here is
> the next attempt. Assumptions:
> 
> 1. Heuristics are bad. The better they are, the more subtly the
>way they might fail.
> 
> 2. The TOC pointer is usually dividable by 4, if not by 8. An odd
>value never occurs.
> 
> Conclusively, this patch unambiguously creates an odd TOC value when
> an ftraced function's global entry point is used. Ftrace_caller will
> then immediately fix it, and alongside gather the information whether
> the made call was local or global.
> 
> In case of live patching this information is furthermore used to decide
> whether a klp_return_helper needs to be inserted or not.
> CAVEAT: any frameless klp_return_helper does not play well with
> sibling calls! There's an emergency exit that might work, at worst
> it will cause an oops, but it surely avoids a lockup.
> At least the live patching modules on ppc64le will need to be compiled
> using the -fno-optimize-sibling-calls compiler flag!
> 
> Thanks go to Michael Matz and Richard Biener for reassurance about
> heuristics and pointers to the compiler flag.
> 
> Signed-off-by: Torsten Duwe 

Hi Torsten,

Should this patch be applied over Petr Mladek's v4 ?

Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc

[Kamalesh Babulal]

* Petr Mladek <pmla...@suse.com> [2016-03-03 17:52:01]:

> From: Balbir Singh <bsinghar...@gmail.com>
> 
> Changelog v4:
>   1. Renamed klp_matchaddr() to klp_get_ftrace_location()
>  and used it just to convert the function address.
>   2. Synced klp_write_module_reloc() with s390(); made it
>  inline, no error message, return -ENOSYS
>   3. Added an error message when including
>  powerpc/include/asm/livepatch.h without HAVE_LIVEPATCH
>   4. Update some comments.
> Changelog v3:
>   1. Moved -ENOSYS to -EINVAL in klp_write_module_reloc
>   2. Moved klp_matchaddr to use ftrace_location_range
> Changelog v2:
>   1. Implement review comments by Michael
>   2. The previous version compared _NIP from the
>  wrong location to check for whether we
>  are going to a patched location
> 
> This applies on top of the patches posted by Michael
> https://patchwork.ozlabs.org/patch/589791/
> 
> It enables livepatching. This takes patch 6/8 and 7/8 of v8 as the base.
> (See the reference [1] below) and adds logic for checking offset ranges
> in livepatch with ftrace_location_range.
> 
> I tested the sample in the livepatch
> 
> Signed-off-by: Torsten Duwe <d...@suse.de>
> Signed-off-by: Balbir Singh <bsinghar...@gmail.com>
> Signed-off-by: Petr Mladek <pmla...@suse.com>

Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

I tried it, with the sample livepatch module.

Tested-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>



Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC][PATCH][v2] Enable livepatching for powerpc

[Kamalesh Babulal]

* Balbir Singh <bsinghar...@gmail.com> [2016-03-03 18:00:54]:

> Changelog:
>   1. Implement review comments by Michael
>   2. The previous version compared _NIP from the
>  wrong location to check for whether we
>  are going to a patched location
> 
> This applies on top of the patches posted by Michael 
> https://patchwork.ozlabs.org/patch/589791/
> 
> It enables livepatching. This takes patch 6/8 and 7/8 of v8 as the base.
> Removes the extra strict check in gcc-profile-kernel-notrace.sh
> and adds logic for checking offsets in livepatch. The patch
> for HAVE_C_RECORDMCOUNT is not required and not used here.
> 
> Depending on whether or not a TOC is generated, the offset
> for _mcount can be +16,+12,+8,+4. The changes are such that the
> offset checks are specific to powerpc.
> 
> TODOs
> 1. Build a version with offsets removed and rebuild
>ftrace_location() sort of functionality
> 2. Make livepatching experimental on powerpc
> 
> Comments? Testing? I tested the sample in the livepatch
> directory
> 
> References
> 
> 1. https://patchwork.ozlabs.org/patch/581521/
> 2. https://patchwork.ozlabs.org/patch/587464/
> 
> Signed-off-by: Torsten Duwe <d...@suse.de>
> Signed-off-by: Balbir Singh <bsinghar...@gmail.com>

Tested-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/8] powerpc: Create a helper for getting the kernel toc value

[Kamalesh Babulal]

* Michael Ellerman <m...@ellerman.id.au> [2016-03-03 15:26:53]:

> Move the logic to work out the kernel toc pointer into a header. This is
> a good cleanup, and also means we can use it elsewhere in future.
> 
> Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>
> Reviewed-by: Torsten Duwe <d...@suse.de>
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>

For the patchset,

Tested-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 5/8] powerpc/ftrace: Use generic ftrace_modify_all_code()

[Kamalesh Babulal]

* Michael Ellerman <m...@ellerman.id.au> [2016-02-29 20:26:26]:

> From: Torsten Duwe <d...@lst.de>
> 
> Convert powerpc's arch_ftrace_update_code() from its own version to use
> the generic default functionality (without stop_machine -- our
> instructions are properly aligned and the replacements atomic).
> 
> With this we gain error checking and the much-needed function_trace_op
> handling.
> 
> Reviewed-by: Balbir Singh <bsinghar...@gmail.com>
> Signed-off-by: Torsten Duwe <d...@suse.de>
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>

Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 2/8] powerpc/module: Only try to generate the ftrace_caller() stub once

[Kamalesh Babulal]

* Michael Ellerman  [2016-02-29 20:26:23]:

> Currently we generate the module stub for ftrace_caller() at the bottom
> of apply_relocate_add(). However apply_relocate_add() is potentially
> called more than once per module, which means we will try to generate
> the ftrace_caller() stub multiple times.
> 
> Although the current code deals with that correctly, ie. it only
> generates a stub the first time, it would be clearer to only try to
> generate the stub once.
> 
> Note also on first reading it may appear that we generate a different
> stub for each section that requires relocation, but that is not the
> case. The code in stub_for_addr() that searches for an existing stub
> uses sechdrs[me->arch.stubs_section], ie. the single stub section for
> this module.
> 
> A cleaner approach is to only generate the ftrace_caller() stub once,
> from module_finalize(). Although the original code didn't check to see
> if the stub was actually generated correctly, it seems prudent to add a
> check, so do that. And an additional benefit is we can clean the ifdefs
> up a little.
> 
> Finally we must propagate the const'ness of some of the pointers passed
> to module_finalize(), but that is also an improvement.
> 
> Reviewed-by: Balbir Singh 
> Reviewed-by: Torsten Duwe 
> Signed-off-by: Michael Ellerman 
> ---


with !CONFIG_DYNAMIC_FTRACE, build breaks

arch/powerpc/kernel/module_64.c:491:13: error: ‘squash_toc_save_inst’ used 
but never defined [-Werror]
 static void squash_toc_save_inst(const char *name, unsigned long addr);
 ^
cc1: all warnings being treated as errors

moving squash_toc_save_inst() definition to #else part
of #ifdef CONFIG_DYNAMIC_FTRACE helps.

 arch/powerpc/kernel/module_64.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index c9c75ceb7ed3..def0b9a013c9 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -774,8 +774,6 @@ static unsigned long create_ftrace_stub(const Elf64_Shdr 
*sechdrs, struct module
return (unsigned long)entry;
 }
 #else
-static void squash_toc_save_inst(const char *name, unsigned long addr) { }
-
 static unsigned long create_ftrace_stub(const Elf64_Shdr *sechdrs, struct 
module *me)
 {
return stub_for_addr(sechdrs, (unsigned long)ftrace_caller, me);
@@ -792,4 +790,8 @@ int module_finalize_ftrace(struct module *mod, const 
Elf_Shdr *sechdrs)
 
return 0;
 }
+
+#else
+static void squash_toc_save_inst(const char *name, unsigned long addr) { }
+
 #endif
-- 
2.6.0.rc1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/8] powerpc: Create a helper for getting the kernel toc value

[Kamalesh Babulal]

* Michael Ellerman <m...@ellerman.id.au> [2016-02-29 20:26:22]:

> Move the logic to work out the kernel toc pointer into a header. This is
> a good cleanup, and also means we can use it elsewhere in future.
> 
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>

Reviewed-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC][PATCH] Enable livepatching for powerpc

[Kamalesh Babulal]

* Balbir Singh <bsinghar...@gmail.com> [2016-02-25 23:11:45]:

> This applies on top of the patches posted by Michael today
> Enable livepatching. This takes patch 6/8 and 7/8 of v8 as the base.
> Removes the extra strict check in gcc-profile-kernel-notrace.sh
> and adds logic for checking offsets in livepatch. The patch
> for HAVE_C_RECORDMCOUNT is not required and not used here.
> 
> Depending on whether or not a TOC is generated, the offset
> for _mcount can be +16 or +8. The changes are such that the
> offset checks are specific to powerpc.
> 
> Comments? Testing? I tested the sample in the livepatch
> directory
> 
> References
> 
> 1. https://patchwork.ozlabs.org/patch/581521/
> 2. https://patchwork.ozlabs.org/patch/587464/
> 
> Signed-off-by: Torsten Duwe <d...@suse.de>
> Signed-off-by: Balbir Singh <bsinghar...@gmail.com>

I was able to test livepatch-sample module with this patch + Michael patch set.

Tested-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>


Regards,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 01/12] powerpc/module: Only try to generate the ftrace_caller() stub once

[Kamalesh Babulal]

* Michael Ellerman <m...@ellerman.id.au> [2016-02-25 01:28:24]:

> Currently we generate the module stub for ftrace_caller() at the bottom
> of apply_relocate_add(). However apply_relocate_add() is potentially
> called more than once per module, which means we will try to generate
> the ftrace_caller() stub multiple times.
> 
> Although the current code deals with that correctly, ie. it only
> generates a stub the first time, it would be clearer to only try to
> generate the stub once.
> 
> Note also on first reading it may appear that we generate a different
> stub for each section that requires relocation, but that is not the
> case. The code in stub_for_addr() that searches for an existing stub
> uses sechdrs[me->arch.stubs_section], ie. the single stub section for
> this module.
> 
> A cleaner approach is to only generate the ftrace_caller() stub once,
> from module_finalize(). An additional benefit is we can clean the ifdefs
> up a little.
> 
> Finally we must propagate the const'ness of some of the pointers passed
> to module_finalize(), but that is also an improvement.
> 
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>

For all of the patches in the series.

Tested-by: Kamalesh Babulal <kamal...@linux.vnet.ibm.com>


Regards,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v8 8/8] livepatch: Detect offset for the ftrace location during build

[Kamalesh Babulal]

* Torsten Duwe  [2016-02-23 18:00:17]:

> On Wed, Feb 17, 2016 at 02:08:41PM +1100, Michael Ellerman wrote:
> > 
> > That stub uses r2 to find the location of itself, but it only works if r2 
> > holds
> > the TOC for scsi_mod.ko. In this case r2 still contains ibmvscsi.ko's TOC.
> 
> Here's my solution, a bit rough still. This replaces the module_64.c change
> from patch 2/8:
> 
> I shuffle the trampoline instructions so the R2-save-to-stack comes first.
> This allows me to construct a profiling trampoline code that
> looks very similar. The first instruction, harmful to -mprofile-kernel
> can now be replaced with a load of the *kernel* TOC value via paca.
> Arithmetic is done in r11, to keep it bitwise identical where possible.
> Likewise the result is "moved" to r12 via an addi.
> 
> What do you think?
> 

Hi Torsten,

 I hit build failure, after replacing this patch with patch 2/8 module_64.c
hunk.

  CC  arch/powerpc/kernel/module.o
  CC  arch/powerpc/kernel/module_64.o
In file included from ./arch/powerpc/include/asm/asm-offsets.h:1:0,
 from arch/powerpc/kernel/module_64.c:30:
include/generated/asm-offsets.h:14:0: error: "NMI_MASK" redefined [-Werror]
 #define NMI_MASK 1048576 /* NMI_MASK  # */
 ^
In file included from include/linux/spinlock.h:50:0,
 from include/linux/seqlock.h:35,
 from include/linux/time.h:5,
 from include/linux/stat.h:18,
 from include/linux/module.h:10,
 from arch/powerpc/kernel/module_64.c:21:
include/linux/preempt.h:46:0: note: this is the location of the previous 
definition
 #define NMI_MASK (__IRQ_MASK(NMI_BITS) << NMI_SHIFT)
 ^
In file included from ./arch/powerpc/include/asm/asm-offsets.h:1:0,
 from arch/powerpc/kernel/module_64.c:30:
include/generated/asm-offsets.h:148:0: error: "CLONE_VM" redefined [-Werror]
 #define CLONE_VM 256 /* CLONE_VM  # */
 ^
In file included from include/linux/sched.h:4:0,
 from ./arch/powerpc/include/asm/elf.h:12,
 from include/linux/elf.h:4,
 from include/linux/module.h:15,
 from arch/powerpc/kernel/module_64.c:21:
include/uapi/linux/sched.h:8:0: note: this is the location of the previous 
definition
 #define CLONE_VM 0x0100 /* set if VM shared between processes */
 ^
In file included from ./arch/powerpc/include/asm/asm-offsets.h:1:0,
 from arch/powerpc/kernel/module_64.c:30:
include/generated/asm-offsets.h:149:0: error: "CLONE_UNTRACED" redefined 
[-Werror]
 #define CLONE_UNTRACED 8388608 /* CLONE_UNTRACED  # */
 ^
In file included from include/linux/sched.h:4:0,
 from ./arch/powerpc/include/asm/elf.h:12,
 from include/linux/elf.h:4,
 from include/linux/module.h:15,
 from arch/powerpc/kernel/module_64.c:21:
include/uapi/linux/sched.h:22:0: note: this is the location of the previous 
definition
 #define CLONE_UNTRACED  0x0080 /* set if the tracing process can't force 
CLONE_PTRACE on this clone */
 ^
In file included from ./arch/powerpc/include/asm/asm-offsets.h:1:0,
 from arch/powerpc/kernel/module_64.c:30:
include/generated/asm-offsets.h:185:0: error: "NSEC_PER_SEC" redefined [-Werror]
 #define NSEC_PER_SEC 10 /* NSEC_PER_SEC  # */
 ^
In file included from include/linux/time.h:7:0,
 from include/linux/stat.h:18,
 from include/linux/module.h:10,
 from arch/powerpc/kernel/module_64.c:21:
include/linux/time64.h:35:0: note: this is the location of the previous 
definition
 #define NSEC_PER_SEC 10L
 ^
In file included from ./arch/powerpc/include/asm/asm-offsets.h:1:0,
 from arch/powerpc/kernel/module_64.c:30:
include/generated/asm-offsets.h:188:0: error: "PGD_TABLE_SIZE" redefined 
[-Werror]
 #define PGD_TABLE_SIZE 32768 /* PGD_TABLE_SIZE  # */
 ^
In file included from ./arch/powerpc/include/asm/book3s/64/hash.h:58:0,
 from ./arch/powerpc/include/asm/book3s/64/pgtable.h:8,
 from ./arch/powerpc/include/asm/mmu-hash64.h:24,
 from ./arch/powerpc/include/asm/mmu.h:185,
 from ./arch/powerpc/include/asm/lppaca.h:36,
 from ./arch/powerpc/include/asm/paca.h:21,
 from ./arch/powerpc/include/asm/hw_irq.h:42,
 from ./arch/powerpc/include/asm/irqflags.h:11,
 from include/linux/irqflags.h:15,
 from include/linux/spinlock.h:53,
 from include/linux/seqlock.h:35,
 from include/linux/time.h:5,
 from include/linux/stat.h:18,
 from include/linux/module.h:10,
 from arch/powerpc/kernel/module_64.c:21:
./arch/powerpc/include/asm/book3s/64/hash-64k.h:133:0: note: this is the 
location of the previous definition
 #define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
 

Re: [PATCH v8 8/8] livepatch: Detect offset for the ftrace location during build

[Kamalesh Babulal]

* Torsten Duwe <d...@lst.de> [2016-02-16 09:23:02]:

> On Tue, Feb 16, 2016 at 11:17:02AM +0530, Kamalesh Babulal wrote:
> > * Petr Mladek <pmla...@suse.com> [2016-02-12 17:45:17]:
> > >  int test(int a)
> > >  {
> > > + printk("%d\n", a);
> > >   return ++a;
> > >  }
> > 
> > Thanks. This workaround, helped to load sample livepatch module.
> 
> N.b.: if you try to livepatch/trace such a leaf function without
> global dependencies, it will crash if that function got called with
> a different TOC value. Hence this whole testing.
> 

I am running out of ideas on how to generate this crash, any pointers
will be helpful.

> You may alternatively try my gcc patch ;-)

Thank you. I will give the patch a try.

Regards,
Kamalesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v8 8/8] livepatch: Detect offset for the ftrace location during build

[Kamalesh Babulal]

* Petr Mladek  [2016-02-12 17:45:17]:

[...]
> I guess that you used a broken gcc and cheated the check
> to pass the compilation. Did you, please?
> 
> The test used to detect the offset is using a minimalistic
> function is is afftected by the gcc bug.
> 
> The patch below might be used to cheat the offset check as well.
> 
> Torsten, please mention this somewhere if you, just by chance,
> send a new version of the patchset.
> 
> From f6a438a3f2f60cc1acc859b41d0cc9259c9a331e Mon Sep 17 00:00:00 2001
> From: root 
> Date: Tue, 2 Feb 2016 15:35:06 +0100
> Subject: [PATCH 2/2] livepatch: Make sure the TOC is handled when detecting
>  ftrace location
> 
> There seems to be a bug in gcc on PPC. It does not handle TOC
> if the function does not access global variables or functions
> by default. But it should when profiling is enabled.
> 
> This patch works around this problem by adding a call
> to a global function.
> 
> This patch is for testing only!
> ---
>  kernel/livepatch/ftrace-test.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/livepatch/ftrace-test.c b/kernel/livepatch/ftrace-test.c
> index 22f0c54bf7b3..a3b7aabb67e5 100644
> --- a/kernel/livepatch/ftrace-test.c
> +++ b/kernel/livepatch/ftrace-test.c
> @@ -1,6 +1,9 @@
>  /* Sample code to figure out mcount location offset */
> +#include 
> +
>  
>  int test(int a)
>  {
> + printk("%d\n", a);
>   return ++a;
>  }

Thanks. This workaround, helped to load sample livepatch module.

Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables

[Kamalesh Babulal]

* Balbir Singh  [2016-02-11 18:48:17]:

> On Wed, 2016-02-10 at 17:25 +0100, Torsten Duwe wrote:
> 
> snip
> 
> > diff --git a/arch/powerpc/gcc-mprofile-kernel-notrace.sh 
> > b/arch/powerpc/gcc-mprofile-kernel-notrace.sh
> > new file mode 100755
> > index 000..68d6482
> > --- /dev/null
> > +++ b/arch/powerpc/gcc-mprofile-kernel-notrace.sh
> > @@ -0,0 +1,33 @@
> > +#!/bin/sh
> > +# Test whether the compile option -mprofile-kernel
> > +# generates profiling code ( = a call to mcount), and
> > +# whether a function without any global references sets
> > +# the TOC pointer properly at the beginning, and
> > +# whether the "notrace" function attribute successfully
> > +# suppresses the _mcount call.
> > +
> > +echo "int func() { return 0; }" | \
> > +$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
> > +grep -q "mcount"
> > +
> > +trace_result=$?
> > +
> > +echo "int func() { return 0; }" | \
> > +$* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
> > +sed -n -e '/func:/,/bl _mcount/p' | grep -q TOC
> > +
> > +leaf_toc_result=$?
> > +
> 
> leaf_toc_result failed for me with gcc 5. I'll try and grab gcc-6
> and give the patches a spin
> 

It fails for me to on ppc64le but pass over ppc64

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/5.1.1/lto-wrapper
Target: ppc64-redhat-linux
[...]
gcc version 5.1.1 20150422 (Red Hat 5.1.1-1) (GCC)

# echo "int func() { return 0;  }" | gcc -S -x c -O2 -p -mprofile-kernel - 
-o - 2> /dev/null | sed -n -e '/func:/,/bl _mcount/p'
func:
.quad   .L.func,.TOC.@tocbase
.previous
.type   func, @function
.L.func:
mflr 0
std 0,16(1)
bl _mcount

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/5/lto-wrapper
Target: powerpc64le-linux-gnu
[...]
gcc version 5.3.1 20160205 (Ubuntu/IBM 5.3.1-8ubuntu2)

# echo "int func() { return 0;  }" | gcc -S -x c -O2 -p -mprofile-kernel - 
-o - 2> /dev/null | sed -n -e '/func:/,/bl _mcount/p'
func:
mflr 0
std 0,16(1)
bl _mcount


I will try it over gcc-6.

Thanks,
Kamalesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RESEND,v3] powerpc/pseries: Limit EPOW reset event warnings

[Kamalesh Babulal]

* Michael Ellerman m...@ellerman.id.au [2015-07-16 14:05:52]:

[..]
 
 Why are we even getting these reset events when nothing has happened?

Thanks for the review. It was seen only on one machine, couldn't
get hold of the machine any more. I am guessing here, that it might be
the firmware.

 
  Also, merged adjacent pr_err/pr_emerg into single one to reduce
  the number of lines printed per warning.
[..]
   
  +/* Flag to limit EPOW RESET warning. */
  +static bool epow_state;
 
 This name is terrible, it doesn't give me any hint to what it means.
 
 But really it should be a counter, not a boolean.
 
 We could have multiple EPOW events come in and then later get the reset events
 for them, couldn't we?
 
 
 So what about:
 
 static unsigned epow_event_depth;
 
---8

From 0d27916fd09a9f0912a217432a41e2b579dc2952 Mon Sep 17 00:00:00 2001
From: Kamalesh Babulal kamal...@linux.vnet.ibm.com
Date: Fri, 17 Jul 2015 13:19:31 +0530
Subject: [PATCH v4] powerpc/pseries: Limit EPOW reset event warnings

Kernel prints respective warnings about various EPOW events for
user information/action after parsing EPOW interrupts. At times
EPOW reset event warning, such as below could flood kernel log,
over a period of time.

May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared

This patch avoids these multiple EPOW reset warnings by using epow_depth
counter. Which is incremented every time EPOW event is reported and
decremented on EPOW_RESET event. With this approach number EPOW RESET
warning matches the number of EPOW events.

Also, merged adjacent pr_info/pr_err/pr_emerg into single one to reduce
the number of lines printed per warning across the file and converted
non-critical errors to pr_info from pr_error, including grammar
correction in the warnings printed.

Suggested-by: Michael Ellerman m...@ellerman.id.au
Cc: Anshuman Khandual khand...@linux.vnet.ibm.com
Cc: Anton Blanchard an...@samba.org
Cc: Vipin K Parashar vi...@linux.vnet.ibm.com
Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
---
V4: Changes:
   - Changed the approach to depth counter to match the EPOW events and
 EPOW reset.
   - Converted pr_err() ot pr_info() for non-critical errors.
   - Merged adjacent warnings into single line across the file.
   - Fixed grammar in the warnings to make is short.

v3 Changes:
   - Limit warning printed by EPOW RESET event, by guarding it with bool flag.
 Instead of rate limiting all the EPOW events.

v2 Changes:
   - Merged multiple adjacent pr_err/pr_emerg into single line to reduce 
multi-line
 warnings, based on Michael's comments.

 arch/powerpc/platforms/pseries/ras.c | 53 
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..995cab8 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,8 @@ static int ras_check_exception_token;
 #define EPOW_SENSOR_TOKEN  9
 #define EPOW_SENSOR_INDEX  0
 
+static unsigned epow_event_depth;
+
 static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
 static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
 
@@ -82,32 +84,30 @@ static void handle_system_shutdown(char event_modifier)
 {
switch (event_modifier) {
case EPOW_SHUTDOWN_NORMAL:
-   pr_emerg(Firmware initiated power off);
+   pr_emerg(Firmware initiated power off\n);
orderly_poweroff(true);
break;
 
case EPOW_SHUTDOWN_ON_UPS:
-   pr_emerg(Loss of power reported by firmware, system is 
-   running on UPS/battery);
-   pr_emerg(Check RTAS error log for details);
+   pr_emerg(Loss of power reported, system is running on
+ UPS/battery. Check RTAS error log for details\n);
orderly_poweroff(true);
break;
 
case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS:
-   pr_emerg(Loss of system critical functions reported

Re: [PATCH v2] powerpc/pseries: Ratelimit EPOW event warnings

[Kamalesh Babulal]

* Vipin K Parashar vi...@linux.vnet.ibm.com [2015-06-25 00:48:20]:

 
 On 06/02/2015 10:48 AM, Kamalesh Babulal wrote:
 We print the respective warning after parsing EPOW interrupts,
 prompting user to take action depending upon the severity of the
 event.
 
 Some times same EPOW event warning, such as below could flood kernel
 log, over a period of time. So Limit the warnings by using ratelimit
 variant of pr_err. Also, merge adjacent pr_err/pr_emerg into single
 one to reduce the number of lines printed per warning.
 
 May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
 May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
 May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
 May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
 May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
 May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
 May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
 May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
 May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
 May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
 May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
 May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
 May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared
 
 These messages are minutes apart and thus rate limiting won't help.
 One solution could be to use a flag based approach. Set a flag once a
 EPOW condition is detected and check that flag upon receiving EPOW_RESET.
 EPOW condition clear message should be logged only if a EPOW was previously
 detected i.e. flag found set.

Thanks for reviewing it. Sorry for late response.

bool flag epow_state, which is initialized to false and when any event gets
reported, the flag set to true once the event gets acknowledged by a reset.
As, seen in the example of flooded messages occurring only with reset event.
The reset action is guarded with bool flag (set only if there was event
reported previously) and ignore multiple resets, without real EPOW event.

I have only compile tested the patch. If this approach sounds good.
I will resend formal patch.


diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..4819b1d 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,8 @@ static int ras_check_exception_token;
 #define EPOW_SENSOR_TOKEN  9
 #define EPOW_SENSOR_INDEX  0
 
+static bool epow_state = false;
+
 static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
 static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
 
@@ -145,21 +147,27 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
switch (action_code) {
case EPOW_RESET:
-   pr_err(Non critical power or cooling issue cleared);
+   if (epow_state) {
+   pr_err(Non critical power or cooling issue cleared);
+   epow_state = false;
+   }
break;
 
case EPOW_WARN_COOLING:
-   pr_err(Non critical cooling issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err(Non critical cooling issue reported by firmware, 
+  Check RTAS error log for details);
+   epow_state = true;
break;
 
case EPOW_WARN_POWER:
-   pr_err(Non critical power issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err(Non critical power issue reported by firmware, 
+  Check RTAS error log for details);
+   epow_state = true;
break;
 
case EPOW_SYSTEM_SHUTDOWN:
handle_system_shutdown(epow_log-event_modifier);
+   epow_state = true;
break;
 
case EPOW_SYSTEM_HALT:
@@ -169,9 +177,8 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
case EPOW_MAIN_ENCLOSURE:
case EPOW_POWER_OFF:
-   pr_emerg(Critical power/cooling issue reported by firmware);
-   pr_emerg(Check RTAS error log for details);
-   pr_emerg(Immediate power off);
+   pr_emerg(Critical power/cooling issue reported by firmware, 
+Check RTAS error log for details. Immediate power 
off.);
emergency_sync();
kernel_power_off();
break;
@@ -179,6 +186,7 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
default:
pr_err(Unknown power/cooling event (action code %d),
action_code);
+   epow_state = true

[PATCH v3] powerpc/pseries: Limit EPOW reset event warnings

[Kamalesh Babulal]

We print the respective warning after parsing EPOW interrupts,
prompting user to take action depending upon the severity of the
event.

Some times EPOW rest event warning, such as below could flood
kernel log, over a period of time. Limit these warnings by use of
epow_state flag, which is initialized to false and when any event
gets reported, the flag set to true once an event gets acknowledged
by a reset.

The reset action is guarded by bool flag (set only if there was event
reported previously) and ignore multiple resets, without real EPOW
event. Also, merge adjacent pr_err/pr_emerg into single one to reduce
the number of lines printed per warning.

May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared

Suggested-by: Vipin K Parashar vi...@linux.vnet.ibm.com
Cc: Anshuman Khandual khand...@linux.vnet.ibm.com
Cc: Anton Blanchard an...@samba.org
Cc: Michael Ellerman m...@ellerman.id.au
Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
---
v3 Changes:
  - Limit warning printed by EPOW RESET event, by guarding it with bool flag.
Instead of rate limiting all the EPOW events.

v2 Changes:
  - Merged multiple adjacent pr_err/pr_emerg into single line to reduce 
multi-line
warnings, based on Michael's comments.

 arch/powerpc/platforms/pseries/ras.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..b30396a 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,9 @@ static int ras_check_exception_token;
 #define EPOW_SENSOR_TOKEN  9
 #define EPOW_SENSOR_INDEX  0
 
+/* Flag to limit EPOW RESET warning. */
+static bool epow_state;
+
 static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
 static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
 
@@ -145,21 +148,27 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
switch (action_code) {
case EPOW_RESET:
-   pr_err(Non critical power or cooling issue cleared);
+   if (epow_state) {
+   pr_err(Non critical power or cooling issue cleared);
+   epow_state = false;
+   }
break;
 
case EPOW_WARN_COOLING:
-   pr_err(Non critical cooling issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err(Non critical cooling issue reported by firmware, 
+  Check RTAS error log for details);
+   epow_state = true;
break;
 
case EPOW_WARN_POWER:
-   pr_err(Non critical power issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err(Non critical power issue reported by firmware, 
+  Check RTAS error log for details);
+   epow_state = true;
break;
 
case EPOW_SYSTEM_SHUTDOWN:
handle_system_shutdown(epow_log-event_modifier);
+   epow_state = true;
break;
 
case EPOW_SYSTEM_HALT:
@@ -169,9 +178,8 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
case EPOW_MAIN_ENCLOSURE:
case EPOW_POWER_OFF:
-   pr_emerg(Critical power/cooling issue reported by firmware);
-   pr_emerg(Check RTAS error log for details);
-   pr_emerg(Immediate power off);
+   pr_emerg(Critical power/cooling issue reported by firmware, 
+Check RTAS error log for details. Immediate power 
off.);
emergency_sync();
kernel_power_off();
break;
@@ -179,6 +187,7 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
default:
pr_err(Unknown power/cooling event (action code %d),
action_code);
+   epow_state = true;
}
 }
 
-- 
2.1.2

___
Linuxppc-dev

[RESEND PATCH v3] powerpc/pseries: Limit EPOW reset event warnings

[Kamalesh Babulal]

Kernel prints respective warnings about various EPOW events for
user information/action after parsing EPOW interrupts.Prompting
user to take action depending upon the severity of the event.

At times EPOW reset event warning, such as below could flood
kernel log, over a period of time.

May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared

This patch avoids these multiple EPOW reset warnings by using a boolean
flag. This flag is initialized to false and is set to true upon arrival
of EPOW event. This same flag is checked and reset during EPOW_RESET
scenario to filter out valid EPOW reset events and avoid multiple warning
logs.

Also, merged adjacent pr_err/pr_emerg into single one to reduce
the number of lines printed per warning.

Suggested-by: Vipin K Parashar vi...@linux.vnet.ibm.com
[Vipin: edited the changelog]
Cc: Anshuman Khandual khand...@linux.vnet.ibm.com
Cc: Anton Blanchard an...@samba.org
Cc: Michael Ellerman m...@ellerman.id.au
Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
---
v3 Changes:
   - Limit warning printed by EPOW RESET event, by guarding it with bool flag.
 Instead of rate limiting all the EPOW events.

v2 Changes:
   - Merged multiple adjacent pr_err/pr_emerg into single line to reduce 
multi-line
 warnings, based on Michael's comments.

 arch/powerpc/platforms/pseries/ras.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..b30396a 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,9 @@ static int ras_check_exception_token;
 #define EPOW_SENSOR_TOKEN  9
 #define EPOW_SENSOR_INDEX  0
 
+/* Flag to limit EPOW RESET warning. */
+static bool epow_state;
+
 static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
 static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
 
@@ -145,21 +148,27 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
switch (action_code) {
case EPOW_RESET:
-   pr_err(Non critical power or cooling issue cleared);
+   if (epow_state) {
+   pr_err(Non critical power or cooling issue cleared);
+   epow_state = false;
+   }
break;
 
case EPOW_WARN_COOLING:
-   pr_err(Non critical cooling issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err(Non critical cooling issue reported by firmware, 
+  Check RTAS error log for details);
+   epow_state = true;
break;
 
case EPOW_WARN_POWER:
-   pr_err(Non critical power issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err(Non critical power issue reported by firmware, 
+  Check RTAS error log for details);
+   epow_state = true;
break;
 
case EPOW_SYSTEM_SHUTDOWN:
handle_system_shutdown(epow_log-event_modifier);
+   epow_state = true;
break;
 
case EPOW_SYSTEM_HALT:
@@ -169,9 +178,8 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
case EPOW_MAIN_ENCLOSURE:
case EPOW_POWER_OFF:
-   pr_emerg(Critical power/cooling issue reported by firmware);
-   pr_emerg(Check RTAS error log for details);
-   pr_emerg(Immediate power off);
+   pr_emerg(Critical power/cooling issue reported by firmware, 
+Check RTAS error log for details. Immediate power 
off.);
emergency_sync();
kernel_power_off();
break;
@@ -179,6 +187,7 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
default:
pr_err(Unknown power/cooling event (action code %d),
action_code);
+   epow_state = true;
}
 }
 
-- 
2.1.2

[PATCH v2] powerpc/pseries: Ratelimit EPOW event warnings

[Kamalesh Babulal]

We print the respective warning after parsing EPOW interrupts,
prompting user to take action depending upon the severity of the
event.

Some times same EPOW event warning, such as below could flood kernel
log, over a period of time. So Limit the warnings by using ratelimit
variant of pr_err. Also, merge adjacent pr_err/pr_emerg into single
one to reduce the number of lines printed per warning.

May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared

Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
Cc: Anshuman Khandual khand...@linux.vnet.ibm.com
Cc: Anton Blanchard an...@samba.org
Cc: Michael Ellerman m...@ellerman.id.au
---
v2 Changes:
 - Merged multiple adjacent pr_err/pr_emerg into single line to reduce 
multi-line
   warnings, based on Michael's comments.

 arch/powerpc/platforms/pseries/ras.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..3620935 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -145,17 +145,17 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
switch (action_code) {
case EPOW_RESET:
-   pr_err(Non critical power or cooling issue cleared);
+   pr_err_ratelimited(Non critical power or cooling issue 
cleared);
break;
 
case EPOW_WARN_COOLING:
-   pr_err(Non critical cooling issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err_ratelimited(Non critical cooling issue reported by 
firmware,
+   Check RTAS error log for details);
break;
 
case EPOW_WARN_POWER:
-   pr_err(Non critical power issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err_ratelimited(Non critical power issue reported by 
firmware,
+   Check RTAS error log for details);
break;
 
case EPOW_SYSTEM_SHUTDOWN:
@@ -169,15 +169,14 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
case EPOW_MAIN_ENCLOSURE:
case EPOW_POWER_OFF:
-   pr_emerg(Critical power/cooling issue reported by firmware);
-   pr_emerg(Check RTAS error log for details);
-   pr_emerg(Immediate power off);
+   pr_emerg(Critical power/cooling issue reported by firmware,
+ Check RTAS error log for details. Immediate power 
off);
emergency_sync();
kernel_power_off();
break;
 
default:
-   pr_err(Unknown power/cooling event (action code %d),
+   pr_err_ratelimited(Unknown power/cooling event (action code 
%d),
action_code);
}
 }
-- 
2.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] powerpc/pseries: Ratelimit EPOW event warnings

[Kamalesh Babulal]

* Michael Ellerman m...@ellerman.id.au [2015-06-01 21:26:51]:

 On Thu, 2015-05-28 at 10:03 +0530, Kamalesh Babulal wrote:
  We print the respective warning after parsing EPOW interrupts,
  prompting user to take action depending upon the severity of the
  event.
  
  Some times same EPOW event warning, such as below could flood kernel
  log, within very short duration. So Limit the message by using
  ratelimit variant of pr_err.
  
  May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
  May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
  May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
  May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
  May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
  May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
  May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
  May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
  May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
  May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
  May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
  May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
  May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared
 
 Looking at the time stamps those are actually all fairly far apart in time,
 aren't they? So do we actually see them within a short duration in practice?

Thanks for the review. Agree, I should have phrased it better. My intend was to
say, that these warnings keep flooding the kernel log, over a period of time.

[..]
  case EPOW_WARN_POWER:
  -   pr_err(Non critical power issue reported by firmware);
  -   pr_err(Check RTAS error log for details);
  +   pr_err_ratelimited(Non critical power issue reported by 
  firmware);
  +   pr_err_ratelimited(Check RTAS error log for details);
  break;
 
 Those last two could be collapsed onto one line which would reduce the spam.

Yes, it could reduce the number of lines printed. Will resend the patch with the
changes.

Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[RFC PATCH] powerpc/pseries: Ratelimit EPOW event warnings

[Kamalesh Babulal]

We print the respective warning after parsing EPOW interrupts,
prompting user to take action depending upon the severity of the
event.

Some times same EPOW event warning, such as below could flood kernel
log, within very short duration. So Limit the message by using
ratelimit variant of pr_err.

May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared

Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
Cc: Anshuman Khandual khand...@linux.vnet.ibm.com
Cc: Anton Blanchard an...@samba.org
Cc: Michael Ellerman m...@ellerman.id.au
---
 arch/powerpc/platforms/pseries/ras.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c 
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..2556bc2 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -145,17 +145,17 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
 
switch (action_code) {
case EPOW_RESET:
-   pr_err(Non critical power or cooling issue cleared);
+   pr_err_ratelimited(Non critical power or cooling issue 
cleared);
break;
 
case EPOW_WARN_COOLING:
-   pr_err(Non critical cooling issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err_ratelimited(Non critical cooling issue reported by 
firmware);
+   pr_err_ratelimited(Check RTAS error log for details);
break;
 
case EPOW_WARN_POWER:
-   pr_err(Non critical power issue reported by firmware);
-   pr_err(Check RTAS error log for details);
+   pr_err_ratelimited(Non critical power issue reported by 
firmware);
+   pr_err_ratelimited(Check RTAS error log for details);
break;
 
case EPOW_SYSTEM_SHUTDOWN:
@@ -177,7 +177,7 @@ static void rtas_parse_epow_errlog(struct rtas_error_log 
*log)
break;
 
default:
-   pr_err(Unknown power/cooling event (action code %d),
+   pr_err_ratelimited(Unknown power/cooling event (action code 
%d),
action_code);
}
 }
-- 
2.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/spufs: Remove MAX_USER_PRIO define

[Kamalesh Babulal]

* Jeremy Kerr j...@ozlabs.org [2014-02-11 14:05:17]:

 Current ppc64_defconfig fails with:
 
  arch/powerpc/platforms/cell/spufs/sched.c:86:0: error: MAX_USER_PRIO 
 redefined [-Werror]
  cc1: all warnings being treated as errors
 
 6b6350f1 introduced a generic MAX_USER_PRIO macro to sched/prio.h, which
 is causing the conflit. Use that one instead of our own.

you can also use DEFAULT_PRIO from sched/prio.h instead of NORMAL_PRIO.

diff --git a/arch/powerpc/platforms/cell/spufs/sched.c 
b/arch/powerpc/platforms/cell/spufs/sched.c
index 49318385d4fa..014979db2018 100644
--- a/arch/powerpc/platforms/cell/spufs/sched.c
+++ b/arch/powerpc/platforms/cell/spufs/sched.c
@@ -64,11 +64,6 @@ static struct timer_list spusched_timer;
 static struct timer_list spuloadavg_timer;
 
 /*
- * Priority of a normal, non-rt, non-niced'd process (aka nice level 0).
- */
-#define NORMAL_PRIO120
-
-/*
  * Frequency of the spu scheduler tick.  By default we do one SPU scheduler
  * tick for every 10 CPU scheduler ticks.
  */
@@ -97,7 +92,7 @@ static struct timer_list spuloadavg_timer;
  */
 void spu_set_timeslice(struct spu_context *ctx)
 {
-   if (ctx-prio  NORMAL_PRIO)
+   if (ctx-prio  DEFAULT_PRIO)
ctx-time_slice = SCALE_PRIO(DEF_SPU_TIMESLICE * 4, ctx-prio);
else
ctx-time_slice = SCALE_PRIO(DEF_SPU_TIMESLICE, ctx-prio);

Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 2/2] sched: Remove un-necessary iteration over sched domains to update nr_busy_cpus

[Kamalesh Babulal]

Hi Preeti,

 nr_busy_cpus parameter is used by nohz_kick_needed() to find out the number
 of busy cpus in a sched domain which has SD_SHARE_PKG_RESOURCES flag set.
 Therefore instead of updating nr_busy_cpus at every level of sched domain,
 since it is irrelevant, we can update this parameter only at the parent
 domain of the sd which has this flag set. Introduce a per-cpu parameter
 sd_busy which represents this parent domain.
 
 In nohz_kick_needed() we directly query the nr_busy_cpus parameter
 associated with the groups of sd_busy.
 
 By associating sd_busy with the highest domain which has
 SD_SHARE_PKG_RESOURCES flag set, we cover all lower level domains which could
 have this flag set and trigger nohz_idle_balancing if any of the levels have
 more than one busy cpu.
 
 sd_busy is irrelevant for asymmetric load balancing. However sd_asym has been
 introduced to represent the highest sched domain which has SD_ASYM_PACKING 
 flag set
 so that it can be queried directly when required.
 
 While we are at it, we might as well change the nohz_idle parameter to be
 updated at the sd_busy domain level alone and not the base domain level of a 
 CPU.
 This will unify the concept of busy cpus at just one level of sched domain
 where it is currently used.
 
 Signed-off-by: Preeti U Murthypre...@linux.vnet.ibm.com
 ---
  kernel/sched/core.c  |6 ++
  kernel/sched/fair.c  |   38 --
  kernel/sched/sched.h |2 ++
  3 files changed, 28 insertions(+), 18 deletions(-)
 
 diff --git a/kernel/sched/core.c b/kernel/sched/core.c
 index c06b8d3..e6a6244 100644
 --- a/kernel/sched/core.c
 +++ b/kernel/sched/core.c
 @@ -5271,6 +5271,8 @@ DEFINE_PER_CPU(struct sched_domain *, sd_llc);
  DEFINE_PER_CPU(int, sd_llc_size);
  DEFINE_PER_CPU(int, sd_llc_id);
  DEFINE_PER_CPU(struct sched_domain *, sd_numa);
 +DEFINE_PER_CPU(struct sched_domain *, sd_busy);
 +DEFINE_PER_CPU(struct sched_domain *, sd_asym);
 
  static void update_top_cache_domain(int cpu)
  {
 @@ -5282,6 +5284,7 @@ static void update_top_cache_domain(int cpu)
   if (sd) {
   id = cpumask_first(sched_domain_span(sd));
   size = cpumask_weight(sched_domain_span(sd));
 + rcu_assign_pointer(per_cpu(sd_busy, cpu), sd-parent);
   }


consider a machine with single socket, dual core with HT enabled. The top most
domain is also the highest domain with SD_SHARE_PKG_RESOURCES flag set,
i.e MC domain (the machine toplogy consist of SIBLING and MC domain).

# lstopo-no-graphics --no-bridges --no-io
Machine (7869MB) + Socket L#0 + L3 L#0 (3072KB)
  L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
PU L#0 (P#0)
PU L#1 (P#1)
  L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
PU L#2 (P#2)
PU L#3 (P#3)

With this approach parent of MC domain is NULL and given that sd_busy is NULL,
nr_busy_cpus of sched domain sd_busy will never be incremented/decremented.
Resulting is nohz_kick_needed returning 0.

Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] sched: Fix nohz_kick_needed to consider the nr_busy of the parent domain's group

[Kamalesh Babulal]

* Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com [2013-10-21 17:14:42]:

   for_each_domain(cpu, sd) {
 - struct sched_group *sg = sd-groups;
 - struct sched_group_power *sgp = sg-sgp;
 - int nr_busy = atomic_read(sgp-nr_busy_cpus);
 -
 - if (sd-flags  SD_SHARE_PKG_RESOURCES  nr_busy  1)
 - goto need_kick_unlock;
 + struct sched_domain *sd_parent = sd-parent;
 + struct sched_group *sg;
 + struct sched_group_power *sgp;
 + int nr_busy;
 +
 + if (sd_parent) {
 + sg = sd_parent-groups;
 + sgp = sg-sgp;
 + nr_busy = atomic_read(sgp-nr_busy_cpus);
 +
 + if (sd-flags  SD_SHARE_PKG_RESOURCES  nr_busy  1)
 + goto need_kick_unlock;
 + }
 
   if (sd-flags  SD_ASYM_PACKING  nr_busy != sg-group_weight
(cpumask_first_and(nohz.idle_cpus_mask,

CC'ing Suresh Siddha and Vincent Guittot

Please correct me, If my understanding of idle balancing is wrong.
With proposed approach will not idle load balancer kick in, even if
there are busy cpus across groups or if there are 2 busy cpus which
are spread across sockets.

Consider 2 socket machine with 4 processors each (MC and NUMA domains).
If the machine is partial loaded such that cpus 0,4,5,6,7 are busy, then too
nohz balancing is triggered because with this approach
(NUMA)-groups-sgp-nr_busy_cpus is taken in account for nohz kick, while
iterating over MC domain.

Isn't idle load balancer not suppose kick in, even in the case of two busy
cpu's in a dual-core single socket system.

Thanks,
Kamalesh.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

linux-next: 20090925 - hvc driver build breaks with !HVC_CONSOLE

[Kamalesh Babulal]

Hi Stephen,

next-20090925 randconfig build breaks on hvcs driver on powerpc,
with HVC_CONSOLE=n.

ERROR: .hvc_put_chars [drivers/char/hvcs.ko] undefined!
ERROR: .hvc_get_chars [drivers/char/hvcs.ko] undefined!

adding the dependency of HVC_CONSOLE helped

Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
--
 drivers/char/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index a2a0e67..2583231 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -682,7 +682,7 @@ config VIRTIO_CONSOLE
 
 config HVCS
tristate IBM Hypervisor Virtual Console Server support
-   depends on PPC_PSERIES
+   depends on PPC_PSERIES  HVC_CONSOLE
help
  Partitionable IBM Power5 ppc64 machines allow hosting of
  firmware virtual consoles from one Linux partition by

Kamalesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[BUG] 2.6.29-rc1 - Badness at kernel/sched.c:4440 with CONFIG_DEBUG_PREEMPT

[Kamalesh Babulal]

/git/davem/sparc-next-2.6
git-bisect bad 6de71484cf9561edb45224f659a9db38b6056d5e
# good: [3c92ec8ae91ecf59d88c798301833d7cf83f2179] Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
git-bisect good 3c92ec8ae91ecf59d88c798301833d7cf83f2179
# bad: [179475a3b46f86e2d06f83e2312218ac3f0cf3a7] Merge branch 
'irq-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git-bisect bad 179475a3b46f86e2d06f83e2312218ac3f0cf3a7
# bad: [cc37d3d20604f3759d269247b022616f710aa52d] Merge branch 'core/futexes' 
into core/core
git-bisect bad cc37d3d20604f3759d269247b022616f710aa52d
# bad: [7918baa5551409891270f48533987d48fdba] mutex: __used is needed for 
function referenced only from inline asm
git-bisect bad 7918baa5551409891270f48533987d48fdba
# good: [30742d5c2277c325fb0e9d2d817d55a19995fe8f] Revert lockdep: fix 
compilation when CONFIG_TRACE_IRQFLAGS_SUPPORT is not set
git-bisect good 30742d5c2277c325fb0e9d2d817d55a19995fe8f
# bad: [c7e78cff6b7518212247fb20b1dc6411540dc9af] lockstat: contend with points
git-bisect bad c7e78cff6b7518212247fb20b1dc6411540dc9af
# good: [9b9b181ce53ef387dfe3df9316bbc641fca13d51] Merge commit 'v2.6.27-rc7' 
into core/locking
git-bisect good 9b9b181ce53ef387dfe3df9316bbc641fca13d51
# bad: [7317d7b87edb41a9135e30be1ec3f7ef817c53dd] sched: improve preempt 
debugging
git-bisect bad 7317d7b87edb41a9135e30be1ec3f7ef817c53dd
# good: [6918bc5c830e890681eabb3c6cb6b8d117a52d14] lockstat: fixup signed 
division
git-bisect good 6918bc5c830e890681eabb3c6cb6b8d117a52d14


kernel warning is not seen after reverting the patch.

commit 7317d7b87edb41a9135e30be1ec3f7ef817c53dd
Author: Nick Piggin nickpig...@yahoo.com.au
Date:   Tue Sep 30 20:50:27 2008 +1000

sched: improve preempt debugging

This patch helped me out with a problem I recently had

Basically, when the kernel lock is held, then preempt_count underflow does 
not
get detected until it is released which may be a long time (and arbitrarily,
eg at different points it may be rescheduled). If the bkl is released at
schedule, the resulting output is actually fairly cryptic...

With any other lock that elevates preempt_count, it is illegal to schedule
under it (which would get found pretty quickly). bkl allows scheduling with
preempt_count elevated, which makes underflows hard to debug.

Signed-off-by: Ingo Molnar mi...@elte.hu

diff --git a/kernel/sched.c b/kernel/sched.c
index 9889080..ec3bd1f 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4305,7 +4305,7 @@ void __kprobes sub_preempt_count(int val)
/*
 * Underflow?
 */
-   if (DEBUG_LOCKS_WARN_ON(val  preempt_count()))
+   if (DEBUG_LOCKS_WARN_ON(val  preempt_count() - (!!kernel_locked(
return;
/*
 * Is the spinlock portion underflowing?
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUG] 2.6.28-git-4 - powerpc - kernel expection 'c01 at .kernel_thread'

[Kamalesh Babulal]

* Rafael J. Wysocki r...@sisk.pl [2009-01-11 01:08:19]:

 On Friday 02 January 2009, Kamalesh Babulal wrote:
  Hi,
  
  2.6.28-git4 kernel drops to xmon with kernel expection. Similar kernel
  expection was seen next-20081230 and next-20081231 and was reported 
  earlier at http://lkml.org/lkml/2008/12/31/157
 
 Is this a regression from 2.6.27?
 
 Rafael


This is not a regression from 2.6.27, this expection was first seen 
next-20081230 patches and then was introduced into 2.6.28-git4 and is 
reproducible with 2.6.28-rc1 kernel.

-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] 2.6.28-git4 - powerpc - drivers build fails with !CONFIG_VIOPATH

[Kamalesh Babulal]

* Sam Ravnborg s...@ravnborg.org [2009-01-06 08:31:49]:

  
  Sorry for resending the patch before taking care of the response. 
  Resending 
  the patch with changes made to other three drivers also.
  
  Impact: Fix the VIOPATH dependency in the iSeries dependent drivers.
  
  iSeries depend drivers build fails, when CONFIG_VIOPATH is disabled.
  Removing the dependency of VIOPATH by selecting it, when the drivers
  dependent on iSeries code.
  
  
  Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
  ---
   arch/powerpc/platforms/iseries/Kconfig |5 -
   drivers/char/Kconfig   |1 +
   drivers/scsi/Kconfig   |1 +
   3 files changed, 6 insertions(+), 1 deletions(-)
  
  diff --git a/arch/powerpc/platforms/iseries/Kconfig 
  b/arch/powerpc/platforms/iseries/Kconfig
  index ed3753d..5cb2320 100644
  --- a/arch/powerpc/platforms/iseries/Kconfig
  +++ b/arch/powerpc/platforms/iseries/Kconfig
  @@ -10,18 +10,21 @@ menu iSeries device drivers
   config VIODASD


snip

 
 VIOPATH is set using select so the depends on is effectively ignored.
 If you think you need the depends on then you need to revisit the
 symbol that will select VIOPATH and make sure _they_ have this dependency.
 
   Sam

Hi Sam,

VIOPATH is used only by the PPC_ISERIES code. The symbols selecting
the VIOPATH are also dependent on the PPC_ISERIES. Should we make the 
config VIOPATH as default n, because it being selected the dependent
drivers.

Impact: Fix the VIOPATH dependency in the iSeries dependent drivers.

iSeries depend drivers build fails, when CONFIG_VIOPATH is disabled.
Removing the dependency of VIOPATH by selecting it, when the drivers
dependent on iSeries code.

Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/iseries/Kconfig |6 --
 drivers/char/Kconfig   |1 +
 drivers/scsi/Kconfig   |1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/iseries/Kconfig 
b/arch/powerpc/platforms/iseries/Kconfig
index ed3753d..fd524cd 100644
--- a/arch/powerpc/platforms/iseries/Kconfig
+++ b/arch/powerpc/platforms/iseries/Kconfig
@@ -10,18 +10,21 @@ menu iSeries device drivers
 config VIODASD
tristate iSeries Virtual I/O disk support
depends on BLOCK
+   select VIOPATH
help
  If you are running on an iSeries system and you want to use
  virtual disks created and managed by OS/400, say Y.
 
 config VIOCD
tristate iSeries Virtual I/O CD support
+   select VIOPATH
help
  If you are running Linux on an IBM iSeries system and you want to
  read a CD drive owned by OS/400, say Y here.
 
 config VIOTAPE
tristate iSeries Virtual Tape Support
+   select VIOPATH
help
  If you are running Linux on an iSeries system and you want Linux
  to read and/or write a tape drive owned by OS/400, say Y here.
@@ -30,5 +33,4 @@ endmenu
 
 config VIOPATH
bool
-   depends on VIODASD || VIOCD || VIOTAPE || ISERIES_VETH
-   default y
+   default n
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 1697043..b8da09a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -616,6 +616,7 @@ config HVC_ISERIES
default y
select HVC_DRIVER
select HVC_IRQ
+   select VIOPATH
help
  iSeries machines support a hypervisor virtual console.
 
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index b732297..256c7be 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -884,6 +884,7 @@ config SCSI_IBMVSCSI
tristate IBM Virtual SCSI support
depends on PPC_PSERIES || PPC_ISERIES
select SCSI_SRP_ATTRS
+   select VIOPATH if PPC_ISERIES
help
  This is the IBM POWER Virtual SCSI Client
 
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] 2.6.28-git4 - powerpc - drivers build fails with !CONFIG_VIOPATH

[Kamalesh Babulal]

* Sam Ravnborg s...@ravnborg.org [2009-01-06 11:46:19]:

 Hi Kamalesh
 
 Looks good, small nit below.
 
   config VIOPATH
  bool
  -   depends on VIODASD || VIOCD || VIOTAPE || ISERIES_VETH
  -   default y
  +   default n
 
 As 'n' is default anyway this line is not needed and I suggest you
 spin a final version of the patch with this removed.
 
   Sam

Hi Sam,

Thanks for the review comments. I am resending the patch with the 
changes
you have recommended.

Impact: Fix the VIOPATH dependency in the iSeries dependent drivers.

iSeries depend drivers build fails, when CONFIG_VIOPATH is disabled.
Removing the dependency of VIOPATH by selecting it, when the drivers
dependent on iSeries code.

Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/iseries/Kconfig |5 +++--
 drivers/char/Kconfig   |1 +
 drivers/scsi/Kconfig   |1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/iseries/Kconfig 
b/arch/powerpc/platforms/iseries/Kconfig
index ed3753d..7ddd0a2 100644
--- a/arch/powerpc/platforms/iseries/Kconfig
+++ b/arch/powerpc/platforms/iseries/Kconfig
@@ -10,18 +10,21 @@ menu iSeries device drivers
 config VIODASD
tristate iSeries Virtual I/O disk support
depends on BLOCK
+   select VIOPATH
help
  If you are running on an iSeries system and you want to use
  virtual disks created and managed by OS/400, say Y.
 
 config VIOCD
tristate iSeries Virtual I/O CD support
+   select VIOPATH
help
  If you are running Linux on an IBM iSeries system and you want to
  read a CD drive owned by OS/400, say Y here.
 
 config VIOTAPE
tristate iSeries Virtual Tape Support
+   select VIOPATH
help
  If you are running Linux on an iSeries system and you want Linux
  to read and/or write a tape drive owned by OS/400, say Y here.
@@ -30,5 +33,3 @@ endmenu
 
 config VIOPATH
bool
-   depends on VIODASD || VIOCD || VIOTAPE || ISERIES_VETH
-   default y
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 1697043..b8da09a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -616,6 +616,7 @@ config HVC_ISERIES
default y
select HVC_DRIVER
select HVC_IRQ
+   select VIOPATH
help
  iSeries machines support a hypervisor virtual console.
 
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index b732297..256c7be 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -884,6 +884,7 @@ config SCSI_IBMVSCSI
tristate IBM Virtual SCSI support
depends on PPC_PSERIES || PPC_ISERIES
select SCSI_SRP_ATTRS
+   select VIOPATH if PPC_ISERIES
help
  This is the IBM POWER Virtual SCSI Client
 
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] 2.6.28-git4 - powerpc - drivers build fails with !CONFIG_VIOPATH

[Kamalesh Babulal]

* Milton Miller milt...@bga.com [2009-01-05 07:33:32]:

 On Jan 4, 2009, at 12:24 PM, Kamalesh Babulal wrote:

 Hi Milton,

  Thanks for the review comments, I am resending the patch with the
 changes you have recommended.

 Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com

 Better, but you didn't include the change log, nor did you respond to 
 Stephen's reply suggesting that all users be converted to select viopath 
 (versus the proposed 2 select and 5 get it via depends and default y).

 milton


Hi Milton/Stephen,

Sorry for resending the patch before taking care of the response. 
Resending 
the patch with changes made to other three drivers also.

Impact: Fix the VIOPATH dependency in the iSeries dependent drivers.

iSeries depend drivers build fails, when CONFIG_VIOPATH is disabled.
Removing the dependency of VIOPATH by selecting it, when the drivers
dependent on iSeries code.


Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/iseries/Kconfig |5 -
 drivers/char/Kconfig   |1 +
 drivers/scsi/Kconfig   |1 +
 3 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/iseries/Kconfig 
b/arch/powerpc/platforms/iseries/Kconfig
index ed3753d..5cb2320 100644
--- a/arch/powerpc/platforms/iseries/Kconfig
+++ b/arch/powerpc/platforms/iseries/Kconfig
@@ -10,18 +10,21 @@ menu iSeries device drivers
 config VIODASD
tristate iSeries Virtual I/O disk support
depends on BLOCK
+   select VIOPATH
help
  If you are running on an iSeries system and you want to use
  virtual disks created and managed by OS/400, say Y.
 
 config VIOCD
tristate iSeries Virtual I/O CD support
+   select VIOPATH
help
  If you are running Linux on an IBM iSeries system and you want to
  read a CD drive owned by OS/400, say Y here.
 
 config VIOTAPE
tristate iSeries Virtual Tape Support
+   select VIOPATH
help
  If you are running Linux on an iSeries system and you want Linux
  to read and/or write a tape drive owned by OS/400, say Y here.
@@ -30,5 +33,5 @@ endmenu
 
 config VIOPATH
bool
-   depends on VIODASD || VIOCD || VIOTAPE || ISERIES_VETH
+   depends on PPC_ISERIES
default y
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 1697043..b8da09a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -616,6 +616,7 @@ config HVC_ISERIES
default y
select HVC_DRIVER
select HVC_IRQ
+   select VIOPATH
help
  iSeries machines support a hypervisor virtual console.
 
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index b732297..256c7be 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -884,6 +884,7 @@ config SCSI_IBMVSCSI
tristate IBM Virtual SCSI support
depends on PPC_PSERIES || PPC_ISERIES
select SCSI_SRP_ATTRS
+   select VIOPATH if PPC_ISERIES
help
  This is the IBM POWER Virtual SCSI Client
 
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] 2.6.28-git4 - powerpc - drivers build fails with !CONFIG_VIOPATH

[Kamalesh Babulal]

* Milton Miller milt...@bga.com [2009-01-04 02:54:15]:

 In-Reply-To: 20090103191359.ga9...@linux.vnet.ibm.com

 Kamalesh Babulal wrote:
  config SCSI_IBMVSCSI
 tristate IBM Virtual SCSI support
 -   depends on PPC_PSERIES || PPC_ISERIES
 +   depends on (PPC_PSERIES || PPC_ISERIES)  VIOPATH
 select SCSI_SRP_ATTRS
 help
   This is the IBM POWER Virtual SCSI Client

 As VIOPATH is iSeries code and is only used by the iSeries code, the 
 requirment should be

 depends on PPC_PSERIES || (PPC_ISERIES  VIOPATH)

 except VIOPATH isn't selectable:

 arch/powerpc/platforms/iseries/Kconfig:

  config VIOPATH
 bool
 depends on VIODASD || VIOCD || VIOTAPE || ISERIES_VETH
 default y

 so instead we should be adding

 select VIOPATH if PPC_ISERIES

 to SCSI_IBMVSCSI and just

 select VIOPATH

 to HVC_ISERIES as it depends on PPC_ISERIES

 otherwise you have to enable one driver to get these other drivers.

 milton


Hi Milton,

Thanks for the review comments, I am resending the patch with the 
changes you have recommended.

Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
--
 drivers/char/Kconfig |1 +
 drivers/scsi/Kconfig |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 1697043..b8da09a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -616,6 +616,7 @@ config HVC_ISERIES
default y
select HVC_DRIVER
select HVC_IRQ
+   select VIOPATH
help
  iSeries machines support a hypervisor virtual console.
 
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index b732297..256c7be 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -884,6 +884,7 @@ config SCSI_IBMVSCSI
tristate IBM Virtual SCSI support
depends on PPC_PSERIES || PPC_ISERIES
select SCSI_SRP_ATTRS
+   select VIOPATH if PPC_ISERIES
help
  This is the IBM POWER Virtual SCSI Client
 
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] 2.6.28-git4 - powerpc - drivers build fails with !CONFIG_VIOPATH

[Kamalesh Babulal]

Hi Stephen,

2.6.28-git4 kernel build fails on powerpc, with CONFIG_VIOPATH=n

drivers/built-in.o: In function `put_chars':
/linux-2.6.28/drivers/char/hvc_iseries.c:156: undefined reference to 
`.viopath_isactive'
/linux-2.6.28/drivers/char/hvc_iseries.c:162: undefined reference to 
`.vio_get_event_buffer'
drivers/built-in.o: In function `init_data_event':
/linux-2.6.28/drivers/char/hvc_iseries.c:106: undefined reference to 
`.viopath_sourceinst'
/linux-2.6.28/drivers/char/hvc_iseries.c:107: undefined reference to 
`.viopath_targetinst'
drivers/built-in.o: In function `put_chars':
/linux-2.6.28/drivers/char/hvc_iseries.c:194: undefined reference to 
`.vio_free_event_buffer'
drivers/built-in.o: In function `send_open':
/linux-2.6.28/drivers/char/hvc_iseries.c:480: undefined reference to 
`.viopath_sourceinst'
/linux-2.6.28/drivers/char/hvc_iseries.c:480: undefined reference to 
`.viopath_targetinst'
drivers/built-in.o: In function `hvc_vio_init':
/linux-2.6.28/drivers/char/hvc_iseries.c:499: undefined reference to 
`.viopath_open'
/linux-2.6.28/drivers/char/hvc_iseries.c:505: undefined reference to 
`.vio_set_hostlp'
/linux-2.6.28/drivers/char/hvc_iseries.c:515: undefined reference to 
`.viopath_open'
/linux-2.6.28/drivers/char/hvc_iseries.c:523: undefined reference to 
`.vio_setHandler'
/linux-2.6.28/drivers/char/hvc_iseries.c:532: undefined reference to 
`.viopath_isactive'
/linux-2.6.28/drivers/char/hvc_iseries.c:543: undefined reference to 
`.viopath_isactive'
/linux-2.6.28/drivers/char/hvc_iseries.c:543: undefined reference to 
`.viopath_isactive'
drivers/built-in.o:(.toc1+0x2eb8): undefined reference to `viopath_hostLp'
make: *** [.tmp_vmlinux1] Error 1


ERROR: .vio_setHandler [drivers/scsi/ibmvscsi/ibmvscsic.ko] undefined!
ERROR: .viopath_open [drivers/scsi/ibmvscsi/ibmvscsic.ko] undefined!
ERROR: viopath_hostLp [drivers/scsi/ibmvscsi/ibmvscsic.ko] undefined!
ERROR: .viopath_close [drivers/scsi/ibmvscsi/ibmvscsic.ko] undefined!
ERROR: .viopath_targetinst [drivers/scsi/ibmvscsi/ibmvscsic.ko] undefined!
ERROR: .viopath_sourceinst [drivers/scsi/ibmvscsi/ibmvscsic.ko] undefined!
ERROR: .vio_clearHandler [drivers/scsi/ibmvscsi/ibmvscsic.ko]
undefined!
make[1]: *** [__modpost] Error 1

Adding CONFIG_VIOPATH to the depends list for both the drivers, fixes
the build failure. I have tested the patch for build failure only.

Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
--
 drivers/char/Kconfig |2 +-
 drivers/scsi/Kconfig |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 1697043..69ae607 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -612,7 +612,7 @@ config HVC_CONSOLE
 
 config HVC_ISERIES
bool iSeries Hypervisor Virtual Console support
-   depends on PPC_ISERIES
+   depends on PPC_ISERIES  VIOPATH
default y
select HVC_DRIVER
select HVC_IRQ
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index b732297..bae8cd0 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -882,7 +882,7 @@ config SCSI_IPS
 
 config SCSI_IBMVSCSI
tristate IBM Virtual SCSI support
-   depends on PPC_PSERIES || PPC_ISERIES
+   depends on (PPC_PSERIES || PPC_ISERIES)  VIOPATH
select SCSI_SRP_ATTRS
help
  This is the IBM POWER Virtual SCSI Client
--
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28-git4-autokern1
# Fri Jan  2 23:22:08 2009
#
CONFIG_PPC64=y

#
# Processor support
#
# CONFIG_POWER4_ONLY is not set
CONFIG_POWER3=y
CONFIG_POWER4=y
CONFIG_TUNE_CELL=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
# CONFIG_VSX is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_64=y
CONFIG_PPC_MM_SLICES=y
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_SMP=y
CONFIG_NR_CPUS=128
CONFIG_64BIT=y
CONFIG_WORD_SIZE=64
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
CONFIG_GENERIC_TBSYNC=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_HIBERNATE_64=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
CONFIG_PPC_DCR_MMIO=y
CONFIG_PPC_DCR=y
CONFIG_PPC_OF_PLATFORM_PCI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup

[BUG] 2.6.28-git-4 - powerpc - kernel expection 'c01 at .kernel_thread'

[Kamalesh Babulal]

)
c00e2abc  ebc2b260  ld  r30,-19872(r2)
c00e2ac0  f821ff51  stdur1,-176(r1)
c00e2ac4  7c7b1b78  mr  r27,r3
c00e2ac8  7c9d2378  mr  r29,r4
c00e2acc  3800  li  r0,0
c00e2ad0  8b4d01da  lbz r26,474(r13)
c00e2ad4  980d01da  stb r0,474(r13)
c00e2ad8  e93e8110  ld  r9,-32496(r30)
c00e2adc  a00d000a  lhz r0,10(r13)
c00e2ae0  7daa6b78  mr  r10,r13
c00e2ae4  8129  lwz r9,0(r9)
c00e2ae8  78001f24  rldicr  r0,r0,3,60
c00e2aec  7fe3002a  ldx r31,r3,r0
c00e2af0  2f89  cmpwi   cr7,r9,0
c00e2af4  419e0160  beq cr7,c00e2c54# 
.kmem_cache_free+0x1b8/0x244
c00e2af8  3d204000  lis r9,16384
c00e2afc  f8810070  std r4,112(r1)
c00e2b00  3838  li  r0,56
c00e2b04  3960  li  r11,-1
c00e2b08  792907c6  rldicr  r9,r9,32,31
c00e2b0c  796b00c4  rldicr  r11,r11,0,3
c00e2b10  7d244a14  add r9,r4,r9
c00e2b14  7929a302  rldicl  r9,r9,52,12
c00e2b18  7d2901d2  mulld   r9,r9,r0
c00e2b1c  7c09582a  ldx r0,r9,r11
c00e2b20  7d695a14  add r11,r9,r11
c00e2b24  780997e3  rldicl. r9,r0,50,63
c00e2b28  41a20008  beq c00e2b30# 
.kmem_cache_free+0x94/0x244
c00e2b2c  e96b0010  ld  r11,16(r11)
c00e2b30  e80b  ld  r0,0(r11)
c00e2b34  6880  xorir0,r0,128
c00e2b38  7800cfe2  rldicl  r0,r0,57,63
c00e2b3c  0b00  tdnei   r0,0
c00e2b40  a00a000a  lhz r0,10(r10)
c00e2b44  e93e8028  ld  r9,-32728(r30)
c00e2b48  e96b0030  ld  r11,48(r11)
c00e2b4c  78001764  rldicr  r0,r0,2,61
c00e2b50  a38b0028  lhz r28,40(r11)
c00e2b54  7d2902aa  lwaxr9,r9,r0
c00e2b58  7f9c4800  cmpwcr7,r28,r9
c00e2b5c  41be00f8  beq cr7,c00e2c54# 
.kmem_cache_free+0x1b8/0x244
c00e2b60  79291f24  rldicr  r9,r9,3,60
c00e2b64  7d29da14  add r9,r9,r27
c00e2b68  e9290168  ld  r9,360(r9)
c00e2b6c  e8690050  ld  r3,80(r9)
c00e2b70  2fa3  cmpdi   cr7,r3,0
c00e2b74  419e0088  beq cr7,c00e2bfc# 
.kmem_cache_free+0x160/0x244
c00e2b78  7b891f24  rldicr  r9,r28,3,60
c00e2b7c  7fa3482a  ldx r29,r3,r9
c00e2b80  2fbd  cmpdi   cr7,r29,0
c00e2b84  419e0078  beq cr7,c00e2bfc# 
.kmem_cache_free+0x160/0x244
c00e2b88  387d0010  addir3,r29,16
c00e2b8c  4823eb5d  bl  c03216e8# 
._spin_lock+0x0/0x88
c00e2b90  6000  nop
c00e2b94  801d  lwz r0,0(r29)
c00e2b98  813d0004  lwz r9,4(r29)
c00e2b9c  7f804840  cmplw   cr7,r0,r9
c00e2ba0  40be0014  bne cr7,c00e2bb4# 
.kmem_cache_free+0x118/0x244
c00e2ba4  7f63db78  mr  r3,r27

-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[BUG] next-20081231 -powerpc - panic at tasklet_kill_immediate()

[Kamalesh Babulal]

Hi Stephen,

next-20081231 kernel panic's, while booting up on powerpc. This
panic was visible in next-20081230 kernel also.

[1.268844] Brought up 2 CPUs
[1.268873] Unable to handle kernel paging request for data at address 
0x0009
[1.268876] Faulting instruction address: 0xc005a9f8
[1.268880] Oops: Kernel access of bad area, sig: 11 [#1]
[1.268882] SMP NR_CPUS=32 NUMA PowerMac
[1.268886] Modules linked in:
[1.268889] NIP: c005a9f8 LR: c006ee54 CTR: c005a9c0
[1.268893] REGS: c002763c3c80 TRAP: 0300   Not tainted  
(2.6.28-next-20081231-autokern1)
[1.268896] MSR: 90009032 EE,ME,IR,DR  CR: 2424  XER: 000f
[1.268903] DAR: 0009, DSISR: 4000
[1.268905] TASK = c002760e20c0[5] 'ksoftirqd/1' THREAD: 
c002763c CPU: 1
[1.268908] GPR00:  c002763c3f00 c04f9088 
0001 
[1.268913] GPR04: c002760e28d0  2422 
c0010098 
[1.268917] GPR08:  0ec1c518 c0514a40 
0010 
[1.268922] GPR12: c051c700 c051c500  
 
[1.268926] GPR16:    
 
[1.268930] GPR20:    
0140 
[1.268934] GPR24: 01829d88 c0429b28 0140 
 
[1.268939] GPR28: c002760bfc48 0001 c0498a98 
c04b0150 
[1.268950] NIP [c005a9f8] .tasklet_kill_immediate+0x38/0xb8
[1.268955] LR [c006ee54] .kthread+0x78/0xc4
[1.268957] Call Trace:
[1.268960] [c002763c3f00] [c006ee1c] .kthread+0x40/0xc4 
(unreliable)
[1.268967] [c002763c3f90] [c00227a8] .kernel_thread+0x54/0x70
[1.268969] Instruction dump:
[1.268971] 7c8b07b4 7d693670 7d290194 556b06be e95e8040 7d2907b4 79291f24 
e94a 
[1.268977] 7c0a482a 7c005c36 780007e0 0b00 e8030008 7800ffe2 0b00 
e8030008 
[1.268992] ---[ end trace 31fd0ba7d8756001 ]---
[1.269016] Unable to handle kernel paging request for data at address 
0x
[1.269019] Faulting instruction address: 0xc00d9b4c
[1.269022] Oops: Kernel access of bad area, sig: 11 [#2]
[1.269024] SMP NR_CPUS=32 NUMA PowerMac
[1.269026] Modules linked in:
[1.269029] NIP: c00d9b4c LR: c00511fc CTR: 0003
[1.269032] REGS: c002763c35d0 TRAP: 0300   Tainted: G  D 
(2.6.28-next-20081231-autokern1)
[1.269035] MSR: 90009032 EE,ME,IR,DR  CR: 28004082  XER: 200f
[1.269040] DAR: , DSISR: 4000
[1.269043] TASK = c002760e20c0[5] 'ksoftirqd/1' THREAD: 
c002763c CPU: 1
[1.269046] GPR00: 0004 c002763c3850 c04f9088 
c00276027d00 
[1.269051] GPR04: c002763b6980  c0457278 
c0457278 
[1.269055] GPR08: c002760e2290  c051c500 
c002763b6080 
[1.269060] GPR12: 4884 c051c500  
 
[1.269064] GPR16:    
 
[1.269068] GPR20:    
0001 
[1.269073] GPR24: c002760e20b0 c002760e2228  
c00276027d00 
[1.269077] GPR28:  c002763b6980 c049c9b8 
 
[1.269086] NIP [c00d9b4c] .kmem_cache_free+0x1b8/0x244
[1.269090] LR [c00511fc] .__cleanup_sighand+0x44/0x5c
[1.269092] Call Trace:
[1.269095] [c002763c3850] [c049abe8] 0xc049abe8 
(unreliable)
[1.269099] [c002763c3900] [c00511fc] 
.__cleanup_sighand+0x44/0x5c
[1.269104] [c002763c3980] [c0057244] .release_task+0x2dc/0x400
[1.269108] [c002763c3a20] [c0057b14] .do_exit+0x7ac/0x858
[1.269112] [c002763c3af0] [c0020414] .die+0x1c8/0x1cc
[1.269117] [c002763c3b90] [c0027f4c] .bad_page_fault+0xb8/0xd4
[1.269122] [c002763c3c10] [c0005318] handle_page_fault+0x3c/0x5c
[1.269128] --- Exception: 300 at .tasklet_kill_immediate+0x38/0xb8
[1.269130] LR = .kthread+0x78/0xc4
[1.269133] [c002763c3f00] [c006ee1c] .kthread+0x40/0xc4 
(unreliable)
[1.269138] [c002763c3f90] [c00227a8] .kernel_thread+0x54/0x70
[1.269141] Instruction dump:
[1.269142] 4800016d e97d0168 880d01dc 2fa0 41be0010 7c0004ac 3800 
980d01dc 
[1.269148] 7c2004ac 3800 900b0040 4850 817f 801f0004 7f8b0040 
409c001c 
[1.269155] ---[ end trace 31fd0ba7d8756001 ]---
[1.269157] Fixing recursive fault but reboot is needed!
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center

[BUG] 2.6.28-git2 - powerpc - kernel expection with KGDB - kgdbts:RUN sw breakpoint test

[Kamalesh Babulal]

/0x3f0
[2.613330] LR = .smp_call_function_mask+0x58/0x3f0
[2.613342] [c004fe059660] [c0102f18] 
.smp_call_function+0x58/0x80
[2.613356] [c004fe059700] [c0044bf4] .smp_send_stop+0x34/0x50
[2.613370] [c004fe059780] [c00a0b44] .panic+0xa4/0x210
[2.613383] [c004fe059830] [c012df20] 
.kgdb_handle_exception+0x4e0/0x8b0
[2.613398] [c004fe059940] [c00429e4] 
.kgdb_handle_breakpoint+0x74/0x120
[2.613412] [c004fe0599d0] [c003c3d0] 
.program_check_exception+0x370/0xb00
[2.613427] [c004fe059a90] [c0004b04] 
program_check_common+0x104/0x180
[2.613442] --- Exception: 700 at .smp_call_function_mask+0x78/0x3f0
[2.613446] LR = .smp_call_function_mask+0x58/0x3f0
[2.613458] [c004fe059f10] [c0102f18] 
.smp_call_function+0x58/0x80
[2.613472] [c004fe059fb0] [c0044bf4] .smp_send_stop+0x34/0x50
[2.613486] [c004fe05a030] [c00a0b44] .panic+0xa4/0x210
[2.613499] [c004fe05a0e0] [c012df20] 
.kgdb_handle_exception+0x4e0/0x8b0
[2.613514] [c004fe05a1f0] [c00429e4] 
.kgdb_handle_breakpoint+0x74/0x120
[2.613528] [c004fe05a280] [c003c3d0] 
.program_check_exception+0x370/0xb00
[2.613543] [c004fe05a340] [c0004b04] 
program_check_common+0x104/0x180
[2.613558] --- Exception: 700 at .smp_call_function_mask+0x78/0x3f0
[2.613562] LR = .smp_call_function_mask+0x58/0x3f0
[2.613575] [c004fe05a7c0] [c01020
[2.628594] Call Trace:
[2.628600] Kernel panic - not syncing: Recursive entry to debugger
[2.628623] Call Trace:
[2.628629] Kernel panic - not syncing: Recursive entry to debugger
[2.628652] Call Trace:
(1's of above 2 lines)
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] clean up of netif_rx_reschedule() changes in drivers

[Kamalesh Babulal]

* Stephen Rothwell s...@canb.auug.org.au [2008-12-29 11:00:41]:

 Hi Dave, Neil,
 
 Today's linux-next build (powerpc ppc64_defconfig) failed like this:
 
 drivers/net/ibmveth.c: In function 'ibmveth_poll':
 drivers/net/ibmveth.c:1034: warning: passing argument 1 of 
 'netif_rx_reschedule' from incompatible pointer type
 drivers/net/ibmveth.c:1034: error: too many arguments to function 
 'netif_rx_reschedule'
 
 Another miss in commit 908a7a16b852ffd618a9127be8d62432182d81b4 (net: Remove
 unused netdev arg from some NAPI interfaces).
 
 I have added the following patch for today.
 
 (I wonder how many more there will be? :-()
 
 -- 
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
 http://www.canb.auug.org.au/~sfr/
 
 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Mon, 29 Dec 2008 10:56:00 +1100
 Subject: [PATCH] net: ibmveth NAPI interface cleanup fix
 
 Commit 908a7a16b852ffd618a9127be8d62432182d81b4 (net: Remove unused
 netdev arg from some NAPI interfaces) missed one spot.

Hi Stephen,

Thanks, the patch fixes the build failure for me.

  Tested-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
 ---
  drivers/net/ibmveth.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
 index 1f055a9..9bc0f17 100644
 --- a/drivers/net/ibmveth.c
 +++ b/drivers/net/ibmveth.c
 @@ -1031,7 +1031,7 @@ static int ibmveth_poll(struct napi_struct *napi, int 
 budget)
   netif_rx_complete(napi);
 
   if (ibmveth_rxq_pending_buffer(adapter) 
 - netif_rx_reschedule(netdev, napi)) {
 + netif_rx_reschedule(napi)) {
   lpar_rc = h_vio_signal(adapter-vdev-unit_address,
  VIO_IRQ_DISABLE);
   goto restart_poll;
 -- 
 1.6.0.5

I hit similar build failure due to the change in the netif_rx_reschedule()

drivers/net/ehea/ehea_main.c: In function 'ehea_poll':
drivers/net/ehea/ehea_main.c:844: warning: passing argument 1 of 
'netif_rx_reschedule' from incompatible pointer type
drivers/net/ehea/ehea_main.c:844: error: too many arguments to function 
'netif_rx_reschedule'
make[3]: *** [drivers/net/ehea/ehea_main.o] Error 1

greping through the sources for the changes missed out, we have

./drivers/net/arm/ixp4xx_eth.c:507: 
netif_rx_reschedule(dev, napi)) {
./drivers/net/arm/ep93xx_eth.c:310: if (more  
netif_rx_reschedule(dev, napi))
./drivers/net/wan/ixp4xx_hss.c:657: 
netif_rx_reschedule(dev, napi)) {

Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
--
 drivers/net/arm/ep93xx_eth.c |2 +-
 drivers/net/arm/ixp4xx_eth.c |2 +-
 drivers/net/wan/ixp4xx_hss.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 6ecc600..3ec20cc 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -307,7 +307,7 @@ poll_some_more:
}
spin_unlock_irq(ep-rx_lock);
 
-   if (more  netif_rx_reschedule(dev, napi))
+   if (more  netif_rx_reschedule(napi))
goto poll_some_more;
}
 
diff --git a/drivers/net/arm/ixp4xx_eth.c b/drivers/net/arm/ixp4xx_eth.c
index 26af411..5fce1d5 100644
--- a/drivers/net/arm/ixp4xx_eth.c
+++ b/drivers/net/arm/ixp4xx_eth.c
@@ -504,7 +504,7 @@ static int eth_poll(struct napi_struct *napi, int budget)
netif_rx_complete(napi);
qmgr_enable_irq(rxq);
if (!qmgr_stat_empty(rxq) 
-   netif_rx_reschedule(dev, napi)) {
+   netif_rx_reschedule(napi)) {
 #if DEBUG_RX
printk(KERN_DEBUG %s: eth_poll
netif_rx_reschedule successed\n,
diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
index 0c68025..2dc2416 100644
--- a/drivers/net/wan/ixp4xx_hss.c
+++ b/drivers/net/wan/ixp4xx_hss.c
@@ -654,7 +654,7 @@ static int hss_hdlc_poll(struct napi_struct *napi, int 
budget)
netif_rx_complete(dev, napi);
qmgr_enable_irq(rxq);
if (!qmgr_stat_empty(rxq) 
-   netif_rx_reschedule(dev, napi)) {
+   netif_rx_reschedule(napi)) {
 #if DEBUG_RX
printk(KERN_DEBUG %s: hss_hdlc_poll
netif_rx_reschedule succeeded\n,
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

next-20081216 - powerpc link error 'dynreloc miscount'

[Kamalesh Babulal]

Hi,
next-20081216 build breaks on powerpc

ld: dynreloc miscount for kernel/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1

# ld --version
GNU ld version 2.16.1 Debian GNU/Linux

# gcc --version
gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28-rc8-next-20081216
# Tue Dec 16 15:27:34 2008
#
CONFIG_PPC64=y

#
# Processor support
#
# CONFIG_POWER4_ONLY is not set
CONFIG_POWER3=y
CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_MM_SLICES=y
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_SMP=y
CONFIG_NR_CPUS=32
CONFIG_64BIT=y
CONFIG_WORD_SIZE=64
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
CONFIG_GENERIC_TBSYNC=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_HIBERNATE_64=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
CONFIG_PPC_DCR_MMIO=y
CONFIG_PPC_DCR=y
CONFIG_PPC_OF_PLATFORM_PCI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=n
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_NS is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
# CONFIG_GROUP_SCHED is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
# CONFIG_COMPAT_BRK is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_MARKERS=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=anticipatory
CONFIG_CLASSIC_RCU=y
# CONFIG_FREEZER is not set
CONFIG_PPC_MSI_BITMAP=y

#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
CONFIG_PPC_PSERIES=y
CONFIG_PPC_SPLPAR=y
CONFIG_EEH=y
CONFIG_SCANLOG=m
CONFIG_LPARCFG=y
CONFIG_PPC_SMLPAR=y
CONFIG_CMM=y
CONFIG_PPC_ISERIES=y

#
# iSeries device drivers
#
CONFIG_VIODASD=y
CONFIG_VIOCD=m
CONFIG_VIOTAPE=m
CONFIG_VIOPATH=y
CONFIG_PPC_PMAC=y
CONFIG_PPC_PMAC64=y
CONFIG_PPC_MAPLE=y
CONFIG_PPC_PASEMI=y

#
# PA Semi PWRficient options
#
CONFIG_PPC_PASEMI_IOMMU=y
# CONFIG_PPC_PASEMI_IOMMU_DMA_FORCE is not set

[BUILD-FAILURE] 2.6.28-rc2-mm1 - build breaks on powerpc with !GENERIC_BUG

[Kamalesh Babulal]

CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
# CONFIG_PPC_CLOCK is not set
CONFIG_VIRTUALIZATION=y
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y

[Kamalesh Babulal]

* Adrian Bunk [EMAIL PROTECTED] [2008-10-14 20:58:22]:

 On Tue, Oct 14, 2008 at 09:10:33AM -0700, Brandeburg, Jesse wrote:
  Brice Goglin wrote:
   Adrian Bunk wrote:
   But considering that igb is in a similar situation it would be nice
   if all 3 drivers would handle it the same way.
   
   
   Jesse,
   What do you think of the below patch?
  
  Seems like a much better solution.  I can have Jeff Kirsher work on the
  equivalent patches for igb, and ixgbe today.
  
   I am not very familiar with Kconfig, but it seems to solve the
   problem. 
   If a Kconfig guru could double-check...
  
  Yeah, please Kconfig gurus on the list have a quick look.
 
 Brice's patch looks fine.
 
 cu
 Adrian
 

Thanks, the patch fixes the build failure with CONFIG_MYRI10GE=y, once
patch for CONFIG_IXGBE are send out by Jeff Kirsher/Jesse, I will retest
them.

-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25

[Kamalesh Babulal]

Arjan van de Ven wrote:
 Kamalesh Babulal wrote:
 Hi Stephen,

 Badness warning is seen, while booting up the next-20080825/26 kernels on 
 the powerpc boxes

 
 this is fixed in the patch I sent to Ingo earlier today
 (attached again for reference)
 
 
 
 
 From eafa461d187448998b1f66c9134e66b125db9531 Mon Sep 17 00:00:00 2001
 From: Arjan van de Ven [EMAIL PROTECTED]
 Date: Tue, 26 Aug 2008 09:01:06 -0700
 Subject: [PATCH] debug: add notifier chain debugging
 
 during some development we suspected a case where we left something
 in a notifier chain that was from a module that was unloaded already...
 and that sort of thing is rather hard to track down.
 
 This patch adds a very simple sanity check (which isn't all that
 expensive) to make sure the notifier we're about to call is
 actually from either the kernel itself of from a still-loaded
 module, avoiding a hard-to-chase-down crash.
 
 Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
 Acked-by: Tony Luck [EMAIL PROTECTED]
 ---
  include/linux/kernel.h |3 +++
  kernel/extable.c   |   16 
  kernel/notifier.c  |6 ++
  lib/vsprintf.c |2 +-
  4 files changed, 26 insertions(+), 1 deletions(-)
 
 diff --git a/include/linux/kernel.h b/include/linux/kernel.h
 index 2651f80..4e1366b 100644
 --- a/include/linux/kernel.h
 +++ b/include/linux/kernel.h
 @@ -187,6 +187,9 @@ extern unsigned long long memparse(char *ptr, char 
 **retptr);
  extern int core_kernel_text(unsigned long addr);
  extern int __kernel_text_address(unsigned long addr);
  extern int kernel_text_address(unsigned long addr);
 +extern int func_ptr_is_kernel_text(void *ptr);
 +extern void *dereference_function_descriptor(void *ptr);
 +
  struct pid;
  extern struct pid *session_of_pgrp(struct pid *pgrp);
 
 diff --git a/kernel/extable.c b/kernel/extable.c
 index a26cb2e..adf0cc9 100644
 --- a/kernel/extable.c
 +++ b/kernel/extable.c
 @@ -66,3 +66,19 @@ int kernel_text_address(unsigned long addr)
   return 1;
   return module_text_address(addr) != NULL;
  }
 +
 +/*
 + * On some architectures (PPC64, IA64) function pointers
 + * are actually only tokens to some data that then holds the
 + * real function address. As a result, to find if a function
 + * pointer is part of the kernel text, we need to do some
 + * special dereferencing first.
 + */
 +int func_ptr_is_kernel_text(void *ptr)
 +{
 + unsigned long addr;
 + addr = (unsigned long) dereference_function_descriptor(ptr);
 + if (core_kernel_text(addr))
 + return 1;
 + return module_text_address(addr) != NULL;
 +}
 diff --git a/kernel/notifier.c b/kernel/notifier.c
 index 823be11..522277c 100644
 --- a/kernel/notifier.c
 +++ b/kernel/notifier.c
 @@ -82,6 +82,12 @@ static int __kprobes notifier_call_chain(struct 
 notifier_block **nl,
 
   while (nb  nr_to_call) {
   next_nb = rcu_dereference(nb-next);
 + if (!func_ptr_is_kernel_text(nb-notifier_call)) {
 + WARN(1, Invalid notifier called!);
 + nb = next_nb;
 + continue;
 + }
 +
   ret = nb-notifier_call(nb, val, v);
 
   if (nr_calls)
 diff --git a/lib/vsprintf.c b/lib/vsprintf.c
 index d8d1d11..f5e5ffb 100644
 --- a/lib/vsprintf.c
 +++ b/lib/vsprintf.c
 @@ -513,7 +513,7 @@ static char *string(char *buf, char *end, char *s, int 
 field_width, int precisio
   return buf;
  }
 
 -static inline void *dereference_function_descriptor(void *ptr)
 +void *dereference_function_descriptor(void *ptr)
  {
  #if defined(CONFIG_IA64) || defined(CONFIG_PPC64)
   void *p;

Thanks for reference of the patch, After replacing the patch with the latest 
one above on the powerpc, the warning still remains

Badness at kernel/notifier.c:86
NIP: c0081470 LR: c0081494 CTR: c005a2d0
REGS: c021ce0bfaf0 TRAP: 0700   Not tainted  
(2.6.27-rc4-next-20080826-autotest)
MSR: 80029032 EE,ME,IR,DR  CR: 24008042  XER: 0005
TASK = c015de08[1] 'swapper' THREAD: c021ce0bc000 CPU: 0
GPR00: c0081494 c021ce0bfd70 c081e940 c0749c38 
GPR04: 0003 0001  c021ce0bfe90 
GPR08:   c04fd9f0 c04fd9f0 
GPR12: 2442 c089c300 02307ef0 c06332a0 
GPR16: c0631f28 c0633388 018bf8b0 0270 
GPR20: c070b07c c0707ef0 c0708160 c0631c58 
GPR24: 0003 0001 c021ce0bfe90  
GPR28:  c0749c20 c07bf338 c0749c38 
NIP [c0081470] .notifier_call_chain+0x70/0x140
LR [c0081494] .notifier_call_chain+0x94/0x140
Call Trace:
[c021ce0bfd70] [c0081494] .notifier_call_chain+0x94/0x140 
(unreliable

Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25

[Kamalesh Babulal]

Arjan van de Ven wrote:
 Kamalesh Babulal wrote:
 Thanks for reference of the patch, After replacing the patch with the latest 
 one above on the powerpc, the warning still remains

 Badness at kernel/notifier.c:86
 
 sadly you have something going on that doesn't list the modules loaded etc...
 
 is this during boot or way later?
 (because if it's the later, you might be hitting a legitimate bug ;-)
 
 NIP: c0081470 LR: c0081494 CTR: c005a2d0
 REGS: c021ce0bfaf0 TRAP: 0700   Not tainted  
 (2.6.27-rc4-next-20080826-autotest)
 MSR: 80029032 EE,ME,IR,DR  CR: 24008042  XER: 0005
 TASK = c015de08[1] 'swapper' THREAD: c021ce0bc000 CPU: 0
 GPR00: c0081494 c021ce0bfd70 c081e940 c0749c38 
 GPR04: 0003 0001  c021ce0bfe90 
 GPR08:   c04fd9f0 c04fd9f0 
 GPR12: 2442 c089c300 02307ef0 c06332a0 
 GPR16: c0631f28 c0633388 018bf8b0 0270 
 GPR20: c070b07c c0707ef0 c0708160 c0631c58 
 GPR24: 0003 0001 c021ce0bfe90  
 GPR28:  c0749c20 c07bf338 c0749c38 
 NIP [c0081470] .notifier_call_chain+0x70/0x140
 LR [c0081494] .notifier_call_chain+0x94/0x140
 Call Trace:
 [c021ce0bfd70] [c0081494] .notifier_call_chain+0x94/0x140 
 (unreliable)
 [c021ce0bfe20] [c04fe3fc] .cpu_up+0x10c/0x200
 [c021ce0bfee0] [c06cdcc0] .kernel_init+0x1b0/0x440
 [c021ce0bff90] [c00299cc] .kernel_thread+0x4c/0x68
 Instruction dump:
 e863 2fa3 419e00f0 2fa6 419e00e8 2e27 7c7f1b78 3b60 
 4828 6000 6000 6000 0fe0 2fbd 2f3c 7fbfeb78 

This is during the bootup
Welcome to yaboot version 1.3.12
Enter help to get some basic usage information
boot: autotest
Please wait, loading kernel...
   Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 0270, size: 846 Kbytes
OF stdout device is: /vdevice/[EMAIL PROTECTED]
Hypertas detected, assuming LPAR !
command line: root=/dev/sda6 console=hvc0 IDENT=1219851195 
memory layout at init:
  alloc_bottom : 027d4000
  alloc_top: 0800
  alloc_top_hi : 0001
  rmo_top  : 0800
  ram_top  : 0001
Looking for displays
instantiating rtas at 0x076a1000 ... done
boot cpu hw idx 
starting cpu hw idx 0002... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x028d5000 - 0x028d637a
Device tree struct  0x028d7000 - 0x028df000
Calling quiesce ...
returning from prom_init
Using pSeries machine description
Found initrd at 0xc270:0xc27d3800
console [udbg0] enabled
Partition configured for 4 cpus.
CPU maps initialized for 2 threads per core
Starting Linux PPC64 #1 SMP Wed Aug 27 11:25:24 EDT 2008
-
ppc64_pft_size= 0x1a
physicalMemorySize= 0x1
htab_hash_mask= 0x7
-
Initializing cgroup subsys cpuset
Linux version 2.6.27-rc4-next-20080826-autotest ([EMAIL PROTECTED]) (gcc 
version 3.4.6 20060404 (Red Hat 3.4.6-3)) #1 SMP Wed Aug 27 11:25:24 EDT 2008
[boot]0012 Setup Arch
PCI host bridge /[EMAIL PROTECTED]  ranges:
  IO 0x03fe0060..0x03fe006f - 0x
 MEM 0x0401..0x04017fff - 0x8000 
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
  DMA  0x - 0x0010
  Normal   0x0010 - 0x0010
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x - 0x0010
[boot]0015 Setup Done
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1034240
Policy zone: DMA
Kernel command line: root=/dev/sda6 console=hvc0 IDENT=1219851195 
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
clocksource: timebase mult[10cd746] shift[22] registered
Console: colour dummy device 80x25
console handover: boot [udbg0] - real [hvc0]
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 0
Memory: 4101404k/4194304k available (7536k kernel code, 92900k reserved, 1108k 
data, 604k bss, 300k init)
SLUB: Genslabs=13, HWalign=128, Order=0-3, MinObjects=0, CPUs=4, Nodes=16
Calibrating delay loop... 475.13 BogoMIPS (lpj=950272)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
[ cut here ]
Badness at kernel/notifier.c:86
NIP: c050228c LR: c0502274 CTR

[BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25

[Kamalesh Babulal]

: c075f640  00b0 001bb4f0 
GPR08: 3b7d85d0  c08027b0 c08027b0 
GPR12: 003697af c08c4300  c0636720 
GPR16: 4210 c0634fb8  00246c00 
GPR20: 02819298 c0719298 02819508 c0719508 
GPR24: 02c0 c06361d0 c08d5918 c0716618 
GPR28: c08c1040 c075f640 c07d9ee8 c075f4f8 
NIP [c0075bfc] .notifier_chain_register+0x30/0x80
LR [c0075bf0] .notifier_chain_register+0x24/0x80
Call Trace:
[c0843d40] [c0075bf0] .notifier_chain_register+0x24/0x80 
(unreliable)
[c0843dd0] [c04d6240] .register_cpu_notifier+0x2c/0x54
[c0843e60] [c06fefe8] .page_alloc_init+0x1c/0x34
[c0843ee0] [c06e3784] .start_kernel+0x1d4/0x498
[c0843f90] [c000850c] .start_here_common+0x3c/0xb0
Instruction dump:
7c0802a6 fba1ffe8 fbe1fff8 7c7f1b78 e864 7c9d2378 f8010010 f821ff71 
4bff77c5 6000 2fa3 409e0020 0fe0 4830 801d0010 812b0010 
.
.
.
snip many of the similar call traces

the commit which introduced this warning is

commit 16f9b13de93c8bfdac16b4d15577af2c132358ef
Author: Arjan van de Ven [EMAIL PROTECTED]
Date:   Fri Aug 15 15:29:38 2008 -0700

debug: add notifier chain debugging

during some development we suspected a case where we left something
in a notifier chain that was from a module that was unloaded already...
and that sort of thing is rather hard to track down.

This patch adds a very simple sanity check (which isn't all that
expensive) to make sure the notifier we're about to call is
actually from either the kernel itself of from a still-loaded
module, avoiding a hard-to-chase-down crash.

Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]

diff --git a/kernel/notifier.c b/kernel/notifier.c
index 823be11..143fdd7 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -21,6 +21,10 @@ BLOCKING_NOTIFIER_HEAD(reboot_notifier_list);
 static int notifier_chain_register(struct notifier_block **nl,
struct notifier_block *n)
 {
+   if (!kernel_text_address((unsigned long)n-notifier_call)) {
+   WARN(1, Invalid notifier registered!);
+   return 0;
+   }
while ((*nl) != NULL) {
if (n-priority  (*nl)-priority)
break;
snip


-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc

[Kamalesh Babulal]

Tony Breeds wrote:
 On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
 Hi Andrew,

 make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fails with build 
 error
 
 snip
 
 Turning off GCOV fixes this.  Not really the best solution but at
 least it narrows doen the search effort.

Thanks, kernel compiles after turning off the GCOV profiling options.
 
 Peter,
   Can you have a look at how this can be fixed, if at all?
Peter, 
kindly let me know if you want me to test any test patches/fixes.
 
 Yours Tony
 
   linux.conf.auhttp://www.marchsouth.org/
   Jan 19 - 24 2009 The Australian Linux Technical Conference!
 


-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [BUG] 2.6.26-rc8-git2 - powerpc - circular locking dependency detected with net/ehea driver

[Kamalesh Babulal]

Jan-Bernd Themann wrote:
 Hi Kamalesh,
 
 where you able to reproduce this problem with the patches applied
 we posted on friday?
 
 Regards,
 Jan-Bernd
 
 On Tuesday 01 July 2008 14:38, Kamalesh Babulal wrote:
 Hi,

 circular locking dependency is detected, while booting the
 powerpc box with the 2.6.26-rc8-git2 kernel.

 ===
 [ INFO: possible circular locking dependency detected ]
 2.6.26-rc8-git2 #1
 ---
Hi Jan-Bernd,

Thanks for the patch. I tried your patch set over the 2.6.26-rc8-git2 kernel, 
the circular dependency is still begin detected :(.

Jul  7 09:12:42 : ===
Jul  7 09:12:42 : [ INFO: possible circular locking dependency detected ]
Jul  7 09:12:42 : 2.6.26-rc8-git2 #2
Jul  7 09:12:42 : ---
Jul  7 09:12:42 : ip/2218 is trying to acquire lock:
Jul  7 09:12:42 :  (ehea_fw_handles.lock){--..}, at: [d02740c4] 
.ehea_up+0x6c/0x6f4 [ehea]
Jul  7 09:12:42 : 
Jul  7 09:12:42 : but task is already holding lock:
Jul  7 09:12:42 :  (port-port_lock){--..}, at: [d02757dc] 
.ehea_open+0x44/0xcc [ehea]
Jul  7 09:12:42 : 
Jul  7 09:12:42 : which lock already depends on the new lock.
Jul  7 09:12:42 : 
Jul  7 09:12:42 : 
Jul  7 09:12:42 : the existing dependency chain (in reverse order) is:
Jul  7 09:12:42 : 
Jul  7 09:12:42 : - #2 (port-port_lock){--..}:
Jul  7 09:12:42 :[c00aa0e8] .__lock_acquire+0xc84/0xee0
Jul  7 09:12:42 :[c00aa41c] .lock_acquire+0xd8/0x124
Jul  7 09:12:42 :[c0452008] .mutex_lock_nested+0x168/0x420
Jul  7 09:12:42 :[d02757dc] .ehea_open+0x44/0xcc [ehea]
Jul  7 09:12:42 :[c03b62b0] .dev_open+0xec/0x160
Jul  7 09:12:42 :[c03b46a4] .dev_change_flags+0x10c/0x210
Jul  7 09:12:42 :[c04162b0] .devinet_ioctl+0x2cc/0x778
Jul  7 09:12:42 :[c04173e0] .inet_ioctl+0xdc/0x134
Jul  7 09:12:42 :[c03a4464] .sock_ioctl+0x2dc/0x338
Jul  7 09:12:42 :[c012d12c] .vfs_ioctl+0x64/0xfc
Jul  7 09:12:42 :[c012d614] .do_vfs_ioctl+0x450/0x494
Jul  7 09:12:42 :[c012d6d0] .sys_ioctl+0x78/0xc0
Jul  7 09:12:42 :[c016413c] .dev_ifsioc+0x1e8/0x450
Jul  7 09:12:42 :[c0163588] .compat_sys_ioctl+0x3ec/0x484
Jul  7 09:12:42 :[c00086dc] syscall_exit+0x0/0x40
Jul  7 09:12:42 : 
Jul  7 09:12:42 : - #1 (rtnl_mutex){--..}:
Jul  7 09:12:42 :[c00aa0e8] .__lock_acquire+0xc84/0xee0
Jul  7 09:12:42 :[c00aa41c] .lock_acquire+0xd8/0x124
Jul  7 09:12:42 :[c0452008] .mutex_lock_nested+0x168/0x420
Jul  7 09:12:42 :[c03c1ad0] .rtnl_lock+0x28/0x44
Jul  7 09:12:42 :[c03b5334] .register_netdev+0x24/0x8c
Jul  7 09:12:42 :[d027292c] 
.ehea_setup_single_port+0x2d4/0x3e0 [ehea]
Jul  7 09:12:42 :[d027a494] .ehea_probe_adapter+0x290/0x3a0 
[ehea]
Jul  7 09:12:42 :[c03a0098] 
.of_platform_device_probe+0x80/0x8c4
Jul  7 09:12:42 :[c0305ce4] .driver_probe_device+0x144/0x20c
Jul  7 09:12:42 :[c0305e14] .__driver_attach+0x68/0xb0
Jul  7 09:12:42 :[c0304ed4] .bus_for_each_dev+0x88/0xe4
Jul  7 09:12:42 :[c0305a24] .driver_attach+0x34/0x50
Jul  7 09:12:42 :[c0305524] .bus_add_driver+0xe0/0x294
Jul  7 09:12:42 :[c0306178] .driver_register+0xcc/0x1a4
Jul  7 09:12:42 :[c039ff30] .of_register_driver+0x54/0x6c
Jul  7 09:12:42 :[c00256f4] .ibmebus_register_driver+0x40/0x60
Jul  7 09:12:42 :[d027a788] .ehea_module_init+0x1e4/0x238c 
[ehea]
Jul  7 09:12:42 :[c00b5294] .sys_init_module+0x19a0/0x1b80
Jul  7 09:12:42 :[c00086dc] syscall_exit+0x0/0x40
Jul  7 09:12:42 : 
Jul  7 09:12:42 : - #0 (ehea_fw_handles.lock){--..}:
Jul  7 09:12:42 :[c00a9fe4] .__lock_acquire+0xb80/0xee0
Jul  7 09:12:42 :[c00aa41c] .lock_acquire+0xd8/0x124
Jul  7 09:12:42 :[c0452008] .mutex_lock_nested+0x168/0x420
Jul  7 09:12:42 :[d02740c4] .ehea_up+0x6c/0x6f4 [ehea]
Jul  7 09:12:42 :[d0275804] .ehea_open+0x6c/0xcc [ehea]
Jul  7 09:12:42 :[c03b62b0] .dev_open+0xec/0x160
Jul  7 09:12:42 :[c03b46a4] .dev_change_flags+0x10c/0x210
Jul  7 09:12:42 :[c04162b0] .devinet_ioctl+0x2cc/0x778
Jul  7 09:12:42 :[c04173e0] .inet_ioctl+0xdc/0x134
Jul  7 09:12:42 :[c03a4464] .sock_ioctl+0x2dc/0x338
Jul  7 09:12:42 :[c012d12c] .vfs_ioctl+0x64/0xfc
Jul  7 09:12:42 :[c012d614] .do_vfs_ioctl+0x450/0x494
Jul  7 09:12:42 :[c012d6d0] .sys_ioctl+0x78/0xc0
Jul  7

Re: [BUILD-FAILURE] linux-next: Tree for June 30 - powerpc - build failure at arch_add_memory()

[Kamalesh Babulal]

Tony Breeds wrote:
 On Mon, Jun 30, 2008 at 11:55:02PM +0530, Kamalesh Babulal wrote:
 Hi Stephen,

 next-20080630 kernel build fails on powerpc, with randconfig

   CC  arch/powerpc/mm/mem.o
 arch/powerpc/mm/mem.c: In function ‘arch_add_memory’:
 arch/powerpc/mm/mem.c:130: error: implicit declaration of function 
 ‘create_section_mapping’
 make[1]: *** [arch/powerpc/mm/mem.o] Error 1
 make: *** [arch/powerpc/mm] Error 2
 
 This problem exists in in 2.6.26-rc8, so it's not specifially linux-next
 realted.  The patch at:
 http://patchwork.ozlabs.org/linuxppc/patch?id=19347
 should fix it but is un-ACK'd ;P
Hi Tony,

Thanks, the patch fixes the build failure on the machine.

 
 Yours Tony
 
   linux.conf.auhttp://www.marchsouth.org/
   Jan 19 - 24 2009 The Australian Linux Technical Conference!
 


-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[BUG] 2.6.26-rc8-git2 - powerpc - circular locking dependency detected with net/ehea driver

[Kamalesh Babulal]

]
[c0010608faf0] [d08189a0] .ipv6_setsockopt+0x90/0x120 [ipv6]
[c0010608fba0] [d081d408] .udpv6_setsockopt+0x40/0x5c [ipv6]
[c0010608fc20] [c03a4bf4] .sock_common_setsockopt+0x40/0x58
[c0010608fca0] [c03a1ae8] .sys_setsockopt+0xc0/0x110
[c0010608fd60] [c03a4054] .sys_socketcall+0x1bc/0x21c
[c0010608fe30] [c00086dc] syscall_exit+0x0/0x40
[  OK  ]

0xc03c1ad0 is in rtnl_lock (net/core/rtnetlink.c:66).
61
62  static DEFINE_MUTEX(rtnl_mutex);
63
64  void rtnl_lock(void)
65  {
66  mutex_lock(rtnl_mutex);
67  }
68
69  void __rtnl_unlock(void)
70  {

0x4fa8 is in ehea_up (drivers/net/ehea/ehea_main.c:2462).
2457struct ehea_port *port = netdev_priv(dev);
2458
2459if (port-state == EHEA_PORT_UP)
2460return 0;
2461
2462mutex_lock(ehea_fw_handles.lock);
2463
2464ret = ehea_port_res_setup(port, port-num_def_qps,
2465  port-num_add_tx_qps);
2466if (ret) {

0x57bc is in ehea_open (drivers/net/ehea/ehea_main.c:2552).
2547static int ehea_open(struct net_device *dev)
2548{
2549int ret;
2550struct ehea_port *port = netdev_priv(dev);
2551
2552mutex_lock(port-port_lock);
2553
2554if (netif_msg_ifup(port))
2555ehea_info(enabling port %s, dev-name);
2556


-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[BUILD-FAILURE] linux-next: Tree for June 30 - powerpc - build failure at arch_add_memory()

[Kamalesh Babulal]

Hi Stephen,

next-20080630 kernel build fails on powerpc, with randconfig

  CC  arch/powerpc/mm/mem.o
arch/powerpc/mm/mem.c: In function ‘arch_add_memory’:
arch/powerpc/mm/mem.c:130: error: implicit declaration of function 
‘create_section_mapping’
make[1]: *** [arch/powerpc/mm/mem.o] Error 1
make: *** [arch/powerpc/mm] Error 2


-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.26-rc8-next-20080630
# Mon Jun 30 13:21:18 2008
#
CONFIG_PPC64=y

#
# Processor support
#
CONFIG_POWER4_ONLY=y
CONFIG_POWER4=y
# CONFIG_TUNE_CELL is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_MM_SLICES=y
# CONFIG_VIRT_CPU_ACCOUNTING is not set
# CONFIG_SMP is not set
CONFIG_64BIT=y
CONFIG_WORD_SIZE=64
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
# CONFIG_DEFAULT_UIMAGE is not set
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EMBEDDED=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
# CONFIG_HOTPLUG is not set
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
CONFIG_PCSPKR_PLATFORM=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
# CONFIG_EVENTFD is not set
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_MARKERS=y
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
# CONFIG_HAVE_DMA_ATTRS is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=1
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED=noop
CONFIG_CLASSIC_RCU=y

#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_PPC_82xx is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_86xx is not set
CONFIG_PPC_PSERIES=y
# CONFIG_PPC_SPLPAR is not set
CONFIG_EEH=y
# CONFIG_LPARCFG is not set
CONFIG_PPC_PSERIES_DEBUG=y
# CONFIG_PPC_ISERIES is not set
# CONFIG_PPC_MPC512x is not set
# CONFIG_PPC_MPC5121 is not set
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
# CONFIG_PPC_PASEMI is not set
CONFIG_PPC_PS3=y

#
# PS3 Platform Options
#
CONFIG_PS3_ADVANCED=y
CONFIG_PS3_HTAB_SIZE=20
CONFIG_PS3_VUART=y
CONFIG_PS3_PS3AV=y
CONFIG_PS3_SYS_MANAGER=y
# CONFIG_PS3_DISK is not set
# CONFIG_PS3_ROM is not set
# CONFIG_PS3_FLASH is not set
# CONFIG_PS3_LPM is not set
CONFIG_PPC_CELL=y
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PPC_IBM_CELL_BLADE is not set
# CONFIG_PPC_CELLEB is not set

#
# Cell Broadband Engine options
#
CONFIG_SPU_FS=y
CONFIG_SPU_FS_64K_LS=y
# CONFIG_SPU_TRACE is not set
CONFIG_SPU_BASE=y
# CONFIG_PQ2ADS is not set
CONFIG_PPC_NATIVE=y
CONFIG_UDBG_RTAS_CONSOLE=y
CONFIG_XICS=y
# CONFIG_IPIC is not set
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
CONFIG_PPC_I8259=y
# CONFIG_U3_DART is not set
CONFIG_PPC_RTAS=y
CONFIG_RTAS_ERROR_LOGGING=y
# CONFIG_RTAS_PROC is not set
# CONFIG_MMIO_NVRAM is not set
CONFIG_IBMVIO=y
CONFIG_IBMEBUS=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
CONFIG_CPU_FREQ=y

[BUILD-FAILURE] linux-next: Tree for June 17 - powerpc build fails with !CONFIG_BUG

[Kamalesh Babulal]

Hi Stephen,

next-20080617 kernel build fails with randconfig on a powerpc box

arch/powerpc/kernel/module_32.c: In function ‘module_find_bug’:
arch/powerpc/kernel/module_32.c:377: error: increment of pointer to unknown 
structure
arch/powerpc/kernel/module_32.c:377: error: arithmetic on pointer to an 
incomplete type
arch/powerpc/kernel/module_32.c:378: error: dereferencing pointer to incomplete 
type
make[1]: *** [arch/powerpc/kernel/module_32.o] Error 1
make: *** [arch/powerpc/kernel] Error 2


-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.26-rc6-next-20080617
# Tue Jun 17 18:29:34 2008
#
# CONFIG_PPC64 is not set

#
# Processor support
#
# CONFIG_6xx is not set
CONFIG_PPC_85xx=y
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_E500=y
CONFIG_PPC_E500MC=y
CONFIG_PPC_FPU=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
CONFIG_FSL_EMB_PERFMON=y
# CONFIG_PHYS_64BIT is not set
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_DEFAULT_UIMAGE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_NS=y
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EMBEDDED=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
# CONFIG_BUG is not set
CONFIG_ELF_CORE=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
# CONFIG_SHMEM is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
CONFIG_PROFILING=y
CONFIG_MARKERS=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
# CONFIG_HAVE_DMA_ATTRS is not set
# CONFIG_USE_GENERIC_SMP_HELPERS is not set
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=1
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_KMOD is not set
# CONFIG_BLOCK is not set
# CONFIG_CLASSIC_RCU is not set

#
# Platform support
#
# CONFIG_PPC_MPC512x is not set
# CONFIG_PPC_MPC5121 is not set
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PQ2ADS is not set
CONFIG_MPC85xx=y
CONFIG_MPC8540_ADS=y
CONFIG_MPC8560_ADS=y
# CONFIG_MPC85xx_CDS is not set
# CONFIG_MPC85xx_MDS is not set
CONFIG_MPC85xx_DS=y
CONFIG_KSI8560=y
CONFIG_STX_GP3=y
# CONFIG_TQM8540 is not set
# CONFIG_TQM8541 is not set
# CONFIG_TQM8548 is not set
CONFIG_TQM8555=y
# CONFIG_TQM8560 is not set
CONFIG_SBC8548=y
# CONFIG_SBC8560 is not set
CONFIG_TQM85xx=y
# CONFIG_IPIC is not set
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
CONFIG_PPC_I8259=y
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=m
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=m