On 6/18/19 12:16 PM, Christophe Leroy wrote:
>> +/* Maximum len for DABR is 8 bytes and DAWR is 512 bytes */
>> +static int hw_breakpoint_validate_len(struct arch_hw_breakpoint *hw)
>> +{
>> + u16 length_max = 8;
>> + u16 final_len;
>
> You should be more consistent in naming. If one is
Andrew Donnellan writes:
> On 4/6/19 1:05 pm, Christopher M Riedl wrote:>>> +if (!xmon_is_ro) {
+ xmon_is_ro = kernel_is_locked_down("Using xmon write-access",
+ LOCKDOWN_INTEGRITY);
+ if (xmon_is_ro) {
+
On 6/18/19 12:01 PM, Christophe Leroy wrote:
>> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
>> index f002d286..265fac9fb3a4 100644
>> --- a/arch/powerpc/kernel/process.c
>> +++ b/arch/powerpc/kernel/process.c
>> @@ -793,10 +793,22 @@ static inline int set_dabr(
On 6/18/19 11:45 AM, Michael Neuling wrote:
> On Tue, 2019-06-18 at 09:57 +0530, Ravi Bangoria wrote:
>> Directly setting dawr and dawrx with 0 should be enough to
>> disable watchpoint. No need to reset individual bits in
>> variable and then set in hw.
>
> This seems like a pointless optimisa
On Wed, Jun 05, 2019 at 03:49:15PM +1000, Oliver wrote:
> On Tue, May 7, 2019 at 2:30 PM Sam Bobroff wrote:
> >
> > Now that EEH support for all devices (on PowerNV and pSeries) is
> > provided by the pcibios bus add device hooks, eeh_probe_devices() and
> > eeh_addr_cache_build() are redundant an
Hi Naveen,
Sorry I meant to reply to this earlier .. :/
"Naveen N. Rao" writes:
> With -mprofile-kernel, gcc emits 'mflr r0', followed by 'bl _mcount' to
> enable function tracing and profiling. So far, with dynamic ftrace, we
> used to only patch out the branch to _mcount(). However, mflr is
>
Abhishek Goel's on June 17, 2019 7:56 pm:
> Currently, the cpuidle governors determine what idle state a idling CPU
> should enter into based on heuristics that depend on the idle history on
> that CPU. Given that no predictive heuristic is perfect, there are cases
> where the governor predicts a s
On Tue, Jun 11, 2019 at 03:47:58PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 07/05/2019 14:30, Sam Bobroff wrote:
> > Also remove useless comment.
> >
> > Signed-off-by: Sam Bobroff
> > Reviewed-by: Alexey Kardashevskiy
> > ---
> > arch/powerpc/kernel/eeh.c| 2 +-
> > a
The out-of-tree NVIDIA driver has been re-licensed recently to MIT/GPL
so we can do the right thing and restrict the exported symbols to GPL
only.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/npu-dma.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
Alexey Kardashevskiy writes:
> On 11/05/2019 08:36, Thiago Jung Bauermann wrote:
>>
>> Alexey Kardashevskiy writes:
>>
>>> The commit 8617a5c5bc00 ("powerpc/dma: handle iommu bypass in
>>> dma_iommu_ops") merged direct DMA ops into the IOMMU DMA ops allowing
>>> SWIOTLB as well but only for ma
Christophe Leroy's on June 11, 2019 4:28 pm:
>
>
> Le 10/06/2019 à 05:08, Nicholas Piggin a écrit :
>> __ioremap_at error handling is wonky, it requires caller to clean up
>> after it. Implement a helper that does the map and error cleanup and
>> remove the requirement from the caller.
>>
>> Sig
Christophe Leroy's on June 11, 2019 4:46 pm:
>
>
> Le 10/06/2019 à 05:08, Nicholas Piggin a écrit :
>> Radix can use ioremap_page_range for ioremap, after slab is available.
>> This makes it possible to enable huge ioremap mapping support.
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>> arch/p
Christophe Leroy's on June 11, 2019 3:24 pm:
>
>
> Le 10/06/2019 à 06:38, Nicholas Piggin a écrit :
>> ioremap_page_range is a generic function to create a kernel virtual
>> mapping, move it to mm/vmalloc.c and rename it vmap_range.
>>
>> For clarity with this move, also:
>> - Rename vunmap_page
Christophe Leroy's on June 11, 2019 3:39 pm:
>
>
> Le 10/06/2019 à 06:38, Nicholas Piggin a écrit :
>> For platforms that define HAVE_ARCH_HUGE_VMAP, have vmap allow vmalloc to
>> allocate huge pages and map them
>
> Will this be compatible with Russell's series
> https://patchwork.ozlabs.org/p
Anshuman Khandual's on June 11, 2019 4:17 pm:
>
>
> On 06/10/2019 08:14 PM, Nicholas Piggin wrote:
>> Mark Rutland's on June 11, 2019 12:10 am:
>>> Hi,
>>>
>>> On Mon, Jun 10, 2019 at 02:38:38PM +1000, Nicholas Piggin wrote:
For platforms that define HAVE_ARCH_HUGE_VMAP, have vmap allow vmal
Anshuman Khandual's on June 11, 2019 4:59 pm:
> On 06/11/2019 05:46 AM, Nicholas Piggin wrote:
>> Anshuman Khandual's on June 10, 2019 6:53 pm:
>>> On 06/10/2019 10:08 AM, Nicholas Piggin wrote:
For platforms that define HAVE_ARCH_HUGE_VMAP, have vmap allow vmalloc to
allocate huge pages
On 18/06/2019 22:15, Michael Ellerman wrote:
> Alexey Kardashevskiy writes:
>> The pseries platform uses the PCI_PROBE_DEVTREE method of PCI probing
>> which is basically reading "assigned-addresses" of every PCI device.
>> However if the property is missing or zero sized, then there is
>> no f
On Tue, 2019-06-18 at 18:28 +0200, Christophe Leroy wrote:
>
> Le 04/06/2019 à 05:00, Michael Neuling a écrit :
> > If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
> > at linking with:
> >arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined
> > reference to `
Andreas Schwab writes:
> On Jun 18 2019, Radu Rendec wrote:
>
>> Since you already have a working setup, it would be nice if you could
>> add a printk to arch_ptrace() to print the address and confirm what I
>> believe happens (by reading the gdb source code).
>
> A ppc32 ptrace syscall goes thr
On 23/05/2019 17:49, Christoph Hellwig wrote:
> None of these routines were ever used since they were added to the
> kernel.
It is still being used exactly in the way as it was explained before in
previous respins. Thanks.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/include/
Hello Bharata,
Bharata B Rao writes:
> diff --git a/arch/powerpc/include/asm/kvm_book3s_hmm.h
> b/arch/powerpc/include/asm/kvm_book3s_hmm.h
> index 21f3de5f2acb..3e13dab7f690 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_hmm.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_hmm.h
> @@ -11,6
On Monday, May 20, 2019 11:52:36 AM CEST Ran Wang wrote:
> Some user might want to go through all registered wakeup sources
> and doing things accordingly. For example, SoC PM driver might need to
> do HW programming to prevent powering down specific IP which wakeup
> source depending on. And is us
The Kdump documentation describes procedures with admins use
in order to solve issues on their systems.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/bug-hunting.rst| 4 ++--
Documentation/admin-guide/index.rst | 1 +
Documentation/{ => admin-gui
System gets checkstop if RxFIFO overruns with more requests than the
maximum possible number of CRBs in FIFO at the same time. The max number
of requests per window is controlled by window credits. So find max
CRBs from FIFO size and set it to receive window credits.
Fixes: b0d6c9bab5e4 ("cry
On 06/18/2019 05:35 AM, Michael Ellerman wrote:
> Haren Myneni writes:
>>
>> System gets checkstop if RxFIFO overruns with more requests than the
>> maximum possible number of CRBs in FIFO at the same time. So find max
>> CRBs from FIFO size and set it to receive window credits.
>>
>> CC:
On Tue, 18 Jun 2019 23:53:11 +0530
"Naveen N. Rao" wrote:
> Naveen N. Rao wrote:
> > Steven Rostedt wrote:
> >> On Tue, 18 Jun 2019 20:17:04 +0530
> >> "Naveen N. Rao" wrote:
> >>
> >>> @@ -1551,7 +1551,7 @@ unsigned long ftrace_location_range(unsigned long
> >>> start, unsigned long end)
Naveen N. Rao wrote:
Steven Rostedt wrote:
On Tue, 18 Jun 2019 20:17:04 +0530
"Naveen N. Rao" wrote:
@@ -1551,7 +1551,7 @@ unsigned long ftrace_location_range(unsigned long start,
unsigned long end)
key.flags = end;/* overload flags, as it is unsigned long */
for (pg = ft
Steven Rostedt wrote:
On Tue, 18 Jun 2019 20:17:04 +0530
"Naveen N. Rao" wrote:
@@ -1551,7 +1551,7 @@ unsigned long ftrace_location_range(unsigned long start,
unsigned long end)
key.flags = end;/* overload flags, as it is unsigned long */
for (pg = ftrace_pages_start; pg;
On Jun 18 2019, Radu Rendec wrote:
> Since you already have a working setup, it would be nice if you could
> add a printk to arch_ptrace() to print the address and confirm what I
> believe happens (by reading the gdb source code).
A ppc32 ptrace syscall goes through compat_arch_ptrace.
Andreas.
From: Geert Uytterhoeven
Date: Mon, 17 Jun 2019 13:50:44 +0200
> Flexible array members should be denoted using [] instead of [0], else
> gcc will not warn when they are no longer at the end of a struct.
>
> Signed-off-by: Geert Uytterhoeven
Applied to net-next, thanks.
Le 04/06/2019 à 05:00, Michael Neuling a écrit :
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference
to `dawr_force_enable'
This was caused by commit c1fe190c0672 ("powerpc: Add
On Tue, Jun 4, 2019 at 7:15 PM Masahiro Yamada
wrote:
>
>
> Multiple people have suggested to compile-test UAPI headers.
>
> Currently, Kbuild provides simple sanity checks by headers_check
> but they are not enough to catch bugs.
>
> The most recent patch I know is David Howells' work:
> https://
On Tue, 18 Jun 2019 20:17:04 +0530
"Naveen N. Rao" wrote:
> @@ -1551,7 +1551,7 @@ unsigned long ftrace_location_range(unsigned long
> start, unsigned long end)
> key.flags = end;/* overload flags, as it is unsigned long */
>
> for (pg = ftrace_pages_start; pg; pg = pg->next
On Tue, Jun 18, 2019 at 06:47:01AM -0500, Segher Boessenkool wrote:
> Hi Paul,
>
> On Mon, Jun 17, 2019 at 12:06:32PM +1000, Paul Mackerras wrote:
> > The thing we need to consider is that when SMFCTRL[E] = 0, a ucall
> > instruction becomes a hcall (that is, sc 2 is executed as if it was
> > sc 1
While over-riding ftrace_replace_code(), we still want to reuse the
existing __ftrace_replace_code() function. Rename the function and
make it available for other kernel code.
Signed-off-by: Naveen N. Rao
---
include/linux/ftrace.h | 1 +
kernel/trace/ftrace.c | 8
2 files changed, 5 i
Now that we are patching the preceding 'mflr r0' instruction with
-mprofile-kernel, we need to update ftrace_location[_range]() to
recognise that as being part of ftrace. To do this, we make a small
change to ftrace_location_range() and convert ftrace_cmp_recs() into a
weak function. We implement a
Ftrace location could include more than a single instruction in case of
some architectures (powerpc64, for now). In this case, kprobe is
permitted on any of those instructions, and uses ftrace infrastructure
for functioning.
However, [dis]arm_kprobe_ftrace() uses the kprobe address when setting
up
With KPROBES_ON_FTRACE, kprobe is allowed to be inserted on instructions
that branch to _mcount (referred to as ftrace location). With
-mprofile-kernel, we now include the preceding 'mflr r0' as being part
of the ftrace location.
However, by default, probing on an instruction that is not actually
With -mprofile-kernel, gcc emits 'mflr r0', followed by 'bl _mcount' to
enable function tracing and profiling. So far, with dynamic ftrace, we
used to only patch out the branch to _mcount(). However, mflr is
executed by the branch unit that can only execute one per cycle on
POWER9 and shared with b
In commit a0572f687fb3c ("ftrace: Allow ftrace_replace_code() to be
schedulable), the generic ftrace_replace_code() function was modified to
accept a flags argument in place of a single 'enable' flag. However, the
x86 version of this function was not updated. Fix the same.
Fixes: a0572f687fb3c ("f
Since ftrace_replace_code() is a __weak function and can be overridden,
we need to expose the flags that can be set. So, move the flags enum to
the header file.
Reviewed-by: Steven Rostedt (VMware)
Signed-off-by: Naveen N. Rao
---
include/linux/ftrace.h | 5 +
kernel/trace/ftrace.c | 5 ---
Changes since RFC:
- Patches 1 and 2: No changes
- Patch 3: rename function to ftrace_replace_code_rec() to signify that
it acts on a ftrace record.
- Patch 4: numerous small changes, including those suggested by Nick
Piggin.
- Patch 4: additionally handle scenario where __ftrace_make_call()
On Tue, 2019-06-18 at 09:57 +0530, Ravi Bangoria wrote:
> Watchpoint match range is always doubleword(8 bytes) aligned on
> powerpc. If the given range is crossing doubleword boundary, we
> need to increase the length such that next doubleword also get
> covered. Ex,
>
> address len =
Michael Ellerman writes:
> Vaibhav Jain writes:
>> We recently discovered an bug where physical memory meant for
>> allocation of Huge-pages was inadvertently allocated by another component
>> during early boot.
>
> Can you give me some more detail on what that was? You're seemingly the
> only p
On 6/18/19 5:37 PM, Michael Ellerman wrote:
Vaibhav Jain writes:
We recently discovered an bug where physical memory meant for
allocation of Huge-pages was inadvertently allocated by another component
during early boot.
Can you give me some more detail on what that was? You're seemingly the
o
Le 18/06/2019 à 14:31, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 11/06/2019 à 17:47, Christophe Leroy a écrit :
The patch referenced below moved the loading of segment registers
out of load_up_mmu() in order to do it earlier in the boot sequence.
However, the secondary CPU stil
Jonathan Corbet writes:
> On Wed, 12 Jun 2019 14:52:55 -0300
> Mauro Carvalho Chehab wrote:
>
>> Convert docs to ReST and add them to the arch-specific
>> book.
>>
>> The conversion here was trivial, as almost every file there
>> was already using an elegant format close to ReST standard.
>>
>>
Haren Myneni writes:
>
> System gets checkstop if RxFIFO overruns with more requests than the
> maximum possible number of CRBs in FIFO at the same time. So find max
> CRBs from FIFO size and set it to receive window credits.
>
> CC: sta...@vger.kernel.org # v4.14+
> Signed-off-by:Haren M
Hi Michael,
On Tue, Jun 18, 2019 at 2:23 PM Michael Ellerman wrote:
> Geert Uytterhoeven writes:
> > "git diff" says:
> >
> > \ No newline at end of file
> >
> > after modifying the file.
>
> Is that a problem?
>
> Just curious because it was presumably me that broke it :)
It looks messy ;-
Christophe Leroy writes:
> Le 11/06/2019 à 17:47, Christophe Leroy a écrit :
>> The patch referenced below moved the loading of segment registers
>> out of load_up_mmu() in order to do it earlier in the boot sequence.
>> However, the secondary CPU still needs it to be done when loading up
>> the M
On Tue, 2019-06-18 at 22:15 +1000, Michael Ellerman wrote:
> Alexey Kardashevskiy writes:
> > The pseries platform uses the PCI_PROBE_DEVTREE method of PCI probing
> > which is basically reading "assigned-addresses" of every PCI device.
> > However if the property is missing or zero sized, then th
Ravi Bangoria writes:
> Peter / mpe,
>
> Is the v2 looks good? If so, can anyone of you please pick this up.
I usually wouldn't take it, it's generic perf code. Unless
peter/ingo/acme tell me otherwise.
It's sort of a bug fix for 0819b2e30ccb, should it have a fixes and/or
stable tag?
Fixes:
Geert Uytterhoeven writes:
> "git diff" says:
>
> \ No newline at end of file
>
> after modifying the file.
Is that a problem?
Just curious because it was presumably me that broke it :)
cheers
> diff --git a/tools/testing/selftests/powerpc/mm/.gitignore
> b/tools/testing/selftests/powerpc
Andrew Morton writes:
> On Sat, 15 Jun 2019 10:06:54 +0200 Christophe Leroy
> wrote:
>> Le 14/06/2019 à 21:00, Andrew Morton a écrit :
>> > On Fri, 14 Jun 2019 12:01:09 +0200 David Hildenbrand
>> > wrote:
>> >
>> >> We are using a mixture of "int" and "unsigned long". Let's make this
>> >> co
On Tue, 2019-06-18 at 16:42 +1000, Daniel Axtens wrote:
> Radu Rendec <
> radu.ren...@gmail.com
> > writes:
>
> > On Mon, 2019-06-17 at 11:19 +1000, Daniel Axtens wrote:
> > > Radu Rendec <
> > > radu.ren...@gmail.com
> > >
> > > > writes:
> > > > Hi Everyone,
> > > >
> > > > I'm following up on
Alexey Kardashevskiy writes:
> The pseries platform uses the PCI_PROBE_DEVTREE method of PCI probing
> which is basically reading "assigned-addresses" of every PCI device.
> However if the property is missing or zero sized, then there is
> no fallback of any kind and the PCI resources remain undis
Vaibhav Jain writes:
> We recently discovered an bug where physical memory meant for
> allocation of Huge-pages was inadvertently allocated by another component
> during early boot.
Can you give me some more detail on what that was? You're seemingly the
only person who's ever hit this :)
> The b
On Mon, Jun 17, 2019 at 05:24:58PM -0400, Gustavo Romero wrote:
> In some cases, compiler can allocate the same register for operand 'res'
> and 'vecoutptr', resulting in segfault at 'stxvd2x 40,0,%[vecoutptr]'
> because base register will contain 1, yielding a false-positive.
>
> This is because
Hi Paul,
On Mon, Jun 17, 2019 at 12:06:32PM +1000, Paul Mackerras wrote:
> The thing we need to consider is that when SMFCTRL[E] = 0, a ucall
> instruction becomes a hcall (that is, sc 2 is executed as if it was
> sc 1). In that case, the first argument to the ucall will be
> interpreted as the h
On 6/18/19 11:41 AM, Michael Neuling wrote:
> This is going to collide with this patch
> https://patchwork.ozlabs.org/patch/1109594/
Yeah, I'm aware of the patch. I just developed this on powerpc/next.
I'll rebase my patches accordingly once mpe picks up that patche.
On 6/18/19 11:51 AM, Christophe Leroy wrote:
>
>
> Le 18/06/2019 à 06:27, Ravi Bangoria a écrit :
>> Move feature availability check at the start of the function.
>> Rearrange comment to it's associated code. Use hw->address and
>> hw->len in the 512 bytes boundary check(to write if statement
On 6/18/19 1:39 AM, Alexey Kardashevskiy wrote:
On 18/06/2019 14:26, Shawn Anastasio wrote:
On 6/12/19 2:15 PM, Shawn Anastasio wrote:
On 6/12/19 2:07 AM, Alexey Kardashevskiy wrote:
On 12/06/2019 15:05, Shawn Anastasio wrote:
On 6/5/19 11:11 PM, Shawn Anastasio wrote:
On 5/30/19 2:03 AM
62 matches
Mail list logo
