[Bug] assertion failed in function rt_completion_wait_flags

[zhangjing0303]

RT-Thread Version

master commit accd616

Hardware Type/Architectures

riscv64 fpga

Develop Toolchain

GCC

Describe the bug

When running the RT-Thread Smart version and using an SPI TF card as a storage medium, in the SPI driver, synchronization of the send completion is implemented through the rt_completion_wait and rt_completion_done APIs. However, when running the hello example from userapps（https://github.com/RT-Thread/userapps/tree/main/apps/hello） in the ash shell, the following error occurs:

/ # hello
hello world!
(result != RT_EOK) assertion failed at function:rt_completion_wait_flags, line number:139

Here is the source code when the error occurs:
             ```
  else
                {
                    /* no changes, waiting failed */
                    result = thread->error;
                    result = result > 0 ? -result : result;
                    RT_ASSERT(result != RT_EOK);
                }

Other additional context

When the error occurs, checking the system status， shows rt_thread_ready_priority_group = 0 and rt_scheduler_lock_nest =0. And now the status of idle thread is 0x7, the idle task is suspended. Here is the stack trace when the idle task is suspended：

#0  _thread_set_suspend_state (thread=thread@entry=0xffffffc0002adf58 <idle_thread>, suspend_flag=suspend_flag@entry=2) 
#1  0xffffffc0002718a6 in rt_thread_suspend_to_list (thread=thread@entry=0xffffffc0002adf58 <idle_thread>, susp_list=susp_list@entry=0xffffffc000295328 <fdlock+40>,
    ipc_flags=<optimized out>, suspend_flag=suspend_flag@entry=2)
#2  0xffffffc00026a06c in _rt_mutex_take (mutex=mutex@entry=0xffffffc000295300 <fdlock>, timeout=timeout@entry=-1, suspend_flag=suspend_flag@entry=2)
#3  0xffffffc00026a318 in rt_mutex_take (mutex=mutex@entry=0xffffffc000295300 <fdlock>, time=time@entry=-1)
#4  0xffffffc00020f434 in dfs_file_lock () at /home/turtle/zhangjing/bak/rt-thread/components/dfs/dfs_v2/src/dfs.c:158
#5  0xffffffc000213fb2 in on_varea_close (varea=0xffffffc0003067c8) 
#6  0xffffffc000248128 in _varea_uninstall_locked (varea=varea@entry=0xffffffc0003067c8) 
#7  0xffffffc0002474ee in rt_aspace_detach (aspace=aspace@entry=0xffffffc000305d88) 
#8  0xffffffc000247574 in rt_aspace_delete (aspace=0xffffffc000305d88)
#9  0xffffffc00021e91c in arch_user_space_free (lwp=lwp@entry=0xffffffc0002f18c8)
#10 0xffffffc000239f62 in lwp_unmap_user_space (lwp=lwp@entry=0xffffffc0002f18c8) 
#11 0xffffffc00022b2a0 in lwp_free (lwp=lwp@entry=0xffffffc0002f18c8) 
#12 0xffffffc00022b97e in lwp_ref_dec (lwp=lwp@entry=0xffffffc0002f18c8) 
#13 0xffffffc00021f63e in lwp_cleanup (tid=tid@entry=0xffffffc0002f3998) 
#14 0xffffffc000268790 in rt_defunct_execute () 
#15 0xffffffc000268806 in idle_thread_entry (parameter=0x0)
#16 0xffffffc0002001a2 in _rt_thread_entry ()

[heyuanjie87]

#9367 很大可能是这里的问题引起的

[zhangjing0303]

#9367 很大可能是这里的问题引起的

验证了下，merge pr9367后可以解决该问题。