A resource processing method, apparatus, medium, device and product

Abstract

The application discloses a resource processing method and device, medium, equipment and product, and relates to the technical field of computers. First, an abnormal service process that is executed in an accelerator fusion system is identified, and then the remaining threads that are in a hibernation block state in the abnormal service process are controlled to run on a kernel side, so that the threads exit the hibernation block state. Whether a device context is in a lock state due to the remaining threads holding a read lock is identified within a target execution time length. Only when the device context is in an unlock state, a device context destruction process is executed, and corresponding kernel resources are recycled. Thus, a race condition caused by directly destroying the device context when the device context is still occupied by the read lock is avoided, the risk of kernel crash caused by using the released resources is reduced, and the safety of the kernel side resource recycling process in the accelerator fusion system is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a resource processing method, apparatus, medium, device and product. Background Technology

[0002] In an accelerator fusion system, user-space business processes can create multiple device contexts and rely on these contexts to complete business operations such as computation tasks, memory mapping, and message synchronization. When a business process terminates abnormally, such as being killed by a signal, experiencing a segmentation fault, or being terminated by an OutOfMemoryError (OOM), some user threads may have finished their user-space execution path, but remain stuck in kernel space and blocked on the message synchronization ioctl wait queue. These blocked threads will continue to hold the read lock on the device context, causing a race condition between the device context destruction operation and the input-output control (ioctl) access path.

[0003] Currently, the accelerator driver lacks a coordinated handling mechanism for the aforementioned blocked threads and lock states during resource reclamation after abnormal process exit. Directly executing device context destruction can easily lead to Use After Free (UAF) issues, causing kernel crashes. If the reclamation process is skipped directly after lock acquisition fails, kernel resources such as page tables, address space IDs, and buffer object mappings will not be released, resulting in kernel resource leaks. It is impossible to simultaneously ensure kernel operational stability and complete kernel resource reclamation. Summary of the Invention

[0004] In view of this, this application provides a resource processing method, apparatus, medium, equipment and product, the main purpose of which is to solve the technical problem that race condition kernel crashes and kernel resource leaks are prone to occur when the service process of an accelerator fusion system is abnormally terminated.

[0005] Firstly, this application provides a resource processing method, including: Obtain the abnormal business processes that have been suspended in the accelerator fusion system; Set the device context corresponding to the remaining thread in the abnormal business process to a pending destruction mark, and perform a wake-up operation on the remaining thread to release the remaining thread from its dormant and blocked state, so that the remaining thread can run in kernel mode. The remaining thread is the thread that is dormant and blocked when the abnormal business process is terminated. Within the target execution time, identify whether the device context corresponding to the remaining thread is in a locked state. The device context is the context that the remaining thread needs to use during execution. If the remaining thread holds a read lock on the corresponding device context, it is determined that the device context is in a locked state.

[0006] In response to the device context corresponding to the remaining thread being in an unlocked state, the device context is destroyed, and the kernel resources associated with the destroyed device context are reclaimed.

[0007] Secondly, this application provides a resource processing apparatus, comprising: The acquisition module is configured to acquire abnormal business processes that have been terminated in the accelerator fusion system. The control module is configured to set the device context corresponding to the remaining threads in the abnormal business process to a state to be destroyed, and to perform a wake-up operation on the remaining threads to release the sleeping and blocked state of the remaining threads, so that the remaining threads can run in kernel mode. The remaining threads are the threads that are sleeping and blocked when the abnormal business process is terminated. The identification module is configured to identify whether the device context corresponding to the remaining thread is locked within the target execution time. The device context is the context that the remaining thread needs to use during execution. If the remaining thread holds a read lock on the corresponding device context, it is determined that the device context is locked.

[0008] The processing module is configured to destroy the device context and reclaim the kernel resources associated with the destroyed device context in response to the device context corresponding to the remaining thread being in an unlocked state.

[0009] Thirdly, this application provides a computer storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the resource processing method of the first aspect described above.

[0010] Fourthly, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the resource processing method described in the first aspect.

[0011] Fifthly, this application provides a computer program product having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect above.

[0012] By employing the above technical solutions, this application provides a resource processing method, apparatus, medium, device, and product. Compared with existing technologies, this application first identifies abnormal business processes that have been suspended in the accelerator fusion system, then controls the remaining threads that are dormant and blocked in the abnormal business processes to run on the kernel side, causing these threads to exit dormancy and blocking. Within the target execution duration, it identifies whether the device context is locked due to the remaining threads holding a read lock. Only when the device context is unlocked is the device context destruction process performed and the corresponding kernel resources reclaimed. This avoids race conditions caused by directly destroying the device context while it is still held by a read lock, reduces the risk of kernel crashes caused by using it after release, and improves the security of the kernel-side resource reclamation process in the accelerator fusion system. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0014] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 A flowchart illustrating a resource processing method provided in an embodiment of this application is shown; Figure 2 This illustration shows a resource recycling process of a heterogeneous AI accelerator fusion system according to an embodiment of this application; Figure 3 This paper shows a schematic diagram of the structure of a resource processing apparatus provided in an embodiment of the present application; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0016] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0017] This application's embodiments are applicable to kernel resource reclamation scenarios in accelerator fusion systems equipped with heterogeneous AI accelerators (cards), particularly suitable for device context management scenarios after abnormal process exits in AI inference and AI training services with multi-card hybrid deployment. It can also be applied to scenarios such as single-accelerator hardware deployment and multi-process, multi-tenant access to accelerator hardware.

