Memory locking method and device

Abstract

The embodiment of the invention provides a memory locking method and device, and relates to the technical field of computers.The method comprises the steps that an equipment kernel obtains a memory locking request from a first task interface, and the memory locking request comprises the first number of memories needing to be locked; calling a first memory tracking subsystem to obtain a second number of locked memories of a first task group and a first resource upper limit value, namely, a third number of locked memories of a first task interface and a second resource upper limit value; if the first sum value is larger than the first resource upper limit value and / or the second sum value is larger than the second resource upper limit value, memory locking is refused, the first sum value is the sum value of the second number and the first number, and the second sum value is the sum value of the third number and the first number. According to the scheme, the problem that the physical memory of the host is exhausted due to the fact that the actual memory consumption of the equipment reaches multiple resource upper limit values due to fragmented bookkeeping can be solved, and the problem that resource limitation caused by a privileged interface may fail is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a memory locking method and apparatus. Background Technology

[0002] In the Linux kernel implementation, user-space applications can lock physical memory pages to ensure that physical memory pages are not swapped to disk; at the same time, a resource-limited memory locking mechanism (RLIMIT_MEMLOCK) can be used to limit memory locking to prevent a single task interface (such as a process or driver) from occupying too much non-swapable memory.

[0003] However, the RLIMIT_MEMLOCK mechanism is applied to a single task interface, and task interfaces can use various counting methods to count the amount of locked memory. This fragmented accounting means that the same physical memory page may be counted in different counters, none of which exceed the limit of the RLIMIT_MEMLOCK mechanism. This can cause actual memory consumption to reach several times the preset resource limit, and it cannot achieve the requirement of resource isolation by task group, easily leading to the exhaustion of host physical memory. In addition, there are privileged interfaces in the task interface. These privileged interfaces can bypass the standard RLIMIT_MEMLOCK accounting mechanism and directly lock memory, causing the resource limit to fail. Summary of the Invention

[0004] The purpose of this application is to provide a memory locking method and apparatus to solve the problem that fragmented accounting causes the actual memory consumption of the device to reach multiple times the resource limit, resulting in the exhaustion of the host's physical memory, and to address the potential failure of resource limits imposed by privileged interfaces. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of this application provide a memory locking method applied to a device kernel. The device kernel is configured with a group controller corresponding to each task group. Each group controller manages the quantity of locked memory and the resource limit for the corresponding task group. Each task group includes at least one task interface, and each task interface is associated with a memory tracking subsystem. The method includes: obtaining a memory locking request from a first task interface in a first task group, the memory locking request including a first quantity of memory to be locked; invoking the first memory tracking subsystem associated with the first task interface, using the first group controller corresponding to the first task group, obtaining a second quantity of locked memory and a first resource limit for the first task group, and obtaining a third quantity of locked memory and a second resource limit for the first task interface; comparing a first sum with the first resource limit, and comparing a second sum with the second resource limit, the first sum being the sum of the second quantity and the first quantity, and the second sum being the sum of the third quantity and the first quantity; if the first sum is greater than the first resource limit, and / or the second sum is greater than the second resource limit, then memory locking is refused.

[0006] In some embodiments, the memory tracking subsystem manages the flag bit of the corresponding task interface; the method further includes: invoking the first memory tracking subsystem to obtain a first flag bit of the first task interface; if the first flag bit indicates that the first task interface is a non-privileged interface, then executing the step of invoking the first memory tracking subsystem associated with the first task interface, using the first group controller corresponding to the first task group to obtain a second number of locked memory and a first resource limit value of the first task group, and obtaining a third number of locked memory and a second resource limit value corresponding to the first task interface; if the first flag bit indicates that the first task interface is a privileged interface, then invoking the first memory tracking subsystem, using the first group controller to obtain the second number and the first resource limit value; comparing the first sum with the first resource limit value; if the first sum is greater than the first resource limit value, then rejecting memory locking.

[0007] In some embodiments, the method further includes: if the first sum is less than or equal to the first resource limit value and the second sum is less than or equal to the second resource limit value, then locking the first amount of memory; updating the amount of memory locked by the first task interface, and invoking the first group controller to update the amount of memory locked by the first task group.

[0008] In some embodiments, the method further includes: obtaining a memory unlock request from the first task interface, the memory unlock request including a fourth amount of memory to be unlocked; invoking the first memory tracking subsystem to unlock the fourth amount of memory; updating the amount of memory locked by the first task interface, and invoking the first group controller to update the amount of memory locked by the first task group.

[0009] In some embodiments, the first task group includes multiple sub-task groups, each sub-task group includes at least one task interface, and the device kernel configures a sub-group controller corresponding to each sub-task group. Each sub-group controller manages the number of locked memory and the resource limit value of the corresponding sub-task group. The first task interface belongs to the first sub-task group included in the first task group. The method further includes: calling the first memory tracking subsystem, using the first sub-group controller corresponding to the first sub-task group to obtain a fifth number of locked memory and a third resource limit value of the first sub-task group; comparing a third sum with the third resource limit value, wherein the third sum is the sum of the fifth number and the first number; if the third sum is greater than the third resource limit value, then the memory is rejected from being locked; after unlocking the fourth number of memory, calling the first sub-group controller to update the number of locked memory in the first sub-task group.

[0010] In some embodiments, the method further includes: obtaining a trace release request from the first task interface; invoking the first memory tracing subsystem and releasing the first memory tracing subsystem.

[0011] In some embodiments, the group controller configures a system interface and a read / write callback interface; the method further includes: calling the file system interface of the first group controller to display the second quantity and the first resource limit value; when receiving an adjustment operation for the first resource limit value, calling the read / write callback interface of the first group controller to modify the recorded first resource limit value.

[0012] In some embodiments, the number of memory blocks locked by the task group is counted using an atomic counter.

[0013] Secondly, embodiments of this application provide a memory locking device applied to a device kernel. The device kernel is configured with a group controller corresponding to each task group. Each group controller manages the quantity of locked memory and the resource limit for the corresponding task group. Each task group includes at least one task interface, and each task interface is associated with a memory tracking subsystem. The device includes: an acquisition unit, configured to acquire a memory locking request from a first task interface in a first task group, the memory locking request including a first quantity of memory to be locked; a calling unit, configured to call the first memory tracking subsystem associated with the first task interface, using the first group controller corresponding to the first task group to obtain a second quantity of locked memory and a first resource limit for the first task group, and to acquire a third quantity of locked memory and a second resource limit for the first task interface; a comparison unit, configured to compare a first sum with the first resource limit and a second sum with the second resource limit, the first sum being the sum of the second quantity and the first quantity, and the second sum being the sum of the third quantity and the first quantity; and a rejection unit, configured to reject locking memory if the first sum is greater than the first resource limit and / or the second sum is greater than the second resource limit.

[0014] In some embodiments, the memory tracking subsystem manages the flag bit of the corresponding task interface; the calling unit is further configured to call the first memory tracking subsystem to obtain the first flag bit of the first task interface; if the first flag bit indicates that the first task interface is a non-privileged interface, then the first memory tracking subsystem associated with the first task interface is called, and the first group controller corresponding to the first task group is used to obtain the second number of locked memory and the first resource limit value of the first task group, and the third number of locked memory and the second resource limit value corresponding to the first task interface are obtained; if the first flag bit indicates that the first task interface is a privileged interface, then the first memory tracking subsystem is called, and the first group controller is used to obtain the second number and the first resource limit value; the comparison unit is further configured to compare the first sum value with the first resource limit value.

[0015] In some embodiments, the apparatus further includes: a locking unit, configured to lock the first quantity of memory if the first sum is less than or equal to the first resource limit value and the second sum is less than or equal to the second resource limit value; and an updating unit, configured to update the quantity of memory locked by the first task interface and to invoke the first group controller to update the quantity of memory locked by the first task group.

[0016] In some embodiments, the apparatus further includes an update unit; the acquisition unit is further configured to acquire a memory unlock request from the first task interface, the memory unlock request including a fourth quantity of memory to be unlocked; the invocation unit is further configured to invoke the first memory tracking subsystem to unlock the fourth quantity of memory; the update unit is configured to update the quantity of memory locked by the first task interface and invoke the first group controller to update the quantity of memory locked by the first task group.

[0017] In some embodiments, the first task group includes multiple sub-task groups, each sub-task group includes at least one task interface, and the device kernel is configured with a sub-group controller corresponding to each sub-task group. Each sub-group controller manages the number of locked memory and the resource limit value of the corresponding sub-task group. The first task interface belongs to the first sub-task group included in the first task group. The calling unit is further configured to call the first memory tracking subsystem associated with the first task interface, and use the first sub-group controller corresponding to the first sub-task group to obtain the fifth number of locked memory and the third resource limit value of the first sub-task group. The comparison unit is further configured to compare the third sum value with the third resource limit value, wherein the third sum value is the sum of the fifth number and the first number. The rejection unit is further configured to reject locking memory if the third sum value is greater than the third resource limit value. The update unit is further configured to call the first sub-group controller after unlocking the fourth number of memory to update the number of locked memory in the first sub-task group.

[0018] In some embodiments, the acquisition unit is further configured to acquire a trace release request from the first task interface; the invocation unit is further configured to invoke the first memory tracing subsystem and release the first memory tracing subsystem.

[0019] In some embodiments, the group controller configures a system interface and a read / write callback interface; the calling unit is further configured to call the file system interface of the first group controller to display the second quantity and the first resource limit value; when receiving an adjustment operation for the first resource limit value, the unit calls the read / write callback interface of the first group controller to modify the recorded first resource limit value.

[0020] In some embodiments, the number of memory blocks locked by the task group is counted using an atomic counter.

[0021] Thirdly, embodiments of this application provide an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor is used to implement any of the methods provided in the first aspect when executing the programs stored in the memory.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods provided in the first aspect.

[0023] Fifthly, embodiments of this application also provide a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods provided in the first aspect.

[0024] Beneficial effects of the embodiments in this application:

[0025] In the technical solution provided in this application embodiment, the device kernel allocates a unified accounting interface (i.e., a memory tracking subsystem) and a group controller corresponding to the task group to which the task interface belongs to each task interface. The memory tracking subsystem can obtain both the locked memory amount and resource limit value of a single task interface, as well as the locked memory amount and resource limit value of a task group maintained by the group controller. It then compares whether the locked memory amount of the task group exceeds the resource limit value corresponding to the task group, and whether the locked memory amount of the task interface exceeds the resource limit value corresponding to the task interface. If it exceeds the resource limit value corresponding to the task group and / or the resource limit value corresponding to the task interface, memory locking for that task interface is refused. This effectively controls the total locked memory of the task group / task interface to ensure it does not exceed the resource limit value allocated to the task group / task interface. This avoids the problem of fragmented accounting causing the same physical memory page to be counted in different counters, resulting in the actual memory consumption of the device reaching multiple times the preset resource limit value. Furthermore, it effectively controls the amount of resources locked by the task group, achieving effective overall management of the total locked memory of the entire machine.

[0026] Furthermore, by utilizing a unified accounting interface, all task interfaces (including privileged interfaces) can perform operations to compare whether the amount of memory locked by a task group exceeds the resource limit of the corresponding task group, and whether the amount of memory locked by a task interface exceeds the resource limit of the corresponding task interface. This solves the problem of privileged processes bypassing the accounting mechanism and directly locking memory, causing resource limits to fail.

[0027] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0029] Figure 1 This is a schematic diagram of a first flowchart of a memory locking method provided in an embodiment of this application;

[0030] Figure 2 A schematic diagram of the networking environment of the memory tracking subsystem and group controller provided in the embodiments of this application;

[0031] Figure 3 This is a second flowchart illustrating the memory locking method provided in an embodiment of this application;

[0032] Figure 4 A flowchart illustrating a memory unlocking method provided in an embodiment of this application;

[0033] Figure 5 A schematic diagram illustrating the architecture of system functional entities and external entities provided in the embodiments of this application;

[0034] Figure 6 A schematic diagram of a memory locking device provided in an embodiment of this application;

[0035] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0037] In the Linux kernel's memory management system, user-space applications can use system calls such as `mlock()` and `mmap()` to lock or pin physical memory pages, ensuring that these pages are not swapped out to disk. This memory locking mechanism is particularly important for applications requiring low latency guarantees, such as real-time data processing, high-performance computing (HPC), deterministic task execution, and direct memory access (DMA) operations. However, excessive use of memory locking can lead to severe system resource contention, affecting overall stability and even rendering the entire system unusable in some extreme cases.

[0038] Currently, in the Linux kernel implementation, memory locking is limited using a resource-limited memory locking mechanism (RLIMIT_MEMLOCK) to prevent a single process or driver from consuming excessive amounts of non-swapable memory, which could increase overall system memory pressure and affect the normal operation of other critical services. Specifically, in the RLIMIT_MEMLOCK mechanism, the administrator sets a resource limit (rlimit) for each process or driver. When a process locks physical memory via the mlock() system call, the RLIMIT_MEMLOCK mechanism is triggered, checking whether the total amount of memory locked by the process exceeds the corresponding resource limit. If it does, the memory lock request is rejected; otherwise, the memory lock request is allowed, locking the corresponding physical memory pages. Similarly, when a driver locks physical memory, the RLIMIT_MEMLOCK mechanism is triggered, checking whether the total amount of memory locked by the process exceeds the corresponding resource limit. If it does, the memory lock request is rejected; otherwise, the memory lock request is allowed, locking the corresponding physical memory pages.

[0039] However, the RLIMIT_MEMLOCK mechanism has the following problems:

[0040] (1) Fragmented accounting can lead to the same physical memory page being counted in different counters, which can cause the actual memory consumption to reach several times the preset resource limit.

