This LOR happens when reading from a file backed MD device:
lock order reversal:
1st 0xfffffe00431eaac0 pbufwait (pbufwait, lockmgr) @ /cobra/src/sys/vm/vm_pager.c:471
2nd 0xfffff80003f17930 ufs (ufs, lockmgr) @ /cobra/src/sys/dev/md/md.c:977
lock order pbufwait -> ufs attempted at:
#0 0xffffffff80c78ead at witness_checkorder+0xbdd
#1 0xffffffff80bd6a52 at lockmgr_lock_flags+0x182
#2 0xffffffff80f52d5c at ffs_lock+0x6c
#3 0xffffffff80d0f3f4 at _vn_lock+0x54
#4 0xffffffff80708629 at mdstart_vnode+0x499
#5 0xffffffff807060ec at md_kthread+0x20c
#6 0xffffffff80bbfcd0 at fork_exit+0x80
#7 0xffffffff810b809e at fork_trampoline+0xe
This LOR was previously blessed by witness before commit 531f8cfea0
("Use dedicated lock name for pbufs").
Instead of blessing ufs and pbufwait, use LK_NOWAIT to prevent recording
the lock order. LK_NOWAIT will be a nop here as the lock is dropped in
pbuf_dtor(). The takes the same approach as 5875b94c74 ("buf_alloc():
lock the buffer with LK_NOWAIT").
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D34183
Merge commit 28fb22c90fe7 from llvm git (by Dimitry Andric):
[TSan] Handle FreeBSD specific indirection of libpthread functions
Similar to 60cc1d3218fc for NetBSD, add aliases and interceptors for the
following pthread related functions:
- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(3)
- pthread_rwlock_init(3)
- pthread_rwlock_destroy(3)
- pthread_rwlock_rdlock(3)
- pthread_rwlock_tryrdlock(3)
- pthread_rwlock_wrlock(3)
- pthread_rwlock_trywrlock(3)
- pthread_rwlock_unlock(3)
- pthread_once(3)
- pthread_sigmask(3)
In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.
ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D119034
MFC after: 3 days
We should clear the single step flag when entering a signal hander and
set it when returning. This fixes the ptrace__PT_STEP_with_signal test.
While here add support for userspace to set the single step bit as on
x86. This can be used by userspace for self tracing.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34170
Missed to move the tcp_set_flags() past ECN processing
in rack_fast_output() earlier.
Reviewed By: rrs, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D34180
When debugging 32-bit programs a debugger may insert a instruction that
will raise the undefined instruction trap. The kernel handles these
by raising a SIGTRAP, however the code was incorrect.
Fix this by using the expected TRAP_BRKPT signal code.
Sponsored by: The FreeBSD Foundation
As promised to the transport call on 11/4/22 here is an implementation
of hystart++ for cubic. It also cleans up the tcp_congestion function
to have a better name. Common variables are moved into the general
cc.h structure so that both cubic and newreno can use them for
hystart++
Reviewed by: Michael Tuexen, Richard Scheffenegger
Sponsored by: Netflix Inc.
Differential Revision: https://reviews.freebsd.org/D33035
These headers originate with the Xen project and shouldn't be mixed with
the main portion of the FreeBSD kernel. Notably they shouldn't be the
target of clean-up commits.
Switch to use the headers in sys/contrib/xen.
Reviewed by: royger
The current path of the Xen headers at /sys/xen/interface/ is not
correct, as those headers are imported verbatim from the Xen sources
and shouldn't be modified, as any modifications would be lost when a
new version is imported.
Changes to the public headers must be first done in Xen upstream so
that they can be backported and new imports will already carry them.
Import Xen 4.16 headers in sys/contrib/xen/. It's unlikely that we
will import different Xen code, so don't place them inside of any
subdirectory. If in the future other pieces of Xen code need to be
imported the headers will need to move into an include/ subdirectory.
Note that this commit does not yet modify the include path to use the
newly imported headers.
Sponsored by: Citrix Systems R&D
There's no need to explicitly add linear mappings for the grant table
area, as the memory is allocated using xenmem_alloc and it should
already have a linear mapping that can be obtained using
rman_get_virtual.
While there also remove the return value of gnttab_map, since there's
no return value anymore.
Sponsored by: Citrix Systems R&D
Reviewed by: Elliott Mitchell <ehem+freebsd@m5p.com>
Differential revision: https://reviews.freebsd.org/D29602
In libc++'s __threading_support header the semaphore.h header was
implicitly included, but from version 14 onwards, this is no longer the
case, resulting in compile errors:
tests/sys/fs/fusefs/setattr.cc:740:8: error: variable has incomplete type 'sem_t' (aka '_sem')
sem_t sem;
^
tests/sys/fs/fusefs/utils.hh:33:8: note: forward declaration of '_sem'
struct _sem;
^
MFC after: 3 days
This fixes the following warnings from clang 14:
usr.sbin/kbdmap/kbdmap.c:241:16: error: 'sscanf' may overflow; destination buffer in argument 5 has size 20, but the corresponding specifier may require size 21 [-Werror,-Wfortify-source]
&a, &b, buf);
^
usr.sbin/kbdmap/kbdmap.c:615:8: error: 'sscanf' may overflow; destination buffer in argument 3 has size 64, but the corresponding specifier may require size 65 [-Werror,-Wfortify-source]
keym, lng, desc);
^
usr.sbin/kbdmap/kbdmap.c:615:14: error: 'sscanf' may overflow; destination buffer in argument 4 has size 64, but the corresponding specifier may require size 65 [-Werror,-Wfortify-source]
keym, lng, desc);
^
usr.sbin/kbdmap/kbdmap.c:615:19: error: 'sscanf' may overflow; destination buffer in argument 5 has size 256, but the corresponding specifier may require size 257 [-Werror,-Wfortify-source]
keym, lng, desc);
^
In each case, the buffer being sscanf'd into is one byte too small.
MFC after: 3 days
This fixes the following warning from clang 14:
usr.sbin/bootparamd/bootparamd/bootparamd.c:204:32: error: 'fscanf' may
overflow; destination buffer in argument 3 has size 255, but the
corresponding specifier may require size 256 [-Werror,-Wfortify-source]
The MAX_MACHINE_NAME macro indicates the maximum number of bytes in a
machine name, but it does not include the NUL terminator required for
scanf.
MFC after: 3 days
getline() returns -1 on erorr or EOF, so use that condition instead of
feof() and check that there was no error after the loop exits.
Reviewed by: bapt, kevans (both earlier)
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34159
This release assigns a default value to the internal program name
variable in case the program is invoked with argv[0] == NULL.
There was no security issue: the prevuous program version would have
been immediately terminated due to a NULL dereference.
Since 59f256ec35 dmesg(8) will always skip first line of the message
buffer, cause it might be incomplete. The problem is that in most cases
it is complete, valid and contains the "---<<BOOT>>---" marker. This
skip can be disabled with '-a', but that would also unhide all non-kernel
messages. Move this functionality from dmesg(8) to kernel, since kernel
actually knows if wrap has happened or not.
The main motivation for the change is not actually the value of the
"---<<BOOT>>---" marker. The problem breaks unit tests, that clear
message buffer, perform a test and then check the message buffer for
a result. Example of such test is sys/kern/sonewconn_overflow.
Features of interest:
Allow setting target local variables (similar to gmake)
In META_MODE .MAKE.META.CMP_FILTER can be used for filtering commands
before comparion.
contrib/bmake/mk/cc-wrap.mk is an example of using these
See ChangeLog for the gory details.