[0018] The AI ​​accelerator fusion system is a hardware and software collaborative system consisting of one or more AI accelerator hardware components, along with supporting kernel drivers and user-mode runtime. Within this system, user-mode business processes can create device contexts and use the ioctl interface to send computation tasks to the accelerators, perform memory mapping, message synchronization, and other operations. The device context is a data structure maintained by the kernel. When a thread performs an ioctl message synchronization operation, it holds a read lock on the device context. When destroying and reclaiming the device context, it needs to acquire a mutually exclusive write lock. Read locks and write locks are mutually exclusive; read locks and write locks cannot be active simultaneously.

[0019] In the actual operation of the accelerator fusion system, business processes may encounter abnormal termination situations such as signal kill, segmentation fault, and OutOfMemoryError (OOM) termination. When a process terminates abnormally, the user-mode execution path of the business process has ended, but some threads performing message synchronization are not directly destroyed by the kernel. Instead, they remain in kernel mode, blocked on the waiting queue corresponding to the message synchronization ioctl. These blocked threads will continue to hold the read lock of the device context and will not actively release it. The existing driver's recycling logic does not provide coordinated handling for this scenario: the recycling process does not actively intervene in the blocked threads. When the background recycling path directly attempts to acquire and destroy the write lock to execute the device context destruction, the write lock cannot be acquired because the blocked threads still hold the read lock. At this time, the driver usually has two processing results: one is to directly execute the destruction regardless of the lock state. After the destruction is completed, the threads blocked in the kernel waiting queue will still access the already released device context memory, triggering a high-risk User-Avoidance-Failure (UAF) error, ultimately causing a race condition kernel crash. Secondly, if the write lock acquisition fails, the current reclamation is abandoned directly. The device context and associated kernel resources such as page tables and address space identifiers (ASIDs) are not released, resulting in kernel resource leakage. Long-term operation will consume the system's limited hardware resources and reduce the utilization of accelerator hardware.

[0020] To address the technical issues of race-state kernel crashes and kernel resource leaks that easily occur when service processes in an accelerator fusion system are abnormally terminated, this embodiment provides a resource handling method. This method is applied to the kernel-mode driver (KMD) of the AI ​​accelerator fusion system. This KMD runs in the operating system kernel space and is responsible for accelerator hardware resource management, device context lifecycle maintenance, input / output control request processing, kernel resource allocation and reclamation, etc. User-mode service processes interact with the accelerator hardware through the device file interface provided by the driver.

[0021] like Figure 1 The diagram shown illustrates a resource processing method, which includes: S101. Obtain the abnormal business process that was terminated in the accelerator fusion system.

[0022] The abnormal business process refers to a business process that has been abnormally terminated, such as being killed by a signal, segmentation fault, or OOM termination. The user-mode execution path of the process has been terminated, but there are still business processes with threads that are dormant and blocked in the kernel mode.

[0023] In this embodiment, a unified process entity (ecu_process) is set up on the kernel side of the accelerator fusion system. User-space business processes interact with the kernel through a dual-channel architecture. The dual channels include a control channel and a device channel. When a business process opens the / dev / ecuctl device file to enable the control channel, the kernel creates or binds an ecu_process structure. This ecu_process maintains a global process list node (process_list) and an array (res_devs) organized by device index. Each item in res_devs corresponds to an accelerator hardware, which stores the device context list (ctx_list), device object (ecu_dev), and page table (pg_tbl); at the same time, it maintains a process-level mutex (proc_mutex) and a user virtual address (UVA) management module (uva_am). Among them, uva_am has a built-in address management mutex (am_mutex), which is used to protect the concurrent access of virtual address mapping-related data structures.

[0024] In this embodiment, the ecu_process is mounted on the process_list. The background kernel monitoring thread periodically scans this global process list, traverses each ecu_process in the list, and combines the process-related status information maintained inside the ecu_process to identify the ecu_process corresponding to a user-mode execution path that has terminated, but still exists on the kernel side as a dormant or blocked thread. Thus, it obtains the abnormal business process corresponding to the ecu_process that has terminated.

[0025] S102. Set the device context corresponding to the remaining thread in the abnormal business process to a pending destruction mark, and perform a wake-up operation on the remaining thread to release the sleeping and blocked state of the remaining thread, so that the remaining thread can run in kernel mode.

