From yuxiaozhang at google.com Wed Mar 1 00:03:18 2023 From: yuxiaozhang at google.com (Yuxiao Zhang) Date: Tue, 28 Feb 2023 16:03:18 -0800 Subject: dhcp6 client patch upstream Message-ID: Hello busybox team, I have a simple patch related to dhcpv6 fqdn option. The context is that according to RFC4704, the server should send fqdn in dns encoding format. But some servers are still using plain text format. The patch is to workaround this issue. Basically the patch will check the first data byte, if it is greater than 63, which means that it is impossible to be a dns encoding format. In this case it will parse the fqdn part as plain text. Attached is the patch, let me know if the patch is acceptable. Also since this is my first time upstreaming a patch to busybox, feel free to suggest any additional process that I need to follow to make this work. Thanks, -Yuxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Work-around-broken-dhcp6-server-on-fqdn-option.patch Type: application/octet-stream Size: 1689 bytes Desc: not available URL: From p.faase1 at chello.nl Wed Mar 1 06:34:01 2023 From: p.faase1 at chello.nl (Peter Faasse) Date: Wed, 01 Mar 2023 07:34:01 +0100 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Message-ID: <2356446.UT8QKTmq2k@vullis> On dinsdag 28 februari 2023 23:17:19 CET ben.busybox at backplane.be wrote: > Hi, > > I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 > UTC)" (the one from the Docker image busybox:musl) when running on amd64 > GitHub actions runner VMs (azure). > > When I use sha256sum it is getting terminated with SIGILL, Illegal > instruction. The issue is hard to reproduce but I have a GitHub actions > CI/CD job that I can re-run repeatedly (no changes to code, environment, > data input, etc) that will occasionally have the issue. I managed to > capture a core dump. << snipped >>> > Any idea what's going on? Bad RAM? H/W (bus) problems?? This smells like hardware problems more than software :-/ As to analyzing: Is running 'it' with the debugger feasible? Or loading the core dump into the debugger... Then compare 'ok' with 'fail' (from core-dump) to see what / where the problem lurks. > Thanks, > Ben Kind regards, Peter -- The PGP PUBLIC KEY BLOCK below is my response to the traditional useless disclaimer found at the end of e-mails. This public PGP key is one member of a pair of public/private PGP keys that I have generated on my computer in less than a minute.. You could use this public PGP key to: - Verify that this message is the unchanged message as sent by me, using the digital signature of this e-mail and this public PGP key. My mail-program signs all sent e-mail using my private PGP key. - Encrypt any e-mail you send to me, so only I can decrypt it using my private PGP key. I prefer to receive so-encrypted e-mail; My mail program decrypts all e-mails that are encrypted using this public PGP key. You could do the same. If you have a public and private PGP key pair, please provide your public PGP key to me. - I will use it to check the integrity of e-mail received from you, if you sign your e-mail. - If you so prefer, I will use it to encrypt all my e-mail to you, so only you can decrypt and read e-mail sent from me to you. All e-mail programs support automatically and transparently performing the above-mentioned steps that implement these privacy-enhancing measures, using freely-available tools. -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFFgk6cBCACVLaCELJZMnbjcjmvnyI74YGVTs7iPchuFNIFLW7Y4UBxB8JFc sZOUT5LrJV9+ebCX2eVh1+n79Z4QuzRDTlsznToON6yA31jK3R057tJcmc4CVSjI 1+SpDRhDMsEPYId7IgGacezKuVPbbDqEVZZXkUj/7kyyaaWR1eNN4exJQ6DcVkfd 9c1Kv9blom3DbWeqkkTWqWxRT5bnFAVB8xLrFE2sA0D/cFejX/WxMmZXJEPhIZT9 eKqND7LMGQF/XwIzO11IsyB/7aFD2dfemgNiWf9rD7++knRjrCYPADB1cK6XbD8r rm6LYhK3PnkHfb8BG0mU78dB4LyOqE8UdFtHABEBAAG0LlBldGVyIEZhYXNzZSAo ZS1tYWlsIGtleSkgPHAuZmFhc2UxQGNoZWxsby5ubD6JATgEEwECACIFAlFgk6cC Gw8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGxmOUkWLm1ykfEH/A9sCA20 BcaMxXsdkKH78Y2yIwVkPCSpHHsnrYQUBOPqUF2i0iimEgol0NwN4BD4OOsuUmmG y2re9HzmIL+AwtqMg8JPw3Pw1d1+MzRldKm4f7cZMhi0p78xvi6bCaFNBAqJHD97 q70k3t46BlFQk2alMQKpLcB2xaWQuxn8rhr8HJMlpNbJ4Ifh9jNn/SeYvXyxbSrA qzUJ4r4cWLGJ6tdKzmiem3CV8hOU5CdtAfi/RhtwGTU27glNyVmkdpE1o9QYR1q3 P7TRavdtdCNX0sl7OlN5Go2O9jWt2igsiiyjS2KlytCVONRilH1FAMaXtcPs/KU9 tvOxHkbVz6bfXOg= =oiSn -----END PGP PUBLIC KEY BLOCK----- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From ben.busybox at backplane.be Wed Mar 1 07:29:50 2023 From: ben.busybox at backplane.be (ben.busybox at backplane.be) Date: Wed, 1 Mar 2023 08:29:50 +0100 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: <2356446.UT8QKTmq2k@vullis> References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> <2356446.UT8QKTmq2k@vullis> Message-ID: <99D97A48-6850-4EA5-BFD4-64EEED9671C2@backplane.be> Quick update: I've tried all these docker base images: busybox:1.3{4,5,6}-{musl,uclibc,glibc} and I can only reproduce the failure in 1.36 - but it does fail with all three stdlib variants. These docker images contain the core dump: ghcr.io/backplane/avxtest:1.36-glibc-1677653916 ghcr.io/backplane/avxtest:1.36-uclibc-1677653904 ghcr.io/backplane/avxtest:1.36-musl-1677653897 You can look at these images without downloading them by using https://explore.ggcr.dev/ Here are some direct links to browse the filesystem of in those images (and see the cores): https://explore.ggcr.dev/layers/ghcr.io/backplane/avxtest:1.36-glibc-1677653916 at sha256:16b6212308944e247fd275ed73cf57768fbd3f6442fd92e790755fd72bf6ca71/ https://explore.ggcr.dev/layers/ghcr.io/backplane/avxtest:1.36-uclibc-1677653904 at sha256:964053d7a517abb5214286fbf43849a795344ef2c136431ff1cfeafce5d76af6/ https://explore.ggcr.dev/layers/ghcr.io/backplane/avxtest:1.36-musl-1677653897 at sha256:53be164ff4070b4db5493c6d223dd9cfc872d6bfc712c8b6b4d4dd3fcc645b9f/ My dockerfile is now very simple: https://raw.githubusercontent.com/backplane/avxtest/main/Dockerfile The workflow is here: https://raw.githubusercontent.com/backplane/avxtest/main/.github/workflows/docker-publish.yml Peter - I have been able to get gdb going on the core file but I'm not experienced enough to be able to get much out of it when the binary is stripped and optimised like this. I can disassemble address ranges in the core dump with like "disassemble $fp-32, $fp+32" but I'm out of my depth. I'll look into getting a shell on the GitHub Actions runner to debug it in real time. > On 1 Mar 2023, at 7:34 AM, Peter Faasse wrote: > > On dinsdag 28 februari 2023 23:17:19 CET ben.busybox at backplane.be wrote: >> Hi, >> >> I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 >> UTC)" (the one from the Docker image busybox:musl) when running on amd64 >> GitHub actions runner VMs (azure). >> >> When I use sha256sum it is getting terminated with SIGILL, Illegal >> instruction. The issue is hard to reproduce but I have a GitHub actions >> CI/CD job that I can re-run repeatedly (no changes to code, environment, >> data input, etc) that will occasionally have the issue. I managed to >> capture a core dump. > > << snipped >>> >> Any idea what's going on? > > Bad RAM? H/W (bus) problems?? This smells like hardware problems more than > software :-/ > > As to analyzing: Is running 'it' with the debugger feasible? Or loading the > core dump into the debugger... Then compare 'ok' with 'fail' (from core-dump) > to see what / where the problem lurks. > >> Thanks, >> Ben > > Kind regards, > Peter > > -- > The PGP PUBLIC KEY BLOCK below is my response to the traditional useless > disclaimer found at the end of e-mails. > > This public PGP key is one member of a pair of public/private PGP keys > that I have generated on my computer in less than a minute.. > > You could use this public PGP key to: > > - Verify that this message is the unchanged message as sent by me, > using the digital signature of this e-mail and this public PGP key. > My mail-program signs all sent e-mail using my private PGP key. > - Encrypt any e-mail you send to me, so only I can decrypt it using my > private PGP key. I prefer to receive so-encrypted e-mail; My mail program > decrypts all e-mails that are encrypted using this public PGP key. > > You could do the same. If you have a public and private PGP key pair, > please provide your public PGP key to me. > > - I will use it to check the integrity of e-mail received from you, if you > sign your e-mail. > - If you so prefer, I will use it to encrypt all my e-mail to you, so only you > can decrypt and read e-mail sent from me to you. > > All e-mail programs support automatically and transparently performing > the above-mentioned steps that implement these privacy-enhancing > measures, using freely-available tools. > > -----BEGIN PGP PUBLIC KEY BLOCK----- > > mQENBFFgk6cBCACVLaCELJZMnbjcjmvnyI74YGVTs7iPchuFNIFLW7Y4UBxB8JFc > sZOUT5LrJV9+ebCX2eVh1+n79Z4QuzRDTlsznToON6yA31jK3R057tJcmc4CVSjI > 1+SpDRhDMsEPYId7IgGacezKuVPbbDqEVZZXkUj/7kyyaaWR1eNN4exJQ6DcVkfd > 9c1Kv9blom3DbWeqkkTWqWxRT5bnFAVB8xLrFE2sA0D/cFejX/WxMmZXJEPhIZT9 > eKqND7LMGQF/XwIzO11IsyB/7aFD2dfemgNiWf9rD7++knRjrCYPADB1cK6XbD8r > rm6LYhK3PnkHfb8BG0mU78dB4LyOqE8UdFtHABEBAAG0LlBldGVyIEZhYXNzZSAo > ZS1tYWlsIGtleSkgPHAuZmFhc2UxQGNoZWxsby5ubD6JATgEEwECACIFAlFgk6cC > Gw8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGxmOUkWLm1ykfEH/A9sCA20 > BcaMxXsdkKH78Y2yIwVkPCSpHHsnrYQUBOPqUF2i0iimEgol0NwN4BD4OOsuUmmG > y2re9HzmIL+AwtqMg8JPw3Pw1d1+MzRldKm4f7cZMhi0p78xvi6bCaFNBAqJHD97 > q70k3t46BlFQk2alMQKpLcB2xaWQuxn8rhr8HJMlpNbJ4Ifh9jNn/SeYvXyxbSrA > qzUJ4r4cWLGJ6tdKzmiem3CV8hOU5CdtAfi/RhtwGTU27glNyVmkdpE1o9QYR1q3 > P7TRavdtdCNX0sl7OlN5Go2O9jWt2igsiiyjS2KlytCVONRilH1FAMaXtcPs/KU9 > tvOxHkbVz6bfXOg= > =oiSn > -----END PGP PUBLIC KEY BLOCK----- > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox -------------- next part -------------- An HTML attachment was scrubbed... URL: From arsen at gentoo.org Wed Mar 1 09:28:23 2023 From: arsen at gentoo.org (Arsen =?utf-8?Q?Arsenovi=C4=87?=) Date: Wed, 01 Mar 2023 10:28:23 +0100 Subject: [PATCH] fixdep: avoid underflow when end of entry doesn't coincide with EOF In-Reply-To: References: <20230221192030.3729279-1-arsen@gentoo.org> Message-ID: <86ilfkq0qh.fsf@gentoo.org> Denys Vlasenko writes: > Applied, thank you. Thanks, have a lovely day. > On Tue, Feb 21, 2023 at 8:24 PM Arsen Arsenovi? wrote: >> >> Bug: https://bugs.gentoo.org/893776 >> Closes: https://bugs.busybox.net/show_bug.cgi?id=15326 >> Signed-off-by: Arsen Arsenovi? >> --- >> Hi, >> >> This is a fix for the recently reported scandep-related build failure. >> The linked Gentoo bug also includes a write-up explaining how the error >> happens. >> >> Thanks in advance, have a lovely day. >> >> scripts/basic/fixdep.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c >> index 426b4888b..66be73aad 100644 >> --- a/scripts/basic/fixdep.c >> +++ b/scripts/basic/fixdep.c >> @@ -338,6 +338,11 @@ void parse_dep_file(void *map, size_t len) >> do p--; while (!isalnum((unsigned char)*p)); >> p++; >> } >> + if (p < m) { >> + /* we've consumed the last filename of this list >> + already. */ >> + break; >> + } >> memcpy(s, m, p-m); s[p-m] = 0; >> if (strrcmp(s, "include/autoconf.h") && >> strrcmp(s, "arch/um/include/uml-config.h") && >> -- >> 2.39.2 >> >> _______________________________________________ >> busybox mailing list >> busybox at busybox.net >> http://lists.busybox.net/mailman/listinfo/busybox -- Arsen Arsenovi? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 381 bytes Desc: not available URL: From alice at ayaya.dev Wed Mar 1 10:55:16 2023 From: alice at ayaya.dev (alice) Date: Wed, 01 Mar 2023 11:55:16 +0100 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Message-ID: On Tue Feb 28, 2023 at 11:17 PM CET, wrote: > Hi, > > I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 > UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub > actions runner VMs (azure). > > When I use sha256sum it is getting terminated with SIGILL, Illegal > instruction. The issue is hard to reproduce but I have a GitHub actions CI/CD > job that I can re-run repeatedly (no changes to code, environment, data input, > etc) that will occasionally have the issue. I managed to capture a core dump. this was also reported in http://lists.busybox.net/pipermail/busybox/2023-January/090113.html it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, and the code that checks it is broken and misdetects sha_ni support when avx512 exists. the github runners don't have sha_ni, so it breaks exactly there. quite the rare combo :) i feel this was reported before, but apparently not outside an irc channel.. From ben.busybox at backplane.be Wed Mar 1 11:46:03 2023 From: ben.busybox at backplane.be (ben.busybox at backplane.be) Date: Wed, 1 Mar 2023 12:46:03 +0100 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Message-ID: <1DA56BFB-3F61-4F2C-96D0-0A0B882E0BB9@backplane.be> On 1 Mar 2023, at 11:55 AM, alice wrote: > > On Tue Feb 28, 2023 at 11:17 PM CET, wrote: >> Hi, >> >> I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 >> UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub >> actions runner VMs (azure). >> > > this was also reported in http://lists.busybox.net/pipermail/busybox/2023-January/090113.html > > it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, > and the code that checks it is broken and misdetects sha_ni support when avx512 > exists. the github runners don't have sha_ni, so it breaks exactly there. > > quite the rare combo :) > > i feel this was reported before, but apparently not outside an irc channel.. Thank you! (And sorry I didn't find that myself. I swear I searched.) From ncopa at alpinelinux.org Wed Mar 1 11:53:25 2023 From: ncopa at alpinelinux.org (Natanael Copa) Date: Wed, 1 Mar 2023 12:53:25 +0100 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Message-ID: <20230301125325.0e363e94@ncopa-desktop.lan> Hi, On Wed, 01 Mar 2023 11:55:16 +0100 "alice" wrote: > On Tue Feb 28, 2023 at 11:17 PM CET, wrote: > > Hi, > > > > I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 > > UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub > > actions runner VMs (azure). > > > > When I use sha256sum it is getting terminated with SIGILL, Illegal > > instruction. The issue is hard to reproduce but I have a GitHub actions CI/CD > > job that I can re-run repeatedly (no changes to code, environment, data input, > > etc) that will occasionally have the issue. I managed to capture a core dump. > > this was also reported in http://lists.busybox.net/pipermail/busybox/2023-January/090113.html > > it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, > and the code that checks it is broken and misdetects sha_ni support when avx512 > exists. the github runners don't have sha_ni, so it breaks exactly there. > > quite the rare combo :) > > i feel this was reported before, but apparently not outside an irc channel.. I did try to create a fix for it: https://github.com/ncopa/busybox/commit/e4ad5e7f2fed8e36d0779d918052169fe9a0bb95 But it didn't work. I was unable to create a proper core dump and sort of gave up. In Alpine we have simply disabled the HWACCEL as it is broken. Thanks! -nc From ben.busybox at backplane.be Wed Mar 1 12:00:58 2023 From: ben.busybox at backplane.be (ben.busybox at backplane.be) Date: Wed, 1 Mar 2023 13:00:58 +0100 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: <20230301125325.0e363e94@ncopa-desktop.lan> References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> <20230301125325.0e363e94@ncopa-desktop.lan> Message-ID: <3B7F3D48-B4B2-47BB-85CD-0D3B91DD566A@backplane.be> On 1 Mar 2023, at 12:53 PM, Natanael Copa wrote: > Hi, > > On Wed, 01 Mar 2023 11:55:16 +0100 > "alice" wrote: > >> On Tue Feb 28, 2023 at 11:17 PM CET, wrote: >>> Hi, >>> >>> I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 >>> UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub >>> actions runner VMs (azure). >>> >>> When I use sha256sum it is getting terminated with SIGILL, Illegal >>> instruction. The issue is hard to reproduce but I have a GitHub actions CI/CD >>> job that I can re-run repeatedly (no changes to code, environment, data input, >>> etc) that will occasionally have the issue. I managed to capture a core dump. >> >> this was also reported in http://lists.busybox.net/pipermail/busybox/2023-January/090113.html >> >> it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, >> and the code that checks it is broken and misdetects sha_ni support when avx512 >> exists. the github runners don't have sha_ni, so it breaks exactly there. >> >> quite the rare combo :) >> >> i feel this was reported before, but apparently not outside an irc channel.. > > I did try to create a fix for it: > https://github.com/ncopa/busybox/commit/e4ad5e7f2fed8e36d0779d918052169fe9a0bb95 > > But it didn't work. I was unable to create a proper core dump and sort > of gave up. In Alpine we have simply disabled the HWACCEL as it is > broken. OK. I've got a bug report to docker library to also disable HWACCEL there until a detection fix can be integrated into the busybox codebase. https://github.com/docker-library/busybox/issues/166 From henrique at nic.br Wed Mar 1 18:15:28 2023 From: henrique at nic.br (Henrique de Moraes Holschuh) Date: Wed, 1 Mar 2023 15:15:28 -0300 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: <3B7F3D48-B4B2-47BB-85CD-0D3B91DD566A@backplane.be> References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> <20230301125325.0e363e94@ncopa-desktop.lan> <3B7F3D48-B4B2-47BB-85CD-0D3B91DD566A@backplane.be> Message-ID: There is some data in: https://www.intel.com/content/dam/develop/external/us/en/documents/intel-sha-extensions-white-paper.pdf page 13. If what the document above describes is what busybox is already doing on Intel, then it is time to find out the exact processor model that exposed the issue, hunt down its Specification Update documentation, and check for known errata, etc. Do note the 16-byte alignment requirement for all buffers involved. -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Opera??es (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br From soeren at soeren-tempel.net Fri Mar 3 16:00:17 2023 From: soeren at soeren-tempel.net (soeren at soeren-tempel.net) Date: Fri, 3 Mar 2023 17:00:17 +0100 Subject: [PATCH v2] umount: Implement -O option to unmount by mount options In-Reply-To: <20220619145223.11321-1-soeren@soeren-tempel.net> References: <20220619145223.11321-1-soeren@soeren-tempel.net> Message-ID: <20230303160016.4785-1-soeren@soeren-tempel.net> From: S?ren Tempel This commit adds an implementation of the umount -O option, as provided by util-linux's mount(8) implementation, to BusyBox. Similar to -t, the option is intended to be used in conjunction with -a thereby allowing users to filter which file systems are unmounted by mount options. Multiple options can be specified with -O, all of which need to match. Each option can be prefixed with `no` to indicate that no action should be taken for a mount point with this mount option. The "no" prefix interpretation can be disabled using the "+" prefix. At Alpine, this feature is often requested by users as the OpenRC netmount service uses `umount -a -O _netdev` to amount all network file systems [1] [2]. This implementation is functionally equivalent to the util-linux implementation with the exception that it implements no special handling for `key="value"` mount options to keep the implementation simple. Therefore, filesystems mounted with options like `foo="bar"` won't be matched by `umount -a -O foo`. [1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/9923 [2]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13789 Signed-off-by: S?ren Tempel --- Changes since v1: * Fix a typo during parsing of no keyword (n0 -> no) * Treat alone "no" as an error (as done in util-linux) * Implement support for the "+" prefix to bypass the "no" keyword This version of the patch has been tested against the util-linux implementation using KLEE: https://github.com/nmeum/umount-test-opts include/libbb.h | 1 + libbb/Kbuild.src | 1 + libbb/match_fsopts.c | 69 ++++++++++++++++++++++++++++++++++++++++++++ util-linux/umount.c | 10 +++++-- 4 files changed, 78 insertions(+), 3 deletions(-) create mode 100644 libbb/match_fsopts.c diff --git a/include/libbb.h b/include/libbb.h index cca33a177..ad41adec8 100644 --- a/include/libbb.h +++ b/include/libbb.h @@ -1586,6 +1586,7 @@ const struct hwtype *get_hwntype(int type) FAST_FUNC; extern int fstype_matches(const char *fstype, const char *comma_list) FAST_FUNC; +extern int fsopts_matches(const char *opts_list, const char *reqopts_list) FAST_FUNC; #ifdef HAVE_MNTENT_H extern struct mntent *find_mount_point(const char *name, int subdir_too) FAST_FUNC; #endif diff --git a/libbb/Kbuild.src b/libbb/Kbuild.src index 653025e56..4bb8260b9 100644 --- a/libbb/Kbuild.src +++ b/libbb/Kbuild.src @@ -120,6 +120,7 @@ lib-y += xrealloc_vector.o lib-$(CONFIG_MOUNT) += match_fstype.o lib-$(CONFIG_UMOUNT) += match_fstype.o +lib-$(CONFIG_UMOUNT) += match_fsopts.o lib-$(CONFIG_FEATURE_UTMP) += utmp.o diff --git a/libbb/match_fsopts.c b/libbb/match_fsopts.c new file mode 100644 index 000000000..b1cc85c3c --- /dev/null +++ b/libbb/match_fsopts.c @@ -0,0 +1,69 @@ +/* vi: set sw=4 ts=4: */ +/* + * Match fsopts for use in mount unmount -O. + * + * Returns 1 for a match, otherwise 0. + * + * Licensed under GPLv2 or later, see file LICENSE in this source tree. + */ + +#include "libbb.h" + +static int fsopt_matches(const char *opts_list, const char *opt, size_t optlen) +{ + int match = 1; + + if (optlen >= 2 && opt[0] == 'n' && opt[1] == 'o') { + match--; + opt += 2; optlen -= 2; + } + + /* The alone "no" is an error, all matching ends with False. */ + if (optlen == 0) + return 0; + + /* The "no" prefix interpretation can be disabled by the "+" prefix. */ + if (match && optlen > 1 && *opt == '+') { + opt++; optlen--; + } + + while (1) { + if (strncmp(opts_list, opt, optlen) == 0) { + const char *after_opt = opts_list + optlen; + if (*after_opt == '\0' || *after_opt == ',') + return match; + } + + opts_list = strchr(opts_list, ','); + if (!opts_list) + break; + opts_list++; + } + + return !match; +} + +/* This function implements the mnt_match_options function from libmount. */ +int FAST_FUNC fsopts_matches(const char *opts_list, const char *reqopts_list) +{ + if (!reqopts_list) + return 1; /* no options requested, match anything */ + + while (1) { + size_t len; + const char *comma = strchr(reqopts_list, ','); + if (!comma) + len = strlen(reqopts_list); + else + len = comma - reqopts_list; + + if (len && !fsopt_matches(opts_list, reqopts_list, len)) + return 0; + + if (!comma) + break; + reqopts_list = ++comma; + } + + return 1; +} diff --git a/util-linux/umount.c b/util-linux/umount.c index 23da32868..7a54cafb0 100644 --- a/util-linux/umount.c +++ b/util-linux/umount.c @@ -41,7 +41,7 @@ //kbuild:lib-$(CONFIG_UMOUNT) += umount.o //usage:#define umount_trivial_usage -//usage: "[-rlf"IF_FEATURE_MTAB_SUPPORT("m")IF_FEATURE_MOUNT_LOOP("d")IF_FEATURE_UMOUNT_ALL("a")"] [-t FSTYPE] FILESYSTEM|DIRECTORY" +//usage: "[-rlf"IF_FEATURE_MTAB_SUPPORT("m")IF_FEATURE_MOUNT_LOOP("d")IF_FEATURE_UMOUNT_ALL("a")"] [-t FSTYPE] [-O FSOPT] FILESYSTEM|DIRECTORY" //usage:#define umount_full_usage "\n\n" //usage: "Unmount filesystems\n" //usage: IF_FEATURE_UMOUNT_ALL( @@ -57,6 +57,7 @@ //usage: "\n -d Free loop device if it has been used" //usage: ) //usage: "\n -t FSTYPE[,...] Unmount only these filesystem type(s)" +//usage: "\n -O FSOPT[,...] Unmount only filesystem mounted with the given options" //usage: //usage:#define umount_example_usage //usage: "$ umount /dev/hdc1\n" @@ -82,7 +83,7 @@ static struct mntent *getmntent_r(FILE* stream, struct mntent* result, #endif /* ignored: -c -v -i */ -#define OPTION_STRING "fldnrat:" "cvi" +#define OPTION_STRING "fldnrat:O:" "cvi" #define OPT_FORCE (1 << 0) // Same as MNT_FORCE #define OPT_LAZY (1 << 1) // Same as MNT_DETACH #define OPT_FREELOOP (1 << 2) @@ -96,6 +97,7 @@ int umount_main(int argc UNUSED_PARAM, char **argv) int doForce; struct mntent me; FILE *fp; + char *opts = NULL; char *fstype = NULL; int status = EXIT_SUCCESS; unsigned opt; @@ -105,7 +107,7 @@ int umount_main(int argc UNUSED_PARAM, char **argv) struct mtab_list *next; } *mtl, *m; - opt = getopt32(argv, OPTION_STRING, &fstype); + opt = getopt32(argv, OPTION_STRING, &fstype, &opts); //argc -= optind; argv += optind; @@ -133,6 +135,8 @@ int umount_main(int argc UNUSED_PARAM, char **argv) /* Match fstype (fstype==NULL matches always) */ if (!fstype_matches(me.mnt_type, fstype)) continue; + if (!fsopts_matches(me.mnt_opts, opts)) + continue; m = xzalloc(sizeof(*m)); m->next = mtl; m->device = xstrdup(me.mnt_fsname); From patrick at phiz.us Sat Mar 4 08:12:41 2023 From: patrick at phiz.us (Patrick Garrett) Date: Sat, 4 Mar 2023 00:12:41 -0800 Subject: Busybox & SELinux References: <17E2CCFE-B891-400C-B6BA-6CF9BB4941E2@phiz.us> Message-ID: <536D2205-5274-4B34-87D8-9BEFA52ACFF5@phiz.us> ?I am building openWRT and busybox on SELinux. When I compile and install with SELinux I receive the error logging in to the serial console ?login: can?t get SID for root?. If I compile without SELinux enabled it works fine. Any help or direction is appreciated. Thanks in advance. Sent from my iPhone From yszhou4tech at gmail.com Sun Mar 5 01:38:17 2023 From: yszhou4tech at gmail.com (Yousong Zhou) Date: Sun, 5 Mar 2023 09:38:17 +0800 Subject: [PATCH] libiproute: fix filtering ip6 route by table id In-Reply-To: References: <20230212043020.861-1-yszhou4tech@gmail.com> Message-ID: > > The very same code exists in current iproute2 git tree. > > Is it also buggy in the same way? > > Hi Denys > > I checked before and iproute2 works just fine. The code is a bit different: Friendly ping. Regards, yousong > > > > > iproute.c > > static int filter_nlmsg(struct nlmsghdr *n, struct rtattr **tb, int host_len) > > { > > struct rtmsg *r = NLMSG_DATA(n); > > inet_prefix dst = { .family = r->rtm_family }; > > inet_prefix src = { .family = r->rtm_family }; > > inet_prefix via = { .family = r->rtm_family }; > > inet_prefix prefsrc = { .family = r->rtm_family }; > > __u32 table; > > static int ip6_multiple_tables; > > > > table = rtm_get_table(r, tb); > > > > if (preferred_family != AF_UNSPEC && r->rtm_family != preferred_family) > > return 0; > > > > if (r->rtm_family == AF_INET6 && table != RT_TABLE_MAIN) > > ip6_multiple_tables = 1; > > It sets ip6_multiple_tables here. > > > > > if (filter.cloned == !(r->rtm_flags & RTM_F_CLONED)) > > return 0; > > > > if (r->rtm_family == AF_INET6 && !ip6_multiple_tables) { > > So it won't go into this branch > > > if (filter.tb) { > > if (filter.tb == RT_TABLE_LOCAL) { > > if (r->rtm_type != RTN_LOCAL) > > return 0; > > } else if (filter.tb == RT_TABLE_MAIN) { > > if (r->rtm_type == RTN_LOCAL) > > return 0; > > } else { > > return 0; > > } > > } > > } else { > > if (filter.tb > 0 && filter.tb != table) > > return 0; > > The check happens here. > > Regards, > yousong > > > } From andreas.mahling at googlemail.com Tue Mar 7 18:53:31 2023 From: andreas.mahling at googlemail.com (Andreas Mahling) Date: Tue, 7 Mar 2023 19:53:31 +0100 Subject: httpd should accept trailing slash after PATH_INFO Message-ID: hello, I stumbled upon a problem with the CGI-enabled httpd. It seems that httpd can't handle a CGI call with an appended PATH_INFO, if the latter ends with a slash. httpd takes this as a call for a directory listing and throws 404. For further details you may take a look here: https://lists.zx2c4.com/pipermail/cgit/2023-March/004825.html I've attached a patch, which works for me, although my understanding of the httpd.c code is only superficial. Patch was generated by diff -u networking/httpd.c networking/httpd.c.new >httpd.patch against the busybox-1.34.1 tarball Thanks a lot to the busybox developers for their outstanding work. best regards Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: httpd.patch Type: text/x-patch Size: 703 bytes Desc: not available URL: From andreas.mahling at googlemail.com Tue Mar 7 19:08:10 2023 From: andreas.mahling at googlemail.com (Andreas Mahling) Date: Tue, 7 Mar 2023 20:08:10 +0100 Subject: [PATCH] httpd should accept trailing slash after PATH_INFO Message-ID: sorry, it seems I didn't follow the usual path for submitting a patch, so here I go again: I stumbled upon a problem with the CGI-enabled httpd. It seems that httpd can't handle a CGI call with an appended PATH_INFO, if the latter ends with a slash. httpd takes this as a call for a directory listing and throws 404. For further details you may take a look here: https://lists.zx2c4.com/pipermail/cgit/2023-March/004825.html I've attached a patch, which works for me, although my understanding of the httpd.c code is only superficial. Patch was generated by diff -u networking/httpd.c networking/httpd.c.new >httpd.patch against the busybox-1.34.1 tarball Thanks a lot to the busybox developers for their outstanding work. best regards Andreas --- networking/httpd.c 2021-06-16 12:02:16.000000000 +0200 +++ networking/httpd.c.new 2023-03-07 19:05:22.447075000 +0100 @@ -2426,11 +2426,14 @@ } #if ENABLE_FEATURE_HTTPD_CGI else if (urlp[-1] == '/') { - /* It's a dir URL and there is no index.html */ - /* Is there cgi-bin/index.cgi? */ - if (access("/cgi-bin/index.cgi"+1, X_OK) != 0) - send_headers_and_exit(HTTP_NOT_FOUND); /* no */ - cgi_type = CGI_INDEX; + if (cgi_type == CGI_NONE) { + /* It's a dir URL and there is no index.html */ + /* Is there cgi-bin/index.cgi? */ + if (access("/cgi-bin/index.cgi"+1, X_OK) != 0) { + send_headers_and_exit(HTTP_NOT_FOUND); /* no */ + } + cgi_type = CGI_INDEX; + } } #endif From ksperling at apple.com Wed Mar 8 03:23:32 2023 From: ksperling at apple.com (Karsten Sperling) Date: Wed, 08 Mar 2023 16:23:32 +1300 Subject: ash: another use-after-free in bash pattern substitution Message-ID: <7EEDF173-AADF-4A36-ABE2-7E3810EAAFCD@apple.com> Hi, This is a fix for a use-after-free issue in the bash pattern substitution code in ash (related to STPUTC potentially causing the buffer to be reallocated). Most of these were fixed in 1.36.0 however one unguarded STPUTC remained which is fixed in the attached patch. Thanks, Karsten -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-ash-another-uaf.patch Type: application/octet-stream Size: 397 bytes Desc: not available URL: From lkml at jv-coder.de Wed Mar 8 07:19:35 2023 From: lkml at jv-coder.de (Joerg Vehlow) Date: Wed, 8 Mar 2023 08:19:35 +0100 Subject: Busybox & SELinux In-Reply-To: <536D2205-5274-4B34-87D8-9BEFA52ACFF5@phiz.us> References: <17E2CCFE-B891-400C-B6BA-6CF9BB4941E2@phiz.us> <536D2205-5274-4B34-87D8-9BEFA52ACFF5@phiz.us> Message-ID: <3be03085-a1b7-b95e-2316-7c459261e527@jv-coder.de> Hi Patrick, there is already a patch for this, sadly it (and my ping) is completely ignored by the maintainers. See: http://lists.busybox.net/pipermail/busybox/2020-January/087740.html Joerg Am 3/4/2023 um 9:12 AM schrieb Patrick Garrett: > ?I am building openWRT and busybox on SELinux. When I compile and install with SELinux I receive the error logging in to the serial console ?login: can?t get SID for root?. If I compile without SELinux enabled it works fine. > > Any help or direction is appreciated. Thanks in advance. > > Sent from my iPhone > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From andreas.mahling at googlemail.com Thu Mar 9 14:30:48 2023 From: andreas.mahling at googlemail.com (Andreas Mahling) Date: Thu, 9 Mar 2023 15:30:48 +0100 Subject: httpd privilege drop / supplementary groups Message-ID: hello, while working at a setup with httpd serving cgit, I noticed, that privilege dropping option -u xyz attaches only the primary group of user xyz to the process but not the supplementary groups. So httpd works different compared to be started by user xyz. I wonder whether there is interest for supporting supplementary groups. If so, I would try to develop a patch for that. The supplementary group feature could be triggerd by extending the commandline option, e.g with -u user:+ or -u user:group+. So it would be fully backward compatible. I'm looking forward to hear from you. Regards Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ksperling at apple.com Wed Mar 15 00:19:14 2023 From: ksperling at apple.com (Karsten Sperling) Date: Wed, 15 Mar 2023 13:19:14 +1300 Subject: [PATCH] ash: another use-after-free in bash pattern substitution In-Reply-To: <7EEDF173-AADF-4A36-ABE2-7E3810EAAFCD@apple.com> References: <7EEDF173-AADF-4A36-ABE2-7E3810EAAFCD@apple.com> Message-ID: <74D96B8E-C0A5-41E9-9008-1DF8CA3D0B07@apple.com> Re-sending this fix for a use-after-free in the bash pattern substitution code in ash, I?m not sure the mailing list software liked my original attachment. Thanks, Karsten -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: busybox-ash-another-uaf.patch.txt URL: -------------- next part -------------- > On 8/03/2023, at 4:23 PM, Karsten Sperling wrote: > > Hi, > > This is a fix for a use-after-free issue in the bash pattern substitution code in ash (related to STPUTC potentially causing the buffer to be reallocated). Most of these were fixed in 1.36.0 however one unguarded STPUTC remained which is fixed in the attached patch. > > Thanks, Karsten > > From isaac at is.having.coffee Thu Mar 16 14:54:17 2023 From: isaac at is.having.coffee (Isaac True) Date: Thu, 16 Mar 2023 14:54:17 +0000 Subject: [PATCH] mount: add feature to ignore flags starting with "x-" Message-ID: Some tools add non-standard mount flags beginning with "x-", which are commonly used for adding comments and metadata to mountpoints. These can be optionally safely ignored, as they don't affect the functionality of the mount and would otherwise cause Busybox to fail to mount the device. Some examples for such mount flags are "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. This patch does not change the current default behaviour; the mount flags will only be ignored if this feature is enabled. An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. Signed-off-by: Isaac True --- util-linux/mount.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) diff --git a/util-linux/mount.c b/util-linux/mount.c index 4e65b6b46..418aca171 100644 --- a/util-linux/mount.c +++ b/util-linux/mount.c @@ -107,6 +107,23 @@ //config: default y //config: help //config: Support mount -T (specifying an alternate fstab) +//config: +//config:config FEATURE_MOUNT_IGNORE_X_FLAGS +//config: depends on MOUNT +//config: bool "Ignore any mount flags starting with 'x-'" +//config: default n +//config: help +//config: Ignore any mount flags starting with 'x-', which are generally +//config: used for adding comments/metadata to mount points. Normally, +//config: the mount command would fail if one of these options is added. +//config: +//config:config FEATURE_MOUNT_IGNORE_X_FLAGS_VERBOSE +//config: depends on FEATURE_MOUNT_IGNORE_X_FLAGS +//config: bool "Report ignored mount flags" +//config: default y +//config: help +//config: If any mount flags starting with "x-" are being ignored, report +//config: them to the user. Otherwise, silently ignore them. /* On full-blown systems, requires suid for user mounts. * But it's not unthinkable to have it available in non-suid flavor on some systems, @@ -1964,6 +1981,73 @@ static unsigned long long cut_out_ull_opt(char *opts, const char *name_eq) } } +// Find any mount options beginning with "x-" and remove them. These are used +// to add metadata and comments to the mounts, which isn't currently supported +// by Busybox. +static void cut_out_x_opts(char *opts) +{ + const char *const x_opt = "x-"; + const size_t x_opt_len = strlen(x_opt); + char *opt = opts; + const char *const opts_end = opts + strlen(opts); + + if (!opts) + return; + + for (;;) { + if (strlen(opt) < x_opt_len) { + // Option string is too small to fit such an option + break; + } + + if (!strncmp(opt, x_opt, x_opt_len)) { + // Found a matching option. Now remove it + char *current_opt = NULL; + char *end = strstr(opt, ","); + + if (ENABLE_FEATURE_MOUNT_IGNORE_X_FLAGS_VERBOSE) { + // Make a copy for verbose reporting + current_opt = xstrdup(opt); + } + + if (end == NULL) { + // No comma found, this is the last/only flag. Null it out so + // that it's not parsed. + *opt = '\0'; + } else { + // There are more options; move them up to remove the current + // option + memmove(opt, end + 1, opts_end - end); + if (ENABLE_FEATURE_MOUNT_IGNORE_X_FLAGS_VERBOSE) { + // Null out where the next comma is to single out the + // current option for optional verbose reporting + current_opt[end - opt] = '\0'; + } + } + + if (ENABLE_FEATURE_MOUNT_IGNORE_X_FLAGS_VERBOSE) { + bb_perror_msg("ignoring unsupported option: %s", + current_opt); + free(current_opt); + } + + // The string has been modified; check this + // memory address for the target string again + continue; + } + + // Go to the next option + opt = strstr(opt, ","); + if (opt == NULL) { + // No more commas - we're at the last option + break; + } + + // Skip over the comma + opt++; + } +} + // Mount one directory. Handles CIFS, NFS, loopback, autobind, and filesystem // type detection. Returns 0 for success, nonzero for failure. // NB: mp->xxx fields may be trashed on exit @@ -1978,6 +2062,10 @@ static int singlemount(struct mntent *mp, int ignore_busy) errno = 0; + if (ENABLE_FEATURE_MOUNT_IGNORE_X_FLAGS) { + cut_out_x_opts(mp->mnt_opts); + } + vfsflags = parse_mount_options(mp->mnt_opts, &filteropts, NULL); // Treat fstype "auto" as unspecified -- 2.37.2 From service.iit at mayer-emi.at Fri Mar 17 20:27:20 2023 From: service.iit at mayer-emi.at (Service IIT (Mayer EMI)) Date: Fri, 17 Mar 2023 21:27:20 +0100 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" Message-ID: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> Hi Can somone help how to get rid of the message "Invalid ELF header magic: !=ELF" of busybox when using moprobe with compressed kernel modules BusyBox v1.36.0 (2023-03-17 16:25:58 UTC) multi-call binary. -M- From raj.khem at gmail.com Sat Mar 18 01:57:24 2023 From: raj.khem at gmail.com (Khem Raj) Date: Fri, 17 Mar 2023 18:57:24 -0700 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" In-Reply-To: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> References: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> Message-ID: On Fri, Mar 17, 2023 at 2:10?PM Service IIT (Mayer EMI) wrote: > > Hi > > Can somone help how to get rid of the message "Invalid ELF header magic: > !=ELF" of busybox when using moprobe with compressed kernel modules > Something is not in ELF format. Can you provide more details of what you are trying to do? > BusyBox v1.36.0 (2023-03-17 16:25:58 UTC) multi-call binary. > > -M- > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From service.iit at mayer-emi.at Sat Mar 18 09:40:31 2023 From: service.iit at mayer-emi.at (Service IIT (Mayer EMI)) Date: Sat, 18 Mar 2023 10:40:31 +0100 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" In-Reply-To: References: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> Message-ID: Am 18.03.2023 um 02:57 schrieb Khem Raj: > On Fri, Mar 17, 2023 at 2:10?PM Service IIT (Mayer EMI) > wrote: >> Hi >> >> Can somone help how to get rid of the message "Invalid ELF header magic: >> !=ELF" of busybox when using moprobe with compressed kernel modules >> > Something is not in ELF format. Can you provide more details of what > you are trying to do? Having compiled the kernel (6.1.19) with ????? Module compression mode (XZ)? ---> ????? [*]?? Support in-kernel module decompression Having compiled busybox with ??? Archival Utilities? ---> ?????? [*] Make tar, rpm, modprobe etc understand .xz data ?????? [*] Make tar, rpm, modprobe etc understand .gz data Modules are succesfully compressed compiled Booting up brings "Invalid ELF header magic: !=ELF" message for each loaded module, modules are loaded and working (show up in lsmod and functionality is given) running modprobe manually have the same result >> BusyBox v1.36.0 (2023-03-17 16:25:58 UTC) multi-call binary. -- -M- From nolange79 at gmail.com Sat Mar 18 09:46:16 2023 From: nolange79 at gmail.com (Norbert Lange) Date: Sat, 18 Mar 2023 10:46:16 +0100 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" In-Reply-To: References: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> Message-ID: Hello, BusyBox first tries to pass the module the the kernel via filedescriptor, this method only accepts uncompressed files. Yielding that error message. Only then it will decompress the module and try again. Regards, Norbert. https://bugs.busybox.net/show_bug.cgi?id=14041 On Sat, 18 Mar 2023, 10:41 Service IIT (Mayer EMI), < service.iit at mayer-emi.at> wrote: > > Am 18.03.2023 um 02:57 schrieb Khem Raj: > > On Fri, Mar 17, 2023 at 2:10?PM Service IIT (Mayer EMI) > > wrote: > >> Hi > >> > >> Can somone help how to get rid of the message "Invalid ELF header magic: > >> !=ELF" of busybox when using moprobe with compressed kernel modules > >> > > Something is not in ELF format. Can you provide more details of what > > you are trying to do? > > Having compiled the kernel (6.1.19) with > Module compression mode (XZ) ---> > [*] Support in-kernel module decompression > > Having compiled busybox with > Archival Utilities ---> > [*] Make tar, rpm, modprobe etc understand .xz data > [*] Make tar, rpm, modprobe etc understand .gz data > > Modules are succesfully compressed compiled > Booting up brings > > "Invalid ELF header magic: !=ELF" message for each loaded module, modules > are loaded and working (show up in lsmod and functionality is given) > > running modprobe manually have the same result > > >> BusyBox v1.36.0 (2023-03-17 16:25:58 UTC) multi-call binary. > > -- > > -M- > > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox > -------------- next part -------------- An HTML attachment was scrubbed... URL: From service.iit at mayer-emi.at Sat Mar 18 10:29:28 2023 From: service.iit at mayer-emi.at (Service IIT (Mayer EMI)) Date: Sat, 18 Mar 2023 11:29:28 +0100 Subject: depmod results in empty modules.dep for gz compressed modules Message-ID: <0adfb267-4abe-4f16-ff91-fb470b346711@mayer-emi.at> Hi. Having compiled the kernel (6.1.19) with ?????? Module compression mode (GZIP)? ---> ?????? [*]?? Support in-kernel module decompression Having compiled busybox with ???? Archival Utilities? ---> ??????? [*] Make tar, rpm, modprobe etc understand .xz data ??????? [*] Make tar, rpm, modprobe etc understand .gz data Building with ???? make clean all After building the modules.dep file remains empty The task works well with ?????? Module compression mode (XZ)? ---> or ?????? Module compression mode (NONE)? ---> What do i miss? -- - M - From service.iit at mayer-emi.at Sat Mar 18 10:35:13 2023 From: service.iit at mayer-emi.at (Service IIT (Mayer EMI)) Date: Sat, 18 Mar 2023 11:35:13 +0100 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" In-Reply-To: References: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> Message-ID: <1c951152-2011-6184-10a4-95c51266c906@mayer-emi.at> Am 18.03.2023 um 10:46 schrieb Norbert Lange: > Hello, > > BusyBox first tries to pass the module the the kernel via > filedescriptor, this method only accepts uncompressed files. Yielding > that error message. > > Only then it will decompress the module and try again. > > > Regards, Norbert. Ok, understood. However, why even does it not work with the filedescriptor Kernel setting ???? [*]?? Support in-kernel module decompression should enable this to work not needing the modprobe to fallback to uncompress and try it again - or not? > > https://bugs.busybox.net/show_bug.cgi?id=14041 > > On Sat, 18 Mar 2023, 10:41 Service IIT (Mayer EMI), > wrote: > > > Am 18.03.2023 um 02:57 schrieb Khem Raj: > > On Fri, Mar 17, 2023 at 2:10?PM Service IIT (Mayer EMI) > > wrote: > >> Hi > >> > >> Can somone help how to get rid of the message "Invalid ELF > header magic: > >> !=ELF" of busybox when using moprobe with compressed kernel modules > >> > > Something is not in ELF format. Can you provide more details of what > > you are trying to do? > > Having compiled the kernel (6.1.19) with > ?????? Module compression mode (XZ)? ---> > ?????? [*]?? Support in-kernel module decompression > > Having compiled busybox with > ???? Archival Utilities? ---> > ??????? [*] Make tar, rpm, modprobe etc understand .xz data > ??????? [*] Make tar, rpm, modprobe etc understand .gz data > > Modules are succesfully compressed compiled > Booting up brings > > "Invalid ELF header magic: !=ELF" message for each loaded module, > modules are loaded and working (show up in lsmod and functionality > is given) > > running modprobe manually have the same result > > >> BusyBox v1.36.0 (2023-03-17 16:25:58 UTC) multi-call binary. > -- - M - -------------- next part -------------- An HTML attachment was scrubbed... URL: From xoneca at gmail.com Sat Mar 18 12:23:09 2023 From: xoneca at gmail.com (Xabier Oneca -- xOneca) Date: Sat, 18 Mar 2023 13:23:09 +0100 Subject: [PATCH] mount: add feature to ignore flags starting with "x-" In-Reply-To: References: Message-ID: Hi Isaac, > Some tools add non-standard mount flags beginning with "x-", which are > commonly used for adding comments and metadata to mountpoints. These can > be optionally safely ignored, as they don't affect the functionality of > the mount and would otherwise cause Busybox to fail to mount the device. > > Some examples for such mount flags are "x-gdu.hide" and "x-gvfs-hide", > both of which are used to indicate to userspace programs that a given > mount should not be shown in a list of mounted partitions/filesystems. > > This patch does not change the current default behaviour; the mount > flags will only be ignored if this feature is enabled. An additional > verbose option has also been added to enable the ability to report that > the mount flags have been ignored, rather than silently ignoring them. > > Signed-off-by: Isaac True > --- > util-linux/mount.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 88 insertions(+) Thanks for the patch. I only want to add that there are two types of x-* options according to the util-linux manual: > X-* > All options prefixed with "X-" are interpreted as comments or as userspace application-specific options. These options are not stored in user space (e.g., > mtab file), nor sent to the mount.type helpers nor to the mount(2) system call. The suggested format is X-appname.option. > > x-* > The same as X-* options, but stored permanently in user space. This means the options are also available for umount(8) or other operations. Note that > maintaining mount options in user space is tricky, because it?s necessary use libmount-based tools and there is no guarantee that the options will be always > available (for example after a move mount operation or in unshared namespace). > > Note that before util-linux v2.30 the x-* options have not been maintained by libmount and stored in user space (functionality was the same as for X-* now), > but due to the growing number of use-cases (in initrd, systemd etc.) the functionality has been extended to keep existing fstab configurations usable > without a change. Cheers, Xabier Oneca_,,_ From isaac at is.having.coffee Tue Mar 21 12:03:55 2023 From: isaac at is.having.coffee (Isaac True) Date: Tue, 21 Mar 2023 12:03:55 +0000 Subject: [PATCH] mount: add feature to ignore flags starting with "x-" In-Reply-To: References: Message-ID: Hi Xabier, Do you think I should modify the patch to check for and ignore "X-" in addition to "x-"? Cheers, Isaac ------- Original Message ------- On Saturday, March 18th, 2023 at 13:23, Xabier Oneca -- xOneca wrote: > > > Hi Isaac, > > > Some tools add non-standard mount flags beginning with "x-", which are > > commonly used for adding comments and metadata to mountpoints. These can > > be optionally safely ignored, as they don't affect the functionality of > > the mount and would otherwise cause Busybox to fail to mount the device. > > > > Some examples for such mount flags are "x-gdu.hide" and "x-gvfs-hide", > > both of which are used to indicate to userspace programs that a given > > mount should not be shown in a list of mounted partitions/filesystems. > > > > This patch does not change the current default behaviour; the mount > > flags will only be ignored if this feature is enabled. An additional > > verbose option has also been added to enable the ability to report that > > the mount flags have been ignored, rather than silently ignoring them. > > > > Signed-off-by: Isaac True isaac at is.having.coffee > > --- > > util-linux/mount.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 88 insertions(+) > > > Thanks for the patch. I only want to add that there are two types of > x-* options according to the util-linux manual: > > > X-* > > All options prefixed with "X-" are interpreted as comments or as userspace application-specific options. These options are not stored in user space (e.g., > > mtab file), nor sent to the mount.type helpers nor to the mount(2) system call. The suggested format is X-appname.option. > > > > x-* > > The same as X-* options, but stored permanently in user space. This means the options are also available for umount(8) or other operations. Note that > > maintaining mount options in user space is tricky, because it?s necessary use libmount-based tools and there is no guarantee that the options will be always > > available (for example after a move mount operation or in unshared namespace). > > > > Note that before util-linux v2.30 the x-* options have not been maintained by libmount and stored in user space (functionality was the same as for X-* now), > > but due to the growing number of use-cases (in initrd, systemd etc.) the functionality has been extended to keep existing fstab configurations usable > > without a change. > > > Cheers, > > Xabier Oneca_,,_ From xoneca at gmail.com Wed Mar 22 19:38:08 2023 From: xoneca at gmail.com (Xabier Oneca -- xOneca) Date: Wed, 22 Mar 2023 20:38:08 +0100 Subject: [PATCH] mount: add feature to ignore flags starting with "x-" In-Reply-To: References: Message-ID: Hi Isaac, > Do you think I should modify the patch to check for and ignore "X-" in addition to "x-"? Don't know... Maybe lowercase is enough. It was more an "informational" comment than a "request" comment. :) I personally don't use "x-" nor "X-" options, and the few ones that I have seen in the wild have been the lowercase ones (e.g. Systemd options). Cheers, Xabier Oneca_,,_ From yuxiaozhang at google.com Thu Mar 23 23:17:44 2023 From: yuxiaozhang at google.com (Yuxiao Zhang) Date: Thu, 23 Mar 2023 16:17:44 -0700 Subject: dhcp6 client patch upstream In-Reply-To: References: Message-ID: Hi, any update on this? Thanks, -Yuxiao On Tue, Feb 28, 2023 at 4:03?PM Yuxiao Zhang wrote: > Hello busybox team, > > I have a simple patch related to dhcpv6 fqdn option. The context is that > according to RFC4704, the server should send fqdn in dns encoding format. > But some servers are still using plain text format. The patch is to > workaround this issue. > Basically the patch will check the first data byte, if it is greater than > 63, which means that it is impossible to be a dns encoding format. In this > case it will parse the fqdn part as plain text. > > Attached is the patch, let me know if the patch is acceptable. Also since > this is my first time upstreaming a patch to busybox, feel free to > suggest any additional process that I need to follow to make this work. > > Thanks, > -Yuxiao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblake at redhat.com Fri Mar 24 14:58:14 2023 From: eblake at redhat.com (Eric Blake) Date: Fri, 24 Mar 2023 09:58:14 -0500 Subject: [PATCH] readlink: Support --, -n always Message-ID: <20230324145814.1113627-1-eblake@redhat.com> POSIX will be standardizing readlink (just the -n option) and realpath (just -E and -e options): https://www.austingroupbugs.net/view.php?id=1457 Change things for readlink so that the POSIX-mandated -n and -- work even when disabling the non-standard (and partially non-working) -f when FEATURE_READLINK_FOLLOW is clear. POSIX also wants readlink to be verbose by default (if the argument is not a symlink, readlink must output a diagnostic); I did NOT address that one, because I'm waiting to see what the GNU Coreutils folks do: https://lists.gnu.org/archive/html/bug-coreutils/2023-03/msg00035.html Partial fix for https://bugs.busybox.net/show_bug.cgi?id=15466 Signed-off-by: Eric Blake --- coreutils/readlink.c | 29 ++++++++++++----------------- 1 file changed, 12 insertions(+), 17 deletions(-) diff --git a/coreutils/readlink.c b/coreutils/readlink.c index b2e867883..0a9aa957e 100644 --- a/coreutils/readlink.c +++ b/coreutils/readlink.c @@ -25,12 +25,14 @@ //kbuild:lib-$(CONFIG_READLINK) += readlink.o //usage:#define readlink_trivial_usage -//usage: IF_FEATURE_READLINK_FOLLOW("[-fnv] ") "FILE" +//usage: IF_FEATURE_READLINK_FOLLOW("[-fnv] ") +//usage: IF_NOT_FEATURE_READLINK_FOLLOW("[-n] ") +//usage: "FILE" //usage:#define readlink_full_usage "\n\n" -//usage: "Display the value of a symlink" -//usage: IF_FEATURE_READLINK_FOLLOW( "\n" -//usage: "\n -f Canonicalize by following all symlinks" +//usage: "Display the value of a symlink" "\n" //usage: "\n -n Don't add newline" +//usage: IF_FEATURE_READLINK_FOLLOW( +//usage: "\n -f Canonicalize by following all symlinks" //usage: "\n -v Verbose" //usage: ) @@ -67,25 +69,18 @@ int readlink_main(int argc UNUSED_PARAM, char **argv) { char *buf; char *fname; + unsigned opt; - IF_FEATURE_READLINK_FOLLOW( - unsigned opt; - /* We need exactly one non-option argument. */ - opt = getopt32(argv, "^" "fnvsq" "\0" "=1"); - fname = argv[optind]; - ) - IF_NOT_FEATURE_READLINK_FOLLOW( - const unsigned opt = 0; - if (argc != 2) bb_show_usage(); - fname = argv[1]; - ) + opt = getopt32(argv, "^" "n" IF_FEATURE_READLINK_FOLLOW("fvsq") + "\0" "=1"); + fname = argv[optind]; /* compat: coreutils readlink reports errors silently via exit code */ if (!(opt & 4)) /* not -v */ logmode = LOGMODE_NONE; /* NOFORK: only one alloc is allowed; must free */ - if (opt & 1) { /* -f */ + if (opt & 2) { /* -f */ buf = xmalloc_realpath_coreutils(fname); } else { buf = xmalloc_readlink_or_warn(fname); @@ -93,7 +88,7 @@ int readlink_main(int argc UNUSED_PARAM, char **argv) if (!buf) return EXIT_FAILURE; - printf((opt & 2) ? "%s" : "%s\n", buf); + printf((opt & 1) ? "%s" : "%s\n", buf); free(buf); fflush_stdout_and_exit_SUCCESS(); -- 2.39.2 From rmy at pobox.com Fri Mar 24 15:16:35 2023 From: rmy at pobox.com (Ron Yorston) Date: Fri, 24 Mar 2023 15:16:35 +0000 Subject: [PATCH] lineedit: fix matching of directories when searching PATH Message-ID: <641dbed3.9WjHe8/8yMe5BS8c%rmy@pobox.com> Commit 8baa643a3 (lineedit: match local directories when searching PATH) included subdirectories of the current directory in the search when tab-completing commands. Unfortunately a short time later commit 1d180cd74 (lineedit: use strncmp instead of is_prefixed_with (we know the length)) broke this feature by returning an incorrect length for the array of paths. Fix the length and reinstate matching of subdirectories. Signed-off-by: Ron Yorston --- libbb/lineedit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libbb/lineedit.c b/libbb/lineedit.c index b942f540a..625884adf 100644 --- a/libbb/lineedit.c +++ b/libbb/lineedit.c @@ -825,8 +825,8 @@ static unsigned path_parse(char ***p) res[npth++] = tmp; } /* special case: "match subdirectories of the current directory" */ - /*res[npth++] = NULL; - filled by xzalloc() */ - return npth; + /*res[npth] = NULL; - filled by xzalloc() */ + return npth + 1; } /* Complete command, directory or file name. -- 2.39.2 From rmy at pobox.com Sun Mar 26 10:20:46 2023 From: rmy at pobox.com (Ron Yorston) Date: Sun, 26 Mar 2023 11:20:46 +0100 Subject: [PATCH] ash: make EPOCH variables work if RANDOM is disabled Message-ID: <64201c7e.nzmBcxnN77db5Kh/%rmy@pobox.com> Commit 1d37186fe2 (ash: add bash-compatible EPOCH variables) added support for the EPOCHSECONDS and EPOCHREALTIME variables. These variables are dynamic and therefore require the VDYNAMIC flag to be non-zero. However, this is only the case if support for the RANDOM variable is enabled. Give VDYNAMIC a non-zero value if either EPOCH variables or RANDOM are enabled. Signed-off-by: Ron Yorston --- shell/ash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shell/ash.c b/shell/ash.c index 5f8c8ea19..559566b58 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -2087,7 +2087,7 @@ struct localvar { #define VNOFUNC 0x40 /* don't call the callback function */ #define VNOSET 0x80 /* do not set variable - just readonly test */ #define VNOSAVE 0x100 /* when text is on the heap before setvareq */ -#if ENABLE_ASH_RANDOM_SUPPORT +#if ENABLE_ASH_RANDOM_SUPPORT || BASH_EPOCH_VARS # define VDYNAMIC 0x200 /* dynamic variable */ #else # define VDYNAMIC 0 -- 2.39.2 From vda.linux at googlemail.com Tue Mar 28 16:13:29 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 28 Mar 2023 18:13:29 +0200 Subject: [PATCH] find: implement -ok In-Reply-To: <36947oo9-4s69-904r-10r7-n66o9s24or46@nqncgvir-ragrecevfrf.pbz> References: <9p395o38-9o30-q397-83nn-612r2orors5s@nqncgvir-ragrecevfrf.pbz> <36947oo9-4s69-904r-10r7-n66o9s24or46@nqncgvir-ragrecevfrf.pbz> Message-ID: On Sun, Jan 29, 2023 at 3:14?AM David Leonard wrote: > Resending patch for 'find -ok'. I re-ran bloatcheck (x86_64). findutils/find.c: In function ?do_exec?: findutils/find.c:837:12: error: ?rc? may be used uninitialized in this function [-Werror=maybe-uninitialized] 837 | return rc == 0; /* return 1 if exitcode 0 */ | ~~~^~~~ This is indeed the case (rc is used uninitialized). > +testing "find -ok" \ > + "cd find.tempdir && find testfile -ok true {} + 2>&1; echo \$?" \ > + "true testfile ?\n0\n" \ > + "" "y" The test actually failed (extra "\n"). "-ok CMD +" is not accepted by GNU findutils 4.9.0> Fixing the test. Applied the result. Thank you. From vda.linux at googlemail.com Tue Mar 28 16:59:33 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 28 Mar 2023 18:59:33 +0200 Subject: [PATCH] httpd should accept trailing slash after PATH_INFO In-Reply-To: References: Message-ID: Fixed in git (a bit differently). Thank you. On Tue, Mar 7, 2023 at 8:08?PM Andreas Mahling wrote: > > sorry, it seems I didn't follow the usual path for submitting a patch, > so here I go again: > > I stumbled upon a problem with the CGI-enabled httpd. It seems that > httpd can't handle a CGI call with an appended PATH_INFO, if the > latter ends with a slash. httpd takes this as a call for a directory > listing and throws 404. > > For further details you may take a look here: > https://lists.zx2c4.com/pipermail/cgit/2023-March/004825.html > > I've attached a patch, which works for me, although my understanding > of the httpd.c code is only superficial. > > Patch was generated by > diff -u networking/httpd.c networking/httpd.c.new >httpd.patch > against the busybox-1.34.1 tarball > > Thanks a lot to the busybox developers for their outstanding work. > > best regards > Andreas > > --- networking/httpd.c 2021-06-16 12:02:16.000000000 +0200 > +++ networking/httpd.c.new 2023-03-07 19:05:22.447075000 +0100 > @@ -2426,11 +2426,14 @@ > } > #if ENABLE_FEATURE_HTTPD_CGI > else if (urlp[-1] == '/') { > - /* It's a dir URL and there is no index.html */ > - /* Is there cgi-bin/index.cgi? */ > - if (access("/cgi-bin/index.cgi"+1, X_OK) != 0) > - send_headers_and_exit(HTTP_NOT_FOUND); /* no */ > - cgi_type = CGI_INDEX; > + if (cgi_type == CGI_NONE) { > + /* It's a dir URL and there is no index.html */ > + /* Is there cgi-bin/index.cgi? */ > + if (access("/cgi-bin/index.cgi"+1, X_OK) != 0) { > + send_headers_and_exit(HTTP_NOT_FOUND); /* no */ > + } > + cgi_type = CGI_INDEX; > + } > } > #endif > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Wed Mar 29 13:07:49 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 29 Mar 2023 15:07:49 +0200 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Message-ID: On Wed, Mar 1, 2023 at 12:01?PM alice wrote: > On Tue Feb 28, 2023 at 11:17 PM CET, wrote: > > I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 > > UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub > > actions runner VMs (azure). > > > > When I use sha256sum it is getting terminated with SIGILL, Illegal > > instruction. The issue is hard to reproduce but I have a GitHub actions CI/CD > > job that I can re-run repeatedly (no changes to code, environment, data input, > > etc) that will occasionally have the issue. I managed to capture a core dump. > > this was also reported in http://lists.busybox.net/pipermail/busybox/2023-January/090113.html > > it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, > and the code that checks it is broken and misdetects sha_ni support when avx512 > exists. the github runners don't have sha_ni, so it breaks exactly there. The code is: if (!shaNI) { unsigned eax = 7, ebx = ebx, ecx = 0, edx = edx; cpuid(&eax, &ebx, &ecx, &edx); shaNI = ((ebx >> 29) << 1) - 1; } if (shaNI > 0) ctx->process_block = sha1_process_block64_shaNI; If ebx's bit 29 is set, then shaNI = 1. If it is clear, then shaNI = -1. I checked "Intel? 64 and IA-32 Architectures Software Developer?s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4" to verify that CPUID(EAX=7, ECX=0) and bit position (EBX.29) is the correct check for SHA-NI. I double-checked it in Linux kernel source. I checked disassembly and it correctly sets up registers for CPUID. Can someone tell me on what CPU this does not work? From vda.linux at googlemail.com Wed Mar 29 13:46:58 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 29 Mar 2023 15:46:58 +0200 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Message-ID: On Wed, Mar 29, 2023 at 3:07?PM Denys Vlasenko wrote: > On Wed, Mar 1, 2023 at 12:01?PM alice wrote: > > On Tue Feb 28, 2023 at 11:17 PM CET, wrote: > > > I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 > > > UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub > > > actions runner VMs (azure). > > > > > > When I use sha256sum it is getting terminated with SIGILL, Illegal > > > instruction. The issue is hard to reproduce but I have a GitHub actions CI/CD > > > job that I can re-run repeatedly (no changes to code, environment, data input, > > > etc) that will occasionally have the issue. I managed to capture a core dump. > > > > this was also reported in http://lists.busybox.net/pipermail/busybox/2023-January/090113.html > > > > it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, > > and the code that checks it is broken and misdetects sha_ni support when avx512 > > exists. the github runners don't have sha_ni, so it breaks exactly there. > > The code is: > > if (!shaNI) { > unsigned eax = 7, ebx = ebx, ecx = 0, edx = edx; > cpuid(&eax, &ebx, &ecx, &edx); > shaNI = ((ebx >> 29) << 1) - 1; > } > if (shaNI > 0) > ctx->process_block = sha1_process_block64_shaNI; > > If ebx's bit 29 is set, then shaNI = 1. If it is clear, then shaNI = -1. ...aaaand this is not true! The bits 30,31 also will affect the result, need to be masked out! For example this way: shaNI = ((ebx >> 28) & 2) - 1; Sorry... From vda.linux at googlemail.com Wed Mar 29 14:46:53 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 29 Mar 2023 16:46:53 +0200 Subject: [PATCH] lineedit: fix matching of directories when searching PATH In-Reply-To: <641dbed3.9WjHe8/8yMe5BS8c%rmy@pobox.com> References: <641dbed3.9WjHe8/8yMe5BS8c%rmy@pobox.com> Message-ID: Applied, thank you. On Fri, Mar 24, 2023 at 4:25?PM Ron Yorston wrote: > > Commit 8baa643a3 (lineedit: match local directories when searching > PATH) included subdirectories of the current directory in the search > when tab-completing commands. > > Unfortunately a short time later commit 1d180cd74 (lineedit: use > strncmp instead of is_prefixed_with (we know the length)) broke > this feature by returning an incorrect length for the array of paths. > > Fix the length and reinstate matching of subdirectories. > > Signed-off-by: Ron Yorston > --- > libbb/lineedit.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libbb/lineedit.c b/libbb/lineedit.c > index b942f540a..625884adf 100644 > --- a/libbb/lineedit.c > +++ b/libbb/lineedit.c > @@ -825,8 +825,8 @@ static unsigned path_parse(char ***p) > res[npth++] = tmp; > } > /* special case: "match subdirectories of the current directory" */ > - /*res[npth++] = NULL; - filled by xzalloc() */ > - return npth; > + /*res[npth] = NULL; - filled by xzalloc() */ > + return npth + 1; > } > > /* Complete command, directory or file name. > -- > 2.39.2 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Wed Mar 29 14:47:11 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 29 Mar 2023 16:47:11 +0200 Subject: [PATCH] ash: make EPOCH variables work if RANDOM is disabled In-Reply-To: <64201c7e.nzmBcxnN77db5Kh/%rmy@pobox.com> References: <64201c7e.nzmBcxnN77db5Kh/%rmy@pobox.com> Message-ID: Applied, thank you. On Sun, Mar 26, 2023 at 12:21?PM Ron Yorston wrote: > > Commit 1d37186fe2 (ash: add bash-compatible EPOCH variables) added > support for the EPOCHSECONDS and EPOCHREALTIME variables. > > These variables are dynamic and therefore require the VDYNAMIC flag > to be non-zero. However, this is only the case if support for the > RANDOM variable is enabled. > > Give VDYNAMIC a non-zero value if either EPOCH variables or RANDOM > are enabled. > > Signed-off-by: Ron Yorston > --- > shell/ash.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/shell/ash.c b/shell/ash.c > index 5f8c8ea19..559566b58 100644 > --- a/shell/ash.c > +++ b/shell/ash.c > @@ -2087,7 +2087,7 @@ struct localvar { > #define VNOFUNC 0x40 /* don't call the callback function */ > #define VNOSET 0x80 /* do not set variable - just readonly test */ > #define VNOSAVE 0x100 /* when text is on the heap before setvareq */ > -#if ENABLE_ASH_RANDOM_SUPPORT > +#if ENABLE_ASH_RANDOM_SUPPORT || BASH_EPOCH_VARS > # define VDYNAMIC 0x200 /* dynamic variable */ > #else > # define VDYNAMIC 0 > -- > 2.39.2 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From rmy at pobox.com Thu Mar 30 10:05:04 2023 From: rmy at pobox.com (Ron Yorston) Date: Thu, 30 Mar 2023 11:05:04 +0100 Subject: [PATCH] ash: improve trap and jobs builtins in child shells Message-ID: <64255ed0.xUtzQMxQBVk2PKTq%rmy@pobox.com> The trap and jobs builtins can be used to report information about traps and jobs. This works when they're called from the current shell but in a child shell the required information is usually cleared. Special hacks allow: - trap to work with command substitution; - jobs to work with command substitution or in a pipeline. Neither works with process substitution. - Relax the test for the trap hack so it also supports pipelines. - Pass the command to be evaluated to forkshell() in evalbackcmd() so trap and jobs both work with process substitution. function old new delta forkchild 629 640 +11 argstr 1502 1496 -6 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/1 up/down: 11/-6) Total: 5 bytes Signed-off-by: Ron Yorston --- shell/ash.c | 13 +++++++------ shell/ash_test/ash-signals/usage.right | 12 ++++++++++++ shell/ash_test/ash-signals/usage.tests | 12 ++++++++++++ 3 files changed, 31 insertions(+), 6 deletions(-) diff --git a/shell/ash.c b/shell/ash.c index 559566b58..40b921be1 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -5190,8 +5190,7 @@ forkchild(struct job *jp, union node *n, int mode) closescript(); - if (mode == FORK_NOJOB /* is it `xxx` ? */ - && n && n->type == NCMD /* is it single cmd? */ + if (n && n->type == NCMD /* is it single cmd? */ /* && n->ncmd.args->type == NARG - always true? */ && n->ncmd.args && strcmp(n->ncmd.args->narg.text, "trap") == 0 && n->ncmd.args->narg.next == NULL /* "trap" with no arguments */ @@ -5285,10 +5284,12 @@ forkchild(struct job *jp, union node *n, int mode) ) { TRACE(("Job hack\n")); /* "jobs": we do not want to clear job list for it, - * instead we remove only _its_ own_ job from job list. + * instead we remove only _its_ own_ job from job list + * (if it has one). * This makes "jobs .... | cat" more useful. */ - freejob(curjob); + if (jp) + freejob(curjob); return; } #endif @@ -6607,9 +6608,9 @@ evalbackcmd(union node *n, struct backcmd *result if (pipe(pip) < 0) ash_msg_and_raise_perror("can't create pipe"); - /* process substitution uses NULL job/node, like openhere() */ + /* process substitution uses NULL job, like openhere() */ jp = (ctl == CTLBACKQ) ? makejob(/*n,*/ 1) : NULL; - if (forkshell(jp, (ctl == CTLBACKQ) ? n : NULL, FORK_NOJOB) == 0) { + if (forkshell(jp, n, FORK_NOJOB) == 0) { /* child */ FORCE_INT_ON; close(pip[ip]); diff --git a/shell/ash_test/ash-signals/usage.right b/shell/ash_test/ash-signals/usage.right index c0dbd6c3c..df1ed2dd7 100644 --- a/shell/ash_test/ash-signals/usage.right +++ b/shell/ash_test/ash-signals/usage.right @@ -6,6 +6,18 @@ trap -- 'a' INT trap -- 'a' USR1 trap -- 'a' USR2 ___ +trap -- 'a' EXIT trap -- 'a' INT trap -- 'a' USR1 trap -- 'a' USR2 +___ +trap -- 'a' EXIT +trap -- 'a' INT +trap -- 'a' USR1 +trap -- 'a' USR2 +___ +trap -- 'a' EXIT +trap -- 'a' INT +trap -- 'a' USR1 +trap -- 'a' USR2 +___ ___ trap -- 'a' USR1 trap -- 'a' USR2 diff --git a/shell/ash_test/ash-signals/usage.tests b/shell/ash_test/ash-signals/usage.tests index d29c6e74a..34e24cceb 100755 --- a/shell/ash_test/ash-signals/usage.tests +++ b/shell/ash_test/ash-signals/usage.tests @@ -10,6 +10,18 @@ trap "a" EXIT INT USR1 USR2 echo ___ trap +# show them by command substitution +echo ___ +echo $(trap) + +# show them by pipe +echo ___ +trap | cat + +# show them by process substitution +echo ___ +cat <(trap) + # clear one echo ___ trap 0 INT -- 2.39.2 From eblake at redhat.com Thu Mar 30 13:05:23 2023 From: eblake at redhat.com (Eric Blake) Date: Thu, 30 Mar 2023 08:05:23 -0500 Subject: [PATCH 2/1] readlink: slight size optimization In-Reply-To: <20230324145814.1113627-1-eblake@redhat.com> References: <20230324145814.1113627-1-eblake@redhat.com> Message-ID: <20230330130523.56401-1-eblake@redhat.com> Exploit the value of the flag for -n to reduce the compiled size of readlink_main() from 79 to 76 bytes on x86_64. Signed-off-by: Eric Blake --- coreutils/readlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coreutils/readlink.c b/coreutils/readlink.c index 0a9aa957e..83c417e66 100644 --- a/coreutils/readlink.c +++ b/coreutils/readlink.c @@ -88,8 +88,8 @@ int readlink_main(int argc UNUSED_PARAM, char **argv) if (!buf) return EXIT_FAILURE; - printf((opt & 1) ? "%s" : "%s\n", buf); + printf("%s%s", buf, "\n"[opt & 1]); free(buf); fflush_stdout_and_exit_SUCCESS(); -- 2.39.2 From ncopa at alpinelinux.org Thu Mar 30 15:09:16 2023 From: ncopa at alpinelinux.org (Natanael Copa) Date: Thu, 30 Mar 2023 17:09:16 +0200 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Message-ID: <20230330170916.52fd858b@ncopa-desktop.lan> On Wed, 29 Mar 2023 15:07:49 +0200 Denys Vlasenko wrote: > On Wed, Mar 1, 2023 at 12:01*PM alice wrote: > > On Tue Feb 28, 2023 at 11:17 PM CET, wrote: > > > I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 > > > UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub > > > actions runner VMs (azure). > > > > > > When I use sha256sum it is getting terminated with SIGILL, Illegal > > > instruction. The issue is hard to reproduce but I have a GitHub actions CI/CD > > > job that I can re-run repeatedly (no changes to code, environment, data input, > > > etc) that will occasionally have the issue. I managed to capture a core dump. > > > > this was also reported in http://lists.busybox.net/pipermail/busybox/2023-January/090113.html > > > > it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, > > and the code that checks it is broken and misdetects sha_ni support when avx512 > > exists. the github runners don't have sha_ni, so it breaks exactly there. > > The code is: > > if (!shaNI) { > unsigned eax = 7, ebx = ebx, ecx = 0, edx = edx; > cpuid(&eax, &ebx, &ecx, &edx); > shaNI = ((ebx >> 29) << 1) - 1; > } > if (shaNI > 0) > ctx->process_block = sha1_process_block64_shaNI; > > If ebx's bit 29 is set, then shaNI = 1. If it is clear, then shaNI = -1. > > I checked > "Intel? 64 and IA-32 Architectures Software Developer*s Manual > Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4" > > to verify that CPUID(EAX=7, ECX=0) and bit position (EBX.29) > is the correct check for SHA-NI. > > I double-checked it in Linux kernel source. > > I checked disassembly and it correctly sets up registers for CPUID. > > Can someone tell me on what CPU this does not work? Github runners. I created a job where it fails. See here: You have output of cpuinfo here: https://github.com/ncopa/busybox/actions/runs/3947969708/jobs/6757415539#step:4:1 I also tried to fix it with this change, but failed: https://github.com/ncopa/busybox/commit/e4ad5e7f2fed8e36d0779d918052169fe9a0bb95 This was based on the example function `int CheckForIntelShaExtensions()` in https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sha-extensions.html -nc From ben.busybox at backplane.be Thu Mar 30 16:33:12 2023 From: ben.busybox at backplane.be (ben.busybox at backplane.be) Date: Thu, 30 Mar 2023 18:33:12 +0200 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: <20230330170916.52fd858b@ncopa-desktop.lan> References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> <20230330170916.52fd858b@ncopa-desktop.lan> Message-ID: <1CC37AD2-146E-4CF4-9CF5-6AF814130AAF@backplane.be> The bug report says the 8171M and 8272CL have the problem. After applying the simple Intel approach Natanael is referring to, I was able to run on the 8171M (I have a run log to confirm it). I used the patch from the bug report: https://bugs.busybox.net/show_bug.cgi?id=15236 shaNI = ((ebx >> 28) & 2) - 1; /* bit 29 -> 1 or -1 */ Seems a lot more complicated than intel's approach: shaNI = ((ebx >> 29) & 1); > On 30 Mar 2023, at 5:09 PM, Natanael Copa wrote: > > On Wed, 29 Mar 2023 15:07:49 +0200 > Denys Vlasenko wrote: > >> On Wed, Mar 1, 2023 at 12:01*PM alice wrote: >>> On Tue Feb 28, 2023 at 11:17 PM CET, wrote: >>>> I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 >>>> UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub >>>> actions runner VMs (azure). >>>> >>>> When I use sha256sum it is getting terminated with SIGILL, Illegal >>>> instruction. The issue is hard to reproduce but I have a GitHub actions CI/CD >>>> job that I can re-run repeatedly (no changes to code, environment, data input, >>>> etc) that will occasionally have the issue. I managed to capture a core dump. >>> >>> this was also reported in http://lists.busybox.net/pipermail/busybox/2023-January/090113.html >>> >>> it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, >>> and the code that checks it is broken and misdetects sha_ni support when avx512 >>> exists. the github runners don't have sha_ni, so it breaks exactly there. >> >> The code is: >> >> if (!shaNI) { >> unsigned eax = 7, ebx = ebx, ecx = 0, edx = edx; >> cpuid(&eax, &ebx, &ecx, &edx); >> shaNI = ((ebx >> 29) << 1) - 1; >> } >> if (shaNI > 0) >> ctx->process_block = sha1_process_block64_shaNI; >> >> If ebx's bit 29 is set, then shaNI = 1. If it is clear, then shaNI = -1. >> >> I checked >> "Intel? 64 and IA-32 Architectures Software Developer*s Manual >> Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4" >> >> to verify that CPUID(EAX=7, ECX=0) and bit position (EBX.29) >> is the correct check for SHA-NI. >> >> I double-checked it in Linux kernel source. >> >> I checked disassembly and it correctly sets up registers for CPUID. >> >> Can someone tell me on what CPU this does not work? > > Github runners. I created a job where it fails. See here: > You have output of cpuinfo here: > https://github.com/ncopa/busybox/actions/runs/3947969708/jobs/6757415539#step:4:1 > > I also tried to fix it with this change, but failed: > https://github.com/ncopa/busybox/commit/e4ad5e7f2fed8e36d0779d918052169fe9a0bb95 > > This was based on the example function `int CheckForIntelShaExtensions()` in > https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sha-extensions.html > > -nc > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox -------------- next part -------------- An HTML attachment was scrubbed... URL: From explorer09 at gmail.com Fri Mar 31 00:29:36 2023 From: explorer09 at gmail.com (Kang-Che Sung) Date: Fri, 31 Mar 2023 08:29:36 +0800 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: <1CC37AD2-146E-4CF4-9CF5-6AF814130AAF@backplane.be> References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> <20230330170916.52fd858b@ncopa-desktop.lan> <1CC37AD2-146E-4CF4-9CF5-6AF814130AAF@backplane.be> Message-ID: On Fri, Mar 31, 2023 at 12:34?AM wrote: > > shaNI = ((ebx >> 28) & 2) - 1; /* bit 29 -> 1 or -1 */ > > Seems a lot more complicated than intel's approach: > > shaNI = ((ebx >> 29) & 1); > The `shaNI` variable is not a boolean, but has three possible values: 0 (undetermined), 1 (SHA instructions supported), -1 (not supported) That's why the slightly complicated logic. By the way, the `shaNI` name is a misnomer, as Intel never uses "NI" to refer to their SHA instruction set, unlike the AES instruction set. From ben.busybox at backplane.be Fri Mar 31 05:14:49 2023 From: ben.busybox at backplane.be (ben.busybox at backplane.be) Date: Fri, 31 Mar 2023 07:14:49 +0200 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> <20230330170916.52fd858b@ncopa-desktop.lan> <1CC37AD2-146E-4CF4-9CF5-6AF814130AAF@backplane.be> Message-ID: On 31 Mar 2023, at 2:29 AM, Kang-Che Sung wrote: > On Fri, Mar 31, 2023 at 12:34?AM wrote: >> shaNI = ((ebx >> 28) & 2) - 1; /* bit 29 -> 1 or -1 */ >> >> Seems a lot more complicated than intel's approach: >> >> shaNI = ((ebx >> 29) & 1); > The `shaNI` variable is not a boolean, but has three possible values: > 0 (undetermined), 1 (SHA instructions supported), -1 (not supported) > That's why the slightly complicated logic. > > By the way, the `shaNI` name is a misnomer, as Intel never uses "NI" > to refer to their SHA instruction set, unlike the AES instruction set. Thanks I did miss that. I can now see that this approach prevents cpuid from being called on every invocation of the sha1 & sha256 functions -- which would happen with my patch on systems that don't have the SHA extensions. From ncopa at alpinelinux.org Fri Mar 31 07:07:36 2023 From: ncopa at alpinelinux.org (Natanael Copa) Date: Fri, 31 Mar 2023 09:07:36 +0200 Subject: sha256sum Illegal instruction on musl amd64 In-Reply-To: References: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Message-ID: <20230331090736.3341114c@ncopa-desktop.lan> On Wed, 29 Mar 2023 15:46:58 +0200 Denys Vlasenko wrote: > > > it's caused by having a cpu with AVX512 (the github runners do) but not sha_ni, > > > and the code that checks it is broken and misdetects sha_ni support when avx512 > > > exists. the github runners don't have sha_ni, so it breaks exactly there. > > > > The code is: > > > > if (!shaNI) { > > unsigned eax = 7, ebx = ebx, ecx = 0, edx = edx; > > cpuid(&eax, &ebx, &ecx, &edx); > > shaNI = ((ebx >> 29) << 1) - 1; > > } > > if (shaNI > 0) > > ctx->process_block = sha1_process_block64_shaNI; > > > > If ebx's bit 29 is set, then shaNI = 1. If it is clear, then shaNI = -1. > > ...aaaand this is not true! The bits 30,31 also will affect the result, > need to be masked out! For example this way: > > shaNI = ((ebx >> 28) & 2) - 1; > > Sorry... Thank you for the fix. I can confirm it solves it. https://github.com/ncopa/busybox/actions/runs/4568076877/jobs/8062671513 -nc From vda.linux at googlemail.com Fri Mar 31 11:19:40 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 31 Mar 2023 13:19:40 +0200 Subject: Busybox modprobe brings error "Invalid ELF header magic: !=ELF" In-Reply-To: <1c951152-2011-6184-10a4-95c51266c906@mayer-emi.at> References: <6fe13fa9-bc25-1aec-ac1f-59e34435be51@mayer-emi.at> <1c951152-2011-6184-10a4-95c51266c906@mayer-emi.at> Message-ID: On Sat, Mar 18, 2023 at 11:35?AM Service IIT (Mayer EMI) wrote: > Am 18.03.2023 um 10:46 schrieb Norbert Lange: > > Hello, > > BusyBox first tries to pass the module the the kernel via filedescriptor, this method only accepts uncompressed files. Yielding that error message. > > Only then it will decompress the module and try again. > > > Regards, Norbert. > > Ok, understood. > However, why even does it not work with the filedescriptor > Kernel setting > [*] Support in-kernel module decompression > should enable this to work not needing the modprobe to fallback to uncompress and try it again - or not? Kernel does not auto-detect compressed modules. We need to call finit_module() with MODULE_INIT_COMPRESSED_FILE flag if module is compressed. Fixed it in git. Please try it now. From vda.linux at googlemail.com Fri Mar 31 13:53:53 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 31 Mar 2023 15:53:53 +0200 Subject: [PATCH] ash: improve trap and jobs builtins in child shells In-Reply-To: <64255ed0.xUtzQMxQBVk2PKTq%rmy@pobox.com> References: <64255ed0.xUtzQMxQBVk2PKTq%rmy@pobox.com> Message-ID: Applied, thank you. On Thu, Mar 30, 2023 at 12:05?PM Ron Yorston wrote: > > The trap and jobs builtins can be used to report information about > traps and jobs. This works when they're called from the current > shell but in a child shell the required information is usually > cleared. Special hacks allow: > > - trap to work with command substitution; > - jobs to work with command substitution or in a pipeline. > > Neither works with process substitution. > > - Relax the test for the trap hack so it also supports pipelines. > > - Pass the command to be evaluated to forkshell() in evalbackcmd() > so trap and jobs both work with process substitution. > > function old new delta > forkchild 629 640 +11 > argstr 1502 1496 -6 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 1/1 up/down: 11/-6) Total: 5 bytes > > Signed-off-by: Ron Yorston > --- > shell/ash.c | 13 +++++++------ > shell/ash_test/ash-signals/usage.right | 12 ++++++++++++ > shell/ash_test/ash-signals/usage.tests | 12 ++++++++++++ > 3 files changed, 31 insertions(+), 6 deletions(-) > > diff --git a/shell/ash.c b/shell/ash.c > index 559566b58..40b921be1 100644 > --- a/shell/ash.c > +++ b/shell/ash.c > @@ -5190,8 +5190,7 @@ forkchild(struct job *jp, union node *n, int mode) > > closescript(); > > - if (mode == FORK_NOJOB /* is it `xxx` ? */ > - && n && n->type == NCMD /* is it single cmd? */ > + if (n && n->type == NCMD /* is it single cmd? */ > /* && n->ncmd.args->type == NARG - always true? */ > && n->ncmd.args && strcmp(n->ncmd.args->narg.text, "trap") == 0 > && n->ncmd.args->narg.next == NULL /* "trap" with no arguments */ > @@ -5285,10 +5284,12 @@ forkchild(struct job *jp, union node *n, int mode) > ) { > TRACE(("Job hack\n")); > /* "jobs": we do not want to clear job list for it, > - * instead we remove only _its_ own_ job from job list. > + * instead we remove only _its_ own_ job from job list > + * (if it has one). > * This makes "jobs .... | cat" more useful. > */ > - freejob(curjob); > + if (jp) > + freejob(curjob); > return; > } > #endif > @@ -6607,9 +6608,9 @@ evalbackcmd(union node *n, struct backcmd *result > > if (pipe(pip) < 0) > ash_msg_and_raise_perror("can't create pipe"); > - /* process substitution uses NULL job/node, like openhere() */ > + /* process substitution uses NULL job, like openhere() */ > jp = (ctl == CTLBACKQ) ? makejob(/*n,*/ 1) : NULL; > - if (forkshell(jp, (ctl == CTLBACKQ) ? n : NULL, FORK_NOJOB) == 0) { > + if (forkshell(jp, n, FORK_NOJOB) == 0) { > /* child */ > FORCE_INT_ON; > close(pip[ip]); > diff --git a/shell/ash_test/ash-signals/usage.right b/shell/ash_test/ash-signals/usage.right > index c0dbd6c3c..df1ed2dd7 100644 > --- a/shell/ash_test/ash-signals/usage.right > +++ b/shell/ash_test/ash-signals/usage.right > @@ -6,6 +6,18 @@ trap -- 'a' INT > trap -- 'a' USR1 > trap -- 'a' USR2 > ___ > +trap -- 'a' EXIT trap -- 'a' INT trap -- 'a' USR1 trap -- 'a' USR2 > +___ > +trap -- 'a' EXIT > +trap -- 'a' INT > +trap -- 'a' USR1 > +trap -- 'a' USR2 > +___ > +trap -- 'a' EXIT > +trap -- 'a' INT > +trap -- 'a' USR1 > +trap -- 'a' USR2 > +___ > ___ > trap -- 'a' USR1 > trap -- 'a' USR2 > diff --git a/shell/ash_test/ash-signals/usage.tests b/shell/ash_test/ash-signals/usage.tests > index d29c6e74a..34e24cceb 100755 > --- a/shell/ash_test/ash-signals/usage.tests > +++ b/shell/ash_test/ash-signals/usage.tests > @@ -10,6 +10,18 @@ trap "a" EXIT INT USR1 USR2 > echo ___ > trap > > +# show them by command substitution > +echo ___ > +echo $(trap) > + > +# show them by pipe > +echo ___ > +trap | cat > + > +# show them by process substitution > +echo ___ > +cat <(trap) > + > # clear one > echo ___ > trap 0 INT > -- > 2.39.2 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox