On 10/29/19 11:00 AM, Dan Williams wrote:
On Mon, Oct 28, 2019 at 9:35 PM Aneesh Kumar K.V
wrote:
On 10/29/19 4:38 AM, Dan Williams wrote:
On Mon, Oct 28, 2019 at 2:48 AM Aneesh Kumar K.V
wrote:
The page size used to map the namespace is arch dependent. For example
architectures like
The following build warning occurred on powerpc 64-bit builds:
drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of
1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
This is with a cross-compiler based on
On 10/30/19 7:39 PM, Michael Ellerman wrote:
Hi John,
Sorry I didn't reply to this sooner, too many patches :/
John Hubbard writes:
The following build warning occurred on powerpc 64-bit builds:
drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
The arch specific kernel module policy rule requires kernel modules to
be signed, either as an IMA signature, stored as an xattr, or as an
appended signature. As a result, kernel modules appended signatures
could be enforced without "sig_enforce" being set or reflected in
From: Nayna Jain
This patch updates the arch-specific policies for PowerNV system to make
sure that the binary hash is not blacklisted.
Signed-off-by: Nayna Jain
Cc: Jessica Yu
Signed-off-by: Mimi Zohar
---
arch/powerpc/kernel/ima_arch.c | 8
1 file changed, 4 insertions(+), 4
From: Nayna Jain
Asymmetric private keys are used to sign multiple files. The kernel
currently supports checking against blacklisted keys. However, if the
public key is blacklisted, any file signed by the blacklisted key will
automatically fail signature verification. Blacklisting the public
From: Nayna Jain
The -EKEYREJECTED error returned by existing is_hash_blacklisted() is
misleading when called for checking against blacklisted hash of a
binary.
This patch adds a wrapper function is_binary_blacklisted() to return
-EPERM error if binary is blacklisted.
Signed-off-by: Nayna Jain
From: Nayna Jain
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).
process_buffer_measurement() may be
From: Nayna Jain
This patch defines an arch-specific trusted boot only policy and a
combined secure and trusted boot policy.
Signed-off-by: Nayna Jain
Signed-off-by: Mimi Zohar
---
arch/powerpc/kernel/ima_arch.c | 33 -
1 file changed, 32 insertions(+), 1
From: Nayna Jain
This patch defines a function to detect the secure boot state of a
PowerNV system.
The PPC_SECURE_BOOT config represents the base enablement of secure boot
for powerpc.
Signed-off-by: Nayna Jain
---
arch/powerpc/Kconfig | 10 ++
From: Nayna Jain
While secure boot permits only properly verified signed kernels to be
booted, trusted boot calculates the file hash of the kernel image and
stores the measurement prior to boot, that can be subsequently compared
against good known values via attestation services.
This patch
From: Nayna Jain
PowerNV systems use a Linux-based bootloader, which rely on the IMA
subsystem to enforce different secure boot modes. Since the verification
policy may differ based on the secure boot mode of the system, the
policies must be defined at runtime.
This patch implements
This patchset extends the previous version[1] by adding support for
checking against a blacklist of binary hashes.
The IMA subsystem supports custom, built-in, arch-specific policies to
define the files to be measured and appraised. These policies are honored
based on priority, where
On 2019/10/30 18:14, 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.
>>
>>
Hi John,
Sorry I didn't reply to this sooner, too many patches :/
John Hubbard writes:
> The following build warning occurred on powerpc 64-bit builds:
>
> drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
> drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of
Hi Michael, Can you pull this to linux-next so that we can test it on
linux-next for some time?
Thanks,
Jason
On 2019/10/23 7:21, Scott Wood wrote:
This contains KASLR support for book3e 32-bit.
The following changes since commit 612ee81b9461475b5a5612c2e8d71559dd3c7920:
On Thu, 31 Oct 2019 10:33:00 +0900 Masahiro Yamada
wrote:
> Hi Andrew,
>
> I think this patch has already been picked up to your tree,
> but I noticed a typo in the commit message just now.
> Please see below.
>
> ...
>
> > Include to make it self-contained, and add it to
>
> Include to
Hi Andrew,
I think this patch has already been picked up to your tree,
but I noticed a typo in the commit message just now.
Please see below.
On Wed, Oct 30, 2019 at 3:40 PM Masahiro Yamada
wrote:
>
> The user-space cannot compile due to some missing type
> definitions. For example, building
https://bugzilla.kernel.org/show_bug.cgi?id=205327
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Michael Ellerman from comment #3)
> That looks like a pretty straight forward memory leak here:
[...]
> Do you want to send a patch?
Thanks for pointing out! Yes, in this case
When porting a powerpc-only driver to work on another architecture,
one has to change e.g. out_be32 to iowrite32be. Unfortunately, while
the other target architecture (in my case arm) may have static inline
definitions of iowrite32 and friends, this change pessimizes the
existing powerpc users of
The only caller of pcibios_vaddr_is_ioport() is in pci-common.c, so we
can make it static and move it into the same #ifndef block as its
caller.
Signed-off-by: Rasmus Villemoes
---
arch/powerpc/include/asm/pci-bridge.h | 9 -
arch/powerpc/kernel/pci-common.c | 4 ++--
2 files
When trying to make the QUICC Engine drivers compile on arm, I
mechanically (with coccinelle) changed out_be32() to iowrite32be()
etc. Christophe pointed out [1][2] that that would pessimize the
powerpc SOCs since the IO accesses now incur a function call
overhead. He asked that I try to make
Make it possible for an architecture to include asm-generic/iomap.h
without necessarily getting all the external declarations for
iowrite32 and friends. For example, the architecture could (maybe just
in some configurations) provide static inline versions of some or all
of these, but still use
pci_iounmap seems misplaced in iomap.h. Move it to where its cousins
live. Since iomap.h includes pci_iomap.h, anybody relying on getting
the declaration through iomap.h will still get it.
It would be natural to put the static inline version inside the
#elif defined(CONFIG_GENERIC_PCI_IOMAP)
As preparation for making iowrite32 and friends static inlines, move
the definition of pci_iounmap() from iomap.c to pci-common.c. This
definition of pci_iounmap() is compiled in when
!CONFIG_PPC_INDIRECT_PIO && CONFIG_PCI - we're just interchanging
which condition is in the Kbuild logic and which
On 10/1/19 1:02 PM, Bjorn Helgaas wrote:
> On Tue, Oct 01, 2019 at 01:12:05AM -0500, Tyrel Datwyler wrote:
>> There was an initial previous effort yo add support for the PAPR
>> architected ibm,drc-info property. This property provides a more
>> memory compact representation of a paritions Dynamic
On 10/10/19 12:04 PM, Nathan Lynch wrote:
> Tyrel Datwyler writes:
>> The ibm,drc-info property is an array property that contains drc-info
>> entries such that each entry is made up of 2 string encoded elements
>> followed by 5 int encoded elements. The of_read_drc_info_cell()
>> helper contains
On Wed, 2019-10-30 at 09:58 +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:
> >
On Wed, 30 Oct 2019 at 07:31, Russell Currey wrote:
>
> 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
On 10/10/19 11:56 AM, Nathan Lynch wrote:
> Hi Tyrel,
>
> Tyrel Datwyler writes:
>> +static bool valid_cpu_drc_index(struct device_node *parent, u32 drc_index)
>> +{
>> +const __be32 *indexes;
>> +int i;
>> +
>> +if (of_find_property(parent, "ibm,drc-info", NULL))
>> +
On Wed, Oct 30, 2019 at 10:55:03PM +1100, Michael Ellerman wrote:
> 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
On 10/30/19 3:49 PM, John Hubbard wrote:
> This also fixes one or two likely bugs.
Well, actually just one...
>
> 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
>
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1)
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. 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
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
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
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
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
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".
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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:
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
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 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 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 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:
> >
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
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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")
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
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
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
Hello, Daniel
>
> @@ -1294,14 +1299,19 @@ static bool __purge_vmap_area_lazy(unsigned long
> start, unsigned long end)
> spin_lock(_vmap_area_lock);
> llist_for_each_entry_safe(va, n_va, valist, purge_list) {
> unsigned long nr = (va->va_end - va->va_start) >>
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
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
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
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
>
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
> 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 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
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 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 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.
>
>
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 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
>
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
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
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 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 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
1 - 100 of 136 matches
Mail list logo