[0026] Among these, remaining threads are threads that are dormant and blocked when an abnormal business process terminates. For example, these remaining threads are those blocked in the waiting queue corresponding to the message synchronization ioctl when the business process exits abnormally. The user-mode execution path of the remaining thread has ended, but the thread itself remains in the kernel-mode waiting queue and continues to hold the read lock on the device context, without releasing the lock resource itself.

[0027] In this embodiment, the remaining thread's sleep blocking state is released by setting a release status flag (ECU_CTX_LIFE_STATE_RELEASING) on the device context corresponding to the remaining thread and calling the wake-up interface to perform a wake-up operation on the waiting queue. The awakened remaining thread continues to execute logic in kernel mode, and upon detecting the release status flag of the device context, exits the message synchronization waiting process and releases the device context read lock it holds.

[0028] In this embodiment, a pending-destruction flag (ECU_CTX_LIFE_STATE_RELEASING) is written to the device context to mark the device context as entering a pending-destruction state. This pending-destruction state means the device context has been determined to require destruction and recycling, prohibiting the acceptance of new service requests, and prompting any remaining kernel threads to actively exit service processing and release their held lock resources. Next, the kernel wait queue wake-up interface is called to wake up the remaining threads blocked in the wait queue corresponding to the message synchronization ioctl.

[0029] For example, after the remaining threads are awakened, they do not return to user mode but continue to execute subsequent logic in kernel mode. During the thread execution, if the device context is detected as pending destruction, the thread will actively exit the message synchronization waiting process and release the device context read lock it holds.

[0030] By using a flag-and-wake-up mechanism, the stranded thread is driven to release the lock in kernel mode, thus avoiding the risk of kernel race-state crashes caused by direct brute-force destruction.

[0031] S103. Within the target execution duration, identify whether the device context corresponding to the remaining thread is in a locked state. The device context is the context that the remaining thread needs to use during execution. If the remaining thread holds a read lock on the corresponding device context, it is determined that the device context is in a locked state.

[0032] The target execution time refers to the maximum waiting time preset by the kernel for this resource reclamation operation, which is used as the time window for constraint lock state detection.

[0033] In this embodiment of the application, if the device context is waited for indefinitely, the recycling process will be suspended indefinitely, and the ecu_process will remain in the closed state for a long time, continuously occupying kernel resources such as ASID and page tables without being released, thereby causing system resource leakage.

[0034] In this embodiment, the device context is configured with a read-write lock (ctx_release_rw_lock). The read lock corresponds to the read lock acquired by the business thread when performing message synchronization ioctl. When destroying and reclaiming the lock, a mutually exclusive write lock needs to be acquired. This step repeatedly attempts to acquire the write lock of the device context within the target execution duration time window to identify the lock state of the device context. If the write lock cannot be acquired successfully, it indicates that the remaining thread still holds the read lock, and the device context is determined to be in a locked state. If the write lock is successfully acquired, it indicates that the read lock has been released, and the device context is determined to be in an unlocked state.

[0035] S104. In response to the device context corresponding to the remaining thread being in an unlocked state, the device context is destroyed and the kernel resources associated with the destroyed device context are reclaimed.

[0036] In this embodiment, after determining that the device context is in an unlocked state and successfully acquiring the write lock (ctx_release_rw_lock), the device context destruction process is executed. First, the device context of the ecu_context is removed from the device context linked list corresponding to the res_devs array under its respective ecu_process, completing the unbinding of the context from the process management linked list. Then, the dedicated kernel resources corresponding to the device context itself are reclaimed, such as buffer object mappings bound to the context and context private descriptors. After resource reclamation is completed, the currently held ctx_release_rw_lock is released to prevent long-term lock occupation from affecting the creation and destruction operations of other device contexts.

[0037] For example, after destroying a single device context, the state of the ctx_list linked list under the current device item is also checked. When it is detected that the ctx_list linked list corresponding to the device is empty, it indicates that there is no remaining device context under the accelerator hardware. Then, the shared kernel resources at the hardware level, such as ASID, page tables and other global resources, are further reclaimed to prevent the leakage of shared kernel resources.

[0038] Compared with existing technologies, this application first identifies abnormal business processes that have been terminated in the accelerator fusion system, then controls the remaining threads that are dormant and blocked in the abnormal business processes to run in kernel mode, causing these threads to exit dormancy and blocking. Within the target execution duration, it identifies whether the device context is locked due to remaining threads holding read locks, and only performs device context destruction and reclaims the corresponding kernel resources when the device context is unlocked. This avoids race conditions caused by directly destroying the device context while it is still held by read locks, reduces the risk of kernel crashes due to post-release use, and improves the security of the kernel-side resource reclamation process in the accelerator fusion system.

[0039] The resource processing method provided in the embodiments of this application will now be described in detail.

