mm: handle take mm sem in IRQ

This is a fix of:
0169a51220
This is caused by wrong memory sem operation in IDLE.

Fix:
Obey the original design, don't check the IDLE in mm_takesemaphore()

Signed-off-by: ligd <liguiding1@xiaomi.com>
This commit is contained in:
ligd 2022-02-18 13:26:08 +08:00 committed by Xiang Xiao
parent ee0a0735e3
commit 419bc2fd04
2 changed files with 16 additions and 26 deletions

View File

@ -90,9 +90,9 @@ void mm_free(FAR struct mm_heap_s *heap, FAR void *mem)
{ {
kasan_unpoison(mem, mm_malloc_size(mem)); kasan_unpoison(mem, mm_malloc_size(mem));
/* We are in IDLE task & can't get sem, or meet -ESRCH return, /* Meet -ESRCH return, which means we are in situations
* which means we are in situations during context switching(See * during context switching(See mm_takesemaphore() & getpid()).
* mm_takesemaphore() & getpid()). Then add to the delay list. * Then add to the delay list.
*/ */
mm_add_delaylist(heap, mem); mm_add_delaylist(heap, mem);

View File

@ -80,9 +80,21 @@ bool mm_takesemaphore(FAR struct mm_heap_s *heap)
if (up_interrupt_context()) if (up_interrupt_context())
{ {
/* Can't take semaphore in the interrupt handler */ #if !defined(CONFIG_SMP)
int val;
/* Check the semaphore value, if held by someone, then return false.
* Or, touch the heap internal data directly.
*/
_SEM_GETVALUE(&heap->mm_semaphore, &val);
return val > 0;
#else
/* Can't take semaphore in SMP interrupt handler */
return false; return false;
#endif
} }
else else
#endif #endif
@ -101,28 +113,6 @@ bool mm_takesemaphore(FAR struct mm_heap_s *heap)
{ {
return false; return false;
} }
#if defined(CONFIG_BUILD_FLAT) || defined(__KERNEL__)
else if (sched_idletask())
{
return false;
}
else if (up_interrupt_context())
{
#ifdef CONFIG_SMP
return false;
#else
int val;
/* Check the semaphore value, if held by someone, then return false.
* Else, we can take it, return true.
*/
_SEM_GETVALUE(&heap->mm_semaphore, &val);
return val > 0;
#endif
}
#endif
else else
{ {
int ret; int ret;