MigGPT: Harnessing Large Language Models for Automated Migration of Out-of-Tree Linux Kernel Patches Across Versions
Authors: Pucheng Dang
Di Huang
Dong Li
Kang Chen
Yuanbo Wen
Qi Guo
Xing Hu
Venue: NeurIPS 2025 spotlight ()
Keywords: Code Migration
Linux Kernel
Out-of-Tree Patch Migration
large language models
Code Structure Analysis
Primary area: applications
TL;DR: This paper introduces MigGPT, a novel framework that leverages large language models and a code fingerprint structure to automate the migration and maintenance of out-of-tree Linux kernel patches.

Abstract: Out-of-tree kernel patches are essential for adapting the Linux kernel to new hardware or enabling specific functionalities. Maintaining and updating these patches across different kernel versions demands significant effort from experienced engineers. Large language models (LLMs) have shown remarkable progress across various domains, suggesting their potential for automating out-of-tree kernel patch migration. However, our findings reveal that LLMs, while promising, struggle with incomplete code context understanding and inaccurate migration point identification. In this work, we propose MigGPT, a framework that employs a novel code fingerprint structure to retain code snippet information and incorporates three meticulously designed modules to improve the migration accuracy and efficiency of out-of-tree kernel patches. Furthermore, we establish a robust benchmark using real-world out-of-tree kernel patch projects to evaluate LLM capabilities. Evaluations show that MigGPT significantly outperforms the direct application of vanilla LLMs, achieving an average completion rate of 72.59\% ($\uparrow 50.74\%$) for migration tasks.

MIGGPT: Harnessing Large Language Models for Automated Migration of Out-of-Tree Linux Kernel Patches Across Versions
Pucheng Dang 1,2,3
Di Huang' 1
Dong Li 12,3
Kang Chen 4
Yuanbo Wen State Key Lab of Processors, Institute of Computing Technology, CAS University of Chinese Academy of Sciences
Qi Guo Xing Hu 1.3
Zhongguancun Laboratory
Tsinghua University
(dangpucheng20g, lidong)ddict..... ac.
Abstract
Out-of-tree kernel patches essential for adapting the Linux kernel to hardware or enabling specific functionalities. Maintaining and updating these patches across different kernel versions demands significant effort from experi- enced engineers. Large language models (LLMs) have shown remarkable progress across various domains, suggesting their potential for automating out-of-tree ker- nel patch migration. However, our findings reveal that L.MMs, while promising, struggle with incomplete code context understanding and inaccurate migration point identification. In this work, we propose MIGGPT, a framework that em- ploys a novel code fingerprint structure to retain code snippet information and incorporates three meticulously designed modules to improve the migration ac- curacy and efficiency of out-of-tree kernel patches. Furthermore, we establish a robust benchmark using real-world out-of-tree kernel patch projects to evalu- ate LLM capabilities. Evaluations show that MIGGPT significantly outperforms the direct application of vanilla I.L.ss, achieving an average completion rate of 74.07% 7 (f 45.92% for migration tasks. Our code and data are available https: //githbb.tuut....... www com./CheerryBluberrrr/ggeaeeeeee
Introduction
The Linux kernel, a widely-used open-source operating system, is extensively applied across various domains [46 30 5 (55.. Its adaptability and extensibility enable developers create out-of-tree kernel patches that enhance performance [23 or security [50] [7]])) [52), holding irreplaceable significance in modern engineering practices. Out-of-tree kernel patches, such RT- RT-PREEMPT, AUFS, HAOC, Raspberry Pi kernel, and Open vSwitch, are modifications to the Linux kernel that are developed and maintained independently of the mainline source tree. Unlike in-tree patches, which are included in official kernel releases, out-of-tree patches address specific use cases or features not yet supported by the mainline kernel. As the Linux kernel evolves, these out-of-tree patches require ongoing maintenance to ensure compatibility with newer Linux kernel versions. As shown in Figure | the maintenance process involves utilizing the old out-of-tree kernel patch and analyzing the differences between the old and new Linux kernel versions to upgrade the patched kernel repository to the new version. This maintenance process is crucial and labor-intensive in engineering applications, which demands specialized experts and takes weeks of intensive effort [56].
"Corresponding author
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

Existing code migration technologies
48
25
Old Linux Kernel
New Linux Kemel Repository
12
utilize static program analysis 26 to facilitate API
44
53
Repository
Version Update
cross-version maintenance or the backporting of CVE security patches. However, these methods only address a subset of scenarios out-of-tree kernel patch migration. 1) They rely on pre- defined migration rules, which are insufficient for handling comprehensive scenarios involving complex changes such as namespace modifica- tions, invocation conflict resolution, and the inte- gration of control and data flow dependencies. 2) These single-step methods assume known target code locations in updated repositories, limiting their applicability out-of-tree kernel patch scenarios.
Expert Fiffort
BEG
Old Ous-of-Tie Patch
Migration
X000
Parched Old Linux
Patched New Linux Korel Repository
Kemel Repository
MigGPT
Figure 1: MIGGPT assist in automating the version migration and maintenance out-of-tree kernel patches of the Linux kernel. This saves on expert labor costs and reduces the development cycle.
With the substantial progress made by Large Language Models (LLMs) in understanding 38 I|
24
and generating code [13 [ 336 51 (54), there is promising opportunity to leverage LLMs for the automated migration and maintenance of out-of-tree kernel patches. However, due to the inherent lack of determinism in LLMs when generating content, several challenges arise when directly employing these models to handle the migration and maintenance of out-of- tree kernel patches. These challenges include 1) structural
mmnllartty-nduuce failure, 2) -en-deterministic code snippet boundaries, 3) absence of associated code snippet information, and 4) inaccuracies locating migration points, which reveal that LLMs struggle with incomplete code context understanding and inaccurate migration point identification.
To address the challenges, we propose MIGGPT, the first framework designed to assist humans in automating the migration and maintenance of out-of-tree kernel patches. We reframe this migration process as two-step task: retrieving target code from updated kernels and performing patch migration, which is both more challenging and practical. MIGGPT utilizes Code Fingerprint (CFP), a novel data structure to encapsulate the structural and critical information of code snippets throughout the migration process of out-of-tree kernel patches. With the assistance of CFP, MIGGPT incorporates three core modules: the Retrieval Augmentation Module (addressing challenges 1 and challenges 3), the Retrieval Alignment Module (addressing challenge 2), and the Migration Enhancement Module (addressing challenge 4). Specifically, the Retrieval Augmentation Module supplies code snippet information via CFPs, mitigates interference from similar structures, and appends additional code snippet information pertinent to migration. The Retrieval Alignment Module achieves alignment of the target code snippet boundaries through the first anchor line and the last anchor line within CFPs. The Migration Enhancement Module facilitates accurate and efficient migration by comparing CFPs to ascertain the number of migration points and their respective locations.
To evaluate the efficiency of MIGGPT, construct robust benchmark that includes three real-world projects from the out-of-tree patch community of the Linux kernel. These projects comprise two different levels of migration examples, encompassing variety of common migration types. With this benchmark, we evaluated MIGGPT across diverse LLMs (GPT-3.5, GPT-4-turbo, OpenAI-ol, DeepSeek-V3, DeepSeck-R1, and Llama-3.1) [33 34 35 8 I to validate its effectiveness and broad applicability. MIGGPT significantly outperforms the direct application of vanilla LLMs, achieving an average completion rate of 74.07% % (t 45.92%) for migration tasks. Additionally, the average number of queries to LLMs is only 2.26(t 0.26), indicating no substantial increase in computational overhead. Mcanwhile, MIGGPT required only 2.08% % of the average time taken by human experts, demonstrating its superior time efficiency.
In summary, we make the following contributions:
We have developed robust migration benchmark, encompassing three real-world projects. To the best of our knowledge, this is the first benchmark for out-of-tree kernel patch migration that can assess performance across diverse migration tools, providing a valuable foundation for future research.
We propose CFP, a carefully designed data structure that encapsulates the structural and critical information of code snippets, providing essential migration context for LLMs. Based

---

on this, we introduce MIGGPT, a framework to assist humans in automating out-of tit-of-tree kernel patch migration and maintenance.
We conduct comprehensive experiments on both closed-source models (i.e. GPT-3.5, GPT-4 and OpenAI-ol) and open-source models (i.e. DeepSeek- V3, Deepseek-RI, and Llama- 3.1). The results demonstrate that MIGGPT achieved an average migration accuracy of 74.07%( 45.92%), representing significant improvement over vanilla L.Mss.
2 Related Work
2.1 Code Migration Kernel Patch
Existing code migration 9
37 technologies primarily focus API cross-version maintenance
[48]
25 [2 17 47 22
41
10 and the backporting of CVE security patches [45] 43
44
53
The most
similar migration efforts, FixMorph [43] TSBPORT (53), and PPatHF (37. focus CVE patch
or forked code, which cannot be applied to the migration of out-of-tree kernel patch: 1) these methods only partially address out-of-tree kernel patch migration due to the tight coupling between kernel and patch code. They identify vulnerability patterns and apply predefined rules [26) but fail to manage complex changes such as namespace modifications, invocation conflicts, and control/data flow dependencies, limiting their effectiveness in comprehensive migration scenarios. 2) These works handle single-step migration, assuming known target code locations in updated repositories, making them difficult apply to out-of-tree kernel patch scenarios. In contrast, our MIGGPT tackles more complex two-step task: retrieving target code from updated kernels and migrating patches, which both more challenging and more practical.
2.2 LLMs for Coding
In recent years, LLMs
have achieved remarkable progress in various natural language processing tasks. Initially focused on natural language understanding and generation, the adaptability of LLMs has expanded to the field of software engineering, where they can be fine- tuned to perform programming tasks such code completion [38] 19 24 code search [13], code summarization (2), code generation [36], and even complex code repair [15 20). This inspires us to apply LLMs to the migration of out-of-tree kernel patches. To the best of our knowledge, MIGGPT the first work to apply LLMs to this task, paving the way for subsequent research.
42
27
32 28
3 Problem Formulation
Out-of-tree kernel patches lack official support and require manual maintenance to ensure com- patibility with future Linux kernel versions. An example of migration is provided in App. B Let R denote a Linux kernel repository, where E R represents a code snippet within the repos- itory. The older version of Linux kernel Rold. out-of-tree patch, it be-
Table 1: Formalization and counts of the two types of migration examples. Other cases are too simple to necessitate resolution. Details in App. A.2
Class
Formalization
Number
A 7 Ø, Σ Ø, Vo E Σ, (6,0)
80
Type
48
A,
(59.3%)
A Ø Σ Z
55
and after applying comes R'aa- When the kernel advances to new version Reew, the migration problem is to construct a function M R' > ReE where vs Ra (s) E Ryew V.L. E Inputs, Execute (R x)
Type 2
V5 A,
E Σ, (6,0) #
(40.7%)
A
Too simple
Others
A + 2, Σ = Ø
to resolve
Execute RR 2).
4 Migration Benchmark
4.1 Migration Types
We can obtain the code snippets Sola E RoM and 5'id E Ro at the same location in the repository before and after applying the out-of-tree kernel patch, with the differences represented by A. As Roi is updated to new version of the Linux kernel Rnew: we need to locate the corresponding code snippet Snow Raey in the new version of the Linux kernel to obtain the difference information
3

---

during the kernel update. The differences between and Snew are denoted as E. Subsequently, by utilizing the information from A and Σ, we complete the migration task to obtain the new version of the out-of-tree kernel patch code snippet Snow Finally, these code snippets are integrated to form the new version of the out-of-tree kernel patch code repository Rnew.
Considering the states of A and M, we can categorize the migration types into two classes:
Type 1: This type of migration example satisfies A + Ø, Σ o Ø. vo E A, Yo E Σ, (6, 0. This indicates that both the out-of-tree kernel patch and the new version of the Linux kernel have modified the code snippet, and their changes do not affect the same lines of code, meaning the modifications do not overlap or conflict with each other. Traditional methods' limitations with Type 1 are discussed in App. G.I G.I
Type 2: In contrast, this type satisfies A + Ø0 x 23, Vg E A, 3o E E, (6, * 0, indicating that their modifications overlap on the same lines of code, leading to conflicts.
The remaining cases, A and A + Ø, kernel patch and no changes in the new kernel version, respectively. Due to their simplicity and straightforward migration, they are excluded from our benchmark.
Ø, signify no code modification in the out-of-tree
4.2 Benchmark Design
We have built robust migration testing benchmark using out-of tut-of-tree kernel patches from real-world projects, specifically focusing on three open-source initiatives: RT-PREEMPT (21). Raspberry Pi Linux [39] and HAOC [6 More details about these projects are available in App. We collect code from these projects across Linux kernel versions 19, 5.4, 5.10, and 6.6 for our benchmark. The selected kernel versions are officially maintained LTS releases, which are widely adopted in production systems(e.g.. enterprise servers, embedded devices).
Guided by the experience of manually completing the task, we divide the migration task into two steps: 1) Identifying the migration location, i.e., finding Snew 2) Completing the migration obtain deww In this case, firstly, we use the diff command to obtain the code snippets Sold and & from files with the same name in the code repository. Subsequently, by matching filenames, we locate the file in code repository Rnew that contains the target new version code snippet Snew Finally, we gather the ground truth (results manually completed by humans) Snew and Knew Specifically, our benchmark includes a quintuple (sola, d'ad: filenew, Snew, 8new) for each migration example. After filtering out invalid differences (such as spaces, blank lines, file deletions, etc.), we randomly collected 135 migration examples, comprising 80 Type 1 and 55 Type 2, as detailed in Table
MIGGPT
We first outline the challenges faced when utilizing vanilla LLMS for the migration of out-of-tree kernel patches (Section 5.1.. and then discuss how MIGGPT effetvvfley addresses these challenges
(Sections 5.2 to 5.7
5.1 Challenges
Through analyzing LLM behavior and results, we identify key challenges hindering their success in out-of-tree kernel patch migration:
Challenge (Structural Ambiguity): When identifying the code snippet 8new in file for migration, retrieval errors can occur. LLMs often struggle to locate function definitions within Snew due to interference from similar function structures, leading inaccuracies that affect subsequent migration stages. An example is provided in App. C.T
Challenge 2 (Boundary Indeterminacy): This challenge occurs when retrieving Snew from filenew- Due to the inherent randomness in L.LM-generaae responses, discrepancies often arise between the start and end lines of Snew identified by the LLM and those retrieved by human developers ($
2 Even with knowledge of the code in these oft-of-tree kernel patches, LLMs still struggle to accomplish migration and maintenance tasks.

---

Retrieval Augmentation Module
Retrieval Prompl
filenew
Correlation Function
Retrieval Task
Extraction
CFP
Prompe
LLM
CFP Generation
Function Signature
Structure
CFPump
Extraction
Prompt
Sold
Anchor Statement
Alignment
Fail
CFP Generation
Snow
Extraction
Prompt
Expert Persona
Critical Information Check
Pass
Prompe
Retrieval Alignment Module
Simp
Migration Prompt
Migration
LLM
Task Prompt
CFP
Location
Migration Point Localization
CFP Generation
Prompt
Snew
Expert Pensona
Sold
Migration Augmentation Module
Prompt
Figure 2: Overview of MIGGPT. MIGGPT employs code fingerprint (CFP) structure to retain code snippet information, enhanced by three modules to improve migration accuracy and efficiency. The migration process involves two steps: 1) locating the migration position in file,ew find and 2) completing the migration to obtain s'ww.
This indeterminacy can result in missing or extraneous lines, significantly compromising migration outcomes where precise code segment boundaries are critical. An example provided App. | C.2
Challenge 3 (Missing Associated Fragments): This challenge occurs when retrieving 8new from filenew. During Linux kernel upgrades, code blocks from older versions may be split into fragments in the new version for standardization or reuse. LLMs often fail to identify and retrieve all these fragments, leading to incomplete 9aww This results errors during out-of-trec kernel patch migration due to missing code segments. An example is provided in App. C33
Challenge 4 (Ambiguous Migration Points): This challenge arises during the migration of Snew to Seww Although the information provided by Sold and s'd sufficient to accurately infer the migration point, LLMs frequently fail to precisely identify these points. This ambiguity results in errors when determining the correct location for migration. An example is provided in App. C.4
Overall, LLMs require migration-relevant code structure information and code scope constraints to more effectively migrate and maintain out-of-tree kernel patches.
5.2
Overview
5.3
Code Fingerprint
To this end, we propose MIGGPT, a framework combin- ing traditional program analysis with LLMs facilitate out-of-tree kernel patch migration across Linux versions. As outlined Section 4 MIGGPT works two stages: identifying target code snippets in the new version and mi- grating the out-of-tree patch. Figure shows its three core modules: the Retrieval Augmentation Module (address- ing Challenges and 3), the Retrieval Alignment Module (addressing Challenge 2), and the Migration Enhance- ment Module (addressing Challenge 4). Each module uses code fingerprint structure, which encodes the struc- tural features of code snippets, to enhance LLM performance and migration accuracy, tackling the challenges discussed earlier.
static local_ scil_daif__re daif_maskint set_mm)
asm volatile( "msr daifset, HOxf"...::
(system nmi())
billit_sstil)
Don't for
trace trace_hardirge hardirqs_off((;:
Figure 3: A code snippet containing inline assembly statements and comment annota- tions.
To address challenges LLMs face migrating out-of-tree kernel patches across Linux kernel versions, detailed analysis of code snippet structure is essential to identify migration-related code structure information and code scope constraints. While tools like Abstract Syntax Tree (AST) are useful for structural analysis, they have limitations: 1) Inability to process code snippets that lack
5

---

complete compilation dependencies (e.g., missing variable or function definitions, absent macro declarations, or incomplete header inclusions) due tight integration with the compilation process. 2) The mismatch between excessive structural details (AST tools provide a plethora of information irrelevant to patch migration) and the absence of critical information (such as comments and inline assembly), which is essential for maintaining and updating kernel patches F Focusing on key statements, such as migration points and alignment positions, while preserving essential elements like comments and inline assembly, can enhance efficiency and reduce overhead in the migration process.
To address the limitations of traditional code structure analysis, we propose Code Finger- print (CFP), lightweight sequential data struc- ture for analyzing code snippets. CFP records both the content and positional information for each line of statements, encompassing all C lan- guage statements, including comments and in- line assembly (a detailed example is provided in App. D.I.. As shown Figure 4 CFP fo- cuses recording function definitions and func- tion calls, which are crucial for addressing chal- lenges and 3, detailed in Section [5.4 Ad- ditionally, its linear structure facilitates accu- rate positioning for insertion, deletion, and other update operations, tackling challenges 2 and 4, further explained in Sections 5.5 and [.6] The algorithm for generating CFP is in App. D.5] Overall, CFP offers three key advantages: 1) ef- fective processing of incomplete code snippets. 2) preservation of critical information such as comments and inline assembly, which are vital for out-of-tree kernel patch migration, and 3) a streamlined design that focuses on essential statements, improving migration efficiency and reducing overhead. CFP is specifically designed for out-of-tree kernel patch code, addressing the challenges encountered in Linux kernel patches. More discussions about CFP are in App. G.2, By minimizing unnecessary processing while ensuring relevance, CFP provides a targeted solution for migrating out-of-tree kernel patches across Linux kernel versions.
Delikte
Pareniter
Nare
Bodyy
Moditar
lcars
lesal eal: eui
ranic ihe
vid
Neww
Type
Connent
Thas
AST:
Information Overload, Comples, Tree Structure.
Cal
Cill
Nete
Arpanize
Nasc
Arpanas
ailtua
Tacis Defatica
Amn
I
Cantent
Tax
Fi
I
lile Scatl
CFP:
Key Information,
mi
Lightweight,
Sequential Structure.
Compared AST, CFP extracts key code structures, and its linear representation enables clearer localization of code modification points.
Figure 4:
5.4 Retrieval Augmentation Module
The retrieval augmentation module is designed to address challenge 1 and challenge 3 encountered during the migration update of out-of-tree kernel patches by LLMs. In challenge 1, LLMs are prone to be misled by similar function structure when processing function definitions in code snippets, leading to incorrect retrieval of snow in filcnew, which ultimately results in erroneous migrated s' To overcome this challenge, it is necessary to constrain the LLM's attention to the target code snippet. As illustrated in Figure the retricval augmentation module achieves this by constructing a code fingerprint structure (CFPata) for the old version of the Linux kernel code snippets Sald- By analyzing CFPola the module extracts the function signatures of the function definitions contained within Sold- These function signatures then used to build a prompt to describe the structure information ("Structure Prompt"), ) which is incorporated into the input fed to the LLM. An example is provided in the App. D.2
On the other hand, challenge highlights that during the migration update out-of-tree kernel patches by LLMs, there is an issue with missing associated functions. For the LLM's 's temporary retrieval result Sup. we utilize the code fingerprint structures CFP and CFP of Sump and Sold, respectively, and extract from them the sets of internally called associated functions, denoted as Fup and Fou- Then, using string matching techniques, we retrieve from filc the code snippets corresponding to the associated function calls Funccall that satisfy Funccall Fump \ Fuls. Ultimately, these associated function code snippets are combined with Sump to form the complete code snippet Spow- An example is provided in the App. D.2
'Iliine assembly is widely used in the Linux kernel, and comments are crucial for future module development. their omission would hinder subsequent modifications.

