pkg/aflow/flow/patching: improve prompts

More instructions slightly more concrete,
and add details about some bug types.

1 files changed, 33 insertions, 3 deletions

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.