[0040] Optionally, this application also provides an embodiment for obtaining an abnormal business process that has terminated in an accelerator fusion system. In this embodiment, the current business process in the accelerator fusion system is obtained through a background kernel monitoring thread. The control channel status of the current business process and the execution path status of the thread on the user-mode side are identified. When the control channel is closed and the execution path of the thread on the user-mode side is terminated, the current business process is identified as an abnormal business process that has terminated.

[0041] The accelerator fusion system comprises multiple service processes, each managing the device context of at least one accelerator card within the system via a control channel. The device context is the kernel session object corresponding to the accelerator card, maintained by a unified process entity management node bound to the service process, and used by threads within the service process. During service execution, threads can hold a read lock on the device context; if the process terminates abnormally, any remaining threads that are currently in a dormant or blocked state may continue to hold the read lock.

[0042] In this embodiment, a background kernel monitoring thread (EcuProcMonitor) periodically executes scanning tasks according to a preset cycle, traversing the global process list (process_list) under the protection of a global linked list protection lock (proc_mgr_op_mutex). The monitoring thread sequentially traverses each node in the linked list, selecting each ecu_process node in the list as the object to be detected, completing the polling of the unified process entity of ecu_process corresponding to multiple business processes, and determining the current business process to be detected from it.

[0043] For example, after the background kernel monitoring thread finishes reading the linked list node, it releases the global linked list protection lock to prevent the system from holding the global lock for a long time and blocking the normal processing flow of other business processes such as creation and destruction.

[0044] In this embodiment, the control channel status of the current business process is identified by reading the process status identifier recorded inside ecu_process; the survival status of the corresponding thread task entity is verified by the kernel PID validity query interface, thereby identifying the execution path status of the thread on the user-mode side.

[0045] For example, ecu_process maintains three types of process states: normal operation, closed, and destroyed. When the process state is closed, it indicates that the control channel of the business process has been closed and no longer receives new device context creation requests. Based on this, the kernel PID validity query interface is used to determine whether the thread task entity has been destroyed, distinguishing between three different situations: process idle, process still alive, and process terminated, in order to complete the determination of abnormal business processes.

[0046] When the process is in an idle state, i.e., in the CLOSING state, all device context lists ctx_list are empty, the unified process entity ecu_process is destroyed directly, and all kernel resources corresponding to the process entity are reclaimed.

[0047] When the process is still alive (i.e., the control channel is closed, but the corresponding thread task entity is still alive), it means that the user-mode process is still performing normal cleanup operations. In this case, no forced recycling will be performed in this scan. The user-mode process will be allowed to close the device channel itself and wait for the next round of monitoring thread cycle scans to make a judgment.

[0048] When the target situation is that the process has been terminated, that is, the control channel is in the CLOSING state and the thread task entity has been destroyed, and the user space can no longer complete the context closure itself, the forced recycling process of this application is triggered to destroy the device context attached to the ecu_process.

[0049] The above embodiments rely on the status identifier of a unified process entity combined with kernel thread liveness verification to achieve multi-branch processing, which avoids accidentally damaging business processes that are still in the process of terminating normally, and can promptly perform resource reclamation on abnormal business processes that have been terminated, thus balancing system security and resource release efficiency.

[0050] Optionally, this application also provides an embodiment for identifying whether the device context corresponding to the remaining threads is in a locked state within the target execution duration. In this embodiment, within the target execution duration, an attempt is made to acquire a write lock on the device context; if the write lock is not acquired, the device context is determined to be in a locked state; if the write lock is acquired, the device context is determined to be in an unlocked state.

[0051] In this embodiment, a contention-based acquisition operation with a timeout is performed on the ctx_release_rw_lock read-write lock of the device context. The timeout is configured to the target execution duration, thereby competing to acquire and destroy the write lock within a limited time window. If the remaining threads have not yet released the read lock, read-write mutual exclusion will occur, the write lock destruction contention-acquisition operation will time out and return, indicating that the device context is in a locked state. If the remaining threads have released the read lock and the write lock destruction contention-acquisition is successful, the device context is determined to be in an unlocked state.

[0052] For example, the target execution duration can be a millisecond-level time threshold, which is set based on the typical processing time of message synchronization ioctl of heterogeneous accelerators and the overhead of kernel thread context switching. It needs to allow sufficient time for the remaining awakened threads to complete the lock release, but it cannot be set too large, causing the garbage collection process to block for a long time and occupy kernel resources.

[0053] The above embodiments utilize a timeout-based write lock contention logic to identify the lock state, thus avoiding infinite waiting that could cause the recycling process to be suspended and kernel resources to leak.

[0054] Optionally, if the target execution time expires and the write lock is not acquired to destroy, the resource reclamation process for the abnormal business process is terminated.

[0055] In this embodiment of the application, when the competitive acquisition and destruction of the write lock operation with timeout returns after a timeout, the current resource reclamation process for the abnormal business process is directly terminated, the original state of the ecu_process unified process entity is preserved, and no forced destruction action is performed.

