`nx_icmp_interface_ping` inhibits pre-emption causing interface driver faults

[diggit]

Describe the bug
calling nx_icmp_ping consequenctly calls _nx_icmp_interface_ping.
It inhibits preemption and then nests into packet tranmission.

This prevents any nested code to block, e.g.: to wait for shared resource or to wait until the packet hand over finishes in the interface driver. Necessary in the EMW3080 driver (LOCK, SEM_WAIT).

My setup:

• EM3090 attached via SPI, Driver from STM.
• ThreadX: 6.2.0
• NetxDuo: 6.2.0

To Reproduce
Steps to reproduce the behavior:

1. Have a interface driver that requires some kind of blocking (resource locking, waiting for txn to finish etc.)
2. Start some interface interaction (send packet, ....)
3. Call nx_icmp_ping from other thread, whole the interface driver is busy

Expected behavior
_nx_icmp_interface_ping does not inhibit preemption thus allows interface driver to properly work

Impact
nx_icmp_ping now easily breaks the interface driver (mutexes, sempahores,.. do not work)

[diggit]

My naive attempt with operation reordering by putting _nx_ip_packet_send right after the mutex lock and before TX_DISABLE seems to work. I am not sure about consequences though...

    /* Obtain the IP internal mutex to prevent against possible suspension later in the
       call to IP packet send.  */
    tx_mutex_get(&(ip_ptr -> nx_ip_protection), TX_WAIT_FOREVER);

    /* Send the ICMP packet to the IP component.  */
    /*lint -e{644} suppress variable might not be initialized, since "next_hop_address" was initialized in _nx_ip_route_find. */
   /* new position of  _nx_ip_packet_send call */
    _nx_ip_packet_send(ip_ptr, request_ptr, ip_address,
                       NX_IP_NORMAL, NX_IP_TIME_TO_LIVE, NX_IP_ICMP, NX_FRAGMENT_OKAY, next_hop_address);

    /* Disable interrupts.  */
    TX_DISABLE

[fdesbiens]

Hi @diggit.

I will look into this soon. Out of curiosity, did you try with the latest versions of ThreadX / NetX (v6.5.1.202602)? The reason I am asking is that any fix will ship in a 6.5.x release.

[fdesbiens]

@diggit, I checked the current NetX Duo code. Both IPv4 and IPv6 ping register the waiting thread before sending. Moving the send earlier creates a race: a fast echo reply could arrive before its waiter is registered and be discarded.

The NetX Duo Network Drivers guide says driver entry runs with the IP mutex held and should avoid blocking operations. The linked mipc_request() contains a semaphore wait. If your transmit entry calls it synchronously, that wait needs to move out of the driver entry, for example to a worker that completes transmission asynchronously. Reordering the ping calls would not safely support a blocking transmit entry.

I propose closing this as not planned for a NetX Duo core change. If the same failure occurs with a driver whose transmit entry returns promptly, please open a new issue with a minimal reproducer so we can investigate that path.