From 22003bbfe9ef57dd80e3be819bf8a74d76dce00c Mon Sep 17 00:00:00 2001 From: Dmitry Vyukov Date: Fri, 30 Jan 2026 09:32:52 +0100 Subject: pkg/aflow/flow/patching: improve prompts More instructions slightly more concrete, and add details about some bug types. --- pkg/aflow/flow/patching/patching.go | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-) (limited to 'pkg/aflow/flow/patching') diff --git a/pkg/aflow/flow/patching/patching.go b/pkg/aflow/flow/patching/patching.go index fcc74d076..1906204ec 100644 --- a/pkg/aflow/flow/patching/patching.go +++ b/pkg/aflow/flow/patching/patching.go @@ -105,8 +105,16 @@ func init() { const debuggingInstruction = ` You are an experienced Linux kernel developer tasked with debugging a kernel crash root cause. You need to provide a detailed explanation of the root cause for another developer to be -able to write a fix for the bug based on your explanation. -Your final reply must contain only the explanation. +able to write a fix for the bug based on your explanation. Include all relevant details +into the response: function/struct/field/etc names, code snippets, line numbers, +macro/enum values, etc. + +{{if titleIsKASANNullDeref .BugTitle}} +Note: under KASAN NULL-derefs on the source level don't happen around the actual 0 address, +they happen on the KASAN shadow memory around address dfff800000000000 or dffffc0000000000. +Don't be confused by that. Look for the like at the top of the report that tells +the access address and size. +{{end}} ` const debuggingPrompt = ` @@ -117,9 +125,30 @@ The crash is: const patchInstruction = ` You are an experienced Linux kernel developer tasked with creating a fix for a kernel bug. +You will be given a crash report, and an initial explanation of the root cause done by another +kernel expert. + Use the codeedit tool to do code edits. Note: you will not see your changes when looking at the code using codesearch tools. -Your final reply should contain explanation of what you did in the patch and why. + +Your final reply should contain explanation of what you did in the patch and why +(details not present in the initial explanation of the bug). + +Your fix must not just prevent the given crash, but also be the best fix for the underlying +root cause from the software engineering point of view. There can be several ways to fix the +same bug. Consider alternatives, and pick the best one. For example, additional checks may be +added at different locations/functions, it's usually better to place them earlier in the +execution to avoid multiple checks at various locations later. + +Frequently the same coding mistake is done in several locations in the source code. +Check if your fix should be extended/applied to similar cases around to fix other similar bugs. +But don't go too wide, don't try to fix problems kernel-wide, fix similar issues +in the same file only. + +If you are changing post-conditions of a function, consider all callers of the functions, +and if they need to be updated to handle new post-conditions. For example, if you make +a function that previously never returned a NULL, return NULL, consider if callers +need to be updated to handle NULL return value. {{if titleIsWarning .BugTitle}} If you will end up removing the WARN_ON macro because the condition can legitimately happen, @@ -170,6 +199,7 @@ const descriptionInstruction = ` You are an experienced Linux kernel developer tasked with writing a commit description for a kernel bug fixing commit. The description should start with a one-line summary, and then include description of the bug being fixed, and how it's fixed by the provided patch. + Your final reply should contain only the text of the commit description. Phrase the one-line summary so that it is not longer than 72 characters. The rest of the description must be word-wrapped at 72 characters. -- cgit mrf-deployment