[0056] For example, after the current recycling process is terminated, the background kernel monitoring thread will wait for the next scan cycle to arrive before initiating a complete round of resource recycling detection and processing for the unified process entity again.

[0057] The above embodiments avoid the single recycling process from getting stuck by exiting after a timeout and retrying in the next cycle, thus ensuring that the overall scanning task of the kernel monitoring thread can continue to operate normally.

[0058] Optionally, this application also provides an embodiment for destroying a device context and reclaiming the kernel resources of the destroyed device context. In this embodiment, a destroy write lock on the device context is acquired; the device context is removed from the device context linked list corresponding to the service process, and the dedicated kernel resources of the device context are reclaimed; the destroy write lock is released.

[0059] In this embodiment, after competitively acquiring the destroy write lock corresponding to the device context ctx_release_rw_lock, the ctx_list in the res_devs array maintained by ecu_process is accessed to complete the linked list removal operation of the target ecu_context node, and then the various dedicated kernel resources corresponding to the device context are reclaimed. After processing is completed, the held destroy write lock is released.

[0060] For example, dedicated kernel resources include device context private descriptors, buffer object mappings, and other resources; if the ctx_list linked list corresponding to the current device is empty after removal, the shared kernel resources such as the ASID and page table corresponding to the accelerator hardware can be further reclaimed.

[0061] The above embodiments rely on destruction write locks for mutual exclusion protection throughout the destruction process, ensuring thread safety during device context list operations and resource reclamation, and preventing kernel resource leaks.

[0062] Optionally, this application also provides an embodiment for reclaiming shared kernel resources. In this embodiment, the state information of the device context list is obtained, and if it is determined from the state information that the device context list is empty, the shared kernel resources of multiple device contexts are reclaimed.

[0063] In this embodiment, the count of the ctx_list device context list nodes under the res_devs array is read to obtain the status information of the device context list; when it is determined that there is no valid device context node inside the list, the reclamation operation of the shared kernel resources of the accelerator hardware dimension is triggered.

[0064] For example, shared kernel resources include ASIDs, hardware-bound page tables, and other resources that are shared by multiple device contexts under the same hardware. These resources are not automatically released when a single device context is destroyed.

[0065] The above embodiments reclaim shared kernel resources only after confirming that all device contexts have been destroyed, thus avoiding premature release of shared resources that could cause access errors in other contexts.

[0066] In conjunction with the above embodiments, this application also provides a specific implementation method for device context security resource reclamation based on a unified process entity in a heterogeneous AI accelerator fusion system. This method is applied to user process anomaly scenarios in the heterogeneous AI accelerator fusion system. The heterogeneous AI accelerator fusion system deploys two or more heterogeneous AI accelerator hardware types, such as D10 and D20 computing cards, supporting multiple D10 homogeneous deployments, multiple D20 homogeneous deployments, and mixed heterogeneous deployments of D10 and D20 cards, among other hardware topologies.

[0067] The upper layer of the system carries AI inference and training services. The service processes rely on the heterogeneous accelerator user-space runtime library (RIVS-Runtime) to complete hardware interactions. On the kernel side, a dual-channel driver model is adopted, consisting of the / dev / ecuctl control channel and the / dev / ecuN device channel. The ecu_process manages the ecu_context device contexts under multiple heterogeneous hardware in a unified manner.

[0068] like Figure 2 The diagram shown illustrates a resource recycling process for a heterogeneous AI accelerator fusion system, including: S201. Construct a unified process entity and a dual-channel model.

[0069] The kernel-side `ecu_process` maintains a global `process_list`, a `res_devs[]` array arranged by device index, and process-level management resources. Each device entry in the `res_devs[]` array maintains a device context list (`ctx_list`), a device object (`ecu_dev`), and a page table (`pg_tbl`). Process-level management resources include a process mutex (`proc_mutex`) and a UVA management module (`uva_am`) with an `am_mutex` lock.

[0070] User space binds to the `ecu_process` via the ` / dev / ecuctl` control channel, and then creates a device context (`ecu_context`) via the ` / dev / ecuN` device channel. This context is then mounted to the corresponding linked list `res_devs[i].ctx_list` (where `i` is the device index). ECU-type ioctls such as memory mapping and message synchronization are forwarded via `ecuctl` and bound to the target `ecu_context`, thereby incorporating the device contexts of various heterogeneous devices (D10, D20, etc.) into the same set of process resource views.

[0071] S202, Configure the asynchronous state machine and background kernel monitoring thread.

[0072] When a user closes the file descriptor (`close`) and shuts down ` / dev / ecuctl`, the `ecu_process` reference count reaches zero. Instead of directly destroying the `ecu_process`, the kernel sets its state to `ECU_PROCESS_STATE__CLOSING`, stopping it from receiving new device context creation requests. Then, `EcuProcMonitor` iterates through the `process_list` at 10ms intervals, protected by the `proc_mgr_op_mutex` lock.