[0041] A process can use process counters to record the number of locked memory pages. Process counters include process locked memory page counters (such as mm->locked_vm) and process pinned memory page counters (such as mm->pinned_vm). A driver can use user counters (such as user->locked_vm) to record the number of locked memory pages. Because multiple counters record the number of locked memory pages, this fragmented accounting method can easily lead to duplicate accounting of locked memory pages. This can cause the same physical memory page to be counted in different counters (such as the three counters mentioned above), which may result in the actual memory consumption reaching three times the preset resource limit.

[0042] (2) Privileged processes bypass the standard accounting mechanism RLIMIT_MEMLOCK and directly lock memory, which may render resource limits ineffective.

[0043] The root process or a process with inter-process communication locking (Capability_Inter-ProcessCommunication_Lock, CAP_IPC_LOCK) capabilities can completely ignore the limitations of the RLIMIT_MEMLOCK mechanism and arbitrarily lock physical memory pages. This creates a clear privilege escaping vulnerability in scenarios with stringent security requirements. While this approach retains flexibility for certain specific use cases (such as legacy database applications relying on this feature), it clearly violates the principle of least privilege in security practices.

[0044] (3) In a multi-tenant environment or a multi-service hosting environment, it is impossible to achieve the requirement of resource isolation by task group, which can easily lead to the exhaustion of host physical memory.

[0045] Containers, virtualization instances, and other task groups can include multiple processes. Even if each process in a task group adheres to its own RLIMIT_MEMLOCK quota (i.e., the default resource limit), when a task group contains a large number of processes, and each process requests locked memory close to the limit, it may still lead to the exhaustion of the host's physical memory, and the total locked memory of the entire machine cannot be effectively managed.

[0046] (4) When the parent process derives a child process through system calls such as fork(), the child process can inherit the physical memory pages locked by the parent process without having to perform the RLIMIT_MEMLOCK mechanism check, which is equivalent to indirectly breaking the constraint of the single process resource limit.

[0047] To address the aforementioned issues, this application provides a memory locking method applied to a device kernel. The device kernel configures a group controller for each task group. Each group controller manages the amount of locked memory and the maximum resource limit for the corresponding task group. Each task group includes at least one task interface, and each task interface is associated with a memory tracking subsystem. For example... Figure 1 As shown, the method includes the following steps:

[0048] Step S101: Obtain a memory lock request from the interface of the first task in the first task group. The memory lock request includes a first amount of memory that needs to be locked.

[0049] Step S102: Call the first memory tracking subsystem associated with the first task interface, use the first group controller corresponding to the first task group to obtain the second number of locked memory in the first task group and the first resource limit value, and obtain the third number of locked memory in the first task interface and the second resource limit value corresponding to the first task interface.

[0050] Step S103: Compare the first sum with the first resource limit value, and compare the second sum with the second resource limit value. The first sum is the sum of the second quantity and the first quantity, and the second sum is the sum of the third quantity and the first quantity.

[0051] Step S104: If the first sum is greater than the first resource limit value, and / or the second sum is greater than the second resource limit value, then the memory locking is rejected.

[0052] In the technical solution provided in this application embodiment, the device kernel allocates a unified accounting interface (i.e., a memory tracking subsystem) and a group controller corresponding to the task group to which the task interface belongs to each task interface. The memory tracking subsystem can obtain both the locked memory amount and resource limit value of a single task interface, as well as the locked memory amount and resource limit value of a task group maintained by the group controller. It then compares whether the locked memory amount of the task group exceeds the resource limit value corresponding to the task group, and whether the locked memory amount of the task interface exceeds the resource limit value corresponding to the task interface. If it exceeds the resource limit value corresponding to the task group and / or the resource limit value corresponding to the task interface, memory locking for that task interface is refused. This effectively controls the total locked memory of the task group / task interface to ensure it does not exceed the resource limit value allocated to the task group / task interface. This avoids the problem of fragmented accounting causing the same physical memory page to be counted in different counters, resulting in the actual memory consumption of the device reaching multiple times the preset resource limit value. Furthermore, it effectively controls the amount of resources locked by the task group, achieving effective overall management of the total locked memory of the entire machine.

[0053] Furthermore, by utilizing a unified accounting interface, all task interfaces (including privileged interfaces) can perform operations to compare whether the amount of memory locked by a task group exceeds the resource limit of the corresponding task group, and whether the amount of memory locked by a task interface exceeds the resource limit of the corresponding task interface. This solves the problem of privileged processes bypassing the accounting mechanism and directly locking memory, causing resource limits to fail.

[0054] Furthermore, even if the storage parent task interface derives a child task interface through system calls such as fork(), in this embodiment, the physical memory pages locked by the parent task interface are counted in the number of locked memory pages in the task group, and are limited by the resource upper limit value corresponding to the task group, thus solving the problem of omission caused by the memory lock of the derived child task interface.

[0055] In this embodiment, the device kernel can be the kernel of a physical machine node or the kernel of a virtual machine node. One or more task groups can be created on a virtual machine node. Each task group includes at least one task interface, which can be a process or a driver. One task interface is associated with a memory tracking subsystem (such as the mem_tracker subsystem).

[0056] The networking environment of the memory tracking subsystem and group controller is as follows: Figure 2 As shown. Figure 2 The example given is a virtual machine node comprising a task group. This task group includes process A and process B. Memory tracing subsystem 1 and memory tracing subsystem 2, and group controller 1 run on the kernel. Process A is associated with memory tracing subsystem 1, and process B is associated with memory tracing subsystem 2. Memory tracing subsystem 1 and memory tracing subsystem 2 can call group controller 1. The memory tracing subsystems and group controller run within the kernel and do not rely on external network communication.

[0057] The memory tracing subsystem maintains the context information for task interface latch operations. This context information can include the relationships between the process-locked page counter, the process-fixed page counter, and the user counter; that is, the relationships between the task structure (task_struct), the memory management structure (mm_struct), and the user structure (user_struct). The context information may also include the group controller pointer and flags on the task interface. The group controller pointer points to the group controller. The flags on the task interface indicate whether the task interface is a non-privileged interface or a privileged interface. A privileged interface can be the root process or a process with CAP_IPC_LOCK capability, etc.

[0058] In one example, the memory tracing subsystem can be defined as follows: Identification: MEM_TRACKER; Type: Kernel accounting subsystem; Purpose: Receive locked memory requests and perform multi-level limit checks; Functions list: Initialize latch operation context information, check RLIMIT_MEMLOCK and memlock_cgroup limits, update mm / user / memlock_cgroup counts (i.e., update process locked memory page counters, process fixed memory page counters, user counters, and counters within the group controller); debit operations and reference releases. The memory tracing subsystem needs to support unified locked memory page counts and support dual limits of RLIMIT_MEMLOCK + memlock_cgroup.

