With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will be one
W+X page at boot by default. This can be tested with
CONFIG_PPC_PTDUMP=y and CONFIG_PPC_DEBUG_WX=y set, and checking the
kernel log during boot.
powerpc doesn't implement its own alloc() for kprobes like other
architectures d
The set_memory_{ro/rw/nx/x}() functions are required for STRICT_MODULE_RWX,
and are generally useful primitives to have. This implementation is
designed to be completely generic across powerpc's many MMUs.
It's possible that this could be optimised to be faster for specific
MMUs, but the focus is
Very rudimentary, just
echo 1 > [debugfs]/check_wx_pages
and check the kernel log. Useful for testing strict module RWX.
Updated the Kconfig entry to reflect this.
Also fixed a typo.
Signed-off-by: Russell Currey
---
arch/powerpc/Kconfig.debug | 6 --
arch/powerpc/mm/ptdum
skiroot_defconfig is the only powerpc defconfig with STRICT_KERNEL_RWX
enabled, and if you want memory protection for kernel text you'd want it
for modules too, so enable STRICT_MODULE_RWX there.
Signed-off-by: Russell Currey
---
arch/powerpc/configs/skiroot_defconfig | 1 +
1 file changed, 1 in
To enable strict module RWX on powerpc, set:
CONFIG_STRICT_MODULE_RWX=y
You should also have CONFIG_STRICT_KERNEL_RWX=y set to have any real
security benefit.
ARCH_HAS_STRICT_MODULE_RWX is set to require ARCH_HAS_STRICT_KERNEL_RWX.
This is due to a quirk in arch/Kconfig and arch/powerpc/Kcon
v4 cover letter:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
v3 cover letter:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
Changes since v4:
[1/5]: Addressed review comments from Michael Ellerman (thanks!)
[4/5]: make ARCH_
On 29.10.19 14:18, Richard Henderson wrote:
> On 10/29/19 8:26 AM, Harald Freudenberger wrote:
>> Fine with me, Thanks, reviewed, build and tested.
>> You may add my reviewed-by: Harald Freudenberger
>> However, will this go into the kernel tree via crypto or s390 subsystem ?
> That's an excellent
Le 30/10/2019 à 08:31, Russell Currey a écrit :
The set_memory_{ro/rw/nx/x}() functions are required for STRICT_MODULE_RWX,
and are generally useful primitives to have. This implementation is
designed to be completely generic across powerpc's many MMUs.
It's possible that this could be optim
On Wed, Oct 30, 2019 at 03:20:35AM +, S.j. Wang wrote:
> Hi
>
> >
> > On Tue, Oct 29, 2019 at 05:17:09PM +0800, Shengjiu Wang wrote:
> > > There are two asrc module in imx8qm, each module has different clock
> > > configuration, and the DMA type is EDMA.
> > >
> > > So in this patch, we defin
Le 30/10/2019 à 08:31, Russell Currey a écrit :
v4 cover letter:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
v3 cover letter:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
Changes since v4:
[1/5]: Addressed review comments from
When passing the return value of dev_to_node() to cpumask_of_node()
without checking if the device's node id is NUMA_NO_NODE, there is
global-out-of-bounds detected by KASAN.
>From the discussion [1], NUMA_NO_NODE really means no node affinity,
which also means all cpus should be usable. So the cp
On Wed, Oct 30, 2019 at 05:34:28PM +0800, Yunsheng Lin wrote:
> When passing the return value of dev_to_node() to cpumask_of_node()
> without checking if the device's node id is NUMA_NO_NODE, there is
> global-out-of-bounds detected by KASAN.
>
> From the discussion [1], NUMA_NO_NODE really means
On Wed 30-10-19 17:34:28, Yunsheng Lin wrote:
> When passing the return value of dev_to_node() to cpumask_of_node()
> without checking if the device's node id is NUMA_NO_NODE, there is
> global-out-of-bounds detected by KASAN.
>
> >From the discussion [1], NUMA_NO_NODE really means no node affinit
On Wed 30-10-19 11:14:49, Peter Zijlstra wrote:
> On Wed, Oct 30, 2019 at 05:34:28PM +0800, Yunsheng Lin wrote:
> > When passing the return value of dev_to_node() to cpumask_of_node()
> > without checking if the device's node id is NUMA_NO_NODE, there is
> > global-out-of-bounds detected by KASAN.
Le 25/10/2019 à 14:40, Rasmus Villemoes a écrit :
The local qe_ic.h header is only used by qe_ic.c, so merge its
contents into the .c file. This is preparation for moving the driver
to drivers/irqchip/. It also avoids confusion between this header and
the one at include/soc/fsl/qe/qe_ic.h, whi
On Wed, Oct 30, 2019 at 11:22:29AM +0100, Michal Hocko wrote:
> On Wed 30-10-19 11:14:49, Peter Zijlstra wrote:
> > On Wed, Oct 30, 2019 at 05:34:28PM +0800, Yunsheng Lin wrote:
> > > When passing the return value of dev_to_node() to cpumask_of_node()
> > > without checking if the device's node id
Hi Kyle,
KyleMahlkuch writes:
> From: Kyle Mahlkuch
>
> During kexec some adapters hit an EEH since they are not properly
> shut down in the radeon_pci_shutdown() function. Adding
> radeon_suspend_kms() fixes this issue.
> Enabled only on PPC because this patch causes issues on some other
> boar
Le 25/10/2019 à 14:40, Rasmus Villemoes a écrit :
These functions are only ever called through a function pointer, and
therefore it makes no sense for them to be "static inline" - gcc has
no choice but to emit a copy in each translation unit that takes the
address of one of these (currently va
Le 25/10/2019 à 14:40, Rasmus Villemoes a écrit :
The qe_ic_cascade_{low,high}_mpic functions are now used as handlers
both when the interrupt parent is mpic as well as ipic, so remove the
_mpic suffix.
Here you are modifying code that you drop in patch 14. That's pointless.
You should perf
Le 25/10/2019 à 14:40, Rasmus Villemoes a écrit :
Now that the references from arch/powerpc/ are gone, these are only
referenced from inside qe_ic.c, so make them static.
Why do that in two steps ?
I think patch 9 could remain until here, and then you could squash patch
9 and patch 17 toget
Le 25/10/2019 à 14:40, Rasmus Villemoes a écrit :
Currently, QUICC_ENGINE depends on PPC32, so this in itself does not
change anything. In order to allow removing the PPC32 dependency from
QUICC_ENGINE and avoid allmodconfig build failures, add this explicit
dependency.
Signed-off-by: Rasmus
Le 25/10/2019 à 14:40, Rasmus Villemoes a écrit :
Currently SERIAL_QE depends on QUICC_ENGINE, which in turn depends on
PPC32, so this doesn't add any extra dependency. However, the QUICC
Engine IP block also exists on some arm boards, so this serves as
preparation for removing the PPC32 depen
As part of the uapi we export a lot of PT_xx defines for each register
in struct pt_regs. These are expressed as an index from gpr[0], in
units of unsigned long.
Currently there's nothing tying the values of those defines to the
actual layout of the struct.
But we *don't* want to change the uapi
Le 30/10/2019 à 12:12, Michael Ellerman a écrit :
As part of the uapi we export a lot of PT_xx defines for each register
in struct pt_regs. These are expressed as an index from gpr[0], in
units of unsigned long.
Currently there's nothing tying the values of those defines to the
actual layout
On Wed 30-10-19 11:28:00, Peter Zijlstra wrote:
> On Wed, Oct 30, 2019 at 11:22:29AM +0100, Michal Hocko wrote:
> > On Wed 30-10-19 11:14:49, Peter Zijlstra wrote:
> > > On Wed, Oct 30, 2019 at 05:34:28PM +0800, Yunsheng Lin wrote:
> > > > When passing the return value of dev_to_node() to cpumask_o
Richard Henderson writes:
> We cannot use the pointer output without validating the
> success of the random read.
You _can_, but you must not.
> Signed-off-by: Richard Henderson
> ---
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> ---
> arch/powerpc/include/asm/
In order to support the two asrc modules in imx8qm, we need to
add compatible string "fsl,imx8qm-asrc0" and "fsl,imx8qm-asrc1"
Signed-off-by: Shengjiu Wang
---
Documentation/devicetree/bindings/sound/fsl,asrc.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation
There are two asrc module in imx8qm, each module has different
clock configuration, and the DMA type is EDMA.
So in this patch, we define the new clocks, refine the clock map,
and include struct fsl_asrc_soc_data for different soc usage.
The EDMA channel is fixed with each dma request, one dma re
Segher Boessenkool writes:
> On Thu, Oct 24, 2019 at 11:47:30AM +1100, Michael Ellerman wrote:
>> Some of our scripts are passed $objdump and then call it as
>> "$objdump". This doesn't work if it contains spaces because we're
>> using ccache, for example you get errors such as:
>>
>> ./arch/po
On Tue, 2019-05-28 at 08:16:14 UTC, Michael Ellerman wrote:
> We have several "defconfigs" that are not actually full defconfigs
> they are just a base set of options which are then merged with other
> fragments to produce a working defconfig.
>
> The most obvious example is corenet_basic_defconfi
On Mon, 2019-07-15 at 18:32:32 UTC, Qian Cai wrote:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warnings,
>
> arch/powerpc/kernel/setup_64.c
On Thu, 2019-08-01 at 04:58:55 UTC, Andrew Donnellan wrote:
> Add a debug config fragment that we can use to put useful debug options
> into.
>
> Currently we only define a target for powernv[_be]_debug_defconfig, and the
> only option included is to enable debugfs SCOM access.
>
> Suggested-by:
On Sat, 2019-09-07 at 06:11:23 UTC, "Christopher M. Riedl" wrote:
> Read-only mode should not prevent listing and clearing any active
> breakpoints.
>
> Tested-by: Daniel Axtens
> Reviewed-by: Daniel Axtens
> Signed-off-by: Christopher M. Riedl
Series applied to powerpc next, thanks.
https://
On Tue, 2019-09-17 at 12:38:51 UTC, "Aneesh Kumar K.V" wrote:
> With commit: 7cc7867fb061 ("mm/devm_memremap_pages: enable sub-section remap")
> pmem namespaces are remapped in 2M chunks. On architectures like ppc64 we
> can map the memmap area using 16MB hugepage size and that can cover
> a memory
On Tue, 2019-09-17 at 15:22:30 UTC, Qian Cai wrote:
> pkey_allows_readwrite() was first introduced in the commit 5586cf61e108
> ("powerpc: introduce execute-only pkey"), but the usage was removed
> entirely in the commit a4fcc877d4e1 ("powerpc/pkeys: Preallocate
> execute-only key").
>
> Found by
On Wed, 2019-10-09 at 14:04:29 UTC, Hari Bathini wrote:
> FADump is supported on PowerNV platform. To fulfill this support, the
> petitboot kernel must be FADump aware. Enable config PRESERVE_FA_DUMP
> to make the petitboot kernel FADump aware.
>
> Signed-off-by: Hari Bathini
Applied to powerpc
On Wed, 2019-10-09 at 15:27:20 UTC, Hari Bathini wrote:
> arch/powerpc/kernel/fadump.c file needs to be compiled in if 'config
> FA_DUMP' or 'config PRESERVE_FA_DUMP' is set. The current syntax
> achieves that but looks a bit odd. Fix it for better readability.
>
> Signed-off-by: Hari Bathini
Ap
On Sun, 2019-10-13 at 23:46:43 UTC, Michael Ellerman wrote:
> The defaults for the sigfuz test is to run for 4000 iterations, but
> that can take quite a while and the test harness may kill the test.
> Reduce the number of iterations to 600, which gives a runtime of
> roughly 1 minute on a Power8 s
On Thu, 2019-10-24 at 05:59:32 UTC, Michael Ellerman wrote:
> accumulate_stolen_time() is called prior to interrupt state being
> reconciled, which can trip the warning in arch_local_irq_restore():
>
> WARNING: CPU: 5 PID: 1017 at arch/powerpc/kernel/irq.c:258
> .arch_local_irq_restore+0x9c/0x1
On Thu, 2019-10-24 at 09:35:40 UTC, "Aneesh Kumar K.V" wrote:
> No functional change in this patch.
>
> Signed-off-by: Aneesh Kumar K.V
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/82ce028ad26dd075b06285ef61a854a564d910fb
cheers
On Mon, 2018-05-21 at 02:04:38 UTC, Deb McLemore wrote:
> Problem being solved is when issuing a BMC soft poweroff during IPL,
> the poweroff was being lost so the machine would not poweroff.
>
> Opal messages were being received before the opal-power code
> registered its notifiers.
>
> Alternat
On Wed, 2019-09-11 at 16:34:33 UTC, Thiago Jung Bauermann wrote:
> The ultravisor will do an integrity check of the kernel image but we
> relocated it so the check will fail. Restore the original image by
> relocating it back to the kernel virtual base address.
>
> This works because during build
On Wed, 2019-10-16 at 16:28:33 UTC, Frederic Barrat wrote:
> Recent cleanup in the way EEH support is added to a device causes a
> kernel oops when the cxl driver probes a device and creates virtual
> devices discovered on the FPGA:
>
> BUG: Kernel NULL pointer dereference at 0x00a0
>
On Tue, 2019-10-22 at 11:58:14 UTC, Nicholas Piggin wrote:
> Commit e78a7614f3876 ("idle: Prevent late-arriving interrupts from
> disrupting offline") changes arch_cpu_idle_dead to be called with
> interrupts disabled, which triggers the WARN in pnv_smp_cpu_kill_self.
>
> Fix this by fixing up irq
> On Oct 30, 2019, at 6:28 AM, Peter Zijlstra wrote:
>
> It only makes 'wild' guesses when the BIOS is shit and it complains
> about that.
>
> Or do you like you BIOS broken?
Agree. It is the garbage in and garbage out. No need to complicate the existing
code further.
On 30/10/2019 11.50, Christophe Leroy wrote:
>
>
> Le 25/10/2019 à 14:40, Rasmus Villemoes a écrit :
>> Now that the references from arch/powerpc/ are gone, these are only
>> referenced from inside qe_ic.c, so make them static.
>
> Why do that in two steps ?
> I think patch 9 could remain until
Hello,
On Wed, Oct 02, 2019 at 01:13:52PM +1000, Nicholas Piggin wrote:
> Michal Suchánek's on September 24, 2019 7:33 pm:
> > Hello,
> >
> > can you mark the individual patches with RFC rather than the wole
> > series?
>
> Hey, thanks for the reviews. I'll resend all but the last two patches
>
Andrey Ryabinin writes:
> On 10/29/19 7:20 AM, Daniel Axtens wrote:
>> In the case where KASAN directly allocates memory to back vmalloc
>> space, don't map the early shadow page over it.
>>
>> We prepopulate pgds/p4ds for the range that would otherwise be empty.
>> This is required to get it sy
On 10/30/19 4:50 PM, Daniel Axtens wrote:
> Andrey Ryabinin writes:
>
>> On 10/29/19 7:20 AM, Daniel Axtens wrote:
>>> In the case where KASAN directly allocates memory to back vmalloc
>>> space, don't map the early shadow page over it.
>>>
>>> We prepopulate pgds/p4ds for the range that would
Andrey Ryabinin writes:
> On 10/30/19 4:50 PM, Daniel Axtens wrote:
>> Andrey Ryabinin writes:
>>
>>> On 10/29/19 7:20 AM, Daniel Axtens wrote:
In the case where KASAN directly allocates memory to back vmalloc
space, don't map the early shadow page over it.
We prepopulate pg
Hello, Daniel
>
> @@ -1294,14 +1299,19 @@ static bool __purge_vmap_area_lazy(unsigned long
> start, unsigned long end)
> spin_lock(&free_vmap_area_lock);
> llist_for_each_entry_safe(va, n_va, valist, purge_list) {
> unsigned long nr = (va->va_end - va->va_start) >> PAG
On 10/23/19 8:47 PM, Nayna Jain wrote:
Hi Nayna,
process_buffer_measurement() is limited to measuring the kexec boot
command line. This patch makes process_buffer_measurement() more
generic, allowing it to measure other types of buffer data (e.g.
blacklisted binary hashes or key hashes).
Now
On Wed, 2019-10-30 at 08:22 -0700, Lakshmi Ramasubramanian wrote:
> On 10/23/19 8:47 PM, Nayna Jain wrote:
>
> Hi Nayna,
>
> > process_buffer_measurement() is limited to measuring the kexec boot
> > command line. This patch makes process_buffer_measurement() more
> > generic, allowing it to measu
Trim the pointless temporary variable.
Signed-off-by: Reza Arbab
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index b78b5e81f941..319152
Rework of pnv_pci_ioda_iommu_bypass_supported() dropped a call to
pnv_npu_try_dma_set_bypass(). Reintroduce this call, so that the DMA
bypass configuration of a GPU device is propagated to its corresponding
NPU devices.
Fixes: 2d6ad41b2c21 ("powerpc/powernv: use the generic iommu bypass code")
Sig
Rework of pnv_pci_ioda_dma_set_mask() effectively reverted commit
253fd51e2f53 ("powerpc/powernv/pci: Return failure for some uses of
dma_set_mask()").
Reintroduce the desired behavior that an unfulfilled request for a DMA
mask between 32 and 64 bits will return error instead of silently
falling b
Change pnv_pci_ioda_iommu_bypass_supported() to have no side effects, by
separating the part of the function that determines if bypass is
supported from the part that actually attempts to configure it.
Move the latter to a controller-specific dma_set_mask() callback.
Signed-off-by: Reza Arbab
--
Collapse several open coded instances of pnv_ioda_get_pe().
Signed-off-by: Reza Arbab
---
arch/powerpc/platforms/powernv/npu-dma.c | 22 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 10 +++---
2 files changed, 8 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc
Revert commit b4d37a7b6934 ("powerpc/powernv: Remove unused
pnv_npu_try_dma_set_bypass() function") so that this function can be
reintegrated.
Fixes: 2d6ad41b2c21 ("powerpc/powernv: use the generic iommu bypass code")
Signed-off-by: Reza Arbab
Cc: Christoph Hellwig
---
arch/powerpc/platforms/po
Write this loop more compactly to improve readability.
Signed-off-by: Reza Arbab
---
arch/powerpc/platforms/powernv/npu-dma.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index a6
Move this code to its own function for reuse. As a side benefit,
rearrange the comments and spread things out for readability.
Signed-off-by: Reza Arbab
---
arch/powerpc/platforms/powernv/pci-ioda.c | 37 +--
1 file changed, 25 insertions(+), 12 deletions(-)
diff --g
This little calculation will be needed in other places. Move it to a
convenience function.
Signed-off-by: Reza Arbab
---
arch/powerpc/platforms/powernv/pci-ioda.c | 8 +++-
arch/powerpc/platforms/powernv/pci.h | 8
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a
Bring back the pci controller based hook in dma_set_mask(), as it will
have a user again.
This reverts commit 662acad4067a ("powerpc/pci: remove the dma_set_mask
pci_controller ops methods"). The callback signature has been adjusted
with void return to fit its caller.
Signed-off-by: Reza Arbab
C
With recent kernels, TCE tables for NPU devices are no longer being
configured. That task was performed by pnv_npu_try_dma_set_bypass(), a
function that got swept away in recent overhauling of dma code.
Patches 1-4 here bring the lost function back and reintegrate it with
the updated generic iommu
To enable simpler calling code, change this function to find the value
of bypass instead of taking it as an argument.
Signed-off-by: Reza Arbab
---
arch/powerpc/platforms/powernv/npu-dma.c | 12 +---
arch/powerpc/platforms/powernv/pci.h | 2 +-
2 files changed, 10 insertions(+), 4 d
On Wed, Oct 30, 2019 at 11:59:49AM -0500, Reza Arbab wrote:
> With recent kernels, TCE tables for NPU devices are no longer being
> configured. That task was performed by pnv_npu_try_dma_set_bypass(), a
> function that got swept away in recent overhauling of dma code.
>
> Patches 1-4 here bring th
On Wed, Oct 30, 2019 at 12:00:00PM -0500, Reza Arbab wrote:
> Change pnv_pci_ioda_iommu_bypass_supported() to have no side effects, by
> separating the part of the function that determines if bypass is
> supported from the part that actually attempts to configure it.
>
> Move the latter to a contr
On Wed, Oct 30, 2019 at 06:53:41PM +0100, Christoph Hellwig wrote:
How do you even use this code? Nothing in the kernel even calls
dma_set_mask for NPU devices, as we only suport vfio pass through.
You use it by calling dma_set_mask() for the *GPU* device. The purpose
of pnv_npu_try_dma_set_b
On Wed, Oct 30, 2019 at 06:55:18PM +0100, Christoph Hellwig wrote:
On Wed, Oct 30, 2019 at 12:00:00PM -0500, Reza Arbab wrote:
Change pnv_pci_ioda_iommu_bypass_supported() to have no side effects, by
separating the part of the function that determines if bypass is
supported from the part that ac
On Wed, Oct 30, 2019 at 01:08:51PM -0500, Reza Arbab wrote:
> On Wed, Oct 30, 2019 at 06:53:41PM +0100, Christoph Hellwig wrote:
>> How do you even use this code? Nothing in the kernel even calls
>> dma_set_mask for NPU devices, as we only suport vfio pass through.
>
> You use it by calling dma_se
On Wed, Oct 30, 2019 at 09:58:19AM +0100, Christophe Leroy wrote:
>
>
> Le 30/10/2019 à 08:31, Russell Currey a écrit :
> > v4 cover letter:
> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
> > v3 cover letter:
> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2019
On Wed, Oct 30, 2019 at 07:13:59PM +0100, Christoph Hellwig wrote:
On Wed, Oct 30, 2019 at 01:08:51PM -0500, Reza Arbab wrote:
On Wed, Oct 30, 2019 at 06:53:41PM +0100, Christoph Hellwig wrote:
How do you even use this code? Nothing in the kernel even calls
dma_set_mask for NPU devices, as we
On Wed, Oct 30, 2019 at 01:32:01PM -0500, Reza Arbab wrote:
> Aha, it's this again. Didn't catch your meaning at first. Point taken.
It's not _me_. It that you (plural) keep ignoring how Linux development
works.
On Tue, 2019-07-23 at 16:57 +0530, Anju T Sudhakar wrote:
> Hi Qian,
>
> On 7/16/19 12:11 AM, Qian Cai wrote:
> > On Thu, 2019-07-11 at 14:53 +1000, Michael Ellerman wrote:
> > > Hi Maddy,
> > >
> > > Madhavan Srinivasan writes:
> > > > diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
> >
On Wed, Oct 30, 2019 at 11:16:22AM +1100, Michael Ellerman wrote:
> Kees Cook writes:
> > On Mon, Oct 14, 2019 at 04:13:16PM +1100, Russell Currey wrote:
> >> v3 cover letter here:
> >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
> >>
> >> Only minimal changes since t
Le 30/10/2019 à 19:30, Kees Cook a écrit :
On Wed, Oct 30, 2019 at 09:58:19AM +0100, Christophe Leroy wrote:
Le 30/10/2019 à 08:31, Russell Currey a écrit :
v4 cover letter:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
v3 cover letter:
https://lists.ozlabs.org
Still see those,
WARNING: vmlinux.o(.text+0x2d04): Section mismatch in reference from the
variable __boot_from_prom to the function .init.text:prom_init()
The function __boot_from_prom() references
the function __init prom_init().
This is often because __boot_from_prom lacks a __init
annotation or
Using cpu_up/down directly to bring cpus online/offline loses synchronization
with sysfs and could suffer from a race similar to what is described in
commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and serialization
during LPM").
cpu_up/down seem to be more of a internal implementation d
The core device API performs extra housekeeping bits that are missing
from directly calling cpu_up/down.
See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and
serialization during LPM") for an example description of what might go
wrong.
This also prepares to make cpu_up/down a private
On Mon, Oct 14, 2019 at 08:31:03PM +0200, Nicolas Saenz Julienne wrote:
> Some architectures, notably ARM, are interested in tweaking this
> depending on their runtime DMA addressing limitations.
>
> Signed-off-by: Nicolas Saenz Julienne
Do you want me to pick this up for the 5.5 dma-mapping tre
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: a7f290dad32ee [PATCH] powerpc: Merge vdso's and add vdso support
to 32 bits kernel.
The bot has tested the following trees: v5.3.8, v4.19.81, v4.14.151, v4.9.198,
v4.4.198.
v5.3.
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Also placate checkpatch.pl by shortening a nearby line.
Cc: Kirill A. Shutemov
Signed-off-by: John Hubbard
---
mm/gup.c | 28 ++--
1 file changed, 18 ins
Hi,
This applies cleanly to linux-next and mmotm, and also to linux.git if
linux-next's commit 20cac10710c9 ("mm/gup_benchmark: fix MAP_HUGETLB
case") is first applied there.
This provides tracking of dma-pinned pages. This is a prerequisite to
solving the larger problem of proper interactions be
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static functi
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "pin_goldfish_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Signed-off-by: John Hubbard
---
drivers/platform/goldfish/goldfish_pipe.c | 18 +-
1 file changed, 9 in
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling set_page_
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This i
Convert infiniband to use the new wrapper calls, and stop
explicitly setting FOLL_LONGTERM at the call sites.
The new pin_longterm_*() calls replace get_user_pages*()
calls, and set both FOLL_LONGTERM and a new FOLL_PIN
flag. The FOLL_PIN flag requires that the caller must
return the pages via put
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
These variants all set FOLL_PIN, which is also introduced, and
basically documented. (An upcoming patch provides more extensive
documentation.) The second set (pin_longterm*) also sets
FOL
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of p
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
Signed-off-by: John Hubbard
---
fs/io_uring.c | 5 ++---
1 file changed, 2 inser
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
Signed-off-by: John Hubbard
---
drivers/gpu/drm/via/via_dmablit.c | 2 +-
1 fil
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
Signed-off-by: John Hubbard
---
net/xdp/xdp_umem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xdp/xdp_
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via put_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
Pag
1. Change v4l2 from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Cc: Mauro Carvalho Chehab
Sig
This also fixes one or two likely bugs.
1. Change vfio from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
Note that this is a change in behavior, because the
get_user_pages_remote() call was not setting FOLL_LONGTERM, but the
new pin_user_page
Now that all other kernel callers of get_user_pages(FOLL_LONGTERM)
have been converted to pin_longterm_pages(), lock it down:
1) Add an assertion to get_user_pages(), preventing callers from
passing FOLL_LONGTERM (in addition to the existing assertion that
prevents FOLL_PIN).
2) Remove the
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new correspon
1. Convert from get_user_pages(FOLL_LONGTERM) to pin_longterm_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is
Document the new pin_user_pages() and related calls
and behavior.
Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
in this documentation. (I've reworded it and expanded on it slightly.)
Cc: Jonathan Corbet
Signed-off-by: John Hubbard
---
Documentation/vm/index.rst |
1 - 100 of 134 matches
Mail list logo