[0073] For each process in the CLOSING state, the branch judgment is completed under the protection of proc_mutex: the process idle judgment function (ecu_process_is_idle()) is called to determine whether ecu_process has no more hardware resources in use and has entered an idle state; if the ctx_list under all res_devs array items is empty and there is no valid ecu_dev, the unified process entity destruction interface (ecu_process_destroy) is called to complete the complete destruction of the process entity.

[0074] The process termination judgment function (ecu_process_is_terminated()) is called to check whether the user business process associated with ecu_process has been terminated. If ctx_list is not empty, and the process identifier of the thread corresponding to the device context is invalid as found by the process PID lookup interface (efi_find_get_pid), then the all-context forced release interface (ecu_process_force_release_all_ctx) is called to perform forced context reclamation.

[0075] In other cases, if the process is still alive and the context has not been completely closed, wait for the user-mode to normally close the / dev / ecuN device channel.

[0076] S203. Read-write locks are used to coordinate input / output control business operations and device context release processes.

[0077] For each ecu_context, an independent ctx_release_rw_lock[ctx_id] read / write semaphore (rw_semaphore) is configured in the corresponding accelerator device to achieve single-context exclusive lock management. When user space forwards various ECU-type ioctl requests through the control channel, the kernel driver acquires a read lock for the device context corresponding to the target ctx_id. After the ioctl business is completed and returns a result, the corresponding read lock is released in a timely manner. For blocking message synchronization operations, the waiting logic (wait_event) is placed outside the scope of read / write lock management. During the thread blocking and waiting process, the read lock is continuously held to ensure the stability of the synchronization business.

[0078] In a normal user-mode resource shutdown scenario, the user closes the / dev / ecuN device channel by calling close. The kernel driver resource release path competes for the context destruction write lock, calls the device context destruction processing interface (blob_ecu_context_finish_and_destroy) to complete the complete destruction process, and releases the write lock after the destruction operation is completed.

[0079] In kernel-forced reclamation scenarios, the ecu_process_force_release_all_ctx forced reclamation processing path follows the same processing logic. It first competes to acquire the destroy write lock, and then calls the same set of destruction interfaces to ensure that the abnormal reclamation and the device context dismantling processing path of normal shutdown are completely isomorphic.

[0080] S204. Active interruption mechanism for executing blocking synchronous input / output control.

[0081] When the context enters the resource release process, the kernel driver sets the device context lifecycle flag to ECU_CTX_LIFE_STATE_RELEASING; in the ecu_context_release and ecu_process_wake_ctx_release_waiters processing logic before write lock retry, the kernel wait queue wake-up function (wake_up_interruptible_all) is called to wake up the msg_queue->wait_queue wait queue.

[0082] When the message synchronization wait logic detects the ECU_CTX_LIFE_STATE_RELEASING state or that the msg_queue is empty, it terminates the wait and the ioctl returns an error code (EECURESET). During the blocking wait phase, an unkillable count (unkillable_cnt) is maintained and aligned with the hardware reset processing path to prevent improper thread termination. This mechanism forces threads blocked in the waiting queue and holding read locks to proactively exit the ioctl and release the read lock, creating conditions for the monitoring thread to acquire and destroy the write lock, preventing waiters from remaining after the waiting queue is destroyed, thus avoiding User-Avoidance (UAF) defects.

[0083] S205, Execute layered lock processing and write lock retry logic.

[0084] The kernel's forced reclamation process is protected by proc_mutex. It traverses ctx_list according to res_devs[i] (where i is the device index), retrieves the device context at the head of the list, and immediately releases proc_mutex. This avoids the risk of deadlock caused by repeatedly requesting the same lock with the removal and cleanup logic inside finish_and_destroy.

[0085] Then, `ecu_process_ctx_release_write_lock(ctx)` is called, first executing `wake_ctx_release_waiters` to wake up the user, and then repeatedly calling `down_write_killable` to compete for and destroy the write lock. For example, it is configured to perform 6000 retries with a 10ms interval, resulting in a total timeout of approximately 60 seconds, re-executing the wake-up operation after each failed lock acquisition.

[0086] After successfully acquiring the write lock, the process calls blob_ecu_context_finish_and_destroy(ctx) to complete the destruction, executes up_write to release the write lock, and then reacquires the proc_mutex process mutex to handle the next device context.

[0087] If the write lock acquisition fails in this round, the current processing loop of the device is terminated, the device context is not removed from the linked list, and the monitoring thread is handed over to the next cycle scan for retry and reclamation.

[0088] Once all device contexts under a given device have been processed, `ecu_process_fini_device_resource()` is called. In scenarios where the user process has died and user space cannot execute `close`, the kernel safely and retryably performs a destruction process equivalent to `ecu_release`, resolving issues such as deadlocks and `ecu_process` remaining permanently in the CLOSING state.

