Add a common method to format backtrace to buffer, so it can be used by both mm, fs and other possoble modules.
Signed-off-by: fangpeina <fangpeina@xiaomi.com>
- `g_iob_sem.semcount` must be equal to the total number of free IOBs.
It can also be negative if there are no free IOBs and there are threads
waiting for an IOB.
- g_throttle_sem.semcount represents the number of IOBs available for
throttled IOB allocations. Like any other semaphore, it should only go
negative if there is a thread waiting for it.
- Both semaphores are related to the same resource (free IOBs), hence,
they must be incremented/decremented simultaneously:
- Whenever a IOB buffer is freed, if a thread is waiting for a
non-throttled IOB or a thread is waiting for a throttled IOB and we
have at least `CONFIG_IOB_THROTTLE` buffers available, the IOB is put
in the committed list (`g_iob_committed`). Otherwise, it is put in the
common free list (`g_iob_freelist`).
- `g_iob_sem` is always incremented when an IOB buffer is freed, but
`g_throttle_sem` is incremented only if we have at least CONFIG_IOB_THROTTLE
buffers free.
- Both semaphores are posted with the schedule locked to avoid any
mismatches in the semaphores count.
- If a task is waiting for an IOB semaphore (`iob_allocwait`) is
awakened and would check the `g_iob_committed`. The highest priority
task waiting for a semaphore will be awakened first.
make possible enable pool, but disabled in system heap.
also compatible for further extra heap use/not use pool.
Now use MM_HEAP_MEMPOOL_THRESHOLD -1 to indicate pool disabled.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
If the CAN stack receiving packets fast, but the application layer reading packets slow. Then `conn->readahead` will continue to grow, leading to memory leaks. Finally CAN stack potentially starve out all IOB buffers. To prevent memory leaks, users can restrict can socket buffer length.
Signed-off-by: gaohedong <gaohedong@xiaomi.com>
GRAN_ALIGNED should check that the memory block's alignment (log2align)
is correct, not that the memory block is aligned with the granule size.
This fixes DEBUGASSERT() in mm_granfree:
_assert: Assertion failed : at file: mm_gran/mm_granfree.c:49
The assertion triggers if granule size != alignment.
This revises vm_map_region() by accepting unaligned paddr, which is
aligned-down before mapping and in-page offset is then added to vaddr
before returning. It also moves vm_map_region() and vm_unmap_region()
to vm_region.c.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
This patch adds definitions to support user space device mappings
that allows devices like frame buffer to be accessible from user
space in kernel mode.
The are mainly two changes:
- in `mm/`:
added vm_map_region(), vm_unmap_region() for drivers to do
device mapping easily.
- in `arch/`:
extended ARCH_SHM_NPAGES as user-space mapping region size.
decoupled ARCH_SHM_MAXREGIONS from region size calculations and
limit its usage only for SysV shm purposes.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
Support the network interface card driver to receive zero copies of packets and send and receive giant frame packets, allowing drivers to initialize the DMA buffer to the iob structure, and we can apply for IOB with large memory
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
This patch refactors granule allocator to remove the 32 granules
limitation with the help of a gran_range_s structure and related
functions, see "mm_grantable.h" for details.
Below are the major functions explaining how this works:
- The gran_match() checks if a gran range all in the given state.
it gives last mismatch position when fails free range matching.
- The gran_search() tries to find the position of a free range.
It leverages last mismatch position from gran_match() to speed
up the search.
range size handling is mainly in gran_match() and gran_set_().
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
- Add ARCH_KVMA_MAPPING to guard kernel mapping.
- Set dependency from MM_KMAP to ARCH_KVMA_MAPPING, as per commit
70de321de3.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
Extracting global variable information using scripts:
kasan_global.py:
1. Extract the global variable information provided by the -- param asan globals=1 option
2. Generate shadow regions for global variable out of bounds detection
Makefile:
1. Implement multiple links, embed the shadow area into the program, and call it by the Kasan module
Signed-off-by: W-M-R <mike_0528@163.com>
In SMP mode, up_cpu_index()/this_cpu() are the same, both return the index of the physical core.
In AMP mode, up_cpu_index() will return the index of the physical core, and this_cpu() will always return 0
| #ifdef CONFIG_SMP
| # define this_cpu() up_cpu_index()
| #elif defined(CONFIG_AMP)
| # define this_cpu() (0)
| #else
| # define this_cpu() (0)
| #endif
Signed-off-by: chao an <anchao@lixiang.com>
These variables will trigger variable 'ret' set but not used warnings due to different configurations.
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
ctc E246: ["map/mm_map.c" 67/41] left side of '.' or '->' is not struct or union
ctc E260: ["map/mm_map.c" 67/25] not an lvalue
ctc E246: ["map/mm_map.c" 80/3] left side of '.' or '->' is not struct or union
ctc E260: ["map/mm_map.c" 80/3] not an lvalue
Signed-off-by: chao an <anchao@lixiang.com>
After this, RISC-V fully supports the kmap interface.
Due to the current design limitations of having only a single L2 table
per process, the kernel kmap area cannot be mapped via any user page
directory, as they do not contain the page tables to address that range.
So a "kernel address environment" is added, which can do the mapping. The
mapping is reflected to every process as only the root page directory (L1)
is copied to users, which means every change to L2 / L3 tables will be
seen by every user.
Mapping a physical page to a kernel virtual page is very simple and does
not need the kernel vma list, just get the kernel addressable virtual
address for the page.
is_kmap_vaddr is added and used to test that a given (v)addr is actually
inside the kernel map area. This gives a speed optimization for kmm_unmap,
as it is no longer necessary to take the mm_map_lock to check if such a
mapping exists; obviously if the address is not within the kmap area, it
won't be in the list either.
User pages are mapped from the currently active address environment. If
the process is running on a borrowed address environment, then the
mapping should be created from there.
This happens during (new) process creation only.
buxiasen