Please look through the following Linux Crash Report and Repository structure and provide a list of files that one would need to edit to fix the crash report


- **Bug Title**: {title}  
- **Crash Report**:  
```  
{crash_report}  
```  

REPOSITORY STRUCTURE:
{repo_tree}

Please only provide the full path and return at most 5 files.
The returned files should be placed inside <files> tags as shown below.
Ordered by most to least important, please follow the following format:
<files>  
  1: net/netfilter/file1.c  
  2: include/linux/file2.h  
</files>  

"""

LOCALIZE_N_FILES_PROMPT = """
 
You are an experienced Linux kernel developer tasked with identifying critical files that may contain the code causing a bug. Use the crash report, stack traces, subsystem context, and your expertise to prioritize files for investigation.  

# Context  
- **Bug Title**: {title}  
- **Crash Report**:  
```  
{crash_report}  
```  
- **Relevant Subsystem Files**: Files in the same subsystem as those mentioned in the crash report:  
{relavent_files}  

# Task  
1. **Analyze the crash report**:  
   - Focus on stack trace hierarchy: Files mentioned **at the top of the stack trace** are statistically more likely to contain the root cause.  
   - Identify error patterns (e.g., NULL dereference, use-after-free, locking imbalance).  
2. **Cross-reference subsystem files**:  
   - Map crash symptoms (e.g., "BUG: unable to handle page fault") to subsystems (e.g., memory management, drivers).  
3. **Evaluate file relevance**:  
   - Prioritize `.c` files (implementation) but include critical `.h` files (APIs, structs).  
   - Flag files with known bug patterns (e.g., race conditions in concurrency-heavy code).  
4. **Narrow to {NUM_FILES_TO_LOCALIZE} candidates**:  
   - Ensure diversity (no duplicates) and subsystem alignment.  

# Rules  
- **Stack trace priority**: Always weigh files in the **top 3 stack frames** most heavily.  
- **Relevance over quantity**: Exclude files unrelated to the crash symptoms.  Only include files logically tied to the crash symptoms.
- **Format**: Use XML with `<thoughts>` (reasoning) and `<files>` (output) sections.  
- **No duplicates**: Ensure all {NUM_FILES_TO_LOCALIZE} files are distinct and ensure that you have provided all the {NUM_FILES_TO_LOCALIZE} files.

# Output Example  
```xml  
<thoughts>  
1. **Stack Trace Analysis**:
   - Top stack frame: `drivers/net/wireless/ath/ath9k/ath9k_main.c:ath9k_tx_failure()` shows failed packet transmission.
   - Second frame: `kernel/locking/mutex.c:mutex_lock()` reveals a mutex was held during the failure.
   - Third frame: `mm/slub.c:kmem_cache_alloc()` indicates memory allocation occurred prior to crash.
   - *Key Insight*: The crash origin likely lies in `ath9k_main.c` (top frame), but memory allocation (slub) and locking (mutex) subsystems may contribute.

2. **Error Pattern Recognition**:
   - Crash message "BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000" suggests:
     - Uninitialized struct in driver code (common in wireless drivers)
     - Race condition between memory allocation and device reset
     - Incorrect mutex locking sequence causing stale pointer access

3. **Subsystem Mapping**:
   - Primary subsystem: Wireless drivers (`drivers/net/wireless/ath/ath9k/`)
   - Related subsystems:
     - Memory management (`mm/`) due to kmem_cache_alloc()
     - Kernel locking (`kernel/locking/`) due to mutex involvement
   - Cross-checked against provided relevant_files:
     - `include/linux/mutex.h` (locking API)
     - `drivers/net/wireless/ath/ath.h` (driver shared headers)

4. **File Prioritization Logic**:
   - High Priority:
     - `ath9k_main.c` (direct crash site)
     - `ath9k.h` (defines `struct ath_tx_control` used in crash context)
   - Medium Priority:
     - `mutex.c` (locking subsystem - possible lock ordering issue)
     - `ath9k_htc.c` (shared HTC layer - potential race with USB disconnects)
   - Lower Priority but Relevant:
     - `slub.c` (memory allocator - if crash reproduces with SLUB_DEBUG)
     - `netdevice.h` (generic netdev structures - sanity check API usage)

5. **Header File Importance**:
   - `ath9k.h` defines:
     - `struct ath_hw` with ->caldata pointer (NULL deref candidate)
     - TX queue configuration macros that might mismatch mutex ops
   - `mutex.h` documents `mutex_lock()` vs `mutex_trylock()` semantics

</thoughts>  

<files>  
  1: drivers/net/ethernet/example_driver.c  
  2: include/linux/netdevice.h  
  3: drivers/dma/dma-buf.c  
</files>  
```  

# Required Output Format  
```xml  
<thoughts>  
[Your step-by-step reasoning here. Mention stack trace hierarchy, subsystem logic, and why specific files are prioritized.]  
</thoughts>  

<files>  
  1: path/to/file1.c  
  2: path/to/file2.h  
  ...  
</files>  
```  

Begin your analysis by reasoning through the crash report and stack traces.  
