NuttX kernel should not use the syscall functions, especially after
enabling CONFIG_SCHED_INSTRUMENTATION_SYSCALL, all system functions
will be traced to backend, which will impact system performance.
Signed-off-by: chao an <anchao@xiaomi.com>
Original code assumes the previous node in physical must be
ALLOCED, but other thread may free the previous node between
mm_malloc() and mm_lock(), and the original code didn't condsider
this, which will cause two adjacent free nodes situation and this
should not be happened.
This commit will merge the previous node and node if the previous
node is free to avoid the situation discribed above.
Signed-off-by: wangbowen6 <wangbowen6@xiaomi.com>
When adding more heap memory, the total heap size was not updated. This
results in a crash in mm_mallinfo:
DEBUGASSERT((size_t)info->uordblks + info->fordblks == heap->mm_heapsize);
This commit fixes this issue
There are many small memory block in NuttX system, eg: struct tcb_s,
struct inode, etc, and several disadvantages about them:
1.Their frequent allocate and free cause the system memory fragmentation.
2.Since each memory block has an overhead, the utilization of small memory
blocks is relatively low, which will cause memory waste.
So we can use mempool to alloc smallo block, to improve alloc speed
and utilization, to reduce fragmentation.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
do simple copy to instead of memset and memcpy operation because
they have been instrumented, if you access the posion area,
the system will crash.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
The return value of function mm_takesemaphore will never below
than zero, DEBUGVERIFY make no effect to check it, use DEBUGASSERT
instead.
Signed-off-by: xiangdong6 <xiangdong6@xiaomi.com>
The free node is still in use after kasan_poison(), the node member
access will cause the assert report by kasan.
| (gdb) bt
| #0 kasan_report (addr=1743265406637584896, size=140737337053680, is_write=46) at kasan/kasan.c:97
| #1 0x0000555555607bdd in __asan_loadN_noabort (addr=140737272831420, size=4) at kasan/kasan.c:289
| #2 0x0000555555607cd7 in __asan_load4_noabort (addr=140737272831420) at kasan/kasan.c:323
| #3 0x00005555556061ef in gmtime_r (timep=0x7ffff3275dbc, result=0x7ffff3275e10) at time/lib_gmtimer.c:301
| #4 0x000055555560e507 in sim_rtc_rdtime (lower=0x55555576b780 <g_sim_rtc>, rtctime=0x7ffff3275e10) at sim/up_rtc.c:77
| #5 0x00005555555fcbdb in up_rtc_gettime (tp=0x7ffff3275ef0) at timers/arch_rtc.c:128
| #6 0x00005555555f08b4 in clock_systime_timespec (ts=0x7ffff3275ef0) at clock/clock_systime_timespec.c:72
| #7 0x00005555555ecc77 in note_common (tcb=0x7ffff31d2180, note=0x7ffff3275f80, length=21 '\025', type=18 '\022') at sched/sched_note.c:144
| #8 0x00005555555ed706 in sched_note_syscall_enter (nr=1, argc=0) at sched/sched_note.c:765
| #9 0x000055555560eb37 in __wrap_getpid () at wraps/WRAP_getpid.c:26
| #10 0x0000555555608d1c in mm_takesemaphore (heap=0x7ffff30ae000) at mm_heap/mm_sem.c:127
| #11 0x0000555555609477 in mm_free (heap=0x7ffff30ae000, mem=0x7ffff3265b80) at mm_heap/mm_free.c:89
| #12 0x00005555556070c5 in free (mem=0x7ffff3265b80) at umm_heap/umm_free.c:49
| #13 0x000055555560c3b0 in up_release_stack (dtcb=0x7ffff31e4b00, ttype=0 '\000') at sim/up_releasestack.c:67
| #14 0x00005555555f2515 in nxsched_release_tcb (tcb=0x7ffff31e4b00, ttype=0 '\000') at sched/sched_releasetcb.c:134
| #15 0x00005555556bdf0c in nxtask_terminate (pid=4, nonblocking=true) at task/task_terminate.c:184
| #16 0x00005555556bdb0f in nxtask_exit () at task/task_exit.c:168
| #17 0x000055555566e05f in up_exit (status=0) at sim/up_exit.c:64
| #18 0x000055555564f454 in _exit (status=0) at task/exit.c:78
| #19 0x000055555560ea89 in __wrap__exit (parm1=0) at wraps/WRAP__exit.c:27
| #20 0x00005555555eb288 in exit (status=0) at stdlib/lib_exit.c:54
| #21 0x00005555555fe2cc in nxtask_startup (entrypt=0x555555670c34 <critmon_start_main>, argc=1, argv=0x7ffff3265bb0) at sched/task_startup.c:70
| #22 0x00005555555f02a0 in nxtask_start () at task/task_start.c:134
| #23 0x0000000000000000 in ?? ()
Signed-off-by: chao.an <anchao@xiaomi.com>