---

5.5 Retrieval Alignment Module
The retrieval alignment module is devised to tackle challenge 2, which was encountered during the migration update of out-of- kernel patches by LLMs. Challenge 2 indicates that when the LLM retrieves the target code snippet Snew from the new version of the Linux kernel file filenew: there can be mismatch between the boundary line of 8new- To address this issue, we need to leverage the information from the first and last lines of the old version code snippet Sold to aid in the localization during the retrieval of Snew- As illustrated in Figure 2 we utilize the code fingerprint structure CFP old of Sold. By taking advantage of its linear structure, we obtain the CFP statements for the first and last lines. These statements are used to construct an "Alignment Prompt", which describes the information of the first and last lines and is included as part of the input to the LLM. This prompt guides the LLM in performing the retrieval task better by accurately identifying the boundaries of the code snippet.
5.6 Migration Augmentation Module
The migration augmentation module is primarily designed to address challenge 4 encountered by LLMs during the migration of new-version Linux kernel code snippets Snew into the final updated out- of-tree kernel patch n'ww In challenge 4, LLMs often struggle to accurately identify the number and location of migration points, leading to errors in the final migrated show- As illustrated in Figure to tackle this challenge, we leverage information from the old version code snippet Sold and its modified counterpart Saa determine the number and location of modifications made the out-of-tree kernel patch. This information is used to construct a "Location Prompt" that assists the LLM in accurately identifying the number and location of migration points. An example is provided in the App. D.3
5.7
Implementation
With the critical code information provided by CFP, we can leverage the Retrieval Augmentation Module and the Retrieval Alignment Module assist LLMs in more effectively identifying target kernel code snippets Snew. Subsequently, with the aid of the Migration Augmentation Module, we facilitate the migration to generate the final code snippet s'ew. All the prompts and the algorithm of MIGGPT are provided in App. D.4
As illustrated in Figure [ first need to retrieve code snippet Snow from filenew-- Specifically, using the information contained within CFPold, we can extract set of critical function signatures S and set of key anchor statements A. With this information, we construct the Structure and Alignment Prompl, ultimately forming the complete Retrieval
We then query LLMs using the Retrieval Prompt obtain an initial result Sup.. We check if Sump contains items from the target function signature set S. If not, we repeatedly query the LLMs using the RetrievalPrompp (up to m times). If it does contain items from S, we use CFPodd and CFPtmp to extract newly appeared called functions within Simp and retrieve the code snippets where these called functions are defined from filenew as additional supplementary information for Sump- Finally, we concatenate these two parts of the code snippets to obtain Snew. After obtaining Snew. we proceed to migrate it to achieve S'ew We utilize the differences between CFP and CFP ald to extract the number and positions of migration points and generate the Location Prompt. Further, we formulate the M Migration Picioomroooo Prompt and query the LLM to obtain the migrated out-of-tree kernel patch code snippet S'ow.
Evaluation
In this section, we assess the performance of MIGGPT, focusing on the following questions: RQ1 (Performance): How does the performance of MIGGPT compare with that of vanilla LLM? RQ2 (Ablation): How does each module within MIGGPT contribute to the overall performance? RQ3 (Failure Analysis): How much modification is required for MIGGPT's failed example to align with human-level performance in out-of-tree patch migration tasks?
6.1 Evaluation Settings
We assess MIGGPT using two benchmarks: the out-of-tree kernel patch migration benchmark from Section 4 and FixMorph's CVE patch backporting benchmark [33, which includes 350 in- stances. For baselines, we use vanilla LLMs, including GPT-3.5 [3], GPT-4-turbo (34], OpenAl-
7

---

Table 2: The accuracy of the MicGPT-angmented LLMs compared to vanilla LLMs retrieving target code
snippets.
12M
Masted
Bea Maach
Senseric Masch
Epe Tiffi
Heraa Maxh
Macc
Serrarti March
5pe T:15
Earrn March
Bea March
Seruento March
All 11111
Herras Mash
Query Times
Avergee
27.27%
31.37%
68.75%
795
71.35%
61 61.355
14,11G
65:976
67
11.116
Vazila
00/87%
07. 07.50%
65.0%
00.09%
76,35%
78 3.184
63.70%
7L.15%
75337
1100
MicUPT
01.25%
05.177
95.256
61.529
$3.455
20.091
$1419
00.2%
03-37%
1.16
Operstiol
Vanta
96.258
51325
35455
02739
73:226
33.707
Dec N3
MisGPT
Vanil
07.975
71284
05.05
12.97
05.07%
78.05
89 1W
164
19ATS
87.415
2000
02.49%
70315
1.22
100
Deepbeck-Rt
Vania
7137%
77375
53395
20075
110
Liana 3.1-88
MicGPT
71.00%
50.00%
41.55
81.25%
70.19
74,556
4545
78 155
1481
1002
77.79%
80006
1.36
Vasila
58.758
051075
63.25 252
61
72.756
25.559
50006
08.15%
65.156
100
$66676
Anerae
MIGGPT
97.30%
88,05%
76.25%
V2.225
78.13%
84. 59.199
$3.00%
54.55%
$7.32%
1.26
+15.00
+18.709
+12.50
+16.005
+35.49
-30.555
+33.8
Table 3: The accuracy of the MiGGPT-angmented LLMs compared vanilla LLMs on the migration task of target code snippets.
LLM
Michal
Best Musc
Sersance Mutch
Type I 1899
Human March
Best March
Semaatic Mutch
Type (4-))
Haman Masch
Best Match
Semantic Match
All (T35)
Homan Musch
OPE-3
MiGdPT
Vanilaa
7,505
5200%
46.2693
47.50%
K
$8.18%
1,645
41.82%
33555
61.32%
5,25%
57.3076
5.97%
4.1355
55.3398
7.41%
GPT
MioRiPT
Vanilla
$2.506
12,50%
18.75%
10.01%
30.955
23,64/
13:335%
20.00%
7N.528
20.74%%
OpenAA-1
MiGUPT
90.099
60.00%
76.366
70.37%
84.44%
65.70%
DrepSook-VS V3
MiGGPT
Vanilla
81.35%
88 79759
37.305
87.50%
65.49%
34.5%
513355
78.185
74.5%%
281159
14316
84.44%
82 2353
391 2075
DeepSock R1
MidtPT
Vanilla
53.75%6
72
15 800
60,02%
81,25%
62.50%
40000%
09/M5
54.359
81.826
$6.369
7K.199
48.15%
71.01
37.78%
50,00%
[Jans 1-18
MInGPT
Vanilla
$5.88
S1972
66 029
12307
67.50 505
R5,558
25.45%
175
$2.715
252154
56. 1/6
11 1.85%
1505
60.005
153055
42 901
201174
L.170-311-70
MIGGPT
Vanilla
62.50%
3.75%
80005
16.255
81.25%
18.75%
47.27%
7.27%5
67.27%
27.275
23264%
72.758
56.30%
5.19%
207445
74.8155
77.755
20.74%
Vanilla
15.99%
26.795
10.364
31.995
30.15%
1737%
27.135
15.555
Avanaee
MiGGPT
76.785
51.43%
67.796
69.61%
57.88%
73.12%
74.07%
0l 35), DeepSeek- V2.5 77 DeepSeek-V3 8 Deepseek-R1 6. L.aam-3.1-88 and Llama-3.1-70B:
Instruct [II. as they are widely recognized for their advanced performance, along with previous migration efforts like FixMorph 43 TSBPORT (53] and PPatHF (37) Evaluation metrics include "best match" (exact code similarity after removing spaces, line breaks, and tab characters), "semantic match" (CodeBLEU with a 0.9 threshold for binary classification, detailed in App. (.6) [40), and
"human match" (developer-judge) functional equivalence, detailed in App. F3 We also considered the compilation success rate, as detailed in App. F.4 The hyperparameter m set to 3.
For each sample (Sold: s''s:: file Snew, (eww in our benchmark, we evaluate vanilla LLMs using two distinct strategies: One-step Strategy: The LLM directly generates the migrated code snippet 8 by taking the triplet (Sold, dald filenew) as input. Two-step Strategy: The process is divided into two phases. First, the LLM identifies the corresponding new version code snippet 8new using the pair (Sola; filenew). ). Then, the LLM generates nnow by taking the triplet (Sold, Saaa Snew) as input.
6.2 Performance Evaluation (RQ1)
MIGGPT demonstrates exceptional capabil- ity in retrieving target code snippets. As shown in Table? 2, MIGGPT exhibits signifi- cant advantage in the subtask of retrieving target code. Specifically, when paired with high- performance L.M like GPT-4-turbo, MIGGPT achieves human matching precision of 96.25% for Type 1 samples, significantly outperform- ing standalone GPT-4-turbo (65.00%) Overall, MIGGPT attains an average semantic match- ing precision of 84.55% across all sample types, marking a 20.53% relative improvement.
Ohn-stop
Ona-siop
GPT-335
Aceway
40
10
1ype
Type
All
Type Type
All
Show
Retrioval
Migration
Figure 5: The semantic match accuracy of the target code snippets retrieval task and the target code snippets migration task across various LLMss "Onc-step" indi- cates the direct utilization of an LLM to complete the migration task in single step.
MIGGPT demonstrates outstanding perfor- mance generating migrated code snippets. As shown in Table 3 MIGGPT outperforms vanilla I.MMs, achieving 73. 12% higher average migration semantic matching precision, a 45.61 % relative improvement. Notably, due to Llama-3, 3.1-8B 's weak base performance, MigGPPTaugmented
8

---

Llama-3.1-8B underperforms- yet still achieves 44.44% higher semantic matching precision than vanilla Llama-3.1-8B Additional results for other LLMs are provided in App. E
The two-step strategy outperforms the one-step strategy. We compared GPT-3.5 and GPT-4- turbo using both one-step and two-step strategies to investigate the impact of task complexity on migration performance. As illustrated in Figure | when vanilla LLMs are employed, the two-step strategy achieves average migration accuracy of 12.22% across all sample types, repreenting an improvement of 8.89% over the one-step strategy's 's accuracy of 3.33%.
MIGGPT performs well on compilation-Ievel metric. We conducted additional compilation success rate experiments on migrated patches.
Table 4: The compilation success rate MIGGPT com- pared vanilla LLMs.
As shown in Table 4 MigGPT achieves 48.49% average improvement in compilation success rate over vanilla L.Mss.
Method
Vanilla
GPT-4-turbo
MIGGPT
Vanilla 31.85%
DeepSeck-V3
MiGGPT
Rate
16.30%
66.67% (+50.37%)
79.26% (+47.441%)
MIGGPT outperformed previous migration efforts on the CVE patch backporting task. We also evaluate the performance of MIGGPT in the context of CVE patch backporting. No- tably, our out-of-tree patch migration task is different from FixMorph, TSBPORT, and PPatHF, which only solve the migration problem, while we target both target code retrieval and migration. As illustrated in Table [] MIGGPT demonstrates superior performance compared to previous patch backporting methods.
Table 5: The semantic match accuracy of MIGGPT compared to patch backporting methods.
Method
Fichtturu
TSPPORT
PPuSEF
vasilla
GPE turbo
MIGGPT
vunilla MIGGPT 97.12%
DeepSees V3
24.6398
$7.59%
75.12%
91.78%
92.59%
MIGGPT performs well on the Linux driver migration task. We conducted experiments to assess MIGGPT's performance driver migration. We randomly collected 24 driver migration samples. The results, presented in the Table 6 indicate that MIGGPT performs well in migrating patches involving driver interface modifications.
Table 6: The accuracy of MIGGPT compared to vanilla LLM on the Linux driver migration task.
the Linux
Method
Vanilla
GPT-4-urbo
MIGGPT
Vanilla
DeepSeek V3
MioGPT
Best Mutch
54.16%
83.39% (429 1798)
58.199
79 169 (4201855)
Semantic Match
62.50%
83.33% (+20.896)
62.50%
87.50% (+25,0016)
MIGGPT demonstrates cross-language gen- eralizability. We conducted an experiment fo- cusing on Python code migration. We randomly selected 31 migration examples from our bench- mark and translated them to Python. With only minor adjustments (modify the implementation of the statement tokenization and statement element extraction functions to adapt the CFP for Python syntax) MIGGPT can process these Python examples. The results of Table 7 demonstrate that the average semantic match performance improved by 16. 16.1% compared to vanilla approach, indicating MIGGPT's effectiveness beyond C-language code. We also discuss the generalization of MIGGPT in App. G.3
Table 7: The accuracy of MIGGPT compared to vanilla LLM on Python code migration task.
Method
Vanilla
GPT-4-turbo
MirGPT
DeepSeek--3 V/3
MiGGPT
Best Match
61.29%
50065% (+19 (+193669)
64.52%
83.8%% (+19,3598)
Semaniic Match
70.97%
$7.10% (-16.138)
90.32% (+16.139)
MIGGPT more time-efficient. We com- pared MIGGPT with three human experts experts.
Table 8: The time cost of MIGGPT compared to human
our out-of-tree patch migration benchmark. As shown in Table g MIGGPT required only 2.08% of the average time taken by human ex- perts, demonstrating its superior time efficiency.
Method
Expert A
Export
Expert
GPT-4-trbb
MiGGPT
DeepSeck-3
Time (days)
14.15
10.89
12.51
0.25
6.3 Ablation Study (RQ2)
6.4 Ablation Study
We conduct an ablation study to evaluate the impact of the four units in MIGGPT: CFP, Retrieval Augmentation Module, Retrieval Alignment Module, and Migration Augmentation Module (details in App. F.7. Figure the outcomes of four tested variants on our benchmarks. Among these, MIGGPT consistently outperforms the ablation baselines. Meanwhile, we perform an ablation study on the hyperparameter in Algorithm I with MigGPT-GPT---urbo, which controls the total query time of the Retrieval Augmentation Module, As shown in Figure 5 m = 3 is suitable for both Type and Type 2 examples.

---

Mighi Fig bericul hegeneutio C1P
Magcort
90
Megifine Mipuato degaematin
70
Type 1spe
90
51.
WIB
1ype
Type 2
All
Tyne
Type 2
All
Reew Retrieval Figure 6: Left: The accuracy of different variants of MIGGPT. Right: The best match retricval accuracy of different m.
%oew
Migration
Failure Analysis (RQ3)
We evaluate MIGGPT's robustness by analyz- ing failed migration cases (not human-matched) across various samples, measuring line edit dis- tances (insertions, deletions, modifications) be- tween MIGGPT's incorrect outputs and human- corrected results (see App. F.5). As shown in Table 9 41 % of MIGGPT'S errors require fewer than three lines of modification to align with correct results, demonstrating its potential aid in out-of-tree kernel patch migration.
Table 9: The line edit distance between the failure cases of MIGGPT-aaumenter GPT-4-Turbo and the manual
migration results. "3 < dis 6" denotes a line edit
distance of at least but less than 6.
TLM GPE33.5
Type
dis < 3 dis <6 6S dis < 9 9 dis
All
Type
13
Type2
8
21
Type
12
Type
7
17
DeepSeck V2.5
Type
10
16
Type
16
DeepSeck-V3
Type
10
Type
our in-depth analysis of "human match" er- rors in MiGGPT-augmente GPT-4-turbo, we identified the following primary categories:
Incomplete Snew Retrieval for Large Codebases (31.03%): In some instances, when retriev- ing Snew from file,ew- the target code Snew was significantly large (exceeding 150 lines), leading incomplete retrieval. This could be due LLMs' tendency shift attention when dealing with long contexts.
Deviation from the Migration Point in Shew Generation (24.14%): Even with precise migration point information provided by CFP, the LLM occasionally failed to strictly adhere to these locations during Snew generation. While minor offsets often didn't 't impact functionality, they sometimes led to functional errors in code with complex control or data flows. This behavior appears to be related to the inherent randomness of LLMs.
Difficulty in Fusing Divergent Changes in Type Migrations (27.59%): For certain Type 2 migrations, significant differences between 8new and Sold's 's modifications to sold prevented the LLM from correctly integrating these changes, resulting in errors. This limitation points challenges related the LLM's code comprehension and manipulation capabilities.
Miscellaneous (17.24%): Errors symbols, statements, etc., appearing Snewe such as incorrectly writing verbose (env, off, size, reg's id) instead of verbose (env, off, size, reg->id). This may be related L.M hallucinations.
It's important to note that these identified failure modes primarily arise from the inherent limitations of the LLMs themselves, rather than architectural flaws within the MigGPT framework.
Conclusion
This study explores the migration of out-of- tree kernel patches in the Linux kernel across versions. Our proposed benchmark reveals that LLMS struggle with incomplete code context understanding and inaccurate migration point identification. To address these issues, we propose MIGGPT, an automated tool for migrating Linux kernel downstream patches. Our evaluation highlights MIGGPT's effectiveness and potential to advance this field.
10

---

Acknowledgments and Disclosure of Funding
This work is partially supported by the Strategic Priority Research Program of the Chinese Academy of Sciences (Grants No. XDB0660000,,, XDB0660301, XDB0660302), Science and Technology Major Special Program of Jiangsu (Grant No. BG2024028). the NSF of China (Grants No. U22A2028, 62302483, 6240073476), CAS Project for Young Scientists in Basic Research (YSBR-029) and Youth Innovation Promotion Association CAS, This work is also supported by NSFC-92467102.
References
[1] George K. Adam. Real-time performance and response latency measurements of linux kernlss on single-board computers. Comput., 10(5):64, 2021.
[2] Toufique Ahmed and Premkumar T. Devanbu. Fhw-shot training Ilms for project-specific code-summarizattoo. In ASE, pages 177:1-177:5, ACM, 2022.
[3] Huilai Chen, Yuanbo Wen, Limin Cheng, Shouxu Kuang, Yumeng Liu, Weijia Li, Ling Li, Rui Zhang, Xinkai Song, Wei Li, Qi Guo, and Yunji Chen. Autoos: Make your OS more powerful by exploiting large language models. In ICMI.. OpenReview.net, 2024.
[4] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Pondé de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray. Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert. Fotios Chantzis, Elizabeth Barnes, Ariel Herbert- Voss. William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Joshua Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojciech Zaremba. Evaluating large language models trained on code. arXiv preprint, WXXv:2107.03377. 2021.
[5] Daniel Bristot de Oliveira, Daniel Casini, and Tommaso Cucinotta. Operating system noise in the linux kernel. IEEE Trans. Computers, 72(1):196-207) 2023.
[6] DeepSeek-AI, Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma. Peiyi Wang, Xiao Bi, Xiaokang Zhang, Xingkai Yu, Yu Wu, Z. F. Wu, Zhibin Gou, Zhihong Shao, Zhuoshu Li, Ziyi Gao, Aixin Liu, Bing Xue, Bingxuan Wang, Bochao Wu, Bei Feng, Chengda Lu, Chenggang Zhao, Chengqi Deng, Chenyu Zhang, Chong Ruan, Damai Dai, Deli Chen, Dongjie Ji, Erhang Li, Fangyun Lin, Fucong Dai, Fuli Luo, Guangbo Hao, Guanting Chen, Guowei Li, H. Zhang, Han Bao, Hanwei Xu, Haocheng Wang, Honghui Ding, Huajian Xin, Huazuo Gao, Hui Qu, Hui Li, Jianzhong Guo, Jiashi Li, Jiawei Wang, Jingchang Chen, Jingyang Yuan, Junjie Qiu, Junlong Li, J. L. Cai, Jiaqi Ni, Jian Liang, Jin Chen, Kai Dong, Kai Hu, Kaige Gao, Kang Guan, Kexin Huang, Kuai Yu, Lean Wang, Lecong Zhang, Liang Zhao, Litong Wang, Liyue Zhang, Lei Xu, Leyi Xia, Mingchuan Zhang, Minghua Zhang, Minghui Tang, Meng Li, Miaojun Wang, Mingming Li, Ning Tian, Panpan Huang, Peng Zhang, Qiancheng Wang, Qinyu Chen, Qiushi Du, Ruiqi Ge, Ruisong Zhang, Ruizhe Pan, Runji Wang. R. J. Chen, R. L. Jin, Ruyi Chen, Shanghao Lu, Shangyan Zhou, Shanhuang Chen, Shengfeng Ye, Shiyu Wang. Shuiping Yu, Shunfeng Zhou, Shuting Pan, and S. S. Li. Deepseek-rl: Incentivizing reasoning capability in llms via reinforcement learning. arXiv, arXiv/2501. 12948, 2025.
[7] DeepSeek-AL, Aixin Liu, Bei Feng, Bin Wang, Bingxuan Wang, Bo Liu, Chenggang Zhao, Chengqi Deng, Chong Ruan, Damai Dai, Daya Guo, Dejian Yang, Deli Chen, Dongjie Ji, Erhang Li, Fangyun Lin, Fuli Luo, Guangbo Hao, Guanting Chen, Guowei Li, Hao Zhang, Hanwei Xu, Hao Yang, Haowei Zhang, Honghui Ding, Huajian Xin, Huazuo Gao, Hui Li. Hui
Qu, J. L. Cai, Jian Liang, Jianzhong Guo, Jiaqi Ni, Jiashi Li, Jin Chen, Jingyang Yuan, Junjie Qiu, Junxiao Song, Kai Dong, Kaige Gao, Kang Guan, Lean Wang, Lecong Zhang, Lei Xu, Leyi Xia, Liang Zhao, Liyue Zhang, Meng Li, Miaojun Wang. Mingchuan Zhang, Minghua Zhang, Minghui Tang, Mingming Li, Ning Tian, Panpan Huang, Peiyi Wang, Peng Zhang, Qihao Zhu,
11

---

Qinyu Chen, Qiushi Du, R. J. Chen, R. L. Jin, Ruiqi Ge, Ruizhe Pan, Runxin Xu, Ruyi Chen, S. S. Li, Shanghao Lu, Shangyan Zhou, Shanhuang Chen, Shaoqing Wu, Shengfeng Ye, Shirong Ma, Shiyu Wang, Shuang Zhou, Shuiping Yu, Shunfeng Zhou, Size Zheng, Tao Wang, Tian Pei, Tian Yuan, Tianyu Sun, W. L. Xiao, Wangding Zeng. Wei An, Wen Liu, Wenfeng Liang, Wenjun Gao, Wentao Zhang, X. Q. Li, Xiangyue Jin, Xianzu Wang, Xiao Bi, Xiaodong Liu, Xiaohan Wang, Xiaojin Shen, Xiaokang Chen, Xiaosha Chen, Xiaotao Nie, and Xiaowen Sun. Deepseek-v2: A strong, economical, and efficient mixture-of-experts language model. arXiv, arXiv/2405.04444 2024.
[8] DeepSeek-AL, Aixin Liu, Bei Feng. Bing Xue. Bingxuan Wang. Bochao Wu, Chengda Lu, Chenggang Zhao, Chengqi Deng, Chenyu Zhang, Chong Ruan, Damai Dai. Daya Guo, Dejian Yang, Deli Chen, Dongjie Ji, Erhang Li, Fangyun Lin, Fucong Dai, Fuli Luo, Guangho Hao, Guanting Chen, Guowei Li, H. Zhang, Han Bao, Hanwei Xu, Haocheng Wang, Haowei Zhang, Honghui Ding, Huajian Xin, Huazuo Gao, Hui Li, Hui Qu, J. L. Cai, Jian Liang. Jianzhong Guo, Jiaqi Ni, Jiashi Li, Jiawei Wang. Jin Chen, Jingchang Chen, Jingyang Yuan, Junjie Qiu, Junlong Li, Junxiao Song, Kai Dong, Kai Hu, Kaige Gao, Kang Guan, Kexin Huang, Kuai Yu, Lean Wang. Lecong Zhang, Lei Xu, Leyi Xia, Liang Zhao, Litong Wang. Liyue Zhang, Meng Li, Miaojun Wang. Mingchuan Zhang. Minghua Zhang, Minghui Tang. Mingming Li, Ning Tian, Pampan Huang. Peiyi Wang, Peng Zhang, Qiancheng Wang. Qihao Zhu, Qinyu Chen. Qiushi Du, R. J. Chen, R. L. Jin, Ruiqi Ge. Ruisong Zhang, Ruizhe Pan, Runji Wang. Runxin Xu, Ruoyu Zhang, Ruyi Chen, S. S. Li, Shanghao Lu, Shangyan Zhou, Shanhuang Chen, Shaoqing Wu, Shengfeng Ye, Shengfeng Ye, Shirong Ma, Shiyu Wang, Shuang Zhou, Shuiping Yu, Shunfeng Zhou, Shuting Pan, T. Wang. Tao Yun, Tian Pei, Tianyu Sun, W. L. Xiao, and Wangding Zeng. Deepseek-v3 v3 technical report. arXiv, arXiv/2412.194337 2024.
[9] Malinda Dilhara, Abhiram Bellur, Timofey Bryksin, and Danny Dig. Unprecedented code change automation: The fusion of llms and transformation by example. Proc. ACM Softw. Eng., (FFSE):63165533 2024.
[10] Malinda Dilhara, Danny Dig, and Ameya Ketkar. PYEVOLVE: automating frequent code changes in python ML systems. In ICSE, pages 995-1007. IEEE, 2023.
[11]
Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang. Angela Fan, Anirudh Goyal, Anthony Hartshom, Aobo Yang, Archi Mitra, Archie Sravankumar, Artem Korenev, Arthur Hinsvark, Arun Rao, Aston Zhang, Aurélien Rodriguez, Austen Gregerson, Ava Spataru, Baptiste Rozière, Bethany Biron, Binh Tang, Bobbie Chern, Charlotte Caucheteux, Chaya Nayak, Chloe Bi, Chris Marra, Chris McConnell, Christian Keller, Christophe Touret, Chunyang Wu, Corinne Wong, Cristian Canton Ferrer, Cyrus Nikolaidis, Damien Allonsius, Daniel Song, Danielle Pintz, Danny Livshits, David Esiobu, Dhruv Choudhary, Dhruv Mahajan, Diego Garcia-Olano, Diego Perino. Dicuwke Hupkes, Egor Lakomkin, Ehab AlBadawy, Elina Lobanova, Emily Dinan, Eric Michael Smith, Filip Radenovie, Frank Zhang, Gabriel Synnaeve, Gabrielle Lee, Georgia Lewis Anderson, Graeme Nail, Grégoire Mialon, Guan Pang, Guillem Cucurell, Hailey Nguyen, Hannah Korevaar, Hu Xu, Hugo Touvron, Iliyan Zarov, Imanol Arrieta Ibarra, Isabel M. Kloumann, Ishan Misra, Ivan Evtimov, Jade Copet, Jaewon Lee, Jan Geffert, Jana Vranes, Jason Park, Jay Mahadeokar, Ject Shah, Jelmer van der Linde, Jennifer Billock, Jenny Hong, Jenya Lee, Jeremy Fu, Jianfeng Chi, Jianyu Huang, Jiawen Liu, Jie Wang. Jiecao Yu, Joanna Bitton, Joe Spisak, Jongsoo Park, Joseph Rocca, Joshua Johnstun, Joshua Saxe, Junteng Jia, Kalyan Vasuden Alwala, Kartikeya Upasani, Kate Plawiak, Ke Li, Kenneth Heafield, Kevin Stone, and et al. The lama 3 herd of models. arXiv,, arXiv/2407.21788 2024.
[12] Mattia Fazzini, Qi Xin, and Alessandro Orso. Automated api-usage update for android apps. In ISSTA, pages 204-215. ACM, 2019.
[13] Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, and Ming Zhou. Codebert: A pre-trained model for programming and natural languages. In EMNLP (Findings), volume EMNLP 2020 of Findings ACL, pages 1536-1547. Association for Computational Linguistics, 2020.
[14] Daniel Fried, Armen Aghajanyan, Jessy Lin, Sida Wang, Eric Wallace, Freda Shi, Ruiqi Zhong, Scott Yih, Luke Zettlemoyer, and Mike Lewis. Incoder: A generative model for code infilling and synthesis. In ICLR. OpenReview.net, 2023.
12

---

[15] Michael Fu, Chakkrit Tantibaamthavom, Trung Le, Van Nguyen, and Dinh Q. Phung. Vulrepair: a t5-based automated software vulnerability repair. In ESEC/SIGSOFT FSE, pages 935-947. ACM, 2022.
[16] HAOC. Haoc http:///wtatt..c/./////////////a 0005 has--haoo-keeeel patch 2024.
[17] Stefanus A.
Haryono, Ferdian Thung, Hong Jin Kang. Lucas Serrano, Gilles Muller, Julia Lawall, David Lo, and Lingxiao Jiang. Automatic android deprecated-api usage update by learning from single updated example. In ICPC, pages 401-405. ACM, 2020.
[18] Jie Hu, Qian Zhang, and Heng Yin. Augmenting greybox fuzzing with generative ai. arXiv preprint arXiv:2306.0673 2023.
[19] Maliheh Izadi, Roberta Gismondi, and Georgios Gousios. Codefill: Multi-token code completion by jointly learning from structure and naming sequences. In ICSE, pages 401-412 ACM, 2022.
[20] Kevin Jesse, Toufique Ahmed, Premkumar T. Devanbu, and Emily Morgan. Large language models and simple, stupid bugs. In MSR, pages 563-575. IEEE, 2023.
[21] Linux Kernel. Re-preempt patch. htttps://mirross: kernel//roojects/rtt 2013.
kernel. beeanel.org/puuiee wttp Linux/
[22] Ameya Ketkar, Ali Mesbah, Davood Mazinanian, Danny Dig, and Edward Aftandilian. Type migration in ultra-large-scale codebases. In ICSE, pages 1 1142-1 11331153. IEEE/ / ACM, 2019.
[23] Jungho Kim, Philkyue Shin, Myungsun Kim, and Seongsoo Hong. Memory-aware fair-share scheduling for improved performance isolation in the linux kernel. IEEE Access, 8:98874- 98886, 2020.
[24] Seohyun Kim, Jimman Zhao, Yuchi Tian, and Satish Chandra. Code prediction by feeding trees to transformers. In ICSE, pages 150-162, IEEE, 2021.
[25] Maxime Lamothe, Weiyi Shang, and Tse-Hsun Peter Chen. A3: assisting android API migra- tions using code examples. IEEE Trans. Software Eng., 48(2)4117-411, 2022.
[26] William Landi. Undecidability of static analysis. LOPLAS, 144):233-337, 1992.
[27] Hung Le, Yue Wang, Akhilesh Deepak Gotmare, Silvio Savarese, and Steven Chu-Hong Hoi. Coderl: Mastering code generation through pretrained models and deep reinforcement learning. In NewrlPS, 2022.
(28) Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Marc Marone, Christopher Akiki, Jia Li, Jenny Chim, Qian Liu, Exgenii Zheltonozh- skii, Terry Yue Zhuo, Thomas Wang, Olivier Dehaene, Mishig Davaadorj. Joel Lamy-Poirier, João Monteiro, Olch Shliazhko, Nicolas Gontier, Nicholas Meade, Armel Zebaze, Ming-Ho Yee, Logesh Kumar Umapathi, Jian Zhu, Benjamin Lipkin, Muhtasham Oblokulov, Zhiruo Wang, Rudra Murthy V. Jason Stillerman, Siva Sankalp Patel, Dmitry Abulkhanov, Marco Zocca, Manan Dey, Zhihan Zhang, Nour Moustafa-Fahmn, Urvashi Bhattacharyya, Wenhao Yu, Swayam Singh, Sasha Luccioni, Paulo Villegas, Maxim Kunakov, Fedor Zhdanov. Manuel Romero, Tony Lee, Nadav Timor, Jennifer Ding, Claire Schlesinger, Hailey Schoelkopf, Jan Ebert, Tri Dao, Mayank Mishra, Alex Gu, Jennifer Robinson, Carolyn Jane Anderson, Brendan Dolan-Gavitt, Danish Contractor, Siva Reddy, Daniel Fried, Dzmitry Bahdanau, Yacine Jernite, Carlos Muñoz Ferrandis, Sean Hughes, Thomas Wolf, Arjun Guha, Leandro von Werra, and Harm de Vries. Starcoder: may the source be with you! arXiv preprint, arXiv:2305.06: 06661, 2023.
[29] Hongyu Lin, Yuchen Li, Haoran Luo, Kaichun Yao, Libo Zhang, Mingjie Xing, and Yanjun Wu. Byos: Knowledge-driven large language models bring your own operating system more excellent. arXiv preprint arXiv:2503. 09663, 2025.
[30] Zhenpeng Lin, Yuhang Wu, and Xinyu Xing. Dirtycred: Escalating privilege linux kernel. In CCS, pages 1963-1976. ACM, 2022.
13

---

[31] Na Meng, Miryung Kim, and Kathryn S. McKinley. Systematic editing: generating program transformations from an example. PLDI, pages 329-342. ACM, 2011.
[32] Erik Nijkamp, Bo Pang. Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. Codegen: An open large language model for code with multi-tum program synthesis. In ICLR, 2023.
[33] OpenAl. Chatgpt, 2023. 2023.
[34] OpenAl. GPT-4 technical report. arXiv preprint, arXiv:2303.08774 2023.
[35] OpenAl. Openai-ol, 2024. 2024.
[36] Shuyin Ouyang, Jie M. Zhang, Mark Harman, and Meng Wang. LLM like box of chocolates: the non-determinism of chatgpt in code generation. arXiv preprint, arXiv:2308.0253 2023.
[37] Shengyi Pan, You Wang, Zhongxin Liu, Xing Hu, Xin Xia, and Shanping Li. Automating zero-shot patch porting for hard forks. In ISSTA, pages 363-375. ACM, 2024.
[38] Ajay Patel, Bryan Li, Mohammad Sadegh Rasooli, Noah Constant, Colin Raffel, and Chris Burcc. Bidirectional language models are also few-shot learners. view.net, 2023.
learners, In ICLR. OpenRe-
[39] Raspberry Pi. Raspberry pi linux kernel. httppe//ggtaab.coo//ppppprrppppp
2018.
[40] Shuo Ren, Daya Guo, Shuai Lu, Long Zhou, Shujie Liu, Duyu Tang, Neel Sundaresan, Ming Zhou, Ambrosio Blanco, and Shuai Ma. Codebleu: a method for automatic evaluation of code synthesis. arXiv, arxiv/2009. 2020.
[41] Reudismam Rolim, Gustavo Soares, Loris D'Antoni, Oleksandr Polozov, Sumit Gulwani, Rohit Gheyi, Ryo Suzuki, and Björn Hartmann. Learning syntactic program transformations from examples. In ICSE, pages 404 415. IEEE/ ACM, 2017.
[42] Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, Artyom Kozhevnikov, Ivan Evtimov, Joanna Bitton, Manish Bhatt, Cristian -eeren,Ferrer, Aaron Grattafiori, Wenhan Xiong, Alexandre Défossez, Jade Copet, Faisal Azhar, Hugo Touvron, Louis Martin, Nicolas Usunier, Thomas Scialom, and Gabriel Synnaeve. Code Ilama: Open foundation models for code. arXiv preprint. arXiv:2308. 19500, 2023.
[43] Ridwan Sharifideen, Xiang Gao, Gregory J. Duck, Shin Hwei Tan, Julia Lawall, and Abhik Roychoudhury. Automated patch backporting linux (experience paper). In ISSTA, pages 633-645, ACM, 2021.
[44] Ridwan Salihin Shariffdeen, Shin Hwei Tan, Mingyuan Gao, and Abhik Roychoudhury. Auto- mated patch transplantation. ACM Trans. Softw. Eng. Methodol., 30(1))6:116:36 2021.
[45] Youkun Shi, Yuan Zhang, Tianhan Luo, Xiangyu Mao, Yizzhi Cao, Ziwen Wang, Yudi Zhao, Zongan Huang, and Min Yang. Backporting security patches of web applications: A prototype design and implementation on injection vulnerability patches. USENIX Security Symposium, pages 1993-2010. USENIX Association, 2022.
[46] Xin Tan, Minghui Zhou, and Brian Fitzgerald. Scaling open source communities: an empirical study of the linux kernel. In ICSE, pages 1222-1234. ACM, 2020.
[47] Ferdian Thung, Hong Jin Kang, Lingxiao Jiang, and David Lo. Towards generating transforma- tion rules without examples for android API replacement. In ICSME, pages 213-217. IEEE, 2019.
[48] Zhenchang Xing and Eleni Stroulia. Api-evolution support with diff-catchup. IEEE Trans. Software Eng., 33(12)8818883 2007.
[49] Hanxiang Xu, Wei Ma, Ting Zhou, Yanjie Zhao, Kai Chen, Qiang Hu, Yang Liu, and Haoyu Wang. Ckgfuzzer: Llm-based fuzz. driver generation enhanced by code knowledge graph. In ICSE Companion, pages 243-254. IEEE, 2025.
14

---

[50] Jiali Xu, Mengyao Xie, Chenggang Wu, Yingian Zhang, Qijing Li, Xuan Huang, Yuanming Lai, Yan Kang, Wei Wang. Qiang Wei, and Zhe Wang. PANIC: pan-assisted intra-process memory isolation on ARM. In CCS, pages 919-933. ACM, 2023.
[51] Weixiang Yan, Yuchen Tian, Yunzhe Li, Qian Chen, and Wen Wang. Codetransocean: A comprehensive multilingual benchmark for code translation. In EMNLP (Findings), pages 5067-5089. Association for Computational Linguistics, 2023.
[52] Chenyuan Yang, Zijie Zhao, and Lingming Zhang. Kernllpp: Enhanced kernel fuzzing via large language models. In ASPLOS (2), pages 560-573. ACM, 2025.
[53] Su Yang, Yang Xiao, Zhengzi Xu, Chengyi Sun, Chen Ji, and Yuqing Zhang. Enhancing OSS patch backporting with semantics. In CCS, pages 2366-2380, ACM, 2023.
[54] Zhen Yang. Fang Liu, Zhongxing Yu, Jacky Wai Keung, Jia Li, Shuo Liu, Yifan Hong, Xiaoxue Ma, Zhi Jin, and Ge Li. Exploring and unleashing the power of large language models in 2024.
automated code translation. Proc. ACM Softw. Eng., 1(FSE):1585-11
[55] Xiao Yi, Yuzhou Fang, Daoyuan Wu, and Lingxiao Jiang. Blockscope: Detecting and investi- gating propagated vulnerabilities in forked blockchain projects. In NDSS. The Internet Society, 2023.
[56] Zheng Zhang, Hang Zhang, Zhiyun Qian, and Billy Lau. An investigation of the android kernel patch ecosystem. In USENIX Security Symposium, pages 3649-3666. USENIX Association, 2021.
[57] Jie Zhou, Yufei Du, Zhuojia Shen, Lele Ma, John Criswell, and Robert J. Walls. Silhouette: Efficient protected shadow stacks for embedded systems. In USENIX Security Symposium. pages 1219-1236. USENIX Association, 2020.
15

---

NeurIPS Paper Checklist
The checklist is designed encourage best practices for responsible machine learning research, addressing issues of reproducibility, transparency, research ethics, and societal impact. Do not remove the checklist: The papers not including the checklist will be desk rejected. The checklist should follow the references and follow the (optional) supplemental material. The checklist does NOT count towards the page limit.
Please read the checklist guidelines carefully for information on how to answer these questions. For each question in the checklist:
You should answer [Yes], [No] or [NA].
[NA] means either that the question is Not Applicable for that particular paper or the relevant information is Not Available.
Please provide short (1-2 sentence) justificatin right after your answer (even for NA).
The checklist answers are an integral part of your paper submission. They are visible to the reviewers, area chairs, senior area chairs, and ethics reviewers. You will be asked to also include it (after eventual revisions) with the final version of your paper, and its final version will be published with the paper.
The reviewers of your paper will be asked to use the checklist as one of the factors their evaluation. While "[Yes] is generally preferable to "[No]" ", is perfectly acceptable to answer "[No] pprovided proper justification is given (e.g., "error bars are not reported because would be too computationally expensive" or "we were unable to find the license for the dataset we used"). In general, answering "[No] or "[NA] is not grounds for rejection. While the questions are phrased in binary way, we acknowledge that the true answer is often more nuanced, so please just use your best judgment and write justification to elaborate. All supporting evidence can appear either in the main paper or the supplemental material, provided in appendix. If you answer [Yes] to question, in the justification please point to the section(s) where related material for the question can found.
IMPORTANT, please:
Delete this instruction block, but keep the section heading "NeurIPS Paper Checklist",
Keep the checklist subsection headings, questions/answers and guidelines below.
Do not modify the questions and only use the provided macros for your answers.
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification:
The abstract and/or introduction is clear.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize other settings.
It is fine include aspirational goals as motivation long is clear that these goals are not attained by the paper.
2. Limitations
Question: Does the paper discuss the limitations of the work performed by the authors?
Answer: [Yes]
Justification: For detailed discussion the limitations regarding the generalization capa-
bility of MIGGPT, please see Appendix G.3
16

---

Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create a separate "Limitations" section their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on a few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect on the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution low or images are taken in low lighting. Or speech-to-tex system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairesss.
While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, a worse outcome might be that reviewers discover limitations that aren't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [NA]
Justification: Does not involve theoretical proof.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide short proof sketch to provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
Answer: [Yes]
Justification: We have thoroughly elaborated on the experimental setup details and provided the code in the supplementary materials to facilitate reproducibility.
Guidelines:
The answer NA means that the paper does not include experiments.
17

---

If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is specific model and empirical evaluation, it may be necessary to either make possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
While NeurIPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm. (b) If the contribution is primarily new model architecture, the paper should describe the architecture clearly and fully.
(c) If the contribution is new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g.. with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors welcome describe the particular way they provide for reproducibilityy In the case of closed-source models, it may be that access to the model is limited in some way (e.g., registered users), but it should be possible for other researchers to have some path to reproducing or verifying the results.
5. Open access to data and code
Question: Does the paper provide open access to the data and code, with sufficient instruc- tions to faithfully reproduce the main experimental results, as described in supplemental material?
Answer: [Yes]
Justification: We have thoroughly elaborated on the experimental setup details and provided the data and code in the supplementary materials to facilitate reproducibility.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurlPS code and data submission guidelines (https://nips. cc/
for more details.
While we encourage the release of code and data, we understand that this might not be possible, so "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (c.g., for a new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https
//nips.cc/public/eee.c www.eeddeee.oeuuummmcecomd ssi ssionyolicy) for more details.
The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
18

---

Providing as much information as possible in supplemental material (appended to the paper) recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
Justification: We have provided a comprehensive explanation of the experimental setup details; please refer to the App. For further information.
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to level of detail that is necessary appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, or as supplemental material.
7. Experiment statistical significance
Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Answer: [Yes]
Justification: Refer to the ablation study for details.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by error bars, confi- dence intervals, statistical significance tests, least for the experiments that support the main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g.. Normally distributed errors).
It should be clear whether the error bar is the standard deviation or the standard error of the mean.
OK to report I-sigma error bars, but one should state it. The authors should preferably report a 2-simma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out range (e.g. negative error rates).
If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time exccution) needed to reproduce the experiments?
Question:
Answer: [Yes]
Justification: Refer to the App.
F. Table 1 and Table for details.
Guidelines:
The answer NA means that the paper does include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.
19

---

The paper should provide the amount of compute required for each of the individual experimental runs as well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't make into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics
Answer: [Yes]
Justification: See App. G.6
Guidelines:
The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special circumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g., there a special consid- eration due to laws regulations in their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification:
See App. G.6
Guidelines:
The answer NA means that there no societal impact of the work performed.
If the authors answer NA or No, they should explain why their work has no societal impact why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.
If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition attacks, mechanisms for monitoring misuse, mechanisms to monitor how system learns from feedback over time, improving the efficiency and accessibility ML).
11. Safeguards
Question: Does the paper describe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pretrained language models, image generators, scraped datasets)?
Answer: [NA]
Justification: Our dataset was obtained from open-source channels (See App. A.1 and does not involve any data misuse.
Guidelines:
20

---

The answer NA means that the paper poses no such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards challenging, and many papers do not require this, but encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Question:
Answer: [Yes]
Justification:
All the models and open-source data have been credited.
Guidelines:
The answer NA means that the paper does existing assets.
The authors should cite the original paper that produced the code package or dataset.
The authors should state which version of the asset used and, possible, include URL.
The name of the license (e.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (c.g.. website), the copyright and terms of service of that source should be provided.
If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswi thcode. com datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that re- ce-packaged, both the original license and the license of the derived asset (if it has changed) should be provided. If this information is not available online, the authors are encouraged to reach out to the asset's s creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [Yes]
Justification: Our code and data are provided in an anonymous zip file.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details the dataset/code/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset used.
At submission time, remember to anonymize your assets (if applicable). You can either create anonymized URL or include anonymized zip file.
14. Crowdsourcing and research with human subjects
For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and sereenshots, if applicable, as well details about compensation (if any)?
Question:
Answer: [Yes]
21

---

Justification:
See supplementary materials.
Guidelines:
The answer NA means that the paper does not involve crowdsoureing nor research with
human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included in the main paper.
According to the NeurIPS Code of Ethics, workers involved data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [Yes]
Justification: We disclosed the potential risks to the research participants and signed an agreement with them.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Depending on the country in which research is conducted, IRB approval (or equivalent)
may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
Declaration LLM usage
Question: Does the paper describe the usage of LLMs if it is important, original, non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, formatting purposes and does not impact the core methodology, scientific rigorousness, or originality of the research, declaration is not required.
Answer: [Yes]
Justification: We have provided a detailed description of the LLM usage.
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, or non non-standard components.
Please refer to our LLM policy http://eeerrrrssec/oooot/eeeeeee for what should or should be described.
22

---

A Benchmark
A.1 Collection
The migration examples in our benchmark are derived from three open-source out-of-tree kemne patch projects: RT-PREEMPT [21], HAOC [66,, and Raspberry Pi kernel [39]. RT-PREEMPT enhances the Linux kernel's real-time performance for sensiivve applications like industrial control and robotics. while Raspberry Pi Linux |
enhances
Joferrs a lightweight kernel optimized for embedded systems. HAOC iimpoves improves kernel security through a Stuael"ernell" design, enhancing code behavior, data access, and permission management. These projects are widely adopted in industry and open-source communities, ensuring coverage of critical out-of-tree patch scenarios. Notably, RT- RT-PREEMPT's latest version has been integrated into the mainline Linux kernel for maintenance and no longer exists as out-of-tree kernel patch. However, this does not impede our utilization of it for research on automated migration and maintenance of out-offtree kernel patches.
A.2 Examples of Benchmark
As shown in Table classes:
! we categorized these samples based on the difficulty of migration into two
Type 1: This type of migration example satisfies A + Ø, E o Ø. vo E A, Yo E Σ, (6) = 0. This indicates that both the out-of-tree kernel patch and the new version of the Linux kernel have modified the code snippet, and their changes do not affect the same lines of code, meaning the modifications do not overlap or conflict with each other. As shown in Table for example, Sou introduces additional lines of code the function definition of hisilicon_ 1 1980005_ _eri000__eableeeee__e___ enable in Sald- Conversely, Snew both adds and removes certain lines of code within the same function definition in Sold- However, it is important to note that these modifications do not occur on the same lines of code.
Type 2: This type of migration example satisfics A * Ø, * 2, Vo E A, 30 E (6, * O. This indicates that both the out-of-tree kernel patch and the new version of the Linux kernel have modified the code snippet, and their changes affect the same lines of code, resulting in overlapping modifications that conflict with each other. As illustrated in Table for instance, &la introduces additional lines of code to the function definition of ptep-get _nd___nd_allllll clear in Sold- However, &new refactors the same function definition into two separate function definitions, resulting in overlapping modifications that conflict with each other.
Table 10: Formalization, Counts, and Examples of the Three Types of Migration Example.
Class
Type
Type 2 A x Ø. Σ o C
À + C. Σ + Ø
Formalization
V5 E A. YO
E E. (6,
0
V5 E A. 37 E Σ, (6, + 40
Number
80 (59.3%)
55 (40.7%)
Fooiionn 1990005_ www.iitionnttoooommmmm SCrVCE www.spp_ppppooopo.....
get deadppocc unolgndd long strneee, pir "plegl
Sold aaa
BrrId to rng civel mask A "B TRmmem DDC SHIT:
RiFI CONF IEE
Rypiing Sheer
www.AIIAAALLA...... HAS DACHE JUGG
wleestr Wl SCTTRLFI L Pj:
SITCLLE SHIF]:
pleval Luttoll icc_stt Locgg relocctpppp (leaL
piu.) nett _.
retumn ret.
Boke
tsw CONTEEL PTP
sysrog dwaar.aaaraee Setarrs AI B.TLRC. L
relum JOANE www.o//ooooooooalaaaaaao
statlo plu. get pla Struct unsigned addiess, plo.1 "pos))
atati an Notioo, 190500s wwoteapocnet
arr64 SOU CaCobEIESS U.LSSC
pin i pie- rietechg relonee willtter) Dfj:
COAR wwW.RRAAA HAS EACHE JUCE
arri6, by. Ieg dny and I- BITICRR DC SHIFT
pagi ttw.sattttssccccoeoooooo wttps__ccccc___s__essoeeeee deartie stot.
return pie.
Sold VS Spew
Certe__t_____dddeeeeeeee www.nnndddaannnmnnncoom maak ICIHRI
reg cww.Duge NITCTR
SHIFT)
pou_ ptop_.pe
"plept
sysrgg, dearr wtap:_dddarrsstptocccoooo SETTLLL LUCT, OL.
"BIEEE JLL IDC_RIIT)
add; wttp_________pp____a return pwwpttg mesoodjfppe spa/
contoNi
1
retum p100 get. www.:/pw.......oom deadere addr, ples)
"hups://mirrrrs.cdee hwwp://wwwwwd...ede...e....ee wedg...eneel.rgg/ubbiinnnn hww..kknn.....gpoummn////////eee
s "htpps//gituub.com//// com/ruspherrypi//inxx
23

---

B Examples of Out-of-tree Kernel Patch Migration
As shown in Figure 7 the migration maintenance of am out-of-tree kernel patch requires integrating the modifications from the old version out-of-tree kernel patch and the modifications from the new version Linux kernel to ultimately complete the code snippet for the new version out-of-tree kernel patch.
Liboned LAAA Pww.Orc ACT Tran))
LEAAT SACLITA GATIE
straet tilt camentt
ptrctt carmen
MAYE ON OHOEE Eak-fag RTJTIIDDACE:
Woee, deL EPCO of CIHAAAO)
10
13
MARI
BEONE MULL
locil FLradEe
memtbrrker sarete PWNNLLL resignt, Miboe
vingu Jiry.
activn yemn bustl trer beat miridt
thictie ee bus (reer" tood munr
achve mnn sill "rae'
(a)
(h)
(c)
Figure 7: (a) Old version Linux kernel code snippet, with the green section indicating modifications from the old version oft-of-tree kernel patch; (b) Old version Linux kernel code snippet. with the red and green sections indicating modifications for the new Linux version kernel; (c) New Linux version kernel code snippet, with the green section indicating modifications from the new version out-of-tree kernel patch.
C Examples of Each Challenge
C.1 Challenge 1
static inline vold pmnd free, rth(stract mms, gather *th,
pmd_t "pmdp, unsigned long eddr)
struct pideac pptdose virt, to ptdeanjommpp
pagetable_smi Bacell___________ dioriptdess); thb remormmooocoooo pttssoo_tttssstttt ptdesc);
10
static inline void ste_free__ wwt_tte__rbttttee ribistruct mma mat_gather 'ub,
11
pgtable pta, ansigned long addr)
12
13
struct ptdesc ppddess ptaesspeess//tt
15
pagelable ple dioriptdesc;;
16
fhfsef CONFIG_PTP
otdese/tth, pidesej;
18
Aelse
19
ib_remowe httpo/st__desbbb.ooe podeso);
Rendit
21
Figure migration case for challenge 1. out-of-tree tree kernel patches.
The green code denotes modifications originating from the
In the migration case shown in Figure g we need locate the target code snippet Snew, which defines the function ftt___ffeeeeeeeeeeeeepeee____ett tlb, within the code file filenew of the new Linux kernel version. However, the new version file also contains code snippet --pmd_frre free_free____ee t_t that elosely resembles the target code snippet Ltt_____eeee_______e_______ free_tlb. When LLMs attempt to locate the function
ttapt___ree___e_ee tlb in free_teee tlb. This misidentification leads
filenew, they erroneously retrieve the similar function ______frre______________________ to errors during the migration of the out-of-tree kernel patch code. This issue highlights the challenges faced by L.MMs distinguishing between similar elements within codebases, indicating a need for improved precision in function identification and handling during the migration process.
24