[0089] S206. Call the unified destruction processing interface of the device context and the backup recycling interface of the device resources to reclaim resources.

[0090] blob_ecu_context_finish_and_destroy executes the process in a fixed order: removing the device context from the list, suspending hardware tasks, cleaning up resources, reclaiming pg_tbl and setting ecu_dev to null when processing the last context, and finally executing ecu_context_destroy to destroy the context structure.

[0091] As a fallback logic, when ctx_list is empty but ecu_dev is not NULL, it performs the same ecu_mmu_ctx_switch_out, free_asid, and page_table_fini operations as cleaning up the last context, and then clears ecu_dev.

[0092] S207. Coordinated management of the global process linked list protection lock between the execution monitoring thread and the destruction path.

[0093] The monitoring thread holds the proc_mgr_op_mutex while iterating through the process_list; it actively releases the proc_mgr_op_mutex before performing time-consuming destruction operations such as ecu_process_destroy and force_release_all_ctx.

[0094] After authorization is granted through the ecu_process_operation_validate whitelist, the monitoring thread can call the blob_ecu_context_finish_and_destroy interface to destroy the process.

[0095] Furthermore, as Figure 1 and Figure 2 To provide a specific implementation of the method shown, this embodiment offers a resource processing device, such as... Figure 3 The diagram shows the structure of a resource processing device 300, which includes an acquisition module 301, a control module 302, an identification module 303, and a processing module 304; wherein: The acquisition module 301 is configured to acquire abnormal business processes that have been terminated in the accelerator fusion system.

[0096] The control module 302 is configured to set the device context corresponding to the remaining thread in the abnormal business process to a pending destruction mark state, and to perform a wake-up operation on the remaining thread to release the remaining thread from its dormant and blocked state, so that the remaining thread can run in kernel mode. The remaining thread is the thread that is dormant and blocked when the abnormal business process is terminated.

[0097] The identification module 303 is configured to identify whether the device context corresponding to the remaining thread is in a locked state within the target execution duration. The device context is the context that the remaining thread needs to use during execution. If the remaining thread holds a read lock on the corresponding device context, it is determined that the device context is in a locked state.

[0098] Processing module 304 is configured to destroy the device context and reclaim the kernel resources associated with the destroyed device context in response to the device context corresponding to the remaining thread being in an unlocked state.

[0099] Optionally, the acquisition module 301 is also configured to obtain the current business process in the accelerator fusion system through a background kernel monitoring thread. The accelerator fusion system includes multiple business processes, and the business processes manage the device context of at least one accelerator card in the accelerator fusion system through a control channel.

[0100] Identify the control channel status of the current business process and the execution path status of the thread on the user side. If the control channel is closed and the execution path of the thread on the user side is terminated, identify the current business process as an abnormal business process that has stopped execution.

[0101] Optionally, the control module 302 is also configured to set the device context corresponding to the remaining threads to a state to be destroyed, and to perform a wake-up operation on the remaining threads to release the sleeping and blocked state of the remaining threads, so that the remaining threads can run in kernel mode.

[0102] Optionally, the identification module 303 is also configured to attempt to acquire a destroy write lock on the device context within the target execution duration.

[0103] If the write lock for destruction is not acquired, the device context is determined to be in a locked state.

[0104] If the write lock is acquired and destroyed, the device context is determined to be in an unlocked state.

[0105] Optionally, the identification module 303 is also configured to terminate the resource reclamation process of the abnormal business process if the target execution time is exhausted and the write lock for destruction is not acquired.

[0106] Optionally, the processing module 304 is also configured to acquire a destroy write lock for the device context.

[0107] Remove the device context from the device context list corresponding to the business process and reclaim the dedicated kernel resources of the device context.

[0108] Release and destroy the write lock.

[0109] Optionally, the processing module 304 is also configured to obtain the status information of the device context list, and if it is determined from the status information that the device context list is empty, reclaim the shared kernel resources of multiple device contexts.

[0110] It should be noted that other corresponding descriptions of the functional units involved in the resource processing device provided in this embodiment can be found in [reference]. Figure 1 and Figure 2 The corresponding descriptions in [the document] will not be repeated here.

[0111] Based on the above, Figure 1 and Figure 2 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 and Figure 2 The method shown.

[0112] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0113] like Figure 4 The diagram shown is a hardware structure schematic of an electronic device according to the present invention, comprising: At least one processor 401; and, A memory 402 is communicatively connected to at least one of the processors 401; wherein, The memory 402 stores instructions that can be executed by at least one of the processors to enable the at least one processor to perform the resource processing method as described above.

[0114] Figure 4 Take a processor 401 as an example.

[0115] The electronic device may also include an input device 403 and an output device 404.

[0116] The processor 401, memory 402, input device 403, and output device 404 can be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0117] Memory 402, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the resource processing method in the embodiments of this application, for example, Figure 1 and Figure 2 The method flow is shown. The processor 401 executes various functional applications and data processing by running non-volatile software programs, instructions, and modules stored in the memory 402, thereby implementing the resource processing method in the above embodiments.

