"Aneesh Kumar K.V" writes:
> From: Peter Zijlstra
>
> Towards a more consistent naming scheme.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Signed-off-by: Aneesh Kumar K.V
...
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index 18e9fb6fcf1b..c703eb6b7461 100644
> --- a/arch/sparc/K
On Thu, Jan 16, 2020 at 11:11 PM Shengjiu Wang wrote:
>
> Hi
>
> On Thu, Jan 16, 2020 at 1:56 PM John Stultz wrote:
> >
> > On Wed, Jan 8, 2020 at 8:58 PM John Stultz wrote:
> > > On Thu, Sep 26, 2019 at 6:50 PM Shengjiu Wang
> > > wrote:
> > > >
> > > > When set the runtime hardware parameter
Hi Gustavo,
Thanks for fixing that TM issue.
On 01/16/2020 07:05 PM, Gustavo Luiz Duarte wrote:
Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal
context")
Cc: sta...@vger.kernel.org # v3.9
Signed-off-by: Gustavo Luiz Duarte
---
arch/powerpc/kernel/signal.c
On 17.01.2020 13:51, Will Deacon wrote:
> On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote:
>>
>> Open access to monitoring for CAP_SYS_PERFMON privileged processes.
>> For backward compatibility reasons access to the monitoring remains open
>> for CAP_SYS_ADMIN privileged processe
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #286869|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #13 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 286871
--> https://bugzilla.kernel.org/attachment.cgi?id=286871&action=edit
kernel .config (5.5-rc6, KASAN_VMALLOC + INLINE KASAN, PowerMac G4 DP))
--
You are receivi
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #12 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 286869
--> https://bugzilla.kernel.org/attachment.cgi?id=286869&action=edit
dmesg (kernel 5.5-rc6+, INLINE KASAN, PowerMac G4 DP)
However I might have gotten a hint wh
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #11 from Erhard F. (erhar...@mailbox.org) ---
Applied your patch series on top of 5.5-rc6. CONFIG_KASAN_VMALLOC is not
non-selectable but forced on by default.
Current situation is that the hit does not show up with INLINE KASAN in
ra
On 01/16/2020 07:05 PM, Gustavo Luiz Duarte wrote:
The test case tm-signal-context-force-tm expects a segfault to happen on
returning from signal handler, and then does a setcontext() to run the test
again. However, the test doesn't always segfault, causing the test to run a
single time.
This pa
Hi Gustavo,
Nice catch on using userfaultfd() to make it deterministic.
On 01/16/2020 07:05 PM, Gustavo Luiz Duarte wrote:
This test triggers a TM Bad Thing by raising a signal in transactional state
and forcing a pagefault to happen in kernelspace when the kernel signal
handling code first tou
https://bugzilla.kernel.org/show_bug.cgi?id=205283
--- Comment #12 from Erhard F. (erhar...@mailbox.org) ---
Applied your patch series on top of 5.5-rc6. CONFIG_KASAN_VMALLOC is not
non-selectable but forced on by default.
Current situation is that the hit does not show up with KASAN and btrs mod
https://bugzilla.kernel.org/show_bug.cgi?id=205283
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #286385|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=205283
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #286387|0 |1
is obsolete|
On 1/17/20 4:49 AM, Sandipan Das wrote:
> 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 directo
On Fri, Jan 17, 2020 at 8:11 AM David Hildenbrand wrote:
>
> On 17.01.20 16:54, Dan Williams wrote:
> > On Fri, Jan 17, 2020 at 7:30 AM Michal Hocko wrote:
> >>
> >> On Fri 17-01-20 15:58:26, David Hildenbrand wrote:
> >>> On 17.01.20 15:52, Michal Hocko wrote:
> On Fri 17-01-20 14:08:06, Da
On Fri, Jan 17, 2020 at 06:16:19PM +0530, Kajol Jain wrote:
> Patch enhances current metric infrastructure to handle "?" in the metric
> expression. The "?" can be use for parameters whose value not known while
> creating metric events and which can be replace later at runtime to
> the proper value
On 17.01.20 16:54, Dan Williams wrote:
> On Fri, Jan 17, 2020 at 7:30 AM Michal Hocko wrote:
>>
>> On Fri 17-01-20 15:58:26, David Hildenbrand wrote:
>>> On 17.01.20 15:52, Michal Hocko wrote:
On Fri 17-01-20 14:08:06, David Hildenbrand wrote:
> On 17.01.20 12:33, Michal Hocko wrote:
On Fri, Jan 17, 2020 at 7:30 AM Michal Hocko wrote:
>
> On Fri 17-01-20 15:58:26, David Hildenbrand wrote:
> > On 17.01.20 15:52, Michal Hocko wrote:
> > > On Fri 17-01-20 14:08:06, David Hildenbrand wrote:
> > >> On 17.01.20 12:33, Michal Hocko wrote:
> > >>> On Fri 17-01-20 11:57:59, David Hilde
On Fri 17-01-20 15:58:26, David Hildenbrand wrote:
> On 17.01.20 15:52, Michal Hocko wrote:
> > On Fri 17-01-20 14:08:06, David Hildenbrand wrote:
> >> On 17.01.20 12:33, Michal Hocko wrote:
> >>> On Fri 17-01-20 11:57:59, David Hildenbrand wrote:
> Let's refactor that code. We want to check i
On 17.01.20 15:52, Michal Hocko wrote:
> On Fri 17-01-20 14:08:06, David Hildenbrand wrote:
>> On 17.01.20 12:33, Michal Hocko wrote:
>>> On Fri 17-01-20 11:57:59, David Hildenbrand wrote:
Let's refactor that code. We want to check if we can offline memory
blocks. Add a new function is_me
On Fri 17-01-20 14:08:06, David Hildenbrand wrote:
> On 17.01.20 12:33, Michal Hocko wrote:
> > On Fri 17-01-20 11:57:59, David Hildenbrand wrote:
> >> Let's refactor that code. We want to check if we can offline memory
> >> blocks. Add a new function is_mem_section_offlineable() for that and
> >>
On 17.01.20 12:33, Michal Hocko wrote:
> On Fri 17-01-20 11:57:59, David Hildenbrand wrote:
>> Let's refactor that code. We want to check if we can offline memory
>> blocks. Add a new function is_mem_section_offlineable() for that and
>> make it call is_mem_section_offlineable() for each contained
On Thu, 2020-01-16 at 09:44 -0800, Christoph Hellwig wrote:
> Hi Abdul,
>
> I think the problem is that mpt3sas has some convoluted logic to do
> some DMA allocations with a 32-bit coherent mask, and then switches
> to a 63 or 64 bit mask, which is not supported by the DMA API.
>
> Can you try th
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: 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
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
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 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: 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
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: 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
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: "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
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()
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 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.
Cc: Dave Hansen
Cc: Florian Wei
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
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
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
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.
cc: Dave Hansen
cc: Florian Weimer
cc: Ram Pai
cc: Thiago Jung Bauermann
Sign
From: Ram Pai
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.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Sandipan Da
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
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
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 ++
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
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
Patch enhances current metric infrastructure to handle "?" in the metric
expression. The "?" can be use for parameters whose value not known while
creating metric events and which can be replace later at runtime to
the proper value. It also add flexibility to create multiple events out
of single me
Function 'read_sys_info_pseries()' is added to get system parameter
values like number of sockets and chips per socket.
and it gets these details via rtas_call with token
"PROCESSOR_MODULE_INFO".
Incase lpar migrate from one system to another, system
parameter details like chips per sockets or num
The hv_24×7 feature in IBM® POWER9™ processor-based servers provide the
facility to continuously collect large numbers of hardware performance
metrics efficiently and accurately.
This patch adds hv_24x7 json metric file for different Socket/chip
resources.
Result:
power9 platform:
command:# ./pe
Add documentation for the following sysfs files:
/sys/devices/hv_24x7/interface/chips,
/sys/devices/hv_24x7/interface/sockets
Signed-off-by: Kajol Jain
---
.../testing/sysfs-bus-event_source-devices-hv_24x7 | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/ABI/tes
To expose the system dependent parameter like total number of
sockets and numbers of chips per socket, patch adds two sysfs files.
"sockets" and "chips" are added to /sys/devices/hv_24x7/interface/
of the "hv_24x7" pmu.
Signed-off-by: Kajol Jain
---
arch/powerpc/perf/hv-24x7.c | 22 +
For hv_24x7 socket/chip level events, specific chip-id to which
the data requested should be added as part of pmu events.
But number of chips/socket in the system details are not exposed.
Patch implements read_sys_info_pseries() to get system
parameter values like number of sockets and chips per s
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The hv_24??7 feature in IBM?? POWER9??? processor-based servers provide the
facility to continuously collect large numbers of hardware performance
metrics efficiently and accurately.
Patchset adds json file
On Fri 17-01-20 11:57:59, David Hildenbrand wrote:
> Let's refactor that code. We want to check if we can offline memory
> blocks. Add a new function is_mem_section_offlineable() for that and
> make it call is_mem_section_offlineable() for each contained section.
> Within is_mem_section_offlineable
Let's refactor that code. We want to check if we can offline memory
blocks. Add a new function is_mem_section_offlineable() for that and
make it call is_mem_section_offlineable() for each contained section.
Within is_mem_section_offlineable(), add some more sanity checks and
directly bail out if th
On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_SYS_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
> monitori
Le 17/01/2020 à 09:58, Segher Boessenkool a écrit :
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: 89
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 nsec/call
>
> The first patch adds VDSO gener
59 matches
Mail list logo