[0059] In this embodiment, the memory tracing subsystem may include a tracing initialization module (such as mem_tracker_int). After the memory tracing subsystem is created, the tracing initialization module initializes the context information of the latch operation.

[0060] Group controllers (such as memlock_cgroup) are used to maintain the amount of memory locked by a task group (memlock.used) and the resource limit value corresponding to the task group (memlock.limit). Group controllers can also be used to maintain the number of events that request to lock resources exceeding the resource limit value (i.e., the over-limit event count). In this embodiment, users can manage group controllers locally or remotely. For example, using / sys / fs / cgroup / as the mount point for the group controller, a memlock_cgroup can be created under / sys / fs / cgroup / using a Cascading Style Sheets (CSS) framework, and the corresponding resource limit value can be configured to achieve collaborative work with existing memory cgroups.

[0061] In one example, a group controller can be defined as: {Identification: MEMLOCK_CGROUP; Type: Control group (cgroup) subsystem; Purpose: To implement pinned memory page count limits, statistics, and monitoring at the cgroup level; Functions list: Maintain memlock.used (current count, i.e., current pinned memory page count), maintain memlock.limit (also known as cgroup limit value), maintain memlock.events (out-of-limit event count); Provide file system interface (sysfs interface), provide read / write callback interface (sysfs read / write callback interface)}. The group controller maintains data entities (such as struct memlock_cgroup) which can be defined as: {Identification: MEMLOCK_CGROUP; Type: Kernel data structure; Purpose: To store pinned page counts, resource limits, out-of-limit event counts, and lifecycle control structures (such as CSS) in the group controller}.

[0062] In some embodiments, the amount of memory locked by the task group (memlock.used) can be implemented using an atomic counter (such as an atomic_t counter). The atomic counter updates the count using a sequence of atomic operations (atomic_t), ensuring accuracy in lock contention scenarios, while switching to a precise global count during quota overrun detection, ensuring correctness in concurrent scenarios. Furthermore, this design balances performance and accuracy requirements, maintaining stable throughput even under extreme loads.

[0063] In step S101 above, the first task group can be any task group on the device. The first task interface can be any task interface included in the first task group. The first task interface can call system calls such as mlock() to input a memory lock request to the device kernel. This memory lock request includes the amount of memory to be locked, i.e., the first quantity. The first quantity can be represented in bytes (B), such as 4KB, 32KB, 64KB, etc. The first quantity can also be represented in the number of physical memory pages, such as 1, 8, 18, etc. The memory lock request can also include the start address, end address, etc. of the memory to be locked.

[0064] In step S102 above, after receiving a memory lock request from the first task interface, the device kernel determines the memory tracking subsystem associated with the first task interface, i.e., the first memory tracking subsystem, and then calls the first memory tracking subsystem. The memory tracking subsystem uniformly encapsulates resource limit checking logic and count updates. The resource limit checking logic includes the limit checking logic of the RLIMIT_MEMLOCK mechanism and the limit checking logic of the group controller (memlock_cgroup).

[0065] After the device kernel calls the first memory tracing subsystem, it further calls the group controller (i.e., the first group controller) corresponding to the first task group. After the first group controller is called, it obtains the second quantity of memory locked by the first task group (i.e., memlock.used) and the first resource limit value of memory locked by the first task group (i.e., memlock.limit) maintained by itself in order to perform a limit check on memlock_cgroup.

[0066] Furthermore, after the device kernel calls the first memory tracing subsystem, it can use the first memory tracing subsystem to obtain the third quantity of memory locked by the first task interface (i.e., the current count value of RLIMIT_MEMLOCK) and the second resource limit value corresponding to the first task interface (i.e., the limit value of RLIMIT_MEMLOCK). In this embodiment, the memory tracing subsystem maintains context information of task interface latching operations, such as the relationship between task_struct, mm_struct, and user_struct. Regardless of whether a task interface uses the mm->locked_vm or mm->pinned_vm field in mm_struct for counting, or the user->locked_vm field in user_struct for counting, the memory tracing subsystem can obtain the quantity of memory locked by the task interface (such as the third quantity) to facilitate the limit check of the RLIMIT_MEMLOCK mechanism.

[0067] In step S103 above, the device kernel calls the first memory tracking subsystem. The first memory tracking subsystem calculates the sum of the second quantity and the first quantity to obtain the first sum, calculates the sum of the third quantity and the first quantity to obtain the second sum, and then compares the first sum with the first resource limit value, and compares the second sum with the second resource limit value.

[0068] If any of the following conditions are met, it indicates that the restriction check has failed, and step S104 is executed. The device kernel calls the first memory tracking subsystem, refuses to lock the memory, and may return an error to the first task interface.

[0069] Case 1: The first sum is greater than the first resource limit.

[0070] Case 2: The second sum is greater than the second resource limit.

[0071] Case 3: The first sum is greater than the first resource limit, and the second sum is greater than the second resource limit.

[0072] When conditions 1 to 3 above are not met, i.e., the first sum is less than or equal to the first resource limit value and the second sum is less than or equal to the second resource limit value, it means that the restriction check is passed, and the device kernel can call the first memory tracking subsystem to lock the first amount of memory; update the amount of memory locked by the first task interface, and call the first group controller to update the amount of memory locked by the first task group.

[0073] In this embodiment, the memory tracking subsystem may include a memory locking module (such as mem_tracker_lock). The group controller may include a try-hold module (such as memlock_try_hold). The memory locking module executes steps S102 to S104 above to complete the RLIMIT_MEMLOCK mechanism and the limit check of memlock_cgroup. When any of conditions 1 to 3 are met, mem_tracker_lock may refuse to lock the memory and return an error to the first task interface; when conditions 1 to 3 are not met, mem_tracker_lock may lock a first amount of physical memory and update the number of memory locked by the first task interface in the RLIMIT_MEMLOCK mechanism (i.e., increase the number of memory locked by the first task interface by a first amount), and call memlock_try_hold, which updates the number of memory locked by the first task group (i.e., increase the number of memory locked by the first task group by a first amount).

[0074] In this embodiment, the execution order of the restriction checks of the RLIMIT_MEMLOCK mechanism and the memlock_cgroup mechanism is not limited. That is, the restriction checks of the RLIMIT_MEMLOCK mechanism and the memlock_cgroup mechanism can be executed in parallel; the restriction checks of the RLIMIT_MEMLOCK mechanism can be executed first, followed by the restriction checks of the memlock_cgroup mechanism. In this case, if the restriction check of the RLIMIT_MEMLOCK mechanism fails, i.e., the second sum value is greater than the second resource limit value, the memory lock can be directly rejected without executing the restriction check of the memlock_cgroup mechanism; or the restriction checks of the RLIMIT_MEMLOCK mechanism can be executed first, followed by the restriction checks of the memlock_cgroup mechanism. In this case, if the restriction check of the memlock_cgroup mechanism fails, i.e., the first sum value is greater than the first resource limit value, the memory lock can be directly rejected without executing the restriction check of the RLIMIT_MEMLOCK mechanism.

