Summary:
1.Modified the i_crefs from int16_t to atomic_int
2.Modified the i_crefs add, delete, read, and initialize interfaces to atomic operations
The purpose of this change is to avoid deadlock in cross-core scenarios, where A Core blocks B Core’s request for a write operation to A Core when A Core requests a read operation to B Core.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
For some case, need large files from tmpfs or shmfs, will lead to high
pressure on memory fragments, add an optional fs_heap with independent
heap will benifit for memory fragments issue.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
[Desc]:We need to check the parameter passed to the kmm_zalloc(size_t) function.
If it exceeds the limit of size_t, we need to return an error directly to avoid further errors.
Signed-off-by: pengyinjie <pengyinjie@xiaomi.com>
When shmfs_truncate is called, it uses shmfs_alloc_object to create the
physical backing for the shm file. However, the allocated physical
memory returned by mm_pgalloc is not cleared when CONFIG_BUILD_KERNEL is
set, which is a clear POSIX violation:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/truncate.html
"If the file was previously shorter than length, its size is increased,
and the extended area appears as if it were zero-filled."
For FLAT and PROTECTED modes zalloc is used, so the violation affects
KERNEL mode only.
Fixes build error with -Werror:
shm/shmfs.c: In function 'shmfs_read':
shm/shmfs.c:122:33: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith]
122 | memcpy(buffer, sho->paddr + startpos, nread);
| ^
shm/shmfs.c: In function 'shmfs_write':
shm/shmfs.c:166:25: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith]
166 | memcpy(sho->paddr + startpos, buffer, nwritten);
| ^
cc1: all warnings being treated as errors
If the shm file is removed and a subsequent close, only release shm
object, but inode is leaked. Should decrease refcount to release inode
when unmapped, that matched with refcount increase when mapped.
Another fix that remove the shm file failed.
nsh> rm /var/shm/pts_mmap_1_2_5
nsh: rm: unlink failed: 6
Signed-off-by: fangxinyong <fangxinyong@xiaomi.com>
No memory map count limit that will exhaust memory and cause
the system hang. Also that fix pass LTP posix case mmap/24-1.c
Signed-off-by: fangxinyong <fangxinyong@xiaomi.com>
1. Update all CMakeLists.txt to adapt to new layout
2. Fix cmake build break
3. Update all new file license
4. Fully compatible with current compilation environment(use configure.sh or cmake as you choose)
------------------
How to test
From within nuttx/. Configure:
cmake -B build -DBOARD_CONFIG=sim/nsh -GNinja
cmake -B build -DBOARD_CONFIG=sim:nsh -GNinja
cmake -B build -DBOARD_CONFIG=sabre-6quad/smp -GNinja
cmake -B build -DBOARD_CONFIG=lm3s6965-ek/qemu-flat -GNinja
(or full path in custom board) :
cmake -B build -DBOARD_CONFIG=$PWD/boards/sim/sim/sim/configs/nsh -GNinja
This uses ninja generator (install with sudo apt install ninja-build). To build:
$ cmake --build build
menuconfig:
$ cmake --build build -t menuconfig
--------------------------
2. cmake/build: reformat the cmake style by cmake-format
https://github.com/cheshirekow/cmake_format
$ pip install cmakelang
$ for i in `find -name CMakeLists.txt`;do cmake-format $i -o $i;done
$ for i in `find -name *\.cmake`;do cmake-format $i -o $i;done
Co-authored-by: Matias N <matias@protobits.dev>
Signed-off-by: chao an <anchao@xiaomi.com>
This way the mappings can be modified for any vm area, not only the
process that is running.
Why? This allows mapping pages to kernel dynamically, this functionality
will be presented later.
This implements the file system logic for posix shared memory:
shm_open, shm_unlink, mmap, munmap and close
For flat and protected builds the memory simply allocated from (user) heap
For kernel build the memory is allocated from page pool and mapped with MMU
This doesn't yet support protection flags or re-sizing already truncated shared
memory area.
Co-authored-by: Ville Juven <ville.juven@unikie.com>
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
