threads_win: fix improper cast to long * instead of LONG *

InterlockedExchangeAdd expects arguments of type LONG *, LONG
but the int arguments were improperly cast to long *, long

threads_win: fix improper cast to long * instead of LONG *

InterlockedExchangeAdd expects arguments of type LONG *, LONG
but the int arguments were improperly cast to long *, long

Note:
- LONG is always 32 bit
- long is 32 bit on Win32 VC x86/x64 and MingW-W64
- long is 64 bit on cygwin64

Signed-off-by: Georgi Valkov <gvalkov@gmail.com>

Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24941)

show more ...

threads: follow formatting rules

Adjust long lines and correct padding in preprocessor lines to
match the formatting rules

Signed-off-by: Georgi Valkov <gvalkov@gmail.com>

threads: follow formatting rules

Adjust long lines and correct padding in preprocessor lines to
match the formatting rules

Signed-off-by: Georgi Valkov <gvalkov@gmail.com>

Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24941)

show more ...

Detect MinGW 32 bit for NO_INTERLOCKEDOR64

Builds using 32 bit MinGW will fail, due to the same reasoning described in commit 2d46a44ff24173d2cf5ea2196360cb79470d49c7.

CLA: trivial

Detect MinGW 32 bit for NO_INTERLOCKEDOR64

Builds using 32 bit MinGW will fail, due to the same reasoning described in commit 2d46a44ff24173d2cf5ea2196360cb79470d49c7.

CLA: trivial

Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25025)

show more ...

Fix typing on call to interlockedExchange for windows

mingw is complaining on builds about the use of InterlockedExchange on a
uint32_t type, as the input parameter here is expected to b

Fix typing on call to interlockedExchange for windows

mingw is complaining on builds about the use of InterlockedExchange on a
uint32_t type, as the input parameter here is expected to be LONG
(defined as signed 32 bit on all versions of windows).

the input value (reader_idx) will never grow larger than the group size
of the lock (nominally 2, but always a reasonably small value), so it
should be safe to just cast it to the appropriate type here.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/25015)

show more ...

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 thread

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)

show more ...

threads_win: fix build error with mingw64

This fixes a build error regression on mingw64 introduced by me in
16beec98d26644b96d57bd8da477166d0bc7d05c

In get_hold_current_qp, uin

threads_win: fix build error with mingw64

This fixes a build error regression on mingw64 introduced by me in
16beec98d26644b96d57bd8da477166d0bc7d05c

In get_hold_current_qp, uint32_t variables were improperly
used to hold the value of reader_idx, which is defined as long int.
So I used CRYPTO_atomic_load_int, where a comment states
On Windows, LONG is always the same size as int

There is a size confusion, because
Win32 VC x86/x64: LONG, long, long int are 32 bit
MingW-W64: LONG, long, long int are 32 bit
cygwin64: LONG is 32 bit, long, long int are 64 bit

Fix:
- define reader_idx as uint32_t
- edit misleading comment, to clarify:
On Windows, LONG (but not long) is always the same size as int.

Fixes the following build error, reported in [1].
crypto/threads_win.c: In function 'get_hold_current_qp':
crypto/threads_win.c:184:32: error: passing argument 1 of 'CRYPTO_atomic_load_int' from incompatible pointer type [-Wincompatible-pointer-types]
184 | CRYPTO_atomic_load_int(&lock->reader_idx, (int *)&qp_idx,
| ^~~~~~~~~~~~~~~~~
| |
| volatile long int *

[1] https://github.com/openssl/openssl/pull/24405#issuecomment-2211602282

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)

show more ...

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

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)

show more ...

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.or

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 d38d2642287ef9a22f20e662a19c217c227043a6)

show more ...

threads_win: fix build error with VS2010

VC 2010 or earlier compilers do not support static inline.
To work around this problem, we can use the ossl_inline macro.

Fixes:
cry

threads_win: fix build error with VS2010