[0075] In some embodiments, each group controller can also manage the over-limit event count (i.e., memlock.events) for the corresponding task group. In this case, after the device kernel calls the first memory tracking subsystem to refuse to lock memory, it uses the first memory tracking subsystem to call the first group controller, thereby incrementing the over-limit event count maintained by the first group controller itself by 1, that is, incrementing the over-limit event count of the first task group by 1. By maintaining the over-limit event count, users can easily understand resource locking information and maintain memory resources in a timely and effective manner.

[0076] In some embodiments, the memory tracking subsystem may also manage the flag bits of the corresponding task interface. In this case, such as... Figure 3 As shown, a memory locking method is also provided, which may include steps S301 to S306; wherein, steps S301, S303 to S304, and S307 are the same as steps S101 to S104, and will not be described again here.

[0077] Step S302: Call the first memory tracking subsystem associated with the first task interface to obtain the first flag bit of the first task interface; if the first flag bit indicates that the first task interface is a non-privileged interface, then execute step S303; if the first flag bit indicates that the first task interface is a privileged interface, then execute step S305.

[0078] Step S305: Invoke the first memory tracking subsystem and use the first group of controllers to obtain the second quantity and the first resource limit value;

[0079] Step S306: Compare the first sum with the first resource limit value.

[0080] Step S307: If the first sum is greater than the first resource limit value, and / or the second sum is greater than the second resource limit value, then the memory locking is rejected.

[0081] In step S302 above, after receiving a memory lock request from the first task interface, the device kernel determines the first memory tracking subsystem associated with the first task interface and then calls the first memory tracking subsystem. The first memory tracking subsystem obtains the flag bit of the first task interface, i.e., the first flag bit, from the maintained context information of the task interface latching operation. If the first flag bit indicates that the first task interface is a non-privileged interface, the device kernel executes steps S303, S304, and S307, i.e., performs the restriction check of the RLIMIT_MEMLOCK mechanism and the restriction check of memlock_cgroup. If the first flag bit indicates that the first task interface is a privileged interface, steps S305, S306, and S307 are executed, i.e., the restriction check of the RLIMIT_MEMLOCK mechanism is bypassed, and the restriction check of memlock_cgroup is performed. When the first sum value is greater than the first resource limit value, memory locking is refused.

[0082] In the technical solution provided in this application, the privileged interface retains its exemption capability from the RLIMIT_MEMLOCK mechanism through a flag bit in the task interface, but implements hard restrictions at the memlock_cgroup level. In this way, the privileged interface can still exceed process-level quotas, but will not exceed the total limit of its task group (such as the first resource limit). This ensures backward compatibility while achieving more granular resource management, thus accommodating historical compatibility while plugging existing resource exhaustion vulnerabilities, thereby strengthening the security model.

[0083] In some embodiments, such as Figure 4 As shown, a memory unlocking method is also provided, applied to the device kernel. The device kernel is configured with a group controller corresponding to each task group. Each group controller manages the amount of locked memory and the resource limit for the corresponding task group. Each task group includes at least one task interface, and each task interface is associated with a memory tracking subsystem. The method may include the following steps:

[0084] Step S401: Obtain a memory unlock request from the first task interface. The memory unlock request includes a fourth quantity of memory that needs to be unlocked.

[0085] In this embodiment, the first task interface can call system calls such as munlock() to input a memory unlock request to the device kernel. This memory unlock request includes the amount of memory to be unlocked, i.e., the fourth quantity. The fourth quantity can be represented in bytes (B), such as 4KB, 32KB, 64KB, etc. The fourth quantity can also be represented in the number of physical memory pages, such as 1, 8, 18, etc. The memory unlock request may also include the start address and end address of the memory to be unlocked.

[0086] Step S402: Invoke the first memory tracking subsystem to unlock the fourth amount of memory;

[0087] After receiving a memory lock request from the first task interface, the device kernel determines the first memory tracking subsystem associated with the first task interface, and then calls the first memory tracking subsystem to unlock the fourth number of physical memory.

[0088] Step S403: Update the amount of memory locked by the first task interface, and call the first group controller to update the amount of memory locked by the first task group.

[0089] In this embodiment, the memory tracking subsystem may include a memory unlocking module (such as mem_tracker_unlock). The group controller may include a release module (such as memlock_unhold). mem_tracker_unlock executes the above steps S402-S403 to complete memory unlocking. Afterwards, mem_tracker_unlock can update the number of locked memory items in the first task interface in the RLIMIT_MEMLOCK mechanism (i.e., reduce the current number of locked memory items in the first task interface by a fourth amount), and call memlock_unhold, which updates the number of locked memory items in the first task group (i.e., reduce the current number of locked memory items in the first task group by a fourth amount).

[0090] In this embodiment, the update of the locked memory count is implemented by the mem_tracker() series of functions included in the memory tracking subsystem, such as mem_tracker_lock and mem_tracker_unlock. This not only handles the logic of incrementing the locked memory count but also maintains the reverse mapping relationship, ensuring the correct rollback of the count when memory pages are released. This ensures the correctness of memory lock management.

[0091] In some embodiments, the device kernel may also obtain a trace release request from the first task interface; invoke the first memory tracing subsystem, and release the first memory tracing subsystem.

[0092] In this embodiment, the memory tracking subsystem may include an interface release module (such as mem_tracker_free). The first task interface may input an interface release request to the device kernel to close the first task interface. The device kernel calls mem_tracker_free in the first memory tracking subsystem to release the first memory tracking subsystem, thereby reducing kernel load.

[0093] In some embodiments, each task group may include multiple sub-task groups, each sub-task group includes at least one task interface, and the device kernel configures a sub-group controller corresponding to each sub-task group. Each sub-group controller manages the amount of locked memory and the resource limit for the corresponding sub-task group. The sub-group controller is actually a group controller; that is, the implementation of the sub-group controller is the same as that of the group controller, the only difference being that the sub-group controller maintains the amount of locked memory (memlock.used), the resource limit (memlock.limit) for the sub-task group, and the number of events where the requested locked resources exceed the resource limit for the sub-task group.

[0094] Taking the first task interface as an example, which belongs to the first sub-task group within the first task group. After receiving a memory lock request from the first task interface, the device kernel can also call the first memory tracking subsystem, using the first subgroup controller corresponding to the first sub-task group, to obtain the fifth quantity and the third resource limit value of the locked memory in the first sub-task group; compare the third sum with the third resource limit value, where the third sum is the sum of the fifth quantity and the first quantity; if the third sum is greater than the third resource limit value, then the memory lock is rejected. If the first sum is less than or equal to the first resource limit value, the second sum is less than or equal to the second resource limit value, and the third sum is less than or equal to the third resource limit value, then the first quantity of memory is locked, thereby updating the quantity of locked memory in the first task interface, and calling the first group controller to update the quantity of locked memory in the first task group, and calling the first subgroup controller to update the quantity of locked memory in the first sub-task group (that is, increasing the current quantity of locked memory in the first sub-task group by the first quantity).

