This assert cannot be turned on, as `pdu` will be NULL sometimes. This
is okay, it just means that the current channel doesn't have anything to
send and that we should probably try another one.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
When user_data is not zeroed-out, the API returns an error. Downgrade
the API error to a warning log instead.
Introducing this check (#76489) broke a few PTS tests, as user_data is
not initialized by `net_buf_alloc()`. Doing so is in discussion:
https://github.com/zephyrproject-rtos/zephyr/issues/77088
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Convert users of net_buf_put() and net_buf_get() functions to use
non-wrapped putters and getters k_fifo_put() and k_fifo_get().
Special handling of net_bufs in k_fifos is no longer needed after commit
3d306c181f, since these actions are now
atomic regardless of any net_buf fragments.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
It was not being set, and thus if the user_data contained garbage from
before, then conn.c would attempt to call that garbage.
Static channels don't have this issue, as every "SDU" fits into one PDU.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Huajiang Zheng <nxf88597@lsv051208.swis.nl-cdc01.nxp.com>
Storing stuff in user_data? That's a paddlin'
We have been debugging issue after issue because ownership of this
"user" data is not clearly defined. Now it is. L2CAP owns the user_data
field entirely, as soon as `send()` is called.
Also add a warning and retval using CHECKIF.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Utilize a code spell-checking tool to scan for and correct spelling errors
in all files within the subsys/bluetooth/host directory.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
Similar to ISO connections, ACL connections are not serviced as fast as
possible. Change this, and try to send as much as we have resources for.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
We can get rid of the view pool for SDU segments :)
We have to make the code slightly more complex :'(
The basic idea is always giving the original SDU buffer to `conn.c` for it
to pull ACL fragments from.
In order to do this, we need to add the PDU headers just-in-time.
`bt_l2cap_send_pdu()` does not add them before putting the PDU on the queue
anymore. They are added by `l2cap_data_pull()` right before the data leaves
`l2cap.c` for `conn.c`.
We also have to inform `conn.c` "out of band" of the real L2CAP PDU size so
it doesn't fragment across segment boundaries. This oob is the new `length`
parameter to the `.pull()` method.
This is the added complexity mentioned above.
Since SDU segmentation concerns only LE-L2CAP, ISO and Classic L2CAP don't
need this extra logic.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This API replaces `bt_l2cap_send()` and `bt_l2cap_send_cb()`.
The difference is that it takes the `struct bt_l2cap_le_chan` object
directly instead of a connection + CID.
We need the channel object in order to put the PDU on the TX queue. It
is inefficient to do a search for every PDU when the caller knows the
channel object's address and can just pass it down.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
The current TX pattern in the host is to try to push a buffer through all
the layers up until it is ingested by the controller.
Since sending can fail at any layer, we need error-handling and separate
retry logic on pretty much all layers. That logic obscures the "happy path"
for people trying ot understand the code.
This commit inverts the control, in a way that doesn't require changing the
host or HCI driver API (yet):
Layers don't send buffers synchronously, they instead put their buffer in a
private queue of their own and raise a TX flag on the lower layer. Think of
it as a `READY` interrupt line that has to be serviced by the lower layer.
Sending is now non-blocking, rate depends on the size of buffer pools.
There is a single TX processing function. This can be thought as the
Interrupt Service Routine that will handle the `READY` interrupt from the
layers above.
That `tx_processor()` will then attempt to allocate enough resources in
order to send the buffer through to the controller. This allocation logic
does not block.
After acquiring all the resources, the TX processor will attempt to pull
data from the upper layer. The upper layer has to figure out which buffer
to pass to the controller. This is a good spot to put scheduling or QoS
logic in the upper layer.
Notes:
- user-facing API for tuning QoS will be implemented in a future patch
- this scheme could (and probably will) be extended to upper layers (e.g.
ATT, L2CAP CoC segmentation).
- this patch removes the `pending_no_cb()` memory optimization for
clarity/correctness. It might get re-implemented after a stabilization
period. Hopefully with more documentation.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Instead of allocating segments/fragments and copying data into them, we
allocate segments as "views" (or slices) into the original buffer.
The view also gives access to the headroom of the original buffer, allowing
lower layers to push their headers.
We choose not to allow multiple views into the same buffer as the headroom
of a view would overlap with the data of the previous view.
We mark a buffer as locked (or "in-view") by temporarily setting its
headroom to zero. This effectively stops create_view because the requested
headroom is not available.
Each layer that does some kind of fragmentation and wants to use views for
that needs to maintain a buffer pool (bufsize 0, count = max views) and a
metadata array (size = max views) for the view mechanism to work.
Maximum number of views: number of parallel buffers from the upper layer,
e.g. number of L2CAP channels for L2CAP segmentation or number of ACL
connections for HCI fragmentation.
Reason for the change:
1. prevent deadlocks or (ATT/SMP) requests timing out
2. save time (zero-copy)
3. save memory (gets rid of frag pools)
L2CAP CoC: would either allocate from the `alloc_seg` application callback,
or worse _steal_ from the same pool, or allocate from the global ACL pool.
Conn/HCI: would either allocate from `frag_pool` or the global ACL pool.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
These are safety checks to guard against silent data corruption. The
implementation currently does not clobber bufs, but soon it will. The
bufs will be zero-copy segmented and fragmented, which involves
overwriting already-sent contents with headers for the next fragment.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
We can (and do) open multiple channels with a single L2CAP command. If the
remote doesn't support dynamic channels at all, then it sends back a
REJECT_RSP.
We only destroyed the first channel that matched the command PDU
identifier. Fix that and remove all channels that match.
Also add a test that verifies the patch.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
We could start executing the work item after the channel has been
disconnected or destroyed, due to a race condition.
Double-check we are connected before attempting to send data.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
`ret` is the amount sent from the current buffer. `sent` contains the
total amount that was transferred in the while loop.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
It's needless complexity, and the terminology clashes with
Bluetooth (HCI frags).
It has one user, IPSP, that is going away soon.
Removing frag support will allow a future optimization, removing the
need for HCI and L2CAP fragment buffer pools, saving memory.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
During local testing with UBSAN enabled, warning was reported:
bluetooth/host/l2cap.c:980:25: runtime error: member access
within null pointer of type 'struct k_work_q'
It turned out that le_chan->rtx_work.queue can be NULL.
Since null-pointer dereference is a UB, additional check
was added to ensure we don't access
`le_chan->rtx_work.queue->thread` when
`le_chan->rtx_work.queue == NULL`
The same changes applied to l2cap_br.c
Signed-off-by: Ivan Iushkov <ivan.iushkov@nordicsemi.no>
The only thing we put in there is the CID and that fits comfortably into
the (at least) 4-byte void pointer `user_data`.
This removes the dependency between `CONFIG_BT_ATT_TX_COUNT` and
`CONFIG_BT_L2CAP_TX_BUF_COUNT` since previously there was still a need
for an L2CAP context for every TX'd buffer.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Fix the handling of buffers with fragments. What seems to have been
broken is the metadata reference that was not passed to the next frag in
the chain.
Add a test to regression too.
The main user of this is IPSP.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Remove the logic for adding the SDU length when allocating segments. That
section was dead code after the recent patches.
Inline the remainder of the logic into `l2cap_chan_le_send()`.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Always pull from the channel queue from the system workqueue context.
This simplifies debugging.
This also allows us to remove `sent` from the metadata struct.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Separate most of the param checking in `bt_l2cap_chan_send()`, with the
logic in `bt_l2cap_dyn_chan_send()`.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Previously it was not always possible to prepend the header.
It was not possible if the application neglected to reserve the space
for headers. This is bad because it forces a buffer segment allocation
even if the buffer had enough room for the headers. E.g. a payload of 10
bytes in a netbuf of 30 bytes would have been segmented.
We now explicitly reject the buffer if it does not have the headroom.
This allows us to do a nice thing; simplify L2CAP segmentation.
We convert the SDU from the application into a PDU payload, by
prepending the SDU header, i.e. the SDU length in the original buffer.
This PDU payload is ready to be chunked into PDUs without having to keep
track of where in the SDU we are. This has the effect of removing a
bunch of logic in the segmentation machine.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
It seems like a nice idea at first, but leads to hard-to-debug
situations for the application.
The previous behavior can be implemented by the app by defining
`alloc_seg` and allocating from the same pool as `buf`.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Makes it clearer what that bit means:
If set, the channel has capacity to send at least one PDU.
If unset, the channel ran out of credits and won't be able to send
anything until the peer sends credits back.
Also add debug logs.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Prevents confusion, as the similarly-named `l2cap_send()` also unrefs the
buffer if it fails to send.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Replace hardcoded value `8` with `CONFIG_BT_CONN_TX_USER_DATA_SIZE`,
that is `8` but is going to change.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Fix l2cap error handling generally not properly disposing of tx buffers for
enhanced channels; Any callbacks have to be called and the
l2cap_tx_meta_data has to be freed
Signed-off-by: Troels Nilsson <trnn@demant.com>
Add a pointer to the associated server structure in the L2CAP accept()
callback. This allows the callee to know which server an incoming L2CAP
connection is associated with.
Signed-off-by: Donatien Garnier <donatien.garnier@blecon.net>
bt_l2cap_chan_send_sdu previously returned the number of bytes sent
in the last sent sdu buf fragment or 0 if the buf has only
one fragment. bt_l2cap_chan_send_sdu now returns the total data
bytes sent from the buf.
Signed-off-by: Tom Finet <tom.codeninja@gmail.com>
Fix a bunch of mismatched CONTAINER_OF, few missing
k_work_delayable_from_work conversions but also many
bt_l2cap_le_chan/bt_l2cap_chan and few others.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Upon receiving a L2CAP PDU, only send credits back if the L2CAP channel
hasn't been disconnected. The recv() callback called from
l2cap_chan_le_recv() can trigger a disconnect, which would cause an
assert failure when attempting to send credits back.
Signed-off-by: Donatien Garnier <donatien.garnier@blecon.net>
This was recently refactored (in #58440). But it introduced a bug in which
some channels were connected but not the whole list asked for by the peer.
In that case, `result` will not be `SUCCESS` but we still want to call the
`connected` callback as the peer will consider those channels to be
connected when we send the response.
The symptom is that EATT channels are being instantiated, but not
considered connected (ie. usable by the stack).
Also introduce a test that has asymmetric channel resources (5 on central
vs 2 on peripheral) to reproduce the bug.
Fixes#60212
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
