[Sorry for a really late response]
On Mon 27-05-19 13:11:42, David Hildenbrand wrote:
> By converting start and size to page granularity, we actually ignore
> unaligned parts within a page instead of properly bailing out with an
> error.
I do not expect any code path would ever provide an unalign
On Mon 27-05-19 13:11:43, David Hildenbrand wrote:
> ZONE_DEVICE is not yet supported, fail if an altmap is passed, so we
> don't forget arch_add_memory()/arch_remove_memory() when unlocking
> support.
Why do we need this? Sure ZONE_DEVICE is not supported for s390 and so
might be the case for oth
On Mon 27-05-19 13:11:44, David Hildenbrand wrote:
> Will come in handy when wanting to handle errors after
> arch_add_memory().
I do not understand this. Why do you add a code for something that is
not possible on this HW (based on the comment - is it still valid btw?)
> Cc: Martin Schwidefsky
On Mon 27-05-19 13:11:46, David Hildenbrand wrote:
> We'll rework hotplug_memory_register() shortly, so it no longer consumes
> pass a section.
>
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Signed-off-by: David Hildenbrand
Acked-by: Michal Hocko
> ---
> drivers/base/memory.c | 15 +
On Mon 27-05-19 13:11:47, David Hildenbrand wrote:
> We want to improve error handling while adding memory by allowing
> to use arch_remove_memory() and __remove_pages() even if
> CONFIG_MEMORY_HOTREMOVE is not set to e.g., implement something like:
>
> arch_add_memory()
> rc = do_some
On Mon 27-05-19 13:11:48, David Hildenbrand wrote:
> Only memory to be added to the buddy and to be onlined/offlined by
> user space using /sys/devices/system/memory/... needs (and should have!)
> memory block devices.
>
> Factor out creation of memory block devices. Create all devices after
> arc
On Mon 27-05-19 13:11:49, David Hildenbrand wrote:
> No longer needed, the callers of arch_add_memory() can handle this
> manually.
>
> Cc: Andrew Morton
> Cc: David Hildenbrand
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Pavel Tatashin
> Cc: Wei Yang
> Cc: Joonsoo Kim
> Cc: Qian Cai
> C
On Mon 27-05-19 13:11:50, David Hildenbrand wrote:
> Let's factor out removing of memory block devices, which is only
> necessary for memory added via add_memory() and friends that created
> memory block devices. Remove the devices before calling
> arch_remove_memory().
>
> This finishes factoring
Steven Rostedt wrote:
On Thu, 27 Jun 2019 20:58:20 +0530
"Naveen N. Rao" wrote:
> But interesting, I don't see a synchronize_rcu_tasks() call
> there.
We felt we don't need it in this case. We patch the branch to ftrace
with a nop first. Other cpus should see that first. But, now that I
On Mon 27-05-19 13:11:51, David Hildenbrand wrote:
> We really don't want anything during memory hotunplug to fail.
> We always pass a valid memory block device, that check can go. Avoid
> allocating memory and eventually failing. As we are always called under
> lock, we can use a static piece of m
Alexey Kardashevskiy writes:
> On 29/06/2019 18:03, Christoph Hellwig wrote:
>> Use the dma_get_mask helper from dma-mapping.h instead.
>>
>> Signed-off-by: Christoph Hellwig
>
> Reviewed-by: Alexey Kardashevskiy
I'll add to the change log "because they are functionally identical."
cheers
On Mon 27-05-19 13:11:52, David Hildenbrand wrote:
> The parameter is unused, so let's drop it. Memory removal paths should
> never care about zones. This is the job of memory offlining and will
> require more refactorings.
>
> Reviewed-by: Dan Williams
> Signed-off-by: David Hildenbrand
Acked-
On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote:
> Yeah, we do not allow to offline multi zone (node) ranges so the current
> code seems to be over engineered.
>
> Anyway, I am wondering why do we have to strictly check for already
> removed nodes links. Is the sysfs code going to com
On Mon, Jul 01, 2019 at 04:40:24PM +1000, Nicholas Piggin wrote:
> walk_page_range() is going to be allowed to walk page tables other than
> those of user space. For this it needs to know when it has reached a
> 'leaf' entry in the page tables. This information will be provided by the
> p?d_large()
On 01/07/2019 07:40, Nicholas Piggin wrote:
> walk_page_range() is going to be allowed to walk page tables other than
> those of user space. For this it needs to know when it has reached a
> 'leaf' entry in the page tables. This information will be provided by the
> p?d_large() functions/macros.
>
On 07/01/2019 12:10 PM, Nicholas Piggin wrote:
> vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
> Whether or not a vmap is huge depends on the architecture details,
> alignments, boot options, etc., which the caller can not be expected
> to know. Therefore HUGE_VMAP is a re
On 01/07/2019 10:27, Will Deacon wrote:
> Hi Nick,
>
> On Sun, Jun 23, 2019 at 07:44:44PM +1000, Nicholas Piggin wrote:
>> walk_page_range() is going to be allowed to walk page tables other than
>> those of user space. For this it needs to know when it has reached a
>> 'leaf' entry in the page tab
On Mon 01-07-19 11:36:44, Oscar Salvador wrote:
> On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote:
> > Yeah, we do not allow to offline multi zone (node) ranges so the current
> > code seems to be over engineered.
> >
> > Anyway, I am wondering why do we have to strictly check for alr
Hi Nick,
On Sun, Jun 23, 2019 at 07:44:44PM +1000, Nicholas Piggin wrote:
> walk_page_range() is going to be allowed to walk page tables other than
> those of user space. For this it needs to know when it has reached a
> 'leaf' entry in the page tables. This information will be provided by the
> p
On Mon, Jul 01, 2019 at 11:03:51AM +0100, Steven Price wrote:
> On 01/07/2019 10:27, Will Deacon wrote:
> > On Sun, Jun 23, 2019 at 07:44:44PM +1000, Nicholas Piggin wrote:
> >> walk_page_range() is going to be allowed to walk page tables other than
> >> those of user space. For this it needs to kn
"Oliver O'Halloran" writes:
> On Sat, Jun 29, 2019 at 5:39 PM Aneesh Kumar K.V
> wrote:
>>
>> Allocation from altmap area can fail based on vmemmap page size used. Add
>> kernel
>> info message to indicate the failure. That allows the user to identify
>> whether they
>> are really using persis
On Mon 01-07-19 09:43:06, Michal Hocko wrote:
> On Mon 27-05-19 13:11:43, David Hildenbrand wrote:
> > ZONE_DEVICE is not yet supported, fail if an altmap is passed, so we
> > don't forget arch_add_memory()/arch_remove_memory() when unlocking
> > support.
>
> Why do we need this? Sure ZONE_DEVICE
On Mon 01-07-19 09:45:03, Michal Hocko wrote:
> On Mon 27-05-19 13:11:44, David Hildenbrand wrote:
> > Will come in handy when wanting to handle errors after
> > arch_add_memory().
>
> I do not understand this. Why do you add a code for something that is
> not possible on this HW (based on the com
On Mon 27-05-19 13:11:45, David Hildenbrand wrote:
> A proper arch_remove_memory() implementation is on its way, which also
> cleanly removes page tables in arch_add_memory() in case something goes
> wrong.
>
> As we want to use arch_remove_memory() in case something goes wrong
> during memory hot
On Mon 01-07-19 10:01:41, Michal Hocko wrote:
> On Mon 27-05-19 13:11:47, David Hildenbrand wrote:
> > We want to improve error handling while adding memory by allowing
> > to use arch_remove_memory() and __remove_pages() even if
> > CONFIG_MEMORY_HOTREMOVE is not set to e.g., implement something l
Hi Sven,
On Tue, 25 Jun 2019 20:54:34 +0200
Sven Schnelle wrote:
> Hi List,
>
> i recently started working on kexec for PA-RISC. While doing so, i figured
> that powerpc already has support for reading ELF images inside of the Kernel.
> My first attempt was to steal the source code and modify i
Good evening from Singapore,
Can I compile Linux Kernel 5.2-rc7 for PowerPC on Intel/AMD x86 hardware, for
example, AMD Ryzen 9 3950X, with 16 CPU cores and 32 threads?
Is it called cross-compiling?
Thank you.
-BEGIN EMAIL SIGNATURE-
The Gospel for all Targeted Individuals (TIs):
[Th
Architectures like powerpc use different address range to map ioremap
and vmalloc range. The memunmap() check used by the nvdimm layer was
wrongly using is_vmalloc_addr() to check for ioremap range which fails for
ppc64. This result in ppc64 not freeing the ioremap mapping. The side effect
of this
Add the ppc_capabilities ELF note to the powerpc kernel binary. It is a
bitmap that can be used to advertise kernel capabilities to userland.
This patch also defines PPCCAP_ULTRAVISOR_BIT as being the bit zero.
Suggested-by: Paul Mackerras
Signed-off-by: Claudio Carvalho
---
arch/powerpc/kerne
On 6/15/19 4:36 AM, Paul Mackerras wrote:
> On Thu, Jun 06, 2019 at 02:36:08PM -0300, Claudio Carvalho wrote:
>> This feature tells if the ultravisor firmware is available to handle
>> ucalls.
> Everything in this patch that depends on CONFIG_PPC_UV should just
> depend on CONFIG_PPC_POWERNV inst
On Thu, Jun 27, 2019 at 10:58:40PM -0300, Thiago Jung Bauermann wrote:
>
> Michael S. Tsirkin writes:
>
> > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote:
> >>
> >>
> >> Michael S. Tsirkin writes:
> >>
> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauerman
Allocation from altmap area can fail based on vmemmap page size used. Add kernel
info message to indicate the failure. That allows the user to identify whether
they
are really using persistent memory reserved space for per-page metadata.
The message looks like:
[ 136.587212] altmap block allocat
With hash translation and 4K PAGE_SIZE config, we need to make sure we don't
use 64K page size for vmemmap.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/hash_utils.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c
b/ar
We use mmu_vmemmap_psize to find the page size for mapping the vmmemap area.
With radix translation, we are suboptimally setting this value to PAGE_SIZE.
We do check for 2M page size support and update mmu_vmemap_psize to use
hugepage size but we suboptimally reset the value to PAGE_SIZE in
radix_
If we fail to parse the associativity array we should default to
NUMA_NO_NODE instead of NODE 0. Rest of the code fallback to the
right default if we find the numa node value NUMA_NO_NODE.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/numa.c | 10 ++
1 file changed, 6 insertions(+)
If we boot with numa=off, we need to make sure we return NUMA_NO_NODE when
looking up associativity details of resources. Without this, we hit crash
like below
BUG: Unable to handle kernel data access at 0x408
Faulting instruction address: 0xc8f31704
cpu 0x1b: Vector: 380 (Data SLB
If we fail to parse min_common_depth from device tree we boot with
numa disabled. Reflect the same by updating numa_enabled variable
to false. Also, switch all min_common_depth failure check to
if (!numa_enabled) check.
This helps us to avoid checking for both in different code paths.
Signed-off-
__kernel_virt_size is not used anymore.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 7dede2e34b70..a3eab10f5a2
On Thu, 2019-06-27 at 23:19 -0300, Thiago Jung Bauermann wrote:
> Hello,
>
> This version is essentially identical to the last one.
>
> It is only a rebase on top of today's linux-integrity/next-queued-testing,
> prompted by conflicts with Prakhar Srivastava's patches to measure the
> kernel comm
+++ Thiago Jung Bauermann [27/06/19 23:19 -0300]:
IMA will use the module_signature format for append signatures, so export
the relevant definitions and factor out the code which verifies that the
appended signature trailer is valid.
Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can
On Mon, Jun 24, 2019 at 9:23 AM Thomas Gleixner wrote:
>
> On Mon, 24 Jun 2019, Christoph Hellwig wrote:
> >
> > asm-generic/ptrace.h is a little weird in that it doesn't actually
> > implement any functionality, but it provided multiple layers of macros
> > that just implement trivial inline func
Le 01/07/2019 à 15:39, Turritopsis Dohrnii Teo En Ming a écrit :
Good evening from Singapore,
Good evening afternoon from Paris,
Can I compile Linux Kernel 5.2-rc7 for PowerPC on Intel/AMD x86 hardware, for
example, AMD Ryzen 9 3950X, with 16 CPU cores and 32 threads?
Yes you can
Is
"Aneesh Kumar K.V" writes:
> I guess we should have here.
>
> modified arch/powerpc/mm/numa.c
> @@ -416,12 +416,11 @@ static int of_get_assoc_arrays(struct assoc_arrays
> *aa)
> static int of_drconf_to_nid_single(struct drmem_lmb *lmb)
> {
> struct assoc_arrays aa = { .arrays = NULL }
Hi Michael,
On Fri, Jun 28, 2019 at 12:04:11PM +1000, Michael Ellerman wrote:
> Sven Schnelle writes:
> https://github.com/linuxppc/wiki/wiki/Booting-with-Qemu
>
> But I'm not sure where you get a version of kexec that uses kexec_file().
kexec-tools HEAD supports it, so that's not a problem.
Hi Philipp,
On Mon, Jul 01, 2019 at 02:31:20PM +0200, Philipp Rudo wrote:
> Sven Schnelle wrote:
>
> > I'm attaching the patch to this Mail. What do you think about that change?
> > s390 also uses ELF files, and (maybe?) could also switch to this
> > implementation.
> > But i don't know anythin
Hi Michael,
Nathan Lynch writes:
> The protocol for suspending or migrating an LPAR requires all present
> processor threads to enter H_JOIN. So if we have threads offline, we
> have to temporarily bring them up. This can race with administrator
> actions such as SMT state changes. As of dfd718a2
On Mon, 1 Jul 2019 19:10:38 +0530 "Aneesh Kumar K.V"
wrote:
> Architectures like powerpc use different address range to map ioremap
> and vmalloc range. The memunmap() check used by the nvdimm layer was
> wrongly using is_vmalloc_addr() to check for ioremap range which fails for
> ppc64. This r
Nathan Lynch writes:
> Hi Michael,
>
> Nathan Lynch writes:
>> The protocol for suspending or migrating an LPAR requires all present
>> processor threads to enter H_JOIN. So if we have threads offline, we
>> have to temporarily bring them up. This can race with administrator
>> actions such as SM
Christophe Leroy writes:
> Le 01/07/2019 à 15:39, Turritopsis Dohrnii Teo En Ming a écrit :
>> Good evening from Singapore,
>
> Good evening afternoon from Paris,
>
>>
>> Can I compile Linux Kernel 5.2-rc7 for PowerPC on Intel/AMD x86 hardware,
>> for example, AMD Ryzen 9 3950X, with 16 CPU core
On 7/1/19 10:12 PM, Nathan Lynch wrote:
"Aneesh Kumar K.V" writes:
I guess we should have here.
modified arch/powerpc/mm/numa.c
@@ -416,12 +416,11 @@ static int of_get_assoc_arrays(struct assoc_arrays
*aa)
static int of_drconf_to_nid_single(struct drmem_lmb *lmb)
{
struct assoc
Steven Price's on July 1, 2019 7:57 pm:
> On 01/07/2019 07:40, Nicholas Piggin wrote:
>> walk_page_range() is going to be allowed to walk page tables other than
>> those of user space. For this it needs to know when it has reached a
>> 'leaf' entry in the page tables. This information will be provi
Will Deacon's on July 1, 2019 8:15 pm:
> On Mon, Jul 01, 2019 at 11:03:51AM +0100, Steven Price wrote:
>> On 01/07/2019 10:27, Will Deacon wrote:
>> > On Sun, Jun 23, 2019 at 07:44:44PM +1000, Nicholas Piggin wrote:
>> >> walk_page_range() is going to be allowed to walk page tables other than
>> >>
Andrew Morton writes:
> On Mon, 1 Jul 2019 19:10:38 +0530 "Aneesh Kumar K.V"
> wrote:
>
>> Architectures like powerpc use different address range to map ioremap
>> and vmalloc range. The memunmap() check used by the nvdimm layer was
>> wrongly using is_vmalloc_addr() to check for ioremap range
From: Reza Arbab
The function doesn't get used outside this file, so make it static.
Signed-off-by: Reza Arbab
---
arch/powerpc/kernel/mce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index b18df633eae9..e78c4f1
From: Reza Arbab
If a notifier returns NOTIFY_STOP, consider the MCE handled, just as we
do when machine_check_early() returns 1.
Signed-off-by: Reza Arbab
---
arch/powerpc/include/asm/asm-prototypes.h | 2 +-
arch/powerpc/include/asm/mce.h| 3 +-
arch/powerpc/kernel/exceptions-6
From: Reza Arbab
If the instruction causing a UE has an exception table entry with fixup
address, save it in the machine_check_event struct.
If a machine check notifier callback returns NOTIFY_STOP to indicate it
has handled the error, set nip to continue execution from the fixup
address.
Signe
From: Balbir Singh
The pmem infrastructure uses memcpy_mcsafe in the pmem
layer so as to convert machine check exceptions into
a return value on failure in case a machine check
exception is encountered during the memcpy.
This patch largely borrows from the copyuser_power7
logic and does not add
From: Reza Arbab
Add an mce notifier intended to service memcpy_mcsafe().
The notifier uses this heuristic; if a UE occurs when accessing device
memory, and the faulting instruction had a fixup entry, the callback
will return NOTIFY_STOP.
This causes the notification mechanism to consider the M
From: Reza Arbab
Signed-off-by: Reza Arbab
---
arch/powerpc/kernel/exceptions-64s.S | 6 ++
arch/powerpc/kernel/mce.c| 2 ++
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index c83e38a403fd..311f1392a2
memcpy_mcsafe currently return -EFAULT on a machine check exception, change
it to return the remaining bytes that needs to be copied, so that machine
check safe copy_to_user can maintain the same behavior as copy_to_user.
Signed-off-by: Santosh Sivaraj
---
arch/powerpc/lib/memcpy_mcsafe_64.S | 1
Use memcpy_mcsafe() implementation to define copy_to_user_mcsafe()
Signed-off-by: Santosh Sivaraj
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/uaccess.h | 12
2 files changed, 13 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
inde
From: Reza Arbab
Testing my memcpy_mcsafe() work in progress with an injected UE, I get
an error like this immediately after the function returns:
BUG: Unable to handle kernel data access at 0x7fff84dec8f8
Faulting instruction address: 0xc008009c00b0
Oops: Kernel access of bad area, sig: 11
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 = 6 bytes
|=.
|v--|--v-
ptrace-hwbreak.c selftest is logically broken. On powerpc, when
watchpoint is created with ptrace, signals are generated before
executing the instruction and user has to manually singlestep
the instruction with watchpoint disabled, which selftest never
does and thus it keeps on getting the signal a
Radix boot looks like this:
-
phys_mem_size = 0x2
dcache_bsize = 0x80
icache_bsize = 0x80
cpu_features = 0xc06f8f5fb1a7
possible= 0xfbffcf5fb1a7
always = 0x0003800081a1
cpu_user_
Santosh Sivaraj's on July 2, 2019 3:19 pm:
> From: Reza Arbab
>
> Signed-off-by: Reza Arbab
> ---
> arch/powerpc/kernel/exceptions-64s.S | 6 ++
> arch/powerpc/kernel/mce.c| 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S
> b/arch
Santosh Sivaraj's on July 2, 2019 3:19 pm:
> From: Reza Arbab
>
> Testing my memcpy_mcsafe() work in progress with an injected UE, I get
> an error like this immediately after the function returns:
>
> BUG: Unable to handle kernel data access at 0x7fff84dec8f8
> Faulting instruction address: 0xc
On 19/6/19 11:28 pm, Frederic Barrat wrote:
Protect the PHB's list of PE. Probably not needed as long as it was
populated during PHB creation, but it feels right and will become
required once we can add/remove opencapi devices on hotplug.
Signed-off-by: Frederic Barrat
Reviewed-by: Andrew Don
During a memcpy from a pmem device, if a machine check exception is
generated we end up in a panic. In case of fsdax read, this should
only result in a -EIO. Avoid MCE by implementing memcpy_mcsafe.
Before this patch series:
```
bash-4.4# mount -o dax /dev/pmem0 /mnt/pmem/
[ 7621.714094] Disablin
From: Balbir Singh
The code currently assumes PAGE_SHIFT as the shift value of
the pfn, this works correctly (mostly) for user space pages,
but the correct thing to do is
1. Extract the shift value returned via the pte-walk API's
2. Use the shift value to access the instruction address.
Note, t
From: Reza Arbab
Signed-off-by: Reza Arbab
---
arch/powerpc/include/asm/asm-prototypes.h | 1 +
arch/powerpc/include/asm/mce.h| 4
arch/powerpc/kernel/exceptions-64s.S | 4
arch/powerpc/kernel/mce.c | 22 ++
4 files changed, 31 i
From: Reza Arbab
Move the call site of machine_check_ue_event() slightly later in the MCE
codepath. No functional change intended--this is prep for a later patch
to conditionally skip the call.
Signed-off-by: Reza Arbab
---
arch/powerpc/kernel/mce.c | 5 -
1 file changed, 4 insertions(+),
/arch/powerpc/kernel/head_64.S?h=next-20190701&id=9c4e4c90ec24652921e31e9551fcaedc26eec86d
Will be cherry-picked by stable once merged into 4.3 I guess.
Christophe
FATAL: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
scripts/Makefile.modpos
Michael Ellerman writes:
> Daniel Axtens writes:
>> While reviewing lockdown patches, I discovered that we still enable
>> /dev/port (CONFIG_DEVPORT) in skiroot.
>>
>> We don't need it. Deselect CONFIG_DEVPORT for skiroot.
>
> Why don't we need it? :)
I should have explained this better :)
/de
74 matches
Mail list logo