---

oxtern void set pmddpmmssss "pmdp, pmd_1 pmd);
Relse
PicLi reserved deepPss_ dePPTRS__PPPPPR PER_PRS
exdem void wwwwpwr_aglppaaeeeee "Fgdp, pac pgd);
static inline pei_pndjond_ "yendp, p (pnd]
11
Rendif
Figure 9: A migration case for challenge 2. In this migration case Sold modifications originating from the out-of tree kernel patch.
Suew
The green code denotes
statlc inline pte. get and clearjstnuct mm struct "mm, unsigned long addr, pte_t "plep)
contpto. unfoisimm, addr, pien, gerlotepl:
CONFFIG PTP
ptevall: pleval secchhhhhhhhhteeteeeeeeee hwtpcchhggglooppppee...ooo (ptevai pta_1 not -toepttealll
rel:
#elsee
10
retur ptopichgg relaxed]Spte_ vall vattllllllppppppl Bj::
Bendif
12
static plop. and clear(strust
unsigred long address, ple_t "ptep)
Rifdef CONFIO,
plevol. pleval iee, wel_etteegaauaaooooo.. wat___cot___aaaeeeeeeee relaned(ipte__ I "16
pte_val"" ptep), [pteval_tjjj
plc_t phofppevally
Relse plo. pte ptojechggg relaved]Spto, patpp) Hendif
11
page_table Lace__tale__dee watii_/chec__tt_eeeeereeeee poe):
12
return ple;
14
1
15
ptep clear[stnuct
17
unsigned long addr, ple_1 "ptep!
18
[
contote try. unfoidimm, plep, plop gertpteplyy
20
return plep_ pttepp_ee__ameee clesstme sudr, plept:
21
(b)
Figure 10: A migration case challenge 3. (a) The legacy Linux kernel code snippet saa. (b) The updated Linux keree code snippet 8aow The green code denotes modifications originating from the out-of-tree kernel patch.
C.2 Challenge 2
In the migration case shown in Figure 9 we need to locate the target code segment Snow. which encompasses lines to 10, within the code file filcnew of the new Linux kernel version. However, when LLMs perform this task, they only retrieve the code segment from line 7 to line 10. As result, the migrated custom module code exhibits deficiencies due to the missing lines. This issue underscores the limitations of LLMs in accurately identifying precise code segments, suggesting need for enhanced alignment strategies to improve the reliability of migration tasks.
C.3 Challenge 3
As shown in Figure 10 in the legacy Linux kernel code snippet Sald- the function ptep-get_and uut__and_aa clear is defined. In the updated Linux kernel code snippet Snew. this function has been decomposed into two separate definitions: -_ptep_gee ptep-get_and and__cnd_lall The modifications introduced by our out-of-tree kernel patch are located within the definition of the ...tte_get_ance ael_e_l_add_eearrrrr_ee__ function the Snew code snippet. When em- ploying LLMs directly to retrieve 8new from filenew, the L.Mss tend to overlook the definition of --ptep_get, _et_andd____eeeeeeeeeeeeeee and clear, focusing instead on the definition of trep_get_ands ____and__eee____ clear present in the new version code. Consequently, during the subsequent phase of migrating the out-of-tree kerel
and__leerr and
25

---

/" Tall call offset jump
CONFIG, HIVE
IS
SL__ENABLEDCCOEFE.... MABLEDICONFIGAAMMAA BRMGG/_AAAGABBBXEEEXG
mdstine PROLOGUE, OFFSET
Rendil
#define PROLOGUE_ OFFSEET (BTLINSNS + PAC_INSNS 9)
static prolog-nfstruct ctx "ak, bool ahot chpf)
10
11
bonst struct hpt, prnng "prag crx-pprog
12
Aifde CONFIG_HIVE HIVE
const base Opfiz0o4j5P_REG__BAA
14
15
Rendif
idx0
17
18
Figure 11:
migration for challenge The green code denotes modifications originating from the out-of-tree kernel patch.
patch, the correct migration point cannot be identified, leading erroneous migration. This issue highlights the difficulties LLMs face in handling the fragmentation code during version updates, indicating need for improved methods to accurately locate and integrate all relevant code fragments for successful migration
C.4 Challenge 4
As shown in Figure 11 accurately obtain the migrated out-of-tree kernel patch code 'new it is essential to perform two modifications on the new Linux kernel code segment Spow (specifically, adding the code snippet #ifdef CONFIG_HRE HIVE at two locations). However, when LLMs undertake this task, they either misidentify the migration positions or only execute one of the required modifications. This results in the failure of the out-of-tree kernel patch code migration. This issue reveals the limitations of LLMs in interpreting the precise context required for accurate migration, suggesting a need for more refined techniques enhance the models' ability correctly infer migration points based on the given information.
D MIGGPT Modules
D.1 Examples of CFP
Figure [2 illustrates segment of code alongside its corresponding CFP. The CFP sub- statement in the second row of Figure 12 (b), IfdefNode, represents the second line of the code snippet in Figure 12 (a). This indicates an #ifdef statement that spans from
line 2 to line 4 (pos=2, end=4) of the code segment, with the critical identifier being GRM_64_SSAPPER..C BEEEERRUSESSSMMAS MAPS (name=?
D.2 Examples of Retrieval Augmentation Module
The retrieval augmentation module is designed to address challenge and challenge 3.
For challenge 1, we construct a "Structure Prompt" to specify the signatures of the code snippet 8ol- By constructing the code fingerprint structure CFP from as shown in Figure [ we can extract FuncDef statements that contain the code signatures (Figure 13), thereby generating a "Structure Prompt" that describes these signatures. Consequently, the LLM will focus its attention on the function definition __pte_ sppt__free free_ tlb rather than on the similar function definition _mmd_frreee_____p_pppp_______e_e fol_freeetllll This Structure prompt enhances the LLM's ability by providing precise description of the target code, allowing the LLM to focus more accurately on the relevant code snippet and improving the precision of the retrieval.
For challenge we extract the associated function calls of the code snippet to provide comprehensive code context. As shown in Figure 10 (b), when retrieving 8new, the LLM can only find the definition snippet of the function ptep_get _nd_alldd_aa clear (lines 16-21) and overlooks the definition snippet of the internally called function - ppee__ge_aade clear (lines I to 14). To address this challenge,
26

---

We intend to enable IROs #ndde ARML_44__ SWAPPERRUUES, Winclude <las/sehip.h>
#endif
inline local_datt__ mask)/nn setumm))
volatile
"mar datfeer,
11
12
"memory"1 "I:
14
15
Don't care
(eysten_ceess_nggg peee__mii)
17
setint_satjj:
18
(a)
CommencNode(pooe ende sontent-
IndeNNodejposs 2, and name ARM SWA.SARAARRRRR (A__SWAERR_SSSS_NA LSES_MMASS)
3 end-3, contert- /on/stpphhh
FuncDef(poueó, namee"local dail_makk
type-|static;; sstatic; 'niine', 'vidd'
param (aarDeejje 'sen mnt, type-(intp)
ASMNccellpos-9, end-13,
9
contoxt "Ymar dalfset, #0xf "(otsncyy "memory"""
CommencNodsjpop- 16, end-18,
12
content DDn't really care for here
iiNodeipos intine fuccalles
FunoCalllpas 17, end 17, name: "system_usos_mmm)
16
FuncCall(oos- 17, end- 17, namee' slint set?)
pone
name-irace, harrice_hadiigs_oof
(b)
Figure 12: (a) A code snippet. (b) Corresponding CFP of the code snippet.
FuncDelfnamee pho free. rbl, type-[static inline", param-[ VerDedpname= (ypee(stract, immu_ppthhrr', VarUes/name-"pte "pte" (ppetlpttabll__"" VarDeojhame "adar, (Undliged"' long'l)
Figure 13: The CFP statement on line 10 of Figure
necessary to supplement the initially retrieved Sump from filenew with its invoked associated functions, ultimately obtaining complete code snippet Spew It should be noted that the function and_clear often invokes many functions (such as peattte_try_uufftee what require. Therefore, need to
on line 19),
which also appear in Sold (line 4 of Figure T0 (a)) and select only those associated functions that are invoked within Sump but not by Sold to form the complete code snippet Snew-
D.3 Examples of Migration Augmentation Module
The migration augmentation module is primarily designed to address challenge 4. Specifically, as shown in Figure I we conduct comparative analysis between the code fingerprint structures CFP and CFP old of the code snippets to ascertain that there are two primary migration points. The first point is located after the comment statement Tial call offset... and before the macro definition statement #define PROLOGUE, OFFFEE......... The second point is situated after the statement const struct bpf bpf_prog.-. and before the statement const int fdx0=ctx- >idx. By constructing the "Location Prompt", we enable the LLM precisely locate the migration points, thereby successfully completing the task of migrating and maintaining the out-of-tree kernel patch.
D.4 Algorithm and Prompts
Algorithm [ and Algorithm 2 respectively illustrate the specific details of target code snip- pet retrieval and code migration processes. We also present the prompts utilized by MIGGPT. As shown in Figure [4] when retrieving the target code snippet Saow, construct
27

---

Algorithm Retrieval of the target code snippet 8new
1: Input: (Sold; filenew). LLM, and maximum query count
2: Output: Snew
3: Generating CFP form Sold
4: Preparing
5: Preparing "ExpertPersonie Prompt
6: S + Exxtractsignaature((FFPdd
7: StructurePromppt Promptp Prompt(S)
8: A < Extrractanchor(CFPaJJ.
9: AlignmentPromppt +- Prompt(A)
10: Retrieval Rromie +
12: + +.lignment Prompl + StruclurePromppl
11: RetrievalT ask
13: while q <= do
14:
Stmp f
Weeeeeeeealrrooieeeeeeee Sold, file Generating CFP tmp from Stmp
16: if' find(S, Stmp) then
break end if
18:
q 5 1-9+1
20: end while
Fold < Funccall ( (CFP
22: Fimp Funccall imp
Snow Sump
FindCode (Tmpp Fnew; filenow)
24: return 5new
Algorithm 2 Migration of code snippet s'new
1: Input: (Sold, d'ld Snew) and LLM
2: Output: Snew
3: Generating CFPada CFP' old form Sold and s'
4: Preparing MigrationT aask
5: Preparing E'cperPPersonde Prompt
6: P f- Vinpoinn/iiraatioooooooiiiii
CFP)))
7: LocationProniie +- Prompt(P)
8: Migration Migration.Prompt +- MigrationnTsstPrompt
9: #LocationPrompp EaxpertPersomaPromy
10: s new
Prompt, Sold, d' $now)
11: return new
the Retrieval Prompt to query LLMs. Specifically, we employ Task Prompt 1 to de- scribe the task and Expert Persona Prompt standardize the output format of LLMs. Ad- ditionally, StructurePrompt and AlignmentPromppt are used to enhance the retrieval ca- pabilities of the LLMs. When generating the migrated code snippet &'mu. construct the Migration Prompt to query LLMs. Specifically, we utilize Task Prompt to describe the task and Expert Persona Prompt to standardize the output format of the large language model. Additionally, Location Prompt is employed to enhance the migration capabilities of the LLM.
D.5 CFP
Algorithm 3 illlustrates the specific details about generating CFP. The code snippet is tokenized, and nested scopes (e.g., (,), #ifdef /#endif) are identified via bracket matching, Critical symbols (e.g., }. #ifdef, func()) demarcate code blocks. Function calls (e.g., foo()) are detected through pattern matching on token sequences (e.g., identifier followed by (). Associated functions identified by analyzing call statements within code blocks, avoiding call graph construction.
example of step-by-step CFP generation is illustrated in Figure 16
28

---

Algorithm 3 The generation of CFP
1: Input: code snippet
2: Output: CFP,
3: Initialize list CFP:
4: for line in s do
5: Node + AedentifyyTyeelinnee
6: (Node.pos, ..Nee.edd t- IdentifyScopo((me)
7:
if Node E [FuncDef) then
8:
Node.parameter < CFP (IntenalSSatcmmn(((ooot))
9: end if
10: if N Node E {if, else, while, for, do, switch} then
11:
Vode.inline__aeee
+- Funcall (InternalStatemmnnl) (Node))
12: end
13: Node. "ode.content Content(Node)
14:
end for
15: CFP, t CFP, U {Node}
16: return CFP,
Retrieval Tesk Retrieval Prompt knewledge
Migration Prompt
challenge
Migration Prompt: reaching
corteppuudngg codo, hut smmetiaally provided snippet libeld par Given jutt tuga agmmen. enginstes
Liuxx
would be anvilable. of the
now
will the successtul odaptation kemal For will povilz cod: snippets your
pan
idomnty comparing
snippet,
old'
poire your following part (oode Mar] And entire contest available nnew.": joods flle
comeoerrderee semradyy
Veaa) Snipps ormapunding deseloped
kemel lode exipel ppn old' the Linx
purt patchel! stippet, denoted
taa Stuppe part
Structure Prompt appors 'part old eroompsaass defitition fancias [tunget fanctons sigsature of aFP Your
pirpoint mutching code mure the alctifiee firetion defintiooss
Location Prompt: Upon pretininary anilssi aspeuss that (sumber modifccatioss specific
soymert part now within "oo are sokly derived frum 'roue" Avaid condracting filee srippcte by using the function defintiio
ppatt old patched requies modification
mudifization sholld male sinceal afler ihe line amtsining theal location statement CPPaal
past, old-
cnntiniig
lossiio statemeni of CPP og with
Allgnment Prompt: To Dellitate the seuth, you may need to align perr_tww" using the intial [Bead anchor sittemere of (FFas)) and thz firal lic (tsil archor eorumnn of CFPad fron part old
stange being caralysis CfPeu and CPE. on. biy licely ther smilrr aljetmerrs reed to made witiin port nox to montan funciiordit and compatiillyy Given your cttersive knnndrayy experienze this amiid you kindly sacia ganrsinng comresonndng code silppe part new putched developed on part new'?
Expert Persona Prompe You ace expert in Limx Kemnel development and coding. We kindly sak you to respond with Mariddezz-oomm fommrnal string witii sodk blcck that stars and enda with tiple badiickaa ("") The ropprse striely comuis the stemi iial 'part now wihhoo provsing additiondl analycis or usin list store lines ofde..
Expert Persoan Prompe You are expert in Linxx kemel develogiten: and coding We kindly alk you to respadd with Markdown fiematted shing witlin code block the statts and ends with tiple bacatdas (" 1. The respane should stritly contais the ideniiiedd pee: new without proviting adhinual analyss or seing lad stre lincs oste.
Figure 14: The prompts of MIGGPT.
E More Results of MIGGPT
We have also tested the performance of MigGPT on DeepSeek-V22 V2.5 [7), as shown in Table anand and Table 12 MIGGPT outperforms the vanilla LLM.
Table 11: The accuracy of the MrGGPT-angmented LLMs compared to vanilla LLMs on retrieving target code snippets.
11M
Manhel
Bee Match
Semsnic Masch
Harnan Macc
Best March
Semantic Maich
Homas Maich
Soi Masch
Sementic Munch
Huran Muach
Query Times
Vania ModGitt
$1.256
22.30
55395
07797
S1.27%
1300
91.5%
$7.27%
90000
94.31%
94.01%
F Settings
F.1 Platform
Our experiments were conducted on a system equipped with an AMD Ryzen 9 7900X 12-core CPU, 32GB of RAM, running on Ubuntu 22.04.3 LTS.
F.2
Contextual Information
The contextual information given to the LLM is identical for both the "two-step strategy" (baseline vanilla approach Tables T and and the "one-step strategy", so the comparison is fair (details are
shown in Table 13 The contextual information includes the old version code Sold, slolds and the new
29

---

100
CodoBLEU
80
Type
Type
All
Threshold 0.8
Threhhod
Threshold 0.9
Threshold 0.95
40
60
120
Human Match
Figure 15: Comparison of Consistency with Human Match Different Thresholds for CodeBLEU.
Code
Ade
If
Corasare
TracCal
4
pir
intatlee your daitet #bem DopttiLieoooom Jentt
Code
riilic...
tiee Food
cal
wdlp of
CFP:
Key Information, Lightweight.
Sequential Stracture.
Step
Step 2
Slap
Step
Step
Line
musiht srturnt
sa dabet
Cast hame
Duflatiin
Auii
Crennzzi
FreeCal
CFP Node
neme mack
entryy 2fl
Part Code
bille wew. Lalti eer
Erystrnn
FeacCal
CFP Node
pic
Figure 16: An example of step-by-step CFP generation.
version file new As shown in Figure the paper, the "two-step strategy" is clearly superior to the "one-step strategy".
We provided the key migration information extracted by CFP and the code information (Solds slotd- new. c) as context to the "one-step strategy" (One-step + CFP) and compared it with MigGPT (Two- step + CFP). As shown in Table [4] formulating the migration task as two-step process demonstrates performance advantages.
F.3 The Reliability of Human Match
We strictly adhere to defined steps and principles for Human Match testing, ensuring reliable post- migration code functionality verification:
Cross-validation 5 experienced Linux kernel engineers independently validate results.
Triple-blind voting:
Each example is evaluated by 3 randomly assigned engineers.
Criteria: (1) syntactic consistency, which ensures preservation of original patch logic through structural adaptations (e.g.. variable renaming while maintaining control flow); and (2) semantic correctness, verifying functional equivalence between migrated code and human-generated ground truth patches.
30

---

Table 12: The accuracy of the MiGGPT-augmmnted LLMs compared to vanilla LLMs the migration task of target code snippets.
15p 1937
Ispe (53)
(1:5)
Semanti
DeepSeek
90.1%
10.37
Table 13: The contextual information of various methods.
One-step stratogy
Two-step strategy (Vanilla)
One-step stratogy CFP MigGPT (Two-step strategy CFP)
Code Information
CFP Information
Adherence these provisions enhances the reliability and credibility of our Human Match metric, ensuring rigorous alignment with established evaluation standards.
F.4 Compilation Success Rate
We conducted additional compilation success rate experiments on migrated patches. For each migration sample, we replace the generated code with MigGPT into the patched version new kernel in containerized environment and attempt to compile the modified kernel. The compilation success rate the ratio successfully compiled samples to all types of migration examples.
E55
Line Edit Distance
The line edit distance is measure of the difference between two code snippets. It is defined as the minimum number of single-line edit operations (insertions, delctions, substitutions) required to transform one line into another.
Given two code snippets A {ar) /_ and B {by D with line lengths |A| and [ m, the line edit distance D B) be defined recursively as follows:
max(n, m)
min(m, m) = 0,
D(prefi((A,n 1), 1), D(A, prefix( 1)) + 1,
D(A, B)
min
otherwise.
D(prefix(A,) 1), prefix (B, m 1)) I(a,, + bm)
(I)
Where:
1. prefix(A,k)) {ai)/ denotes the first k lines of code snippet A.
2. Ia, * by) is an indicator function that equals if ag * by and otherwise.
3. The three cases in the recursion correspond to:
1) Deletion:
Delete the last line of and compute (prrefix A, B).
2) Insertion:
Insert the last line of B into A and compute ((A, Ar,rixxi BB 1)).
Replace the last line of with the last line B (if they differ) and compute D(pretix(A, 1), prefix B, m 1)).
3) Substitution:
F.6 Threshold of CodeBLEU
an automated metric designed to evaluate the quality of code generation, specifi- cally tailored for tasks involving the generation of programming code. By integrating both syntactic and semantic features of code, CodeBLEU provides similarity score ((0, 1)) between two code snippets. We employ CodeBLEU as measure of "semantic match" and investigate the alignment between CodeBL.EU-basee "semantic matches" and "human matches" across various thresholds. As illustrated in Figure and and Table we identify a threshold of 0.9 as optimal for our proposed bench- mark, ensuring high degree of consistency between "semantic matches" derived from CodeBI.EU and those determined by human evaluation.
CodeBLEU [40
31

---

Table 14: The accuracy of MIGGPT and "One-step + CFP" on the migration task.
Method
Best Match
Semantic Match
One-step + CFP
38.52%
42.96%
MIGGPT
62.96%
80.00%
Table 15: The results of MIGGPT, compared to the ground truth, are presented in terms of the number of correct examples under both CodeBLEU "semantic match" and "human match". Here, "CodcBLEU-00." denotes CodcBLEU classification threshold set 0.8.
Metric
Type
Retrieval
GPT -turoo
Migration
Retrieval
DeepSeck-V2 V2.3
Migration
Retrieval
DeepSeck-V3
Migration
Retrieval
Average
Migration
Type1
77
77
64
76
70
77
Human Match
Type2
49
38
50
39
49
41
49
All
126
106
127
103
125
111
126
107
Typel
78
77
79
77
77
77
78
77
Type2
49
All
124
122
129
125
128
125
127
124
Typel
78
79
70
74
78
CodeBLBU 0.85
Type2
46
50
46
45
49
All
124
112
129
116
127
119
127
116
Typel
CodeBI FU--0.9
Type2
46
42
50
41
51
43
49
42
All
122
105
126
125
Typel
76
57
75
67
76
CodeBLEUU-0.9
Type2
45
38
41
48
All
121
102
127
95
124
108
124
102
F.7
Variant of MIGGPT
implement four variants for the ablation study:
1. MigCPENNo-ReriiallAgggnnnaan
The Retrieval Augmentation Module is deactivated, causing no constraint on the structure of code snippets.
2.
The Retrieval Alignment Module is deactivated, leading the absence descriptions for the starting and ending line information of code snippets.
3. Milt-N--MirraiionAAgmeeennn
The Migration Augmentation Module disabled. The LLMs will not have the assistance of additional analytical information when completing migration tasks.
4. MigGPT-No-CPP CFF: Replace all components of MIGGPT that require CFP participation (including code snippet invocation relationship analysis, anchor function identification, and migration location detection) with implementations utilizing LLMs.
G Discussion
G.1 Type 1 Migration Sample
Traditional methods like FixMorph 43 SyDIT (31], TSBPORT [53] and PPatHF (37 target single- step migration and cannot solve the target code retrieval problem. while MIGGPT tackles both problems, which is harder and more practical. Besides, traditional methods struggle with Type cases due to their reliance on static alignment and predefined transformation rules. As an example shown in Figure 17 when backporting patch that modifies compute sttteststsssssss () in the old keree,, FixMorph relies on static alignment (e.g., matching function names like process _attsssddtaa,, However, since compute _atrteessttttttees () is now standalone function in the new kernel, traditional methods like FixMorph cannot generate transformation rules for the split code structure, as AST differencing assumes code blocks stay within the same function. This illustrates how traditional methods struggle with Type I's non-conflicting but structurally divergent changes.
G.2 CFP and Intermediate Representations
pertinent research question emerges: Could the structural semantics captured through code snip- pet intermediate representations (IR) provide enhanced contextual signals for guiding LLM-based
32

---

void compute_sst statss (...)
vold process, p
void process_datal {
puidate_inputtyy
compute__ster stats();
// Patch modifies this line
compute_siade statss];
// Unmodified line
resulss;::)
res_rest)
}
(a)
(b)
Figure 17: (a) A code snippet of old kernel. (b) The code snippet is refactored into modular functions in the new kernel.
code migration processes? The answer is negative. While IR-based approaches excel at syntax normalization, our CFP method prioritizes two critical requirements for kernel patch migration:
Context Preservation: Kernel patches often contain conditional compilation macros, inline assembly, and annotations stripped during IR generation (e.g.. preprocessing eliminates macros). CFP retains these alongside code structure (function signatures, control-flow anchors) to provide LLMs with full migration context.
Non-Compilable Code Support: Experimental/unmergen patches (e.g., ARM64-specific optimizations) may fail compilation, making IR extraction impossible. CFP operates directly source fragments, even for broken" code in development.
This demonstrates the necessity employing CFP MIGGPT.
G.3
Generalization of MIGGPT
MIGGPT demonstrates innovative advancements through its dual strengths of generalizability and domain-speciff optimization. While initially designed for out-of-tree kernel patches, its core method- ology addresses universal challenges in LLM-based code migration, such as resolving structure conflicts, precisely aligning code boundaries, reconstructing missing context, and establishing mi- gration localization mechanisms, forming a framework extensible to multiple domains (CVE patch forked code porting
(5)). The architecture incorporates its Code Fingerprint structure, which embeds Linux kernel-specific optimizations through preserving inline assembly instructions and kernel macro patterns, interpreting kernel-specific comment conventions, and adapt- ing to coding norms like function chaining. This technical design achieves balance between cross-domain adaptability and deep specialization, with the CFP serving as modular component that enhances Linux kernel patch migration while maintaining the system's 's capacity for expansion into other technical ecosystems. The solution thus enables bidirectional scalability, supporting both horizontal domain transfer and vertical technical refinement.
backporting 43 53
G.4 Structured Analysis of CFP
The high-level idea of using program analysis techniques to create structured representations of code to guide LLMs is an emerging area of research. We have compared MigGPT with existing research in this emerging area. For instance, works such as AutoOS (3) and BYOS 29 utilize heuristic tree structures to assist LLMs in optimizing kernel configurations during the deployment of operating systems. Similarly, LLM-based fuzzing tools [49 18 employ formal templates to guide LLMs in generating more effective test cases. These approaches, much like MigGPT, leverage deterministic information such as trees, graphs, and lists to mitigate the inherent uncertainty and randomness of LLMs. thereby improving performance across various application tasks. However, it's worth noting that the specific deterministic information used and its data structure are often tailored to the particular task hand.
G.S Deprecated System Calls
Once a system call added to the kernel, it's generally supported indefinitely to avoid breaking existing software that relies on it. However, kernels do evolve, introducing new system calls that offer more robust, secure, or efficient functionalities. These new features can, in some cases, functionally supersede older, more limited mechanisms. When patch migration involves new system calls
33

---

introduced in newer kernel version, MigGPT is well-equipped to handle such scenarios. In these cases, the new version target code (snw will contain examples of how the new system call is used. MigGPT can then refer to these usage examples in 8new to complete the migration and generate corresponding patch that aligns with the new API. Certainly, this scenario, migration types can still be categorized according to the rules in Table If the new kernel version and patch modifications don't overlap location, it's Type 1. Otherwise, it's Type 2.
G.6 Impact Statement
This work advances the field of automated software maintenance by introducing MIGGPT, frame- work that leverages LLMs to automate the migration and maintenance of out-of-tree Linux kernel patches. By reducing the manual effort and costs associated with these tasks, our research has the potential improve the efficiency and reliability of software systems, benefiting industries that rely on stable and up-to-date infrastructure.
However, the adoption of such automation tools also raises ethical considerations. For example, automating tasks traditionally performed by specialized engineers may impact job roles, necessitating workforce adaptation. Additionally, the reliance LLMs for critical maintenance tasks requires rigorous validation to ensure accuracy and avoid potential risks to system stability and security.
While primary focus is technical advancements, acknowledge the broader societal im- plications of automating complex engineering processes. This study lays the foundation for future research and encourages ongoing diseussions the responsible use of Al in software maintenance, balancing innovation with ethical considerations.
34


Reviews:
[{"review_id": "jknYZ2exFt", "reviewer": "Reviewer_2EZF", "summary": "This paper introduces MIGGPT, a novel framework designed to automate the challenging task of migrating out-of-tree Linux kernel patches across different kernel versions. The authors identify key failures of vanilla LLMs on this task and propose a multi-stage approach that uses a custom \"Code Fingerprint\" (CFP) representation and three specialized modules to improve code retrieval and patch migration. The framework is evaluated on a new, real-world benchmark, demonstrating significant performance gains over various state-of-the-art LLMs.", "questions": "1. Can more migration scenarios be added, such as complex cases where patches involve changes in driver interfaces and kernel subsystem refactoring?​\n\n2. When the target kernel version is quite different from the original version (such as spanning 5 major versions), will the performance of MIGGPT decline significantly? Is there an incremental migration strategy?​", "limitations": "yes", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "**Strengths**\n1. The paper tackles a highly practical and challenging real-world problem in software engineering. The creation of a new, robust benchmark using patches from well-known projects like RT-PREEMPT and Raspberry Pi Linux is a significant contribution that will benefit future research. \n2. The proposed Code Fingerprint (CFP) is an elegant and well-motivated solution. It pragmatically avoids the rigidity of traditional Intermediate Representations (like ASTs) by handling non-compilable code and preserving kernel-specific information like comments and inline assembly, which are crucial for this task.\n3. The evaluation is comprehensive and convincing. The authors test their framework against a wide array of modern LLMs, employ multiple evaluation metrics including human judgment, and provide a thorough ablation study that validates the contribution of each component of their system. \n\n**Weakness**\n1. The proposed MIGGPT framework is quite complex and heavily engineered for the specific task of Linux kernel patch migration. While effective, its generalizability to other code migration tasks (e.g., in different programming languages) is unclear.\n\n2. The comparison between the proposed \"two-step strategy\" and the \"one-step strategy\" may not be entirely fair. The one-step baseline appears to be a naive, direct query to the LLM. A stronger baseline might involve a more sophisticated one-step prompt that incorporates some of the contextual cues used by MIGGPT, which could provide a more nuanced measure of the framework's benefit.", "was_revised": true, "final_justification": "After carefully reviewing the authors’ rebuttal and experiments on cross-language generalization, the fair “one-step + CFP” vs. “two-step + CFP” comparison, migration scenarios, and multi-version migration strategy, I am more convinced by the technical rigor and theoretical completeness of MIGGPT. I therefore raise my recommendation to **5: Accept**.", "rebuttal": "Thanks for your valuable feedback. We've addressed your comments on MigGPT's generalization, the fairness of the \"one-step strategy\" comparison, additional migration scenarios, and cross-major-version migration. We discussed and supplemented the experiment to address the concern. Please refer to the specific responses below and our rebuttal for more information.\n\n---\n\n**Weakness 1**. Generalization of the Framework\n\nWe thank you for raising an important question about the generalizability of MigGPT to other programming languages migration scenarios or other domains. Below, we have added a new experiment:\n\n- Cross-Language Generalizability: To address the concern about **cross-language generalizability**, we conducted an additional experiment focusing on Python code migration. We randomly selected 31 migration examples from our benchmark and translated them to Python. With only minor adjustments (modify the implementation of the statement tokenization and statement element extraction functions) to adapt the CFP for Python syntax, MigGPT was able to process these examples. The results demonstrate that the average semantic match performance improved by 16.13%. compared to a vanilla approach, indicating MigGPT's effectiveness beyond C-language code.\n\n| LLM | Method | Best Match | Semantic Match |\n| --- | --- | --- | --- |\n| GPT-4-turbo | Vanilla | 61.29% | 70.97% |\n| GPT-4-turbo | MigGPT | 80.65% | 87.10% |\n| DeepSeek-V3 | Vanilla | 64.52 | 74.19% |\n| DeepSeek-V3 | MigGPT | 83.87% | 90.32% |\n- Generalizability to Other Migration Tasks: Our original submission already showcased MigGPT's applicability to **other code migration tasks**. As presented in **Table 5** of our paper, MigGPT was successfully applied to the **CVE patch backporting** task (migrating a CVE patch from the version where the CVE was discovered to an older version). In this task, we only need to modify MigGPT's task prompt (to describe the details of the CVE patch backporting task); no modifications are required for the CFP. The results demonstrate MigGPT's superior performance compared to existing methods in this different migration scenario.\n\n---\n\n**Weakness 2.** Misunderstanding of the \"One-step Strategy”\n\nApologize for the confusion, but we want to clarify that the contextual information given to the LLM is **identical for both the \"two-step strategy\"** (baseline vanilla approach in Tables 2 and 3)  **and the \"one-step strategy\", so the comparison is fair** (details are shown in the table below). The contextual information includes the **old version code** `s_old` , `s'_old` and the **new version file** `new.c`. As shown in Figure 5 of the paper, the \"two-step strategy\" is clearly superior to the \"one-step strategy\".\n\n| Context | One-step strategy | Two-step strategy (Vanilla) | One-step strategy + CFP | MigGPT (Two-step strategy + CFP) |\n| --- | --- | --- | --- | --- |\n| Code Information | ✔ | ✔ | ✔ | ✔ |\n| CFP Information | ✘ | ✘ | ✔ | ✔ |\n\nTo further address your concerns, we provided the key migration information extracted by CFP and the code information (`s_old` , `s'_old`, `new.c`) as context to the \"one-step strategy\" (One-step + CFP) and compared it with MigGPT (Two-step + CFP). As shown in the table below, formulating the migration task as a two-step process demonstrates performance advantages.\n\n|  | Best Match | Semantic Match |\n| --- | --- | --- |\n| One-step + CFP | 38.52% | 42.96% |\n| MigGPT | 62.96% | 80.00% |\n\nWe recognize we didn't make this clear enough in the current paper, which likely led to this misunderstanding. We'll **revise the manuscript to explicitly emphasize this alignment of contextual information** for both strategies, ensuring readers fully understand the fairness of our comparison and our framework's true impact. Thanks for your valuable comment.\n\n---\n\n**Question 1.** More Migration Scenarios\n\nWe appreciate the reviewer's insightful question regarding more complex migration scenarios. Kernel subsystem refactoring: Indeed, our experiments already encompass kernel subsystem refactoring. For instance, our benchmarks include significant memory management subsystem changes, such as the introduction of folio and enhancements to io_uring. We also cover the process management subsystem's shift from CFS to EEVDF. These cases demonstrate our approach's effectiveness in handling substantial internal kernel restructuring. \n\nDriver interfaces: While our paper primarily focuses on out-of-tree patch migration, we've conducted supplementary experiments to assess MigGPT's performance on these cases and address your concerns. We randomly collected 24 driver migration samples. The results, presented in the table below, indicate that MigGPT performs well in migrating patches involving driver interface modifications.\n\n| LLM | Method | Best Match | Semantic Match |\n| --- | --- | --- | --- |\n| GPT-4-turbo | Vanilla | 54.16% | 62.5% |\n| GPT-4-turbo | MigGPT | 83.33% | 83.33% |\n| DeepSeek-V3 | Vanilla | 58.33% | 62.5% |\n| DeepSeek-V3 | MigGPT | 79.16% | 87.5% |\n\n---\n\n**Question 2.** Migrating Across Multiple Versions\n\nOur benchmarks have already included the scenario where the target kernel version is quite different from the original. For instance, we demonstrate MigGPT's superior performance in migrating code from Kernel 5.10 to Kernel 6.6. This migration spans 15 versions (5.10, 5.11, …, 5.19, 6.0, 6.1, …, 6.6), clearly showing our tool's effectiveness across substantial version gaps.\n\nFurthermore, Linux kernel development, and especially the maintenance of out-of-tree patches by vendors, typically focuses on Long-Term Support (LTS) versions (e.g., 4.19, 5.4, 5.10, 6.6).   It's uncommon for vendors to directly develop and maintain patches across multiple, non-consecutive LTS versions.  Our benchmarks specifically target migrations between these LTS versions, making them representative of real-world out-of-tree patch migration scenarios.\n\n| Version | 4.19 | 5.4 | 5.10 | 6.6 |\n| --- | --- | --- | --- | --- |\n| Released Time | 2018-11 | 2019-11 | 2020-12 | 2023-10 |\n\nHowever, if an extreme case necessitates migrating across multiple LTS versions (e.g., from 4.19 to 6.6), an incremental migration strategy can be employed. A vendor could first use MigGPT to migrate from Kernel 5.4 to 5.10, rigorously test the migrated code, and resolve any bugs to ensure functionality.  Subsequently, MigGPT could then be used for the migration from Kernel 5.10 to 6.6."}, {"review_id": "cGlN0qKIWa", "reviewer": "Reviewer_igwW", "summary": "This paper introduces MIGGPT, a novel framework designed to automate the migration of out-of-tree Linux kernel patches across different kernel versions, a task that is traditionally manual, time-consuming, and requires significant expertise. The authors identify key challenges LLMs face when applied directly to this task, including misunderstanding incomplete code contexts and inaccurately identifying migration points. To address these issues, MIGGPT reframes the migration process into a two-step task: retrieving target code from the updated kernel and then performing the patch migration.\n\nAuthors propose a new data structure called Code Fingerprint (CFP), which is designed to encapsulate the essential structural and critical information of code snippets to provide better context for the LLM. The framework integrates three modules to improve accuracy and efficiency: a Retrieval Augmentation Module, a Retrieval Alignment Module, and a Migration Enhancement Module. The paper also introduces a new benchmark for evaluating out-of-tree kernel patch migration, built from three real-world open-source projects containing 135 migration tasks. The evaluation shows that MIGGPT significantly improves the success rate of patch migration.\nease in computational overhead.", "questions": "- Could you provide a more detailed algorithmic description of the Code Fingerprint (CFP) generation process? For example, what specific heuristics or parsing techniques are used to identify the different statement types shown in Figure 4? How does the process handle complex, nested structures or preprocessor macros that are common in kernel code?\n- The paper demonstrates impressive results on migrating patches for RT-PREEMPT, Raspberry Pi Linux, and HAOC. How do you see MIGGPT generalizing to other, potentially very different, out-of-tree kernel patches or even to code migration tasks in other large-scale C-based projects? What adaptations to the Code Fingerprint or the prompting strategies might be necessary for different codebases?\n- Could you provide a qualitative analysis of cases where MIGGPT fails? Are there common patterns in these failures? For instance, do they relate to particularly complex code refactorings in the kernel, specific types of patch modifications, or limitations in the underlying LLMs that even the CFP cannot overcome? A deeper understanding of the failure modes would be very valuable.", "limitations": "yes", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths\n- The paper tackles a highly relevant and challenging real-world problem in software engineering, the maintenance of out-of-tree Linux kernel patches. To best of my knowledge, this is a novel code migration benchmark and is a solid contribution to LLM community. \n- The proposed method, MIGGPT, is well-motivated by a clear analysis of the shortcomings of vanilla LLMs for this task. The experimental evaluation is thorough, using a variety of both closed-source and open-source LLMs and demonstrating robust improvements across the board. \n- The paper is well-structured and clearly written. The problem is well-defined, and the challenges of using LLMs are articulated with concrete examples referenced in the appendix.\n\nWeaknesses: \n- The paper contrasts CFP with Abstract Syntax Trees (ASTs) but a more formal definition and a more detailed, step-by-step example of the CFP generation process would enhance the reader's understanding of this key component.\n- Given that LLMs can process sufficiently large context 100k+ tokens, it's not clear what value does CFT abstraction provide against a simple baseline of providing whole file. \n- The paper's evaluation of migration success relies on \"semantic match\" and \"human match\", with the latter being the more stringent and important metric. While the \"human match\" results are impressive, the paper could benefit from a more detailed analysis of the cases where MIGGPT fails. Understanding the remaining failure modes would provide valuable insights for future work in this area.\n- While the application to out-of-tree kernel patches is novel, the high-level idea of using program analysis techniques to create structured representations of code to guide LLMs is an emerging area of research. The paper could strengthen its contribution by more explicitly situating the Code Fingerprint concept within this broader context of research on combining structured analysis and large language models for code.\n\n-", "was_revised": true, "final_justification": "After reading authors responses as well as fellow reviewers feedback, I keep my positive scope of the paper.", "rebuttal": "Thank you for your thoughtful feedback. We have carefully considered your comments concerning the generation process of CFP, the generalization of MigGPT, failed cases of MigGPT, and the discussion of CFP. We discussed and supplemented the experiment to address the concern. Please refer to the specific responses below and our rebuttal for more information.\n\n---\n\n**Weakness 1.** The Generation of CFP\n\nThe CFP generation algorithm is detailed in **Algorithm 3 of Appendix D.4**, as mentioned on line 232 of the manuscript. The supplementary materials also include the implementation code for CFP.\n\nIn brief, the CFP generation process involves the following steps:\n\n- Tokenization and Scope Identification: The code snippet `s` is first tokenized. We identify nested code scopes (e.g., `{}` and `#ifdef/#endif`) via bracket matching.\n- Code Block Demarcation: Critical symbols (e.g., `{`, `}`, `#ifdef`, `func()`) are used to demarcate different code blocks.\n- Function Call Detection: Function calls are detected through pattern matching on token sequences, for instance, identifying an identifier followed by `()`.\n- Associated Function Identification: We identify associated functions by analyzing call statements within code blocks, avoiding the need to construct complex call graphs.\n- Preprocessor Macros: Preprocessor macros (e.g., `#ifdef/#endif`) are identified via specific keyword matching and treated as distinct code block boundaries.\n\nWe cannot provide a step-by-step example figure of the CFP generation process for you due to **the rebuttal policy restrictions (\"prohibit using any links in the rebuttal\"),** but following your advice, **we will revise our paper to include such a figure**. Thanks for your valuable suggestions.\n\n---\n\n**Weakness 2.** Baseline\n\nThank you for your question regarding the context window of LLMs. While LLMs with large contexts can process entire code files, they cannot analyze the structural information needed for code migration, such as target code structure information, migration point information, and patch difference information. As mentioned in Section 5.1 of our paper, there are challenges hindering LLMs’ success in out-of-tree kernel patch migration:\n\n- **Structural Ambiguity**: LLMs struggle to accurately identify function definitions, often getting confused by similar structures.\n- **Boundary Indeterminacy**: Inherent randomness in LLM-generated responses leads to inconsistencies between LLM-identified and human-retrieved target code snippet boundaries.\n- **Missing Associated Fragments**: LLMs often overlook critical code fragments relevant to the migration, resulting in migration failures.\n- **Ambiguous Migration Points**: LLMs cannot precisely identify and locate code migration points.\n\nOur experimental results strongly demonstrate the necessity of CFP. \n\nThe baseline vanilla (”two-step strategy”) approach in Tables 2 and 3 is completely equivalent to MigGPT in terms of the context provided to the LLM, as both offer \"the whole file\" context relevant to migration. The only difference is that MigGPT uses CFP for the extraction and analysis of migration information, while “two-step” does not use CFP. The experimental data clearly shows that MigGPT improved the average migration accuracy by **45.92%** compared to vanilla. This fully demonstrates the indispensable value of CFP abstraction in code migration tasks.\n\n---\n\n**Weakness 3.** Failure Cases\n\nWe agree that understanding these remaining failure modes is crucial for future advancements.\n\nWe've conducted an in-depth analysis of the \"human match\" errors and identified the following primary categories:\n\n- **Incomplete `s_new` Retrieval for Large Codebases (31.03%):** In some instances, when retrieving `s_new` from `new.c`, the target code `s_new` was significantly large (exceeding 150 lines), leading to incomplete retrieval. This could be due to LLMs' tendency to shift attention when dealing with long contexts.\n- **Deviation from the Migration Point in `s'_new` Generation (24.14%):** Even with precise migration point information provided by CFP, the LLM occasionally failed to strictly adhere to these locations during `s'_new` generation. While minor offsets often didn't impact functionality, they sometimes led to functional errors in code with complex control or data flows. This behavior appears to be related to the inherent randomness of LLMs.\n- **Difficulty in Fusing Divergent Changes in Type 2 Migrations (27.59%):** For certain Type 2 migrations, significant differences between `s_new` and `s_old`'s modifications to `s_old` prevented the LLM from correctly integrating these changes, resulting in errors. This limitation points to challenges related to the LLM's code comprehension and manipulation capabilities.\n- **Miscellaneous (17.24%)**: Errors in symbols, statements, etc., appearing in `s'_new`, such as incorrectly writing `verbose(env, off, size, reg's id)` instead of `verbose(env, off, size, reg->id)`. This may be related to LLM hallucinations.\n\n**It's important to note that these identified failure modes primarily arise from the inherent limitations of the LLMs themselves, rather than architectural flaws within the MigGPT framework.** We will incorporate this detailed failure analysis into the final version of our paper. Thank you again for your insightful feedback.\n\n---\n\n**Weakness 4.** Structured Analysis + LLMs\n\nThank you for your valuable feedback.  We agree that explicitly situating our Code Fingerprint concept within the broader context of combining structured analysis and LLMs for code will strengthen the paper's contribution.\n\nWe have compared MigGPT with existing research in this emerging area.  For instance, works such as [r-1, r-2] utilize heuristic tree structures to assist LLMs in optimizing kernel configurations during operating system deployment.  Similarly, LLM-based fuzzing tools like [r-3, r-4, r-5] employ formal templates to guide LLMs in generating more effective test cases.  These approaches, much like MigGPT, leverage deterministic information such as trees, graphs, and lists to mitigate the inherent uncertainty and randomness of LLMs, thereby improving performance across various application tasks.  However, it's worth noting that the specific deterministic information used and its data structure are often tailored to the particular task at hand.\n\nWe will incorporate this discussion into the Related Work section of the final version of our paper.\n\n[r-1] Chen H, Wen Y, Cheng L, et al. AutoOS: Make your os more powerful by exploiting large language models, Forty-first International Conference on Machine Learning. 2024.\n\n[r-2] Lin H, Li Y, Luo H, et al. BYOS: Knowledge-driven Large Language Models Bring Your Own Operating System More Excellent. arXiv preprint arXiv:2503.09663, 2025.\n\n[r-3] Xu H, Ma W, Zhou T, et al. CKGFuzzer: LLM-Based Fuzz Driver Generation Enhanced By Code Knowledge Graph, 2025 IEEE/ACM 47th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion). IEEE, 2025: 243-254.\n\n[r-4] J. Hu, Q. Zhang, and H. Yin, “Augmenting greybox fuzzing with generative AI,” arXiv preprint arXiv:2306.06782, 2023.\n\n[r-5] Z. Liu, C. Chen, J. Wang, M. Chen, B. Wu, X. Che, D. Wang, and Q. Wang, “Testing the limits: Unusual text inputs generation for mobile app crash detection with large language model,” arXiv preprint arXiv:2310.15657, 2023. \n\n---\n\n**Question 1.** The Generation of CFP\n\nPlease refer to our response to Weakness 1\n\n---\n\n**Question 2.** Generalization of MigGPT\n\nThank you for your excellent question regarding MigGPT's generalizability across other tasks and domains. We've conducted new experiments to address this:\n\n- **Broad Migration Task Applicability:** Our initial submission (Table 5) already demonstrated MigGPT's versatility by successfully applying it to CVE patch backporting—migrating patches to older code versions. In this scenario, MigGPT significantly outperformed existing methods. In this task, we only need to modify MigGPT's task prompt (to describe the details of the CVE patch backporting task); no modifications are required for the CFP.\n- **Cross-Language Adaptability:** We tested MigGPT's performance with Python code migration. After randomly translating 31 benchmark examples to Python and making minor adjustments to handle Python syntax (specifically in the statement tokenization and element extraction functions), MigGPT showed an average semantic match improvement of 16.13% over a vanilla approach. This confirms MigGPT's effectiveness beyond C-language code.\n\n| LLM | Method | Best Match | Semantic Match |\n| --- | --- | --- | --- |\n| GPT-4-turbo | Vanilla | 61.29% | 70.97% |\n| GPT-4-turbo | MigGPT | 80.65% | 87.10% |\n| DeepSeek-V3 | Vanilla | 64.52 | 74.19% |\n| DeepSeek-V3 | MigGPT | 83.87% | 90.32% |\n\n---\n\n**Question 3.** Failure Cases\n\nPlease refer to our response to Weakness 3"}, {"review_id": "EspQSvufdJ", "reviewer": "Reviewer_Nf59", "summary": "The authors propose an LLM-based framework targeting the automation of maintaining out-of-tree Linux Kernel Patches across different kernel versions. To do so, they leverage what they define as Code Fingerprints, a sequential structure that aims to preserve code context for code segments and to facilitate migration. Further, they design their framework in a modular way to address challenges that they identify. To address structural ambiguity (similar function signature) and missing associated fragments (for example, due to refactoring work), they design a retrieval augmentation module. To address boundary ambiguity, i.e. patch anchor points can change across Linux versions, they design a Retrieval Alignment module. Finally, they built their Migration Augmentation module with the potential of ambiguous application points in mind to address a final challenge they identified. To evaluate their proposed framework on their proposed problem domain, the authors devise a new benchmark using RT-PREEMPT, RPi Linux, and HAOC. They focus on two types of migrations: those whose updated line-spans intersect, and those that do not. The latter form a more difficult category as this can signal refactoring, or modularisation, etc. This new benchmark focuses on the maintenance use case, in contrast to previous work, which focused on (security) back-porting. They evaluate their framework on two benchmarks, the one proposed and FixMorph's CVE patch back-porting framework. MigGPT shows consistent improvement on Best Match, Semantic Match, and Human Match across all considered LLMs. Further, it also shows significant improvement in code compilation on GPT-4-turbo and DeepSeek-V3.", "questions": "Q1. In your dataset, has it been the case that the out-of-tree patch-set used _now_ deprecated system calls? What would the expected LLM output be in such a case? I feel there can exist a Type 3 (perhaps in other systems if the LK does not show such cases) where the API/system calls have evolved and the patch itself should be augmented, not just determining where to apply it unaltered.\n\n- Side remark: While I appreciate the argument for code fingerprints in §5.3/G.2, the argument is concerning the AST of the full language grammar. Alternatives could be considered, specifically island grammars. Interesting structures could be relegated to \"land\" and parsed, while noise could be relegated to \"water\". This would not address the AST depth issue; however, it can address the issue of focusing on specific patterns as well as preserving comments or other information usually not included in traditional ASTs (see H-AST in [+3])\n[+1]Balland, E., Kirchner, C. and Moreau, P.E., 2006, July. Formal islands. In International Conference on Algebraic Methodology and Software Technology (pp. 51-65). Berlin, Heidelberg: Springer Berlin Heidelberg.\n[+2]Afroozeh, A., Bach, J.C., Van den Brand, M., Johnstone, A., Manders, M., Moreau, P.E. and Scott, E., 2013. Island grammar-based parsing using gll and tom. In Software Language Engineering: 5th International Conference, SLE 2012, Dresden, Germany, September 26-28, 2012, Revised Selected Papers 5 (pp. 224-243). Springer Berlin Heidelberg.\n[+3] L. Ponzanelli, A. Mocci and M. Lanza, \"StORMeD: Stack Overflow Ready Made Data,\" 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories, Florence, Italy, 2015, pp. 474-477, doi: 10.1109/MSR.2015.67.", "limitations": "Limitations are reasonably addressed.", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 4, "clarity": 3, "significance": 4, "originality": 3, "strengths_and_weaknesses": "+ S1 Strong results on patch migration, especially the line edits result in §6.4, suggesting that the explored patch types are reasonably automatable.\n+ S2 Detailed analysis of the expected data shape (out-of-tree diffs and Linux kernel version update diffs), justifying the system design from the data.\n+ S/W(Mixed) The design methodology can be generalised to other domains, but the presented system is domain-specific to the Linux Kernel and the out-of-tree patch-set maintenance task. My side-remark below does offer alternatives that are more standard in Software Engineering; however, those too would be specific to the problem domain once designed, requiring adaptation to a new domain.\n- W1 The formalism introduced in §4.1 (Δ,Σ,δ,σ,⟨⋅,⋅⟩) does not reduce the cognitive load of trying to understand the Type 1 and Type 2 migrations. The English explanations serve this role better, and the paper could have its clarity improved if the formalism is dropped, as it is not reused in other parts of the paper.\n- W2 Perhaps a nit-pick. I personally really like this work, but this seems to be more so an AI4SE paper with a very strong SE flavour. I understand that NeurIPS does allow application papers, so perhaps this paper falls under that rubric.", "was_revised": true, "final_justification": "After reading the author's responses and other reviews, I maintain my positive score.", "rebuttal": "We are so pleased and grateful for your thoughtful feedback. Thank you! We have carefully considered your comments concerning MigGPT's generalization capabilities, symbolic representation, and deprecated system calls, and have provided thorough responses to each of these points. Please refer to the specific responses below and our rebuttal for more information.\n\n---\n\n**Strength/Weakness Mixed.** Generalization of MigGPT\n\nThank you for an insightful question about MigGPT's generalizability. We've strengthened our findings with new experiments:\n\n- **MigGPT Excels in Cross-Language Migration:** To directly address concerns about its applicability beyond C-language, we rigorously tested MigGPT on Python code migration. By randomly translating 31 examples from our benchmark and making only minor adjustments for Python's syntax (specifically in tokenization and element extraction), MigGPT achieved a 16.13% average improvement in semantic match performance over traditional methods. This is a powerful testament to its cross-language capabilities.\n\n| LLM | Method | Best Match | Semantic Match |\n| --- | --- | --- | --- |\n| GPT-4-turbo | Vanilla | 61.29% | 70.97% |\n| GPT-4-turbo | MigGPT | 80.65% | 87.10% |\n| DeepSeek-V3 | Vanilla | 64.52 | 74.19% |\n| DeepSeek-V3 | MigGPT | 83.87% | 90.32% |\n- **Proving Versatility Across Migration Challenges:** Our original paper (Table 5) already showcased MigGPT's versatility through its successful application to CVE patch backporting. In this different, yet critical, migration task, MigGPT consistently outperformed existing solutions. In this task, we only need to modify MigGPT's task prompt (to describe the details of the CVE patch backporting task); no modifications are required for the CFP.\n\n---\n\n**Weakness 1.** Symbol Notation (Response to Weakness 1)\n\nWe appreciate the reviewer's insightful feedback. To improve clarity and streamline the presentation, we will simplify ****the expression of this part. Thank you for helping us enhance the readability of our manuscript.\n\n---\n\n**Weakness 2.** AI4SE (Response to Weakness 2)\n\nYour positive feedback and generous words regarding our work are truly appreciated! We're so pleased it resonated with you and had an impact. We focused on the intersection of AI and software engineering, as we believe this domain offers significant opportunities for practical impact. Our future plans include expanding this work to a broader range of code application areas, and we indeed plan to further delve into the SE aspects of our research and submit to a software engineering conference.\n\n---\n\n**Question 1.** Deprecated System Calls\n\nThank you very much for your insightful question. This is indeed a profound point that deserves thorough discussion.\n\nRegarding your question about whether \"out-of-tree patch-sets used now deprecated system calls\" in our dataset, such instances are rare. This is primarily due to Linux kernel development principles prioritizing backward compatibility. Once a system call is added to the kernel, it's generally supported indefinitely to avoid breaking existing software that relies on it.\n\nHowever, kernels do evolve, introducing new system calls that offer more robust, secure, or efficient functionalities. These new features can, in some cases, functionally supersede older, more limited mechanisms. \n\nWhen a patch migration involves new system calls introduced in a newer kernel version, MigGPT is well-equipped to handle such scenarios.  In these cases, the new version target code (s_new) will contain examples of how the new system call is used. MigGPT can then refer to these usage examples in s_new to complete the migration and generate a corresponding patch that aligns with the new API. Certainly, in this scenario, migration types can still be categorized according to the rules in Table 1 of the paper. If the new kernel version and patch modifications don't overlap in location, it's Type 1. Otherwise, it's Type 2."}, {"review_id": "CrpchOsVPs", "reviewer": "Reviewer_NY3E", "summary": "The paper proposes a MIGGPT, a novel framework that employs code fingerprints (CFPs) to enhance Large Language Models in backporting out-of-tree Linux Kernel patches. The paper identifies key challenges in using LLMs for this task, such as namespace interference and the absence of key code information. To address these, MIGGPT leverages a novel data structure CFP to augment LLM's capability in backporting Linux Kernel patches across different versions. The experimental results demonstrate that the proposed MIGGPT framework outperforms the direct application of vanilla LLMs, achieving more than a 70% improvement in the completion rate.", "questions": "I appreciate the authors' efforts in applying LLMs to backport out-of-tree Linux Kernel patches. The proposed method provides a novel way to constrain LLMs to focus on the specific context of the program, which effectively prevents the potential issues of directly using LLMs for program-repair tasks, such as hallucination. While the experimental results show MIGGPT works excellently on the task, I am still concerned with a few aspects of the proposed method.\n\n### On the code fingerprint (CFP)\n\nWhile the paper claims that using Abstract Syntax Trees (ASTs) is unable to tackle some scenarios during the analysis since it is highly tight to the compilation process, I was wondering if the tools commonly used in static analysis such as the Intermediate Representation (IR) of the kernel program could be helpful to distinguish the patches from similar contexts. Since IR (either LLVM IR or Gimple) is specifically designed to address the syntax sugars, would that be a better choice for this task?\n\n### On the wider application/generalization of MIGGPT\n\nThe proposed framework significantly improves the capability of LLMs to backport out-of-tree patches in Linux Kernel. However, the proposed framework gives me a feeling that it is quite a general method of backporting patches from the mainstream project to the forks or distributions. Is it possible to extend the pack backporting approach to other similar scenarios? If so, could the authors generally discuss a wider application of MIGGPT? I would like to suggest adding a minor discussion section in the paper, which could highlight the future work.", "limitations": "Yes.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 4, "significance": 4, "originality": 3, "strengths_and_weaknesses": "### Strengthens\n\n- The task is important. LLMs are applied in a reasonable way to reduce human labor.\n- The experiments are well designed, including the ablation experiment.\n- The experimental results are impressive.\n\n### Weaknesses\n\n- The proposed LLM-based approach seems not to be limited to the Linux Kernel vulnerability patching only. I would like to recommend that the authors discuss the potential generalization of MIGGPT to a wider application.\n\n-  Potential runtime overhead brought by using LLMs.\n\nSee more details in `Questions`.", "was_revised": true, "final_justification": "I have went through authors' response and other reviews. My concerns have been addresses. I would like to keep my decision and recommend the acceptance of this paper.", "rebuttal": "Thank you for your review comments. Your concerns regarding the discussion on MigGPT's generalization, IR-based approaches, and runtime overhead have all been addressed. We discussed and supplemented the experiment to address the concern. Please refer to the specific responses below and our rebuttal for more information.\n\n---\n\n**Weakness 1.** Generalization of MigGPT\n\nWe appreciate you bringing up the crucial question of MigGPT's generalizability to other migration scenarios and domains. In response, we've incorporated new experimental findings:\n\n- **Demonstrated Generalizability to Other Migration Tasks:** As explicitly detailed in Table 5 of our paper, MigGPT was successfully deployed in a CVE patch backporting task—specifically, migrating a CVE patch from its discovery version to an earlier iteration. In this task, we only need to modify MigGPT's task prompt (to describe the details of the CVE patch backporting task); no modifications are required for the CFP. The results show that MigGPT consistently outperformed existing solutions.\n- **Enhanced Cross-Language Generalizability:** We randomly selected 31 migration examples from our benchmark and translated them into Python. With only minimal modifications required for the statement tokenization and statement element extraction functions of CFP to accommodate Python syntax, MigGPT efficiently processed these examples. The results show an average semantic match performance improvement of 16.13% when compared to the vanilla approach, thereby underscoring MigGPT's robust effectiveness beyond its original C-language application.\n\n| LLM | Method | Best Match | Semantic Match |\n| --- | --- | --- | --- |\n| GPT-4-turbo | Vanilla | 61.29% | 70.97% |\n| GPT-4-turbo | MigGPT | 80.65% | 87.10% |\n| DeepSeek-V3 | Vanilla | 64.52 | 74.19% |\n| DeepSeek-V3 | MigGPT | 83.87% | 90.32% |\n\n---\n\n**Weakness 2.** Runtime Overhead\n\nWe would like to thank the reviewer for the insightful comment.  As shown in **Table 6** of our manuscript, we conducted a comparison between MigGPT and human experts in terms of time cost for performing code migration tasks.  The results demonstrate that MigGPT required only **2.08%** of the average time taken by human experts.  This highlights the capability of MigGPT to automate the code migration process, significantly reducing human effort and achieving substantial efficiency improvements.\n\n---\n\n**Question 1.** CFP and Intermediate Representations\n\nThank you for the suggestion. While IR-based methods are effective at normalizing syntax, CFP is designed to meet two essential needs in kernel patch migration:\n\n- **Context Preservation**: Kernel patches often include macros, inline assembly, and annotations that are lost during IR generation. CFP retains this information, along with structural elements like function signatures and control-flow anchors, to give the LLM a richer migration context.\n- **Support for Non-Compilable Code**: Early-stage or experimental patches may not compile, making IR extraction infeasible. CFP works directly on source code fragments, even if they are incomplete or broken.\n\n---\n\n**Question 2.** Generalization of MigGPT\n\nPlease refer to our response to Weakness 1"}]

Author rebuttal:

Meta-review: MigGPT presents a technically solid and impactful contribution to the intersection of LLMs and software maintenance, offering SOTA results on a difficult and valuable task. The "Code Fingerprint" representation, is an elegant and well-motivated solution. 

Despite concerns about generalizability and baseline comparisons, the authors have adequately addressed these issues in the rebuttal, and none of the identified weaknesses undermine the central contributions or experimental findings. Given the strong real-world relevance, novel methodology, and robust results, I recommend acceptance.
Decision: Accept (spotlight)