Revert r302194, there are issues with some applications after changing
the return value, in particular console-kit-daemon.

Reported by: Ivan Klymenko <fidaj@ukr.net>
Sponsored by: The FreeBSD Founda

Revert r302194, there are issues with some applications after changing
the return value, in particular console-kit-daemon.

Reported by: Ivan Klymenko <fidaj@ukr.net>
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Approved by: re (gjb)

show more ...

For pthread_mutex_trylock() call on owned error-check or non-portable
adaptive mutex, return EDEADLK as required by POSIX. The
pthread_mutex_lock() is already compliant.

Tested by: Guy Yur <guyyur@

For pthread_mutex_trylock() call on owned error-check or non-portable
adaptive mutex, return EDEADLK as required by POSIX. The
pthread_mutex_lock() is already compliant.

Tested by: Guy Yur <guyyur@gmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Approved by: re (gjb)

show more ...

libthr: Use formatted PANIC()

No functional change, although _thread_printf() may be slightly less functional
or render some values differently from libc snprintf(3). No ABI change.

Reviewed by: k

libthr: Use formatted PANIC()

No functional change, although _thread_printf() may be slightly less functional
or render some values differently from libc snprintf(3). No ABI change.

Reviewed by: kib
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D6672

show more ...

Add implementation of robust mutexes, hopefully close enough to the
intention of the POSIX IEEE Std 1003.1TM-2008/Cor 1-2013.

A robust mutex is guaranteed to be cleared by the system upon either
thr

Add implementation of robust mutexes, hopefully close enough to the
intention of the POSIX IEEE Std 1003.1TM-2008/Cor 1-2013.

A robust mutex is guaranteed to be cleared by the system upon either
thread or process owner termination while the mutex is held. The next
mutex locker is then notified about inconsistent mutex state and can
execute (or abandon) corrective actions.

The patch mostly consists of small changes here and there, adding
neccessary checks for the inconsistent and abandoned conditions into
existing paths. Additionally, the thread exit handler was extended to
iterate over the userspace-maintained list of owned robust mutexes,
unlocking and marking as terminated each of them.

The list of owned robust mutexes cannot be maintained atomically
synchronous with the mutex lock state (it is possible in kernel, but
is too expensive). Instead, for the duration of lock or unlock
operation, the current mutex is remembered in a special slot that is
also checked by the kernel at thread termination.

Kernel must be aware about the per-thread location of the heads of
robust mutex lists and the current active mutex slot. When a thread
touches a robust mutex for the first time, a new umtx op syscall is
issued which informs about location of lists heads.

The umtx sleep queues for PP and PI mutexes are split between
non-robust and robust.

Somewhat unrelated changes in the patch:
1. Style.
2. The fix for proper tdfind() call use in umtxq_sleep_pi() for shared
pi mutexes.
3. Removal of the userspace struct pthread_mutex m_owner field.
4. The sysctl kern.ipc.umtx_vnode_persistent is added, which controls
the lifetime of the shared mutex associated with a vnode' page.

Reviewed by: jilles (previous version, supposedly the objection was fixed)
Discussed with: brooks, Martin Simmons <martin@lispworks.com> (some aspects)
Tested by: pho
Sponsored by: The FreeBSD Foundation

show more ...

MFH

Sponsored by: The FreeBSD Foundation

If off-page lookup failed, there is no memory to perform
shared_mutex_init() upon.

Sponsored by: The FreeBSD Foundation

MFH

Sponsored by: The FreeBSD Foundation

Use __FBSDID() for .c files from lib/libthr/thread.

Sponsored by: The FreeBSD Foundation

Assert that the lock objects put into the off-page, fit into the page.

Sponsored by: The FreeBSD Foundation

MFH

Sponsored by: The FreeBSD Foundation

Apparently there are some popular programs around which assume that it
is safe to call pthread_mutex_init() on the same shared mutex several
times. POSIX claims that the behaviour in this case is un

Apparently there are some popular programs around which assume that it
is safe to call pthread_mutex_init() on the same shared mutex several
times. POSIX claims that the behaviour in this case is undefined.

Make this working by only allowing one caller to initialize the mutex.
Other callers either see already completed initialization and do
nothing, or busy-loop yielding while designated initializer finishes.
Also make the API requirements loose by initializing mutexes on other
pthread_mutex*() calls if they see uninitialized shared mutex.

Only mutexes provide the hack for now, but it could be also
implemented for other process shared primitives from libthr.

Reported and tested by: "Oleg V. Nauman" <oleg@opentransfer.com>
Sponsored by: The FreeBSD Foundation

show more ...

Provide more information on failing checks in mutex_assert_is_owned()
and mutex_assert_not_owned(). snprintf() use in this context should
be safe.

Sponsored by: The FreeBSD Foundation

Merge ^/head r296007 through r296368.

MFH

Sponsored by: The FreeBSD Foundation

Implement process-shared locks support for libthr.so.3, without
breaking the ABI. Special value is stored in the lock pointer to
indicate shared lock, and offline page in the shared memory is
alloca

Implement process-shared locks support for libthr.so.3, without
breaking the ABI. Special value is stored in the lock pointer to
indicate shared lock, and offline page in the shared memory is
allocated to store the actual lock.

Reviewed by: vangyzen (previous version)
Discussed with: deischen, emaste, jhb, rwatson,
Martin Simmons <martin@lispworks.com>
Tested by: pho
Sponsored by: The FreeBSD Foundation

show more ...

Merge sync of head

MFH: r278968-r280640

Sponsored by: The FreeBSD Foundation

Merge from head

Merge r278538 through r279514.

Merge ^/head r279163 through r279308.

Propagate errors from _thr_umutex_unlock2 through mutex_unlock_common.

Errors from _thr_umutex_unlock2 should "never happen" in normal
circumstances. If they do, however, return them to the applica

Propagate errors from _thr_umutex_unlock2 through mutex_unlock_common.

Errors from _thr_umutex_unlock2 should "never happen" in normal
circumstances. If they do, however, return them to the application
so it can fail early and loudly. Hiding the errors will only delay
the inevitable failure, making it harder to find and diagnose.

Submitted by: Eric van Gyzen <eric_van_gyzen@dell.com>
Obtained from: Dell Inc.
PR: 198914
MFC after: 1 week

show more ...

MFC @ r241285

IFC @ r242684

Sync from head

Merge head r233826 through r240095.