Re: Subject: Re: [PATCH v3] kbuild: add support for zstd compressed modules
On Fri, Apr 9, 2021 at 1:31 PM Sedat Dilek wrote: > > On Fri, Apr 9, 2021 at 1:10 PM Piotr Gorski wrote: > > > > I originally posted the patch in a different form [1] even before > > Masahiro's changes. > > I've been testing this solution since December last year and posted it in > > March this year, > > after I made sure everything was working fine. This patch was tested by > > Oleksandr and he also didn't report any objections. [2] > > > > Masahiro notified me about the planned changes [3] and asked me to resend > > this patch, adjusted to those changes, which I did. > > > > My current logs: > > > > lucjan@archlinux ~ $ zgrep CONFIG_DEBUG_INFO /proc/config.gz > > CONFIG_DEBUG_INFO=y > > # CONFIG_DEBUG_INFO_REDUCED is not set > > # CONFIG_DEBUG_INFO_COMPRESSED is not set > > # CONFIG_DEBUG_INFO_SPLIT is not set > > CONFIG_DEBUG_INFO_DWARF4=y > > CONFIG_DEBUG_INFO_BTF=y > > CONFIG_DEBUG_INFO_BTF_MODULES=y > > lucjan@archlinux ~ $ zgrep CONFIG_MODULE_COMPRESS_ZSTD /proc/config.gz > > CONFIG_MODULE_COMPRESS_ZSTD=y > > CONFIG_MODULE_COMPRESS_ZSTD_LEVEL=19 > > > > Pay no attention to CONFIG_MODULE_COMPRESS_ZSTD_LEVEL as this is not in the > > upstream, it's an additional patch I use. > > > > The only difference - I don't use clang. Maybe those who use will comment > > on this. > > I relied on the opinions of Oleksander and a dozen other users who reported > > no errors in using zstd module compression. > > > > [1] https://marc.info/?l=linux-kbuild=161710402402989=2 > > > > [2] https://marc.info/?l=linux-kbuild=161710503403517=2 > > > > [3] https://marc.info/?l=linux-kbuild=161780602730829=2 > > I am a big fan of ZSTD and have it as default in all available Linux > Kconfigs and Debian's initramfs-tools. > So, I am highly interested in getting this fixed. > > Unfortunately, I have thrown away my yesterday's Clang-LTO build and > switched to Clang-CFI with builddeb - should do handle the same way. > > I see three iwlwifi.ko (as an example): > > $ LC_ALL=C ll drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > -rw-r--r-- 1 dileks dileks 8.2M Apr 9 11:07 > drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > > $ file drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: ELF 64-bit LSB > relocatable, x86-64, version 1 (SYSV), > BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, with > debug_info, not stripped > > That iwlwifi.ko with debug-info is optimized when moving to > debian/linux-image-dbg directory: > > $ LC_ALL=C ll > debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > -rw-r--r-- 1 dileks dileks 7.9M Apr 9 11:18 > debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > > $ file > debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: > ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), > BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, with > debug_info, not stripped > > And think it's shrunk down and included debian/linux-image directory: > > $ LC_ALL=C ll > debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > -rw-r--r-- 1 dileks dileks 694K Apr 9 11:18 > debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > > $ file > debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko > debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: > ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), > BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, not stripped > > I speculate both iwlwifi.ko below debian directory should be ZSTD-compressed. > Fact is the one with debug-info is done correctly. > Might be builddeb script needs a special treatment. > OK, I see (sorry Gmail truncates my paste of snippet). We need to add in this block a CONFIG_MODULE_COMPRESS_XXX handling: [ scripts/package/builddeb ] #159: if is_enabled CONFIG_MODULES; then ... #184: fi Maybe other scripts in scripts/package/ directory, too. What do you say Masahiro? I have to admit I never used any compression for kernel-modules before and after recent changes in . - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/tree/scripts/package/builddeb?h=kbuild#n159
Re: Subject: Re: [PATCH v3] kbuild: add support for zstd compressed modules
On Fri, Apr 9, 2021 at 1:10 PM Piotr Gorski wrote: > > I originally posted the patch in a different form [1] even before Masahiro's > changes. > I've been testing this solution since December last year and posted it in > March this year, > after I made sure everything was working fine. This patch was tested by > Oleksandr and he also didn't report any objections. [2] > > Masahiro notified me about the planned changes [3] and asked me to resend > this patch, adjusted to those changes, which I did. > > My current logs: > > lucjan@archlinux ~ $ zgrep CONFIG_DEBUG_INFO /proc/config.gz > CONFIG_DEBUG_INFO=y > # CONFIG_DEBUG_INFO_REDUCED is not set > # CONFIG_DEBUG_INFO_COMPRESSED is not set > # CONFIG_DEBUG_INFO_SPLIT is not set > CONFIG_DEBUG_INFO_DWARF4=y > CONFIG_DEBUG_INFO_BTF=y > CONFIG_DEBUG_INFO_BTF_MODULES=y > lucjan@archlinux ~ $ zgrep CONFIG_MODULE_COMPRESS_ZSTD /proc/config.gz > CONFIG_MODULE_COMPRESS_ZSTD=y > CONFIG_MODULE_COMPRESS_ZSTD_LEVEL=19 > > Pay no attention to CONFIG_MODULE_COMPRESS_ZSTD_LEVEL as this is not in the > upstream, it's an additional patch I use. > > The only difference - I don't use clang. Maybe those who use will comment on > this. > I relied on the opinions of Oleksander and a dozen other users who reported > no errors in using zstd module compression. > > [1] https://marc.info/?l=linux-kbuild=161710402402989=2 > > [2] https://marc.info/?l=linux-kbuild=161710503403517=2 > > [3] https://marc.info/?l=linux-kbuild=161780602730829=2 I am a big fan of ZSTD and have it as default in all available Linux Kconfigs and Debian's initramfs-tools. So, I am highly interested in getting this fixed. Unfortunately, I have thrown away my yesterday's Clang-LTO build and switched to Clang-CFI with builddeb - should do handle the same way. I see three iwlwifi.ko (as an example): $ LC_ALL=C ll drivers/net/wireless/intel/iwlwifi/iwlwifi.ko -rw-r--r-- 1 dileks dileks 8.2M Apr 9 11:07 drivers/net/wireless/intel/iwlwifi/iwlwifi.ko $ file drivers/net/wireless/intel/iwlwifi/iwlwifi.ko drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, with debug_info, not stripped That iwlwifi.ko with debug-info is optimized when moving to debian/linux-image-dbg directory: $ LC_ALL=C ll debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko -rw-r--r-- 1 dileks dileks 7.9M Apr 9 11:18 debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko $ file debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko debian/linux-image-dbg/usr/lib/debug/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, with debug_info, not stripped And think it's shrunk down and included debian/linux-image directory: $ LC_ALL=C ll debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko -rw-r--r-- 1 dileks dileks 694K Apr 9 11:18 debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko $ file debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko debian/linux-image/lib/modules/5.12.0-rc6-5-amd64-clang12-cfi/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=78d593f4fd2b8efe81caeb8f1ea729107a33e244, not stripped I speculate both iwlwifi.ko below debian directory should be ZSTD-compressed. Fact is the one with debug-info is done correctly. Might be builddeb script needs a special treatment. - Sedat -
Re: Subject: Re: [PATCH v3] kbuild: add support for zstd compressed modules
On Thu, Apr 8, 2021 at 11:05 PM Piotr Gorski wrote: > > No, the --rm option is essential. xz and gzip have the --rm option built in > as opposed to zstd, which is why I used it. I've been using zstd module > compression since last december (although I set a different compression level > on mine) and everything works fine. Oleksandr also tested it at his place and > didn't report any objections. [ CC me I am not subscribed to linux-kbuild or linux-kernel ] [ CC Nick ] Unfortunately, I do not find my initial posting which has all information. I add the link to the thread on linux-kbuild ML. So, I gave you as much information as I have (linux-config, make-line etc.) and you write "everything works fine"? What do you mean by "everything" - different compressors and none? Is that working "fine"? What build environment do you use? Here: Debian/testing AMD64. Did you try with... CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_DWARF5=y CONFIG_MODULE_COMPRESS_ZSTD=y ...Kconfigs enabled? As said I use builddeb from scripts directory to generate my Debian packages. Any chance you can test with builddeb? I have enabled Clang-LTO Kconfig. Tried with Clang-LTO Kconfig? This worked *before* and *after*... kbuild: add support for zstd compressed modules kbuild: remove CONFIG_MODULE_COMPRESS (CC Nick as he is listed as a reviewer here) ... not within my build-environment. For me this is a *regression*. - Sedat - [1] https://marc.info/?t=16179091462=1=2
Re: Usage of CXX in tools directory
> So you need to pass CXX=clang++ manually when playing in tools directory: > > MAKE="make V=1 > MAKE_OPTS="HOSTCC=clang HOSTCXX=clang++ HOSTLD=ld.lld CC=clang > CXX=clang++ LD=ld.lld LLVM=1 LLVM_IAS=1" > MAKE_OPTS="MAKE_OPTS $PAHOLE=/opt/pahole/bin/pahole" > > $ LC_ALL=C $MAKE $MAKE_OPTS -C tools/testing/selftests/bpf/ clean > $ LC_ALL=C $MAKE $MAKE_OPTS -C tools/testing/selftests/bpf/ > Correct: MAKE="make V=1" MAKE_OPTS="HOSTCC=clang HOSTCXX=clang++ HOSTLD=ld.lld CC=clang CXX=clang++ LD=ld.lld LLVM=1 LLVM_IAS=1" MAKE_OPTS="$MAKE_OPTS PAHOLE=/opt/pahole/bin/pahole" - Sedat -
Usage of CXX in tools directory
[ Please CC me I am not subscribed to all mailing-lists ] [ Please CC some more folks if you like ] Hi, when dealing/experimenting with BPF together with pahole/dwarves and dwarf-v5 and clang-lto I fell over that there is usage of CXX in tools directory. Especially, I wanted to build and run test_progs from BPF selftests. One BPF selftest called "test_cpp" used GNU/g++ (and even /usr/bin/ld) and NOT LLVM/clang++. For details see the linux-bpf/dwarves thread "[PATCH dwarves] dwarf_loader: handle DWARF5 DW_OP_addrx properly" in [1]. Lemme check: $ git grep CXX tools/ tools/build/Build.include:cxx_flags = -Wp,-MD,$(depfile) -Wp,-MT,$@ $(CXXFLAGS) -D"BUILD_STR(s)=\#s" $(CXXFLAGS_$(basetarget).o) $(CXXFLAGS_$(obj)) tools/build/Makefile.build:quiet_cmd_cxx_o_c = CXX $@ tools/build/Makefile.build: cmd_cxx_o_c = $(CXX) $(cxx_flags) -c -o $@ $< tools/build/Makefile.feature: feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CC="$(CC)" CXX="$(CXX)" CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" CXXFLAGS="$(EXTRA_CXXFLAGS) $(FEATURE_CHECK_CXXFLAGS-$(1))" LDFLAGS="$(LDFLAGS) $(FEATURE_CHECK_LDFLAGS-$(1))" -C $(feature_dir) $(OUTPUT_FEATURES)test-$1.bin >/dev/nu ll 2>/dev/null && echo 1 || echo 0) tools/build/feature/Makefile:__BUILDXX = $(CXX) $(CXXFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.cpp,$(@F)) $(LDFLAGS) ... tools/perf/Makefile.config:USE_CXX = 0 tools/perf/Makefile.config:CXXFLAGS += -DHAVE_LIBCLANGLLVM_SUPPORT -I$(shell $(LLVM_CONFIG) --includedir) tools/perf/Makefile.config:$(call detected,CONFIG_CXX) tools/perf/Makefile.config: USE_CXX = 1 tools/perf/Makefile.perf:export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK tools/perf/Makefile.perf:ifeq ($(USE_CXX), 1) tools/perf/util/Build:perf-$(CONFIG_CXX) += c++/ ... tools/scripts/Makefile.include:$(call allow-override,CXX,$(CROSS_COMPILE)g++) ... tools/testing/selftests/bpf/Makefile:CXX ?= $(CROSS_COMPILE)g++ tools/testing/selftests/bpf/Makefile: $(call msg,CXX,,$@) tools/testing/selftests/bpf/Makefile: $(Q)$(CXX) $(CFLAGS) $^ $(LDLIBS) -o $@ The problem is if you pass LLVM=1 there is no clang(++) assigned to CXX automagically. [2] says: LLVM has substitutes for GNU binutils utilities. Kbuild supports LLVM=1 to enable them. make LLVM=1 They can be enabled individually. The full list of the parameters: make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \ OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \ HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld [ EndOfQuote ] So you need to pass CXX=clang++ manually when playing in tools directory: MAKE="make V=1 MAKE_OPTS="HOSTCC=clang HOSTCXX=clang++ HOSTLD=ld.lld CC=clang CXX=clang++ LD=ld.lld LLVM=1 LLVM_IAS=1" MAKE_OPTS="MAKE_OPTS $PAHOLE=/opt/pahole/bin/pahole" $ LC_ALL=C $MAKE $MAKE_OPTS -C tools/testing/selftests/bpf/ clean $ LC_ALL=C $MAKE $MAKE_OPTS -C tools/testing/selftests/bpf/ Unsure, if tools needs a special treatment in things of CXX or LLVM=1 needs to be enhanced with CCX=clang++. If we have HOSTCXX why not have a CXX in toplevel Makefile? In "tools: Factor Clang, LLC and LLVM utils definitions" (see [3]) I did some factor-ing. For the records: Here Linus Git is my base. Ideas? Thanks. Regards, - Sedat - P.S.: Just a small note: I know there is less usage of CXX code in the linux-kernel. [1] https://lore.kernel.org/bpf/CA+icZUWh6YOkCKG72SndqUbQNwG+iottO4=cPyRRVjaHD2=0...@mail.gmail.com/T/#m22907f838d2d27be24e8959a53473a62f21cecea [2] https://www.kernel.org/doc/html/latest/kbuild/llvm.html#llvm-utilities [3] https://git.kernel.org/linus/211a741cd3e124bffdc13ee82e7e65f204e53f60
Re: [PATCH] qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute
On Fri, Apr 2, 2021 at 8:31 PM Nathan Chancellor wrote: > > On Fri, Apr 02, 2021 at 11:25:42AM -0700, Kees Cook wrote: > > On Fri, Apr 02, 2021 at 08:42:07AM +0200, Sedat Dilek wrote: > > > On Thu, Feb 25, 2021 at 10:25 PM Kees Cook wrote: > > > > > > > > On Thu, 11 Feb 2021 12:42:58 -0700, Nathan Chancellor wrote: > > > > > fw_cfg_showrev() is called by an indirect call in kobj_attr_show(), > > > > > which violates clang's CFI checking because fw_cfg_showrev()'s second > > > > > parameter is 'struct attribute', whereas the ->show() member of > > > > > 'struct > > > > > kobj_structure' expects the second parameter to be of type 'struct > > > > > kobj_attribute'. > > > > > > > > > > $ cat /sys/firmware/qemu_fw_cfg/rev > > > > > 3 > > > > > > > > > > [...] > > > > > > > > Applied to kspp/cfi/cleanups, thanks! > > > > > > > > [1/1] qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute > > > > https://git.kernel.org/kees/c/f5c4679d6c49 > > > > > > > > > > I have queued this up in my custom patchset > > > (for-5.12/kspp-cfi-cleanups-20210225). > > > > > > What is the plan to get this upstream? > > > > I haven't sent it to Linus yet -- I was expecting to batch more of these > > and send them for v5.13. (But if the kvm folks snag it, that's good > > too.) > > I am going to be putting the CFI series through its paces on both arm64 > and x86_64 over the next week or so on several different machines (in > fact, I am writing up a report right now) so I will probably have some > more of these as I find them. > This was just a friendly ping. Sami has sent some patches which I reported in the early stage of clang-cfi (x86-64) through subtree maintainers. It's up to you Nathan or kvm folks. Upstreamed patches means to me a RDC-ed custom patchset. - Sedat -
Re: [PATCH] qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute
On Thu, Feb 25, 2021 at 10:25 PM Kees Cook wrote: > > On Thu, 11 Feb 2021 12:42:58 -0700, Nathan Chancellor wrote: > > fw_cfg_showrev() is called by an indirect call in kobj_attr_show(), > > which violates clang's CFI checking because fw_cfg_showrev()'s second > > parameter is 'struct attribute', whereas the ->show() member of 'struct > > kobj_structure' expects the second parameter to be of type 'struct > > kobj_attribute'. > > > > $ cat /sys/firmware/qemu_fw_cfg/rev > > 3 > > > > [...] > > Applied to kspp/cfi/cleanups, thanks! > > [1/1] qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute > https://git.kernel.org/kees/c/f5c4679d6c49 > I have queued this up in my custom patchset (for-5.12/kspp-cfi-cleanups-20210225). What is the plan to get this upstream? Feel free to add my: Tested-by: Sedat Dilek - Sedat -
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Sat, Mar 27, 2021 at 9:02 PM Linus Torvalds wrote: > > On Sat, Mar 27, 2021 at 5:08 AM Sedat Dilek wrote: > > > > debian-5.10.19 as host-kernel: > > 11655.755564957 seconds time elapsed > > > > dileks-5.12-rc3 plus x86-nops as host-kernel: > > 11941.439350080 seconds time elapsed > > That's 2.5% - a huge difference. Particularly since kernel build times > shouldn't even be that kernel-intensive. > > I think there's something else going on than the nops. Same config? > There are likely many other differences between 5.10.19 and 5.12-rc3. > > So can you check just plain 5.12-rc3 and then 5.12-rc3 plus x86-nops, > with otherwise identical configuration? > Hi Linus, I re-checked my linux-config and custom patchset. I had "kbuild: add CONFIG_VMLINUX_MAP expert option" in my queue and build with CONFIG_VMLINUX_MAP=y. This option generated here an approx. 30MiB big vmlinux.map file. Cannot say how long this is taking in seconds but that can explain the the time-diff. [ The above option is helpful to analyze a recent Linux-kernel build with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y. Always, I was able to build but not boot on bare metal with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y. With a LLVM toolchain, of course. ] ( In the meantime Debian has a 5.20.26 kernel released - so if you want I can re-test with Linux v5.12-rc5. ) Regards, - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=babd8cd96d333cb83c9b8abf4f01ab1f161d6ec4
Re: [PATCH 0/3] Fix CONFIG_FUNCTION_TRACER with clang
On Fri, Mar 26, 2021 at 2:07 PM Nathan Chancellor wrote: > > On Fri, Mar 26, 2021 at 09:37:55AM +0100, Sedat Dilek wrote: > > On Thu, Mar 25, 2021 at 11:38 PM Nathan Chancellor > > wrote: > > > > > > Hi all, > > > > > > This series fixes function tracing with clang. > > > > > > Patch 1 adjusts the mcount regex in scripts/recordmcount.pl to handle > > > the presence of PLT relocations, which happen with clang. Without this, > > > the mcount_loc section will not be created properly. > > > > > > Patch 2 adds a workaround for clang less than 13.0.0 in relation to the > > > mcount symbol name, which was "mcount" rather than "_mcount". This was > > > written as a separate patch so that it can be reverted when the minimum > > > clang version is bumped to clang 13.0.0. > > > > > > Patch 3 avoids a build error when -fpatchable-function-entry is not > > > available, which is the case with clang less than 13.0.0. This will make > > > dynamic ftrace unavailable but all of the other function tracing should > > > work due to the prescence of the previous patch. > > > > > > I am hoping this series can go in as fixes for 5.12, due to patch 3, but > > > if not, they can always be backported (patches 1 and 2 are already > > > marked for stable). > > > > > > This series has been build tested with gcc-8 through gcc-10 and clang-11 > > > through clang-13 with defconfig and nommu_virt_defconfig plus > > > CONFIG_FTRACE=y and CONFIG_FUNCTION_TRACER=y then boot tested under > > > QEMU. > > > > > > Cheers, > > > Nathan > > > > > > Nathan Chancellor (3): > > > scripts/recordmcount.pl: Fix RISC-V regex for clang > > > riscv: Workaround mcount name prior to clang-13 > > > riscv: Select HAVE_DYNAMIC_FTRACE when -fpatchable-function-entry is > > > available > > > > > > > Does this only fixes stuff for clang + riscv? > > Yes. > > > If so, please put a label "riscv" also in the cover-letter. > > Sure, my apologies for not doing that in the first place, I must have > been in a rush with the cover letter. > > In my defense, I think the titles of my commit messages and the diffstat > below make that obvious without the tag :) > No need for any apologies. I was fooled as you sent two triple-patchset nearly simultaneously. This riscv patchset here was not of interest to me. - Sedat - > > > - Sedat - > > > > > arch/riscv/Kconfig | 2 +- > > > arch/riscv/include/asm/ftrace.h | 14 -- > > > arch/riscv/kernel/mcount.S | 10 +- > > > scripts/recordmcount.pl | 2 +- > > > 4 files changed, 19 insertions(+), 9 deletions(-) > > > > > > -- > > > 2.31.0 > > >
Re: [PATCH 0/2] x86: Remove ideal_nops[]
Out of curiosity I tried in my build-environment and my testing-rules to have comparable numbers... ..without passing "V=1" and "KBUILD_VERBOSE=1" as make-options: NOTE: Identical linux-config plus LLVM/Clang v12.0.0-rc3. debian-5.10.19 as host-kernel: 11655.755564957 seconds time elapsed dileks-5.12-rc3 plus x86-nops as host-kernel: 11941.439350080 seconds time elapsed I compared the build-times only: Approx. 04:45 [mm:ss] in the worst case. ( Brewing time of a strong Turkish tea-bag ~5mins. ) I will keep both make-options to see what's going on in my builds. - Sedat -
Re: linux-next: build failure after merge of the tip tree
On Fri, Mar 26, 2021 at 2:11 PM Borislav Petkov wrote: > > On Fri, Mar 26, 2021 at 09:57:43AM +0100, Sedat Dilek wrote: > > The commit b90829704780 "bpf: Use NOP_ATOMIC5 instead of > > emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG" is now in Linus Git > > (see [1]). > > > > Where will Stephen's fixup-patch be carried? > > Linux-next? > > net-next? > > ? > > I guess we'll resolve it on our end and pick up sfr's patch, most > likely. > > Thanks for letting me know. > Sounds good to me. So you need: $ grep CONFIG_BPF_JIT= .config 1795:CONFIG_BPF_JIT=y $ git grep CONFIG_BPF_JIT arch/x86/net/Makefile arch/x86/net/Makefile:obj-$(CONFIG_BPF_JIT) += bpf_jit_comp32.o arch/x86/net/Makefile:obj-$(CONFIG_BPF_JIT) += bpf_jit_comp.o I wonder why Stephen's fixup-patch was not carried in recent Linux-next releases. Wild speculation - no random-config with x86(-64) plus CONFIG_BPF_JIT=y? Anyway, I integrated Stephen's fixup-patch into my custom patchset. $ git log --oneline --author="Stephen Rothwell" v5.12-rc4.. 600417efac59 (for-5.12/x86-cpu-20210315-net-bpf-sfr) x86: fix up for "bpf: Use NOP_ATOMIC5 instead of emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG" Feel free to add my: Tested-by: Sedat Dilek # LLVM/Clang v12.0.0-rc3 (x86-64) - Sedat -
Re: linux-next: build failure after merge of the tip tree
On Mon, Mar 22, 2021 at 10:02 AM Borislav Petkov wrote:
>
> On Mon, Mar 22, 2021 at 02:37:14PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > arch/x86/net/bpf_jit_comp.c: In function 'arch_prepare_bpf_trampoline':
> > arch/x86/net/bpf_jit_comp.c:2015:16: error: 'ideal_nops' undeclared (first
> > use in this function)
> > 2015 | memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> > |^~
> > arch/x86/net/bpf_jit_comp.c:2015:16: note: each undeclared identifier is
> > reported only once for each function it appears in
> > arch/x86/net/bpf_jit_comp.c:2015:27: error: 'NOP_ATOMIC5' undeclared (first
> > use in this function); did you mean 'GFP_ATOMIC'?
> > 2015 | memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> > | ^~~
> > | GFP_ATOMIC
> >
> > Caused by commit
> >
> > a89dfde3dc3c ("x86: Remove dynamic NOP selection")
> >
> > interacting with commit
> >
> > b90829704780 ("bpf: Use NOP_ATOMIC5 instead of emit_nops(, 5) for
> > BPF_TRAMP_F_CALL_ORIG")
> >
> > from the net tree.
> >
> > I have applied the following merge fix patch.
> >
> > From: Stephen Rothwell
> > Date: Mon, 22 Mar 2021 14:30:37 +1100
> > Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of
> > emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG"
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > arch/x86/net/bpf_jit_comp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index db50ab14df67..e2b5da5d441d 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -2012,7 +2012,7 @@ int arch_prepare_bpf_trampoline(struct
> > bpf_tramp_image *im, void *image, void *i
> > /* remember return value in a stack for bpf prog to access */
> > emit_stx(, BPF_DW, BPF_REG_FP, BPF_REG_0, -8);
> > im->ip_after_call = prog;
> > - memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> > + memcpy(prog, x86_nops[5], X86_PATCH_SIZE);
> > prog += X86_PATCH_SIZE;
> > }
> >
> > --
>
> I guess we can do the same as with the hyperv tree - the folks who send the
> respective branches to Linus in the next merge window should point to this
> patch
> of yours which Linus can apply after merging the second branch in order.
>
> Thx.
>
The commit b90829704780 "bpf: Use NOP_ATOMIC5 instead of
emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG" is now in Linus Git
(see [1]).
Where will Stephen's fixup-patch be carried?
Linux-next?
net-next?
?
Thanks.
- Sedat -
[1] https://git.kernel.org/linus/b9082970478009b778aa9b22d5561eef35b53b63
Re: [PATCH 1/3] x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)
On Fri, Mar 26, 2021 at 1:04 AM Nathan Chancellor wrote: > > From: John Millikin > > When cross-compiling with Clang, the `$(CLANG_FLAGS)' variable > contains additional flags needed to build C and assembly sources > for the target platform. Normally this variable is automatically > included in `$(KBUILD_CFLAGS)' by via the top-level Makefile. > > The x86 real-mode makefile builds `$(REALMODE_CFLAGS)' from a > plain assignment and therefore drops the Clang flags. This causes > Clang to not recognize x86-specific assembler directives: > > arch/x86/realmode/rm/header.S:36:1: error: unknown directive > .type real_mode_header STT_OBJECT ; .size real_mode_header, > .-real_mode_header > ^ > > Explicit propagation of `$(CLANG_FLAGS)' to `$(REALMODE_CFLAGS)', > which is inherited by real-mode make rules, fixes cross-compilation > with Clang for x86 targets. > > Relevant flags: > > * `--target' sets the target architecture when cross-compiling. This > flag must be set for both compilation and assembly (`KBUILD_AFLAGS') > to support architecture-specific assembler directives. > > * `-no-integrated-as' tells clang to assemble with GNU Assembler > instead of its built-in LLVM assembler. This flag is set by default > unless `LLVM_IAS=1' is set, because the LLVM assembler can't yet > parse certain GNU extensions. > > Signed-off-by: John Millikin > Tested-by: Sedat Dilek > Signed-off-by: Nathan Chancellor I had John's v2 of this patch in my custom 5.11 patchset. Thanks for bringing this up again, Nathan. Later, I will test the triple patchset series. Feel free to add for this one: Tested-by: Sedat Dilek - Sedat - > --- > arch/x86/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index 2d6d5a28c3bf..9a73e0cea19c 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -33,6 +33,7 @@ REALMODE_CFLAGS += -ffreestanding > REALMODE_CFLAGS += -fno-stack-protector > REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), > -Wno-address-of-packed-member) > REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), > $(cc_stack_align4)) > +REALMODE_CFLAGS += $(CLANG_FLAGS) > export REALMODE_CFLAGS > > # BITS is used as extension for files which are available in a 32 bit > -- > 2.31.0 >
Re: [PATCH 0/3] Fix CONFIG_FUNCTION_TRACER with clang
On Thu, Mar 25, 2021 at 11:38 PM Nathan Chancellor wrote: > > Hi all, > > This series fixes function tracing with clang. > > Patch 1 adjusts the mcount regex in scripts/recordmcount.pl to handle > the presence of PLT relocations, which happen with clang. Without this, > the mcount_loc section will not be created properly. > > Patch 2 adds a workaround for clang less than 13.0.0 in relation to the > mcount symbol name, which was "mcount" rather than "_mcount". This was > written as a separate patch so that it can be reverted when the minimum > clang version is bumped to clang 13.0.0. > > Patch 3 avoids a build error when -fpatchable-function-entry is not > available, which is the case with clang less than 13.0.0. This will make > dynamic ftrace unavailable but all of the other function tracing should > work due to the prescence of the previous patch. > > I am hoping this series can go in as fixes for 5.12, due to patch 3, but > if not, they can always be backported (patches 1 and 2 are already > marked for stable). > > This series has been build tested with gcc-8 through gcc-10 and clang-11 > through clang-13 with defconfig and nommu_virt_defconfig plus > CONFIG_FTRACE=y and CONFIG_FUNCTION_TRACER=y then boot tested under > QEMU. > > Cheers, > Nathan > > Nathan Chancellor (3): > scripts/recordmcount.pl: Fix RISC-V regex for clang > riscv: Workaround mcount name prior to clang-13 > riscv: Select HAVE_DYNAMIC_FTRACE when -fpatchable-function-entry is > available > Does this only fixes stuff for clang + riscv? If so, please put a label "riscv" also in the cover-letter. - Sedat - > arch/riscv/Kconfig | 2 +- > arch/riscv/include/asm/ftrace.h | 14 -- > arch/riscv/kernel/mcount.S | 10 +- > scripts/recordmcount.pl | 2 +- > 4 files changed, 19 insertions(+), 9 deletions(-) > > -- > 2.31.0 > > -- > You received this message because you are subscribed to the Google Groups > "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clang-built-linux+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clang-built-linux/20210325223807.2423265-1-nathan%40kernel.org.
Re: [PATCH] iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()
On Mon, Mar 22, 2021 at 1:13 PM Jiri Kosina wrote: > > On Sat, 13 Mar 2021, Luca Coelho wrote: > > > > > > > > > > It's possible for iwl_pcie_enqueue_hcmd() to be called with > > > > > > > > > hard IRQs > > > > > > > > > disabled (e.g. from LED core). We can't enable BHs in such a > > > > > > > > > situation. > > > > > > > > > > > > > > > > > > Turn the unconditional BH-enable/BH-disable code into > > > > > > > > > hardirq-disable/conditional-enable. > > > > > > > > > > > > > > > > > > This fixes the warning below. > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > friendly ping on this one ... > > > > > > > > > > > > > > Luca, > > > > > > > > > > > > > > Johannes is telling me that he merged this patch internally, but > > > > > > > I have no > > > > > > > idea what is happening to it ... ? > > > > > > > > > > > > > > The reported splat is a clear bug, so it should be fixed one way > > > > > > > or the > > > > > > > other. > > > > > > > > > > > > Should I take this to wireless-drivers? > > > > > > > > > > I can't speak for the maintainers, but as far as I am concerned, it > > > > > definitely is a 5.12 material, as it fixes real scheduling bug. > > > > > > > > Yes, please take this to w-d. We have a similar patch internally, but > > > > there's a backlog and it will take me some time to get to it. I'll > > > > resolve eventual conflicts when time comes. > > > > > > Ok, can I have your ack for patchwork? > > > > Sorry, forgot that. > > > > Acked-by: Luca Coelho > > Sorry for sounding like broken record :) but this fix is still not in any > tree as far as I can tell. And it's fixing real scheduling in atomic bug. > > Thanks, > [ CC Chris Murphy ] A week ago Chris sent an email to linux-wireless with pointing to: https://bugzilla.kernel.org/show_bug.cgi?id=212297 AFAICS, that is the same bug. - Sedat -
Re: linux-next: build failure after merge of the tip tree
On Mon, Mar 22, 2021 at 4:39 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/net/bpf_jit_comp.c: In function 'arch_prepare_bpf_trampoline':
> arch/x86/net/bpf_jit_comp.c:2015:16: error: 'ideal_nops' undeclared (first
> use in this function)
> 2015 | memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> |^~
> arch/x86/net/bpf_jit_comp.c:2015:16: note: each undeclared identifier is
> reported only once for each function it appears in
> arch/x86/net/bpf_jit_comp.c:2015:27: error: 'NOP_ATOMIC5' undeclared (first
> use in this function); did you mean 'GFP_ATOMIC'?
> 2015 | memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> | ^~~
> | GFP_ATOMIC
>
> Caused by commit
>
> a89dfde3dc3c ("x86: Remove dynamic NOP selection")
>
> interacting with commit
>
> b90829704780 ("bpf: Use NOP_ATOMIC5 instead of emit_nops(, 5) for
> BPF_TRAMP_F_CALL_ORIG")
>
> from the net tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell
> Date: Mon, 22 Mar 2021 14:30:37 +1100
> Subject: [PATCH] x86: fix up for "bpf: Use NOP_ATOMIC5 instead of
> emit_nops(, 5) for BPF_TRAMP_F_CALL_ORIG"
>
> Signed-off-by: Stephen Rothwell
I had the same issue yesterday, when I had...
+
...on top of Linux v5.12-rc4.
( See [1] and [2] ).
I applied the same fix.
- Sedat -
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/cpu=a89dfde3dc3c2dbf56910af75e2d8b11ec5308f6
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b9082970478009b778aa9b22d5561eef35b53b63
> ---
> arch/x86/net/bpf_jit_comp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index db50ab14df67..e2b5da5d441d 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -2012,7 +2012,7 @@ int arch_prepare_bpf_trampoline(struct bpf_tramp_image
> *im, void *image, void *i
> /* remember return value in a stack for bpf prog to access */
> emit_stx(, BPF_DW, BPF_REG_FP, BPF_REG_0, -8);
> im->ip_after_call = prog;
> - memcpy(prog, ideal_nops[NOP_ATOMIC5], X86_PATCH_SIZE);
> + memcpy(prog, x86_nops[5], X86_PATCH_SIZE);
> prog += X86_PATCH_SIZE;
> }
>
> --
> 2.30.0
>
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Mon, Mar 15, 2021 at 11:14 PM Peter Zijlstra wrote: > > On Mon, Mar 15, 2021 at 07:23:29PM +0100, Sedat Dilek wrote: > > > You mean something like that ^^? > > > > - Sedat - > > > > [1] > > https://git.zx2c4.com/laptop-kernel/commit/?id=116badbe0a18bc36ba90acb8b80cff41f9ab0686 > > *shudder*, I was more thinking you'd simply add it to you CFLAGS when > building. I don't see any point in having that in Kconfig. Simply adding the CFLAGS to arch/x86/Makefile. If I forgot to mention: Tested-by: Sedat Dilek . # LLVM/Clang v12.0.0-rc3 - Sedat -
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Mon, Mar 15, 2021 at 7:10 PM Peter Zijlstra wrote: > > On Mon, Mar 15, 2021 at 06:04:41PM +0100, Sedat Dilek wrote: > > > make V=1 -j4 LLVM=1 LLVM_IAS=1 > > So for giggles I checked, neither GCC nor LLVM seem to emit prefix NOPs > when building with -march=sandybridge, they always use MOPL. > > Furthermore, the kernel explicitly sets: -falign-jumps=1 > -falign-loops=1, which, when not specified, default to 16 or so. > > This means that your userspace is *littered* with NOPL, even when you > build your entire distro from source with -march=sandybridge. > (arch/gentoo FTW I suppose). > That reminds me of the Git repo of the wireguard maintainer. "x86: enable additional cpu optimizations for gcc v9.1+" You mean something like that ^^? - Sedat - [1] https://git.zx2c4.com/laptop-kernel/commit/?id=116badbe0a18bc36ba90acb8b80cff41f9ab0686 > (The only good new is that recent LLVM has a pass to use alternative > instruction encoding in order to grow a basic block in size in order to > minimize the amount of NOP it needs to emit at the end in order to > satisfy the jump/loop alignment.) > > So if you *really* deeply care about NOP performance on your SNB, start > by teaching LLVM about prefix NOPs and rebuild your complete userspace. > At that point, you can do some trivial patches to the kernel to make it > use -march=sandybridge and prefix NOPs too. > > Until that time, the vast majority of NOPs your CPU will execute will be > NOPL.
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Mon, Mar 15, 2021 at 6:15 PM Borislav Petkov wrote: > > On Mon, Mar 15, 2021 at 06:04:41PM +0100, Sedat Dilek wrote: > > Here some fresh numbers: > > Lemme paste my previous reply which still holds true here: > > "There's a reason I have -s for silent in the build - printing output > during the build creates a *lot* of variance. And you have excessive > printing with V=1 and KBUILD_VERBOSE=1. > I have this for diagnostic reasons. Yes, I can drop V=1 and KBUILD_VERBOSE=1. This is a good idea for a fast build. > Also, you need to repeat those workloads a couple of times - one is not > enough. That's why I have --repeat 5 in there. > > Also, you need --pre=/root/bin/pre-build-kernel.sh where that script is: > > --- > #!/bin/bash > echo $0 > > make -s clean > echo 3 > /proc/sys/vm/drop_caches > --- > > so that you can avoid pagecache influence." > With my next build I try to apply this. - Sedat -
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Sat, Mar 13, 2021 at 2:47 PM Sedat Dilek wrote: [ ... ] > Let me look if I will do a selfmade ThinLTO+PGO optimized LLVM > toolchain v12.0.0-rc3 this weekend. > I did it. Here some fresh numbers: [ Selfmade LLVM toolchain v12.0.0-rc3 "stage1-only" ] [ Host-Kernel: 5.12.0-rc2-8-amd64-clang12-cfi includes Peter's NOPS patchset ] Performance counter stats for 'make V=1 -j4 LLVM=1 LLVM_IAS=1 PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-9-amd64-clang12-cfi KBUILD_VERBOSE=1 KBUILD_BUILD_HOST=iniza KBUILD_BUILD_USER=sedat.di...@gmail.com KBUILD_BUILD_TIMESTAMP=2021-03-13 bindeb-pkg KDEB_PKGVERSION=5.12.0~rc2-9~bullseye+dileks1': 55936351.95 msec task-clock#3.580 CPUs utilized 8291848 context-switches #0.148 K/sec 269686 cpu-migrations#0.005 K/sec 288389721 page-faults #0.005 M/sec 108344049253836 cycles#1.937 GHz 83228135285263 stalled-cycles-frontend # 76.82% frontend cycles idle 65616255370809 stalled-cycles-backend# 60.56% backend cycles idle 59590373937199 instructions #0.55 insn per cycle #1.40 stalled cycles per insn 10906265495505 branches # 194.976 M/sec 488578274434 branch-misses #4.48% of all branches 15622.926203302 seconds time elapsed 53453.974928000 seconds user 2526.773533000 seconds sys [ Selfmade LLVM toolchain v12.0.0-rc3 "thinlto_pgo_optimized" ] [ Host-Kernel: Debian's 5.10.19-1 kernel ] Performance counter stats for 'make V=1 -j4 LLVM=1 LLVM_IAS=1 PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-10-amd64-clang12-cfi KBUILD_VERBOSE=1 KBUILD_BUILD_HOST=iniza KBUILD_BUILD_USER=sedat.di...@gmail.com KBUILD_BUILD_TIMESTAMP=2021-03-14 bindeb-pkg KDEB_PKGVERSION=5.12.0~rc2-10~bullseye+dileks1': 40223080.69 msec task-clock#3.434 CPUs utilized 7438923 context-switches #0.185 K/sec 245636 cpu-migrations#0.006 K/sec 288073015 page-faults #0.007 M/sec 77325441657129 cycles#1.922 GHz 55357463522675 stalled-cycles-frontend # 71.59% frontend cycles idle 38978871249074 stalled-cycles-backend# 50.41% backend cycles idle 55178265045056 instructions #0.71 insn per cycle #1.00 stalled cycles per insn 9749166033571 branches # 242.377 M/sec 431303563167 branch-misses #4.42% of all branches 11714.751645982 seconds time elapsed 37951.11784 seconds user 2313.807151000 seconds sys [ Selfmade LLVM toolchain v12.0.0-rc3 "thinlto_pgo_optimized" ] [ Host-Kernel: 5.12.0-rc2-10-amd64-clang12-cfi includes Peter's NOPS patchset ] Performance counter stats for 'make V=1 -j4 LLVM=1 LLVM_IAS=1 PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-1-amd64-clang12-cfi KBUILD_VERBOSE=1 KBUILD_BUILD_HOST=iniza KBUILD_BUILD_USER=sedat.di...@gmail.com KBUILD_BUILD_TIMESTAMP=2021-03-15 bindeb-pkg KDEB_PKGVERSION=5.12.0~rc3-1~bullseye+dileks1': 40632207.25 msec task-clock#3.406 CPUs utilized 8216832 context-switches #0.202 K/sec 277610 cpu-migrations#0.007 K/sec 281331052 page-faults #0.007 M/sec 77031538570411 cycles#1.896 GHz (83.33%) 55247905369487 stalled-cycles-frontend # 71.72% frontend cycles idle (83.33%) 39046795510242 stalled-cycles-backend# 50.69% backend cycles idle (66.67%) 54592585444704 instructions #0.71 insn per cycle #1.01 stalled cycles per insn (83.33%) 9641589406714 branches # 237.289 M/sec (83.33%) 435317273069 branch-misses #4.51% of all branches (83.33%) 11928.047003788 seconds time elapsed 38187.685111000 seconds user 2502.075987000 seconds sys As said in an earlier email: A ThinLTO+PGO optimized LLVM-toolchain saves here approx. 60mins of build-time. Depending on the host-kernel including Peter's NOPS patchset: 3mins longer build-time. Brewing time of one single Turkish Tea bag. Attached are the 3 build-time log-files. - Sedat - Performance counter stats for 'make V=1 -j4 LLVM=1 LLVM_IAS=1 PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-9-amd64-clang12-cfi KBUILD_VERBOSE=1 KBUILD_BUILD_HOST=iniza KBUILD_BUILD_USER=sedat.di...@gmail.com KBUILD_BUILD_TIMESTAMP=2021-03-13 bindeb-pkg KDEB_PKGVERSION=5.12.0~rc2-9~bullseye+dileks1': 55936351.95 msec task-clock
Re: [PATCH v2 1/2] Makefile: Remove '--gcc-toolchain' flag
On Mon, Mar 15, 2021 at 5:22 PM Masahiro Yamada wrote:
>
> On Wed, Mar 10, 2021 at 5:59 AM Nathan Chancellor wrote:
> >
> > This flag was originally added to allow clang to find the GNU cross
> > tools in commit 785f11aa595b ("kbuild: Add better clang cross build
> > support"). This flag was not enough to find the tools at times so
> > '--prefix' was added to the list in commit ef8c4ed9db80 ("kbuild: allow
> > to use GCC toolchain not in Clang search path") and improved upon in
> > commit ca9b31f6bb9c ("Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang
> > cross compilation"). Now that '--prefix' specifies a full path and
> > prefix, '--gcc-toolchain' serves no purpose because the kernel builds
> > with '-nostdinc' and '-nostdlib'.
> >
> > This has been verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as
> > well as a distribution version of LLVM 11.1.0 without binutils in the
> > LLVM toolchain locations.
> >
> > Link: https://reviews.llvm.org/D97902
> > Signed-off-by: Nathan Chancellor
> > ---
> >
> > v1 -> v2:
> >
> > * Improve commit message (add history behind flag and link to Fangrui's
> > documentation improvement).
>
>
> Both applied to linux-kbuild. Thanks.
>
Sorry for being pedantic: This misses my Tested-by#s (see [1]).
Tested-by: Sedat Dilek # LLVM/Clang v13-git
AFAICS v2 changes some comments in the commit only but not code?
- Sedat -
[1] https://marc.info/?l=linux-kernel=161480031518629=2
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=d4aa405bc9cd506532f075456645716cdd1739c1
>
>
>
>
> > I did not carry tags forward so that people could re-review and test.
> >
> > Makefile | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 31dcdb3d61fa..182e93d91198 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),)
> > CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%))
> > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
> > CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
> > -GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
> > -endif
> > -ifneq ($(GCC_TOOLCHAIN),)
> > -CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
> > endif
> > ifneq ($(LLVM_IAS),1)
> > CLANG_FLAGS+= -no-integrated-as
> >
> > base-commit: a38fd8748464831584a19438cbb3082b5a2dab15
> > --
> > 2.31.0.rc1
> >
>
>
> --
> Best Regards
> Masahiro Yamada
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Sat, Mar 13, 2021 at 2:29 PM Borislav Petkov wrote: > > On Sat, Mar 13, 2021 at 01:58:56PM +0100, Sedat Dilek wrote: > > You can add Debian/experimental APT sources.list ... > > I could but I don't expect clang12 to behave any differently here. > Agreed in things of build-time. There were some improvements and optimizations to LLVM/Clang but twice as slow is really hard compared with GCC. I was thinking more in the direction of "compatibility" of tip tree with recent LLVM/Clang other than what is officially supported via Kbuild-system. Let me look if I will do a selfmade ThinLTO+PGO optimized LLVM toolchain v12.0.0-rc3 this weekend. - Sedat -
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Sat, Mar 13, 2021 at 1:49 PM Borislav Petkov wrote: > > On Sat, Mar 13, 2021 at 01:38:22PM +0100, Sedat Dilek wrote: > > AFAICS you did a 5 times x86-64 defconfig with dropped pagecache and `make > > -j9`? > > The tailored .config for that particular test box. > > > Does your distribution offer LLVM/Clang v12.0.0-rc3 (released this > > week) binaries? > > The partition on that box I used is debian testing, so no: > > $ apt search llvm-1* 2>/dev/null | grep llvm-1 > libllvm-11-ocaml-dev/testing,testing 1:11.0.1-2 amd64 > llvm-10/now 1:10.0.1-8+b1 amd64 [installed,local] > llvm-10-dev/now 1:10.0.1-8+b1 amd64 [installed,local] > llvm-10-runtime/now 1:10.0.1-8+b1 amd64 [installed,local] > llvm-10-tools/now 1:10.0.1-8+b1 amd64 [installed,local] > llvm-11/testing,testing,now 1:11.0.1-2 amd64 [installed,automatic] > llvm-11-dev/testing,testing,now 1:11.0.1-2 amd64 [installed,automatic] > llvm-11-doc/testing,testing 1:11.0.1-2 all > llvm-11-examples/testing,testing 1:11.0.1-2 all > llvm-11-runtime/testing,testing,now 1:11.0.1-2 amd64 [installed,automatic] > llvm-11-tools/testing,testing,now 1:11.0.1-2 amd64 [installed,automatic] > You can add Debian/experimental APT sources.list ... [ /etc/apt/sources.list.d/debian-experimental.list ] deb http://ftp.debian.org/debian experimental main contrib non-free deb https://deb.debian.org/debian experimental main non-free contrib [ /etc/apt/preferences.d/99_debian-experimental.pref ] Package: * Pin: release o=Debian,a=experimental Pin-Priority: 99 This gives LLVM/Clang v12 packages an APT prio of 99 - meaning no auto-upgrade installations will be done. You have full control by doing it manually. Renew informations from APT repositories: root# apt-get update What clang-12 version is/are available? root# apt-cache policy clang-12 Simulate an install (note: --no-install-recommends option): root# apt-get install llvm-12 clang-12 lld-12 llvm-12-tools --no-install-recommends -t experimental -s option -s: simulate Really do an installation of LLVM/Clang v12 stuff: root# apt-get install llvm-12 clang-12 lld-12 llvm-12-tools --no-install-recommends -t experimental -y option -y: yes If you like to test. Of course you can use packages from repositories. I can give you APT sources.list plus pref files if you desire. Have more fun. - Sedat -
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Sat, Mar 13, 2021 at 1:15 PM Borislav Petkov wrote: > > On Sat, Mar 13, 2021 at 01:10:29PM +0100, Sedat Dilek wrote: > > Here we go: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=864b435514b286c0be2a38a02f487aa28d990ef8 > > That's why I told earlier you to use tip/master - that patch is already > in it and all you would've needed to do is to apply the two nop patches. > Thanks for all your testings and suggestions. For me it was easier to apply these 3 patches on top of my custom patchset to see what impact Peter's patchset. AFAICS you did a 5 times x86-64 defconfig with dropped pagecache and `make -j9`? I run my "normal" workflow(s) (and build-script) for easier comparison on my side. Big thank-you for testing with LLVM/Clang v11.x - twice as slow as with GCC :-(. A selfmade ThinLTO+PGO optimized LLVM tooolchain v11.x/v12-rcX/v13-git is here as fast as Debian's GCC-v10.2.1 to build a Linux-kernel - approx. 03:30 [hh:mm] - full adapted Debian v5.10.y kernel-config. Does your distribution offer LLVM/Clang v12.0.0-rc3 (released this week) binaries? - Sedat -
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Sat, Mar 13, 2021 at 9:51 AM Borislav Petkov wrote: > > On Sat, Mar 13, 2021 at 06:26:15AM +0100, Sedat Dilek wrote: > > x86/jump_label: Mark arguments as const to satisfy asm constraints > > Where do I find this patch? > Here we go: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=864b435514b286c0be2a38a02f487aa28d990ef8 > > x86: Remove dynamic NOP selection > > objtool,x86: Use asm/nops.h > > > > My benchmark was to build a Linux-kernel with LLVM/Clang v12.0.0-rc3 > > on Debian/testing AMD64. > > > > Patchset applied for a first build: > > > > Performance counter stats for 'make V=1 -j4 LLVM=1 LLVM_IAS=1 > > PAHOLE=/opt/pahole/bin/pahole LOCALVERSION=-7-amd64-clang12-cfi > > KBUILD_VERBOSE=1 KBUILD_BUILD_HOST=iniza > > There's a reason I have -s for silent in the build - printing output > during the build creates a *lot* of variance. And you have excessive > printing with V=1 and KBUILD_VERBOSE=1. > > Also, you need to repeat those workloads a couple of times - one is not > enough. That's why I have --repeat 5 in there. > > Also, you need --pre=/root/bin/pre-build-kernel.sh where that script is: > > --- > #!/bin/bash > echo $0 > > make -s clean > echo 3 > /proc/sys/vm/drop_caches > --- > > so that you can avoid pagecache influence. > OK, I see. - Sedat - > Lemme rerun here with clang. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()
On Sat, Mar 13, 2021 at 6:45 AM Kalle Valo wrote: > > Jiri Kosina writes: > > > On Mon, 8 Mar 2021, Jiri Kosina wrote: > > > >> > From: Jiri Kosina > >> > > >> > It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs > >> > disabled (e.g. from LED core). We can't enable BHs in such a situation. > >> > > >> > Turn the unconditional BH-enable/BH-disable code into > >> > hardirq-disable/conditional-enable. > >> > > >> > This fixes the warning below. > >> > >> Hi, > >> > >> friendly ping on this one ... > > > > Luca, > > > > Johannes is telling me that he merged this patch internally, but I have no > > idea what is happening to it ... ? > > > > The reported splat is a clear bug, so it should be fixed one way or the > > other. > > Should I take this to wireless-drivers? > If you do so, please add: Tested-by: Sedat Dilek # LLVM/Clang v12.0.0-rc3 - Sedat - > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Fri, Mar 12, 2021 at 7:13 PM Sedat Dilek wrote: > > On Fri, Mar 12, 2021 at 6:47 PM Steven Rostedt wrote: > > > > On Fri, 12 Mar 2021 18:35:45 +0100 > > Sedat Dilek wrote: > > > > > > > Hey Steve, you degraded me to a number :-). > > > > It's the internet, everyone is a number. > > > > > > > > I dunno which Git tree this patchset applies to, but I check if I can > > > apply the patchset to my current local Git. > > > > Try Linus's latest. > > > > $ git describe origin/HEAD > v5.12-rc2-338-gf78d76e72a46 > > I adapted 1/2 in arch/x86/include/asm/jump_label.h to fit ^^^, see attachment. > Forget this. With latest Linus Git you need to apply "x86/jump_label: Mark arguments as const to satisfy asm constraints" from tip Git. - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=864b435514b286c0be2a38a02f487aa28d990ef8 > > > > Then build a kernel in the same build-environment. > > > Lemme see. > > > > > > To say with Linus's words: > > > "Numbers talk - bullshit walks." > > > > Exactly. > > > > -- Steve
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 12, 2021 at 7:05 PM Alan Stern wrote: > > On Fri, Mar 12, 2021 at 06:41:58PM +0100, Sedat Dilek wrote: > > OK, now for the records: > > > > [ /etc/modprobe.d/usb-storage.conf ] > > > > # Add quirks for USB Mass Storage devices > > # > > # Link: > > https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html > > # > > # Option #1: Use Kernel command line parameter > > # [1] Usage: usb-storage.quirks= > > # [2] VendorID (VID) and ProductID (PID): > > # ASMedia M1042 USB-3.0 controller: VID: 174c PID: 55aa > > # [3] Flags: > > # t = NO_ATA_1X (don't allow ATA(12) and ATA(16) commands, uas only); > > # u = IGNORE_UAS (don't bind to the uas driver); > > # [4] Example: usb-storage.quirks=174c:55aa:t > > # > > # Option #2: Set quirk via sysfs > > # DEBUG: echo '174c:55aa:t' > /sys/module/usb_storage/parameters/quirks > > # > > # Option #3: Pass options via /etc/modprobe.d/usb-storage.conf (this file > > here) > > # XXX: Do NOT forget to run `update-initramfs` command! > > options usb-storage quirks=174c:55aa:t > > - EOF - > > > > With generating a new /boot/initrd.img via `update-initramfs` this > > looks good to me: > > > > root# LC_ALL=C dmesg -T | egrep -i 'quirks|reset|SCSI ioctl error' > > [Fri Mar 12 18:25:56 2021] xhci_hcd :03:00.0: hcc params > > 0x0200f180 hci version 0x96 quirks 0x0008 > > [Fri Mar 12 18:25:57 2021] usb-storage 4-1:1.0: Quirks match for vid > > 174c pid 55aa: 240 > > [Fri Mar 12 18:25:57 2021] SCSI ioctl error, cmd A1, prog ata_id > > [Fri Mar 12 18:25:57 2021] SCSI ioctl error, cmd A1, prog ata_id > > [Fri Mar 12 18:25:58 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:25:58 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:25:58 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:25:59 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:25:59 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:25:59 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:25:59 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:01 2021] SCSI ioctl error, cmd A1, prog ata_id > > [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:02 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:02 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:02 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:02 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:03 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:03 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:03 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 12 18:26:24 2021] SCSI ioctl error, cmd A1, prog ata_id > > [Fri Mar 12 18:26:24 2021] SCSI ioctl error, cmd A1, prog ata_id > > [Fri Mar 12 18:26:29 2021] SCSI ioctl error, cmd 85, prog smartd > > [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog hdparm > > [Fri Mar 12 18:26:30 2021] SCSI io
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Fri, Mar 12, 2021 at 6:47 PM Steven Rostedt wrote: > > On Fri, 12 Mar 2021 18:35:45 +0100 > Sedat Dilek wrote: > > > > Hey Steve, you degraded me to a number :-). > > It's the internet, everyone is a number. > > > > > I dunno which Git tree this patchset applies to, but I check if I can > > apply the patchset to my current local Git. > > Try Linus's latest. > $ git describe origin/HEAD v5.12-rc2-338-gf78d76e72a46 I adapted 1/2 in arch/x86/include/asm/jump_label.h to fit ^^^, see attachment. - Sedat - > > Then build a kernel in the same build-environment. > > Lemme see. > > > > To say with Linus's words: > > "Numbers talk - bullshit walks." > > Exactly. > > -- Steve 20210312_peterz_x86_remove_ideal_nops-dileks-v2.mbx Description: Binary data
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
OK, now for the records: [ /etc/modprobe.d/usb-storage.conf ] # Add quirks for USB Mass Storage devices # # Link: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html # # Option #1: Use Kernel command line parameter # [1] Usage: usb-storage.quirks= # [2] VendorID (VID) and ProductID (PID): # ASMedia M1042 USB-3.0 controller: VID: 174c PID: 55aa # [3] Flags: # t = NO_ATA_1X (don't allow ATA(12) and ATA(16) commands, uas only); # u = IGNORE_UAS (don't bind to the uas driver); # [4] Example: usb-storage.quirks=174c:55aa:t # # Option #2: Set quirk via sysfs # DEBUG: echo '174c:55aa:t' > /sys/module/usb_storage/parameters/quirks # # Option #3: Pass options via /etc/modprobe.d/usb-storage.conf (this file here) # XXX: Do NOT forget to run `update-initramfs` command! options usb-storage quirks=174c:55aa:t - EOF - With generating a new /boot/initrd.img via `update-initramfs` this looks good to me: root# LC_ALL=C dmesg -T | egrep -i 'quirks|reset|SCSI ioctl error' [Fri Mar 12 18:25:56 2021] xhci_hcd :03:00.0: hcc params 0x0200f180 hci version 0x96 quirks 0x0008 [Fri Mar 12 18:25:57 2021] usb-storage 4-1:1.0: Quirks match for vid 174c pid 55aa: 240 [Fri Mar 12 18:25:57 2021] SCSI ioctl error, cmd A1, prog ata_id [Fri Mar 12 18:25:57 2021] SCSI ioctl error, cmd A1, prog ata_id [Fri Mar 12 18:25:58 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:25:58 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:25:58 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:25:59 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:25:59 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:25:59 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:25:59 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:00 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:01 2021] SCSI ioctl error, cmd A1, prog ata_id [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:01 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:02 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:02 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:02 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:02 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:03 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:03 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:03 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 12 18:26:24 2021] SCSI ioctl error, cmd A1, prog ata_id [Fri Mar 12 18:26:24 2021] SCSI ioctl error, cmd A1, prog ata_id [Fri Mar 12 18:26:29 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog hdparm [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog hdparm [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog hdparm [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd A1, prog ata_id [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog hdparm [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog hdparm [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog hdparm [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:30 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:31 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:31 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:31 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:31 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:31 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:31 2021] SCSI ioctl error, cmd 85, prog smartd [Fri Mar 12 18:26:39 2021] SCSI ioctl error, cmd A1, prog ata_id [Fri Mar 12 18:26:39 2021] SCSI
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Fri, Mar 12, 2021 at 6:26 PM Steven Rostedt wrote: > > On Fri, 12 Mar 2021 15:47:26 +0100 > Borislav Petkov wrote: > > > On Fri, Mar 12, 2021 at 03:29:48PM +0100, Sedat Dilek wrote: > > > What does this change exactly mean to/for me? > > > > Probably nothing. > > > > I would be very surprised if it would be at all noticeable for you - > > it's not like the kernel is executing long streams of NOPs in fast > > paths. > > > > With ftrace enabled, every function starts with a NOP. But that said, the > simple answer is for Sedat to apply the patches on his box and do some > performance testing. It doesn't matter if you are white, black, male, > female, or anything in between. As my daughter's swim coach said; it's the > numbers that matter here. Run a bunch of benchmarks on your box on the > latest kernel, apply Peter's patches, and then run the benchmarks again on > the latest kernel with Peter's patches and then report the difference. If > it's negligible then there's nothing to worry about. > Hey Steve, you degraded me to a number :-). I dunno which Git tree this patchset applies to, but I check if I can apply the patchset to my current local Git. Then build a kernel in the same build-environment. Lemme see. To say with Linus's words: "Numbers talk - bullshit walks." - Sedat -
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 12, 2021 at 5:57 PM Sedat Dilek wrote: > > On Sun, Mar 7, 2021 at 6:07 PM Alan Stern wrote: > > > > On Sun, Mar 07, 2021 at 05:57:39PM +0100, Sedat Dilek wrote: > > > On Sun, Mar 7, 2021 at 4:46 PM Alan Stern > > > wrote: > > > > > > > > On Sat, Mar 06, 2021 at 09:49:00PM +0100, Sedat Dilek wrote: > > > > > > > > > For testing purposes, I stopped these systemd services: > > > > > > > > > > 1. systemctl stop smartmontools.service > > > > > > > > > > 2. systemctl stop udisks2.service > > > > > > > > > > Last seen xhci-reset: > > > > > > > > > > [Sat Mar 6 21:37:40 2021] SCSI ioctl error, cmd 85, prog pool-udisksd > > > > > > > > > > So, that every 10min xhci-reset was caused by pool-udisksd from > > > > > udisks2.service. > > > > > > > > You have found the cause of your problem! Great! > > > > > > > > And now, obviously order to fix the problem, you'll have to look into > > > > the udisks2 service. Maybe you can configure it so that it won't send > > > > the problem-causing commands. > > > > > > > > > > I tried yesterday to add --debug option to the ExexStart line of > > > udisks2.service, but did not see anything helpful. > > > > > > There exist more user-space than udisks2 causing these xhci-resets. > > > The cmd#s are also clear: A1 and 85 - whatever they mean. > > > > Those are the two prefixes which indicate an ATA command is present. > > You can find them listed as ATA_12 and ATA_16 in > > include/scsi/scsi_proto.h. > > > > > As said with Linux v5.10.y and Linux v5.11 I have not seen this. > > > > Have you tried setting the quirk flag we discussed earlier _and_ turning > > off udisks2? Maybe also turning off the other services which generate > > these commands? Perhaps you'll find that when the quirk flag is > > present, some of those programs _don't_ generate any ATA commands. > > > > I passed as a kernel-command-line parameter: usb-storage.quirks=174c:55aa:t > > dmesg says: > > [Fri Mar 12 17:25:33 2021] usb-storage 4-1:1.0: Quirks match for vid > 174c pid 55aa: 240 > > Without that parameter (there is an existing Quirks for my ASMedia USB > 3.0 controller in the kernel-sources): > > [Fri Mar 12 11:49:03 2021] usb-storage 4-1:1.0: Quirks match for vid > 174c pid 55aa: 40 > > NOTE: 240 (new) VS. 40 (old) > > The parameter is really active: > > root# cat /sys/module/usb_storage/parameters/quirks > 174c:55aa:t > > The total number of xhci-resets is reduced: > > root# LC_ALL=C dmesg -T | egrep 'usb 4-1: reset SuperSpeed Gen 1 USB > device number 2 using xhci_hcd' | wc -l > 24 > > Together with your diff, I see in dmesg now: > > # LC_ALL=C dmesg -T | egrep 'reset|SCSI ioctl error' > [Fri Mar 12 17:25:32 2021] SCSI ioctl error, cmd A1, prog ata_id > [Fri Mar 12 17:25:32 2021] SCSI ioctl error, cmd A1, prog ata_id > [Fri Mar 12 17:25:33 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:33 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:33 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:34 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:34 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:34 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:34 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:34 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:35 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:35 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:35 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:35 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:36 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:36 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd > [Fri Mar 12 17:25:36 2021] SCSI ioctl error, cmd A1, prog ata_id > [Fri Mar 12 17:25:36 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > number 2 using xhci_hcd >
Re: [PATCH 0/2] x86: Remove ideal_nops[]
On Fri, Mar 12, 2021 at 1:00 PM Peter Zijlstra wrote: > > Hi! > > A while ago Steve complained about x86 being weird for having different NOPs > [1] > > Having cursed the same thing before, I figured it was time to look at the NOP > situation. > > 32bit simply isn't a performance target anymore, so all we need is a set of > NOPs that works on all. > > x86_64 has two main NOP variants, NOPL and prefix NOP. NOPL was introduced by > P6 and is architecturally mandated for x86_64. However, some uarchs made the > choice to limit NOPL decoding to a single port, which obviously limits NOPL > throughput. Other uarchs have (severe) decoding penalties for excessive (>~3) > prefixes, hobbling prefix NOP throughput. > > But the thing is, all the modern uarchs can handle both without issue; that is > AMD K10 (2007) and later and Intel Ivy Bridge (2012) and later. The only > exception is Atom, which has the prefix penalty. > > Since ultimate performance of a 10 year old chip (Intel Sandy Bridge, 2011) is > simply irrelevant today, remove variable NOPs and use NOPL. > Hi Peter, I am an Intel SandyBridge power user and want the ultimate performance on my hardware. What does this change exactly mean to/for me? I got this laptop as the last gift for my birthday in 2012 from my mother. She died the same year. So, this is a bit sentimental hardware for me. It's amazing what this laptop all was involved in. 10+ years of LLVM/Clang for Linux-kernel and Linux graphics stack. Worked in a Ubuntu/precise 12.04 LTS WUBI (installation) environment - 5 years (full LTS period) long! How many Linux-kernel bugs got reported and/or fixed... Debian/stretch...Debian/bullseye with no fresh installation. Rolling release. I remember my decision in March 2012 not to choose that Asus notebook with the first hardware-revision of IvyBridge and bought conservatively a SandyBridge Gen. 2 Samsung notebook. It's a pity to see no or restricted/limited Vulkan support. If you are not concerned - life goes on for you. It's like being white colored not understanding what "Black Lives Matter" really means. If people use or talk about white/black listings then allow/deny lists. Or being a female software developer having a 10-15% less salary because you are not male - in the same department! This week we had our 100th anniversary of International Women's Day. I am not black - I am male - I am not concerned - Live goes on? Again, this machine is able to do fast Linux-kernel builds with an adapted Debian Linux v5.10 kernel-config. If you do NOT use Debian's LLVM/Clang - means build a selfmade stage1-only LLVM toolchain (saves ~1 hour of build-time) - or a ThinLTO+PGO optimized LLVM toolchain (saves again ~1 hour of build-time). Latest Linus Git plus With Clang-CFI took me today approx. 04:20 [hh:mm] with a selfmade stage1-only LLVM toolchain version 12.0.0-rc3. Again, this is amazing. What I wanna try to say is: This is old hardware but you can - if you are a smart enough - optimize your builds. On the other hand I can understand dropping support for XXX whatever hardware... Where is the limit(ation): Support 10 years or 7 years old hardware? Sorry, I am a bit concerned that this is the beginning - or a backdoor ? - to drop (optimized) Intel SandyBridge support. So, what do I need to do - to have "ultimate performance" back for SandyBridge with your patchset :-)? Yes, you are right: Life goes on. Regards, - Sedat - > This gives us deterministic NOPs and restores sanity. > > > > [1] https://lkml.kernel.org/r/20210302105827.34036...@gandalf.local.home >
Re: [PATCH] kbuild: collect minimum tool versions into scripts/min-tool-version.sh
On Thu, Mar 11, 2021 at 10:47 AM Masahiro Yamada wrote:
>
> The kernel build uses various tools, many of which are provided by the
> same software suite, for example, LLVM and Binutils.
>
> When you raise the minimum version of Clang/LLVM, you need to update
> clang_min_version in scripts/cc-version.sh and also lld_min_version in
> scripts/ld-version.sh.
>
> Kbuild can handle CC=clang and LD=ld.lld independently, but it does not
> make much sense to maintain their versions separately.
>
> Let's make scripts/min-tool-version.sh a central place of minimum tool
> versions so you do not need to touch multiple files.
>
> This script prints the minimum version of the given tool.
>
> $ scripts/min-tool-version.sh gcc
> 4.9.0
> $ scripts/min-tool-version.sh llvm
> 10.0.1
> $ scripts/min-tool-version.sh binutils
> 2.23.0
> $ scripts/min-tool-version.sh foo
> foo: unknown tool
>
> Signed-off-by: Masahiro Yamada
> Reviewed-by: Nathan Chancellor
The idea with creating gcc, llvm, binutils etc. files containing the
minimum version-string sounds good to me.
This version here tested on Debian/testing AMD64.
Tested-by: Sedat Dilek # LLVM/Clang v12.0.0-rc3
- Sedat -
> ---
>
> scripts/cc-version.sh | 20 +---
> scripts/ld-version.sh | 11 ---
> scripts/min-tool-version.sh | 27 +++
> 3 files changed, 36 insertions(+), 22 deletions(-)
> create mode 100755 scripts/min-tool-version.sh
>
> diff --git a/scripts/cc-version.sh b/scripts/cc-version.sh
> index 3f2ee885b116..f1952c522466 100755
> --- a/scripts/cc-version.sh
> +++ b/scripts/cc-version.sh
> @@ -6,18 +6,6 @@
>
> set -e
>
> -# When you raise the minimum compiler version, please update
> -# Documentation/process/changes.rst as well.
> -gcc_min_version=4.9.0
> -clang_min_version=10.0.1
> -icc_min_version=16.0.3 # temporary
> -
> -# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293
> -# https://lore.kernel.org/r/20210107111841.gn1...@shell.armlinux.org.uk
> -if [ "$SRCARCH" = arm64 ]; then
> - gcc_min_version=5.1.0
> -fi
> -
> # Print the compiler name and some version components.
> get_compiler_info()
> {
> @@ -48,18 +36,20 @@ set -- $(get_compiler_info "$@")
>
> name=$1
>
> +min_tool_version=$(dirname $0)/min-tool-version.sh
> +
> case "$name" in
> GCC)
> version=$2.$3.$4
> - min_version=$gcc_min_version
> + min_version=$($min_tool_version gcc)
> ;;
> Clang)
> version=$2.$3.$4
> - min_version=$clang_min_version
> + min_version=$($min_tool_version llvm)
> ;;
> ICC)
> version=$(($2 / 100)).$(($2 % 100)).$3
> - min_version=$icc_min_version
> + min_version=$($min_tool_version icc)
> ;;
> *)
> echo "$orig_args: unknown compiler" >&2
> diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
> index 30debf78aa09..5b9481e98b4f 100755
> --- a/scripts/ld-version.sh
> +++ b/scripts/ld-version.sh
> @@ -6,11 +6,6 @@
>
> set -e
>
> -# When you raise the minimum linker version, please update
> -# Documentation/process/changes.rst as well.
> -bfd_min_version=2.23.0
> -lld_min_version=10.0.1
> -
> # Convert the version string x.y.z to a canonical 5 or 6-digit form.
> get_canonical_version()
> {
> @@ -35,10 +30,12 @@ set -- $("$@" --version)
> IFS=' '
> set -- $1
>
> +min_tool_version=$(dirname $0)/min-tool-version.sh
> +
> if [ "$1" = GNU -a "$2" = ld ]; then
> shift $(($# - 1))
> version=$1
> - min_version=$bfd_min_version
> + min_version=$($min_tool_version binutils)
> name=BFD
> disp_name="GNU ld"
> elif [ "$1" = GNU -a "$2" = gold ]; then
> @@ -51,7 +48,7 @@ else
>
> if [ "$1" = LLD ]; then
> version=$2
> - min_version=$lld_min_version
> + min_version=$($min_tool_version llvm)
> name=LLD
> disp_name=LLD
> else
> diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
> new file mode 100755
> index ..37c438d766d7
> --- /dev/null
> +++ b/scripts/min-tool-version.sh
> @@ -0,0 +1,27 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Print the minimum supported version of the given tool.
> +
> +set -e
> +
> +# When you raise the minimum version, please update
> +# Documentation/process/changes.rst as well.
> +min_gcc_version=4.9.0
> +min_llvm_version=10.0.1
> +min_icc_version=16.0.3 #
Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
On Wed, Mar 10, 2021 at 10:47 PM Nicolas Pitre wrote: ... > > With CONFIG_TRIM_UNUSED_KSYMS=y I see a 3x-loops of building .version > > and folowing steps - got no answer if this is intended. > > Yes it is intended. I explained it here: > > https://lkml.org/lkml/2021/3/9/1099 > Ah, cool. Thanks for that link. > With CONFIG_TRIM_UNUSED_KSYMS some EXPORT_SYMBOL() are removed, which > allows for optimizing away the corresponding code, which in turn opens > the possibility for more EXPORT_SYMBOL() to be removed, etc. The process > eventually converge to a stable build. Normally only 2 passes are needed > to converge, but LTO opens the possibilities for extra passes. > > > Means longer build-time. > > Oh, absolutely. LTO (at least when I played with it) is slow. Add the > multi-pass from CONFIG_TRIM_UNUSED_KSYMS on top of that and your kernel > build becomes agonizingly slow. This is not something you want when > doing kernel development. > Thanks for the feedback. > > I did not follow this anymore as both Kconfigs with Clang-LTO consume > > more build-time and the resulting vmlinux is some MiB bigger than with > > Clang-CFI. > > That's rather strange. At least with gcc LTO I always obtained smaller > kernels. > I cannot say much to GCC-LTO - I never used it. If you are interested in Clang-CFI (see [1]) - which requires Clang-LTO enabled and LLVM/Clang >= 12. Some hours ago version 12.0.0-rc3 was released, see [2]. - Sedat - [1] https://github.com/samitolvanen/linux/commits/clang-cfi [2] https://github.com/ClangBuiltLinux/linux/issues/1259
Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
On Wed, Mar 10, 2021 at 10:08 PM Arnd Bergmann wrote:
>
> On Wed, Mar 10, 2021 at 9:50 PM Masahiro Yamada wrote:
> > On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
> > > Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
>
> >
> > masahiro@oscar:~/ref/linux$ echo 'void this_func_is_unused(void) {}'
> > >> kernel/cpu.c
> > masahiro@oscar:~/ref/linux$ export
> > CROSS_COMPILE=/home/masahiro/tools/powerpc-10.1.0/bin/powerpc-linux-
> > masahiro@oscar:~/ref/linux$ make ARCH=powerpc defconfig
> > masahiro@oscar:~/ref/linux$ ./scripts/config -e EXPERT
> > masahiro@oscar:~/ref/linux$ ./scripts/config -e
> > LD_DEAD_CODE_DATA_ELIMINATION
> > masahiro@oscar:~/ref/linux$
> > ~/tools/powerpc-10.1.0/bin/powerpc-linux-nm -n vmlinux | grep
> > this_func
> > c0170560 T .this_func_is_unused
> > c1d8d560 D this_func_is_unused
> > masahiro@oscar:~/ref/linux$ grep DEAD_CODE_ .config
> > CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y
> > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y
> >
> >
> > If I remember correctly,
> > LD_DEAD_CODE_DATA_ELIMINATION dropped unused functions
> > when I tried it last time.
> >
> >
> > I also tried arm64 with a HAVE_LD_DEAD_CODE_DATA_ELIMINATION hack.
> > The result was the same.
> >
> >
> >
> > Am I missing something?
>
> It's possible that it only works in combination with CLANG_LTO now
> because something broke. I definitely saw a reduction in kernel
> size when both options are enabled, but did not try a simple test
> case like you did.
>
> Maybe some other reference gets created that prevents the function
> from being garbage-collected unless that other option is removed
> as well?
>
The best results on size-reduction of vmlinux I got with Clang-CFI on x86-64.
Clang-LTO and Clang-CFI:
I was able to build with CONFIG_TRIM_UNUSED_KSYMS=y which needs to add
a whitelist file or add a whitelist to scripts/gen_autoksyms.sh.
And boot on bare metal.
Furthermore, I was able to compile
CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y with and without
CONFIG_TRIM_UNUSED_KSYMS=y.
Every kernel I had CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y does not boot.
Yes, there is a size reduction with both enabled but not that good as
with Clang-CFI.
All testings with several iterations of LLVM/Clang v13-git.
With CONFIG_TRIM_UNUSED_KSYMS=y I see a 3x-loops of building .version
and folowing steps - got no answer if this is intended.
Means longer build-time.
I did not follow this anymore as both Kconfigs with Clang-LTO consume
more build-time and the resulting vmlinux is some MiB bigger than with
Clang-CFI.
If someone is interested in x86-64 I can provide the whitelist files
and or (alternatively) changes to scripts/gen_autoksyms.sh.
AFAICS I had open a thread for this - damn digital dementia.
- Sedat -
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sun, Mar 7, 2021 at 4:46 PM Alan Stern wrote: > > On Sat, Mar 06, 2021 at 09:49:00PM +0100, Sedat Dilek wrote: > > > For testing purposes, I stopped these systemd services: > > > > 1. systemctl stop smartmontools.service > > > > 2. systemctl stop udisks2.service > > > > Last seen xhci-reset: > > > > [Sat Mar 6 21:37:40 2021] SCSI ioctl error, cmd 85, prog pool-udisksd > > > > So, that every 10min xhci-reset was caused by pool-udisksd from > > udisks2.service. > > You have found the cause of your problem! Great! > > And now, obviously order to fix the problem, you'll have to look into > the udisks2 service. Maybe you can configure it so that it won't send > the problem-causing commands. > I tried yesterday to add --debug option to the ExexStart line of udisks2.service, but did not see anything helpful. There exist more user-space than udisks2 causing these xhci-resets. The cmd#s are also clear: A1 and 85 - whatever they mean. As said with Linux v5.10.y and Linux v5.11 I have not seen this. What about CCing linux-block and linux-scsi people? - Sedat -
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sat, Mar 6, 2021 at 9:56 PM Sedat Dilek wrote:
>
> On Sat, Mar 6, 2021 at 9:49 PM Sedat Dilek wrote:
> >
> > On Sat, Mar 6, 2021 at 9:38 PM Sedat Dilek wrote:
> > >
> > > On Sat, Mar 6, 2021 at 9:26 PM Sedat Dilek wrote:
> > > >
> > > > On Sat, Mar 6, 2021 at 5:58 PM Alan Stern
> > > > wrote:
> > > > >
> > > > > On Sat, Mar 06, 2021 at 07:42:30AM +0100, Sedat Dilek wrote:
> > > > > > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets:
> > > > >
> > > > > Is the kernel the only thing that is different? The rest of the
> > > > > operating system and environment is exactly the same?
> > > > >
> > > > > > But I see there is already a quirk enabled and matches my ASmedia
> > > > > > USB
> > > > > > 3.0 controller (as I have *no* usb-storage-quirks enabled):
> > > > > >
> > > > > > root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa'
> > > > > > [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid
> > > > > > 174c pid 55aa: 40
> > > > >
> > > > > Yes, this is because that type of device already has a quirk entry
> > > > > built
> > > > > into the kernel. You can find it by searching for "174c" in the
> > > > > kernel
> > > > > source file drivers/usb/storage/unusual_devs.h.
> > > > >
> > > > > > Thanks Alan for all the hints and tips in the topic "usb-storage and
> > > > > > quirks" and your patience.
> > > > >
> > > > > You can try building a 5.11 kernel with the patch below. I don't know
> > > > > whether it will show anything in the dmesg log when one of these
> > > > > resets
> > > > > occurs, but it might.
> > > > >
> > > > > If that doesn't work out, another possibility is to use git bisect to
> > > > > find the commit between 5.10 and 5.11 which caused the problem to
> > > > > start.
> > > > >
> > > > > Alan Stern
> > > > >
> > > > >
> > > > > --- usb-devel.orig/block/scsi_ioctl.c
> > > > > +++ usb-devel/block/scsi_ioctl.c
> > > > > @@ -258,8 +258,11 @@ static int blk_complete_sghdr_rq(struct
> > > > > hdr->host_status = host_byte(req->result);
> > > > > hdr->driver_status = driver_byte(req->result);
> > > > > hdr->info = 0;
> > > > > - if (hdr->masked_status || hdr->host_status ||
> > > > > hdr->driver_status)
> > > > > + if (hdr->masked_status || hdr->host_status ||
> > > > > hdr->driver_status) {
> > > > > hdr->info |= SG_INFO_CHECK;
> > > > > + printk(KERN_INFO "SCSI ioctl error, cmd %02X, prog
> > > > > %s\n",
> > > > > + req->cmd[0], current->comm);
> > > > > + }
> > > > > hdr->resid = req->resid_len;
> > > > > hdr->sb_len_wr = 0;
> > > > >
> > > > >
> > > >
> > > > Thanks for the diff, Alan.
> > > >
> > > > With an adapted version to fit Linux v5.12-rc2 (see attachment) I see:
> > > >
> > > > root@iniza:~# LC_ALL=C dmesg -T | grep 'SCSI ioctl error'
> > > > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:16:45 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > &
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sat, Mar 6, 2021 at 9:49 PM Sedat Dilek wrote:
>
> On Sat, Mar 6, 2021 at 9:38 PM Sedat Dilek wrote:
> >
> > On Sat, Mar 6, 2021 at 9:26 PM Sedat Dilek wrote:
> > >
> > > On Sat, Mar 6, 2021 at 5:58 PM Alan Stern
> > > wrote:
> > > >
> > > > On Sat, Mar 06, 2021 at 07:42:30AM +0100, Sedat Dilek wrote:
> > > > > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets:
> > > >
> > > > Is the kernel the only thing that is different? The rest of the
> > > > operating system and environment is exactly the same?
> > > >
> > > > > But I see there is already a quirk enabled and matches my ASmedia USB
> > > > > 3.0 controller (as I have *no* usb-storage-quirks enabled):
> > > > >
> > > > > root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa'
> > > > > [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid
> > > > > 174c pid 55aa: 40
> > > >
> > > > Yes, this is because that type of device already has a quirk entry built
> > > > into the kernel. You can find it by searching for "174c" in the kernel
> > > > source file drivers/usb/storage/unusual_devs.h.
> > > >
> > > > > Thanks Alan for all the hints and tips in the topic "usb-storage and
> > > > > quirks" and your patience.
> > > >
> > > > You can try building a 5.11 kernel with the patch below. I don't know
> > > > whether it will show anything in the dmesg log when one of these resets
> > > > occurs, but it might.
> > > >
> > > > If that doesn't work out, another possibility is to use git bisect to
> > > > find the commit between 5.10 and 5.11 which caused the problem to start.
> > > >
> > > > Alan Stern
> > > >
> > > >
> > > > --- usb-devel.orig/block/scsi_ioctl.c
> > > > +++ usb-devel/block/scsi_ioctl.c
> > > > @@ -258,8 +258,11 @@ static int blk_complete_sghdr_rq(struct
> > > > hdr->host_status = host_byte(req->result);
> > > > hdr->driver_status = driver_byte(req->result);
> > > > hdr->info = 0;
> > > > - if (hdr->masked_status || hdr->host_status ||
> > > > hdr->driver_status)
> > > > + if (hdr->masked_status || hdr->host_status ||
> > > > hdr->driver_status) {
> > > > hdr->info |= SG_INFO_CHECK;
> > > > + printk(KERN_INFO "SCSI ioctl error, cmd %02X, prog
> > > > %s\n",
> > > > + req->cmd[0], current->comm);
> > > > + }
> > > > hdr->resid = req->resid_len;
> > > > hdr->sb_len_wr = 0;
> > > >
> > > >
> > >
> > > Thanks for the diff, Alan.
> > >
> > > With an adapted version to fit Linux v5.12-rc2 (see attachment) I see:
> > >
> > > root@iniza:~# LC_ALL=C dmesg -T | grep 'SCSI ioctl error'
> > > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:16:45 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd A1, prog ata_id
> > > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:15 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:16 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > > [Sat Mar 6 2
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sat, Mar 6, 2021 at 9:38 PM Sedat Dilek wrote:
>
> On Sat, Mar 6, 2021 at 9:26 PM Sedat Dilek wrote:
> >
> > On Sat, Mar 6, 2021 at 5:58 PM Alan Stern wrote:
> > >
> > > On Sat, Mar 06, 2021 at 07:42:30AM +0100, Sedat Dilek wrote:
> > > > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets:
> > >
> > > Is the kernel the only thing that is different? The rest of the
> > > operating system and environment is exactly the same?
> > >
> > > > But I see there is already a quirk enabled and matches my ASmedia USB
> > > > 3.0 controller (as I have *no* usb-storage-quirks enabled):
> > > >
> > > > root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa'
> > > > [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid
> > > > 174c pid 55aa: 40
> > >
> > > Yes, this is because that type of device already has a quirk entry built
> > > into the kernel. You can find it by searching for "174c" in the kernel
> > > source file drivers/usb/storage/unusual_devs.h.
> > >
> > > > Thanks Alan for all the hints and tips in the topic "usb-storage and
> > > > quirks" and your patience.
> > >
> > > You can try building a 5.11 kernel with the patch below. I don't know
> > > whether it will show anything in the dmesg log when one of these resets
> > > occurs, but it might.
> > >
> > > If that doesn't work out, another possibility is to use git bisect to
> > > find the commit between 5.10 and 5.11 which caused the problem to start.
> > >
> > > Alan Stern
> > >
> > >
> > > --- usb-devel.orig/block/scsi_ioctl.c
> > > +++ usb-devel/block/scsi_ioctl.c
> > > @@ -258,8 +258,11 @@ static int blk_complete_sghdr_rq(struct
> > > hdr->host_status = host_byte(req->result);
> > > hdr->driver_status = driver_byte(req->result);
> > > hdr->info = 0;
> > > - if (hdr->masked_status || hdr->host_status || hdr->driver_status)
> > > + if (hdr->masked_status || hdr->host_status || hdr->driver_status)
> > > {
> > > hdr->info |= SG_INFO_CHECK;
> > > + printk(KERN_INFO "SCSI ioctl error, cmd %02X, prog %s\n",
> > > + req->cmd[0], current->comm);
> > > + }
> > > hdr->resid = req->resid_len;
> > > hdr->sb_len_wr = 0;
> > >
> > >
> >
> > Thanks for the diff, Alan.
> >
> > With an adapted version to fit Linux v5.12-rc2 (see attachment) I see:
> >
> > root@iniza:~# LC_ALL=C dmesg -T | grep 'SCSI ioctl error'
> > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:16:45 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:15 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:16 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> > [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> > [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> &
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sat, Mar 6, 2021 at 9:26 PM Sedat Dilek wrote:
>
> On Sat, Mar 6, 2021 at 5:58 PM Alan Stern wrote:
> >
> > On Sat, Mar 06, 2021 at 07:42:30AM +0100, Sedat Dilek wrote:
> > > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets:
> >
> > Is the kernel the only thing that is different? The rest of the
> > operating system and environment is exactly the same?
> >
> > > But I see there is already a quirk enabled and matches my ASmedia USB
> > > 3.0 controller (as I have *no* usb-storage-quirks enabled):
> > >
> > > root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa'
> > > [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid
> > > 174c pid 55aa: 40
> >
> > Yes, this is because that type of device already has a quirk entry built
> > into the kernel. You can find it by searching for "174c" in the kernel
> > source file drivers/usb/storage/unusual_devs.h.
> >
> > > Thanks Alan for all the hints and tips in the topic "usb-storage and
> > > quirks" and your patience.
> >
> > You can try building a 5.11 kernel with the patch below. I don't know
> > whether it will show anything in the dmesg log when one of these resets
> > occurs, but it might.
> >
> > If that doesn't work out, another possibility is to use git bisect to
> > find the commit between 5.10 and 5.11 which caused the problem to start.
> >
> > Alan Stern
> >
> >
> > --- usb-devel.orig/block/scsi_ioctl.c
> > +++ usb-devel/block/scsi_ioctl.c
> > @@ -258,8 +258,11 @@ static int blk_complete_sghdr_rq(struct
> > hdr->host_status = host_byte(req->result);
> > hdr->driver_status = driver_byte(req->result);
> > hdr->info = 0;
> > - if (hdr->masked_status || hdr->host_status || hdr->driver_status)
> > + if (hdr->masked_status || hdr->host_status || hdr->driver_status) {
> > hdr->info |= SG_INFO_CHECK;
> > + printk(KERN_INFO "SCSI ioctl error, cmd %02X, prog %s\n",
> > + req->cmd[0], current->comm);
> > + }
> > hdr->resid = req->resid_len;
> > hdr->sb_len_wr = 0;
> >
> >
>
> Thanks for the diff, Alan.
>
> With an adapted version to fit Linux v5.12-rc2 (see attachment) I see:
>
> root@iniza:~# LC_ALL=C dmesg -T | grep 'SCSI ioctl error'
> [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:16:42 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:16:45 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:17:07 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:12 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:13 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:17:14 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:15 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:16 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:18 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:19 2021] SCSI ioctl error, cmd 85, prog smartd
> [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:17:21 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd A1, prog ata_id
> [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:22 2021] SCSI ioctl error, cmd 85, prog hdparm
> [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udisksd
> [Sat Mar 6 21:17:28 2021] SCSI ioctl error, cmd 85, prog udis
Re: [PATCH 1/2] iwlwifi: fix DVM build regression in 5.12-rc
On Sat, Mar 6, 2021 at 9:27 PM Hugh Dickins wrote:
>
> On Sat, 6 Mar 2021, Sedat Dilek wrote:
> > On Sat, Mar 6, 2021 at 8:48 PM Hugh Dickins wrote:
> > >
> > > There is no iwl_so_trans_cfg if CONFIG_IWLDVM but not CONFIG_IWLMVM:
> > > move the CONFIG_IWLMVM guard up before the problematic SnJ workaround
> > > to fix the build breakage.
> > >
> > > Fixes: 930be4e76f26 ("iwlwifi: add support for SnJ with Jf devices")
> > > Signed-off-by: Hugh Dickins
> >
> > See "iwlwifi: pcie: fix iwl_so_trans_cfg link error when CONFIG_IWLMVM
> > is disabled" in [1].
> >
> > - Sedat -
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=62541e266703549550e77fd46138422dbdc881f1
>
> Thanks for looking out that and the other one, Sedat: I swear I checked
> linux-next before sending, but my check seems to have been... defective.
>
No problem, Hugh.
Here, I have also an iwldwm device aka Intel(R) Centrino(R) Advanced-N
6230 AGN (REV=0xB0) and needed both patches.
The opmode commit fixed a call-trace.
It is always good to check wireless-drivers Git and/or linux-wireless ML.
- Sedat -
Re: [PATCH 2/2] iwlwifi: fix DVM boot regression in 5.12-rc
On Sat, Mar 6, 2021 at 8:50 PM Hugh Dickins wrote:
>
> No time_point op has been provided for DVM: check for NULL before
> calling, to fix the oops (blank screen booting non-modular kernel).
>
> Fixes: d01293154c0a ("iwlwifi: dbg: add op_mode callback for collecting debug
> data.")
> Signed-off-by: Hugh Dickins
See "iwlwifi: avoid crash on unsupported debug collection" in [1].
- Sedat -
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=4538c5ed0f7e892f1b643472e48146757d1e60c5
> ---
>
> drivers/net/wireless/intel/iwlwifi/iwl-op-mode.h |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- 5.12-rc2/drivers/net/wireless/intel/iwlwifi/iwl-op-mode.h 2021-02-28
> 16:58:55.058425551 -0800
> +++ linux/drivers/net/wireless/intel/iwlwifi/iwl-op-mode.h 2021-03-05
> 20:59:14.156217412 -0800
> @@ -205,7 +205,8 @@ static inline void iwl_op_mode_time_poin
> enum iwl_fw_ini_time_point tp_id,
> union iwl_dbg_tlv_tp_data *tp_data)
> {
> - op_mode->ops->time_point(op_mode, tp_id, tp_data);
> + if (op_mode->ops->time_point)
> + op_mode->ops->time_point(op_mode, tp_id, tp_data);
> }
>
> #endif /* __iwl_op_mode_h__ */
Re: [PATCH 1/2] iwlwifi: fix DVM build regression in 5.12-rc
On Sat, Mar 6, 2021 at 8:48 PM Hugh Dickins wrote:
>
> There is no iwl_so_trans_cfg if CONFIG_IWLDVM but not CONFIG_IWLMVM:
> move the CONFIG_IWLMVM guard up before the problematic SnJ workaround
> to fix the build breakage.
>
> Fixes: 930be4e76f26 ("iwlwifi: add support for SnJ with Jf devices")
> Signed-off-by: Hugh Dickins
See "iwlwifi: pcie: fix iwl_so_trans_cfg link error when CONFIG_IWLMVM
is disabled" in [1].
- Sedat -
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=62541e266703549550e77fd46138422dbdc881f1
> ---
>
> drivers/net/wireless/intel/iwlwifi/pcie/drv.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 5.12-rc2/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 2021-02-28
> 16:58:55.082425755 -0800
> +++ linux/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 2021-03-05
> 18:42:53.650809293 -0800
> @@ -1106,6 +1106,7 @@ static int iwl_pci_probe(struct pci_dev
> }
> }
>
> +#if IS_ENABLED(CONFIG_IWLMVM)
> /*
> * Workaround for problematic SnJ device: sometimes when
> * certain RF modules are connected to SnJ, the device ID
> @@ -1116,7 +1117,6 @@ static int iwl_pci_probe(struct pci_dev
> if (CSR_HW_REV_TYPE(iwl_trans->hw_rev) == IWL_CFG_MAC_TYPE_SNJ)
> iwl_trans->trans_cfg = _so_trans_cfg;
>
> -#if IS_ENABLED(CONFIG_IWLMVM)
> /*
> * special-case 7265D, it has the same PCI IDs.
> *
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Sat, Mar 6, 2021 at 5:58 PM Alan Stern wrote:
>
> On Sat, Mar 06, 2021 at 07:42:30AM +0100, Sedat Dilek wrote:
> > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets:
>
> Is the kernel the only thing that is different? The rest of the
> operating system and environment is exactly the same?
>
The kernel is the only change.
> > But I see there is already a quirk enabled and matches my ASmedia USB
> > 3.0 controller (as I have *no* usb-storage-quirks enabled):
> >
> > root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa'
> > [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid
> > 174c pid 55aa: 40
>
> Yes, this is because that type of device already has a quirk entry built
> into the kernel. You can find it by searching for "174c" in the kernel
> source file drivers/usb/storage/unusual_devs.h.
>
OK, will look into it.
> > Thanks Alan for all the hints and tips in the topic "usb-storage and
> > quirks" and your patience.
>
> You can try building a 5.11 kernel with the patch below. I don't know
> whether it will show anything in the dmesg log when one of these resets
> occurs, but it might.
>
> If that doesn't work out, another possibility is to use git bisect to
> find the commit between 5.10 and 5.11 which caused the problem to start.
>
This is with Linux v5.12-rc2 - not v5.11.y.
I look if I can apply the patch.
- Sedat -
>
>
> --- usb-devel.orig/block/scsi_ioctl.c
> +++ usb-devel/block/scsi_ioctl.c
> @@ -258,8 +258,11 @@ static int blk_complete_sghdr_rq(struct
> hdr->host_status = host_byte(req->result);
> hdr->driver_status = driver_byte(req->result);
> hdr->info = 0;
> - if (hdr->masked_status || hdr->host_status || hdr->driver_status)
> + if (hdr->masked_status || hdr->host_status || hdr->driver_status) {
> hdr->info |= SG_INFO_CHECK;
> + printk(KERN_INFO "SCSI ioctl error, cmd %02X, prog %s\n",
> + req->cmd[0], current->comm);
> + }
> hdr->resid = req->resid_len;
> hdr->sb_len_wr = 0;
>
>
Re: Linux 5.12-rc1
On Mon, Mar 1, 2021 at 10:34 PM Linus Torvalds wrote: > > On Mon, Mar 1, 2021 at 12:35 AM Sedat Dilek wrote: > > > > I wondered why there was approx. for 6 days no commits and got an > > answer from an LWN posting "5.12 Merge window delayed". > > Unsure, if there was a posting to LKML? > > There was no posting to lkml because lkml doesn't take html emails, > and I only had mobile data (and not even that for the first 24 hours > or so - even cell towers were down). > > I did send updates to several top-level maintainers and to the > us...@kernel.org mailing list, so a lot of people knew about it, but > they in turn probably only ended up mentioning it on a need-to-know > basis. As you mention, LWN did have a mention of it, but you'd have to > find it. > > In normal times I would have just taken a laptop to the nearest > Starbucks and worked that way, but not in the pandemic. Plus the local > highway was actually shut down for three days because of downed trees > on the road (this was not a Texas-style electricity generation problem > - it was literally thousands of trees falling all over. We had one > miss our house by a couple of meters). > > Two weeks later, and the roadways are still littered with trees and > tons of branches everywhere you drive. > > And I didn't have a generator because our local power lines are > actually buried, and we very seldom lose electricity. But when all the > feeder lines are down because trees fell over, and it takes a week > first for the tree crews to clear the roads and then the electric > crews to replace literally miles of electric cable, it doesn't really > help all that much that the local lines are buried and all in good > working order ;) > > > Anyway, if you are not able to make your work someone else should jump > > in like Greg did once. > > It was an option, it didn't seem worth it. > > And part of _that_ was that it looked like "ok, a couple of days", and > then it just kept being "one more day" for several days. > > A lot of people lost power for just a day or two. > > The area I live in probably wasn't a huge priority, because it's > somewhat sparsely populated, and nice and wooded. > > Which is really nice most of the time. It's not quite so nice when you > can hear the trees keep falling around you, and you know you have a > few really big ones right next to the house.. ;^p > Based on / Freely adapted from Goethe: I answer just when it suits me! I can hardly imagine your feelings and/or emotions as I was NOT in such a situation. I remember "Blackout Münsterland - Münsterländer Schneechaos 2005" [1] seen on German TV. 150km (approx. 92 miles) from my new home-town. To make a story short: Be proud you made a merge-window happen in real 14 -6 = 8 days. That is amazing, really! There exist emergency plans - especially for pandemic situations - here in Germany. For me it looks like no one cares - including the responsibles. Exceptional circumstances or you might say "CHAOS". Sometimes having no plan is good - but never forget your focus or targets. I wanted to hear from you: Next time in such an exceptional situation I/we will do ... And hey yah: Linux v5.12-rc2 on a Saturday Morning @ 06-Mar-2021. Congrats! - Sedat - [1] https://www.youtube.com/watch?v=jfKeGHqrip8
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 5, 2021 at 8:54 PM Sedat Dilek wrote: > > On Fri, Mar 5, 2021 at 8:47 PM Alan Stern wrote: > > > > On Fri, Mar 05, 2021 at 08:41:40PM +0100, Sedat Dilek wrote: > > > On Fri, Mar 5, 2021 at 8:30 PM Alan Stern > > > wrote: > > > > > > Okay, that indicates the ATA commands are being sent not by the kernel > > > > but by some program. I'm not sure how you can easily find out which > > > > program; probably the best thing to do is turn them off one by one until > > > > you find the one responsible. > > > > > > > > > > I can hardly imagine which user-space tools other than powertop can > > > interfere here. > > > Any ideas? > > > > No. Especially since I have no idea what programs are running on your > > computer. > > > > Are we talking about things like gvfs - udisks - fuse etc.? > All running via systemd here. > > Here I am using KDE/Plasma as DE. > Unsure if this runs apps in the background. > > AFAICS I have not seen xhci-resets with Debian-Kernel 5.10.19-1. > No, with Debian-Kernel 5.10.19-1 there are no xhci-resets: root# cat /proc/version Linux version 5.10.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.19-1 (2021-03-02) root# LC_ALL=C dmesg -T | grep xhci | grep reset [ empty ] But I see there is already a quirk enabled and matches my ASmedia USB 3.0 controller (as I have *no* usb-storage-quirks enabled): root# LC_ALL=C dmesg -T | grep -i quirks | egrep '174c|55aa' [Sat Mar 6 06:52:41 2021] usb-storage 4-1:1.0: Quirks match for vid 174c pid 55aa: 40 For the sake of completeness my latest /etc/modules-load.d/usb-storage.conf: # Add quirks for USB Mass Storage devices # # Link: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html # # usb-storage quirks kernel-parameters and options explained: # [1] Usage: usb-storage.quirks= # [2] VendorID (VID) and ProductID (PID): # ASMedia M1042 USB-3.0 controller: VID: 174c PID: 55aa # [3] Flags: # t = NO_ATA_1X (don't allow ATA(12) and ATA(16) commands, uas only); # u = IGNORE_UAS (don't bind to the uas driver); # [4] Example: usb-storage.quirks=174c:55aa:t # # DEBUG: echo '174c:55aa:t' > /sys/module/usb_storage/parameters/quirks # # XXX: Commented - xhci-resets NOT caused by the Linux-kernel (check user-space) #options usb-storage quirks=174c:55aa:t - EOF - Thanks Alan for all the hints and tips in the topic "usb-storage and quirks" and your patience. - Sedat -
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 5, 2021 at 8:47 PM Alan Stern wrote: > > On Fri, Mar 05, 2021 at 08:41:40PM +0100, Sedat Dilek wrote: > > On Fri, Mar 5, 2021 at 8:30 PM Alan Stern wrote: > > > > Okay, that indicates the ATA commands are being sent not by the kernel > > > but by some program. I'm not sure how you can easily find out which > > > program; probably the best thing to do is turn them off one by one until > > > you find the one responsible. > > > > > > > I can hardly imagine which user-space tools other than powertop can > > interfere here. > > Any ideas? > > No. Especially since I have no idea what programs are running on your > computer. > Are we talking about things like gvfs - udisks - fuse etc.? All running via systemd here. Here I am using KDE/Plasma as DE. Unsure if this runs apps in the background. AFAICS I have not seen xhci-resets with Debian-Kernel 5.10.19-1. - Sedat -
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 5, 2021 at 8:30 PM Alan Stern wrote: > > On Fri, Mar 05, 2021 at 08:22:22PM +0100, Sedat Dilek wrote: > > The quirks match: > > > > [Fri Mar 5 20:06:56 2021] usb-storage 4-1:1.0: USB Mass Storage device > > detected > > [Fri Mar 5 20:06:56 2021] usb-storage 4-1:1.0: Quirks match for vid > > 174c pid 55aa: 40 > > > > That seems not to be the trick: > > > > root# LC_ALL=C dmesg -T | grep 'usb 4-1:' > > [Fri Mar 5 20:06:55 2021] usb 4-1: new SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 5 20:06:55 2021] usb 4-1: New USB device found, > > idVendor=174c, idProduct=55aa, bcdDevice= 1.00 > > [Fri Mar 5 20:06:55 2021] usb 4-1: New USB device strings: Mfr=2, > > Product=3, SerialNumber=1 > > [Fri Mar 5 20:06:55 2021] usb 4-1: Product: MEDION HDDrive-n-GO > > [Fri Mar 5 20:06:55 2021] usb 4-1: Manufacturer: MEDION > > [Fri Mar 5 20:06:55 2021] usb 4-1: SerialNumber: 3180092C > > [Fri Mar 5 20:06:57 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > Okay, that indicates the ATA commands are being sent not by the kernel > but by some program. I'm not sure how you can easily find out which > program; probably the best thing to do is turn them off one by one until > you find the one responsible. > I can hardly imagine which user-space tools other than powertop can interfere here. Any ideas? I will remove or better comment the quirks in /etc/modules-load.d/usb-storage.conf for now. - Sedat -
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 5, 2021 at 8:25 PM Alan Stern wrote: > > On Fri, Mar 05, 2021 at 08:05:49PM +0100, Sedat Dilek wrote: > > On Fri, Mar 5, 2021 at 5:07 PM Alan Stern wrote: > > > > Don't worry about trying to decode the output. To me it looks like the > > > drive crashes and needs to be reset at times when the computer sends it > > > an ATA command. (Not all ATA commands, but some.) You can prevent this > > > by setting the following module parameter for the usb-storage driver: > > > > > > quirks=174c:55aa:t > > > > > > where the two numbers are the Vendor and Product IDs for the external > > > drive, and the 't' is a quirks flag saying not to use any ATA commands. > > > If this module parameter fixes the problem, we can add a permanent quirk > > > setting to the kernel. > > > > > > > Thanks Alan. > > > > I did: > > > > [ /etc/modules-load.d/usb-storage.conf ] > > > > # Add quirks for ATA commands for usb-storage devices connected to > > ASMedia M1042 USB-3.0 controller > > options usb-storage quirks=174c:55aa:t > > - EOF - > > > > It is: > > > > /lib/modules/5.12.0-rc1-11-amd64-clang13-cfi/kernel/drivers/usb/storage/usb-storage.ko > > > > But: > > > > root# lsmod | grep usb | grep storage > > usb_storage90112 2 uas > > scsi_mod 307200 6 sd_mod,usb_storage,uas,libata,sg,sr_mod > > usbcore 385024 14 > > usbserial,xhci_hcd,ehci_pci,usbnet,usbhid,usb_storage,usb_wwan,uvcvideo,ehci_hcd,btusb,xhci_pci,cdc_ether,uas,option > > I don't understand. What is the point of this listing? > I was confused about lsmod and modinfo output: usb-storage.ko (kernel-module name) VS. usb_storage (modinfo: name: usb_storage) > > I have not rebooted yet. > > Depending on how your system is set up, the new usb-storage.conf file > might need to be copied into the initramfs image. > That seems not to be needed. > However, you don't need to reload the driver module or reboot. To make > the new quirk take effect, all you have to do is write 174c:55aa:t to > /sys/module/usb_storage/parameters/quirks. > OK, keep this for next USB(mon) testings before doing a reboot. > > Interferences with PowerTop? > > Maybe. It's entirely possible that PowerTop or some other program is > issuing the troublesome ATA commands. > > > These xhci-resets happen every 10mins in a sequence of 4. > > > > I have here a powertop.service (systemd) with passing --auto-tune option. > > That was not a problem with previous Linux-kernels >= v5.12-rc1, so. > > > > Alan, what do you think? > > Try turning the service off and see if that makes any difference. > NO, it is not powertop.service causing the xhci-resets. - Sedat -
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 5, 2021 at 8:05 PM Sedat Dilek wrote: > > On Fri, Mar 5, 2021 at 5:07 PM Alan Stern wrote: > > > > On Fri, Mar 05, 2021 at 01:09:16PM +0100, Sedat Dilek wrote: > > > On Mon, Mar 1, 2021 at 4:53 PM Alan Stern > > > wrote: > > > [ ... ] > > > > You can use usbmon on bus 4 to record the USB traffic. It may indicate > > > > why the resets occur. > > > > > > > > > > Hi Alan, > > > > > > I followed the instructions in [1]. > > > > > > root# modprobe -v usbmon > > > > > > root# ls /sys/kernel/debug/usb/usbmon > > > 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u > > > > > > root# cat /sys/kernel/debug/usb/usbmon/4u > /tmp/usbmon-log_4u.txt > > > [ Ctrl+C ] > > > > > > I recorded 13:03 - 13:04 (one minute). > > > > > > So these xhci-resets should be included: > > > > > > [Fri Mar 5 13:03:07 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > > number 2 using xhci_hcd > > > [Fri Mar 5 13:03:07 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > > number 2 using xhci_hcd > > > [Fri Mar 5 13:03:27 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > > number 2 using xhci_hcd > > > [Fri Mar 5 13:03:27 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > > number 2 using xhci_hcd > > > [Fri Mar 5 13:03:27 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > > number 2 using xhci_hcd > > > [Fri Mar 5 13:03:28 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > > number 2 using xhci_hcd > > > [Fri Mar 5 13:03:28 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > > number 2 using xhci_hcd > > > > > > The usbmon-log is attached. > > > > > > Unsure how to interpret the log - the kernel-doc says `raw data`. > > > How can I bring this into a human-readable format? > > > Can you give me a hand? > > > > Don't worry about trying to decode the output. To me it looks like the > > drive crashes and needs to be reset at times when the computer sends it > > an ATA command. (Not all ATA commands, but some.) You can prevent this > > by setting the following module parameter for the usb-storage driver: > > > > quirks=174c:55aa:t > > > > where the two numbers are the Vendor and Product IDs for the external > > drive, and the 't' is a quirks flag saying not to use any ATA commands. > > If this module parameter fixes the problem, we can add a permanent quirk > > setting to the kernel. > > > > Thanks Alan. > > I did: > > [ /etc/modules-load.d/usb-storage.conf ] > > # Add quirks for ATA commands for usb-storage devices connected to > ASMedia M1042 USB-3.0 controller > options usb-storage quirks=174c:55aa:t > - EOF - > > It is: > > /lib/modules/5.12.0-rc1-11-amd64-clang13-cfi/kernel/drivers/usb/storage/usb-storage.ko > > But: > > root# lsmod | grep usb | grep storage > usb_storage90112 2 uas > scsi_mod 307200 6 sd_mod,usb_storage,uas,libata,sg,sr_mod > usbcore 385024 14 > usbserial,xhci_hcd,ehci_pci,usbnet,usbhid,usb_storage,usb_wwan,uvcvideo,ehci_hcd,btusb,xhci_pci,cdc_ether,uas,option > > I have not rebooted yet. > > Interferences with PowerTop? > > These xhci-resets happen every 10mins in a sequence of 4. > > I have here a powertop.service (systemd) with passing --auto-tune option. > That was not a problem with previous Linux-kernels >= v5.12-rc1, so. > > Alan, what do you think? > The quirks match: [Fri Mar 5 20:06:56 2021] usb-storage 4-1:1.0: USB Mass Storage device detected [Fri Mar 5 20:06:56 2021] usb-storage 4-1:1.0: Quirks match for vid 174c pid 55aa: 40 That seems not to be the trick: root# LC_ALL=C dmesg -T | grep 'usb 4-1:' [Fri Mar 5 20:06:55 2021] usb 4-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 5 20:06:55 2021] usb 4-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00 [Fri Mar 5 20:06:55 2021] usb 4-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [Fri Mar 5 20:06:55 2021] usb 4-1: Product: MEDION HDDrive-n-GO [Fri Mar 5 20:06:55 2021] usb 4-1: Manufacturer: MEDION [Fri Mar 5 20:06:55 2021] usb 4-1: SerialNumber: 3180092C [Fri Mar 5 20:06:57 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 5 20:06:57 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 5 20:06:57 2021] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [Fri Mar 5 20:06:58 2021] usb 4-1: reset SuperSpeed Gen 1 USB dev
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Fri, Mar 5, 2021 at 5:07 PM Alan Stern wrote: > > On Fri, Mar 05, 2021 at 01:09:16PM +0100, Sedat Dilek wrote: > > On Mon, Mar 1, 2021 at 4:53 PM Alan Stern wrote: > > [ ... ] > > > You can use usbmon on bus 4 to record the USB traffic. It may indicate > > > why the resets occur. > > > > > > > Hi Alan, > > > > I followed the instructions in [1]. > > > > root# modprobe -v usbmon > > > > root# ls /sys/kernel/debug/usb/usbmon > > 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u > > > > root# cat /sys/kernel/debug/usb/usbmon/4u > /tmp/usbmon-log_4u.txt > > [ Ctrl+C ] > > > > I recorded 13:03 - 13:04 (one minute). > > > > So these xhci-resets should be included: > > > > [Fri Mar 5 13:03:07 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 5 13:03:07 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 5 13:03:27 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 5 13:03:27 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 5 13:03:27 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 5 13:03:28 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > [Fri Mar 5 13:03:28 2021] usb 4-1: reset SuperSpeed Gen 1 USB device > > number 2 using xhci_hcd > > > > The usbmon-log is attached. > > > > Unsure how to interpret the log - the kernel-doc says `raw data`. > > How can I bring this into a human-readable format? > > Can you give me a hand? > > Don't worry about trying to decode the output. To me it looks like the > drive crashes and needs to be reset at times when the computer sends it > an ATA command. (Not all ATA commands, but some.) You can prevent this > by setting the following module parameter for the usb-storage driver: > > quirks=174c:55aa:t > > where the two numbers are the Vendor and Product IDs for the external > drive, and the 't' is a quirks flag saying not to use any ATA commands. > If this module parameter fixes the problem, we can add a permanent quirk > setting to the kernel. > Thanks Alan. I did: [ /etc/modules-load.d/usb-storage.conf ] # Add quirks for ATA commands for usb-storage devices connected to ASMedia M1042 USB-3.0 controller options usb-storage quirks=174c:55aa:t - EOF - It is: /lib/modules/5.12.0-rc1-11-amd64-clang13-cfi/kernel/drivers/usb/storage/usb-storage.ko But: root# lsmod | grep usb | grep storage usb_storage90112 2 uas scsi_mod 307200 6 sd_mod,usb_storage,uas,libata,sg,sr_mod usbcore 385024 14 usbserial,xhci_hcd,ehci_pci,usbnet,usbhid,usb_storage,usb_wwan,uvcvideo,ehci_hcd,btusb,xhci_pci,cdc_ether,uas,option I have not rebooted yet. Interferences with PowerTop? These xhci-resets happen every 10mins in a sequence of 4. I have here a powertop.service (systemd) with passing --auto-tune option. That was not a problem with previous Linux-kernels >= v5.12-rc1, so. Alan, what do you think? - Sedat -
Re: [PATCH v2] sched: Optimize __calc_delta.
On Thu, Mar 4, 2021 at 7:24 PM Sedat Dilek wrote:
>
> On Thu, Mar 4, 2021 at 6:34 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > On Wed, Mar 3, 2021 at 2:48 PM Josh Don wrote:
> > >
> > > From: Clement Courbet
> > >
> > > A significant portion of __calc_delta time is spent in the loop
> > > shifting a u64 by 32 bits. Use `fls` instead of iterating.
> > >
> > > This is ~7x faster on benchmarks.
> > >
> > > The generic `fls` implementation (`generic_fls`) is still ~4x faster
> > > than the loop.
> > > Architectures that have a better implementation will make use of it. For
> > > example, on X86 we get an additional factor 2 in speed without dedicated
> > > implementation.
> > >
> > > On gcc, the asm versions of `fls` are about the same speed as the
> > > builtin. On clang, the versions that use fls are more than twice as
> > > slow as the builtin. This is because the way the `fls` function is
> > > written, clang puts the value in memory:
> > > https://godbolt.org/z/EfMbYe. This bug is filed at
> > > https://bugs.llvm.org/show_bug.cgi?id=49406.
> >
> > Hi Josh, Thanks for helping get this patch across the finish line.
> > Would you mind updating the commit message to point to
> > https://bugs.llvm.org/show_bug.cgi?id=20197?
> >
> > >
> > > ```
> > > name cpu/op
> > > BM_Calc<__calc_delta_loop> 9.57ms ±12%
> > > BM_Calc<__calc_delta_generic_fls> 2.36ms ±13%
> > > BM_Calc<__calc_delta_asm_fls> 2.45ms ±13%
> > > BM_Calc<__calc_delta_asm_fls_nomem>1.66ms ±12%
> > > BM_Calc<__calc_delta_asm_fls64>2.46ms ±13%
> > > BM_Calc<__calc_delta_asm_fls64_nomem> 1.34ms ±15%
> > > BM_Calc<__calc_delta_builtin> 1.32ms ±11%
> > > ```
> > >
> > > Signed-off-by: Clement Courbet
> > > Signed-off-by: Josh Don
> > > ---
> > > kernel/sched/fair.c | 19 +++
> > > kernel/sched/sched.h | 1 +
> > > 2 files changed, 12 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 8a8bd7b13634..a691371960ae 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -229,22 +229,25 @@ static void __update_inv_weight(struct load_weight
> > > *lw)
> > > static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct
> > > load_weight *lw)
> > > {
> > > u64 fact = scale_load_down(weight);
> > > + u32 fact_hi = (u32)(fact >> 32);
> > > int shift = WMULT_SHIFT;
> > > + int fs;
> > >
> > > __update_inv_weight(lw);
> > >
> > > - if (unlikely(fact >> 32)) {
> > > - while (fact >> 32) {
> > > - fact >>= 1;
> > > - shift--;
> > > - }
> > > + if (unlikely(fact_hi)) {
> > > + fs = fls(fact_hi);
> > > + shift -= fs;
> > > + fact >>= fs;
> > > }
> > >
> > > fact = mul_u32_u32(fact, lw->inv_weight);
> > >
> > > - while (fact >> 32) {
> > > - fact >>= 1;
> > > - shift--;
> > > + fact_hi = (u32)(fact >> 32);
> > > + if (fact_hi) {
> > > + fs = fls(fact_hi);
> > > + shift -= fs;
> > > + fact >>= fs;
> > > }
> > >
> > > return mul_u64_u32_shr(delta_exec, fact, shift);
> > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > > index 10a1522b1e30..714af71cf983 100644
> > > --- a/kernel/sched/sched.h
> > > +++ b/kernel/sched/sched.h
> > > @@ -36,6 +36,7 @@
> > > #include
> > >
> > > #include
> > > +#include
> >
> > This hunk of the patch is curious. I assume that bitops.h is needed
> > for fls(); if so, why not #include it in kernel/sched/fair.c?
> > Otherwise this potentially hurts compile time for all TUs that include
> > kernel/sched/sched.h.
> >
>
> I have v2 as-is in my custom patchset and booted right now on bare metal.
>
> As Nick points out moving the include makes sense to me.
> We h
Re: [PATCH v2] sched: Optimize __calc_delta.
On Thu, Mar 4, 2021 at 6:34 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Wed, Mar 3, 2021 at 2:48 PM Josh Don wrote:
> >
> > From: Clement Courbet
> >
> > A significant portion of __calc_delta time is spent in the loop
> > shifting a u64 by 32 bits. Use `fls` instead of iterating.
> >
> > This is ~7x faster on benchmarks.
> >
> > The generic `fls` implementation (`generic_fls`) is still ~4x faster
> > than the loop.
> > Architectures that have a better implementation will make use of it. For
> > example, on X86 we get an additional factor 2 in speed without dedicated
> > implementation.
> >
> > On gcc, the asm versions of `fls` are about the same speed as the
> > builtin. On clang, the versions that use fls are more than twice as
> > slow as the builtin. This is because the way the `fls` function is
> > written, clang puts the value in memory:
> > https://godbolt.org/z/EfMbYe. This bug is filed at
> > https://bugs.llvm.org/show_bug.cgi?id=49406.
>
> Hi Josh, Thanks for helping get this patch across the finish line.
> Would you mind updating the commit message to point to
> https://bugs.llvm.org/show_bug.cgi?id=20197?
>
> >
> > ```
> > name cpu/op
> > BM_Calc<__calc_delta_loop> 9.57ms ±12%
> > BM_Calc<__calc_delta_generic_fls> 2.36ms ±13%
> > BM_Calc<__calc_delta_asm_fls> 2.45ms ±13%
> > BM_Calc<__calc_delta_asm_fls_nomem>1.66ms ±12%
> > BM_Calc<__calc_delta_asm_fls64>2.46ms ±13%
> > BM_Calc<__calc_delta_asm_fls64_nomem> 1.34ms ±15%
> > BM_Calc<__calc_delta_builtin> 1.32ms ±11%
> > ```
> >
> > Signed-off-by: Clement Courbet
> > Signed-off-by: Josh Don
> > ---
> > kernel/sched/fair.c | 19 +++
> > kernel/sched/sched.h | 1 +
> > 2 files changed, 12 insertions(+), 8 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 8a8bd7b13634..a691371960ae 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -229,22 +229,25 @@ static void __update_inv_weight(struct load_weight
> > *lw)
> > static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct
> > load_weight *lw)
> > {
> > u64 fact = scale_load_down(weight);
> > + u32 fact_hi = (u32)(fact >> 32);
> > int shift = WMULT_SHIFT;
> > + int fs;
> >
> > __update_inv_weight(lw);
> >
> > - if (unlikely(fact >> 32)) {
> > - while (fact >> 32) {
> > - fact >>= 1;
> > - shift--;
> > - }
> > + if (unlikely(fact_hi)) {
> > + fs = fls(fact_hi);
> > + shift -= fs;
> > + fact >>= fs;
> > }
> >
> > fact = mul_u32_u32(fact, lw->inv_weight);
> >
> > - while (fact >> 32) {
> > - fact >>= 1;
> > - shift--;
> > + fact_hi = (u32)(fact >> 32);
> > + if (fact_hi) {
> > + fs = fls(fact_hi);
> > + shift -= fs;
> > + fact >>= fs;
> > }
> >
> > return mul_u64_u32_shr(delta_exec, fact, shift);
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index 10a1522b1e30..714af71cf983 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -36,6 +36,7 @@
> > #include
> >
> > #include
> > +#include
>
> This hunk of the patch is curious. I assume that bitops.h is needed
> for fls(); if so, why not #include it in kernel/sched/fair.c?
> Otherwise this potentially hurts compile time for all TUs that include
> kernel/sched/sched.h.
>
I have v2 as-is in my custom patchset and booted right now on bare metal.
As Nick points out moving the include makes sense to me.
We have a lot of include at the wrong places increasing build-time.
- Sedat -
> > #include
> > #include
> > #include
> > --
> > 2.30.1.766.gb4fecdf3b7-goog
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdmijctJfM3gNfwEVjaQyp3LZkhnAwgsT7EBhsSBJyfLAA%40mail.gmail.com.
Re: [PATCH v2] iwlwifi: don't call netif_napi_add() with rxq->lock held (was Re: Lockdep warning in iwl_pcie_rx_handle())
On Wed, Mar 3, 2021 at 1:38 AM Kalle Valo wrote:
>
> "Coelho, Luciano" writes:
>
> > On Tue, 2021-03-02 at 11:34 +0100, Jiri Kosina wrote:
> >> From: Jiri Kosina
> >>
> >> We can't call netif_napi_add() with rxq-lock held, as there is a potential
> >> for deadlock as spotted by lockdep (see below). rxq->lock is not
> >> protecting anything over the netif_napi_add() codepath anyway, so let's
> >> drop it just before calling into NAPI.
> >>
> >>
> >> WARNING: possible irq lock inversion dependency detected
> >> 5.12.0-rc1-2-gbada49429032 #5 Not tainted
> >>
> >> irq/136-iwlwifi/565 just changed the state of lock:
> >> 89f28433b0b0 (>lock){+.-.}-{2:2}, at:
> >> iwl_pcie_rx_handle+0x7f/0x960 [iwlwifi]
> >> but this lock took another, SOFTIRQ-unsafe lock in the past:
> >> (napi_hash_lock){+.+.}-{2:2}
> >>
> >> and interrupts could create inverse lock ordering between them.
> >>
> >> other info that might help us debug this:
> >> Possible interrupt unsafe locking scenario:
> >>
> >> CPU0CPU1
> >>
> >>lock(napi_hash_lock);
> >> local_irq_disable();
> >> lock(>lock);
> >> lock(napi_hash_lock);
> >>
> >> lock(>lock);
> >>
> >> *** DEADLOCK ***
> >>
> >> 1 lock held by irq/136-iwlwifi/565:
> >> #0: 89f2b1440170 (sync_cmd_lockdep_map){+.+.}-{0:0}, at:
> >> iwl_pcie_irq_handler+0x5/0xb30
> >>
> >> the shortest dependencies between 2nd lock and 1st lock:
> >> -> (napi_hash_lock){+.+.}-{2:2} {
> >> HARDIRQ-ON-W at:
> >>lock_acquire+0x277/0x3d0
> >>_raw_spin_lock+0x2c/0x40
> >>netif_napi_add+0x14b/0x270
> >>e1000_probe+0x2fe/0xee0 [e1000e]
> >>local_pci_probe+0x42/0x90
> >>pci_device_probe+0x10b/0x1c0
> >>really_probe+0xef/0x4b0
> >>driver_probe_device+0xde/0x150
> >>device_driver_attach+0x4f/0x60
> >>__driver_attach+0x9c/0x140
> >>bus_for_each_dev+0x79/0xc0
> >>bus_add_driver+0x18d/0x220
> >>driver_register+0x5b/0xf0
> >>do_one_initcall+0x5b/0x300
> >>do_init_module+0x5b/0x21c
> >>load_module+0x1dae/0x22c0
> >>__do_sys_finit_module+0xad/0x110
> >>do_syscall_64+0x33/0x80
> >>entry_SYSCALL_64_after_hwframe+0x44/0xae
> >> SOFTIRQ-ON-W at:
> >>lock_acquire+0x277/0x3d0
> >>_raw_spin_lock+0x2c/0x40
> >>netif_napi_add+0x14b/0x270
> >>e1000_probe+0x2fe/0xee0 [e1000e]
> >>local_pci_probe+0x42/0x90
> >>pci_device_probe+0x10b/0x1c0
> >>really_probe+0xef/0x4b0
> >>driver_probe_device+0xde/0x150
> >>device_driver_attach+0x4f/0x60
> >>__driver_attach+0x9c/0x140
> >>bus_for_each_dev+0x79/0xc0
> >>bus_add_driver+0x18d/0x220
> >>driver_register+0x5b/0xf0
> >>do_one_initcall+0x5b/0x300
> >>do_init_module+0x5b/0x21c
> >>load_module+0x1dae/0x22c0
> >>__do_sys_finit_module+0xad/0x110
> >>do_syscall_64+0x33/0x80
> >>entry_SYSCALL_64_after_hwframe+0x44/0xae
> >> INITIAL USE at:
> >> lock_acquire+0x277/0x3d0
> >> _raw_spin_lock+0x2c/0x40
> >> netif_napi_add+0x14b/0x270
> >> e1000_probe+0x2fe/0xee0 [e1000e]
> >> local_pci_probe+0x42/0x90
> >> pci_device_probe+0x10b/0x1c0
> >> really_probe+0xef/0x4b0
> >> driver_probe_device+0xde/0x150
> >> device_driver_attach+0x4f/0x60
> >> __driver_attach+0x9c/0x140
> >> bus_for_each_dev+0x79/0xc0
> >> bus_add_driver+0x18d/0x220
> >> driver_register+0x5b/0xf0
> >> do_one_initcall+0x5b/0x300
> >> do_init_module+0x5b/0x21c
> >> load_module+0x1dae/0x22c0
> >> __do_sys_finit_module+0xad/0x110
> >> do_syscall_64+0x33/0x80
> >> entry_SYSCALL_64_after_hwframe+0x44/0xae
> >>}
Re: [PATCH 1/2] Makefile: Remove '--gcc-toolchain' flag
On Wed, Mar 3, 2021 at 4:25 AM Sedat Dilek wrote: > > On Tue, Mar 2, 2021 at 10:07 PM Nathan Chancellor wrote: > > > > This is not necessary anymore now that we specify '--prefix=', which > > tells clang exactly where to find the GNU cross tools. This has been > > verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as well as a > > distribution version of LLVM 11.1.0 without binutils in the LLVM > > toolchain locations. > > > > Signed-off-by: Nathan Chancellor > > [ CC Behan ] > > Hahaha, that is a change of a very early commit in times of the > LLVM/Clang Linux-kernel development. > So-to-say a historical change :-). > > I will try this patchset later with latest Linux -v5.12-rc1+ and my > custom patchset. > I tested these two patches in my build environment. So far no issues. NOTE: I have not tested the combo: Clang and GNU AS. Tested-by: Sedat Dilek # LLVM/Clang v13-git - Sedat - > > --- > > Makefile | 4 > > 1 file changed, 4 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index f9b54da2fca0..c20f0ad8be73 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),) > > CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) > > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) > > CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > > -GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..) > > -endif > > -ifneq ($(GCC_TOOLCHAIN),) > > -CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN) > > endif > > ifneq ($(LLVM_IAS),1) > > CLANG_FLAGS+= -no-integrated-as > > > > base-commit: 7a7fd0de4a9804299793e564a555a49c1fc924cb > > -- > > 2.31.0.rc0.75.gec125d1bc1 > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Clang Built Linux" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clang-built-linux+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/clang-built-linux/20210302210646.3044738-1-nathan%40kernel.org.
Re: [PATCH 1/2] Makefile: Remove '--gcc-toolchain' flag
On Tue, Mar 2, 2021 at 10:07 PM Nathan Chancellor wrote: > > This is not necessary anymore now that we specify '--prefix=', which > tells clang exactly where to find the GNU cross tools. This has been > verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as well as a > distribution version of LLVM 11.1.0 without binutils in the LLVM > toolchain locations. > > Signed-off-by: Nathan Chancellor [ CC Behan ] Hahaha, that is a change of a very early commit in times of the LLVM/Clang Linux-kernel development. So-to-say a historical change :-). I will try this patchset later with latest Linux -v5.12-rc1+ and my custom patchset. Thanks. - Sedat - > --- > Makefile | 4 > 1 file changed, 4 deletions(-) > > diff --git a/Makefile b/Makefile > index f9b54da2fca0..c20f0ad8be73 100644 > --- a/Makefile > +++ b/Makefile > @@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),) > CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%)) > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) > CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > -GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..) > -endif > -ifneq ($(GCC_TOOLCHAIN),) > -CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN) > endif > ifneq ($(LLVM_IAS),1) > CLANG_FLAGS+= -no-integrated-as > > base-commit: 7a7fd0de4a9804299793e564a555a49c1fc924cb > -- > 2.31.0.rc0.75.gec125d1bc1 > > -- > You received this message because you are subscribed to the Google Groups > "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clang-built-linux+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clang-built-linux/20210302210646.3044738-1-nathan%40kernel.org.
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Wed, Feb 24, 2021 at 6:25 PM Sedat Dilek wrote: > > On Wed, Feb 24, 2021 at 2:44 PM Sedat Dilek wrote: > > > > Hi Mathias, > > > > I am here on Linux-v5.11-10201-gc03c21ba6f4e. > > > > I see a lot xhci-resets in my dmesg-log: > > > > root# LC_ALL=C dmesg -T | grep 'usb 4-1: reset SuperSpeed Gen 1 USB > > device number 2 using xhci_hcd' | wc -l > > 75 > > > > This is what I have: > > > > root# lsusb -s 004:001 > > Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > > > > root# lsusb -s 004:002 > > Bus 004 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA > > 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, > > ASM1153E SATA 6Gb/s bridge > > > > My external USB 3.0 HDD contains the partition with my Debian-system > > and is attached to the above xhci bus/device. > > > > Can you enlighten what this means? > > Is this a known issue? > > Is there a fix around? > > > > BTW, in which Git tree is the xhci development happening? > > Can you point me to it? > > > > I am attaching my linux-config and full dmesg-log. > > > > Also I have attached outputs of: > > > > $ sudo lsusb -vvv -d 1d6b:0003 > > $ sudo lsusb -vvv -d 174c:55aa > > > > If you need further information, please let me know. > > > > Thanks. > > > > Looks like that xhci-reset happens here every 10min. > [ To Greg ] The problem still remains with Linux v5.12-rc1 (see [1]). Yesterday, I ran some disk-health checks with smartctl and gsmartcontrol. All good. For the first time I used badblocks from e2fsprogs Debian package: root# LC_ALL=C badblocks -v -p 1 -s /dev/sdc -o badblocks-v-p-1-s_dev-sdc_$(uname -r).txt Checking blocks 0 to 976762583 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. (0/0/0 errors) Good, there is no file-system corruption or badblocks or even a hardware damage. Anyway, feedback is much appreciated. Thanks. Regards, - Sedat - [1] https://lore.kernel.org/lkml/ca+iczuujvnbjc4ajtt9lys4j+qbuqzuvj5xdw+ipmjxxuod...@mail.gmail.com/
Linux 5.12-rc1
[ Please CC me I am not subscribed to LKML ] [ Original post see [0] ] Hi Linus, Thanks for Linux v5.12-rc1 and all involved people. [ Delayed merge-window ] I wondered why there was approx. for 6 days no commits and got an answer from an LWN posting "5.12 Merge window delayed". Unsure, if there was a posting to LKML? Anyway, if you are not able to make your work someone else should jump in like Greg did once. When Stephen could not do his work someone else jumped in and did the Linux-next work. There should be a clear communication and alternative workflow in such situation. Why not post such delays on (if this is the official website)? [ News - Clang-LTO ] Always I read your "RC" announcement and would like to see some pointers to interesting new stuff. ( I know "interesting" is very POV. ) Thanks for pointing to the several clean-ups in Linux v5.12-rc1. As someone active on ClangBuiltLinux - we have now Clang-LTO support for arm64 and x86-64. Some issues I have seen and reported: [ Issues - iwlwifi / iwldwm ] I know of a call-trace for users of iwldwm device. You will need "iwlwifi: avoid crash on unsupported debug collection" patch (see [2]). [ Issues -usb / xhci ] I reported xhci-resets every 10min in "[xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd" thread (see [3]). No response, yet. Some ideas and feedback from me, myself and I. Have more fun! Regards, - Sedat - [0] https://marc.info/?l=linux-kernel=161455865730695=2 [1] https://lwn.net/Articles/846406/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/ [3] https://marc.info/?t=16141791281=1=2
Re: [PATCH v2] kbuild: fix UNUSED_KSYMS_WHITELIST for Clang LTO
On Sat, Feb 27, 2021 at 8:08 AM Sedat Dilek wrote:
>
> On Sat, Feb 27, 2021 at 7:55 AM Masahiro Yamada wrote:
> >
> > On Fri, Feb 26, 2021 at 6:26 PM Sedat Dilek wrote:
> > >
> > > On Fri, Feb 26, 2021 at 7:26 AM Masahiro Yamada
> > > wrote:
> > > >
> > > > Commit fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> > > > does not work as expected if the .config file has already specified
> > > > CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list" before enabling
> > > > CONFIG_LTO_CLANG.
> > > >
> > > > So, the user-supplied whitelist and LTO-specific white list must be
> > > > independent of each other.
> > > >
> > > > I refactored the shell script so CONFIG_MODVERSIONS and CONFIG_CLANG_LTO
> > > > handle whitelists in the same way.
> > > >
> > > > Fixes: fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> > > > Signed-off-by: Masahiro Yamada
Tested-by: Sedat Dilek
- Sedat -
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Rebase on top of Arnd's patch:
> > > >
> > > > https://lore.kernel.org/lkml/20210225143456.3829513-1-a...@kernel.org/
> > > >
> > > > init/Kconfig| 1 -
> > > > scripts/gen_autoksyms.sh| 35 -
> > > > scripts/lto-used-symbollist.txt | 6 --
> > >
> > > People who want to use their own "white-listed" (allow-listed)
> > > symbollist-file can do that via
> > > CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list".
> > > Correct?
> > >
> > > Why do you delete the default "scripts/lto-used-symbollist.txt" file
> > > and remove the default in the appropriate Kconfig for people who want
> > > to enable Clang-(Thin)LTO?
> > > These people should now use
> > > CONFIG_UNUSED_KSYMS_WHITELIST="scripts/lto-used-symbollist.txt"?
> > > But again - the file was deleted with your patch.
> > > Do I miss something?
> >
> > I think so.
> >
> > I moved those symbols to scripts/gen_autoksyms.sh
> >
>
> OK, I have overseen hat.
>
> - Sedat -
Re: [PATCH v2] kbuild: fix UNUSED_KSYMS_WHITELIST for Clang LTO
On Sat, Feb 27, 2021 at 7:55 AM Masahiro Yamada wrote:
>
> On Fri, Feb 26, 2021 at 6:26 PM Sedat Dilek wrote:
> >
> > On Fri, Feb 26, 2021 at 7:26 AM Masahiro Yamada
> > wrote:
> > >
> > > Commit fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> > > does not work as expected if the .config file has already specified
> > > CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list" before enabling
> > > CONFIG_LTO_CLANG.
> > >
> > > So, the user-supplied whitelist and LTO-specific white list must be
> > > independent of each other.
> > >
> > > I refactored the shell script so CONFIG_MODVERSIONS and CONFIG_CLANG_LTO
> > > handle whitelists in the same way.
> > >
> > > Fixes: fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> > > Signed-off-by: Masahiro Yamada
> > > ---
> > >
> > > Changes in v2:
> > > - Rebase on top of Arnd's patch:
> > > https://lore.kernel.org/lkml/20210225143456.3829513-1-a...@kernel.org/
> > >
> > > init/Kconfig| 1 -
> > > scripts/gen_autoksyms.sh| 35 -
> > > scripts/lto-used-symbollist.txt | 6 --
> >
> > People who want to use their own "white-listed" (allow-listed)
> > symbollist-file can do that via
> > CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list".
> > Correct?
> >
> > Why do you delete the default "scripts/lto-used-symbollist.txt" file
> > and remove the default in the appropriate Kconfig for people who want
> > to enable Clang-(Thin)LTO?
> > These people should now use
> > CONFIG_UNUSED_KSYMS_WHITELIST="scripts/lto-used-symbollist.txt"?
> > But again - the file was deleted with your patch.
> > Do I miss something?
>
> I think so.
>
> I moved those symbols to scripts/gen_autoksyms.sh
>
OK, I have overseen hat.
- Sedat -
Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
On Fri, Feb 26, 2021 at 10:51 AM Arnd Bergmann wrote: > > On Fri, Feb 26, 2021 at 10:05 AM Sedat Dilek wrote: > > On Fri, Feb 26, 2021 at 9:14 AM Arnd Bergmann wrote: > > > > > > BTW, is CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y setable for x86 (64bit)? > > > > ( Did not look or check for it. ) > > > > > > No, in mainline, HAVE_LD_DEAD_CODE_DATA_ELIMINATION is currently > > > only selected on MIPS and PowerPC. I only sent experimental patches to > > > enable it on arm64 and m68k, but have not tried booting them. If you > > > select the symbol on x86, you should see similar results. > > > > > > > OK, i see: > > > > $ git grep HAVE_LD_DEAD_CODE_DATA_ELIMINATION arch/mips/ > > arch/mips/Kconfig: select HAVE_LD_DEAD_CODE_DATA_ELIMINATION > > > > $ git grep HAVE_LD_DEAD_CODE_DATA_ELIMINATION arch/powerpc/ > > arch/powerpc/Kconfig: select HAVE_LD_DEAD_CODE_DATA_ELIMINATION > > > > So, I need to add this to arch/x86/Kconfig. > > > > You happen to know if changes to arch/x86/kernel/vmlinux.lds.S > > (sections) are needed? > > No idea. I'm still debugging a possible regression on arm64, but both > issues I found for arm64 are specific to that architecture and won't > happen on x86. It's likely that something else breaks though. > My first experiences with gc were with the freetz project (mips embedded router) and don't ask me what GCC version. I will try with gc + trim + cfi later after my current build has finished. > > Last question: > > The last days I see a lot of fixes touching inlining with LLVM/Clang > > v13-git. > > What git tag are you using? > > What are your experiences? > > Pending patches (kernel-side)? > > > > I use: > > $ /opt/llvm-toolchain/bin/clang --version > > dileks clang version 13.0.0 (https://github.com/llvm/llvm-project.git > > c465429f286f50e52a8d2b3b39f38344f3381cce) > > This is what I have on the build box: > Ubuntu clang version > 13.0.0-++20210223104451+ebca13c66504-1~exp1~20210223095200.234 > Distro-clang takes much longer here. Selfmade stage1-only LLVM toolchain compiles here 10% faster. cfi takes approx. 20% longer. With trim + gc I suppose it will take much longer. Let me test. Will report later. - Sedat -
Re: [PATCH v2] kbuild: fix UNUSED_KSYMS_WHITELIST for Clang LTO
On Fri, Feb 26, 2021 at 7:26 AM Masahiro Yamada wrote:
>
> Commit fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> does not work as expected if the .config file has already specified
> CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list" before enabling
> CONFIG_LTO_CLANG.
>
> So, the user-supplied whitelist and LTO-specific white list must be
> independent of each other.
>
> I refactored the shell script so CONFIG_MODVERSIONS and CONFIG_CLANG_LTO
> handle whitelists in the same way.
>
> Fixes: fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - Rebase on top of Arnd's patch:
> https://lore.kernel.org/lkml/20210225143456.3829513-1-a...@kernel.org/
>
> init/Kconfig| 1 -
> scripts/gen_autoksyms.sh| 35 -
> scripts/lto-used-symbollist.txt | 6 --
People who want to use their own "white-listed" (allow-listed)
symbollist-file can do that via
CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list".
Correct?
Why do you delete the default "scripts/lto-used-symbollist.txt" file
and remove the default in the appropriate Kconfig for people who want
to enable Clang-(Thin)LTO?
These people should now use
CONFIG_UNUSED_KSYMS_WHITELIST="scripts/lto-used-symbollist.txt"?
But again - the file was deleted with your patch.
Do I miss something?
- Sedat -
> 3 files changed, 26 insertions(+), 16 deletions(-)
> delete mode 100644 scripts/lto-used-symbollist.txt
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 719871f8727c..64c32300d1b4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -2283,7 +2283,6 @@ config TRIM_UNUSED_KSYMS
> config UNUSED_KSYMS_WHITELIST
> string "Whitelist of symbols to keep in ksymtab"
> depends on TRIM_UNUSED_KSYMS
> - default "scripts/lto-used-symbollist.txt" if LTO_CLANG
> help
> By default, all unused exported symbols will be un-exported from the
> build when TRIM_UNUSED_KSYMS is selected.
> diff --git a/scripts/gen_autoksyms.sh b/scripts/gen_autoksyms.sh
> index d54dfba15bf2..da320151e7c3 100755
> --- a/scripts/gen_autoksyms.sh
> +++ b/scripts/gen_autoksyms.sh
> @@ -19,7 +19,26 @@ esac
> # We need access to CONFIG_ symbols
> . include/config/auto.conf
>
> -ksym_wl=/dev/null
> +needed_symbols=
> +
> +# Special case for modversions (see modpost.c)
> +if [ -n "$CONFIG_MODVERSIONS" ]; then
> + needed_symbols="$needed_symbols module_layout"
> +fi
> +
> +# With CONFIG_LTO_CLANG, LLVM bitcode has not yet been compiled into a binary
> +# when the .mod files are generated, which means they don't yet contain
> +# references to certain symbols that will be present in the final binaries.
> +if [ -n "$CONFIG_LTO_CLANG" ]; then
> + # intrinsic functions
> + needed_symbols="$needed_symbols memcpy memmove memset"
> + # ftrace
> + needed_symbols="$needed_symbols _mcount"
> + # stack protector symbols
> + needed_symbols="$needed_symbols __stack_chk_fail __stack_chk_guard"
> +fi
> +
> +ksym_wl=
> if [ -n "$CONFIG_UNUSED_KSYMS_WHITELIST" ]; then
> # Use 'eval' to expand the whitelist path and check if it is relative
> eval ksym_wl="$CONFIG_UNUSED_KSYMS_WHITELIST"
> @@ -40,16 +59,14 @@ cat > "$output_file" << EOT
> EOT
>
> [ -f modules.order ] && modlist=modules.order || modlist=/dev/null
> -sed 's/ko$/mod/' $modlist |
> -xargs -n1 sed -n -e '2{s/ /\n/g;/^$/!p;}' -- |
> -cat - "$ksym_wl" |
> +
> +{
> + sed 's/ko$/mod/' $modlist | xargs -n1 sed -n -e '2p'
> + echo "$needed_symbols"
> + [ -n "$ksym_wl" ] && cat "$ksym_wl"
> +} | sed -e 's/ /\n/g' | sed -n -e '/^$/!p' |
> # Remove the dot prefix for ppc64; symbol names with a dot (.) hold entry
> # point addresses.
> sed -e 's/^\.//' |
> sort -u |
> sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$output_file"
> -
> -# Special case for modversions (see modpost.c)
> -if [ -n "$CONFIG_MODVERSIONS" ]; then
> - echo "#define __KSYM_module_layout 1" >> "$output_file"
> -fi
> diff --git a/scripts/lto-used-symbollist.txt b/scripts/lto-used-symbollist.txt
> deleted file mode 100644
> index 406ada65e926..
> --- a/scripts/lto-used-symbollist.txt
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -memcpy
> -memmove
> -memset
> -_mcount
> -__stack_chk_fail
> -__stack_chk_guard
> --
> 2.27.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/20210226062548.3334081-1-masahiroy%40kernel.org.
Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
On Fri, Feb 26, 2021 at 9:14 AM Arnd Bergmann wrote: > > On Fri, Feb 26, 2021 at 1:36 AM Sedat Dilek wrote: > > > > On Thu, Feb 25, 2021 at 12:21 PM Arnd Bergmann wrote: > > > > > > From: Arnd Bergmann > > > > > > When looking at kernel size optimizations, I found that arm64 > > > does not currently support HAVE_LD_DEAD_CODE_DATA_ELIMINATION, > > > which enables the --gc-sections flag to the linker. > > > > > > I see that for a defconfig build with llvm, there are some > > > notable improvements from enabling this, in particular when > > > combined with the recently added CONFIG_LTO_CLANG_THIN > > > and CONFIG_TRIM_UNUSED_KSYMS: > > > > > >textdata bss dec hex filename > > > 16570322 10998617 506468 28075407 1ac658f defconfig/vmlinux > > > 16318793 10569913 506468 27395174 1a20466 trim_defconfig/vmlinux > > > 16281234 10984848 504291 27770373 1a7be05 gc_defconfig/vmlinux > > > 16029705 10556880 504355 27090940 19d5ffc gc+trim_defconfig/vmlinux > > > 17040142 11102945 504196 28647283 1b51f73 thinlto_defconfig/vmlinux > > > 16788613 10663201 504196 27956010 1aa932a thinlto+trim_defconfig/vmlinux > > > 16347062 11043384 502499 27892945 1a99cd1 gc+thinlto_defconfig/vmlinux > > > 15759453 10532792 502395 26794640 198da90 > > > gc+thinlto+trim_defconfig/vmlinux > > > > > > > Thanks for the numbers. > > Does CONFIG_TRIM_UNUSED_KSYMS=y have an impact to the build-time (and > > disc-usage - negative way means longer/bigger)? > > Do you have any build-time for the above numbers? > > They are in the mailing list archive I linked to: > > defconfig > 332.001786355 seconds time elapsed > 8599.464163000 seconds user > 676.919635000 seconds sys > trim_defconfig > 448.378576012 seconds time elapsed >10735.489271000 seconds user > 964.006504000 seconds sys > gc_defconfig > 324.347492236 seconds time elapsed > 8465.78580 seconds user > 614.899797000 seconds sys > gc+trim_defconfig > 429.188875620 seconds time elapsed >10203.759658000 seconds user > 871.307973000 seconds sys > thinlto_defconfig > 389.793540200 seconds time elapsed > 9491.66532 seconds user > 664.858109000 seconds sys > thinlto+trim_defconfig > 580.431820561 seconds time elapsed >11429.515538000 seconds user > 1056.985745000 seconds sys > gc+thinlto_defconfig > 389.484364525 seconds time elapsed > 9473.83198 seconds user > 675.057675000 seconds sys > gc+thinlto+trim_defconfig > 580.824912807 seconds time elapsed >11433.650337000 seconds user > 1049.845569000 seconds sys > Thanks for the numbers Arnd. > So HAVE_LD_DEAD_CODE_DATA_ELIMINATION is a small improvement > on build time (since it can spend less time linking), while > CONFIG_TRIM_UNUSED_KSYMS slows it down quite a bit. Combining > CONFIG_TRIM_UNUSED_KSYMS with CONFIG_THINLTO is really > slow because here most of the time is spent in the final link (especially > when you have many CPU cores to do the earlier bits quickly), but then > it does the link twice. > My first pre-v5.12-rc1 kernel-build was with Clang-ThinLTO enabled. But with the next ones I jumped to Sami's Clang-CFI. > > BTW, is CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y setable for x86 (64bit)? > > ( Did not look or check for it. ) > > No, in mainline, HAVE_LD_DEAD_CODE_DATA_ELIMINATION is currently > only selected on MIPS and PowerPC. I only sent experimental patches to > enable it on arm64 and m68k, but have not tried booting them. If you > select the symbol on x86, you should see similar results. > OK, i see: $ git grep HAVE_LD_DEAD_CODE_DATA_ELIMINATION arch/mips/ arch/mips/Kconfig: select HAVE_LD_DEAD_CODE_DATA_ELIMINATION $ git grep HAVE_LD_DEAD_CODE_DATA_ELIMINATION arch/powerpc/ arch/powerpc/Kconfig: select HAVE_LD_DEAD_CODE_DATA_ELIMINATION So, I need to add this to arch/x86/Kconfig. You happen to know if changes to arch/x86/kernel/vmlinux.lds.S (sections) are needed? Last question: The last days I see a lot of fixes touching inlining with LLVM/Clang v13-git. What git tag are you using? What are your experiences? Pending patches (kernel-side)? I use: $ /opt/llvm-toolchain/bin/clang --version dileks clang version 13.0.0 (https://github.com/llvm/llvm-project.git c465429f286f50e52a8d2b3b39f38344f3381cce) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /opt/llvm-toolchain/bin My LLVM toolchain is ThinLTO+PGO optimized for Linux-kernel builds. - Sedat -
Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
On Thu, Feb 25, 2021 at 12:21 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> When looking at kernel size optimizations, I found that arm64
> does not currently support HAVE_LD_DEAD_CODE_DATA_ELIMINATION,
> which enables the --gc-sections flag to the linker.
>
> I see that for a defconfig build with llvm, there are some
> notable improvements from enabling this, in particular when
> combined with the recently added CONFIG_LTO_CLANG_THIN
> and CONFIG_TRIM_UNUSED_KSYMS:
>
>textdata bss dec hex filename
> 16570322 10998617 506468 28075407 1ac658f defconfig/vmlinux
> 16318793 10569913 506468 27395174 1a20466 trim_defconfig/vmlinux
> 16281234 10984848 504291 27770373 1a7be05 gc_defconfig/vmlinux
> 16029705 10556880 504355 27090940 19d5ffc gc+trim_defconfig/vmlinux
> 17040142 11102945 504196 28647283 1b51f73 thinlto_defconfig/vmlinux
> 16788613 10663201 504196 27956010 1aa932a thinlto+trim_defconfig/vmlinux
> 16347062 11043384 502499 27892945 1a99cd1 gc+thinlto_defconfig/vmlinux
> 15759453 10532792 502395 26794640 198da90 gc+thinlto+trim_defconfig/vmlinux
>
Thanks for the numbers.
Does CONFIG_TRIM_UNUSED_KSYMS=y have an impact to the build-time (and
disc-usage - negative way means longer/bigger)?
Do you have any build-time for the above numbers?
BTW, is CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y setable for x86 (64bit)?
( Did not look or check for it. )
- Sedat -
> I needed a small change to the linker script to get clean randconfig
> builds, but I have not done any meaningful boot testing on it to
> see if it works. If there are no regressions, I wonder whether this
> should be autmatically done for LTO builds, given that it improves
> both kernel size and compile speed.
>
> Link:
> https://lore.kernel.org/lkml/cak8p3a05vz9hskrzvtxtn+1nf9e+gqebjwtj6n23nfm+elh...@mail.gmail.com/
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/vmlinux.lds.S | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b94a678afce4..75e13cc52928 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2,6 +2,7 @@
> config ARM64
> def_bool y
> select ACPI_CCA_REQUIRED if ACPI
> + select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> select ACPI_GENERIC_GSI if ACPI
> select ACPI_GTDT if ACPI
> select ACPI_IORT if ACPI
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index bad2b9eaab22..926cdb597a45 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -217,7 +217,7 @@ SECTIONS
> INIT_CALLS
> CON_INITCALL
> INIT_RAM_FS
> - *(.init.altinstructions .init.bss .init.bss.*) /* from the
> EFI stub */
> + *(.init.altinstructions .init.data.* .init.bss .init.bss.*)
> /* from the EFI stub */
> }
> .exit.data : {
> EXIT_DATA
> --
> 2.29.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/20210225112122.2198845-1-arnd%40kernel.org.
Re: [PATCH v9 0/3] Kbuild: DWARF v5 support
On Fri, Feb 5, 2021 at 9:22 PM Nick Desaulniers wrote: > > DWARF v5 is the latest standard of the DWARF debug info format. > > DWARF5 wins significantly in terms of size and especially so when mixed > with compression (CONFIG_DEBUG_INFO_COMPRESSED). > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf > Accepted into mainline via kbuild-v5.12. - Sedat - [1] https://git.kernel.org/linus/6fbd6cf85a3be127454a1ad58525a3adcf8612ab > Patch 1 places the DWARF v5 sections explicitly in the kernel linker > script. > Patch 2 modifies Kconfig for DEBUG_INFO_DWARF4 to be used as a fallback. > Patch 3 adds an explicit Kconfig for DWARF v5 for clang and older GCC > where the implicit default DWARF version is not 5. > > Changes from v8: > * Separate out the linker script changes (from v7 0002). Put those > first. Carry Reviewed by and tested by tags. Least contentious part > of the series. Tagged for stable; otherwise users upgrading to GCC 11 > may find orphan section warnings from the implicit default DWARF > version changing and generating the new debug info sections. > * Add CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT in 0002, make it the > default rather than CONFIG_DEBUG_INFO_DWARF4, as per Mark, Jakub, > Arvind. > * Drop reviewed by and tested by tags for 0002 and 0003; sorry > reviewers/testers, but I view that as a big change. I will buy you > beers if you're fatigued, AND for the help so far. I appreciate you. > * Rework commit one lines, and commit messages somewhat. > * Remove Kconfig help text about v4 being "bigger." > * I didn't touch the BTF config from v8, but suggest the BTF folks > consider > > https://lore.kernel.org/bpf/2021080609.713998-1-natechancel...@gmail.com/ > that way we can express via Kconfig that older version of pahole are > in conflict with other Kconfig options. > > Changes from v7: > (Strictly commit message changes) > * Pick up Nathan's reviewed by tags for both patches. > * Add note about only modifying compiler dwarf info, not assembler dwarf > info, as per Nathan. > * Add link to Red Hat bug report and Chris' reported by on patch 2. > * Add more info from Jakub on patch 2 commit message. > * Reorder info about validating version, noting the tree is not "clean" > in the sense that parts mess up existing CFLAGS, or don't use > DEBUG_CFLAGS. I will not be adding such cleanups to this series. They > can be done AFTER. > * Update note about 2.35.2 (rather than include the full text Jakub > wrote on it in > https://patchwork.kernel.org/project/linux-kbuild/patch/20201022012106.1875129-1-ndesaulni...@google.com/#23727667). > * Add note that GCC 11 has changed the implicit default version. > > Changes from v6: > * Reorder sections from linker script to match order from BFD's internal > linker script. > * Add .debug_names section, as per Fangrui. > * Drop CONFIG_DEBUG_INFO_DWARF2. Patch 0001 becomes a menu with 1 > choice. GCC's implicit default version of DWARF has been DWARF v4 > since ~4.8. > * Modify the test script to check for the presence of > https://sourceware.org/bugzilla/show_bug.cgi?id=27195. > * Drop the clang without integrated assembler block in > 0002. Bumps the version requirement for GAS to 2.35.2, which isn't > released yet (but should be released soon). Folks looking to test > with clang but without the integrated assembler should fetch > binutils-gdb, build it from source, add a symlink to > binutils-gdb/gas/as-new to binutils-gdb/gas/as, then prefix > binutils-gdb/gas/as to their $PATH when building the kernel. > > Changes from v5: > * Drop previous patch 1, it has been accepted into kbuild: > > https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44 > * Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of > additional complexity. Drop it that part of the patch. We can revisit > clang without the integrated assembler setting -Wa,-gdwarf-4 later. > That is a separate problem from generally supporting DWARF v5. > * Rework the final patch for clang without the integrated assembler. > -Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will > not accept the assembler directives clang produces from C code when > generating asm. > > Changes from v4: > * drop set -e from script as per Nathan. > * add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat. > * Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and > Masahiro. Sorry it took me a few tries to understand the point (I > might still not), but it looks much cleaner this way. Sorry Nathan, I > did not carry forward your previous reviews as a result, but I would > appreciate if you could look again. > * Add Nathan's reviewed by tag to patch 1. > * Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5 > binutils addition later, and BTF issue. > * I still happen to see a pahole related error spew
Re: [PATCH] perf tools: Move feature cleanup under tools/build
On Wed, Feb 24, 2021 at 4:38 PM Jiri Olsa wrote:
>
> Arnaldo reported issue for following build command:
>
> $ rm -rf /tmp/krava; mkdir /tmp/krava; make O=/tmp/krava clean
> CLEANconfig
> /bin/sh: line 0: cd: /tmp/krava/feature/: No such file or directory
> ../../scripts/Makefile.include:17: *** output directory
> "/tmp/krava/feature/" does not exist. Stop.
> make[1]: *** [Makefile.perf:1010: config-clean] Error 2
> make: *** [Makefile:90: clean] Error 2
>
> The problem is that now that we include scripts/Makefile.include
> in feature's Makefile (which is fine and needed), we need to ensure
> the OUTPUT directory exists, before executing (out of tree) clean
> command.
>
> Removing the feature's cleanup from perf Makefile and fixing
> feature's cleanup under build Makefile, so it now checks that
> there's existing OUTPUT directory before calling the clean.
>
> Cc: Sedat Dilek
For my new friends from linux-bpf and linux-perf...
I tested your patch on top of Linux v5.11-10201-gc03c21ba6f4e.
git checkout c03c21ba6f4e -b for-5.12/perf-tools_feature_cleanup-jolsa
git branch --show-current
link="https://lore.kernel.org/r/20210224150831.409639-1-jo...@kernel.org;
b4 am $link -o - | git am
LLVM_TOOLCHAIN_PATH="/opt/llvm-toolchain/bin"
if [ -d ${LLVM_TOOLCHAIN_PATH} ]; then
export PATH="${LLVM_TOOLCHAIN_PATH}:${PATH}"
fi
echo $PATH
MAKE="make V=1"
MAKE_OPTS="HOSTCC=clang HOSTCXX=clang++ HOSTLD=ld.lld CC=clang
LD=ld.lld LLVM=1 LLVM_IAS=1"
MAKE_OPTS="$MAKE_OPTS PAHOLE=/opt/pahole/bin/pahole"
echo $MAKE $MAKE_OPTS
LC_ALL=C $MAKE -j1 $MAKE_OPTS -C tools/ clean 2>&1 | tee
../make-log_tools-clean_before-perf-build.txt
LC_ALL=C PYTHON=python3 $MAKE -j4 $MAKE_OPTS -C tools/perf/ 2>&1 | tee
../make-log_tools-perf.txt
grep gcc ../make-log_tools-perf.txt
[ empty ]
LC_ALL=C $MAKE -j1 $MAKE_OPTS -C tools/ clean 2>&1 | tee
../make-log_tools-clean_after-perf-build.txt
$ clang --version
dileks clang version 13.0.0 (https://github.com/llvm/llvm-project.git
c465429f286f50e52a8d2b3b39f38344f3381cce)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm-toolchain/bin
Logs etc. see attached tarball.
Feel free to add:
Tested-by: Sedat Dilek # LLVM/Clang v13-git
- Sedat -
> Fixes: 211a741cd3e1 ("tools: Factor Clang, LLC and LLVM utils definitions")
> Reported-by: Arnaldo Carvalho de Melo
> Signed-off-by: Jiri Olsa
> ---
> tools/build/Makefile | 8 +++-
> tools/perf/Makefile.perf | 10 +-
> 2 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/tools/build/Makefile b/tools/build/Makefile
> index bae48e6fa995..5ed41b96fcde 100644
> --- a/tools/build/Makefile
> +++ b/tools/build/Makefile
> @@ -30,12 +30,18 @@ build := -f $(srctree)/tools/build/Makefile.build
> dir=. obj
>
> all: $(OUTPUT)fixdep
>
> +# Make sure there's anything to clean,
> +# feature contains check for existing OUTPUT
> +TMP_O := $(if $(OUTPUT),$(OUTPUT)/feature,./)
> +
> clean:
> $(call QUIET_CLEAN, fixdep)
> $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name
> '\.*.cmd' -delete -o -name '\.*.d' -delete
> $(Q)rm -f $(OUTPUT)fixdep
> $(call QUIET_CLEAN, feature-detect)
> - $(Q)$(MAKE) -C feature/ clean >/dev/null
> +ifneq ($(wildcard $(TMP_O)),)
> + $(Q)$(MAKE) -C feature OUTPUT=$(TMP_O) clean >/dev/null
> +endif
>
> $(OUTPUT)fixdep-in.o: FORCE
> $(Q)$(MAKE) $(build)=fixdep
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 5345ac70cd83..536f6f90af92 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -1001,14 +1001,6 @@ $(INSTALL_DOC_TARGETS):
>
> ### Cleaning rules
>
> -#
> -# This is here, not in Makefile.config, because Makefile.config does
> -# not get included for the clean target:
> -#
> -config-clean:
> - $(call QUIET_CLEAN, config)
> - $(Q)$(MAKE) -C $(srctree)/tools/build/feature/ $(if
> $(OUTPUT),OUTPUT=$(OUTPUT)feature/,) clean >/dev/null
> -
> python-clean:
> $(python-clean)
>
> @@ -1048,7 +1040,7 @@ endif # BUILD_BPF_SKEL
> bpf-skel-clean:
> $(call QUIET_CLEAN, bpf-skel) $(RM) -r $(SKEL_TMP_OUT) $(SKELETONS)
>
> -clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean
> $(LIBSUBCMD)-clean $(LIBPERF)-clean config-clean fixdep-clean python-clean
> bpf-skel-clean
> +clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean
> $(LIBSUBCMD)-clean $(LIBPERF)-clean fixdep-clean python-clean bpf-skel-clean
> $(call QUIET_CLEAN, core-objs) $(RM) $(LIBPERF_A)
> $(OUTPUT)perf-archive $(OUTPUT)perf-with-kcore $(LANG_BINDINGS)
> $(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name
> '\.*.cmd' -delete -o -name '\.*.d' -delete
> $(Q)$(RM) $(OUTPUT).config-detected
> --
> 2.29.2
>
for-linux-bpf.tar.zst
Description: application/zstd
for-linux-bpf.tar.zst.sha256
Description: Binary data
Re: [PATCH] qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute
On Thu, Feb 11, 2021 at 9:41 PM 'Sami Tolvanen' via Clang Built Linux
wrote:
>
> Hi Nathan,
>
> On Thu, Feb 11, 2021 at 11:43 AM Nathan Chancellor wrote:
> >
> > fw_cfg_showrev() is called by an indirect call in kobj_attr_show(),
> > which violates clang's CFI checking because fw_cfg_showrev()'s second
> > parameter is 'struct attribute', whereas the ->show() member of 'struct
> > kobj_structure' expects the second parameter to be of type 'struct
> > kobj_attribute'.
> >
> > $ cat /sys/firmware/qemu_fw_cfg/rev
> > 3
> >
> > $ dmesg | grep "CFI failure"
> > [ 26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8):
> >
> > Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where
> > this would have been caught automatically by the incompatible pointer
> > types compiler warning. Update fw_cfg_showrev() accordingly.
> >
> > Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg
> > device")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1299
> > Signed-off-by: Nathan Chancellor
>
> Looks good to me. Thank you for sending the patch!
>
> Reviewed-by: Sami Tolvanen
>
Environment: Linux v5.11-10201-gc03c21ba6f4e plus Clang-CFI as of
24-Feb-2021 on top built with LLVM v13-git.
Tested-by: Sedat Dilek
- Sedat -
Re: [PATCH] drm/amd/pm/swsmu: Avoid using structure_size uninitialized in smu_cmn_init_soft_gpu_metrics
On Thu, Feb 18, 2021 at 11:49 PM Nathan Chancellor wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:764:2: warning:
> variable 'structure_size' is used uninitialized whenever switch default
> is taken [-Wsometimes-uninitialized]
> default:
> ^~~
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:770:23: note:
> uninitialized use occurs here
> memset(header, 0xFF, structure_size);
> ^~
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:753:25: note:
> initialize the variable 'structure_size' to silence this warning
> uint16_t structure_size;
>^
> = 0
> 1 warning generated.
>
> Return in the default case, as the size of the header will not be known.
>
> Fixes: de4b7cd8cb87 ("drm/amd/pm/swsmu: unify the init soft gpu metrics
> function")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1304
> Signed-off-by: Nathan Chancellor
I fell over this today with Linux v5.11-10201-gc03c21ba6f4e.
Tested-by: Sedat Dilek # LLVM/Clang v13-git
- Sedat -
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> index bb620fdd4cd2..bcedd4d92e35 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c
> @@ -762,7 +762,7 @@ void smu_cmn_init_soft_gpu_metrics(void *table, uint8_t
> frev, uint8_t crev)
> structure_size = sizeof(struct gpu_metrics_v2_0);
> break;
> default:
> - break;
> + return;
> }
>
> #undef METRICS_VERSION
> --
> 2.30.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/20210218224849.5591-1-nathan%40kernel.org.
Re: [xhci] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
On Wed, Feb 24, 2021 at 2:44 PM Sedat Dilek wrote: > > Hi Mathias, > > I am here on Linux-v5.11-10201-gc03c21ba6f4e. > > I see a lot xhci-resets in my dmesg-log: > > root# LC_ALL=C dmesg -T | grep 'usb 4-1: reset SuperSpeed Gen 1 USB > device number 2 using xhci_hcd' | wc -l > 75 > > This is what I have: > > root# lsusb -s 004:001 > Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > > root# lsusb -s 004:002 > Bus 004 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA > 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, > ASM1153E SATA 6Gb/s bridge > > My external USB 3.0 HDD contains the partition with my Debian-system > and is attached to the above xhci bus/device. > > Can you enlighten what this means? > Is this a known issue? > Is there a fix around? > > BTW, in which Git tree is the xhci development happening? > Can you point me to it? > > I am attaching my linux-config and full dmesg-log. > > Also I have attached outputs of: > > $ sudo lsusb -vvv -d 1d6b:0003 > $ sudo lsusb -vvv -d 174c:55aa > > If you need further information, please let me know. > > Thanks. > Looks like that xhci-reset happens here every 10min. - Sedat -
Re: clang-12: i386: Unsupported relocation type: R_386_PLT32 (4)
On Mon, Feb 22, 2021 at 5:30 PM Naresh Kamboju
wrote:
>
> On Mon, 22 Feb 2021 at 21:44, Sedat Dilek wrote:
> >
> > On Mon, Feb 22, 2021 at 5:08 PM Naresh Kamboju
> > wrote:
> > >
> > > While building i386 configs on stable-rc 5.10, stable-rc 5.11 branch
> > > and mainline
> > > with clang-12 these following warnings and errors were noticed.
> > >
> >
> > Hi Naresh,
> >
> > Please see commit bb73d07148c405c293e576b40af37737faf23a6a
> > ("x86/build: Treat R_386_PLT32 relocation as R_386_PC32").
> > Recently accepted into Linus Git tree.
>
> Can this be backported / cherry-picked into stable-rc 5.10 and stable-rc 5.11
> ?
>
I have this one in my custom patchset (even though I only build x86-64).
Makes sense to have it in Linux v5.10.y LTS and Linux v5.11.y and
maybe other linux-stable releases.
The usual way to get a fix into linux-stable is to contact Greg and
Sasha - the Linux-stable maintainers and ask for inclusion.
See "STABLE BRANCH" in MAINTAINERS.
But we have also LLVM/Clang maintainers (see [2]).
Cannot say if you address LLVM/Clang maintainers first... and they
help or what is the recommended/ideal way.
- Sedat -
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS/?h=v5.11#n16828
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS/?h=v5.11#n4306
> >
> > [1] says:
> >
> > Further info for the more interested:
> >
> > https://github.com/ClangBuiltLinux/linux/issues/1210
> > https://sourceware.org/bugzilla/show_bug.cgi?id=27169
> >
> > https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de008232da3f1d6
> >
> > Hope that helps.
> >
> > - Sedat -
> >
> > [1] https://git.kernel.org/linus/bb73d07148c405c293e576b40af37737faf23a6a
> >
> > > make --silent --keep-going --jobs=8
> > > O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=i386
> > > CROSS_COMPILE=i686-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
> > > clang'
> > >
> > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2586:9: warning: shift
> > > count >= width of type [-Wshift-count-overflow]
> > >
> > > return hweight64(VDBOX_MASK(>gt));
> > >^~~~
> > > include/asm-generic/bitops/const_hweight.h:29:49: note: expanded from
> > > macro 'hweight64'
> > > #define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) :
> > > __arch_hweight64(w))
> > > ^~~~
> > > include/asm-generic/bitops/const_hweight.h:21:76: note: expanded from
> > > macro '__const_hweight64'
> > > #define __const_hweight64(w) (__const_hweight32(w) +
> > > __const_hweight32((w) >> 32))
> > >
> > > ^ ~~
> > > include/asm-generic/bitops/const_hweight.h:20:49: note: expanded from
> > > macro '__const_hweight32'
> > > #define __const_hweight32(w) (__const_hweight16(w) +
> > > __const_hweight16((w) >> 16))
> > > ^
> > > include/asm-generic/bitops/const_hweight.h:19:48: note: expanded from
> > > macro '__const_hweight16'
> > > #define __const_hweight16(w) (__const_hweight8(w) +
> > > __const_hweight8((w) >> 8 ))
> > >^
> > > include/asm-generic/bitops/const_hweight.h:10:9: note: expanded from
> > > macro '__const_hweight8'
> > > ((!!((w) & (1ULL << 0))) + \
> > >^
> > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2586:9: warning: shift
> > > count >= width of type [-Wshift-count-overflow]
> > > return hweight64(VDBOX_MASK(>gt));
> > >^~~~
> > >
> > >
> > > 32 warnings generated.
> > > Unsupported relocation type: R_386_PLT32 (4)
> > > make[3]: *** [arch/x86/boot/compressed/Makefile:116:
> > > arch/x86/boot/compressed/vmlinux.relocs] Error 1
> > > make[3]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
> > > make[3]: Target 'arch/x86/boot/compressed/vmlinux' not remade because of
> > > errors.
> > >
> > > Reported-by: Naresh Kamboju
> > >
> > > Steps to reproduce:
> > > ---
> > > # TuxMake is a command line tool and P
Re: clang-12: i386: Unsupported relocation type: R_386_PLT32 (4)
On Mon, Feb 22, 2021 at 5:08 PM Naresh Kamboju
wrote:
>
> While building i386 configs on stable-rc 5.10, stable-rc 5.11 branch
> and mainline
> with clang-12 these following warnings and errors were noticed.
>
Hi Naresh,
Please see commit bb73d07148c405c293e576b40af37737faf23a6a
("x86/build: Treat R_386_PLT32 relocation as R_386_PC32").
Recently accepted into Linus Git tree.
[1] says:
Further info for the more interested:
https://github.com/ClangBuiltLinux/linux/issues/1210
https://sourceware.org/bugzilla/show_bug.cgi?id=27169
https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de008232da3f1d6
Hope that helps.
- Sedat -
[1] https://git.kernel.org/linus/bb73d07148c405c293e576b40af37737faf23a6a
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=i386
> CROSS_COMPILE=i686-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
> clang'
>
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2586:9: warning: shift
> count >= width of type [-Wshift-count-overflow]
>
> return hweight64(VDBOX_MASK(>gt));
>^~~~
> include/asm-generic/bitops/const_hweight.h:29:49: note: expanded from
> macro 'hweight64'
> #define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) :
> __arch_hweight64(w))
> ^~~~
> include/asm-generic/bitops/const_hweight.h:21:76: note: expanded from
> macro '__const_hweight64'
> #define __const_hweight64(w) (__const_hweight32(w) +
> __const_hweight32((w) >> 32))
>^
> ~~
> include/asm-generic/bitops/const_hweight.h:20:49: note: expanded from
> macro '__const_hweight32'
> #define __const_hweight32(w) (__const_hweight16(w) +
> __const_hweight16((w) >> 16))
> ^
> include/asm-generic/bitops/const_hweight.h:19:48: note: expanded from
> macro '__const_hweight16'
> #define __const_hweight16(w) (__const_hweight8(w) +
> __const_hweight8((w) >> 8 ))
>^
> include/asm-generic/bitops/const_hweight.h:10:9: note: expanded from
> macro '__const_hweight8'
> ((!!((w) & (1ULL << 0))) + \
>^
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2586:9: warning: shift
> count >= width of type [-Wshift-count-overflow]
> return hweight64(VDBOX_MASK(>gt));
>^~~~
>
>
> 32 warnings generated.
> Unsupported relocation type: R_386_PLT32 (4)
> make[3]: *** [arch/x86/boot/compressed/Makefile:116:
> arch/x86/boot/compressed/vmlinux.relocs] Error 1
> make[3]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
> make[3]: Target 'arch/x86/boot/compressed/vmlinux' not remade because of
> errors.
>
> Reported-by: Naresh Kamboju
>
> Steps to reproduce:
> ---
> # TuxMake is a command line tool and Python library that provides
> # portable and repeatable Linux kernel builds across a variety of
> # architectures, toolchains, kernel configurations, and make targets.
> #
> # TuxMake supports the concept of runtimes.
> # See https://docs.tuxmake.org/runtimes/, for that to work it requires
> # that you install podman or docker on your system.
> #
> # To install tuxmake on your system globally:
> # sudo pip3 install -U tuxmake
> #
> # See https://docs.tuxmake.org/ for complete documentation.
>
> tuxmake --runtime podman --target-arch i386 --toolchain clang-12
> --kconfig defconfig --kconfig-add
> https://builds.tuxbuild.com/1opxSKxZuRowPsiOsSJ0IoUOXOt/config
>
> --
> Linaro LKFT
> https://lkft.linaro.org
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/CA%2BG9fYtNOZ-G_RTq_Uedy-7wkFog2q%2BOWNbWd--eL%2Bi2-OQ7NA%40mail.gmail.com.
Re: [PATCH v2 1/2] x86/stackprotector/32: Make the canary into a regular percpu variable
On Tue, Feb 16, 2021 at 7:45 PM Nick Desaulniers wrote: > > On Sat, Feb 13, 2021 at 11:19 AM Andy Lutomirski wrote: > > > > On 32-bit kernels, the stackprotector canary is quite nasty -- it is > > stored at %gs:(20), which is nasty because 32-bit kernels use %fs for > > percpu storage. It's even nastier because it means that whether %gs > > contains userspace state or kernel state while running kernel code > > depends on whether stackprotector is enabled (this is > > CONFIG_X86_32_LAZY_GS), and this setting radically changes the way > > that segment selectors work. Supporting both variants is a > > maintenance and testing mess. > > > > Merely rearranging so that percpu and the stack canary > > share the same segment would be messy as the 32-bit percpu address > > layout isn't currently compatible with putting a variable at a fixed > > offset. > > > > Fortunately, GCC 8.1 added options that allow the stack canary to be > > accessed as %fs:__stack_chk_guard, effectively turning it into an ordinary > > percpu variable. This lets us get rid of all of the code to manage the > > stack canary GDT descriptor and the CONFIG_X86_32_LAZY_GS mess. > > > > (That name is special. We could use any symbol we want for the > > %fs-relative mode, but for CONFIG_SMP=n, gcc refuses to let us use any > > name other than __stack_chk_guard.) > > > > This patch forcibly disables stackprotector on older compilers that > > don't support the new options and makes the stack canary into a > > percpu variable. The "lazy GS" approach is now used for all 32-bit > > configurations. > > > > This patch also makes load_gs_index() work on 32-bit kernels. On > > 64-bit kernels, it loads the GS selector and updates the user > > GSBASE accordingly. (This is unchanged.) On 32-bit kernels, > > it loads the GS selector and updates GSBASE, which is now > > always the user base. This means that the overall effect is > > the same on 32-bit and 64-bit, which avoids some ifdeffery. > > > > Cc: Sedat Dilek > > Cc: Nick Desaulniers > > Signed-off-by: Andy Lutomirski > > --- > > arch/x86/Kconfig | 7 +- > > arch/x86/Makefile | 8 +++ > > arch/x86/entry/entry_32.S | 56 ++-- > > arch/x86/include/asm/processor.h | 15 ++--- > > arch/x86/include/asm/ptrace.h | 5 +- > > arch/x86/include/asm/segment.h| 30 +++-- > > arch/x86/include/asm/stackprotector.h | 79 +-- > > arch/x86/include/asm/suspend_32.h | 6 +- > > arch/x86/kernel/asm-offsets_32.c | 5 -- > > arch/x86/kernel/cpu/common.c | 5 +- > > arch/x86/kernel/doublefault_32.c | 4 +- > > arch/x86/kernel/head_32.S | 18 +- > > arch/x86/kernel/setup_percpu.c| 1 - > > arch/x86/kernel/tls.c | 8 +-- > > arch/x86/kvm/svm/svm.c| 10 +-- > > arch/x86/lib/insn-eval.c | 4 -- > > arch/x86/platform/pvh/head.S | 14 > > arch/x86/power/cpu.c | 6 +- > > arch/x86/xen/enlighten_pv.c | 1 - > > scripts/gcc-x86_32-has-stack-protector.sh | 6 +- > > 20 files changed, 62 insertions(+), 226 deletions(-) > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 21f851179ff0..12d8bf011d08 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -353,10 +353,6 @@ config X86_64_SMP > > def_bool y > > depends on X86_64 && SMP > > > > -config X86_32_LAZY_GS > > - def_bool y > > - depends on X86_32 && !STACKPROTECTOR > > - > > config ARCH_SUPPORTS_UPROBES > > def_bool y > > > > @@ -379,7 +375,8 @@ config CC_HAS_SANE_STACKPROTECTOR > > default > > $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC)) > > help > >We have to make sure stack protector is unconditionally disabled > > if > > - the compiler produces broken code. > > + the compiler produces broken code or if it does not let us > > control > > + the segment on 32-bit kernels. > > > > menu "Processor type and features" > > > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > > index 7116da3980be..0b5cd8c49ccb 100644 > > --- a/arch/x86/Makefile > > +++ b/arch/x86/Makefile > > @@ -76,6 +76,14 @@ ifeq
Re: [PATCH v2 1/2] x86/stackprotector/32: Make the canary into a regular percpu variable
On Tue, Feb 16, 2021 at 5:21 PM Sean Christopherson wrote:
>
> On Sat, Feb 13, 2021, Andy Lutomirski wrote:
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index f923e14e87df..ec39073b4897 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -1467,12 +1467,8 @@ static void svm_vcpu_put(struct kvm_vcpu *vcpu)
> > #ifdef CONFIG_X86_64
> > loadsegment(fs, svm->host.fs);
> > wrmsrl(MSR_KERNEL_GS_BASE, current->thread.gsbase);
> > - load_gs_index(svm->host.gs);
> > -#else
> > -#ifdef CONFIG_X86_32_LAZY_GS
> > - loadsegment(gs, svm->host.gs);
> > -#endif
>
> This manually GS crud is gone as of commit e79b91bb3c91 ("KVM: SVM: use
> vmsave/vmload for saving/restoring additional host state"), which is queued
> for
> 5.12.
>
Link to the above KVM patch see [1].
As said the base for this patchset should be changed - for example it
conflicts with [2].
Maybe wait for Linux v5.12-rc1?
- Sedat -
[1]
https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=tags/kvm-5.12-1=e79b91bb3c916a52ce823ab60489c717c925c49f
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tag/?h=x86-entry-2021-02-15
> > #endif
> > + load_gs_index(svm->host.gs);
> >
> > for (i = 0; i < NR_HOST_SAVE_USER_MSRS; i++)
> > wrmsrl(host_save_user_msrs[i].index,
> > @@ -3705,13 +3701,11 @@ static noinstr void svm_vcpu_enter_exit(struct
> > kvm_vcpu *vcpu,
> > } else {
> > __svm_vcpu_run(svm->vmcb_pa, (unsigned long
> > *)>vcpu.arch.regs);
> >
> > + /* Restore the percpu segment immediately. */
> > #ifdef CONFIG_X86_64
> > native_wrmsrl(MSR_GS_BASE, svm->host.gs_base);
> > #else
> > loadsegment(fs, svm->host.fs);
> > -#ifndef CONFIG_X86_32_LAZY_GS
> > - loadsegment(gs, svm->host.gs);
> > -#endif
> > #endif
> > }
Re: Linux 5.8-rc6
On Mon, Aug 10, 2020 at 5:30 PM Geert Uytterhoeven wrote:
>
> Hi Sedat,
>
> On Tue, Jul 21, 2020 at 10:19 AM Sedat Dilek wrote:
> > You happen to know if I can configure in my ~/.gitconfig to pull
> > linux-git stuff from two repositories - check first git.kernel.org
> > then GitHub.
> >
> > Some days ago GitHub had some maintenance issues and I was not able to pull.
> > Means I trust more the security and integrity concept of git.kernel.org.
> >
> > To pull from GitHub - saved 15-16mins of my life-time - meant
> > 15-16mins go earlier to sleep - as said I started my build 01:02a.m.
> > (German local-time).
>
> Assumed your cloned from kernel.org:
>
> git remote add github https://github.com/torvalds/linux
>
> After that:
> 1. "git remote update" will fetch data from both origin and github,
> 2. "git merge $(git tag | grep -v rc | sort -n | tail -1)" will
> merge in the latest release, if you don't have it merged already.
>
Last week or so I really used your recommendation.
Thanks Geert.
- Sedat -
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH v2 0/2] Clean up x86_32 stackprotector
On Sat, Feb 13, 2021 at 8:19 PM Andy Lutomirski wrote: > > x86_32 stackprotector is a maintenance nightmare. Clean it up. This > disables stackprotector on x86_32 on GCC 8.1 and on all clang > versions. Some clang people are cc'd. > > Changes from v1: > - Changelog fixes. > - Comment fixes (mostly from Sean). > - Fix the !SMP case. > > Andy Lutomirski (2): > x86/stackprotector/32: Make the canary into a regular percpu variable > x86/entry/32: Remove leftover macros after stackprotector cleanups > Happy Valentine's Day, I have no rose or pralines for you, Andy :-). First, I tried to apply your patchset on top of which has shown some conflicts. AFAICS it conflicts with (or more precisely with the recent "Merge branch 'x86/paravirt' into x86/entry"). Just wanna let you know. I have tested this on Debian/testing AMD64 (x86 64bit) with LLVM/Clang v12.0.0-rc1 and my custom patchset. Means compile-tested and booted into bare metal and checked build-log and dmesg-log for warnings. So far nothing scary. Feel free to give credits like a Tested-by if you like. ( Roses and pralines are welcome, too, hahaha :-). ) Icecold and sunshiny Greetings from North-West Germany, - Sedat - > arch/x86/Kconfig | 7 +- > arch/x86/Makefile | 8 ++ > arch/x86/entry/entry_32.S | 95 +-- > arch/x86/include/asm/processor.h | 15 +--- > arch/x86/include/asm/ptrace.h | 5 +- > arch/x86/include/asm/segment.h| 30 ++- > arch/x86/include/asm/stackprotector.h | 79 --- > arch/x86/include/asm/suspend_32.h | 6 +- > arch/x86/kernel/asm-offsets_32.c | 5 -- > arch/x86/kernel/cpu/common.c | 5 +- > arch/x86/kernel/doublefault_32.c | 4 +- > arch/x86/kernel/head_32.S | 18 + > arch/x86/kernel/setup_percpu.c| 1 - > arch/x86/kernel/tls.c | 8 +- > arch/x86/kvm/svm/svm.c| 10 +-- > arch/x86/lib/insn-eval.c | 4 - > arch/x86/platform/pvh/head.S | 14 > arch/x86/power/cpu.c | 6 +- > arch/x86/xen/enlighten_pv.c | 1 - > scripts/gcc-x86_32-has-stack-protector.sh | 6 +- > 20 files changed, 62 insertions(+), 265 deletions(-) > > -- > 2.29.2 >
Re: [PATCH v2 1/2] x86/stackprotector/32: Make the canary into a regular percpu variable
On Sat, Feb 13, 2021 at 8:19 PM Andy Lutomirski wrote: > > On 32-bit kernels, the stackprotector canary is quite nasty -- it is > stored at %gs:(20), which is nasty because 32-bit kernels use %fs for > percpu storage. It's even nastier because it means that whether %gs > contains userspace state or kernel state while running kernel code > depends on whether stackprotector is enabled (this is > CONFIG_X86_32_LAZY_GS), and this setting radically changes the way > that segment selectors work. Supporting both variants is a > maintenance and testing mess. > > Merely rearranging so that percpu and the stack canary > share the same segment would be messy as the 32-bit percpu address > layout isn't currently compatible with putting a variable at a fixed > offset. > > Fortunately, GCC 8.1 added options that allow the stack canary to be > accessed as %fs:__stack_chk_guard, effectively turning it into an ordinary > percpu variable. This lets us get rid of all of the code to manage the > stack canary GDT descriptor and the CONFIG_X86_32_LAZY_GS mess. > > (That name is special. We could use any symbol we want for the > %fs-relative mode, but for CONFIG_SMP=n, gcc refuses to let us use any > name other than __stack_chk_guard.) > > This patch forcibly disables stackprotector on older compilers that > don't support the new options and makes the stack canary into a > percpu variable. The "lazy GS" approach is now used for all 32-bit > configurations. > > This patch also makes load_gs_index() work on 32-bit kernels. On > 64-bit kernels, it loads the GS selector and updates the user > GSBASE accordingly. (This is unchanged.) On 32-bit kernels, > it loads the GS selector and updates GSBASE, which is now > always the user base. This means that the overall effect is > the same on 32-bit and 64-bit, which avoids some ifdeffery. > > Cc: Sedat Dilek > Cc: Nick Desaulniers > Signed-off-by: Andy Lutomirski > --- > arch/x86/Kconfig | 7 +- > arch/x86/Makefile | 8 +++ > arch/x86/entry/entry_32.S | 56 ++-- > arch/x86/include/asm/processor.h | 15 ++--- > arch/x86/include/asm/ptrace.h | 5 +- > arch/x86/include/asm/segment.h| 30 +++-- > arch/x86/include/asm/stackprotector.h | 79 +-- > arch/x86/include/asm/suspend_32.h | 6 +- > arch/x86/kernel/asm-offsets_32.c | 5 -- > arch/x86/kernel/cpu/common.c | 5 +- > arch/x86/kernel/doublefault_32.c | 4 +- > arch/x86/kernel/head_32.S | 18 +- > arch/x86/kernel/setup_percpu.c| 1 - > arch/x86/kernel/tls.c | 8 +-- > arch/x86/kvm/svm/svm.c| 10 +-- > arch/x86/lib/insn-eval.c | 4 -- > arch/x86/platform/pvh/head.S | 14 > arch/x86/power/cpu.c | 6 +- > arch/x86/xen/enlighten_pv.c | 1 - > scripts/gcc-x86_32-has-stack-protector.sh | 6 +- > 20 files changed, 62 insertions(+), 226 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 21f851179ff0..12d8bf011d08 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -353,10 +353,6 @@ config X86_64_SMP > def_bool y > depends on X86_64 && SMP > > -config X86_32_LAZY_GS > - def_bool y > - depends on X86_32 && !STACKPROTECTOR > - > config ARCH_SUPPORTS_UPROBES > def_bool y > > @@ -379,7 +375,8 @@ config CC_HAS_SANE_STACKPROTECTOR > default > $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC)) > help >We have to make sure stack protector is unconditionally disabled if > - the compiler produces broken code. > + the compiler produces broken code or if it does not let us control > + the segment on 32-bit kernels. > > menu "Processor type and features" > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index 7116da3980be..0b5cd8c49ccb 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -76,6 +76,14 @@ ifeq ($(CONFIG_X86_32),y) > > # temporary until string.h is fixed > KBUILD_CFLAGS += -ffreestanding > + > + ifeq ($(CONFIG_STACKPROTECTOR),y) > + ifeq ($(CONFIG_SMP),y) > + KBUILD_CFLAGS += -mstack-protector-guard-reg=fs > -mstack-protector-guard-symbol=__stack_chk_guard > + else > + KBUILD_CFLAGS += -mstack-protector-guard=global > + endif > + endif Just FYI: According to [1] the following clang
Re: [PATCH v2 0/2] Clean up x86_32 stackprotector
On Sat, Feb 13, 2021 at 8:19 PM Andy Lutomirski wrote: > > x86_32 stackprotector is a maintenance nightmare. Clean it up. This > disables stackprotector on x86_32 on GCC 8.1 and on all clang > versions. Some clang people are cc'd. > > Changes from v1: > - Changelog fixes. > - Comment fixes (mostly from Sean). > - Fix the !SMP case. > > Andy Lutomirski (2): > x86/stackprotector/32: Make the canary into a regular percpu variable > x86/entry/32: Remove leftover macros after stackprotector cleanups > Thanks Andy for bringing this up as v2. AFAICS, LLVM bug #47479 was involved here (see [1]). Maybe Nick can say some words. After patching my LLVM toolchain I decided to drop this and integrated the (kernel-side) diff from Nick (see [1]) in my custom patch-series. Is this your x86/unify_stack_canary Git branch (see [2])? - Sedat - [1] https://bugs.llvm.org/show_bug.cgi?id=47479 [2] https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/unify_stack_canary > arch/x86/Kconfig | 7 +- > arch/x86/Makefile | 8 ++ > arch/x86/entry/entry_32.S | 95 +-- > arch/x86/include/asm/processor.h | 15 +--- > arch/x86/include/asm/ptrace.h | 5 +- > arch/x86/include/asm/segment.h| 30 ++- > arch/x86/include/asm/stackprotector.h | 79 --- > arch/x86/include/asm/suspend_32.h | 6 +- > arch/x86/kernel/asm-offsets_32.c | 5 -- > arch/x86/kernel/cpu/common.c | 5 +- > arch/x86/kernel/doublefault_32.c | 4 +- > arch/x86/kernel/head_32.S | 18 + > arch/x86/kernel/setup_percpu.c| 1 - > arch/x86/kernel/tls.c | 8 +- > arch/x86/kvm/svm/svm.c| 10 +-- > arch/x86/lib/insn-eval.c | 4 - > arch/x86/platform/pvh/head.S | 14 > arch/x86/power/cpu.c | 6 +- > arch/x86/xen/enlighten_pv.c | 1 - > scripts/gcc-x86_32-has-stack-protector.sh | 6 +- > 20 files changed, 62 insertions(+), 265 deletions(-) > > -- > 2.29.2 >
Re: [PATCH] x86: entry: Remove _TIF_SINGLESTEP define leftover
On Mon, Feb 8, 2021 at 11:01 PM Kyle Huey wrote:
>
> Looks good to me.
>
Any other comments on this patch v2?
Thanks.
- Sedat -
> - Kyle
>
> On Mon, Feb 8, 2021 at 1:43 PM Sedat Dilek wrote:
> >
> > After commit 6342adcaa683 ("entry: Ensure trap after single-step on
> > system call return") a _TIF_SINGLESTEP define is obsolete for arch/x86.
> >
> > So, remove the leftover in arch/x86/include/asm/thread_info.h file.
> >
> > Fixes: 6342adcaa683 ("entry: Ensure trap after single-step on system call
> > return"
> > CC: Kyle Huey
> > Signed-off-by: Sedat Dilek
> > ---
> > arch/x86/include/asm/thread_info.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/thread_info.h
> > b/arch/x86/include/asm/thread_info.h
> > index 0d751d5da702..8861967e0305 100644
> > --- a/arch/x86/include/asm/thread_info.h
> > +++ b/arch/x86/include/asm/thread_info.h
> > @@ -101,7 +101,6 @@ struct thread_info {
> > #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
> > #define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
> > #define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
> > -#define _TIF_SINGLESTEP(1 << TIF_SINGLESTEP)
> > #define _TIF_SSBD (1 << TIF_SSBD)
> > #define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
> > #define _TIF_SPEC_FORCE_UPDATE (1 << TIF_SPEC_FORCE_UPDATE)
> > --
> > 2.30.0
> >
Re: [ANNOUNCE] exfatprogs-1.1.0 version released
On Wed, Feb 10, 2021 at 8:24 AM Sedat Dilek wrote: > > On Wed, Feb 10, 2021 at 5:51 AM Namjae Jeon wrote: > > > > Hope Sven will do a new release for Debian. > > > ( Note that Debian/bullseye release plans "Milestone 2" this Friday, > > > February 12th (see [1] > "Key > > > release dates" > "[2021-Feb-12] Soft Freeze"). Dunno which impact this > > > might have on this. ) > > I hope he will do it, too! > > > > Thanks Sedat:) > > I filed Debian Bug #982431 "exfatprogs: Update to version 1.1.0" > > - Sedat - > > [1] https://bugs.debian.org/982431 Who said Debian GNU/linux has outdated packages :-)? root# RELEASE="buildd-unstable" ; LC_ALL=C apt-get dist-upgrade -V -t $RELEASE ... The following packages will be upgraded: exfatprogs (1.0.4-1 => 1.1.0-1) 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 37.2 kB of archives. After this operation, 61.4 kB of additional disk space will be used. Do you want to continue? [Y/n] - Sedat -
Re: [ANNOUNCE] exfatprogs-1.1.0 version released
On Wed, Feb 10, 2021 at 5:51 AM Namjae Jeon wrote: > > Hope Sven will do a new release for Debian. > > ( Note that Debian/bullseye release plans "Milestone 2" this Friday, > > February 12th (see [1] > "Key > > release dates" > "[2021-Feb-12] Soft Freeze"). Dunno which impact this > > might have on this. ) > I hope he will do it, too! > > Thanks Sedat:) I filed Debian Bug #982431 "exfatprogs: Update to version 1.1.0" - Sedat - [1] https://bugs.debian.org/982431
Re: [ANNOUNCE] exfatprogs-1.1.0 version released
On Wed, Feb 10, 2021 at 12:50 AM Namjae Jeon wrote: > > Hi folk, > > We have released exfatprogs 1.1.0 version. In this release, exfatlabel > has been added to print or re-write volume label and volume serial value. > Also, A new dump.exfat util has been added to display statistics from > a given device(Requested by Mike Fleetwood(GParted Developer)). > > Any feedback is welcome!:) > Congrats to the new release and thanks to all involved people. Hope Sven will do a new release for Debian. ( Note that Debian/bullseye release plans "Milestone 2" this Friday, February 12th (see [1] > "Key release dates" > "[2021-Feb-12] Soft Freeze"). Dunno which impact this might have on this. ) - Sedat - [1] https://release.debian.org/ > CHANGES : > * fsck.exfat: Recover corrupted boot region. > > NEW FEATURES : > * exfatlabel: Print or set volume label and serial. > * dump.exfat: Show the on-disk metadata information and the statistics. > > BUG FIXES : > * Set _FILE_OFFSET_BITS=64 for Android build. > > The git tree is at: > https://github.com/exfatprogs/exfatprogs > > The tarballs can be found at: > > https://github.com/exfatprogs/exfatprogs/releases/download/1.1.0/exfatprogs-1.1.0.tar.gz >
[PATCH v2] x86: entry: Remove _TIF_SINGLESTEP define leftover
After commit 6342adcaa683 ("entry: Ensure trap after single-step on
system call return") a _TIF_SINGLESTEP define is obsolete for arch/x86.
So, remove the leftover in arch/x86/include/asm/thread_info.h file.
Fixes: 6342adcaa683 ("entry: Ensure trap after single-step on system call
return")
CC: Kyle Huey
Signed-off-by: Sedat Dilek
---
Changes v1->v2:
- Add closing parenthesis to Fixes tag
arch/x86/include/asm/thread_info.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 0d751d5da702..8861967e0305 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -101,7 +101,6 @@ struct thread_info {
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
#define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
-#define _TIF_SINGLESTEP(1 << TIF_SINGLESTEP)
#define _TIF_SSBD (1 << TIF_SSBD)
#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
#define _TIF_SPEC_FORCE_UPDATE (1 << TIF_SPEC_FORCE_UPDATE)
--
2.30.0
[PATCH] x86: entry: Remove _TIF_SINGLESTEP define leftover
After commit 6342adcaa683 ("entry: Ensure trap after single-step on
system call return") a _TIF_SINGLESTEP define is obsolete for arch/x86.
So, remove the leftover in arch/x86/include/asm/thread_info.h file.
Fixes: 6342adcaa683 ("entry: Ensure trap after single-step on system call
return"
CC: Kyle Huey
Signed-off-by: Sedat Dilek
---
arch/x86/include/asm/thread_info.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 0d751d5da702..8861967e0305 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -101,7 +101,6 @@ struct thread_info {
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
#define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
-#define _TIF_SINGLESTEP(1 << TIF_SINGLESTEP)
#define _TIF_SSBD (1 << TIF_SSBD)
#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
#define _TIF_SPEC_FORCE_UPDATE (1 << TIF_SPEC_FORCE_UPDATE)
--
2.30.0
Re: ANNOUNCE: pahole v1.20 (gcc11 DWARF5's default, lots of ELF sections, BTF)
On Mon, Feb 8, 2021 at 1:32 PM Arnaldo Carvalho de Melo
wrote:
>
> Em Mon, Feb 08, 2021 at 03:44:54AM +0100, Sedat Dilek escreveu:
> > On Thu, Feb 4, 2021 at 11:07 PM Arnaldo Carvalho de Melo
> > wrote:
> > >
> > > Hi,
> > >
> > > The v1.20 release of pahole and its friends is out, mostly
> > > addressing problems related to gcc 11 defaulting to DWARF5 for -g,
> > > available at the usual places:
> > >
> > > Main git repo:
> > >
> > >git://git.kernel.org/pub/scm/devel/pahole/pahole.git
> > >
> > > Mirror git repo:
> > >
> > >https://github.com/acmel/dwarves.git
> > >
> > > tarball + gpg signature:
> > >
> > >https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.xz
> > >https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.bz2
> > >https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.sign
> > >
> >
> > FYI:
> > Debian now ships dwarves package version 1.20-1 in unstable.
> >
> > Just a small nit to this release and its tagging:
> >
> > You did:
> > commit 0d415f68c468b77c5bf8e71965cd08c6efd25fc4 ("pahole: Prep 1.20")
> >
> > Is this new?
> >
> > The release before:
> > commit dd15aa4b0a6421295cbb7c3913429142fef8abe0 ("dwarves: Prep v1.19")
>
> Its minor but intentional, pahole is by far the most well known tool in
> dwarves, so using that name more frequently (the git repo is pahole.git
> , for instance) may help more quickly associate with the tool needed for
> BTF encoding, data analysis, etc. And since its not about only DWARF,
> perhaps transitioning to using 'pahole' more widely is interesting.
>
I am fine with that, Arnaldo.
The Git tree is called "pahole" Git, so that makes sense to me.
- Sedat -
> - Arnaldo
>
> > - Sedat -
> >
> > > Best Regards,
> > >
> > > - Arnaldo
> > >
> > > v1.20:
> > >
> > > BTF encoder:
> > >
> > > - Improve ELF error reporting using elf_errmsg(elf_errno()).
> > >
> > > - Improve objcopy error handling.
> > >
> > > - Fix handling of 'restrict' qualifier, that was being treated as a
> > > 'const'.
> > >
> > > - Support SHN_XINDEX in st_shndx symbol indexes, to handle ELF objects
> > > with
> > > more than 65534 sections, for instance, which happens with kernels
> > > built
> > > with 'KCFLAGS="-ffunction-sections -fdata-sections", Other cases may
> > > include when using FG-ASLR, LTO.
> > >
> > > - Cope with functions without a name, as seen sometimes when building
> > > kernel
> > > images with some versions of clang, when a SEGFAULT was taking place.
> > >
> > > - Fix BTF variable generation for kernel modules, not skipping
> > > variables at
> > > offset zero.
> > >
> > > - Fix address size to match what is in the ELF file being processed, to
> > > fix using
> > > a 64-bit pahole binary to generate BTF for a 32-bit vmlinux image.
> > >
> > > - Use kernel module ftrace addresses when finding which functions to
> > > encode,
> > > which increases the number of functions encoded.
> > >
> > > libbpf:
> > >
> > > - Allow use of packaged version, for distros wanting to dynamically
> > > link with
> > > the system's libbpf package instead of using the libbpf git submodule
> > > shipped
> > > in pahole's source code.
> > >
> > > DWARF loader:
> > >
> > > - Support DW_AT_data_bit_offset
> > >
> > > This appeared in DWARF4 but is supported only in gcc's -gdwarf-5,
> > > support it in a way that makes the output be the same for both cases.
> > >
> > > $ gcc -gdwarf-5 -c examples/dwarf5/bf.c
> > > $ pahole bf.o
> > > struct pea {
> > > long int a:1; /* 0: 0
> > > 8 */
> > > long int b:1; /* 0: 1
> > > 8 */
> > > long int c:1; /* 0: 2
> > > 8 */
> > >
> > > /* XXX 29 bits hole, try to pack */
> > > /* Bitfield combined with next fields */
> > >
> > > intafter_bitfield; /* 4
> > > 4 */
> > >
> > > /* size: 8, cachelines: 1, members: 4 */
> > > /* sum members: 4 */
> > > /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes:
> > > 29 bits */
> > > /* last cacheline: 8 bytes */
> > > };
> > >
> > > - DW_FORM_implicit_const in attr_numeric() and attr_offset()
> > >
> > > - Support DW_TAG_GNU_call_site, its the standardized rename of the
> > > previously supported
> > > DW_TAG_GNU_call_site.
> > >
> > > build:
> > >
> > > - Fix compilation on 32-bit architectures.
> > >
> > > Signed-off-by: Arnaldo Carvalho de Melo
>
> --
>
> - Arnaldo
Re: ANNOUNCE: pahole v1.20 (gcc11 DWARF5's default, lots of ELF sections, BTF)
On Thu, Feb 4, 2021 at 11:07 PM Arnaldo Carvalho de Melo
wrote:
>
> Hi,
>
> The v1.20 release of pahole and its friends is out, mostly
> addressing problems related to gcc 11 defaulting to DWARF5 for -g,
> available at the usual places:
>
> Main git repo:
>
>git://git.kernel.org/pub/scm/devel/pahole/pahole.git
>
> Mirror git repo:
>
>https://github.com/acmel/dwarves.git
>
> tarball + gpg signature:
>
>https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.xz
>https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.bz2
>https://fedorapeople.org/~acme/dwarves/dwarves-1.20.tar.sign
>
FYI:
Debian now ships dwarves package version 1.20-1 in unstable.
Just a small nit to this release and its tagging:
You did:
commit 0d415f68c468b77c5bf8e71965cd08c6efd25fc4 ("pahole: Prep 1.20")
Is this new?
The release before:
commit dd15aa4b0a6421295cbb7c3913429142fef8abe0 ("dwarves: Prep v1.19")
- Sedat -
> Best Regards,
>
> - Arnaldo
>
> v1.20:
>
> BTF encoder:
>
> - Improve ELF error reporting using elf_errmsg(elf_errno()).
>
> - Improve objcopy error handling.
>
> - Fix handling of 'restrict' qualifier, that was being treated as a 'const'.
>
> - Support SHN_XINDEX in st_shndx symbol indexes, to handle ELF objects with
> more than 65534 sections, for instance, which happens with kernels built
> with 'KCFLAGS="-ffunction-sections -fdata-sections", Other cases may
> include when using FG-ASLR, LTO.
>
> - Cope with functions without a name, as seen sometimes when building kernel
> images with some versions of clang, when a SEGFAULT was taking place.
>
> - Fix BTF variable generation for kernel modules, not skipping variables at
> offset zero.
>
> - Fix address size to match what is in the ELF file being processed, to fix
> using
> a 64-bit pahole binary to generate BTF for a 32-bit vmlinux image.
>
> - Use kernel module ftrace addresses when finding which functions to encode,
> which increases the number of functions encoded.
>
> libbpf:
>
> - Allow use of packaged version, for distros wanting to dynamically link
> with
> the system's libbpf package instead of using the libbpf git submodule
> shipped
> in pahole's source code.
>
> DWARF loader:
>
> - Support DW_AT_data_bit_offset
>
> This appeared in DWARF4 but is supported only in gcc's -gdwarf-5,
> support it in a way that makes the output be the same for both cases.
>
> $ gcc -gdwarf-5 -c examples/dwarf5/bf.c
> $ pahole bf.o
> struct pea {
> long int a:1; /* 0: 0 8 */
> long int b:1; /* 0: 1 8 */
> long int c:1; /* 0: 2 8 */
>
> /* XXX 29 bits hole, try to pack */
> /* Bitfield combined with next fields */
>
> intafter_bitfield; /* 4 4 */
>
> /* size: 8, cachelines: 1, members: 4 */
> /* sum members: 4 */
> /* sum bitfield members: 3 bits, bit holes: 1, sum bit holes: 29
> bits */
> /* last cacheline: 8 bytes */
> };
>
> - DW_FORM_implicit_const in attr_numeric() and attr_offset()
>
> - Support DW_TAG_GNU_call_site, its the standardized rename of the
> previously supported
> DW_TAG_GNU_call_site.
>
> build:
>
> - Fix compilation on 32-bit architectures.
>
> Signed-off-by: Arnaldo Carvalho de Melo
Re: [Linux v5.11-rc7] x86: entry: Leftover of _TIF_SINGLESTEP define?
On Mon, Feb 8, 2021 at 12:25 AM Kyle Huey wrote:
>
> On Sun, Feb 7, 2021 at 3:09 PM Sedat Dilek wrote:
> >
> > Hi,
> >
> > congrats to Linux v5.11-rc7.
> >
> > after commit 6342adcaa683 ("entry: Ensure trap after single-step on
> > system call return"):
> >
> > $ git grep '\_TIF_SINGLESTEP' arch/x86/
> > arch/x86/include/asm/thread_info.h:#define _TIF_SINGLESTEP
> > (1 << TIF_SINGLESTEP)
> >
> > Is this a leftover and can be removed (now)?
> >
> > Thanks.
> >
> > Regards,
> > - Sedat -
> >
> > [1] https://marc.info/?l=linux-kernel=161273724611262=2
> > [2] https://git.kernel.org/linus/6342adcaa683
>
> Yes it looks like that can be removed now.
>
Hi Kylem
Thanks for the confirmation.
Shall I send a patch?
With an ACK of you or mention in the commit message?
- Sedat -
Re: [Linux v5.11-rc7] x86: entry: Leftover of _TIF_SINGLESTEP define?
On Mon, Feb 8, 2021 at 12:27 AM Bhaskar Chowdhury wrote:
>
> On 00:08 Mon 08 Feb 2021, Sedat Dilek wrote:
> >Hi,
> >
> >congrats to Linux v5.11-rc7.
> >
> >after commit 6342adcaa683 ("entry: Ensure trap after single-step on
> >system call return"):
> >
> >$ git grep '\_TIF_SINGLESTEP' arch/x86/
> >arch/x86/include/asm/thread_info.h:#define _TIF_SINGLESTEP
> > (1 << TIF_SINGLESTEP)
> >
> Does it failed the build???
>
> Just curious??
>
No, it is simply a leftover.
Kyle confirmed.
I was able to build and boot into bare metal.
- Sedat -
> >Is this a leftover and can be removed (now)?
> >
> >Thanks.
> >
> >Regards,
> >- Sedat -
> >
> >[1] https://marc.info/?l=linux-kernel=161273724611262=2
> >[2] https://git.kernel.org/linus/6342adcaa683
[Linux v5.11-rc7] x86: entry: Leftover of _TIF_SINGLESTEP define?
Hi,
congrats to Linux v5.11-rc7.
after commit 6342adcaa683 ("entry: Ensure trap after single-step on
system call return"):
$ git grep '\_TIF_SINGLESTEP' arch/x86/
arch/x86/include/asm/thread_info.h:#define _TIF_SINGLESTEP
(1 << TIF_SINGLESTEP)
Is this a leftover and can be removed (now)?
Thanks.
Regards,
- Sedat -
[1] https://marc.info/?l=linux-kernel=161273724611262=2
[2] https://git.kernel.org/linus/6342adcaa683
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 9:13 PM Yonghong Song wrote:
>
>
>
> On 2/6/21 11:44 AM, Sedat Dilek wrote:
> > On Sat, Feb 6, 2021 at 8:33 PM Yonghong Song wrote:
> >>
> >>
> >>
> >> On 2/6/21 11:28 AM, Sedat Dilek wrote:
> >>> On Sat, Feb 6, 2021 at 8:22 PM Sedat Dilek wrote:
> >>>>
> >>>> On Sat, Feb 6, 2021 at 8:17 PM Yonghong Song wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2/6/21 10:10 AM, Sedat Dilek wrote:
> >>>>>> On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2/6/21 8:24 AM, Mark Wieelard wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote:
> >>>>>>>>> With the above vmlinux, the issue appears to be handling
> >>>>>>>>> DW_ATE_signed_1, DW_ATE_unsigned_{1,24,40}.
> >>>>>>>>>
> >>>>>>>>> The following patch should fix the issue:
> >>>>>>>>
> >>>>>>>> That doesn't really make sense to me. Why is the compiler emitting a
> >>>>>>>> DW_TAG_base_type that needs to be interpreted according to the
> >>>>>>>> DW_AT_name attribute?
> >>>>>>>>
> >>>>>>>> If the issue is that the size of the base type cannot be expressed in
> >>>>>>>> bytes then the DWARF spec provides the following option:
> >>>>>>>>
> >>>>>>>> If the value of an object of the given type does not fully
> >>>>>>>> occupy
> >>>>>>>> the storage described by a byte size attribute, the base type
> >>>>>>>> entry may also have a DW_AT_bit_size and a
> >>>>>>>> DW_AT_data_bit_offset
> >>>>>>>> attribute, both of whose values are integer constant values
> >>>>>>>> (see
> >>>>>>>> Section 2.19 on page 55). The bit size attribute describes
> >>>>>>>> the
> >>>>>>>> actual size in bits used to represent values of the given
> >>>>>>>> type. The data bit offset attribute is the offset in bits
> >>>>>>>> from the
> >>>>>>>> beginning of the containing storage to the beginning of the
> >>>>>>>> value. Bits that are part of the offset are padding. If this
> >>>>>>>> attribute is omitted a default data bit offset of zero is
> >>>>>>>> assumed.
> >>>>>>>>
> >>>>>>>> Would it be possible to use that encoding of those special types? If
> >>>>>>>
> >>>>>>> I agree with you. I do not like comparing me as well. Unfortunately,
> >>>>>>> there is no enough information in dwarf to find out actual
> >>>>>>> information.
> >>>>>>> The following is the dwarf dump with vmlinux (Sedat provided) for
> >>>>>>> DW_ATE_unsigned_1.
> >>>>>>>
> >>>>>>> 0x000e97e9: DW_TAG_base_type
> >>>>>>> DW_AT_name ("DW_ATE_unsigned_1")
> >>>>>>> DW_AT_encoding (DW_ATE_unsigned)
> >>>>>>> DW_AT_byte_size (0x00)
> >>>>>>>
> >>>>>>> There is no DW_AT_bit_size and DW_AT_bit_offset for base type.
> >>>>>>> AFAIK, these two attributes typically appear in struct/union members
> >>>>>>> together with DW_AT_byte_size.
> >>>>>>>
> >>>>>>> Maybe compilers (clang in this case) can emit DW_AT_bit_size = 1
> >>>>>>> and DW_AT_bit_offset = 0/7 (depending on big/little endian) and
> >>>>>>> this case, we just test and get DW_AT_bit_size and it should work.
> >>>>>>>
> >>>>>>> But I think BTF does not need this (DW_ATE_unsigned_1) for now.
> >>>>>>> I che
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 8:33 PM Yonghong Song wrote:
>
>
>
> On 2/6/21 11:28 AM, Sedat Dilek wrote:
> > On Sat, Feb 6, 2021 at 8:22 PM Sedat Dilek wrote:
> >>
> >> On Sat, Feb 6, 2021 at 8:17 PM Yonghong Song wrote:
> >>>
> >>>
> >>>
> >>> On 2/6/21 10:10 AM, Sedat Dilek wrote:
> >>>> On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2/6/21 8:24 AM, Mark Wieelard wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote:
> >>>>>>> With the above vmlinux, the issue appears to be handling
> >>>>>>> DW_ATE_signed_1, DW_ATE_unsigned_{1,24,40}.
> >>>>>>>
> >>>>>>> The following patch should fix the issue:
> >>>>>>
> >>>>>> That doesn't really make sense to me. Why is the compiler emitting a
> >>>>>> DW_TAG_base_type that needs to be interpreted according to the
> >>>>>> DW_AT_name attribute?
> >>>>>>
> >>>>>> If the issue is that the size of the base type cannot be expressed in
> >>>>>> bytes then the DWARF spec provides the following option:
> >>>>>>
> >>>>>>If the value of an object of the given type does not fully
> >>>>>> occupy
> >>>>>>the storage described by a byte size attribute, the base type
> >>>>>>entry may also have a DW_AT_bit_size and a DW_AT_data_bit_offset
> >>>>>>attribute, both of whose values are integer constant values (see
> >>>>>>Section 2.19 on page 55). The bit size attribute describes the
> >>>>>>actual size in bits used to represent values of the given
> >>>>>>type. The data bit offset attribute is the offset in bits from
> >>>>>> the
> >>>>>>beginning of the containing storage to the beginning of the
> >>>>>>value. Bits that are part of the offset are padding. If this
> >>>>>>attribute is omitted a default data bit offset of zero is
> >>>>>> assumed.
> >>>>>>
> >>>>>> Would it be possible to use that encoding of those special types? If
> >>>>>
> >>>>> I agree with you. I do not like comparing me as well. Unfortunately,
> >>>>> there is no enough information in dwarf to find out actual information.
> >>>>> The following is the dwarf dump with vmlinux (Sedat provided) for
> >>>>> DW_ATE_unsigned_1.
> >>>>>
> >>>>> 0x000e97e9: DW_TAG_base_type
> >>>>>DW_AT_name ("DW_ATE_unsigned_1")
> >>>>>DW_AT_encoding (DW_ATE_unsigned)
> >>>>>DW_AT_byte_size (0x00)
> >>>>>
> >>>>> There is no DW_AT_bit_size and DW_AT_bit_offset for base type.
> >>>>> AFAIK, these two attributes typically appear in struct/union members
> >>>>> together with DW_AT_byte_size.
> >>>>>
> >>>>> Maybe compilers (clang in this case) can emit DW_AT_bit_size = 1
> >>>>> and DW_AT_bit_offset = 0/7 (depending on big/little endian) and
> >>>>> this case, we just test and get DW_AT_bit_size and it should work.
> >>>>>
> >>>>> But I think BTF does not need this (DW_ATE_unsigned_1) for now.
> >>>>> I checked dwarf dump and it is mostly used for some arith operation
> >>>>> encoded in dump (in this case, e.g., shift by 1 bit)
> >>>>>
> >>>>> 0x15cf: DW_TAG_base_type
> >>>>>DW_AT_name ("DW_ATE_unsigned_1")
> >>>>>DW_AT_encoding (DW_ATE_unsigned)
> >>>>>DW_AT_byte_size (0x00)
> >>>>>
> >>>>> 0x00010ed9: DW_TAG_formal_parameter
> >>>>> DW_AT_location(DW_OP_lit0, DW_OP_not,
> >>>>> DW_OP_convert (0x15cf) "DW_ATE_unsigned_1", DW_OP_convert
> >>>>> (0x15d4) "DW_ATE_unsigned_8", DW_OP_s
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 8:22 PM Sedat Dilek wrote:
>
> On Sat, Feb 6, 2021 at 8:17 PM Yonghong Song wrote:
> >
> >
> >
> > On 2/6/21 10:10 AM, Sedat Dilek wrote:
> > > On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song wrote:
> > >>
> > >>
> > >>
> > >> On 2/6/21 8:24 AM, Mark Wieelard wrote:
> > >>> Hi,
> > >>>
> > >>> On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote:
> > >>>> With the above vmlinux, the issue appears to be handling
> > >>>> DW_ATE_signed_1, DW_ATE_unsigned_{1,24,40}.
> > >>>>
> > >>>> The following patch should fix the issue:
> > >>>
> > >>> That doesn't really make sense to me. Why is the compiler emitting a
> > >>> DW_TAG_base_type that needs to be interpreted according to the
> > >>> DW_AT_name attribute?
> > >>>
> > >>> If the issue is that the size of the base type cannot be expressed in
> > >>> bytes then the DWARF spec provides the following option:
> > >>>
> > >>> If the value of an object of the given type does not fully occupy
> > >>> the storage described by a byte size attribute, the base type
> > >>> entry may also have a DW_AT_bit_size and a DW_AT_data_bit_offset
> > >>> attribute, both of whose values are integer constant values (see
> > >>> Section 2.19 on page 55). The bit size attribute describes the
> > >>> actual size in bits used to represent values of the given
> > >>> type. The data bit offset attribute is the offset in bits from the
> > >>> beginning of the containing storage to the beginning of the
> > >>> value. Bits that are part of the offset are padding. If this
> > >>> attribute is omitted a default data bit offset of zero is assumed.
> > >>>
> > >>> Would it be possible to use that encoding of those special types? If
> > >>
> > >> I agree with you. I do not like comparing me as well. Unfortunately,
> > >> there is no enough information in dwarf to find out actual information.
> > >> The following is the dwarf dump with vmlinux (Sedat provided) for
> > >> DW_ATE_unsigned_1.
> > >>
> > >> 0x000e97e9: DW_TAG_base_type
> > >> DW_AT_name ("DW_ATE_unsigned_1")
> > >> DW_AT_encoding (DW_ATE_unsigned)
> > >> DW_AT_byte_size (0x00)
> > >>
> > >> There is no DW_AT_bit_size and DW_AT_bit_offset for base type.
> > >> AFAIK, these two attributes typically appear in struct/union members
> > >> together with DW_AT_byte_size.
> > >>
> > >> Maybe compilers (clang in this case) can emit DW_AT_bit_size = 1
> > >> and DW_AT_bit_offset = 0/7 (depending on big/little endian) and
> > >> this case, we just test and get DW_AT_bit_size and it should work.
> > >>
> > >> But I think BTF does not need this (DW_ATE_unsigned_1) for now.
> > >> I checked dwarf dump and it is mostly used for some arith operation
> > >> encoded in dump (in this case, e.g., shift by 1 bit)
> > >>
> > >> 0x15cf: DW_TAG_base_type
> > >> DW_AT_name ("DW_ATE_unsigned_1")
> > >> DW_AT_encoding (DW_ATE_unsigned)
> > >> DW_AT_byte_size (0x00)
> > >>
> > >> 0x00010ed9: DW_TAG_formal_parameter
> > >> DW_AT_location(DW_OP_lit0, DW_OP_not,
> > >> DW_OP_convert (0x15cf) "DW_ATE_unsigned_1", DW_OP_convert
> > >> (0x15d4) "DW_ATE_unsigned_8", DW_OP_stack_value)
> > >> DW_AT_abstract_origin (0x00013984 "branch")
> > >>
> > >> Look at clang frontend, only the following types are encoded with
> > >> unsigned dwarf type.
> > >>
> > >> case BuiltinType::UShort:
> > >> case BuiltinType::UInt:
> > >> case BuiltinType::UInt128:
> > >> case BuiltinType::ULong:
> > >> case BuiltinType::WChar_U:
> > >> case BuiltinType::ULongLong:
> > >> Encoding = llvm::dwarf::DW_ATE_unsigned;
> > >> break;
> > >>
> > >>
> > >>> not, can we try to come up with some extension that doesn't require
> > >>> consumers to match magic names?
> > >>>
> > >
> > > You want me to upload mlx5_core.ko?
> >
> > I just sent out a patch. You are cc'ed. I also attached in this email.
> > Yes, it would be great if you can upload mlx5_core.ko so I can
> > double check with this DW_ATE_unsigned_160 which is really usual.
> >
>
> Yupp, just built a new pahole :-).
> Re-building linux-kernel...
>
> Will upload mlx5_core.ko - need zstd-ed it before.
>
Hmm, I guess you want a mlx5_core.ko with your patch applied-to-pahole-1.20 :-)?
> - Sedat -
>
> > >
> > > When looking with llvm-dwarf for DW_ATE_unsigned_160:
> > >
> > > 0x00d65616: DW_TAG_base_type
> > > DW_AT_name ("DW_ATE_unsigned_160")
> > > DW_AT_encoding (DW_ATE_unsigned)
> > > DW_AT_byte_size (0x14)
> > >
> > > If you need further information, please let me know.
> > >
> > > Thanks.
> > >
> > > - Sedat -
> > >
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 8:17 PM Yonghong Song wrote:
>
>
>
> On 2/6/21 10:10 AM, Sedat Dilek wrote:
> > On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song wrote:
> >>
> >>
> >>
> >> On 2/6/21 8:24 AM, Mark Wieelard wrote:
> >>> Hi,
> >>>
> >>> On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote:
> >>>> With the above vmlinux, the issue appears to be handling
> >>>> DW_ATE_signed_1, DW_ATE_unsigned_{1,24,40}.
> >>>>
> >>>> The following patch should fix the issue:
> >>>
> >>> That doesn't really make sense to me. Why is the compiler emitting a
> >>> DW_TAG_base_type that needs to be interpreted according to the
> >>> DW_AT_name attribute?
> >>>
> >>> If the issue is that the size of the base type cannot be expressed in
> >>> bytes then the DWARF spec provides the following option:
> >>>
> >>> If the value of an object of the given type does not fully occupy
> >>> the storage described by a byte size attribute, the base type
> >>> entry may also have a DW_AT_bit_size and a DW_AT_data_bit_offset
> >>> attribute, both of whose values are integer constant values (see
> >>> Section 2.19 on page 55). The bit size attribute describes the
> >>> actual size in bits used to represent values of the given
> >>> type. The data bit offset attribute is the offset in bits from the
> >>> beginning of the containing storage to the beginning of the
> >>> value. Bits that are part of the offset are padding. If this
> >>> attribute is omitted a default data bit offset of zero is assumed.
> >>>
> >>> Would it be possible to use that encoding of those special types? If
> >>
> >> I agree with you. I do not like comparing me as well. Unfortunately,
> >> there is no enough information in dwarf to find out actual information.
> >> The following is the dwarf dump with vmlinux (Sedat provided) for
> >> DW_ATE_unsigned_1.
> >>
> >> 0x000e97e9: DW_TAG_base_type
> >> DW_AT_name ("DW_ATE_unsigned_1")
> >> DW_AT_encoding (DW_ATE_unsigned)
> >> DW_AT_byte_size (0x00)
> >>
> >> There is no DW_AT_bit_size and DW_AT_bit_offset for base type.
> >> AFAIK, these two attributes typically appear in struct/union members
> >> together with DW_AT_byte_size.
> >>
> >> Maybe compilers (clang in this case) can emit DW_AT_bit_size = 1
> >> and DW_AT_bit_offset = 0/7 (depending on big/little endian) and
> >> this case, we just test and get DW_AT_bit_size and it should work.
> >>
> >> But I think BTF does not need this (DW_ATE_unsigned_1) for now.
> >> I checked dwarf dump and it is mostly used for some arith operation
> >> encoded in dump (in this case, e.g., shift by 1 bit)
> >>
> >> 0x15cf: DW_TAG_base_type
> >> DW_AT_name ("DW_ATE_unsigned_1")
> >> DW_AT_encoding (DW_ATE_unsigned)
> >> DW_AT_byte_size (0x00)
> >>
> >> 0x00010ed9: DW_TAG_formal_parameter
> >> DW_AT_location(DW_OP_lit0, DW_OP_not,
> >> DW_OP_convert (0x15cf) "DW_ATE_unsigned_1", DW_OP_convert
> >> (0x15d4) "DW_ATE_unsigned_8", DW_OP_stack_value)
> >> DW_AT_abstract_origin (0x00013984 "branch")
> >>
> >> Look at clang frontend, only the following types are encoded with
> >> unsigned dwarf type.
> >>
> >> case BuiltinType::UShort:
> >> case BuiltinType::UInt:
> >> case BuiltinType::UInt128:
> >> case BuiltinType::ULong:
> >> case BuiltinType::WChar_U:
> >> case BuiltinType::ULongLong:
> >> Encoding = llvm::dwarf::DW_ATE_unsigned;
> >> break;
> >>
> >>
> >>> not, can we try to come up with some extension that doesn't require
> >>> consumers to match magic names?
> >>>
> >
> > You want me to upload mlx5_core.ko?
>
> I just sent out a patch. You are cc'ed. I also attached in this email.
> Yes, it would be great if you can upload mlx5_core.ko so I can
> double check with this DW_ATE_unsigned_160 which is really usual.
>
Yupp, just built a new pahole :-).
Re-building linux-kernel...
Will upload mlx5_core.ko - need zstd-ed it before.
- Sedat -
> >
> > When looking with llvm-dwarf for DW_ATE_unsigned_160:
> >
> > 0x00d65616: DW_TAG_base_type
> > DW_AT_name ("DW_ATE_unsigned_160")
> > DW_AT_encoding (DW_ATE_unsigned)
> > DW_AT_byte_size (0x14)
> >
> > If you need further information, please let me know.
> >
> > Thanks.
> >
> > - Sedat -
> >
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song wrote:
>
>
>
> On 2/6/21 8:24 AM, Mark Wieelard wrote:
> > Hi,
> >
> > On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote:
> >> With the above vmlinux, the issue appears to be handling
> >> DW_ATE_signed_1, DW_ATE_unsigned_{1,24,40}.
> >>
> >> The following patch should fix the issue:
> >
> > That doesn't really make sense to me. Why is the compiler emitting a
> > DW_TAG_base_type that needs to be interpreted according to the
> > DW_AT_name attribute?
> >
> > If the issue is that the size of the base type cannot be expressed in
> > bytes then the DWARF spec provides the following option:
> >
> > If the value of an object of the given type does not fully occupy
> > the storage described by a byte size attribute, the base type
> > entry may also have a DW_AT_bit_size and a DW_AT_data_bit_offset
> > attribute, both of whose values are integer constant values (see
> > Section 2.19 on page 55). The bit size attribute describes the
> > actual size in bits used to represent values of the given
> > type. The data bit offset attribute is the offset in bits from the
> > beginning of the containing storage to the beginning of the
> > value. Bits that are part of the offset are padding. If this
> > attribute is omitted a default data bit offset of zero is assumed.
> >
> > Would it be possible to use that encoding of those special types? If
>
> I agree with you. I do not like comparing me as well. Unfortunately,
> there is no enough information in dwarf to find out actual information.
> The following is the dwarf dump with vmlinux (Sedat provided) for
> DW_ATE_unsigned_1.
>
> 0x000e97e9: DW_TAG_base_type
> DW_AT_name ("DW_ATE_unsigned_1")
> DW_AT_encoding (DW_ATE_unsigned)
> DW_AT_byte_size (0x00)
>
> There is no DW_AT_bit_size and DW_AT_bit_offset for base type.
> AFAIK, these two attributes typically appear in struct/union members
> together with DW_AT_byte_size.
>
> Maybe compilers (clang in this case) can emit DW_AT_bit_size = 1
> and DW_AT_bit_offset = 0/7 (depending on big/little endian) and
> this case, we just test and get DW_AT_bit_size and it should work.
>
> But I think BTF does not need this (DW_ATE_unsigned_1) for now.
> I checked dwarf dump and it is mostly used for some arith operation
> encoded in dump (in this case, e.g., shift by 1 bit)
>
> 0x15cf: DW_TAG_base_type
> DW_AT_name ("DW_ATE_unsigned_1")
> DW_AT_encoding (DW_ATE_unsigned)
> DW_AT_byte_size (0x00)
>
> 0x00010ed9: DW_TAG_formal_parameter
>DW_AT_location(DW_OP_lit0, DW_OP_not,
> DW_OP_convert (0x15cf) "DW_ATE_unsigned_1", DW_OP_convert
> (0x15d4) "DW_ATE_unsigned_8", DW_OP_stack_value)
>DW_AT_abstract_origin (0x00013984 "branch")
>
> Look at clang frontend, only the following types are encoded with
> unsigned dwarf type.
>
>case BuiltinType::UShort:
>case BuiltinType::UInt:
>case BuiltinType::UInt128:
>case BuiltinType::ULong:
>case BuiltinType::WChar_U:
>case BuiltinType::ULongLong:
> Encoding = llvm::dwarf::DW_ATE_unsigned;
> break;
>
>
> > not, can we try to come up with some extension that doesn't require
> > consumers to match magic names?
> >
You want me to upload mlx5_core.ko?
When looking with llvm-dwarf for DW_ATE_unsigned_160:
0x00d65616: DW_TAG_base_type
DW_AT_name ("DW_ATE_unsigned_160")
DW_AT_encoding (DW_ATE_unsigned)
DW_AT_byte_size (0x14)
If you need further information, please let me know.
Thanks.
- Sedat -
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
Some post-mortem:
LLVM_DWARF_BIN="/opt/llvm-toolchain/bin/llvm-dwarfdump"
module="drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko"
Module has DW_ATE_unsigned_160 and DW_ATE_unsigned_1:
$LLVM_DWARF_BIN $module | grep DW_AT_name | grep DW_ATE_ | sort -u
DW_AT_name ("DW_ATE_signed_32")
DW_AT_name ("DW_ATE_signed_64")
DW_AT_name ("DW_ATE_unsigned_1")
DW_AT_name ("DW_ATE_unsigned_128")
DW_AT_name ("DW_ATE_unsigned_16")
DW_AT_name ("DW_ATE_unsigned_160")
DW_AT_name ("DW_ATE_unsigned_32")
DW_AT_name ("DW_ATE_unsigned_64")
vmlinux has only DW_ATE_unsigned_1:
$ $LLVM_DWARF_BIN vmlinux | grep DW_AT_name | grep DW_ATE_ | sort -u
DW_AT_name ("DW_ATE_signed_1")
DW_AT_name ("DW_ATE_signed_16")
DW_AT_name ("DW_ATE_signed_32")
DW_AT_name ("DW_ATE_signed_64")
DW_AT_name ("DW_ATE_signed_8")
DW_AT_name ("DW_ATE_unsigned_1")
DW_AT_name ("DW_ATE_unsigned_128")
DW_AT_name ("DW_ATE_unsigned_16")
DW_AT_name ("DW_ATE_unsigned_24")
DW_AT_name ("DW_ATE_unsigned_32")
DW_AT_name ("DW_ATE_unsigned_40")
DW_AT_name ("DW_ATE_unsigned_64")
DW_AT_name ("DW_ATE_unsigned_8")
- Sedat -
Re: [PATCH v9 0/3] Kbuild: DWARF v5 support
On Sat, Feb 6, 2021 at 1:05 PM Masahiro Yamada wrote: > > On Sat, Feb 6, 2021 at 6:00 AM Sedat Dilek wrote: > > > > On Fri, Feb 5, 2021 at 9:22 PM Nick Desaulniers > > wrote: > > > > > > DWARF v5 is the latest standard of the DWARF debug info format. > > > > > > DWARF5 wins significantly in terms of size and especially so when mixed > > > with compression (CONFIG_DEBUG_INFO_COMPRESSED). > > > > > > Link: http://www.dwarfstd.org/doc/DWARF5.pdf > > > > > > Patch 1 places the DWARF v5 sections explicitly in the kernel linker > > > script. > > > Patch 2 modifies Kconfig for DEBUG_INFO_DWARF4 to be used as a fallback. > > > Patch 3 adds an explicit Kconfig for DWARF v5 for clang and older GCC > > > where the implicit default DWARF version is not 5. > > > > > > Changes from v8: > > > * Separate out the linker script changes (from v7 0002). Put those > > > first. Carry Reviewed by and tested by tags. Least contentious part > > > of the series. Tagged for stable; otherwise users upgrading to GCC 11 > > > may find orphan section warnings from the implicit default DWARF > > > version changing and generating the new debug info sections. > > > * Add CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT in 0002, make it the > > > default rather than CONFIG_DEBUG_INFO_DWARF4, as per Mark, Jakub, > > > Arvind. > > > * Drop reviewed by and tested by tags for 0002 and 0003; sorry > > > reviewers/testers, but I view that as a big change. I will buy you > > > beers if you're fatigued, AND for the help so far. I appreciate you. > > > > All 3 patches NACKed - I drink no beer. > > LoL. > Other than beer, I am fine with v9. > > Personally, I thought v8 (no CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT) > was good too, but I do not have a strong opinion about > leaving the compiler's freedom to choose the dwarf version. > > Unless somebody has an objection, I will pick up v9 for the next MW. > > > Meanwhile, if you want to give reviewed-by / tested-by > please do so. > Fine with me. I have no opinion towards distro-handling of toolchain-default(s). Feel free to add my: Tested-by: Sedat Dilek # LLVM/Clang v12.0.0-rc1 x86-64 Thanks to all involved people - I enjoyed the evolution of this patchset. - Sedat - P.S.: /me drinking right now an Earl Grey tea - drink whatever you prefer :-).
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
[ SNIP ]
> > > > > Please help do a test. I can submit a formal patch tomorrow.
> > > >
> > > > Thanks for the patch.
> > > >
> > > > Can you attach the diff as Gmail has totally truncated/malformed it?
> > > >
> > > > For the Linux breakage - you will need some additional Clang specific
> > > > patches.
> > > > Is this Linux 5.11-rcX?
> > > > The "Blocking bugs" are listed in the first post of "Linux 5.11 release
> > > > cycle".
> > > > Hope this helps.
> > > >
> > > > This is cool co-working :-).
> > > >
> > > > - Sedat -
> > > >
> > > > [1] https://github.com/ClangBuiltLinux/linux/issues/1228
> > >
> > > With the attached diff and new selfmade pahole looks good here.
> > >
> > > Passed (see line-numbers):
> > >
> > > 11090:+ info LD .tmp_vmlinux.btf
> > > 11099:+ info BTF .btf.vmlinux.bin.o
> > > 11103:+ LLVM_OBJCOPY=llvm-objcopy /opt/pahole/bin/pahole -J
> > > .tmp_vmlinux.btf
> > > 11121:+ info LD .tmp_vmlinux.kallsyms1
> > > 11139:+ info KSYMS .tmp_vmlinux.kallsyms1.S
> > > 11145:+ info AS .tmp_vmlinux.kallsyms1.S
> > > 11160:+ info LD .tmp_vmlinux.kallsyms2
> > > 11178:+ info KSYMS .tmp_vmlinux.kallsyms2.S
> > > 11184:+ info AS .tmp_vmlinux.kallsyms2.S
> > > 11200:+ info LD vmlinux
> > > 11210:+ info BTFIDS vmlinux
> > > 11216:+ info SORTTAB vmlinux
> > >
> > > Still building linux-kernel...
> > >
> > > Will report later if I was able to boot on bare metal.
> > >
> >
> > When running scripts/Makefile.modfinal:
> >
> > ...
> > not supported bit_size 160
> > Encountered error while encoding BTF.
> > ...
> > make[5]: *** [scripts/Makefile.modfinal:59:
> > drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] Error 1
> > make[5]: *** Deleting file
> > 'drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko'
> >
>
> I added "bit_size 160" to libbtf.c:
>
> static int bits_to_int_bytes(uint16_t bit_size)
> {
>if (bit_size <= 8)
>return 1;
>if (bit_size <= 16)
>return 2;
>if (bit_size <= 32)
>return 4;
>if (bit_size <= 64)
>return 8;
>if (bit_size <= 128)
>return 16;
>if (bit_size <= 160)
>return 20;
>/* BTF supports upto 16byte int (__int128). */
>return -1;
> }
>
> It still breaks with:
>
> [521367] INT DW_ATE_unsigned_160 Error emitting BTF type
> Encountered error while encoding BTF.
> make[5]: *** [scripts/Makefile.modfinal:58:
> drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] Error 1
> make[5]: *** Deleting file
> 'drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko'
>
> Comments?
>
Indeed there is DW_ATE_unsigned_160:
$ /opt/llvm-toolchain/bin/llvm-dwarfdump
drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.o | grep DW_AT_name
| grep DW_ATE_ | sort -u
DW_AT_name ("DW_ATE_signed_32")
DW_AT_name ("DW_ATE_signed_64")
DW_AT_name ("DW_ATE_unsigned_1")
DW_AT_name ("DW_ATE_unsigned_128")
DW_AT_name ("DW_ATE_unsigned_16")
DW_AT_name ("DW_ATE_unsigned_160")
DW_AT_name ("DW_ATE_unsigned_32")
DW_AT_name ("DW_ATE_unsigned_64")
DW_AT_name ("DW_ATE_unsigned_8")
Attached is diff v2 with the "bit_size 160" fix.
- Sedat -
diff --git a/dwarf_loader.c b/dwarf_loader.c
index b73d7867e1e6..aba14679a07e 100644
--- a/dwarf_loader.c
+++ b/dwarf_loader.c
@@ -467,8 +467,15 @@ static struct base_type *base_type__new(Dwarf_Die *die, struct cu *cu)
if (bt != NULL) {
tag__init(>tag, cu, die);
- bt->name = strings__add(strings, attr_string(die, DW_AT_name));
- bt->bit_size = attr_numeric(die, DW_AT_byte_size) * 8;
+ const char *name = attr_string(die, DW_AT_name);
+ bt->name = strings__add(strings, name);
+ /* DW_ATE_unsigned_1 has DW_AT_byte_size == 0.
+ * specially process it.
+ */
+ if (strcmp(name, "DW_ATE_unsigned_1") == 0)
+ bt->bit_size = 1;
+ else
+ bt->bit_size = attr_numeric(die, DW_AT_byte_size) * 8;
uint64_t encoding = attr_numeric(die, DW_AT_encoding);
bt->is_bool = encoding == DW_ATE_boolean;
bt->is_signed = encoding == DW_ATE_signed;
diff --git a/libbtf.c b/libbtf.c
index 9f7628304495..48ba57394090 100644
--- a/libbtf.c
+++ b/libbtf.c
@@ -367,13 +367,34 @@ static void btf_log_func_param(const struct btf_elf *btfe,
}
}
+/* btf requires power-of-2 bytes, yet dwarf may have something like
+ * DW_ATE_unsigned_24 which encodes as 24 bits (3 bytes).
+ */
+static int bits_to_int_bytes(uint16_t bit_size)
+{
+ if (bit_size <= 8)
+ return 1;
+ if (bit_size <= 16)
+ return 2;
+ if (bit_size <= 32)
+ return 4;
+ if (bit_size <= 64)
+ return 8;
+ if (bit_size <= 128)
+ return 16;
+ if (bit_size <= 160)
+ return 20;
+ /* BTF supports upto 16byte int (__int128). */
+ return -1;
+}
+
int32_t btf_elf__add_base_type(struct
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 10:48 AM Sedat Dilek wrote:
>
> On Sat, Feb 6, 2021 at 10:32 AM Sedat Dilek wrote:
> >
> > On Sat, Feb 6, 2021 at 9:32 AM Sedat Dilek wrote:
> > >
> > > On Sat, Feb 6, 2021 at 9:27 AM Yonghong Song wrote:
> > > >
> > > >
> > > >
> > > > On 2/5/21 10:52 PM, Sedat Dilek wrote:
> > > > > On Sat, Feb 6, 2021 at 7:26 AM Sedat Dilek
> > > > > wrote:
> > > > >>
> > > > >> On Sat, Feb 6, 2021 at 6:53 AM Sedat Dilek
> > > > >> wrote:
> > > > >>>
> > > > >>> On Sat, Feb 6, 2021 at 6:44 AM Sedat Dilek
> > > > >>> wrote:
> > > > >>>>
> > > > >>>> On Sat, Feb 6, 2021 at 4:34 AM Sedat Dilek
> > > > >>>> wrote:
> > > > >>>>>
> > > > >>>>> On Fri, Feb 5, 2021 at 10:54 PM Yonghong Song wrote:
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> On 2/5/21 12:31 PM, Sedat Dilek wrote:
> > > > >>>>>>> On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song
> > > > >>>>>>> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> > > > >>>>>>>>> Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song
> > > > >>>>>>>>> escreveu:
> > > > >>>>>>>>>> On 2/5/21 11:06 AM, Sedat Dilek wrote:
> > > > >>>>>>>>>>> On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek
> > > > >>>>>>>>>>> wrote:
> > > > >>>>>>>>>>> Grepping through linux.git/tools I guess some BTF
> > > > >>>>>>>>>>> tools/libs need to
> > > > >>>>>>>>>>> know what BTF_INT_UNSIGNED is?
> > > > >>>>>>>>>
> > > > >>>>>>>>>> BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>> ignore this for now until kernel infrastructure is ready.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Yeah, I thought about doing that.
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Not sure whether this information will be useful or not
> > > > >>>>>>>>>> for BTF. This needs to be discussed separately.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Maybe search for the rationale for its introduction in DWARF.
> > > > >>>>>>>>
> > > > >>>>>>>> In LLVM, we have:
> > > > >>>>>>>> uint8_t BTFEncoding;
> > > > >>>>>>>> switch (Encoding) {
> > > > >>>>>>>> case dwarf::DW_ATE_boolean:
> > > > >>>>>>>>BTFEncoding = BTF::INT_BOOL;
> > > > >>>>>>>>break;
> > > > >>>>>>>> case dwarf::DW_ATE_signed:
> > > > >>>>>>>> case dwarf::DW_ATE_signed_char:
> > > > >>>>>>>>BTFEncoding = BTF::INT_SIGNED;
> > > > >>>>>>>>break;
> > > > >>>>>>>> case dwarf::DW_ATE_unsigned:
> > > > >>>>>>>> case dwarf::DW_ATE_unsigned_char:
> > > > >>>>>>>>BTFEncoding = 0;
> > > > >>>>>>>>break;
> > > > >>>>>>>>
> > > > >>>>>>>> I think DW_ATE_unsigned can be ignored in pahole since
> > > > >>>>>>>> the default encoding = 0. A simple comment is enough.
> > > > >>>>>>>>
> > > > >>>>>>>
>
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 10:32 AM Sedat Dilek wrote:
>
> On Sat, Feb 6, 2021 at 9:32 AM Sedat Dilek wrote:
> >
> > On Sat, Feb 6, 2021 at 9:27 AM Yonghong Song wrote:
> > >
> > >
> > >
> > > On 2/5/21 10:52 PM, Sedat Dilek wrote:
> > > > On Sat, Feb 6, 2021 at 7:26 AM Sedat Dilek
> > > > wrote:
> > > >>
> > > >> On Sat, Feb 6, 2021 at 6:53 AM Sedat Dilek
> > > >> wrote:
> > > >>>
> > > >>> On Sat, Feb 6, 2021 at 6:44 AM Sedat Dilek
> > > >>> wrote:
> > > >>>>
> > > >>>> On Sat, Feb 6, 2021 at 4:34 AM Sedat Dilek
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> On Fri, Feb 5, 2021 at 10:54 PM Yonghong Song wrote:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On 2/5/21 12:31 PM, Sedat Dilek wrote:
> > > >>>>>>> On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> > > >>>>>>>>> Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song
> > > >>>>>>>>> escreveu:
> > > >>>>>>>>>> On 2/5/21 11:06 AM, Sedat Dilek wrote:
> > > >>>>>>>>>>> On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>> Grepping through linux.git/tools I guess some BTF tools/libs
> > > >>>>>>>>>>> need to
> > > >>>>>>>>>>> know what BTF_INT_UNSIGNED is?
> > > >>>>>>>>>
> > > >>>>>>>>>> BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole to
> > > >>>>>>>>>> ignore this for now until kernel infrastructure is ready.
> > > >>>>>>>>>
> > > >>>>>>>>> Yeah, I thought about doing that.
> > > >>>>>>>>>
> > > >>>>>>>>>> Not sure whether this information will be useful or not
> > > >>>>>>>>>> for BTF. This needs to be discussed separately.
> > > >>>>>>>>>
> > > >>>>>>>>> Maybe search for the rationale for its introduction in DWARF.
> > > >>>>>>>>
> > > >>>>>>>> In LLVM, we have:
> > > >>>>>>>> uint8_t BTFEncoding;
> > > >>>>>>>> switch (Encoding) {
> > > >>>>>>>> case dwarf::DW_ATE_boolean:
> > > >>>>>>>>BTFEncoding = BTF::INT_BOOL;
> > > >>>>>>>>break;
> > > >>>>>>>> case dwarf::DW_ATE_signed:
> > > >>>>>>>> case dwarf::DW_ATE_signed_char:
> > > >>>>>>>>BTFEncoding = BTF::INT_SIGNED;
> > > >>>>>>>>break;
> > > >>>>>>>> case dwarf::DW_ATE_unsigned:
> > > >>>>>>>> case dwarf::DW_ATE_unsigned_char:
> > > >>>>>>>>BTFEncoding = 0;
> > > >>>>>>>>break;
> > > >>>>>>>>
> > > >>>>>>>> I think DW_ATE_unsigned can be ignored in pahole since
> > > >>>>>>>> the default encoding = 0. A simple comment is enough.
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> Yonghong Son, do you have a patch/diff for me?
> > > >>>>>>
> > > >>>>>> Looking at error message from log:
> > > >>>>>>
> > > >>>>>>LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J
> > > >>>>>> .tmp_vmlinux.btf
> > > >>>>>> [115] INT DW_ATE_unsigned_1 Error emitting BTF type
> > >
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 10:32 AM Sedat Dilek wrote:
>
> On Sat, Feb 6, 2021 at 9:32 AM Sedat Dilek wrote:
> >
> > On Sat, Feb 6, 2021 at 9:27 AM Yonghong Song wrote:
> > >
> > >
> > >
> > > On 2/5/21 10:52 PM, Sedat Dilek wrote:
> > > > On Sat, Feb 6, 2021 at 7:26 AM Sedat Dilek
> > > > wrote:
> > > >>
> > > >> On Sat, Feb 6, 2021 at 6:53 AM Sedat Dilek
> > > >> wrote:
> > > >>>
> > > >>> On Sat, Feb 6, 2021 at 6:44 AM Sedat Dilek
> > > >>> wrote:
> > > >>>>
> > > >>>> On Sat, Feb 6, 2021 at 4:34 AM Sedat Dilek
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> On Fri, Feb 5, 2021 at 10:54 PM Yonghong Song wrote:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On 2/5/21 12:31 PM, Sedat Dilek wrote:
> > > >>>>>>> On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> > > >>>>>>>>> Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song
> > > >>>>>>>>> escreveu:
> > > >>>>>>>>>> On 2/5/21 11:06 AM, Sedat Dilek wrote:
> > > >>>>>>>>>>> On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>> Grepping through linux.git/tools I guess some BTF tools/libs
> > > >>>>>>>>>>> need to
> > > >>>>>>>>>>> know what BTF_INT_UNSIGNED is?
> > > >>>>>>>>>
> > > >>>>>>>>>> BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole to
> > > >>>>>>>>>> ignore this for now until kernel infrastructure is ready.
> > > >>>>>>>>>
> > > >>>>>>>>> Yeah, I thought about doing that.
> > > >>>>>>>>>
> > > >>>>>>>>>> Not sure whether this information will be useful or not
> > > >>>>>>>>>> for BTF. This needs to be discussed separately.
> > > >>>>>>>>>
> > > >>>>>>>>> Maybe search for the rationale for its introduction in DWARF.
> > > >>>>>>>>
> > > >>>>>>>> In LLVM, we have:
> > > >>>>>>>> uint8_t BTFEncoding;
> > > >>>>>>>> switch (Encoding) {
> > > >>>>>>>> case dwarf::DW_ATE_boolean:
> > > >>>>>>>>BTFEncoding = BTF::INT_BOOL;
> > > >>>>>>>>break;
> > > >>>>>>>> case dwarf::DW_ATE_signed:
> > > >>>>>>>> case dwarf::DW_ATE_signed_char:
> > > >>>>>>>>BTFEncoding = BTF::INT_SIGNED;
> > > >>>>>>>>break;
> > > >>>>>>>> case dwarf::DW_ATE_unsigned:
> > > >>>>>>>> case dwarf::DW_ATE_unsigned_char:
> > > >>>>>>>>BTFEncoding = 0;
> > > >>>>>>>>break;
> > > >>>>>>>>
> > > >>>>>>>> I think DW_ATE_unsigned can be ignored in pahole since
> > > >>>>>>>> the default encoding = 0. A simple comment is enough.
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> Yonghong Son, do you have a patch/diff for me?
> > > >>>>>>
> > > >>>>>> Looking at error message from log:
> > > >>>>>>
> > > >>>>>>LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J
> > > >>>>>> .tmp_vmlinux.btf
> > > >>>>>> [115] INT DW_ATE_unsigned_1 Error emitting BTF type
> > >
