There are no callers of both __opal_async_get_token() and
__opal_async_release_token().
This patch also removes the possibility of "emergency through
synchronous call to __opal_async_get_token()" as such it makes more
sense to initialise opal_sync_sem for the maximum number of async
tokens.
Signe
Hello,
This patchset aims to solve the problem that currently all users of
the opal-async calls must use wait_event(), this may be undesirable
when there is a userspace process behind the request for the opal
call, if OPAL takes too long to complete the call then hung task
warnings will appear.
I
This is a pretty substantial rework of the last patch that should address most
of the comment mpe had, namely:
1. Removed the random cpu_feature(ARCH_300) check. The new series always builds
the cache mask and the new scheduler topology is used if we detect a mismatch
of the thread and
2. In
When building the CPU scheduler topology the kernel uses the ibm,chipid
property from the devicetree to group logical CPUs. Currently the DT
search for this property is open-coded in smp.c and this functionality
is a duplication of what's in cpu_to_chip_id() already. This patch
removes the existing
The CPU scheduler topology is constructed from a number of per-cpu
cpumasks which describe which sets of logical CPUs are related in some
fashion. Current code that handles constructing these masks when CPUs
are hot(un)plugged can be simplified a bit by exploiting the fact that
the scheduler requir
We want to add an extra level to the CPU scheduler topology to account
for cores which share a cache. To do this we need to build a cpumask
for each CPU that indicates which CPUs share this cache to use as an
input to the scheduler.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/s
In previous generations of Power processors each core had a private L2
cache. The Power 9 processor has a slightly different design where the
L2 cache is shared among pairs of cores rather than being completely
private.
Making the scheduler aware of this cache sharing allows the scheduler to
make
dev_pm_ops are not supposed to change at runtime. All functions
working with dev_pm_ops provided by work with const
dev_pm_ops. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
179561456 8 194204bdc drivers/scsi/ibmvscsi/
dev_pm_ops are not supposed to change at runtime. All functions
working with dev_pm_ops provided by work with const
dev_pm_ops. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
419371296 20 43253a8f5 drivers/scsi/ibmvscsi/
This patch fixes a crash seen while doing a kexec from
radix mode to hash mode. Key 0 is special in hash and
used in the RPN by default, we set the key values to 0
today. In radix mode key 0 is used to control
supervisor<->user access. In hash key 0 is used by default,
so the first instruction afte
On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote:
> On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote:
>> On Wed, Jun 28, 2017 at 6:32 PM, Eryu Guan wrote:
>> Thanks for the excellent bug report, I am a little lost on the stack
>> trace, it shows a bad page access that we think is tri
On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote:
> On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote:
> > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote:
> >> On Wed, Jun 28, 2017 at 6:32 PM, Eryu Guan wrote:
>
> >> Thanks for the excellent bug report, I am a little los
On Thursday 29 June 2017 01:11 AM, Thomas Gleixner wrote:
On Thu, 29 Jun 2017, Anju T Sudhakar wrote:
+static void cleanup_all_core_imc_memory(struct imc_pmu *pmu_ptr)
+{
+ struct imc_mem_info *ptr;
+
+ for (ptr = pmu_ptr->mem_info; ptr; ptr++) {
+ if (ptr->vbase[0])
Balbir Singh writes:
> This patch fixes a crash seen while doing a kexec from
> radix mode to hash mode. Key 0 is special in hash and
> used in the RPN by default, we set the key values to 0
> today. In radix mode key 0 is used to control
> supervisor<->user access. In hash key 0 is used by defau
I've seen this as well (or something like it) in mambo at boot, but
it's pretty rare to hit. I'm trying to debug it.
I'm guessing possibly an idle vs interrupt race.
> [ 4255.151192] Sending NMI from CPU 5 to CPUs 0:
> [ 4255.151246] NMI backtrace for cpu 0
> [ 4255.151287] CPU: 0 PID: 0 Comm: sw
On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote:
> On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote:
> > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote:
> >> On Wed, Jun 28, 2017 at 6:32 PM, Eryu Guan wrote:
>
> >> Thanks for the excellent bug report, I am a little los
On Thu, 29 Jun 2017 19:36:14 +1000
Nicholas Piggin wrote:
> I've seen this as well (or something like it) in mambo at boot, but
> it's pretty rare to hit. I'm trying to debug it.
>
> I'm guessing possibly an idle vs interrupt race.
>
> > [ 4255.151192] Sending NMI from CPU 5 to CPUs 0:
> > [ 42
Eryu Guan writes:
> Hi all,
>
> Li Wang and I are constantly seeing ppc64le hosts crashing due to bad
> page access. But it's not reproducing on every ppc64le host we've
> tested, but it usually happened in filesystem testings.
> And I've confirmed that reverting above commit 'resolves' the cr
On Thu, Jun 29, 2017 at 08:27:11PM +1000, Michael Ellerman wrote:
> Eryu Guan writes:
>
> > Hi all,
> >
> > Li Wang and I are constantly seeing ppc64le hosts crashing due to bad
> > page access. But it's not reproducing on every ppc64le host we've
> > tested, but it usually happened in filesystem
On Thu, 29 Jun 2017, Madhavan Srinivasan wrote:
> On Thursday 29 June 2017 01:11 AM, Thomas Gleixner wrote:
> Idea is to handle multiple event session for a given core and
> yes, my bad, current implementation is racy/broken.
> But an alternate approach is to have a per-core mutex and
> per-core re
This is the third in the series of patches to build out an appropriate
kprobes blacklist for powerpc. Since posting the second series (*),
there have been related changes to the code and I have brought that
series forward to account for those changes. As such, all patches from
the second series are
Currently, we assume that the function pointer we receive in
ppc_function_entry() points to a function descriptor. However, this is
not always the case. In particular, assembly symbols without the right
annotation do not have an associated function descriptor. Some of these
symbols are added to the
Convert some of the symbols into private symbols and blacklist
system_call_common() and system_call() from kprobes. We can't take a
trap at parts of these functions as either MSR_RI is unset or the kernel
stack pointer is not yet setup.
Reviewed-by: Masami Hiramatsu
Reviewed-by: Nicholas Piggin
Commit b48bbb82e2b835 ("powerpc/64s: Don't unbalance the return branch
predictor in __replay_interrupt()") introduced __replay_interrupt_return
symbol with '.L' prefix in hopes of keeping it private. However, due to
the use of LOAD_REG_ADDR(), the assembler kept this symbol visible. Fix
the same by
It is common to get a PMU interrupt right after the mtmsr instruction that
enables interrupts. Due to this, the stack trace profile gets needlessly split
across system_call_common() and system_call().
Previously, system_call() symbol was at the current place to hide a few
earlier symbols which hav
Blacklist all functions involved while handling a trap. We:
- convert some of the symbols into private symbols, and
- blacklist most functions involved while handling a trap.
Reviewed-by: Masami Hiramatsu
Signed-off-by: Naveen N. Rao
---
arch/powerpc/kernel/entry_64.S | 35 +++
It is actually safe to probe system_call() in entry_64.S, but only till
we unset MSR_RI. To allow this, add a new symbol system_call_exit()
after the mtmsrd and blacklist that. Though the mtmsrd instruction
itself is now whitelisted, we won't be allowed to probe on it as we
don't allow probing on r
We can't take traps with relocation off, so blacklist enter_rtas() and
rtas_return_loc(). However, instead of blacklisting all of enter_rtas(),
introduce a new symbol __enter_rtas from where on we can't take a trap
and blacklist that.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/kernel/entry_64
On Thu, 29 Jun 2017 16:11:04 +0530
"Naveen N. Rao" wrote:
> Currently, we assume that the function pointer we receive in
> ppc_function_entry() points to a function descriptor. However, this is
> not always the case. In particular, assembly symbols without the right
> annotation do not have an as
On Thu, 29 Jun 2017 16:11:08 +0530
"Naveen N. Rao" wrote:
> It is actually safe to probe system_call() in entry_64.S, but only till
> we unset MSR_RI. To allow this, add a new symbol system_call_exit()
> after the mtmsrd and blacklist that. Though the mtmsrd instruction
> itself is now whiteliste
On Thu, 29 Jun 2017 16:11:10 +0530
"Naveen N. Rao" wrote:
> We can't take traps with relocation off, so blacklist enter_rtas() and
> rtas_return_loc(). However, instead of blacklisting all of enter_rtas(),
> introduce a new symbol __enter_rtas from where on we can't take a trap
> and blacklist th
Eryu Guan writes:
> On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote:
>> On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote:
>> > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote:
>> >> On Wed, Jun 28, 2017 at 6:32 PM, Eryu Guan wrote:
>>
>> >> Thanks for the excellent bu
From: Balbir Singh
> Sent: 28 June 2017 18:04
> For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M.
> We use 16M since its the larger of 2M on radix and 16M
> on hash for our linear mapping. The plan is to have
> .text, .rodata and everything upto __init_begin marked
> as RX. Note we still have
On Thu, Jun 29, 2017 at 9:29 PM, David Laight wrote:
> From: Balbir Singh
>> Sent: 28 June 2017 18:04
>> For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M.
>> We use 16M since its the larger of 2M on radix and 16M
>> on hash for our linear mapping. The plan is to have
>> .text, .rodata and ev
On Thu, Jun 29, 2017 at 09:12:55PM +1000, Michael Ellerman wrote:
> Eryu Guan writes:
>
> > On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote:
> >> On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote:
> >> > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Singh wrote:
> >> >> On Wed, Ju
On Thu, 29 Jun 2017 16:11:07 +0530
"Naveen N. Rao" wrote:
> It is common to get a PMU interrupt right after the mtmsr instruction that
> enables interrupts. Due to this, the stack trace profile gets needlessly split
> across system_call_common() and system_call().
>
> Previously, system_call() s
On 2017/06/29 08:49PM, Nicholas Piggin wrote:
> On Thu, 29 Jun 2017 16:11:04 +0530
> "Naveen N. Rao" wrote:
>
> > Currently, we assume that the function pointer we receive in
> > ppc_function_entry() points to a function descriptor. However, this is
> > not always the case. In particular, assembl
On 2017/06/29 08:55PM, Nicholas Piggin wrote:
> On Thu, 29 Jun 2017 16:11:08 +0530
> "Naveen N. Rao" wrote:
>
> > It is actually safe to probe system_call() in entry_64.S, but only till
> > we unset MSR_RI. To allow this, add a new symbol system_call_exit()
> > after the mtmsrd and blacklist that
On Thu, Jun 29, 2017 at 7:29 PM, Michael Ellerman wrote:
> Balbir Singh writes:
>
>> This patch fixes a crash seen while doing a kexec from
>> radix mode to hash mode. Key 0 is special in hash and
>> used in the RPN by default, we set the key values to 0
>> today. In radix mode key 0 is used to c
On 2017/06/29 09:01PM, Nicholas Piggin wrote:
> On Thu, 29 Jun 2017 16:11:10 +0530
> "Naveen N. Rao" wrote:
>
> > We can't take traps with relocation off, so blacklist enter_rtas() and
> > rtas_return_loc(). However, instead of blacklisting all of enter_rtas(),
> > introduce a new symbol __enter_
This patch fixes a crash seen while doing a kexec from
radix mode to hash mode. Key 0 is special in hash and
used in the RPN by default, we set the key values to 0
today. In radix mode key 0 is used to control
supervisor<->user access. In hash key 0 is used by default,
so the first instruction afte
Eryu Guan writes:
> On Thu, Jun 29, 2017 at 09:12:55PM +1000, Michael Ellerman wrote:
>> Eryu Guan writes:
>>
>> > On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote:
>> >> On Thu, Jun 29, 2017 at 1:41 PM, Eryu Guan wrote:
>> >> > On Thu, Jun 29, 2017 at 03:16:10AM +1000, Balbir Sing
Eryu Guan writes:
> On Thu, Jun 29, 2017 at 08:27:11PM +1000, Michael Ellerman wrote:
>> Eryu Guan writes:
>>
>> > Hi all,
>> >
>> > Li Wang and I are constantly seeing ppc64le hosts crashing due to bad
>> > page access. But it's not reproducing on every ppc64le host we've
>> > tested, but it u
On Thu, 29 Jun 2017 17:24:14 +0530
"Naveen N. Rao" wrote:
> On 2017/06/29 09:01PM, Nicholas Piggin wrote:
> > On Thu, 29 Jun 2017 16:11:10 +0530
> > "Naveen N. Rao" wrote:
> >
> > > We can't take traps with relocation off, so blacklist enter_rtas() and
> > > rtas_return_loc(). However, instea
On Thu, 2017-04-06 at 14:14:50 UTC, Anshuman Khandual wrote:
> Adds some explaination on how the vmemmap based struct page layout's
> physical mapping is allocated and tracked through linked list. It
> also keeps note of a possible race condition.
>
> Signed-off-by: Anshuman Khandual
Applied to
On Thu, 2017-04-06 at 14:14:49 UTC, Anshuman Khandual wrote:
> Add some explaination to the layout of vmemmap virtual address
> space and how physical page mapping is only used for valid PFNs
> present at any point on the system.
>
> Reviewed-by: Aneesh Kumar K.V
> Signed-off-by: Anshuman Khandua
On Tue, 2017-04-11 at 05:23:25 UTC, Balbir Singh wrote:
> Just a quick patch to trace tlbie(l)'s. The idea being that it can be
> enabled when we suspect corruption or when we need to see if we are doing
> the right thing during flush. I think the format can be enhanced to
> make it nicer (expand t
On Mon, 2017-05-08 at 06:18:31 UTC, Michael Neuling wrote:
> Update to real function name.
>
> Signed-off-by: Michael Neuling
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/2bafb7ffa3e0908ad2e69b94c436a0
cheers
On Mon, 2017-05-08 at 06:23:31 UTC, Michael Neuling wrote:
> The asm code assumes the FP regs are at the start of fp_state. While
> this is true now, it may not always be the case and there is nothing
> enforcing it.
>
> This fixes the asm-offsets to point to the actual FP registers inside
> the f
On Thu, 2017-06-01 at 17:20:38 UTC, Hari Bathini wrote:
> fadump sets up crash memory ranges to be used for creating PT_LOAD
> program headers in elfcore header. Memory chunk RMA_START through
> boot memory area size is added as the first memory range because
> firmware, at the time of crash, moves
On Thu, 2017-06-01 at 19:40:10 UTC, Hari Bathini wrote:
> Around 95% of memory is reserved by fadump/capture kernel. All this
> memory is freed, one page at a time, on writing '1' to the node
> /sys/kernel/fadump_release_mem. On systems with large memory, this
> can take a long time to complete, le
On Wed, 2017-06-14 at 04:19:58 UTC, Russell Currey wrote:
> Dumping the PE State Tables (PEST) can be highly verbose if a number of PEs
> are affected, especially in the case where the whole PHB is frozen and 512
> lines get printed. Check for duplicates when dumping the PEST to reduce
> useless o
On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote:
> local_irq_enable can cause interrupts to be taken which could
> take significant amount of processing time. The idle process
> should set its polling flag before this, so another process that
> wakes it during this time will not have to s
On Thu, 2017-06-15 at 01:53:16 UTC, Michael Neuling wrote:
> The P9 PVR bits 12-15 don't indicate a revision but instead different
> chip configurations. From BookIV we have:
>Bits Configuration
> 0 :Scale out 12 cores
> 1 :Scale out 24 cores
> 2 :Scale up 12 core
On Thu, 2017-06-15 at 18:54:14 UTC, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But
On Thu, 2017-06-15 at 18:54:15 UTC, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But
On Thu, 2017-06-15 at 18:54:16 UTC, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But
On Thu, 2017-06-15 at 18:54:17 UTC, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But
On Thu, 2017-06-15 at 18:54:18 UTC, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But
On Wed, 2017-06-21 at 07:18:03 UTC, Russell Currey wrote:
> Add a helper that determines if all the devices contained in a given PE
> are all from the same vendor or not. This can be useful in determining
> if it's okay to make PE-wide changes that may be suitable for some
> devices but not for ot
On Sat, 2017-06-24 at 17:29:01 UTC, Benjamin Herrenschmidt wrote:
> On POWER9 the ERAT may be incorrect on wakeup from some stop states
> that lose state. This causes random segvs and illegal instructions
> when these stop states are enabled.
>
> This patch invalidates the ERAT on wakeup on POWER9
On Sat, 2017-06-24 at 19:57:27 UTC, Benjamin Herrenschmidt wrote:
> There is no reason for that message to be pr_info(), it will be printed
> every time we start a KVM guest.
>
> Signed-off-by: Benjamin Herrenschmidt
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/89d8bb163868
On Sun, 2017-06-25 at 15:34:46 UTC, Madhavan Srinivasan wrote:
> Correct "branch" event code of Power9 is "r4d05e".
> Replace the current "branch" event code with "r4d05e"
> and add a hack to use "r10012" as event code for
> power9 dd1.
>
> Fixes: d89f473ff6f8 ("powerpc/perf: Fix PM_BRU_CMPL event
On Sun, 2017-06-25 at 20:08:46 UTC, Benjamin Herrenschmidt wrote:
> From:Â Michael Neuling
>
> On P9 (Nimbus) DD2 and later, in radix mode, the move to the PID
> register will implicitly invalidate the user space ERAT entries
> and leave the kernel ones alone. Thus the only thing needed is
> an i
On Tue, 2017-06-27 at 07:00:05 UTC, Santosh Sivaraj wrote:
> During secondary start, we do not need to BUG_ON if an invalid CPU number
> is passed. We already print an error if secondary cannot be started, so
> just return an error instead.
>
> Signed-off-by: Santosh Sivaraj
Series applied to po
On Wed, 2017-06-28 at 01:16:49 UTC, Akshay Adiga wrote:
> pnv_wakeup_noloss expects R12 to contain SRR1 value to determine if
> the wakeup reason is an HMI in CHECK_HMI_INTERRUPT.
>
> When we wakeup with ESL=0, SRR1 will not contain the wakeup reason, so
> there is no point setting R12 to SRR1.
>
On 2017/06/29 09:57AM, Masami Hiramatsu wrote:
> On Thu, 29 Jun 2017 00:13:24 +0530
> "Naveen N. Rao" wrote:
>
> > On 2017/06/28 11:16PM, Masami Hiramatsu wrote:
> > > > > diff --git
> > > > > a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > > > > b/tools/testing/selftests
When we derive event names, convert some expected symbols (such as ':'
used to specify module:name and '.' present in some symbols) into
underscores so that the event name is not rejected.
Before this patch:
# echo 'p kobject_example:foo_store' > kprobe_events
trace_kprobe: Failed to alloc
v1:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1427923.html
Changes since v1:
- Patch 1 is unchanged from v1.
- Patch 3 drops change to include dot symbols, as suggested by Masami.
- Patches 2 and 4 implement new test cases to cover these scenarios
Thanks,
Naveen
Masami
Add a kprobes test to ensure that we are able to add a probe on a
module function using 'p :' format, without having to
specify a probe name.
Suggested-by: Masami Hiramatsu
Acked-by: Masami Hiramatsu
Signed-off-by: Naveen N. Rao
---
.../testing/selftests/ftrace/test.d/kprobe/probe_module.tc |
KPROBES_ON_FTRACE is only available on powerpc64le. Update comment to
clarify this.
Also, we should use an offset of 8 to ensure that the probe does not
fall on ftrace location. The current offset of 4 will fall before the
function local entry point and won't fire, while an offset of 12 or 16
will
From: Masami Hiramatsu
Add a testcase for kprobe event naming. This testcase
checks whether the kprobe events can automatically ganerate
its event name on normal function and dot-suffixed function.
Also it checks whether the kprobe events can correctly
define new event with given event name and g
On Thu, 2017-06-29 at 15:24 +1000, Michael Ellerman wrote:
> Benjamin Herrenschmidt writes:
>
> > On Wed, 2017-06-28 at 15:17 +1000, Michael Ellerman wrote:
> > > Which doesn't really make sense. FSP says it's running (runtime).
> > >
> > > The end of the OPAL log is below.
> > >
> > > I think
On Thu, Jun 29, 2017 at 10:06:31PM +1000, Michael Ellerman wrote:
> Eryu Guan writes:
>
> > On Thu, Jun 29, 2017 at 09:12:55PM +1000, Michael Ellerman wrote:
> >> Eryu Guan writes:
> >>
> >> > On Thu, Jun 29, 2017 at 06:47:50PM +1000, Balbir Singh wrote:
> >> >> On Thu, Jun 29, 2017 at 1:41 PM,
Hello,
Could be the same problem as the one reported in the following thread.
http://lkml.kernel.org/r/1497266622.15415.39.ca...@abdul.in.ibm.com
The root cause there is ppc arch code not setting up possible cpu <->
numa mapping during boot.
Thanks.
--
tejun
On Thu, 29 Jun 2017 20:23:05 +1000
Nicholas Piggin wrote:
> On Thu, 29 Jun 2017 19:36:14 +1000
> Nicholas Piggin wrote:
> > I don't *think* the replay-wakeup-interrupt patch is directly involved, but
> > it's likely to be one of the idle patches.
Okay this turned out to be misconfigured slee
On 2017/06/29 10:13PM, Nicholas Piggin wrote:
> On Thu, 29 Jun 2017 17:24:14 +0530
> "Naveen N. Rao" wrote:
>
> > On 2017/06/29 09:01PM, Nicholas Piggin wrote:
> > > On Thu, 29 Jun 2017 16:11:10 +0530
> > > "Naveen N. Rao" wrote:
> > >
> > > > We can't take traps with relocation off, so black
This is the third in the series of patches to build out an appropriate
kprobes blacklist for powerpc. Since posting the second series (*),
there have been related changes to the code and I have brought that
series forward to account for those changes. As such, all patches from
the second series are
Currently, we assume that the function pointer we receive in
ppc_function_entry() points to a function descriptor. However, this is
not always the case. In particular, assembly symbols without the right
annotation do not have an associated function descriptor. Some of these
symbols are added to the
Commit b48bbb82e2b835 ("powerpc/64s: Don't unbalance the return branch
predictor in __replay_interrupt()") introduced __replay_interrupt_return
symbol with '.L' prefix in hopes of keeping it private. However, due to
the use of LOAD_REG_ADDR(), the assembler kept this symbol visible. Fix
the same by
Convert some of the symbols into private symbols and blacklist
system_call_common() and system_call() from kprobes. We can't take a
trap at parts of these functions as either MSR_RI is unset or the kernel
stack pointer is not yet setup.
Reviewed-by: Masami Hiramatsu
Reviewed-by: Nicholas Piggin
It is common to get a PMU interrupt right after the mtmsr instruction that
enables interrupts. Due to this, the stack trace profile gets needlessly split
across system_call_common() and system_call().
Previously, system_call() symbol was at the current place to hide a few
earlier symbols which hav
It is actually safe to probe system_call() in entry_64.S, but only till
we unset MSR_RI. To allow this, add a new symbol system_call_exit()
after the mtmsrd and blacklist that.
Suggested-by: Michael Ellerman
Reviewed-by: Nicholas Piggin
Signed-off-by: Naveen N. Rao
---
arch/powerpc/kernel/entr
Blacklist all functions involved while handling a trap. We:
- convert some of the symbols into private symbols, and
- blacklist most functions involved while handling a trap.
Reviewed-by: Masami Hiramatsu
Signed-off-by: Naveen N. Rao
---
arch/powerpc/kernel/entry_64.S | 35 +++
We can't take traps with relocation off, so blacklist enter_rtas() and
rtas_return_loc(). However, instead of blacklisting all of enter_rtas(),
introduce a new symbol __enter_rtas from where on we can't take a trap
and blacklist that.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/kernel/entry_64
On 06/27/2017 10:05 AM, Cyril Bur wrote:
> On Mon, 2017-06-26 at 11:02 +0530, Shilpasri G Bhat wrote:
>> In P9, OCC (On-Chip-Controller) supports shared memory based
>> commad-response interface. Within the shared memory there is an OPAL
>> command buffer and OCC response buffer that can be used
In P9, OCC (On-Chip-Controller) supports shared memory based
commad-response interface. Within the shared memory there is an OPAL
command buffer and OCC response buffer that can be used to send
inband commands to OCC. This patch adds a platform driver to support
the command/response interface betwe
Hi,
On 06/30/2017 12:02 AM, Shilpasri G Bhat wrote:
> In P9, OCC (On-Chip-Controller) supports shared memory based
> commad-response interface. Within the shared memory there is an OPAL
> command buffer and OCC response buffer that can be used to send
> inband commands to OCC. This patch adds a pl
From: Arvind Yadav
Date: Thu, 29 Jun 2017 11:14:50 +0530
> dev_pm_ops are not supposed to change at runtime. All functions
> working with dev_pm_ops provided by work with const
> dev_pm_ops. So mark the non-const structs as const.
>
> File size before:
>text data bss dec
[ Adding my IMAP address on CC to avoid another Lotus Notes reply to LKML.
Man, it has been more than 15 years since the last one!!! ]
Nicholas Piggin wrote on 06/29/2017 07:45:34 AM:
> On Thu, 29 Jun 2017 20:23:05 +1000
> Nicholas Piggin wrote:
>
> > On Thu, 29 Jun 2017 19:36:14 +1000
> > Nicho
compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK,
instead using those in ptrace_request(). The compat variant should
read a compat_sigset_t from userspace instead of ptrace_request()s
sigset_t.
While compat_sigset_t is the same size as sigset_t, it is defined as
2xu32, instead of a
On Wed, 28 Jun 2017 17:27:32 +1000
Alexey Kardashevskiy wrote:
> On 24/06/17 01:17, Alex Williamson wrote:
> > On Fri, 23 Jun 2017 15:06:37 +1000
> > Alexey Kardashevskiy wrote:
> >
> >> On 23/06/17 07:11, Alex Williamson wrote:
> >>> On Thu, 15 Jun 2017 15:48:42 +1000
> >>> Alexey Kardashe
On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman
wrote:
> On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote:
>> local_irq_enable can cause interrupts to be taken which could
>> take significant amount of processing time. The idle process
>> should set its polling flag before this, so anot
Hello,
The hypervisor interface to access 24x7 performance counters (which collect
performance information from system power on to system power off) has been
extended in POWER9 adding new fields to the request and result element
structures.
Also, results for some domains now return more than one
H_GET_24X7_CATALOG_PAGE needs to be passed the version number obtained from
the first catalog page obtained previously. This is a 64 bit number, but
create_events_from_catalog truncates it to 32-bit.
This worked on POWER8, but POWER9 actually uses the upper bits so the call
fails with H_P3 because
request_buffer can hold 254 requests, so if it already has that number of
entries we can't add a new one.
Also, define constant to show where the number comes from.
Fixes: e3ee15dc5d19 ("powerpc/perf/hv-24x7: Define add_event_to_24x7_request()")
Reviewed-by: Sukadev Bhattiprolu
Signed-off-by: Th
hv-24x7.h has a comment mentioning that result_buffer->results can't be
indexed as a normal array because it may contain results of variable sizes,
so fix the loop in h_24x7_event_commit_txn to take the variation into
account when iterating through results.
Another problem in that loop is that it
make_24x7_request already calls log_24x7_hcall if it fails, so callers
don't have to do it again.
In fact, since the latter is now only called from the former, there's no
need for a separate log_24x7_hcall anymore so remove it.
Reviewed-by: Sukadev Bhattiprolu
Signed-off-by: Thiago Jung Bauerman
The H_GET_24X7_CATALOG_PAGE hcall can return a signed error code, so fix
this in the code.
The H_GET_24X7_DATA hcall can return a signed error code, so fix this in
the code. Also, don't truncate it to 32 bit to use as return value for
make_24x7_request. In case of error h_24x7_event_commit_txn pas
There's an H24x7_DATA_BUFFER_SIZE constant, so use it in init_24x7_request.
There's also an HV_PERF_DOMAIN_MAX constant, so use it in
h_24x7_event_init. This makes the comment above the check redundant,
so remove it.
In add_event_to_24x7_request, a statement is terminated with a comma
instead of
1 - 100 of 111 matches
Mail list logo
