The function is not relevant any longer, remove it. Also remove
save_addrenv_t, the parameter taken by up_addrenv_restore.
Implement addrenv_select() / addrenv_restore() to handle the temporary
instantiation of address environments, e.g. when a process is being
created.
There is currently a big problem in the address environment handling which
is that the address environment is released too soon when the process is
exiting. The current MMU mappings will always be the exiting process's, which means
the system needs them AT LEAST until the next context switch happens. If
the next thread is a kernel thread, the address environment is needed for
longer.
Kernel threads "lend" the address environment of the previous user process.
This is beneficial in two ways:
- The kernel processes do not need an allocated address environment
- When a context switch happens from user -> kernel or kernel -> kernel,
the TLB does not need to be flushed. This must be done only when
changing to a different user address environment.
Another issue is when a new process is created; the address environment
of the new process must be temporarily instantiated by up_addrenv_select().
However, the system scheduler does not know that the process has a different
address environment to its own and when / if a context restore happens, the
wrong MMU page directory is restored and the process will either crash or
do something horribly wrong.
The following changes are needed to fix the issues:
- Add mm_curr which is the current address environment of the process
- Add a reference counter to safeguard the address environment
- Whenever an address environment is mapped to MMU, its reference counter
is incremented
- Whenever and address environment is unmapped from MMU, its reference
counter is decremented, and tested. If no more references -> drop the
address environment and release the memory as well
- To limit the context switch delay, the address environment is freed in
a separate low priority clean-up thread (LPWORK)
- When a process temporarily instantiates another process's address
environment, the scheduler will now know of this and will restore the
correct mappings to MMU
Why is this not causing more noticeable issues ? The problem only happens
under the aforementioned special conditions, and if a context switch or
IRQ occurs during this time.
Detach the address environment handling from the group structure to the
tcb. This is preparation to fix rare cases where the system (MMU) is left
without a valid page directory, e.g. when a process exits.
1.
net/slip.c:865:29: warning: unused variable ‘priv’ [-Wunused-variable]
865 | FAR struct slip_driver_s *priv =
| ^~~~
net/slip.c: In function ‘slip_rmmac’:
net/slip.c:895:29: warning: unused variable ‘priv’ [-Wunused-variable]
895 | FAR struct slip_driver_s *priv =
| ^~~~
2.
local/local_sendmsg.c: In function ‘local_sendmsg’:
local/local_sendmsg.c:423:18: warning: ‘count’ may be used uninitialized in this function [-Wmaybe-uninitialized]
423 | return count;
| ^~~~~
local/local_sendmsg.c:131:11: warning: ‘i’ may be used uninitialized in this function [-Wmaybe-uninitialized]
131 | while (i-- > 0)
| ~^~
local/local_sendmsg.c:71:7: note: ‘i’ was declared here
71 | int i;
| ^
Signed-off-by: chao an <anchao@xiaomi.com>
1.
ipfrag/ipv4_frag.c: In function ‘ipv4_fragin’:
ipfrag/ipv4_frag.c:184:22: warning: ‘head’ may be used uninitialized in this function [-Wmaybe-uninitialized]
184 | ipv4->len[1] = head->io_pktlen & 0xff;
| ~~~~^~~~~~~~~~~
ipfrag/ipv4_frag.c:123:21: note: ‘head’ was declared here
123 | FAR struct iob_s *head;
| ^~~~
2.
devif/ipv6_input.c: In function ‘ipv6_in’:
devif/ipv6_input.c:60:33: error: ‘TCPIPv6BUF’ undeclared (first use in this function); did you mean ‘UDPIPv6BUF’?
60 | #define PAYLOAD ((FAR uint8_t *)TCPIPv6BUF)
| ^~~~~~~~~~
3.
nat/ipv4_nat.c: In function ‘ipv4_nat_inbound_icmp’:
nat/ipv4_nat.c:67:30: error: ‘TCP_HDRLEN’ undeclared (first use in this function); did you mean ‘UDP_HDRLEN’?
67 | ((proto) == IP_PROTO_TCP ? TCP_HDRLEN : \
| ^~~~~~~~~~
nat/ipv4_nat.c:323:47: note: in expansion of macro ‘L4_HDRLEN’
323 | inner_l4hdrlen = MIN(inner_l4len, L4_HDRLEN(inner->proto));
| ^~~~~~~~~
Signed-off-by: chao an <anchao@xiaomi.com>
The cyw43-driver is a submodule in the pick-sdk, if the submodule is
not updated, the dummy firmware driver will be used, update the document
to correct the setup flow.
${PICO_SDK_PATH}/lib/cyw43-driver/firmware/43439A0-7.95.49.00.combined
Signed-off-by: chao an <anchao@xiaomi.com>
ld: warning: boards/arm/rp2040/raspberrypi-pico-w/scripts/raspberrypi-pico-flash.ld contains output sections; did you forget -T?
Signed-off-by: chao an <anchao@xiaomi.com>
common/arm_backtrace_unwind.c: In function 'up_backtrace':
common/arm_backtrace_unwind.c:626:27:
warning: assignment to 'long unsigned int' from 'uint8_t (*)[]'\
{aka 'unsigned char (*)[]'} makes integer from pointer without a cast [-Wint-conversion]
626 | frame.stack_top = &g_intstacktop;
|
Summary:
- I noticed that nuttx crashes if DEBUG_ASSERTIONS=y
- This commit fixes this issue by changing QEMU options
Impact:
- None
Testing:
- Tested with QEMU
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- Since QEMU does not report L2CC information correctly,
NuttX stops if DEBUG_ASSERTIONS=y.
- This commit adds DEBUG_ASSERTIONS=y to citest/defconfigs
and disables L2CC related configs.
- Also, it disables RAMLOG to show the crash information
Impact:
- None
Testing:
- Tested with QEMU-7.1
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- I noticed that the following build error happened on my machine.
make -C sched libsched.a EXTRAFLAGS="-D__KERNEL__ "
make[1]: Entering directory '/mnt/m2ssd/opensource/RTOS/tmp/nuttx/sched'
/bin/sh: 1: echoCC: clock/clock_initialize.c : not found
- This commit fixes this issue
Impact:
- Should be none
Testing:
- Build on ubuntu 18.04 x86_64
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
sim/rpserver
NuttShell (NSH) NuttX-12.0.0
server> cu
_assert: Current Version: NuttX server 12.0.0 3ead669e7a-dirty Feb 2 2023 23:53:48 sim
_assert: Assertion failed : at file: libs/libc/misc/lib_mutex.c:303 task: cu 0x5662fff4
Signed-off-by: chao an <anchao@xiaomi.com>
Receiving an ACK indicating TCP Window Update will not set ACKDATA flag (because tx_unacked is 0) in our TCP stack. Then this ACK won't let us send anything after receiving it, even if it updates snd_wnd. So we need to check whether we can send data immediately when our snd_wnd is updated (especially from 0), otherwise we will only send next data after timer expiry.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
Using the full path will make __FILE__ longer, which will lead to a larger flash footprint
revert 9c6c9fb0cd && e14309a92d
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
