The behavior is the same as in capability mode, it does not actually
return EINVAL for absolute lookups:
openat(AT_FDCWD,"/tmp/test",O_RDONLY|O_DIRECTORY,00) = 3 (0x3)
openat(3,"../../",O_RDONLY|0x800000,00) ERR#93 'Capabilities insufficient'
openat(3,"/etc/passwd",O_RDONLY|0x800000,00) ERR#93 'Capabilities insufficient'
Fixes: 1f305be43 ("Document {O,AT}_RESOLVE_BENEATH...")
Reviewed by: kib, pauamma (manpages), emaste
Sponsored by: https://www.patreon.com/valpackett
Pull Request: https://github.com/freebsd/freebsd-src/pull/680
Differential Revision: https://reviews.freebsd.org/D38675
Rephrase double negated sentences to improve readability
OpenBSD has done the same in the past to their man 3 daemon
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/671
- Be consistent with RFC references, so add a space after 'RFC'
- Add a LIBRARY section
- Use standard integer types in the SYNOPSIS section
Obtained from: DragonflyBSD
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D27548
For compatibility with glibc. The previous code would trigger a division
by zero in roundup() and terminate. Instead, just pass through to
malloc() for align == 0.
PR: 269688
Reviewed by: imp, mjg
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/655
profil(II) is in the scanned 3rd edition manual that we have. We don't
have the 3rd edition sources, nor do we have the 4th edition souces. We
have a mostly complete (missing pipes) 4th edition C rewrite where
profil system call number is reserved, but it's not implemented (it's in
the manx section for things that apeared to have been in 3rd edition but
weren't yet part of the reimplemented 4th edition). The 5th edition
sources we have do have it, however. For other items that have appeared
in earlier manuals, we've added the simple verbage to the manual and
relegated the rest of the data for that file to the commit message.
To allow to run a newer world on a pre-1400079 kernel a compat shims to
the sched_affinity functions has beed added.
Reported by: antoine
Tested by: antoine
Reviewed by: kib
Differential revision: https://reviews.freebsd.org/D38555
MFC after: 3 days
Use it instead of defining IN_RTLD by base sources that want P_OSREL_
defines in userspace, but are not rtld.
This allows to remove abuse of IN_RTLD from userspace.
Reviewed by: dchagin, markj, imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38585
Simplify the tests for 32-bit arm soft float support. For the files
included only on arm, drop the test entirely. For others, test
MACHINE_CPUARCH against arm.
No functional change intended. File lists appear the same before / after
the change.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38582
No need to check the mode again here; we know that `iop` wraps the
correct fd.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D37987
getopt_long(3) will not allow an `optind` setting of 0 to be bug-for-bug
compatible with the GNU implementation, as some software does rely on
it. Document it as a BUG, since it affects previous declarations of
compatibility with getopt(3).
Reviewed by: pauamma (markup)
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D37867
With GCC 4.2 out of the tree for a while now and no sign of it
returning, we don't really need to support older versions that don't
allow us to specify a ctor priority anymore.
Noticed by: mjg
This function has been around since 4.4BSD but was dropped upstream in 2020. This went unnoticed when tzcode was updated. Bring it back, but prepare for removing it before 14.0 is released.
PR: 269445
MFC after: 3 days
Reported by: val@packett.cool
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38445
Casting to int truncates size on some platforms, resulting swab not
copying all the data. Cast len to size_t to avoid right shifting a
signed value: we know here it's > 0, so we can safely cast it w/o losing
precision.
In addition, be more careful with signedness of char pointers and
temporaries. Downgrade tmp from unsigned long to unsigned char since
we're only reading and writing characters.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/516
While here, move notes about FreeBSD-specific functionality to the
COMPATIBILITY section, and document the ECAPMODE error for shm_open().
Reviewed by: pauamma, kib
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D38282
In preparation for a follow-up revision wherein kvmclock may export
timekeeping info to userspace even in the absence of AMDID_RDTSCP, fall
back to using rdtsc when rdtscp isn't available. This mimics
pvclock_read_time_info() in the kernel.
Reviewed by: kib
Tested by: Shrikanth R Kamath <kshrikanth@juniper.net>
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D38341
Remove the hard-coded dependency on HYPERV being only x86. Instead, 100%
rely on MK_HYPERV. It's always right (since it's marked BROKEN (so set
to "no") on architectures we don't support).
Sponsored by: Netflix
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D38306
Under Linux to sched_[g|s]etaffinity() functions the value returned from a call
to gettid(2) (thread id) can be passed in the argument pid. Specifying pid as 0
will set the attribute for the calling thread, and passing the value returned
from a call to getpid(2) (process id) will set the attribute for the main thread
of the thread group.
Native cpuset(2) family of system calls has "which" argument to determine how
the value of id argument is interpreted, i.e., CPU_WHICH_TID is used to pass
a thread id and CPU_WHICH_PID - to pass a process id.
For now native sched_[g|s]etaffinity() implementation is wrong as uses "which"
CPU_WHICH_PID to pass both (process and thread id) to the kernel. To fix this
adding a new "which" CPU_WHICH_TIDPID intended to handle both id's.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D38209
MFC after: 1 week
Cast char's through unsigned char before storing as an integer in
xdr_char(), this ensures that the encoded form is consistently not
sign-extended following Open Solaris's example.
Prior to this change, platforms with signed chars would sign extend
values with the high bit set but ones with unsigned chars would not
so 0xff would be stored as 0x000000ff on unsigned char platforms and
0xffffffff on signed char platforms. Decoding has the same
result for either form so this is a largely cosmetic change, but it
seems best to produce consistent output.
For more discussion, see https://github.com/openzfs/zfs/issues/14173
Reviewed by: mav, imp
Differential Revision: https://reviews.freebsd.org/D37992
* Replay 2010[acflm] which had been merged but not recorded.
* Merge 2010n.
* Reorganize (unsplit) the code to match the upstream layout.
* Merge 2022[cdefg].
MFC after: 1 week
Sponsored by: Klara, Inc.
These architectures fail to handle this special case, and will cause the
corresponding setjmp/_setjmp to return 0 rather than 1. Fix this and add
regression tests (also committed upstream).
PR: 268684
Reviewed by: arichardson, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29363
Do not cache PID for a process that does not fabricate it,
calls openlog() before forking and does not call exec() thereafter.
PR: 268666
Fixes: e9ae9fa937
Tested by: kp
MFC after: 3 days
- provide various missing MLINKS for library functions
- update various SEE ALSO section to include the
new linked manual pages
- add various definitions of new functions like isideogram_l(3)
- document COMPATIBILITY for some functions
- bump man page dates
Reviewed by: gbe, bcr
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/621
Differential Revision: https://reviews.freebsd.org/D37203
Reverting because of issue in Makefile.inc1 during native builds:
make[1]: “.../freebsd/Makefile.inc1" line 163: Unknown target aarch64:aarch64.
Since I only tested this patch with make universe on amd64, this issue wasn't caught.
This reverts commit 83bf6ab568.
On powerpc64, powerpc64le and riscv64 some software wrongly assumes that
it runs on powerpc or riscv (32-bit).
Differential revision: https://reviews.freebsd.org/D35962
Approved by: alfredo, imp
Without this patch, the code in the rpcbind client forces
the use of UDP. A comment notes that some rpcbind servers
only support UDP. This makes NFSv3 mounts to Azure servers
impossible, since they require use of TCP for rpcbind.
Since the comment is very old (imported from NetBSD in 2001)
and I do not believe any UDP only rpcbind servers will
still exist, this patch comments out the code that forces
use of UDP, so that NFSv3 mounts to Azure servers can work.
For an NFSv3 mount, the "udp" mount option will still
make mount_nfs use UDP for rpcbind so that can be used
as a workaround for any old NFSv3 server that only
supports rpcbind over UDP (if any such server still exists).
I asked if doing this change is appropriate on freebsd-fs@
and I only got one reply (off list) that supported doing
the change.
PR: 267301
MFC after: 1 month
Refer to sockets rather than processes, since one can have multiple
sockets in a load-balancing group within the same process.
MFC after: 1 week
Sponsored by: Modirum MDPay
Sponsored by: Klara, Inc.
