It's currently possible to generate a socket event when a non-blocking socket is closed:
1. _pending is set to 0 in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/TCPSocket.cpp#L22
when the socket is created.
2. close() calls event() in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/Socket.cpp#L66
3. event() increments _pending, and since _pending is 1 it will call _callback() in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/TCPSocket.cpp#L167
However, if send() (for example) is called, this can happen:
- send() is called and sets _pending to 0.
- when the data is sent, event() is called, which sets _pending to 1 and calls _callback().
- if close() is called at this point, there won't be an event generated for close() anymore,
since _pending will be set to 2.
Same thing for recv. Also, same thing for TCPServer and UDPSocket.
This PR changes the initial value of _pending to 1 instead of 0, so that
events are never generated for close().
The equeue_chain function is supposed to unchain the event queue
from whatever queue it is chained to when passed a null target.
Internally, this is accomplished by just calling equeue_background
with null and letting the previously registered update function
clean up the chaining.
However, equeue_chain did not appropriately check for null, causing
it to unnecessarily allocate memory and leaving the update function
in a bad state. Fixed with a simple null check.
The configuration option for the mbed TLS specific hardware acceleration
has to be in the macro section and not in the device capabilities
section in targets.json.
The option has also been renamed to better reflect its function.
Add data and instruction synchronization barriers to prevent
interrupts from occurring after NVIC_DisableIRQ is called. This
is a backport of changes made in CMSIS_5.
The crypto hardware acceleration might require defining a lot of mbed
TLS specific macros. Enumerating all of them in `targets.json` creates
too much noise, therefore we move it into a target specific mbed TLS
header.
The target with crypto hardware acceleration has to
- indicate its capability in `targets.json` by adding "CRYPTO"
to the "device_has" section
- has to define his crypto hardware acceleration related macros
in an `mbedtls_device.h` header
- place the `mbedtls_device.h` file in the
`features/mbedtls/targets/TARGET_XXXX`
directory specific to the target
Martin Kojtal
Bogdan Marinescu
Martin Kojtal
Mohammad Azim Khan
Mika Leppänen
Seppo Takalo
Simon Hughes
Anna Bridge
andreas.larsson
Russ Butler
Alessandro Angelino
Christopher Haster
Jimmy Brisson
Mizuho
Janos Follath
Sam Grove
Russ Butler
bcostm