it will block other works of the list of hpwork when it waits to get buffer for too long. so use a separate workqueue for rpmsgdev.
Signed-off-by: liaoao <liaoao@xiaomi.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
when client read and poll wait buffer from server side and server side may
poll notify more than one times, then rpmsgdev in client side will call
"rpmsgdev_poll_setup(priv, 0, false);" twice which will cause crash in
vela rpmsgdev_server.c
Signed-off-by: rongyichang <rongyichang@xiaomi.com>
/usr/bin/ld: nuttx.rel: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
Signed-off-by: cuiziwei <cuiziwei@xiaomi.com>
stdio/lib_libvsprintf.c:1018:17: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long long int'; cast to an unsigned type to negate this value to itself
#0 0x3326a86 in vsprintf_internal stdio/lib_libvsprintf.c:1018
#1 0x332926b in lib_vsprintf stdio/lib_libvsprintf.c:1363
#2 0x3777978 in vfprintf stdio/lib_vfprintf.c:52
#3 0x671b3a0 in printf stdio/lib_printf.c:44
#4 0x37abc0c in hello_main /data/project/code/vela-pt/apps/examples/hello/hello_main.c:38
#5 0x33201d3 in nxtask_startup sched/task_startup.c:70
#6 0x3208ecb in nxtask_start task/task_start.c:134
#7 0x3357a49 in pre_start sim/sim_initialstate.c:52
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
We save interrupted TCB state on tcb->xcp.regs not interrupt stack now
which allows us to remove x86_64_savestate() from up_switch_context()
and other places.
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Migrate the Changing the System Clock Configuration documentation from
the Confluence wiki to the official documentation
Signed-off-by: Ludovic Vanasse <ludovicvanasse@gmail.com>
A use-after-free problem occurs when there are multiple remotes in the list `g_rpmsg` and the matching remote is not the last item in the list.
Log
# Export the device "/dev/LOCAL_DEV" to remote "REMOTE_CPU"
ap> testdev -d 2 -c "REMOTE_CPU" -l "/dev/LOCAL_DEV"
[ap] kasan_report: kasan detected a read access error, address at 0x3c3d4740,size is 4, return address: 0x2c33620f
[ap] kasan_show_memory: Shadow bytes around the buggy address:
[ap] kasan_show_memory: 0x3c3d46f0: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[ap] kasan_show_memory: 0x3c3d4700: aa aa aa aa cc cc cc cc cc cc cc cc cc cc cc cc
[ap] kasan_show_memory: 0x3c3d4710: 40 47 3d 3c ed 61 33 2c 00 00 00 00 00 00 00 00
[ap] kasan_show_memory: 0x3c3d4720: 00 00 00 00 00 00 00 00 00 00 00 00 cc cc cc cc
[ap] kasan_show_memory: 0x3c3d4730: 55 55 55 55 38 00 00 00 02 2c 00 00 cc cc cc cc
[ap] kasan_show_memory: 0x3c3d4740:[00 00 00 00]66 e0 42 3c cc cc cc cc cc cc cc cc
[ap] kasan_show_memory: 0x3c3d4750: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[ap] kasan_show_memory: 0x3c3d4760: aa aa aa aa 38 00 00 00 01 2c 00 00 cc cc cc cc
[ap] kasan_show_memory: 0x3c3d4770: 50 57 44 3d 2f 00 cc cc cc cc cc cc cc cc cc cc
[ap] kasan_show_memory: 0x3c3d4780: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[ap] dump_assert_info: Current Version: NuttX ****** ***** *** 12.3.0 **********-***** *** ** 2024 **:**:** arm
[ap] dump_assert_info: Assertion failed panic: at file: kasan/hook.c:187 task: testdev process: testdev 0x2ca20495
$ addr2line -fe nuttx/nuttx 0x2c33620f
rpmsgdev_server_created
/workspace/nuttx/drivers/misc/rpmsgdev_server.c:529
# Line 529 => strcmp()
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
struct sockaddr_in
{
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
uint8_t sin_zero[8];
};
sin_zero is probably a random number.
struct sockaddr_in6
{
sa_family_t sin6_family;
in_port_t sin6_port;
uint32_t sin6_flowinfo;
struct in6_addr sin6_addr;
uint32_t sin6_scope_id;
};
sin6_flowinfo and sin6_scope_id is probably a random number.
Random numbers cause the same server configuration check failed,
so let's initialize it.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Need to save the regs firstly in case syslog triggers another crash.
Otherwise we may loose the register contents for the first exception.
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
jiangtao16