Hi Laurent,
On Tue, 1 Oct 2019 15:29:28 +0200 Laurent Dufour wrote:
>
> Fixes: 1211ee61b4a8 ("powerpc/pseries: Read TLB Block Invalidate
> Characteristics")
> Reported-by: Stephen Rothwell
Please use my external email address , thanks.
--
Cheers,
Stephen Rothwell
pgp68Uzwgj5xQ.pgp
Descrip
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index cba16ca0694a..26d9367c41a1 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powe
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh_pe.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
index b89ed46f14e6..0486d3c6ff20 100644
--- a/arch/powerpc/kerne
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 26d9367c41a1..c61bfaf4ca26 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh
Hi Everyone,
It's currently possible to cause a kernel crash by being (un)lucky while adding
or removing PCI devices during EEH recovery. The cause of the problem is that
there are trees of objects (struct eeh_pe, implemented with pointers and kernel
linked lists) that are manipulated concurrentl
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index c56a796dd894..12367ed2083b 100644
--- a
There are now functions eeh_get_pe() and eeh_pe_get() which seems
likely to cause confusion.
Keep eeh_get_pe() because "get" is commonly used to refer to acquiring
a reference (which it does), and rename eeh_pe_get() to eeh_pe_find()
because it performs a search.
Signed-off-by: Sam Bobroff
---
To facilitate debugging of (the inevitable) refcounting problems with
struct eeh_pes, detect when a struct eeh_pe has been removed from it's
global PHB list but not yet freed ("orphaned"), and collect these
PEs in a list.
They should only remain in the list briefly during processing, so any
PEs th
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh_pe.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
index 0486d3c6ff20..e89a30de2e7e 100644
--- a/arch/powerpc/kernel/
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 171be70b34d8..cba16ca0694a 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arc
Note that even though there is currently only one place where a PE can
be removed from the parent/child tree (eeh_rmv_from_parent_pe()), it
is still protected against concurrent removal in case that changes in
the future.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh_pe.c | 26 +
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index eb37cb384ff4..171be70b34d8 100644
--- a/arch/powerpc/
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh_driver.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index b3245d0cfb22..c9d73070793e 100644
--- a/arch/powerpc/kernel/eeh_driver.c
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh_driver.c | 15 +---
arch/powerpc/platforms/powernv/eeh-powernv.c | 38
2 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arc
Synchronize access to eeh_pe.
Signed-off-by: Sam Bobroff
---
arch/powerpc/kernel/eeh.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 7eb6ca1ab72b..eb37cb384ff4 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch
Reference counting for the in-line loop macro "eeh_for_each_pe()" can
be done by having eeh_pe_next() both get and put references; "rolling"
a reference along the list. This allows most loops to work without
change, although ones that use an "early-out" must manually release
the final reference.
W
Introduce infrastructure supporting refcounting for struct eeh_pe.
This will provide protection of the list members and struct memory so
that crashes related to accessing free memory or poisoned list
pointers can be avoided (for example, when EEH is triggered during
device removal).
While this pr
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
soon for merge in the next window.
scv needs a bit more work but hopefully it will be me
Michal Suchánek's on September 23, 2019 10:47 pm:
> On Sun, Sep 15, 2019 at 11:28:09AM +1000, Nicholas Piggin wrote:
>> System call entry and particularly exit code is beyond the limit of what
>> is reasonable to implement in asm.
>>
>> This conversion moves all conditional branches out of the asm
Hi,
>> /*
>> * Find a place in the tree where VA potentially will be
>> * inserted, unless it is merged with its sibling/siblings.
>> @@ -741,6 +752,10 @@ merge_or_add_vmap_area(struct vmap_area *va,
>> if (sibling->va_end == va->va_start) {
>> si
Hi Nayna,
Nayna writes:
> On 09/30/2019 09:04 PM, Thiago Jung Bauermann wrote:
>>> diff --git a/arch/powerpc/kernel/ima_arch.c b/arch/powerpc/kernel/ima_arch.c
>>> new file mode 100644
>>> index ..39401b67f19e
>>> --- /dev/null
>>> +++ b/arch/powerpc/kernel/ima_arch.c
>>> @@ -0,0 +
On Sun, Sep 29, 2019 at 8:33 AM Adam Ford wrote:
>
> I am attaching two logs. I now the mailing lists will be unhappy, but
> don't want to try and spam a bunch of log through the mailing liast.
> The two logs show the differences between the working and non-working
> imx6q 3D accelerator when tr
Hi David,
I love your patch! Perhaps something to improve:
[auto build test WARNING on mmotm/master]
url:
https://github.com/0day-ci/linux/commits/David-Hildenbrand/mm-memory_hotplug-Shrink-zones-before-removing-memory/20191002-054310
base: git://git.cmpxchg.org/linux-mmotm.git master
conf
Hi David,
I love your patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
url:
https://github.com/0day-ci/linux/commits/David-Hildenbrand/mm-memory_hotplug-Shrink-zones-before-removing-memory/20191002-054310
base: git://git.cmpxchg.org/linux-mmotm.git master
config: i3
The keys used to verify the Host OS kernel are managed by firmware as
secure variables. This patch loads the verification keys into the .platform
keyring and revocation hashes into .blacklist keyring. This enables
verification and loading of the kernels signed by the boot time keys which
are truste
The handlers to add the keys to the .platform keyring and blacklisted
hashes to the .blacklist keyring is common for both the uefi and powerpc
mechanisms of loading the keys/hashes from the firmware.
This patch moves the common code from load_uefi.c to keyring_handler.c
Signed-off-by: Nayna Jain
PowerNV secure variables, which store the keys used for OS kernel
verification, are managed by the firmware. These secure variables need to
be accessed by the userspace for addition/deletion of the certificates.
This patch adds the sysfs interface to expose secure variables for PowerNV
secureboot.
The X.509 certificates trusted by the platform and required to secure boot
the OS kernel are wrapped in secure variables, which are controlled by
OPAL.
This patch adds firmware/kernel interface to read and write OPAL secure
variables based on the unique key.
This support can be enabled using CONF
In order to verify the OS kernel on PowerNV systems, secure boot requires
X.509 certificates trusted by the platform. These are stored in secure
variables controlled by OPAL, called OPAL secure variables. In order to
enable users to manage the keys, the secure variables need to be exposed
to usersp
This patch fixes the size and write parameter for the macro
__BIN_ATTR_WO().
Fixes: 7f905761e15a8 ("sysfs: add BIN_ATTR_WO() macro")
Signed-off-by: Nayna Jain
---
include/linux/sysfs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/sysfs.h b/include/linux/s
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 Reconfig
> Connectors (DRC). These can otherwi
On Tue, 2019-10-01 at 12:04 -0700, John Hubbard wrote:
> On 10/1/19 10:56 AM, Leonardo Bras wrote:
> > On Mon, 2019-09-30 at 14:51 -0700, John Hubbard wrote:
> > > On 9/27/19 4:40 PM, Leonardo Bras wrote:
> ...
> > > > diff --git a/mm/gup.c b/mm/gup.c
> > > > index 98f13ab37bac..7105c829cf44 100644
On 10/1/19 10:56 AM, Leonardo Bras wrote:
> On Mon, 2019-09-30 at 14:51 -0700, John Hubbard wrote:
>> On 9/27/19 4:40 PM, Leonardo Bras wrote:
...
>>> diff --git a/mm/gup.c b/mm/gup.c
>>> index 98f13ab37bac..7105c829cf44 100644
>>> --- a/mm/gup.c
>>> +++ b/mm/gup.c
>>> @@ -2325,6 +2325,7 @@ static
On 10/01/2019 02:16 PM, Greg Kroah-Hartman wrote:
On Tue, Oct 01, 2019 at 02:08:53PM -0400, Nayna wrote:
Hi Greg,
On 08/26/2019 11:01 AM, Greg Kroah-Hartman wrote:
This variant was missing from sysfs.h, I guess no one noticed it before.
Turns out the powerpc secure variable code can use i
On 10/1/19 11:39 AM, Leonardo Bras wrote:
> On Mon, 2019-09-30 at 14:47 -0700, John Hubbard wrote:
>> On 9/30/19 11:42 AM, Leonardo Bras wrote:
>>> On Mon, 2019-09-30 at 10:57 -0700, John Hubbard wrote:
...
>
> I am failing to understand the issue.
> I mean, smp_call_function_many() will issue a I
On Mon, 2019-09-30 at 14:47 -0700, John Hubbard wrote:
> On 9/30/19 11:42 AM, Leonardo Bras wrote:
> > On Mon, 2019-09-30 at 10:57 -0700, John Hubbard wrote:
> > > > As I told before, there are cases where this function is called from
> > > > 'real mode' in powerpc, which doesn't disable irqs and m
On Tue, Oct 01, 2019 at 02:08:53PM -0400, Nayna wrote:
> Hi Greg,
>
>
> On 08/26/2019 11:01 AM, Greg Kroah-Hartman wrote:
> > This variant was missing from sysfs.h, I guess no one noticed it before.
> >
> > Turns out the powerpc secure variable code can use it, so add it to the
> > tree for it,
Hi Greg,
On 08/26/2019 11:01 AM, Greg Kroah-Hartman wrote:
This variant was missing from sysfs.h, I guess no one noticed it before.
Turns out the powerpc secure variable code can use it, so add it to the
tree for it, and potentially others to take advantage of, instead of
open-coding it.
Repo
On Mon, 2019-09-30 at 14:51 -0700, John Hubbard wrote:
> On 9/27/19 4:40 PM, Leonardo Bras wrote:
> > As decribed, gup_pgd_range is a lockless pagetable walk. So, in order to
> > monitor against THP split/collapse with the couting method, it's necessary
>
> s/couting/counting/
>
Thanks, fixed fo
On 10/01/2019 09:33 AM, Rob Herring wrote:
On Fri, Sep 27, 2019 at 10:25:52AM -0400, Nayna Jain wrote:
PowerNV represents both the firmware and Host OS secureboot state of the
system via device tree. This patch adds the documentation to give
the definition of the nodes and the properties.
Si
On 09/30/2019 09:04 PM, Thiago Jung Bauermann wrote:
Hello,
Hi,
diff --git a/arch/powerpc/kernel/ima_arch.c b/arch/powerpc/kernel/ima_arch.c
new file mode 100644
index ..39401b67f19e
--- /dev/null
+++ b/arch/powerpc/kernel/ima_arch.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifi
https://bugzilla.kernel.org/show_bug.cgi?id=204789
--- Comment #11 from Cameron (c...@neo-zeon.de) ---
grep RAM /proc/iomem
-3f : System RAM
The system has 16 dimm slots, all are populated. Unfortunately, I will
not have physical to access to the box in the foreseeable future.
A
On Tue, Oct 01, 2019 at 10:03:56AM +0100, Will Deacon wrote:
> Hi Kees,
>
> On Thu, Sep 26, 2019 at 10:55:51AM -0700, Kees Cook wrote:
> > The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA.
> >
> > Signed-off-by: Kees Cook
> > ---
> > arch/arm64/kernel/vmlinux.lds.S | 6 --
> >
On 01.10.19 16:57, David Hildenbrand wrote:
> On 01.10.19 16:40, David Hildenbrand wrote:
>> From: "Aneesh Kumar K.V"
>>
>> With altmap, all the resource pfns are not initialized. While initializing
>> pfn, altmap reserve space is skipped. Hence when removing pfn from zone
>> skip pfns that were n
On 01.10.19 16:40, David Hildenbrand wrote:
> From: "Aneesh Kumar K.V"
>
> With altmap, all the resource pfns are not initialized. While initializing
> pfn, altmap reserve space is skipped. Hence when removing pfn from zone
> skip pfns that were never initialized.
>
> Update memunmap_pages to ca
Let's drop the basically unused section stuff and simplify.
Also, let's use a shorter variant to calculate the number of pages to
the next section boundary.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Wei Yang
Signed-off-by: David Hildenbran
Get rid of the unnecessary local variables.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Wei Yang
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 15 ++-
1 file changed, 6 insertions(+), 9 deleti
If we have holes, the holes will automatically get detected and removed
once we remove the next bigger/smaller section. The extra checks can
go.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: David Hildenbrand
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Wei Yang
Signed-off-by: David
With shrink_pgdat_span() out of the way, we now always have a valid
zone.
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Pavel Tatashin
Cc: Dan Williams
Cc: Wei Yang
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 4 ++--
1 file changed, 2 inser
Let's poison the pages similar to when adding new memory in
sparse_add_section(). Also call remove_pfn_range_from_zone() from
memunmap_pages(), so we can poison the memmap from there as well.
While at it, calculate the pfn in memunmap_pages() only once.
Cc: Andrew Morton
Cc: David Hildenbrand
C
We currently try to shrink a single zone when removing memory. We use the
zone of the first page of the memory we are removing. If that memmap was
never initialized (e.g., memory was never onlined), we will read garbage
and can trigger kernel BUGs (due to a stale pointer):
:/# [ 23.912993] BUG:
Let's limit shrinking to !ZONE_DEVICE so we can fix the current code. We
should never try to touch the memmap of offline sections where we could
have uninitialized memmaps and could trigger BUGs when calling
page_to_nid() on poisoned pages.
There is no reliable way to distinguish an uninitialized
We might use the nid of memmaps that were never initialized. For
example, if the memmap was poisoned, we will crash the kernel in
pfn_to_nid() right now. Let's use the calculated boundaries of the separate
zones instead. This now also avoids having to iterate over a whole bunch of
subsections again
From: "Aneesh Kumar K.V"
The third argument is actually number of pages. Changes the variable name
from size to nr_pages to indicate this better.
No functional change in this patch.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Oscar Salvador
Cc: Mel Gorman
Cc: Mike Rapoport
From: "Aneesh Kumar K.V"
With altmap, all the resource pfns are not initialized. While initializing
pfn, altmap reserve space is skipped. Hence when removing pfn from zone
skip pfns that were never initialized.
Update memunmap_pages to calculate start and end pfn based on altmap
values. This fix
This series fixes the access of uninitialized memmaps when shrinking
zones/nodes and when removing memory. Also, it contains all fixes for
crashes that can be triggered when removing certain namespace using
memunmap_pages() - ZONE_DEVICE, reported by Aneesh.
We stop trying to shrink ZONE_DEVICE, a
On Fri, Sep 27, 2019 at 10:25:52AM -0400, Nayna Jain wrote:
> PowerNV represents both the firmware and Host OS secureboot state of the
> system via device tree. This patch adds the documentation to give
> the definition of the nodes and the properties.
>
> Signed-off-by: Nayna Jain
> ---
> .../b
Since the commit 1211ee61b4a8 ("powerpc/pseries: Read TLB Block Invalidate
Characteristics"), a warning message is displayed when booting a guest on
top of KVM:
lpar: arch/powerpc/platforms/pseries/lpar.c
pseries_lpar_read_hblkrm_characteristics Error calling get-system-parameter
(0xfffd)
T
The patch
ASoC: fsl_asrc: Use in(out)put_format instead of in(out)put_word_width
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime i
The patch
ASoC: fsl_asrc: update supported sample format
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
ASoC: pcm_dmaengine: Extract snd_dmaengine_pcm_refine_runtime_hwparams
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime i
The patch
ASoC: fsl_mqs: add DT binding documentation
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and se
The patch
ASoC: fsl_mqs: Add MQS component driver
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent t
The patch
ASoC: fsl_asrc: Fix error with S24_3LE format bitstream in i.MX8
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
Hello, Daniel.
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index a3c70e275f4e..9fb7a16f42ae 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -690,8 +690,19 @@ merge_or_add_vmap_area(struct vmap_area *va,
> struct list_head *next;
> struct rb_node **link;
> struct rb_node *p
Perf is the primary interface to program performance monitoring
unit (pmu) and collect counter data in system.
But currently pmu register files are created in the
/sys/devices/system/cpu/cpu* without checking CONFIG_PERF_EVENTS
option. These includes PMC* and MMCR* sprs.
Patch ties sysfs pmu spr fi
https://bugzilla.kernel.org/show_bug.cgi?id=204789
--- Comment #10 from Michael Ellerman (mich...@ellerman.id.au) ---
Can you boot a good kernel and do:
$ sudo grep RAM /proc/iomem
And paste the output. Just to confirm what your memory layout is.
What arrangement of DIMMs do you have? It's poss
https://bugzilla.kernel.org/show_bug.cgi?id=204789
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |ASSIGNED
--
https://bugzilla.kernel.org/show_bug.cgi?id=204789
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
CC||mich...@ellerm
On Thu, Sep 26, 2019 at 10:55:47AM -0700, Kees Cook wrote:
> Many architectures have an EXCEPTION_TABLE that needs only to be
> read-only. As such, it should live in RO_DATA. This creates a macro to
> identify this case for the architectures that can move EXCEPTION_TABLE
> into RO_DATA.
>
> Signed
Hi Kees,
On Thu, Sep 26, 2019 at 10:55:51AM -0700, Kees Cook wrote:
> The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA.
>
> Signed-off-by: Kees Cook
> ---
> arch/arm64/kernel/vmlinux.lds.S | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/ke
With large memory (8TB and more) hotplug, we can get soft lockup warnings
as below. These were caused by a long loop without any explicit cond_resched
which is a problem for !PREEMPT kernels.
Avoid the using cond_resched() while inserting hash page table entries. We
already do similar cond_resched
On 9/29/19 9:08 PM, Oliver O'Halloran wrote:
A couple of extra patches on top of Shawn's existing re-ordering patch.
This seems to fix the problem Alexey noted with Shawn's change causing
VFs to lose their IOMMU group. I've tried pretty hard to make this a
minimal fix it's still a bit large.
If
Provide the current number of vmalloc shadow pages in
/sys/kernel/debug/kasan/vmalloc_shadow_pages.
Signed-off-by: Daniel Axtens
---
v8: rename kasan_vmalloc/shadow_pages -> kasan/vmalloc_shadow_pages
On v4 (no dynamic freeing), I saw the following approximate figures
on my test VM:
- fresh
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 synced to hardware on boot, allowing the
lower levels of the page tables to be filled d
Supporting VMAP_STACK with KASAN_VMALLOC is straightforward:
- clear the shadow region of vmapped stacks when swapping them in
- tweak Kconfig to allow VMAP_STACK to be turned on with KASAN
Reviewed-by: Dmitry Vyukov
Signed-off-by: Daniel Axtens
---
arch/Kconfig | 9 +
kernel/fork.c
Test kasan vmalloc support by adding a new test to the module.
Signed-off-by: Daniel Axtens
--
v5: split out per Christophe Leroy
---
lib/test_kasan.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 49cc4d570a40..328d33b
Hook into vmalloc and vmap, and dynamically allocate real shadow
memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mapp
78 matches
Mail list logo
