WO2023273424A1 - 一种基于linux内核ko模块的加载方法及装置 - Google Patents
一种基于linux内核ko模块的加载方法及装置 Download PDFInfo
- Publication number
- WO2023273424A1 WO2023273424A1 PCT/CN2022/081865 CN2022081865W WO2023273424A1 WO 2023273424 A1 WO2023273424 A1 WO 2023273424A1 CN 2022081865 W CN2022081865 W CN 2022081865W WO 2023273424 A1 WO2023273424 A1 WO 2023273424A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- page
- address
- current
- current address
- loading
- Prior art date
Links
- 238000011068 loading method Methods 0.000 title claims abstract description 120
- 230000015654 memory Effects 0.000 claims abstract description 116
- 238000000034 method Methods 0.000 claims abstract description 91
- 230000008569 process Effects 0.000 claims abstract description 71
- 238000012545 processing Methods 0.000 claims abstract description 30
- 238000013507 mapping Methods 0.000 claims description 28
- 238000004590 computer program Methods 0.000 claims description 16
- 230000000903 blocking effect Effects 0.000 claims description 4
- 238000001514 detection method Methods 0.000 claims description 3
- 238000013519 translation Methods 0.000 claims description 3
- 230000003139 buffering effect Effects 0.000 claims 1
- 230000006870 function Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 230000001360 synchronised effect Effects 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 230000002159 abnormal effect Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000009977 dual effect Effects 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000005111 flow chemistry technique Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
Definitions
- Embodiments of the present disclosure relate to the communication field, and in particular, relate to a loading method and device based on a linux kernel ko module.
- the loading technology of the existing kernel ko module is to complete the relocation processing of all related functions and variable related assembly codes in the ko when the Linux kernel starts.
- the ko module of the Linux kernel is loaded into the memory space as a whole. If the ko version is large, the ko module will occupy too much memory.
- the ko file is loaded into the memory space as a whole. If the ko version is large, the problem that the ko module occupies too much memory will occur, and no solution has been proposed yet.
- the embodiment of the present disclosure provides a loading method and device based on the linux kernel ko module to at least solve the problem of loading the ko file into the memory space as a whole in the Linux kernel ko module in the related art. If the ko version is larger, ko Modules take up too much memory.
- a loading method based on the linux kernel ko module including:
- the current address is dynamically loaded through the page fault exception processing flow of the Linux kernel
- a loading device based on the linux kernel ko module including:
- the detection module is configured to detect whether the current address is within the dynamic loading address range in the page fault exception processing flow of the linux kernel;
- the loading module is configured to dynamically load the current address through the page fault exception processing flow of the Linux kernel if the current address is within the dynamic loading address range;
- the first release module is configured to dynamically release the code segments dynamically loaded into the physical memory under the current standard through the dynamic release interface when the current standard is switched to another standard.
- a computer-readable storage medium where a computer program is stored in the storage medium, wherein the computer program is set to execute any one of the above method embodiments when running in the steps.
- an electronic device including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to perform any of the above Steps in the method examples.
- the current address is within the dynamic loading address range in the page fault exception processing flow of the Linux kernel; if the current address is within the dynamic loading address range, the page fault exception processing flow of the Linux kernel is used to The current address is dynamically loaded; when the current system is switched to other systems, the code segment dynamically loaded into the physical memory under the current system is dynamically released through the dynamic release interface, which can solve the problem of the Linux kernel ko module in the related art Loading is to load the ko file into the memory space as a whole. If the ko version is large, the ko module will occupy too much memory.
- Fig. 1 is the hardware structural block diagram of the mobile terminal based on the loading method of linux kernel ko module of the embodiment of the present disclosure
- Fig. 2 is the flow chart of the loading method based on linux kernel ko module according to the disclosed embodiment
- Fig. 3 is the flowchart of the dynamic loading based on the Linux kernel ko module according to the present embodiment
- FIG. 4 is a schematic diagram of a page fault abnormal process of ko dynamic loading according to this embodiment
- Fig. 5 is the release flow diagram according to the dynamic loading of linux kernel ko of the present embodiment
- FIG. 6 is a block diagram of a loading device based on the linux kernel ko module according to this embodiment.
- Fig. 1 is a block diagram of the hardware structure of the mobile terminal based on the loading method of the linux kernel ko module according to an embodiment of the present disclosure.
- the mobile terminal may include one or more (Fig. 1 Only one is shown in the figure) processor 102 (processor 102 may include but not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the above-mentioned mobile terminal may also include A transmission device 106 and an input and output device 108 for communication functions.
- processor 102 may include but not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA
- memory 104 for storing data
- the above-mentioned mobile terminal may also include A transmission device 106 and an input and output device 108 for communication functions.
- FIG. 1 is only for illustration, and it does not limit the structure of the above mobile terminal.
- the mobile terminal may also include more or fewer components than those shown in FIG. 1 , or have a different configuration from that shown in FIG. 1 .
- the memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the loading method based on the linux kernel ko module in the embodiment of the present disclosure, the processor 102 runs the computer program stored in the memory 104 program, so as to execute various functional applications and service chain address pool slicing processing, that is, to realize the above-mentioned method.
- the memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.
- the memory 104 may further include a memory that is remotely located relative to the processor 102, and these remote memories may be connected to the mobile terminal through a network. Examples of the aforementioned networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
- the transmission device 106 is used to receive or transmit data via a network.
- the specific example of the above network may include a wireless network provided by the communication provider of the mobile terminal.
- the transmission device 106 includes a network interface controller (NIC for short), which can be connected to other network devices through a base station so as to communicate with the Internet.
- the transmission device 106 may be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet in a wireless manner.
- RF Radio Frequency
- a loading method based on the linux kernel ko module running on the above-mentioned mobile terminal or network architecture is provided, which is applied to a terminal, and the terminal accesses the source area through a dual connection (Dual Connection, referred to as DC)
- the current primary node MN cell and the current secondary node SN cell Fig. 2 is a flowchart of a loading method based on the linux kernel ko module according to an embodiment of the present disclosure, as shown in Fig. 2, the process includes the following steps:
- Step S202 detecting whether the current address is within the dynamic loading address range in the page fault exception processing flow of the linux kernel
- Step S204 if the current address is within the dynamic loading address range, dynamically load the current address through the page fault exception processing flow of the Linux kernel;
- Step S206 when the current standard is switched to another standard, dynamically release the code segment dynamically loaded into the physical memory under the current standard through the dynamic release interface.
- step S204 may specifically include:
- step S12 dynamically load the code segment of the current address with a page of the first predetermined size.
- step S12 can be specifically implemented in the following manner: if it is determined that the current address causing the exception is in Within the dynamically loaded link address range, judge whether the page table entry corresponding to the current address is already in the page table entry of the existing kernel; Synchronize to the page table entry of the current process to complete the dynamic loading of the current address; if the judgment result is no, if the page corresponding to the current address is being mapped, the current dynamic loading process is blocked and waits for the same After the other dynamic loading process of page completes the mapping and wakes up the current process, the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process to complete the dynamic loading of the current address; if the The page corresponding to the current address is not being mapped, first set the status of the page as a flag that is being mapped, and then calculate its page offset in the ko code segment according to the current
- step S206 may specifically include:
- step S22 traversing and releasing the temporary linked list, further, step S22 can be specifically implemented in the following manner:
- the mapping relationship of physical addresses clear the TLB (Translation Lookaside Buffer, address translation back-up buffer, referred to as fast table) cache; release the temporary memory address space of dynamically loaded pages recorded in the memory management node, and release the occupied memory management node memory space.
- TLB Translation Lookaside Buffer, address translation back-up buffer, referred to as fast table
- LTE/W/GSM Global System for Mobile Communication
- the PC Personal Computer, personal computer
- step S202 through the PC side, the code segment address range of each application scenario is marked with a predefined symbol in the link script generating the ko file, and the code that needs to be dynamically loaded in each application scenario Segments are reordered.
- the ko file is fixed to be loaded and run first, and the ko file is not unloaded, and the ko file is relocated on the PC side, that is, in the above steps Before S202, fix the first ko file loaded and running through the PC side, and not be unloaded, so that the starting address allocated by the kernel for the ko is fixed, so all the ko files involved in the ko file can be completed on the PC Relocation processing of functions, variable addresses and assembly codes, wherein the ko file includes multiple segments such as code segments, data segments, bss segments, and rodata segments.
- This embodiment dynamically loads and dynamically releases the kernel ko module.
- ko When ko is loaded, the text segment is not loaded into the memory. Only when the code segment address in ko is executed, if it is found that the current address has not been mapped to the physical address, a data exception or prefetch instruction exception page fault will occur. Enter the page fault exception handling process of the Linux kernel to complete the dynamic loading action.
- the process support for the dynamic loading of the code segment of the kernel ko module has been added. Every time a page fault exception is triggered, a page of a fixed size is loaded once to achieve the purpose of saving memory.
- a dynamic release interface is implemented in the Linux kernel to achieve the purpose of dynamically releasing the code segment dynamically loaded into the memory without unloading the kernel ko module.
- it is selected to release the code segment of the previous standard when the standard (LTE/W/GSM) is switched, which can save about 3M of memory space and play a role in projects with small DDR memory configurations. Very good memory compression effect, which promotes the reduction of project cost.
- the kernel ko module Since the protocol stack is compiled into a kernel ko module as a whole, the kernel ko module is relatively large, and the ko dynamic loading and dynamic release technology is applied to the kernel ko module.
- the specific process can be shown in the figure below.
- the multi-mode device When the multi-mode device is started, it will reside in a certain standard environment. In the business process under the current standard, if it is found that no physical mapping is performed when the code in ko is executed, a fault will be triggered. The page exception enters the dynamic loading process of ko to complete the mapping process. When the system is switched, it is necessary to dynamically release the code segment dynamically loaded in the previous system, and then complete the dynamic loading of the code segment required for this system to reside.
- Fig. 3 is the flow chart of the dynamic loading based on the Linux kernel ko module according to the present embodiment, as shown in Fig. 3, comprising:
- Step S301 the LTE multi-mode device is started, including camping in the LTE standard, camping in the W standard, and camping in the GSM standard;
- Step S302 select a system to reside in
- Step S303 execute the protocol stack business process
- Step S304 system switching
- Step S305 the kernel ko is dynamically released, and what is released is the code segment of the previous standard, and then enters step S303 for cyclic operation;
- step S306 judging whether the function in ko is executed (remarks: the release is modified to whether, and the figure also needs to be modified) to load the memory, and if the judgment result is yes, return to step S303, otherwise execute step S307;
- Step S307 triggering a page fault exception processing flow
- Step S308 the kernel ko is dynamically loaded, and the unit is page;
- Step S309 complete the dynamic loading.
- the dynamic loading of the Linux kernel ko may specifically include:
- the addresses of functions and variables in the existing kernel ko module are all determined during loading and running.
- the Linux kernel completes the relocation processing of all the functions and variable-related assembly codes involved in the ko, that is, if a ko is loaded/unloaded multiple times, the functions and variables in each loading
- the addresses may be different.
- the protocol stack ko processed by this solution is the first ko file to be loaded and run, and will not be unloaded.
- the starting address assigned by the kernel to the ko is fixed, so the ko file can be completed on the PC side. All involved functions, variables, and assembly codes are relocated (refer to the processing flow of the normal loading of the Linux kernel ko), so that the code segment can be directly read from the ko file during subsequent dynamic loading.
- the main purpose of the link script is to reorder the text code segments of the dynamically loaded kernel ko module, and perform centralized collection and sorting according to the functions executed in the actual application scenario, so as to collect frequently executed functions in one segment for dynamic loading Purpose, this can effectively improve the utilization rate of dynamically loaded pages and reduce the number of loading times.
- the EXCLUDE_FILE statement For the text section of the .o file that cannot be dynamically loaded, it is necessary to use the EXCLUDE_FILE statement to eliminate the .o file that does not need to be linked into the rest of the text section.
- the section of ps_2g_func below is to collect the gsm standard resident Below are all frequently executed functions, as follows:
- the cpko_text_start variable is the start symbol of the ko module code segment defined in the link script
- the modem_text_end variable is the end symbol of the code segment to be released.
- FIG. 4 is a schematic diagram of the page fault abnormal process of ko dynamic loading according to this embodiment, as shown in Fig. 4 , including:
- Step S401 judge whether the virtual address addr that caused the failure is within the address range of dynamic loading according to the incoming parameters, if the judgment result is no, execute step S402, and if the judgment result is yes, execute step S403 ,;
- Step S402 process from the solution corresponding to the original failure state of the kernel
- Step S403 judging whether addr has been mapped to the kernel page table entry pointed to by init_mm.pgd, if the judging result is yes, go to step S404, otherwise go to step S405;
- Step S404 synchronizing the kernel page table entry corresponding to addr to the current process page table entry, and completing the dynamic loading of this process; (note: there are many entries in the kernel page table, only the mapping page table entry of the current address is synchronized)
- Step S405 judging whether the page where addr is located is being mapped, if the judgment result is yes, go to step S406, otherwise go to step S407 (note: addr minus the start address of the ko code, then divided by the page size, is addr The page where it is located);
- Step S406 the current dynamic loading process is blocked and waits, and wakes up the current process after other dynamic loading processes of the same page complete the mapping, and then enters step S404;
- Step S407 calculate the code segment page offset of addr in the ko file, read the ko file with a predetermined size page according to the value of the page offset for dynamic loading, and store the read page data in the requested temporary memory space , establish a memory management node, record the temporary memory space and addr of the dynamically loaded page, and add the memory management node to the linked list;
- Step S408 synchronizing the kernel page table entry corresponding to addr to the current process page table entry, and performing the operation of invalid cache and BTB;
- Step S409 judging whether the waiting queue is empty, if the judgment result is No, execute Step S410, and if the judgment result is Yes, execute Step S411;
- Step S410 triggering to wake up other processes waiting for the same page mapping; (Note: to wake up other waiting processes, not waiting)
- step S411 the dynamic loading exception flow processing ends this time.
- the loading address of the ko module is managed by the kernel page directory table and stored in the global directory init_mm.pgd (swapper_pg_dir) of the main kernel page, so every time the mapping is done, the base address of the kernel page table init_mm is directly used according to the original scheme. pgd is mapped first. In the processing of the page fault exception process, it is first necessary to determine whether the page corresponding to addr has been mapped to the "kernel page table entry". (current->actinve_mm->pgd) page table entry" can complete this address mapping exception process.
- Manage all code segments that are dynamically loaded into the memory according to the page define two global variables, an array that manages the mapping state of the page, such as setting the flag bit that the page is mapping; an array of completions used to manage page mapping synchronization , so that the mapping of each page is independently synchronized through the amount of completion, because the mapping of the same page may trigger page fault exception processing by different processes at the same time, so synchronization processing is required, and only one page fault is allowed The process performs virtual address mapping and sets the flag being mapped at the same time.
- the function read_code_file is the interface used to read the relocated ko module file from the file system.
- the incoming read parameter is the code segment page offset of addr relative to the ko file (read in page units).
- the read code segment is temporarily stored in the memory space applied by get_zeroed_page (GFP_KERNEL), and the memory is applied as a memory management node to record the storage address and addr of the dynamically loaded page.
- linked lists are used to manage memory management nodes, which are GSM/W/LTE/common code segments.
- memory management nodes which are GSM/W/LTE/common code segments.
- the code segment has been dynamically loaded into the memory space requested by get_zeroed_page. At this time, the virtual address corresponding to addr needs to be mapped to the physical memory corresponding to the code segment. This step can be completed by calling ioremap_page(addr&PAGE_MASK, _pa(vir_codebuf), mtype).
- Fig. 5 is according to the release flowchart of the dynamic loading of linux kernel ko of the present embodiment, as shown in Fig. 5, comprises:
- Step S501 copy the linked list to be released to the temporary linked list tmp_page_list, and traverse and release from the temporary linked list. This can reduce the time occupied by linked list resources.
- Step S502 traversing and deleting the memory management nodes recorded in the linked list from the temporary linked list.
- Step S503 clear the page mapping status flag recorded in the global variable, and reset the completed amount. Since the mapping mark has been set during the page fault mapping, remember to clear the mark of the page when releasing it, and also reset the completion amount page_completion of the page.
- Step S504 breaking the mapping relationship between the current address addr recorded in the memory management node and the physical address corresponding to the dynamically loaded page, and performing a flush operation on the tlb cache.
- Step S505 release the temporary storage memory of the dynamically loaded page recorded by the memory management node, and release the space of the memory management node at the same time.
- a loading device based on the linux kernel ko module is also provided, and Fig. 6 is a block diagram of a loading device based on the linux kernel ko module according to the present embodiment, as shown in Fig. 6 , including:
- Detection module 62 is configured to detect whether the current address is within the dynamic loading address range in the abnormal page fault processing flow of the linux kernel;
- the loading module 64 is configured to dynamically load the current address by the page fault exception processing flow of the Linux kernel if the current address is within the dynamic loading address range;
- the first release module 66 is configured to dynamically release the code segments dynamically loaded into the physical memory under the current standard through the dynamic release interface when the current standard is switched to another standard.
- the loading module 64 includes:
- a new sub-module is added, which is set to add a dynamic loading process for dynamically loading the code segment of the kernel ko module in the page fault exception handling process of the linux kernel;
- the loading submodule is configured to dynamically load the code segment at the current address with a page of a first predetermined size in the dynamic loading process.
- the loading submodule is also set to
- the loading submodule is also set to
- a predetermined size of memory is used as a memory management node for recording the temporary storage memory address of the dynamically loaded page and the current address, and the memory management node is added to the linked list;
- the first release module 66 includes:
- Copy submodule set to copy the linked list to be released to the temporary linked list
- the release submodule is set to traverse and release the temporary linked list.
- the release sub-module is also set to
- the device also includes:
- the second release module is configured to release all code segments in the ko file that need to be dynamically loaded during the system startup phase.
- the device further includes:
- the sorting module is configured to, through the PC side, mark the code segment address ranges of each application scenario with predefined symbols in the link script generating the ko file, and reorder the code segments that need to be dynamically loaded in each application scenario .
- the ko file is fixed to be loaded and run first, and the ko file is not unloaded, and the relocation process of the ko file is completed on the PC side.
- Embodiments of the present disclosure also provide a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps in any one of the above method embodiments when running.
- the above-mentioned computer-readable storage medium may include but not limited to: U disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM) , mobile hard disk, magnetic disk or optical disk and other media that can store computer programs.
- ROM read-only memory
- RAM random access memory
- mobile hard disk magnetic disk or optical disk and other media that can store computer programs.
- Embodiments of the present disclosure also provide an electronic device, including a memory and a processor, where a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.
- the electronic device may further include a transmission device and an input and output device, wherein the transmission device is connected to the processor, and the input and output device is connected to the processor.
- each module or each step of the above-mentioned disclosure can be realized by a general-purpose computing device, and they can be concentrated on a single computing device, or distributed in a network composed of multiple computing devices In fact, they can be implemented in program code executable by a computing device, and thus, they can be stored in a storage device to be executed by a computing device, and in some cases, can be executed in an order different from that shown here. Or described steps, or they are fabricated into individual integrated circuit modules, or multiple modules or steps among them are fabricated into a single integrated circuit module for implementation. As such, the present disclosure is not limited to any specific combination of hardware and software.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Abstract
本公开实施例提供了一种基于linux内核ko模块的加载方法及装置,该方法包括:在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内;若该当前地址在动态加载地址范围之内,通过Linux内核的缺页异常处理流程对该当前地址进行动态加载;在当前制式切换为其他制式时,通过动态释放接口对该当前制式下动态加载到物理内存中的代码段进行动态释放,可以解决相关技术中Linux内核ko模块的加载是将ko文件整体载入到内存空间中,如果ko版本较大会出现ko模块占用内存过多的问题,通过动态加载与动态释放,减少了ko模块的占用内存。
Description
相关申请的交叉引用
本公开基于2021年06月28日提交的发明名称为“一种基于linux内核ko模块的加载方法及装置”的中国专利申请CN202110723379.9,并且要求该专利申请的优先权,通过引用将其所公开的内容全部并入本公开。
本公开实施例涉及通信领域,具体而言,涉及一种基于linux内核ko模块的加载方法及装置。
现有内核ko模块的加载技术是在Linux内核启动时完成对该ko中所有涉及的函数、变量相关汇编代码的重定位处理。目前Linux内核ko模块的加载都是整体载入到内存空间中,如果ko版本较大的情况下,会出现ko模块占用内存过多的情况。
针对相关技术中Linux内核ko模块的加载是将ko文件整体载入到内存空间中,如果ko版本较大会出现ko模块占用内存过多的问题,尚未提出解决方案。
发明内容
本公开实施例提供了一种基于linux内核ko模块的加载方法及装置,以至少解决相关技术中Linux内核ko模块的加载是将ko文件整体载入到内存空间中,如果ko版本较大会出现ko模块占用内存过多的问题。
根据本公开的一个实施例,提供了一种基于linux内核ko模块的加载方法,包括:
在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内;
若所述当前地址在动态加载地址范围之内,通过Linux内核的缺页异常处理流程对所述当前地址进行动态加载;
在当前制式切换为其他制式时,通过动态释放接口对所述当前制式下动态加载到物理内存中的代码段进行动态释放。
根据本公开的另一个实施例,还提供了一种基于linux内核ko模块的加载装置,包括:
检测模块,设置为在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内;
加载模块,设置为若所述当前地址在动态加载地址范围之内,通过Linux内核的缺页异常处理流程对所述当前地址进行动态加载;
第一释放模块,设置为在当前制式切换为其他制式时,通过动态释放接口对所述当前制式下动态加载到物理内存中的代码段进行动态释放。
根据本公开的又一个实施例,还提供了一种计算机可读的存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本公开的又一个实施例,还提供了一种电子装置,包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
本公开实施例,在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内;若所述当前地址在动态加载地址范围之内,通过Linux内核的缺页异常处理流程对所述当前地址进行动态加载;在当前制式切换为其他制式时,通过动态释放接口对所述当前制式下动态加载到物理内存中的代码段进行动态释放,可以解决相关技术中Linux内核ko模块的加载是将ko文件整体载入到内存空间中,如果ko版本较大会出现ko模块占用内存过多的问题,当前地址还未映射到物理地址上产生数据异常或者预取指令异常缺页时,进入到Linux内核的缺页异常处理流程中完成动态加载,在Linux内核中设置动态释放的接口,以达到内核ko模块不被卸载的情况下能够对动态加载到内存中的代码段进行动态释放的目的,通过动态加载与动态释放,减少了ko模块的占用内存。
图1是本公开实施例的基于linux内核ko模块的加载方法的移动终端的硬件结构框图;
图2是根据本公开实施例的基于linux内核ko模块的加载方法的流程图;
图3是根据本实施例的基于Linux内核ko模块的动态加载的流程图;
图4是根据本实施例的ko动态加载缺页异常流程的示意图;
图5是根据本实施例的linux内核ko动态加载的释放流程图;
图6是根据本实施例的基于linux内核ko模块的加载装置的框图。
下文中将参考附图并结合实施例来详细说明本公开的实施例。
需要说明的是,本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。
本公开实施例中所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例,图1是本公开实施例的基于linux内核ko模块的加载方法的移动终端的硬件结构框图,如图1所示,移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104,其中,上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解,图1所示的结构仅为示意,其并不对上述移动终端的结构造成限定。例如,移动终端还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。
存储器104可用于存储计算机程序,例如,应用软件的软件程序以及模块,如本公开实施例中的基于linux内核ko模块的加载方法对应的计算机程序,处理器102通过运行存储在存储器104内的计算机程序,从而执行各种功能应用以及业务链地址池切片处理,即实现上述的方法。存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至移动终端。 上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中,传输装置106包括一个网络适配器(Network Interface Controller,简称为NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输装置106可以为射频(Radio Frequency,简称为RF)模块,其用于通过无线方式与互联网进行通讯。
在本实施例中提供了一种运行于上述移动终端或网络架构的基于linux内核ko模块的加载方法,应用于终端,所述终端通过双连接(Dual Connection,简称为DC)接入源区域的当前主节点MN小区与当前辅节点SN小区,图2是根据本公开实施例的基于linux内核ko模块的加载方法的流程图,如图2所示,该流程包括如下步骤:
步骤S202,在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内;
步骤S204,若所述当前地址在动态加载地址范围之内,通过Linux内核的缺页异常处理流程对所述当前地址进行动态加载;
步骤S206,在当前制式切换为其他制式时,通过动态释放接口对所述当前制式下动态加载到物理内存中的代码段进行动态释放。
本实施例中,上述步骤S204具体可以包括:
S11,在linux内核的缺页异常处理流程中新增对内核ko模块的代码段进行动态加载的动态加载流程;
S12,在所述动态加载流程中以第一预定大小的page对所述当前地址的代码段进行动态加载,进一步的,步骤S12具体可以通过以下方式实现:若确定引起异常的所述当前地址在动态加载的链接地址范围之内,判断所述当前地址对应的页表项是否已在存在内核的页表项中;在判断结果为是的情况下,将所述当前地址对应的内核页表项同步到当前进程的页表项中,完成对所述当前地址的动态加载;在判断结果为否的情况下,若所述当前地址对应的page正在进行映射,当前动态加载流程阻塞等待,待同page的其它动态加载流程完成映射后唤醒当前流程之后,将所述当前地址对应的内核页表项同步到所述当前进程的页表项中,完成对所述当前地址的动态加载;若所述当前地址对应的page不是正在进行映射,则首先设置page的状态为正在进行映射的标记,然后根据所述当前地址计算出其在ko代码段中的page页偏移,以预定大小的page开始进行加载,将读取出的page大小数据存储在申请的临时内存空间中,并同时申请内存空间作为page对应的内存管理节点,用于记录动态加载页的临时存储内存地址和所述当前地址,添加当前内存管理节点到链表中;将所述当前地址映射到动态加载页对应的物理内存上;将所述当前地址对应的内核页表项同步到所述当前进程的页表项中,同时进行无效cache和BTB(Branch Target Buffer,分支目标缓冲)的操作;若检测到等待队列为空,完成对所述当前地址的动态加载。若检测到等待队列不为空,需首先唤醒等待映射完成的流程,然后完成对所述当前地址的动态加载。
在linux内核的缺页异常机制中实现ko的动态加载流程,当执行ko中的代码段地址时如果发现未映射到物理地址上时则触发缺页异常处理流程,每次触发加载一个page的代码段,对于未执行到的代码段则不载入到内存空间中。
本实施例中,上述步骤S206具体可以包括:
S21,将要释放的链表拷贝到临时链表中;
S22,对所述临时链表进行遍历释放,进一步的,步骤S22具体可以通过以下方式实现:
从所述临时链表中删除page对应的内存管理节点,并清除page的状态标记,包括映射的标记位清除及复位完成量;断开内存管理节点中的所述当前地址addr和动态加载页对应的物理地址的映射关系;对TLB(Translation Lookaside Buffer,地址转换后援缓冲器,简称为快表)缓存进行清除操作;释放内存管理节点中记录的动态加载页临时内存地址空间,同时释放内存管理节点占用的内存空间。
在不卸载ko模块的情况下,在制式(LTE/W/GSM)切换时对之前一个制式动态加载的代码段进行动态释放,以节省内存空间,其中,LTE为长期演进(Long Term Evaluation),GSM为全球移动通信系统(Global System for Mobile Communication)。
在一示例性实施例中,在为所述ko文件分配固定的起始地址,通过PC(Personal Computer,个人计算机)侧完成所述ko文件中所有涉及的函数、变量汇编代码的重定位处理之后,将所述ko文件中需要动态加载的代码段在系统启动阶段全部释放。
进一步的,在上述步骤S202之前,通过PC侧,在生成所述ko文件的链接脚本中通过预定义符号标记各个应用场景的代码段地址范围,并对所述各个应用场景中需要动态加载的代码段进行重新排序。
在另一示例性实施例中,所述ko文件是固定第一个加载运行的,且所述ko文件不被卸载,所述ko文件是在PC侧上完成重定位处理的,即在上述步骤S202之前,通过PC侧固定第一个加载运行的ko文件,且不被卸载,这样内核为所述ko分配的起始地址就是固定的,因此可在PC上完成所述ko文件中所有涉及的函数、变量地址及汇编代码的重定位处理,其中,所述ko文件包括代码段、数据段、bss段、rodata段等多个段。
本实施例对内核ko模块的动态加载和动态释放。在ko加载时text段都是不加载到内存中的,只有执行到ko中的代码段地址时,如果发现当前地址还未映射到物理地址上就会产生数据异常或者预取指令异常缺页,进入到Linux内核的缺页异常处理流程中完成动态加载的动作。在linux内核的缺页流程中新增了对内核ko模块代码段动态加载的流程支持,每次触发缺页异常时都以固定大小的page进行一次加载,达到节省内存的目的。在Linux内核中实现了动态释放的接口,以达到内核ko模块不被卸载的情况下能够对动态加载到内存中的代码段进行动态释放的目的。在本实施例的一个应用实例中是选择在制式(LTE/W/GSM)切换的时候对之前制式的代码段进行释放,可以节省3M左右的内存空间,对于DDR内存配置较小的项目起到很好的内存压缩作用,促进了项目成本的降低。
由于协议栈是整体编译成一个内核ko模块,所以导致内核ko模块较大,针对该内核ko模块应用ko的动态加载和动态释放技术。其具体流程可如下图所示,在多模设备启动时会驻留到某一个制式环境下,在当前制式下的业务流程中,如果执行到ko中的代码时发现未做物理映射则触发缺页异常进入ko的动态加载流程完成本次映射过程。当制式进行切换的时候,就需要把之前制式动态加载的代码段进行动态释放操作,然后在完成本次制式驻留所需代码段的动态加载。
应用产品的实施包括但不限于协议栈ko模块,任何内核ko模块都可以采用该技术进行实施来达到省内存空间,节约设备成本的目的。图3是根据本实施例的基于Linux内核ko模块的动态加载的流程图,如图3所示,包括:
步骤S301,LTE多模设备启动,包括LTE制式驻留、W制式驻留以及GSM制式驻留;
步骤S302,选择制式驻留;
步骤S303,执行协议栈业务流程;
步骤S304,制式切换;
步骤S305,内核ko动态释放,释放的是之前制式的代码段,之后进入步骤S303进行循环操作;
S306,判断执行ko中函数是否(备注:释放修改为是否,图中也要修改)载入内存,在判断结果为是的情况下,返回步骤S303,否则执行步骤S307;
步骤S307,触发缺页异常处理流程;
步骤S308,内核ko动态加载,以page为单位;
步骤S309,完成动态加载。
本实施例中Linux内核ko动态加载,具体可以包括:
1,ko模块PC侧处理;
现有内核ko模块中的函数、变量的地址都是在加载运行时确定的。当该ko文件被加载时,由Linux内核完成对该ko中所有涉及的函数、变量相关汇编代码的重定位处理,即如果一个ko被加载/卸载多次,每次加载中的函数、变量的地址都可能不一样。本方案处理的协议栈ko是固定第一个加载运行的ko文件,且不被卸载,这种场景下,内核为该ko分配起始地址是固定的,因此可以在PC侧完成该ko文件中所有涉及的函数、变量及汇编代码进行重定位处理(参考Linux内核ko正常加载的处理流程),这样的话后续动态加载时可以直接从该ko文件中读取代码段。
2,ko链接脚本的实现;
链接脚本主要目的是对动态加载的内核ko模块的text代码段进行重新排序,并根据实际应用场景执行到的函数做集中收集排序,以达到把频繁执行的函数收集在一个段中进行动态加载的目的,这样能够有效提高动态加载页的利用率,减少加载的次数。对于不能进行动态加载的.o文件的text段放在一起,这就需要使用EXCLUDE_FILE语句来剔除不需要链接进其余text段的.o文件,举例说明:比如下面ps_2g_func的段就是收集gsm制式驻留下所有频繁执行到的函数,如下所示:
在链接脚本中自定义符号标记来区分各个应用场景的地址范围,方便内核在动态加载的时候能够区分所加载的地址属于哪一个根据应用场景的text代码段中,这样在释放的时候可以根据应用场景的变换进行释放。举例说明:比如cpko_text_start变量就是在链接脚本中定义的ko模块代码段的起始符号,modem_text_end变量是要释放代码段的结束符号,这些都需要注册进内核中,方便内核使用该标记判断动态代码段加载开始及结束的地址。
3,动态加载的ko代码段全释放;
在Linux内核insomod加载ko的正常流程中,整个ko会完全加载进内存中,在ko完成加载后,需要在ko的初始化入口处把要动态加载的代码段全部释放掉,同时获取ko文件的句柄以及注册内核需要的各个应用场景的text代码段开始的变量标记,过程实例如下所示:
4,ko动态加载缺页异常流程。
系统启动后,当内核执行到动态代码加载的地址范围的时候,由于该地址空间在ko模块初始化入口处已经全部释放过,所以目前是未映射到任何具体的物理地址上的,这时系统就会产生数据异常和预取指令异常缺页,分别调用do_DataAbort和do_PrefetchAbort函数进行缺页异常的处理流程。而动态代码加载的实现主要就是在该流程中。图4是根据本实施例的ko动态加载缺页异常流程的示意图,如图4所示,包括:
步骤S401,根据传入参数来判断引起失效的虚拟地址addr是否在动态加载的地址范围之内,在判断结果为否的情况下,执行步骤S402,在判断结果为是的情况下,执行步骤S403,;
步骤S402,从内核的原始失效状态对应的方案进行处理;
步骤S403,判断addr是否已经映射到init_mm.pgd指向的内核页表项中,在判断结果为是的情况下,执行步骤S404,否则执行步骤S405;
步骤S404,将addr对应的内核页表项同步到当前进程页表项中,完成本流程的动态加载;(备注:内核页表中有很多项,只同步当前地址的映射页表项)
步骤S405,判断addr所在的page是否正在做映射,在判断结果为是的情况下,执行步骤S406,否则执行步骤S407(备注:addr减去ko代码起始地址,然后除以page大小,就是addr所在的page);
步骤S406,当前动态加载流程阻塞等待,待同page的其它动态加载流程完成映射后唤醒当前流程,之后进入步骤S404;
步骤S407,计算addr在ko文件中的代码段页偏移,根据页偏移的值以预定大小的page读取ko文件进行动态加载,将读取出的page数据存储在申请的临时内存空间中,建立内存管理节点,记录动态加载页的临时内存空间及addr,并添加内存管理节点到链表中;
步骤S408,将addr对应的内核页表项同步到当前进程页表项中,做无效cache和BTB 的操作;
步骤S409,判断等待队列是否为空,在判断结果为否的情况下,执行步骤S410,在判断结果为是的情况下,执行步骤S411;
步骤S410,触发唤醒等待同page映射的其他流程;(备注:要唤醒其他等待流程,不是等待)
步骤S411,本次动态加载异常流程处理结束。
ko模块的加载地址是由内核页目录表管理,存放在主内核页全局目录init_mm.pgd(swapper_pg_dir)中,所以每次做映射的时候都是依照原始方案直接使用内核的页表基地址init_mm.pgd先进行映射的。在缺页异常流程处理中要首先判断addr对应的page是否已经映射到“内核的页表项”中,如已经做了映射,只需要同步该页的“内核的页表项”到“当前进程(current->actinve_mm->pgd)的页表项”中即可完成本次地址映射异常流程。
对动态加载到内存中的所有代码段按照页进行管理,定义两个全局变量,一个管理page的映射状态的数组,比如设置page正在映射的标记位;一个用于管理page映射同步的完成量数组,这样每个页的映射都独立的通过完成量completion来进行同步,因为同一个页的映射可能会同时由不同的流程触发缺页的异常处理,这样就需要做同步处理,只允许一个缺页流程进行虚拟地址映射,同时置位正在映射的标记,其他触发该页的缺页异常流程如发现该页正在映射的标记已置位的情况下,需要调用wait_for_completion(&page_completion[page_index])等待该页的映射结束才能返回,返回前要“同步页表项”。
函数read_code_file是用来从文件系统中读取重定位好的ko模块文件的接口。传入的读取参数是addr相对于ko文件的代码段页偏移(以页为单位进行读取)。读取的代码段临时存储在get_zeroed_page(GFP_KERNEL)申请的内存空间,同时申请内存作为内存管理节点用于记录动态加载页的存储地址和addr。
本实施例采用四个链表来管理内存管理节点,分别为GSM/W/LTE/公共代码段,各个制式在动态加载代码段到内存的时候会把相应的内存管理节点添加到链表中,方便制式切换的时候释放其他制式下的动态加载的内存空间。
代码段已经动态加载进get_zeroed_page申请的内存空间,这时就需要把addr对应的虚拟地址映射到代码段对应的物理内存中,调用ioremap_page(addr&PAGE_MASK,_pa(vir_codebuf),mtype)可以完成该步骤。
同步“内核的页表项”到“当前进程的页表项”中,同时做无效cache和BTB的操作,防止cache不一致导致的问题。
映射流程结束后,需要调用waitqueue_active(&page_completion[page_index].wait)来判断在等待该页映射的进程队列是否存在,存在的话需要调用complete_all全部触发完成量的等待唤醒。
本实施例中的linux内核ko动态加载的释放,具体包括:
在系统启动后,随着测试场景的变化,最终都会把所有代码动态加载到内存中,这就和ko完全加载占用的内存是一样的,没有达到节约内存的目的,所以需要考虑内存释放的情况。本方案中选择在制式切换的时候来进行内存的释放,因为在链接的时候对GSM/W/LTE/modem公共代码分别链接进单独的地址区间中,动态加载的时候根据链接地址范围已经加入到相应 的链表中,这样在制式切换的时候才能对已加载其它制式及公共的代码进行释放操作,同时也可以在系统内存紧张的情况下,对这部分内存进行临时释放,以缓解系统内存压力。图5是根据本实施例的linux内核ko动态加载的释放流程图,如图5所示,包括:
步骤S501,将要释放的链表拷贝到临时链表tmp_page_list中,从临时链表进行遍历释放。这样可以减少对链表资源占用的时间。
步骤S502,从临时链表中遍历删除链表中记录的内存管理节点。
步骤S503,清除在全局变量中记录的页映射状态标记,并复位完成量。由于在缺页映射的时候已经置位了映射的标记,所以在释放的时候要记得对该page页的标记进行清除,同时也要对该page的完成量page_completion进行复位操作。
步骤S504,断开内存管理节点中记录的所述当前地址addr和动态加载页对应的物理地址的映射关系,对tlb缓存进行flush操作。
步骤S505,释放内存管理节点记录的动态加载页的临时存储内存,同时释放内存管理节点空间。
根据本公开的另一个实施例,还提供了一种基于linux内核ko模块的加载装置,图6是根据本实施例的基于linux内核ko模块的加载装置的框图,如图6所示,包括:
检测模块62,设置为在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内;
加载模块64,设置为若所述当前地址在动态加载地址范围之内,通过Linux内核的缺页异常处理流程对所述当前地址进行动态加载;
第一释放模块66,设置为在当前制式切换为其他制式时,通过动态释放接口对所述当前制式下动态加载到物理内存中的代码段进行动态释放。
在一示例性实施例中,所述加载模块64包括:
新增子模块,设置为在linux内核的缺页异常处理流程中新增对内核ko模块的代码段进行动态加载的动态加载流程;
加载子模块,设置为在所述动态加载流程中以第一预定大小的page对所述当前地址的代码段进行动态加载。
在一示例性实施例中,所述加载子模块,还设置为
若确定引起异常的所述当前地址在动态加载的链接地址范围之内,判断所述当前地址对应的page是否已映射到内核的页表项中;
在判断结果为是的情况下,将所述当前地址对应的内核页表项同步到当前进程的页表项中,完成对所述当前地址的动态加载;
在判断结果为否的情况下,若所述当前地址对应的page正在进行映射,控制当前动态加载流程进入阻塞等待,待所述page的其它动态加载流程完成映射后唤醒所述当前动态加载流程之后,将所述当前地址对应的内核页表项同步到所述当前进程的页表项中,完成对所述当前地址的动态加载;
若所述当前地址对应的page不是正在进行映射,根据所述当前地址计算出所述page在ko代码段中的page页偏移,并根据所述page页偏移对所述当前地址进行动态加载。
在一示例性实施例中,所述加载子模块,还设置为
将所述page的状态标记设置为正在进行映射,根据所述page页偏移开始进行加载,将 所述page页偏移读取出的数据存储在申请的临时内存空间中,并同时申请第二预定大小的内存作为记录动态加载页的临时存储内存地址和所述当前地址的内存管理节点,将所述内存管理节点添加到链表中;
将所述当前地址映射到所述临时内存空间对应的物理地址上,并将所述当前地址对应的内核页表项同步到所述当前进程的页表项中,同时进行无效cache和BTB的操作;
若检测到所述等待队列不为空,唤醒所述阻塞等待的流程,完成对所述当前地址的动态加载;
若检测到等待队列为空,完成对所述当前地址的动态加载。
在一示例性实施例中,所述第一释放模块66包括:
拷贝子模块,设置为将要释放的链表拷贝到临时链表中;
释放子模块,设置为对所述临时链表进行遍历释放。
在一示例性实施例中,所述释放子模块,还设置为
从所述临时链表中删除page对应的内存管理节点,并清除所述page的状态标记;
断开内存管理节点中的所述当前地址和临时内存空间对应的物理地址的映射关系;
对TLB缓存进行清除操作;
释放所述内存管理节点中记录的临时内存空间,同时释放所述内存管理节点占用的内存。
在一示例性实施例中,所述装置还包括:
第二释放模块,设置为将所述ko文件中需要动态加载的代码段在系统启动阶段全部释放。
在另一示例性实施例中,所述装置还包括:
排序模块,设置为通过PC侧,在生成所述ko文件的链接脚本中通过预定义符号标记各个应用场景的代码段地址范围,并对所述各个应用场景中需要动态加载的代码段进行重新排序。
在本实施例中,所述ko文件是固定第一个加载运行的,且所述ko文件不被卸载,所述ko文件是在PC侧上完成重定位处理的。
本公开的实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有计算机程序,其中,该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中,上述计算机可读存储介质可以包括但不限于:U盘、只读存储器(Read-Only Memory,简称为ROM)、随机存取存储器(Random Access Memory,简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本公开的实施例还提供了一种电子装置,包括存储器和处理器,该存储器中存储有计算机程序,该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中,上述电子装置还可以包括传输设备以及输入输出设备,其中,该传输设备和上述处理器连接,该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例,本实施例在此不再赘述。
显然,本领域的技术人员应该明白,上述的本公开的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上, 它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本公开不限制于任何特定的硬件和软件结合。
以上所述仅为本公开的优选实施例而已,并不用于限制本公开,对于本领域的技术人员来说,本公开可以有各种更改和变化。凡在本公开的原则之内,所作的任何修改、等同替换、改进等,均应包含在本公开的保护范围之内。
Claims (12)
- 一种基于linux内核ko模块的加载方法,包括:在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内;若所述当前地址在动态加载地址范围之内,通过Linux内核的缺页异常处理流程对所述当前地址进行动态加载;在当前制式切换为其他制式时,通过动态释放接口对所述当前制式下动态加载到物理内存中的代码段进行动态释放。
- 根据权利要求1所述的方法,其中,通过Linux内核的缺页异常处理流程对所述当前地址进行动态加载包括:在所述linux内核的缺页异常处理流程中新增对内核ko模块的代码段进行动态加载的动态加载流程;在所述动态加载流程中以第一预定大小的page对所述当前地址的代码段进行动态加载。
- 根据权利要求2所述的方法,其中,在所述动态加载流程中以第一预定大小的page对所述当前地址的代码段进行动态加载包括:若确定引起异常的所述当前地址在动态加载的链接地址范围之内,判断所述当前地址对应的page是否已映射到内核的页表项中;在判断结果为是的情况下,将所述当前地址对应的内核页表项同步到当前进程的页表项中,完成对所述当前地址的动态加载;在判断结果为否的情况下,若所述当前地址对应的page正在进行映射,控制当前动态加载流程进入阻塞等待,待所述page的其它动态加载流程完成映射后唤醒所述当前动态加载流程之后,将所述当前地址对应的内核页表项同步到所述当前进程的页表项中,完成对所述当前地址的动态加载;若所述当前地址对应的page不是正在进行映射,根据所述当前地址计算出所述page在ko代码段中的page页偏移,并根据所述page页偏移对所述当前地址进行动态加载。
- 根据权利要求3所述的方法,其中,根据所述page页偏移对所述当前地址进行动态加载包括:将所述page的状态标记设置为正在进行映射,根据所述page页偏移开始进行加载,将所述page页偏移读取出的数据存储在申请的临时内存空间中,并同时申请第二预定大小的内存作为记录动态加载页的临时存储内存地址和所述当前地址的内存管理节点,将所述内存管理节点添加到链表中;将所述当前地址映射到所述临时内存空间对应的物理地址上,并将所述当前地址对应的内核页表项同步到所述当前进程的页表项中,同时进行无效cache和分支目标缓冲BTB的操作;若检测到所述等待队列不为空,唤醒所述阻塞等待的流程,完成对所述当前地址的动态加载;若检测到等待队列为空,完成对所述当前地址的动态加载。
- 根据权利要求1所述的方法,其中,通过所述动态释放接口对动态加载到所述物理内存中的代码段进行动态释放包括:将要释放的链表拷贝到临时链表中;对所述临时链表进行遍历释放。
- 根据权利要求5所述的方法,其中,对所述临时链表进行遍历释放包括:从所述临时链表中删除page对应的内存管理节点,并清除所述page的状态标记;断开内存管理节点中的所述当前地址和临时内存空间对应的物理地址的映射关系;对地址转换后援缓冲器TLB缓存进行清除操作;释放所述内存管理节点中记录的临时内存空间,同时释放所述内存管理节点占用的内存。
- 根据权利要求1至6中任一项所述的方法,其中,在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内之前,所述方法还包括:将所述ko文件中需要动态加载的代码段在系统启动阶段全部释放。
- 根据权利要求7所述的方法,其中,在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内之前,所述方法还包括:通过PC侧,在生成所述ko文件的链接脚本中通过预定义符号标记各个应用场景的代码段地址范围,并对所述各个应用场景中需要动态加载的代码段进行重新排序。
- 根据权利要求8所述的方法,其中,所述ko文件是固定第一个加载运行的,且所述ko文件不被卸载,所述ko文件是在PC侧上完成重定位处理的。
- 一种基于linux内核ko模块的加载装置,包括:检测模块,设置为在linux内核的缺页异常处理流程中检测当前地址是否在动态加载地址范围之内;加载模块,设置为若所述当前地址在动态加载地址范围之内,通过Linux内核的缺页异常处理流程对所述当前地址进行动态加载;第一释放模块,设置为在当前制式切换为其他制式时,通过动态释放接口对所述当前制式下动态加载到物理内存中的代码段进行动态释放。
- 一种计算机可读的存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行所述权利要求1至9任一项中所述的方法。
- 一种电子装置,包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行所述权利要求1至9任一项中所述的方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110723379.9A CN115599448A (zh) | 2021-06-28 | 2021-06-28 | 一种基于linux内核ko模块的加载方法及装置 |
CN202110723379.9 | 2021-06-28 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023273424A1 true WO2023273424A1 (zh) | 2023-01-05 |
Family
ID=84691131
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2022/081865 WO2023273424A1 (zh) | 2021-06-28 | 2022-03-19 | 一种基于linux内核ko模块的加载方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN115599448A (zh) |
WO (1) | WO2023273424A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116243971A (zh) * | 2023-05-10 | 2023-06-09 | 北京麟卓信息科技有限公司 | 一种基于静态依赖自举的内核无关的模块构建方法 |
CN117251216A (zh) * | 2023-09-15 | 2023-12-19 | 上海合芯数字科技有限公司 | 一种服务器固件启动优化方法、系统、服务器及存储介质 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117149499B (zh) * | 2023-10-30 | 2024-01-19 | 北京麟卓信息科技有限公司 | 一种基于动态符号表的内核模块内存占用优化方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101324850A (zh) * | 2007-06-12 | 2008-12-17 | 中兴通讯股份有限公司 | Linux内核动态加载方法 |
CN102938035A (zh) * | 2012-11-08 | 2013-02-20 | 西安交通大学 | 一种在虚拟机内部的驱动隔离系统与方法 |
US20170123999A1 (en) * | 2015-10-28 | 2017-05-04 | International Business Machines Corporation | Efficient translation reloads for page faults |
-
2021
- 2021-06-28 CN CN202110723379.9A patent/CN115599448A/zh active Pending
-
2022
- 2022-03-19 WO PCT/CN2022/081865 patent/WO2023273424A1/zh active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101324850A (zh) * | 2007-06-12 | 2008-12-17 | 中兴通讯股份有限公司 | Linux内核动态加载方法 |
CN102938035A (zh) * | 2012-11-08 | 2013-02-20 | 西安交通大学 | 一种在虚拟机内部的驱动隔离系统与方法 |
US20170123999A1 (en) * | 2015-10-28 | 2017-05-04 | International Business Machines Corporation | Efficient translation reloads for page faults |
Non-Patent Citations (4)
Title |
---|
ANONYMOUS: "Everything is a mapping: Talking about page fault exceptions in the operating system kernel (Page Fault)", 8 March 2018 (2018-03-08), pages 1 - 6, XP093020471, Retrieved from the Internet <URL:https://cloud.tencent.com/developer/article/1807351> [retrieved on 20220511] * |
LUCIEN: "Analysis of Dynamic Loading Technology of Linux Kernel Module LKM", 8 September 2012 (2012-09-08), pages 1 - 24, XP093020468, Retrieved from the Internet <URL:https://blog.csdn.net/lucien_cc/article/details/7959076> [retrieved on 20230203] * |
TU ALAN: "Linux memory management - page fault exception handling", 8 March 2018 (2018-03-08), pages 1 - 28, XP093020469, Retrieved from the Internet <URL:https://www.cnblogs.com/alantu2018/p/8527077.html> [retrieved on 20220511] * |
ZHANG JISHENG: "Techniques Based on Virtual Machine in Anti-Rootkit", CHINESE MASTER'S THESES FULL-TEXT DATABASE, 9 May 2009 (2009-05-09), pages 1 - 72, XP093020466, ISSN: 1674-0246 * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116243971A (zh) * | 2023-05-10 | 2023-06-09 | 北京麟卓信息科技有限公司 | 一种基于静态依赖自举的内核无关的模块构建方法 |
CN117251216A (zh) * | 2023-09-15 | 2023-12-19 | 上海合芯数字科技有限公司 | 一种服务器固件启动优化方法、系统、服务器及存储介质 |
CN117251216B (zh) * | 2023-09-15 | 2024-04-05 | 上海合芯数字科技有限公司 | 一种服务器固件启动优化方法、系统、服务器及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN115599448A (zh) | 2023-01-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2023273424A1 (zh) | 一种基于linux内核ko模块的加载方法及装置 | |
US20210240636A1 (en) | Memory Management Method and Apparatus | |
CN107480150B (zh) | 一种文件加载方法和装置 | |
CN111190854B (zh) | 通信数据处理方法、装置、设备、系统和存储介质 | |
US9977598B2 (en) | Electronic device and a method for managing memory space thereof | |
US9158690B2 (en) | Performing zero-copy sends in a networked file system with cryptographic signing | |
US20240256477A1 (en) | Method and apparatus for processing dma, and computer-readable storage medium | |
CN113742290B (zh) | 一种数据存储方法、装置、存储介质及电子装置 | |
EP4375836A1 (en) | Memory paging method and system, and storage medium | |
WO2016040652A1 (en) | Systems, methods, and computer-readable media for tracking udates and loading data | |
KR20160048173A (ko) | 기억 처리 방법, 장치 및 단말 | |
US20220107752A1 (en) | Data access method and apparatus | |
US20240205292A1 (en) | Data processing method and apparatus, computer device, and computer-readable storage medium | |
CN115268767A (zh) | 数据处理方法以及装置 | |
CN113779452B (zh) | 数据处理方法、装置、设备及存储介质 | |
CN113691466B (zh) | 一种数据的传输方法、智能网卡、计算设备及存储介质 | |
CN105939203B (zh) | 表项同步方法以及装置 | |
CN111913893A (zh) | 保留内存的映射方法和装置、设备和存储介质 | |
US20170118113A1 (en) | System and method for processing data packets by caching instructions | |
CN114826906B (zh) | 流量控制方法、装置、电子设备及存储介质 | |
CN115525462A (zh) | 一种日志存储方法、装置、电子设备及存储介质 | |
CN116192776A (zh) | 可自修复的报文保序方法、装置、终端及存储介质 | |
CN113572747B (zh) | 一种ip地址的处理方法、装置、存储介质和处理器 | |
WO2020227878A1 (zh) | 一种调度存储器中数据的方法、数据调度设备及系统 | |
CN116346382A (zh) | 一种阻断恶意tcp连接的方法、装置及电子设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22831255 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 22831255 Country of ref document: EP Kind code of ref document: A1 |