[nrf fromtree] Bluetooth: att: don't re-use the ATT buffer for confir…

…mations

If the peer is a zephyr host, there is no problem, as the Zephyr
host limits sending parallel REQs and INDs.

But the spec allows sending those in parallel, and it may end up that
the re-used REQ buffer hasn't been destroyed when an indication comes.

Only re-use the buffer when enqueuing ATT responses.

This means that we may run out of buffers if the peer sends too many
indications and our application also sends a lot of commands/notifications.

The rationale for this is that having to handle a lot of requests is a
more plausible scenario (e.g. being discovered by multiple peers) than
handling lots of parallel indications.

Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
(cherry picked from commit 7093538)

subsys/bluetooth/host/att.c

@@ -670,11 +670,13 @@ static struct net_buf *bt_att_chan_create_pdu(struct bt_att_chan *chan, uint8_t
 
 	switch (att_op_get_type(op)) {
 	case ATT_RESPONSE:
-	case ATT_CONFIRMATION:
-		/* Use a timeout only when responding/confirming */
+		/* Use a timeout only when responding */
 		timeout = BT_ATT_TIMEOUT;
 		re_use = true;
 		break;
+	case ATT_CONFIRMATION:
+		timeout = BT_ATT_TIMEOUT;
+		break;
 	default:
 		timeout = K_FOREVER;
 	}
@@ -701,7 +703,7 @@ static struct net_buf *bt_att_chan_create_pdu(struct bt_att_chan *chan, uint8_t
 			 * This is better than an assert as an assert would
 			 * allow a peer to DoS us.
 			 */
-			LOG_ERR("already processing a transaction on chan %p", chan);
+			LOG_ERR("already processing a REQ/RSP on chan %p", chan);
 
 			return NULL;
 		}