Mahesh J Salgaonkar's on January 16, 2020 5:03 pm:
> On 2019-12-11 20:01:18 Wed, Nicholas Piggin wrote:
>> Provide facilities to decode machine checks into human readable
>> strings, with only sufficient information required to deal with
>> them sanely.
>>
>> The old machine check stuff was over e
On Mon, Jan 20, 2020 at 05:52:15PM -0800, Joe Perches wrote:
> On Tue, 2020-01-21 at 09:31 +0800, Chen Zhou wrote:
> > Fixes coccicheck warning:
> > ./arch/powerpc/platforms/maple/setup.c:232:15-16:
> > WARNING comparing pointer to 0
>
> Does anyone have or use these powerpc maple boards anymo
发件人：Andrew Donnellan
发送日期：2020-01-21 14:13:07
收件人：wangwenhu ,Benjamin Herrenschmidt
,Paul Mackerras ,Michael Ellerman
,Kate Stewart ,Greg
Kroah-Hartman ,Richard Fontana
,Thomas Gleixner
,linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org
抄送人：triv...@kernel.org,loneh...@hotmail.com,wen
On 3/12/19 2:46 pm, Alastair D'Silva wrote:
From: Alastair D'Silva
This patch adds platform support to map & release LPC memory.
Might want to explain what LPC is.
Otherwise:
Reviewed-by: Andrew Donnellan
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/pnv-ocxl.h | 2
发件人：Scott Wood
发送日期：2020-01-21 13:49:59
收件人："王文虎"
抄送人：wangwenhu ,Kumar Gala
,Benjamin Herrenschmidt
,Paul Mackerras ,Michael Ellerman
,linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org,triv...@kernel.org,Rai
Harninder
主题：Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configur
On 21/1/20 4:31 pm, wangwenhu wrote:
From: wangwenhu
Include arch/powerpc/include/asm/io.h into fsl_85xx_cache_sram.c to
fix the implicit declaration compile errors when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fs
Le 21/01/2020 à 06:31, wangwenhu a écrit :
From: wangwenhu
Include arch/powerpc/include/asm/io.h into fsl_85xx_cache_sram.c to
fix the implicit declaration compile errors when building Cache-Sram.
It is usually better to include instead of
Christophe
On Tue, 2020-01-21 at 13:20 +0800, 王文虎 wrote:
> From: Scott Wood
> Date: 2020-01-21 11:25:25
> To: wangwenhu ,Kumar Gala ,
> Benjamin Herrenschmidt ,Paul Mackerras <
> pau...@samba.org>,Michael Ellerman ,
> linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org
> Cc: triv...@kernel.org,wenhu
From: Scott Wood
Date: 2020-01-21 11:25:25
To: wangwenhu ,Kumar Gala
,Benjamin Herrenschmidt
,Paul Mackerras ,Michael Ellerman
,linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org
Cc: triv...@kernel.org,wenhu.w...@vivo.com,Rai Harninder
Subject: Re: [PATCH] powerpc/Kconfig: Make FSL_
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #19 from Christophe Leroy (christophe.le...@c-s.fr) ---
Can you tell exactly where it stops during the boot ? Or take a photo of the
screen ?
In parallele, could you try (without VMAP_STACK) increasing CONFIG_THREAD_SHIFT
to 14 ? It w
From: wangwenhu
Include arch/powerpc/include/asm/io.h into fsl_85xx_cache_sram.c to
fix the implicit declaration compile errors when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: impli
This adds the CPU or thread number to printk messages. This can help
decipher concurrent oopses that have been interleaved.
Example output, of PID1 (T1) triggering a warning:
[1.581678][T1] WARNING: CPU: 0 PID: 1 at crypto/rsa-pkcs1pad.c:539
pkcs1pad_verify+0x38/0x140
[1.581681][
Enable more hardening options.
Note BUG_ON_DATA_CORRUPTION selects DEBUG_LIST and is essentially just
a synonym for it.
DEBUG_SG, DEBUG_NOTIFIERS, DEBUG_LIST, DEBUG_CREDENTIALS and
SCHED_STACK_END_CHECK should all be low overhead and just add a few
extra checks.
SLAB_FREELIST_RANDOM, and SLUB_DE
If the skiroot kernel crashes we don't want it sitting at an xmon
prompt forever. Instead it's more helpful to reboot and bring the
boot loader back up, and if the crash was transient we can then boot
successfully.
Similarly if we panic we should reboot, with a short timeout in case
someone is wat
From: Joel Stanley
This turns on HARDENED_USERCOPY with HARDENED_USERCOPY_PAGESPAN, and
FORTIFY_SOURCE.
It also enables SECURITY_LOCKDOWN_LSM with _EARLY and
LOCK_DOWN_KERNEL_FORCE_INTEGRITY options enabled. This still allows
xmon to be used in read-only mode.
MODULE_SIG is selected by lockdown
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/skiroot_defconfig | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
v2: No change.
diff --git a/arch/powerpc/configs/skiroot_defconfig
b/arch/powerpc/configs/skiroot_defconfig
index 0aa060eef06c..24a210fe
It's default n so we don't need to disable it.
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/skiroot_defconfig | 1 -
1 file changed, 1 deletion(-)
v2: No change.
diff --git a/arch/powerpc/configs/skiroot_defconfig
b/arch/powerpc/configs/skiroot_defconfig
index 74cffb854c0f..0aa060
Commit bdd08fff4915 ("HID: logitech: Add depends on LEDS_CLASS to
Logitech Kconfig entry") made HID_LOGITECH depend on LEDS_CLASS which
we do not enable, meaning we are not actually enabling those drivers
any more.
The Kconfig help text suggests USB HID compliant Logictech devices
will continue to
The HP network driver moved to staging in commit 52340b82cf1a ("hp100:
Move 100BaseVG AnyLAN driver to staging") meaning we don't need to
disable it any more in our defconfigs.
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/44x/akebono_defconfig | 1 -
arch/powerpc/configs/skiroot_defc
The QLGE driver moved to staging in commit 955315b0dc8c ("qlge: Move
drivers/net/ethernet/qlogic/qlge/ to drivers/staging/qlge/"), meaning
our defconfigs that enable it have no effect as we don't enable
CONFIG_STAGING.
It sounds like the device is obsolete, so drop the driver.
Signed-off-by: Mich
The NET_CADENCE symbol was renamed to NET_VENDOR_CADENCE, so we don't
need to disable the former, see commit 0df5f81c481e ("net: ethernet:
Add missing VENDOR to Cadence and Packet Engines symbols").
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/skiroot_defconfig | 1 -
1 file changed,
Joel Stanley writes:
> On Thu, 16 Jan 2020 at 01:48, Michael Ellerman wrote:
>>
>> Enable more hardening options.
>>
>> Note BUG_ON_DATA_CORRUPTION selects DEBUG_LIST and is essentially just
>> a synonym for it.
>>
>> DEBUG_SG, DEBUG_NOTIFIERS, DEBUG_LIST, DEBUG_CREDENTIALS and
>> SCHED_STACK_END
On 21/01/2020 09:10, Tyrel Datwyler wrote:
> From: Tyrel Datwyler
>
> Commit e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to
> iommu_table") missed an iommu_table allocation in the pseries vio code.
> The iommu_table is allocated with kzalloc and as a result the associated
> k
On Mon, 2020-01-20 at 06:43 -0800, wangwenhu wrote:
> From: wangwenhu
>
> When generating .config file with menuconfig on Freescale BOOKE
> SOC, FSL_85XX_CACHE_SRAM is not configurable for the lack of
> description in the Kconfig field, which makes it impossible
> to support L2Cache-Sram driver.
On Tue, 2020-01-21 at 09:31 +0800, Chen Zhou wrote:
> Fixes coccicheck warning:
> ./arch/powerpc/platforms/maple/setup.c:232:15-16:
> WARNING comparing pointer to 0
Does anyone have or use these powerpc maple boards anymore?
Maybe the whole codebase should just be deleted instead.
If not,
Fixes coccicheck warning:
./arch/powerpc/platforms/maple/setup.c:232:15-16:
WARNING comparing pointer to 0
Compare pointer-typed values to NULL rather than 0.
Signed-off-by: Chen Zhou
---
arch/powerpc/platforms/maple/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #18 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #17)
> Created attachment 286907 [details]
> Patch to fix kasan with KASAN_VMALLOC and VMAP_STACK
>
> Please try the attached patch, it fixes the
From: Tyrel Datwyler
Commit e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to
iommu_table") missed an iommu_table allocation in the pseries vio code.
The iommu_table is allocated with kzalloc and as a result the associated
kref gets a value of zero. This has the side effect that du
From: wangwenhu
When generating .config file with menuconfig on Freescale BOOKE
SOC, FSL_85XX_CACHE_SRAM is not configurable for the lack of
description in the Kconfig field, which makes it impossible
to support L2Cache-Sram driver. Add a description to make it
configurable.
Signed-off-by: wangw
On Mon, Jan 20, 2020 at 05:26:27PM +, Mark Brown wrote:
> I think the important thing here is that *someone* takes the patches.
> We've now got Ted and Borislav both saying they're OK applying the
> patches, an additional proposal that Andrew takes the patches, nobody
> saying anything negative
On Mon, Jan 20, 2020 at 06:08:23PM +0100, Christophe Leroy wrote:
> Not easy I think.
>
> First we have the unavoidable ASM entry function that can't be dropped
> because of the CR[SO] bit the set on error or clear on no error and that
> can't be done in C.
Yup.
> In our ASM VDSO, fixed shifts
On Fri, Jan 10, 2020 at 12:05:59PM -0500, Theodore Y. Ts'o wrote:
> On Fri, Jan 10, 2020 at 04:51:53PM +0100, Borislav Petkov wrote:
> > On Fri, Jan 10, 2020 at 02:54:12PM +, Mark Brown wrote:
> > > This is a resend of a series from Richard Henderson last posted back in
> > > November:
> > >
Le 20/01/2020 à 16:19, Segher Boessenkool a écrit :
On Mon, Jan 20, 2020 at 02:56:00PM +, Christophe Leroy wrote:
Nice! Much better.
It should be tested on more representative hardware, too, but this looks
promising alright :-)
mpc832x (e300c2 core) at 333 MHz:
Before:
gettimeofday:
On Mon, Jan 20, 2020 at 02:56:00PM +, Christophe Leroy wrote:
> >Nice! Much better.
> >
> >It should be tested on more representative hardware, too, but this looks
> >promising alright :-)
>
> mpc832x (e300c2 core) at 333 MHz:
>
> Before:
>
> gettimeofday:vdso: 235 nsec/call
> clock-get
Hi
On 01/17/2020 08:58 AM, Segher Boessenkool wrote:
Hi!
On Thu, Jan 16, 2020 at 05:58:24PM +, Christophe Leroy wrote:
On a powerpc8xx, with current powerpc/32 ASM VDSO:
gettimeofday:vdso: 907 nsec/call
clock-getres-realtime:vdso: 484 nsec/call
clock-gettime-realtime:vdso: 899
On 1/20/20 7:29 PM, Sandipan Das wrote:
> Some tests are built only for 64-bit systems. This makes
> sure that these tests are built for both big and little
> endian variants of powerpc64.
>
> Fixes: 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit
> arch")
> Signed-off-by: Sandi
Some tests are built only for 64-bit systems. This makes
sure that these tests are built for both big and little
endian variants of powerpc64.
Fixes: 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit arch")
Signed-off-by: Sandipan Das
---
Changelog:
v2:
- Added required changes
Some tests are built only for 64-bit systems. This makes
sure that these tests are built for both big and little
endian variants of powerpc64.
Fixes: 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit arch")
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/Makefile | 2 +
From: Wang Hai
Date: Sat, 26 Oct 2019 09:57:38 +0800
> Fix the following gcc warning:
>
> drivers/ide/pmac.c: In function pmac_ide_setup_device:
> drivers/ide/pmac.c:1027:14: warning: variable hwif set but not used
> [-Wunused-but-set-variable]
>
> Fixes: d58b0c39e32f ("powerpc/macio: Rework ho
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #17 from Christophe Leroy (christophe.le...@c-s.fr) ---
Created attachment 286907
--> https://bugzilla.kernel.org/attachment.cgi?id=286907&action=edit
Patch to fix kasan with KASAN_VMALLOC and VMAP_STACK
Please try the attached patc
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to CAP_PERFMON
capability. Providing the access
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to CAP_PERFMON
capability. Providing the access
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to CAP_PERFMON
capability. Providing the access
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to CAP_PERFMON
capability. Providing the access
Open access to bpf_trace monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to bpf_trace monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for
secure bpf_trace monitoring is discouraged with respect to CAP_PERFMON
capabi
Open access to i915_perf monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to i915_perf subsystem remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for
secure i915_perf monitoring is discouraged with respect to CAP_PERFMON
capabil
Extend error messages to mention CAP_PERFMON capability as an option
to substitute CAP_SYS_ADMIN capability for secure system performance
monitoring and observability operations. Make perf_event_paranoid_check()
and __cmd_ftrace() to be aware of CAP_PERFMON capability.
Signed-off-by: Alexey Buda
Open access to anon kprobes, uprobes and eBPF tracing for CAP_PERFMON
privileged processes. For backward compatibility reasons access remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for
secure monitoring is discouraged with respect to CAP_PERFMON capability.
Providing
Open access to monitoring of kernel code, system, tracepoints and namespaces
data for a CAP_PERFMON privileged process. For backward compatibility
reasons access to perf_events subsystem remains open for CAP_SYS_ADMIN
privileged processes but CAP_SYS_ADMIN usage for secure perf_events
monitoring
Introduce CAP_PERFMON capability designed to secure system performance
monitoring and observability operations so that CAP_PERFMON would assist
CAP_SYS_ADMIN capability in its governing role for perf_events, i915_perf
and other performance monitoring and observability subsystems.
CAP_PERFMON int
On Mon, 20 Jan 2020 at 10:17, Christian Zigotzky wrote:
>
> Am 16.01.20 um 16:46 schrieb Ulf Hansson:
> > On Thu, 16 Jan 2020 at 12:18, Christian Zigotzky
> > wrote:
> >> Hi All,
> >>
> >> We still need the attached patch for our onboard SD card interface
> >> [1,2]. Could you please add this pa
Currently access to perf_events, i915_perf and other performance monitoring and
observability subsystems of the kernel is open for a privileged process [1] with
CAP_SYS_ADMIN capability enabled in the process effective set [2].
This patch set introduces CAP_PERFMON capability designed to secure
IMC(In-memory Collection Counters) does performance monitoring in
two different modes, i.e accumulation mode(core-imc and thread-imc events),
and trace mode(trace-imc events). A cpu thread can either be in
accumulation-mode or trace-mode at a time and this is done via the LDBAR
register in POWER ar
commit <249fad734a25> ""powerpc/perf: Disable trace_imc pmu"
disables IMC(In-Memory Collection) trace-mode in kernel, since frequent
mode switching between accumulation mode and trace mode via the spr LDBAR
in the hardware can trigger a checkstop(system crash).
Patch to re-enable imc-trace mode in
On 20.01.20 10:14, David Hildenbrand wrote:
> On 20.01.20 08:48, Michal Hocko wrote:
>> On Fri 17-01-20 08:57:51, Dan Williams wrote:
>> [...]
>>> Unless the user is willing to hold the device_hotplug_lock over the
>>> evaluation then the result is unreliable.
>>
>> Do we want to hold the device_ho
Am 16.01.20 um 16:46 schrieb Ulf Hansson:
On Thu, 16 Jan 2020 at 12:18, Christian Zigotzky wrote:
Hi All,
We still need the attached patch for our onboard SD card interface
[1,2]. Could you please add this patch to the tree?
No, because according to previous discussion that isn't the correct
On 20.01.20 08:48, Michal Hocko wrote:
> On Fri 17-01-20 08:57:51, Dan Williams wrote:
> [...]
>> Unless the user is willing to hold the device_hotplug_lock over the
>> evaluation then the result is unreliable.
>
> Do we want to hold the device_hotplug_lock from this user readable file
> in the fi
From: Ram Pai
Some pkeys which are valid on the hardware are reserved
and not available for application use. These keys cannot
be allocated.
test_pkey_alloc_exhaust() tries to account for these and
has an assertion which validates if all available pkeys
have been exahaustively allocated. However
From: Ram Pai
For the pkeys subsystem to work, both the CPU and the
kernel need to have support. So, additionally check if
the kernel supports pkeys apart from the CPU feature
checks.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Sandipan Das
---
tools/testing/sel
From: Ram Pai
Detect write-violation on a page to which access-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/protection_keys.c | 13 +++
From: Thiago Jung Bauermann
In preparation for multi-arch support, move definitions which
have arch-specific values to x86-specific header.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Acked-by: Dave Hansen
Signed-off-by: Sandipan Das
---
From: Ram Pai
alloc_random_pkey() was allocating the same pkey every
time. Not all pkeys were geting tested. This fixes it.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/protection_keys.c | 3 ++-
From: Ram Pai
This introduces some generic abstractions and provides
the corresponding architecture-specfic implementations
for these abstractions.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Sandipan Das
---
tools/testing/s
The size of the pkey register can vary across architectures.
This converts the data type of all its references to u64 in
preparation for multi-arch support.
To keep the definition of the u64 type consistent and remove
format specifier related warnings, __SANE_USERSPACE_TYPES__
is defined as sugges
From: Ram Pai
Ensure that pkey-0 is allocated on start and that it can
be attached dynamically in various modes, without failures.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/protection_keys.c | 53
From: Ram Pai
Some platforms hardcode the x86 values for PKEY_DISABLE_ACCESS
and PKEY_DISABLE_WRITE such as those in:
/usr/include/bits/mman-shared.h.
This overrides the definitions with correct values for powerpc.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: San
From: Ram Pai
Detect write-violation on a page to which write-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/protection_keys.c | 12
From: Thiago Jung Bauermann
This will help us ensure we print pkey_reg_t values correctly in
different architectures.
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/pkey-helpers.h | 4
1 file changed, 4 insertions(+)
diff --git a/tools/te
This introduces some functions that help with setting
or clearing bits of a particular pkey. This also adds
an abstraction for getting a pkey's bit position in
the pkey register as this may vary across architectures.
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/pkey-helpers.h|
From: Ram Pai
Currently, pkey_disable_clear() sets the specified bits
instead clearing them. This has been dead code up to now
because its only callers i.e. pkey_access/write_allow()
are also unused.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
Signed-off-b
From: Ram Pai
This makes use of the abstractions added earlier and
introduces support for powerpc.
For powerpc, after receiving the SIGSEGV, the signal
handler must explicitly restore access permissions
for the faulting pkey to allow the test to continue.
As this makes use of pkey_access_allow()
Both 4K and 64K pages are supported on powerpc. Parts of
the selftest code perform alignment computations based on
the PAGE_SIZE macro which is currently hardcoded to 64K
for powerpc. This causes some test failures on kernels
configured with 4K page size.
In some cases, we need to enforce function
From: "Desnes A. Nunes do Rosario"
The number of reserved pkeys in a PowerNV environment is
different from that on PowerVM or KVM.
Tested on PowerVM and PowerNV environments.
Signed-off-by: "Desnes A. Nunes do Rosario"
Signed-off-by: Ram Pai
Signed-off-by: Sandipan Das
---
tools/testing/sel
From: Ram Pai
In some cases, a pkey's bits need not necessarily change
in a way that the value of the pkey register increases
when performing a pkey_disable_set() or decreases when
performing a pkey_disable_clear().
For example, on powerpc, if a pkey's current state is
PKEY_DISABLE_ACCESS and we
From: Ram Pai
This introduces a new allocator that allocates 4K hardware
pages to back 64K linux pages. This allocator is available
only on powerpc.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Sandipan Das
---
tools/testing/
From: Ram Pai
Detect access-violation on a page to which access-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
Signed-off: Sandipan Das
---
tools/testing/selftests/vm/protection_keys.c | 19 +
From: Ram Pai
This renames PKRU references to "pkey_reg" or "pkey" based on
the usage.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Dave Hansen
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/pkey-helpers.h| 85
The huge page size can vary across architectures. This will
ensure that the correct huge page size is used when accessing
the hugetlb controls under sysfs. Instead of using a hardcoded
page size (i.e. 2MB), this now uses the HPAGE_SIZE macro which
is arch-specific.
Signed-off-by: Sandipan Das
---
From: Ram Pai
Moved all the generic definition and helper functions to the
header file.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Acked-by: Dave Hansen
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/pkey-helpers.h| 35 ++
This ensures that both 32-bit and 64-bit binaries are generated
when this is built on a x86_64 system. Most of the changes have
been borrowed from tools/testing/selftests/x86/Makefile.
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/Makefile | 49 +
1 file
From: Ram Pai
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Acked-by: Ingo Molnar
Acked-by: Dave Hansen
Signed-off-by: Sandipan Das
---
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile
Memory protection keys enables an application to protect its address
space from inadvertent access by its own code.
This feature is now enabled on powerpc and has been available since
4.16-rc1. The patches move the selftests to arch neutral directory
and enhance their test coverage.
Tested on pow
Le 24/12/2019 à 06:55, 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
83 matches
Mail list logo
