On 09/01/2020 10:25 PM, Nick Desaulniers wrote:
Rather than invoke the compiler as the driver, use the linker. That way
we can check --orphan-handling=warn support correctly, as cc-ldoption
was removed in
commit 055efab3120b ("kbuild: drop support for cc-ldoption").
Requires dropping the .got
On Thu, Aug 20, 2020 at 01:39:22PM +1000, Jordan Niethe wrote:
> There are two main places where instructions are loaded from the guest:
> * Emulate loadstore - such as when performing MMIO emulation
> triggered by an HDSI
> * After an HV emulation assistance interrupt (e40)
>
> If i
On Thu, Aug 20, 2020 at 01:39:21PM +1000, Jordan Niethe wrote:
> The ppc_inst type was added to help cope with the addition of prefixed
> instructions to the ISA. Convert KVM to use this new type for dealing
> wiht instructions. For now do not try to add further support for
> prefixed instructions.
Le 27/08/2020 à 17:00, Christoph Hellwig a écrit :
Stop providing the possibility to override the address space using
set_fs() now that there is no need for that any more.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/Kconfig | 1 -
arch/powerpc/include/asm/processo
On Mon, 2020-08-31 at 14:35 +1000, Alexey Kardashevskiy wrote:
>
> On 29/08/2020 04:36, Leonardo Bras wrote:
> > On Mon, 2020-08-24 at 15:17 +1000, Alexey Kardashevskiy wrote:
> > > On 18/08/2020 09:40, Leonardo Bras wrote:
> > > > As of today, if the biggest DDW that can be created can't map the
On Mon, 2020-08-31 at 14:34 +1000, Alexey Kardashevskiy wrote:
>
> On 29/08/2020 01:25, Leonardo Bras wrote:
> > On Mon, 2020-08-24 at 15:07 +1000, Alexey Kardashevskiy wrote:
> > > On 18/08/2020 09:40, Leonardo Bras wrote:
> > > > Code used to create a ddw property that was previously scattered i
On Tue, Sep 01, 2020 at 03:25:21PM -0700, Nick Desaulniers wrote:
> Kees Cook is working on series that adds --orphan-section=warn to arm,
> arm64, and x86. I noticed that ppc vdso were still using cc-ldoption
> for these which I removed. It seems this results in that flag being
> silently droppe
Hi Paul,
On 9/2/20 8:02 AM, Paul Mackerras wrote:
On Thu, Jul 23, 2020 at 03:50:51PM +0530, Ravi Bangoria wrote:
Patch #1, #2 and #3 enables p10 2nd DAWR feature for Book3S kvm guest. DAWR
is a hypervisor resource and thus H_SET_MODE hcall is used to set/unset it.
A new case H_SET_MODE_RESOURCE
Hi Paul,
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index 33793444144c..03f401d7be41 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -538,6 +538,8 @@ struct hv_guest_state {
s64 tb_offset;
u64 dawr
Hi Paul,
On 9/2/20 7:19 AM, Paul Mackerras wrote:
On Thu, Jul 23, 2020 at 03:50:52PM +0530, Ravi Bangoria wrote:
Power10 is introducing second DAWR. Use real register names (with
suffix 0) from ISA for current macros and variables used by kvm.
Most of this looks fine, but I think we should no
Hi Paul,
On 9/2/20 7:31 AM, Paul Mackerras wrote:
On Thu, Jul 23, 2020 at 03:50:53PM +0530, Ravi Bangoria wrote:
kvm code assumes single DAWR everywhere. Add code to support 2nd DAWR.
DAWR is a hypervisor resource and thus H_SET_MODE hcall is used to set/
unset it. Introduce new case H_SET_MODE
On Thu, Jul 16, 2020 at 05:07:12PM +0800, Qinglang Miao wrote:
> From: Chen Huang
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Chen Huang
For the arch/powerpc/kvm part:
Acked-by: Paul Mackerras
I expect Michael Ellerman will take the patch through his tree.
Introduce tests to cover simple scenarios where user is watching
memory which can be accessed by kernel as well. We also support
_MODE_EXACT with _SETHWDEBUG interface. Move those testcases out-
side of _BP_RANGE condition. This will help to test _MODE_EXACT
scenarios when CONFIG_HAVE_HW_BREAKPOINT
PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 can be used to determine whether
we are running on an ISA 3.1 compliant machine. Which is needed to
determine DAR behaviour, 512 byte boundary limit etc. This was
requested by Pedro Miraglia Franco de Carvalho for extending
watchpoint features in gdb. Note that ava
There are couple of places where we set len but not hw_len. For
ptrace/perf watchpoints, when CONFIG_HAVE_HW_BREAKPOINT=Y, hw_len
will be calculated and set internally while parsing watchpoint.
But when CONFIG_HAVE_HW_BREAKPOINT=N, we need to manually set
'hw_len'. Similarly for xmon as well, hw_le
On powerpc, ptrace watchpoint works in one-shot mode. i.e. kernel
disables event every time it fires and user has to re-enable it.
Also, in case of ptrace watchpoint, kernel notifies ptrace user
before executing instruction.
With CONFIG_HAVE_HW_BREAKPOINT=N, kernel is missing to disable
ptrace eve
Power10 hw has multiple DAWRs but hw doesn't tell which DAWR caused
the exception. So we have a sw logic to detect that in hw_breakpoint.c.
But hw_breakpoint.c gets compiled only with CONFIG_HAVE_HW_BREAKPOINT=Y.
Move DAWR detection logic outside of hw_breakpoint.c so that it can be
reused when CON
When kernel is compiled with CONFIG_HAVE_HW_BREAKPOINT=N, user can
still create watchpoint using PPC_PTRACE_SETHWDEBUG, with limited
functionalities. But, such watchpoints are never firing because of
the missing privilege settings. Fix that.
It's safe to set HW_BRK_TYPE_PRIV_ALL because we don't r
Vector load/store instructions are special because they are always
aligned. Thus unaligned EA needs to be aligned down before comparing
it with watch ranges. Otherwise we might consider valid event as
invalid.
Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than
one watch
On p10 predecessors, watchpoint with quarword access is compared at
quardword length. If the watch range is doubleword or less than that
in a first half of quarword aligned 16 bytes, and if there is any
unaligned quadword access which will access only the 2nd half, the
handler should consider it as
Patch #1 fixes issue for quardword instruction on p10 predecessors.
Patch #2 fixes issue for vector instructions.
Patch #3 fixes a bug about watchpoint not firing when created with
ptrace PPC_PTRACE_SETHWDEBUG and CONFIG_HAVE_HW_BREAKPOINT=N.
The fix uses HW_BRK_TYPE_PRIV_ALL for
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable the support until we get the tests updated.
[ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
cpu 0x0: Vector: 700 (Program Check) at [c00c6d1e76c0]
pc: c009a5ec: assert_pte_loc
On 9/2/20 9:19 AM, Anshuman Khandual wrote:
On 09/01/2020 03:28 PM, Aneesh Kumar K.V wrote:
On 9/1/20 1:08 PM, Anshuman Khandual wrote:
On 09/01/2020 12:07 PM, Aneesh Kumar K.V wrote:
On 9/1/20 8:55 AM, Anshuman Khandual wrote:
On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
pte_clear_
The MPS field in the VF config space is marked as reserved in current
versions of the SR-IOV spec. In other words, this fixup doesn't do
anything.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 18 --
1 file changed, 18 deletions(-)
diff --gi
The corresponding definitions were deleted in commit 3d5134ee8341
("[POWERPC] Rewrite IO allocation & mapping on powerpc64") which
was merged a mere 13 years ago.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/ppc-pci.h | 4
1 file changed, 4 deletions(-)
diff --git a/arch/p
Nothing uses it.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/ppc-pci.h | 3 ---
arch/powerpc/kernel/pci_dn.c | 40 --
2 files changed, 43 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-pci.h
b/arch/powerpc/include/asm/ppc-pci.h
index
On 09/01/2020 03:28 PM, Aneesh Kumar K.V wrote:
> On 9/1/20 1:08 PM, Anshuman Khandual wrote:
>>
>>
>> On 09/01/2020 12:07 PM, Aneesh Kumar K.V wrote:
>>> On 9/1/20 8:55 AM, Anshuman Khandual wrote:
On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
> pte_clear_tests operate on a
On 09/01/2020 01:21 PM, Christophe Leroy wrote:
>
>
> Le 01/09/2020 à 09:40, Aneesh Kumar K.V a écrit :
>> On 9/1/20 12:20 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 01/09/2020 à 08:25, Aneesh Kumar K.V a écrit :
On 9/1/20 8:52 AM, Anshuman Khandual wrote:
>
>
>
> There is
On 09/01/2020 01:25 PM, Aneesh Kumar K.V wrote:
> On 9/1/20 1:16 PM, Anshuman Khandual wrote:
>>
>>
>> On 09/01/2020 01:06 PM, Aneesh Kumar K.V wrote:
>>> On 9/1/20 1:02 PM, Anshuman Khandual wrote:
On 09/01/2020 11:51 AM, Aneesh Kumar K.V wrote:
> On 9/1/20 8:45 AM, Anshuman
allyesconfig
powerpc allmodconfig
x86_64 randconfig-a004-20200901
x86_64 randconfig-a006-20200901
x86_64 randconfig-a003-20200901
x86_64 randconfig-a005-20200901
x86_64 randconfig-a001-20200901
allmodconfig
x86_64 randconfig-a004-20200901
x86_64 randconfig-a006-20200901
x86_64 randconfig-a003-20200901
x86_64 randconfig-a005-20200901
x86_64 randconfig-a001-20200901
x86_64 randconfig-a002-20200901
i386
defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a004-20200901
Christophe Leroy writes:
> The following random segfault is observed from time to time with
> map_hugetlb selftest:
>
> root@localhost:~# ./map_hugetlb 1 19
> 524288 kB hugepages
> Mapping 1 Mbytes
> Segmentation fault
>
> [ 31.219972] map_hugetlb[365]: segfault (11) at 117 nip 77974f8c lr
> 7
I think $subject needs a typo update... vdso32...
On Tue, Sep 01, 2020 at 03:25:23PM -0700, Nick Desaulniers wrote:
> Rather than invoke the compiler as the driver, use the linker. That way
> we can check --orphan-handling=warn support correctly, as cc-ldoption
> was removed in
> commit 055efab312
On Thu, Jul 23, 2020 at 03:50:51PM +0530, Ravi Bangoria wrote:
> Patch #1, #2 and #3 enables p10 2nd DAWR feature for Book3S kvm guest. DAWR
> is a hypervisor resource and thus H_SET_MODE hcall is used to set/unset it.
> A new case H_SET_MODE_RESOURCE_SET_DAWR1 is introduced in H_SET_MODE hcall
> f
Rather than invoke the compiler as the driver, use the linker. That way
we can check --orphan-handling=warn support correctly, as cc-ldoption
was removed in
commit 055efab3120b ("kbuild: drop support for cc-ldoption").
Requires dropping the .got section. I couldn't find how it was used in
the vds
On Thu, Jul 23, 2020 at 03:50:53PM +0530, Ravi Bangoria wrote:
> kvm code assumes single DAWR everywhere. Add code to support 2nd DAWR.
> DAWR is a hypervisor resource and thus H_SET_MODE hcall is used to set/
> unset it. Introduce new case H_SET_MODE_RESOURCE_SET_DAWR1 for 2nd DAWR.
Is this the s
On Thu, Jul 23, 2020 at 03:50:52PM +0530, Ravi Bangoria wrote:
> Power10 is introducing second DAWR. Use real register names (with
> suffix 0) from ISA for current macros and variables used by kvm.
Most of this looks fine, but I think we should not change the existing
names in arch/powerpc/include
The pnv_phb->initialized flag is an odd beast. It was added back in 2012 in
commit db1266c85261 ("powerpc/powernv: Skip check on PE if necessary") to
allow devices to be enabled even if the device had not yet been assigned to
a PE. Allowing the device to be enabled before the PE is configured may
c
On Tue, Sep 01, 2020 at 04:40:16PM -0500, Li Yang wrote:
>
> Looks like the CAAM driver and dependent QBMAN driver doesn't support
> COMPILE_TEST yet. Are you trying to add the support for it?
Yes.
> I think this is a valid concern that if the parent structure doesn't
> meet certain alignment re
On Tue, 1 Sep 2020 at 14:09, Gautham R. Shenoy wrote:
>
> From: "Gautham R. Shenoy"
>
> commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
> of the Extended CEDE states advertised by the platform. The values
> ad
On Tue, Sep 1, 2020 at 4:50 PM Thomas Gleixner wrote:
>
> On Sun, Aug 30 2020 at 08:52, Andy Lutomirski wrote:
> >> > [RUN]SYSCALL
> >> > [FAIL]Initial args are wrong (nr=29, args=0 0 0 0 0 4289172732)
> >> > [RUN]SYSCALL
> >> > [OK]Args after SIGUSR1 are correct (ax = -514)
> >> >
It's not done anything for a long time. Save the percpu variable, and
emit a warning to remind users to not expect it to do anything.
This uses pr_warn_once instead of pr_warn_ratelimit as testing
'ppc64_cpu --smt=off' on a 24 core / 4 SMT system showed the warning to
be noisy, as the online/offli
On Sun, Aug 30 2020 at 08:52, Andy Lutomirski wrote:
>> > [RUN]SYSCALL
>> > [FAIL]Initial args are wrong (nr=29, args=0 0 0 0 0 4289172732)
>> > [RUN]SYSCALL
>> > [OK]Args after SIGUSR1 are correct (ax = -514)
>> > [OK]Child got SIGUSR1
>> > [RUN]Step again
>> > [OK]paus
On 2/09/20 11:29 am, Chris Packham wrote:
>
> On 1/09/20 6:14 pm, Nicholas Piggin wrote:
>> Excerpts from Chris Packham's message of September 1, 2020 11:25 am:
>>> On 1/09/20 12:33 am, Heiner Kallweit wrote:
On 30.08.2020 23:59, Chris Packham wrote:
> On 31/08/20 9:41 am, Heiner Kallweit
On 1/09/20 6:14 pm, Nicholas Piggin wrote:
> Excerpts from Chris Packham's message of September 1, 2020 11:25 am:
>> On 1/09/20 12:33 am, Heiner Kallweit wrote:
>>> On 30.08.2020 23:59, Chris Packham wrote:
On 31/08/20 9:41 am, Heiner Kallweit wrote:
> On 30.08.2020 23:00, Chris Packham w
On Mon, 2020-08-31 at 10:47 +1000, Alexey Kardashevskiy wrote:
> >
> > Maybe testing with host 64k pagesize and IOMMU 16MB pagesize in qemu
> > should be enough, is there any chance to get indirect mapping in qemu
> > like this? (DDW but with smaller DMA window available)
>
> You will have to ha
The default segment_boundary_mask was set to DMA_BIT_MAKS(32)
a decade ago by referencing SCSI/block subsystem, as a 32-bit
mask was good enough for most of the devices.
Now more and more drivers set dma_masks above DMA_BIT_MAKS(32)
while only a handful of them call dma_set_seg_boundary(). This
me
These two patches are to update default segment_boundary_mask.
PATCH-1 fixes overflow issues in callers of dma_get_seg_boundary.
Previous version was a series: https://lkml.org/lkml/2020/8/31/1026
Then PATCH-2 sets default segment_boundary_mask to ULONG_MAX.
Nicolin Chen (2):
dma-mapping: intr
We found that callers of dma_get_seg_boundary mostly do an ALIGN
with page mask and then do a page shift to get number of pages:
ALIGN(boundary + 1, 1 << shift) >> shift
However, the boundary might be as large as ULONG_MAX, which means
that a device has no specific boundary limit. So either "+
On Mon, Aug 31, 2020 at 8:57 PM Herbert Xu wrote:
>
> On Tue, Sep 01, 2020 at 01:50:38AM +, Leo Li wrote:
> >
> > Sorry for the late response. I missed this email previously.
> >
> > These structures are descriptors used by hardware, we cannot have _ANY_
> > padding from the compiler. The c
On Mon, 2020-08-31 at 13:48 +1000, Alexey Kardashevskiy wrote:
> > > > Well, I created this TCE_RPN_BITS = 52 because the previous mask was a
> > > > hardcoded 40-bit mask (0xfful), for hard-coded 12-bit (4k)
> > > > pagesize, and on PAPR+/LoPAR also defines TCE as having bits 0-51
> > > >
On Tue, Sep 01, 2020 at 11:27:36PM +1000, Michael Ellerman wrote:
> Nicolin Chen writes:
> > The boundary_size might be as large as ULONG_MAX, which means
> > that a device has no specific boundary limit. So either "+ 1"
> > or passing it to ALIGN() would potentially overflow.
> >
> > According to
Le 01/09/2020 à 19:25, Al Viro a écrit :
On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
10.92% dd [kernel.kallsyms] [k] iov_iter_zero
Interesting... Could you get an instruction-level profile inside
iov_iter_zero(),
along with the disassembly of that sucke
On Sat, Aug 29, 2020 at 11:24:06AM +0200, Christoph Hellwig wrote:
> On Thu, Aug 27, 2020 at 11:06:28AM -0700, Linus Torvalds wrote:
> > On Thu, Aug 27, 2020 at 8:00 AM Christoph Hellwig wrote:
> > >
> > > Once we can't manipulate the address limit, we also can't test what
> > > happens when the m
On Sat, Aug 29, 2020 at 11:24:06AM +0200, Christoph Hellwig wrote:
> On Thu, Aug 27, 2020 at 11:06:28AM -0700, Linus Torvalds wrote:
> > On Thu, Aug 27, 2020 at 8:00 AM Christoph Hellwig wrote:
> > >
> > > Once we can't manipulate the address limit, we also can't test what
> > > happens when the m
Le 01/09/2020 à 19:25, Al Viro a écrit :
On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
10.92% dd [kernel.kallsyms] [k] iov_iter_zero
Interesting... Could you get an instruction-level profile inside
iov_iter_zero(),
along with the disassembly of that sucke
On Tue, Sep 01, 2020 at 06:25:12PM +0100, Al Viro wrote:
> On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
>
> > 10.92% dd [kernel.kallsyms] [k] iov_iter_zero
>
> Interesting... Could you get an instruction-level profile inside
> iov_iter_zero(),
> along with the d
On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
> 10.92% dd [kernel.kallsyms] [k] iov_iter_zero
Interesting... Could you get an instruction-level profile inside
iov_iter_zero(),
along with the disassembly of that sucker?
Hi Christoph,
Le 27/08/2020 à 17:00, Christoph Hellwig a écrit :
Hi all,
this series removes the last set_fs() used to force a kernel address
space for the uaccess code in the kernel read/write/splice code, and then
stops implementing the address space overrides entirely for x86 and
powerpc.
T
> On 01-Sep-2020, at 6:16 PM, Michael Ellerman wrote:
>
> In commit 9b725a90a8f1 ("powerpc/64s: Disallow PROT_SAO in LPARs by
> default") PROT_SAO was disabled in guests/LPARs by default. So skip
> the test if we are running in a guest to avoid a spurious failure.
>
> Signed-off-by: Michael E
Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Michael Ellerman (powerpc)
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/mmu_context.h | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mm
From: "Gautham R. Shenoy"
commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
of the Extended CEDE states advertised by the platform. The values
advertised by the platform are in timebase ticks. However the cpuidle
Oliver O'Halloran writes:
> The pnv_phb->initialized flag is an odd beast. It was added back in 2012 in
> commit db1266c85261 ("powerpc/powernv: Skip check on PE if necessary") to
> allow devices to be enabled even if their PE assignments hadn't been
> completed yet. I can't think of any situatio
Nicolin Chen writes:
> The boundary_size might be as large as ULONG_MAX, which means
> that a device has no specific boundary limit. So either "+ 1"
> or passing it to ALIGN() would potentially overflow.
>
> According to kernel defines:
> #define ALIGN_MASK(x, mask) (((x) + (mask)) & ~(mask))
In commit 9b725a90a8f1 ("powerpc/64s: Disallow PROT_SAO in LPARs by
default") PROT_SAO was disabled in guests/LPARs by default. So skip
the test if we are running in a guest to avoid a spurious failure.
Signed-off-by: Michael Ellerman
---
tools/testing/selftests/powerpc/mm/prot_sao.c | 9 +++
Nicholas Piggin writes:
> Commit 0cef77c7798a7 ("powerpc/64s/radix: flush remote CPUs out of
> single-threaded mm_cpumask") added a mechanism to trim the mm_cpumask of
> a process under certain conditions. One of the assumptions is that
> mm_users would not be incremented via a reference outside t
Masahiro Yamada 於 2020年9月1日 週二 上午2:23寫道:
>
> The vdso linker script is preprocessed on demand.
> Adding it to 'targets' is enough to include the .cmd file.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/arm64/kernel/vdso/Makefile | 2 +-
> arch/arm64/kernel/vdso32/Makefile | 2 +-
> arc
On 09/01/2020 03:14 PM, Aneesh Kumar K.V wrote:
> The test is broken w.r.t page table update rules and results in kernel
> crash as below. Disable the support until we get the tests updated.
>
> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
> cpu 0x0: Vector: 700 (Program Check) a
On Tue, 01 Sep 2020 12:04:53 +0200,
Allen wrote:
>
> Takashi,
> > > > > These patches which I wasn't CCed on and which need their subject
> > > > > lines
> > > > > fixing :( . With the subject lines fixed I guess so so
> > >
> > > > Extremely sorry. I thought I had it covered. How would you like
> > > >
> > > > Commit 12cc923f1ccc ("tasklet: Introduce new initialization
> > > > API")' introduced a new tasklet initialization API. This series
> > > > converts all the scsi drivers to use the new tasklet_setup() API
> > >
> > > I've got to say I agree with Jens, this was a silly obfuscation:
>
Takashi,
> > > > These patches which I wasn't CCed on and which need their subject lines
> > > > fixing :( . With the subject lines fixed I guess so so
> >
> > > Extremely sorry. I thought I had it covered. How would you like it
> > > worded?
> >
> > ASoC:
>
> To be more exact, "ASoC:" prefix is f
On 09/01/2020 03:06 PM, Aneesh Kumar K.V wrote:
>
[ 17.080644] [ cut here ]
[ 17.081342] kernel BUG at mm/pgtable-generic.c:164!
[ 17.082091] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 17.082977] Modules linked in:
[ 17.08348
On 9/1/20 1:08 PM, Anshuman Khandual wrote:
On 09/01/2020 12:07 PM, Aneesh Kumar K.V wrote:
On 9/1/20 8:55 AM, Anshuman Khandual wrote:
On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
pte_clear_tests operate on an existing pte entry. Make sure that is not a none
pte entry.
Signed-off-by:
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable the support until we get the tests updated.
[ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
cpu 0x0: Vector: 700 (Program Check) at [c00c6d1e76c0]
pc: c009a5ec: assert_pte_loc
[ 17.080644] [ cut here ]
[ 17.081342] kernel BUG at mm/pgtable-generic.c:164!
[ 17.082091] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 17.082977] Modules linked in:
[ 17.083481] CPU: 79 PID: 1 Comm: swapper/0 Tainted: G W
5.9.0-rc2-00105-
On 09/01/2020 12:08 PM, Aneesh Kumar K.V wrote:
> On 9/1/20 9:11 AM, Anshuman Khandual wrote:
>>
>>
>> On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
>>> This will help in adding proper locks in a later patch
>>
>> It really makes sense to classify these tests here as static and dynamic.
>> Sta
On Tue, Sep 01, 2020 at 03:22:39AM +0900, Masahiro Yamada wrote:
> The vdso linker script is preprocessed on demand.
> Adding it to 'targets' is enough to include the .cmd file.
>
> Signed-off-by: Masahiro Yamada
For arm64:
Acked-by: Catalin Marinas
On 9/1/20 2:40 PM, Christophe Leroy wrote:
Le 01/09/2020 à 10:15, Christophe Leroy a écrit :
Le 01/09/2020 à 10:12, Aneesh Kumar K.V a écrit :
On 9/1/20 1:40 PM, Christophe Leroy wrote:
Le 01/09/2020 à 10:02, Aneesh Kumar K.V a écrit :
The test is broken w.r.t page table update rules an
On 09/01/2020 01:33 PM, Christophe Leroy wrote:
>
>
> Le 21/08/2020 à 10:51, Anshuman Khandual a écrit :
>>
>> On 08/19/2020 06:30 PM, Aneesh Kumar K.V wrote:
>>> This patch series includes fixes for debug_vm_pgtable test code so that
>>> they follow page table updates rules correctly. The fir
Le 01/09/2020 à 10:15, Christophe Leroy a écrit :
Le 01/09/2020 à 10:12, Aneesh Kumar K.V a écrit :
On 9/1/20 1:40 PM, Christophe Leroy wrote:
Le 01/09/2020 à 10:02, Aneesh Kumar K.V a écrit :
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable
On Tue, Sep 01, 2020 at 12:54:01AM -0700, Nicolin Chen wrote:
> Hi Christoph,
>
> On Tue, Sep 01, 2020 at 09:36:23AM +0200, Christoph Hellwig wrote:
> > I really don't like all the open coded smarts in the various drivers.
> > What do you think about a helper like the one in the untested patch
>
Le 01/09/2020 à 10:12, Aneesh Kumar K.V a écrit :
On 9/1/20 1:40 PM, Christophe Leroy wrote:
Le 01/09/2020 à 10:02, Aneesh Kumar K.V a écrit :
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable the support untill we get the tests updated.
Signe
On 9/1/20 1:40 PM, Christophe Leroy wrote:
Le 01/09/2020 à 10:02, Aneesh Kumar K.V a écrit :
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable the support untill we get the tests updated.
Signed-off-by: Aneesh Kumar K.V
Any Fixes: tag ?
---
Le 01/09/2020 à 10:02, Aneesh Kumar K.V a écrit :
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable the support untill we get the tests updated.
Signed-off-by: Aneesh Kumar K.V
Any Fixes: tag ?
---
arch/powerpc/Kconfig | 1 -
1 file change
Le 21/08/2020 à 10:51, Anshuman Khandual a écrit :
On 08/19/2020 06:30 PM, Aneesh Kumar K.V wrote:
This patch series includes fixes for debug_vm_pgtable test code so that
they follow page table updates rules correctly. The first two patches introduce
changes w.r.t ppc64. The patches are incl
The test is broken w.r.t page table update rules and results in kernel
crash as below. Disable the support untill we get the tests updated.
[ 21.083506] [ cut here ]
[ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
cpu 0x0: Vector: 700 (Program Check) at [c
Le 01/09/2020 à 08:30, Aneesh Kumar K.V a écrit :
I actually wanted to add #ifdef BROKEN. That test is completely broken.
Infact I would suggest to remove that test completely.
#ifdef will not be required here as there would be a stub definition
for hugetlb_advanced_tests() when CONFI
On 9/1/20 1:16 PM, Anshuman Khandual wrote:
On 09/01/2020 01:06 PM, Aneesh Kumar K.V wrote:
On 9/1/20 1:02 PM, Anshuman Khandual wrote:
On 09/01/2020 11:51 AM, Aneesh Kumar K.V wrote:
On 9/1/20 8:45 AM, Anshuman Khandual wrote:
On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
ppc64 use
Hi Christoph,
On Tue, Sep 01, 2020 at 09:36:23AM +0200, Christoph Hellwig wrote:
> I really don't like all the open coded smarts in the various drivers.
> What do you think about a helper like the one in the untested patch
A helper function will be actually better. I was thinking of
one yet not v
Le 01/09/2020 à 09:40, Aneesh Kumar K.V a écrit :
On 9/1/20 12:20 PM, Christophe Leroy wrote:
Le 01/09/2020 à 08:25, Aneesh Kumar K.V a écrit :
On 9/1/20 8:52 AM, Anshuman Khandual wrote:
There is a checkpatch.pl warning here.
WARNING: Possible unwrapped commit description (prefer a m
On 09/01/2020 01:06 PM, Aneesh Kumar K.V wrote:
> On 9/1/20 1:02 PM, Anshuman Khandual wrote:
>>
>>
>> On 09/01/2020 11:51 AM, Aneesh Kumar K.V wrote:
>>> On 9/1/20 8:45 AM, Anshuman Khandual wrote:
On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
> ppc64 use bit 62 to indicate
On 9/1/20 12:20 PM, Christophe Leroy wrote:
Le 01/09/2020 à 08:25, Aneesh Kumar K.V a écrit :
On 9/1/20 8:52 AM, Anshuman Khandual wrote:
There is a checkpatch.pl warning here.
WARNING: Possible unwrapped commit description (prefer a maximum 75
chars per line)
#7:
Architectures like ppc
On 09/01/2020 12:07 PM, Aneesh Kumar K.V wrote:
> On 9/1/20 8:55 AM, Anshuman Khandual wrote:
>>
>>
>> On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
>>> pte_clear_tests operate on an existing pte entry. Make sure that is not a
>>> none
>>> pte entry.
>>>
>>> Signed-off-by: Aneesh Kumar K.V
>
On 01.09.2020 04:52, Chris Packham wrote:
>
> On 1/09/20 12:33 am, Heiner Kallweit wrote:
>> On 30.08.2020 23:59, Chris Packham wrote:
>>> On 31/08/20 9:41 am, Heiner Kallweit wrote:
On 30.08.2020 23:00, Chris Packham wrote:
> On 31/08/20 12:30 am, Nicholas Piggin wrote:
>> Excerpts f
On 9/1/20 1:02 PM, Anshuman Khandual wrote:
On 09/01/2020 11:51 AM, Aneesh Kumar K.V wrote:
On 9/1/20 8:45 AM, Anshuman Khandual wrote:
On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
ppc64 use bit 62 to indicate a pte entry (_PAGE_PTE). Avoid setting that bit in
random value.
Signed-off-
I really don't like all the open coded smarts in the various drivers.
What do you think about a helper like the one in the untested patch
below (on top of your series). Also please include the original
segment boundary patch with the next resend so that the series has
the full context.
diff --git
low_sleep_handler() has an hardcoded restore of segment registers
that doesn't take KUAP and KUEP into account.
Use head_32's load_segment_registers() routine instead.
Signed-off-by: Christophe Leroy
Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access
Protection")
Fixes: 31ed2b
On 09/01/2020 11:51 AM, Aneesh Kumar K.V wrote:
> On 9/1/20 8:45 AM, Anshuman Khandual wrote:
>>
>>
>> On 08/27/2020 01:34 PM, Aneesh Kumar K.V wrote:
>>> ppc64 use bit 62 to indicate a pte entry (_PAGE_PTE). Avoid setting that
>>> bit in
>>> random value.
>>>
>>> Signed-off-by: Aneesh Kumar K.
Nicholas Piggin writes:
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/include/asm/mmu_context.h | 22 +++---
> 1 file changed, 7 insertions(+), 15 deletions(-)
1 - 100 of 103 matches
Mail list logo