79 Commits

Author	SHA1	Message	Date
Bernd Edlinger	39960bb02b	Do not use RW mutexes on RISC-V arch ... For unknown reasons using RW mutexes on RISC-V arch seems to be broken, at least with glibc. Fixes #28550 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com> (Merged from https://github.com/openssl/openssl/pull/28634) (cherry picked from commit bea53924ce)	2025-09-23 13:05:31 -04:00
Bernd Edlinger	7be0b5cc8a	Fix another memory order issue ... this adds another release/acquire link between update_qp and get_hold_current_qp via the reader_idx because the current one which is based on the qp users count is only preventing a race condition, but does not help when the reader acquires the next qp. Fixes #27267 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/28585) (cherry picked from commit d296f96533)	2025-09-19 07:04:47 +02:00
Bernd Edlinger	5b5459f89a	Do some more cleanup in the RCU code ... Only a minimum of 2 qp's are necessary: one for the readers, and at least one that writers can wait on for retirement. There is no need for one additional qp that is always unused. Also only one ACQUIRE barrier is necessary in get_hold_current_qp, so the ATOMIC_LOAD of the reader_idx can be changed to RELAXED. And finally clarify some comments. Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/27012) (cherry picked from commit a532f2302d)	2025-03-18 18:52:53 +01:00
Bernd Edlinger	9cb6508f29	Fix a memory order issue with weakly ordered systems ... this adds a dummy atomic release operation to update_qp, which should make sure that the new value of reader_idx is visible in get_hold_current_qp, directly after incrementing the users count. Fixes: #26875 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Neil Horman <nhorman@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26964) (cherry picked from commit 4a1a7fe5ce)	2025-03-17 08:23:10 -04:00
Andrew Dinh	6278daa9bf	Fix RCU TODOs ... - Update allocate_new_qp_group to take unsigned int - Move id_ctr in rcu_lock_st for better stack alignment Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Neil Horman <nhorman@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26972) (cherry picked from commit 7097d2e00e)	2025-03-12 12:17:29 -04:00
Bernd Edlinger	a464113b2a	RCU: Ensure that qp's are actually retired in order ... The current retirement code for rcu qp's has a race condition, which can cause use-after-free errors, but only if more than 3 QPs are allocated, which is not the default configuration. This fixes an oversight in commit 5949918f9a ("Rework and simplify RCU code") Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26952) (cherry picked from commit 6e7be995fd)	2025-03-05 16:04:34 +01:00
Bernd Edlinger	1a6e903562	Revert wrong macos RCU fix ... This reverts #23974 which seems to be no longer needed now, due to other fixes nearby. Most likely the change did just slightly decrease the performance of the reader threads, and did therefore create the wrong impression that it fixed the issue. Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26881) (cherry picked from commit a6f512a1e6)	2025-02-25 10:38:40 +01:00
Bernd Edlinger	ba4e15d7cb	Make CRYPTO_atomic_load/store use the same preprocessor guards ... as the other CRYPTO_atomic_X functions. All CRYPTO_atomic functions should use the same logic here, just in case... Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Neil Horman <nhorman@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26815) (cherry picked from commit 3240427a85)	2025-02-21 14:06:17 +01:00
Bernd Edlinger	a523906fa5	Cleanup atomic fallbacks in threads_pthread.c ... the unused atomic stub functions make clang issue unused function warnings -Wunused-function Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Neil Horman <nhorman@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26815) (cherry picked from commit eacf14594d)	2025-02-21 14:06:15 +01:00
Neil Horman	ec7c1ca879	Don't use __ATOMIC_ACQ_REL on older compilers ... Older compilers don't always support __ATOMIC_ACQ_REL, use a lock where they don't Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/26747) (cherry picked from commit 7d284560a0)	2025-02-16 15:32:15 -05:00
Bernd Edlinger	51f69325e8	Rework and simplify RCU code ... Use __ATOMIC_RELAXED where possible. Dont store additional values in the users field. Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26690) (cherry picked from commit 5949918f9a)	2025-02-13 20:26:14 +01:00
Bernd Edlinger	80040de935	Revert "rcu: Ensure that updates to the ID field of a qp don't lose refs" ... This reverts commit fbd34c03e3. Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26690) (cherry picked from commit 65787e2dc2)	2025-02-13 20:24:03 +01:00
openssl-machine	5f8049f2c5	Copyright year updates ... Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Release: yes	2025-02-11 14:27:50 +00:00
Neil Horman	9388dcf098	rcu: Ensure that updates to the ID field of a qp don't lose refs ... ppc64le occasionally still fails the threadstest on __rcu_torture From several days of debugging, I think I've landed on the problem. Occasionally, under high load I observe the following pattern CPU0 CPU1 update_qp get_hold_current_qp atomic_and_fetch(qp->users, ID_MASK, RELEASE) atomic_add_fetch(qp->users, 1, RELEASE atomic_or_fetch(qp->users, ID_VAL++, RELEASE) When this pattern occurs, the atomic or operation fails to see the published value of CPU1 and when the or-ed value is written back to ram, the incremented value in get_hold_current_qp is overwritten, meaning the hold that the reader placed on the rcu lock is lost, allowing the writer to complete early, freeing memory before a reader is done reading any held memory. Why this is only observed on ppc64le I'm not sure, but it seems like a pretty clear problem. fix it by implementing ATOMIC_COMPARE_EXCHANGE_N, so that, on the write side in update_qp, we can ensure that updates are only done if the read side hasn't changed anything. If it has, retry the operation. With this fix, I'm able to run the threads test overnight (4000 iterations and counting) without failure. Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26478) (cherry picked from commit fbd34c03e3)	2025-01-22 20:18:01 +01:00
Neil Horman	31cbf5f732	Fix premature reuse of qp's in rcu locks ... An intermittent failure was noted on our new ppc64le CI runner, in which what appeared to be a corrupted or invalid value getting returned from a shared pointer under rcu protection Investigation showed that the problem was with our small number of qp's in a lock, and slightly incorrect accounting of the number of qp's available we were prematurely recycling qp's, which led in turn to premature completion of synchronization states, resulting in readers reading memory that may have already been freed. Fix it by: a) Ensuring that we account for the fact that the first qp in an rcu lock is allocated at the time the lock is created and b) Ensuring that we have a minimum number of 3 qp's: 1 that is free for write side allocation 1 that is in use by the write side currently 1 "next" qp that the read side can update while the prior qp is being retired With this change, the rcu threadstest runs indefinately in my testing Fixes #26356 Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26384) (cherry picked from commit 25f8e2c15b)	2025-01-14 11:44:13 +01:00
Tomas Mraz	c734897df9	Fix breakage on arm64_32 platforms ... We just avoid the special handling needed for Apple M1. Fixes #26135 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> (Merged from https://github.com/openssl/openssl/pull/26145) (cherry picked from commit 79c9cbbe1f)	2024-12-13 15:05:35 +01:00
Neil Horman	22ab18fa4f	Fix solaris build in CRYPTO_atomic_store api ... Misnamed variable, just correct it to dst Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/26075) (cherry picked from commit 4c04a19860)	2024-11-29 12:08:40 +01:00
Neil Horman	7408d58714	disable rwlocks on nonstop klt model ... It appears nonstops new threading model defines some level of rwlock pthread api, but its not working properly. Disable rwlocks for _KLT_MODEL_ for now Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> (Merged from https://github.com/openssl/openssl/pull/24969)	2024-07-31 08:05:53 -04:00
Neil Horman	3190f5c06b	Fix CRYPTO_atomic_store ... If the implementation of this function falls to using a pthread lock to update a value, it should be a write lock, not a read lock Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> (Merged from https://github.com/openssl/openssl/pull/24969)	2024-07-31 08:05:53 -04:00
Georgi Valkov	ce6b2f9826	threads_pthread, threads_win: improve code consistency ... Improve code consistency between threads_pthread.c and threads_win.c threads_pthread.c has good comments, let's copy them to threads_win.c In many places uint64_t or LONG int was used, and assignments were performed between variables with different sizes. Unify the code to use uint32_t. In 32 bit architectures it is easier to perform 32 bit atomic operations. The size is large enough to hold the list of operations. Fix result of atomic_or_uint_nv improperly casted to int * instead of int. Note: In general size_t should be preferred for size and index, due to its descriptive name, however it is more convenient to use uint32_t for consistency between platforms and atomic calls. READER_COUNT and ID_VAL return results that fit 32 bit. Cast them to uint32_t to save a few CPU cycles, since they are used in 32 bit operations anyway. TODO: In struct rcu_lock_st, qp_group can be moved before id_ctr for better alignment, which would save 8 bytes. allocate_new_qp_group has a parameter count of type int. Signed values should be avoided as size or index. It is better to use unsigned, e.g uint32_t, even though internally this is assigned to a uint32_t variable. READER_SIZE is 16 in threads_pthread.c, and 32 in threads_win.c Using a common size for consistency should be prefered. Signed-off-by: Georgi Valkov <gvalkov@gmail.com> Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24803)	2024-07-17 16:37:07 +02:00
Georgi Valkov	16beec98d2	threads_win: fix build error with VS2010 x86 ... InterlockedAnd64 and InterlockedAdd64 are not available on VS2010 x86. We already have implemented replacements for other functions, such as InterlockedOr64. Apply the same approach to fix the errors. A CRYPTO_RWLOCK rw_lock is added to rcu_lock_st. Replace InterlockedOr64 and InterlockedOr with CRYPTO_atomic_load and CRYPTO_atomic_load_int, using the existing design pattern. Add documentation and tests for the new atomic functions CRYPTO_atomic_add64, CRYPTO_atomic_and Fixes: libcrypto.lib(libcrypto-lib-threads_win.obj) : error LNK2019: unresolved external symbol _InterlockedAdd64 referenced in function _get_hold_current_qp libcrypto.lib(libcrypto-lib-threads_win.obj) : error LNK2019: unresolved external symbol _InterlockedOr referenced in function _get_hold_current_qp libcrypto.lib(libcrypto-lib-threads_win.obj) : error LNK2019: unresolved external symbol _InterlockedAnd64 referenced in function _update_qp libcrypto.lib(libcrypto-lib-threads_win.obj) : error LNK2019: unresolved external symbol _InterlockedOr64 referenced in function _ossl_synchronize_rcu Signed-off-by: Georgi Valkov <gvalkov@gmail.com> Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24405)	2024-07-01 10:02:02 +02:00
Neil Horman	f7252d736d	Some minor nit corrections in the thread code for rcu ... Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24630) (cherry picked from commit d38d264228)	2024-06-20 16:56:39 +02:00
sanumesh	36ba419286	threads_pthread.c: change inline to ossl_inline ... Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24502)	2024-05-28 17:19:18 +02:00
Neil Horman	7e45ac6891	Add CRYPTO_atomic_store api ... Generally we can get away with just using CRYPTO_atomic_load to do stores by reversing the source and target variables, but doing so creates a problem for the thread sanitizer as CRYPTO_atomic_load hard codes an __ATOMIC_ACQUIRE constraint, which confuses tsan into thinking that loads and stores aren't properly ordered, leading to RAW/WAR hazzards getting reported. Instead create a CRYPTO_atomic_store api that is identical to the load variant, save for the fact that the value is a unit64_t rather than a pointer that gets stored using an __ATOMIC_RELEASE constraint, satisfying tsan. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/23671)	2024-04-24 12:03:03 +10:00
Neil Horman	f39a862818	Fix list appending in win ossl_rcu_call ... The ossl_rcu_call function for windows creates a linked list loop. fix it to work like the pthread version properly Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/23671)	2024-04-24 12:03:03 +10:00
Neil Horman	3bcac46035	Make thread sanitizer cope with rcu locks ... This is unfortunate, but seems necessecary tsan in gcc/clang tracks data races by recording memory references made while various locks are held. If it finds that a given address is read/written while under lock (or under no locks without the use of atomics), it issues a warning this creates a specific problem for rcu, because on the write side of a critical section, we write data under the protection of a lock, but by definition the read side has no lock, and so rcu warns us about it, which is really a false positive, because we know that, even if a pointer changes its value, the data it points to will be valid. The best way to fix it, short of implementing tsan hooks for rcu locks in any thread sanitizer in the field, is to 'fake it'. If thread sanitization is activated, then in ossl_rcu_write_[lock|unlock] we add annotations to make the sanitizer think that, after the write lock is taken, that we immediately unlock it, and lock it right before we unlock it again. In this way tsan thinks there are no locks held while referencing protected data on the read or write side. we still need to use atomics to ensure that tsan recognizes that we are doing atomic accesses safely, but thats ok, and we still get warnings if we don't do that properly Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/23671)	2024-04-24 12:03:03 +10:00
Logan Upchurch	5454ef7cb3	crypto/threads_pthread.c: Fix typos found by codespell ... CLA: trivial Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24206)	2024-04-23 11:26:29 +02:00
Neil Horman	24d16d3a19	Make rcu_thread_key context-aware ... Currently, rcu has a global bit of data, the CRYPTO_THREAD_LOCAL object to store per thread data. This works in some cases, but fails in FIPS, becuase it contains its own copy of the global key. So 1) Make the rcu_thr_key a per-context variable, and force ossl_rcu_lock_new to be context aware 2) Store a pointer to the context in the lock object 3) Use the context to get the global thread key on read/write lock 4) Use ossl_thread_start_init to properly register a cleanup on thread exit 5) Fix up missed calls to OSSL_thread_stop() in our tests Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24162)	2024-04-19 09:22:53 -04:00
Richard Levitte	a02077d4d7	crypto/threads_pthread.c: refactor all atomics fallbacks for type safety ... The atomics fallbacks were using 'void *' as a generic transport for all possible scalar and pointer types, with the hypothesis that a pointer is as large as the largest possible scalar type that we would use. Then enters the use of uint64_t, which is larger than a pointer on any 32-bit system (or any system that has 32-bit pointer configurations). We could of course choose a larger type as a generic transport. However, that only pushes the problem forward in time... and it's still a hack. It's therefore safer to reimplement the fallbacks per type that atomics are used for, and deal with missing per type fallbacks when the need arrises in the future. For test build purposes, the macro USE_ATOMIC_FALLBACKS is introduced. If OpenSSL is configured with '-DUSE_ATOMIC_FALLBACKS', the fallbacks will be used, unconditionally. Fixes #24096 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24123)	2024-04-16 09:18:01 +02:00
Richard Levitte	81f393498b	crypto/threads_pthread.c: Cleanup misaligned preprocessor directives ... Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24123)	2024-04-16 09:18:01 +02:00
Neil Horman	f5b5a35c84	Ensure proper memory barriers around ossl_rcu_deref/ossl_rcu_assign_ptr ... Since the addition of macos14 M1 runners in our CI jobs we've been seeing periodic random failures in the test_threads CI job. Specifically we've seen instances in which the shared pointer in the test (which points to a monotonically incrementing uint64_t went backwards. From taking a look at the disassembled code in the failing case, we see that __atomic_load_n when emitted in clang 15 looks like this 0000000100120488 <_ossl_rcu_uptr_deref>: 100120488: f8bfc000 ldapr x0, [x0] 10012048c: d65f03c0 ret Notably, when compiling with gcc on the same system we get this output instead: 0000000100120488 <_ossl_rcu_uptr_deref>: 100120488: f8bfc000 ldar x0, [x0] 10012048c: d65f03c0 ret Checking the arm docs for the difference between ldar and ldapr: https://developer.arm.com/documentation/ddi0602/2023-09/Base-Instructions/LDAPR--Load-Acquire-RCpc-Register- https://developer.arm.com/documentation/dui0802/b/A64-Data-Transfer-Instructions/LDAR It seems that the ldar instruction provides a global cpu fence, not completing until all writes in a given cpus writeback queue have completed Conversely, the ldapr instruction attmpts to achieve performance improvements by honoring the Local Ordering register available in the system coprocessor, only flushing writes in the same address region as other cpus on the system. I believe that on M1 virtualized cpus the ldapr is not properly ordering writes, leading to an out of order read, despite the needed fencing. I've opened an issue with apple on this here: https://developer.apple.com/forums/thread/749530 I believe that it is not safe to issue an ldapr instruction unless the programmer knows that the Local order registers are properly configured for use on the system. So to fix it I'm proposing with this patch that we, in the event that: 1) __APPLE__ is defined AND 2) __clang__ is defined AND 3) __aarch64__ is defined during the build, that we override the ATOMIC_LOAD_N macro in the rcu code such that it uses a custom function with inline assembly to emit the ldar instruction rather than the ldapr instruction. The above conditions should get us to where this is only used on more recent MAC cpus, and only in the case where the affected clang compiler emits the offending instruction. I've run this patch 10 times in our CI and failed to reproduce the issue, whereas previously I could trigger it within 5 runs routinely. Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/23974)	2024-04-10 09:18:07 +02:00
Richard Levitte	b646179229	Copyright year updates ... Reviewed-by: Neil Horman <nhorman@openssl.org> Release: yes (cherry picked from commit 0ce7d1f355) Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24034)	2024-04-09 13:43:26 +02:00
Dimitri Papadopoulos	39fe3e5de1	Fix the grammar as suggsted in the review ... Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/23545)	2024-02-14 09:36:11 +01:00
Dimitri Papadopoulos	f7241edda4	Fix new typos found by codespell ... Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/23545)	2024-02-14 09:36:11 +01:00
Neil Horman	d0e1a0ae70	RCU lock implementation ... Introduce an RCU lock implementation as an alternative locking mechanism to openssl. The api is documented in the ossl_rcu.pod file Read side implementaiton is comparable to that of RWLOCKS: ossl_rcu_read_lock(lock); < critical section in which data can be accessed via ossl_derefrence > ossl_rcu_read_unlock(lock); Write side implementation is: ossl_rcu_write_lock(lock); < critical section in which data can be updated via ossl_assign_pointer and stale data can optionally be scheduled for removal via ossl_rcu_call > ossl_rcu_write_unlock(lock); ... ossl_synchronize_rcu(lock); ossl_rcu_call fixup Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22729)	2024-02-01 08:33:25 -05:00
Matt Caswell	da1c088f59	Copyright year updates ... Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes	2023-09-07 09:59:15 +01:00
Neil Horman	e4d808652b	issue-21718: remove setting of PTHREAD_MUTEX_NORMAL ... issue: https://github.com/openssl/openssl/issues/21718 build break reported: crypto/threads_pthread.c:76:5: warning: implicit declaration of function 'pthread_mutexattr_settype'; did you mean 'pthread_mutexattr_destroy'? [-Wimplicit-function-declaration] 76 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL); | ^~~~~~~~~~~~~~~~~~~~~~~~~ | pthread_mutexattr_destroy crypto/threads_pthread.c:76:38: error: 'PTHREAD_MUTEX_NORMAL' undeclared (first use in this function); did you mean 'PTHREAD_MUTEX_TIMED_NP'? 76 | pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL); | ^~~~~~~~~~~~~~~~~~~~ | PTHREAD_MUTEX_TIMED_NP This occurs because PTHREAD_MUTEX_NORMAL is only defined in glibc if __USE_UNIX98 or __USE_XOPEN2K8 is defined, which is derived from setting __USE_POSIX_C_SOURCE or __XOPEN_SOURCE is selected in the glibc feature set for a build. Since openssl selects no specific feature set from glibc, the build break occurs We could select a feature set of course, but that seems like a significant discussion to have prior to doing so. Instead, the simpler solution is to just not set the mutex type at all, given that pthread_mutexattr_init sets the default mutex type, which should be akin to normal anyway (i.e. no mutex error checking or allowed-recursive behavior) Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21726)	2023-08-17 08:02:15 +01:00
Hugo Landau	629b408c12	QUIC: Fix bugs where threading is disabled ... Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20856)	2023-05-24 10:34:54 +01:00
Tomas Mraz	894f2166ef	CRYPTO_THREAD_lock_new(): Avoid infinite recursion on allocation error ... Fixes #19334 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19335)	2022-10-05 10:20:10 +11:00
Matt Caswell	fecb3aae22	Update copyright year ... Reviewed-by: Tomas Mraz <tomas@openssl.org> Release: yes	2022-05-03 13:34:51 +01:00
Kirill A. Korinsky	d39de4792d	Never use `__atomic_*` on macOS 10.7 and 10.8 ... macOS 10.7 and 10.8 had a bit wired clang which is detected as `__GNUC__` which has `__ATOMIC_ACQ_REL` but it excepts one option at `__atomic_is_lock_free` instead of 2. This prevents OpenSSL to be compiled on such systems. Fixes: #18055 Signed-off-by: Kirill A. Korinsky <kirill@korins.ky> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/18056)	2022-04-22 15:25:20 +02:00
Matt Caswell	5979596247	Some platforms don't have pthread_atfork ... We've had a report of a linker failure on some platforms (this one was linux ARM) that apparently did not have pthread_atfork. It's strange that this has not been reported before but the simplest solution is just to remove this from the library since it isn't really used anyway. Currently it is called to set up the fork handlers OPENSSL_fork_prepare, OPENSSL_fork_parent and OPENSSL_fork_child. However all of those functions are no-ops. This is a remnant from earlier code that got removed. We can safely remove it now. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/17842)	2022-03-10 13:22:28 +11:00
Randall S. Becker	6870c1e7b7	Defined out MUTEX attributes not available on NonStop SPT Threads. ... Standard Posix Threads (SPT) Threads are an older separate branch of pthreads that do not support some of the capabilities in the current Posix User Threads (PUT). The change also includes a rename of the close field of OSSL_STORE_LOADER which was causing preprocessor conflicts. Fixes #15885 Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15886)	2021-07-02 12:33:45 +10:00
Randall S. Becker	0d40745671	Add assert.h to threads_pthread.c for NonStop thread compiles. ... Fixes: #15809 Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15812)	2021-06-23 17:34:06 +02:00
Rich Salz	cd3f8c1b11	Always check CRYPTO_LOCK_{read,write}_lock ... Some functions that lock things are void, so we just return early. Also make ossl_namemap_empty return 0 on error. Updated the docs, and added some code to ossl_namemap_stored() to handle the failure, and updated the tests to allow for failure. Fixes: #14230 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14238)	2021-03-14 15:33:34 +10:00
Rich Salz	3d8905f859	Fix error-checking compiles for mutex ... Fixes: #14229 Reviewed-by: Kurt Roeckx <kurt@roeckx.be> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14264)	2021-03-12 08:00:18 +10:00
Matt Caswell	a28d06f3e9	Update copyright year ... Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14235)	2021-02-18 15:05:17 +00:00
Rich Salz	e60147fe74	Don't make pthreads mutexes recursive. ... Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13924)	2021-02-05 10:29:44 +00:00
Matt Caswell	d5e742de65	Add some more CRYPTO_atomic functions ... We add an implementation for CRYPTO_atomic_or() and CRYPTO_atomic_load() Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/13733)	2020-12-31 13:14:38 +01:00
Matt Caswell	c739222b5a	Fix no-threads ... Make OPENSSL_fork_prepare() et al always available even in a no-threads build. These functions are no-ops anyway so this shouldn't make any difference. This fixes an issue where the symbol_presence test fails in a no-threads build. This is because these functions have not been marked in libcrypto.num as being dependent on thread support. Enclosing the declarations of the functions in the header with an appropriate guard does not help because we never define OPENSSL_NO_THREADS (we define the opposite OPENSSL_THREADS). This confuses the scripts which only consider OPENSSL_NO_* guards. The simplest solution is to just make them always available. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13647)	2020-12-14 10:45:27 +10:00