nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

Susheel Nuguru — Tue, 23 May 2023 10:06:55 GMT

For your reference, our internal ticket to track the progress on this discussion is MBTLE-4290. I will update you when I have more details from the Mesh team. But for now, I suggest that you go ahead with your prototyping and if scenario 1) turns out to be very possible, then we can come up with a workaround.

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

m.wagner — Tue, 23 May 2023 08:30:10 GMT

Okay great, thank you.

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

Susheel Nuguru — Tue, 23 May 2023 08:08:03 GMT

Hi Michael, Thanks for your patience and I hope that you had a some days to rest over the long weekend.

I think I see the scenario which you describe, but I would like to discuss this with the Mesh experts. The whole discussion is based on the response of (Timeslot API: Can application code be executed between signal handler and Softdevice event handler?),

I do not think that Mesh timeslot handling was done expecting that the application can run between signal handler and event handler. I will create an internal ticket and have some brain storming with Mesh team before we conclude this. This might take time, but I think would yield better results including the Mesh team here.

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

m.wagner — Wed, 17 May 2023 05:36:00 GMT

Hi Susheel,

No problem, we've got a holiday weekend as well and it is indeed not a pressing matter!

Thank you for taking your time and best regards,
-mike

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

Susheel Nuguru — Tue, 16 May 2023 17:45:44 GMT

Hmm,

Michal, I need to take a closer look at the whole state.machine one more time. Unfortunately I wont be able to do that before next week as it is holiday week in Norway after today and I already am at Home.

Fortunately, we are discussing the theoretical possibilities of a race condition, so you are not blocked in your development. So I am hoping, me answering you next week about this would be OK?

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

m.wagner — Tue, 16 May 2023 07:50:30 GMT

[quote userid="6207" url="~/f/nordic-q-a/99699/nrf5-sdk-for-mesh-possible-race-condition-in-timeslot_start/425777"]If the timeslot is successfully requested but not started yet, then timeslot_stop->timeslot_trigger->m_current_timeslot.in_progress must be false since it is set to true only when application handles the START signal from the softdevice.[/quote]

That is true, but m_timeslot_forced_command will get set and thus the else-clause in radio_signal_callback() will result in NRF_RADIO_SIGNAL_CALLBACK_ACTION_END being returned, leading to the scenario described in case 1.

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

Susheel Nuguru — Tue, 16 May 2023 07:35:00 GMT

[quote user="m.wagner"]I think we do have a misunderstanding concerning scenario 1. By "timeslot not currently being served" I mean that the timeslot was successfully requested, but at the time of timeslot_stop() being executed, the timeslot is not currently granted due to (pending) softdevice activity (e.g. due to a connection event).

We would enter the if ()-clause and thus force the timeslot to stop immediately when the START signal is handled the next time around.[/quote]

If the timeslot is successfully requested but not started yet, then timeslot_stop->timeslot_trigger->m_current_timeslot.in_progress must be false since it is set to true only when application handles the START signal from the softdevice. So I do not see timeslot_stop able to do anything without a proper start being handled by the application (inside handle_signal_start->on_ts_begin->p_timeslot->in_progress = true;)

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

m.wagner — Tue, 16 May 2023 06:00:01 GMT

Hi Susheel,
Thanks for your response.

I think we do have a misunderstanding concerning scenario 1. By "timeslot not currently being served" I mean that the timeslot was successfully requested, but at the time of timeslot_stop() being executed, the timeslot is not currently granted due to (pending) softdevice activity (e.g. due to a connection event).

We would enter the if ()-clause and thus force the timeslot to stop immediately when the START signal is handled the next time around.
Re-checking m_current_timeslot.session_state in scenario 2 seems like a sensible workaround, thank you.

Thank you / best regards,

-mike

RE: nRF5 SDK for Mesh: Possible race condition in timeslot_start()?

Susheel Nuguru — Tue, 16 May 2023 05:00:32 GMT

Hi Michal,

timeslot_stop would do nothing if the session is not being served. I think it also the application responsibility to keep track of states and to fence/protect the trigger of the API where ever it is not appropriate. Like you already noticed, timeslot_stop have an if condition in it that checks the session state to see if the session state is in the right state. In this scenario, m_current_timeslot.session_state would not be equal to STATE_RUNNING so nothing should happen here.
This scenario seems like a possibility, in which case the application can handle the the NRF_ERROR_FORBIDDEN error by looking at the

m_current_timeslot.session_state again to handle the race condition before having an application panic/assert.