Re: [regression 5.4.97 → 5.10.24]: raid6 avx2x4 speed drops from 18429 MB/s to 6155 MB/s
Den 2021-04-02 kl. 17:05, skrev Borislav Petkov: > On Fri, Apr 02, 2021 at 10:33:51AM +0200, Paul Menzel wrote: >> Dear Linux folks, >> >> >> On an two socket AMD EPYC 7601, we noticed a decrease in raid6 avx2x4 speed >> shown at the beginning of the boot. >> >> 5.4.955.10.24 >> -- >> raid6: avx2x4 gen() 18429 MB/s 6155 MB/s >> raid6: avx2x4 xor()6644 MB/s 4274 MB/s >> raid6: avx2x2 gen() 17894 MB/s18744 MB/s >> raid6: avx2x2 xor() 11642 MB/s11950 MB/s >> raid6: avx2x1 gen() 13992 MB/s17112 MB/s >> raid6: avx2x1 xor() 10855 MB/s11143 MB/s > > Looks like those two might help: > That would mean only this is missing: > 49200d17d27d x86/fpu/64: Don't FNINIT in kernel_fpu_begin() as this one landed in 5.10.11: > e45122893a98 x86/fpu: Add kernel_fpu_begin_mask() to selectively initialize > state > -- Thomas
Re: linux-5.10.11 build failure
Den 28.1.2021 kl. 12:05, skrev Chris Clayton: > > On 28/01/2021 09:34, Greg Kroah-Hartman wrote: >> On Thu, Jan 28, 2021 at 09:17:10AM +, Chris Clayton wrote: >>> Hi, >>> >>> Building 5.10.11 fails on my (x86-64) laptop thusly: >>> >>> .. >>> >>> AS arch/x86/entry/thunk_64.o >>>CC arch/x86/entry/vsyscall/vsyscall_64.o >>>AS arch/x86/realmode/rm/header.o >>>CC arch/x86/mm/pat/set_memory.o >>>CC arch/x86/events/amd/core.o >>>CC arch/x86/kernel/fpu/init.o >>>CC arch/x86/entry/vdso/vma.o >>>CC kernel/sched/core.o >>> arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn at >>> offset 0x3e >>> >>>AS arch/x86/realmode/rm/trampoline_64.o >>> make[2]: *** [scripts/Makefile.build:360: arch/x86/entry/thunk_64.o] Error >>> 255 >>> make[2]: *** Deleting file 'arch/x86/entry/thunk_64.o' >>> make[2]: *** Waiting for unfinished jobs >>> >>> .. >>> >>> Compiler is latest snapshot of gcc-10. >>> >>> Happy to test the fix but please cc me as I'm not subscribed >> >> Can you do 'git bisect' to track down the offending commit? >> > > Sure, but I'll hold that request for a while. I updated to binutils-2.36 on > Monday and I'm pretty sure that is a feature > of this build fail. I've reverted binutils to 2.35.1, and the build succeeds. > Updated to 2.36 again and, surprise, > surprise, the kernel build fails again. > > I've had a glance at the binutils ML and there are all sorts of issues being > reported, but it's beyond my knowledge to > assess if this build error is related to any of them. > > I'll stick with binutils-2.35.1 for the time being. > >> And what exact gcc version are you using? >> > > It's built from the 10-20210123 snapshot tarball. > > I can report this to the binutils folks, but might it be better if the > objtool maintainer looks at it first? The > binutils change might just have opened the gate to a bug in objtool. > >> thanks, >> >> greg k-h >> > AFAIK you need this in stable trees: From 1d489151e9f9d1647110277ff77282fe4d96d09b Mon Sep 17 00:00:00 2001 From: Josh Poimboeuf Date: Thu, 14 Jan 2021 16:14:01 -0600 Subject: [PATCH] objtool: Don't fail on missing symbol table -- Thomas
Re: [PATCH] hwmon: corsair-psu: update supported devices
Den 01.12.2020 kl. 09:24, skrev Wilken Gottwalt: Thank you. Hmm yeah, this dongle has no usb hid part. So this driver will not work with this dongle for sure. I already have an idea how to support all 3 series, though it involves a lot of testing. I would provide a github repo with tools and test kernel modules if you are interested. But I don't know yet how long it will take, I work on other stuff which has a higher prio. Yes, I'm interested... Just drop me a note when you have something to test. -- Thomas
Re: [PATCH] hwmon: corsair-psu: update supported devices
Den 28.11.2020 kl. 12:35, skrev Wilken Gottwalt: On Sat, 28 Nov 2020 02:37:38 -0300 Jonas Malaco wrote: On Thu, Nov 26, 2020 at 8:43 AM Wilken Gottwalt wrote: Adds support for another Corsair PSUs series: AX760i, AX860i, AX1200i, AX1500i and AX1600i. The first 3 power supplies are supported through the Corsair Link USB Dongle which is some kind of USB/Serial/TTL converter especially made for the COM ports of these power supplies. There are 3 known revisions of these adapters. The AX1500i power supply has revision 3 built into the case and AX1600i is the only one in that series, which has an unique usb hid id like the RM/RX series. Can I ask what AXi power supplies were tested? I ask because, based on the user-space implementations I am aware of, the AXi dongle protocol appears to be different from the RMi/HXi series. I was not able to test this against the AX power supplies, they are really hard to find (and are far to expensive). But I went through all these tools and stuck to the most common commands, which all 3 series support. Not every series supports all commands (there also seem to be different firmwares in the micro-conrollers). But this is fine, some sensors will show up as N/A. Even my HX850i does not support all commands covered in this driver. What kind of tests do you want / need ? I have an AX860i here. -- Regards Thomas Backlund
Re: perf build error with gcc 10 on arm and aarch64
Den 05-05-2020 kl. 07:10, skrev Leo Yan: Hi Thomas, [ + Mathieu/Mike/Suzuki ] On Mon, May 04, 2020 at 10:22:27PM +0300, Thomas Backlund wrote: This is building perf from kernel-5.6.10 on armv7hl and aarch64: Compiler is gcc 10.1.0-RC LD perf-in.o ld: arch/perf-in.o: in function `.LANCHOR0': /home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118: multiple definition of `traceid_list'; util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/cs-etm.h:118: first defined here make[3]: *** [/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/build/Makefile.build:145: perf-in.o] Error 1 LD perf-in.o ld: arch/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118: multiple definition of `traceid_list'; util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/cs-etm.h:118: first defined here make[3]: *** [/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/build/Makefile.build:145: perf-in.o] Error 1 make[2]: *** [Makefile.perf:616: perf-in.o] Error 2 make[1]: *** [Makefile.perf:225: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 The same build succeeds with gcc 9.3.0 Thanks for reporting the issue. Could you help confirm if below change can resolve this issue? Yes, fix confirmed on i586, x86_64, armv7hl and aarch64 builds so I guess you can add: Reported-by: Thomas Backlund Tested-by: Thomas Backlund Thanks, Leo ---8<--- Subject: [PATCH] perf cs-etm: Move defined of traceid_list The variable 'traceid_list' is defined in the header file cs-etm.h, if multiple C files include cs-etm.h the compiler might complaint for multiple definition of 'traceid_list'. To fix multiple definition error, move the definition of 'traceid_list' into cs-etm.c. Signed-off-by: Leo Yan --- tools/perf/util/cs-etm.c | 3 +++ tools/perf/util/cs-etm.h | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 62d2f9b9ce1b..381d9708e9bd 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -94,6 +94,9 @@ struct cs_etm_queue { struct cs_etm_traceid_queue **traceid_queues; }; +/* RB tree for quick conversion between traceID and metadata pointers */ +static struct intlist *traceid_list; + static int cs_etm__update_queues(struct cs_etm_auxtrace *etm); static int cs_etm__process_queues(struct cs_etm_auxtrace *etm); static int cs_etm__process_timeless_queues(struct cs_etm_auxtrace *etm, diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h index 650ecc2a6349..4ad925d6d799 100644 --- a/tools/perf/util/cs-etm.h +++ b/tools/perf/util/cs-etm.h @@ -114,9 +114,6 @@ enum cs_etm_isa { CS_ETM_ISA_T32, }; -/* RB tree for quick conversion between traceID and metadata pointers */ -struct intlist *traceid_list; - struct cs_etm_queue; struct cs_etm_packet { -- 2.17.1
perf build error with gcc 10 on arm and aarch64
This is building perf from kernel-5.6.10 on armv7hl and aarch64: Compiler is gcc 10.1.0-RC LD perf-in.o ld: arch/perf-in.o: in function `.LANCHOR0': /home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118: multiple definition of `traceid_list'; util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/cs-etm.h:118: first defined here make[3]: *** [/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/build/Makefile.build:145: perf-in.o] Error 1 LD perf-in.o ld: arch/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118: multiple definition of `traceid_list'; util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/cs-etm.h:118: first defined here make[3]: *** [/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/build/Makefile.build:145: perf-in.o] Error 1 make[2]: *** [Makefile.perf:616: perf-in.o] Error 2 make[1]: *** [Makefile.perf:225: sub-make] Error 2 make: *** [Makefile:70: all] Error 2 The same build succeeds with gcc 9.3.0 -- Thomas
Re: [PATCH 5.2 36/37] vhost: block speculation of translated descriptors
Den 14-09-2019 kl. 11:08, skrev Greg Kroah-Hartman: On Sat, Sep 14, 2019 at 09:15:48AM +0200, Stefan Lippers-Hollmann wrote: Hi On 2019-09-14, Greg Kroah-Hartman wrote: On Sat, Sep 14, 2019 at 02:54:11AM +0200, Stefan Lippers-Hollmann wrote: On 2019-09-13, Greg Kroah-Hartman wrote: From: Michael S. Tsirkin commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream. iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the address is not validated out of node range. [...] Do you have the same problem with Linus's tree right now? Actually, yes I do (I had not tested i386 for 5.3~ within the last ~2 weeks, only amd64). Very similar kernel config, same compiler versions but built in a slightly different environment (built directly on the bare iron, in a amd64 multilib userspace, rather than a pure-i386 chroot on an amd64 kernel). $ git describe v5.3-rc8-36-ga7f89616b737 $ LANG= make ARCH=x86 -j1 bzImage modules CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h CHK kernel/kheaders_data.tar.xz CC [M] drivers/vhost/vhost.o In file included from ./include/linux/export.h:45, from ./include/linux/linkage.h:7, from ./include/linux/kernel.h:8, from ./include/linux/list.h:9, from ./include/linux/wait.h:7, from ./include/linux/eventfd.h:13, from drivers/vhost/vhost.c:13: drivers/vhost/vhost.c: In function 'translate_desc': ./include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2076' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long) 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^ ./include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert' 331 |prefix ## suffix();\ |^~ ./include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ ./include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ ./include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON' 56 | BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \ | ^~~~ drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec' 2076 | array_index_nospec((unsigned long)(addr - node->start), | ^~ make[2]: *** [scripts/Makefile.build:281: drivers/vhost/vhost.o] Error 1 make[1]: *** [scripts/Makefile.build:497: drivers/vhost] Error 2 make: *** [Makefile:1083: drivers] Error 2 $ git revert a89db445fbd7f1f8457b03759aa7343fa530ef6b $ LANG= make ARCH=x86 -j16 bzImage modules CALLscripts/atomic/check-atomics.sh CALLscripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/kheaders_data.tar.xz Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#1) MODPOST 3464 modules $ echo $? 0 $ find . -name vhost\\.ko ./drivers/vhost/vhost.ko I've attached the affected kernel config for v5.3~/ i386. Ok, good, we will be "bug compatible" at the very least now :) When this gets fixed in Linus's tree we can backport the fix here as well. The number of users of that compiler version/configuration is probably pretty low at the moment to want to hold off on this fix. This is now reverted upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d4a3f2abbef73b9e5bb5f12213c275565473588 -- Thomas
Re: [PATCH] Partially revert "mm/memcontrol.c: keep local VM counters in sync with the hierarchical ones"
Den 24-08-2019 kl. 22:57, skrev Andrew Morton: On Sat, 17 Aug 2019 19:15:23 + Roman Gushchin wrote: Fixes: 766a4c19d880 ("mm/memcontrol.c: keep local VM counters in sync with the hierarchical ones") Signed-off-by: Roman Gushchin Cc: Yafang Shao Cc: Johannes Weiner --- mm/memcontrol.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. Oh, I'm sorry, will read and follow next time. Thanks! 766a4c19d880 is not present in 5.2 so no -stable backport is needed, yes? Unfortunately it got added in 5.2.7, so backport is needed. -- Thomas
Re: Regression with the latest iwlwifi-9260-*-46.ucode
Den 06-08-2019 kl. 16:04, skrev Takashi Iwai: On Mon, 05 Aug 2019 14:03:55 +0200, Now we got a feedback from the latest linux-firmware (20190726) and surprising the result was negative. The dmesg after the cold boot is found at: https://bugzilla.suse.com/show_bug.cgi?id=1142128#c26 The kernel is 5.2.3, so it should be new enough. If anything else needed (or something missing), let us know. I read on some forum that some commented that the "Add support for SAR South Korea limitation" fix is needed, but it seemed weird... Anyway, with theese on top of 5.2.7 39bd984c203e86f3 iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version < 41 f5a47fae6aa3eb06 iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT support 0c3d7282233c7b02 iwlwifi: Add support for SAR South Korea limitation We have confirmation from an affected user that its now stable with both older and newer firmwares... And we earlier tried with only the: 39bd984c203e86f3 iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT on version < 41 But that did not help (not that I really expected it since its loading version 46 firmwares anyway) So my guess is that the newer firmware actually subtly expects to get the behaviour of the: 0c3d7282233c7b02 iwlwifi: Add support for SAR South Korea limitation Of course that's still guessing and I assume only Intel fw guys can verify that... -- Thomas
Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n
Den 13-06-2019 kl. 10:42, skrev Greg Kroah-Hartman: I've just reverted it now. If someone can send me a patch series of all of what needs to be applied, in a format that I can actually apply them in, I will be glad to do so. But for now, I'd like to get people's systems building again. That would be basically re-adding the b30a43ac7132 commit and adding the following patch (also attached in case the inlined version gets mangled): From 0d91b155a7f9c1f4a2b360bc2b79dc728aee8b48 Mon Sep 17 00:00:00 2001 From: Thomas Backlund Date: Sat, 15 Jun 2019 12:22:44 +0300 Subject: [PATCH] nouveau: Fix build with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT disabled Not-entirely-upstream-sha1-but-equivalent: bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132) causes the build to fail with: ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! This does not happend upstream as the offending code got removed in: bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around the drm_legacy_mmap() call. Also, as Sven Joachim pointed out, we need to make the check in CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n case return -EINVAL as its done for basically all other gpu drivers, especially in upstream kernels drivers/gpu/drm/ttm/ttm_bo_vm.c as of the upstream commit bed2dd8421. NOTE. This is a minimal stable-only fix for trees where b30a43ac7132 is backported as the build error affects nouveau only. Fixes: b30a43ac7132 ("drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)") Signed-off-by: Thomas Backlund Cc: sta...@vger.kernel.org Cc: Daniel Vetter Cc: Sven Joachim --- drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 1543c2f8d3d3..05d513d54555 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c @@ -169,7 +169,11 @@ nouveau_ttm_mmap(struct file *filp, struct vm_area_struct *vma) struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev); if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) return drm_legacy_mmap(filp, vma); +#else + return -EINVAL; +#endif return ttm_bo_mmap(filp, vma, >ttm.bdev); } -- 2.21.0 >From 0d91b155a7f9c1f4a2b360bc2b79dc728aee8b48 Mon Sep 17 00:00:00 2001 From: Thomas Backlund Date: Sat, 15 Jun 2019 12:22:44 +0300 Subject: [PATCH] nouveau: Fix build with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT disabled Not-entirely-upstream-sha1-but-equivalent: bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132) causes the build to fail with: ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! This does not happend upstream as the offending code got removed in: bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around the drm_legacy_mmap() call. Also, as Sven Joachim pointed out, we need to make the check in CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n case return -EINVAL as its done for basically all other gpu drivers, especially in upstream kernels drivers/gpu/drm/ttm/ttm_bo_vm.c as of the upstream commit bed2dd8421. NOTE. This is a minimal stable-only fix for trees where b30a43ac7132 is backported as the build error affects nouveau only. Fixes: b30a43ac7132 ("drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)") Signed-off-by: Thomas Backlund Cc: sta...@vger.kernel.org Cc: Daniel Vetter Cc: Sven Joachim --- drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 1543c2f8d3d3..05d513d54555 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c @@ -169,7 +169,11 @@ nouveau_ttm_mmap(struct file *filp, struct vm_area_struct *vma) struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev); if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) return drm_legacy_mmap(filp, vma); +#else + return -EINVAL; +#endif return ttm_bo_mmap(filp, vma, >ttm.bdev); } -- 2.21.0
Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
Den 15-06-2019 kl. 08:50, skrev Greg KH: On Fri, Jun 14, 2019 at 04:09:35PM -0600, James Feeney wrote: Hey Everyone On 4/24/19 10:41 AM, Benjamin Tissoires wrote: For a patch to be picked up by stable, it first needs to go in Linus' tree. Currently we are working on 5.1, so any stable patches need to go in 5.1 first. Then, once they hit Linus' tree, the stable team will pick them and backport them in the appropriate stable tree. Hmm - so, I just booted linux 5.1.9, and this patch set is *still* missing from the kernel. Is there anything that we can do about this? What is the git commit id of the patch in Linus's tree? As I said before, it can not be backported until it shows up there first. That would be: d43c17ead879ba7c076dc2f5fd80cd76047c9ff4 and 39b3c3a5fbc5d744114e497d35bf0c12f798c134 -- Thomas
Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n
Den 11-06-2019 kl. 22:43, skrev Sven Joachim: On 2019-06-11 22:08 +0300, Thomas Backlund wrote: Den 11-06-2019 kl. 20:40, skrev Greg Kroah-Hartman: On Tue, Jun 11, 2019 at 07:33:16PM +0200, Daniel Vetter wrote: On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman wrote: On Tue, Jun 11, 2019 at 03:56:35PM +0200, Sven Joachim wrote: Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)") has caused a build failure for me when I actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n): , | Kernel: arch/x86/boot/bzImage is ready (#1) | Building modules, stage 2. | MODPOST 290 modules | ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! | scripts/Makefile.modpost:91: recipe for target '__modpost' failed ` Calling drm_legacy_mmap is definitely not a great idea. I think either we need a custom patch to remove that out on older kernels, or maybe even #ifdef if you want to be super paranoid about breaking stuff ... Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") has removed the use of drm_legacy_mmap from nouveau_ttm.c. Unfortunately that commit does not apply in 5.1.9. Most likely 4.19.50 and 4.14.125 are also affected, I haven't tested them yet. They probably are. Should I just revert this patch in the stable tree, or add some other patch (like the one pointed out here, which seems an odd patch for stable...) ... or backport the above patch, that should be save to do too. Not sure what stable folks prefer? The above patch does not apply to all of the stable branches, so how about I just revert this? People can live with this option not able to turn off for now, and if they really want it, they can use a newer kernel, right? Or add the simple fix suggested by Daniel (if I understand correctly): From: Thomas Backlund Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132) causes the build to fail with: ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around the code using drm_legacy_mmap() Fixes: b30a43ac7132 drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3) Signed-off-by: Thomas Backlund --- drivers/gpu/drm/nouveau/nouveau_ttm.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c @@ -168,8 +168,10 @@ nouveau_ttm_mmap(struct file *filp, stru struct drm_file *file_priv = filp->private_data; struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev); +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) return drm_legacy_mmap(filp, vma); +#endif return ttm_bo_mmap(filp, vma, >ttm.bdev); } That's not quite correct, I am afraid. If CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not defined, you still need to do the test, but return -EINVAL. Something along these lines: diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 1543c2f8d3d3..05d513d54555 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c @@ -169,7 +169,11 @@ nouveau_ttm_mmap(struct file *filp, struct vm_area_struct *vma) struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev); if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) return drm_legacy_mmap(filp, vma); +#else + return -EINVAL; +#endif return ttm_bo_mmap(filp, vma, >ttm.bdev); } At least that builds for me, need to reboot to check whether it works. Cheers, Sven Ah, indeed. thats what basically all other drivers did before bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()"), and in that commit the same check was moved to drivers/gpu/drm/ttm/ttm_bo_vm.c -- Thomas
Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n
Den 11-06-2019 kl. 20:40, skrev Greg Kroah-Hartman: On Tue, Jun 11, 2019 at 07:33:16PM +0200, Daniel Vetter wrote: On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman wrote: On Tue, Jun 11, 2019 at 03:56:35PM +0200, Sven Joachim wrote: Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)") has caused a build failure for me when I actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n): , | Kernel: arch/x86/boot/bzImage is ready (#1) | Building modules, stage 2. | MODPOST 290 modules | ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! | scripts/Makefile.modpost:91: recipe for target '__modpost' failed ` Calling drm_legacy_mmap is definitely not a great idea. I think either we need a custom patch to remove that out on older kernels, or maybe even #ifdef if you want to be super paranoid about breaking stuff ... Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") has removed the use of drm_legacy_mmap from nouveau_ttm.c. Unfortunately that commit does not apply in 5.1.9. Most likely 4.19.50 and 4.14.125 are also affected, I haven't tested them yet. They probably are. Should I just revert this patch in the stable tree, or add some other patch (like the one pointed out here, which seems an odd patch for stable...) ... or backport the above patch, that should be save to do too. Not sure what stable folks prefer? The above patch does not apply to all of the stable branches, so how about I just revert this? People can live with this option not able to turn off for now, and if they really want it, they can use a newer kernel, right? Or add the simple fix suggested by Daniel (if I understand correctly): From: Thomas Backlund Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132) causes the build to fail with: ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around the code using drm_legacy_mmap() Fixes: b30a43ac7132 drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3) Signed-off-by: Thomas Backlund --- drivers/gpu/drm/nouveau/nouveau_ttm.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c @@ -168,8 +168,10 @@ nouveau_ttm_mmap(struct file *filp, stru struct drm_file *file_priv = filp->private_data; struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev); +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) return drm_legacy_mmap(filp, vma); +#endif return ttm_bo_mmap(filp, vma, >ttm.bdev); }
Re: [PATCH 5.1 56/85] doc: Cope with the deprecation of AutoReporter
Den 10-06-2019 kl. 17:05, skrev Greg Kroah-Hartman: On Mon, Jun 10, 2019 at 06:33:40AM -0600, Jonathan Corbet wrote: On Mon, 10 Jun 2019 09:48:40 +0200 Greg Kroah-Hartman wrote: Hm, 2.1 here: Running Sphinx v2.1.0 perhaps Tumbleweed needs to update? :) Heh...trying 2.1 is still on my list of things to do ... :) Anyway, this should not be breaking, if Jon doesn't have any ideas, I'll just drop these changes. The fix for that is 551bd3368a7b (drm/i915: Maintain consistent documentation subsection ordering) which was also marked for stable. Jiri, do you somehow not have that one? It's part of this series, which is probably why it works for me. Don't know why it doesn't work for Jiri, unless he is cherry-picking things? Actualliy it is not. This patch Jiri responded to / points out to break stuff is part of 5.1.8, but the fix in in review queue for 5.1.9 : https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-5.1/drm-i915-maintain-consistent-documentation-subsection-ordering.patch?id=29167bff7a1c0d79dda104c44c262b0bc4cd6644 -- Thomas
Re: perf build broken in 5.1-rc7
Den 01-05-2019 kl. 20:31, skrev Arnaldo Carvalho de Melo: Em Wed, May 01, 2019 at 05:09:59PM +0300, Thomas Backlund escreveu: Den 01-05-2019 kl. 16:07, skrev Arnaldo Carvalho de Melo: Em Tue, Apr 30, 2019 at 04:31:14PM +0300, Thomas Backlund escreveu: Can you check the output for /tmp/build/perf/feature/test-disassembler-four-args.make.output in your system? And also check what is the prototype for the disassembler() routine on mageia7? I guess this is what fails the test: cat /tmp/build/perf/feature/test-disassembler-four-args.make.output /usr/bin/ld: /usr/lib64/libbfd.a(plugin.o): in function `try_load_plugin': /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:243: undefined reference to `dlopen' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:271: undefined reference to `dlsym' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:256: undefined reference to `dlclose' /usr/bin/ld: /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:246: undefined reference to `dlerror' as we allow dynamic linking and loading And we use linker flags: rpm --eval %ldflags -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags Would this help? diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index fe3f97e342fa..6d65874e16c3 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -227,7 +227,7 @@ FEATURE_CHECK_LDFLAGS-libpython-version := $(PYTHON_EMBED_LDOPTS) EATURE_CHECK_LDFLAGS-libaio = -lrt -FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes +FEATURE_CHECK_LDFLAGS-disassembler-four-args = -lbfd -lopcodes -ldl CFLAGS += -fno-omit-frame-pointer CFLAGS += -ggdb3 Yeah, that fixes it and /tmp/build/perf/feature/test-disassembler-four-args.make.output is now empty as wanted. So I guess: Reported-by: Thomas Backlund Tested-by: Thomas Backlund Thanks! -- Thomas
Re: perf build broken in 5.1-rc7
Den 01-05-2019 kl. 17:09, skrev Thomas Backlund: Den 01-05-2019 kl. 16:07, skrev Arnaldo Carvalho de Melo: Em Tue, Apr 30, 2019 at 04:31:14PM +0300, Thomas Backlund escreveu: Den 30-04-2019 kl. 16:06, skrev Song Liu: On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund wrote: Den 30-04-2019 kl. 10:26, skrev Thomas Backlund: Building perf in 5.1-rc5/6/7 fails: Build start: make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all BUILD: Doing 'make -j32' parallel build HOSTCC fixdep.o HOSTLD fixdep-in.o LINK fixdep Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs from latest version at 'arch/x86/include/uapi/asm/vmx.h' diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ... libbfd: [ on ] ... libelf: [ on ] ... libnuma: [ on ] ... numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... libaio: [ on ] ... disassembler-four-args: [ OFF ] Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev And breaks with: CC ui/setup.o util/annotate.c: In function 'symbol__disassemble_bpf': util/annotate.c:1767:29: error: incompatible type for argument 1 of 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' but argument is of type 'bfd *' {aka 'struct bfd *'} extern disassembler_ftype disassembler (enum bfd_architecture arc, ~~^~~ util/annotate.c:1767:16: error: too few arguments to function 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:27: note: declared here extern disassembler_ftype disassembler (enum bfd_architecture arc, ^~~~ CC arch/x86/util/header.o CC arch/x86/util/tsc.o CC arch/x86/util/pmu.o mv: cannot stat 'util/.annotate.o.tmp': No such file or directory CC bench/futex-requeue.o CC arch/x86/util/kvm-stat.o make[4]: *** [/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: util/annotate.o] Error 1 make[4]: *** Waiting for unfinished jobs CC util/build-id.o And I forgot... Reverting: From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001 From: Song Liu Date: Mon, 11 Mar 2019 22:30:48 -0700 Subject: perf annotate: Enable annotation of BPF programs Makes it build again. -- Thomas Hi Thomas, Which system are you running this test on? I would like to repro it in a VM. Thanks, Song Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month. Basesystem is: binutils-2.32-5.mga7 (includes all fixes from upstream binutils-2_32-branch) gcc-8.3.1-0.20190419.2.mga7 glibc-2.29-7.mga7 (includes all fixes from upstream glibc release/2.29/master branch up to 2019-04-15 for now) kernel-desktop-5.1.0-0.rc7.1.mga7 kernel-userspace-headers-5.1.0-0.rc7.1.mga7 Ok, so the steps are: 1) the feature test, the small C program that we try to build is: [acme@quaco perf]$ cat tools/build/feature/test-disassembler-four-args.c // SPDX-License-Identifier: GPL-2.0 #include #include int main(void) { bfd *abfd = bfd_openr(NULL, NULL); disassembler(bfd_get_arch(abfd), bfd_big_endian(abfd), bfd_get_mach(abfd), abfd); return 0; } [acme@quaco perf]$ And here in my fedora29 system it ends up producing the following file, when built with: $ make O=/tmp/build/perf -C tools/perf install-bin [acme@quaco perf]$ cat /tmp/build/perf/feature/test-disassembler-four-args.make.output [acme@quaco perf]$ [acme@quaco perf]$ file /tmp/build/perf/feature/test-disassembler-four-args.bin /tmp/build/perf/feature/test
Re: perf build broken in 5.1-rc7
Den 01-05-2019 kl. 16:07, skrev Arnaldo Carvalho de Melo: Em Tue, Apr 30, 2019 at 04:31:14PM +0300, Thomas Backlund escreveu: Den 30-04-2019 kl. 16:06, skrev Song Liu: On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund wrote: Den 30-04-2019 kl. 10:26, skrev Thomas Backlund: Building perf in 5.1-rc5/6/7 fails: Build start: make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all BUILD: Doing 'make -j32' parallel build HOSTCC fixdep.o HOSTLD fixdep-in.o LINK fixdep Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs from latest version at 'arch/x86/include/uapi/asm/vmx.h' diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h Auto-detecting system features: ... dwarf: [ on ] ...dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libnuma: [ on ] ...numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ...libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ...libaio: [ on ] ...disassembler-four-args: [ OFF ] Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev And breaks with: CC ui/setup.o util/annotate.c: In function 'symbol__disassemble_bpf': util/annotate.c:1767:29: error: incompatible type for argument 1 of 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' but argument is of type 'bfd *' {aka 'struct bfd *'} extern disassembler_ftype disassembler (enum bfd_architecture arc, ~~^~~ util/annotate.c:1767:16: error: too few arguments to function 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:27: note: declared here extern disassembler_ftype disassembler (enum bfd_architecture arc, ^~~~ CC arch/x86/util/header.o CC arch/x86/util/tsc.o CC arch/x86/util/pmu.o mv: cannot stat 'util/.annotate.o.tmp': No such file or directory CC bench/futex-requeue.o CC arch/x86/util/kvm-stat.o make[4]: *** [/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: util/annotate.o] Error 1 make[4]: *** Waiting for unfinished jobs CC util/build-id.o And I forgot... Reverting: From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001 From: Song Liu Date: Mon, 11 Mar 2019 22:30:48 -0700 Subject: perf annotate: Enable annotation of BPF programs Makes it build again. -- Thomas Hi Thomas, Which system are you running this test on? I would like to repro it in a VM. Thanks, Song Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month. Basesystem is: binutils-2.32-5.mga7 (includes all fixes from upstream binutils-2_32-branch) gcc-8.3.1-0.20190419.2.mga7 glibc-2.29-7.mga7 (includes all fixes from upstream glibc release/2.29/master branch up to 2019-04-15 for now) kernel-desktop-5.1.0-0.rc7.1.mga7 kernel-userspace-headers-5.1.0-0.rc7.1.mga7 Ok, so the steps are: 1) the feature test, the small C program that we try to build is: [acme@quaco perf]$ cat tools/build/feature/test-disassembler-four-args.c // SPDX-License-Identifier: GPL-2.0 #include #include int main(void) { bfd *abfd = bfd_openr(NULL, NULL); disassembler(bfd_get_arch(abfd), bfd_big_endian(abfd), bfd_get_mach(abfd), abfd); return 0; } [acme@quaco perf]$ And here in my fedora29 system it ends up producing the following file, when built with: $ make O=/tmp/build/perf -C tools/perf install-bin [acme@quaco perf]$ cat /tmp/build/perf/feature/test-disassembler-four-args.make.output [acme@quaco perf]$ [acme@quaco perf]$ file /tmp/build/perf/feature/test-disassembler-four-args.bin /tmp/build/perf/feature/test
Re: perf build broken in 5.1-rc7
Den 01-05-2019 kl. 06:37, skrev Song Liu: On Tue, Apr 30, 2019 at 6:31 AM Thomas Backlund wrote: Den 30-04-2019 kl. 16:06, skrev Song Liu: On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund wrote: Den 30-04-2019 kl. 10:26, skrev Thomas Backlund: Building perf in 5.1-rc5/6/7 fails: Build start: make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all BUILD: Doing 'make -j32' parallel build HOSTCC fixdep.o HOSTLD fixdep-in.o LINK fixdep Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs from latest version at 'arch/x86/include/uapi/asm/vmx.h' diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h Auto-detecting system features: ... dwarf: [ on ] ...dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libnuma: [ on ] ...numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ...libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ...libaio: [ on ] ...disassembler-four-args: [ OFF ] Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev And breaks with: CC ui/setup.o util/annotate.c: In function 'symbol__disassemble_bpf': util/annotate.c:1767:29: error: incompatible type for argument 1 of 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' but argument is of type 'bfd *' {aka 'struct bfd *'} extern disassembler_ftype disassembler (enum bfd_architecture arc, ~~^~~ util/annotate.c:1767:16: error: too few arguments to function 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:27: note: declared here extern disassembler_ftype disassembler (enum bfd_architecture arc, ^~~~ CC arch/x86/util/header.o CC arch/x86/util/tsc.o CC arch/x86/util/pmu.o mv: cannot stat 'util/.annotate.o.tmp': No such file or directory CC bench/futex-requeue.o CC arch/x86/util/kvm-stat.o make[4]: *** [/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: util/annotate.o] Error 1 make[4]: *** Waiting for unfinished jobs CC util/build-id.o And I forgot... Reverting: From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001 From: Song Liu Date: Mon, 11 Mar 2019 22:30:48 -0700 Subject: perf annotate: Enable annotation of BPF programs Makes it build again. -- Thomas Hi Thomas, Which system are you running this test on? I would like to repro it in a VM. Thanks, Song Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month. Basesystem is: binutils-2.32-5.mga7 (includes all fixes from upstream binutils-2_32-branch) gcc-8.3.1-0.20190419.2.mga7 glibc-2.29-7.mga7 (includes all fixes from upstream glibc release/2.29/master branch up to 2019-04-15 for now) kernel-desktop-5.1.0-0.rc7.1.mga7 kernel-userspace-headers-5.1.0-0.rc7.1.mga7 -- Thomas I am trying to install Mageia 7 beta 3, but hit some issue. While I try fix it, could you please try clean everything under tools/ and retry: make -C tools/ clean make -C tools/perf -j Still fails: util/annotate.c: In function 'symbol__disassemble_bpf': util/annotate.c:1767:29: error: incompatible type for argument 1 of 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' but argument is of type 'bfd *' {aka 'struct bfd *'} extern disassembler_ftype disassembler (enum bfd_architecture arc, ~~^~~ util/annotate.c:1767:16: error: too few arguments to function 'disassembler' disassemble = disassembler(bfdf
Re: perf build broken in 5.1-rc7
Den 30-04-2019 kl. 16:06, skrev Song Liu: On Tue, Apr 30, 2019 at 12:55 AM Thomas Backlund wrote: Den 30-04-2019 kl. 10:26, skrev Thomas Backlund: Building perf in 5.1-rc5/6/7 fails: Build start: make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all BUILD: Doing 'make -j32' parallel build HOSTCC fixdep.o HOSTLD fixdep-in.o LINK fixdep Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs from latest version at 'arch/x86/include/uapi/asm/vmx.h' diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h Auto-detecting system features: ... dwarf: [ on ] ...dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libnuma: [ on ] ...numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ...libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ...libaio: [ on ] ...disassembler-four-args: [ OFF ] Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev And breaks with: CC ui/setup.o util/annotate.c: In function 'symbol__disassemble_bpf': util/annotate.c:1767:29: error: incompatible type for argument 1 of 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' but argument is of type 'bfd *' {aka 'struct bfd *'} extern disassembler_ftype disassembler (enum bfd_architecture arc, ~~^~~ util/annotate.c:1767:16: error: too few arguments to function 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:27: note: declared here extern disassembler_ftype disassembler (enum bfd_architecture arc, ^~~~ CC arch/x86/util/header.o CC arch/x86/util/tsc.o CC arch/x86/util/pmu.o mv: cannot stat 'util/.annotate.o.tmp': No such file or directory CC bench/futex-requeue.o CC arch/x86/util/kvm-stat.o make[4]: *** [/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: util/annotate.o] Error 1 make[4]: *** Waiting for unfinished jobs CC util/build-id.o And I forgot... Reverting: From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001 From: Song Liu Date: Mon, 11 Mar 2019 22:30:48 -0700 Subject: perf annotate: Enable annotation of BPF programs Makes it build again. -- Thomas Hi Thomas, Which system are you running this test on? I would like to repro it in a VM. Thanks, Song Mageia Cauldron currently stabilizing to become Mageia 7 in ~1 month. Basesystem is: binutils-2.32-5.mga7 (includes all fixes from upstream binutils-2_32-branch) gcc-8.3.1-0.20190419.2.mga7 glibc-2.29-7.mga7 (includes all fixes from upstream glibc release/2.29/master branch up to 2019-04-15 for now) kernel-desktop-5.1.0-0.rc7.1.mga7 kernel-userspace-headers-5.1.0-0.rc7.1.mga7 -- Thomas
Re: perf build broken in 5.1-rc7
Den 30-04-2019 kl. 10:26, skrev Thomas Backlund: Building perf in 5.1-rc5/6/7 fails: Build start: make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all BUILD: Doing 'make -j32' parallel build HOSTCC fixdep.o HOSTLD fixdep-in.o LINK fixdep Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs from latest version at 'arch/x86/include/uapi/asm/vmx.h' diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ... libbfd: [ on ] ... libelf: [ on ] ... libnuma: [ on ] ... numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... libaio: [ on ] ... disassembler-four-args: [ OFF ] Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev And breaks with: CC ui/setup.o util/annotate.c: In function 'symbol__disassemble_bpf': util/annotate.c:1767:29: error: incompatible type for argument 1 of 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' but argument is of type 'bfd *' {aka 'struct bfd *'} extern disassembler_ftype disassembler (enum bfd_architecture arc, ~~^~~ util/annotate.c:1767:16: error: too few arguments to function 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:27: note: declared here extern disassembler_ftype disassembler (enum bfd_architecture arc, ^~~~ CC arch/x86/util/header.o CC arch/x86/util/tsc.o CC arch/x86/util/pmu.o mv: cannot stat 'util/.annotate.o.tmp': No such file or directory CC bench/futex-requeue.o CC arch/x86/util/kvm-stat.o make[4]: *** [/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: util/annotate.o] Error 1 make[4]: *** Waiting for unfinished jobs CC util/build-id.o And I forgot... Reverting: From 6987561c9e86eace45f2dbb0c564964a63f4150a Mon Sep 17 00:00:00 2001 From: Song Liu Date: Mon, 11 Mar 2019 22:30:48 -0700 Subject: perf annotate: Enable annotation of BPF programs Makes it build again. -- Thomas
perf build broken in 5.1-rc7
Building perf in 5.1-rc5/6/7 fails: Build start: make -s -C tools/perf NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 NO_JVMTI=1 prefix=/usr lib=lib64 all BUILD: Doing 'make -j32' parallel build HOSTCC fixdep.o HOSTLD fixdep-in.o LINK fixdep Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs from latest version at 'arch/x86/include/uapi/asm/vmx.h' diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h Auto-detecting system features: ... dwarf: [ on ] ... dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ... libbfd: [ on ] ... libelf: [ on ] ... libnuma: [ on ] ... numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ... libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... libaio: [ on ] ... disassembler-four-args: [ OFF ] Makefile.config:473: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev Makefile.config:853: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev And breaks with: CC ui/setup.o util/annotate.c: In function 'symbol__disassemble_bpf': util/annotate.c:1767:29: error: incompatible type for argument 1 of 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:63: note: expected 'enum bfd_architecture' but argument is of type 'bfd *' {aka 'struct bfd *'} extern disassembler_ftype disassembler (enum bfd_architecture arc, ~~^~~ util/annotate.c:1767:16: error: too few arguments to function 'disassembler' disassemble = disassembler(bfdf); ^~~~ In file included from util/annotate.c:1689: /usr/include/dis-asm.h:325:27: note: declared here extern disassembler_ftype disassembler (enum bfd_architecture arc, ^~~~ CC arch/x86/util/header.o CC arch/x86/util/tsc.o CC arch/x86/util/pmu.o mv: cannot stat 'util/.annotate.o.tmp': No such file or directory CC bench/futex-requeue.o CC arch/x86/util/kvm-stat.o make[4]: *** [/work/rpmbuild/BUILD/kernel-x86_64/linux-5.0/tools/build/Makefile.build:97: util/annotate.o] Error 1 make[4]: *** Waiting for unfinished jobs CC util/build-id.o -- Thomas
Re: [PATCH 5.0 39/93] perf top: Delete the evlist before perf_session, fixing heap-use-after-free issue
fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==27350==ABORTING Signed-off-by: Changbin Du Reviewed-by: Jiri Olsa Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Steven Rostedt (VMware) Link: http://lkml.kernel.org/r/20190316080556.3075-8-changbin...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/builtin-top.c | 42 ++-- 1 file changed, 19 insertions(+), 23 deletions(-) diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c index f64e312db787..9b215007924b 100644 --- a/tools/perf/builtin-top.c +++ b/tools/perf/builtin-top.c @@ -1192,23 +1192,19 @@ static int __cmd_top(struct perf_top *top) pthread_t thread, thread_process; int ret; - top->session = perf_session__new(NULL, false, NULL); - if (top->session == NULL) - return -1; - if (!top->annotation_opts.objdump_path) { ret = perf_env__lookup_objdump(>session->header.env, >annotation_opts.objdump_path); if (ret) - goto out_delete; + return ret; } ret = callchain_param__setup_sample_type(_param); if (ret) - goto out_delete; + return ret; if (perf_session__register_idle_thread(top->session) < 0) - goto out_delete; + return ret; if (top->nr_threads_synthesize > 1) perf_set_multithreaded(); @@ -1224,13 +1220,18 @@ static int __cmd_top(struct perf_top *top) if (perf_hpp_list.socket) { ret = perf_env__read_cpu_topology_map(_env); - if (ret < 0) - goto out_err_cpu_topo; + if (ret < 0) { + char errbuf[BUFSIZ]; + const char *err = str_error_r(-ret, errbuf, sizeof(errbuf)); + + ui__error("Could not read the CPU topology map: %s\n", err); + return ret; + } } ret = perf_top__start_counters(top); if (ret) - goto out_delete; + return ret; ret = perf_evlist__apply_drv_configs(evlist, , _term); if (ret) { @@ -1257,7 +1258,7 @@ static int __cmd_top(struct perf_top *top) ret = -1; if (pthread_create(_process, NULL, process_thread, top)) { ui__error("Could not create process thread.\n"); - goto out_delete; + return ret; } if (pthread_create(, NULL, (use_browser > 0 ? display_thread_tui : @@ -1301,19 +1302,7 @@ static int __cmd_top(struct perf_top *top) out_join_thread: pthread_cond_signal(>qe.cond); pthread_join(thread_process, NULL); -out_delete: - perf_session__delete(top->session); - top->session = NULL; - return ret; - -out_err_cpu_topo: { - char errbuf[BUFSIZ]; - const char *err = str_error_r(-ret, errbuf, sizeof(errbuf)); - - ui__error("Could not read the CPU topology map: %s\n", err); - goto out_delete; -} } static int @@ -1644,10 +1633,17 @@ int cmd_top(int argc, const char **argv) signal(SIGWINCH, winch_sig); } + top.session = perf_session__new(NULL, false, NULL); + if (top.session == NULL) { + status = -1; + goto out_delete_evlist; + } + status = __cmd_top(); out_delete_evlist: perf_evlist__delete(top.evlist); + perf_session__delete(top.session); return status; } This one breaks perf build like this: builtin-top.c: In function '__cmd_top': builtin-top.c:1241:3: error: label 'out_delete' used but not defined goto out_delete; Suggested 5.0 specific fix attached. Subject: perf top: fix builtin-top build breakage. In 5.0 -stable queue, backported upstream commit 0dba9e4be95b (perf top: Delete the evlist before perf_session, fixing heap-use-after-free issue) causes the perf build to break with: builtin-top.c: In function '__cmd_top': builtin-top.c:1241:3: error: label 'out_delete' used but not defined goto out_delete; ^~~~ This does not happend in upstream linus tree as the affected code is removed in commit 159b0da50adb (perf pmu: Remove set_drv_config API) that I assume is not ok to backport in -stable trees. Fix it up like other code in commit 0dba9e4be95b. Signed-
Re: [PATCH 5.0 05/93] perf data: Dont store auxtrace index for directory data file
Den 18-04-2019 kl. 20:56, skrev Greg Kroah-Hartman: [ Upstream commit cd3dd8dd8ff62374d90cb3f2e54b8c94106c7810 ] We can't store the auxtrace index when we store into multiple files, because we keep only offset for it, not the file. The auxtrace data will be processed correctly in the 'pipe' mode. Signed-off-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Andi Kleen Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/20190308134745.5057-3-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/builtin-record.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index 882285fb9f64..3fd154f1701b 100644 --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -386,7 +386,7 @@ static int record__process_auxtrace(struct perf_tool *tool, size_t padding; u8 pad[8] = {0}; - if (!perf_data__is_pipe(data)) { + if (!perf_data__is_pipe(data) && !perf_data__is_dir(data)) { off_t file_offset; int fd = perf_data__fd(data); int err; This breaks the build with: builtin-record.c: In function 'record__process_auxtrace': builtin-record.c:389:36: warning: implicit declaration of function 'perf_data__is_dir'; did you mean 'perf_data__is_pipe'? [-Wimplicit-function-declaration] if (!perf_data__is_pipe(data) && !perf_data__is_dir(data)) { ^ Looks like it depends atleast on: commit ec65def1045e4c7817b7f741a86dadae82877a93 Author: Jiri Olsa Date: Fri Mar 8 14:47:35 2019 +0100 perf data: Support having perf.data stored as a directory Maybe better to drop it. -- Thomas
Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn
Den 23-12-2018 kl. 01:28, skrev Linus Torvalds: On Sat, Dec 22, 2018 at 3:07 PM Christian Brauner wrote: However, for this case should I resend the revert? Since I was pointed at the original email thread, I just picked it up from there directly. It still applied cleanly, nothing had changed in that area. Linus This should also be picked up for 4.19 lts Greg, it's now upstream as: From 94f82008ce30e2624537d240d64ce718255e0b80 Mon Sep 17 00:00:00 2001 From: Christian Brauner Date: Thu, 5 Jul 2018 17:51:20 +0200 Subject: Revert "vfs: Allow userns root to call mknod on owned filesystems." -- Thomas
Re: [PATCH AUTOSEL 4.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF
Den 2018-12-03 kl. 11:22, skrev Sasha Levin: > > This is a case where theory collides with the real world. Yes, our QA is > lacking, but we don't have the option of not doing the current process. > If we stop backporting until a future data where our QA problem is > solved we'll end up with what we had before: users stuck on ancient > kernels without a way to upgrade. > Sorry, but you seem to be living in a different "real world"... People stay on "ancient kernels" that "just works" instead of updating to a newer one that "hopefully/maybe/... works" > With the current model we're aware that bugs sneak through, but we try > to deal with it by both improving our QA, and encouraging users to do > their own extensive QA. If we encourage users to update frequently we > can keep improving our process and the quality of kernels will keep > getting better. And here you want to turn/force users into QA ... good luck with that. In reality they wont "update frequently", instead they will stop updating when they have something that works... and start ignoring updates as they expect something "to break as usual" as they actually need to get some real work done too... > > We simply can't go back to the "enterprise distro" days. > Maybe so, but we should atleast get back to having "stable" or "longterm" actually mean something again... Or what does it say when distros starts thinking about ignoring (and some already do) stable/longterm trees because there is _way_ too much questionable changes coming through, even overriding maintainers to the point where they basically state "we dont care about monitoring stable trees anymore, as they add whatever they want anyway"... And pretending that every fix is important enough to backport, and saying if you dont take everything you have an "unsecure" kernel wont help, as reality has shown from time to time that backports can/will open up a new issue instead for no good reason Wich for distros starts to mean, switch back to selectively taking fixes for _known_ security issues are considered way better choice End result, no-one cares about -stable trees -> no-one uses them -> a lot of wasted work for nothing... -- Thomas
Re: [PATCH AUTOSEL 4.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF
Den 2018-12-03 kl. 11:22, skrev Sasha Levin: > > This is a case where theory collides with the real world. Yes, our QA is > lacking, but we don't have the option of not doing the current process. > If we stop backporting until a future data where our QA problem is > solved we'll end up with what we had before: users stuck on ancient > kernels without a way to upgrade. > Sorry, but you seem to be living in a different "real world"... People stay on "ancient kernels" that "just works" instead of updating to a newer one that "hopefully/maybe/... works" > With the current model we're aware that bugs sneak through, but we try > to deal with it by both improving our QA, and encouraging users to do > their own extensive QA. If we encourage users to update frequently we > can keep improving our process and the quality of kernels will keep > getting better. And here you want to turn/force users into QA ... good luck with that. In reality they wont "update frequently", instead they will stop updating when they have something that works... and start ignoring updates as they expect something "to break as usual" as they actually need to get some real work done too... > > We simply can't go back to the "enterprise distro" days. > Maybe so, but we should atleast get back to having "stable" or "longterm" actually mean something again... Or what does it say when distros starts thinking about ignoring (and some already do) stable/longterm trees because there is _way_ too much questionable changes coming through, even overriding maintainers to the point where they basically state "we dont care about monitoring stable trees anymore, as they add whatever they want anyway"... And pretending that every fix is important enough to backport, and saying if you dont take everything you have an "unsecure" kernel wont help, as reality has shown from time to time that backports can/will open up a new issue instead for no good reason Wich for distros starts to mean, switch back to selectively taking fixes for _known_ security issues are considered way better choice End result, no-one cares about -stable trees -> no-one uses them -> a lot of wasted work for nothing... -- Thomas
Re: [PATCH 00/39 v7] PTI support for x86-32
Den 2018-07-11 kl. 20:28, skrev Jiri Kosina: On Wed, 11 Jul 2018, Linus Torvalds wrote: It's the testing that worries me most. Pretty much no developers run 32-bit any more, and I'd be most worried about the odd interactions that might be hw-specific. Some crazy EFI mapping setup or the similar odd case that simply requires a particular configuration or setup. But I guess those issues will never be found until we just spring this all on the unsuspecting public. FWIW we shipped Joerg's 32bit KAISER kernel out to our 32bit users (on old product where we still support it) on Apr 25th already (and some issues have been identified since then because of that). So it (or its port to 3.0, to be more precise :p) already did receive some crowd-testing. And Mageia has had v2 since February 13th patched into 4.14 -longterm, then updated to v3 at March 5th, and updated to v4 at March 19th and been running that since then (since v5 is rebased on v4.17 we stayed with v4) So, here is another "lets merge it upstream" vote :) -- Thomas
Re: [PATCH 00/39 v7] PTI support for x86-32
Den 2018-07-11 kl. 20:28, skrev Jiri Kosina: On Wed, 11 Jul 2018, Linus Torvalds wrote: It's the testing that worries me most. Pretty much no developers run 32-bit any more, and I'd be most worried about the odd interactions that might be hw-specific. Some crazy EFI mapping setup or the similar odd case that simply requires a particular configuration or setup. But I guess those issues will never be found until we just spring this all on the unsuspecting public. FWIW we shipped Joerg's 32bit KAISER kernel out to our 32bit users (on old product where we still support it) on Apr 25th already (and some issues have been identified since then because of that). So it (or its port to 3.0, to be more precise :p) already did receive some crowd-testing. And Mageia has had v2 since February 13th patched into 4.14 -longterm, then updated to v3 at March 5th, and updated to v4 at March 19th and been running that since then (since v5 is rebased on v4.17 we stayed with v4) So, here is another "lets merge it upstream" vote :) -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-07 kl. 22:40, skrev Linus Torvalds: On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund wrote: I can work around it for now (or keep the revert in our kernel builds for now) until it gets properly fixed... So rather than doing the revert, it's probably better if your workaround just does make ARCH=i386 oldconfig (or maybe even just a "export ARCH=i386" in the environment) That should get you to continue to otherwise do the same thing. And if it turns out that your flow is the *only* one affected by this, and nobody else complains, maybe we can just say "yeah, slight change in build rules, easy to work around" and leave it at that. Linus Yeah, I can live with that too :) I just wanted to point out the regression in case it was not (sort of) intentional... -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-07 kl. 22:40, skrev Linus Torvalds: On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund wrote: I can work around it for now (or keep the revert in our kernel builds for now) until it gets properly fixed... So rather than doing the revert, it's probably better if your workaround just does make ARCH=i386 oldconfig (or maybe even just a "export ARCH=i386" in the environment) That should get you to continue to otherwise do the same thing. And if it turns out that your flow is the *only* one affected by this, and nobody else complains, maybe we can just say "yeah, slight change in build rules, easy to work around" and leave it at that. Linus Yeah, I can live with that too :) I just wanted to point out the regression in case it was not (sort of) intentional... -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-06 kl. 06:30, skrev Masahiro Yamada: Hi Linus, 2018-06-06 11:19 GMT+09:00 Linus Torvalds : On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds wrote: But once you *have* that particular Kconfig, I do think that "make oldconfig" should just work. And it apparently used to. So I think this is a behavioral regression. That doesn't necessarily mean that he fix should be to revert. If this is a regression, I am OK with the revert, and it is the only quick solution. It is a regression as the same "make oldconfig routine" has been working iirc since atleast 2.4 series kernels :) But I dont see it as needing a "quick solution" revert if the "kconfig: only write '# CONFIG_FOO is not set' for visible symbols" is considered a "useful thing we want to keep"... I'd rather think waiting/working a bit for a proper fix is the better way then... I can work around it for now (or keep the revert in our kernel builds for now) until it gets properly fixed... Feel free to cc me on suggested fixes to test -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-06 kl. 06:30, skrev Masahiro Yamada: Hi Linus, 2018-06-06 11:19 GMT+09:00 Linus Torvalds : On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds wrote: But once you *have* that particular Kconfig, I do think that "make oldconfig" should just work. And it apparently used to. So I think this is a behavioral regression. That doesn't necessarily mean that he fix should be to revert. If this is a regression, I am OK with the revert, and it is the only quick solution. It is a regression as the same "make oldconfig routine" has been working iirc since atleast 2.4 series kernels :) But I dont see it as needing a "quick solution" revert if the "kconfig: only write '# CONFIG_FOO is not set' for visible symbols" is considered a "useful thing we want to keep"... I'd rather think waiting/working a bit for a proper fix is the better way then... I can work around it for now (or keep the revert in our kernel builds for now) until it gets properly fixed... Feel free to cc me on suggested fixes to test -- Thomas
Re: python errors in tools/testing/selftests/tc-testing - IGNORE
Den 2018-06-05 kl. 23:10, skrev Thomas Backlund: Compiling /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py ... File "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", line 18 print('This script must be run with root privileges', file=sys.stderr) ^ SyntaxError: invalid syntax Caused by: commit f6926e85eee9be08d05170af3a2266b8d7f9cdef Author: Brenda J. Butler Date: Wed Feb 14 14:08:55 2018 -0500 tools: tc-testing: rootPlugin Move the functionality that checks for root permissions into a plugin. and: Compiling /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py ... File "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", line 167 print('', file=sys.stderr) ^ SyntaxError: invalid syntax Caused by: commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd Author: Brenda J. Butler Date: Wed Feb 14 14:08:54 2018 -0500 tools: tc-testing: Introduce plugin architecture And this system has: $ python3 -V Python 3.5.3 $ python -V Python 2.7.15 This one on the other hand seems to be a toolchain issue... rpmbuild calls out to /usr/lib/rpm/brp-python-bytecompile /usr/bin/python which basically in this case seems to try to parse python3 code with python2 and it falls over... So I've disabled bytecompiling on kernel builds until I can check the toolchain behaviour... -- Thomas
Re: python errors in tools/testing/selftests/tc-testing - IGNORE
Den 2018-06-05 kl. 23:10, skrev Thomas Backlund: Compiling /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py ... File "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", line 18 print('This script must be run with root privileges', file=sys.stderr) ^ SyntaxError: invalid syntax Caused by: commit f6926e85eee9be08d05170af3a2266b8d7f9cdef Author: Brenda J. Butler Date: Wed Feb 14 14:08:55 2018 -0500 tools: tc-testing: rootPlugin Move the functionality that checks for root permissions into a plugin. and: Compiling /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py ... File "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", line 167 print('', file=sys.stderr) ^ SyntaxError: invalid syntax Caused by: commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd Author: Brenda J. Butler Date: Wed Feb 14 14:08:54 2018 -0500 tools: tc-testing: Introduce plugin architecture And this system has: $ python3 -V Python 3.5.3 $ python -V Python 2.7.15 This one on the other hand seems to be a toolchain issue... rpmbuild calls out to /usr/lib/rpm/brp-python-bytecompile /usr/bin/python which basically in this case seems to try to parse python3 code with python2 and it falls over... So I've disabled bytecompiling on kernel builds until I can check the toolchain behaviour... -- Thomas
python errors in tools/testing/selftests/tc-testing (was: Linux 4.17)
Compiling /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py ... File "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", line 18 print('This script must be run with root privileges', file=sys.stderr) ^ SyntaxError: invalid syntax Caused by: commit f6926e85eee9be08d05170af3a2266b8d7f9cdef Author: Brenda J. Butler Date: Wed Feb 14 14:08:55 2018 -0500 tools: tc-testing: rootPlugin Move the functionality that checks for root permissions into a plugin. and: Compiling /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py ... File "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", line 167 print('', file=sys.stderr) ^ SyntaxError: invalid syntax Caused by: commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd Author: Brenda J. Butler Date: Wed Feb 14 14:08:54 2018 -0500 tools: tc-testing: Introduce plugin architecture And this system has: $ python3 -V Python 3.5.3 $ python -V Python 2.7.15 -- Thomas
python errors in tools/testing/selftests/tc-testing (was: Linux 4.17)
Compiling /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py ... File "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", line 18 print('This script must be run with root privileges', file=sys.stderr) ^ SyntaxError: invalid syntax Caused by: commit f6926e85eee9be08d05170af3a2266b8d7f9cdef Author: Brenda J. Butler Date: Wed Feb 14 14:08:55 2018 -0500 tools: tc-testing: rootPlugin Move the functionality that checks for root permissions into a plugin. and: Compiling /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py ... File "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", line 167 print('', file=sys.stderr) ^ SyntaxError: invalid syntax Caused by: commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd Author: Brenda J. Butler Date: Wed Feb 14 14:08:54 2018 -0500 tools: tc-testing: Introduce plugin architecture And this system has: $ python3 -V Python 3.5.3 $ python -V Python 2.7.15 -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-05 kl. 22:13, skrev Linus Torvalds: On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund wrote: but why do you care? Because without it running the build in the 32bit chroot will get the initial reported issue: Ahh. I can re-create that now. Yes, doing make ARCH=i386 allnoconfig followed by make oldconfig is broken. And doing a trivial "git bisect run" to pinpoint where CONFIG_64BIT goes away gives us f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit which does that "kconfig: only write '# CONFIG_FOO is not set' for visible symbols" and it turns out that CONFIG_64BIT is not a visible symbol on x86-32, because that question is disabled when ARCH != "x86". bool "64-bit kernel" if ARCH = "x86" And the problem with that, is that *next* time around this config file is used, because we don't have that # CONFIG_64BIT is not set line, we don't turn it into CONFIG_64BIT=n and then the "depends on" in X86_64 config X86_64 def_bool y depends on 64BIT no longer hides it. Hmm. Ulf, Masahiro, comments? Should we just revert that commit? Thomas, can you verify that a git revert f467c5640c29ad258c3cd8186a776c82fc3b8057 fixes the problem for you? Linus Yep, that fixes it so it works both in the 32bit chroot and on the 64bit host -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-05 kl. 22:13, skrev Linus Torvalds: On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund wrote: but why do you care? Because without it running the build in the 32bit chroot will get the initial reported issue: Ahh. I can re-create that now. Yes, doing make ARCH=i386 allnoconfig followed by make oldconfig is broken. And doing a trivial "git bisect run" to pinpoint where CONFIG_64BIT goes away gives us f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit which does that "kconfig: only write '# CONFIG_FOO is not set' for visible symbols" and it turns out that CONFIG_64BIT is not a visible symbol on x86-32, because that question is disabled when ARCH != "x86". bool "64-bit kernel" if ARCH = "x86" And the problem with that, is that *next* time around this config file is used, because we don't have that # CONFIG_64BIT is not set line, we don't turn it into CONFIG_64BIT=n and then the "depends on" in X86_64 config X86_64 def_bool y depends on 64BIT no longer hides it. Hmm. Ulf, Masahiro, comments? Should we just revert that commit? Thomas, can you verify that a git revert f467c5640c29ad258c3cd8186a776c82fc3b8057 fixes the problem for you? Linus Yep, that fixes it so it works both in the 32bit chroot and on the 64bit host -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-05 kl. 21:38, skrev Linus Torvalds: On Tue, Jun 5, 2018 at 11:23 AM Thomas Backlund wrote: # -# CONFIG_64BIT is not set So something _does_ strip away the needed config bit Why do you need it? I get CONFIG_X86_32=y CONFIG_X86=y and CONFIG_64BIT never gets set. It is true that I don't get the # CONFIG_64BIT is not set line, but why do you care? Linus Because without it running the build in the 32bit chroot will get the initial reported issue: $ uname -m i686 $ make oldconfig scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * Linux/x86 4.17.0 Kernel Configuration * 64-bit kernel (64BIT) [Y/n/?] (NEW) which breaks our buildbots running in chroots... Now I can work around it by adding the config bit myself, but I'd like to understand what changed and why... -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-05 kl. 21:38, skrev Linus Torvalds: On Tue, Jun 5, 2018 at 11:23 AM Thomas Backlund wrote: # -# CONFIG_64BIT is not set So something _does_ strip away the needed config bit Why do you need it? I get CONFIG_X86_32=y CONFIG_X86=y and CONFIG_64BIT never gets set. It is true that I don't get the # CONFIG_64BIT is not set line, but why do you care? Linus Because without it running the build in the 32bit chroot will get the initial reported issue: $ uname -m i686 $ make oldconfig scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * Linux/x86 4.17.0 Kernel Configuration * 64-bit kernel (64BIT) [Y/n/?] (NEW) which breaks our buildbots running in chroots... Now I can work around it by adding the config bit myself, but I'd like to understand what changed and why... -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-05 kl. 21:11, skrev Linus Torvalds: On Tue, Jun 5, 2018 at 10:51 AM Thomas Backlund wrote: Is this intentional ? If so, why ? If not, how can I fix it ? It shouldn't be intentional. And I don't see anythin ghaving changed in this area. We still have config 64BIT bool "64-bit kernel" if ARCH = "x86" default ARCH != "i386" which is what it was in 4.16 too. Of course, we also have (in the main Makefile) SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ and ARCH?= $(SUBARCH) so if you don't set ARCH explicitly, it will always translate "i686" into "x86", so it will default to 64-bit. None of this is new to 4.17, though. Are you sure you didn't use to have an ARCH=i386 somewhere? Because this works for me: make ARCH=i386 oldconfig and it's how I have done cross-builds before (although honestly, I don't do them very often). But adding Masahiro to the cc in case he sees something I've missed. Of course, doing a bisect on *when* it broke for you would be good too. You don't need to actually build the kernel, you can just bisect the configuration phase (and even automate it with "git bisect run" if you want to). Linus Taking back the earlier " IGNORE " part... This happends on the 64bit host: # make ARCH=i386 oldconfig --- .config.old 2018-06-05 21:17:07.829954548 +0300 +++ .config 2018-06-05 21:17:43.367487580 +0300 @@ -1,8 +1,7 @@ # # Automatically generated file; DO NOT EDIT. -# Linux/i386 4.16.12 Kernel Configuration +# Linux/i386 4.17.0 Kernel Configuration # -# CONFIG_64BIT is not set So something _does_ strip away the needed config bit So any ideas, or should I start bisecting ? -- Thomas
Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-05 kl. 21:11, skrev Linus Torvalds: On Tue, Jun 5, 2018 at 10:51 AM Thomas Backlund wrote: Is this intentional ? If so, why ? If not, how can I fix it ? It shouldn't be intentional. And I don't see anythin ghaving changed in this area. We still have config 64BIT bool "64-bit kernel" if ARCH = "x86" default ARCH != "i386" which is what it was in 4.16 too. Of course, we also have (in the main Makefile) SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ and ARCH?= $(SUBARCH) so if you don't set ARCH explicitly, it will always translate "i686" into "x86", so it will default to 64-bit. None of this is new to 4.17, though. Are you sure you didn't use to have an ARCH=i386 somewhere? Because this works for me: make ARCH=i386 oldconfig and it's how I have done cross-builds before (although honestly, I don't do them very often). But adding Masahiro to the cc in case he sees something I've missed. Of course, doing a bisect on *when* it broke for you would be good too. You don't need to actually build the kernel, you can just bisect the configuration phase (and even automate it with "git bisect run" if you want to). Linus Taking back the earlier " IGNORE " part... This happends on the 64bit host: # make ARCH=i386 oldconfig --- .config.old 2018-06-05 21:17:07.829954548 +0300 +++ .config 2018-06-05 21:17:43.367487580 +0300 @@ -1,8 +1,7 @@ # # Automatically generated file; DO NOT EDIT. -# Linux/i386 4.16.12 Kernel Configuration +# Linux/i386 4.17.0 Kernel Configuration # -# CONFIG_64BIT is not set So something _does_ strip away the needed config bit So any ideas, or should I start bisecting ? -- Thomas
Re: building in 32bit chroot on x86_64 host broken - IGNORE
Den 2018-06-05 kl. 20:52, skrev Thomas Backlund: I have a 32bit x86 and a 64bit x86_64 install on the system. With linux source up to 4.16.x I could do: setarch i686 (or use command linux32) chroot /path/to/32bit/ (/dev, /proc, /sys, /run is bind mounted in the chroot) Then I could build a 32bit kernel in the chroot without booting the 32bit system... (host is running a 4.14 longterm kernel) but building from 4.17 source in the chroot I get: $ uname -m i686 $ make oldconfig scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * Linux/x86 4.17.0 Kernel Configuration * 64-bit kernel (64BIT) [Y/n/?] (NEW) So it does not pick up 32bit anymore ... Is this intentional ? If so, why ? If not, how can I fix it ? Never mind... For some reason I seem to have lost this in the .config update to 4.17: # CONFIG_64BIT is not set Re-adding it restores proper behaviour... Sorry for the noise... -- Thomas
Re: building in 32bit chroot on x86_64 host broken - IGNORE
Den 2018-06-05 kl. 20:52, skrev Thomas Backlund: I have a 32bit x86 and a 64bit x86_64 install on the system. With linux source up to 4.16.x I could do: setarch i686 (or use command linux32) chroot /path/to/32bit/ (/dev, /proc, /sys, /run is bind mounted in the chroot) Then I could build a 32bit kernel in the chroot without booting the 32bit system... (host is running a 4.14 longterm kernel) but building from 4.17 source in the chroot I get: $ uname -m i686 $ make oldconfig scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * Linux/x86 4.17.0 Kernel Configuration * 64-bit kernel (64BIT) [Y/n/?] (NEW) So it does not pick up 32bit anymore ... Is this intentional ? If so, why ? If not, how can I fix it ? Never mind... For some reason I seem to have lost this in the .config update to 4.17: # CONFIG_64BIT is not set Re-adding it restores proper behaviour... Sorry for the noise... -- Thomas
building in 32bit chroot on x86_64 host broken (was: Linux 4.17)
I have a 32bit x86 and a 64bit x86_64 install on the system. With linux source up to 4.16.x I could do: setarch i686 (or use command linux32) chroot /path/to/32bit/ (/dev, /proc, /sys, /run is bind mounted in the chroot) Then I could build a 32bit kernel in the chroot without booting the 32bit system... (host is running a 4.14 longterm kernel) but building from 4.17 source in the chroot I get: $ uname -m i686 $ make oldconfig scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * Linux/x86 4.17.0 Kernel Configuration * 64-bit kernel (64BIT) [Y/n/?] (NEW) So it does not pick up 32bit anymore ... Is this intentional ? If so, why ? If not, how can I fix it ? -- Thomas
building in 32bit chroot on x86_64 host broken (was: Linux 4.17)
I have a 32bit x86 and a 64bit x86_64 install on the system. With linux source up to 4.16.x I could do: setarch i686 (or use command linux32) chroot /path/to/32bit/ (/dev, /proc, /sys, /run is bind mounted in the chroot) Then I could build a 32bit kernel in the chroot without booting the 32bit system... (host is running a 4.14 longterm kernel) but building from 4.17 source in the chroot I get: $ uname -m i686 $ make oldconfig scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * Linux/x86 4.17.0 Kernel Configuration * 64-bit kernel (64BIT) [Y/n/?] (NEW) So it does not pick up 32bit anymore ... Is this intentional ? If so, why ? If not, how can I fix it ? -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 19.04.2018 kl. 18:57, skrev Greg KH: On Thu, Apr 19, 2018 at 06:16:26PM +0300, Thomas Backlund wrote: Den 19.04.2018 kl. 17:22, skrev Greg KH: On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote: On Thu 19-04-18 15:59:43, Greg KH wrote: On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: Den 16-04-2018 kl. 19:19, skrev Sasha Levin: On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: On Mon, 16 Apr 2018 16:02:03 + Sasha Levin <alexander.le...@microsoft.com> wrote: One of the things Greg is pushing strongly for is "bug compatibility": we want the kernel to behave the same way between mainline and stable. If the code is broken, it should be broken in the same way. Wait! What does that mean? What's the purpose of stable if it is as broken as mainline? This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not. In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable. Yeah, but _intentionally_ breaking existing setups to stay "bug compatible" _is_ a _regression_ you _really_ _dont_ want in a stable supported distro. Because end-users dont care about upstream breaking stuff... its the distro that takes the heat for that... Something "already broken" is not a regression... As distro maintainer that means one now have to review _every_ patch that carries "AUTOSEL", follow all the mail threads that comes up about it, then track if it landed in -stable queue, and read every response and possible objection to all patches in the -stable queue a second time around... then check if it still got included in final stable point relase and then either revert them in distro kernel or go track down all the follow-up fixes needed... Just to avoid being "bug compatible with master" I've done this "bug compatible" "breakage" more than the AUTOSEL stuff has in the past, so you had better also be reviewing all of my normal commits as well :) Anyway, we are trying not to do this, but it does, and will, occasionally happen. Sure, that's understood. So this was just misunderstanding. Sasha's original comment really sounded like "bug compatibility" with current master is desirable and that made me go "Are you serious?" as well... As I said before in this thread, yes, sometimes I do this on purpose. And I guess this is the one that gets people the feeling that "stable is not as stable as it used to be" ... It's always been this way, it's just that no one noticed :) :) As an specific example, see a recent bluetooth patch that caused a regression on some chromebook devices. The chromeos developers rightfully complainied, and I left the commit in there to provide the needed "leverage" on the upstream developers to fix this properly. Otherwise if I had reverted the stable patch, when people move to a newer kernel version, things break, and no one remembers why. I do understand what you are trying to do... But from my distro hat on I have to treat things differently (and I dont think I'm alone doing it this way...) Known breakages gets reverted even before it hits QA, so endusers wont see the issue at all... So the only ones to see the issue are those building with latest upstream without own patches applied... I also wrote a long response as to _why_ I do this, and even though it does happen, why it still is worth taking the stable updates. Please see the archives for the full details. I don't want to duplicate this again here. And we do use latest stable (with some delay as I dont want to overload QA & endusers with a new kernel every week :)) You need to automate your QA :) Yeah, some can be automated... but that means having a lot of different hw to test on... emulators/vms can only test so much... users part of QA test on a variety of hw with various installs/setups that exposes fun things with some hw :) We just revert known broken (or add known fixes) before releasing them to our users That's great, and is what you should be doing, nothing wrong there. thanks, greg k-h -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 19.04.2018 kl. 18:57, skrev Greg KH: On Thu, Apr 19, 2018 at 06:16:26PM +0300, Thomas Backlund wrote: Den 19.04.2018 kl. 17:22, skrev Greg KH: On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote: On Thu 19-04-18 15:59:43, Greg KH wrote: On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: Den 16-04-2018 kl. 19:19, skrev Sasha Levin: On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: On Mon, 16 Apr 2018 16:02:03 + Sasha Levin wrote: One of the things Greg is pushing strongly for is "bug compatibility": we want the kernel to behave the same way between mainline and stable. If the code is broken, it should be broken in the same way. Wait! What does that mean? What's the purpose of stable if it is as broken as mainline? This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not. In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable. Yeah, but _intentionally_ breaking existing setups to stay "bug compatible" _is_ a _regression_ you _really_ _dont_ want in a stable supported distro. Because end-users dont care about upstream breaking stuff... its the distro that takes the heat for that... Something "already broken" is not a regression... As distro maintainer that means one now have to review _every_ patch that carries "AUTOSEL", follow all the mail threads that comes up about it, then track if it landed in -stable queue, and read every response and possible objection to all patches in the -stable queue a second time around... then check if it still got included in final stable point relase and then either revert them in distro kernel or go track down all the follow-up fixes needed... Just to avoid being "bug compatible with master" I've done this "bug compatible" "breakage" more than the AUTOSEL stuff has in the past, so you had better also be reviewing all of my normal commits as well :) Anyway, we are trying not to do this, but it does, and will, occasionally happen. Sure, that's understood. So this was just misunderstanding. Sasha's original comment really sounded like "bug compatibility" with current master is desirable and that made me go "Are you serious?" as well... As I said before in this thread, yes, sometimes I do this on purpose. And I guess this is the one that gets people the feeling that "stable is not as stable as it used to be" ... It's always been this way, it's just that no one noticed :) :) As an specific example, see a recent bluetooth patch that caused a regression on some chromebook devices. The chromeos developers rightfully complainied, and I left the commit in there to provide the needed "leverage" on the upstream developers to fix this properly. Otherwise if I had reverted the stable patch, when people move to a newer kernel version, things break, and no one remembers why. I do understand what you are trying to do... But from my distro hat on I have to treat things differently (and I dont think I'm alone doing it this way...) Known breakages gets reverted even before it hits QA, so endusers wont see the issue at all... So the only ones to see the issue are those building with latest upstream without own patches applied... I also wrote a long response as to _why_ I do this, and even though it does happen, why it still is worth taking the stable updates. Please see the archives for the full details. I don't want to duplicate this again here. And we do use latest stable (with some delay as I dont want to overload QA & endusers with a new kernel every week :)) You need to automate your QA :) Yeah, some can be automated... but that means having a lot of different hw to test on... emulators/vms can only test so much... users part of QA test on a variety of hw with various installs/setups that exposes fun things with some hw :) We just revert known broken (or add known fixes) before releasing them to our users That's great, and is what you should be doing, nothing wrong there. thanks, greg k-h -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 19.04.2018 kl. 18:09, skrev Sasha Levin: On Thu, Apr 19, 2018 at 06:04:26PM +0300, Thomas Backlund wrote: Den 19.04.2018 kl. 16:59, skrev Greg KH: Anyway, we are trying not to do this, but it does, and will, occasionally happen. Look, we just did that for one platform for 4.9.94! And the key to all of this is good testing, which we are now doing, and hopefully you are also doing as well. Yeah, but having to test stuff with known breakages is no fun, so we try to avoid that Known breakages are easier to deal with than unknown ones :) well, if a system worked before the update, but not after... Guess wich one we want... I think that that "bug compatability" is basically a policy on *which* regressions you'll see vs *if* you'll see a regression. No. Intentionally breaking known working code in a stable branch is never ok. As I said before... something that never worked is not a regression, but breaking a previously working setup is... That goes for security fixes too... there is not much point in a security fix, if it basically turns into a local DOS when the system stops working... People will just boot older code and there you have it... We'll never pull in a commit that introduces a bug but doesn't fix another one, right? So if you have to deal with a regression anyway, might as well deal with a regression that is also seen on mainline, so that when you upgrade your stable kernel you'll keep the same set of regressions to deal with. Here I actually like the comment Linus posted about API breakage earlier in this thread... If you break user workflows, NOTHING ELSE MATTERS. Even security is secondary to "people don't use the end result, because it doesn't work for them any more". _This_ same statement should be aknowledged / enforced in stable trees too IMHO... Because this is what will happend... simple logic... if it does not work, the enduser will boot an earlier kernel... missing "all the good fixes" (including security ones) just because one fix is bad. For example in this AUTOSEL round there is 161 fixes of wich the enduser never gets the 160 "supposedly good ones" when one is "bad"... How is that a "good thing" ? And trying to tell those that get hit "this will force upstream to fix it faster, so you get a working setup in some days/weeks/months..." is not going to work... Heh, This even reminds me that this is just as annoying as when MS started to "bundle monthly security updates" and you get 95% installed just to realize that the last 5% does not work (or install at all) and you have to rollback to something working thus missing the needed security fixes... Same flawed logic... Thnakfully we as distro maintainers can avoid some of the breakage for our enduses... -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 19.04.2018 kl. 18:09, skrev Sasha Levin: On Thu, Apr 19, 2018 at 06:04:26PM +0300, Thomas Backlund wrote: Den 19.04.2018 kl. 16:59, skrev Greg KH: Anyway, we are trying not to do this, but it does, and will, occasionally happen. Look, we just did that for one platform for 4.9.94! And the key to all of this is good testing, which we are now doing, and hopefully you are also doing as well. Yeah, but having to test stuff with known breakages is no fun, so we try to avoid that Known breakages are easier to deal with than unknown ones :) well, if a system worked before the update, but not after... Guess wich one we want... I think that that "bug compatability" is basically a policy on *which* regressions you'll see vs *if* you'll see a regression. No. Intentionally breaking known working code in a stable branch is never ok. As I said before... something that never worked is not a regression, but breaking a previously working setup is... That goes for security fixes too... there is not much point in a security fix, if it basically turns into a local DOS when the system stops working... People will just boot older code and there you have it... We'll never pull in a commit that introduces a bug but doesn't fix another one, right? So if you have to deal with a regression anyway, might as well deal with a regression that is also seen on mainline, so that when you upgrade your stable kernel you'll keep the same set of regressions to deal with. Here I actually like the comment Linus posted about API breakage earlier in this thread... If you break user workflows, NOTHING ELSE MATTERS. Even security is secondary to "people don't use the end result, because it doesn't work for them any more". _This_ same statement should be aknowledged / enforced in stable trees too IMHO... Because this is what will happend... simple logic... if it does not work, the enduser will boot an earlier kernel... missing "all the good fixes" (including security ones) just because one fix is bad. For example in this AUTOSEL round there is 161 fixes of wich the enduser never gets the 160 "supposedly good ones" when one is "bad"... How is that a "good thing" ? And trying to tell those that get hit "this will force upstream to fix it faster, so you get a working setup in some days/weeks/months..." is not going to work... Heh, This even reminds me that this is just as annoying as when MS started to "bundle monthly security updates" and you get 95% installed just to realize that the last 5% does not work (or install at all) and you have to rollback to something working thus missing the needed security fixes... Same flawed logic... Thnakfully we as distro maintainers can avoid some of the breakage for our enduses... -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 19.04.2018 kl. 17:22, skrev Greg KH: On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote: On Thu 19-04-18 15:59:43, Greg KH wrote: On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: Den 16-04-2018 kl. 19:19, skrev Sasha Levin: On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: On Mon, 16 Apr 2018 16:02:03 + Sasha Levin <alexander.le...@microsoft.com> wrote: One of the things Greg is pushing strongly for is "bug compatibility": we want the kernel to behave the same way between mainline and stable. If the code is broken, it should be broken in the same way. Wait! What does that mean? What's the purpose of stable if it is as broken as mainline? This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not. In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable. Yeah, but _intentionally_ breaking existing setups to stay "bug compatible" _is_ a _regression_ you _really_ _dont_ want in a stable supported distro. Because end-users dont care about upstream breaking stuff... its the distro that takes the heat for that... Something "already broken" is not a regression... As distro maintainer that means one now have to review _every_ patch that carries "AUTOSEL", follow all the mail threads that comes up about it, then track if it landed in -stable queue, and read every response and possible objection to all patches in the -stable queue a second time around... then check if it still got included in final stable point relase and then either revert them in distro kernel or go track down all the follow-up fixes needed... Just to avoid being "bug compatible with master" I've done this "bug compatible" "breakage" more than the AUTOSEL stuff has in the past, so you had better also be reviewing all of my normal commits as well :) Anyway, we are trying not to do this, but it does, and will, occasionally happen. Sure, that's understood. So this was just misunderstanding. Sasha's original comment really sounded like "bug compatibility" with current master is desirable and that made me go "Are you serious?" as well... As I said before in this thread, yes, sometimes I do this on purpose. And I guess this is the one that gets people the feeling that "stable is not as stable as it used to be" ... As an specific example, see a recent bluetooth patch that caused a regression on some chromebook devices. The chromeos developers rightfully complainied, and I left the commit in there to provide the needed "leverage" on the upstream developers to fix this properly. Otherwise if I had reverted the stable patch, when people move to a newer kernel version, things break, and no one remembers why. I do understand what you are trying to do... But from my distro hat on I have to treat things differently (and I dont think I'm alone doing it this way...) Known breakages gets reverted even before it hits QA, so endusers wont see the issue at all... So the only ones to see the issue are those building with latest upstream without own patches applied... I also wrote a long response as to _why_ I do this, and even though it does happen, why it still is worth taking the stable updates. Please see the archives for the full details. I don't want to duplicate this again here. And we do use latest stable (with some delay as I dont want to overload QA & endusers with a new kernel every week :)) We just revert known broken (or add known fixes) before releasing them to our users -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 19.04.2018 kl. 17:22, skrev Greg KH: On Thu, Apr 19, 2018 at 04:05:45PM +0200, Jan Kara wrote: On Thu 19-04-18 15:59:43, Greg KH wrote: On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: Den 16-04-2018 kl. 19:19, skrev Sasha Levin: On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: On Mon, 16 Apr 2018 16:02:03 + Sasha Levin wrote: One of the things Greg is pushing strongly for is "bug compatibility": we want the kernel to behave the same way between mainline and stable. If the code is broken, it should be broken in the same way. Wait! What does that mean? What's the purpose of stable if it is as broken as mainline? This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not. In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable. Yeah, but _intentionally_ breaking existing setups to stay "bug compatible" _is_ a _regression_ you _really_ _dont_ want in a stable supported distro. Because end-users dont care about upstream breaking stuff... its the distro that takes the heat for that... Something "already broken" is not a regression... As distro maintainer that means one now have to review _every_ patch that carries "AUTOSEL", follow all the mail threads that comes up about it, then track if it landed in -stable queue, and read every response and possible objection to all patches in the -stable queue a second time around... then check if it still got included in final stable point relase and then either revert them in distro kernel or go track down all the follow-up fixes needed... Just to avoid being "bug compatible with master" I've done this "bug compatible" "breakage" more than the AUTOSEL stuff has in the past, so you had better also be reviewing all of my normal commits as well :) Anyway, we are trying not to do this, but it does, and will, occasionally happen. Sure, that's understood. So this was just misunderstanding. Sasha's original comment really sounded like "bug compatibility" with current master is desirable and that made me go "Are you serious?" as well... As I said before in this thread, yes, sometimes I do this on purpose. And I guess this is the one that gets people the feeling that "stable is not as stable as it used to be" ... As an specific example, see a recent bluetooth patch that caused a regression on some chromebook devices. The chromeos developers rightfully complainied, and I left the commit in there to provide the needed "leverage" on the upstream developers to fix this properly. Otherwise if I had reverted the stable patch, when people move to a newer kernel version, things break, and no one remembers why. I do understand what you are trying to do... But from my distro hat on I have to treat things differently (and I dont think I'm alone doing it this way...) Known breakages gets reverted even before it hits QA, so endusers wont see the issue at all... So the only ones to see the issue are those building with latest upstream without own patches applied... I also wrote a long response as to _why_ I do this, and even though it does happen, why it still is worth taking the stable updates. Please see the archives for the full details. I don't want to duplicate this again here. And we do use latest stable (with some delay as I dont want to overload QA & endusers with a new kernel every week :)) We just revert known broken (or add known fixes) before releasing them to our users -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 19.04.2018 kl. 16:59, skrev Greg KH: On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: Den 16-04-2018 kl. 19:19, skrev Sasha Levin: On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: On Mon, 16 Apr 2018 16:02:03 + Sasha Levin <alexander.le...@microsoft.com> wrote: One of the things Greg is pushing strongly for is "bug compatibility": we want the kernel to behave the same way between mainline and stable. If the code is broken, it should be broken in the same way. Wait! What does that mean? What's the purpose of stable if it is as broken as mainline? This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not. In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable. Yeah, but _intentionally_ breaking existing setups to stay "bug compatible" _is_ a _regression_ you _really_ _dont_ want in a stable supported distro. Because end-users dont care about upstream breaking stuff... its the distro that takes the heat for that... Something "already broken" is not a regression... As distro maintainer that means one now have to review _every_ patch that carries "AUTOSEL", follow all the mail threads that comes up about it, then track if it landed in -stable queue, and read every response and possible objection to all patches in the -stable queue a second time around... then check if it still got included in final stable point relase and then either revert them in distro kernel or go track down all the follow-up fixes needed... Just to avoid being "bug compatible with master" I've done this "bug compatible" "breakage" more than the AUTOSEL stuff has in the past, so you had better also be reviewing all of my normal commits as well :) Yeah, I do... and same goes there ... if there is a known issue, then same procedure... Either revert, or try to track down fixes... Anyway, we are trying not to do this, but it does, and will, occasionally happen. Look, we just did that for one platform for 4.9.94! And the key to all of this is good testing, which we are now doing, and hopefully you are also doing as well. Yeah, but having to test stuff with known breakages is no fun, so we try to avoid that -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 19.04.2018 kl. 16:59, skrev Greg KH: On Thu, Apr 19, 2018 at 02:41:33PM +0300, Thomas Backlund wrote: Den 16-04-2018 kl. 19:19, skrev Sasha Levin: On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: On Mon, 16 Apr 2018 16:02:03 + Sasha Levin wrote: One of the things Greg is pushing strongly for is "bug compatibility": we want the kernel to behave the same way between mainline and stable. If the code is broken, it should be broken in the same way. Wait! What does that mean? What's the purpose of stable if it is as broken as mainline? This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not. In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable. Yeah, but _intentionally_ breaking existing setups to stay "bug compatible" _is_ a _regression_ you _really_ _dont_ want in a stable supported distro. Because end-users dont care about upstream breaking stuff... its the distro that takes the heat for that... Something "already broken" is not a regression... As distro maintainer that means one now have to review _every_ patch that carries "AUTOSEL", follow all the mail threads that comes up about it, then track if it landed in -stable queue, and read every response and possible objection to all patches in the -stable queue a second time around... then check if it still got included in final stable point relase and then either revert them in distro kernel or go track down all the follow-up fixes needed... Just to avoid being "bug compatible with master" I've done this "bug compatible" "breakage" more than the AUTOSEL stuff has in the past, so you had better also be reviewing all of my normal commits as well :) Yeah, I do... and same goes there ... if there is a known issue, then same procedure... Either revert, or try to track down fixes... Anyway, we are trying not to do this, but it does, and will, occasionally happen. Look, we just did that for one platform for 4.9.94! And the key to all of this is good testing, which we are now doing, and hopefully you are also doing as well. Yeah, but having to test stuff with known breakages is no fun, so we try to avoid that -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 16-04-2018 kl. 19:19, skrev Sasha Levin: On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: On Mon, 16 Apr 2018 16:02:03 + Sasha Levinwrote: One of the things Greg is pushing strongly for is "bug compatibility": we want the kernel to behave the same way between mainline and stable. If the code is broken, it should be broken in the same way. Wait! What does that mean? What's the purpose of stable if it is as broken as mainline? This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not. In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable. Yeah, but _intentionally_ breaking existing setups to stay "bug compatible" _is_ a _regression_ you _really_ _dont_ want in a stable supported distro. Because end-users dont care about upstream breaking stuff... its the distro that takes the heat for that... Something "already broken" is not a regression... As distro maintainer that means one now have to review _every_ patch that carries "AUTOSEL", follow all the mail threads that comes up about it, then track if it landed in -stable queue, and read every response and possible objection to all patches in the -stable queue a second time around... then check if it still got included in final stable point relase and then either revert them in distro kernel or go track down all the follow-up fixes needed... Just to avoid being "bug compatible with master" -- Thomas
Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Den 16-04-2018 kl. 19:19, skrev Sasha Levin: On Mon, Apr 16, 2018 at 12:12:24PM -0400, Steven Rostedt wrote: On Mon, 16 Apr 2018 16:02:03 + Sasha Levin wrote: One of the things Greg is pushing strongly for is "bug compatibility": we want the kernel to behave the same way between mainline and stable. If the code is broken, it should be broken in the same way. Wait! What does that mean? What's the purpose of stable if it is as broken as mainline? This just means that if there is a fix that went in mainline, and the fix is broken somehow, we'd rather take the broken fix than not. In this scenario, *something* will be broken, it's just a matter of what. We'd rather have the same thing broken between mainline and stable. Yeah, but _intentionally_ breaking existing setups to stay "bug compatible" _is_ a _regression_ you _really_ _dont_ want in a stable supported distro. Because end-users dont care about upstream breaking stuff... its the distro that takes the heat for that... Something "already broken" is not a regression... As distro maintainer that means one now have to review _every_ patch that carries "AUTOSEL", follow all the mail threads that comes up about it, then track if it landed in -stable queue, and read every response and possible objection to all patches in the -stable queue a second time around... then check if it still got included in final stable point relase and then either revert them in distro kernel or go track down all the follow-up fixes needed... Just to avoid being "bug compatible with master" -- Thomas
Re: [PATCH 4.14 000/109] 4.14.28-stable review
Den 27.03.2018 kl. 09:37, skrev Guenter Roeck: On 03/26/2018 11:28 PM, Greg Kroah-Hartman wrote: On Mon, Mar 26, 2018 at 01:54:18PM -0400, Kash Pande wrote: On 2018-03-19 02:20 PM, Guenter Roeck wrote: Ryzen and Threadripper are only supported in v4.15+. Nope, the offset for 1900X is not available in 4.15, I've had to manually patch all systems otherwise monitoring complains they idle at 53C. I don't understand, what patch are you talking about here? 6509614fdd2d, but you'll also want aef17ca12719 if that isn't queued already. Guenter And if you ant it to work in 4.14 longterm, you want the series: 68546abf7a3a63f199e53d6dcaa7375df37a6aaa hwmon: (k10temp) Move chip specific code into probe function 9af0a9aecdb945cd5513941ffdcbcc031009b402 hwmon: (k10temp) Add support for family 17h 1b50b776355fa6c6d7b3281a63c275d5c18d629d hwmon: (k10temp) Add support for temperature offsets ab5ee24615f9dd8b0cd199403959f8b13309e7b1 hwmon: (k10temp) Correct model name for Ryzen 1600X 6509614fdd2d05c6926d50901a45d5dfb852b715 hwmon: (k10temp) Add temperature offset for Ryzen 1900X aef17ca1271948ee57cc39b2493d31110cc42625 hwmon: (k10temp) Only apply temperature offset if result is positive We have it in Mageia, and I've confirmed it works on a Ryzen 7 1700 and ThreadRipper 1950X -- Thomas
Re: [PATCH 4.14 000/109] 4.14.28-stable review
Den 27.03.2018 kl. 09:37, skrev Guenter Roeck: On 03/26/2018 11:28 PM, Greg Kroah-Hartman wrote: On Mon, Mar 26, 2018 at 01:54:18PM -0400, Kash Pande wrote: On 2018-03-19 02:20 PM, Guenter Roeck wrote: Ryzen and Threadripper are only supported in v4.15+. Nope, the offset for 1900X is not available in 4.15, I've had to manually patch all systems otherwise monitoring complains they idle at 53C. I don't understand, what patch are you talking about here? 6509614fdd2d, but you'll also want aef17ca12719 if that isn't queued already. Guenter And if you ant it to work in 4.14 longterm, you want the series: 68546abf7a3a63f199e53d6dcaa7375df37a6aaa hwmon: (k10temp) Move chip specific code into probe function 9af0a9aecdb945cd5513941ffdcbcc031009b402 hwmon: (k10temp) Add support for family 17h 1b50b776355fa6c6d7b3281a63c275d5c18d629d hwmon: (k10temp) Add support for temperature offsets ab5ee24615f9dd8b0cd199403959f8b13309e7b1 hwmon: (k10temp) Correct model name for Ryzen 1600X 6509614fdd2d05c6926d50901a45d5dfb852b715 hwmon: (k10temp) Add temperature offset for Ryzen 1900X aef17ca1271948ee57cc39b2493d31110cc42625 hwmon: (k10temp) Only apply temperature offset if result is positive We have it in Mageia, and I've confirmed it works on a Ryzen 7 1700 and ThreadRipper 1950X -- Thomas
Re: [PATCH 4.14 00/75] 4.14.5-stable review
Den 09.12.2017 kl. 19:13, skrev Greg Kroah-Hartman: On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote: On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartmanwrote: On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote: I saw no problems on 8 of 9 machines, but the last one had a problem because it used NVIDIA drivers (387); DKMS reported: FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol 'ex_handler_refcount' //usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92: recipe for target '__modpost' failed make[3]: *** [__modpost] Error 1 Is this a new issue? Does 4.14.4 have this issue? I believe it is a new issue, because I have a 4.14.4 build and an NVIDIA DKMS log for that 4.14.4 showing build success. Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text section for refcount exceptions") causing this? That was my guess too, but I did not verify. That feels really wrong here, I'd like to get some confirmation before I add this patch... It's needed. The reason you hit in 4.14.5 queue is because of: [PATCH 4.14 64/75] locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT From foo@baz Wed Dec 6 18:04:41 CET 2017 From: Kees Cook Date: Sat, 2 Sep 2017 13:09:46 -0700 Subject: locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT that does this: - select ARCH_HAS_REFCOUNTif BROKEN + select ARCH_HAS_REFCOUNT So it exposes previously hidden code -- Thomas
Re: [PATCH 4.14 00/75] 4.14.5-stable review
Den 09.12.2017 kl. 19:13, skrev Greg Kroah-Hartman: On Sat, Dec 09, 2017 at 07:56:40AM +, Ivan Kozik wrote: On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman wrote: On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote: I saw no problems on 8 of 9 machines, but the last one had a problem because it used NVIDIA drivers (387); DKMS reported: FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol 'ex_handler_refcount' //usr/src/linux-headers-4.14.0-11-common/scripts/Makefile.modpost:92: recipe for target '__modpost' failed make[3]: *** [__modpost] Error 1 Is this a new issue? Does 4.14.4 have this issue? I believe it is a new issue, because I have a 4.14.4 build and an NVIDIA DKMS log for that 4.14.4 showing build success. Odd, is 564c9cc84e2a ("locking/refcounts, x86/asm: Use unique .text section for refcount exceptions") causing this? That was my guess too, but I did not verify. That feels really wrong here, I'd like to get some confirmation before I add this patch... It's needed. The reason you hit in 4.14.5 queue is because of: [PATCH 4.14 64/75] locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT From foo@baz Wed Dec 6 18:04:41 CET 2017 From: Kees Cook Date: Sat, 2 Sep 2017 13:09:46 -0700 Subject: locking/refcounts, x86/asm: Enable CONFIG_ARCH_HAS_REFCOUNT that does this: - select ARCH_HAS_REFCOUNTif BROKEN + select ARCH_HAS_REFCOUNT So it exposes previously hidden code -- Thomas
Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed
Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman: 4.13-stable review patch. If anyone has any objections, please let me know. -- From: Steve Frenchcommit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream. According to MS-SMB2 3.2.55 validate_negotiate request must always be signed. Some Windows can fail the request if you send it unsigned See kernel bugzilla bug 197311 Acked-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman --- fs/cifs/smb2pdu.c |3 +++ 1 file changed, 3 insertions(+) --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -1963,6 +1963,9 @@ SMB2_ioctl(const unsigned int xid, struc } else iov[0].iov_len = get_rfc1002_length(req) + 4; + /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */ + if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO) + req->hdr.sync_hdr.Flags |= SMB2_FLAGS_SIGNED; rc = SendReceive2(xid, ses, iov, n_iov, _buftype, flags, _iov); cifs_small_buf_release(req); This one needs to be backported to all stable kernels as the commit that introduced the regression: ' 0603c96f3af50e2f9299fa410c224ab1d465e0f9 SMB: Validate negotiate (to protect against downgrade) even if signing off is backported in stable trees as of: 4.9.53, 4.4.90, 3.18.73 -- Thomas
Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed
Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman: 4.13-stable review patch. If anyone has any objections, please let me know. -- From: Steve French commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream. According to MS-SMB2 3.2.55 validate_negotiate request must always be signed. Some Windows can fail the request if you send it unsigned See kernel bugzilla bug 197311 Acked-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman --- fs/cifs/smb2pdu.c |3 +++ 1 file changed, 3 insertions(+) --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -1963,6 +1963,9 @@ SMB2_ioctl(const unsigned int xid, struc } else iov[0].iov_len = get_rfc1002_length(req) + 4; + /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */ + if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO) + req->hdr.sync_hdr.Flags |= SMB2_FLAGS_SIGNED; rc = SendReceive2(xid, ses, iov, n_iov, _buftype, flags, _iov); cifs_small_buf_release(req); This one needs to be backported to all stable kernels as the commit that introduced the regression: ' 0603c96f3af50e2f9299fa410c224ab1d465e0f9 SMB: Validate negotiate (to protect against downgrade) even if signing off is backported in stable trees as of: 4.9.53, 4.4.90, 3.18.73 -- Thomas
Re: [PATCH 1/2] Correct function definition for C++
Den 22.02.2017 kl. 09:50, skrev Joakim Tjernlund: On Wed, 2017-02-22 at 08:10 +0100, Greg KH wrote: On Tue, Feb 21, 2017 at 04:24:04PM +0100, Joakim Tjernlund wrote: C++ does does not like the extra extern before asmlinkage, remove it. Signed-off-by: Joakim Tjernlund--- include/linux/printk.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/printk.h b/include/linux/printk.h index 3472cc6..be823f5 100644 --- a/include/linux/printk.h +++ b/include/linux/printk.h Why are you building this file with a C++ compiler? virtualbox uses C++ and includes various kernel headers and the build fails, virtualbox guest additions has not build for quite some time now and this is one of the problems. You need this fix for virtualbox: https://www.virtualbox.org/changeset/65874/vbox/trunk/configure -- Thomas
Re: [PATCH 1/2] Correct function definition for C++
Den 22.02.2017 kl. 09:50, skrev Joakim Tjernlund: On Wed, 2017-02-22 at 08:10 +0100, Greg KH wrote: On Tue, Feb 21, 2017 at 04:24:04PM +0100, Joakim Tjernlund wrote: C++ does does not like the extra extern before asmlinkage, remove it. Signed-off-by: Joakim Tjernlund --- include/linux/printk.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/printk.h b/include/linux/printk.h index 3472cc6..be823f5 100644 --- a/include/linux/printk.h +++ b/include/linux/printk.h Why are you building this file with a C++ compiler? virtualbox uses C++ and includes various kernel headers and the build fails, virtualbox guest additions has not build for quite some time now and this is one of the problems. You need this fix for virtualbox: https://www.virtualbox.org/changeset/65874/vbox/trunk/configure -- Thomas
Re: [PATCH 4.4 00/34] 4.4.32-stable review
Den 13.11.2016 kl. 17:34, skrev Philip Müller: Hi Greg, with inclusion of 'Fix data integrity failure for JBOD (passthrough) devices' in v4.4.31, we currently have a regression with SCSI and macro MEGASAS_IS_LOGICAL. To fix it, commit 5e5ec17[1] is needed or that patch JBOD patch[2] reverted until it is merged in mainline. The other patches seem fine. kind regards, Philip Müller - Manjaro Project Lead --- [1] http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8 [2] https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/releases/4.4.31/scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.patch The needed fix is now upstream as: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8 -- Thomas
Re: [PATCH 4.4 00/34] 4.4.32-stable review
Den 13.11.2016 kl. 17:34, skrev Philip Müller: Hi Greg, with inclusion of 'Fix data integrity failure for JBOD (passthrough) devices' in v4.4.31, we currently have a regression with SCSI and macro MEGASAS_IS_LOGICAL. To fix it, commit 5e5ec17[1] is needed or that patch JBOD patch[2] reverted until it is merged in mainline. The other patches seem fine. kind regards, Philip Müller - Manjaro Project Lead --- [1] http://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8 [2] https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/releases/4.4.31/scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.patch The needed fix is now upstream as: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e5ec1759dd663a1d5a2f10930224dd009e500e8 -- Thomas
Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers
Den 01-07-2016 kl. 12:30, skrev Herbert Xu: On Thu, Jun 30, 2016 at 12:23:51PM +0200, Jan Stancek wrote: Parallel build can sporadically fail because asn1 headers may not be built yet by the time qat_asym_algs.o is compiled: drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory #include "qat_rsapubkey-asn1.h" Signed-off-by: Jan StancekCc: Tadeusz Struk Cc: Herbert Xu Jan, Salvatore just posted a patch to delete the qat ASN code altogether, so your patch won't be needed. Thanks, Yeah, but that patch seem to be heading to 4.8 only , so qat build in upcoming 4.7 still breaks... and pulling that fix only to 4.7 breaks too, so I guess more fixes would be needed for proper backport then... or are the qat fixes already queued somewhere for 4.7 final ? -- Thomas
Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers
Den 01-07-2016 kl. 12:30, skrev Herbert Xu: On Thu, Jun 30, 2016 at 12:23:51PM +0200, Jan Stancek wrote: Parallel build can sporadically fail because asn1 headers may not be built yet by the time qat_asym_algs.o is compiled: drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory #include "qat_rsapubkey-asn1.h" Signed-off-by: Jan Stancek Cc: Tadeusz Struk Cc: Herbert Xu Jan, Salvatore just posted a patch to delete the qat ASN code altogether, so your patch won't be needed. Thanks, Yeah, but that patch seem to be heading to 4.8 only , so qat build in upcoming 4.7 still breaks... and pulling that fix only to 4.7 breaks too, so I guess more fixes would be needed for proper backport then... or are the qat fixes already queued somewhere for 4.7 final ? -- Thomas
Re: [PATCH 4.1 39/46] sched/preempt: Fix cond_resched_lock() and cond_resched_softirq()
Den 23.10.2015 kl. 20:46, skrev Greg Kroah-Hartman: 4.1-stable review patch. If anyone has any objections, please let me know. -- From: Konstantin Khlebnikov commit fe32d3cd5e8eb0f82e459763374aa80797023403 upstream. This one broke drivers/xen/ build drivers/xen/preempt.c: In function ”xen_maybe_preempt_hcall”: drivers/xen/preempt.c:34:11: error: too few arguments to function ”should_resched” && should_resched())) { ^ Needed fix is: From 0fa2f5cb2b0ecd8d56baa51f35f09aab234eb0bf Mon Sep 17 00:00:00 2001 From: Konstantin Khlebnikov Date: Wed, 15 Jul 2015 12:52:01 +0300 Subject: [PATCH] sched/preempt, xen: Use need_resched() instead of should_resched() -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 39/46] sched/preempt: Fix cond_resched_lock() and cond_resched_softirq()
Den 23.10.2015 kl. 20:46, skrev Greg Kroah-Hartman: 4.1-stable review patch. If anyone has any objections, please let me know. -- From: Konstantin Khlebnikovcommit fe32d3cd5e8eb0f82e459763374aa80797023403 upstream. This one broke drivers/xen/ build drivers/xen/preempt.c: In function ”xen_maybe_preempt_hcall”: drivers/xen/preempt.c:34:11: error: too few arguments to function ”should_resched” && should_resched())) { ^ Needed fix is: From 0fa2f5cb2b0ecd8d56baa51f35f09aab234eb0bf Mon Sep 17 00:00:00 2001 From: Konstantin Khlebnikov Date: Wed, 15 Jul 2015 12:52:01 +0300 Subject: [PATCH] sched/preempt, xen: Use need_resched() instead of should_resched() -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.19 176/177] netfilter: x_tables: fix cgroup matching on non-full sks
Den 02.05.2015 22:03, Greg Kroah-Hartman skrev: 3.19-stable review patch. If anyone has any objections, please let me know. -- From: Daniel Borkmann commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream. While originally only being intended for outgoing traffic, commit a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks") enabled xt_cgroups for the NF_INET_LOCAL_IN hook as well, in order to allow for nfacct accounting. Besides being currently limited to early demuxes only, commit a00e76349f35 forgot to add a check if we deal with full sockets, i.e. in this case not with time wait sockets. TCP time wait sockets do not have the same memory layout as full sockets, a lower memory footprint and consequently also don't have a sk_classid member; probing for sk_classid member there could potentially lead to a crash. Fixes: a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks") Cc: Alexey Perevalov Signed-off-by: Daniel Borkmann Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman --- net/netfilter/xt_cgroup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/xt_cgroup.c +++ b/net/netfilter/xt_cgroup.c @@ -39,7 +39,7 @@ cgroup_mt(const struct sk_buff *skb, str { const struct xt_cgroup_info *info = par->matchinfo; - if (skb->sk == NULL) + if (skb->sk == NULL || !sk_fullsock(skb->sk)) return false; return (info->id == skb->sk->sk_classid) ^ info->invert; This one breaks the build with: net/netfilter/xt_cgroup.c: In function 'cgroup_mt': net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 'sk_fullsock' [-Werror=implicit-function-declaration] In order to fix it, you also need to add: From 1d0ab253872cdd3d8e7913f59c266c7fd01771d0 Mon Sep 17 00:00:00 2001 From: Eric Dumazet Date: Sun, 15 Mar 2015 21:12:12 -0700 Subject: [PATCH] net: add sk_fullsock() helper which in turn needs this one: From 10feb428a5045d5eb18a5d755fbb8f0cc9645626 Mon Sep 17 00:00:00 2001 From: Eric Dumazet Date: Thu, 12 Mar 2015 16:44:04 -0700 Subject: [PATCH] inet: add TCP_NEW_SYN_RECV state -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.19 176/177] netfilter: x_tables: fix cgroup matching on non-full sks
Den 02.05.2015 22:03, Greg Kroah-Hartman skrev: 3.19-stable review patch. If anyone has any objections, please let me know. -- From: Daniel Borkmann dan...@iogearbox.net commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream. While originally only being intended for outgoing traffic, commit a00e76349f35 (netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks) enabled xt_cgroups for the NF_INET_LOCAL_IN hook as well, in order to allow for nfacct accounting. Besides being currently limited to early demuxes only, commit a00e76349f35 forgot to add a check if we deal with full sockets, i.e. in this case not with time wait sockets. TCP time wait sockets do not have the same memory layout as full sockets, a lower memory footprint and consequently also don't have a sk_classid member; probing for sk_classid member there could potentially lead to a crash. Fixes: a00e76349f35 (netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks) Cc: Alexey Perevalov a.pereva...@samsung.com Signed-off-by: Daniel Borkmann dan...@iogearbox.net Signed-off-by: Pablo Neira Ayuso pa...@netfilter.org Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- net/netfilter/xt_cgroup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/xt_cgroup.c +++ b/net/netfilter/xt_cgroup.c @@ -39,7 +39,7 @@ cgroup_mt(const struct sk_buff *skb, str { const struct xt_cgroup_info *info = par-matchinfo; - if (skb-sk == NULL) + if (skb-sk == NULL || !sk_fullsock(skb-sk)) return false; return (info-id == skb-sk-sk_classid) ^ info-invert; This one breaks the build with: net/netfilter/xt_cgroup.c: In function 'cgroup_mt': net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 'sk_fullsock' [-Werror=implicit-function-declaration] In order to fix it, you also need to add: From 1d0ab253872cdd3d8e7913f59c266c7fd01771d0 Mon Sep 17 00:00:00 2001 From: Eric Dumazet eduma...@google.com Date: Sun, 15 Mar 2015 21:12:12 -0700 Subject: [PATCH] net: add sk_fullsock() helper which in turn needs this one: From 10feb428a5045d5eb18a5d755fbb8f0cc9645626 Mon Sep 17 00:00:00 2001 From: Eric Dumazet eduma...@google.com Date: Thu, 12 Mar 2015 16:44:04 -0700 Subject: [PATCH] inet: add TCP_NEW_SYN_RECV state -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 81/94] libata: support the ata host which implements a queue depth less than 32
Jiri Slaby skrev den 30.7.2014 15:15: From: Kevin Hao 3.12-stable review patch. If anyone has any objections, please let me know. === commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream. The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers"). The reason is that the ata controller on this SoC only implement a queue depth of 16. When issuing the commands in tag order, all the commands in tag 16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata malfunction. It makes no senses to use a 32 queue in software while the hardware has less queue depth. So consider the queue depth implemented by the hardware when requesting a command tag. Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers") Signed-off-by: Kevin Hao Acked-by: Dan Williams Signed-off-by: Tejun Heo Signed-off-by: Jiri Slaby As you have added this to 3.12 branch, you also need to add this to avoid SAS breakage: commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6 Author: Tejun Heo Date: Wed Jul 23 09:05:27 2014 -0400 libata: introduce ata_host->n_tags to avoid oops on SAS controllers 1871ee134b73 ("libata: support the ata host which implements a queue depth less than 32") directly used ata_port->scsi_host->can_queue from ata_qc_new() to determine the number of tags supported by the host; unfortunately, SAS controllers doing SATA don't initialize ->scsi_host leading to the following oops. -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 81/94] libata: support the ata host which implements a queue depth less than 32
Jiri Slaby skrev den 30.7.2014 15:15: From: Kevin Hao haoke...@gmail.com 3.12-stable review patch. If anyone has any objections, please let me know. === commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream. The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6 (libata/ahci: accommodate tag ordered controllers). The reason is that the ata controller on this SoC only implement a queue depth of 16. When issuing the commands in tag order, all the commands in tag 16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata malfunction. It makes no senses to use a 32 queue in software while the hardware has less queue depth. So consider the queue depth implemented by the hardware when requesting a command tag. Fixes: 8a4aeec8d2d6 (libata/ahci: accommodate tag ordered controllers) Signed-off-by: Kevin Hao haoke...@gmail.com Acked-by: Dan Williams dan.j.willi...@intel.com Signed-off-by: Tejun Heo t...@kernel.org Signed-off-by: Jiri Slaby jsl...@suse.cz As you have added this to 3.12 branch, you also need to add this to avoid SAS breakage: commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6 Author: Tejun Heo t...@kernel.org Date: Wed Jul 23 09:05:27 2014 -0400 libata: introduce ata_host-n_tags to avoid oops on SAS controllers 1871ee134b73 (libata: support the ata host which implements a queue depth less than 32) directly used ata_port-scsi_host-can_queue from ata_qc_new() to determine the number of tags supported by the host; unfortunately, SAS controllers doing SATA don't initialize -scsi_host leading to the following oops. -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 000/149] 3.13.7-stable review
Guenter Roeck skrev 21.3.2014 07:37: On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.13.7 release. There are 149 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Mar 23 00:03:54 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 120 skipped: 4 fail: 2 qemu tests all passed. There are two new build failures. Building powerpc:mpc85xx_defconfig ... failed Building powerpc:mpc85xx_smp_defconfig ... failed The failure is the same in both cases. drivers/i2c/busses/i2c-cpm.c: In function 'cpm_i2c_setup': drivers/i2c/busses/i2c-cpm.c:450:2: error: implicit declaration of function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration] drivers/i2c/busses/i2c-cpm.c:461:2: error: implicit declaration of function 'of_iomap' [-Werror=implicit-function-declaration] It appears you picked this up from the latest mainline, where the same builds fail with the same error. The problem was introduced in mainline between rc6 and rc7. I have no immediate idea which patch causes the problem. I can bisect tomorrow if needed. Probably this one exposing additional code to be built: From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001 From: Richard Weinberger Date: Sun, 9 Feb 2014 19:47:40 +0100 Subject: i2c: Remove usage of orphaned symbol OF_I2C From: Richard Weinberger commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream. The symbol is an orphan, don't depend on it anymore. Signed-off-by: Richard Weinberger [wsa: enhanced commit message] Signed-off-by: Wolfram Sang Fixes: 687b81d083c0 (i2c: move OF helpers into the core) Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -387,7 +387,7 @@ config I2C_CBUS_GPIO config I2C_CPM tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)" - depends on (CPM1 || CPM2) && OF_I2C + depends on CPM1 || CPM2 help This supports the use of the I2C interface on Freescale processors with CPM1 or CPM2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 000/149] 3.13.7-stable review
Thomas Backlund skrev 21.3.2014 10:42: Guenter Roeck skrev 21.3.2014 07:37: On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.13.7 release. There are 149 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Mar 23 00:03:54 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 120 skipped: 4 fail: 2 qemu tests all passed. There are two new build failures. Building powerpc:mpc85xx_defconfig ... failed Building powerpc:mpc85xx_smp_defconfig ... failed The failure is the same in both cases. drivers/i2c/busses/i2c-cpm.c: In function 'cpm_i2c_setup': drivers/i2c/busses/i2c-cpm.c:450:2: error: implicit declaration of function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration] drivers/i2c/busses/i2c-cpm.c:461:2: error: implicit declaration of function 'of_iomap' [-Werror=implicit-function-declaration] It appears you picked this up from the latest mainline, where the same builds fail with the same error. The problem was introduced in mainline between rc6 and rc7. I have no immediate idea which patch causes the problem. I can bisect tomorrow if needed. Probably this one exposing additional code to be built: From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001 From: Richard Weinberger Date: Sun, 9 Feb 2014 19:47:40 +0100 Subject: i2c: Remove usage of orphaned symbol OF_I2C From: Richard Weinberger commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream. The symbol is an orphan, don't depend on it anymore. Signed-off-by: Richard Weinberger [wsa: enhanced commit message] Signed-off-by: Wolfram Sang Fixes: 687b81d083c0 (i2c: move OF helpers into the core) Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -387,7 +387,7 @@ config I2C_CBUS_GPIO config I2C_CPM tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)" - depends on (CPM1 || CPM2) && OF_I2C + depends on CPM1 || CPM2 help This supports the use of the I2C interface on Freescale processors with CPM1 or CPM2. and the buildfix was posted to upstream and -stable a couple of days ago (not in upstream linus tree yet), with subject: [PATCH] i2c-cpm: Fix build by adding of_address.h and of_irq.h Fixes a build break due to the undeclared use of irq_of_parse_and_map() and of_iomap(). This build break was apparently introduced while the driver was unbuildable due to the bug fixed by 62c19c9d29e65086e5ae76df371ed2e6b23f00cd ("i2c: Remove usage of orphaned symbol OF_I2C"). When 62c19c was added in v3.14-rc7, the driver was enabled again, breaking the powerpc mpc85xx_defconfig and mpc85xx_smp_defconfig. 62c19c is marked for stable, so this should go there as well. Signed-off-by: Scott Wood Reported-by: Geert Uytterhoeven Cc: Richard Weinberger Cc: sta...@kernel.org --- There are still warnings in this driver that suggest it is broken with CONFIG_PHYS_64BIT, but that part does not appear to be a regression. drivers/i2c/busses/i2c-cpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index be7f0a2..f3b89a4 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -39,7 +39,9 @@ #include #include #include +#include #include +#include #include #include #include -- 1.8.3.2 -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 000/149] 3.13.7-stable review
Thomas Backlund skrev 21.3.2014 10:42: Guenter Roeck skrev 21.3.2014 07:37: On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.13.7 release. There are 149 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Mar 23 00:03:54 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 120 skipped: 4 fail: 2 qemu tests all passed. There are two new build failures. Building powerpc:mpc85xx_defconfig ... failed Building powerpc:mpc85xx_smp_defconfig ... failed The failure is the same in both cases. drivers/i2c/busses/i2c-cpm.c: In function 'cpm_i2c_setup': drivers/i2c/busses/i2c-cpm.c:450:2: error: implicit declaration of function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration] drivers/i2c/busses/i2c-cpm.c:461:2: error: implicit declaration of function 'of_iomap' [-Werror=implicit-function-declaration] It appears you picked this up from the latest mainline, where the same builds fail with the same error. The problem was introduced in mainline between rc6 and rc7. I have no immediate idea which patch causes the problem. I can bisect tomorrow if needed. Probably this one exposing additional code to be built: From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001 From: Richard Weinberger rich...@nod.at Date: Sun, 9 Feb 2014 19:47:40 +0100 Subject: i2c: Remove usage of orphaned symbol OF_I2C From: Richard Weinberger rich...@nod.at commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream. The symbol is an orphan, don't depend on it anymore. Signed-off-by: Richard Weinberger rich...@nod.at [wsa: enhanced commit message] Signed-off-by: Wolfram Sang w...@the-dreams.de Fixes: 687b81d083c0 (i2c: move OF helpers into the core) Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/i2c/busses/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -387,7 +387,7 @@ config I2C_CBUS_GPIO config I2C_CPM tristate Freescale CPM1 or CPM2 (MPC8xx/826x) - depends on (CPM1 || CPM2) OF_I2C + depends on CPM1 || CPM2 help This supports the use of the I2C interface on Freescale processors with CPM1 or CPM2. and the buildfix was posted to upstream and -stable a couple of days ago (not in upstream linus tree yet), with subject: [PATCH] i2c-cpm: Fix build by adding of_address.h and of_irq.h Fixes a build break due to the undeclared use of irq_of_parse_and_map() and of_iomap(). This build break was apparently introduced while the driver was unbuildable due to the bug fixed by 62c19c9d29e65086e5ae76df371ed2e6b23f00cd (i2c: Remove usage of orphaned symbol OF_I2C). When 62c19c was added in v3.14-rc7, the driver was enabled again, breaking the powerpc mpc85xx_defconfig and mpc85xx_smp_defconfig. 62c19c is marked for stable, so this should go there as well. Signed-off-by: Scott Wood scottw...@freescale.com Reported-by: Geert Uytterhoeven ge...@linux-m68k.org Cc: Richard Weinberger rich...@nod.at Cc: sta...@kernel.org --- There are still warnings in this driver that suggest it is broken with CONFIG_PHYS_64BIT, but that part does not appear to be a regression. drivers/i2c/busses/i2c-cpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index be7f0a2..f3b89a4 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -39,7 +39,9 @@ #include linux/i2c.h #include linux/io.h #include linux/dma-mapping.h +#include linux/of_address.h #include linux/of_device.h +#include linux/of_irq.h #include linux/of_platform.h #include sysdev/fsl_soc.h #include asm/cpm.h -- 1.8.3.2 -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 000/149] 3.13.7-stable review
Guenter Roeck skrev 21.3.2014 07:37: On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.13.7 release. There are 149 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Mar 23 00:03:54 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 120 skipped: 4 fail: 2 qemu tests all passed. There are two new build failures. Building powerpc:mpc85xx_defconfig ... failed Building powerpc:mpc85xx_smp_defconfig ... failed The failure is the same in both cases. drivers/i2c/busses/i2c-cpm.c: In function 'cpm_i2c_setup': drivers/i2c/busses/i2c-cpm.c:450:2: error: implicit declaration of function 'irq_of_parse_and_map' [-Werror=implicit-function-declaration] drivers/i2c/busses/i2c-cpm.c:461:2: error: implicit declaration of function 'of_iomap' [-Werror=implicit-function-declaration] It appears you picked this up from the latest mainline, where the same builds fail with the same error. The problem was introduced in mainline between rc6 and rc7. I have no immediate idea which patch causes the problem. I can bisect tomorrow if needed. Probably this one exposing additional code to be built: From 62c19c9d29e65086e5ae76df371ed2e6b23f00cd Mon Sep 17 00:00:00 2001 From: Richard Weinberger rich...@nod.at Date: Sun, 9 Feb 2014 19:47:40 +0100 Subject: i2c: Remove usage of orphaned symbol OF_I2C From: Richard Weinberger rich...@nod.at commit 62c19c9d29e65086e5ae76df371ed2e6b23f00cd upstream. The symbol is an orphan, don't depend on it anymore. Signed-off-by: Richard Weinberger rich...@nod.at [wsa: enhanced commit message] Signed-off-by: Wolfram Sang w...@the-dreams.de Fixes: 687b81d083c0 (i2c: move OF helpers into the core) Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/i2c/busses/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -387,7 +387,7 @@ config I2C_CBUS_GPIO config I2C_CPM tristate Freescale CPM1 or CPM2 (MPC8xx/826x) - depends on (CPM1 || CPM2) OF_I2C + depends on CPM1 || CPM2 help This supports the use of the I2C interface on Freescale processors with CPM1 or CPM2. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZRAM 3.10.6 Buffer I/O error
Minchan Kim skrev 13.8.2013 07:33: Hello Greg, On Mon, Aug 12, 2013 at 08:58:02PM -0700, Greg Kroah-Hartman wrote: On Tue, Aug 13, 2013 at 10:39:00AM +0900, Minchan Kim wrote: Hello, On Mon, Aug 12, 2013 at 07:39:46PM +0300, Thomas Backlund wrote: 12.08.2013 17:27, Jordi Pujol skrev: Hello, zram shows an error when mounting a swap partition, current version Linux kernel 3.10.6, previous versions worked, I suppose that latest zram patches have some problem, machine is an AMD64 dual core, 4GB RAM + modprobe -qb zram num_devices=2 + echo 104857600 > /sys/block/zram0/disksize # mkswap /dev/zram0 Setting up swapspace version 1, size = 102396 KiB no label, UUID=6c249930-2ba0-46cf-a8c6-766481942b7d # pager /var/log/dmesg (no more errors shown) # swapon /dev/zram0 # pager /var/log/dmesg ... [ 309.300479] Buffer I/O error on device zram0, logical block 25599 [ 309.300491] Buffer I/O error on device zram0, logical block 25599 [ 309.300514] Buffer I/O error on device zram0, logical block 25599 [ 345.205887] Adding 102396k swap on /dev/zram0. Priority:-2 extents:1 across:102396k SSFS full log files and the kernel source are stored in the address: http://livenet.selfip.com/ftp/debian/zram_3.10.6_IO_error/ I think this one should fix it and belongs in 3.10 stable too: Very true. Let's Cc Greg, explicitely. -ENOCONTEXT https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/staging/zram?id=75c7caf5a052ffd8db3312fa7864ee2d142890c4 It seems you already merge "zram:allow request end to conincide with disksize" to stable. So there is no concern any more. Nope... thats master branch wich tracks upstream tree... it's not in the 3.10 stable as of 3.10.6 (or current stable queue) https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/staging/zram?h=linux-3.10.y -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZRAM 3.10.6 Buffer I/O error
12.08.2013 17:27, Jordi Pujol skrev: Hello, zram shows an error when mounting a swap partition, current version Linux kernel 3.10.6, previous versions worked, I suppose that latest zram patches have some problem, machine is an AMD64 dual core, 4GB RAM + modprobe -qb zram num_devices=2 + echo 104857600 > /sys/block/zram0/disksize # mkswap /dev/zram0 Setting up swapspace version 1, size = 102396 KiB no label, UUID=6c249930-2ba0-46cf-a8c6-766481942b7d # pager /var/log/dmesg (no more errors shown) # swapon /dev/zram0 # pager /var/log/dmesg ... [ 309.300479] Buffer I/O error on device zram0, logical block 25599 [ 309.300491] Buffer I/O error on device zram0, logical block 25599 [ 309.300514] Buffer I/O error on device zram0, logical block 25599 [ 345.205887] Adding 102396k swap on /dev/zram0. Priority:-2 extents:1 across:102396k SSFS full log files and the kernel source are stored in the address: http://livenet.selfip.com/ftp/debian/zram_3.10.6_IO_error/ I think this one should fix it and belongs in 3.10 stable too: From 75c7caf5a052ffd8db3312fa7864ee2d142890c4 Mon Sep 17 00:00:00 2001 From: Sergey Senozhatsky Date: Sat, 22 Jun 2013 14:21:00 + Subject: zram: allow request end to coincide with disksize Pass valid_io_request() checks if request end coincides with disksize (end equals bound), only fail if we attempt to read beyond the bound. mkfs.ext2 produces numerous errors: [ 2164.632747] quiet_error: 1 callbacks suppressed [ 2164.633260] Buffer I/O error on device zram0, logical block 153599 [ 2164.633265] lost page write due to I/O error on zram0 Signed-off-by: Sergey Senozhatsky Signed-off-by: Greg Kroah-Hartman --- diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c index 7538774..82c7202 100644 --- a/drivers/staging/zram/zram_drv.c +++ b/drivers/staging/zram/zram_drv.c @@ -180,7 +180,7 @@ static inline int valid_io_request(struct zram *zram, struct bio *bio) end = start + (bio->bi_size >> SECTOR_SHIFT); bound = zram->disksize >> SECTOR_SHIFT; /* out of range range */ - if (unlikely(start >= bound || end >= bound || start > end)) + if (unlikely(start >= bound || end > bound || start > end)) return 0; /* I/O request is valid */ -- cgit v0.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZRAM 3.10.6 Buffer I/O error
12.08.2013 17:27, Jordi Pujol skrev: Hello, zram shows an error when mounting a swap partition, current version Linux kernel 3.10.6, previous versions worked, I suppose that latest zram patches have some problem, machine is an AMD64 dual core, 4GB RAM + modprobe -qb zram num_devices=2 + echo 104857600 /sys/block/zram0/disksize # mkswap /dev/zram0 Setting up swapspace version 1, size = 102396 KiB no label, UUID=6c249930-2ba0-46cf-a8c6-766481942b7d # pager /var/log/dmesg (no more errors shown) # swapon /dev/zram0 # pager /var/log/dmesg ... [ 309.300479] Buffer I/O error on device zram0, logical block 25599 [ 309.300491] Buffer I/O error on device zram0, logical block 25599 [ 309.300514] Buffer I/O error on device zram0, logical block 25599 [ 345.205887] Adding 102396k swap on /dev/zram0. Priority:-2 extents:1 across:102396k SSFS full log files and the kernel source are stored in the address: http://livenet.selfip.com/ftp/debian/zram_3.10.6_IO_error/ I think this one should fix it and belongs in 3.10 stable too: From 75c7caf5a052ffd8db3312fa7864ee2d142890c4 Mon Sep 17 00:00:00 2001 From: Sergey Senozhatsky sergey.senozhat...@gmail.com Date: Sat, 22 Jun 2013 14:21:00 + Subject: zram: allow request end to coincide with disksize Pass valid_io_request() checks if request end coincides with disksize (end equals bound), only fail if we attempt to read beyond the bound. mkfs.ext2 produces numerous errors: [ 2164.632747] quiet_error: 1 callbacks suppressed [ 2164.633260] Buffer I/O error on device zram0, logical block 153599 [ 2164.633265] lost page write due to I/O error on zram0 Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c index 7538774..82c7202 100644 --- a/drivers/staging/zram/zram_drv.c +++ b/drivers/staging/zram/zram_drv.c @@ -180,7 +180,7 @@ static inline int valid_io_request(struct zram *zram, struct bio *bio) end = start + (bio-bi_size SECTOR_SHIFT); bound = zram-disksize SECTOR_SHIFT; /* out of range range */ - if (unlikely(start = bound || end = bound || start end)) + if (unlikely(start = bound || end bound || start end)) return 0; /* I/O request is valid */ -- cgit v0.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZRAM 3.10.6 Buffer I/O error
Minchan Kim skrev 13.8.2013 07:33: Hello Greg, On Mon, Aug 12, 2013 at 08:58:02PM -0700, Greg Kroah-Hartman wrote: On Tue, Aug 13, 2013 at 10:39:00AM +0900, Minchan Kim wrote: Hello, On Mon, Aug 12, 2013 at 07:39:46PM +0300, Thomas Backlund wrote: 12.08.2013 17:27, Jordi Pujol skrev: Hello, zram shows an error when mounting a swap partition, current version Linux kernel 3.10.6, previous versions worked, I suppose that latest zram patches have some problem, machine is an AMD64 dual core, 4GB RAM + modprobe -qb zram num_devices=2 + echo 104857600 /sys/block/zram0/disksize # mkswap /dev/zram0 Setting up swapspace version 1, size = 102396 KiB no label, UUID=6c249930-2ba0-46cf-a8c6-766481942b7d # pager /var/log/dmesg (no more errors shown) # swapon /dev/zram0 # pager /var/log/dmesg ... [ 309.300479] Buffer I/O error on device zram0, logical block 25599 [ 309.300491] Buffer I/O error on device zram0, logical block 25599 [ 309.300514] Buffer I/O error on device zram0, logical block 25599 [ 345.205887] Adding 102396k swap on /dev/zram0. Priority:-2 extents:1 across:102396k SSFS full log files and the kernel source are stored in the address: http://livenet.selfip.com/ftp/debian/zram_3.10.6_IO_error/ I think this one should fix it and belongs in 3.10 stable too: Very true. Let's Cc Greg, explicitely. -ENOCONTEXT https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/staging/zram?id=75c7caf5a052ffd8db3312fa7864ee2d142890c4 It seems you already merge zram:allow request end to conincide with disksize to stable. So there is no concern any more. Nope... thats master branch wich tracks upstream tree... it's not in the 3.10 stable as of 3.10.6 (or current stable queue) https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/staging/zram?h=linux-3.10.y -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 089/145] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets
18.07.2013 13:37, Neil Horman skrev: On Thu, Jul 18, 2013 at 11:02:00AM +0300, Thomas Backlund wrote: 18.07.2013 01:47, Kamal Mostafa skrev: 3.8.13.5 -stable review patch. If anyone has any objections, please let me know. -- From: Neil Horman commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream. A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and 5500 chipsets which contained an errata (specificially errata 53), which noted that these chipsets can't properly do interrupt remapping, and as a result the recommend that interrupt remapping be disabled in bios. While many vendors have a bios update to do exactly that, not all do, and of course not all users update their bios to a level that corrects the problem. As a result, occasionally interrupts can arrive at a cpu even after affinity for that interrupt has be moved, leading to lost or spurrious interrupts (usually characterized by the message: kernel: do_IRQ: 7.71 No irq handler for vector (irq -1) There have been several incidents recently of people seeing this error, and investigation has shown that they have system for which their BIOS level is such that this feature was not properly turned off. As such, it would be good to give them a reminder that their systems are vulnurable to this problem. For details of those that reported the problem, please see: https://bugzilla.redhat.com/show_bug.cgi?id=887006 [ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ] Signed-off-by: Neil Horman CC: Prarit Bhargava CC: Don Zickus CC: Don Dutile CC: Bjorn Helgaas CC: Asit Mallick CC: David Woodhouse CC: linux-...@vger.kernel.org CC: Joerg Roedel CC: Konrad Rzeszutek Wilk CC: Arkadiusz Miśkiewicz Signed-off-by: Joerg Roedel Signed-off-by: Luis Henriques --- arch/x86/include/asm/irq_remapping.h | 2 ++ arch/x86/kernel/early-quirks.c | 20 drivers/iommu/intel_irq_remapping.c | 10 ++ drivers/iommu/irq_remapping.c| 6 ++ drivers/iommu/irq_remapping.h| 2 ++ 5 files changed, 40 insertions(+) This patch introduces this warning on 3.8 series kernels: In file included from arch/x86/kernel/early-quirks.c:21:0: /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: varning: ”struct irq_data” deklarerad inuti parameterlista [aktiverat som standard] /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: varning: dess scope-område är endast denna definition eller deklaration, vilket troligen inte är vad du vill. [aktiverat som standard] /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17: varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat som standard] You need to add this upstream fix too: commit 35d3d814cbd46a85bed97cd74ba97fbbb51e0ccd Author: Joerg Roedel Date: Fri Apr 19 20:34:55 2013 +0200 iommu: Fix compile warnings with forward declarations I submited a 3.9 backport that included that fix to -stable over a week ago, you should just be able to use that if you want. Neil Almost, but not enough... The patch you refer to was: [3.9 stable PATCH] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets and got merged in 3.9.9. And that added a missing: "#include " in arch/x86/include/asm/irq_remapping.h But using that patch it still spits out: kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17: >> varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat >> som standard] which is why the additional patch is still needed... -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 089/145] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets
18.07.2013 01:47, Kamal Mostafa skrev: 3.8.13.5 -stable review patch. If anyone has any objections, please let me know. -- From: Neil Horman commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream. A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and 5500 chipsets which contained an errata (specificially errata 53), which noted that these chipsets can't properly do interrupt remapping, and as a result the recommend that interrupt remapping be disabled in bios. While many vendors have a bios update to do exactly that, not all do, and of course not all users update their bios to a level that corrects the problem. As a result, occasionally interrupts can arrive at a cpu even after affinity for that interrupt has be moved, leading to lost or spurrious interrupts (usually characterized by the message: kernel: do_IRQ: 7.71 No irq handler for vector (irq -1) There have been several incidents recently of people seeing this error, and investigation has shown that they have system for which their BIOS level is such that this feature was not properly turned off. As such, it would be good to give them a reminder that their systems are vulnurable to this problem. For details of those that reported the problem, please see: https://bugzilla.redhat.com/show_bug.cgi?id=887006 [ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ] Signed-off-by: Neil Horman CC: Prarit Bhargava CC: Don Zickus CC: Don Dutile CC: Bjorn Helgaas CC: Asit Mallick CC: David Woodhouse CC: linux-...@vger.kernel.org CC: Joerg Roedel CC: Konrad Rzeszutek Wilk CC: Arkadiusz Miśkiewicz Signed-off-by: Joerg Roedel Signed-off-by: Luis Henriques --- arch/x86/include/asm/irq_remapping.h | 2 ++ arch/x86/kernel/early-quirks.c | 20 drivers/iommu/intel_irq_remapping.c | 10 ++ drivers/iommu/irq_remapping.c| 6 ++ drivers/iommu/irq_remapping.h| 2 ++ 5 files changed, 40 insertions(+) This patch introduces this warning on 3.8 series kernels: In file included from arch/x86/kernel/early-quirks.c:21:0: /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: varning: ”struct irq_data” deklarerad inuti parameterlista [aktiverat som standard] /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: varning: dess scope-område är endast denna definition eller deklaration, vilket troligen inte är vad du vill. [aktiverat som standard] /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17: varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat som standard] You need to add this upstream fix too: commit 35d3d814cbd46a85bed97cd74ba97fbbb51e0ccd Author: Joerg Roedel Date: Fri Apr 19 20:34:55 2013 +0200 iommu: Fix compile warnings with forward declarations -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 089/145] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets
18.07.2013 01:47, Kamal Mostafa skrev: 3.8.13.5 -stable review patch. If anyone has any objections, please let me know. -- From: Neil Horman nhor...@tuxdriver.com commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream. A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and 5500 chipsets which contained an errata (specificially errata 53), which noted that these chipsets can't properly do interrupt remapping, and as a result the recommend that interrupt remapping be disabled in bios. While many vendors have a bios update to do exactly that, not all do, and of course not all users update their bios to a level that corrects the problem. As a result, occasionally interrupts can arrive at a cpu even after affinity for that interrupt has be moved, leading to lost or spurrious interrupts (usually characterized by the message: kernel: do_IRQ: 7.71 No irq handler for vector (irq -1) There have been several incidents recently of people seeing this error, and investigation has shown that they have system for which their BIOS level is such that this feature was not properly turned off. As such, it would be good to give them a reminder that their systems are vulnurable to this problem. For details of those that reported the problem, please see: https://bugzilla.redhat.com/show_bug.cgi?id=887006 [ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ] Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: Prarit Bhargava pra...@redhat.com CC: Don Zickus dzic...@redhat.com CC: Don Dutile ddut...@redhat.com CC: Bjorn Helgaas bhelg...@google.com CC: Asit Mallick asit.k.mall...@intel.com CC: David Woodhouse dw...@infradead.org CC: linux-...@vger.kernel.org CC: Joerg Roedel j...@8bytes.org CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com CC: Arkadiusz Miśkiewicz ar...@maven.pl Signed-off-by: Joerg Roedel j...@8bytes.org Signed-off-by: Luis Henriques luis.henriq...@canonical.com --- arch/x86/include/asm/irq_remapping.h | 2 ++ arch/x86/kernel/early-quirks.c | 20 drivers/iommu/intel_irq_remapping.c | 10 ++ drivers/iommu/irq_remapping.c| 6 ++ drivers/iommu/irq_remapping.h| 2 ++ 5 files changed, 40 insertions(+) This patch introduces this warning on 3.8 series kernels: In file included from arch/x86/kernel/early-quirks.c:21:0: /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: varning: ”struct irq_data” deklarerad inuti parameterlista [aktiverat som standard] /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: varning: dess scope-område är endast denna definition eller deklaration, vilket troligen inte är vad du vill. [aktiverat som standard] /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17: varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat som standard] You need to add this upstream fix too: commit 35d3d814cbd46a85bed97cd74ba97fbbb51e0ccd Author: Joerg Roedel j...@8bytes.org Date: Fri Apr 19 20:34:55 2013 +0200 iommu: Fix compile warnings with forward declarations -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 089/145] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets
18.07.2013 13:37, Neil Horman skrev: On Thu, Jul 18, 2013 at 11:02:00AM +0300, Thomas Backlund wrote: 18.07.2013 01:47, Kamal Mostafa skrev: 3.8.13.5 -stable review patch. If anyone has any objections, please let me know. -- From: Neil Horman nhor...@tuxdriver.com commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream. A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and 5500 chipsets which contained an errata (specificially errata 53), which noted that these chipsets can't properly do interrupt remapping, and as a result the recommend that interrupt remapping be disabled in bios. While many vendors have a bios update to do exactly that, not all do, and of course not all users update their bios to a level that corrects the problem. As a result, occasionally interrupts can arrive at a cpu even after affinity for that interrupt has be moved, leading to lost or spurrious interrupts (usually characterized by the message: kernel: do_IRQ: 7.71 No irq handler for vector (irq -1) There have been several incidents recently of people seeing this error, and investigation has shown that they have system for which their BIOS level is such that this feature was not properly turned off. As such, it would be good to give them a reminder that their systems are vulnurable to this problem. For details of those that reported the problem, please see: https://bugzilla.redhat.com/show_bug.cgi?id=887006 [ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ] Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: Prarit Bhargava pra...@redhat.com CC: Don Zickus dzic...@redhat.com CC: Don Dutile ddut...@redhat.com CC: Bjorn Helgaas bhelg...@google.com CC: Asit Mallick asit.k.mall...@intel.com CC: David Woodhouse dw...@infradead.org CC: linux-...@vger.kernel.org CC: Joerg Roedel j...@8bytes.org CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com CC: Arkadiusz Miśkiewicz ar...@maven.pl Signed-off-by: Joerg Roedel j...@8bytes.org Signed-off-by: Luis Henriques luis.henriq...@canonical.com --- arch/x86/include/asm/irq_remapping.h | 2 ++ arch/x86/kernel/early-quirks.c | 20 drivers/iommu/intel_irq_remapping.c | 10 ++ drivers/iommu/irq_remapping.c| 6 ++ drivers/iommu/irq_remapping.h| 2 ++ 5 files changed, 40 insertions(+) This patch introduces this warning on 3.8 series kernels: In file included from arch/x86/kernel/early-quirks.c:21:0: /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: varning: ”struct irq_data” deklarerad inuti parameterlista [aktiverat som standard] /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:46:10: varning: dess scope-område är endast denna definition eller deklaration, vilket troligen inte är vad du vill. [aktiverat som standard] /kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17: varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat som standard] You need to add this upstream fix too: commit 35d3d814cbd46a85bed97cd74ba97fbbb51e0ccd Author: Joerg Roedel j...@8bytes.org Date: Fri Apr 19 20:34:55 2013 +0200 iommu: Fix compile warnings with forward declarations I submited a 3.9 backport that included that fix to -stable over a week ago, you should just be able to use that if you want. Neil Almost, but not enough... The patch you refer to was: [3.9 stable PATCH] iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets and got merged in 3.9.9. And that added a missing: #include linux/irq.h in arch/x86/include/asm/irq_remapping.h But using that patch it still spits out: kernel/linux-3.8.13.5/arch/x86/include/asm/irq_remapping.h:50:17: varning: ”struct msi_msg” deklarerad inuti parameterlista [aktiverat som standard] which is why the additional patch is still needed... -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
perf 3.8-rc build failure: undefined reference to `strlcpy'
[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all ... /tmp/ccJEJv6m.o: In function `main': :(.text+0x14): undefined reference to `strlcpy' collect2: ld returned 1 exit status ... This did not show up in 3.7 -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/74] perf python: Fix breakage introduced by the test_attr infrastructure
Arnaldo Carvalho de Melo skrev 24.1.2013 22:07: From: Arnaldo Carvalho de Melo The test_attr infrastructure hooks on the sys_perf_event_open call, checking if a variable is set and if so calling a function to intercept calls and do the checking. But both the variable and the function aren't on objects that are linked on the python binding, breaking it: Atleast this one is 3.8 material as it is a regression since 3.7 [tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all python_ext_build/tmp/util/evsel.o: In function `sys_perf_event_open': /mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:183: undefined reference to `test_attr__enabled' /mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:184: undefined reference to `test_attr__open' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 -- Thomas # perf test -v 15 15: Try 'use perf' in python, checking link problems : --- start --- Traceback (most recent call last): File "", line 1, in ImportError: /home/acme/git/build/perf//python/perf.so: undefined symbol: test_attr__enabled end Try 'use perf' in python, checking link problems: FAILED! # Fix it by moving the variable to one of the linked object files and providing a stub for the function in the python.o object, that is only linked in the python binding. Now 'perf test' is happy again: # perf test 15 15: Try 'use perf' in python, checking link problems : Ok # Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-0rsca2kn44b38rgdpr3tz...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/tests/attr.c | 2 -- tools/perf/util/python.c | 9 + tools/perf/util/util.c | 2 ++ 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c index 25638a9..05b5acb 100644 --- a/tools/perf/tests/attr.c +++ b/tools/perf/tests/attr.c @@ -33,8 +33,6 @@ extern int verbose; -bool test_attr__enabled; - static char *dir; void test_attr__init(void) diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c index a2657fd..925e0c3 100644 --- a/tools/perf/util/python.c +++ b/tools/perf/util/python.c @@ -1045,3 +1045,12 @@ error: if (PyErr_Occurred()) PyErr_SetString(PyExc_ImportError, "perf: Init failed!"); } + +/* + * Dummy, to avoid dragging all the test_attr infrastructure in the python + * binding. + */ +void test_attr__open(struct perf_event_attr *attr, pid_t pid, int cpu, + int fd, int group_fd, unsigned long flags) +{ +} diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c index 5906e84..252b889 100644 --- a/tools/perf/util/util.c +++ b/tools/perf/util/util.c @@ -12,6 +12,8 @@ */ unsigned int page_size; +bool test_attr__enabled; + bool perf_host = true; bool perf_guest = false; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
the patch "perf tools: Update Makefile for Android" broke 3.8-rc perf build.
Linux Kernel Mailing List skrev 12.12.2012 05:13: Gitweb: http://git.kernel.org/linus/;a=commit;h=d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4 Commit: d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4 Parent: 78da39faf7c903bb6e3c20a726fde1bf98d10af8 Author: Irina Tirdea AuthorDate: Mon Oct 8 09:43:27 2012 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon Oct 8 17:42:16 2012 -0300 perf tools: Update Makefile for Android For cross-compiling on Android, some specific changes are needed in the Makefile. The above patch broke perf build on i586 and x86_64: [tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all CHK -fstack-protector-all CHK -Wstack-protector CHK -Wvolatile-register-var CHK bionic :1:31: fatal error: android/api-level.h: No such file or directory compilation terminated. This is a regression since 3.7 -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
the patch perf tools: Update Makefile for Android broke 3.8-rc perf build.
Linux Kernel Mailing List skrev 12.12.2012 05:13: Gitweb: http://git.kernel.org/linus/;a=commit;h=d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4 Commit: d816ec2d1bea55cfeac373f0ab0ab8a3105e49b4 Parent: 78da39faf7c903bb6e3c20a726fde1bf98d10af8 Author: Irina Tirdea irina.tir...@intel.com AuthorDate: Mon Oct 8 09:43:27 2012 +0300 Committer: Arnaldo Carvalho de Melo a...@redhat.com CommitDate: Mon Oct 8 17:42:16 2012 -0300 perf tools: Update Makefile for Android For cross-compiling on Android, some specific changes are needed in the Makefile. The above patch broke perf build on i586 and x86_64: [tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all CHK -fstack-protector-all CHK -Wstack-protector CHK -Wvolatile-register-var CHK bionic stdin:1:31: fatal error: android/api-level.h: No such file or directory compilation terminated. This is a regression since 3.7 -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/74] perf python: Fix breakage introduced by the test_attr infrastructure
Arnaldo Carvalho de Melo skrev 24.1.2013 22:07: From: Arnaldo Carvalho de Melo a...@redhat.com The test_attr infrastructure hooks on the sys_perf_event_open call, checking if a variable is set and if so calling a function to intercept calls and do the checking. But both the variable and the function aren't on objects that are linked on the python binding, breaking it: Atleast this one is 3.8 material as it is a regression since 3.7 [tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all python_ext_build/tmp/util/evsel.o: In function `sys_perf_event_open': /mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:183: undefined reference to `test_attr__enabled' /mnt/work/Mageia/RPM/1Work/kerenels/linux-3.8-rc5/tools/perf/util/../perf.h:184: undefined reference to `test_attr__open' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 -- Thomas # perf test -v 15 15: Try 'use perf' in python, checking link problems : --- start --- Traceback (most recent call last): File stdin, line 1, in module ImportError: /home/acme/git/build/perf//python/perf.so: undefined symbol: test_attr__enabled end Try 'use perf' in python, checking link problems: FAILED! # Fix it by moving the variable to one of the linked object files and providing a stub for the function in the python.o object, that is only linked in the python binding. Now 'perf test' is happy again: # perf test 15 15: Try 'use perf' in python, checking link problems : Ok # Cc: David Ahern dsah...@gmail.com Cc: Frederic Weisbecker fweis...@gmail.com Cc: Jiri Olsa jo...@redhat.com Cc: Mike Galbraith efa...@gmx.de Cc: Namhyung Kim namhy...@gmail.com Cc: Paul Mackerras pau...@samba.org Cc: Peter Zijlstra pet...@infradead.org Cc: Stephane Eranian eran...@google.com Link: http://lkml.kernel.org/n/tip-0rsca2kn44b38rgdpr3tz...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com --- tools/perf/tests/attr.c | 2 -- tools/perf/util/python.c | 9 + tools/perf/util/util.c | 2 ++ 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c index 25638a9..05b5acb 100644 --- a/tools/perf/tests/attr.c +++ b/tools/perf/tests/attr.c @@ -33,8 +33,6 @@ extern int verbose; -bool test_attr__enabled; - static char *dir; void test_attr__init(void) diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c index a2657fd..925e0c3 100644 --- a/tools/perf/util/python.c +++ b/tools/perf/util/python.c @@ -1045,3 +1045,12 @@ error: if (PyErr_Occurred()) PyErr_SetString(PyExc_ImportError, perf: Init failed!); } + +/* + * Dummy, to avoid dragging all the test_attr infrastructure in the python + * binding. + */ +void test_attr__open(struct perf_event_attr *attr, pid_t pid, int cpu, + int fd, int group_fd, unsigned long flags) +{ +} diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c index 5906e84..252b889 100644 --- a/tools/perf/util/util.c +++ b/tools/perf/util/util.c @@ -12,6 +12,8 @@ */ unsigned int page_size; +bool test_attr__enabled; + bool perf_host = true; bool perf_guest = false; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
perf 3.8-rc build failure: undefined reference to `strlcpy'
[tmb@tmb linux-3.8-rc5]$ make -C tools/perf -s V=1 HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all ... /tmp/ccJEJv6m.o: In function `main': :(.text+0x14): undefined reference to `strlcpy' collect2: ld returned 1 exit status ... This did not show up in 3.7 -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi
Cong Wang skrev 15.1.2013 12:11: On Tue, 2013-01-15 at 12:03 +0200, Thomas Backlund wrote: Eric Blake skrev 15.1.2013 01:57: On 01/13/2013 01:05 PM, Thomas Backlund wrote: Thomas Backlund skrev 13.1.2013 20:38: patch both inline and attached as thunderbird tends to mess up ... - if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Ok, ignore this patch, it's not the correct fix as it introduces redefinitions... Btw, the error that I hit that made me suggest this fix was libvirt config check bailing out: config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has incomplete type Hmm, just now noticing this thread, after independently hitting and and having to work around the same problem in libvirt: https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html https://bugzilla.redhat.com/show_bug.cgi?id=895141 Yep, and the commit breaking uapi headers is by using "struct in6_addr ip6" is: From ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 Mon Sep 17 00:00:00 2001 From: Cong Wang Date: Fri, 7 Dec 2012 00:04:48 + Subject: [PATCH] bridge: export multicast database via netlink Does the following patch help? $ git diff include/uapi/linux/if_bridge.h diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h index 5db2975..653db23 100644 --- a/include/uapi/linux/if_bridge.h +++ b/include/uapi/linux/if_bridge.h @@ -14,6 +14,7 @@ #define _UAPI_LINUX_IF_BRIDGE_H #include +#include #define SYSFS_BRIDGE_ATTR "bridge" #define SYSFS_BRIDGE_FDB "brforward" Well, I suggested the same fix in the beginning of the thread on netdev and lkml: "if_bridge.h: include in6.h for struct in6_addr use" as it seemed to fix the libvirt case but then asked it to be ignored after I tried to build connman, and hit this conflict with glibc-2.17: In file included from /usr/include/arpa/inet.h:22:0, from ./include/connman/inet.h:25, from src/connman.h:128, from src/tethering.c:40: /usr/include/netinet/in.h:35:5: error: expected identifier before numeric constant /usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr' In file included from /usr/include/linux/if_bridge.h:17:0, from src/tethering.c:38: /usr/include/linux/in6.h:30:8: note: originally defined here In file included from /usr/include/arpa/inet.h:22:0, from ./include/connman/inet.h:25, from src/connman.h:128, from src/tethering.c:40: /usr/include/netinet/in.h:238:8: error: redefinition of 'struct sockaddr_in6' In file included from /usr/include/linux/if_bridge.h:17:0, from src/tethering.c:38: /usr/include/linux/in6.h:46:8: note: originally defined here In file included from /usr/include/arpa/inet.h:22:0, from ./include/connman/inet.h:25, from src/connman.h:128, from src/tethering.c:40: /usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq' In file included from /usr/include/linux/if_bridge.h:17:0, from src/tethering.c:38: /usr/include/linux/in6.h:54:8: note: originally defined here make[1]: *** [src/src_connmand-tethering.o] Error 1 So I'm not sure it's the right one... -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
the patch "bridge: export multicast database via netlink" broke kernel 3.8 uapi (was: Re: [libvirt] if_bridge.h: include in6.h for struct in6_addr use)
Eric Blake skrev 15.1.2013 01:57: On 01/13/2013 01:05 PM, Thomas Backlund wrote: Thomas Backlund skrev 13.1.2013 20:38: patch both inline and attached as thunderbird tends to mess up ... - if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Ok, ignore this patch, it's not the correct fix as it introduces redefinitions... Btw, the error that I hit that made me suggest this fix was libvirt config check bailing out: config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has incomplete type Hmm, just now noticing this thread, after independently hitting and and having to work around the same problem in libvirt: https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html https://bugzilla.redhat.com/show_bug.cgi?id=895141 Yep, and the commit breaking uapi headers is by using "struct in6_addr ip6" is: From ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 Mon Sep 17 00:00:00 2001 From: Cong Wang Date: Fri, 7 Dec 2012 00:04:48 + Subject: [PATCH] bridge: export multicast database via netlink V5: fix two bugs pointed out by Thomas remove seq check for now, mark it as TODO V4: remove some useless #include some coding style fix V3: drop debugging printk's update selinux perm table as well V2: drop patch 1/2, export ifindex directly Redesign netlink attributes Improve netlink seq check Handle IPv6 addr as well This patch exports bridge multicast database via netlink message type RTM_GETMDB. Similar to fdb, but currently bridge-specific. We may need to support modify multicast database too (RTM_{ADD,DEL}MDB). (Thanks to Thomas for patient reviews) Cc: Herbert Xu Cc: Stephen Hemminger Cc: "David S. Miller" Cc: Thomas Graf Cc: Jesper Dangaard Brouer Signed-off-by: Cong Wang Acked-by: Thomas Graf Signed-off-by: David S. Miller --- include/uapi/linux/if_bridge.h | 55 ++ include/uapi/linux/rtnetlink.h |3 + net/bridge/Makefile|2 +- net/bridge/br_mdb.c| 163 net/bridge/br_multicast.c |1 + net/bridge/br_private.h|1 + security/selinux/nlmsgtab.c|1 + 7 files changed, 225 insertions(+), 1 deletions(-) create mode 100644 net/bridge/br_mdb.c -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
the patch bridge: export multicast database via netlink broke kernel 3.8 uapi (was: Re: [libvirt] if_bridge.h: include in6.h for struct in6_addr use)
Eric Blake skrev 15.1.2013 01:57: On 01/13/2013 01:05 PM, Thomas Backlund wrote: Thomas Backlund skrev 13.1.2013 20:38: patch both inline and attached as thunderbird tends to mess up ... - if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Ok, ignore this patch, it's not the correct fix as it introduces redefinitions... Btw, the error that I hit that made me suggest this fix was libvirt config check bailing out: config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has incomplete type Hmm, just now noticing this thread, after independently hitting and and having to work around the same problem in libvirt: https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html https://bugzilla.redhat.com/show_bug.cgi?id=895141 Yep, and the commit breaking uapi headers is by using struct in6_addr ip6 is: From ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 Mon Sep 17 00:00:00 2001 From: Cong Wang amw...@redhat.com Date: Fri, 7 Dec 2012 00:04:48 + Subject: [PATCH] bridge: export multicast database via netlink V5: fix two bugs pointed out by Thomas remove seq check for now, mark it as TODO V4: remove some useless #include some coding style fix V3: drop debugging printk's update selinux perm table as well V2: drop patch 1/2, export ifindex directly Redesign netlink attributes Improve netlink seq check Handle IPv6 addr as well This patch exports bridge multicast database via netlink message type RTM_GETMDB. Similar to fdb, but currently bridge-specific. We may need to support modify multicast database too (RTM_{ADD,DEL}MDB). (Thanks to Thomas for patient reviews) Cc: Herbert Xu herb...@gondor.apana.org.au Cc: Stephen Hemminger shemmin...@vyatta.com Cc: David S. Miller da...@davemloft.net Cc: Thomas Graf tg...@suug.ch Cc: Jesper Dangaard Brouer bro...@redhat.com Signed-off-by: Cong Wang amw...@redhat.com Acked-by: Thomas Graf tg...@suug.ch Signed-off-by: David S. Miller da...@davemloft.net --- include/uapi/linux/if_bridge.h | 55 ++ include/uapi/linux/rtnetlink.h |3 + net/bridge/Makefile|2 +- net/bridge/br_mdb.c| 163 net/bridge/br_multicast.c |1 + net/bridge/br_private.h|1 + security/selinux/nlmsgtab.c|1 + 7 files changed, 225 insertions(+), 1 deletions(-) create mode 100644 net/bridge/br_mdb.c -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the patch bridge: export multicast database via netlink broke kernel 3.8 uapi
Cong Wang skrev 15.1.2013 12:11: On Tue, 2013-01-15 at 12:03 +0200, Thomas Backlund wrote: Eric Blake skrev 15.1.2013 01:57: On 01/13/2013 01:05 PM, Thomas Backlund wrote: Thomas Backlund skrev 13.1.2013 20:38: patch both inline and attached as thunderbird tends to mess up ... - if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Ok, ignore this patch, it's not the correct fix as it introduces redefinitions... Btw, the error that I hit that made me suggest this fix was libvirt config check bailing out: config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has incomplete type Hmm, just now noticing this thread, after independently hitting and and having to work around the same problem in libvirt: https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html https://bugzilla.redhat.com/show_bug.cgi?id=895141 Yep, and the commit breaking uapi headers is by using struct in6_addr ip6 is: From ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 Mon Sep 17 00:00:00 2001 From: Cong Wang amw...@redhat.com Date: Fri, 7 Dec 2012 00:04:48 + Subject: [PATCH] bridge: export multicast database via netlink Does the following patch help? $ git diff include/uapi/linux/if_bridge.h diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h index 5db2975..653db23 100644 --- a/include/uapi/linux/if_bridge.h +++ b/include/uapi/linux/if_bridge.h @@ -14,6 +14,7 @@ #define _UAPI_LINUX_IF_BRIDGE_H #include linux/types.h +#include linux/in6.h #define SYSFS_BRIDGE_ATTR bridge #define SYSFS_BRIDGE_FDB brforward Well, I suggested the same fix in the beginning of the thread on netdev and lkml: if_bridge.h: include in6.h for struct in6_addr use as it seemed to fix the libvirt case but then asked it to be ignored after I tried to build connman, and hit this conflict with glibc-2.17: In file included from /usr/include/arpa/inet.h:22:0, from ./include/connman/inet.h:25, from src/connman.h:128, from src/tethering.c:40: /usr/include/netinet/in.h:35:5: error: expected identifier before numeric constant /usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr' In file included from /usr/include/linux/if_bridge.h:17:0, from src/tethering.c:38: /usr/include/linux/in6.h:30:8: note: originally defined here In file included from /usr/include/arpa/inet.h:22:0, from ./include/connman/inet.h:25, from src/connman.h:128, from src/tethering.c:40: /usr/include/netinet/in.h:238:8: error: redefinition of 'struct sockaddr_in6' In file included from /usr/include/linux/if_bridge.h:17:0, from src/tethering.c:38: /usr/include/linux/in6.h:46:8: note: originally defined here In file included from /usr/include/arpa/inet.h:22:0, from ./include/connman/inet.h:25, from src/connman.h:128, from src/tethering.c:40: /usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq' In file included from /usr/include/linux/if_bridge.h:17:0, from src/tethering.c:38: /usr/include/linux/in6.h:54:8: note: originally defined here make[1]: *** [src/src_connmand-tethering.o] Error 1 So I'm not sure it's the right one... -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: if_bridge.h: include in6.h for struct in6_addr use
Thomas Backlund skrev 13.1.2013 20:38: patch both inline and attached as thunderbird tends to mess up ... - if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Ok, ignore this patch, it's not the correct fix as it introduces redefinitions... Btw, the error that I hit that made me suggest this fix was libvirt config check bailing out: config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has incomplete type Reported-by: Colin Guthrie Reported-by: Christiaan Welvaart Signed-off-by: Thomas Backlund -- diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h --- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 20:09:54.257271755 +0200 +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 20:15:04.153676151 +0200 @@ -14,6 +14,7 @@ #define _UAPI_LINUX_IF_BRIDGE_H #include +#include #define SYSFS_BRIDGE_ATTR "bridge" #define SYSFS_BRIDGE_FDB "brforward" - Thomas -- Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
if_bridge.h: include in6.h for struct in6_addr use
patch both inline and attached as thunderbird tends to mess up ... - if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Reported-by: Colin Guthrie Reported-by: Christiaan Welvaart Signed-off-by: Thomas Backlund -- diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h --- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 20:09:54.257271755 +0200 +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 20:15:04.153676151 +0200 @@ -14,6 +14,7 @@ #define _UAPI_LINUX_IF_BRIDGE_H #include +#include #define SYSFS_BRIDGE_ATTR "bridge" #define SYSFS_BRIDGE_FDB "brforward" - Thomas if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Reported-by: Colin Guthrie Reported-by: Christiaan Welvaart Signed-off-by: Thomas Backlund -- diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h --- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 20:09:54.257271755 +0200 +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 20:15:04.153676151 +0200 @@ -14,6 +14,7 @@ #define _UAPI_LINUX_IF_BRIDGE_H #include +#include #define SYSFS_BRIDGE_ATTR "bridge" #define SYSFS_BRIDGE_FDB "brforward"
if_bridge.h: include in6.h for struct in6_addr use
patch both inline and attached as thunderbird tends to mess up ... - if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Reported-by: Colin Guthrie co...@mageia.org Reported-by: Christiaan Welvaart c...@daneel.dyndns.org Signed-off-by: Thomas Backlund t...@mageia.org -- diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h --- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 20:09:54.257271755 +0200 +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 20:15:04.153676151 +0200 @@ -14,6 +14,7 @@ #define _UAPI_LINUX_IF_BRIDGE_H #include linux/types.h +#include linux/in6.h #define SYSFS_BRIDGE_ATTR bridge #define SYSFS_BRIDGE_FDB brforward - Thomas if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Reported-by: Colin Guthrie co...@mageia.org Reported-by: Christiaan Welvaart c...@daneel.dyndns.org Signed-off-by: Thomas Backlund t...@mageia.org -- diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h --- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 20:09:54.257271755 +0200 +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 20:15:04.153676151 +0200 @@ -14,6 +14,7 @@ #define _UAPI_LINUX_IF_BRIDGE_H #include linux/types.h +#include linux/in6.h #define SYSFS_BRIDGE_ATTR bridge #define SYSFS_BRIDGE_FDB brforward
Re: if_bridge.h: include in6.h for struct in6_addr use
Thomas Backlund skrev 13.1.2013 20:38: patch both inline and attached as thunderbird tends to mess up ... - if_bridge.h uses struct in6_addr ip6; but does not include the in6.h header. Found by trying to build libvirt and connman against 3.8-rc3 headers. Ok, ignore this patch, it's not the correct fix as it introduces redefinitions... Btw, the error that I hit that made me suggest this fix was libvirt config check bailing out: config.log:/usr/include/linux/if_bridge.h:173:20: error: field 'ip6' has incomplete type Reported-by: Colin Guthrie co...@mageia.org Reported-by: Christiaan Welvaart c...@daneel.dyndns.org Signed-off-by: Thomas Backlund t...@mageia.org -- diff -Nurp linux-3.8-rc3/include/uapi/linux/if_bridge.h linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h --- linux-3.8-rc3/include/uapi/linux/if_bridge.h2013-01-13 20:09:54.257271755 +0200 +++ linux-3.8-rc3.fix/include/uapi/linux/if_bridge.h2013-01-13 20:15:04.153676151 +0200 @@ -14,6 +14,7 @@ #define _UAPI_LINUX_IF_BRIDGE_H #include linux/types.h +#include linux/in6.h #define SYSFS_BRIDGE_ATTR bridge #define SYSFS_BRIDGE_FDB brforward - Thomas -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/