The __memblock_alloc_base() function tries to allocate a memory up to the
limit specified by its max_addr parameter. Depending on the value of this
parameter, the __memblock_alloc_base() can is replaced with the appropriate
memblock_phys_alloc*() variant.
Signed-off-by: Mike Rapoport
Acked-by:
As all the memblock_alloc*() users are now checking the return value and
panic() in case of error, the panic() call can be removed from the core
memblock allocator, namely memblock_alloc_try_nid().
Signed-off-by: Mike Rapoport
---
mm/memblock.c | 15 +--
1 file changed, 5
On Fri, Jan 18, 2019 at 5:20 PM Arnd Bergmann wrote:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both. We also
> have some architectures that require passing IPC_64 in the flags, and
> others that set it
These functions are not used outside memblock. Make them static.
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 4
mm/memblock.c| 4 ++--
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index
On Mon, Jan 21, 2019 at 9:06 AM Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The
On Fri, Jan 18, 2019 at 5:21 PM Arnd Bergmann wrote:
> This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
> abd use the _time32 system calls from the former compat layer instead
> of the system calls that take __kernel_timespec and similar arguments.
>
> The temporary
Add panic() calls if memblock_alloc*() returns NULL.
Most of the changes are simply addition of
if(!ptr)
panic();
statements after the calls to memblock_alloc*() variants.
Exceptions are pcpu_populate_pte() and kernel_map_range() that were
slightly refactored to
Le 15/01/2019 à 18:23, Andrey Ryabinin a écrit :
On 1/12/19 2:16 PM, Christophe Leroy wrote:
+KASAN_SANITIZE_early_32.o := n
+KASAN_SANITIZE_cputable.o := n
+KASAN_SANITIZE_prom_init.o := n
+
Usually it's also good idea to disable branch profiling - define
DISABLE_BRANCH_PROFILING
On 14.01.19 13:58, David Hildenbrand wrote:
> Nothing major changed since the last version. I would be happy about
> additional ACKs. If there are no further comments, can this go via the
> mm-tree in one chunk?
For the time being, I will not add further patches to this series (as
discussed in
Add check for the return value of memblock_alloc*() functions and call
panic() in case of error.
The panic message repeats the one used by panicing memblock allocators with
adjustment of parameters to include only relevant ones.
The replacement was mostly automated with semantic patches like the
Add the PCIe EP mode support for layerscape platform.
Signed-off-by: Xiaowei Bao
Reviewed-by: Minghuan Lian
Reviewed-by: Zhiqiang Hou
---
v2:
- remove the EP mode check function.
v3:
- modif the return value when enter default case.
v4:
- no change.
v5:
- no change.
On Fri, Jan 18, 2019 at 05:18:23PM +0100, Arnd Bergmann wrote:
> These are all for ignoring the lack of obsolete system calls,
> which have been marked the same way in scripts/checksyscall.sh,
> so these can be removed.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/mips/include/asm/unistd.h |
The memblock_alloc_base() function tries to allocate a memory up to the
limit specified by its max_addr parameter and panics if the allocation
fails. Replace its usage with memblock_phys_alloc_range() and make the
callers check the return value and panic in case of error.
Signed-off-by: Mike
Currently, memblock has several internal functions with overlapping
functionality. They all call memblock_find_in_range_node() to find free
memory and then reserve the allocated range and mark it with kmemleak.
However, there is difference in the allocation constraints and in fallback
strategies.
This patch replaces most #ifdef mess by IS_ENABLED() in 8xx_mmu.c
This has the advantage of allowing syntax verification at compile
time regardless of selected options.
Signed-off-by: Christophe Leroy
---
v2: left CONFIG_BDI_SWITCH change aside as it goes away in another patch
On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both. We also
> have some architectures that require passing IPC_64 in the flags, and
> others that
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
mm/percpu.c | 73
Hi Russell,
On Sat, Jan 19, 2019 at 3:29 PM Russell King - ARM Linux admin
wrote:
> On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > > > On Fri, Jan 18,
Add the documentation for the Device Tree binding for the layerscape PCIe
controller with EP mode.
Signed-off-by: Xiaowei Bao
Reviewed-by: Minghuan Lian
Reviewed-by: Zhiqiang Hou
---
v2:
- Add the SoC specific compatibles.
v3:
- modify the commit message.
v4:
- no change.
v5:
- no change.
There is no reason to re-read each time the pointer at
location 0xf0 as it is fixed and known.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mmu.h | 2 ++
arch/powerpc/kernel/head_32.S | 5 ++---
arch/powerpc/kernel/head_40x.S | 5 ++---
arch/powerpc/kernel/head_8xx.S | 1 +
As all the memblock allocation functions return NULL in case of error
rather than panic(), the duplicates with _nopanic suffix can be removed.
Signed-off-by: Mike Rapoport
Acked-by: Greg Kroah-Hartman
---
arch/arc/kernel/unwind.c | 3 +--
arch/sh/mm/init.c | 2 +-
On Fri, Jan 18, 2019 at 5:20 PM Arnd Bergmann wrote:
> Most architectures define system call numbers for the rseq and pkey system
> calls, even when they don't support the features, and perhaps never will.
>
> Only a few architectures are missing these, so just define them anyway
> for
On Fri, Jan 18, 2019 at 5:20 PM Arnd Bergmann wrote:
> Most architectures have assigned a numbers for the seccomp syscall
> even when they do not implement it.
>
> m68k is an exception here, so for consistency lets add the number.
> Unless CONFIG_SECCOMP is implemented, the system call just
>
On Fri, Jan 18, 2019 at 5:21 PM Arnd Bergmann wrote:
> The time, stime, utime, utimes, and futimesat system calls are only
> used on older architectures, and we do not provide y2038 safe variants
> of them, as they are replaced by clock_gettime64, clock_settime64,
> and utimensat_time64.
>
>
Le 21/01/2019 à 10:24, Dmitry Vyukov a écrit :
On Mon, Jan 21, 2019 at 9:37 AM Christophe Leroy
wrote:
Le 21/01/2019 à 09:30, Dmitry Vyukov a écrit :
On Mon, Jan 21, 2019 at 8:17 AM Christophe Leroy
wrote:
Le 15/01/2019 à 18:23, Andrey Ryabinin a écrit :
On 1/12/19 2:16 PM,
Add the PCIE EP node in dts for ls1046a.
Signed-off-by: Xiaowei Bao
Reviewed-by: Minghuan Lian
Reviewed-by: Zhiqiang Hou
---
v2:
- Add the SoC specific compatibles.
v3:
- no change
v4:
- no change
v5:
- change the OB win number due to the RM update.
memblock_alloc() already clears the allocated memory, no point in doing it
twice.
Signed-off-by: Mike Rapoport
Acked-by: Geert Uytterhoeven # m68k
---
arch/c6x/mm/init.c | 1 -
arch/h8300/mm/init.c| 1 -
arch/ia64/kernel/mca.c | 2 --
arch/m68k/mm/mcfmmu.c | 1 -
Add panic() calls if memblock_alloc*() returns NULL.
Most of the changes are simply addition of
if(!ptr)
panic();
statements after the calls to memblock_alloc*() variants.
Exceptions are create_mem_map_page_table() and ia64_log_init() that were
slightly refactored to
The last parameter of memblock_alloc_from() is the lower limit for the
memory allocation. When it is 0, the call is equivalent to
memblock_alloc().
Signed-off-by: Mike Rapoport
Acked-by: Paul Burton # MIPS part
---
arch/alpha/kernel/core_cia.c | 2 +-
arch/alpha/kernel/pci_iommu.c | 4 ++--
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
Hi Arnd,
On Fri, Jan 18, 2019 at 5:21 PM Arnd Bergmann wrote:
> This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
> abd use the _time32 system calls from the former compat layer instead
and
> of the system calls that take __kernel_timespec and similar arguments.
Add the layerscape EP device support in pci_endpoint_test driver.
Signed-off-by: Xiaowei Bao
Reviewed-by: Minghuan Lian
Reviewed-by: Zhiqiang Hou
Reviewed-by: Greg KH
---
v2:
- no change
v3:
- no change
v4:
- delate the comments.
v5:
- no change.
drivers/misc/pci_endpoint_test.c |1
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
init/main.c | 26
Le 21/01/2019 à 09:30, Dmitry Vyukov a écrit :
On Mon, Jan 21, 2019 at 8:17 AM Christophe Leroy
wrote:
Le 15/01/2019 à 18:23, Andrey Ryabinin a écrit :
On 1/12/19 2:16 PM, Christophe Leroy wrote:
+KASAN_SANITIZE_early_32.o := n
+KASAN_SANITIZE_cputable.o := n
On Fri, Jan 18, 2019 at 5:25 PM Arnd Bergmann wrote:
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This
Some debug setup like CONFIG_KASAN generate huge
kernels with text size over the 8M limit.
This patch maps a second 8M page when _einittext is over 8M.
Signed-off-by: Christophe Leroy
---
v2: Using IS_ENABLED() instead of #ifdef in 8xx_mmu.c
arch/powerpc/kernel/head_8xx.S | 27
On Fri, Jan 18, 2019 at 05:18:20PM +0100, Arnd Bergmann wrote:
> Most architectures define system call numbers for the rseq and pkey system
> calls, even when they don't support the features, and perhaps never will.
>
> Only a few architectures are missing these, so just define them anyway
> for
On Fri, Jan 18, 2019 at 05:18:35PM +0100, Arnd Bergmann wrote:
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
On Mon, Jan 21, 2019 at 05:44:57PM +0800, Xiaowei Bao wrote:
> Add the documentation for the Device Tree binding for the layerscape PCIe
> controller with EP mode.
>
> Signed-off-by: Xiaowei Bao
> Reviewed-by: Minghuan Lian
> Reviewed-by: Zhiqiang Hou
> ---
> v2:
> - Add the SoC specific
Can you test this patch?
>From e511e79af9a314854848ea8fda9dfa6d7e07c5e4 Mon Sep 17 00:00:00 2001
From: "Aneesh Kumar K.V"
Date: Mon, 21 Jan 2019 16:43:17 +0530
Subject: [PATCH] arch/powerpc/radix: Fix kernel crash with mremap
With support for split pmd lock, we use pmd page pmd_huge_pte
Hello Christoph,
Thanks for your reply. I successfully compiled a kernel (uImage) for the
X5000 from your Git 'powerpc-dma.6-debug' (both patches) today.
It detects the SATA hard disk drive and boots without any problems. I
will test the first patch in next days.
Thanks for your help,
On Fri, Jan 18, 2019 at 05:18:34PM +0100, Arnd Bergmann wrote:
> The time, stime, utime, utimes, and futimesat system calls are only
> used on older architectures, and we do not provide y2038 safe variants
> of them, as they are replaced by clock_gettime64, clock_settime64,
> and utimensat_time64.
Hi Xiaowei,
On 21/01/19 3:14 PM, Xiaowei Bao wrote:
> Add the PCIe EP mode support for layerscape platform.
>
> Signed-off-by: Xiaowei Bao
> Reviewed-by: Minghuan Lian
> Reviewed-by: Zhiqiang Hou
This patch looks good to me, except for using epc->features which I've tried to
get rid of in
On Fri, Jan 18, 2019 at 11:46:42AM -0800, Nicolin Chen wrote:
> On Fri, Jan 18, 2019 at 01:16:24PM +, Viorel Suman wrote:
> > > > 1. Moved "dais" node from machine driver DTS node to device driver
> > > > DTS node
> > > > as suggested by Rob.
> > > That was not what I suggested. You still
On Thu, Jan 17, 2019 at 07:02:43PM +0900, Masahiro Yamada wrote:
> In Kbuild, if_changed and friends must have FORCE as a prerequisite.
>
> Hence, $(filter-out FORCE,$^) or $(filter-out $(PHONY),$^) is a common
> pattern to get the names of all the prerequisites except phony targets.
>
> Add
On Fri, Jan 18, 2019 at 5:25 PM Arnd Bergmann wrote:
>
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This
On Mon, Jan 21, 2019 at 9:56 AM Geert Uytterhoeven wrote:
>
> Note that all architectures that already define pkey syscalls, list
> pkey_mprotect first.
It's easy enough to change, so I've reordered them for consistency now.
> Regardless, for m68k:
> Acked-by: Geert Uytterhoeven
Thanks,
On Mon, Jan 21, 2019 at 6:08 PM Arnd Bergmann wrote:
> On Mon, Jan 21, 2019 at 9:19 AM Geert Uytterhoeven
> wrote:
> > Regardless, I'm wondering what to do with the holes marked "room for
> > arch specific calls".
> > When is a syscall really arch-specific, and can it be added there, and
> >
On Mon, Jan 21, 2019 at 9:19 AM Geert Uytterhoeven wrote:
> On Sat, Jan 19, 2019 at 3:29 PM Russell King - ARM Linux admin
> wrote:
> > On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> > > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> > > > On Fri, Jan 18, 2019 at
On Mon, Jan 21, 2019 at 10:04:06AM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant
On Mon, Jan 07, 2019 at 07:43:17PM +0100, Cédric Le Goater wrote:
> This is the basic framework for the new KVM device supporting the XIVE
> native exploitation mode. The user interface exposes a new capability
> and a new KVM device to be used by QEMU.
[snip]
> @@ -1039,7 +1039,10 @@ static int
Add the documentation for the Device Tree binding for the layerscape PCIe
controller with EP mode.
Signed-off-by: Xiaowei Bao
Reviewed-by: Minghuan Lian
Reviewed-by: Zhiqiang Hou
Reviewed-by: Rob Herring
---
v2:
- Add the SoC specific compatibles.
v3:
- modify the commit message.
v4:
- no
The system reset interrupt may use HSRR registers (e.g., to call in to
OPAL), but code that uses HSRR registers is not required to clear
MSR[RI] by convention.
Rather than introduce that requirement, have system reset interrupt
save HSRRs before they might be used.
Signed-off-by: Nicholas Piggin
HV interrupts that use HSRR registers do not clear MSR[RI], but
NMI entry code is not recoverable early on due to both using HSPRG
for a scratch register.
This bug means that a system reset or machine check can cause silent
data corruption (due to loss of r13 register) if it hits in a small
On Mon, Jan 07, 2019 at 07:43:12PM +0100, Cédric Le Goater wrote:
> Hello,
>
> On the POWER9 processor, the XIVE interrupt controller can control
> interrupt sources using MMIO to trigger events, to EOI or to turn off
> the sources. Priority management and interrupt acknowledgment is also
>
On Mon, Jan 07, 2019 at 08:10:05PM +0100, Cédric Le Goater wrote:
> Clear the ESB pages from the VMA of the IRQ being pass through to the
> guest and let the fault handler repopulate the VMA when the ESB pages
> are accessed for an EOI or for a trigger.
Why do we want to do this?
I don't see any
On Mon, Jan 07, 2019 at 07:43:15PM +0100, Cédric Le Goater wrote:
> We will have different KVM devices for interrupts, one for the
> XICS-over-XIVE mode and one for the XIVE native exploitation
> mode. Let's add some checks to make sure we are not mixing the
> interfaces in KVM.
>
>
Add the layerscape EP device support in pci_endpoint_test driver.
Signed-off-by: Xiaowei Bao
Reviewed-by: Minghuan Lian
Reviewed-by: Zhiqiang Hou
Reviewed-by: Greg KH
---
v2:
- no change
v3:
- no change
v4:
- delate the comments.
v5:
- no change.
v6:
- no change.
Add the PCIe EP mode support for layerscape platform.
Signed-off-by: Xiaowei Bao
Reviewed-by: Minghuan Lian
Reviewed-by: Zhiqiang Hou
Reviewed-by: Kishon Vijay Abraham I
---
depends on: https://patchwork.kernel.org/project/linux-pci/list/?series=66177
v2:
- remove the EP mode check
Handlers for interrupts that set DAR / DSISR, set MSR[RI] before those
SPRs are read and saved away.
If a d-side machine check hits in this window, DAR / DSISR will be
clobbered silently, leading to random behaviour.
Fix this by saving those registers before MSR[RI] is set.
Signed-off-by:
The subsequent patch needs to change data interrupts (those that set
DAR / DSISR) in order to cope with a recoverability bug with MCE
interrupts.
This patch prepares for the fix by removing a couple of layers of
macro indirection from the interrupt handlers, and also makes the
0x300 interrupt out
This series fixes several similar but unrelated bugs with NMIs
clobbering live registers and getting away with it because
MSR[RI] is set. Pretty rare bugs, but serious silent corruption
consequences.
For the most part these can be observed and tested quite easily
with the mambo simulator except
On Mon, Jan 07, 2019 at 08:10:06PM +0100, Cédric Le Goater wrote:
> This will be used to destroy the KVM XICS or XIVE device when the
> sPAPR machine is reseted. When the VM boots, the CAS negotiation
> process will determine which interrupt mode to use and the appropriate
> KVM device will then
On Mon, Jan 07, 2019 at 07:43:18PM +0100, Cédric Le Goater wrote:
> This will let the guest create a memory mapping to expose the ESB MMIO
> regions used to control the interrupt sources, to trigger events, to
> EOI or to turn off the sources.
>
> Signed-off-by: Cédric Le Goater
> ---
>
On Mon, Jan 07, 2019 at 07:43:23PM +0100, Cédric Le Goater wrote:
> The XIVE native exploitation mode specs define a set of Hypervisor
> calls to configure the sources and the event queues :
>
> - H_INT_GET_SOURCE_INFO
>
>used to obtain the address of the MMIO page of the Event State
>
Add the PCIE EP node in dts for ls1046a.
Signed-off-by: Xiaowei Bao
Reviewed-by: Minghuan Lian
Reviewed-by: Zhiqiang Hou
Reviewed-by: Rob Herring
---
v2:
- Add the SoC specific compatibles.
v3:
- no change
v4:
- no change
v5:
- change the OB win number due to the RM update.
v6:
- no
On Mon, Jan 07, 2019 at 07:43:20PM +0100, Cédric Le Goater wrote:
> The ESB MMIO region controls the interrupt sources of the guest. QEMU
> will query an fd (GET_ESB_FD ioctl) and map this region at a specific
> address for the guest to use. The guest will obtain this information
> using the
I wanted to test the virtex440-ml507 qemu machine and found that the dtb
for it was not builded.
All powerpc DTB are only built when CONFIG_OF_ALL_DTBS is set which depend on
COMPILE_TEST.
This patchs adds build of virtex dtbs depending on
CONFIG_XILINX_VIRTEX440_GENERIC_BOARD option.
Hi,
Current memblock API is quite extensive and, which is more annoying,
duplicated. Except the low-level functions that allow searching for a free
memory region and marking it as reserved, memblock provides three (well,
two and a half) sets of functions to allocate memory. There are several
The allocation of the page tables memory in openrics uses
memblock_phys_alloc() and then converts the returned physical address to
virtual one. Use memblock_alloc_raw() and add a panic() if the allocation
fails.
Signed-off-by: Mike Rapoport
---
arch/openrisc/mm/init.c | 5 -
1 file changed,
From: Christophe Leroy
Since only the virtual address of allocated blocks is used,
lets use functions returning directly virtual address.
Those functions have the advantage of also zeroing the block.
[ MR:
- updated error message in alloc_stack() to be more verbose
- convereted several
The calls to memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ANYWHERE) and
memblock_phys_alloc(size, align) are equivalent as both try to allocate
'size' bytes with 'align' alignment anywhere in the memory and panic if hte
allocation fails.
The conversion is done using the following semantic
The memblock_alloc_base_nid() is a oneliner wrapper for
memblock_alloc_range_nid() without any side effect.
Replace it's usage by the direct calls to memblock_alloc_range_nid().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 3 ---
mm/memblock.c| 15 ---
2
Rename memblock_alloc_range() to memblock_phys_alloc_range() to emphasize
that it returns a physical address.
While on it, remove the 'enum memblock_flags' parameter from this function
as its only user anyway sets it to MEMBLOCK_NONE, which is the default for
the most of memblock allocations.
The memblock_phys_alloc_try_nid() function tries to allocate memory from
the requested node and then falls back to allocation from any node in the
system. The memblock_alloc_base() fallback used by this function panics if
the allocation fails.
Replace the memblock_alloc_base() fallback with the
Make the memblock_phys_alloc() function an inline wrapper for
memblock_phys_alloc_range() and update the memblock_phys_alloc() callers to
check the returned value and panic in case of error.
Signed-off-by: Mike Rapoport
---
arch/arm/mm/init.c | 4
arch/arm64/mm/mmu.c
76 matches
Mail list logo
