On Tue, 2018-07-24 at 16:27 -0300, Murilo Opsfelder Araujo wrote:
> Hi, everyone.
>
> This series was inspired by the need to modernize and display more
> informative messages about unhandled signals.
>
> The "unhandled signal NN" is not very informative. We thought it would
> be helpful adding
Hi Paul,
Thanks for having tested it, I remove mips from my list.
Thanks again,
Alex
On 07/25/2018 02:34 AM, Paul Burton wrote:
Hi Alexandre,
On Thu, Jul 05, 2018 at 11:07:05AM +, Alexandre Ghiti wrote:
In order to reduce copy/paste of functions across architectures and then
make riscv
On 2018/7/25 0:10, Laurent Dufour wrote:
>
> On 24/07/2018 16:26, zhong jiang wrote:
>> On 2018/5/17 19:06, Laurent Dufour wrote:
>>> From: Peter Zijlstra
>>>
>>> Provide infrastructure to do a speculative fault (not holding
>>> mmap_sem).
>>>
>>> The not holding of mmap_sem means we can race agai
At the moment the kernel does not expect dynamic windows to ever start
at zero on a PCI bus as PAPR requires the hypervisor to create a 32bit
default window which starts from zero and the pseries kernel only
creates additional windows.
However PAPR permits removing the default window and creating
It is quite common for a device to support more than 32bit but less than
64bit for DMA, for example, GPUs often support 42..50bits. However
the pseries platform only allows huge DMA window (the one which allows
the use of more than 2GB of DMA space) for 64bit-capable devices mostly
because:
1. we
I am trying to pass through a 3D controller:
[0302]: NVIDIA Corporation GV100GL [Tesla V100 SXM2] [10de:1db1] (rev a1)
which has a quite unique feature as coherent memory directly accessible
from a POWER9 CPU via an NVLink2 transport.
So in addition to passing a PCI device + accompanying NPU de
We might have memory@ nodes with "linux,usable-memory" set to zero
(for example, to replicate powernv's behaviour for GPU coherent memory)
which means that the memory needs an extra initialization but since
it can be used afterwards, the pseries platform will try mapping it
for DMA so the DMA windo
The page table fragment allocator uses the main page refcount racily
with respect to speculative references. A customer observed a BUG due
to page table page refcount underflow in the fragment allocator. This
can be caused by the fragment allocator set_page_count stomping on a
speculative reference
The kernel page table caches are tied to init_mm, so there is no
more need for them after userspace is finished.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/mmu_context_book3s64.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_book3s64
On 25/07/2018 11:04, zhong jiang wrote:
> On 2018/7/25 0:10, Laurent Dufour wrote:
>>
>> On 24/07/2018 16:26, zhong jiang wrote:
>>> On 2018/5/17 19:06, Laurent Dufour wrote:
From: Peter Zijlstra
Provide infrastructure to do a speculative fault (not holding
mmap_sem).
>
On 2018/7/25 18:44, Laurent Dufour wrote:
>
> On 25/07/2018 11:04, zhong jiang wrote:
>> On 2018/7/25 0:10, Laurent Dufour wrote:
>>> On 24/07/2018 16:26, zhong jiang wrote:
On 2018/5/17 19:06, Laurent Dufour wrote:
> From: Peter Zijlstra
>
> Provide infrastructure to do a specula
On Wed, Jul 25, 2018 at 04:12:02PM +1000, Sam Bobroff wrote:
> From: Sam Bobroff
>
> It is not currently possible to create the full number of possible
> VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
> threads per core than it's core stride (or "VSMT mode"). This is
> becau
Hello Nicholas,
On Sat, Jul 21, 2018 at 02:29:24PM +1000, Nicholas Piggin wrote:
> Reimplement Book3S idle code to C, in the powernv platform code.
> Assembly stubs are used to save and restore the stack frame and
> non-volatile GPRs before going to idle, but these are small and
> mostly agnostic
Hi Gautham,
Thanks for the review, I also missed one or two things from you last
one, but I haven't forgotten them.
On Wed, 25 Jul 2018 16:56:45 +0530
Gautham R Shenoy wrote:
> Hello Nicholas,
>
> On Sat, Jul 21, 2018 at 02:29:24PM +1000, Nicholas Piggin wrote:
> > Reimplement Book3S idle cod
Nicholas Piggin writes:
> The kernel page table caches are tied to init_mm, so there is no
> more need for them after userspace is finished.
>
The commit message could be improved with reference to active_mm.
something like?
destroy_context get called when we drop the last reference for mm whi
On 09/07/18 12:18, Nipun Gupta wrote:
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
I guess this is about as neat as it can get;
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm-smmu.
On 09/07/18 12:18, Nipun Gupta wrote:
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
Reviewed-by:
On 09/07/18 12:18, Nipun Gupta wrote:
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
No more nits from me :)
Acked-by: Robin Murphy
Si
tools/perf/tests/.gitignore:
LLVM byte-codes, uncompressed
On Wed, Jul 25, 2018 at 2:55 AM, Andrew Morton
wrote:
> On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches wrote:
>
>> On Tue, 2018-07-24 at 14:00 -0700, Andrew Morton wrote:
>> > On Tue, 24 Jul 2018 13:13:25 +0200
On Mon, Jul 23, 2018 at 07:46:09AM +0530, Anshuman Khandual wrote:
> There is a redundant definition of virtio_has_iommu_quirk in the tools
> directory (tools/virtio/linux/virtio_config.h) which does not seem to
> be used any where. I guess that can be removed without problem.
It's there just to m
When the mm is being torn down there will be a full PID flush so
there is no need to flush the TLB on page size changes.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/tlb.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/
The first 3 patches in this series are some generic mm changes I
would like to make, including a possible fix which may(?) be needed
for ARM64. Other than the bugfix, these first 3 patches should not
change anything so hopefully they aren't too controversial.
The powerpc patch is also there for re
There is no need to call this from tlb_flush_mmu_tlbonly, it
logically belongs with tlb_flush_mmu_free. This allows some
code consolidation with a subsequent fix.
Signed-off-by: Nicholas Piggin
---
mm/memory.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/memory.c
The generic tlb_end_vma does not call invalidate_range mmu notifier,
and it resets resets the mmu_gather range, which means the notifier
won't be called on part of the range in case of an unmap that spans
multiple vmas.
ARM64 seems to be the only arch I could see that has notifiers and
uses the ge
powerpc wants to de-couple page table caching structure flushes
from TLB flushes, which will make it possible to have mmu_gather
with freed page table pages but no TLB range. These must be sent
to tlb_flush, so allow the arch to specify when mmu_gather with
empty ranges should have tlb_flush called
The mmu_gather APIs keep track of the invalidated address range, and
the generic page table freeing accessors expand the invalidated range
to cover the addresses corresponding to the page tables even if there
are no ptes and therefore no TLB entries to invalidate. This is done
for architectures tha
Nicholas Piggin writes:
> When the mm is being torn down there will be a full PID flush so
> there is no need to flush the TLB on page size changes.
and that tlb flush is PID flush since tlb->fulmm is set? So this avoids
multiple PID tlb flush.
Reviewed-by: Aneesh Kumar K.V
>
> Signed-off-by
Hi Murilo,
LGTM.
Just a comment:
On 07/24/2018 04:27 PM, Murilo Opsfelder Araujo wrote:
This adds a human-readable name in the unhandled signal message.
Before this patch, a page fault looked like:
Jul 11 16:04:11 localhost kernel: pandafault[6303]: unhandled signal 11 at
1
On Wed, 2018-07-25 at 15:12 +0200, Arnd Bergmann wrote:
> tools/perf/tests/.gitignore:
> LLVM byte-codes, uncompressed
> On Wed, Jul 25, 2018 at 2:55 AM, Andrew Morton
> wrote:
> > On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches wrote:
> >
> > > On Tue, 2018-07-24 at 1
Murilo Opsfelder Araujo a écrit :
Modify logic of show_signal_msg() to return early, if possible. Replace
printk_ratelimited() by printk() and a default rate limit burst to limit
displaying unhandled signals messages.
Can you explain more the benefits of this change ?
Christophe
Signed-o
Murilo Opsfelder Araujo a écrit :
This adds a human-readable name in the unhandled signal message.
Before this patch, a page fault looked like:
Jul 11 16:04:11 localhost kernel: pandafault[6303]: unhandled
signal 11 at 17d0 nip 161c lr
7fff93c55100 code 2 i
See below.
On 07/23/2018 10:54 AM, John Allen wrote:
> On Fri, Jul 13, 2018 at 03:18:01PM -0500, Michael Bringmann wrote:
>> migration/dlpar: This patch adds function dlpar_queue_action()
>> which will queued up information about a CPU/Memory 'readd'
>> operation according to resource type, action
See below.
On 07/23/2018 12:51 PM, Nathan Fontenot wrote:
> On 07/13/2018 03:18 PM, Michael Bringmann wrote:
>> migration/dlpar: This patch adds function dlpar_queue_action()
>> which will queued up information about a CPU/Memory 'readd'
>> operation according to resource type, action code, and DR
Murilo Opsfelder Araujo a écrit :
Move show_instructions() declaration to arch/powerpc/include/asm/stacktrace.h
and include asm/stracktrace.h in arch/powerpc/kernel/process.c,
which contains
the implementation.
Modify show_instructions() not to call __kernel_text_address(), allowing
userspa
On Tue, Jul 24, 2018 at 02:43:09PM +0530, Shilpasri G Bhat wrote:
> OPAL firmware provides the facility for some groups of sensors to be
> enabled/disabled at runtime to give the user the option of using the
> system resources for collecting these sensors or not.
>
> For example, on POWER9 systems
With this patch we use 0x8000UL (_PAGE_PRESENT) to indicate a valid
pgd/pud/pmd entry. We also switch the p**_present() to look at this bit.
With pmd_present, we have a special case. We need to make sure we consider a
pmd marked invalid during THP split as present. Right now we clear t
This make hugetlb directory pointer similar to other page able entries. A hugepd
entry is identified by lack of _PAGE_PTE bit set and directory size stored in
HUGEPD_SHIFT_MASK. We update that to also look at _PAGE_PRESENT
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/ha
Update few code paths to check for pmd_large.
set_pmd_at:
We want to use this to store swap pte at pmd level. For swap ptes we don't want
to set H_PAGE_THP_HUGE. Hence check for pmd_large in set_pmd_at. This remove
the false WARN_ON when using this with swap pmd entry.
pmd_page:
We don't really u
Make sure we are operating on THP and hugetlb entries in the respective hash
fault handling routines.
No functional change in this patch. If we walked the table wrongly before, we
will retry the access.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/hugepage-hash64.c| 6 ++
arch/po
We need to make sure pmd_trans_huge returns false for a pmd migration entry.
We mark the migration entry by clearing the _PAGE_PRESENT bit. We keep the
_PAGE_PTE bit set to indicate a leaf page table entry. Hence we need to make
sure we check for pmd_present() so that pmd_trans_huge won't return tr
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 8
arch/powerpc/platforms/Kconfig.cputype | 1 +
2 files changed, 9 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 8b80
Hi All,
Under heavy stress and constant memory hot add/remove, I have observed
the following loop to occasionally loop infinitely:
mm/memory_hotplug.c:__offline_pages
repeat:
/* start memory hot removal */
ret = -EINTR;
if (signal_pending(current))
goto fai
Hi, Mikey.
On Wed, Jul 25, 2018 at 05:00:21PM +1000, Michael Neuling wrote:
> On Tue, 2018-07-24 at 16:27 -0300, Murilo Opsfelder Araujo wrote:
> > Hi, everyone.
> >
> > This series was inspired by the need to modernize and display more
> > informative messages about unhandled signals.
> >
> >
Hi, Gustavo.
On Wed, Jul 25, 2018 at 12:19:00PM -0300, Gustavo Romero wrote:
> Hi Murilo,
>
> LGTM.
>
> Just a comment:
>
> On 07/24/2018 04:27 PM, Murilo Opsfelder Araujo wrote:
> > This adds a human-readable name in the unhandled signal message.
> >
> > Before this patch, a page fault looked
On Wed 25-07-18 13:11:15, John Allen wrote:
[...]
> Does a failure in do_migrate_range indicate that the range is unmigratable
> and the loop in __offline_pages should terminate and goto failed_removal? Or
> should we allow a certain number of retrys before we
> give up on migrating the range?
Unf
Hi, Christophe.
On Wed, Jul 25, 2018 at 05:49:27PM +0200, LEROY Christophe wrote:
> Murilo Opsfelder Araujo a écrit :
>
> > This adds a human-readable name in the unhandled signal message.
> >
> > Before this patch, a page fault looked like:
> >
> > Jul 11 16:04:11 localhost kernel: pandafaul
Hi, Christophe.
On Wed, Jul 25, 2018 at 05:42:28PM +0200, LEROY Christophe wrote:
> Murilo Opsfelder Araujo a écrit :
>
> > Modify logic of show_signal_msg() to return early, if possible. Replace
> > printk_ratelimited() by printk() and a default rate limit burst to limit
> > displaying unhandl
From: Krzysztof Kozlowski
Date: Mon, 23 Jul 2018 18:20:20 +0200
> Use generic kernel CRC32 implementation because it:
> 1. Should be faster (uses lookup tables),
> 2. Removes duplicated CRC generation code,
> 3. Uses well-proven algorithm instead of coding it one more time.
>
> Suggested-by: Eri
Hi, Christophe.
On Wed, Jul 25, 2018 at 06:01:34PM +0200, LEROY Christophe wrote:
> Murilo Opsfelder Araujo a écrit :
>
> > Move show_instructions() declaration to
> > arch/powerpc/include/asm/stacktrace.h
> > and include asm/stracktrace.h in arch/powerpc/kernel/process.c, which
> > contains
>
Pasemi arch code finds the root of the PCI-e bus by searching the
device-tree for a node called 'pxp'. But the root bus has a
compatible property of 'pasemi,rootbus' so search for that instead.
Signed-off-by: Darren Stevens
---
This works on the Amigaone X1000, I don't know if this method of
fi
Pasemi code still uses printk(KERN_ERR/KERN_WARN ... change these to
pr_err(, pr_warn(... to match other powerpc arch code.
No functional changes.
Signed-off-by: Darren Stevens
---
arch/powerpc/platforms/pasemi/dma_lib.c |6 ++--
arch/powerpc/platforms/pasemi/gpio_mdio.c |2 +-
arch/p
> > Should we prefix every line with the PID to avoid this?
>
> That's possible. An alternative would be prefixing each line with the
> process name and its PID, as in the first line. For example:
>
> pandafault[10758]: segfault (11) at 17d0 nip 161c
> lr 7fff
Murilo Opsfelder Araujo writes:
> On Wed, Jul 25, 2018 at 05:00:21PM +1000, Michael Neuling wrote:
>> On Tue, 2018-07-24 at 16:27 -0300, Murilo Opsfelder Araujo wrote:
>> > This series was inspired by the need to modernize and display more
>> > informative messages about unhandled signals.
...
>>
On Wed, Jul 25, 2018 at 04:12:02PM +1000, Sam Bobroff wrote:
> From: Sam Bobroff
>
> It is not currently possible to create the full number of possible
> VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
> threads per core than it's core stride (or "VSMT mode"). This is
> becau
Hi everyone,
This is the result of the build for all arches tackled in this series
rebased on 4.18-rc6:
arm:
versatile_defconfig: without huge page OK
keystone_defconfig: with huge page OK
arm64:
defconfig: with huge page OK
ia64:
generic_defconfig: with huge pa
Commit 1e175d2 ("KVM: PPC: Book3S HV: Pack VCORE IDs to access full
VCPU ID space", 2018-07-25) added code that uses kvm->arch.emul_smt_mode
before any VCPUs are created. However, userspace can change
kvm->arch.emul_smt_mode at any time up until the first VCPU is created.
Hence it is (theoreticall
Commit 1e175d2 ("KVM: PPC: Book3S HV: Pack VCORE IDs to access full
VCPU ID space", 2018-07-25) allowed use of VCPU IDs up to
KVM_MAX_VCPU_ID on POWER9 in all guest SMT modes and guest emulated
hardware SMT modes. However, with the current definition of
KVM_MAX_VCPU_ID, a guest SMT mode of 1 and a
57 matches
Mail list logo
