> On 14-May-2022, at 12:02 AM, Ian Rogers wrote:
>
> On Thu, May 12, 2022 at 11:16 PM Disha Goel
> wrote:
>>
>>
>>
>> -Original Message-
>> From: Athira Rajeev
>> To: a...@kernel.org, jo...@kernel.org
>> Cc: m...@ellerman.id.au, linux-perf-us...@vger.kernel.org,
>>
> On 14-May-2022, at 12:03 AM, Ian Rogers wrote:
>
> On Thu, May 12, 2022 at 11:18 PM Disha Goel
> wrote:
>>
>>
>>
>> -Original Message-
>> From: Athira Rajeev
>> To: a...@kernel.org, jo...@kernel.org
>> Cc: m...@ellerman.id.au, linux-perf-us...@vger.kernel.org,
>>
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: 56b3480a475656b67f52507c635b5c7113e74f9e powerpc/ci: Drop travis
configuration
elapsed time: 3831m
configs tested: 107
configs skipped: 4
The following configs have been built successfully.
More
On Wed, 2022-05-18 at 20:13 -0700, Jakub Kicinski wrote:
> Looks like almost all changes to this driver had been tree-wide
> refactoring since git era begun. There is one commit from Al
> 15 years ago which could potentially be fixing a real bug.
>
> The driver is using virt_to_bus() and is a
On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote:
> to build without PCI to see what happens.
If you bring any of the "heuristic" and palette support code in, you
need PCI. I don't see any reason to take it out.
> Those old Macs use BootX, right? BootX is not supported ATM, as I don't
On Thu, 2022-05-19 at 09:11 +0200, Geert Uytterhoeven wrote:
> Hi Michal,
>
>
>
> On Wed, May 18, 2022 at 8:54 PM Michal Suchánek
> wrote:
>
> > On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote:
> > > --- a/drivers/gpu/drm/tiny/Kconfig
> > > +++ b/drivers/gpu/drm/tiny/Kconfig
Excerpts from Paul E Murphy's message of May 21, 2022 12:21 am:
>
>
> On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
>> This takes the arm64 file and adjusts it for powerpc. Feature
>> descriptions are vaguely handwaved by me.
>> ---
>>
>> Anybody care to expand on or correct the meaning
On Thu, May 19, 2022 at 01:35:47AM +0530, Vaibhav Jain wrote:
> Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
> ima-kexec-buffer lies outside the addressable memory range. This can result
> in a kernel panic if the new kernel is booted with 'mem=X' arg and the
>
On 5/20/22 04:36, Maninder Singh wrote:
As of now sprint_* APIs don't pass buffer size as an argument
and use sprintf directly.
To replace dangerous sprintf API to scnprintf,
buffer size is required in arguments.
Co-developed-by: Onkarnath
Signed-off-by: Onkarnath
Signed-off-by: Maninder
Baoquan He writes:
> On 05/19/22 at 12:59pm, Eric W. Biederman wrote:
>> Baoquan He writes:
>>
>> > Hi Eric,
>> >
>> > On 05/18/22 at 04:59pm, Eric W. Biederman wrote:
>> >> "Naveen N. Rao" writes:
>> >>
>> >> > Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
>> >> >
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
guest control of one or more virtual watchdog timers. The timers have
millisecond granularity. The guest is terminated when a timer
expires.
This patch adds a watchdog driver for these timers, "pseries-wdt".
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
guest control of one or more virtual watchdog timers.
These timers do not conform to PowerPC device conventions. They are
not affixed to any extant bus, nor do they have full representation in
the device tree.
As a
PAPR v2.12 specifies a new optional function set, "hcall-watchdog",
for the /rtas/ibm,hypertas-functions property. The presence of this
function set indicates support for the H_WATCHDOG hypercall.
Check for this function set and, if present, set the new
FW_FEATURE_WATCHDOG flag.
Signed-off-by:
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
guest control of one or more virtual watchdog timers.
Add the opcode for the H_WATCHDOG hypercall to hvcall.h. While here,
add a definition for H_NOOP, a possible return code for H_WATCHDOG.
Signed-off-by: Scott Cheloha
---
This series is preceded by two RFCs:
RFC v1:
https://lore.kernel.org/linux-watchdog/20220413165104.179144-1-chel...@linux.ibm.com/
RFC v2:
https://lore.kernel.org/linux-watchdog/20220509174357.5448-1-chel...@linux.ibm.com/
Changes of note from RFC v2:
- Separate platform device registration
On Fri, May 20, 2022 at 1:50 AM Palmer Dabbelt wrote:
>
> On Tue, 05 Apr 2022 00:12:54 PDT (-0700), guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > Currently, most 64-bit architectures (x86, parisc, powerpc, arm64,
> > s390, mips, sparc) have supported COMPAT mode. But they all have
> >
Stephen Rothwell wrote:
Hi all,
Today's linux-next bboot of the powerpc pseries_le_defconfig build
produced these different kernel messages (diff from yesterday's tree):
- ftrace: allocating 33658 entries in 13 pages
- ftrace: allocated 13 pages with 3 groups
+ ftrace-powerpc: Address of
On Fri, May 20, 2022 at 09:21:43AM -0500, Paul E Murphy wrote:
> >+PPC_FEATURE_HAS_ALTIVEC
> >+Vector (aka Altivec, VSX) facility is available.
>
> I think "(aka Altivec, VSX)" might be more accurately stated as "(aka
> Altivec)"?
"Also known as AltiVec or VMX", yes.
>
On 5/20/22 10:20, Scott Cheloha wrote:
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
guest control of one or more virtual watchdog timers.
Add the opcode for the H_WATCHDOG hypercall to hvcall.h. While here,
add a definition for H_NOOP, a possible return code for
On Fri, 20 May 2022 12:54:56 + Christophe Leroy wrote:
> Le 20/05/2022 à 14:35, Måns Rullgård a écrit :
> > Christophe Leroy writes:
> >> See original commit 070e1f01827c. It explicitely says that the cache
> >> must be invalidate _AFTER_ the copy.
> >>
> >> The cache is initialy invalidated
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
guest control of one or more virtual watchdog timers. The timers have
millisecond granularity. The guest is terminated when a timer
expires.
This patch adds a watchdog driver for these timers, "pseries-wdt".
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
guest control of one or more virtual watchdog timers.
These timers do not conform to PowerPC device conventions. They are
not affixed to any extant bus, nor do they have full representation in
the device tree.
As a
PAPR v2.12 specifies a new optional function set, "hcall-watchdog",
for the /rtas/ibm,hypertas-functions property. The presence of this
function set indicates support for the H_WATCHDOG hypercall.
Check for this function set and, if present, set the new
FW_FEATURE_WATCHDOG flag.
Signed-off-by:
PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits
guest control of one or more virtual watchdog timers.
Add the opcode for the H_WATCHDOG hypercall to hvcall.h. While here,
add a definition for H_NOOP, a possible return code for H_WATCHDOG.
Signed-off-by: Scott Cheloha
---
On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
> +PPC_FEATURE_HAS_ALTIVEC
> +Vector (aka Altivec, VSX) facility is available.
Slight typo. s/VSX/VMX/
Peter
Le 20/05/2022 à 17:57, Laurent Dufour a écrit :
> There is no need to read the H_BLOCK_REMOVE characteristics when running in
> Radix mode because this hcall is never called.
>
> Signed-off-by: Laurent Dufour
> ---
> arch/powerpc/platforms/pseries/setup.c | 3 ++-
> 1 file changed, 2
There is no need to read the H_BLOCK_REMOVE characteristics when running in
Radix mode because this hcall is never called.
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/setup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
This takes the arm64 file and adjusts it for powerpc. Feature
descriptions are vaguely handwaved by me.
---
Anybody care to expand on or correct the meaning of these entries or
bikeshed the wording of the intro? Many of them are no longer
Queued, thanks.
Paolo
The convention for indentation seems to be a single tab. Help text is
further indented by an additional two whitespaces. Fix the lines that
violate these rules.
Signed-off-by: Juerg Haefliger
---
arch/powerpc/kvm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Replace single quotes with double quotes which seems to be the convention
for strings.
Signed-off-by: Juerg Haefliger
---
arch/powerpc/platforms/powernv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/Kconfig
Em Thu, May 19, 2022 at 11:45:07AM -0700, Ian Rogers escreveu:
> On Thu, May 19, 2022 at 8:43 AM Athira Rajeev
> wrote:
> >
> > "perf all PMU test" picks the input events from
> > "perf list --raw-dump pmu" list and runs "perf stat -e"
> > for each of the event in the list. In case of powerpc,
Hi all,
Today's linux-next bboot of the powerpc pseries_le_defconfig build
produced these different kernel messages (diff from yesterday's tree):
- ftrace: allocating 33658 entries in 13 pages
- ftrace: allocated 13 pages with 3 groups
+ ftrace-powerpc: Address of ftrace_regs_caller out of range
Le 20/05/2022 à 14:35, Måns Rullgård a écrit :
> Christophe Leroy writes:
>
>> Le 19/05/2022 à 21:24, Mans Rullgard a écrit :
>>> The dma_sync_single_for_cpu() call must precede reading the received
>>> data. Fix this.
>>
>> See original commit 070e1f01827c. It explicitely says that the cache
Christophe Leroy writes:
> Le 19/05/2022 à 21:24, Mans Rullgard a écrit :
>> The dma_sync_single_for_cpu() call must precede reading the received
>> data. Fix this.
>
> See original commit 070e1f01827c. It explicitely says that the cache
> must be invalidate _AFTER_ the copy.
>
> The cache is
Processors with coherent icache require the sequence sync ; icbi ; isync
to entire store->execute coherency. icbi (to any address) must be
executed to ensure isync flushes the pipeline. See "POWER9 Processor
User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi)" for
details.
On Thu, May 19, 2022 at 4:13 AM Jakub Kicinski wrote:
>
> Looks like almost all changes to this driver had been tree-wide
> refactoring since git era begun. There is one commit from Al
> 15 years ago which could potentially be fixing a real bug.
>
> The driver is using virt_to_bus() and is a real
+ linux-mm
Do you know what are requirements for kernel to support non-contiguous
memory support and what is needed to enable it for 32-bit powerpc?
Currently powerpc arch code does not support "memblock.memory.cnt > 1"
except for WII which seems like a hack... See below.
On Friday 20 May 2022
Alan Modra wrote:
On Tue, May 17, 2022 at 10:32:09PM +1000, Michael Ellerman wrote:
"Naveen N. Rao" writes:
> Michael Ellerman wrote:
>>
>> diff --git a/arch/powerpc/kernel/vdso/gettimeofday.S
b/arch/powerpc/kernel/vdso/gettimeofday.S
>> index eb9c81e1c218..0aee255e9cbb 100644
>> ---
Excerpts from Michael Ellerman's message of May 20, 2022 7:21 pm:
> Nicholas Piggin via Libc-alpha writes:
>> This takes the arm64 file and adjusts it for powerpc. Feature
>> descriptions are vaguely handwaved by me.
>> ---
>
> Thanks for attempting to document this.
It was mainly copy and
On 19/05/2022 20:45, Baoquan He wrote:
> [...]
>> I really appreciate the summary skill you have, to convert complex
>> problems in very clear and concise ideas. Thanks for that, very useful!
>> I agree with what was summarized above.
>
> I want to say the similar words to Petr's reviewing
Vaibhav Jain writes:
>
> [PATCH] powerpc: check previous kernel's ima-kexec-buffer against memory
> bounds
This isn't a powerpc patch, the subject should start with "of:".
> Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
> ima-kexec-buffer lies outside the addressable
On 05/19/22 at 12:59pm, Eric W. Biederman wrote:
> Baoquan He writes:
>
> > Hi Eric,
> >
> > On 05/18/22 at 04:59pm, Eric W. Biederman wrote:
> >> "Naveen N. Rao" writes:
> >>
> >> > Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> >> > symbols") [1], binutils (v2.36+)
On 20/5/22 18:04, Pali Rohár wrote:
> On Friday 20 May 2022 13:41:04 Ash Logan wrote:
>> On 14/5/22 08:43, Pali Rohár wrote:
>>> On Wednesday 02 March 2022 15:44:05 Ash Logan wrote:
pgtable_32.c:mapin_ram loops over each valid memory range, which means
non-contiguous memory just works.
Jakub Kicinski writes:
> Looks like almost all changes to this driver had been tree-wide
> refactoring since git era begun. There is one commit from Al
> 15 years ago which could potentially be fixing a real bug.
>
> The driver is using virt_to_bus() and is a real magnet for pointless
> cleanups.
Brian W Hart writes:
> On Thu, May 19, 2022 at 12:26:29AM +1000, Michael Ellerman wrote:
>> Rather than waiting for the bots to fix these one-by-one, fix all
>> occurences of "the the" throughout arch/powerpc.
...
>> diff --git a/arch/powerpc/platforms/chrp/setup.c
>>
"Oliver O'Halloran" writes:
> On Thu, May 19, 2022 at 10:38 PM Michael Ellerman wrote:
>> Christophe Leroy writes:
>> > Le 02/09/2020 à 05:51, Oliver O'Halloran a écrit :
>> >> The MPS field in the VF config space is marked as reserved in current
>> >> versions of the SR-IOV spec. In other
"perf all PMU test" picks the input events from
"perf list --raw-dump pmu" list and runs "perf stat -e"
for each of the event in the list. In case of powerpc, the
PowerVM environment supports events from hv_24x7 and hv_gpci
PMU which is of example format like below:
-
Nicholas Piggin via Libc-alpha writes:
> This takes the arm64 file and adjusts it for powerpc. Feature
> descriptions are vaguely handwaved by me.
> ---
Thanks for attempting to document this.
> Anybody care to expand on or correct the meaning of these entries or
> bikeshed the wording of the
From: Kajol Jain
The testcase checks if the transalation of a generic hardware cache
event is done properly via perf interface. The hardware cache events
has type as PERF_TYPE_HW_CACHE and each event points to raw event
code id.
Testcase checks different combination of cache level,
cache event
From: Kajol Jain
Thresh select bits in the event code is used to program thresh_sel
field in Monitor Mode Control Register A (MMCRA: 45-47). When scheduling
events as a group, all events in that group should match value in these
bits. Otherwise event open for the sibling events will fail.
From: Kajol Jain
Thresh control bits in the event code is used to program thresh_ctl
field in Monitor Mode Control Register A (MMCRA: 48-55). When scheduling
events as a group, all events in that group should match value in these
bits. Otherwise event open for the sibling events will fail.
From: Kajol Jain
Unit and pmu bits in the event code is used to program unit and pmc
fields in Monitor Mode Control Register 1 (MMCR1). For power9 platform,
incase unit field value is within 6 to 9, one of the event in the group
should use PMC4. Otherwise event_open should fail for that group.
From: Kajol Jain
Thresh compare bits for a event is used to program thresh compare
field in Monitor Mode Control Register A (MMCRA: 9-18 bits for
power9 and MMCRA: 8-18 bits for power10). When scheduling events
as a group, all events in that group should match value in
thresh compare bits.
From: Kajol Jain
Data and instruction cache qualifier bits in the event code is
used to program cache select field in Monitor Mode Control
Register 1 (MMCR1: 16-17). When scheduling events as a group, all
events in that group should match value in these bits. Otherwise
event open for the sibling
From: Kajol Jain
In power10, L2L3 select bits in the event code is used to
program l2l3_sel field in Monitor Mode Control Register 0
(MMCR0: 56-60). When scheduling events as a group,
all events in that group should match value in these bits.
Otherwise event open for the sibling events will
Testcase to ensure that using invalid event in generic
event for PERF_TYPE_HARDWARE will fail. Invalid generic
events in power10 are:
- PERF_COUNT_HW_BUS_CYCLES
- PERF_COUNT_HW_STALLED_CYCLES_FRONTEND
- PERF_COUNT_HW_STALLED_CYCLES_BACKEND
- PERF_COUNT_HW_REF_CPU_CYCLES
Invalid generic events in
Platform specific PMU supports alternative event for some
of the event codes. During perf_event_open, it any event
group doesn't match constraint check criteria, further lookup
is done to find alternative event. Code checks to see if
it is possible to schedule event as group using alternative
Platform specific PMU supports alternative event for some
of the event codes. During perf_event_open, it any event
group doesn't match constraint check criteria, further lookup
is done to find alternative event. Code checks to see if
it is possible to schedule event as group using alternative
Some of the events are blacklisted in power9. The list
of blacklisted events are noted in power9-events-list.h
When trying to do event open for any of these blacklisted
event will cause a failure. Testcase ensures that using
blacklisted events will cause event_open to fail in power9.
This test is
Testcase for reserved bits in Monitor Mode
Control Register A (MMCRA) thresh_ctl bits.
For MMCRA[48:51]/[52:55]) Threshold Start/Stop,
0b/0b is reserved.
Signed-off-by: Athira Rajeev
---
.../powerpc/pmu/event_code_tests/Makefile | 2 +-
Some of the bits in the event code is reserved
for specific platforms. Event code bits 52-59 are
reserved in power9, whereas in power10, these are used
for programming Monitor Mode Control Register 3 (MMCR3).
Bit 9 in event code is reserved in power9, whereas it
is used for programming
Events with different "sample" field values which is
used to program Monitor Mode Control Register A (MMCRA)
in a group will fail to schedule. Testcase uses event with
load only sampling mode as group leader and event with
store only sampling as sibling event. So that it can check
that using
Testcase for reserved bits in Monitor Mode Control
Register A (MMCRA) Random Sampling Mode (SM) value.
As per Instruction Set Architecture (ISA), the values
0x5, 0x9, 0xD, 0x19, 0x1D, 0x1A, 0x1E are reserved
for sampling mode field. Test that having these reserved
bit values should cause
Testcase for group constraint check for radix_scope_qual
field which is used to program Monitor Mode Control Register
(MMCR1) bit 18. All events in the group should match radix_scope_qual
bit, otherwise event_open for the group should fail. Testcase uses
"0x14242"
Testcase for group constraint check when using events
with same PMC. Multiple events in a group asking for
same PMC should fail. Testcase uses "0x22C040" on PMC2
as leader and also subling which is expected to fail.
Using PMC1 for sibling event should pass the test.
Signed-off-by: Athira Rajeev
Testcase for group constraint check for number of
counters in use. The number of programmable counters
is from PMC1 to PMC4. Testcase uses four events with PMC1
to PMC4 and 5th event without any PMC which is expected to fail
since it is exceeding the number of counters in use.
Signed-off-by:
Events using Performance Monitor Counter 5 (PMC5) and
Performance Monitor Counter 6 (PMC6) should be excluded
from constraint check when scheduled along with group of
events. Example, combination of PMC5, PMC6, and an event
with cache bit will succeed to schedule though first two
events doesn't
Events using Performance Monitor Counter 5 (PMC5) and
Performance Monitor Counter 6 (PMC6) can't have other fields in
event code like cache bits, thresholding or marked bit. PMC5 and PMC6
only supports base events: ie 500fa and 600f4. Other combinations
should fail. Testcase tries setting other
Add new folder for enabling perf event code tests which
includes checking for group constraints, valid/invalid events,
also checks for event excludes, alternatives so on. A new folder
"event_code_tests", is created under "selftests/powerpc/pmu".
Also updates the corresponding Makefiles in
From: Kajol Jain
The testcase uses "instructions" event to generate the
samples and fetch Monitor Mode Control Register A (MMCRA)
when overflow. Branch History Rolling Buffer(bhrb) disable bit
is part of MMCRA which need to be verified by perf interface.
Incase sample is not of branch type, bhrb
The testcase uses event code "0x21c040" to verify
the settings for different fields in Monitor Mode Control
Register 1 (MMCR1). The fields include PMCxSEL, PMCXCOMB
PMCxUNIT, cache. Checks if these fields are translated
correctly via perf interface to MMCR1
Signed-off-by: Athira Rajeev
---
For PERF_SAMPLE_BRANCH_STACK sample type, different
branch_sample_type, ie branch filters are supported.
All the branch filters are not supported in powerpc.
Example, power10 platform supports any, ind_call and
cond branch filters. Whereas, it is different in power9.
Testcase checks event open for
With sampling, --intr-regs option is used for capturing
interrupt regs. When --intr-regs option is used, PMU code
uses is_sier_available() function which uses PMU flags in
the code. In environment where platform specific PMU is
not registered, PMU flags is not defined. A fix was added
in kernel to
While enabling branch stack for an event, BHRB (Branch History
Rolling Buffer) filter is set using bhrb_filter_map() callback.
This callback is not defined for cases like generic_compat_pmu
or in case where there is no PMU registered. A fix was added
in kernel to address a crash issue observed
The platform check for selftest support "check_pvr_for_sampling_tests"
is specific to sampling tests which includes PVR check, presence of
PMU and extended regs support. Extended regs support is needed for
sampling tests which tests whether PMU registers are programmed
correctly. There could be
From: Kajol Jain
The testcase uses "instructions" event to generate the
samples and fetch Monitor Mode Control Register A (MMCRA)
when overflow. Branch History Rolling Buffer(bhrb) disable bit
is part of MMCRA which need to be verified by perf interface.
Testcase checks if the bhrb disable bit
From: Kajol Jain
The testcase uses "instructions" event to check if the
Instruction filtering mode(IFM) bits are programmed correctly
for conditional branch type. Testcase checks if IFM bits is
programmed correctly to Monitor Mode Control Register A (MMCRA)
via perf interface for ISA v3.1
From: Kajol Jain
The testcase uses "instructions" event to check if the
Instruction filtering mode(IFM) bits are programmed correctly
for type any branch. Testcase checks if IFM bits is
programmed correctly to Monitor Mode Control Register A (MMCRA)
via perf interface.
Signed-off-by: Kajol Jain
From: Kajol Jain
The testcase uses "instructions" event to check if the
Instruction filtering mode(IFM) bits are programmed correctly
for indirect branch type. Testcase checks if IFM bits are
programmed correctly to Monitor Mode Control Register A (MMCRA)
via perf interface for ISA v3.1
From: Kajol Jain
Add support for sample type as PERF_SAMPLE_BRANCH_STACK in sampling
tests. This change is a precursor/helper for sampling testcases, that
test branck stack feature in perf interface.
Signed-off-by: Kajol Jain
---
.../powerpc/pmu/sampling_tests/misc.c | 21
From: Kajol Jain
The testcase uses event code 0x35340401e0 for load
only sampling, to verify the settings of thresh compare field
in Monitor Mode Control Register A (MMCRA: 9-18 bits for power9
and MMCRA: 8-18 bits for power10). Testcase checks if the thresh compare
field is programmed correctly
The /proc/self/auxv contains information about "platform" on any
system. Also "base platform" which is an indication about platform
string corresponding to the real PVR. When systems are booted in
compat mode, say, power10 booted in power9 mode, "platform" will
point to power9 whereas base
From: Kajol Jain
In power10, threshold compare field is not part of the raw
event code and provided via event attribute config1.
Hence add the mask and shift bits based on event attribute
config1, to extract the threshold compare value for power10
Also add a new function called
Patch series extends the perf interface selftests
to cover scenarios for event code checking,
group constraints, and also thresholding/branch related
interface tests in sampling area.
In this series, patches 1 to 14 adds additional tests under
"powerpc/sampling_tests". These adds support for
Although *lookup* APIs are safe, but better to pass size
as an argument rather than using define KSYM_NAME_LEN.
Because it can cause issue if called with lesser array size.
Co-developed-by: Onkarnath
Signed-off-by: Onkarnath
Signed-off-by: Maninder Singh
---
arch/hexagon/kernel/traps.c
with commit '7878c231dae0 ("slab: remove /proc/slab_allocators")'
lookup_symbol_attrs usage is removed.
Thus removing redundant API.
Signed-off-by: Maninder Singh
---
include/linux/kallsyms.h | 6 --
include/linux/module.h | 6 --
kernel/kallsyms.c| 28
Details is added about "caps" attribute group in the ABI documentation.
This is used to expose some of the PMU attributes in "caps"
directory under : /sys/bus/event_source/devices//. The dev/caps
will contain information about features that platform specific PMU
supports.
Signed-off-by: Athira
Add caps support under "/sys/bus/event_source/devices//"
for powerpc. This directory can be used to expose some of the
specific features that powerpc PMU supports to the user.
Example: pmu_name. The name of PMU registered will depend on
platform, say power9 or power10 or it could be Generic Compat
kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
writes on index "KSYM_NAME_LEN - 1".
Thus array size should be KSYM_NAME_LEN.
for powerpc and hexagon it was defined as "128" directly.
and commit '61968dbc2d5d' changed define value to 512,
So both were missed to update with new
As of now sprint_* APIs don't pass buffer size as an argument
and use sprintf directly.
To replace dangerous sprintf API to scnprintf,
buffer size is required in arguments.
Co-developed-by: Onkarnath
Signed-off-by: Onkarnath
Signed-off-by: Maninder Singh
---
arch/s390/lib/test_unwind.c|
replace sprintf API with scnprintf which prevents buffer overflow.
Co-developed-by: Onkarnath
Signed-off-by: Onkarnath
Signed-off-by: Maninder Singh
---
kernel/kallsyms.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
kallsyms functionality depends on KSYM_NAME_LEN directly.
but if user passed array length lesser than it, sprintf
can cause issues of buffer overflow attack.
So changing *sprint* and *lookup* APIs in this patch set
to have buffer size as an argument and replacing sprintf with
scnprintf.
patch 1
On Friday 20 May 2022 13:41:04 Ash Logan wrote:
> On 14/5/22 08:43, Pali Rohár wrote:
> > On Wednesday 02 March 2022 15:44:05 Ash Logan wrote:
> >> pgtable_32.c:mapin_ram loops over each valid memory range, which means
> >> non-contiguous memory just works.
> >
> > Hello! Does it mean that
> On 20-May-2022, at 12:15 AM, Ian Rogers wrote:
>
> On Thu, May 19, 2022 at 8:43 AM Athira Rajeev
> wrote:
>>
>> "perf all PMU test" picks the input events from
>> "perf list --raw-dump pmu" list and runs "perf stat -e"
>> for each of the event in the list. In case of powerpc, the
>>
Hello Thomas,
On 5/18/22 20:30, Thomas Zimmermann wrote:
>
> +config DRM_OFDRM
> + tristate "Open Firmware display driver"
> + depends on DRM && MMU && PPC
Shouldn't depend on OF? I mean, is a DRM driver for Open Firmware after all :)
I know that the old drivers/video/fbdev/offb.c
> On 20-May-2022, at 3:06 AM, Ian Rogers wrote:
>
> On Thu, May 19, 2022 at 4:29 AM Athira Rajeev
> wrote:
>>
>>> On 19-May-2022, at 10:12 AM, Ian Rogers wrote:
>>>
>>> On Wed, May 18, 2022 at 1:55 AM Athira Rajeev
>>> wrote:
Add caps support under
97 matches
Mail list logo