[0095] After receiving a memory unlock request from the first task interface and unlocking the fourth amount of memory, the device kernel can also call the first subgroup controller to update the amount of memory locked in the first subtask group (that is, reduce the current amount of memory locked in the first subtask group by the fourth amount).

[0096] In this embodiment, the device kernel can configure multi-level group controllers, such as the aforementioned group controllers and sub-group controllers, according to actual control requirements, to achieve more granular monitoring capabilities. Furthermore, in this embodiment, the multi-level group controllers can all be created under / sys / fs / cgroup / to enable collaborative operation with existing memory cgroups.

[0097] In some embodiments, the group controller can configure a configuration system interface (such as the sysfs interface) and a read / write callback interface (such as the sysfs read / write callback interface). In this case, the device kernel calls the file system interface of the first group controller to display the second quantity and the first resource limit value; when it receives an adjustment operation for the first resource limit value, it calls the read / write callback interface of the first group controller to modify the recorded first resource limit value.

[0098] In this embodiment, the user can call the file system interface of the first group controller through the device kernel to display the amount of locked memory and resource limits of each task group maintained by the first group controller. Based on the displayed amount of locked memory and resource limits of each task group, the user can adjust the resource limits of each task group, such as adjusting the first resource limit of the first task group. When the device kernel receives the adjustment operation, it calls the read / write callback interface of the first group controller to modify the first resource limit maintained by the first group controller.

[0099] The following is combined with Figure 5 The architecture of the system functional entities and external entities shown illustrates the memory locking method provided in the embodiments of this application.

[0100] Virtual machine nodes and other software systems have Linux kernel features that impose locking (such as pinned / locked) memory limits, such as the RLIMIT_MEMLOCK mechanism. Virtual machine nodes create a memory tracking (mem_tracker) module (i.e., a memory tracking subsystem) for each task interface. The mem_tracker module can include sub-modules such as mem_tracker_init(), mem_tracker_lock(), mem_tracker_unlock(), and mem_tracker_free(). Using the CSS framework, under the Linux cgroup system (i.e., / sys / fs / cgroup / ), a memlock_cgroup controller (i.e., a group controller) is created for each task group, and corresponding resource limits are configured. The memlock_cgroup controller provides a sysfs interface.

[0101] The mem_tracker_init() function in the mem_tracker module initializes the context information for latch operations.

[0102] The Linux kernel's interface adaptation layer receives memory lock requests from the mlock system call and kernel drivers such as VirtualFunction Input / Out, Remote Direct Memory Access (RDMA), and Virtual Host (VHOST); and calls the corresponding mem_tracker module.

[0103] The `mem_tracker` module acts as the accounting and limiting layer. If the task interface flag maintained by the `mem_tracker` module indicates a non-privileged interface, the `mem_tracker_lock()` submodule within `mem_tracker` obtains the `RLIMIT_MEMLOCK` limit value and current count value for the corresponding task interface and performs an `RLIMIT_MEMLOCK` limit check. If the `RLIMIT_MEMLOCK` limit check passes, the `mem_tracker_lock()` submodule calls the corresponding `memlock_cgroup` controller to obtain the cgroup limit value and current count value for the task group and performs a `memlock_cgroup` limit check. If the `memlock_cgroup` limit check passes, `mem_tracker_lock()` locks the required number of physical memory pages according to the memory locking request and calls the `memlock_cgroup` controller to update the current count value maintained by the `memlock_cgroup` controller. If either the `RLIMIT_MEMLOCK` limit check or the `memlock_cgroup` limit check fails, locking physical memory pages is refused, and an error is returned.

[0104] If the task interface flag maintained by the `mem_tracker` module indicates a privileged interface, the `mem_tracker_lock()` submodule within `mem_tracker` calls the corresponding `memlock_cgroup` controller to obtain the cgroup limit value and current count value of the task group, and performs a `memlock_cgroup` limit check. If the `memlock_cgroup` limit check passes, `mem_tracker_lock()` locks the required number of physical memory pages according to the memory locking request, and calls the `memlock_cgroup` controller to update the current count value maintained by the `memlock_cgroup` controller. If the `memlock_cgroup` limit check fails, locking physical memory pages is refused, and an error is returned.

[0105] The memlock_cgroup controller serves as the control and data presentation layer. Users can access the current count values ​​and cgroup limit values ​​maintained by the memlock_cgroup controller, as well as modify cgroup limit values ​​and write them back to the memlock_cgroup controller, through the sysfs interface provided by the memlock_cgroup controller, via shell, application programming interface (API) console, and other operation and maintenance / management platforms.

[0106] In the Linux kernel's memory management system, a long-standing issue has been the potential for system stability problems due to an imperfect memory locking mechanism. This application addresses this problem by reconstructing the memory locking management system. This system comprises a standardized accounting interface (i.e., the mem_tracker module), cgroup-level memory locking restrictions, and a security model-enhanced execution framework, fundamentally solving this issue and bringing about significant technical improvements in several aspects. Compared to the traditional single-process restriction mechanism that relies solely on RLIMIT_MEMLOCK, the new solution achieves a qualitative improvement in system stability, resource management accuracy, and ease of operation and maintenance, as detailed below:

[0107] (1) Improved system stability. This application embodiment adds a memlock_cgroup controller, which employs a unique management strategy for locked memory, including a hierarchical quota allocation algorithm, counter optimization (i.e., using atomic counters), and interaction rules with RLIMIT_MEMLIMIT. By introducing cgroup-level memory locking restrictions, the risk of system-level memory overflow (OOM) caused by excessive occupation of unrecoverable memory by a single task group is effectively curbed. Actual test data shows that in a high-density container (one task group) environment, the technical solution provided in this application embodiment can reduce the system crash rate caused by memory locking by approximately 78%. This is because the technical solution provided in this application embodiment adopts a dual verification mechanism, meaning that each memory locking operation must comply with the RLIMIT_MEMLOCK limit of the task interface (such as the process) itself, and cannot exceed the total quota of its respective task group (cgroup). This three-dimensional protection completely plugs the loophole in the original solution of allocating locking through forking multiple processes.

[0108] In this embodiment, inspection logic can be implanted in multiple critical paths, such as page processing functions (e.g., handle_mm_fault()) and memory locking functions (e.g., do_mlock()), ensuring security without causing performance bottlenecks. These implementation details demonstrate extremely high practical value in actual deployments.

[0109] (2) Improved resource utilization efficiency. The unified accounting interface (i.e., the memory tracking subsystem) abstracts the common requirements of various memory locking operations and provides standard billing primitives for various kernel subsystems. Specifically, the unified accounting interface encapsulates the differences between various counting methods such as mm->locked_vm, mm->pinned_vm, and user->locked_vm, and ensures that each memory locking operation is accurately reflected in the global statistics through the mem_tracker() series of functions.

