We need r1 to be properly set before activating MMU, otherwise any new
exception taken while saving registers into the stack in syscall
prologs will use the user stack, which is wrong and will even lockup
or crash when KUAP is selected.
Do that by switching the meaning of r11 and r1 until we have saved r1
to the stack: copy r1 into r11 and setup the new stack pointer in r1.
To avoid complicating and impacting all generic and specific prolog
code (and more), copy back r1 into r11 once r11 is save onto
the stack.
We could get rid of copying r1 back and forth at the cost of rewriting
everything to use r1 instead of r11 all the way when CONFIG_VMAP_STACK
is set, but the effort is probably not worth it for now.
Fixes: da7bb43ab9 ("powerpc/32: Fix vmap stack - Properly set r1 before activating MMU")
Cc: stable@vger.kernel.org # v5.10+
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/a3d819d5c348cee9783a311d5d3f3ba9b48fd219.1608531452.git.christophe.leroy@csgroup.eu
The early ATAGS/DT mapping code uses SECTION_SHIFT to mask low order
bits of R2, and decides that no ATAGS/DTB were provided if the resulting
value is 0x0.
This means that on systems where DRAM starts at 0x0 (such as Raspberry
Pi), no explicit mapping of the DT will be created if R2 points into the
first 1 MB section of memory. This was not a problem before, because the
decompressed kernel is loaded at the base of DRAM and mapped using
sections as well, and so as long as the DT is referenced via a virtual
address that uses the same translation (the linear map, in this case),
things work fine.
However, commit 7a1be318f5 ("9012/1: move device tree mapping out of
linear region") changes this, and now the DT is referenced via a virtual
address that is disjoint from the linear mapping of DRAM, and so we need
the early code to create the DT mapping unconditionally.
So let's create the early DT mapping for any value of R2 != 0x0.
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
When linking a multi_v7_defconfig + CONFIG_KASAN=y kernel with
LD=ld.lld, the following error occurs:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
ld.lld: error: section: .exit.data is not contiguous with other relro sections
LLD defaults to '-z relro', which is unneeded for the kernel because
program headers are not used nor is there any position independent code
generation or linking for ARM. Add '-z norelro' to LDFLAGS_vmlinux to
avoid this error.
Link: https://github.com/ClangBuiltLinux/linux/issues/1189
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
The DTB magic marker is stored as a 32-bit big-endian value, and thus
depends on the CPU's endianness. Add a macro to define this value in
native endianness, to reduce #ifdef clutter and (future) duplication.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
The dbgadtb macro is passed the size of the appended DTB, not the end
address.
Fixes: c03e41470e ("ARM: 9010/1: uncompress: Print the location of appended DTB")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
DTB stores all values as 32-bit big-endian integers.
Add a macro to convert such values to native CPU endianness, to reduce
duplication.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Mapping between IPI type index and its string is direct without requiring
an additional offset. Hence the existing macro S(x, s) is now redundant
and can just be dropped. This also makes the code clean and simple.
Cc: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Macros used as functions can be problematic from the compiler perspective.
There was a build failure report caused primarily because of non reference
of an argument variable. Hence convert PUD level pgtable helper macros into
functions in order to avoid such problems in the future. In the process, it
fixes the argument variables sequence in set_pud() which probably remained
hidden for being a macro.
https://lore.kernel.org/linux-mm/202011020749.5XQ3Hfzc-lkp@intel.com/https://lore.kernel.org/linux-mm/5fa49698.Vu2O3r+dU20UoEJ+%25lkp@intel.com/
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Commit aaac373317 ("ARM: kvm: replace open coded VA->PA calculations
with adr_l call") removed all uses of .L__boot_cpu_mode_offset, so there
is no longer a need to define it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Commit f77ac2e378 ("ARM: 9030/1: entry: omit FP emulation for UND
exceptions taken in kernel mode") failed to take into account that there
is in fact a case where we relied on this code path: during boot, the
VFP detection code issues a read of FPSID, which will trigger an undef
exception on cores that lack VFP support.
So let's reinstate this logic using an undef hook which is registered
only for the duration of the initcall to vpf_init(), and which sets
VFP_arch to a non-zero value - as before - if no VFP support is present.
Fixes: f77ac2e378 ("ARM: 9030/1: entry: omit FP emulation for UND ...")
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Skirmisher reported on IRC that the 32-bit LE VDSO was hanging. This
turned out to be due to a branch to self in eg. __kernel_gettimeofday.
Looking at the disassembly with objdump -dR shows why:
00000528 <__kernel_gettimeofday>:
528: f0 ff 21 94 stwu r1,-16(r1)
52c: a6 02 08 7c mflr r0
530: f0 ff 21 94 stwu r1,-16(r1)
534: 14 00 01 90 stw r0,20(r1)
538: 05 00 9f 42 bcl 20,4*cr7+so,53c <__kernel_gettimeofday+0x14>
53c: a6 02 a8 7c mflr r5
540: ff ff a5 3c addis r5,r5,-1
544: c4 fa a5 38 addi r5,r5,-1340
548: f0 00 a5 38 addi r5,r5,240
54c: 01 00 00 48 bl 54c <__kernel_gettimeofday+0x24>
54c: R_PPC_REL24 .__c_kernel_gettimeofday
Because we don't process relocations for the VDSO, this branch remains
a branch from 0x54c to 0x54c.
With the preceding patch to prohibit R_PPC_REL24 relocations, we
instead get a build failure:
0000054c R_PPC_REL24 .__c_kernel_gettimeofday
00000598 R_PPC_REL24 .__c_kernel_clock_gettime
000005e4 R_PPC_REL24 .__c_kernel_clock_gettime64
00000630 R_PPC_REL24 .__c_kernel_clock_getres
0000067c R_PPC_REL24 .__c_kernel_time
arch/powerpc/kernel/vdso32/vdso32.so.dbg: dynamic relocations are not supported
The root cause is that we're branching to `.__c_kernel_gettimeofday`.
But this is 32-bit LE code, which doesn't use function descriptors, so
there are no dot symbols.
The reason we're trying to branch to a dot symbol is because we're
using the DOTSYM macro, but the ifdefs we use to define the DOTSYM
macro do not currently work for 32-bit LE.
So like previous commits we need to differentiate if the current
compilation unit is 64-bit, rather than the kernel as a whole. ie.
switch from CONFIG_PPC64 to __powerpc64__.
With that fixed 32-bit LE code gets the empty version of DOTSYM, which
just resolves to the original symbol name, leading to a direct branch
and no relocations:
000003f8 <__kernel_gettimeofday>:
3f8: f0 ff 21 94 stwu r1,-16(r1)
3fc: a6 02 08 7c mflr r0
400: f0 ff 21 94 stwu r1,-16(r1)
404: 14 00 01 90 stw r0,20(r1)
408: 05 00 9f 42 bcl 20,4*cr7+so,40c <__kernel_gettimeofday+0x14>
40c: a6 02 a8 7c mflr r5
410: ff ff a5 3c addis r5,r5,-1
414: f4 fb a5 38 addi r5,r5,-1036
418: f0 00 a5 38 addi r5,r5,240
41c: 85 06 00 48 bl aa0 <__c_kernel_gettimeofday>
Fixes: ab037dd87a ("powerpc/vdso: Switch VDSO to generic C implementation.")
Reported-by: "Will Springer <skirmisher@protonmail.com>"
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201218111619.1206391-3-mpe@ellerman.id.au
When building the 32-bit VDSO, we are building 32-bit code as part of
a 64-bit kernel build. That requires us to tweak the cflags to trick
the compiler into building 32-bit code for us. The main way we do that
is by passing -m32, but there are other options that affect code
generation and ABI selection.
In particular when building vgettimeofday.c, we end up passing
-mcall-aixdesc because it's in KBUILD_CFLAGS, which causes the
compiler to generate function descriptors, and dot symbols, eg:
$ nm arch/powerpc/kernel/vdso32/vgettimeofday.o
000005d0 T .__c_kernel_clock_getres
00000024 D __c_kernel_clock_getres
...
We get away with that at the moment because we also use the DOTSYM
macro, and that is also incorrectly prepending a '.' in 32-bit VDSO
code due to a separate bug.
But we shouldn't be generating function descriptors for this file,
there's no 32-bit ABI that includes function descriptors, so the
resulting object file is some frankenstein and it's surprising that it
even links.
So filter out all the ABI-related options we add to CFLAGS for 64-bit
builds, so that they're not used when building 32-bit code. With that
we only see regular text symbols:
$ nm arch/powerpc/kernel/vdso32/vgettimeofday.o michael@alpine1-p1
000005d0 T __c_kernel_clock_getres
00000000 T __c_kernel_clock_gettime
00000200 T __c_kernel_clock_gettime64
00000410 T __c_kernel_gettimeofday
00000650 T __c_kernel_time
Fixes: ab037dd87a ("powerpc/vdso: Switch VDSO to generic C implementation.")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201218111619.1206391-2-mpe@ellerman.id.au
Add R_PPC_REL24 relocations to the list of relocations we do NOT
support in the VDSO.
These are generated in some cases and we do not support relocating
them at runtime, so if they appear then the VDSO will not work at
runtime, therefore it's preferable to break the build if we see them.
Fixes: ab037dd87a ("powerpc/vdso: Switch VDSO to generic C implementation.")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201218111619.1206391-1-mpe@ellerman.id.au
It fixes this link warning:
WARNING: modpost: vmlinux.o(.text.unlikely+0x2d98): Section mismatch in reference from the function init_big_cores.isra.0() to the function .init.text:init_thread_group_cache_map()
The function init_big_cores.isra.0() references
the function __init init_thread_group_cache_map().
This is often because init_big_cores.isra.0 lacks a __init
annotation or the annotation of init_thread_group_cache_map is wrong.
Fixes: 425752c63b ("powerpc: Detect the presence of big-cores via "ibm, thread-groups"")
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201221074154.403779-1-clg@kaod.org
The lkp robot reported that some configs fail to build, for example
mpc85xx_smp_defconfig, with:
cc1: fatal error: opening output file arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory
This bisects to:
cc8a51ca6f ("kbuild: always create directories of targets")
Although that commit claims to be about in-tree builds, it somehow
breaks out-of-tree builds. But presumably it's just exposing a latent
bug in our Makefiles.
We can fix it by adding to targets for dts/fsl in the same way that we
do for dts.
Fixes: cc8a51ca6f ("kbuild: always create directories of targets")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201215032906.473460-1-mpe@ellerman.id.au
When turbo has been disabled by the BIOS, but HWP_CAP.GUARANTEED is
changed later, user space may want to take advantage of this increased
guaranteed performance.
HWP_CAP.GUARANTEED is not a static value. It can be adjusted by an
out-of-band agent or during an Intel Speed Select performance level
change. The HWP_CAP.MAX is still the maximum achievable performance
with turbo disabled by the BIOS, so HWP_CAP.GUARANTEED can still
change as long as it remains less than or equal to HWP_CAP.MAX.
When HWP_CAP.GUARANTEED is changed, the sysfs base_frequency
attribute shows the most recent guaranteed frequency value. This
attribute can be used by user space software to update the scaling
min/max limits of the CPU.
Currently, the ->setpolicy() callback already uses the latest
HWP_CAP values when setting HWP_REQ, but the ->verify() callback will
restrict the user settings to the to old guaranteed performance value
which prevents user space from making use of the extra CPU capacity
theoretically available to it after increasing HWP_CAP.GUARANTEED.
To address this, read HWP_CAP in intel_pstate_verify_cpu_policy()
to obtain the maximum P-state that can be used and use that to
confine the policy max limit instead of using the cached and
possibly stale pstate.max_freq value for this purpose.
For consistency, update intel_pstate_update_perf_limits() to use the
maximum available P-state returned by intel_pstate_get_hwp_max() to
compute the maximum frequency instead of using the return value of
intel_pstate_get_max_freq() which, again, may be stale.
This issue is a side-effect of fixing the scaling frequency limits in
commit eacc9c5a92 ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max()
for turbo disabled") which corrected the setting of the reduced scaling
frequency values, but caused stale HWP_CAP.GUARANTEED to be used in
the case at hand.
Fixes: eacc9c5a92 ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled")
Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: 5.8+ <stable@vger.kernel.org> # 5.8+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
$(error-if,...) is expanded to an empty string. Currently, it relies on
eval_clause() returning xstrdup("") when all attempts for expansion fail,
but the correct implementation is to make do_error_if() return xstrdup("").
Fixes: 1d6272e6fe ("kconfig: add 'info', 'warning-if', and 'error-if' built-in functions")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Document best practises for using architecture and platform dependencies.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The C11 _Static_assert() keyword may be used at module scope, and we
need to teach genksyms about it to not abort with an error. We currently
have a growing number of static_assert() (but also direct usage of
_Static_assert()) users at module scope:
git grep -E '^_Static_assert\(|^static_assert\(' | grep -v '^tools' | wc -l
135
More recently, when enabling CONFIG_MODVERSIONS with CONFIG_KCSAN, we
observe a number of warnings:
WARNING: modpost: EXPORT symbol "<..all kcsan symbols..>" [vmlinux] [...]
When running a preprocessed source through 'genksyms -w' a number of
syntax errors point at usage of static_assert()s. In the case of
kernel/kcsan/encoding.h, new static_assert()s had been introduced which
used expressions that appear to cause genksyms to not even be able to
recover from the syntax error gracefully (as it appears was the case
previously).
Therefore, make genksyms ignore all _Static_assert() and the contained
expression. With the fix, usage of _Static_assert() no longer cause
"syntax error" all over the kernel, and the above modpost warnings for
KCSAN are gone, too.
Signed-off-by: Marco Elver <elver@google.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Using EXPORT_SYMBOL*() on static functions is fundamentally wrong.
Modpost currently reports that as a warning, but clearly this is not a
pattern we should allow, and all in-tree occurences should have been
fixed by now. So, promote the warn() message to error() to make sure
this never happens again.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
There is code that reports static EXPORT_SYMBOL a few lines below.
It is not a good idea to bail out here.
I renamed sec_mismatch_fatal to sec_mismatch_warn_only (with logical
inversion) to match to CONFIG_SECTION_MISMATCH_WARN_ONLY.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Change fatal() to error() to continue running to report more possible
issues.
There is no difference in the fact that modpost will fail anyway.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
We have 3 log functions. fatal() is special because it lets modpost bail
out immediately. The difference between warn() and error() is the only
prefix parts ("WARNING:" vs "ERROR:").
In my understanding, the expected handling of error() is to propagate
the return code of the function to the exit code of modpost, as
check_exports() etc. already does. This is a good manner in general
because we should display as many error messages as possible in a
single run of modpost.
What is annoying about fatal() is that it kills modpost at the first
error. People would need to run Kbuild again and again until they fix
all errors.
But, unfortunately, people tend to do:
"This case should not be allowed. Let's replace warn() with fatal()."
One of the reasons is probably it is tedious to manually hoist the error
code to the main() function.
This commit refactors error() so any single call for it automatically
makes modpost return the error code.
I also added comments in modpost.h for warn(), error(), and fatal().
Please use fatal() only when you have a strong reason to do so.
For example:
- Memory shortage (i.e. malloc() etc. has failed)
- The ELF file is broken, and there is no point to continue parsing
- Something really odd has happened
For general coding errors, please use error().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Quentin Perret <qperret@google.com>
The log function names, warn(), merror(), fatal() are inconsistent.
Commit 2a11665945 ("kbuild: distinguish between errors and warnings
in modpost") intentionally chose merror() to avoid the conflict with
the library function error(). See man page of error(3).
But, we are already causing the conflict with warn() because it is also
a library function. See man page of warn(3). err() would be a problem
for the same reason.
The common technique to work around name conflicts is to use macros.
For example:
/* in a header */
#define error(fmt, ...) __error(fmt, ##__VA_ARGS__)
#define warn(fmt, ...) __warn(fmt, ##__VA_ARGS__)
/* function definition */
void __error(const char *fmt, ...)
{
<our implementation>
}
void __warn(const char *fmt, ...)
{
<our implementation>
}
In this way, we can implement our own warn() and error(), still we can
include <error.h> and <err.h> with no problem.
And, commit 93c95e526a ("modpost: rework and consolidate logging
interface") already did that.
Since the log functions are all macros, we can use error() without
causing "conflicting types" errors.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
depmod is not guaranteed to be in /sbin, just let make look for
it in the path like all the other invoked programs
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
There is no explanation about subdir-y.
Let's document it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
The difference between extra-y and always-y is obscure.
Basically, Kbuild builds targets listed in extra-y and always-y in
visited Makefiles without relying on any dependency.
The difference is that extra-y is used to list the targets needed for
vmlinux whereas always-y is used to list the targets that must be always
built irrespective of final targets.
Kbuild skips extra-y when it is building only modules (i.e.
'make modules'). This is the long-standing behavior since extra-y was
introduced in 2003, and it is explained in that commit log [1].
For clarification, this is the extra-y vs always-y table:
extra-y always-y
'make' y y
'make vmlinux' y y
'make modules' n y
Kbuild skips extra-y also when building external modules since obviously
it never builds vmlinux.
Unfortunately, extra-y is wrongly used in many places of upstream code,
and even in external modules.
Using extra-y in external module Makefiles is wrong. What you should
use is probably always-y or 'targets'.
The current documentation for extra-y is misleading. I rewrote it, and
moved it to the section 3.7.
always-y is not documented anywhere. I added.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=f94e5fd7e5d09a56a60670a9bb211a791654bba8
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
The if_changed macro is currently explained in the section
"Commands useful for building a boot image", but the use of
if_changed is not limited to the boot image.
It is often used together with custom rules. Let's split it as a
separate section, and insert it after the "Custom Rules" section.
I slightly reworded the explanation, re-numbered to fill the <deleted>
section, and also fixed the broken indentation of the Note: part.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The two sections "3.10 Special Rules" and "7.8 Custom kbuild commands"
are related because you must understand both of them when you write
custom rules.
Actually I do not understand the policy about what to go into
"3 The kbuild files" and what into "7 Architecture Makefile".
This commit reworks the custom rule explanation as follows:
- Merged "7.8 Custom kbuild commands" into "3.10 Special Rules".
- Reword "Special Rules" to "Custom Rules" for consistency.
- Update the example for kecho because the blackfin Makefile
does not exist any more.
- Replace the example for cmd_<command> with a simpler one.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Fix stale information:
- Fix the section number in the reference from 6.4 to 7.4.
- Remove init-y and net-y. They were removed by commit 23febe375d
("kbuild: merge init-y into core-y") and commit 95fb6317b3
("kbuild: merge net-y and virt-y into drivers-y"), respectively.
- Update the example because arch/sparc64/Makefile does not exit.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Precisely speaking, the arch directory is specified by $(SRCARCH),
not $(ARCH).
In old days, $(ARCH) actually matched to the arch directory because
32-bit and 64-bit were supported as separate architectures.
Most architectures (except arm/arm64) were unified like follows:
arch/i386, arch/x86_64 -> arch/x86
arch/sh, arch/sh64 -> arch/sh
arch/sparc, arch/sparc64 -> arch/sparc
To not break the user interface, commit 6752ed90da ("Kbuild: allow
arch/xxx to use a different source path") introduced SRCARCH to point
to the arch directory, still allowing to pass in the former ARCH=i386
or ARCH=x86_64.
Update the documents for preciseness, and add the explanation of SRCARCH.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
This line was written in 2003. Now we have much more Makefiles.
The number of Makefiles is not important. The point is we have a
Makefile in (almost) every directory.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
- Bindings for Canaan K210 SoC clks
* clk-ingenic:
clk: ingenic: Fix divider calculation with div tables
* clk-vc5:
clk: vc5: Use "idt,voltage-microvolt" instead of "idt,voltage-microvolts"
* clk-cleanup:
clk: sunxi-ng: Make sure divider tables have sentinel
clk: s2mps11: Fix a resource leak in error handling paths in the probe function
clk: bcm: dvp: Add MODULE_DEVICE_TABLE()
clk: bcm: dvp: drop a variable that is assigned to only
* clk-canaan:
dt-binding: clock: Document canaan,k210-clk bindings
dt-bindings: Add Canaan vendor prefix
* clk-marvell:
clk: mvebu: a3700: fix the XTAL MODE pin to MPP1_9
- Add some trace points for clk_set_rate() "range" functions
- DVFS support for AT91 clk driver
* clk-ti:
clk: ti: omap5: Fix reboot DPLL lock failure when using ABE TIMERs
clk: ti: Fix memleak in ti_fapll_synth_setup
* clk-analog:
clk: axi-clkgen: move the OF table at the bottom of the file
clk: axi-clkgen: wrap limits in a struct and keep copy on the state object
dt-bindings: clock: adi,axi-clkgen: convert old binding to yaml format
* clk-trace:
clk: Trace clk_set_rate() "range" functions
* clk-at91:
clk: at91: sam9x60: remove atmel,osc-bypass support
clk: at91: sama7g5: register cpu clock
clk: at91: clk-master: re-factor master clock
clk: at91: sama7g5: do not allow cpu pll to go higher than 1GHz
clk: at91: sama7g5: decrease lower limit for MCK0 rate
clk: at91: sama7g5: remove mck0 from parent list of other clocks
clk: at91: clk-sam9x60-pll: allow runtime changes for pll
clk: at91: sama7g5: add 5th divisor for mck0 layout and characteristics
clk: at91: clk-master: add 5th divisor for mck master
clk: at91: sama7g5: allow SYS and CPU PLLs to be exported and referenced in DT
dt-bindings: clock: at91: add sama7g5 pll defines
clk: at91: sama7g5: fix compilation error
* clk-silabs:
clk: si5351: Wait for bit clear after PLL reset
- Support for SiFive FU740 PRCI
- Add hardware enable information to clk_summary debugfs
* clk-tegra:
clk: tegra: Fix duplicated SE clock entry
clk: tegra: bpmp: Clamp clock rates on requests
clk: tegra: Do not return 0 on failure
* clk-imx: (24 commits)
clk: imx: scu: remove the calling of device_is_bound
clk: imx: scu: Make pd_np with static keyword
clk: imx8mq: drop of_match_ptr from of_device_id table
clk: imx8mp: drop of_match_ptr from of_device_id table
clk: imx8mn: drop of_match_ptr from of_device_id table
clk: imx8mm: drop of_match_ptr from of_device_id table
clk: imx: gate2: Remove unused variable ret
clk: imx: gate2: Add locking in is_enabled op
clk: imx: gate2: Add cgr_mask for more flexible number of control bits
clk: imx: gate2: Check if clock is enabled against cgr_val
clk: imx: gate2: Keep the register writing in on place
clk: imx: gate2: Remove the IMX_CLK_GATE2_SINGLE_BIT special case
clk: imx: scu: fix build break when compiled as modules
clk: imx: remove redundant assignment to pointer np
clk: imx: remove unneeded semicolon
clk: imx: lpcg: add suspend/resume support
clk: imx: clk-imx8qxp-lpcg: add runtime pm support
clk: imx: lpcg: allow lpcg clk to take device pointer
clk: imx: imx8qxp-lpcg: add parsing clocks from device tree
clk: imx: scu: add suspend/resume support
...
* clk-sifive:
clk: sifive: Add clock enable and disable ops
clk: sifive: Fix the wrong bit field shift
clk: sifive: Add a driver for the SiFive FU740 PRCI IP block
clk: sifive: Use common name for prci configuration
clk: sifive: Extract prci core to common base
dt-bindings: fu740: prci: add YAML documentation for the FU740 PRCI
* clk-mediatek:
clk: mediatek: Make mtk_clk_register_mux() a static function
* clk-summary:
clk: Add hardware-enable column to clk summary
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAl/fppEACgkQiiy9cAdy
T1HVJQwAiQr9cny9q+l84pKXEJyv56VXrXRFxsfGl3Xrx0uQRxiSSF6RrKNsqoMt
5m2aBve1rhsDcte4asS7EXM2U6ePRwnmbuKhC+78s0tjfCA6qXLzwF0pJCz7uMxh
jbL42gcx87B7PzO7WpRwNHYPGVBk6oZgAECNfZybvzvQI0VEHaS3IX3249btl+r7
+zithRFqD6aqvcZjaPxIjpRt9zb8tU55GG1JgPMRRiaMwW7tFbXWR9ty+kFRhT1q
0HCYXw4cIYUntPc/EeEQ+LOxzRVqBMJelhv1UvnZgKImBSRFjzTLSFsFn/Hwq2tq
ncuBML5mP4uTYthXrRxXUW24qlx+5owCdgFyVALX+buQu4GeFtNDROZlsXWMbI2L
oOm7sTb0wi6x7CeUJYm8vvS3g0d1QsAnxPgyOnxx1a9/p4vWWBt2kCnpoMmBf50O
9OHk34ffmL2QaK7hLl1HTwxAEz7n0FAvQ8chUQBISsmrxaS33QjxCld5RabPvm1T
Csv4LNml
=1sd/
-----END PGP SIGNATURE-----
Merge tag '5.11-rc-smb3-part2' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs fixes from Steve French:
"Four small CIFS/SMB3 fixes (witness protocol and reconnect related),
and two that add ability to get and set auditing information in the
security descriptor (SACL), which can be helpful not just for backup
scenarios ("smbinfo secdesc" etc.) but also for improving security"
* tag '5.11-rc-smb3-part2' of git://git.samba.org/sfrench/cifs-2.6:
Add SMB 2 support for getting and setting SACLs
SMB3: Add support for getting and setting SACLs
cifs: Avoid error pointer dereference
cifs: Re-indent cifs_swn_reconnect()
cifs: Unlock on errors in cifs_swn_reconnect()
cifs: Delete a stray unlock in cifs_swn_reconnect()
perf record:
- Fix memory leak when using '--user-regs=?' to list registers.
aarch64 support:
- Add aarch64 registers to 'perf record's' --user-regs command line option.
aarch64 hw tracing support:
- Decode memory tagging properties.
- Improve ARM's auxtrace support.
- Add support for ARMv8.3-SPE.
perf kvm:
- Add kvm-stat for arm64.
perf stat:
- Add --quiet option.
Cleanups:
- Fixup function names wrt what is in libperf and what is in tools/perf.
Build:
- Allow building without libbpf in older systems.
New kernel features:
- Initial support for data/code page size sample type, more to come.
perf annotate:
- Support MIPS instruction extended support.
perf stack unwinding:
- Fix separate debug info files when using elfutils' libdw's unwinder.
perf vendor events:
- Update Intel's Skylake client events to v50.
- Add JSON metrics for ARM's imx8mm DDR Perf.
- Support printing metric groups for system PMUs.
perf build id:
- Prep work for supporting having the build id provided by the
kernel in PERF_RECORD_MMAP2 metadata events.
perf stat:
- Support regex pattern in --for-each-cgroup.
pipe mode:
- Allow to use stdio functions for pipe mode.
- Support 'perf report's' --header-only for pipe mode.
- Support pipe mode display in 'perf evlist'.
Documentation:
- Update information about CAP_PERFMON.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Test results:
The first ones are container based builds of tools/perf with and without libelf
support. Where clang is available, it is also used to build perf with/without
libelf, and building with LIBCLANGLLVM=1 (built-in clang) with gcc and clang
when clang and its devel libraries are installed.
The objtool and samples/bpf/ builds are disabled now that I'm switching from
using the sources in a local volume to fetching them from a http server to
build it inside the container, to make it easier to build in a container cluster.
Those will come back later.
Several are cross builds, the ones with -x-ARCH and the android one, and those
may not have all the features built, due to lack of multi-arch devel packages,
available and being used so far on just a few, like
debian:experimental-x-{arm64,mipsel}.
The 'perf test' one will perform a variety of tests exercising
tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands
with a variety of command line event specifications to then intercept the
sys_perf_event syscall to check that the perf_event_attr fields are set up as
expected, among a variety of other unit tests.
Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/
with a variety of feature sets, exercising the build with an incomplete set of
features as well as with a complete one. It is planned to have it run on each
of the containers mentioned above, using some container orchestration
infrastructure. Get in contact if interested in helping having this in place.
$ grep "model name" -m1 /proc/cpuinfo
model name: AMD Ryzen 9 3900X 12-Core Processor
# export PERF_TARBALL=http://192.168.86.5/perf/perf-5.10.0.tar.xz
# dm
1 90.64 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0, clang version 3.8.0 (tags/RELEASE_380/final)
2 95.48 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822, clang version 3.8.1 (tags/RELEASE_381/final)
3 90.22 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0, clang version 4.0.0 (tags/RELEASE_400/final)
4 100.91 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0, Alpine clang version 5.0.0 (tags/RELEASE_500/final) (based on LLVM 5.0.0)
5 79.67 alpine:3.8 : Ok gcc (Alpine 6.4.0) 6.4.0, Alpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1)
6 82.75 alpine:3.9 : Ok gcc (Alpine 8.3.0) 8.3.0, Alpine clang version 5.0.1 (tags/RELEASE_502/final) (based on LLVM 5.0.1)
7 104.64 alpine:3.10 : Ok gcc (Alpine 8.3.0) 8.3.0, Alpine clang version 8.0.0 (tags/RELEASE_800/final) (based on LLVM 8.0.0)
8 117.54 alpine:3.11 : Ok gcc (Alpine 9.3.0) 9.3.0, Alpine clang version 9.0.0 (https://git.alpinelinux.org/aports f7f0d2c2b8bcd6a5843401a9a702029556492689) (based on LLVM 9.0.0)
9 110.74 alpine:3.12 : Ok gcc (Alpine 9.3.0) 9.3.0, Alpine clang version 10.0.0 (https://gitlab.alpinelinux.org/alpine/aports.git 7445adce501f8473efdb93b17b5eaf2f1445ed4c)
10 117.83 alpine:edge : Ok gcc (Alpine 10.2.0) 10.2.0, Alpine clang version 10.0.1
11 68.46 alt:p8 : Ok x86_64-alt-linux-gcc (GCC) 5.3.1 20151207 (ALT p8 5.3.1-alt3.M80P.1), clang version 3.8.0 (tags/RELEASE_380/final)
12 83.96 alt:p9 : Ok x86_64-alt-linux-gcc (GCC) 8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1), clang version 10.0.0
13 81.86 alt:sisyphus : Ok x86_64-alt-linux-gcc (GCC) 9.3.1 20200518 (ALT Sisyphus 9.3.1-alt1), clang version 10.0.1
14 64.54 amazonlinux:1 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2), clang version 3.6.2 (tags/RELEASE_362/final)
15 98.60 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-9), clang version 7.0.1 (Amazon Linux 2 7.0.1-1.amzn2.0.2)
16 21.37 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
17 22.27 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
18 26.01 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
19 31.91 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
20 94.99 centos:8 : Ok gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5), clang version 10.0.1 (Red Hat 10.0.1-1.module_el8.3.0+467+cb298d5b)
21 62.40 clearlinux:latest : Ok gcc (Clear Linux OS for Intel Architecture) 10.2.1 20201210 releases/gcc-10.2.0-621-g027d3288de, clang version 10.0.1
22 75.84 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u2) 4.9.2, Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
23 77.93 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, clang version 3.8.1-24 (tags/RELEASE_381/final)
24 74.34 debian:10 : Ok gcc (Debian 8.3.0-6) 8.3.0, clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
25 90.42 debian:experimental : Ok gcc (Debian 10.2.0-17) 10.2.0, Debian clang version 11.0.0-5
26 29.76 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 9.3.0-8) 9.3.0
27 30.53 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
28 30.46 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6), clang version 3.5.0 (tags/RELEASE_350/final)
29 69.07 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6), clang version 3.7.0 (tags/RELEASE_370/final)
30 80.04 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1), clang version 3.8.1 (tags/RELEASE_381/final)
31 24.97 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
32 82.35 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1), clang version 3.9.1 (tags/RELEASE_391/final)
33 93.70 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2), clang version 4.0.1 (tags/RELEASE_401/final)
34 94.23 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6), clang version 5.0.2 (tags/RELEASE_502/final)
35 105.40 fedora:28 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2), clang version 6.0.1 (tags/RELEASE_601/final)
36 110.12 fedora:29 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2), clang version 7.0.1 (Fedora 7.0.1-6.fc29)
37 115.10 fedora:30 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2), clang version 8.0.0 (Fedora 8.0.0-3.fc30)
38 25.07 fedora:30-x-ARC-uClibc : Ok arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225
39 114.17 fedora:31 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2), clang version 9.0.1 (Fedora 9.0.1-4.fc31)
40 97.00 fedora:32 : Ok gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6), clang version 10.0.1 (Fedora 10.0.1-3.fc32)
41 96.30 fedora:33 : Ok gcc (GCC) 10.2.1 20201005 (Red Hat 10.2.1-5), clang version 11.0.0 (Fedora 11.0.0-1.fc33)
42 96.70 fedora:rawhide : Ok gcc (GCC) 11.0.0 20201204 (Red Hat 11.0.0-0), clang version 11.0.1 (Fedora 11.0.1-1.rc1.fc34)
43 35.33 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 9.3.0-r1 p3) 9.3.0
44 68.19 mageia:5 : Ok gcc (GCC) 4.9.2, clang version 3.5.2 (tags/RELEASE_352/final)
45 84.59 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0, clang version 3.9.1 (tags/RELEASE_391/final)
46 100.44 manjaro:latest : Ok gcc (GCC) 10.2.0, clang version 10.0.1
47 223.64 openmandriva:cooker : Ok gcc (GCC) 10.2.0 20200723 (OpenMandriva), OpenMandriva 11.0.0-1 clang version 11.0.0 (/builddir/build/BUILD/llvm-project-llvmorg-11.0.0/clang 63e22714ac938c6b537bd958f70680d3331a2030)
48 117.94 opensuse:15.0 : Ok gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407], clang version 5.0.1 (tags/RELEASE_501/final 312548)
49 123.97 opensuse:15.1 : Ok gcc (SUSE Linux) 7.5.0, clang version 7.0.1 (tags/RELEASE_701/final 349238)
50 114.14 opensuse:15.2 : Ok gcc (SUSE Linux) 7.5.0, clang version 9.0.1
51 111.44 opensuse:42.3 : Ok gcc (SUSE Linux) 4.8.5, clang version 3.8.0 (tags/RELEASE_380/final 262553)
52 107.98 opensuse:tumbleweed : Ok gcc (SUSE Linux) 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c], clang version 10.0.1
53 26.94 oraclelinux:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23.0.1)
54 32.21 oraclelinux:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44.0.3)
55 115.15 oraclelinux:8 : Ok gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5.0.3), clang version 9.0.1 (Red Hat 9.0.1-2.0.1.module+el8.2.0+5599+9ed9ef6d)
56 27.38 ubuntu:12.04 : Ok gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
57 30.46 ubuntu:14.04 : Ok gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
58 77.46 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609, clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
59 26.74 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
60 25.90 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
61 25.66 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
62 26.15 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
63 25.84 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
64 25.60 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
65 88.96 ubuntu:18.04 : Ok gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
66 27.93 ubuntu:18.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
67 27.98 ubuntu:18.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
68 22.94 ubuntu:18.04-x-m68k : Ok m68k-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
69 27.28 ubuntu:18.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
70 29.15 ubuntu:18.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
71 29.00 ubuntu:18.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
72 162.20 ubuntu:18.04-x-riscv64 : Ok riscv64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
73 24.99 ubuntu:18.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
74 28.56 ubuntu:18.04-x-sh4 : Ok sh4-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
75 25.07 ubuntu:18.04-x-sparc64 : Ok sparc64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
76 70.51 ubuntu:19.10 : Ok gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008, clang version 8.0.1-3build1 (tags/RELEASE_801/final)
77 28.24 ubuntu:19.10-x-alpha : Ok alpha-linux-gnu-gcc (Ubuntu 9.2.1-9ubuntu1) 9.2.1 20191008
78 24.84 ubuntu:19.10-x-hppa : Ok hppa-linux-gnu-gcc (Ubuntu 9.2.1-9ubuntu1) 9.2.1 20191008
79 74.70 ubuntu:20.04 : Ok gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, clang version 10.0.0-4ubuntu1
80 30.69 ubuntu:20.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0
81 75.15 ubuntu:20.10 : Ok gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0, Ubuntu clang version 11.0.0-2
#
# uname -a
Linux quaco 5.9.11-100.fc32.x86_64 #1 SMP Tue Nov 24 19:16:53 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
# git log --oneline -1
2e7f545096 perf mem: Factor out a function to generate sort order
# perf version --build-options
perf version 5.10.g2e7f545096f9
dwarf: [ on ] # HAVE_DWARF_SUPPORT
dwarf_getlocations: [ on ] # HAVE_DWARF_GETLOCATIONS_SUPPORT
glibc: [ on ] # HAVE_GLIBC_SUPPORT
syscall_table: [ on ] # HAVE_SYSCALL_TABLE_SUPPORT
libbfd: [ on ] # HAVE_LIBBFD_SUPPORT
libelf: [ on ] # HAVE_LIBELF_SUPPORT
libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT
numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT
libperl: [ on ] # HAVE_LIBPERL_SUPPORT
libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT
libslang: [ on ] # HAVE_SLANG_SUPPORT
libcrypto: [ on ] # HAVE_LIBCRYPTO_SUPPORT
libunwind: [ on ] # HAVE_LIBUNWIND_SUPPORT
libdw-dwarf-unwind: [ on ] # HAVE_DWARF_SUPPORT
zlib: [ on ] # HAVE_ZLIB_SUPPORT
lzma: [ on ] # HAVE_LZMA_SUPPORT
get_cpuid: [ on ] # HAVE_AUXTRACE_SUPPORT
bpf: [ on ] # HAVE_LIBBPF_SUPPORT
aio: [ on ] # HAVE_AIO_SUPPORT
zstd: [ on ] # HAVE_ZSTD_SUPPORT
libpfm4: [ OFF ] # HAVE_LIBPFM
# perf test
1: vmlinux symtab matches kallsyms : Ok
2: Detect openat syscall event : Ok
3: Detect openat syscall event on all cpus : Ok
4: Read samples using the mmap interface : Ok
5: Test data source output : Ok
6: Parse event definition strings : Ok
7: Simple expression parser : Ok
8: PERF_RECORD_* events & perf_sample fields : Ok
9: Parse perf pmu format : Ok
10: PMU events :
10.1: PMU event table sanity : Ok
10.2: PMU event map aliases : Ok
10.3: Parsing of PMU event table metrics : Ok
10.4: Parsing of PMU event table metrics with fake PMUs : Ok
11: DSO data read : Ok
12: DSO data cache : Ok
13: DSO data reopen : Ok
14: Roundtrip evsel->name : Ok
15: Parse sched tracepoints fields : Ok
16: syscalls:sys_enter_openat event fields : Ok
17: Setup struct perf_event_attr : Ok
18: Match and link multiple hists : Ok
19: 'import perf' in python : Ok
20: Breakpoint overflow signal handler : Ok
21: Breakpoint overflow sampling : Ok
22: Breakpoint accounting : Ok
23: Watchpoint :
23.1: Read Only Watchpoint : Skip (missing hardware support)
23.2: Write Only Watchpoint : Ok
23.3: Read / Write Watchpoint : Ok
23.4: Modify Watchpoint : Ok
24: Number of exit events of a simple workload : Ok
25: Software clock events period values : Ok
26: Object code reading : Ok
27: Sample parsing : Ok
28: Use a dummy software event to keep tracking : Ok
29: Parse with no sample_id_all bit set : Ok
30: Filter hist entries : Ok
31: Lookup mmap thread : Ok
32: Share thread maps : Ok
33: Sort output of hist entries : Ok
34: Cumulate child hist entries : Ok
35: Track with sched_switch : Ok
36: Filter fds with revents mask in a fdarray : Ok
37: Add fd to a fdarray, making it autogrow : Ok
38: kmod_path__parse : Ok
39: Thread map : Ok
40: LLVM search and compile :
40.1: Basic BPF llvm compile : Ok
40.2: kbuild searching : Ok
40.3: Compile source for BPF prologue generation : Ok
40.4: Compile source for BPF relocation : Ok
41: Session topology : Ok
42: BPF filter :
42.1: Basic BPF filtering : Ok
42.2: BPF pinning : Ok
42.3: BPF prologue generation : Ok
42.4: BPF relocation checker : Ok
43: Synthesize thread map : Ok
44: Remove thread map : Ok
45: Synthesize cpu map : Ok
46: Synthesize stat config : Ok
47: Synthesize stat : Ok
48: Synthesize stat round : Ok
49: Synthesize attr update : Ok
50: Event times : Ok
51: Read backward ring buffer : Ok
52: Print cpu map : Ok
53: Merge cpu map : Ok
54: Probe SDT events : Ok
55: is_printable_array : Ok
56: Print bitmap : Ok
57: perf hooks : Ok
58: builtin clang support : Skip (not compiled in)
59: unit_number__scnprintf : Ok
60: mem2node : Ok
61: time utils : Ok
62: Test jit_write_elf : Ok
63: Test libpfm4 support : Skip (not compiled in)
64: Test api io : Ok
65: maps__merge_in : Ok
66: Demangle Java : Ok
67: Parse and process metrics : Ok
68: PE file support : Ok
69: Event expansion for cgroups : Ok
70: Convert perf time to TSC : Ok
71: x86 rdpmc : Ok
72: DWARF unwind : Ok
73: x86 instruction decoder - new instructions : Ok
74: Intel PT packet decoder : Ok
75: x86 bp modify : Ok
76: probe libc's inet_pton & backtrace it with ping : Ok
77: Use vfs_getname probe to get syscall args filenames : Ok
78: Check Arm CoreSight trace data recording and synthesized samples: Skip
79: perf stat metrics (shadow stat) test : Ok
80: build id cache operations : Ok
81: Add vfs_getname probe to get syscall args filenames : Ok
82: Check open filename arg using perf trace + vfs_getname : Ok
83: Zstd perf.data compression/decompression : Ok
#
$ make -C tools/perf build-test
make: Entering directory '/home/acme/git/perf/tools/perf'
- tarpkg: ./tests/perf-targz-src-pkg .
make_no_libbpf_O: make NO_LIBBPF=1
make_no_demangle_O: make NO_DEMANGLE=1
make_doc_O: make doc
make_no_libpython_O: make NO_LIBPYTHON=1
make_install_bin_O: make install-bin
make_no_libnuma_O: make NO_LIBNUMA=1
make_install_O: make install
make_with_clangllvm_O: make LIBCLANGLLVM=1
make_debug_O: make DEBUG=1
make_pure_O: make
make_install_prefix_O: make install prefix=/tmp/krava
make_no_libunwind_O: make NO_LIBUNWIND=1
make_no_newt_O: make NO_NEWT=1
make_tags_O: make tags
make_with_libpfm4_O: make LIBPFM4=1
make_no_auxtrace_O: make NO_AUXTRACE=1
make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1
make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1
make_clean_all_O: make clean all
make_with_babeltrace_O: make LIBBABELTRACE=1
make_no_libaudit_O: make NO_LIBAUDIT=1
make_no_libbionic_O: make NO_LIBBIONIC=1
make_no_backtrace_O: make NO_BACKTRACE=1
make_static_O: make LDFLAGS=-static NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 NO_JVMTI=1
make_with_gtk2_O: make GTK2=1
make_no_libelf_O: make NO_LIBELF=1
make_no_libbpf_DEBUG_O: make NO_LIBBPF=1 DEBUG=1
make_no_libperl_O: make NO_LIBPERL=1
make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
make_help_O: make help
make_perf_o_O: make perf.o
make_util_pmu_bison_o_O: make util/pmu-bison.o
make_util_map_o_O: make util/map.o
make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1 NO_LIBZSTD=1 NO_LIBCAP=1 NO_SYSCALL_TABLE=1
make_no_libcrypto_O: make NO_LIBCRYPTO=1
make_no_gtk2_O: make NO_GTK2=1
make_no_slang_O: make NO_SLANG=1
make_no_sdt_O: make NO_SDT=1
make_install_prefix_slash_O: make install prefix=/tmp/krava/
make_no_syscall_tbl_O: make NO_SYSCALL_TABLE=1
OK
make: Leaving directory '/home/acme/git/perf/tools/perf'
$
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCX96AygAKCRCyPKLppCJ+
JxhxAQD7ESkH/xPGuhs8d1ZZy2jsYJWfpzRH0vq1t5bDoI4uygEAxrWHz7C1qv45
k1bXYNzJLu/XDYvQMCCg4pRnO+HJ1gI=
=THhF
-----END PGP SIGNATURE-----
Merge tag 'perf-tools-2020-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
Pull perf tools updates from Arnaldo Carvalho de Melo:
"perf record:
- Fix memory leak when using '--user-regs=?' to list registers
aarch64 support:
- Add aarch64 registers to 'perf record's' --user-regs command line
option
aarch64 hw tracing support:
- Decode memory tagging properties
- Improve ARM's auxtrace support
- Add support for ARMv8.3-SPE
perf kvm:
- Add kvm-stat for arm64
perf stat:
- Add --quiet option
Cleanups:
- Fixup function names wrt what is in libperf and what is in
tools/perf
Build:
- Allow building without libbpf in older systems
New kernel features:
- Initial support for data/code page size sample type, more to come
perf annotate:
- Support MIPS instruction extended support
perf stack unwinding:
- Fix separate debug info files when using elfutils' libdw's unwinder
perf vendor events:
- Update Intel's Skylake client events to v50
- Add JSON metrics for ARM's imx8mm DDR Perf
- Support printing metric groups for system PMUs
perf build id:
- Prep work for supporting having the build id provided by the kernel
in PERF_RECORD_MMAP2 metadata events
perf stat:
- Support regex pattern in --for-each-cgroup
pipe mode:
- Allow to use stdio functions for pipe mode
- Support 'perf report's' --header-only for pipe mode
- Support pipe mode display in 'perf evlist'
Documentation:
- Update information about CAP_PERFMON"
* tag 'perf-tools-2020-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (134 commits)
perf mem: Factor out a function to generate sort order
perf sort: Add sort option for data page size
perf script: Support data page size
tools headers UAPI: Update asm-generic/unistd.h
tools headers cpufeatures: Sync with the kernel sources
tools headers UAPI: Sync linux/prctl.h with the kernel sources
tools headers UAPI: Sync linux/fscrypt.h with the kernel sources
tools headers UAPI: Sync linux/const.h with the kernel headers
tools arch x86: Sync the msr-index.h copy with the kernel sources
perf trace beauty: Update copy of linux/socket.h with the kernel sources
tools headers: Update linux/ctype.h with the kernel sources
tools headers: Add conditional __has_builtin()
tools headers: Get tools's linux/compiler.h closer to the kernel's
tools headers UAPI: Sync linux/stat.h with the kernel sources
tools headers: Syncronize linux/build_bug.h with the kernel sources
perf tools: Reformat record's control fd man text
perf config: Fix example command in manpage to conform to syntax specified in the SYNOPSIS section.
perf test: Make sample-parsing test aware of PERF_SAMPLE_{CODE,DATA}_PAGE_SIZE
perf tools: Add support to read build id from compressed elf
perf debug: Add debug_set_file function
...
Document the device tree bindings of the Canaan Kendryte K210 SoC clock
driver in Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml.
The header file include/dt-bindings/clock/k210-clk.h is modified to
include the complete list of IDs for all clocks of the SoC.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201220085725.19545-3-damien.lemoal@wdc.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Update Documentation/devicetree/bindings/vendor-prefixes.yaml to
include "canaan" as a vendor prefix for "Canaan Inc.". Canaan is the
vendor of the Kendryte K210 RISC-V SoC.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201220085725.19545-2-damien.lemoal@wdc.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
