From khalid.elmously at canonical.com Thu Dec 2 11:49:13 2021 From: khalid.elmously at canonical.com (Khaled Elmously) Date: Thu, 2 Dec 2021 14:49:13 -0500 Subject: [klibc] Timeout values (-t) not always guaranteed Message-ID: <20211202194913.7mutowzyfn5ywwxv@kbuntu> Hello, I have encountered situations where ipconfig takes longer than the user-specified timeout. The following is an easy way to reproduce the issue: # ip link add eth3 type dummy # date; /usr/lib/klibc/bin/ipconfig -t 2 eth3; date Thu Dec 2 14:26:15 EST 2021 IP-Config: eth3 hardware address aa:8f:6f:bf:35:96 mtu 1500 DHCP RARP IP-Config: no response after 2 secs - giving up Thu Dec 2 14:26:25 EST 2021 Notice that 'ipconfig' thinks it waited 2 seconds (which is the timeout value I specified), but in reality it waited 10 seconds as the 'date' values show. This seems to happen because of the "try again in 10 seconds" that happens when ipconfig encounters an error on send. I believe that a fix such as the following is needed to avoid this issue: diff --git a/usr/kinit/ipconfig/main.c b/usr/kinit/ipconfig/main.c index 5472d0f0..0969e9cb 100644 --- a/usr/kinit/ipconfig/main.c +++ b/usr/kinit/ipconfig/main.c @@ -477,6 +477,14 @@ static int loop(void) if (pending == 0 || (bringup_first && done)) break; + /* Compensate for already-lost time */ + /* Make sure to never exceed user-specified timeouts */ + gettimeofday(&now, NULL); + if (now.tv_sec + timeout > start + loop_timeout) { + timeout = loop_timeout - (now.tv_sec - start); + printf("Lowered timeout to match user request = (%d s) \n", timeout); + } + timeout_ms = timeout * 1000; for (x = 0; x < 2; x++) { Does that make sense? Any problems with this? Thanks Khaled From bgwin at google.com Thu Dec 9 16:42:36 2021 From: bgwin at google.com (Benjamin Gwin) Date: Thu, 9 Dec 2021 16:42:36 -0800 Subject: [klibc] [PATCH] Fix implementation of utimes Message-ID: <20211210004236.1171199-1-bgwin@google.com> This was not correctly initializing the timespec array before passing it on to utimensat. Tested: Built cpio and extracted an image with `cpio -im` to preserve mtime. The calls to utime now pass through the correct timestamps. Signed-off-by: Benjamin Gwin --- usr/klibc/utimes.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/usr/klibc/utimes.c b/usr/klibc/utimes.c index fd378a63..ce6d2f81 100644 --- a/usr/klibc/utimes.c +++ b/usr/klibc/utimes.c @@ -10,8 +10,10 @@ int utimes(const char *file, const struct timeval tvp[2]) struct timespec ts[2]; if (tvp) { - ts->tv_sec = tvp->tv_sec; - ts->tv_nsec = tvp->tv_usec * 1000; + ts[0].tv_sec = tvp[0].tv_sec; + ts[0].tv_nsec = tvp[0].tv_usec * 1000; + ts[1].tv_sec = tvp[1].tv_sec; + ts[1].tv_nsec = tvp[1].tv_usec * 1000; } return utimensat(AT_FDCWD, file, &ts[0], 0); -- 2.34.1.173.g76aa8bc2d0-goog From ben at decadent.org.uk Sun Dec 26 12:26:59 2021 From: ben at decadent.org.uk (Ben Hutchings) Date: Sun, 26 Dec 2021 21:26:59 +0100 Subject: [klibc] Fwd: Ubuntu (new upstream) klibc 2.0.8-6.1ubuntu2 In-Reply-To: References: Message-ID: <9719dc63ca1152e04a91d69f646961d95250005f.camel@decadent.org.uk> On Mon, 2021-08-09 at 21:52 +0000, Thorsten Glaser wrote: > Hi *, > > apparently *buntu have extra patches that might need consideration. [...] > Changes: > klibc (2.0.8-6.1ubuntu2) impish; urgency=medium > . > * Merge with Debian; remaining changes: > - Keep Ubuntu specific debian/patches/cf-protection.patch > * Add debian/patches/armhf-min-fpu.patch for GCC-11 compatibility [...] debian/patches/cf-protection.patch seems to be redundant since this commit included in 2.0.9: https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=b068ef9740d586200c6507bd393095159ff324c9 debian/patches/armhf-min-fpu.patch can be replaced by this: https://salsa.debian.org/kernel-team/klibc/-/commit/e67d83a48c27b807f234c6675a667387e11e6e23 But I would definitely prefer to have a simpler way to select sensible ARM architecture options that isn't as fragile as the current make variables are. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at decadent.org.uk Sun Dec 26 13:04:46 2021 From: ben at decadent.org.uk (Ben Hutchings) Date: Sun, 26 Dec 2021 22:04:46 +0100 Subject: [klibc] Bug#943425: Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use In-Reply-To: References: <162007287387.34046.13798151719953904.reportbug@zelenka.debian.org> <6d1a0f8f-441e-d80d-a988-5bd287cd64fa@linux.ibm.com> <23f588646312a2fcbb955e428f9f2cbc3784dae9.camel@decadent.org.uk> Message-ID: <4332544e88d9fcc30bc59131dbf41b88decfbd98.camel@decadent.org.uk> On Wed, 2021-05-05 at 19:56 +0000, Thorsten Glaser wrote: > Ben Hutchings dixit: > > > > > hpa, maks, bwh: any of you taking these two or should I send > > > > patches > > > > and possibly NMU klibc in Debian? > > > > > > Please send patches.? If you have a test base that could catch > > > bugs > > > > test *case* > > > > > like this (without writing lists of registers in the test > > > itself), that > > > would be really useful. > > Unfortunately, I do not, other than, ?run mksh?s testsuite?. This > seems to highly depend on compiler decisions (what to spill where > and when). > > Patches for klibc upstream git attched; I?m currently trying to test > them, will report. Applied, thanks. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From tg at debian.org Sun Dec 26 13:06:11 2021 From: tg at debian.org (klibc-bot for mirabilos) Date: Sun, 26 Dec 2021 13:06:11 -0800 Subject: [klibc] [klibc:master] sig{set, long}jmp: do not ignore sigsetjmp's second argument Message-ID: Commit-ID: eb10cf8c3128612a089ace8489a81bc4ffd5d07a Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=eb10cf8c3128612a089ace8489a81bc4ffd5d07a Author: mirabilos AuthorDate: Wed, 5 May 2021 21:02:37 +0200 Committer: Ben Hutchings CommitDate: Sun, 26 Dec 2021 18:55:27 +0100 sig{set,long}jmp: do not ignore sigsetjmp's second argument Save and restore the signal mask only if that argument is nonzero, as required by the standards. (Closes: Debian #988027) Signed-off-by: mirabilos Signed-off-by: Ben Hutchings --- usr/include/setjmp.h | 7 ++++++- usr/klibc/CAVEATS | 3 +-- usr/klibc/siglongjmp.c | 3 ++- 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/usr/include/setjmp.h b/usr/include/setjmp.h index abebccde..5916cd8a 100644 --- a/usr/include/setjmp.h +++ b/usr/include/setjmp.h @@ -27,6 +27,7 @@ __extern __noreturn longjmp(jmp_buf, int); struct __sigjmp_buf { jmp_buf __jmpbuf; sigset_t __sigs; + unsigned char __sigs_saved; }; typedef struct __sigjmp_buf sigjmp_buf[1]; @@ -34,7 +35,11 @@ typedef struct __sigjmp_buf sigjmp_buf[1]; #define sigsetjmp(__env, __save) \ ({ \ struct __sigjmp_buf *__e = (__env); \ - sigprocmask(0, NULL, &__e->__sigs); \ + if (__save) { \ + sigprocmask(0, NULL, &__e->__sigs); \ + __e->__sigs_saved = 1; \ + } else \ + __e->__sigs_saved = 0; \ setjmp(__e->__jmpbuf); \ }) diff --git a/usr/klibc/CAVEATS b/usr/klibc/CAVEATS index 5e991cb7..39949c28 100644 --- a/usr/klibc/CAVEATS +++ b/usr/klibc/CAVEATS @@ -13,8 +13,7 @@ Compiling with -O0 is more likely to work on gcc 3. setjmp()/longjmp(): ------------------- setjmp() and longjmp() *do not* save signal state. sigsetjmp() and -siglongjmp() *do* save the signal mask -- regardless of the value of -the extra argument. +siglongjmp() *do* save the signal mask if the extra argument is nonzero. The standards actually state that if you pass longjmp() a final value of zero the library should change that to a 1! Presumably the reason diff --git a/usr/klibc/siglongjmp.c b/usr/klibc/siglongjmp.c index 31042cbd..45f4e400 100644 --- a/usr/klibc/siglongjmp.c +++ b/usr/klibc/siglongjmp.c @@ -10,6 +10,7 @@ __noreturn siglongjmp(sigjmp_buf buf, int retval) { - sigprocmask(SIG_SETMASK, &buf->__sigs, NULL); + if (buf->__sigs_saved) + sigprocmask(SIG_SETMASK, &buf->__sigs, NULL); longjmp(buf->__jmpbuf, retval); } From tg at debian.org Sun Dec 26 13:06:12 2021 From: tg at debian.org (klibc-bot for mirabilos) Date: Sun, 26 Dec 2021 13:06:12 -0800 Subject: [klibc] [klibc:master] {set, long}jmp [s390x]: save/restore the correct registers Message-ID: Commit-ID: 12db27ba0db4fabe1230d1d9b8be56453991e6a9 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=12db27ba0db4fabe1230d1d9b8be56453991e6a9 Author: mirabilos AuthorDate: Wed, 5 May 2021 21:26:33 +0200 Committer: Ben Hutchings CommitDate: Sun, 26 Dec 2021 18:56:52 +0100 {set,long}jmp [s390x]: save/restore the correct registers The s390x ABI actually has FPU registers f8?f15, not f1/f3/f5/f7, to be saved. (Closes: Debian #943425) Signed-off-by: mirabilos Signed-off-by: Ben Hutchings --- usr/include/arch/s390/klibc/archsetjmp.h | 2 +- usr/klibc/arch/s390/setjmp.S | 24 ++++++++++++++++-------- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/usr/include/arch/s390/klibc/archsetjmp.h b/usr/include/arch/s390/klibc/archsetjmp.h index 728780ad..1167c8b6 100644 --- a/usr/include/arch/s390/klibc/archsetjmp.h +++ b/usr/include/arch/s390/klibc/archsetjmp.h @@ -16,7 +16,7 @@ struct __jmp_buf { struct __jmp_buf { uint64_t __gregs[10]; /* general registers r6-r15 */ - uint64_t __fpregs[4]; /* fp registers f1, f3, f5, f7 */ + uint64_t __fpregs[8]; /* fp registers f8-f15 */ }; #endif /* __s390x__ */ diff --git a/usr/klibc/arch/s390/setjmp.S b/usr/klibc/arch/s390/setjmp.S index c36a0517..1386419a 100644 --- a/usr/klibc/arch/s390/setjmp.S +++ b/usr/klibc/arch/s390/setjmp.S @@ -38,10 +38,14 @@ longjmp: setjmp: stmg %r6,%r15,0(%r2) # save all general registers - std %f1,80(%r2) # save fp registers f4 and f6 - std %f3,88(%r2) - std %f5,96(%r2) - std %f7,104(%r2) + std %f8,80(%r2) # save fp registers f8 to f15 + std %f9,88(%r2) + std %f10,96(%r2) + std %f11,104(%r2) + std %f12,112(%r2) + std %f13,120(%r2) + std %f14,128(%r2) + std %f15,136(%r2) lghi %r2,0 # return 0 br %r14 @@ -54,10 +58,14 @@ setjmp: longjmp: lgr %r1,%r2 # jmp_buf lgr %r2,%r3 # return value - ld %f7,104(%r1) # restore all saved registers - ld %f5,96(%r1) - ld %f3,88(%r1) - ld %f1,80(%r1) + ld %f15,136(%r1) # restore all saved registers + ld %f14,128(%r1) + ld %f13,120(%r1) + ld %f12,112(%r1) + ld %f11,104(%r1) + ld %f10,96(%r1) + ld %f9,88(%r1) + ld %f8,80(%r1) lmg %r6,%r15,0(%r1) br %r14 # return to restored address From ben at decadent.org.uk Sun Dec 26 14:09:06 2021 From: ben at decadent.org.uk (Ben Hutchings) Date: Sun, 26 Dec 2021 23:09:06 +0100 Subject: [klibc] Timeout values (-t) not always guaranteed In-Reply-To: <20211202194913.7mutowzyfn5ywwxv@kbuntu> References: <20211202194913.7mutowzyfn5ywwxv@kbuntu> Message-ID: On Thu, 2021-12-02 at 14:49 -0500, Khaled Elmously wrote: > Hello, > > I have encountered situations where ipconfig takes longer than the > user-specified timeout. > > The following is an easy way to reproduce the issue: > > # ip link add eth3 type dummy > # date; /usr/lib/klibc/bin/ipconfig -t 2 eth3; date > Thu Dec 2 14:26:15 EST 2021 > IP-Config: eth3 hardware address aa:8f:6f:bf:35:96 mtu 1500 DHCP RARP > IP-Config: no response after 2 secs - giving up > Thu Dec 2 14:26:25 EST 2021 > > > > Notice that 'ipconfig' thinks it waited 2 seconds (which is the > timeout value I specified), but in reality it waited 10 seconds as > the > 'date' values show. > > This seems to happen because of the "try again in 10 seconds" that > happens when ipconfig encounters an error on send. Yes, I can see that. > I believe that a fix such as the following is needed to avoid this > issue: > > diff --git a/usr/kinit/ipconfig/main.c b/usr/kinit/ipconfig/main.c > index 5472d0f0..0969e9cb 100644 > --- a/usr/kinit/ipconfig/main.c > +++ b/usr/kinit/ipconfig/main.c > @@ -477,6 +477,14 @@ static int loop(void) > if (pending == 0 || (bringup_first && done)) > break; > > + /* Compensate for already-lost time */ > + /* Make sure to never exceed user-specified timeouts */ > + gettimeofday(&now, NULL); > + if (now.tv_sec + timeout > start + loop_timeout) { > + timeout = loop_timeout - (now.tv_sec - start); > + printf("Lowered timeout to match user request = (%d s) \n", timeout); > + } > + > timeout_ms = timeout * 1000; > > for (x = 0; x < 2; x++) { > > > > > > Does that make sense? Any problems with this? It does make some sense. (I think it would make more sense to get rid of the inner loop as well; that would simplify this.) However, I worry a bit that users might depend on the current behaviour. In particular, it looks like a DHCP configuration will currently work as long as the DHCPOFFER is received within the loop timeout (and no packet timeout occurs). If we apply the loop timeout before packet timeouts, the DHCPACK must also be received within the loop timeout. Another issue, if you really want to use short timeouts like 2 seconds, is that we can currently time-out nearly 1 second too early due to rounding down "start" to the last second. We would need to start including the fractional seconds in timeout calculations. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at decadent.org.uk Sun Dec 26 15:01:19 2021 From: ben at decadent.org.uk (Ben Hutchings) Date: Mon, 27 Dec 2021 00:01:19 +0100 Subject: [klibc] [PATCH] Fix implementation of utimes In-Reply-To: <20211210004236.1171199-1-bgwin@google.com> References: <20211210004236.1171199-1-bgwin@google.com> Message-ID: <071950d09ea78e4d2e06badb3cb6966e264cfd6b.camel@decadent.org.uk> On Thu, 2021-12-09 at 16:42 -0800, Benjamin Gwin wrote: > This was not correctly initializing the timespec array before passing it > on to utimensat. > > Tested: Built cpio and extracted an image with `cpio -im` to preserve > mtime. The calls to utime now pass through the correct timestamps. > Applied, thanks. Ben. > Signed-off-by: Benjamin Gwin > --- > usr/klibc/utimes.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/usr/klibc/utimes.c b/usr/klibc/utimes.c > index fd378a63..ce6d2f81 100644 > --- a/usr/klibc/utimes.c > +++ b/usr/klibc/utimes.c > @@ -10,8 +10,10 @@ int utimes(const char *file, const struct timeval tvp[2]) > struct timespec ts[2]; > > if (tvp) { > - ts->tv_sec = tvp->tv_sec; > - ts->tv_nsec = tvp->tv_usec * 1000; > + ts[0].tv_sec = tvp[0].tv_sec; > + ts[0].tv_nsec = tvp[0].tv_usec * 1000; > + ts[1].tv_sec = tvp[1].tv_sec; > + ts[1].tv_nsec = tvp[1].tv_usec * 1000; > } > > return utimensat(AT_FDCWD, file, &ts[0], 0); -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bgwin at google.com Sun Dec 26 15:03:08 2021 From: bgwin at google.com (klibc-bot for Benjamin Gwin) Date: Sun, 26 Dec 2021 15:03:08 -0800 Subject: [klibc] [klibc:master] Fix implementation of utimes Message-ID: Commit-ID: a13b588a915d3a4498bf342d85524eb7dde71594 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=a13b588a915d3a4498bf342d85524eb7dde71594 Author: Benjamin Gwin AuthorDate: Thu, 9 Dec 2021 16:42:36 -0800 Committer: Ben Hutchings CommitDate: Mon, 27 Dec 2021 00:00:46 +0100 [klibc] Fix implementation of utimes This was not correctly initializing the timespec array before passing it on to utimensat. Tested: Built cpio and extracted an image with `cpio -im` to preserve mtime. The calls to utime now pass through the correct timestamps. Signed-off-by: Benjamin Gwin Signed-off-by: Ben Hutchings --- usr/klibc/utimes.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/usr/klibc/utimes.c b/usr/klibc/utimes.c index fd378a63..ce6d2f81 100644 --- a/usr/klibc/utimes.c +++ b/usr/klibc/utimes.c @@ -10,8 +10,10 @@ int utimes(const char *file, const struct timeval tvp[2]) struct timespec ts[2]; if (tvp) { - ts->tv_sec = tvp->tv_sec; - ts->tv_nsec = tvp->tv_usec * 1000; + ts[0].tv_sec = tvp[0].tv_sec; + ts[0].tv_nsec = tvp[0].tv_usec * 1000; + ts[1].tv_sec = tvp[1].tv_sec; + ts[1].tv_nsec = tvp[1].tv_usec * 1000; } return utimensat(AT_FDCWD, file, &ts[0], 0); From tg at debian.org Sun Dec 26 17:50:12 2021 From: tg at debian.org (Thorsten Glaser) Date: Mon, 27 Dec 2021 01:50:12 +0000 (UTC) Subject: [klibc] large C objects (was Re: [Git][kernel-team/klibc][master] 45 commits: 2.0.8 released, next version is 2.0.9) In-Reply-To: <61c90a1adc302_3d3452d476436240bb@godard.mail> References: <61c90a1adc302_3d3452d476436240bb@godard.mail> Message-ID: Ben Hutchings (@benh) dixit: >Further, it's not legal for a C object to be larger than >PTRDIFF_MAX (half of SIZE_MAX) as pointer arithmetic within it could >overflow. So return failure immediately if size is greater than that. Not exactly. The problem is >PTRDIFF_MAX *elements* but an element isn?t necessarily byte-sized, so you _can_ have an unsigned short object that?s larger than half SIZE_MAX bytes but ?PTRDIFF_MAX elements so pointer arithmetics will still work. Unsure if it?s a good idea in general to restrict allocation like this. It probably is for klibc, admittedly. But this got me wondering. Please do correct me, should I be wrong above. bye, //mirabilos -- ?It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.? -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 From ben at decadent.org.uk Mon Dec 27 07:24:06 2021 From: ben at decadent.org.uk (klibc-bot for Ben Hutchings) Date: Mon, 27 Dec 2021 07:24:06 -0800 Subject: [klibc] [klibc:master] Kbuild: Fix include path for Clang builds Message-ID: Commit-ID: 1643d07ebc9a776e90d4af62343c3339cfe2b324 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=1643d07ebc9a776e90d4af62343c3339cfe2b324 Author: Ben Hutchings AuthorDate: Mon, 27 Dec 2021 15:46:14 +0100 Committer: Ben Hutchings CommitDate: Mon, 27 Dec 2021 16:21:57 +0100 [klibc] Kbuild: Fix include path for Clang builds Currently we add the Clang system header directory to the include path with a -I option in Kbuild.klibc. This causes it to be searched before any include directories added by Kbuild files in individual source directories. In particular, Clang 13 added a "builtins.h" header which is found before dash's generated "builtins.h" in the case of an out-of-tree build. Use the -isystem option instead, putting this directory after any directories specified with -I. Signed-off-by: Ben Hutchings --- scripts/Kbuild.klibc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc index 45b4e84a..e88bc003 100644 --- a/scripts/Kbuild.klibc +++ b/scripts/Kbuild.klibc @@ -115,7 +115,7 @@ KLIBCCPPFLAGS := -nostdinc -iwithprefix include \ -I$(KLIBCOBJ)/../include \ -I$(KLIBCINC) ifeq ($(cc-name),clang) -KLIBCCPPFLAGS += -I$(shell $(KLIBCCC) $(KLIBCCFLAGS) --print-file-name=include) +KLIBCCPPFLAGS += -isystem $(shell $(KLIBCCC) $(KLIBCCFLAGS) --print-file-name=include) endif # kernel include paths From benh at debian.org Mon Dec 27 09:11:27 2021 From: benh at debian.org (Ben Hutchings) Date: Mon, 27 Dec 2021 18:11:27 +0100 Subject: [klibc] large C objects (was Re: [Git][kernel-team/klibc][master] 45 commits: 2.0.8 released, next version is 2.0.9) In-Reply-To: References: <61c90a1adc302_3d3452d476436240bb@godard.mail> Message-ID: On Mon, 2021-12-27 at 01:50 +0000, Thorsten Glaser wrote: > Ben Hutchings (@benh) dixit: > > > Further, it's not legal for a C object to be larger than > > PTRDIFF_MAX (half of SIZE_MAX) as pointer arithmetic within it > > could > > overflow.? So return failure immediately if size is greater than > > that. > > Not exactly. The problem is >PTRDIFF_MAX *elements* but an element > isn?t necessarily byte-sized, so you _can_ have an unsigned short > object that?s larger than half SIZE_MAX byhtes but ?PTRDIFF_MAX > elements so pointer arithmetics will still work. > > Unsure if it?s a good idea in general to restrict allocation like > this. It probably is for klibc, admittedly. But this got me > wondering. > > Please do correct me, should I be wrong above. Looking at C99 (I don't have a newer version to hand), there doesn't even seem to be a requirement that arrays are restricted to PTRDIFF_MAX elements. It's simply undefined behaviour if pointer arithmetic results in a value outside the range of ptrdiff_t. I must have misremembered the rule. But the whole purpose of this series was to replace the undefined behaviour of too-large allocations with a safe failure mode, and it might be necessary to do pointer arithmetic on an array of any element type with byte pointers. For example, if a program reads in an array of ints, and then passes it to a general-purpose checksum function that works on bytes. Ben. -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at decadent.org.uk Mon Dec 27 09:18:05 2021 From: ben at decadent.org.uk (klibc-bot for Ben Hutchings) Date: Mon, 27 Dec 2021 09:18:05 -0800 Subject: [klibc] [klibc:master] Use bounded array parameter types consistently Message-ID: Commit-ID: fa9e7b7dfa389758b6f32eab3b478110e870f7f1 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=fa9e7b7dfa389758b6f32eab3b478110e870f7f1 Author: Ben Hutchings AuthorDate: Mon, 27 Dec 2021 16:29:38 +0100 Committer: Ben Hutchings CommitDate: Mon, 27 Dec 2021 16:57:20 +0100 [klibc] Use bounded array parameter types consistently A function parameter declared with array type really has pointer type, and multiple declarations of a function are allowed to specify the same parameter as T[n], T[] or T *. However, gcc 11 now warns if they don't exactly match. Change the prototypes of {j,n}rand48(), seed48(), pipe{,2}(), and utimes() to declare parameters with the same bounded array types that their definitions use. Signed-off-by: Ben Hutchings --- usr/include/stdlib.h | 6 +++--- usr/include/sys/time.h | 2 +- usr/include/unistd.h | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/usr/include/stdlib.h b/usr/include/stdlib.h index 123eddc1..43bb8a36 100644 --- a/usr/include/stdlib.h +++ b/usr/include/stdlib.h @@ -55,11 +55,11 @@ __extern void *bsearch(const void *, const void *, size_t, size_t, __comparefunc_t); __extern void qsort(void *, size_t, size_t, __comparefunc_t); -__extern long jrand48(unsigned short *); +__extern long jrand48(unsigned short[3]); __extern long mrand48(void); -__extern long nrand48(unsigned short *); +__extern long nrand48(unsigned short[3]); __extern long lrand48(void); -__extern unsigned short *seed48(const unsigned short *); +__extern unsigned short *seed48(const unsigned short[3]); __extern void srand48(long); #define RAND_MAX 0x7fffffff diff --git a/usr/include/sys/time.h b/usr/include/sys/time.h index 98497e70..da9f5809 100644 --- a/usr/include/sys/time.h +++ b/usr/include/sys/time.h @@ -52,6 +52,6 @@ __extern int gettimeofday(struct timeval *, struct timezone *); __extern int settimeofday(const struct timeval *, const struct timezone *); __extern int getitimer(int, struct itimerval *); __extern int setitimer(int, const struct itimerval *, struct itimerval *); -__extern int utimes(const char *, const struct timeval *); +__extern int utimes(const char *, const struct timeval[2]); #endif /* _SYS_TIME_H */ diff --git a/usr/include/unistd.h b/usr/include/unistd.h index db90cbbe..6f71f7a6 100644 --- a/usr/include/unistd.h +++ b/usr/include/unistd.h @@ -71,8 +71,8 @@ __extern int fchmod(int, mode_t); __extern int mkdir(const char *, mode_t); __extern int mkdirat(int, const char *, mode_t); __extern int rmdir(const char *); -__extern int pipe(int *); -__extern int pipe2(int *, int); +__extern int pipe(int[2]); +__extern int pipe2(int[2], int); __extern int chroot(const char *); __extern int symlink(const char *, const char *); __extern int symlinkat(const char *, int, const char *); From ben at decadent.org.uk Mon Dec 27 09:18:06 2021 From: ben at decadent.org.uk (klibc-bot for Ben Hutchings) Date: Mon, 27 Dec 2021 09:18:06 -0800 Subject: [klibc] [klibc:master] include: Always include instead of Message-ID: Commit-ID: d96dc346ee46d205e01ee363a7f0d9c1b394371a Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=d96dc346ee46d205e01ee363a7f0d9c1b394371a Author: Ben Hutchings AuthorDate: Mon, 27 Dec 2021 17:32:15 +0100 Committer: Ben Hutchings CommitDate: Mon, 27 Dec 2021 17:34:36 +0100 [klibc] include: Always include instead of Many of our header files indirectly include , which can conflict with our . In particular: In file included from /usr/lib/klibc/include/linux/byteorder/little_endian.h:12, from /usr/lib/klibc/include/asm/byteorder.h:5, from /usr/lib/klibc/include/byteswap.h:9, from :1: /usr/lib/klibc/include/linux/types.h:22: warning: "__bitwise" redefined 22 | #define __bitwise __bitwise__ | In file included from /usr/lib/klibc/include/byteswap.h:8, from :1: /usr/lib/klibc/include/klibc/compiler.h:144: note: this is the location of the previous definition 144 | # define __bitwise | If our is included first, it defines the header guard macro for , avoiding any conflict. So include first in each of these headers. Signed-off-by: Ben Hutchings --- usr/include/byteswap.h | 2 +- usr/include/klibc/endian.h | 2 +- usr/include/net/if_packet.h | 1 + usr/include/net/route.h | 1 + usr/include/netinet/if_ether.h | 1 + usr/include/netinet/in.h | 1 + usr/include/netinet/in6.h | 1 + usr/include/netpacket/packet.h | 1 + usr/include/sys/capability.h | 1 + usr/include/sys/ioctl.h | 1 + usr/include/sys/md.h | 2 ++ usr/include/sys/prctl.h | 1 + usr/include/sys/sysinfo.h | 1 + usr/include/sys/utime.h | 1 + 14 files changed, 15 insertions(+), 2 deletions(-) diff --git a/usr/include/byteswap.h b/usr/include/byteswap.h index 6f41a28b..d70f1f9a 100644 --- a/usr/include/byteswap.h +++ b/usr/include/byteswap.h @@ -5,7 +5,7 @@ #ifndef _BYTESWAP_H #define _BYTESWAP_H -#include +#include #include #define bswap_16(x) __swab16(x) diff --git a/usr/include/klibc/endian.h b/usr/include/klibc/endian.h index 99563de7..8586888a 100644 --- a/usr/include/klibc/endian.h +++ b/usr/include/klibc/endian.h @@ -7,7 +7,7 @@ #ifndef _KLIBC_ENDIAN_H #define _KLIBC_ENDIAN_H -#include +#include #include /* Linux' asm/byteorder.h defines either __LITTLE_ENDIAN or diff --git a/usr/include/net/if_packet.h b/usr/include/net/if_packet.h index b5e8e0e1..33ee0aad 100644 --- a/usr/include/net/if_packet.h +++ b/usr/include/net/if_packet.h @@ -1 +1,2 @@ +#include #include diff --git a/usr/include/net/route.h b/usr/include/net/route.h index a60df24c..8b4305b2 100644 --- a/usr/include/net/route.h +++ b/usr/include/net/route.h @@ -1 +1,2 @@ +#include #include diff --git a/usr/include/netinet/if_ether.h b/usr/include/netinet/if_ether.h index 060ef220..a0b8cdee 100644 --- a/usr/include/netinet/if_ether.h +++ b/usr/include/netinet/if_ether.h @@ -1 +1,2 @@ +#include #include diff --git a/usr/include/netinet/in.h b/usr/include/netinet/in.h index 2952bb2a..7a13d2d8 100644 --- a/usr/include/netinet/in.h +++ b/usr/include/netinet/in.h @@ -5,6 +5,7 @@ #ifndef _NETINET_IN_H #define _NETINET_IN_H +#include #include #include #include /* Must be included *before* */ diff --git a/usr/include/netinet/in6.h b/usr/include/netinet/in6.h index 7e6da92e..91a4e126 100644 --- a/usr/include/netinet/in6.h +++ b/usr/include/netinet/in6.h @@ -5,6 +5,7 @@ #ifndef _NETINET_IN6_H #define _NETINET_IN6_H +#include #include #endif /* _NETINET_IN6_H */ diff --git a/usr/include/netpacket/packet.h b/usr/include/netpacket/packet.h index b5e8e0e1..33ee0aad 100644 --- a/usr/include/netpacket/packet.h +++ b/usr/include/netpacket/packet.h @@ -1 +1,2 @@ +#include #include diff --git a/usr/include/sys/capability.h b/usr/include/sys/capability.h index 41b5b4ac..8b929846 100644 --- a/usr/include/sys/capability.h +++ b/usr/include/sys/capability.h @@ -1,6 +1,7 @@ #ifndef _SYS_CAPABILITY_H #define _SYS_CAPABILITY_H +#include #include #include diff --git a/usr/include/sys/ioctl.h b/usr/include/sys/ioctl.h index 81ae7561..7b0b687d 100644 --- a/usr/include/sys/ioctl.h +++ b/usr/include/sys/ioctl.h @@ -5,6 +5,7 @@ #ifndef _SYS_IOCTL_H #define _SYS_IOCTL_H +#include #include #include #include diff --git a/usr/include/sys/md.h b/usr/include/sys/md.h index 184e4aae..63be3d88 100644 --- a/usr/include/sys/md.h +++ b/usr/include/sys/md.h @@ -21,6 +21,8 @@ #ifndef _SYS_MD_H #define _SYS_MD_H +#include + #define LEVEL_MULTIPATH (-4) #define LEVEL_LINEAR (-1) #define LEVEL_FAULTY (-5) diff --git a/usr/include/sys/prctl.h b/usr/include/sys/prctl.h index c12c191f..b0f41f54 100644 --- a/usr/include/sys/prctl.h +++ b/usr/include/sys/prctl.h @@ -1,6 +1,7 @@ #ifndef _SYS_PRCTL_H #define _SYS_PRCTL_H +#include #include #include diff --git a/usr/include/sys/sysinfo.h b/usr/include/sys/sysinfo.h index dba68dc6..8469ba0a 100644 --- a/usr/include/sys/sysinfo.h +++ b/usr/include/sys/sysinfo.h @@ -5,6 +5,7 @@ #ifndef _SYS_SYSINFO_H #define _SYS_SYSINFO_H +#include #include extern int sysinfo(struct sysinfo *info); diff --git a/usr/include/sys/utime.h b/usr/include/sys/utime.h index 56288a86..55415dbe 100644 --- a/usr/include/sys/utime.h +++ b/usr/include/sys/utime.h @@ -5,6 +5,7 @@ #ifndef _SYS_UTIME_H #define _SYS_UTIME_H +#include #include #endif /* _SYS_UTIME_H */ From tg at mirbsd.de Mon Dec 27 10:23:09 2021 From: tg at mirbsd.de (Thorsten Glaser) Date: Mon, 27 Dec 2021 18:23:09 +0000 (UTC) Subject: [klibc] large C objects (was Re: [Git][kernel-team/klibc][master] 45 commits: 2.0.8 released, next version is 2.0.9) In-Reply-To: References: <61c90a1adc302_3d3452d476436240bb@godard.mail> Message-ID: Ben Hutchings dixit: >But the whole purpose of this series was to replace the undefined >behaviour of too-large allocations with a safe failure mode, and it >might be necessary to do pointer arithmetic on an array of any element >type with byte pointers. For example, if a program reads in an array >of ints, and then passes it to a general-purpose checksum function that >works on bytes. OK, this makes sense; thanks! .NET does the same, by the way. >Looking at C99 (I don't have a newer version to hand), there doesn't Same one I once bought. >even seem to be a requirement that arrays are restricted to PTRDIFF_MAX >elements. It's simply undefined behaviour if pointer arithmetic >results in a value outside the range of ptrdiff_t. Ah, yes. Worse, ptrdiff_t could be long long and size_t unsigned int, so you?d, strictly speaking, have to check both if you do this. C is a neverending can of surprises? but when you control the environment you can, of course, exclude this. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf doesn?t seem to have changed this but recommends against larger-than-long for both. There is now this though: | For those reasons, it is sometimes beneficial to restrict the range of | object sizes to detect programming errors. For implementations | targeting machines with large address spaces, it is recommended that | RSIZE_MAX be defined as the smaller of the size of the largest object | supported or (SIZE_MAX >> 1), even if this limit is smaller than the | size of some legitimate, but very large, objects. Implementations | targeting machines with small address spaces may wish to define | RSIZE_MAX as SIZE_MAX, which means that there is no object size that | is considered a runtime-constraint violation. This indicates that such large objects are, strictly speaking, valid. OTOH, I don?t see throwing ENOMEM if some amount of memory isn?t available as contiguous block as problem either so using this as rationale-of-sorts for this security feature shouldn?t harm even from a standards PoV. bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too? may I quote you on that? sure, tho i doubt anyone will listen ;) From ben at decadent.org.uk Mon Dec 27 10:48:04 2021 From: ben at decadent.org.uk (klibc-bot for Ben Hutchings) Date: Mon, 27 Dec 2021 10:48:04 -0800 Subject: [klibc] [klibc:master] arm: Remove redundant/unsupported linker option --thumb-entry Message-ID: Commit-ID: 9129392a31774e6b63ab7231f1802a094e7eb90b Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=9129392a31774e6b63ab7231f1802a094e7eb90b Author: Ben Hutchings AuthorDate: Mon, 27 Dec 2021 18:34:09 +0100 Committer: Ben Hutchings CommitDate: Mon, 27 Dec 2021 18:53:48 +0100 [klibc] arm: Remove redundant/unsupported linker option --thumb-entry Both GNU ld (since binutils 2.14) and LLD automatically set the Thumb flag bit on the entry address when needed. Further, LLD doesn't support the --thumb-entry option, so we should not use it. Signed-off-by: Ben Hutchings --- usr/klibc/arch/arm/MCONFIG | 2 -- 1 file changed, 2 deletions(-) diff --git a/usr/klibc/arch/arm/MCONFIG b/usr/klibc/arch/arm/MCONFIG index dabefc54..41f39a0e 100644 --- a/usr/klibc/arch/arm/MCONFIG +++ b/usr/klibc/arch/arm/MCONFIG @@ -18,8 +18,6 @@ KLIBCSTRIPFLAGS += -R .ARM.exidx ifeq ($(CONFIG_KLIBC_THUMB),y) CPU_ARCH := $(CPU_ARCH)t KLIBCREQFLAGS += -mthumb -KLIBCLDFLAGS += --thumb-entry _start -KLIBCEMAIN = --thumb-entry main KLIBCREQFLAGS += -mabi=aapcs-linux KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x380000 else From ben at decadent.org.uk Mon Dec 27 13:33:05 2021 From: ben at decadent.org.uk (klibc-bot for Ben Hutchings) Date: Mon, 27 Dec 2021 13:33:05 -0800 Subject: [klibc] [klibc:master] s390: mmap: Change inline assembly to work with Clang Message-ID: Commit-ID: df622860136f95868a36eae578482dc7b9687f50 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=df622860136f95868a36eae578482dc7b9687f50 Author: Ben Hutchings AuthorDate: Mon, 27 Dec 2021 19:48:29 +0100 Committer: Ben Hutchings CommitDate: Mon, 27 Dec 2021 19:48:29 +0100 [klibc] s390: mmap: Change inline assembly to work with Clang Clang rejects the operand "%b1" to svc: usr/klibc/arch/s390/mmap.c:61:3: error: invalid operand in inline asm: ' svc ${1:b}' Since svc always takes an immediate operand, the "b" modifier is not needed. After deleting it, both Clang and gcc generate the correct instruction "svc 90". Signed-off-by: Ben Hutchings --- usr/klibc/arch/s390/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr/klibc/arch/s390/mmap.c b/usr/klibc/arch/s390/mmap.c index 33312397..dfc5a845 100644 --- a/usr/klibc/arch/s390/mmap.c +++ b/usr/klibc/arch/s390/mmap.c @@ -58,7 +58,7 @@ void *mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset) unsigned long __res; __asm__ __volatile__ ( - " svc %b1\n" + " svc %1\n" : "=d" (__svcres) : "i" (__NR_mmap), "0" (__arg1) From ben at decadent.org.uk Mon Dec 27 13:33:07 2021 From: ben at decadent.org.uk (klibc-bot for Ben Hutchings) Date: Mon, 27 Dec 2021 13:33:07 -0800 Subject: [klibc] [klibc:master] sparc64: Remove redundant/unsupported compiler option -mptr64 Message-ID: Commit-ID: 2851d6a3ad9955ca264736c6e6789bdb88632ad7 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=2851d6a3ad9955ca264736c6e6789bdb88632ad7 Author: Ben Hutchings AuthorDate: Mon, 27 Dec 2021 21:11:26 +0100 Committer: Ben Hutchings CommitDate: Mon, 27 Dec 2021 21:13:09 +0100 [klibc] sparc64: Remove redundant/unsupported compiler option -mptr64 The -m64 option to gcc implies -mptr64, so it's redundant there. Clang, however, doesn't understand -mptr64 at all, so we should not use it. Signed-off-by: Ben Hutchings --- usr/klibc/arch/sparc64/MCONFIG | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr/klibc/arch/sparc64/MCONFIG b/usr/klibc/arch/sparc64/MCONFIG index 81ad959e..d8c878aa 100644 --- a/usr/klibc/arch/sparc64/MCONFIG +++ b/usr/klibc/arch/sparc64/MCONFIG @@ -7,7 +7,7 @@ # accordingly. # -KLIBCARCHREQFLAGS = -m64 -mptr64 -D__sparc64__ +KLIBCARCHREQFLAGS = -m64 -D__sparc64__ KLIBCOPTFLAGS += -Os KLIBCBITSIZE = 64 From ben at decadent.org.uk Wed Dec 29 12:33:07 2021 From: ben at decadent.org.uk (klibc-bot for Ben Hutchings) Date: Wed, 29 Dec 2021 12:33:07 -0800 Subject: [klibc] [klibc:master] arm64, x86_64: Fix address collision when using LLD Message-ID: Commit-ID: 84d60fb75c0d8eaebc76da029130657f6c683ff3 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=84d60fb75c0d8eaebc76da029130657f6c683ff3 Author: Ben Hutchings AuthorDate: Wed, 29 Dec 2021 18:32:30 +0100 Committer: Ben Hutchings CommitDate: Wed, 29 Dec 2021 21:30:39 +0100 [klibc] arm64,x86_64: Fix address collision when using LLD LLD 13 is using a default base address of 2 MB for executables on these architectures, and since we set the base address of klibc.so to 2 MB they are now colliding with each other. Explicitly set the base address to 4 MB, matching GNU ld's default. Signed-off-by: Ben Hutchings --- usr/klibc/arch/arm64/MCONFIG | 1 + usr/klibc/arch/x86_64/MCONFIG | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/usr/klibc/arch/arm64/MCONFIG b/usr/klibc/arch/arm64/MCONFIG index f8741ff2..b90568ec 100644 --- a/usr/klibc/arch/arm64/MCONFIG +++ b/usr/klibc/arch/arm64/MCONFIG @@ -13,6 +13,7 @@ CPU_TUNE ?= generic KLIBCOPTFLAGS += -g -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE) KLIBCBITSIZE = 64 KLIBCREQFLAGS += -fno-exceptions -mgeneral-regs-only +KLIBCLDFLAGS = $(LD_IMAGE_BASE_OPT) 0x00400000 # Extra linkflags when building the shared version of the library # This address needs to be reachable using normal inter-module diff --git a/usr/klibc/arch/x86_64/MCONFIG b/usr/klibc/arch/x86_64/MCONFIG index 307b48fb..70d690e3 100644 --- a/usr/klibc/arch/x86_64/MCONFIG +++ b/usr/klibc/arch/x86_64/MCONFIG @@ -25,7 +25,7 @@ else KLIBCOPTFLAGS += -fno-asynchronous-unwind-tables endif KLIBCBITSIZE = 64 -KLIBCLDFLAGS = -m elf_x86_64 +KLIBCLDFLAGS = -m elf_x86_64 $(LD_IMAGE_BASE_OPT) 0x00400000 # Extra linkflags when building the shared version of the library # This address needs to be reachable using normal inter-module From ben at decadent.org.uk Thu Dec 30 07:18:09 2021 From: ben at decadent.org.uk (klibc-bot for Ben Hutchings) Date: Thu, 30 Dec 2021 07:18:09 -0800 Subject: [klibc] [klibc:master] 2.0.10 released, next version is 2.0.11 Message-ID: Commit-ID: 583a73cd89476bd2393ed1ffc02fa6ace8fdd057 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=583a73cd89476bd2393ed1ffc02fa6ace8fdd057 Author: Ben Hutchings AuthorDate: Thu, 30 Dec 2021 16:15:20 +0100 Committer: Ben Hutchings CommitDate: Thu, 30 Dec 2021 16:15:20 +0100 [klibc] 2.0.10 released, next version is 2.0.11 --- usr/klibc/version | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr/klibc/version b/usr/klibc/version index 0a692060..6cbacdc8 100644 --- a/usr/klibc/version +++ b/usr/klibc/version @@ -1 +1 @@ -2.0.10 +2.0.11 From ben at decadent.org.uk Thu Dec 30 07:29:43 2021 From: ben at decadent.org.uk (Ben Hutchings) Date: Thu, 30 Dec 2021 16:29:43 +0100 Subject: [klibc] [ANNOUNCE] klibc 2.0.10 Message-ID: I have released version 2.0.10.? This is available in the git repository at: ??? https://git.kernel.org/pub/scm/libs/klibc/klibc.git and as a tarball at: ??? https://mirrors.kernel.org/pub/linux/libs/klibc/2.0/ New features: - s390x and sparc64 ports can now be compiled using Clang - arm port can now be linked using LLD Bug fixes: - sig{set,long}jmp now honour the savesigs flag - s390x: {set,long}jmp now save and restore correct FP registers - utimes used to set incorrect mtime on architectures which do not have a utimes systtem call - Fixed build failure in dash when using Clang 13 - arm64,x86_64: Fixed address collision when using LLD 13 - Headers consistently use definitions from instead of A git shortlog of changes since version 2.0.9 follows. Ben. Ben Hutchings (8): [klibc] 2.0.9 released, next version is 2.0.10 [klibc] Kbuild: Fix include path for Clang builds [klibc] Use bounded array parameter types consistently [klibc] include: Always include instead of [klibc] arm: Remove redundant/unsupported linker option --thumb-entry [klibc] s390: mmap: Change inline assembly to work with Clang [klibc] sparc64: Remove redundant/unsupported compiler option -mptr64 [klibc] arm64,x86_64: Fix address collision when using LLD Benjamin Gwin (1): [klibc] Fix implementation of utimes mirabilos (2): sig{set,long}jmp: do not ignore sigsetjmp's second argument {set,long}jmp [s390x]: save/restore the correct registers -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed - Carolyn Scheppner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: