summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* kbuild: move KBUILD_LDS, KBUILD_VMLINUX_{OBJS,LIBS} to makefiles.rstMasahiro Yamada2019-08-212-14/+14
| | | | | | | These three variables are not intended to be tweaked by users. Move them from kbuild.rst to makefiles.rst. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* treewide: remove dummy Makefiles for single targetsMasahiro Yamada2019-08-2114-27/+0
| | | | | | | | Now that the single target build descends into sub-directories in the same way as the normal build, these dummy Makefiles are not needed any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: make single targets work more correctlyMasahiro Yamada2019-08-212-37/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the single target build directly descends into the directory of the target. For example, $ make foo/bar/baz.o ... directly descends into foo/bar/. On the other hand, the normal build usually descends one directory at a time, i.e. descends into foo/, and then foo/bar/. This difference causes some problems. [1] miss subdir-asflags-y, subdir-ccflags-y in upper Makefiles The options in subdir-{as,cc}flags-y take effect in the current and its sub-directories. In other words, they are inherited downward. In the example above, the single target will miss subdir-{as,cc}flags-y if they are defined in foo/Makefile. [2] could be built in a different directory As Documentation/kbuild/modules.rst section 4.3 says, Kbuild can handle files that are spread over several sub-directories. The build rule of foo/bar/baz.o may not necessarily be specified in foo/bar/Makefile. It might be specifies in foo/Makefile as follows: [foo/Makefile] obj-y := bar/baz.o This often happens when a module is so big that its source files are divided into sub-directories. In this case, there is no Makefile in the foo/bar/ directory, yet the single target descends into foo/bar/, then fails due to the missing Makefile. You can still do 'make foo/bar/' for partial building, but cannot do 'make foo/bar/baz.s'. I believe the single target '%.s' is a useful feature for inspecting the compiler output. Some modules work around this issue by putting an empty Makefile in every sub-directory. This commit fixes those problems by making the single target build descend in the same way as the normal build does. Another change is the single target build will observe the CONFIG options. Previously, it allowed users to build the foo.o even when the corresponding CONFIG_FOO is disabled: obj-$(CONFIG_FOO) += foo.o In the new behavior, the single target build will just fail and show "No rule to make target ..." (or "Nothing to be done for ..." if the stale object already exists, but cannot be updated). The disadvantage of this commit is the build speed. Now that the single target build visits every directory and parses lots of Makefiles, it is slower than before. (But, I hope it will not be too slow.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: Parameterize kallsyms generation and correct reportingKees Cook2019-08-211-19/+19
| | | | | | | | | | | | | When kallsyms generation happens, temporary vmlinux outputs are linked but the quiet make output didn't report it, giving the impression that the prior command is taking longer than expected. Instead, report the linking step explicitly. While at it, this consolidates the repeated "kallsyms generation step" into a single function and removes the existing copy/pasting. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: re-implement detection of CONFIG options leaked to user-spaceMasahiro Yamada2019-08-211-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scripts/headers_check.pl can detect references to CONFIG options in exported headers, but it has been disabled for more than a decade. Reverting commit 7e3fa5614117 ("kbuild: drop check for CONFIG_ in headers_check") would emit the following warnings for headers_check on x86: usr/include/mtd/ubi-user.h:283: leaks CONFIG_MTD_UBI_BEB_LIMIT to userspace where it is not valid usr/include/linux/cm4000_cs.h:26: leaks CONFIG_COMPAT to userspace where it is not valid usr/include/linux/pkt_cls.h:301: leaks CONFIG_NET_CLS_ACT to userspace where it is not valid usr/include/linux/videodev2.h:2465: leaks CONFIG_VIDEO_ADV_DEBUG to userspace where it is not valid usr/include/linux/bpf.h:249: leaks CONFIG_EFFICIENT_UNALIGNED_ACCESS to userspace where it is not valid usr/include/linux/bpf.h:819: leaks CONFIG_CGROUP_NET_CLASSID to userspace where it is not valid usr/include/linux/bpf.h:1011: leaks CONFIG_IP_ROUTE_CLASSID to userspace where it is not valid usr/include/linux/bpf.h:1742: leaks CONFIG_BPF_KPROBE_OVERRIDE to userspace where it is not valid usr/include/linux/bpf.h:1747: leaks CONFIG_FUNCTION_ERROR_INJECTION to userspace where it is not valid usr/include/linux/bpf.h:1936: leaks CONFIG_XFRM to userspace where it is not valid usr/include/linux/bpf.h:2184: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid usr/include/linux/bpf.h:2210: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid usr/include/linux/bpf.h:2227: leaks CONFIG_SOCK_CGROUP_DATA to userspace where it is not valid usr/include/linux/bpf.h:2311: leaks CONFIG_NET to userspace where it is not valid usr/include/linux/bpf.h:2348: leaks CONFIG_NET to userspace where it is not valid usr/include/linux/bpf.h:2422: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid usr/include/linux/bpf.h:2528: leaks CONFIG_NET to userspace where it is not valid usr/include/linux/pktcdvd.h:37: leaks CONFIG_CDROM_PKTCDVD_WCACHE to userspace where it is not valid usr/include/linux/hw_breakpoint.h:27: leaks CONFIG_HAVE_MIXED_BREAKPOINTS_REGS to userspace where it is not valid usr/include/linux/raw.h:17: leaks CONFIG_MAX_RAW_DEVS to userspace where it is not valid usr/include/linux/elfcore.h:62: leaks CONFIG_BINFMT_ELF_FDPIC to userspace where it is not valid usr/include/linux/eventpoll.h:82: leaks CONFIG_PM_SLEEP to userspace where it is not valid usr/include/linux/atmdev.h:104: leaks CONFIG_COMPAT to userspace where it is not valid usr/include/asm-generic/unistd.h:651: leaks CONFIG_MMU to userspace where it is not valid usr/include/asm-generic/bitsperlong.h:9: leaks CONFIG_64BIT to userspace where it is not valid usr/include/asm-generic/fcntl.h:119: leaks CONFIG_64BIT to userspace where it is not valid usr/include/asm/auxvec.h:14: leaks CONFIG_IA32_EMULATION to userspace where it is not valid usr/include/asm/e820.h:14: leaks CONFIG_NODES_SHIFT to userspace where it is not valid usr/include/asm/e820.h:39: leaks CONFIG_X86_PMEM_LEGACY to userspace where it is not valid usr/include/asm/e820.h:49: leaks CONFIG_INTEL_TXT to userspace where it is not valid usr/include/asm/mman.h:7: leaks CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS to userspace where it is not valid Most of these are false positives because scripts/headers_check.pl parses comment lines. It is also false negative. arch/x86/include/uapi/asm/auxvec.h contains CONFIG_IA32_EMULATION and CONFIG_X86_64, but the only former is reported. It would be possible to fix scripts/headers_check.pl, of course. However, we already have some duplicated checks between headers_check and CONFIG_UAPI_HEADER_TEST. At this moment of time, there are still dozens of headers excluded from the header test (usr/include/Makefile), but we might be able to remove headers_check eventually. I re-implemented it in scripts/headers_install.sh by using sed because the most of code in scripts/headers_install.sh is written in sed. This patch works like this: [1] Run scripts/unifdef first because we need to drop the code surrounded by #ifdef __KERNEL__ ... #endif [2] Remove all C style comments. The sed code is somewhat complicated since we need to deal with both single and multi line comments. Precisely speaking, a comment block is replaced with a space just in case. CONFIG_FOO/* this is a comment */CONFIG_BAR should be converted into: CONFIG_FOO CONFIG_BAR instead of: CONFIG_FOOCONFIG_BAR [3] Match CONFIG_... pattern. It correctly matches to all CONFIG options that appear in a single line. After this commit, this would detect the following warnings, all of which are real ones. warning: include/uapi/linux/pktcdvd.h: leak CONFIG_CDROM_PKTCDVD_WCACHE to user-space warning: include/uapi/linux/hw_breakpoint.h: leak CONFIG_HAVE_MIXED_BREAKPOINTS_REGS to user-space warning: include/uapi/linux/raw.h: leak CONFIG_MAX_RAW_DEVS to user-space warning: include/uapi/linux/elfcore.h: leak CONFIG_BINFMT_ELF_FDPIC to user-space warning: include/uapi/linux/eventpoll.h: leak CONFIG_PM_SLEEP to user-space warning: include/uapi/linux/atmdev.h: leak CONFIG_COMPAT to user-space warning: include/uapi/asm-generic/fcntl.h: leak CONFIG_64BIT to user-space warning: arch/x86/include/uapi/asm/auxvec.h: leak CONFIG_IA32_EMULATION to user-space warning: arch/x86/include/uapi/asm/auxvec.h: leak CONFIG_X86_64 to user-space warning: arch/x86/include/uapi/asm/mman.h: leak CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS to user-space However, it is not nice to show them right now. I created a list of existing leakages. They are not warned, but a new leakage will be blocked by the 0-day bot. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Sam Ravnborg <sam@ravnborg.org>
* kbuild: unify clean-dirs rule for in-kernel and external moduleMasahiro Yamada2019-08-211-10/+8
| | | | | | | Factor out the duplicated code for in-kernel and external module cleaning. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: unify vmlinux-dirs and module-dirs rulesMasahiro Yamada2019-08-211-22/+21
| | | | | | | | | The in-kernel build and external module build have similar code for descending into sub-directories. Factor out the code into the common place. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: unset variables in top Makefile instead of setting 0Masahiro Yamada2019-08-211-23/+23
| | | | | | | | | | | | | | | | | There is no need to set 0 to variables such as config-targets, mixed-targets, etc. Unset instead of setting 0 in order to use 'ifdef' to test them. I also renamed: config-targets -> config-build mixed-targets -> mixed-build dot-config -> need-config to clarify what we are doing. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: do not descend to ./Kbuild when cleaningMasahiro Yamada2019-08-213-10/+1
| | | | | | | | | | | | | 'make clean' descends into ./Kbuild, but does not clean anything since everything is added to no-clean-files. There is no need to descend to ./Kbuild in the first place. We can drop the no-clean-files assignment. With this, there is no more user of no-clean-files. I will keep it for a while to see whether a new user will appear. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: remove meaningless 'targets' in ./KbuildMasahiro Yamada2019-08-141-4/+0
| | | | | | | | | timeconst.h is generated by $(call filechk,...), missing-syscalls and old-atomics are invoked by $(call cmd,...) None of them needs to be added to 'targets'. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: remove 'make /' supportMasahiro Yamada2019-08-141-5/+4
| | | | | | | | | | | | | | 'make /' is just an alias for 'make ./'; this builds all objects of an external module, but skips the modpost stage. I am not a big fan of 'make /' since it looks as if it were touching the root directory of the system. I like 'make ./' better. I do not know how many people are using it, but let's show a hint if it is used. Also, move it close to the external module rules since this only makes sense for external modules. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: fix modkern_aflags implementationMasahiro Yamada2019-08-141-4/+3
| | | | | | | | | | | | | | | For the single target building %.symtypes from %.S, $(a_flags) is expanded into the _KERNEL flags even if the object is a part of a module. $(real-obj-m:.o=.symtypes): modkern_aflags := $(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE) ... would fix the issue, but it is not nice to duplicate similar code for every suffix. Implement modkern_aflags in the same way as modkern_cflags. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: refactor part-of-module moreMasahiro Yamada2019-08-141-2/+1
| | | | | | Make it even shorter. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: move the Module.symvers check for external module buildMasahiro Yamada2019-08-141-2/+2
| | | | | | | | | $(objtree)/Module.symvers is not required for descending into sub-directories. It is needed for the modpost stage. Move the Module.symvers check to the right place. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: treat an object as multi-used when $(foo-) is setMasahiro Yamada2019-08-141-5/+5
| | | | | | | | | | | Currently, Kbuild treats an object as multi-used when any of $(foo-objs), $(foo-y), $(foo-m) is set. It makes more sense to check $(foo-) as well. In the context of foo-$(CONFIG_FOO_FEATURE1), CONFIG_FOO_FEATURE1 could be unset. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: add [M] marker for build log of *.mod.oMasahiro Yamada2019-08-131-1/+1
| | | | | | This builds module objects, so [M] makes sense. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* Kbuild: Handle PREEMPT_RT for version string and magicThomas Gleixner2019-08-134-4/+9
| | | | | | | | | | | | | | | | | | | | Update the build scripts and the version magic to reflect when CONFIG_PREEMPT_RT is enabled in the same way as CONFIG_PREEMPT is treated. The resulting version strings: Linux m 5.3.0-rc1+ #100 SMP Fri Jul 26 ... Linux m 5.3.0-rc1+ #101 SMP PREEMPT Fri Jul 26 ... Linux m 5.3.0-rc1+ #102 SMP PREEMPT_RT Fri Jul 26 ... The module vermagic: 5.3.0-rc1+ SMP mod_unload modversions 5.3.0-rc1+ SMP preempt mod_unload modversions 5.3.0-rc1+ SMP preempt_rt mod_unload modversions Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: move flex and bison rules to Makefile.hostMasahiro Yamada2019-08-132-16/+17
| | | | | | | | | | | Flex and bison are used for kconfig, dtc, genksyms, all of which are host programs. I never imagine the kernel embeds a parser or a lexer. Move the flex and bison rules to scripts/Makefile.host. This file is included only when hostprogs-y etc. is present in the Makefile in the directory. So, parsing these rules are skipped in most of directories. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: make bison create C file and header in a single pattern ruleMasahiro Yamada2019-08-132-17/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We generally expect bison to create not only a C file, but also a header, which will be included from the lexer. Currently, Kbuild generates them in separate rules. So, for instance, when building Kconfig, you will notice bison is invoked twice: HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.h HOSTCC scripts/kconfig/lexer.lex.o YACC scripts/kconfig/parser.tab.c HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTLD scripts/kconfig/conf Make handles such cases nicely in pattern rules [1]. Merge the two rules so that one invokcation of bison can generate both of them. HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTLD scripts/kconfig/conf [1] Pattern rule GNU Make manual says: "Pattern rules may have more than one target. Unlike normal rules, this does not act as many different rules with the same prerequisites and recipe. If a pattern rule has multiple targets, make knows that the rule's recipe is responsible for making all of the targets. The recipe is executed only once to make all the targets. When searching for a pattern rule to match a target, the target patterns of a rule other than the one that matches the target in need of a rule are incidental: make worries only about giving a recipe and prerequisites to the file presently in question. However, when this file's recipe is run, the other targets are marked as having been updated themselves." https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: use $(basename ...) for cmd_asn1_compilerMasahiro Yamada2019-08-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | $(basename ...) trims the last suffix. Using it is more intuitive in my opinion. This pattern rule makes %.asn1.c and %.asn1.h at the same time. Previously, the short log showed only either of them, depending on the target file in question. To clarify that two files are being generated by the single recipe, I changed the log as follows: Before: ASN.1 crypto/asymmetric_keys/x509.asn1.c After: ASN.1 crypto/asymmetric_keys/x509.asn1.[ch] Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* kbuild: Fail if gold linker is detectedThomas Gleixner2019-08-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gold linker has known issues of failing the build both in random and in predictible ways: - The x86/X32 VDSO build fails with: arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres: error: relocation overflow: reference to 'hvclock_page' That's a known issue for years and the usual workaround is to disable CONFIG_X86_32 - A recent build failure is caused by turning a relocation into an absolute one for unknown reasons. See link below. - There are a couple of gold workarounds applied already, but reports about broken builds with ld.gold keep coming in on a regular base and in most cases the root cause is unclear. In context of the most recent fail H.J. stated: "Since building a workable kernel for different kernel configurations isn't a requirement for gold, I don't recommend gold for kernel." So instead of dealing with attempts to duct tape gold support without understanding the root cause and without support from the gold folks, fail the build when gold is detected. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* modpost: check for static EXPORT_SYMBOL* functionsDenis Efremov2019-08-131-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a check to warn about static EXPORT_SYMBOL* functions during the modpost. In most of the cases, a static symbol marked for exporting is an odd combination that should be fixed either by deleting the exporting mark or by removing the static attribute and adding the appropriate declaration to headers. This check could help to detect the following problems: 1. 550113d4e9f5 ("i2c: add newly exported functions to the header, too") 2. 54638c6eaf44 ("net: phy: make exported variables non-static") 3. 98ef2046f28b ("mm: remove the exporting of totalram_pages") 4. 73df167c819e ("s390/zcrypt: remove the exporting of ap_query_configuration") 5. a57caf8c527f ("sunrpc/cache: remove the exporting of cache_seq_next") 6. e4e4730698c9 ("crypto: skcipher - remove the exporting of skcipher_walk_next") 7. 14b4c48bb1ce ("gve: Remove the exporting of gve_probe") 8. 9b79ee9773a8 ("scsi: libsas: remove the exporting of sas_wait_eh") 9. ... The build time impact is very limited and is almost at the unnoticeable level (< 1 sec). Acked-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* Linux 5.3-rc4v5.3-rc4Linus Torvalds2019-08-111-1/+1
|
* Merge tag 'dax-fixes-5.3-rc4' of ↵Linus Torvalds2019-08-112-1/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull dax fixes from Dan Williams: "A filesystem-dax and device-dax fix for v5.3. The filesystem-dax fix is tagged for stable as the implementation has been mistakenly throwing away all cow pages on any truncate or hole punch operation as part of the solution to coordinate device-dma vs truncate to dax pages. The device-dax change fixes up a regression this cycle from the introduction of a common 'internal per-cpu-ref' implementation. Summary: - Fix dax_layout_busy_page() to not discard private cow pages of fs/dax private mappings. - Update the memremap_pages core to properly cleanup on behalf of internal reference-count users like device-dax" * tag 'dax-fixes-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: mm/memremap: Fix reuse of pgmap instances with internal references dax: dax_layout_busy_page() should not unmap cow pages
| * mm/memremap: Fix reuse of pgmap instances with internal referencesDan Williams2019-08-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, attempts to shutdown and re-enable a device-dax instance trigger: Missing reference count teardown definition WARNING: CPU: 37 PID: 1608 at mm/memremap.c:211 devm_memremap_pages+0x234/0x850 [..] RIP: 0010:devm_memremap_pages+0x234/0x850 [..] Call Trace: dev_dax_probe+0x66/0x190 [device_dax] really_probe+0xef/0x390 driver_probe_device+0xb4/0x100 device_driver_attach+0x4f/0x60 Given that the setup path initializes pgmap->ref, arrange for it to be also torn down so devm_memremap_pages() is ready to be called again and not be mistaken for the 3rd-party per-cpu-ref case. Fixes: 24917f6b1041 ("memremap: provide an optional internal refcount in struct dev_pagemap") Reported-by: Fan Du <fan.du@intel.com> Tested-by: Vishal Verma <vishal.l.verma@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/156530042781.2068700.8733813683117819799.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * dax: dax_layout_busy_page() should not unmap cow pagesVivek Goyal2019-08-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vivek: "As of now dax_layout_busy_page() calls unmap_mapping_range() with last argument as 1, which says even unmap cow pages. I am wondering who needs to get rid of cow pages as well. I noticed one interesting side affect of this. I mount xfs with -o dax and mmaped a file with MAP_PRIVATE and wrote some data to a page which created cow page. Then I called fallocate() on that file to zero a page of file. fallocate() called dax_layout_busy_page() which unmapped cow pages as well and then I tried to read back the data I wrote and what I get is old data from persistent memory. I lost the data I had written. This read basically resulted in new fault and read back the data from persistent memory. This sounds wrong. Are there any users which need to unmap cow pages as well? If not, I am proposing changing it to not unmap cow pages. I noticed this while while writing virtio_fs code where when I tried to reclaim a memory range and that corrupted the executable and I was running from virtio-fs and program got segment violation." Dan: "In fact the unmap_mapping_range() in this path is only to synchronize against get_user_pages_fast() and force it to call back into the filesystem to re-establish the mapping. COW pages should be left untouched by dax_layout_busy_page()." Cc: <stable@vger.kernel.org> Fixes: 5fac7408d828 ("mm, fs, dax: handle layout changes to pinned dax mappings") Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Link: https://lore.kernel.org/r/20190802192956.GA3032@redhat.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
* | Merge tag 'ntb-5.3-bugfixes' of git://github.com/jonmason/ntbLinus Torvalds2019-08-111-5/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | Pull NTB fix from Jon Mason: "Bug fix for NTB MSI kernel compile warning" * tag 'ntb-5.3-bugfixes' of git://github.com/jonmason/ntb: NTB/msi: remove incorrect MODULE defines
| * | NTB/msi: remove incorrect MODULE definesLogan Gunthorpe2019-08-051-5/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | msi.c is not a module on its own right and should not have the MODULE_[LICENSE|VERSION|AUTHOR|DESCRIPTION] definitions. This caused a regression noticed by lkp with the following back trace: WARNING: CPU: 0 PID: 1 at kernel/params.c:861 param_sysfs_init+0xb1/0x20a Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc1-00018-g26b3a37b928457 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 RIP: 0010:param_sysfs_init+0xb1/0x20a Code: 24 38 e8 ec 17 2e fd 49 8b 7c 24 38 e8 76 fe ff ff 48 85 c0 48 89 c5 74 25 31 d2 4c 89 e6 48 89 c7 e8 6d 6f 3c fd 85 c0 74 02 <0f> 0b 48 89 ef 31 f6 e8 5d 70 a7 fe 48 89 ef e8 95 52 a7 fe 48 83 RSP: 0000:ffff88806b0ffe30 EFLAGS: 00010282 RAX: 00000000ffffffef RBX: ffffffff83774220 RCX: ffff88806a85e880 RDX: 00000000ffffffef RSI: ffff88806b000400 RDI: ffff88806a8608c0 RBP: ffff88806b392000 R08: ffffed100d61ff59 R09: ffffed100d61ff59 R10: 0000000000000001 R11: ffffed100d61ff58 R12: ffffffff83974bc0 R13: 0000000000000004 R14: 0000000000000028 R15: 00000000000003b9 FS: 0000000000000000(0000) GS:ffff88806b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000000380e000 CR4: 00000000000406b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? file_caps_disable+0x10/0x10 ? locate_module_kobject+0xf2/0xf2 do_one_initcall+0x47/0x1f0 kernel_init_freeable+0x1b1/0x243 ? rest_init+0xd0/0xd0 kernel_init+0xa/0x130 ? calculate_sigpending+0x63/0x80 ? rest_init+0xd0/0xd0 ret_from_fork+0x1f/0x30 ---[ end trace 78201497ae74cc91 ]--- Reported-by: kernel test robot <lkp@intel.com> Fixes: 26b3a37b9284 ("NTB: Introduce MSI library") Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
* | Merge tag 'riscv/for-v5.3-rc4' of ↵Linus Torvalds2019-08-117-202/+24
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V updates from Paul Walmsley: "A few minor RISC-V updates for v5.3-rc4: - Remove __udivdi3() from the 32-bit Linux port, converting the only upstream user to use do_div(), per Linux policy - Convert the RISC-V standard clocksource away from per-cpu data structures, since only one is used by Linux, even on a multi-CPU system - A set of DT binding updates that remove an obsolete text binding in favor of a YAML binding, fix a bogus compatible string in the schema (thus fixing a "make dtbs_check" warning), and clarifies the future values expected in one of the RISC-V CPU properties" * tag 'riscv/for-v5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: dt-bindings: riscv: fix the schema compatible string for the HiFive Unleashed board dt-bindings: riscv: remove obsolete cpus.txt RISC-V: Remove udivdi3 riscv: delay: use do_div() instead of __udivdi3() dt-bindings: Update the riscv,isa string description RISC-V: Remove per cpu clocksource
| * | dt-bindings: riscv: fix the schema compatible string for the HiFive ↵Paul Walmsley2019-08-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unleashed board The YAML binding document for SiFive boards has an incorrect compatible string for the HiFive Unleashed board. Change it to match the name of the board on the SiFive web site: https://www.sifive.com/boards/hifive-unleashed which also matches the contents of the board DT data file: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts#n13 Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Acked-by: Rob Herring <robh@kernel.org>
| * | dt-bindings: riscv: remove obsolete cpus.txtPaul Walmsley2019-08-092-162/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the now-obsolete riscv/cpus.txt DT binding document, since we are using YAML binding documentation instead. While doing so, transfer the explanatory text about 'harts' (with some edits) into the YAML file, at Rob's request. Link: https://lore.kernel.org/linux-riscv/CAL_JsqJs6MtvmuyAknsUxQymbmoV=G+=JfS1PQj9kNHV7fjC9g@mail.gmail.com/ Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Cc: Rob Herring <robh@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org>
| * | RISC-V: Remove udivdi3Palmer Dabbelt2019-08-092-34/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should never have landed in the first place: it was added as part of 64-bit divide support for 32-bit systems, but the kernel doesn't allow this sort of division. I must have forgotten to remove it. This patch removes the support. Since this routine only worked on 64-bit platforms but was only built on 32-bit platforms, it's essentially just nonsense anyway. Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Acked-by: Nicolas Pitre <nico@fluxnic.net> Link: https://lore.kernel.org/linux-riscv/nycvar.YSQ.7.76.1908061413360.19480@knanqh.ubzr/T/#t Reported-by: Eric Lin <tesheng@andestech.com> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
| * | riscv: delay: use do_div() instead of __udivdi3()Paul Walmsley2019-08-091-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for removing __udivdi3() from the RISC-V architecture-specific files, convert its one user to use do_div(). This avoids breaking the RV32 build after __udivdi3() is removed. This second version removes the assignment of the remainder to an unused temporary variable. Thanks to Nicolas Pitre <nico@fluxnic.net> for the suggestion. Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Cc: Nicolas Pitre <nico@fluxnic.net>
| * | dt-bindings: Update the riscv,isa string descriptionAtish Patra2019-08-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the RISC-V specification states that ISA description strings are case-insensitive, there's no functional difference between mixed-case, upper-case, and lower-case ISA strings. Thus, to simplify parsing, specify that the letters present in "riscv,isa" must be all lowercase. Suggested-by: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
| * | RISC-V: Remove per cpu clocksourceAtish Patra2019-08-061-4/+2
| |/ | | | | | | | | | | | | | | There is only one clocksource in RISC-V. The boot cpu initializes that clocksource. No need to keep a percpu data structure. Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
* | Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2019-08-117-28/+48
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A few fixes for x86: - Don't reset the carefully adjusted build flags for the purgatory and remove the unwanted flags instead. The 'reset all' approach led to build fails under certain circumstances. - Unbreak CLANG build of the purgatory by avoiding the builtin memcpy/memset implementations. - Address missing prototype warnings by including the proper header - Fix yet more fall-through issues" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/lib/cpu: Address missing prototypes warning x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS x86/purgatory: Do not use __builtin_memcpy and __builtin_memset x86: mtrr: cyrix: Mark expected switch fall-through x86/ptrace: Mark expected switch fall-through
| * | x86/lib/cpu: Address missing prototypes warningValdis Klētnieks2019-08-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building with W=1, warnings about missing prototypes are emitted: CC arch/x86/lib/cpu.o arch/x86/lib/cpu.c:5:14: warning: no previous prototype for 'x86_family' [-Wmissing-prototypes] 5 | unsigned int x86_family(unsigned int sig) | ^~~~~~~~~~ arch/x86/lib/cpu.c:18:14: warning: no previous prototype for 'x86_model' [-Wmissing-prototypes] 18 | unsigned int x86_model(unsigned int sig) | ^~~~~~~~~ arch/x86/lib/cpu.c:33:14: warning: no previous prototype for 'x86_stepping' [-Wmissing-prototypes] 33 | unsigned int x86_stepping(unsigned int sig) | ^~~~~~~~~~~~ Add the proper include file so the prototypes are there. Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/42513.1565234837@turing-police
| * | x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGSNick Desaulniers2019-08-081-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | KBUILD_CFLAGS is very carefully built up in the top level Makefile, particularly when cross compiling or using different build tools. Resetting KBUILD_CFLAGS via := assignment is an antipattern. The comment above the reset mentions that -pg is problematic. Other Makefiles use `CFLAGS_REMOVE_file.o = $(CC_FLAGS_FTRACE)` when CONFIG_FUNCTION_TRACER is set. Prefer that pattern to wiping out all of the important KBUILD_CFLAGS then manually having to re-add them. Seems also that __stack_chk_fail references are generated when using CONFIG_STACKPROTECTOR or CONFIG_STACKPROTECTOR_STRONG. Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality") Reported-by: Vaibhav Rustagi <vaibhavrustagi@google.com> Suggested-by: Peter Zijlstra <peterz@infradead.org> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Vaibhav Rustagi <vaibhavrustagi@google.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190807221539.94583-2-ndesaulniers@google.com
| * | x86/purgatory: Do not use __builtin_memcpy and __builtin_memsetNick Desaulniers2019-08-084-23/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implementing memcpy and memset in terms of __builtin_memcpy and __builtin_memset is problematic. GCC at -O2 will replace calls to the builtins with calls to memcpy and memset (but will generate an inline implementation at -Os). Clang will replace the builtins with these calls regardless of optimization level. $ llvm-objdump -dr arch/x86/purgatory/string.o | tail 0000000000000339 memcpy: 339: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax 000000000000033b: R_X86_64_64 memcpy 343: ff e0 jmpq *%rax 0000000000000345 memset: 345: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax 0000000000000347: R_X86_64_64 memset 34f: ff e0 Such code results in infinite recursion at runtime. This is observed when doing kexec. Instead, reuse an implementation from arch/x86/boot/compressed/string.c. This requires to implement a stub function for warn(). Also, Clang may lower memcmp's that compare against 0 to bcmp's, so add a small definition, too. See also: commit 5f074f3e192f ("lib/string.c: implement a basic bcmp") Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality") Reported-by: Vaibhav Rustagi <vaibhavrustagi@google.com> Debugged-by: Vaibhav Rustagi <vaibhavrustagi@google.com> Debugged-by: Manoj Gupta <manojgupta@google.com> Suggested-by: Alistair Delva <adelva@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Vaibhav Rustagi <vaibhavrustagi@google.com> Cc: stable@vger.kernel.org Link: https://bugs.chromium.org/p/chromium/issues/detail?id=984056 Link: https://lkml.kernel.org/r/20190807221539.94583-1-ndesaulniers@google.com
| * | x86: mtrr: cyrix: Mark expected switch fall-throughGustavo A. R. Silva2019-08-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mark switch cases where we are expecting to fall through. Fix the following warning (Building: i386_defconfig i386): arch/x86/kernel/cpu/mtrr/cyrix.c:99:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lkml.kernel.org/r/20190805201712.GA19927@embeddedor
| * | x86/ptrace: Mark expected switch fall-throughGustavo A. R. Silva2019-08-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mark switch cases where we are expecting to fall through. Fix the following warning (Building: allnoconfig i386): arch/x86/kernel/ptrace.c:202:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (unlikely(value == 0)) ^ arch/x86/kernel/ptrace.c:206:2: note: here default: ^~~~~~~ Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lkml.kernel.org/r/20190805195654.GA17831@embeddedor
* | | Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds2019-08-1114-16/+69
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf tooling fixes from Thomas Gleixner: "Perf tooling fixes all over the place: - Fix the selection of the main thread COMM in db-export - Fix the disassemmbly display for BPF in annotate - Fix cpumap mask setup in perf ftrace when only one CPU is present - Add the missing 'cpu_clk_unhalted.core' event - Fix CPU 0 bindings in NUMA benchmarks - Fix the module size calculations for s390 - Handle the gap between kernel end and module start on s390 correctly - Build and typo fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf pmu-events: Fix missing "cpu_clk_unhalted.core" event perf annotate: Fix s390 gap between kernel end and module start perf record: Fix module size on s390 perf tools: Fix include paths in ui directory perf tools: Fix a typo in a variable name in the Documentation Makefile perf cpumap: Fix writing to illegal memory in handling cpumap mask perf ftrace: Fix failure to set cpumask when only one cpu is present perf db-export: Fix thread__exec_comm() perf annotate: Fix printing of unaugmented disassembled instructions from BPF perf bench numa: Fix cpu0 binding
| * \ \ Merge tag 'perf-urgent-for-mingo-5.3-20190808' of ↵Thomas Gleixner2019-08-0814-16/+69
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent perf/urgent fixes: db-export: Adrian Hunter: - Fix thread__exec_comm() picking of main thread COMM for pre-existing, synthesized from /proc data records. annotate: Arnaldo Carvalho de Melo: - Fix printing of unaugmented disassembled instructions from BPF, some lines were leaving leftovers from the previous screen, due to use of newlines by binutils's libopcode disassembler. perf ftrace: He Zhe: - Fix cpumask problems when only one CPU is present. PMU events: Jin Yao: - Add missing "cpu_clk_unhalted.core" event. perf bench: Jiri Olsa: - Fix cpu0 binding in the NUMA benchmarks. s390: Thomas Richter: - Fix module size calculations. build system: Masanari Iida: - Fix a typo in a variable name in the Documentation Makefile misc: Ian Rogers: - Fix include paths in ui directory. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | perf pmu-events: Fix missing "cpu_clk_unhalted.core" eventJin Yao2019-08-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The events defined in pmu-events JSON are parsed and added into perf tool. For fixed counters, we handle the encodings between JSON and perf by using a static array fixed[]. But the fixed[] has missed an important event "cpu_clk_unhalted.core". For example, on the Tremont platform, [root@localhost ~]# perf stat -e cpu_clk_unhalted.core -a event syntax error: 'cpu_clk_unhalted.core' \___ parser error With this patch, the event cpu_clk_unhalted.core can be parsed. [root@localhost perf]# ./perf stat -e cpu_clk_unhalted.core -a -vvv ------------------------------------------------------------ perf_event_attr: type 4 size 112 config 0x3c sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest 1 ------------------------------------------------------------ ... Signed-off-by: Jin Yao <yao.jin@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jin Yao <yao.jin@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20190729072755.2166-1-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | perf annotate: Fix s390 gap between kernel end and module startThomas Richter2019-08-083-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During execution of command 'perf top' the error message: Not enough memory for annotating '__irf_end' symbol!) is emitted from this call sequence: __cmd_top perf_top__mmap_read perf_top__mmap_read_idx perf_event__process_sample hist_entry_iter__add hist_iter__top_callback perf_top__record_precise_ip hist_entry__inc_addr_samples symbol__inc_addr_samples symbol__get_annotation symbol__alloc_hist In this function the size of symbol __irf_end is calculated. The size of a symbol is the difference between its start and end address. When the symbol was read the first time, its start and end was set to: symbol__new: __irf_end 0xe954d0-0xe954d0 which is correct and maps with /proc/kallsyms: root@s8360046:~/linux-4.15.0/tools/perf# fgrep _irf_end /proc/kallsyms 0000000000e954d0 t __irf_end root@s8360046:~/linux-4.15.0/tools/perf# In function symbol__alloc_hist() the end of symbol __irf_end is symbol__alloc_hist sym:__irf_end start:0xe954d0 end:0x3ff80045a8 which is identical with the first module entry in /proc/kallsyms This results in a symbol size of __irf_req for histogram analyses of 70334140059072 bytes and a malloc() for this requested size fails. The root cause of this is function __dso__load_kallsyms() +-> symbols__fixup_end() Function symbols__fixup_end() enlarges the last symbol in the kallsyms map: # fgrep __irf_end /proc/kallsyms 0000000000e954d0 t __irf_end # to the start address of the first module: # cat /proc/kallsyms | sort | egrep ' [tT] ' .... 0000000000e952d0 T __security_initcall_end 0000000000e954d0 T __initramfs_size 0000000000e954d0 t __irf_end 000003ff800045a8 T fc_get_event_number [scsi_transport_fc] 000003ff800045d0 t store_fc_vport_disable [scsi_transport_fc] 000003ff800046a8 T scsi_is_fc_rport [scsi_transport_fc] 000003ff800046d0 t fc_target_setup [scsi_transport_fc] On s390 the kernel is located around memory address 0x200, 0x10000 or 0x100000, depending on linux version. Modules however start some- where around 0x3ff xxxx xxxx. This is different than x86 and produces a large gap for which histogram allocation fails. Fix this by detecting the kernel's last symbol and do no adjustment for it. Introduce a weak function and handle s390 specifics. Reported-by: Klaus Theurich <klaus.theurich@de.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20190724122703.3996-2-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | perf record: Fix module size on s390Thomas Richter2019-08-083-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On s390 the modules loaded in memory have the text segment located after the GOT and Relocation table. This can be seen with this output: [root@m35lp76 perf]# fgrep qeth /proc/modules qeth 151552 1 qeth_l2, Live 0x000003ff800b2000 ... [root@m35lp76 perf]# cat /sys/module/qeth/sections/.text 0x000003ff800b3990 [root@m35lp76 perf]# There is an offset of 0x1990 bytes. The size of the qeth module is 151552 bytes (0x25000 in hex). The location of the GOT/relocation table at the beginning of a module is unique to s390. commit 203d8a4aa6ed ("perf s390: Fix 'start' address of module's map") adjusts the start address of a module in the map structures, but does not adjust the size of the modules. This leads to overlapping of module maps as this example shows: [root@m35lp76 perf] # ./perf report -D 0 0 0xfb0 [0xa0]: PERF_RECORD_MMAP -1/0: [0x3ff800b3990(0x25000) @ 0]: x /lib/modules/.../qeth.ko.xz 0 0 0x1050 [0xb0]: PERF_RECORD_MMAP -1/0: [0x3ff800d85a0(0x8000) @ 0]: x /lib/modules/.../ip6_tables.ko.xz The module qeth.ko has an adjusted start address modified to b3990, but its size is unchanged and the module ends at 0x3ff800d8990. This end address overlaps with the next modules start address of 0x3ff800d85a0. When the size of the leading GOT/Relocation table stored in the beginning of the text segment (0x1990 bytes) is subtracted from module qeth end address, there are no overlaps anymore: 0x3ff800d8990 - 0x1990 = 0x0x3ff800d7000 which is the same as 0x3ff800b2000 + 0x25000 = 0x0x3ff800d7000. To fix this issue, also adjust the modules size in function arch__fix_module_text_start(). Add another function parameter named size and reduce the size of the module when the text segment start address is changed. Output after: 0 0 0xfb0 [0xa0]: PERF_RECORD_MMAP -1/0: [0x3ff800b3990(0x23670) @ 0]: x /lib/modules/.../qeth.ko.xz 0 0 0x1050 [0xb0]: PERF_RECORD_MMAP -1/0: [0x3ff800d85a0(0x7a60) @ 0]: x /lib/modules/.../ip6_tables.ko.xz Reported-by: Stefan Liebler <stli@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: stable@vger.kernel.org Fixes: 203d8a4aa6ed ("perf s390: Fix 'start' address of module's map") Link: http://lkml.kernel.org/r/20190724122703.3996-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | perf tools: Fix include paths in ui directoryIan Rogers2019-08-082-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These paths point to the wrong location but still work because they get picked up by a -I flag that happens to direct to the correct file. Fix paths to point to the correct location without -I flags. Signed-off-by: Ian Rogers <irogers@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/20190731225441.233800-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | perf tools: Fix a typo in a variable name in the Documentation MakefileMasanari Iida2019-08-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fix a spelling typo in a variable name in the Documentation Makefile. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20190801032812.25018-1-standby24x7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | perf cpumap: Fix writing to illegal memory in handling cpumap maskHe Zhe2019-08-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpu_map__snprint_mask() would write to illegal memory pointed by zalloc(0) when there is only one cpu. This patch fixes the calculation and adds sanity check against the input parameters. Signed-off-by: He Zhe <zhe.he@windriver.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Fixes: 4400ac8a9a90 ("perf cpumap: Introduce cpu_map__snprint_mask()") Link: http://lkml.kernel.org/r/1564734592-15624-2-git-send-email-zhe.he@windriver.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
| | * | | perf ftrace: Fix failure to set cpumask when only one cpu is presentHe Zhe2019-08-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The buffer containing the string used to set cpumask is overwritten at the end of the string later in cpu_map__snprint_mask due to not enough memory space, when there is only one cpu. And thus causes the following failure: $ perf ftrace ls failed to reset ftrace $ This patch fixes the calculation of the cpumask string size. Signed-off-by: He Zhe <zhe.he@windriver.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Fixes: dc23103278c5 ("perf ftrace: Add support for -a and -C option") Link: http://lkml.kernel.org/r/1564734592-15624-1-git-send-email-zhe.he@windriver.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-25 04:54:11 +0100