VC 2010 or earlier compilers do not support static inline.
To work around this problem, we can use the ossl_inline macro.

Fixes:
crypto\threads_win.c(171) : error C2054: expected '(' to follow 'inline'
crypto\threads_win.c(172) : error C2085: 'get_hold_current_qp' : not in formal parameter list
crypto\threads_win.c(172) : error C2143: syntax error : missing ';' before '{'
crypto\threads_win.c(228) : warning C4013: 'get_hold_current_qp' undefined; assuming extern returning int
crypto\threads_win.c(228) : warning C4047: '=' : 'rcu_qp *' differs in levels of indirection from 'int'

Signed-off-by: Georgi Valkov <gvalkov@gmail.com>

Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24370)

show more ...

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

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)

show more ...

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 M

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)

show more ...

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,
becu

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)

show more ...

Fix duplicate mutex allocation in threads_win.c

Creating an rcu lock does a double allocation of the underlying mutex.
Not sure how asan didn't catch this, but we clearly have a duplicat

Fix duplicate mutex allocation in threads_win.c

Creating an rcu lock does a double allocation of the underlying mutex.
Not sure how asan didn't catch this, but we clearly have a duplicate
line here

Fixes #24085

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24086)

show more ...

Copyright year updates

Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355c1240653e320a3f6f8109c1f05f8c0)

Reviewed-by: Hugo Lan

Copyright year updates

Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355c1240653e320a3f6f8109c1f05f8c0)

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24034)

show more ...

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 implem

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)

show more ...

Copyright year updates


Reviewed-by: Richard Levitte <levitte@openssl.org>
Release: yes

Add note about Windows LONG

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20856)

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/pu

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)

show more ...

VC++ 2010 x86 compilers do not have InterlockedOr64

The changes from the following commit should also apply to
Visual Studio 2010
https://github.com/openssl/openssl/commit/2d46a44ff2

VC++ 2010 x86 compilers do not have InterlockedOr64

The changes from the following commit should also apply to
Visual Studio 2010
https://github.com/openssl/openssl/commit/2d46a44ff24173d2cf5ea2196360cb79470d49c7#r104867505

Fixes build errors: undefined symbol InterlockedOr64
on Windows 2003, Visual Studio 2010 for x86 target.

CLA: trivial

Signed-off-by: Georgi Valkov <gvalkov@gmail.com>

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20557)

show more ...

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>

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)

show more ...

VC++ 2008 or earlier x86 compilers do not have an inline implementation of InterlockedOr64 for 32bit and will fail to run on Windows XP 32bit.
See: https://docs.microsoft.com/en-us/cpp/intrinsics

VC++ 2008 or earlier x86 compilers do not have an inline implementation of InterlockedOr64 for 32bit and will fail to run on Windows XP 32bit.
See: https://docs.microsoft.com/en-us/cpp/intrinsics/interlockedor-intrinsic-functions#requirements
To work around this problem, we implement a manual locking mechanism for only VC++ 2008 or earlier x86 compilers.

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18856)

show more ...

Explicitly #include <synchapi.h> is unnecessary

The header is already included by <windows.h> for WinSDK 8 or later.
Actually this causes problem for WinSDK 7.1 (defaults for VS2010) tha

Explicitly #include <synchapi.h> is unnecessary

The header is already included by <windows.h> for WinSDK 8 or later.
Actually this causes problem for WinSDK 7.1 (defaults for VS2010) that
it does not have this header while SRW Locks do exist for Windows 7.

CLA: trivial

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16603)

show more ...

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

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)

show more ...

Update copyright year

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14512)

Use read/write locking on Windows

Fixes #13914

The "SRWLock" synchronization primitive is available in Windows Vista
and later. CRYPTO_THREAD functions now use SRWLock function

Use read/write locking on Windows

Fixes #13914

The "SRWLock" synchronization primitive is available in Windows Vista
and later. CRYPTO_THREAD functions now use SRWLock functions when the
target operating system supports them.

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14381)

show more ...