Update quic-organization-repolinter.yml #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
as reported/analyzed by Pascal Cuoq, the shlim and shcnt macros/functions are called by the scanf core (vfscanf) with f->rpos potentially null (if the FILE is not yet activated for reading at the time of the call). in this case, they compute differences between a null pointer (f->rpos) and a non-null one (f->buf), resulting in undefined behavior. it's unlikely that any observably wrong behavior occurred in practice, at least without LTO, due to limits on what's visible to the compiler from translation unit boundaries, but this has not been checked. fix is simply ensuring that the FILE is activated for read mode before entering the main scanf loop, and erroring out early if it can't be.
shgetc sets up to be able to perform an "unget" operation without the
caller having to remember and pass back the character value, and for
this purpose used a conditional store idiom:
if (f->rpos[-1] != c) f->rpos[-1] = c
to make it safe to use with non-writable buffers (setup by the
sh_fromstring macro or __string_read with sscanf).
however, validity of this depends on the buffer space at rpos[-1]
being initialized, which is not the case under some conditions
(including at least unbuffered files and fmemopen ones).
whenever data was read "through the buffer", the desired character
value is already in place and does not need to be written. thus,
rather than testing for the absence of the value, we can test for
rpos<=buf, indicating that the last character read could not have come
from the buffer, and thereby that we have a "real" buffer (possibly of
zero length) with writable pushback (UNGET bytes) below it.
this idea came up when I thought we might need to zero the UNGET portion of buf as well, but it seems like a useful improvement even when that turned out not to be necessary.
apparently this function was intended at some point to be used by strto* family as well, and thus was put in its own file; however, as far as I can tell, it's only ever been used by vsscanf. move it to the same file to reduce the number of source files and external symbols.
the sh version of fesetround or'd the new rounding mode onto the control register without clearing the old rounding mode bits, making changes sticky. this was the root cause of multiple test failures.
analogous to commit b287cd7 but for the custom FILE stream type the wcstol and wcstod family use. __toread could be used here as well, but there's a simple direct fix to make the buffer pointers initially valid for subtraction, so just do that to avoid pulling in stdio exit code in programs that don't use stdio.
it's been reported that the vdso clock_gettime64 function on (32-bit) arm is broken, producing erratic results that grow at a rate far greater than one reported second per actual elapsed second. the vdso function seems to have been added sometime between linux 5.4 and 5.6, so if there's ever been a working version, it was only present for a very short window. it's not clear what the eventual upstream kernel solution will be, but something needs to be done on the libc side so as not to be producing binaries that seem to work on older/existing/lts kernels (which lack the function and thus lack the bug) but will break fantastically when moving to newer kernels. hopefully vdso support will be added back soon, but with a new symbol name or version from the kernel to allow continued rejection of broken ones.
unsigned char promotes to int, which can overflow when shifted left by 24 bits or more. this has been reported multiple times but then forgotten. it's expected to be benign UB, but can trap when built with explicit overflow catching (ubsan or similar). fix it now. note that promotion to uint32_t is safe and portable even outside of the assumptions usually made in musl, since either uint32_t has rank at least unsigned int, so that no further default promotions happen, or int is wide enough that the shift can't overflow. this is a desirable property to have in case someone wants to reuse the code elsewhere.
the AD (authenticated data) bit in outgoing dns queries is defined by rfc3655 to request that the nameserver report (via the same bit in the response) whether the result is authenticated by DNSSEC. while all results returned by a DNSSEC conforming nameserver will be either authenticated or cryptographically proven to lack DNSSEC protection, for some applications it's necessary to be able to distinguish these two cases. in particular, conforming and compatible handling of DANE (TLSA) records requires enforcing them only in signed zones. when the AD bit was first defined for queries, there were reports of compatibility problems with broken firewalls and nameservers dropping queries with it set. these problems are probably a thing of the past, and broken nameservers are already unsupported. however, since there is no use in the AD bit with the netdb.h interfaces, explicitly clear it in the queries they make. this ensures that, even with broken setups, the standard functions will work, and at most the res_* functions break.
the old logic here likely dates back, at least in inspiration, to before it was recognized that transient errors must not be allowed to reflect the contents of successful results and must be reported to the application. here, the dns backend for getaddrinfo, when performing a paired query for v4 and v6 addresses, accepted results for one address family even if the other timed out. (the __res_msend backend does not propagate error rcodes back to the caller, but continues to retry until timeout, so other error conditions were not actually possible.) this patch moves the checks to take place before answer parsing, and performs them for each answer rather than only the answer to the first query. if nxdomain is seen it's assumed to apply to both queries since that's how dns semantics work.
the internal __res_msend returns 0 on timeout without having obtained any conclusive answer, but in this case has not filled in meaningful anslen. res_send wrongly treated that as success, but returned a zero answer length. any reasonable caller would eventually end up treating that as an error when attempting to parse/validate it, but it should just be reported as an error. alternatively we could return the last-received inconclusive answer (typically servfail), but doing so would require internal changes in __res_msend. this may be considered later.
presently all archs define SIGSTKFLT but this is not correct. change strsignal as a prerequisite for fixing that.
signal 7 is SIGEMT on Linux mips* ABI according to the man pages and kernel. it's not clear where the wrong name came from but it dates back to original mips commit.
since the backend for LOCK() skips locking if single-threaded, it's unsafe to make the process appear single-threaded before the last use of lock. this fixes potential unsynchronized access to a linked list via __dl_thread_cleanup.
after all but the last thread exits, the next thread to observe libc.threads_minus_1==0 and conclude that it can skip locking fails to synchronize with any changes to memory that were made by the last-exiting thread. this can produce data races. on some archs, at least x86, memory synchronization is unlikely to be a problem; however, with the inline locks in malloc, skipping the lock also eliminated the compiler barrier, and caused code that needed to re-check chunk in-use bits after obtaining the lock to reuse a stale value, possibly from before the process became single-threaded. this in turn produced corruption of the heap state. some uses of libc.threads_minus_1 remain, especially for allocation of new TLS in the dynamic linker; otherwise, it could be removed entirely. it's made non-volatile to reflect that the remaining accesses are only made under lock on the thread list. instead of libc.threads_minus_1, libc.threaded is now used for skipping locks. the difference is that libc.threaded is permanently true once an additional thread has been created. this will produce some performance regression in processes that are mostly single-threaded but occasionally creating threads. in the future it may be possible to bring back the full lock-skipping, but more care needs to be taken to produce a safe design.
these are all flags that can be single-byte values.
the design used here relies on the barrier provided by the first lock operation after the process returns to single-threaded state to synchronize with actions by the last thread that exited. by storing the intent to change modes in the same object used to detect whether locking is needed, it's possible to avoid an extra (possibly costly) memory load after the lock is taken.
coding style warnings enabled by default in clang have long been a source of spurious questions/bug-reports. since clang provides a -w that behaves differently from gcc's, and that lets us enable any warnings we may actually want after turning them all off to start with a clean slate, use it at configure time if clang is detected.
see linux commit eba75c587e811d3249c8bd50d22bb2266ccd3c0f icmp: support rfc 4884
calling lutimes with tv=0 is valid if the application wants to set the timestamps to the current time. this commit makes it so the timespec struct is populated with values from tv only if tv != 0 and calls utimensat with times=0 if tv == 0.
The -a and -o operators are obsolescent and not in baseline POSIX.
commit d150764 added support for null argument in oldmalloc and was overlooked when switching to mallocng.
inability to use realpath in chroot/container without procfs access and at early boot prior to mount of /proc has been an ongoing issue, and it turns out realpath was one of the last remaining interfaces that needed procfs for its core functionality. during investigation while reimplementing, it was determined that there were also serious problems with the procfs-based implementation. most seriously it was unsafe on pre-O_PATH kernels, and unlike other places where O_PATH was used, the unsafety was hard or impossible to fix because O_NOFOLLOW can't be used (since the whole purpose was to follow symlinks). the new implementation is a direct one, performing readlink on each path component to resolve it. an explicit stack, as opposed to recursion, is used to represent the remaining components to be processed. the stack starts out holding just the input string, and reading a link pushes the link contents onto the stack. unlike many other implementations, this one does not call getcwd initially for relative pathnames. instead it accumulates initial .. components to be applied to the working directory if the result is still a relative path. this avoids calling getcwd (which may fail) at all when symlink traversal will eventually yield an absolute path. it also doesn't use any form of stat operation; instead it arranges for readlink to tell it when a non-directory is used in a context where a directory is needed. this minimizes the number of syscalls needed, avoids accessing inodes when the directory table suffices, and reduces the amount of code pulled in for static linking.
reallocarray is an extension introduced by OpenBSD, which introduces calloc overflow checking to realloc. glibc 2.28 introduced support for this function behind _GNU_SOURCE, while glibc 2.29 allows its usage in _DEFAULT_SOURCE.
float_t should represent the type that is used to evaluate float expressions internally. On s390x, float_t is currently set to double. In contrast, the isa supports single-precision float operations and compilers by default evaluate float in single precision, which violates the C standard (sections 5.2.4.2.2 and 7.12 in C11/C17, to be precise). With -fexcess-precision=standard, gcc evaluates float in double precision, which aligns with the standard yet at the cost of added conversion instructions. gcc-11 will drop the special case to retrofit double precision behavior for -fexcess-precision=standard so that __FLT_EVAL_METHOD__ will be 0 on s390x in any scenario. To improve standards compliance and compatibility with future compiler direction, this patch changes the definition of float_t to be derived from the compiler's __FLT_EVAL_METHOD__.
both __clone and __syscall_cp_asm failed to restore the original value of r6 after using it as a syscall argument register. the extent of breakage is not known, and in some cases may be mitigated by the only callers being internal to libc; if they used r6 but no longer needed its value after the call, they may not have noticed the problem. however at least posix_spawn (which uses __clone) was observed returning to the application with the wrong value in r6, leading to crash. since the call frame ABI already provides a place to spill registers, fixing this is just a matter of using it. in __clone, we also spuriously restore r6 in the child, since the parent branch directly returns to the caller. this takes the value from an uninitialized slot of the child's stack, but is harmless since there is no caller to return to in the child.
ucontext.h depends on the internal struct tag name for namespacing reasons, and the intent was always for it to be consistent across archs anyway.
this change should have been made when priority inheritance mutex support was added. if priority protection is also added at some point the implementation will need to change and will probably no longer be a simple bit shuffling.
pthread_once is not compatible with MT-fork constraints (commit 167390f) and is not needed here anyway; we already have a lock suitable for initialization. while changing this, fix a corner case where AT_MINSIGSTKSZ gives a value that's more than MINSIGSTKSZ but by a margin of less than 2048, thereby causing the size to be reduced. it shouldn't matter but the intent was to be the larger of a 2048-byte margin over the legacy fixed minimum stack requirement or a 512-byte margin over the minimum the kernel reports at runtime.
the intent here is just to scan at least l bytes forward for the end of the haystack and at least some decent minimum to avoid doing it over and over if the needle is short, with no need to be precise. the comment erroneously stated this as an estimate for MIN when it's actually an estimate for MAX.
this allows the lock to be shared with setlocale, eliminates repeated per-category lock/unlock in newlocale, and will allow the use of pthread_once in newlocale to be dropped (to be done separately).
in general, pthread_once is not compatible with MT-fork constraints (commit 167390f). here it actually no longer matters, because it's now called with a lock held, but since the lock is held it's pointless to use pthread_once.
this is necessary for MT-fork correctness now that the code runs under locale lock. it would not be hard to avoid, but __get_locale is already using libc-internal malloc anyway. this can be reconsidered during locale overhaul later if needed.
while the layouts match, the member member naming expected by software using mcontext_t omits the sc_ prefix.
commit 2412638 got the size of struct v4l2_buffer wrong and omitted the tv_usec member slot from the offset list, so the ioctl numbers never matched and fallback code path was never taken. this caused the affected ioctls to fail with ENOTTY on kernels not new enough to have the native time64 ioctls.
commit 2412638 got the size of struct v4l2_event wrong and failed to account for the fact that the old struct might be either 120 bytes with time misaligned mod 8, or 128 bytes with time aligned mod 8, due to the contained union having 64-bit members whose alignment is arch-dependent. rather than adding new logic to handle the differences, use an actual stripped-down version of the structure in question to derive the ioctl number, size, and offsets.
these functions are specified to fail with EBADF on negative fd arguments. apart from close, they are also specified to fail if the value exceeds OPEN_MAX, but as written it is not clear that this imposes any requirement when OPEN_MAX is not defined, and it's undesirable to impose a dynamic limit (via setrlimit) here since the limit at the time of posix_spawn may be different from the limit at the time of setting up the file actions. this may require revisiting later.
commit 7586360 removed the unused arguments from the definition of __libc_start_main, making it incompatible with the declaration at the point of call, which still passed 6 arguments. calls with mismatched function type have undefined behavior, breaking LTO and any other tooling that checks for function signature mismatch. removing the extra arguments from the point of call (crt1) is not an option for fixing this, since that would be a change in ABI surface between application and libc. adding back the extra arguments requires some care. on archs that pass arguments on the stack or that reserve argument spill space for the callee on the stack, it imposes an ABI requirement on the caller to provide such space. the modern crt1.c entry point provides such space, but originally there was arch-specific asm for the call to __libc_start_main. the last of this asm was removed in commit 6fef8ca, and manual review of the code removed and its prior history was performed to check that all archs/variants passed the legacy init/fini/ldso_fini arguments.
as an outcome of Austin Group issue #385, future versions of the standard will require free not to alter the value of errno. save and restore it individually around the calls to madvise and munmap so that the cost is not imposed on calls to free that do not result in any syscall.
commit 8d37958 inadvertently broke oldmalloc by having it implement __libc_malloc rather than __libc_malloc_impl.
as an outcome of Austin Group issue #385, future versions of the standard will require free not to alter the value of errno. save and restore it individually around the calls to madvise and munmap so that the cost is not imposed on calls to free that do not result in any syscall.
Signed-off-by: quic-nwtn <[email protected]>
quic-nwtn
force-pushed
the
quic-nwtn-patch-1
branch
from
8a2c341 to
051cfc9
Compare
Signed-off-by: Nitish kumar <[email protected]>
quic-nwtn
force-pushed
the
quic-nwtn-patch-1
branch
from
051cfc9 to
f89e0a7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR upgrades github action workflow that runs repolinter on each push and pull.