[0110] The introduction of a unified accounting interface not only eliminates the need for driver developers to implement their own counting logic, but more importantly, it eradicates the systemic defect of duplicate billing, eliminating the "multiple deductions" phenomenon caused by independent counting by each process and driver in the past. In kernel testing, under the same workload, the actual memory usage of the technical solution provided in this application embodiment is reduced by an average of 42% compared to the original solution. This is because it corrects the problem of duplicate counting of locked memory pages by drivers such as Direct Memory Access Buffer (DMA-BUF) and RDMA. At the same time, the fine-grained monitoring capabilities provided by the memlock cgroup controller allow users to accurately grasp the locked memory consumption patterns for each type of task, providing a reliable basis for memory capacity planning.

[0111] (3) Enhanced security model. The task interface flag bit in the technical solution provided in this application retains the exemption capability of CAP_IPC_LOCK privilege for process-level restrictions, and implements absolute upper limit control at the cgroup level. This means that even privileged interfaces cannot exceed the predetermined total system quota, which is particularly crucial in defending against malicious attacks. Experimental tests show that the technical solution provided in this application can 100% block attack vectors that attempt to exhaust memory through privileged interfaces, while the success rate of these attacks on the original solution is as high as 92%.

[0112] (4) Improved ease of operation and maintenance. By extending the sysfs interface, administrators can now directly view the real-time locked memory usage of each container in the / sys / fs / cgroup / memlock_cgroup directory and dynamically adjust quota limits (i.e., resource limits). Furthermore, the technical solution provided in this application can be used with a perf probe. When used with a perf probe, users can trace the complete call chain of memory lock events, greatly simplifying the performance bottleneck analysis process. These improvements can reduce troubleshooting time in production environments by nearly 60%.

[0113] (5) Good scalability. From an architectural perspective, the unified accounting interface of the technical solution provided in this application lays the foundation for standardized driver development. Any newly added kernel modules that need to lock memory can directly reuse the architecture provided by the technical solution in this application, without having to implement their own private counting logic. This consistency not only reduces development costs and ecological resistance when the solution is implemented, but also paves the way for possible advanced features such as hot migration of memory in the future.

[0114] In memory-sensitive scenarios such as large-scale cloud computing platforms, the technical solutions provided in this application will bring more significant benefits. Especially in scenarios with special loads such as running in-memory databases and real-time computing, applying the technical solutions provided in this application can ensure that critical applications obtain sufficient locked memory while preventing individual abnormal instances from dragging down the entire node, truly achieving a win-win situation of resource isolation and efficient utilization. These improvements will ultimately translate into a comprehensive improvement in service quality and reliability perceived by end users.

[0115] Corresponding to the memory locking method described above, this application also provides a memory locking device, such as... Figure 6 As shown, the device is applied to the device kernel, in which a group controller is configured for each task group. Each group controller manages the amount of locked memory and the upper limit of resources for the corresponding task group. Each task group includes at least one task interface, and each task interface is associated with a memory tracking subsystem. The device includes:

[0116] The acquisition unit 601 is used to acquire a memory lock request from the interface of the first task in the first task group. The memory lock request includes a first amount of memory that needs to be locked.

[0117] Calling unit 602 is used to call the first memory tracking subsystem associated with the first task interface, and use the first group controller corresponding to the first task group to obtain the second number of locked memory in the first task group and the first resource limit value, and obtain the third number of locked memory in the first task interface and the second resource limit value corresponding to the first task interface.

[0118] The comparison unit 603 is used to compare a first sum with a first resource limit value and to compare a second sum with a second resource limit value. The first sum is the sum of a second quantity and a first quantity, and the second sum is the sum of a third quantity and a first quantity.

[0119] Rejection unit 604 is used to reject locking memory if the first sum is greater than the first resource limit value and / or the second sum is greater than the second resource limit value.

[0120] In some embodiments, the memory tracking subsystem manages the flag bit of the corresponding task interface;

[0121] The calling unit 602 is also used to call the first memory tracking subsystem to obtain the first flag bit of the first task interface; if the first flag bit indicates that the first task interface is a non-privileged interface, then the first memory tracking subsystem associated with the first task interface is called, and the first group controller corresponding to the first task group is used to obtain the second quantity of memory locked by the first task group and the first resource limit value, and the third quantity of memory locked by the first task interface and the second resource limit value corresponding to the first task interface are obtained; if the first flag bit indicates that the first task interface is a privileged interface, then the first memory tracking subsystem is called, and the first group controller is used to obtain the second quantity and the first resource limit value.

[0122] Comparison unit 603 is also used to compare the first sum with the first resource limit value.

[0123] In some embodiments, the memory locking device may further include:

[0124] A locking unit is used to lock a first amount of memory if the first sum is less than or equal to the first resource limit value and the second sum is less than or equal to the second resource limit value.

[0125] The update unit is used to update the amount of memory locked by the first task interface and call the first group controller to update the amount of memory locked by the first task group.

[0126] In some embodiments, the memory locking device described above may further include an update unit;

[0127] The acquisition unit 601 is also used to acquire a memory unlock request from the first task interface, the memory unlock request including a fourth quantity of memory to be unlocked;

[0128] Calling unit 602 is also used to call the first memory tracking subsystem to unlock the fourth amount of memory;

[0129] The update unit is used to update the amount of memory locked by the first task interface and to call the first group controller to update the amount of memory locked by the first task group.

[0130] In some embodiments, the first task group includes multiple sub-task groups, each sub-task group includes at least one task interface, and the device kernel configures a subgroup controller corresponding to each sub-task group. Each group controller manages the amount of locked memory and the upper limit of resources of the corresponding sub-task group; the first task interface belongs to the first sub-task group included in the first task group.

[0131] The calling unit 602 is also used to call the first memory tracking subsystem associated with the first task interface, and use the first subgroup controller corresponding to the first subtask group to obtain the fifth quantity and the third resource limit value of the locked memory of the first subtask group;

[0132] Comparison unit 603 is also used to compare the third sum with the third resource limit value, wherein the third sum is the sum of the fifth quantity and the first quantity;

[0133] Rejection unit 604 is also used to reject locking memory if the third sum value is greater than the third resource limit value;

[0134] The update unit is also used to call the first subgroup controller after unlocking the fourth amount of memory to update the amount of memory locked in the first subtask group.

[0135] In some embodiments, the acquisition unit 601 is further configured to acquire a tracking release request from the first task interface;

[0136] Calling unit 602 is also used to call the first memory tracing subsystem and release the first memory tracing subsystem.

[0137] In some embodiments, the group controller configures the system interface and read / write callback interface;

[0138] The calling unit 602 is also used to call the file system interface of the first group controller to display the second quantity and the first resource limit value; when receiving an adjustment operation for the first resource limit value, it calls the read-write callback interface of the first group controller to modify the recorded first resource limit value.

