Re: [PATCH] parisc: avoid a warning on u8 cast for cmpxchg on u8 pointers
Am Dienstag, 6. April 2021, 06:59:29 CEST schrieb Gao Xiang: > From: Gao Xiang > > commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers") > can generate a sparse warningi ("cast truncates bits from constant ^ > value"), which has been reported several times [1] [2] [3]. signature.asc Description: This is a digitally signed message part.
[PATCH] typo: kthead -> kthread
Signed-off-by: Rolf Eike Beer --- kernel/rcu/tree_plugin.h | 2 +- mm/oom_kill.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 2d603771c7dc..5f22869d7c66 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1861,7 +1861,7 @@ static bool rcu_nocb_try_bypass(struct rcu_data *rdp, struct rcu_head *rhp, } /* - * Awaken the no-CBs grace-period kthead if needed, either due to it + * Awaken the no-CBs grace-period kthread if needed, either due to it * legitimately being asleep or due to overload conditions. * * If warranted, also wake up the kthread servicing this CPUs queues. diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 9efaf430cfd3..cd7f9ac48746 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -922,7 +922,7 @@ static void __oom_kill_process(struct task_struct *victim, const char *message) continue; } /* -* No kthead_use_mm() user needs to read from the userspace so +* No kthread_use_mm() user needs to read from the userspace so * we are ok to reap it. */ if (unlikely(p->flags & PF_KTHREAD)) -- 2.30.2 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [PATCH RFCv2] mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault/prealloc memory
diff --git a/mm/internal.h b/mm/internal.h index 9902648f2206..a5c4ed23b1db 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -340,6 +340,9 @@ void __vma_unlink_list(struct mm_struct *mm, struct vm_area_struct *vma); #ifdef CONFIG_MMU extern long populate_vma_page_range(struct vm_area_struct *vma, unsigned long start, unsigned long end, int *nonblocking); +extern long faultin_vma_page_range(struct vm_area_struct *vma, + unsigned long start, unsigned long end, + bool write, int *nonblocking); extern void munlock_vma_pages_range(struct vm_area_struct *vma, unsigned long start, unsigned long end); static inline void munlock_vma_pages_all(struct vm_area_struct *vma) The parameter name does not match the one in the implementation. Otherwise the implementation looks fine AFAICT. Eike
[PATCH] Kconfig: fix help text of TRACEPOINT_BENCHMARK
Signed-off-by: Rolf Eike Beer --- kernel/trace/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 9c266b93cbc0..7fa82778c3e6 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -694,7 +694,7 @@ config TRACEPOINT_BENCHMARK help This option creates the tracepoint "benchmark:benchmark_event". When the tracepoint is enabled, it kicks off a kernel thread that -goes into an infinite loop (calling cond_sched() to let other tasks +goes into an infinite loop (calling cond_resched() to let other tasks run), and calls the tracepoint. Each iteration will record the time it took to write to the tracepoint and the next iteration that data will be passed to the tracepoint itself. That is, the tracepoint -- 2.30.1 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
[PATCH] simplify copy_mm()
All this can happen without a single goto. Signed-off-by: Rolf Eike Beer --- kernel/fork.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index d66cd1014211..1cad8c622b34 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1382,7 +1382,6 @@ static struct mm_struct *dup_mm(struct task_struct *tsk, static int copy_mm(unsigned long clone_flags, struct task_struct *tsk) { struct mm_struct *mm, *oldmm; - int retval; tsk->min_flt = tsk->maj_flt = 0; tsk->nvcsw = tsk->nivcsw = 0; @@ -1409,21 +1408,15 @@ static int copy_mm(unsigned long clone_flags, struct task_struct *tsk) if (clone_flags & CLONE_VM) { mmget(oldmm); mm = oldmm; - goto good_mm; + } else { + mm = dup_mm(tsk, current->mm); + if (!mm) + return -ENOMEM; } - retval = -ENOMEM; - mm = dup_mm(tsk, current->mm); - if (!mm) - goto fail_nomem; - -good_mm: tsk->mm = mm; tsk->active_mm = mm; return 0; - -fail_nomem: - return retval; } static int copy_fs(unsigned long clone_flags, struct task_struct *tsk) -- 2.30.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [PATCH RFC] mm/madvise: introduce MADV_POPULATE to prefault/prealloc memory
Let's introduce MADV_POPULATE with the following semantics 1. MADV_POPULATED does not work on PROT_NONE and special VMAs. It works on everything else. 2. Errors during MADV_POPULATED (especially OOM) are reported. If we hit hardware errors on pages, ignore them - nothing we really can or should do. 3. On errors during MADV_POPULATED, some memory might have been populated. Callers have to clean up if they care. 4. Concurrent changes to the virtual memory layour are tolerated - we ^t process each and every PFN only once, though. 5. If MADV_POPULATE succeeds, all memory in the range can be accessed without SIGBUS. (of course, not if user space changed mappings in the meantime or KSM kicked in on anonymous memory). You are talking both about MADV_POPULATE and MADV_POPULATED here. Eike
Re: [PATCH] scripts: Fix linking extract-cert against libcrypto
Am Donnerstag, 11. Februar 2021, 11:29:33 CET schrieb Rolf Eike Beer: > I'm just guessing, but your build error looks like you are also > cross-building the tools, which is wrong. You want them to be host-tools. > So don't export PKG_CONFIG_SYSROOT_DIR, it would then try to link target > libraries into a host binary. I have looked again how I do it: # this is for additional _host_ .pc files export PKG_CONFIG_PATH=${prefix}/lib/pkgconfig Then have a target-pkg-config, so this code inside several kernel Makefiles will work: PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config And then export your PKG_CONFIG_SYSROOT_DIR and the like inside that. I bet you have all of this already in place, so just remove the SYSROOT_DIR from your kernel build script and things should work. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH] scripts: Fix linking extract-cert against libcrypto
Am Dienstag, 9. Februar 2021, 09:44:33 CET schrieb Rolf Eike Beer: > Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz: > > When compiling under OpenEmbedded, the following error is seen > > > > as of recently: > > /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside / > > /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a > > > > inside / /srv/oe/build/tmp/hosttools/ld: cannot find > > /lib/ld-linux-x86-64.so.2 inside / collect2: error: ld returned 1 exit > > status > > > > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1 > > [...] > > > As per `make`'s documentation: > > LDFLAGS > > > > Extra flags to give to compilers when they are supposed to > > invoke the linker, ‘ld’, such as -L. Libraries (-lfoo) > > should be added to the LDLIBS variable instead. > > > > LDLIBS > > > > Library flags or names given to compilers when they are > > supposed to invoke the linker, ‘ld’. LOADLIBES is a > > deprecated (but still supported) alternative to LDLIBS. > > Non-library linker flags, such as -L, should go in the > > LDFLAGS variable. > > Correct. And the patch I use for my local 4.19 build actually uses LDLIBS, > so it must have gone wrong in some rebase for one of the intermediate > versions. > > Acked-by: Rolf Eike Beer Ok, now actually with proper testing: no, your patch doesn't work. When changing LDLIBS to LDFLAGS things do not show up on the commandline at all. LDLIBS: gcc -Wp,-MMD,scripts/.sign-file.d -Wall -Wmissing-prototypes -Wstrict- prototypes -O2 -fomit-frame-pointer -std=gnu89 -I/opt/emlix/test/include -I ./scripts -o scripts/sign-file /tmp/e2/build/linux-kernel/scripts/sign- file.c -L/opt/emlix/test/lib -lcrypto -lz -ldl -pthread LDFLAGS: gcc -Wp,-MMD,scripts/.sign-file.d -Wall -Wmissing-prototypes -Wstrict- prototypes -O2 -fomit-frame-pointer -std=gnu89 -I/opt/emlix/test/include -I ./scripts -o scripts/sign-file /tmp/e2/build/linux-kernel/scripts/sign- file.c When looking closely you may notice that this is not entirely the same as current master would output: I missed the CFLAGS for sign-file in my patch. When testing your patch I accidentially had a .config that had module signatures disabled, so I have not tested it actually, that's why I didn't notice that it doesn't work. I'm just guessing, but your build error looks like you are also cross-building the tools, which is wrong. You want them to be host-tools. So don't export PKG_CONFIG_SYSROOT_DIR, it would then try to link target libraries into a host binary. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH] scripts: Fix linking extract-cert against libcrypto
Am Dienstag, 9. Februar 2021, 09:44:33 CET schrieb Rolf Eike Beer: > Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz: > > When compiling under OpenEmbedded, the following error is seen > > > > as of recently: > > /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside / > > /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a > > > > inside / /srv/oe/build/tmp/hosttools/ld: cannot find > > /lib/ld-linux-x86-64.so.2 inside / collect2: error: ld returned 1 exit > > status > > > > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1 > > [...] > > > As per `make`'s documentation: > > LDFLAGS > > > > Extra flags to give to compilers when they are supposed to > > invoke the linker, ‘ld’, such as -L. Libraries (-lfoo) > > should be added to the LDLIBS variable instead. > > > > LDLIBS > > > > Library flags or names given to compilers when they are > > supposed to invoke the linker, ‘ld’. LOADLIBES is a > > deprecated (but still supported) alternative to LDLIBS. > > Non-library linker flags, such as -L, should go in the > > LDFLAGS variable. > > Correct. And the patch I use for my local 4.19 build actually uses LDLIBS, > so it must have gone wrong in some rebase for one of the intermediate > versions. > > Acked-by: Rolf Eike Beer Oh, scrap that. I misread your patch. I was actually using LDLIBS exclusively, no LDFLAGS at all. I'll have to get my test setup ready for this, can take a moment. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH] scripts: Fix linking extract-cert against libcrypto
Am Dienstag, 9. Februar 2021, 05:59:56 CET schrieb Daniel Díaz: > When compiling under OpenEmbedded, the following error is seen > as of recently: > > /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside / > /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a > inside / /srv/oe/build/tmp/hosttools/ld: cannot find > /lib/ld-linux-x86-64.so.2 inside / collect2: error: ld returned 1 exit > status > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1 [...] > As per `make`'s documentation: > > LDFLAGS > Extra flags to give to compilers when they are supposed to > invoke the linker, ‘ld’, such as -L. Libraries (-lfoo) > should be added to the LDLIBS variable instead. > > LDLIBS > Library flags or names given to compilers when they are > supposed to invoke the linker, ‘ld’. LOADLIBES is a > deprecated (but still supported) alternative to LDLIBS. > Non-library linker flags, such as -L, should go in the > LDFLAGS variable. Correct. And the patch I use for my local 4.19 build actually uses LDLIBS, so it must have gone wrong in some rebase for one of the intermediate versions. Acked-by: Rolf Eike Beer -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
Am Dienstag, 9. Februar 2021, 03:31:44 CET schrieb Naresh Kamboju: > On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman > > wrote: > > This is the start of the stable review cycle for the 5.10.15 release. > > There are 120 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 Wed, 10 Feb 2021 14:57:55 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5 > > .10.15-rc1.gz> > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable- > > rc.git linux-5.10.y> > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Due to the patch below, the x86_64 build breaks with gcc 7.3.x > This issue is specific to openembedded kernel builder. > > We have also noticed on mainline, Linux next and now on stable-rc 5.10. > > collect2: error: ld returned 1 exit status > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1 > > ref: > Build failure link, > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/D > ISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText Is this part relevant or does that always happen with your builder. | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/libc.so.6 inside / | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /usr/lib/ libc_nonshared.a inside / | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/ld-linux- x86-64.so.2 inside / Can you provide a log with V=1 where we can see what actually is going on? Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH v6] scripts: use pkg-config to locate libcrypto
>From f467f251e44cd406c9556ea7d68d131f56e0d832 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer Date: Thu, 22 Nov 2018 16:40:49 +0100 Subject: [PATCH] scripts: use pkg-config to locate libcrypto Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org # 5.6.x --- scripts/Makefile | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Changes in v6: - hardcode pkg-config diff --git a/scripts/Makefile b/scripts/Makefile index b5418ec587fb..9de3c03b94aa 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -3,6 +3,9 @@ # scripts contains sources for various helper programs used throughout # the kernel for the build process. +CRYPTO_LIBS = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto) +CRYPTO_CFLAGS = $(shell pkg-config --cflags libcrypto 2> /dev/null) + hostprogs-always-$(CONFIG_BUILD_BIN2C) += bin2c hostprogs-always-$(CONFIG_KALLSYMS)+= kallsyms hostprogs-always-$(BUILD_C_RECORDMCOUNT) += recordmcount @@ -14,8 +17,9 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(CRYPTO_LIBS) +HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS) +HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) ifdef CONFIG_UNWINDER_ORC ifeq ($(ARCH),x86_64) -- 2.30.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [PATCH v5] scripts: use pkg-config to locate libcrypto
Am Mittwoch, 13. Januar 2021, 13:49:12 CET schrieb Rolf Eike Beer: > Otherwise build fails if the headers are not in the default location. While > at it also ask pkg-config for the libs, with fallback to the existing > value. Can someone please take this through the kbuild-tree? Noone seems to be interested in picking this up so far. Thanks, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH v5] scripts: use pkg-config to locate libcrypto
Am Dienstag, 26. Januar 2021, 07:30:03 CET schrieb Masahiro Yamada: > On Tue, Jan 26, 2021 at 2:42 PM Rolf Eike Beer wrote: > > Am Mittwoch, 13. Januar 2021, 13:49:12 CET schrieb Rolf Eike Beer: > > > Otherwise build fails if the headers are not in the default location. > > > While > > > at it also ask pkg-config for the libs, with fallback to the existing > > > value. > > > > Can someone please take this through the kbuild-tree? Noone seems to be > > interested in picking this up so far. > Is 'PKG_CONFIG' necessary? > > I see many Makefiles hard-coding 'pkg-config'. Well, it depends ;) When people use pkgconf then this usually installs a pkg-config alias, too, so that would be no problem. The problem comes when other places in the kernel start copying that code over, and then hardcode pkg-config for stuff that needs a prefixed pkg-config because it is about target code. Given that I would prefer it this way, but YMMV. If it is that variable that blocks integrating I'll change it. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH v5] scripts: use pkg-config to locate libcrypto
Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org # 5.6.x --- scripts/Makefile | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) This has been sent multiple times since more than 2 year, please pick it up through whatever tree. I need to patch every new stable kernel version to make them build in our chrooted environment. diff --git a/scripts/Makefile b/scripts/Makefile index b5418ec587fb..7553692d241f 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -3,6 +3,11 @@ # scripts contains sources for various helper programs used throughout # the kernel for the build process. +PKG_CONFIG ?= pkg-config + +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) +CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) + hostprogs-always-$(CONFIG_BUILD_BIN2C) += bin2c hostprogs-always-$(CONFIG_KALLSYMS)+= kallsyms hostprogs-always-$(BUILD_C_RECORDMCOUNT) += recordmcount @@ -14,8 +19,9 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(CRYPTO_LIBS) +HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS) +HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) ifdef CONFIG_UNWINDER_ORC ifeq ($(ARCH),x86_64) -- 2.29.2 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [PATCH] kbuild: improve libelf detection
Am Dienstag, 12. Januar 2021, 20:00:10 CET schrieb Alistair Delva: > When `pkg-config --libs' wasn't used or didn't return anything useful, > the test for libelf would fail even if the headers and libraries were > available to kbuild via KBUILD_HOSTCFLAGS and KBUILD_HOSTLDFLAGS. > > This makes the check in the core Makefile match the check that is done > in tools/objtool/Makefile. Specifically, the C compiler is passed the > full KBUILD_HOSTCFLAGS and KBUILD_HOSTLDFLAGS, which may have set up > additional sysroot/include/library search paths to find libelf. Sounds plausible. -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH] Documentation: fix typos in split page table lock description
Signed-off-by: Rolf Eike Beer --- Documentation/vm/split_page_table_lock.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/vm/split_page_table_lock.rst b/Documentation/vm/split_page_table_lock.rst index ff51f4a5494d..c08919662704 100644 --- a/Documentation/vm/split_page_table_lock.rst +++ b/Documentation/vm/split_page_table_lock.rst @@ -32,7 +32,7 @@ There are helpers to lock/unlock a table and other accessor functions: Split page table lock for PTE tables is enabled compile-time if CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS. -If split lock is disabled, all tables guaded by mm->page_table_lock. +If split lock is disabled, all tables are guarded by mm->page_table_lock. Split page table lock for PMD tables is enabled, if it's enabled for PTE tables and the architecture supports it (see below). -- 2.29.2 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [RFC PATCH] treewide: remove bzip2 compression support
Am 2020-11-17 23:32, schrieb Alex Xu (Hello71): bzip2 is either slower or larger than every other supported algorithm, according to benchmarks at [0]. It is far slower to decompress than any other algorithm, and still larger than lzma, xz, and zstd. diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst index abb9fc164657..b74d14caabe6 100644 --- a/Documentation/x86/boot.rst +++ b/Documentation/x86/boot.rst @@ -781,10 +781,10 @@ Protocol: 2.08+ The payload may be compressed. The format of both the compressed and uncompressed data should be determined using the standard magic numbers. The currently supported compression formats are gzip - (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA - (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number - 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is - currently always ELF (magic number 7F 45 4C 46). + (magic numbers 1F 8B or 1F 9E), LZMA (magic number 5D 00), XZ (magic + number FD 37), LZ4 (magic number 02 21) and ZSTD (magic number 28 + B5). The uncompressed payload is currently always ELF (magic number + 7F 45 4C 46). == Field name:payload_length diff --git a/arch/arm/configs/aspeed_g4_defconfig b/arch/arm/configs/aspeed_g4_defconfig index 58d293b63581..f2f5dcd0e59c 100644 I would keep the magic number, and just tell that it is not supported by newer kernels anymore if at all. It's just handy to be able to look into the most recent documentation and see what the values are for. If you look at an older image and don't find the magic number my first impulse would not be to look at older versions of the documentation for things that were removed. Maybe something like: "Formerly supported was also bzip2 (magic number 42 5A)." Eike
[PATCH] binfmt_elf: simplify error handling in load_elf_phdrs()
Signed-off-by: Rolf Eike Beer --- fs/binfmt_elf.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index b588d1291b25..74827a7a06d0 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -458,7 +458,7 @@ static struct elf_phdr *load_elf_phdrs(const struct elfhdr *elf_ex, struct file *elf_file) { struct elf_phdr *elf_phdata = NULL; - int retval, err = -1; + int retval = -1; unsigned int size; /* @@ -480,15 +480,9 @@ static struct elf_phdr *load_elf_phdrs(const struct elfhdr *elf_ex, /* Read in the program headers */ retval = elf_read(elf_file, elf_phdata, size, elf_ex->e_phoff); - if (retval < 0) { - err = retval; - goto out; - } - /* Success! */ - err = 0; out: - if (err) { + if (retval) { kfree(elf_phdata); elf_phdata = NULL; } -- 2.29.1 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
fix typos in "compress" variants
Signed-off-by: Rolf Eike Beer --- arch/x86/kernel/head64.c | 2 +- fs/f2fs/data.c | 2 +- scripts/kallsyms.c | 2 +- scripts/spelling.txt | 3 +++ 4 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 05e117137b45..a18a11acad92 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -105,7 +105,7 @@ static unsigned int __head *fixup_int(void *ptr, unsigned long physaddr) static bool __head check_la57_support(unsigned long physaddr) { /* -* 5-level paging is detected and enabled at kernel decomression +* 5-level paging is detected and enabled at kernel decompression * stage. Only check if it has been enabled there. */ if (!(native_read_cr4() & X86_CR4_LA57)) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index be4da52604ed..93c23ae5723d 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -2377,7 +2377,7 @@ static int f2fs_mpage_readpages(struct inode *inode, #ifdef CONFIG_F2FS_FS_COMPRESSION if (f2fs_compressed_file(inode)) { - /* there are remained comressed pages, submit them */ + /* there are remained compressed pages, submit them */ if (!f2fs_cluster_can_merge_page(, page->index)) { ret = f2fs_read_multi_pages(, , max_nr_pages, diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c index 7ecd2ccba531..623dedecd8e3 100644 --- a/scripts/kallsyms.c +++ b/scripts/kallsyms.c @@ -12,7 +12,7 @@ * map char code 0xF7 to represent "write_" and then in every symbol where * "write_" appears it can be replaced by 0xF7, saving 5 bytes. * The used codes themselves are also placed in the table so that the - * decompresion can work without "special cases". + * decompression can work without "special cases". * Applied to kernel symbols, this usually produces a compression ratio * of about 50%. * diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 953f4a2de1e5..061e15201739 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -338,6 +338,7 @@ compoment||component comppatible||compatible compres||compress compresion||compression +comressed||compressed comression||compression comunication||communication conbination||combination @@ -406,6 +407,8 @@ debouce||debounce decendant||descendant decendants||descendants decompres||decompress +decompresion||decompression +decomression||decompression decsribed||described decription||description dectected||detected -- 2.29.1 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
binfmt_elf: simplify error handling in load_elf_phdrs()
--- fs/binfmt_elf.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 251298d25c8c..64b4b47448af 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -434,7 +434,7 @@ static struct elf_phdr *load_elf_phdrs(const struct elfhdr *elf_ex, struct file *elf_file) { struct elf_phdr *elf_phdata = NULL; - int retval, err = -1; + int retval = -1; unsigned int size; /* @@ -456,15 +456,9 @@ static struct elf_phdr *load_elf_phdrs(const struct elfhdr *elf_ex, /* Read in the program headers */ retval = elf_read(elf_file, elf_phdata, size, elf_ex->e_phoff); - if (retval < 0) { - err = retval; - goto out; - } - /* Success! */ - err = 0; out: - if (err) { + if (retval) { kfree(elf_phdata); elf_phdata = NULL; } -- 2.28.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
[PATCH] binfmt_elf: fix documented return value for load_elf_phdrs()
This function has never returned anything but a plain NULL. Fixes: 6a8d38945cf4e6e819d6b550250615db763065a0 Signed-off-by: Rolf Eike Beer --- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 9fe3b51c116a..251298d25c8c 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -428,7 +428,7 @@ static int elf_read(struct file *file, void *buf, size_t len, loff_t pos) * * Loads ELF program headers from the binary file elf_file, which has the ELF * header pointed to by elf_ex, into a newly allocated array. The caller is - * responsible for freeing the allocated data. Returns an ERR_PTR upon failure. + * responsible for freeing the allocated data. Returns NULL upon failure. */ static struct elf_phdr *load_elf_phdrs(const struct elfhdr *elf_ex, struct file *elf_file) -- 2.28.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [PATCH v4] scripts: use pkg-config to locate libcrypto
Am Montag, 27. April 2020, 10:11:28 CEST schrieb Rolf Eike Beer: > From 082ba542ca4c710dcf592a6f9233603b9275d05d Mon Sep 17 00:00:00 2001 > From: Rolf Eike Beer > Date: Thu, 22 Nov 2018 16:40:49 +0100 > Subject: [PATCH 1/2] scripts: use pkg-config to locate libcrypto > > Otherwise build fails if the headers are not in the default location. While > at it also ask pkg-config for the libs, with fallback to the existing > value. Close to 2 years since the original patch… can this please be applied? It get's annoying to patch every new kernel version the same way again. Thx Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH] parisc: suppress error messages for 'make clean'
Helge Deller wrote: > On 10.05.20 03:19, Masahiro Yamada wrote: > > Hi Helge, > > > > On Sun, May 10, 2020 at 2:39 AM Helge Deller wrote: > > I will drop this patch from my kbuild tree, > > then you will apply what you think is best > > to your tree. > > > > What do you think? > > Sure, I'll take it through the parisc tree. Is this already in 5.7.2? I get these: pioneer /usr/src/linux-5.7.1-gentoo # make distclean gcc: error: missing argument to '-Wframe-larger-than=' gcc: error: missing argument to '-Wframe-larger-than=' CLEAN arch/parisc/kernel gcc: error: missing argument to '-Wframe-larger-than=' gcc: error: missing argument to '-Wframe-larger-than=' Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 08/12] parisc: use pgtable-nopXd instead of 4level-fixup
diff --git a/arch/parisc/include/asm/page.h b/arch/parisc/include/asm/page.h index 93caf17..1d339ee 100644 --- a/arch/parisc/include/asm/page.h +++ b/arch/parisc/include/asm/page.h @@ -42,48 +42,54 @@ typedef struct { unsigned long pte; } pte_t; /* either 32 or 64bit */ /* NOTE: even on 64 bits, these entries are __u32 because we allocate * the pmd and pgd in ZONE_DMA (i.e. under 4GB) */ -typedef struct { __u32 pmd; } pmd_t; typedef struct { __u32 pgd; } pgd_t; typedef struct { unsigned long pgprot; } pgprot_t; -#define pte_val(x) ((x).pte) -/* These do not work lvalues, so make sure we don't use them as such. */ +#if CONFIG_PGTABLE_LEVELS == 3 +typedef struct { __u32 pmd; } pmd_t; +#define __pmd(x) ((pmd_t) { (x) } ) +/* pXd_val() do not work lvalues, so make sure we don't use them as such. */ For me it sounds like there is something missing, maybe an "as" before lvalues? And it was "These", so plural, and now it is singular, so do -> does? Eike
Re: [PATCH v3][RESEND] scripts: use pkg-config to locate libcrypto
Am Dienstag, 10. September 2019, 12:48:30 CEST schrieb Sasha Levin: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v5.2.13, v4.19.71, v4.14.142, > v4.9.191, v4.4.191. > > v5.2.13: Build OK! > v4.19.71: Build OK! > v4.14.142: Failed to apply! Possible dependencies: > 8377bd2b9ee1 ("kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS") This one causes the collision, the simple fix would probably be to manually use the old variable names when cherry-picking. > How should we proceed with this patch? I can send a backport or you manually fix it up when applying, as you wish. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH v3][RESEND] scripts: use pkg-config to locate libcrypto
Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile b/scripts/Makefile index 16bcb8087899..1715adcd8f81 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -8,7 +8,11 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables +PKG_CONFIG?= pkg-config + HOST_EXTRACFLAGS += -I$(srctree)/tools/include +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) +CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c hostprogs-$(CONFIG_KALLSYMS) += kallsyms @@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(CRYPTO_LIBS) +HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS) +HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) always := $(hostprogs-y) $(hostprogs-m) -- 2.23.0
Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda: > On Thu, Jun 6, 2019 at 8:59 PM Greg KH wrote: > > "manually fixing it up" means "hacked it to pieces" to me, I have no > > idea what the end result really was :) > > > > If someone wants to send me some patches I can actually apply, that > > would be best... > > I will give it a go whenever I get some free time :) I fear this has never happened, did it? Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Nathan Chancellor wrote: > On Fri, Aug 02, 2019 at 09:57:45AM +0200, Greg KH wrote: > > On Thu, Jun 06, 2019 at 09:11:00AM +0200, Rolf Eike Beer wrote: > > > Nick Desaulniers wrote: > > > > On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers > > > > > > > > wrote: > > > > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH wrote: > > > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > > > I decided to dig out a toy project which uses a DragonBoard > > > > > > > 410c. This > > > > > > > has > > > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > > > unrelated > > > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but > > > > > > > it was > > > > > > > buildable, which was good enough. > > > > > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly > > > > > > > fail: > > > > > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in > > > > > > > function > > > > > > > `handle_kernel_image': > > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-s > > > > > > > tub.c: > > > > > > > 63: > > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): > > > > > > > relocation > > > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can > > > > > > > not > > > > > > > be used when making a shared object; recompile with -fPIC > > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-s > > > > > > > tub.c: > > > > > > > 63: > > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target > > > > > > > 'vmlinux' > > > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > > > > > This is caused by commit > > > > > > > 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > > > reverting > > > > > > > this commit fixes the build. > > Did this ever get resolved, or is it still an issue? > > This appears to have been resolved by commit 8fca3c364683 ("efi/libstub: > Unify command line param parsing") in 4.9.181. I can build defconfig + > CONFIG_RANDOMIZE_BASE without any issues. I can confirm that 4.9.186 builds without issues with my original config. Thanks for paying attention. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH v3] scripts: use pkg-config to locate libcrypto
> From 71e19be4247fbaa2540dfb321e2b148234680a13 Mon Sep 17 00:00:00 2001 > From: Rolf Eike Beer > Date: Thu, 22 Nov 2018 16:40:49 +0100 > Subject: [PATCH] scripts: use pkg-config to locate libcrypto > > Otherwise build fails if the headers are not in the default location. While > at it also ask pkg-config for the libs, with fallback to the existing > value. Ping? -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH] parisc: asm: psw.h: missing header guard
Denis Efremov wrote: > The psw.h header file contains #ifndef directive of the guard, > but the complimentary #define directive is missing. The patch > adds the appropriate #define to fix the header guard. > > Signed-off-by: Denis Efremov > --- > arch/parisc/include/asm/psw.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/parisc/include/asm/psw.h b/arch/parisc/include/asm/psw.h > index 76c301146c31..7a175e866ed0 100644 > --- a/arch/parisc/include/asm/psw.h > +++ b/arch/parisc/include/asm/psw.h > @@ -1,5 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > #ifndef _PARISC_PSW_H > +#define _PARISC_PSW_H > > > #define PSW_I 0x0001 You could have removed one of the 2 empty lines then. Eike signature.asc Description: This is a digitally signed message part.
riscv: remove unused barrier defines
>From 947f9fe483dc6561e31f0d2294eb6fedc1d6d9bb Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer Date: Mon, 17 Jun 2019 14:22:37 +0200 Subject: [PATCH] riscv: remove unused barrier defines They were introduced in fab957c11efe2f405e08b9f0d080524bc2631428 long after 2e39465abc4b7856a0ea6fcf4f6b4668bb5db877 removed the remnants of all previous instances from the tree. Signed-off-by: Rolf Eike Beer --- arch/riscv/include/asm/bitops.h | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h index 3943be480af0..396a3303c537 100644 --- a/arch/riscv/include/asm/bitops.h +++ b/arch/riscv/include/asm/bitops.h @@ -15,11 +15,6 @@ #include #include -#ifndef smp_mb__before_clear_bit -#define smp_mb__before_clear_bit() smp_mb() -#define smp_mb__after_clear_bit() smp_mb() -#endif /* smp_mb__before_clear_bit */ - #include #include #include -- 2.21.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
[PATCH RESEND] H8300: remove unused barrier defines
>From c907e749917f430e3dc62048985c8419778572f9 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer Date: Fri, 14 Jul 2017 11:19:08 +0200 Subject: [PATCH] H8300: remove unused barrier defines They were introduced in d2a5f4999f6c211adf30d9788349e13988d6f2a7 long after 2e39465abc4b7856a0ea6fcf4f6b4668bb5db877 removed the remnants of all previous instances from the tree. Signed-off-by: Rolf Eike Beer --- arch/h8300/include/asm/bitops.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/h8300/include/asm/bitops.h b/arch/h8300/include/asm/bitops.h index 647a83bd40b7..7aa16c732aa9 100644 --- a/arch/h8300/include/asm/bitops.h +++ b/arch/h8300/include/asm/bitops.h @@ -51,12 +51,6 @@ static inline void FNAME(int nr, volatile unsigned long *addr) \ } \ } -/* - * clear_bit() doesn't provide any barrier for the compiler. - */ -#define smp_mb__before_clear_bit() barrier() -#define smp_mb__after_clear_bit() barrier() - H8300_GEN_BITOP(set_bit,"bset") H8300_GEN_BITOP(clear_bit, "bclr") H8300_GEN_BITOP(change_bit, "bnot") -- 2.21.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …
Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH: > On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote: > > On Thu, Jun 6, 2019 at 5:29 PM Greg KH wrote: > > > And if you want this, you should look at how the backports to 4.14.y > > > worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use > > > feature checks instead of version checks"), as that gets really messy... > > > > I am confused -- I interpreted Rolf's message as reporting that he > > already successfully built 4.9 by applying a6e60d84989f > > ("include/linux/module.h: copy __init/__exit attrs to > > init/cleanup_module") and manually fixing it up. But maybe I am > > completely wrong... :-) > > "manually fixing it up" means "hacked it to pieces" to me, I have no > idea what the end result really was :) > > If someone wants to send me some patches I can actually apply, that > would be best... Hi all, the patch I actually used was this: diff --git a/include/linux/module.h b/include/linux/module.h index 8fa38d3e7538..f5bc4c046461 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -129,13 +129,13 @@ extern void cleanup_module(void); #define module_init(initfn)\ static inline initcall_t __maybe_unused __inittest(void) \ { return initfn; } \ - int init_module(void) __attribute__((alias(#initfn))); + int init_module(void) __attribute__((__copy__(initfn))) __attribute__((alias(#initfn))); /* This is only required if you want to be unloadable. */ #define module_exit(exitfn)\ static inline exitcall_t __maybe_unused __exittest(void) \ { return exitfn; } \ - void cleanup_module(void) __attribute__((alias(#exitfn))); + void cleanup_module(void) __attribute__((__copy__(exitfn))) __attribute__((alias(#exitfn))); #endif So the final question is: do we want 4.9.x to be buildable with gcc 9.x? If yes then we can probably get this patches into shape. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …
/linux-4.9.180/include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' 228 | module_driver(__platform_driver, platform_driver_register, \ | ^ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/io.h:27, from /tmp/e2/build/linux-4.9.180/include/linux/io.h:25, from /tmp/e2/build/linux-4.9.180/include/linux/irq.h:24, from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/hardirq.h:5, from /tmp/e2/build/linux-4.9.180/include/linux/hardirq.h:8, from /tmp/e2/build/linux-4.9.180/include/linux/interrupt.h:12, from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:12: /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:24: note: 'init_module' target declared here 581 | module_platform_driver(mpc52xx_lpbfifo_driver); |^~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1351:19: note: in definition of macro 'module_driver' 1351 | static int __init __driver##_init(void) \ | ^~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~ So this needs a6e60d84989fa0e91db7f236eda40453b0e44afa, which needs c0d9782f5b6d7157635ae2fd782a4b27d55a6013, which can't be applied cleanly because a3f8a30f3f0079c7edfc72e329eee8594fb3e3cb is missing in 4.9. I have applied a6e60d84989fa0e91db7f236eda40453b0e44afa and modified it to directly use __attribute__((__copy__(initfn))) and (exitfn), which fixes the build for me. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Ard Biesheuvel wrote: > On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer wrote: > > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > > > Greg KH wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > I decided to dig out a toy project which uses a DragonBoard 410c. > > > > > This > > > > > has > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > unrelated > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it > > > > > was > > > > > buildable, which was good enough. > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in > > > > > function > > > > > `handle_kernel_image': > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > c:63 > > > > > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > > be > > > > > used when making a shared object; recompile with -fPIC > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > c:63 > > > > > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target > > > > > 'vmlinux' > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca > > > > > from > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > reverting > > > > > this commit fixes the build. > > > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > > 9.1.0. > > > > > See > > > > > the attached .config for reference. > > > > > > > > > > If you have questions or patches just ping me. > > > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > 5.1.7 with the same config as before and "make olddefconfig" builds for > > > me. > > > > Just for the fun of it: both 4.19 and 4.19.48 also work. > Could you please check whether patch > 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether > it fixes the problem? Thanks. The part in drivers/firmware/efi/libstub/arm-stub.c needs to be applied by hand, but afterwards things build fine. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH v3] scripts: use pkg-config to locate libcrypto
>From 71e19be4247fbaa2540dfb321e2b148234680a13 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer Date: Thu, 22 Nov 2018 16:40:49 +0100 Subject: [PATCH] scripts: use pkg-config to locate libcrypto Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org # 4.19.x --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) v2: add CRYPTO_LIBS and CRYPTO_CFLAGS v3: fix fallback -lcrypto diff --git a/scripts/Makefile b/scripts/Makefile index 9d442ee050bd..9489c3b550df 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -8,7 +8,11 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables +PKG_CONFIG?= pkg-config + HOST_EXTRACFLAGS += -I$(srctree)/tools/include +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) +CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c hostprogs-$(CONFIG_KALLSYMS) += kallsyms @@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(CRYPTO_LIBS) +HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS) +HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) always := $(hostprogs-y) $(hostprogs-m) -- 2.21.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [PATCH v2 RESEND] scripts: use pkg-config to locate libcrypto
David Woodhouse wrote: > On Thu, 2019-06-06 at 09:55 +0200, Rolf Eike Beer wrote: > > +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || > > -lcrypto) > That's going to run: > > $ pkg-config --libs libcrypto || -lcrypto > > > If libcrypto.pc isn't there, it's going to get this: > > > -lcrypto: command not found > > I think you meant: > > +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo > -lcrypto) Doh! Thanks, v3 in a minute. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH v2 RESEND] scripts: use pkg-config to locate libcrypto
>From cca931322233827dc21c7609f21f4042d78f220e Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer Date: Thu, 22 Nov 2018 16:40:49 +0100 Subject: scripts: use pkg-config to locate libcrypto Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org # 4.19.x --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Last time I got notice about a build error with 4.19.3, but it works fine for me on top of both 4.19 and 4.19.48. diff --git a/scripts/Makefile b/scripts/Makefile index 9d442ee050bd..bd2a30b43f28 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -8,7 +8,11 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables +PKG_CONFIG?= pkg-config + HOST_EXTRACFLAGS += -I$(srctree)/tools/include +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto) +CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c hostprogs-$(CONFIG_KALLSYMS) += kallsyms @@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(CRYPTO_LIBS) +HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS) +HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) always := $(hostprogs-y) $(hostprogs-m) -- 2.21.0
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > Greg KH wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > I decided to dig out a toy project which uses a DragonBoard 410c. This > > > has > > > been "running" with kernel 4.9, which I would keep this way for > > > unrelated > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > buildable, which was good enough. > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > > `handle_kernel_image': > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > : > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > aarch64-unknown-linux-gnueabi-ld: > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be > > > used when making a shared object; recompile with -fPIC > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > : > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > reverting > > > this commit fixes the build. > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. > > > See > > > the attached .config for reference. > > > > > > If you have questions or patches just ping me. > > > > Does Linus's latest tree also fail for you (or 5.1)? > > 5.1.7 with the same config as before and "make olddefconfig" builds for me. Just for the fun of it: both 4.19 and 4.19.48 also work. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH linux] objtool: fix pkg-config query in case of cross-compilation
Am Donnerstag, 11. April 2019, 11:26:12 CEST schrieb Nicolas Dichtel: > Le 11/04/2019 à 10:52, Rolf Eike Beer a écrit : > > Am Donnerstag, 11. April 2019, 10:39:40 CEST schrieb Nicolas Dichtel: > >> In case of cross-compilation, there may be two pkg-config tools, one for > >> the host and one for the target. Enable to override the default name. > >> > >> Fixes: 056d28d135bc ("objtool: Query pkg-config for libelf location") > >> Signed-off-by: Nicolas Dichtel > > > > If you do that, you have to fix a lot of other places, too. This starts in > > scripts/kconfig/ and also includes e.g. tools/testing/. > > > > Usually you have pkg-config for host and ${target_platform}-pkg-config for > > the > My use case was for buildroot, which define pkg-config and host-pkgconf. In > fact, I've just seen that a buildroot patch was accepted for this problem: > https://patchwork.ozlabs.org/patch/1081379/ I agree that it makes sense to have both host and target pkg-config configurable. But IMHO that must happen in a central place (i.e. ./Makefile), and it has to be used everywhere. Currently PKG_CONFIG is defined at multiple places, sometimes host, sometimes target, and often pkg-config is called directly, also mixing both usages. So, IMHO, if you want to fix this: fix it once and for all in the whole kernel, not just one place. What I have introduced was just the same as kconfig is using to find the dependencies for some of the *config variants, so this usecase would break for you anyway, although I don't think anyone in buildroot will notice this. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH linux] objtool: fix pkg-config query in case of cross-compilation
Am Donnerstag, 11. April 2019, 10:39:40 CEST schrieb Nicolas Dichtel: > In case of cross-compilation, there may be two pkg-config tools, one for > the host and one for the target. Enable to override the default name. > > Fixes: 056d28d135bc ("objtool: Query pkg-config for libelf location") > Signed-off-by: Nicolas Dichtel If you do that, you have to fix a lot of other places, too. This starts in scripts/kconfig/ and also includes e.g. tools/testing/. Usually you have pkg-config for host and ${target_platform}-pkg-config for the target, and the PKG_CONFIG variable for the target, usually initialized to $ (CROSS_COMPILE)pkg-config. I have sent a bunch of patches to replace the usage of plain pkg-config at several places with the cross-aware version, but sadly a lot of them have not been picked up. It break cross-building tests basically all the time. One example is here: https://marc.info/?l=linux-acpi=153544231529066=2 For me it looks like you are trying to go into the wrong direction. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[tip:core/urgent] objtool: Query pkg-config for libelf location
Commit-ID: 056d28d135bca0b1d0908990338e00e9dadaf057 Gitweb: https://git.kernel.org/tip/056d28d135bca0b1d0908990338e00e9dadaf057 Author: Rolf Eike Beer AuthorDate: Tue, 26 Mar 2019 12:48:39 -0500 Committer: Thomas Gleixner CommitDate: Thu, 28 Mar 2019 13:32:01 +0100 objtool: Query pkg-config for libelf location If it is not in the default location, compilation fails at several points. Signed-off-by: Rolf Eike Beer Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Cc: sta...@vger.kernel.org Link: https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoim...@redhat.com --- Makefile | 4 +++- tools/objtool/Makefile | 7 +-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index c0a34064c574..eef3d3f87c3b 100644 --- a/Makefile +++ b/Makefile @@ -950,9 +950,11 @@ mod_sign_cmd = true endif export mod_sign_cmd +HOST_LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) + ifdef CONFIG_STACK_VALIDATION has_libelf := $(call try-run,\ - echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf -,1,0) + echo "int main() {}" | $(HOSTCC) -xc -o /dev/null $(HOST_LIBELF_LIBS) -,1,0) ifeq ($(has_libelf),1) objtool_target := tools/objtool FORCE else diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index c9d038f91af6..53f8be0f4a1f 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -25,14 +25,17 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a OBJTOOL:= $(OUTPUT)objtool OBJTOOL_IN := $(OBJTOOL)-in.o +LIBELF_FLAGS := $(shell pkg-config libelf --cflags 2>/dev/null) +LIBELF_LIBS := $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) + all: $(OBJTOOL) INCLUDES := -I$(srctree)/tools/include \ -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \ -I$(srctree)/tools/objtool/arch/$(ARCH)/include WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed -CFLAGS += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) -LDFLAGS += -lelf $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS) +CFLAGS += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) $(LIBELF_FLAGS) +LDFLAGS += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS) # Allow old libelf to be used: elfshdr := $(shell echo '$(pound)include ' | $(CC) $(CFLAGS) -x c -E - | grep elf_getshdr)
[PATCH v2] objtool: query pkg-config for libelf location
If it is not in the default location compilation would fail at several points. Signed-off-by: Rolf Eike Beer --- Changes in v2: -also hide stderr when querying cflags -use ":=" assignment as in other places in that file Makefile | 4 +++- tools/objtool/Makefile | 7 +-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 99c0530489ef..32caf30e0d79 100644 --- a/Makefile +++ b/Makefile @@ -950,9 +950,11 @@ mod_sign_cmd = true endif export mod_sign_cmd +HOST_LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) + ifdef CONFIG_STACK_VALIDATION has_libelf := $(call try-run,\ - echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf -,1,0) + echo "int main() {}" | $(HOSTCC) -xc -o /dev/null $(HOST_LIBELF_LIBS) -,1,0) ifeq ($(has_libelf),1) objtool_target := tools/objtool FORCE else diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index c9d038f91af6..53f8be0f4a1f 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -25,14 +25,17 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a OBJTOOL:= $(OUTPUT)objtool OBJTOOL_IN := $(OBJTOOL)-in.o +LIBELF_FLAGS := $(shell pkg-config libelf --cflags 2>/dev/null) +LIBELF_LIBS := $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) + all: $(OBJTOOL) INCLUDES := -I$(srctree)/tools/include \ -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \ -I$(srctree)/tools/objtool/arch/$(ARCH)/include WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed -CFLAGS += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) -LDFLAGS += -lelf $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS) +CFLAGS += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) $(LIBELF_FLAGS) +LDFLAGS += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS) # Allow old libelf to be used: elfshdr := $(shell echo '$(pound)include ' | $(CC) $(CFLAGS) -x c -E - | grep elf_getshdr) -- 2.21.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH] objtool: query pkg-config for libelf location
Josh Poimboeuf wrote: > On Tue, Mar 19, 2019 at 08:20:12AM +0100, Rolf Eike Beer wrote: > > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile > > index c9d038f91af6..0c8dd1609348 100644 > > --- a/tools/objtool/Makefile > > +++ b/tools/objtool/Makefile > > @@ -25,14 +25,17 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a > > > > OBJTOOL:= $(OUTPUT)objtool > > OBJTOOL_IN := $(OBJTOOL)-in.o > > > > +LIBELF_FLAGS = $(shell pkg-config libelf --cflags) > > +LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) > > Should LIBELF_FLAGS also pipe stderr to /dev/null? Probably. New version in a minute. Thanks, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH] objtool: query pkg-config for libelf location
If it is not in the default location compilation would fail at several points. Signed-off-by: Rolf Eike Beer --- Makefile | 4 +++- tools/objtool/Makefile | 7 +-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 9ef547fc7ffe..666b52c1c5f4 100644 --- a/Makefile +++ b/Makefile @@ -940,9 +940,11 @@ mod_sign_cmd = true endif export mod_sign_cmd +HOST_LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) + ifdef CONFIG_STACK_VALIDATION has_libelf := $(call try-run,\ - echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf -,1,0) + echo "int main() {}" | $(HOSTCC) -xc -o /dev/null $(HOST_LIBELF_LIBS) -,1,0) ifeq ($(has_libelf),1) objtool_target := tools/objtool FORCE else diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index c9d038f91af6..0c8dd1609348 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -25,14 +25,17 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a OBJTOOL:= $(OUTPUT)objtool OBJTOOL_IN := $(OBJTOOL)-in.o +LIBELF_FLAGS = $(shell pkg-config libelf --cflags) +LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) + all: $(OBJTOOL) INCLUDES := -I$(srctree)/tools/include \ -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \ -I$(srctree)/tools/objtool/arch/$(ARCH)/include WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed -CFLAGS += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) -LDFLAGS += -lelf $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS) +CFLAGS += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) $(LIBELF_FLAGS) +LDFLAGS += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS) # Allow old libelf to be used: elfshdr := $(shell echo '$(pound)include ' | $(CC) $(CFLAGS) -x c -E - | grep elf_getshdr) -- 2.21.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [PATCH v2] scripts: use pkg-config to locate libcrypto
Am Montag, 26. November 2018, 10:13:23 CET schrieb Rolf Eike Beer: > Am Samstag, 24. November 2018, 06:53:39 CET schrieb Sasha Levin: > > Hi, > > > > [This is an automated email] > > > > This commit has been processed because it contains a -stable tag. > > The stable tag indicates that it's relevant for the following trees: all > > > > The bot has tested the following trees: v4.19.3, v4.14.82, v4.9.138, > > v4.4.164, v3.18.126. > > > > v4.19.3: Build failed! Errors: > > collect2: error: ld returned 1 exit status > > This sounds like it could actually be a problem, can you point me to the > full log, please? > > > v4.14.82: Failed to apply! Possible dependencies: > > Unable to calculate > > This would either need 8377bd2b9ee1be35b39b5523f640a2b75ddd7c4e as well, or > a modified patch. Manually fixing this up should be trivial. Just tell me > which way you prefer. Ping? -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2] scripts: use pkg-config to locate libcrypto
Am Samstag, 24. November 2018, 06:53:39 CET schrieb Sasha Levin: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.19.3, v4.14.82, v4.9.138, > v4.4.164, v3.18.126. > > v4.19.3: Build failed! Errors: > collect2: error: ld returned 1 exit status This sounds like it could actually be a problem, can you point me to the full log, please? > v4.14.82: Failed to apply! Possible dependencies: > Unable to calculate This would either need 8377bd2b9ee1be35b39b5523f640a2b75ddd7c4e as well, or a modified patch. Manually fixing this up should be trivial. Just tell me which way you prefer. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2] scripts: use pkg-config to locate libcrypto
Am Samstag, 24. November 2018, 06:53:39 CET schrieb Sasha Levin: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.19.3, v4.14.82, v4.9.138, > v4.4.164, v3.18.126. > > v4.19.3: Build failed! Errors: > collect2: error: ld returned 1 exit status This sounds like it could actually be a problem, can you point me to the full log, please? > v4.14.82: Failed to apply! Possible dependencies: > Unable to calculate This would either need 8377bd2b9ee1be35b39b5523f640a2b75ddd7c4e as well, or a modified patch. Manually fixing this up should be trivial. Just tell me which way you prefer. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH v2] scripts: use pkg-config to locate libcrypto
Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile b/scripts/Makefile index ece52ff20171..769fa6b7b685 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -8,7 +8,11 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables +PKG_CONFIG?= pkg-config + HOST_EXTRACFLAGS += -I$(srctree)/tools/include +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto) +CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c hostprogs-$(CONFIG_KALLSYMS) += kallsyms @@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(CRYPTO_LIBS) +HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS) +HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) always := $(hostprogs-y) $(hostprogs-m) -- 2.19.1 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
[PATCH v2] scripts: use pkg-config to locate libcrypto
Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile b/scripts/Makefile index ece52ff20171..769fa6b7b685 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -8,7 +8,11 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables +PKG_CONFIG?= pkg-config + HOST_EXTRACFLAGS += -I$(srctree)/tools/include +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto) +CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c hostprogs-$(CONFIG_KALLSYMS) += kallsyms @@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(CRYPTO_LIBS) +HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS) +HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) always := $(hostprogs-y) $(hostprogs-m) -- 2.19.1 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
[PATCH] scripts: use pkg-config to locate libcrypto
Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org --- scripts/Makefile | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile b/scripts/Makefile index ece52ff20171..a303f478a65b 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -8,6 +8,8 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables +PKG_CONFIG?= pkg-config + HOST_EXTRACFLAGS += -I$(srctree)/tools/include hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c @@ -23,8 +25,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto) +HOSTCFLAGS_extract-cert.o = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) +HOSTLDLIBS_extract-cert = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto) always := $(hostprogs-y) $(hostprogs-m) -- 2.19.1 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
[PATCH] scripts: use pkg-config to locate libcrypto
Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org --- scripts/Makefile | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile b/scripts/Makefile index ece52ff20171..a303f478a65b 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -8,6 +8,8 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables +PKG_CONFIG?= pkg-config + HOST_EXTRACFLAGS += -I$(srctree)/tools/include hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c @@ -23,8 +25,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto) +HOSTCFLAGS_extract-cert.o = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) +HOSTLDLIBS_extract-cert = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || -lcrypto) always := $(hostprogs-y) $(hostprogs-m) -- 2.19.1 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command
Am 2018-09-27 13:23, schrieb Leonardo Bras: Hello Rolf, On Thu, Sep 27, 2018 at 3:34 AM, Rolf Eike Beer wrote: Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo Brás: Creates new Makefile to avoid building driver if 'make drivers/oprofile/' is called directly. This driver is usually built from arch/$ARCH and seems to have no meaning building alone. Signed-off-by: Leonardo Brás --- drivers/oprofile/Makefile | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 drivers/oprofile/Makefile diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile new file mode 100644 index ..acaed2ad6eee --- /dev/null +++ b/drivers/oprofile/Makefile @@ -0,0 +1,2 @@ +#Does nothing, since the source is called from arch/$ARCH/ tree. + Now there is a blank line where it does not need to be. Eike Oh, it's a Makefile, and as all text files, it have to end with newline. If I am wrong, please let me know. No, that's fine. But it means it has to have one LF after "tree.". It had none, now it hat 2. Eike
Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command
Am 2018-09-27 13:23, schrieb Leonardo Bras: Hello Rolf, On Thu, Sep 27, 2018 at 3:34 AM, Rolf Eike Beer wrote: Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo Brás: Creates new Makefile to avoid building driver if 'make drivers/oprofile/' is called directly. This driver is usually built from arch/$ARCH and seems to have no meaning building alone. Signed-off-by: Leonardo Brás --- drivers/oprofile/Makefile | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 drivers/oprofile/Makefile diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile new file mode 100644 index ..acaed2ad6eee --- /dev/null +++ b/drivers/oprofile/Makefile @@ -0,0 +1,2 @@ +#Does nothing, since the source is called from arch/$ARCH/ tree. + Now there is a blank line where it does not need to be. Eike Oh, it's a Makefile, and as all text files, it have to end with newline. If I am wrong, please let me know. No, that's fine. But it means it has to have one LF after "tree.". It had none, now it hat 2. Eike
Re: [PATCH v2 1/7] drivers: dio: Avoids building driver if CONFIG_DIO is disabled
Am Donnerstag, 27. September 2018, 03:39:56 CEST schrieb Leonardo Brás: > Avoids building driver if 'make drivers/dio/' is called and > CONFIG_DIO is disabled. > > Signed-off-by: Leonardo Brás > --- > drivers/dio/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dio/Makefile b/drivers/dio/Makefile > index ae92d17083f2..f5cffe232448 100644 > --- a/drivers/dio/Makefile > +++ b/drivers/dio/Makefile > @@ -2,4 +2,4 @@ > # Makefile for the linux kernel. > # > > -obj-y := dio.o dio-driver.o dio-sysfs.o > +obj-$(CONFIG_DIO) := dio.o dio-driver.o dio-sysfs.o > \ No newline at end of file ^^ One more. signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 1/7] drivers: dio: Avoids building driver if CONFIG_DIO is disabled
Am Donnerstag, 27. September 2018, 03:39:56 CEST schrieb Leonardo Brás: > Avoids building driver if 'make drivers/dio/' is called and > CONFIG_DIO is disabled. > > Signed-off-by: Leonardo Brás > --- > drivers/dio/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dio/Makefile b/drivers/dio/Makefile > index ae92d17083f2..f5cffe232448 100644 > --- a/drivers/dio/Makefile > +++ b/drivers/dio/Makefile > @@ -2,4 +2,4 @@ > # Makefile for the linux kernel. > # > > -obj-y := dio.o dio-driver.o dio-sysfs.o > +obj-$(CONFIG_DIO) := dio.o dio-driver.o dio-sysfs.o > \ No newline at end of file ^^ One more. signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command
Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo Brás: > Creates new Makefile to avoid building driver if > 'make drivers/oprofile/' is called directly. > > This driver is usually built from arch/$ARCH and seems to have > no meaning building alone. > > Signed-off-by: Leonardo Brás > --- > drivers/oprofile/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > create mode 100644 drivers/oprofile/Makefile > > diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile > new file mode 100644 > index ..acaed2ad6eee > --- /dev/null > +++ b/drivers/oprofile/Makefile > @@ -0,0 +1,2 @@ > +#Does nothing, since the source is called from arch/$ARCH/ tree. > + Now there is a blank line where it does not need to be. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 6/7] drivers: oprofile: Avoids building driver from direct make command
Am Donnerstag, 27. September 2018, 03:41:38 CEST schrieb Leonardo Brás: > Creates new Makefile to avoid building driver if > 'make drivers/oprofile/' is called directly. > > This driver is usually built from arch/$ARCH and seems to have > no meaning building alone. > > Signed-off-by: Leonardo Brás > --- > drivers/oprofile/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > create mode 100644 drivers/oprofile/Makefile > > diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile > new file mode 100644 > index ..acaed2ad6eee > --- /dev/null > +++ b/drivers/oprofile/Makefile > @@ -0,0 +1,2 @@ > +#Does nothing, since the source is called from arch/$ARCH/ tree. > + Now there is a blank line where it does not need to be. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 6/7] drivers: oprofile: Avoids building driver from direct make command
Leonardo Brás wrote: Creates new Makefile to avoid building driver if 'make drivers/oprofile/' is called directly. This driver is usually built from arch/$ARCH and seems to have no meaning building alone. Signed-off-by: Leonardo Brás --- drivers/oprofile/Makefile | 1 + 1 file changed, 1 insertion(+) create mode 100644 drivers/oprofile/Makefile diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile new file mode 100644 index ..6b36c93e9762 --- /dev/null +++ b/drivers/oprofile/Makefile @@ -0,0 +1 @@ +#Does nothing, since the source is called from arch/$ARCH/ tree. \ No newline at end of file ^ Is that intentional or bogus? Eike
Re: [PATCH 6/7] drivers: oprofile: Avoids building driver from direct make command
Leonardo Brás wrote: Creates new Makefile to avoid building driver if 'make drivers/oprofile/' is called directly. This driver is usually built from arch/$ARCH and seems to have no meaning building alone. Signed-off-by: Leonardo Brás --- drivers/oprofile/Makefile | 1 + 1 file changed, 1 insertion(+) create mode 100644 drivers/oprofile/Makefile diff --git a/drivers/oprofile/Makefile b/drivers/oprofile/Makefile new file mode 100644 index ..6b36c93e9762 --- /dev/null +++ b/drivers/oprofile/Makefile @@ -0,0 +1 @@ +#Does nothing, since the source is called from arch/$ARCH/ tree. \ No newline at end of file ^ Is that intentional or bogus? Eike
Re: [PATCH] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()
Markus Elfring wrote: > From: Markus Elfring> Date: Fri, 24 Nov 2017 22:22:06 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/video/fbdev/stifb.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c > index 6ded5c198998..fe217a2f7d21 100644 > --- a/drivers/video/fbdev/stifb.c > +++ b/drivers/video/fbdev/stifb.c > @@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct > *sti, int bpp_pref) int bpp, xres, yres; > > fb = kzalloc(sizeof(*fb), GFP_ATOMIC); > - if (!fb) { > - printk(KERN_ERR "stifb: Could not allocate stifb structure\n"); > + if (!fb) > return -ENODEV; > - } > > info = >info; This should be -ENOMEM. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()
Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 24 Nov 2017 22:22:06 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/video/fbdev/stifb.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c > index 6ded5c198998..fe217a2f7d21 100644 > --- a/drivers/video/fbdev/stifb.c > +++ b/drivers/video/fbdev/stifb.c > @@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct > *sti, int bpp_pref) int bpp, xres, yres; > > fb = kzalloc(sizeof(*fb), GFP_ATOMIC); > - if (!fb) { > - printk(KERN_ERR "stifb: Could not allocate stifb structure\n"); > + if (!fb) > return -ENODEV; > - } > > info = >info; This should be -ENOMEM. Eike signature.asc Description: This is a digitally signed message part.
[PATCH 2/3] selftests: do not require bash to run bpf tests
>From b9d6c1b7427d708ef2d4d57aac17b700b3694d71 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer <eike-ker...@sf-tec.de> Date: Wed, 14 Dec 2016 09:58:12 +0100 Subject: [PATCH 2/3] selftests: do not require bash to run bpf tests Nothing in this minimal script seems to require bash. We often run these tests on embedded devices where the only shell available is the busybox ash. Signed-off-by: Rolf Eike Beer <e...@emlix.com> --- tools/testing/selftests/bpf/test_kmod.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/test_kmod.sh b/tools/testing/selftests/bpf/test_kmod.sh index 92e627a..6d58cca 100755 --- a/tools/testing/selftests/bpf/test_kmod.sh +++ b/tools/testing/selftests/bpf/test_kmod.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/bin/sh SRC_TREE=../../../../ -- 2.8.3 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix – smart embedded open source
[PATCH 2/3] selftests: do not require bash to run bpf tests
>From b9d6c1b7427d708ef2d4d57aac17b700b3694d71 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer Date: Wed, 14 Dec 2016 09:58:12 +0100 Subject: [PATCH 2/3] selftests: do not require bash to run bpf tests Nothing in this minimal script seems to require bash. We often run these tests on embedded devices where the only shell available is the busybox ash. Signed-off-by: Rolf Eike Beer --- tools/testing/selftests/bpf/test_kmod.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/test_kmod.sh b/tools/testing/selftests/bpf/test_kmod.sh index 92e627a..6d58cca 100755 --- a/tools/testing/selftests/bpf/test_kmod.sh +++ b/tools/testing/selftests/bpf/test_kmod.sh @@ -1,4 +1,4 @@ -#!/bin/bash +#!/bin/sh SRC_TREE=../../../../ -- 2.8.3 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix – smart embedded open source
Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h
Arnd Bergmann wrote: > The asm-generic/rtc.h header can now be included by > architectures that provide their own set_rtc_time/get_rtc_time > macros, letting us remove most of the common contents in > the powerpc implementation. parisc in this case. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h
Arnd Bergmann wrote: > The asm-generic/rtc.h header can now be included by > architectures that provide their own set_rtc_time/get_rtc_time > macros, letting us remove most of the common contents in > the powerpc implementation. parisc in this case. Eike signature.asc Description: This is a digitally signed message part.
4.3.3: error when plugging in USB stick
[199328.874819] [ cut here ] [199328.874825] WARNING: CPU: 3 PID: 15727 at ../block/genhd.c:626 add_disk+0x43e/0x480() [199328.874827] Modules linked in: hid_cherry usb_storage cdc_phonet phonet hid_generic usbhid fuse ctr ccm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit bnep ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_d efrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tab les drbg ansi_cprng dm_crypt nls_iso8859_1 nls_cp437 vfat fat btusb btintel btbcm btrtl bluetooth arc4 joydev rtsx_pci_ms memstick rtsx_pci_sdmmc mmc_core iTCO_wdt iTCO_vendor_support iwlmvm mac80211 pcspkr serio_raw iwlwifi cfg8021 1 snd_hda_codec_via rfkill snd_hda_codec_hdmi rtsx_pci snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp [199328.874868] coretemp kvm_intel kvm lpc_ich crct10dif_pclmul crc32_pclmul crc32c_intel mfd_core i2c_i801 aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 shpchp wmi fjes xhci_pci xhci_hcd tpm_infineon tpm_tis t pm snd_hda_intel snd_hda_codec mei_me snd_hda_core e1000e snd_hwdep mei ptp snd_pcm pps_core snd_seq snd_timer snd_seq_device snd soundcore sg battery ac efivarfs i915 drm_kms_helper ehci_pci ehci_hcd drm usbcore fb_sys_fops sysimgb lt usb_common sysfillrect syscopyarea i2c_algo_bit thermal video button processor scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac raid456 async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid10 raid1 raid0 md_mod dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod [199328.874916] CPU: 3 PID: 15727 Comm: kworker/u16:2 Not tainted 4.3.3-2.gdb72752-default #1 [199328.874917] Hardware name: Notebook W740SU /W740SU , BIOS 4.6.5 07/05/2013 [199328.874923] Workqueue: events_unbound async_run_entry_fn [199328.874925] 81a75772 8800ae937d18 81376259 [199328.874927] 8800ae937d50 8107afc2 88020d3a4000 88020d3a4080 [199328.874930] 88020d3a400c 8802145bc9d0 8802172ef480 8800ae937d60 [199328.874932] Call Trace: [199328.874941] [] try_stack_unwind+0x175/0x190 [199328.874948] [] dump_trace+0x69/0x3a0 [199328.874951] [] show_trace_log_lvl+0x4b/0x60 [199328.874954] [] show_stack_log_lvl+0x10c/0x180 [199328.874957] [] show_stack+0x25/0x50 [199328.874962] [] dump_stack+0x4b/0x72 [199328.874967] [] warn_slowpath_common+0x82/0xc0 [199328.874971] [] warn_slowpath_null+0x1a/0x20 [199328.874973] [] add_disk+0x43e/0x480 [199328.874980] [] sd_probe_async+0x115/0x1d0 [199328.874984] [] async_run_entry_fn+0x48/0x150 [199328.874990] [] process_one_work+0x159/0x470 [199328.874993] [] worker_thread+0x48/0x4a0 [199328.874996] [] kthread+0xc9/0xe0 [199328.875001] [] ret_from_fork+0x3f/0x70 [199328.876721] DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70 [199328.876722] Leftover inexact backtrace: [199328.876725] [] ? kthread_worker_fn+0x170/0x170 [199328.876727] ---[ end trace 0335892bcf3ba8c0 ]--- signature.asc Description: This is a digitally signed message part.
4.3.3: error when plugging in USB stick
[199328.874819] [ cut here ] [199328.874825] WARNING: CPU: 3 PID: 15727 at ../block/genhd.c:626 add_disk+0x43e/0x480() [199328.874827] Modules linked in: hid_cherry usb_storage cdc_phonet phonet hid_generic usbhid fuse ctr ccm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit bnep ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_d efrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tab les drbg ansi_cprng dm_crypt nls_iso8859_1 nls_cp437 vfat fat btusb btintel btbcm btrtl bluetooth arc4 joydev rtsx_pci_ms memstick rtsx_pci_sdmmc mmc_core iTCO_wdt iTCO_vendor_support iwlmvm mac80211 pcspkr serio_raw iwlwifi cfg8021 1 snd_hda_codec_via rfkill snd_hda_codec_hdmi rtsx_pci snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp [199328.874868] coretemp kvm_intel kvm lpc_ich crct10dif_pclmul crc32_pclmul crc32c_intel mfd_core i2c_i801 aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 shpchp wmi fjes xhci_pci xhci_hcd tpm_infineon tpm_tis t pm snd_hda_intel snd_hda_codec mei_me snd_hda_core e1000e snd_hwdep mei ptp snd_pcm pps_core snd_seq snd_timer snd_seq_device snd soundcore sg battery ac efivarfs i915 drm_kms_helper ehci_pci ehci_hcd drm usbcore fb_sys_fops sysimgb lt usb_common sysfillrect syscopyarea i2c_algo_bit thermal video button processor scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac raid456 async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid10 raid1 raid0 md_mod dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod [199328.874916] CPU: 3 PID: 15727 Comm: kworker/u16:2 Not tainted 4.3.3-2.gdb72752-default #1 [199328.874917] Hardware name: Notebook W740SU /W740SU , BIOS 4.6.5 07/05/2013 [199328.874923] Workqueue: events_unbound async_run_entry_fn [199328.874925] 81a75772 8800ae937d18 81376259 [199328.874927] 8800ae937d50 8107afc2 88020d3a4000 88020d3a4080 [199328.874930] 88020d3a400c 8802145bc9d0 8802172ef480 8800ae937d60 [199328.874932] Call Trace: [199328.874941] [] try_stack_unwind+0x175/0x190 [199328.874948] [] dump_trace+0x69/0x3a0 [199328.874951] [] show_trace_log_lvl+0x4b/0x60 [199328.874954] [] show_stack_log_lvl+0x10c/0x180 [199328.874957] [] show_stack+0x25/0x50 [199328.874962] [] dump_stack+0x4b/0x72 [199328.874967] [] warn_slowpath_common+0x82/0xc0 [199328.874971] [] warn_slowpath_null+0x1a/0x20 [199328.874973] [] add_disk+0x43e/0x480 [199328.874980] [] sd_probe_async+0x115/0x1d0 [199328.874984] [] async_run_entry_fn+0x48/0x150 [199328.874990] [] process_one_work+0x159/0x470 [199328.874993] [] worker_thread+0x48/0x4a0 [199328.874996] [] kthread+0xc9/0xe0 [199328.875001] [] ret_from_fork+0x3f/0x70 [199328.876721] DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70 [199328.876722] Leftover inexact backtrace: [199328.876725] [] ? kthread_worker_fn+0x170/0x170 [199328.876727] ---[ end trace 0335892bcf3ba8c0 ]--- signature.asc Description: This is a digitally signed message part.
GPF after s2disk since 4.3 (inode_permission+0x1a/0x50)
Hi all, I see these backtraces whenever I wake up my laptop from s2disk. This has been no problem in 4.2.x. All relevant filesystems I have are ext4. I regularly do s2ram and have not seen any problems with that. Any ideas? Greetings, Eike general protection fault: [#1] PREEMPT SMP Modules linked in: hid_generic usbhid uinput cdc_phonet phonet usb_storage rfcomm cmac ecb ctr ccm fuse af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables bnep drbg ansi_cprng dm_crypt nls_iso8859_1 nls_cp437 vfat fat arc4 iwlmvm mac80211 x86_pkg_temp_thermal intel_powerclamp coretemp btusb btintel btbcm btrtl bluetooth kvm_intel snd_hda_codec_hdmi iwlwifi rtsx_pci_ms snd_hda_codec_via rtsx_pci_sdmmc snd_hda_codec_generic iTCO_wdt mmc_core memstick iTCO_vendor_support cfg80211 rfkill rtsx_pci kvm snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq snd_timer lpc_ich snd_seq_device mfd_core shpchp snd fjes soundcore crct10dif_pclmul crc32_pclmul mei_me crc32c_intel mei aesni_intel joydev pcspkr ablk_helper cryptd lrw i2c_i801 gf128mul glue_helper aes_x86_64 e1000e ptp serio_raw pps_core xhci_pci xhci_hcd wmi tpm_infineon tpm_tis tpm battery ac sg efivarfs i915 ehci_pci ehci_hcd drm_kms_helper drm usbcore fb_sys_fops sysimgblt sysfillrect usb_common syscopyarea i2c_algo_bit thermal video button pr ocessor scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac raid456 async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid10 raid1 raid0 md_mod dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod CPU: 7 PID: 12631 Comm: pm-powersave Not tainted 4.3.3-2.gdb72752-default #1 Hardware name: Notebook W740SU /W740SU , BIOS 4.6.5 07/05/2013 task: 8800a8ea4080 ti: 88005819 task.ti: 88005819 RIP: 0010:[] [] inode_permission+0x1a/0x50 RSP: 0018:880058193db0 EFLAGS: 00010202 RAX: 00d500d4 RBX: 8801fafbf080 RCX: 0005 RDX: 0004 RSI: 0002 RDI: 88003632bd88 RBP: 880058193db0 R08: 0001 R09: 8800c476f02a R10: 8992c6d7 R11: 880034f2dd10 R12: 0001 R13: 880058193e4c R14: 88003632bd88 R15: FS: 7f06336a3700() GS:88021fbc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f0632ad0790 CR3: 000201384000 CR4: 001406e0 Stack: 880058193e00 8163df4f 0017 0800 8800d945e0e0 880034f2dcd8 8801fafbf080 0017 0800 7ffd01ba5050 880058193e78 8163e3f8 Call Trace: [] unix_find_other+0x4f/0x1f0 [] unix_stream_connect+0xf8/0x470 [] SYSC_connect+0xd9/0x110 [] SyS_connect+0xe/0x10 [] entry_SYSCALL_64_fastpath+0x16/0x75 DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x16/0x75 Leftover inexact backtrace: Code: 4c 89 ef e8 59 4f 49 00 e9 74 ff ff ff 0f 1f 40 00 0f 1f 44 00 00 55 40 f6 c6 02 48 89 e5 75 07 e8 3c ff ff ff 5d c3 48 8b 47 28 40 50 01 74 ef 0f b7 07 89 c2 66 81 e2 00 d0 66 81 fa 00 80 RIP [] inode_permission+0x1a/0x50 RSP ---[ end trace 634ddee63c66edbb ]--- signature.asc Description: This is a digitally signed message part.
GPF after s2disk since 4.3 (inode_permission+0x1a/0x50)
Hi all, I see these backtraces whenever I wake up my laptop from s2disk. This has been no problem in 4.2.x. All relevant filesystems I have are ext4. I regularly do s2ram and have not seen any problems with that. Any ideas? Greetings, Eike general protection fault: [#1] PREEMPT SMP Modules linked in: hid_generic usbhid uinput cdc_phonet phonet usb_storage rfcomm cmac ecb ctr ccm fuse af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables bnep drbg ansi_cprng dm_crypt nls_iso8859_1 nls_cp437 vfat fat arc4 iwlmvm mac80211 x86_pkg_temp_thermal intel_powerclamp coretemp btusb btintel btbcm btrtl bluetooth kvm_intel snd_hda_codec_hdmi iwlwifi rtsx_pci_ms snd_hda_codec_via rtsx_pci_sdmmc snd_hda_codec_generic iTCO_wdt mmc_core memstick iTCO_vendor_support cfg80211 rfkill rtsx_pci kvm snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq snd_timer lpc_ich snd_seq_device mfd_core shpchp snd fjes soundcore crct10dif_pclmul crc32_pclmul mei_me crc32c_intel mei aesni_intel joydev pcspkr ablk_helper cryptd lrw i2c_i801 gf128mul glue_helper aes_x86_64 e1000e ptp serio_raw pps_core xhci_pci xhci_hcd wmi tpm_infineon tpm_tis tpm battery ac sg efivarfs i915 ehci_pci ehci_hcd drm_kms_helper drm usbcore fb_sys_fops sysimgblt sysfillrect usb_common syscopyarea i2c_algo_bit thermal video button pr ocessor scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac raid456 async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid10 raid1 raid0 md_mod dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_mod CPU: 7 PID: 12631 Comm: pm-powersave Not tainted 4.3.3-2.gdb72752-default #1 Hardware name: Notebook W740SU /W740SU , BIOS 4.6.5 07/05/2013 task: 8800a8ea4080 ti: 88005819 task.ti: 88005819 RIP: 0010:[] [] inode_permission+0x1a/0x50 RSP: 0018:880058193db0 EFLAGS: 00010202 RAX: 00d500d4 RBX: 8801fafbf080 RCX: 0005 RDX: 0004 RSI: 0002 RDI: 88003632bd88 RBP: 880058193db0 R08: 0001 R09: 8800c476f02a R10: 8992c6d7 R11: 880034f2dd10 R12: 0001 R13: 880058193e4c R14: 88003632bd88 R15: FS: 7f06336a3700() GS:88021fbc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f0632ad0790 CR3: 000201384000 CR4: 001406e0 Stack: 880058193e00 8163df4f 0017 0800 8800d945e0e0 880034f2dcd8 8801fafbf080 0017 0800 7ffd01ba5050 880058193e78 8163e3f8 Call Trace: [] unix_find_other+0x4f/0x1f0 [] unix_stream_connect+0xf8/0x470 [] SYSC_connect+0xd9/0x110 [] SyS_connect+0xe/0x10 [] entry_SYSCALL_64_fastpath+0x16/0x75 DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x16/0x75 Leftover inexact backtrace: Code: 4c 89 ef e8 59 4f 49 00 e9 74 ff ff ff 0f 1f 40 00 0f 1f 44 00 00 55 40 f6 c6 02 48 89 e5 75 07 e8 3c ff ff ff 5d c3 48 8b 47 28 40 50 01 74 ef 0f b7 07 89 c2 66 81 e2 00 d0 66 81 fa 00 80 RIP [] inode_permission+0x1a/0x50 RSP ---[ end trace 634ddee63c66edbb ]--- signature.asc Description: This is a digitally signed message part.
Kconfig: remove comment about scsi_wait_scan module
This module has been removed in commit 6072609d9bb91ff54aee3ef29304bd5b4fc88aae ([SCSI] Remove scsi_wait_scan module), so this module is gone since 3.6. Signed-off-by: Rolf Eike Beer --- drivers/scsi/Kconfig | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 95f7a76..d2f480b 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -242,13 +242,6 @@ config SCSI_SCAN_ASYNC system continues booting, and even probe devices on different busses in parallel, leading to a significant speed-up. - If you have built SCSI as modules, enabling this option can - be a problem as the devices may not have been found by the - time your system expects them to have been. You can load the - scsi_wait_scan module to ensure that all scans have completed. - If you build your SCSI drivers into the kernel, then everything - will work fine if you say Y here. - You can override this choice by specifying "scsi_mod.scan=sync" or async on the kernel's command line. -- 2.5.1 -- 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/
[Doc] class_find_device: fix reference to argument "match"
There is no argument "fn". Signed-off-by: Rolf Eike Beer --- drivers/base/class.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/class.c b/drivers/base/class.c index 6e81088..71059e3 100644 --- a/drivers/base/class.c +++ b/drivers/base/class.c @@ -406,7 +406,7 @@ EXPORT_SYMBOL_GPL(class_for_each_device); * * Note, you will need to drop the reference with put_device() after use. * - * @fn is allowed to do anything including calling back into class + * @match is allowed to do anything including calling back into class * code. There's no locking restriction. */ struct device *class_find_device(struct class *class, struct device *start, -- 2.5.1 -- 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/
[Doc] class_find_device: fix reference to argument "match"
There is no argument "fn". Signed-off-by: Rolf Eike Beer <eike-ker...@sf-tec.de> --- drivers/base/class.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/class.c b/drivers/base/class.c index 6e81088..71059e3 100644 --- a/drivers/base/class.c +++ b/drivers/base/class.c @@ -406,7 +406,7 @@ EXPORT_SYMBOL_GPL(class_for_each_device); * * Note, you will need to drop the reference with put_device() after use. * - * @fn is allowed to do anything including calling back into class + * @match is allowed to do anything including calling back into class * code. There's no locking restriction. */ struct device *class_find_device(struct class *class, struct device *start, -- 2.5.1 -- 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/
Kconfig: remove comment about scsi_wait_scan module
This module has been removed in commit 6072609d9bb91ff54aee3ef29304bd5b4fc88aae ([SCSI] Remove scsi_wait_scan module), so this module is gone since 3.6. Signed-off-by: Rolf Eike Beer <eike-ker...@sf-tec.de> --- drivers/scsi/Kconfig | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 95f7a76..d2f480b 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -242,13 +242,6 @@ config SCSI_SCAN_ASYNC system continues booting, and even probe devices on different busses in parallel, leading to a significant speed-up. - If you have built SCSI as modules, enabling this option can - be a problem as the devices may not have been found by the - time your system expects them to have been. You can load the - scsi_wait_scan module to ensure that all scans have completed. - If you build your SCSI drivers into the kernel, then everything - will work fine if you say Y here. - You can override this choice by specifying "scsi_mod.scan=sync" or async on the kernel's command line. -- 2.5.1 -- 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: [3.18 regression]: machine hangs on s2ram
> Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do > s2ram. For me it looks like the preparations work, but the machine is then > not switched off. The only way to recover is a hard powercycle. Since the > machine has no serial port I can't look what's happening then, but the logs > do not contain anything suspicious until the point when the machine locks > up. Meanwhile I see this on a different machine (Core i7 desktop), too. I'll see if I can dig out any more information there. Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: [3.18 regression]: machine hangs on s2ram
Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do s2ram. For me it looks like the preparations work, but the machine is then not switched off. The only way to recover is a hard powercycle. Since the machine has no serial port I can't look what's happening then, but the logs do not contain anything suspicious until the point when the machine locks up. Meanwhile I see this on a different machine (Core i7 desktop), too. I'll see if I can dig out any more information there. Greetings, Eike signature.asc Description: This is a digitally signed message part.
[3.18 regression]: machine hangs on s2ram
Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do s2ram. For me it looks like the preparations work, but the machine is then not switched off. The only way to recover is a hard powercycle. Since the machine has no serial port I can't look what's happening then, but the logs do not contain anything suspicious until the point when the machine locks up. Greetings, Eike [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.18.1-1.g5f2f35e-desktop (geeko@buildhost) (gcc version 4.8.3 20141208 [gcc-4_8-branch revision 218481] (SUSE Linux) ) #1 SMP PREEMPT Wed Dec 17 18:20:30 UTC 2014 (5f2f35e) [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.18.1-1.g5f2f35e-desktop root=/dev/md0 resume=/dev/system/swap splash=silent quiet acpi_osi=Linux acpi_backlight=vendor showopts [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved [0.00] BIOS-e820: [mem 0x0010-0xcb65bfff] usable [0.00] BIOS-e820: [mem 0xcb65c000-0xcb662fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcb663000-0xcbe26fff] usable [0.00] BIOS-e820: [mem 0xcbe27000-0xcc0d6fff] reserved [0.00] BIOS-e820: [mem 0xcc0d7000-0xdb4e2fff] usable [0.00] BIOS-e820: [mem 0xdb4e3000-0xdb841fff] reserved [0.00] BIOS-e820: [mem 0xdb842000-0xdb89efff] usable [0.00] BIOS-e820: [mem 0xdb89f000-0xdb9d3fff] ACPI NVS [0.00] BIOS-e820: [mem 0xdb9d4000-0xdbffefff] reserved [0.00] BIOS-e820: [mem 0xdbfff000-0xdbff] usable [0.00] BIOS-e820: [mem 0xdd00-0xdf1f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi: ACPI 2.0=0xdb9a7000 ACPI=0xdb9a7000 SMBIOS=0xdbf88598 [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x00058000) (0MB) [0.00] efi: mem01: [Reserved | | | | | |WB|WT|WC|UC] range=[0x00058000-0x00059000) (0MB) [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x00059000-0x0009e000) (0MB) [0.00] efi: mem03: [Reserved | | | | | |WB|WT|WC|UC] range=[0x0009e000-0x000a) (0MB) [0.00] efi: mem04: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0010-0x015be000) (20MB) [0.00] efi: mem05: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x015be000-0x0200) (10MB) [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0200-0x034be000) (20MB) [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x034be000-0x350dc000) (796MB) [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x350dc000-0x36866000) (23MB) [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x36866000-0x91f07000) (1462MB) [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x91f07000-0xc81f4000) (866MB) [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0xc81f4000-0xcb63e000) (52MB) [0.00] efi: mem12: [Loader Code| | | | | |WB|WT|WC|UC] range=[0xcb63e000-0xcb65c000) (0MB) [0.00] efi: mem13: [ACPI Memory NVS| | | | | |WB|WT|WC|UC] range=[0xcb65c000-0xcb663000) (0MB) [0.00] efi: mem14: [Boot Data | | | | | |WB|WT|WC|UC] range=[0xcb663000-0xcb7b4000) (1MB) [0.00] efi: mem15: [Boot Code | | | | | |WB|WT|WC|UC] range=[0xcb7b4000-0xcbde7000)
[3.18 regression]: machine hangs on s2ram
Since I upgraded to 3.18 my machine (W740SU based laptop) hangs when I do s2ram. For me it looks like the preparations work, but the machine is then not switched off. The only way to recover is a hard powercycle. Since the machine has no serial port I can't look what's happening then, but the logs do not contain anything suspicious until the point when the machine locks up. Greetings, Eike [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.18.1-1.g5f2f35e-desktop (geeko@buildhost) (gcc version 4.8.3 20141208 [gcc-4_8-branch revision 218481] (SUSE Linux) ) #1 SMP PREEMPT Wed Dec 17 18:20:30 UTC 2014 (5f2f35e) [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.18.1-1.g5f2f35e-desktop root=/dev/md0 resume=/dev/system/swap splash=silent quiet acpi_osi=Linux acpi_backlight=vendor showopts [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved [0.00] BIOS-e820: [mem 0x0010-0xcb65bfff] usable [0.00] BIOS-e820: [mem 0xcb65c000-0xcb662fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcb663000-0xcbe26fff] usable [0.00] BIOS-e820: [mem 0xcbe27000-0xcc0d6fff] reserved [0.00] BIOS-e820: [mem 0xcc0d7000-0xdb4e2fff] usable [0.00] BIOS-e820: [mem 0xdb4e3000-0xdb841fff] reserved [0.00] BIOS-e820: [mem 0xdb842000-0xdb89efff] usable [0.00] BIOS-e820: [mem 0xdb89f000-0xdb9d3fff] ACPI NVS [0.00] BIOS-e820: [mem 0xdb9d4000-0xdbffefff] reserved [0.00] BIOS-e820: [mem 0xdbfff000-0xdbff] usable [0.00] BIOS-e820: [mem 0xdd00-0xdf1f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi: ACPI 2.0=0xdb9a7000 ACPI=0xdb9a7000 SMBIOS=0xdbf88598 [0.00] efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x-0x00058000) (0MB) [0.00] efi: mem01: [Reserved | | | | | |WB|WT|WC|UC] range=[0x00058000-0x00059000) (0MB) [0.00] efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x00059000-0x0009e000) (0MB) [0.00] efi: mem03: [Reserved | | | | | |WB|WT|WC|UC] range=[0x0009e000-0x000a) (0MB) [0.00] efi: mem04: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0010-0x015be000) (20MB) [0.00] efi: mem05: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x015be000-0x0200) (10MB) [0.00] efi: mem06: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0200-0x034be000) (20MB) [0.00] efi: mem07: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x034be000-0x350dc000) (796MB) [0.00] efi: mem08: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x350dc000-0x36866000) (23MB) [0.00] efi: mem09: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x36866000-0x91f07000) (1462MB) [0.00] efi: mem10: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x91f07000-0xc81f4000) (866MB) [0.00] efi: mem11: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0xc81f4000-0xcb63e000) (52MB) [0.00] efi: mem12: [Loader Code| | | | | |WB|WT|WC|UC] range=[0xcb63e000-0xcb65c000) (0MB) [0.00] efi: mem13: [ACPI Memory NVS| | | | | |WB|WT|WC|UC] range=[0xcb65c000-0xcb663000) (0MB) [0.00] efi: mem14: [Boot Data | | | | | |WB|WT|WC|UC] range=[0xcb663000-0xcb7b4000) (1MB) [0.00] efi: mem15: [Boot Code | | | | | |WB|WT|WC|UC] range=[0xcb7b4000-0xcbde7000)
Re: [PATCH -v5] random: introduce getrandom(2) system call
Theodore Ts'o wrote: It's me again, finding only one issue per cycle :/ > EAGAIN The requested entropy was not available, and > getentropy(2) would have blocked if GRND_BLOCK flag > was set. "if GRND_NONBLOCK flag was not set" Eike -- 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 -v5] random: introduce getrandom(2) system call
Theodore Ts'o wrote: It's me again, finding only one issue per cycle :/ EAGAIN The requested entropy was not available, and getentropy(2) would have blocked if GRND_BLOCK flag was set. if GRND_NONBLOCK flag was not set Eike -- 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 -v4] random: introduce getrandom(2) system call
> EAGAIN The requested entropy was not available, and the > getentropy(2) would have blocked if GRND_BLOCK flag > was set. I think either "and the call to getentropy(2)" or "and getentropy(2)" here. Greetings, Eike -- 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 -v4] random: introduce getrandom(2) system call
EAGAIN The requested entropy was not available, and the getentropy(2) would have blocked if GRND_BLOCK flag was set. I think either and the call to getentropy(2) or and getentropy(2) here. Greetings, Eike -- 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, RFC] random: introduce getrandom(2) system call
Theodore Ts'o wrote: > DESCRIPTION > > The system call getrandom() fills the buffer pointed to by buf > with up to buflen random bytes which can be used to seed user > space random number generators (i.e., DRBG's) or for other > cryptographic processes. It should not be used Monte Carlo > simulations or for other probabilistic sampling applications. The "for" looks misplaced, shouldn't this be "for Monte Carlo simulations or other ..."? Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH, RFC] random: introduce getrandom(2) system call
Theodore Ts'o wrote: DESCRIPTION The system call getrandom() fills the buffer pointed to by buf with up to buflen random bytes which can be used to seed user space random number generators (i.e., DRBG's) or for other cryptographic processes. It should not be used Monte Carlo simulations or for other probabilistic sampling applications. The for looks misplaced, shouldn't this be for Monte Carlo simulations or other ...? Greetings, Eike signature.asc Description: This is a digitally signed message part.
[3.15.0] Sun V240: soft lockup - CPU stuck
I got this tonight while running a CMake dashboard build (that is where the git command was invoked from). The machine has been running for weeks on 3.14 and I never saw this there. In case you need more information just ask. Greetings, Eike [0.00] Linux version 3.15.0 (root@alrakis) (gcc version 4.7.3 (Gentoo 4.7.3 p1.3) ) #1 SMP Tue Jun 10 11:26:55 CEST 2014 […] [242339.538940] git[1513]: segfault at f77d9b70 ip f78f6838 (rpc f7a3e0ac) sp f77d93e0 error 30001 in libc-2.17.so[f780+16a000] [242360.548826] INFO: rcu_sched self-detected stall on CPU { 1} (t=2101 jiffies g=2435314 c=2435313 q=2249) [242360.548847] CPU[ 0]: TSTATE[fa03] TPC[f7b4b0b4] TNPC[f7b4b0b8] TASK[openssl:26204] [242360.548856] TPC[f7b4b0b4] O7[0] I7[f7b49d44] RPC[f7b49d44] [242360.548862] * CPU[ 1]: TSTATE[11001600] TPC[004fb7c4] TNPC[004fb7c8] TASK[git:1513] [242360.548896] TPC[put_compound_page+0x4/0x260] O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x1bc/0x2a0] RPC[futex_wake+0x24/0x140] [242361.678822] BUG: soft lockup - CPU#1 stuck for 22s! [git:1513] [242361.756631] Modules linked in: ipv6 openpromfs libcrc32c multipath linear raid456 async_pq async_xor xor async_memcpy async_raid6_recov async_tx raid6_pq dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log usb_storage sg [242361.756678] CPU: 1 PID: 1513 Comm: git Not tainted 3.15.0 #1 [242361.756685] task: fc033a65cf00 ti: fc033c51c000 task.ti: fc033c51c000 [242361.756691] TSTATE: 004411001600 TPC: 004fb9a8 TNPC: 004fb9ac Y: Not tainted [242361.756699] TPC: [242361.756704] g0: 0001 g1: g2: 0016 g3: [242361.756709] g4: fc033a65cf00 g5: fc133c572000 g6: fc033c51c000 g7: 00484048 [242361.756715] o0: 0016 o1: 01000275 o2: 0040 o3: 0001 [242361.756720] o4: 01000275 o5: 00a8e080 sp: fc033c51ebe1 ret_pc: 004fb95c [242361.756727] RPC: [242361.756732] l0: ff80 l1: 0100 l2: fc033c360140 l3: fc033c4c6008 [242361.756738] l4: f77da000 l5: fc033a0cef78 l6: f77da000 l7: 0300 [242361.756743] i0: 01000275 i1: f77d9fff i2: 0001 i3: 01000275001c [242361.756749] i4: i5: 01000275fb00 i6: fc033c51ec91 i7: 004b519c [242361.756755] I7: [242361.756759] Call Trace: [242361.756765] [004b519c] get_futex_key+0x1bc/0x2a0 [242361.756771] [004b5f64] futex_wake+0x24/0x140 [242361.756777] [004b7460] do_futex+0x100/0x9a0 [242361.756783] [004b7d98] SyS_futex+0x98/0x1c0 [242361.756791] [0045ee14] mm_release+0x74/0x100 [242361.756798] [00462b78] do_exit+0xf8/0x920 [242361.756805] [004634c8] do_group_exit+0x28/0xc0 [242361.756812] [00471348] get_signal_to_deliver+0x128/0x520 [242361.756822] [00448d94] do_signal32+0x14/0xae0 [242361.756832] [0042ce3c] do_signal+0xdc/0x540 [242361.756838] [0042daa0] do_notify_resume+0x40/0x60 [242361.756846] [00404b04] __handle_signal+0xc/0x2c [242423.588580] INFO: rcu_sched self-detected stall on CPU { 1} (t=8405 jiffies g=2435314 c=2435313 q=7340) [242423.588597] CPU[ 0]: TSTATE[11001606] TPC[00493780] TNPC[00493784] TASK[eselect:1590] [242423.588628] TPC[task_tick_fair+0xc0/0x300] O7[task_tick_fair+0x38/0x300] I7[scheduler_tick+0x4c/0xc0] RPC[update_process_times+0x48/0x60] [242423.588635] * CPU[ 1]: TSTATE[004411001600] TPC[004539e8] TNPC[004539ec] TASK[git:1513] [242423.588648] TPC[get_user_pages_fast+0x1a8/0x360] O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x44/0x2a0] RPC[futex_wake+0x24/0x140] [242486.628334] INFO: rcu_sched self-detected stall on CPU { 1} (t=14709 jiffies g=2435314 c=2435313 q=100069) [242486.628350] CPU[ 0]: TSTATE[0044fa02] TPC[f79e2de0] TNPC[f79e2de4] TASK[ctest:2998] [242486.628356] TPC[f79e2de0] O7[f7caba24] I7[47ad64] RPC[478724] [242486.628362] * CPU[ 1]: TSTATE[004411001600] TPC[004539e8] TNPC[004539ec] TASK[git:1513] [242486.628377] TPC[get_user_pages_fast+0x1a8/0x360] O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x44/0x2a0] RPC[futex_wake+0x24/0x140] [242519.442106] Crash[4150]: segfault at 0 ip 00010650 (rpc (null)) sp fffb7a60 error 30001 in Crash[1+2000] [242549.668087] INFO: rcu_sched self-detected stall on CPU { 1} (t=21013 jiffies g=2435314 c=2435313 q=172509) [242549.668103] CPU[ 0]: TSTATE[80001600] TPC[00659e90] TNPC[00659e94] TASK[rcu_sched:9] [242549.668122] TPC[cpumask_next_and+0x10/0x80]
[3.15.0] Sun V240: soft lockup - CPU stuck
I got this tonight while running a CMake dashboard build (that is where the git command was invoked from). The machine has been running for weeks on 3.14 and I never saw this there. In case you need more information just ask. Greetings, Eike [0.00] Linux version 3.15.0 (root@alrakis) (gcc version 4.7.3 (Gentoo 4.7.3 p1.3) ) #1 SMP Tue Jun 10 11:26:55 CEST 2014 […] [242339.538940] git[1513]: segfault at f77d9b70 ip f78f6838 (rpc f7a3e0ac) sp f77d93e0 error 30001 in libc-2.17.so[f780+16a000] [242360.548826] INFO: rcu_sched self-detected stall on CPU { 1} (t=2101 jiffies g=2435314 c=2435313 q=2249) [242360.548847] CPU[ 0]: TSTATE[fa03] TPC[f7b4b0b4] TNPC[f7b4b0b8] TASK[openssl:26204] [242360.548856] TPC[f7b4b0b4] O7[0] I7[f7b49d44] RPC[f7b49d44] [242360.548862] * CPU[ 1]: TSTATE[11001600] TPC[004fb7c4] TNPC[004fb7c8] TASK[git:1513] [242360.548896] TPC[put_compound_page+0x4/0x260] O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x1bc/0x2a0] RPC[futex_wake+0x24/0x140] [242361.678822] BUG: soft lockup - CPU#1 stuck for 22s! [git:1513] [242361.756631] Modules linked in: ipv6 openpromfs libcrc32c multipath linear raid456 async_pq async_xor xor async_memcpy async_raid6_recov async_tx raid6_pq dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log usb_storage sg [242361.756678] CPU: 1 PID: 1513 Comm: git Not tainted 3.15.0 #1 [242361.756685] task: fc033a65cf00 ti: fc033c51c000 task.ti: fc033c51c000 [242361.756691] TSTATE: 004411001600 TPC: 004fb9a8 TNPC: 004fb9ac Y: Not tainted [242361.756699] TPC: put_compound_page+0x1e8/0x260 [242361.756704] g0: 0001 g1: g2: 0016 g3: [242361.756709] g4: fc033a65cf00 g5: fc133c572000 g6: fc033c51c000 g7: 00484048 [242361.756715] o0: 0016 o1: 01000275 o2: 0040 o3: 0001 [242361.756720] o4: 01000275 o5: 00a8e080 sp: fc033c51ebe1 ret_pc: 004fb95c [242361.756727] RPC: put_compound_page+0x19c/0x260 [242361.756732] l0: ff80 l1: 0100 l2: fc033c360140 l3: fc033c4c6008 [242361.756738] l4: f77da000 l5: fc033a0cef78 l6: f77da000 l7: 0300 [242361.756743] i0: 01000275 i1: f77d9fff i2: 0001 i3: 01000275001c [242361.756749] i4: i5: 01000275fb00 i6: fc033c51ec91 i7: 004b519c [242361.756755] I7: get_futex_key+0x1bc/0x2a0 [242361.756759] Call Trace: [242361.756765] [004b519c] get_futex_key+0x1bc/0x2a0 [242361.756771] [004b5f64] futex_wake+0x24/0x140 [242361.756777] [004b7460] do_futex+0x100/0x9a0 [242361.756783] [004b7d98] SyS_futex+0x98/0x1c0 [242361.756791] [0045ee14] mm_release+0x74/0x100 [242361.756798] [00462b78] do_exit+0xf8/0x920 [242361.756805] [004634c8] do_group_exit+0x28/0xc0 [242361.756812] [00471348] get_signal_to_deliver+0x128/0x520 [242361.756822] [00448d94] do_signal32+0x14/0xae0 [242361.756832] [0042ce3c] do_signal+0xdc/0x540 [242361.756838] [0042daa0] do_notify_resume+0x40/0x60 [242361.756846] [00404b04] __handle_signal+0xc/0x2c [242423.588580] INFO: rcu_sched self-detected stall on CPU { 1} (t=8405 jiffies g=2435314 c=2435313 q=7340) [242423.588597] CPU[ 0]: TSTATE[11001606] TPC[00493780] TNPC[00493784] TASK[eselect:1590] [242423.588628] TPC[task_tick_fair+0xc0/0x300] O7[task_tick_fair+0x38/0x300] I7[scheduler_tick+0x4c/0xc0] RPC[update_process_times+0x48/0x60] [242423.588635] * CPU[ 1]: TSTATE[004411001600] TPC[004539e8] TNPC[004539ec] TASK[git:1513] [242423.588648] TPC[get_user_pages_fast+0x1a8/0x360] O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x44/0x2a0] RPC[futex_wake+0x24/0x140] [242486.628334] INFO: rcu_sched self-detected stall on CPU { 1} (t=14709 jiffies g=2435314 c=2435313 q=100069) [242486.628350] CPU[ 0]: TSTATE[0044fa02] TPC[f79e2de0] TNPC[f79e2de4] TASK[ctest:2998] [242486.628356] TPC[f79e2de0] O7[f7caba24] I7[47ad64] RPC[478724] [242486.628362] * CPU[ 1]: TSTATE[004411001600] TPC[004539e8] TNPC[004539ec] TASK[git:1513] [242486.628377] TPC[get_user_pages_fast+0x1a8/0x360] O7[get_user_pages_fast+0x2fc/0x360] I7[get_futex_key+0x44/0x2a0] RPC[futex_wake+0x24/0x140] [242519.442106] Crash[4150]: segfault at 0 ip 00010650 (rpc (null)) sp fffb7a60 error 30001 in Crash[1+2000] [242549.668087] INFO: rcu_sched self-detected stall on CPU { 1} (t=21013 jiffies g=2435314 c=2435313 q=172509) [242549.668103] CPU[ 0]: TSTATE[80001600] TPC[00659e90] TNPC[00659e94] TASK[rcu_sched:9]
Re: [Patch V2 0/9] I2C ACPI operation region handler support
Lan Tianyu wrote: > On 05/20/2014 10:17 PM, Rolf Eike Beer wrote: > > It may be that I have taken the wrong ACPI files. This is the result of a > > fresh run of acpidump, together with the most recent dmesg.log, just in > > case I messed it up. > > I have check the log. I2C ACPI operation region targets to I2C > controller > which has one ACPI node in the ACPI table and is associated with one I2C > adapter. Graphic with one ACPI handle registers several I2C adapters. This > causes attach data to the ACPI handle with the same handler several time. > The ACPICA function will return ALREADY EXIST error code and causes the log > you mentioned. There is no I2C ACPI operation region under graphic device > node and so not break function. To avoid these noise logs, I make them only > appear under dynamic debug mode in the my V3 patchset. Hi, thanks for the clarification. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [Patch V2 0/9] I2C ACPI operation region handler support
Lan Tianyu wrote: On 05/20/2014 10:17 PM, Rolf Eike Beer wrote: It may be that I have taken the wrong ACPI files. This is the result of a fresh run of acpidump, together with the most recent dmesg.log, just in case I messed it up. I have check the log. I2C ACPI operation region targets to I2C controller which has one ACPI node in the ACPI table and is associated with one I2C adapter. Graphic with one ACPI handle registers several I2C adapters. This causes attach data to the ACPI handle with the same handler several time. The ACPICA function will return ALREADY EXIST error code and causes the log you mentioned. There is no I2C ACPI operation region under graphic device node and so not break function. To avoid these noise logs, I make them only appear under dynamic debug mode in the my V3 patchset. Hi, thanks for the clarification. Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [Patch V2 0/9] I2C ACPI operation region handler support
Am Montag, 28. April 2014, 22:27:39 schrieb Lan Tianyu: > ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation > region. It allows ACPI aml code able to access such kind of devices to > implement some ACPI standard method. > > On the Asus T100TA, Bios use GenericSerialBus operation region to access > i2c device to get battery info. So battery function depends on the I2C > operation region support. Here is the bug link. > https://bugzilla.kernel.org/show_bug.cgi?id=69011 Hi all, I have tested this series and got some errors, but no additional functionality: [0.607442] ACPI Error: Error attaching device[f60238a0] data [0.607460] (20140214/bus-143) [0.607708] ACPI Error: Error attaching device[f60238a0] data [0.607724] (20140214/bus-143) [0.607987] ACPI Error: Error attaching device[f60238a0] data [0.608003] (20140214/bus-143) [0.608251] ACPI Error: Error attaching device[f60238a0] data [0.608267] (20140214/bus-143) [0.608515] ACPI Error: Error attaching device[f60238a0] data [0.608531] (20140214/bus-143) A bit more output, e.g. the error code if such is present or the device path, could probably help when identifyint the device in question. Also this still looks incomplete, as on other places one still gets those warnings: [0.314944] pnp 00:08: Plug and Play ACPI device, IDs INT33fc (active) [0.316122] pnp 00:09: unknown resource type 19 in _CRS [0.316136] pnp 00:09: can't evaluate _CRS: 1 I don't know if looking on them at this place has any value, maybe something like this is correct? commit 52e2822c4c8b09180e5eb3dd94e4e9aea0d25eff Author: Rolf Eike Beer Date: Tue Feb 18 11:11:10 2014 +0100 ACPI: ignore GPIO and SERIAL_BUS resources in PNP init code diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c index 167f3d0..5b8459b 100644 --- a/drivers/pnp/pnpacpi/rsparser.c +++ b/drivers/pnp/pnpacpi/rsparser.c @@ -240,6 +240,8 @@ static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res, break; case ACPI_RESOURCE_TYPE_GENERIC_REGISTER: + case ACPI_RESOURCE_TYPE_GPIO: + case ACPI_RESOURCE_TYPE_SERIAL_BUS: break; default: Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: [Patch V2 0/9] I2C ACPI operation region handler support
Am Montag, 28. April 2014, 22:27:39 schrieb Lan Tianyu: ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation region. It allows ACPI aml code able to access such kind of devices to implement some ACPI standard method. On the Asus T100TA, Bios use GenericSerialBus operation region to access i2c device to get battery info. So battery function depends on the I2C operation region support. Here is the bug link. https://bugzilla.kernel.org/show_bug.cgi?id=69011 Hi all, I have tested this series and got some errors, but no additional functionality: [0.607442] ACPI Error: Error attaching device[f60238a0] data [0.607460] (20140214/bus-143) [0.607708] ACPI Error: Error attaching device[f60238a0] data [0.607724] (20140214/bus-143) [0.607987] ACPI Error: Error attaching device[f60238a0] data [0.608003] (20140214/bus-143) [0.608251] ACPI Error: Error attaching device[f60238a0] data [0.608267] (20140214/bus-143) [0.608515] ACPI Error: Error attaching device[f60238a0] data [0.608531] (20140214/bus-143) A bit more output, e.g. the error code if such is present or the device path, could probably help when identifyint the device in question. Also this still looks incomplete, as on other places one still gets those warnings: [0.314944] pnp 00:08: Plug and Play ACPI device, IDs INT33fc (active) [0.316122] pnp 00:09: unknown resource type 19 in _CRS [0.316136] pnp 00:09: can't evaluate _CRS: 1 I don't know if looking on them at this place has any value, maybe something like this is correct? commit 52e2822c4c8b09180e5eb3dd94e4e9aea0d25eff Author: Rolf Eike Beer e...@emlix.com Date: Tue Feb 18 11:11:10 2014 +0100 ACPI: ignore GPIO and SERIAL_BUS resources in PNP init code diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c index 167f3d0..5b8459b 100644 --- a/drivers/pnp/pnpacpi/rsparser.c +++ b/drivers/pnp/pnpacpi/rsparser.c @@ -240,6 +240,8 @@ static acpi_status pnpacpi_allocated_resource(struct acpi_resource *res, break; case ACPI_RESOURCE_TYPE_GENERIC_REGISTER: + case ACPI_RESOURCE_TYPE_GPIO: + case ACPI_RESOURCE_TYPE_SERIAL_BUS: break; default: Greetings, Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Bertha-von-Suttner-Str. 9, 37085 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
Re: Lockup on Sun Fire V240 under load
> I recompiled both binutils and gcc in parallel (independent of each other). > Only minutes after I started this the machine locked up. The machine has > 8GiB of RAM and was otherwise idle. This time it was trying to generate a new OpenSSL cert (qmail-genrsacert from Gentoo): [209482.600816] BUG: NMI Watchdog detected LOCKUP on CPU1, ip 0042f748, registers: [209482.696963] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1 [209482.786173] task: f8033a019980 ti: f8033c4c4000 task.ti: f8033c4c4000 [209482.885679] TSTATE: 009911e01605 TPC: 0042f748 TNPC: 0042f3c0 Y: Not tainted [209483.016074] TPC: <__delay+0x28/0x60> [209483.064099] g0: f8033c9c9458 g1: 0042f3c0 g2: 0002 g3: 0001869e [209483.179617] g4: f8033a019980 g5: f8133c59a000 g6: f8033c4c4000 g7: [209483.295135] o0: 0006 o1: f8033c4c4400 o2: 0043d6fc o3: [209483.410651] o4: o5: f7e58000 sp: f8033c4c70f1 ret_pc: 0042f744 [209483.530745] RPC: <__delay+0x24/0x60> [209483.578778] l0: 02494a37a682 l1: 009ce348 l2: 0043d6f8 l3: 0400 [209483.694301] l4: 000e l5: 0001 l6: l7: 0008 [209483.809820] i0: 0018 i1: i2: 0001 i3: [209483.925338] i4: i5: 0003 i6: f8033c4c71a1 i7: 0043d704 [209484.040864] I7: [209484.106041] Call Trace: [209484.139211] [0043d704] cheetah_xcall_deliver+0x184/0x2a0 [209484.220418] [0043d410] xcall_deliver+0x110/0x140 [209484.292478] [004960fc] check_preempt_wakeup+0x11c/0x1e0 [209484.372534] [0048db74] check_preempt_curr+0x94/0xc0 [209484.448023] [00490548] wake_up_new_task+0x108/0x1a0 [209484.523512] [004608e8] do_fork+0xa8/0x220 [209484.587557] [0042ca88] sparc_do_fork+0x28/0x60 [209484.657328] [00406174] linux_sparc_syscall32+0x34/0x40 [209484.736242] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1 [209484.825451] Call Trace: [209484.858628] [00878c28] perfctr_irq+0x2a8/0x360 [209484.928392] [004209f4] tl0_irq15+0x14/0x20 [209484.993583] [0042f748] __delay+0x28/0x60 [209485.056489] [0043d704] cheetah_xcall_deliver+0x184/0x2a0 [209485.137693] [0043d410] xcall_deliver+0x110/0x140 [209485.209750] [004960fc] check_preempt_wakeup+0x11c/0x1e0 [209485.289809] [0048db74] check_preempt_curr+0x94/0xc0 [209485.365297] [00490548] wake_up_new_task+0x108/0x1a0 [209485.440782] [004608e8] do_fork+0xa8/0x220 [209485.504831] [0042ca88] sparc_do_fork+0x28/0x60 [209485.574601] [00406174] linux_sparc_syscall32+0x34/0x40 [209485.653565] BUG: soft lockup - CPU#1 stuck for 33s! [qmail-genrsacer:4612] [209485.745119] Modules linked in: ipv6 openpromfs libcrc32c multipath linear raid456 async_pq async_xor xor async_memcpy async_raid6_recov async_tx raid6_pq dm_snapshot dm_crypt dm_mirror dm_region_hash dm_log usb_storage sg [209486.004746] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1 [209486.093959] task: f8033a019980 ti: f8033c4c4000 task.ti: f8033c4c4000 [209486.193469] TSTATE: 004480001607 TPC: 00878c7c TNPC: 00878c80 Y: Not tainted [209486.323858] TPC: [209486.378749] g0: 3f40 g1: g2: 0001 g3: feff [209486.494271] g4: f8033a019980 g5: f8133c59a000 g6: f8033c4c4000 g7: 0720 [209486.609787] o0: 0092ec00 o1: f8033c4c7ea0 o2: 0042f748 o3: 0092b400 [209486.725304] o4: 0008 o5: f8033c4c7f40 sp: f8133fe97741 ret_pc: 00878c54 [209486.845399] RPC: [209486.900292] l0: f8033c4c6ee1 l1: 0092ec00 l2: l3: f81339bca000 [209487.015813] l4: f8033a019980 l5: l6: 0008 l7: f7d5c000 [209487.131332] i0: 000f i1: f8033c4c7850 i2: f8033c4c7900 i3: [209487.246848] i4: 004f i5: 0002 i6: f8033c4c6f91 i7: 004209f4 [209487.362367] I7: [209487.411537] Call Trace: [209487.444708] [004209f4] tl0_irq15+0x14/0x20 [209487.509905] [0042f748] __delay+0x28/0x60 [209487.572809] [0043d704] cheetah_xcall_deliver+0x184/0x2a0 [209487.654013] [0043d410] xcall_deliver+0x110/0x140 [209487.726070] [004960fc] check_preempt_wakeup+0x11c/0x1e0 [209487.806130] [0048db74] check_preempt_curr+0x94/0xc0 [209487.881616] [00490548] wake_up_new_task+0x108/0x1a0 [209487.957102] [004608e8] do_fork+0xa8/0x220 [209488.021151] [0042ca88] sparc_do_fork+0x28/0x60 [209488.090920] [00406174]
Re: Lockup on Sun Fire V240 under load
I recompiled both binutils and gcc in parallel (independent of each other). Only minutes after I started this the machine locked up. The machine has 8GiB of RAM and was otherwise idle. This time it was trying to generate a new OpenSSL cert (qmail-genrsacert from Gentoo): [209482.600816] BUG: NMI Watchdog detected LOCKUP on CPU1, ip 0042f748, registers: [209482.696963] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1 [209482.786173] task: f8033a019980 ti: f8033c4c4000 task.ti: f8033c4c4000 [209482.885679] TSTATE: 009911e01605 TPC: 0042f748 TNPC: 0042f3c0 Y: Not tainted [209483.016074] TPC: __delay+0x28/0x60 [209483.064099] g0: f8033c9c9458 g1: 0042f3c0 g2: 0002 g3: 0001869e [209483.179617] g4: f8033a019980 g5: f8133c59a000 g6: f8033c4c4000 g7: [209483.295135] o0: 0006 o1: f8033c4c4400 o2: 0043d6fc o3: [209483.410651] o4: o5: f7e58000 sp: f8033c4c70f1 ret_pc: 0042f744 [209483.530745] RPC: __delay+0x24/0x60 [209483.578778] l0: 02494a37a682 l1: 009ce348 l2: 0043d6f8 l3: 0400 [209483.694301] l4: 000e l5: 0001 l6: l7: 0008 [209483.809820] i0: 0018 i1: i2: 0001 i3: [209483.925338] i4: i5: 0003 i6: f8033c4c71a1 i7: 0043d704 [209484.040864] I7: cheetah_xcall_deliver+0x184/0x2a0 [209484.106041] Call Trace: [209484.139211] [0043d704] cheetah_xcall_deliver+0x184/0x2a0 [209484.220418] [0043d410] xcall_deliver+0x110/0x140 [209484.292478] [004960fc] check_preempt_wakeup+0x11c/0x1e0 [209484.372534] [0048db74] check_preempt_curr+0x94/0xc0 [209484.448023] [00490548] wake_up_new_task+0x108/0x1a0 [209484.523512] [004608e8] do_fork+0xa8/0x220 [209484.587557] [0042ca88] sparc_do_fork+0x28/0x60 [209484.657328] [00406174] linux_sparc_syscall32+0x34/0x40 [209484.736242] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1 [209484.825451] Call Trace: [209484.858628] [00878c28] perfctr_irq+0x2a8/0x360 [209484.928392] [004209f4] tl0_irq15+0x14/0x20 [209484.993583] [0042f748] __delay+0x28/0x60 [209485.056489] [0043d704] cheetah_xcall_deliver+0x184/0x2a0 [209485.137693] [0043d410] xcall_deliver+0x110/0x140 [209485.209750] [004960fc] check_preempt_wakeup+0x11c/0x1e0 [209485.289809] [0048db74] check_preempt_curr+0x94/0xc0 [209485.365297] [00490548] wake_up_new_task+0x108/0x1a0 [209485.440782] [004608e8] do_fork+0xa8/0x220 [209485.504831] [0042ca88] sparc_do_fork+0x28/0x60 [209485.574601] [00406174] linux_sparc_syscall32+0x34/0x40 [209485.653565] BUG: soft lockup - CPU#1 stuck for 33s! [qmail-genrsacer:4612] [209485.745119] Modules linked in: ipv6 openpromfs libcrc32c multipath linear raid456 async_pq async_xor xor async_memcpy async_raid6_recov async_tx raid6_pq dm_snapshot dm_crypt dm_mirror dm_region_hash dm_log usb_storage sg [209486.004746] CPU: 1 PID: 4612 Comm: qmail-genrsacer Not tainted 3.12.5 #1 [209486.093959] task: f8033a019980 ti: f8033c4c4000 task.ti: f8033c4c4000 [209486.193469] TSTATE: 004480001607 TPC: 00878c7c TNPC: 00878c80 Y: Not tainted [209486.323858] TPC: perfctr_irq+0x2fc/0x360 [209486.378749] g0: 3f40 g1: g2: 0001 g3: feff [209486.494271] g4: f8033a019980 g5: f8133c59a000 g6: f8033c4c4000 g7: 0720 [209486.609787] o0: 0092ec00 o1: f8033c4c7ea0 o2: 0042f748 o3: 0092b400 [209486.725304] o4: 0008 o5: f8033c4c7f40 sp: f8133fe97741 ret_pc: 00878c54 [209486.845399] RPC: perfctr_irq+0x2d4/0x360 [209486.900292] l0: f8033c4c6ee1 l1: 0092ec00 l2: l3: f81339bca000 [209487.015813] l4: f8033a019980 l5: l6: 0008 l7: f7d5c000 [209487.131332] i0: 000f i1: f8033c4c7850 i2: f8033c4c7900 i3: [209487.246848] i4: 004f i5: 0002 i6: f8033c4c6f91 i7: 004209f4 [209487.362367] I7: tl0_irq15+0x14/0x20 [209487.411537] Call Trace: [209487.444708] [004209f4] tl0_irq15+0x14/0x20 [209487.509905] [0042f748] __delay+0x28/0x60 [209487.572809] [0043d704] cheetah_xcall_deliver+0x184/0x2a0 [209487.654013] [0043d410] xcall_deliver+0x110/0x140 [209487.726070] [004960fc] check_preempt_wakeup+0x11c/0x1e0 [209487.806130] [0048db74] check_preempt_curr+0x94/0xc0 [209487.881616] [00490548] wake_up_new_task+0x108/0x1a0 [209487.957102] [004608e8] do_fork+0xa8/0x220 [209488.021151]
Lockup on Sun Fire V240 under load
I recompiled both binutils and gcc in parallel (independent of each other). Only minutes after I started this the machine locked up. The machine has 8GiB of RAM and was otherwise idle. Greetings, Eike [233026.041133] BUG: NMI Watchdog detected LOCKUP on CPU1, ip 0043d6f8, registers: [233026.137243] CPU: 1 PID: 362 Comm: khugepaged Not tainted 3.12.1 #3 [233026.219590] task: f8033a1e6000 ti: f8033a0a4000 task.ti: f8033a0a4000 [233026.319095] TSTATE: 004480e01602 TPC: 0043d6f8 TNPC: 0043d6fc Y: Not tainted [233026.449493] TPC: [233026.515814] g0: g1: f8133c820008 g2: 0001 g3: 0001869e [233026.631333] g4: f8033a1e6000 g5: f8133c59e000 g6: f8033a0a4000 g7: [233026.746850] o0: 0018 o1: o2: 0001 o3: [233026.862369] o4: o5: 0003 sp: f8033a0a6821 ret_pc: 0043d704 [233026.982462] RPC: [233027.048794] l0: l1: 0001 l2: 0001 l3: 0002 [233027.164314] l4: l5: 0016 l6: f8133c820040 l7: f8133c82 [233027.279836] i0: f8133c820010 i1: 0001 i2: 0002 i3: 0040 [233027.395354] i4: 0050 i5: 0060 i6: f8033a0a68e1 i7: 0043d410 [233027.510872] I7: [233027.566907] Call Trace: [233027.600078] [0043d410] xcall_deliver+0x110/0x140 [233027.672135] [0043e5c0] smp_flush_tlb_page+0x40/0xa0 [233027.747624] [00452d70] tlb_batch_add_one+0x90/0xc0 [233027.821968] [00521c90] ptep_clear_flush+0x30/0x40 [233027.895162] [0051c4d8] try_to_unmap_one+0x78/0x480 [233027.969505] [0051d138] try_to_unmap_anon+0x78/0x140 [233028.044991] [0051d290] try_to_unmap+0x50/0x80 [233028.113618] [00537a64] migrate_pages+0x3c4/0x720 [233028.185674] [0050cfd4] compact_zone+0x2b4/0x400 [233028.256582] [0050d430] compact_zone_order+0x90/0xc0 [233028.332070] [0050d524] try_to_compact_pages+0xc4/0x120 [233028.410989] [004f3694] __alloc_pages_direct_compact+0x54/0x1c0 [233028.499053] [004f3d48] __alloc_pages_nodemask+0x548/0x8a0 [233028.581410] [00530810] alloc_pages_vma+0x50/0x120 [233028.654603] [005396c0] khugepaged+0x620/0xf80 [233028.723232] [00481d08] kthread+0x88/0xa0 [233028.786130] CPU: 1 PID: 362 Comm: khugepaged Not tainted 3.12.1 #3 [233028.868479] Call Trace: [233028.901654] [008780e8] perfctr_irq+0x2a8/0x360 [233028.971419] [004209f4] tl0_irq15+0x14/0x20 [233029.036608] [0043d6f8] cheetah_xcall_deliver+0x178/0x2a0 [233029.117815] [0043d410] xcall_deliver+0x110/0x140 [233029.189870] [0043e5c0] smp_flush_tlb_page+0x40/0xa0 [233029.265356] [00452d70] tlb_batch_add_one+0x90/0xc0 [233029.339699] [00521c90] ptep_clear_flush+0x30/0x40 [233029.412898] [0051c4d8] try_to_unmap_one+0x78/0x480 [233029.487241] [0051d138] try_to_unmap_anon+0x78/0x140 [233029.562726] [0051d290] try_to_unmap+0x50/0x80 [233029.631350] [00537a64] migrate_pages+0x3c4/0x720 [233029.703407] [0050cfd4] compact_zone+0x2b4/0x400 [233029.774318] [0050d430] compact_zone_order+0x90/0xc0 [233029.849806] [0050d524] try_to_compact_pages+0xc4/0x120 [233029.928721] [004f3694] __alloc_pages_direct_compact+0x54/0x1c0 [233030.016789] [004f3d48] __alloc_pages_nodemask+0x548/0x8a0 -- 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/
Lockup on Sun Fire V240 under load
I recompiled both binutils and gcc in parallel (independent of each other). Only minutes after I started this the machine locked up. The machine has 8GiB of RAM and was otherwise idle. Greetings, Eike [233026.041133] BUG: NMI Watchdog detected LOCKUP on CPU1, ip 0043d6f8, registers: [233026.137243] CPU: 1 PID: 362 Comm: khugepaged Not tainted 3.12.1 #3 [233026.219590] task: f8033a1e6000 ti: f8033a0a4000 task.ti: f8033a0a4000 [233026.319095] TSTATE: 004480e01602 TPC: 0043d6f8 TNPC: 0043d6fc Y: Not tainted [233026.449493] TPC: cheetah_xcall_deliver+0x178/0x2a0 [233026.515814] g0: g1: f8133c820008 g2: 0001 g3: 0001869e [233026.631333] g4: f8033a1e6000 g5: f8133c59e000 g6: f8033a0a4000 g7: [233026.746850] o0: 0018 o1: o2: 0001 o3: [233026.862369] o4: o5: 0003 sp: f8033a0a6821 ret_pc: 0043d704 [233026.982462] RPC: cheetah_xcall_deliver+0x184/0x2a0 [233027.048794] l0: l1: 0001 l2: 0001 l3: 0002 [233027.164314] l4: l5: 0016 l6: f8133c820040 l7: f8133c82 [233027.279836] i0: f8133c820010 i1: 0001 i2: 0002 i3: 0040 [233027.395354] i4: 0050 i5: 0060 i6: f8033a0a68e1 i7: 0043d410 [233027.510872] I7: xcall_deliver+0x110/0x140 [233027.566907] Call Trace: [233027.600078] [0043d410] xcall_deliver+0x110/0x140 [233027.672135] [0043e5c0] smp_flush_tlb_page+0x40/0xa0 [233027.747624] [00452d70] tlb_batch_add_one+0x90/0xc0 [233027.821968] [00521c90] ptep_clear_flush+0x30/0x40 [233027.895162] [0051c4d8] try_to_unmap_one+0x78/0x480 [233027.969505] [0051d138] try_to_unmap_anon+0x78/0x140 [233028.044991] [0051d290] try_to_unmap+0x50/0x80 [233028.113618] [00537a64] migrate_pages+0x3c4/0x720 [233028.185674] [0050cfd4] compact_zone+0x2b4/0x400 [233028.256582] [0050d430] compact_zone_order+0x90/0xc0 [233028.332070] [0050d524] try_to_compact_pages+0xc4/0x120 [233028.410989] [004f3694] __alloc_pages_direct_compact+0x54/0x1c0 [233028.499053] [004f3d48] __alloc_pages_nodemask+0x548/0x8a0 [233028.581410] [00530810] alloc_pages_vma+0x50/0x120 [233028.654603] [005396c0] khugepaged+0x620/0xf80 [233028.723232] [00481d08] kthread+0x88/0xa0 [233028.786130] CPU: 1 PID: 362 Comm: khugepaged Not tainted 3.12.1 #3 [233028.868479] Call Trace: [233028.901654] [008780e8] perfctr_irq+0x2a8/0x360 [233028.971419] [004209f4] tl0_irq15+0x14/0x20 [233029.036608] [0043d6f8] cheetah_xcall_deliver+0x178/0x2a0 [233029.117815] [0043d410] xcall_deliver+0x110/0x140 [233029.189870] [0043e5c0] smp_flush_tlb_page+0x40/0xa0 [233029.265356] [00452d70] tlb_batch_add_one+0x90/0xc0 [233029.339699] [00521c90] ptep_clear_flush+0x30/0x40 [233029.412898] [0051c4d8] try_to_unmap_one+0x78/0x480 [233029.487241] [0051d138] try_to_unmap_anon+0x78/0x140 [233029.562726] [0051d290] try_to_unmap+0x50/0x80 [233029.631350] [00537a64] migrate_pages+0x3c4/0x720 [233029.703407] [0050cfd4] compact_zone+0x2b4/0x400 [233029.774318] [0050d430] compact_zone_order+0x90/0xc0 [233029.849806] [0050d524] try_to_compact_pages+0xc4/0x120 [233029.928721] [004f3694] __alloc_pages_direct_compact+0x54/0x1c0 [233030.016789] [004f3d48] __alloc_pages_nodemask+0x548/0x8a0 -- 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: Hard lockups using 3.10.0
Borislav Petkov wrote: On Sun, Aug 11, 2013 at 01:10:11PM +0200, Rolf Eike Beer wrote: The RAM seems fine. It looks like it is the mainboard or a harddisk. The issues have magically disappeared since 3 weeks, but I have not done any suspend2disk since then anymore. Before that I had suspended the machine on the evening and resumed when I came to work. So it's possible that there was some corrupted stuff in the image. Hmm, probably... This is the smart output I got of one disk yesterday: Vendor: /0:0:0:0 Product: User Capacity:600,332,565,813,390,450 bytes [600 PB] Is this for real? 600 PB?? I wanna hdd like that :-) We have problems getting such a disk again. Seems all available one have disappeared somewhere near Bluffdale. I'm not sure how good ext4 can handle sector sizes of several hundred megabytes, so it may be not that fun ;) Eike -- 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: Hard lockups using 3.10.0
Borislav Petkov wrote: On Sun, Aug 11, 2013 at 01:10:11PM +0200, Rolf Eike Beer wrote: The RAM seems fine. It looks like it is the mainboard or a harddisk. The issues have magically disappeared since 3 weeks, but I have not done any suspend2disk since then anymore. Before that I had suspended the machine on the evening and resumed when I came to work. So it's possible that there was some corrupted stuff in the image. Hmm, probably... This is the smart output I got of one disk yesterday: Vendor: /0:0:0:0 Product: User Capacity:600,332,565,813,390,450 bytes [600 PB] Is this for real? 600 PB?? I wanna hdd like that :-) We have problems getting such a disk again. Seems all available one have disappeared somewhere near Bluffdale. I'm not sure how good ext4 can handle sector sizes of several hundred megabytes, so it may be not that fun ;) Eike -- 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: Hard lockups using 3.10.0
Borislav Petkov wrote: > On Sun, Aug 11, 2013 at 08:09:19AM +0200, Rolf Eike Beer wrote: > > Meanwhile I found that there was a hardware defect on this machine. > > So if it does not happen again I will assume that this was caused by > > this. > > What hardware defect exactly? DIMMs failing...? Probably, since it looks > like the spinlock gets corrupted and the assertion fires... In any case, > it would be interesting to know for future reference. The RAM seems fine. It looks like it is the mainboard or a harddisk. The issues have magically disappeared since 3 weeks, but I have not done any suspend2disk since then anymore. Before that I had suspended the machine on the evening and resumed when I came to work. So it's possible that there was some corrupted stuff in the image. This is the smart output I got of one disk yesterday: Vendor: /0:0:0:0 Product: User Capacity:600,332,565,813,390,450 bytes [600 PB] Logical block size: 774843950 bytes scsiModePageOffset: response length too short, resp_len=47 offset=50 bd_len=46 >> Terminate command early due to bad response to IEC mode page A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Eike signature.asc Description: This is a digitally signed message part.
Re: Hard lockups using 3.10.0
Peter Zijlstra wrote: > On Thu, Jul 11, 2013 at 12:07:21PM +0200, Borislav Petkov wrote: > > On Thu, Jul 11, 2013 at 11:38:37AM +0200, Rolf Eike Beer wrote: > > > Hi, > > > > > > I'm running 3.10.0 (from openSUSE packages) on an "Intel(R) Core(TM) > > > i7-2600 CPU @ 3.40GHz". I got a hard lockup on one of my CPUs twice, > > > once with backtrace (see attached image). Graphics is the builtin > > > Intel, used with X 7.6 and KDE 4.10beta2 (basically current openSUSE > > > 12.3+KDE). > > > > > > I'm not aware that I had done anything special, just "normal" desktop > > > and > > > development usage, but no heavy compile work at the moment the lockups > > > happened. > > > > Hmm, I can see commit_creds() doing some rcu pointers assignment and rcu > > calling into the scheduler which screams about a cpu runqueue of the > > task we're about to reschedule not being locked. Let's add some more > > people who should know better. > > Ok, for the other people too lazy to bother finding the picture: > > http://marc.info/?l=linux-kernel=137353587012001=p3 > > So we bug at: > > kernel/sched/core.c:519 assert_raw_spin_locked(_rq(p)->lock); > > and get there through: > > resched_task() > check_preempt_wakeup() > check_preempt_curr() > try_to_wake_up() > autoremove_wake_function() > __call_rcu_nocb_enqueue() > __call_rcu() > commit_creds() > call_usermodehelper() > ret_from_fork() > > That don't make much sense though. Since: > > try_to_wake_up() > ttwu_queue() > raw_spin_lock(>lock) > ttwu_do_activate() > ttwu_do_wakeup() > check_preempt_curr() > check_preempt_wakeup() > resched_task(rq->curr) > assert_raw_spin_locked(task_rq(p)->lock) > > It would somehow mean that 'task_rq(rq->curr) != rq', that's completely > bonkers, we do after all have rq->lock locked. > > I must also say that I've _never_ seen this bug before. Meanwhile I found that there was a hardware defect on this machine. So if it does not happen again I will assume that this was caused by this. Thanks for looking into this. Eike signature.asc Description: This is a digitally signed message part.
Re: Hard lockups using 3.10.0
Peter Zijlstra wrote: On Thu, Jul 11, 2013 at 12:07:21PM +0200, Borislav Petkov wrote: On Thu, Jul 11, 2013 at 11:38:37AM +0200, Rolf Eike Beer wrote: Hi, I'm running 3.10.0 (from openSUSE packages) on an Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz. I got a hard lockup on one of my CPUs twice, once with backtrace (see attached image). Graphics is the builtin Intel, used with X 7.6 and KDE 4.10beta2 (basically current openSUSE 12.3+KDE). I'm not aware that I had done anything special, just normal desktop and development usage, but no heavy compile work at the moment the lockups happened. Hmm, I can see commit_creds() doing some rcu pointers assignment and rcu calling into the scheduler which screams about a cpu runqueue of the task we're about to reschedule not being locked. Let's add some more people who should know better. Ok, for the other people too lazy to bother finding the picture: http://marc.info/?l=linux-kernelm=137353587012001q=p3 So we bug at: kernel/sched/core.c:519 assert_raw_spin_locked(task_rq(p)-lock); and get there through: resched_task() check_preempt_wakeup() check_preempt_curr() try_to_wake_up() autoremove_wake_function() __call_rcu_nocb_enqueue() __call_rcu() commit_creds() call_usermodehelper() ret_from_fork() That don't make much sense though. Since: try_to_wake_up() ttwu_queue() raw_spin_lock(rq-lock) ttwu_do_activate() ttwu_do_wakeup() check_preempt_curr() check_preempt_wakeup() resched_task(rq-curr) assert_raw_spin_locked(task_rq(p)-lock) It would somehow mean that 'task_rq(rq-curr) != rq', that's completely bonkers, we do after all have rq-lock locked. I must also say that I've _never_ seen this bug before. Meanwhile I found that there was a hardware defect on this machine. So if it does not happen again I will assume that this was caused by this. Thanks for looking into this. Eike signature.asc Description: This is a digitally signed message part.