net: openthread: rpc: Align input line buffer with openthread config #18852
Conversation
github-actions
bot
added
the
changelog-entry-required
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 10bf753a58bf355a631bf3e89340d63ebdc401cf more detailssdk-nrf:
Github labels
List of changed files detected by CI (1)Outputs:ToolchainVersion: f51bdba1d9 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
Make buffer global for high value of CONFIG_OPENTHREAD_CLI_MAX_LINE_LENGTH to prevent stack overflow. The second solution would be increasing CONFIG_NRF_RPC_THREAD_STACK_SIZE but this increases stack buffer for each rpc thread pool. The approach can be optimize in future by implementing packet fragmentation. Signed-off-by: Lukasz Maciejonczyk <[email protected]>
lmaciejonczyk
force-pushed
the
luma/ot_rpc_input_line
branch
from
471df67 to
10bf753
Compare
| struct nrf_rpc_cbor_ctx rsp_ctx; | ||
| char *result; | ||
|
|
||
| #if CONFIG_OPENTHREAD_CLI_MAX_LINE_LENGTH > 256 |
There was a problem hiding this comment.
Shouldn't it be allocated from heap instead?
This fix seems like we want to avoid memory misconfiguration.
@Damian-Nordic, opinions?
There was a problem hiding this comment.
I think it would be cleaner to use a single solution regardless of the configured max line length. Using malloc may be a better option not to increase the static RAM usage (we don't have so much unused RAM on nRF54L in this project). There's another option to just add a null-terminator in the received packet and not copy anything but this would require removing the usage of nrf_rpc_decode_str and perhaps adding another helper, so we can now stick to malloc and optimize it later.
| #if CONFIG_OPENTHREAD_CLI_MAX_LINE_LENGTH > 256 | ||
| static | ||
| #endif | ||
| char input_line_buffer[CONFIG_OPENTHREAD_CLI_MAX_LINE_LENGTH - 1]; |
| struct nrf_rpc_cbor_ctx rsp_ctx; | ||
| char *result; | ||
|
|
||
| #if CONFIG_OPENTHREAD_CLI_MAX_LINE_LENGTH > 256 |
There was a problem hiding this comment.
I think it would be cleaner to use a single solution regardless of the configured max line length. Using malloc may be a better option not to increase the static RAM usage (we don't have so much unused RAM on nRF54L in this project). There's another option to just add a null-terminator in the received packet and not copy anything but this would require removing the usage of nrf_rpc_decode_str and perhaps adding another helper, so we can now stick to malloc and optimize it later.
Make buffer global for high value of CONFIG_OPENTHREAD_CLI_MAX_LINE_LENGTH to prevent stack overflow.
The second solution would be increasing CONFIG_NRF_RPC_THREAD_STACK_SIZE but this increases stack buffer for each rpc thread pool. The approach can be optimize in future by implementing packet fragmentation.