[0139] In some embodiments, the amount of memory locked by the task group is counted using an atomic counter.

[0140] In the technical solution provided in this application embodiment, the device kernel allocates a unified accounting interface (i.e., a memory tracking subsystem) and a group controller corresponding to the task group to which the task interface belongs to each task interface. The memory tracking subsystem can obtain both the locked memory amount and resource limit value of a single task interface, as well as the locked memory amount and resource limit value of a task group maintained by the group controller. It then compares whether the locked memory amount of the task group exceeds the resource limit value corresponding to the task group, and whether the locked memory amount of the task interface exceeds the resource limit value corresponding to the task interface. If it exceeds the resource limit value corresponding to the task group and / or the resource limit value corresponding to the task interface, memory locking for that task interface is refused. This effectively controls the total locked memory of the task group / task interface to ensure it does not exceed the resource limit value allocated to the task group / task interface. This avoids the problem of fragmented accounting causing the same physical memory page to be counted in different counters, resulting in the actual memory consumption of the device reaching multiple times the preset resource limit value. Furthermore, it effectively controls the amount of resources locked by the task group, achieving effective overall management of the total locked memory of the entire machine.

[0141] Furthermore, by utilizing a unified accounting interface, all task interfaces (including privileged interfaces) can perform operations to compare whether the amount of memory locked by a task group exceeds the resource limit of the corresponding task group, and whether the amount of memory locked by a task interface exceeds the resource limit of the corresponding task interface. This solves the problem of privileged processes bypassing the accounting mechanism and directly locking memory, causing resource limits to fail.

[0142] This application also provides an electronic device, such as... Figure 7 As shown, it includes a processor 701, a communication interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704.

[0143] Memory 703 is used to store computer programs;

[0144] The processor 701, when executing a program stored in the memory 703, implements any of the memory locking methods described above.

[0145] The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0146] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0147] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0148] The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0149] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements any of the memory locking methods described above.

[0150] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the memory locking methods described above.

[0151] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0152] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0153] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for devices, electronic devices, storage media, and program products are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0154] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A memory locking method, characterized in that, Applied to a device kernel, the device kernel configures a group controller corresponding to each task group. Each group controller manages the amount of locked memory and the upper limit of resources for the corresponding task group. Each task group includes at least one task interface, and each task interface is associated with a memory tracking subsystem. The method includes: Obtain a memory lock request from the interface of the first task in the first task group, wherein the memory lock request includes a first amount of memory that needs to be locked; The system calls the first memory tracking subsystem associated with the first task interface, uses the first group controller corresponding to the first task group to obtain the second number of locked memory and the first resource limit value of the first task group, and obtains the third number of locked memory and the second resource limit value corresponding to the first task interface. Compare the first sum with the first resource limit value, and compare the second sum with the second resource limit value. The first sum is the sum of the second quantity and the first quantity, and the second sum is the sum of the third quantity and the first quantity. If the first sum is greater than the first resource limit, and / or the second sum is greater than the second resource limit, then memory locking is refused.

2. The method according to claim 1, characterized in that, The memory tracking subsystem manages the flag bit of the corresponding task interface, and the method further includes: Invoke the first memory tracing subsystem to obtain the first flag bit of the first task interface; If the first flag indicates that the first task interface is a non-privileged interface, then the first memory tracking subsystem associated with the first task interface is called, and the second number of locked memory and the first resource limit value of the first task group are obtained by using the first group controller corresponding to the first task group, and the third number of locked memory and the second resource limit value of the first task interface are obtained. If the first flag indicates that the first task interface is a privileged interface, then the first memory tracking subsystem is invoked, and the first group of controllers is used to obtain the second quantity and the first resource limit value; the first sum value is compared with the first resource limit value; if the first sum value is greater than the first resource limit value, then locking the memory is refused.

3. The method according to claim 1, characterized in that, The method further includes: If the first sum is less than or equal to the first resource limit value, and the second sum is less than or equal to the second resource limit value, then the first amount of memory is locked; Update the amount of memory locked by the first task interface, and call the first group controller to update the amount of memory locked by the first task group.

4. The method according to claim 1, characterized in that, The method further includes: Obtain a memory unlock request from the first task interface, the memory unlock request including a fourth quantity of memory to be unlocked; Invoke the first memory tracking subsystem to unlock the fourth amount of memory; Update the amount of memory locked by the first task interface, and call the first group controller to update the amount of memory locked by the first task group.

5. The method according to claim 4, characterized in that, The first task group includes multiple sub-task groups, each sub-task group includes at least one task interface, and the device kernel is configured with a sub-group controller corresponding to each sub-task group. Each sub-group controller manages the amount of locked memory and the upper limit of resources for the corresponding sub-task group. The first task interface belongs to the first sub-task group included in the first task group; The method further includes: The first memory tracking subsystem is invoked, and the first subgroup controller corresponding to the first subtask group is used to obtain the fifth number of locked memory and the third resource limit value of the first subtask group; Compare the third sum with the third resource limit value, where the third sum is the sum of the fifth quantity and the first quantity; If the third sum value is greater than the third resource limit value, then memory locking is refused; After unlocking the fourth amount of memory, the first subgroup controller is invoked to update the amount of memory locked in the first subtask group.

6. The method according to claim 1, characterized in that, The method further includes: Obtain the trace release request from the first task interface; Invoke the first memory tracing subsystem and release the first memory tracing subsystem.

7. The method according to any one of claims 1-6, characterized in that, The group controller configuration file includes system interfaces and read / write callback interfaces; the method further includes: Call the file system interface of the first group of controllers to display the second quantity and the first resource limit value; When an adjustment operation is received for the first resource limit value, the read / write callback interface of the first group controller is invoked to modify the recorded first resource limit value.

8. The method according to any one of claims 1-6, characterized in that, The number of memory locations locked by the task group is counted using an atomic counter.

9. A memory locking device, characterized in that, Applied to a device kernel, the device kernel configures a group controller corresponding to each task group. Each group controller manages the amount of locked memory and the upper limit of resources for the corresponding task group. Each task group includes at least one task interface, and each task interface is associated with a memory tracking subsystem. The device includes: The acquisition unit is used to acquire a memory lock request from the interface of the first task in the first task group, wherein the memory lock request includes a first amount of memory that needs to be locked; The calling unit is used to call the first memory tracking subsystem associated with the first task interface, and use the first group controller corresponding to the first task group to obtain the second number of locked memory and the first resource limit value of the first task group, and obtain the third number of locked memory and the second resource limit value corresponding to the first task interface. A comparison unit is used to compare a first sum with the first resource limit value and to compare a second sum with the second resource limit value, wherein the first sum is the sum of the second quantity and the first quantity, and the second sum is the sum of the third quantity and the first quantity; The rejection unit is configured to refuse to lock memory if the first sum is greater than the first resource limit value and / or the second sum is greater than the second resource limit value.

10. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-8.

Images