libunwind: Backport a fix for -fno-common option to compile #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Author
|
This is the same patch I have shared in list, I though it would be useful to have tested here too. |
|
thanks. I usually follow after yocto AB testing. |
rzr
pushed a commit
to abandonware/openembedded-core
that referenced
this pull request
Dec 6, 2021
[Khem Raj] defaults for gcc is to use -fno-common this ensures that it keeps building with gcc -fno-common Fixes src/arm/Ginit.c:60: multiple definition of `_U_dyn_info_list'; mi/.libs/dyn-info-list.o:/usr/src/debug/libunwind/1.4.0-r0/build/src/../../libunwind-1.4.0/src/mi/dyn-info-list.c:28: first defined here [Philippe Coval] Change and related patch ported to dunfell branch on 1.3.1 version Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]> Origin: openembedded@6cd2cf6 Relate-to: libunwind/libunwind#312 Relate-to: https://booting.oniroproject.org/distro/oniro/-/issues/191 Change-Id: If34ea06e365f57b6007e9ea3da8d9d716e4b01cc Forwarded: https://lists.openembedded.org/g/openembedded-core/message/158932 Last-Update: 2021-11-25 Relate-to: astarte-platform/astarte-device-sdk-rust#20 Relate-to: YoeDistro#1 Signed-off-by: Philippe Coval <[email protected]>
rzr
force-pushed
the
sandbox/rzr/review/master
branch
from
21fec60 to
1b240db
Compare
Add patches for below CVE issues: CVE-2021-27218 CVE-2021-27219 CVE-2021-28153 Link: https://mirrors.ocf.berkeley.edu/ubuntu/pool/main/g/glib2.0/glib2.0_2.64.6-1~ubuntu20.04.3.debian.tar.xz Also, add regression patchs for CVE-2021-27219. CVE-2021-27219-reg1-3.patch is not relevant for glib2.0 v2.64 Signed-off-by: Neetika.Singh <[email protected]> Signed-off-by: Ranjitsinh Rathod <[email protected]> Signed-off-by: Ranjitsinh Rathod <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
An out-of-bounds heap read in unlzma leads to information leak and denial of service when crafted LZMA-compressed input is decompressed. This can be triggered by any applet/format that internally supports LZMA compression. Reference: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-42374 Signed-off-by: Pavel Zhukov <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
A NULL pointer dereference in Busybox's hush applet leads to denial of service when processing a crafted shell command, due to missing validation after a \x03 delimiter character. This may be used for DoS under very rare conditions of filtered command input. Reference: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-42376 Signed-off-by: Pavel Zhukov <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
Backport a fix for -3972, and whitelist -3968: it isn't valid as it fixes a bug which was introduced after 8.2. Signed-off-by: Ross Burton <[email protected]> Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit bec5caa) Signed-off-by: Steve Sakoman <[email protected]>
Add patch to fix CVE-2021-39537 Link: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/ncurses/patches/Attic/patch-ncurses_tinfo_captoinfo.c?rev=1.1&content-type=text/x-cvsweb-markup Signed-off-by: Ranjitsinh Rathod <[email protected]> Signed-off-by: Ranjitsinh Rathod <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
It seems like CVE-2021-33928, CVE-2021-33929, CVE-2021-33930 and CVE-2021-33938 are pointing to same patch as CVE-2021-3200 So add CVE tag inside the patch file which is the remedy for CVE-2021-33928, CVE-2021-33929, CVE-2021-33930 and CVE-2021-33938 Link: https://ubuntu.com/security/CVE-2021-3200 https://ubuntu.com/security/CVE-2021-33928 https://ubuntu.com/security/CVE-2021-33929 https://ubuntu.com/security/CVE-2021-33930 https://ubuntu.com/security/CVE-2021-33938 Signed-off-by: Ranjitsinh Rathod <[email protected]> Signed-off-by: Ranjitsinh Rathod <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
Notes for BIND 9.11.33 This maintenance release of BIND 9.11 contains no significant changes, although some minor updates have been made (for example, to eliminate compiler warnings emitted by GCC 11). Signed-off-by: Steve Sakoman <[email protected]>
Notes for BIND 9.11.34 This maintenance release of BIND 9.11 contains no significant changes, although some minor updates have been made (for example, to fix build issues on Solaris 11). Signed-off-by: Steve Sakoman <[email protected]>
Notes for BIND 9.11.35 Security Fixes named failed to check the opcode of responses when performing zone refreshes, stub zone updates, and UPDATE forwarding. This could lead to an assertion failure under certain conditions and has been addressed by rejecting responses whose opcode does not match the expected value. [GL #2762] Signed-off-by: Steve Sakoman <[email protected]>
Mark goal.upgrade with sltr as targeted This allows a bugfix in dnf to work Signed-off-by: Jate Sujjavanich <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
Keep installed packages in upgrade job This prevents duplicate identical packages from being reinstalled with each upgrade Signed-off-by: Jate Sujjavanich <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
[Khem Raj] defaults for gcc is to use -fno-common this ensures that it keeps building with gcc -fno-common Fixes src/arm/Ginit.c:60: multiple definition of `_U_dyn_info_list'; mi/.libs/dyn-info-list.o:/usr/src/debug/libunwind/1.4.0-r0/build/src/../../libunwind-1.4.0/src/mi/dyn-info-list.c:28: first defined here [Philippe Coval] Change and related patch ported to dunfell branch on 1.3.1 version Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]> Origin: openembedded@6cd2cf6 Signed-off-by: Philippe Coval <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
The code was assuming that the a recipe with only one srcrev wouldn't "name" it. This isn't the case as the glibc or bzip2 recipes show, you can have a single srcrev which is named. We can pull the data from the fetcher and in fact we already have it, we just need to handle the "default" case and make that code the default for all srcrev regardless of length. [YOCTO #14017] Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit 45ae567) Signed-off-by: Steve Sakoman <[email protected]>
Fix deprecation warnings about invalid escape sequences. Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit 4354261) Signed-off-by: Steve Sakoman <[email protected]>
`googlemock` has been absorbed into the [googletest](https://github.com/google/googletest) project and is built and installed from the same source tree. `googletest` has provided a CMake Config-file Package starting with GTest 1.8.1. `find_package(GTest ...)` by default dispatches first to CMake Find Module. Starting with CMake commit 2327b4330cce157d616ff8b611b3e77568d00351 in CMake v3.20.0 the module dispatches onward to the Config-file Package so that the same targets are available. In pre v3.20.0 versions of CMake however the Find Module masks the targets provided by the upstream `GTest` package. Update `Modules/FindGTest.cmake` to provide the same targets as the CMake Config-file Package and backwards compatible targets and result variables. Signed-off-by: Eero Aaltonen <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
Signed-off-by: Dhruva Gole <[email protected]> Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit 8ea1745) Signed-off-by: Steve Sakoman <[email protected]>
Update URLs to what they actually redirect to. Cc: Quentin Schulz <[email protected]> Signed-off-by: Quentin Schulz <[email protected]> Signed-off-by: Richard Purdie <[email protected]> (cherry picked from commit ec21310) Signed-off-by: Steve Sakoman <[email protected]>
rzr
pushed a commit
to abandonware/openembedded-core
that referenced
this pull request
Dec 7, 2021
[Khem Raj] defaults for gcc is to use -fno-common this ensures that it keeps building with gcc -fno-common Fixes src/arm/Ginit.c:60: multiple definition of `_U_dyn_info_list'; mi/.libs/dyn-info-list.o:/usr/src/debug/libunwind/1.4.0-r0/build/src/../../libunwind-1.4.0/src/mi/dyn-info-list.c:28: first defined here [Philippe Coval] Change and related patch ported to dunfell branch on 1.3.1 version Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]> Origin: openembedded@6cd2cf6 Relate-to: libunwind/libunwind#312 Relate-to: https://booting.oniroproject.org/distro/oniro/-/issues/191 Change-Id: If34ea06e365f57b6007e9ea3da8d9d716e4b01cc Forwarded: https://lists.openembedded.org/g/openembedded-core/message/158932 Last-Update: 2021-11-25 Relate-to: astarte-platform/astarte-device-sdk-rust#20 Relate-to: YoeDistro#1 Relate-to: https://lists.openembedded.org/g/openembedded-core/message/159140?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Ccoval%2C20%2C2%2C0%2C87483217 Signed-off-by: Philippe Coval <[email protected]>
rzr
force-pushed
the
sandbox/rzr/review/master
branch
2 times, most recently
from
fad4b04 to
f788765
Compare
kraj
pushed a commit
that referenced
this pull request
Jul 8, 2022
- curl-ptest is taking around 200 seconds to execute so added curl-ptest to PTESTS_SLOW - This patch is rework on an existing patch provided by Maxin B. John ([email protected]) https://www.openembedded.org/pipermail/openembedded-core/2017-July/139176.html - Below is the run log of curl-ptest START: ptest-runner 2022-07-03T15:52 BEGIN: /usr/lib/curl/ptest ********* System characteristics ******** * curl 7.83.1 (x86_64-poky-linux-gnu) * libcurl/7.83.1 OpenSSL/3.0.3 zlib/1.2.12 libidn2/2.3.2 * Features: alt-svc AsynchDNS Debug HSTS HTTPS-proxy IDN Largefile libz NTLM SSL TLS-SRP UnixSockets * Disabled: headers-api * Host: qemux86-64 * System: Linux qemux86-64 5.15.44-yocto-standard #1 SMP PREEMPT Tue May 31 20:28:59 UTC 2022 x86_64 GNU/Linux * OS: linux * Servers: HTTP-unix * Env: * Seed: 238593 ***************************************** PASS: test 0001 (1 out of 1466, remaining: 25:07, took 1.029s, duration: 00:01) PASS: test 0002 (2 out of 1466, remaining: 13:21, took 0.065s, duration: 00:01) ... ... PASS: test 3019 (1460 out of 1466, remaining: 00:00, took 0.012s, duration: 03:16) PASS: test 3020 (1461 out of 1466, remaining: 00:00, took 0.011s, duration: 03:16) test 3025...The tool set in the test case for this: 'lib3025' does not exist TESTDONE: 1280 tests were considered during 197 seconds. TESTDONE: 783 tests out of PASS: 783 report: 100% DURATION: 202 END: /usr/lib/curl/ptest 2022-07-03T15:56 STOP: ptest-runner TOTAL: 1 FAIL: 0 - disable the curl tests that are expected to fail - remove the generated file configurehelp.pm from curl test beacuse it is causing reproducible build failure. this file is used by some curl tests to scan symbols from curl headers. we are anyway not installing curl headers and already have disabled those tests. [YOCTO #6707] Signed-off-by: Yogesh Tyagi <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Oct 20, 2022
Backport a patch to fix the following on powerpc64 ABIv2. root@qemuppc64:~# lttng create trace_session --live -U net://127.0.0.1 Spawning a session daemon lttng_kretprobes: loading out-of-tree module taints kernel. BUG: Unable to handle kernel data access on read at 0xfffffffffffffff8 Faulting instruction address: 0xc0000000001f6fd0 Oops: Kernel access of bad area, sig: 11 [#1] <snip> Signed-off-by: He Zhe <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 18, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 Signed-off-by: Xiangyu Chen <[email protected]> Signed-off-by: Luca Ceresoli <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 20, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 Signed-off-by: Xiangyu Chen <[email protected]> Signed-off-by: Luca Ceresoli <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 21, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 Signed-off-by: Xiangyu Chen <[email protected]> Signed-off-by: Luca Ceresoli <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Nov 11, 2023
Qemu introduced a commit "target/i386: Enable AVX cpuid bits when using TCG" since v7.2.0. It causes qemu-system-i386 hang with following error: traps: rndc-confgen[342] general protection fault ip:b7ef5545 sp:bfcc6e6c error:0 ------------[ cut here ]------------ Bad FPU state detected at __restore_fpregs_from_fpstate+0x2f/0x60, reinitializing FPU registers. WARNING: CPU: 7 PID: 353 at arch/x86/mm/extable.c:65 fixup_exception+0x29c/0x2d0 Modules linked in: cfg80211 8021q parport_pc parport sch_fq_codel openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 kvm irqbypass fuse configfs CPU: 7 PID: 353 Comm: in:imklog Not tainted 5.15.78-yocto-standard #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 EIP: fixup_exception+0x29c/0x2d0 Code: 05 ed da 89 df 01 68 b0 cb 5f df e8 4f e7 b6 00 0f 0b 58 e9 9d fe ff ff c6 05 ef da 89 df 01 50 68 f0 cb 5f df e8 35 e7 b6 00 <0f> 0b 5b 5e e9 0a ff ff ff ba 01 00 00 00 89 f0 e8 8a c1 b6 00 0f EAX: 00000060 EBX: df734b60 ECX: f5be9cd0 EDX: f5be9ccc ESI: c3485eec EDI: 0000000d EBP: c3485e64 ESP: c3485e4c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00000096 CR0: 80050033 CR2: b79fdde0 CR3: 03cbe000 CR4: 001506d0 Call Trace: ? __restore_fpregs_from_fpstate+0x2f/0x60 exc_general_protection+0x9a/0x390 ? exc_bounds+0x90/0x90 handle_exception+0x133/0x133 Upstream has been fixed this issue[1], so backport the patch to fix it. Ref: [1] https://gitlab.com/qemu-project/qemu/-/commit/48b60eb6c917646df9efa7ddb4c25929f358d647 Signed-off-by: Xiangyu Chen <[email protected]> Signed-off-by: Steve Sakoman <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Dec 23, 2023
…ctor
Integrating the following commit(s) to linux-yocto/6.5:
1/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Sync core before enabling interrupts
Date: Thu, 7 Dec 2023 20:49:24 +0100
text_poke_early() does:
local_irq_save(flags);
memcpy(addr, opcode, len);
local_irq_restore(flags);
sync_core();
That's not really correct because the synchronization should happen before
interrupts are reenabled to ensure that a pending interrupt observes the
complete update of the opcodes.
It's not entirely clear whether the interrupt entry provides enough
serialization already, but moving the sync_core() invocation into interrupt
disabled region does no harm and is obviously correct.
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Bruce Ashfield <[email protected]>
]
2/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place
Date: Thu, 7 Dec 2023 20:49:26 +0100
apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set
special as it optimizes the existing NOPs in place.
Unfortunately this happens with interrupts enabled and does not provide any
form of core synchronization.
So an interrupt hitting in the middle of the update and using the affected
code path will observe a half updated NOP and crash and burn. The following
3 NOP sequence was observed to expose this crash halfways reliably under
QEMU 32bit:
0x90 0x90 0x90
which is replaced by the optimized 3 byte NOP:
0x8d 0x76 0x00
So an interrupt can observe:
1) 0x90 0x90 0x90 nop nop nop
2) 0x8d 0x90 0x90 undefined
3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi
4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi
Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously.
Disable interrupts around this NOP optimization and invoke sync_core()
before reenabling them.
Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives")
Reported-by: Paul Gortmaker <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 3, 2024
…ctor
Integrating the following commit(s) to linux-yocto/6.6:
1/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Sync core before enabling interrupts
Date: Thu, 7 Dec 2023 20:49:24 +0100
text_poke_early() does:
local_irq_save(flags);
memcpy(addr, opcode, len);
local_irq_restore(flags);
sync_core();
That's not really correct because the synchronization should happen before
interrupts are reenabled to ensure that a pending interrupt observes the
complete update of the opcodes.
It's not entirely clear whether the interrupt entry provides enough
serialization already, but moving the sync_core() invocation into interrupt
disabled region does no harm and is obviously correct.
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Bruce Ashfield <[email protected]>
]
2/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place
Date: Thu, 7 Dec 2023 20:49:26 +0100
apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set
special as it optimizes the existing NOPs in place.
Unfortunately this happens with interrupts enabled and does not provide any
form of core synchronization.
So an interrupt hitting in the middle of the update and using the affected
code path will observe a half updated NOP and crash and burn. The following
3 NOP sequence was observed to expose this crash halfways reliably under
QEMU 32bit:
0x90 0x90 0x90
which is replaced by the optimized 3 byte NOP:
0x8d 0x76 0x00
So an interrupt can observe:
1) 0x90 0x90 0x90 nop nop nop
2) 0x8d 0x90 0x90 undefined
3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi
4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi
Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously.
Disable interrupts around this NOP optimization and invoke sync_core()
before reenabling them.
Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives")
Reported-by: Paul Gortmaker <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 3, 2024
…ctor
Integrating the following commit(s) to linux-yocto/6.6:
1/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Sync core before enabling interrupts
Date: Thu, 7 Dec 2023 20:49:24 +0100
text_poke_early() does:
local_irq_save(flags);
memcpy(addr, opcode, len);
local_irq_restore(flags);
sync_core();
That's not really correct because the synchronization should happen before
interrupts are reenabled to ensure that a pending interrupt observes the
complete update of the opcodes.
It's not entirely clear whether the interrupt entry provides enough
serialization already, but moving the sync_core() invocation into interrupt
disabled region does no harm and is obviously correct.
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Bruce Ashfield <[email protected]>
]
2/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place
Date: Thu, 7 Dec 2023 20:49:26 +0100
apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set
special as it optimizes the existing NOPs in place.
Unfortunately this happens with interrupts enabled and does not provide any
form of core synchronization.
So an interrupt hitting in the middle of the update and using the affected
code path will observe a half updated NOP and crash and burn. The following
3 NOP sequence was observed to expose this crash halfways reliably under
QEMU 32bit:
0x90 0x90 0x90
which is replaced by the optimized 3 byte NOP:
0x8d 0x76 0x00
So an interrupt can observe:
1) 0x90 0x90 0x90 nop nop nop
2) 0x8d 0x90 0x90 undefined
3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi
4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi
Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously.
Disable interrupts around this NOP optimization and invoke sync_core()
before reenabling them.
Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives")
Reported-by: Paul Gortmaker <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 4, 2024
…ctor
Integrating the following commit(s) to linux-yocto/6.5:
1/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Sync core before enabling interrupts
Date: Thu, 7 Dec 2023 20:49:24 +0100
text_poke_early() does:
local_irq_save(flags);
memcpy(addr, opcode, len);
local_irq_restore(flags);
sync_core();
That's not really correct because the synchronization should happen before
interrupts are reenabled to ensure that a pending interrupt observes the
complete update of the opcodes.
It's not entirely clear whether the interrupt entry provides enough
serialization already, but moving the sync_core() invocation into interrupt
disabled region does no harm and is obviously correct.
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Bruce Ashfield <[email protected]>
]
2/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place
Date: Thu, 7 Dec 2023 20:49:26 +0100
apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set
special as it optimizes the existing NOPs in place.
Unfortunately this happens with interrupts enabled and does not provide any
form of core synchronization.
So an interrupt hitting in the middle of the update and using the affected
code path will observe a half updated NOP and crash and burn. The following
3 NOP sequence was observed to expose this crash halfways reliably under
QEMU 32bit:
0x90 0x90 0x90
which is replaced by the optimized 3 byte NOP:
0x8d 0x76 0x00
So an interrupt can observe:
1) 0x90 0x90 0x90 nop nop nop
2) 0x8d 0x90 0x90 undefined
3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi
4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi
Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously.
Disable interrupts around this NOP optimization and invoke sync_core()
before reenabling them.
Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives")
Reported-by: Paul Gortmaker <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
(cherry picked from commit 1c8d29a)
Signed-off-by: Steve Sakoman <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 5, 2024
…ctor
Integrating the following commit(s) to linux-yocto/6.6:
1/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Sync core before enabling interrupts
Date: Thu, 7 Dec 2023 20:49:24 +0100
text_poke_early() does:
local_irq_save(flags);
memcpy(addr, opcode, len);
local_irq_restore(flags);
sync_core();
That's not really correct because the synchronization should happen before
interrupts are reenabled to ensure that a pending interrupt observes the
complete update of the opcodes.
It's not entirely clear whether the interrupt entry provides enough
serialization already, but moving the sync_core() invocation into interrupt
disabled region does no harm and is obviously correct.
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Bruce Ashfield <[email protected]>
]
2/2 [
Author: Thomas Gleixner
Email: [email protected]
Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place
Date: Thu, 7 Dec 2023 20:49:26 +0100
apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set
special as it optimizes the existing NOPs in place.
Unfortunately this happens with interrupts enabled and does not provide any
form of core synchronization.
So an interrupt hitting in the middle of the update and using the affected
code path will observe a half updated NOP and crash and burn. The following
3 NOP sequence was observed to expose this crash halfways reliably under
QEMU 32bit:
0x90 0x90 0x90
which is replaced by the optimized 3 byte NOP:
0x8d 0x76 0x00
So an interrupt can observe:
1) 0x90 0x90 0x90 nop nop nop
2) 0x8d 0x90 0x90 undefined
3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi
4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi
Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously.
Disable interrupts around this NOP optimization and invoke sync_core()
before reenabling them.
Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives")
Reported-by: Paul Gortmaker <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 23, 2024
[YOCTO #15162]
when doing devtool modify, sources are extracted into a devtool
temporary workdir. The main source is moved inside
build/workspace/sources/${BPN}/ and local files are moved inside
build/workspace/sources/${BPN}/oe-local-files. Secondary sources are
currently not handled and are lost.
Here is the output of devtool modify/build on bzip2 recipe:
NOTE: bzip2: compiling from external source tree <...>/build/workspace/sources/bzip2
ERROR: bzip2-1.0.8-r0 do_install_ptest_base: ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368', 1, None, None)
ERROR: Logfile of failure stored in: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368
Log data follows:
| DEBUG: Executing shell function do_install_ptest_base
| NOTE: make -j 16 DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest install-ptest
| sed -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
| ../../../../../../workspace/sources/bzip2/Makefile.am > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile
| cp ../../../../../../workspace/sources/bzip2/sample1.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample1.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| ln -s /usr/bin/bzip2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2
| cp: cannot stat '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No such file or directory
| WARNING: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/
1.0.8/git/commons-compress <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress'
| WARNING: Backtrace (BB generated script):
| #1: do_install_ptest, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 189
| openembedded#2: do_install_ptest_base, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 158
| #3: main, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 226
ERROR: Task (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) failed with exit code '1'
NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base
externalsrc class modify SRC_URI to keep only:
* 'file', 'npmsw' and 'crate' sources
* url with type parameter matching 'kmeta' or 'git-dependency'
So by forcing to add type='git-dependency' on secondary sources, we
ensure that when building the recipe, the secondary sources can be
unpacked into WORKDIR.
This allows recipes containing several sources to be built under a
devtool context, but it has some limitations:
* user would not be able to generate patches for the secondary sources
* type="git-dependency" is added for secondary sources even on non git
sources, so we may want to rename this parameter
Signed-off-by: Julien Stephan <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 24, 2024
[YOCTO #15162]
when doing devtool modify, sources are extracted into a devtool
temporary workdir. The main source is moved inside
build/workspace/sources/${BPN}/ and local files are moved inside
build/workspace/sources/${BPN}/oe-local-files. Secondary sources are
currently not handled and are lost.
Here is the output of devtool modify/build on bzip2 recipe:
NOTE: bzip2: compiling from external source tree <...>/build/workspace/sources/bzip2
ERROR: bzip2-1.0.8-r0 do_install_ptest_base: ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368', 1, None, None)
ERROR: Logfile of failure stored in: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368
Log data follows:
| DEBUG: Executing shell function do_install_ptest_base
| NOTE: make -j 16 DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest install-ptest
| sed -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
| ../../../../../../workspace/sources/bzip2/Makefile.am > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile
| cp ../../../../../../workspace/sources/bzip2/sample1.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample1.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| ln -s /usr/bin/bzip2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2
| cp: cannot stat '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No such file or directory
| WARNING: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/
1.0.8/git/commons-compress <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress'
| WARNING: Backtrace (BB generated script):
| #1: do_install_ptest, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 189
| openembedded#2: do_install_ptest_base, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 158
| #3: main, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 226
ERROR: Task (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) failed with exit code '1'
NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base
externalsrc class modify SRC_URI to keep only:
* 'file', 'npmsw' and 'crate' sources
* url with type parameter matching 'kmeta' or 'git-dependency'
So by forcing to add type='git-dependency' on secondary sources, we
ensure that when building the recipe, the secondary sources can be
unpacked into WORKDIR.
This allows recipes containing several sources to be built under a
devtool context, but it has some limitations:
* user would not be able to generate patches for the secondary sources
* type="git-dependency" is added for secondary sources even on non git
sources, so we may want to rename this parameter
Signed-off-by: Julien Stephan <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jan 24, 2024
[YOCTO #15162]
when doing devtool modify, sources are extracted into a devtool
temporary workdir. The main source is moved inside
build/workspace/sources/${BPN}/ and local files are moved inside
build/workspace/sources/${BPN}/oe-local-files. Secondary sources are
currently not handled and are lost.
Here is the output of devtool modify/build on bzip2 recipe:
NOTE: bzip2: compiling from external source tree <...>/build/workspace/sources/bzip2
ERROR: bzip2-1.0.8-r0 do_install_ptest_base: ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368', 1, None, None)
ERROR: Logfile of failure stored in: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368
Log data follows:
| DEBUG: Executing shell function do_install_ptest_base
| NOTE: make -j 16 DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest install-ptest
| sed -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
| ../../../../../../workspace/sources/bzip2/Makefile.am > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile
| cp ../../../../../../workspace/sources/bzip2/sample1.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample1.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| ln -s /usr/bin/bzip2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2
| cp: cannot stat '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No such file or directory
| WARNING: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/
1.0.8/git/commons-compress <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress'
| WARNING: Backtrace (BB generated script):
| #1: do_install_ptest, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 189
| openembedded#2: do_install_ptest_base, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 158
| #3: main, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 226
ERROR: Task (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) failed with exit code '1'
NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base
externalsrc class modify SRC_URI to keep only:
* 'file', 'npmsw' and 'crate' sources
* url with type parameter matching 'kmeta' or 'git-dependency'
So by forcing to add type='git-dependency' on secondary sources, we
ensure that when building the recipe, the secondary sources can be
unpacked into WORKDIR.
This allows recipes containing several sources to be built under a
devtool context, but it has some limitations:
* user would not be able to generate patches for the secondary sources
* type="git-dependency" is added for secondary sources even on non git
sources, so we may want to rename this parameter
Signed-off-by: Julien Stephan <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Mar 15, 2024
Add --system parameter for useradd to avoid intruducing .bashrc
and .profile under home dir to fix the below error.
$ bitbake core-image-weston
| DEBUG: Executing python function set_image_size
| DEBUG: 352679.600000 = 271292 * 1.300000
| DEBUG: 455079.600000 = max(352679.600000, 65536)[352679.600000] + 102400
| DEBUG: 455080.000000 = int(455079.600000)
| DEBUG: 455080 = aligned(455080)
| DEBUG: returning 455080
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_tar
| tar: ./home/weston/.bashrc: Unknown file type; file ignored
| tar: ./home/weston/.profile: Unknown file type; file ignored
| tar: Exiting with failure status due to previous errors
| WARNING: /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897:150 exit 1 from '[ $? -eq 1 ]'
| WARNING: Backtrace (BB generated script):
#1: do_image_tar, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897, line 150
openembedded#2: main, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897, line 156
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing python function set_image_size
| DEBUG: 352679.600000 = 271292 * 1.300000
| DEBUG: 455079.600000 = max(352679.600000, 65536)[352679.600000] + 102400
| DEBUG: 455080.000000 = int(455079.600000)
| DEBUG: 455080 = aligned(455080)
| DEBUG: returning 455080
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_ext4
| DEBUG: Executing dd if=/dev/zero of=/buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.ext4 seek=455080 count=0 bs=1024
| 0+0 records in
| 0+0 records out
| 0 bytes copied, 0.00136946 s, 0.0 kB/s
| DEBUG: Actual Rootfs size: 268184 /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs
| DEBUG: Actual Partition size: 466001920
| DEBUG: Executing mkfs.ext4 -F -i 4096 /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.ext4 -d /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs
| mke2fs 1.47.0 (5-Feb-2023)
| Discarding device blocks: done
| Creating filesystem with 455080 1k blocks and 113792 inodes
| Filesystem UUID: 2031373e-63cd-4711-968b-4023ff7d6a90
| Superblock backups stored on blocks:
| 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
|
| Allocating group tables: done
| Writing inode tables: done
| Creating journal (8192 blocks): done
| Copying files into the device: __populate_fs: ignoring entry ".bashrc"
| .bashrc: File not found by ext2_lookup while looking up ".bashrc"
| mkfs.ext4: File not found by ext2_lookup while populating file system
| WARNING: /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895:178 exit 1 from 'mkfs.$fstype -F $extra_imagecmd /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.$fstype -d /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs'
| WARNING: Backtrace (BB generated script):
| #1: oe_mkext234fs, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 178
| openembedded#2: do_image_ext4, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 150
| #3: main, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 215
ERROR: Task (/buildarea1/test/yocto/poky/meta/recipes-graphics/images/core-image-weston.bb:do_image_ext4) failed with exit code '1'
Before the patch:
$ ls -a tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs/home/weston/
. .. .bashrc .profile
After the patch:
$ ls -a tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs/home/weston/
. ..
Signed-off-by: Mingli Yu <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Mar 16, 2024
Add --system parameter for useradd to avoid intruducing .bashrc
and .profile under home dir to fix the below error.
$ bitbake core-image-weston
| DEBUG: Executing python function set_image_size
| DEBUG: 352679.600000 = 271292 * 1.300000
| DEBUG: 455079.600000 = max(352679.600000, 65536)[352679.600000] + 102400
| DEBUG: 455080.000000 = int(455079.600000)
| DEBUG: 455080 = aligned(455080)
| DEBUG: returning 455080
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_tar
| tar: ./home/weston/.bashrc: Unknown file type; file ignored
| tar: ./home/weston/.profile: Unknown file type; file ignored
| tar: Exiting with failure status due to previous errors
| WARNING: /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897:150 exit 1 from '[ $? -eq 1 ]'
| WARNING: Backtrace (BB generated script):
#1: do_image_tar, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897, line 150
openembedded#2: main, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897, line 156
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing python function set_image_size
| DEBUG: 352679.600000 = 271292 * 1.300000
| DEBUG: 455079.600000 = max(352679.600000, 65536)[352679.600000] + 102400
| DEBUG: 455080.000000 = int(455079.600000)
| DEBUG: 455080 = aligned(455080)
| DEBUG: returning 455080
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_ext4
| DEBUG: Executing dd if=/dev/zero of=/buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.ext4 seek=455080 count=0 bs=1024
| 0+0 records in
| 0+0 records out
| 0 bytes copied, 0.00136946 s, 0.0 kB/s
| DEBUG: Actual Rootfs size: 268184 /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs
| DEBUG: Actual Partition size: 466001920
| DEBUG: Executing mkfs.ext4 -F -i 4096 /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.ext4 -d /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs
| mke2fs 1.47.0 (5-Feb-2023)
| Discarding device blocks: done
| Creating filesystem with 455080 1k blocks and 113792 inodes
| Filesystem UUID: 2031373e-63cd-4711-968b-4023ff7d6a90
| Superblock backups stored on blocks:
| 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
|
| Allocating group tables: done
| Writing inode tables: done
| Creating journal (8192 blocks): done
| Copying files into the device: __populate_fs: ignoring entry ".bashrc"
| .bashrc: File not found by ext2_lookup while looking up ".bashrc"
| mkfs.ext4: File not found by ext2_lookup while populating file system
| WARNING: /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895:178 exit 1 from 'mkfs.$fstype -F $extra_imagecmd /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.$fstype -d /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs'
| WARNING: Backtrace (BB generated script):
| #1: oe_mkext234fs, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 178
| openembedded#2: do_image_ext4, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 150
| #3: main, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 215
ERROR: Task (/buildarea1/test/yocto/poky/meta/recipes-graphics/images/core-image-weston.bb:do_image_ext4) failed with exit code '1'
Before the patch:
$ ls -a tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs/home/weston/
. .. .bashrc .profile
After the patch:
$ ls -a tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs/home/weston/
. ..
Signed-off-by: Mingli Yu <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jul 1, 2024
Integrating the following commit(s) to linux-yocto/6.6:
1/1 [
Author: Bruce Ashfield
Email: [email protected]
Subject: cpu/amd: inhibit SMP check for qemux86
Date: Fri, 28 Jun 2024 12:55:18 -0400
When booting with kvm enabled on a AMD host, the following
trace is thrown:
[ 0.084519] ------------[ cut here ]------------
[ 0.084519] WARNING: This combination of AMD processors is not suitable for SMP.
[ 0.084519] WARNING: CPU: 1 PID: 0 at /arch/x86/kernel/cpu/amd.c:341 init_amd+0xaee/0xbcc
[ 0.084519] Modules linked in:
[ 0.084519] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.32-yocto-standard #1
[ 0.084519] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
This warning is not valid in our configuration and is unnecesarily
causing issue with debug.
This has been know for some time (10+ years), but no acceptable
solutioon has been found upstream:
https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01428.html
https://lkml.org/lkml/2010/3/30/397
We have a configuration CONFIG_QEMUX86 that has been added for
situations like this. When that value is defined, we inhibit the
warning, but leave it as-is for other BSPs.
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jul 1, 2024
Integrating the following commit(s) to linux-yocto/6.6:
1/1 [
Author: Bruce Ashfield
Email: [email protected]
Subject: cpu/amd: inhibit SMP check for qemux86
Date: Fri, 28 Jun 2024 12:55:18 -0400
When booting with kvm enabled on a AMD host, the following
trace is thrown:
[ 0.084519] ------------[ cut here ]------------
[ 0.084519] WARNING: This combination of AMD processors is not suitable for SMP.
[ 0.084519] WARNING: CPU: 1 PID: 0 at /arch/x86/kernel/cpu/amd.c:341 init_amd+0xaee/0xbcc
[ 0.084519] Modules linked in:
[ 0.084519] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.32-yocto-standard #1
[ 0.084519] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
This warning is not valid in our configuration and is unnecesarily
causing issue with debug.
This has been know for some time (10+ years), but no acceptable
solutioon has been found upstream:
https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01428.html
https://lkml.org/lkml/2010/3/30/397
We have a configuration CONFIG_QEMUX86 that has been added for
situations like this. When that value is defined, we inhibit the
warning, but leave it as-is for other BSPs.
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jul 9, 2024
Integrating the following commit(s) to linux-yocto/6.6:
1/1 [
Author: Bruce Ashfield
Email: [email protected]
Subject: cpu/amd: inhibit SMP check for qemux86
Date: Fri, 28 Jun 2024 12:55:18 -0400
When booting with kvm enabled on a AMD host, the following
trace is thrown:
[ 0.084519] ------------[ cut here ]------------
[ 0.084519] WARNING: This combination of AMD processors is not suitable for SMP.
[ 0.084519] WARNING: CPU: 1 PID: 0 at /arch/x86/kernel/cpu/amd.c:341 init_amd+0xaee/0xbcc
[ 0.084519] Modules linked in:
[ 0.084519] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.32-yocto-standard #1
[ 0.084519] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
This warning is not valid in our configuration and is unnecesarily
causing issue with debug.
This has been know for some time (10+ years), but no acceptable
solutioon has been found upstream:
https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01428.html
https://lkml.org/lkml/2010/3/30/397
We have a configuration CONFIG_QEMUX86 that has been added for
situations like this. When that value is defined, we inhibit the
warning, but leave it as-is for other BSPs.
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
(cherry picked from commit f0c0300)
Signed-off-by: Steve Sakoman <[email protected]>
kraj
added a commit
that referenced
this pull request
Aug 25, 2024
Fixes ERROR: systemd-1_256.5-r0 do_patch: QA Issue: Fuzz detected: Applying patch 0017-missing_syscall.h-Define-MIPS-ABI-defines-for-musl.patch patching file src/basic/missing_syscall.h Hunk #1 succeeded at 20 with fuzz 1. The issue surfaces when building with musl Signed-off-by: Khem Raj <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Sep 7, 2024
In systemd/systemd@924453c ProtectHome was set to true for systemd-coredump in order to reduce risk, since an attacker could craft a malicious binary in order to compromise systemd-coredump. At that point the object analysis was done in the main systemd-coredump process. Because of this systemd-coredump is unable to product symbolicated call-stacks for binaries running under /home ("n/a" is shown instead of function names). However, later in systemd/systemd@61aea45 systemd-coredump was changed to do the object analysis in a forked process, covering those security concerns. Let's set ProtectHome to read-only so that systemd-coredump produces symbolicated call-stacks for processes running under /home. Note: it still does not work in /tmp (because of PrivateTmp=yes) and in /root (for unknown reasons). Before the change (with minidebuginfo enabled): root@qemux86-64:~# /home/sleep 1000 & [1] 426 root@qemux86-64:~# kill -11 $(pidof sleep) root@qemux86-64:~# coredumpctl info PID: 426 (sleep) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Fri 2024-09-06 17:25:18 UTC (3s ago) Command Line: /home/sleep 1000 Executable: /home/sleep Control Group: /system.slice/system-serial\x2dgetty.slice/[email protected] Unit: [email protected] Slice: system-serial\x2dgetty.slice Boot ID: 44ef4ddfaad249ceaa29d1e9f330d3b5 Machine ID: fb279f18f2c849c59768754c7a274ee3 Hostname: qemux86-64 Storage: /var/lib/systemd/coredump/core.sleep.0.44ef4ddfaad249ceaa29d1e9f330d3b5.426.1725643518000000.zst (present) Size on Disk: 16.5K Message: Process 426 (sleep) of user 0 dumped core. Stack trace of thread 426: #0 0x00007f365f3849a7 clock_nanosleep (libc.so.6 + 0xd49a7) #1 0x00007f365f38f667 __nanosleep (libc.so.6 + 0xdf667) openembedded#2 0x0000561fee703737 n/a (/home/sleep + 0x7737) #3 0x000000003a6227c5 n/a (n/a + 0x0) ELF object binary architecture: AMD x86-64 [1]+ Segmentation fault (core dumped) /home/sleep 1000 After the change (with minidebuginfo enabled): root@qemux86-64:~# /home/sleep 1000 & [1] 450 root@qemux86-64:~# kill -11 $(pidof sleep) root@qemux86-64:~# coredumpctl info PID: 450 (sleep) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Fri 2024-09-06 17:30:12 UTC (4s ago) Command Line: /home/sleep 1000 Executable: /home/sleep Control Group: /system.slice/system-serial\x2dgetty.slice/[email protected] Unit: [email protected] Slice: system-serial\x2dgetty.slice Boot ID: 44ef4ddfaad249ceaa29d1e9f330d3b5 Machine ID: fb279f18f2c849c59768754c7a274ee3 Hostname: qemux86-64 Storage: /var/lib/systemd/coredump/core.sleep.0.44ef4ddfaad249ceaa29d1e9f330d3b5.450.1725643812000000.zst (present) Size on Disk: 16.5K Message: Process 450 (sleep) of user 0 dumped core. Stack trace of thread 450: #0 0x00007f795dd689a7 clock_nanosleep (libc.so.6 + 0xd49a7) #1 0x00007f795dd73667 __nanosleep (libc.so.6 + 0xdf667) openembedded#2 0x0000561965c9d737 rpl_nanosleep (sleep + 0x7737) #3 0x0000561965c9d0c1 xnanosleep (sleep + 0x70c1) #4 0x0000561965c985c8 main (sleep + 0x25c8) openembedded#5 0x00007f795dcba01b __libc_start_call_main (libc.so.6 + 0x2601b) openembedded#6 0x00007f795dcba0d9 __libc_start_main (libc.so.6 + 0x260d9) #7 0x0000561965c98685 _start (sleep + 0x2685) ELF object binary architecture: AMD x86-64 [1]+ Segmentation fault (core dumped) /home/sleep 1000 Signed-off-by: Etienne Cordonnier <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Sep 9, 2024
In systemd/systemd@924453c ProtectHome was set to true for systemd-coredump in order to reduce risk, since an attacker could craft a malicious binary in order to compromise systemd-coredump. At that point the object analysis was done in the main systemd-coredump process. Because of this systemd-coredump is unable to product symbolicated call-stacks for binaries running under /home ("n/a" is shown instead of function names). However, later in systemd/systemd@61aea45 systemd-coredump was changed to do the object analysis in a forked process, covering those security concerns. Let's set ProtectHome to read-only so that systemd-coredump produces symbolicated call-stacks for processes running under /home. Note: it still does not work in /tmp (because of PrivateTmp=yes) and in /root (for unknown reasons). Before the change (with minidebuginfo enabled): root@qemux86-64:~# /home/sleep 1000 & [1] 426 root@qemux86-64:~# kill -11 $(pidof sleep) root@qemux86-64:~# coredumpctl info PID: 426 (sleep) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Fri 2024-09-06 17:25:18 UTC (3s ago) Command Line: /home/sleep 1000 Executable: /home/sleep Control Group: /system.slice/system-serial\x2dgetty.slice/[email protected] Unit: [email protected] Slice: system-serial\x2dgetty.slice Boot ID: 44ef4ddfaad249ceaa29d1e9f330d3b5 Machine ID: fb279f18f2c849c59768754c7a274ee3 Hostname: qemux86-64 Storage: /var/lib/systemd/coredump/core.sleep.0.44ef4ddfaad249ceaa29d1e9f330d3b5.426.1725643518000000.zst (present) Size on Disk: 16.5K Message: Process 426 (sleep) of user 0 dumped core. Stack trace of thread 426: #0 0x00007f365f3849a7 clock_nanosleep (libc.so.6 + 0xd49a7) #1 0x00007f365f38f667 __nanosleep (libc.so.6 + 0xdf667) openembedded#2 0x0000561fee703737 n/a (/home/sleep + 0x7737) #3 0x000000003a6227c5 n/a (n/a + 0x0) ELF object binary architecture: AMD x86-64 [1]+ Segmentation fault (core dumped) /home/sleep 1000 After the change (with minidebuginfo enabled): root@qemux86-64:~# /home/sleep 1000 & [1] 450 root@qemux86-64:~# kill -11 $(pidof sleep) root@qemux86-64:~# coredumpctl info PID: 450 (sleep) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Fri 2024-09-06 17:30:12 UTC (4s ago) Command Line: /home/sleep 1000 Executable: /home/sleep Control Group: /system.slice/system-serial\x2dgetty.slice/[email protected] Unit: [email protected] Slice: system-serial\x2dgetty.slice Boot ID: 44ef4ddfaad249ceaa29d1e9f330d3b5 Machine ID: fb279f18f2c849c59768754c7a274ee3 Hostname: qemux86-64 Storage: /var/lib/systemd/coredump/core.sleep.0.44ef4ddfaad249ceaa29d1e9f330d3b5.450.1725643812000000.zst (present) Size on Disk: 16.5K Message: Process 450 (sleep) of user 0 dumped core. Stack trace of thread 450: #0 0x00007f795dd689a7 clock_nanosleep (libc.so.6 + 0xd49a7) #1 0x00007f795dd73667 __nanosleep (libc.so.6 + 0xdf667) openembedded#2 0x0000561965c9d737 rpl_nanosleep (sleep + 0x7737) #3 0x0000561965c9d0c1 xnanosleep (sleep + 0x70c1) #4 0x0000561965c985c8 main (sleep + 0x25c8) openembedded#5 0x00007f795dcba01b __libc_start_call_main (libc.so.6 + 0x2601b) openembedded#6 0x00007f795dcba0d9 __libc_start_main (libc.so.6 + 0x260d9) #7 0x0000561965c98685 _start (sleep + 0x2685) ELF object binary architecture: AMD x86-64 [1]+ Segmentation fault (core dumped) /home/sleep 1000 Signed-off-by: Etienne Cordonnier <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Oct 10, 2024
Fixed:
1) $ bitbake virtual/kernel -cmenuconfig
Do some changes and save the new config to default .config.
2) $ bitbake virtual/kernel -cdiffconfig
The config fragment is dumped into ${WORKDIR}/fragment.cfg.
But the .config which was saved by step #1 is overridden by .config.orig, so
the changes will be lost if run 'bitbake virtual/kernel'
And the following comment is for subprocess.call(), not for shutil.copy(),
so move subprocess.call() to the correct location.
# No need to check the exit code as we know it's going to be
# non-zero, but that's what we expect.
Signed-off-by: Robert Yang <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Oct 11, 2024
Fixed:
1) $ bitbake virtual/kernel -cmenuconfig
Do some changes and save the new config to default .config.
2) $ bitbake virtual/kernel -cdiffconfig
The config fragment is dumped into ${WORKDIR}/fragment.cfg.
But the .config which was saved by step #1 is overridden by .config.orig, so
the changes will be lost if run 'bitbake virtual/kernel'
And the following comment is for subprocess.call(), not for shutil.copy(),
so move subprocess.call() to the correct location.
# No need to check the exit code as we know it's going to be
# non-zero, but that's what we expect.
Signed-off-by: Robert Yang <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Nov 26, 2024
Fixed:
1) $ bitbake virtual/kernel -cmenuconfig
Do some changes and save the new config to default .config.
2) $ bitbake virtual/kernel -cdiffconfig
The config fragment is dumped into ${WORKDIR}/fragment.cfg.
But the .config which was saved by step #1 is overridden by .config.orig, so
the changes will be lost if run 'bitbake virtual/kernel'
And the following comment is for subprocess.call(), not for shutil.copy(),
so move subprocess.call() to the correct location.
# No need to check the exit code as we know it's going to be
# non-zero, but that's what we expect.
Signed-off-by: Robert Yang <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
(cherry picked from commit 6cccf6b)
Signed-off-by: Steve Sakoman <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Nov 26, 2024
Fixed:
1) $ bitbake virtual/kernel -cmenuconfig
Do some changes and save the new config to default .config.
2) $ bitbake virtual/kernel -cdiffconfig
The config fragment is dumped into ${WORKDIR}/fragment.cfg.
But the .config which was saved by step #1 is overridden by .config.orig, so
the changes will be lost if run 'bitbake virtual/kernel'
And the following comment is for subprocess.call(), not for shutil.copy(),
so move subprocess.call() to the correct location.
# No need to check the exit code as we know it's going to be
# non-zero, but that's what we expect.
Signed-off-by: Robert Yang <[email protected]>
Signed-off-by: Richard Purdie <[email protected]>
(cherry picked from commit 6cccf6b)
Signed-off-by: Steve Sakoman <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Feb 3, 2025
With current master branch I see an error in do_install: | DEBUG: Executing shell function do_install | install: omitting directory '/home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/misc/xorg-minimal-fonts-1.0-build' | WARNING: /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196:151 exit 1 from 'install -m 0644 /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/misc/* /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/image//usr/share/fonts/X11/misc/' | WARNING: Backtrace (BB generated script): | #1: do_install, /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196, line 151 | openembedded#2: main, /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196, line 159 ERROR: Task (/home/flk/poky/meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb:do_install) failed with exit code '1' Fix the problem by specifying more precisely what is to be installed Signed-off-by: Markus Volk <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Feb 4, 2025
With current master branch I see an error in do_install: | DEBUG: Executing shell function do_install | install: omitting directory '/home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/misc/xorg-minimal-fonts-1.0-build' | WARNING: /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196:151 exit 1 from 'install -m 0644 /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/misc/* /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/image//usr/share/fonts/X11/misc/' | WARNING: Backtrace (BB generated script): | #1: do_install, /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196, line 151 | openembedded#2: main, /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196, line 159 ERROR: Task (/home/flk/poky/meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb:do_install) failed with exit code '1' Fix the problem by specifying more precisely what is to be installed Signed-off-by: Markus Volk <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Feb 5, 2025
With current master branch I see an error in do_install: | DEBUG: Executing shell function do_install | install: omitting directory '/home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/misc/xorg-minimal-fonts-1.0-build' | WARNING: /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196:151 exit 1 from 'install -m 0644 /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/misc/* /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/image//usr/share/fonts/X11/misc/' | WARNING: Backtrace (BB generated script): | #1: do_install, /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196, line 151 | openembedded#2: main, /home/flk/poky/build/tmp/work/all-poky-linux/xorg-minimal-fonts/1.0/temp/run.do_install.112196, line 159 ERROR: Task (/home/flk/poky/meta/recipes-graphics/xorg-font/xorg-minimal-fonts.bb:do_install) failed with exit code '1' Fix the problem by specifying more precisely what is to be installed Signed-off-by: Markus Volk <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Feb 6, 2025
When building an image with IMAGE_INSTALL:append = ' rust libstd-rs', a conflict arises due to multiple candidates for the rlib dependency `std`. This results in the following error: error[E0464]: multiple candidates for `rlib` dependency `std` found | = note: candidate #1: /usr/lib/rustlib/x86_64-poky-linux-gnu/lib/libstd-20c3de2d9292cd03.rlib = note: candidate openembedded#2: /usr/lib/rustlib/x86_64-poky-linux-gnu/lib/libstd.so The issue seems to be from an extra copy of the rlib as both the recipes generate the same rlibs, causing conflicts when using std lib to compile rust programs in the image. Remove the redundant rlib copy ensuring only the necessary rlib is present and prevent the conflict. Signed-off-by: Yash Shinde <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Feb 9, 2025
License-Update: Update copyright year, attribution bounds The project has changed to using a pyproject.toml with hatchling as the build backend, so change the recipe to match. Changelog (https://github.com/justinmayer/typogrify/releases/tag/2.1.0): - Add ability to select which filters are applied (#1 by davidlesieur & barrysteyn) - jinja_filters: Update import for Jinja 3.1 (by jyelloz) - Ensure all available tests are run (by mcepl) - Package via pyproject instead of Setuptools (by justinmayer) - Improve testing, linting, and CI tooling - Drop support for Python < 3.9 Signed-off-by: Trevor Gamblin <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Feb 9, 2025
License-Update: Update copyright year, attribution bounds The project has changed to using a pyproject.toml with hatchling as the build backend, so change the recipe to match. Changelog (https://github.com/justinmayer/typogrify/releases/tag/2.1.0): - Add ability to select which filters are applied (#1 by davidlesieur & barrysteyn) - jinja_filters: Update import for Jinja 3.1 (by jyelloz) - Ensure all available tests are run (by mcepl) - Package via pyproject instead of Setuptools (by justinmayer) - Improve testing, linting, and CI tooling - Drop support for Python < 3.9 Signed-off-by: Trevor Gamblin <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Feb 10, 2025
License-Update: Update copyright year, attribution bounds The project has changed to using a pyproject.toml with hatchling as the build backend, so change the recipe to match. Changelog (https://github.com/justinmayer/typogrify/releases/tag/2.1.0): - Add ability to select which filters are applied (#1 by davidlesieur & barrysteyn) - jinja_filters: Update import for Jinja 3.1 (by jyelloz) - Ensure all available tests are run (by mcepl) - Package via pyproject instead of Setuptools (by justinmayer) - Improve testing, linting, and CI tooling - Drop support for Python < 3.9 Signed-off-by: Trevor Gamblin <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Feb 10, 2025
License-Update: Update copyright year, attribution bounds The project has changed to using a pyproject.toml with hatchling as the build backend, so change the recipe to match. Changelog (https://github.com/justinmayer/typogrify/releases/tag/2.1.0): - Add ability to select which filters are applied (#1 by davidlesieur & barrysteyn) - jinja_filters: Update import for Jinja 3.1 (by jyelloz) - Ensure all available tests are run (by mcepl) - Package via pyproject instead of Setuptools (by justinmayer) - Improve testing, linting, and CI tooling - Drop support for Python < 3.9 Signed-off-by: Trevor Gamblin <[email protected]> Signed-off-by: Richard Purdie <[email protected]>
kraj
pushed a commit
that referenced
this pull request
Jun 12, 2025
Calling oe-debuginfod in a build failed: ... $ oe-debuginfod |Getting sysroot... |Error: NOTE: Reconnecting to bitbake server... |NOTE: Retrying server connection (#1)... (18:55:53.009687) |path-to-build/tmp/work/x86_64-linux/elfutils-native/0.192/recipe-sysroot-native doesn't exist. |Have you run 'bitbake elfutils-native -caddto_recipe_sysroot'? ... While calling bitbake-getvar to get sysroot, the output of bitbake-getvar was mixed with output from bitbake ... NOTE: Reconnecting to bitbake server... ... Improve the output of bitbake-getvar, filter out unrelated message BTW: bitbake-getvar --quiet (Silence bitbake server logging) could not skip above "NOTE: Reconnecting to bitbake server..." message from bitbake Signed-off-by: Hongxu Jia <[email protected]> Signed-off-by: Mathieu Dubois-Briand <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[Khem Raj]
defaults for gcc is to use -fno-common this ensures that it keeps
building with gcc -fno-common
Fixes
src/arm/Ginit.c:60: multiple definition of `_U_dyn_info_list'; mi/.libs/dyn-info-list.o:/usr/src/debug/libunwind/1.4.0-r0/build/src/../../libunwind-1.4.0/src/mi/dyn-info-list.c:28: first defined here
[Philippe Coval]
Change and related patch ported to dunfell branch on 1.3.1 version
Signed-off-by: Khem Raj [email protected]
Signed-off-by: Richard Purdie [email protected]
Origin: openembedded@6cd2cf6
Relate-to: libunwind/libunwind#312
Relate-to: https://booting.oniroproject.org/distro/oniro/-/issues/191
Change-Id: If34ea06e365f57b6007e9ea3da8d9d716e4b01cc
Forwarded: https://lists.openembedded.org/g/openembedded-core/message/158932
Last-Update: 2021-11-25
Relate-to: astarte-platform/astarte-device-sdk-rust#20
Signed-off-by: Philippe Coval [email protected]