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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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:
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:
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
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
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
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
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
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
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 randconfig-a004
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
>
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
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
>
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
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
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
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
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
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
>
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
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]
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
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
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
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
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:
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
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
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
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
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
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
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
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.
> 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
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
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
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
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 +-
>
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)
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
> > > >
> > > > 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
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:
[
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:
[ 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
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.
>>
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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.
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
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:
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
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(-)
Le 01/09/2020 à 09:19, Michal Suchánek a écrit :
Hello,
can you add Fixes: ?
That's a commit which is still in powerpc/next-test.
My intention was to provide something that Michael can squash/fixup into
the culprit commit.
Christophe
Thanks
Michal
On Tue, Sep 01, 2020 at 05:28:57AM
Hello,
can you add Fixes: ?
Thanks
Michal
On Tue, Sep 01, 2020 at 05:28:57AM +, Christophe Leroy wrote:
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/include/asm/vdso/gettimeofday.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
Looks like since the start of this series we've grown new code to
use kernel_write on sysctl files based on boot parameters. The good
news is that this just means I need to resurrect the sysctl series
as all that work was done already.
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 ppc64 use deposited page table while updating
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.
Static are the ones that test via page table entry values modification
1 - 100 of 106 matches
Mail list logo
