As the xinstall(8) utility had to be patched up to work with the POSIXly
correct basename()/dirname() prototypes, we make it pretty hard to build
previous versions of FreeBSD on HEAD. xinstall(8) is part of the
bootstrap tools.
Add some logic to <libgen.h> to automatically detect bad calls to
dirname() based on the type of the argument. If the argument is of type
'const char *', we simply fall back to calling into dirname@FBSD_1.0
directly.
I'll also give basename() similar treatment when importing the
thread-safe version of that function.
Tested by: bdrewery, madpilot (thanks!)
i.e. partial line, but set __SERR and errno in the same time, which
is inconsistent.
Now both OpenBSD and NetBSD return failure, i.e. no line and set error
indicators for such case, so make our fgetln() and fgetwln()
(as its wide version) compatible with the rest of *BSD.
PR: 212033
MFC after: 7 days
libifc (pronounced lib-ifconfig) aims to be a light abstraction layer between
programs and the kernel APIs for managing the network configuration.
This should hopefully make programs easier to maintain, and reduce code
duplication.
Work will begin on making ifconfig(8) use this library in the near future.
This code is still evolving. The interface should not be considered stable until
it is announced as such.
Submitted By: Marie Helene Kvello-Aune <marieheleneka@gmail.com>
Reviewed By: kp
Differential Revision: https://reviews.freebsd.org/D7529
functions.
__SERR is for user and the rest of stdio code do not check it
for error sensing internally, only set it.
In vf(w)printf.c here it is more easy to save __SERR, clear and restore it.
return partial line on any errors. See the comment in fgetln.c.
Add corresponding comment to fgetwln() too.
2) Rewrite r304607 case 1).
3) Remove "Fast path" from __fgetwc_mbs() since it can't detect encoding
errors and ignores them all.
PR: 212033
MFC after: 7 days
1) Don't forget to set __SERR on __slbexpand() error.
2) Check for __fgetwc() errors using errno. Don't check for __SERR
as PR suggested, it user-visible flag which can stick from previous
functions and stdio code don't check it for this purpose.
PR: 212033
MFC after: 3 days
Fix for pr24346: arm asm label calculation error in sub
Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:
add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260
would be assembled to the following, which adds 1 to r0, instead of
260:
e2800104 add r0, r0, #4, 2 ; equivalently 1
The new fixup kind fixup_arm_mod_imm takes care of the encoding:
e2800f41 add r0, r0, #260
Patch by Ting-Yuan Huang!
This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.
Requested by: jkim
MFC after: 3 days
- Avoid double use of "request" in a single sentence. Instead, describe
aio_sigevent as being used to request notification of the associated
operation's completion. This matches the language used to describe
aio_sigevent in aio(4).
- Simplify the prohibition on modifying buffers while requests are in
flight.
- Fix case mismatch.
- Drop note about not using stack variables. C programmers should be able
to figure out if a stack variable is safe based on the later warning
about the life cycle requirements of control blocks.
- Remove prohibition on modifying the I/O buffer for aio_fsync() since
it does not use an I/O buffer. For aio_mlock(), prohibit modifications
to the mapping (e.g. due to mprotect, munmap, mmap, etc.) but do not
prohibit modifications to the memory backing the buffer (stores into
the pages backing the buffer).
Requested by: wblock (1,2), kib (4)
Reviewed by: kib, rpokala, wblock
MFC after: 3 days
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7462
[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE
btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.
Differential Revision: http://reviews.llvm.org/D17682
Pull in r262782 from upstream llvm trunk (by Simon Pilgrim):
[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE
btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.
Differential Revision: http://reviews.llvm.org/D17683
This ensures clang does not emit AVX instructions for CPUTYPE=btver1.
Reported by: Michel Depeige <demik+freebsd@lostwave.net>
PR: 211864
MFC after: 3 days
Right now, userspace (fast) gettimeofday(2) on x86 only works for
RDTSC. For older machines, like Core2, where RDTSC is not C2/C3
invariant, and which fall to HPET hardware, this means that the call
has both the penalty of the syscall and of the uncached hw behind the
QPI or PCIe connection to the sought bridge. Nothing can me done
against the access latency, but the syscall overhead can be removed.
System already provides mappable /dev/hpetX devices, which gives
straight access to the HPET registers page.
Add yet another algorithm to the x86 'vdso' timehands. Libc is updated
to handle both RDTSC and HPET. For HPET, the index of the hpet device
to mmap is passed from kernel to userspace, index might be changed and
libc invalidates its mapping as needed.
Remove cpu_fill_vdso_timehands() KPI, instead require that
timecounters which can be used from userspace, to provide
tc_fill_vdso_timehands{,32}() methods. Merge i386 and amd64
libc/<arch>/sys/__vdso_gettc.c into one source file in the new
libc/x86/sys location. __vdso_gettc() internal interface is changed
to move timecounter algorithm detection into the MD code.
Measurements show that RDTSC even with the syscall overhead is faster
than userspace HPET access. But still, userspace HPET is three-four
times faster than syscall HPET on several Core2 and SandyBridge
machines.
Tested by: Howard Su <howard0su@gmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential revision: https://reviews.freebsd.org/D7473
The syscall is a trivial wrapper around new VOP_FDATASYNC(), sharing
code with fsync(2). For all filesystems, this commit provides the
implementation which delegates the work of VOP_FDATASYNC() to
VOP_FSYNC(). This is functionally correct but not efficient.
This is not yet POSIX-compliant implementation, because it does not
ensure that queued AIO requests are completed before returning.
Reviewed by: mckusick
Discussed with: avg (ZFS), jhb (AIO part)
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D7471
Later gcc and clang have deprecated =v (which maps to a specific temp
register) and instead we should just use =r to have the assembler
(hopefully!) save/restore things appropriately after choosing
a register.
Tested:
* AR9344 SoC, with userreg support
* AR9331 SoC, with no userreg support
Sponsored by: Sponsored by: DARPA, AFRL (MIPS TLS user register work)
Sync libarchive with vendor including three security fixes
Vendor issues fixed:
Issue #744: Very long pathnames evade symlink checks
Issue #748: libarchive can compress, but cannot decompress zip some files
PR #750: ustar: fix out of bounds read on empty string ("") filename
PR #755: fix use of acl_get_flagset_np() on FreeBSD
MFC after: 3 days
Depending on the address family and ai_flags containing AI_V4MAPPED,
it might not do a proper DNS lookup on the provided DNS address
Convert some `ai` boolean true/false checks to NULL/non-NULL while here.
MFC after: 1 week
PR: 211790
Reported by: Herbie.Robinson@stratus.com
Sponsored by: EMC / Isilon Storage Division
On particular slow networks, it can (on average) take longer to
resolve hosts to IP* addresses. 20 minutes seemed reasonable for
my work network
This will be solved in a more meaningful way (if possible) using
concurrency in the near future
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
Suppose that ktrace is performed on 32bit binary running on 64bit
host. In this case, the kernel records are 64bit, while utrace
records from rtld and malloc are 32bit. Make kdump useful to see
decoded utrace data in that case.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Now that we've updated the prototypes of the basename(3) and dirname(3)
functions to conform to POSIX, let's go ahead and reimplement dirname(3)
in such a way that it's thread-safe, but also guaranteed to succeed. C
libraries like glibc, musl and the one that's part of Solaris already
follow such an approach.
Move the existing implementation to another source file,
freebsd11_dirname.c to keep existing users of the API that pass in a
constant string happy, using symbol versioning.
Put a new version of the function in dirname.c, obtained from CloudABI's
C library. This version scans through the pathname string from left to
right, normalizing it, while discarding the last pathname component.
Reviewed by: emaste, jilles
Differential Revision: https://reviews.freebsd.org/D7355
glibc has a pretty nice function called crypt_r(3), which is nothing
more than crypt(3), but thread-safe. It accomplishes this by introducing
a 'struct crypt_data' structure that contains a buffer that is large
enough to hold the resulting string.
Let's go ahead and also add this function. It would be a shame if a
useful function like this wouldn't be usable in multithreaded apps.
Refactor crypt.c and all of the backends to no longer declare static
arrays, but write their output in a provided buffer.
There is no need to do any buffer length computation here, as we'll just
need to ensure that 'struct crypt_data' is large enough, which it is.
_PASSWORD_LEN is defined to 128 bytes, but in this case I'm picking 256,
as this is going to be part of the actual ABI.
Differential Revision: https://reviews.freebsd.org/D7306
Uses of commas instead of a semicolons can easily go undetected. The comma
can serve as a statement separator but this shouldn't be abused when
statements are meant to be standalone.
Detected with devel/coccinelle following a hint from DragonFlyBSD.
MFC after: 1 month
Uses of commas instead of a semicolons can easily go undetected. The comma
can serve as a statement separator but this shouldn't be abused when
statements are meant to be standalone.
Detected with devel/coccinelle following a hint from DragonFlyBSD.
MFC after: 1 month
This work, originally from Stacey Son, uses the MIPS UserReg for
reading the TLS data, and will fall back to the normal syscall path
when it isn't supported.
This code dynamically patches cpu_switch() to bypass the UserReg
instruction so to avoid generating a machine exception.
Thanks to sson for the original work, and to Dan Nelson for
bringing it to date and testing it on MIPS32 with me.
Tested:
* mips64 (sson)
* mips74k (dnelson_1901@yahoo.com) - AR9344 SoC, UserReg support
* mips24k (adrian) - AR9331 SoC, no UserReg support
Obtained from: sson, dnelson_1901@yahoo.com
This is the backing feature to implement C++11 thread storage duration
specified by the thread_local keyword. A destructor for given
thread-local object is registered to be executed at the thread
termination time using __cxa_thread_atexit(). Libc calls the
__cxa_thread_calls_dtors() during exit(3), before finalizers and
atexit functions, and libthr calls the function at the thread
termination time, after the stack unwinding and thread-specific key
destruction.
There are several uncertainties in the API which lacks a formal
specification. Among them:
- is it allowed to register destructors during destructing;
we allow, but limiting the nesting level. If too many iterations
detected, a diagnostic is issued to stderr and thread forcibly
terminates for now.
- how to handle destructors which belong to an unloading dso;
for now, we ignore destructor calls for such entries, and
issue a diagnostic. Linux does prevent dso unload until all
threads with destructors from the dso terminated.
It is supposed that the diagnostics allow to detect real-world
applications relying on the above details and possibly adjust
our implementation. Right now the choices were to provide the slim
API (but that rarely stands the practice test).
Tests are added to check generic functionality and to specify some of
the above implementation choices.
Submitted by: Mahdi Mokhtari <mokhi64_gmail.com>
Reviewed by: theraven
Discussed with: dim (detection of -std=c++11 supoort for tests)
Sponsored by: The FreeBSD Foundation (my involvement)
MFC after: 2 weeks
Differential revisions: https://reviews.freebsd.org/D7224,
https://reviews.freebsd.org/D7427
two sepatate functions to make glob(3) code less obscure and more simple.
There is no needs to make them inline since it is error path which supposed
to not happes often.
Our mprotect() function seems to take a "const void *" address to the
pages whose permissions need to be adjusted. POSIX uses "void *". Simply
stick to the POSIX one to prevent us from writing unportable code.
PR: 211423 (exp-run)
Tested by: antoine@ (Thanks!)
In the normal case and correct failure cases, the 'phdl' pointer is passed to
callers to use or clean up as needed. However, some failure cases returned
early, failing to export the phdl pointer.
This was introduced in the restructuring of r303533.
Reported by: Coverity
CID: 1361070
Reviewed by: markj
Sponsored by: EMC / Isilon Storage Division
Just like with freelocale(3), I haven't been able to find any piece of
code that actually makes use of this function's return value, both in
base and in ports. The reason for this is that FreeBSD seems to be the
only operating system to have such a prototype. This is why I'm deciding
to not use symbol versioning for this.
It does seem that the pw(8) utility depends on the function's typing and
already had a switch in place to toggle between the FreeBSD and POSIX
variant of this function. Clean this up by always expecting the POSIX
variant.
There is also a single port that has a couple of local declarations of
setgrent(3) that need to be patched up. This is in the process of being
fixed.
PR: 211394 (exp-run)