[0118] Memory 402 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created according to the use of the resource processing method, etc. Furthermore, memory 402 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 402 may optionally include memory remotely located relative to processor 401, and these remote memories may be connected to the apparatus performing the resource processing method via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0119] Input device 403 can receive user clicks and generate signal inputs related to user settings and function control for resource processing methods. Output device 404 may include display devices such as a display screen.

[0120] When one or more modules are stored in the memory 402, and are run by one or more processors 401, the resource processing method in any of the above method embodiments is executed.

[0121] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0122] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0123] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms, or it can be implemented by hardware. By applying the solution of this embodiment, compared with the prior art, this application first identifies the abnormal business process that has been terminated in the accelerator fusion system, and then controls the remaining threads that are dormant and blocked in the abnormal business process to run on the kernel side, causing these threads to exit dormancy and blocking; within the target execution duration, it identifies whether the device context is in a locked state due to the remaining threads holding a read lock, and only when the device context is in an unlocked state is the device context destruction process executed and the corresponding kernel resources reclaimed. This avoids the race condition conflict caused by directly destroying the device context while it is still occupied by a read lock, reduces the risk of kernel crash caused by using it after release, and improves the security of the kernel-side resource reclamation process of the accelerator fusion system.

[0125] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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.

[0126] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A resource processing method, characterized in that, include: Obtain the abnormal business processes that have been suspended in the accelerator fusion system; Set the device context corresponding to the remaining thread in the abnormal service process to a pending destruction mark state, and perform a wake-up operation on the remaining thread to release the sleeping and blocked state of the remaining thread, so that the remaining thread runs in kernel mode. The remaining thread is the thread that was sleeping and blocked when the abnormal service process was terminated. Within the target execution time, identify whether the device context corresponding to the remaining thread is in a locked state. The device context is the context that the remaining thread needs to use during execution. If the remaining thread holds a read lock on the corresponding device context, it is determined that the device context is in a locked state. In response to the device context corresponding to the remaining thread being in an unlocked state, the device context is destroyed, and the kernel resources associated with the destroyed device context are reclaimed.

2. The method according to claim 1, characterized in that, The abnormal service processes that were interrupted in the accelerator fusion system include: The current service process in the accelerator fusion system is obtained through a background kernel monitoring thread. The accelerator fusion system includes multiple service processes, and the service processes manage the device context of at least one accelerator card in the accelerator fusion system through a control channel. The control channel status of the current business process and the execution path status of the thread on the user side are identified. If the control channel is closed and the execution path of the thread on the user side is terminated, the current business process is identified as an abnormal business process that has been terminated.

3. The method according to claim 1 or 2, characterized in that, The step of identifying whether the device context corresponding to the remaining threads is locked within the target execution duration includes: During the target execution duration, attempt to acquire the destroy write lock of the device context; If the write lock for destruction is not acquired, the device context is determined to be in a locked state; If the write lock is acquired and destroyed, the device context is determined to be in an unlocked state.

4. The method according to claim 3, characterized in that, The method further includes: If the execution time of the target expires and the write lock is not acquired and destroyed, the resource reclamation process for the abnormal business process is terminated.

5. The method according to claim 1 or 2, characterized in that, The step of destroying the device context and reclaiming the kernel resources of the destroyed device context includes: Acquire the destroy write lock of the device context; Remove the device context from the device context list corresponding to the service process and reclaim the dedicated kernel resources of the device context; Release the write lock that was destroyed.

6. The method according to claim 5, characterized in that, The device context linked list contains multiple device contexts belonging to the same accelerator hardware device in the accelerator fusion system; the method further includes: Obtain the state information of the device context list, and if it is determined that the device context list is empty based on the state information, reclaim the shared kernel resources of the multiple device contexts.

7. A resource processing device, characterized in that, include: The acquisition module is configured to acquire abnormal business processes that have been terminated in the accelerator fusion system. The control module is configured to set a pending destruction flag state for the device context corresponding to the remaining threads in the abnormal service process, and to perform a wake-up operation on the remaining threads to release the dormant blocking state of the remaining threads, so that the remaining threads run in kernel mode. The remaining threads are the threads that were dormant and blocked when the abnormal service process was terminated. The identification module is configured to identify whether the device context corresponding to the remaining thread is locked within the target execution time. The device context is the context that the remaining thread needs to use during execution. If the remaining thread holds a read lock on the corresponding device context, it is determined that the device context is locked. The processing module is configured to destroy the device context and reclaim the kernel resources associated with the destroyed device context in response to the device context corresponding to the remaining thread being in an unlocked state.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

9. An electronic device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 6.

10. A computer program product having a computer program stored thereon, characterized in that, When the computer program product is executed by a processor, it implements the method of any one of claims 1 to 6.

Images