הקוד שטורבאלדס כתב עם קלוד קוד נבדק בפומבי. באג נמצא תוך ארבע שעות

לפני שבוע כתבנו על הענף שבו לינוס טורבאלדס עבד עם קלוד קוד על צוואר בקבוק בליבת לינוקס. אז זה היה ענף בעץ הפרטי שלו, עם מכתב פתיחה כן ורשימה ארוכה של מה שלא נבדק. מאז הקוד יצא לאוויר, ופגש מפתחי קרנל אחרים.

ב-13 באוקטובר 2026 טורבאלדס שלח לרשימת התפוצה של ניהול הזיכרון בקרנל (linux-mm) הודעה בשם ״Improve page refcount scalability״. היא מפנה לענף חדש, ‎rcu-free-v3‎: עשרה פאצ’ים. ארבע שעות אחר כך ענה לו קיריל שוטמוב (Kiryl Shutsemau), במשפט שפותח ב-״There’s a race״.

מה טורבאלדס פרסם?

בהודעה הוא מסביר למה בחר דווקא בבעיה הזאת. בכנס המתחזקים של הקרנל השנה, אחד הנושאים הגדולים היה שימוש ב-LLM בפיתוח הקרנל, והוא החליט לנסות לפתור איתו בעיה שהכשילה כמה ניסיונות קודמים. אחד מהם היה שלו: טיוטה שבה השתמש במחשב שלו שנה וחצי, ״עד שאנשים הראו כמה היא שבורה״. ניסיון אחר, של שוטמוב עצמו, מלפני שנה, ״גם בו היו בעיות״.

כל עשרת הפאצ’ים בגרסה 3 נושאים את השורה ‎Assisted-by: LLM‎, ושניים מהם נכתבו בידי שוטמוב. טורבאלדס מעיר בהודעה שהודעות הקומיט ארוכות ממה שהיה כותב בלי כלי, ומוסיף: ״אולי עדיף ככה״.

מספר התצוגה: מחשב Threadripper עם 64 תהליכונים שקוראים שוב ושוב את אותו קטע קטן מקובץ קפץ מ-13.3 מיליון ל-304 מיליון קריאות בשנייה. באותה פסקה טורבאלדס כותב שזה עומס מלאכותי, ושההשפעה על עבודה אמיתית ״תהיה קטנה בהרבה״.

מה נמצא, ומי מצא?

שוטמוב תיאר race condition, כלומר באג שתלוי בסדר שבו שני מעבדים פועלים באותו רגע. בזמן שתהליך אחד קורא מהקובץ בנתיב המהיר החדש, בלי לסמן שהוא משתמש בדף, תהליך אחר מוציא את הדף מה-cache ומיד כותב לקובץ ומאריך אותו. הקורא בודק את אורך הקובץ, רואה את האורך החדש, וממשיך להעתיק מהדף הישן. התוצאה: הוא מקבל נתונים שאף אחד לא כתב שם. התיקון שהציע היה שתי שורות, בדיקה נוספת שהדף עדיין במקומו.

הפרט המעניין ביותר נמצא בהודעות הקומיט עצמן. הן ארוכות ויסודיות, ומתארות בפירוט שני מצבי race אחרים, עם תרשים של מה כל מעבד עושה בכל שלב. את המצב הזה הן לא מזכירות. הניתוח העצמי של הסדרה היה טוב, ומפתח שעבד על אותה בעיה בעצמו מצא את מה שחסר בו בתוך ארבע שעות.

פחות משעה אחר כך טורבאלדס שאל אם שוטמוב מוכן לקחת את כל הסדרה, כי הוא יוצא לחופשה וצריך לנהל את חלון המיזוג. התשובה: ״Yes, can do״.

מה עוד יצא מהבדיקה?

• רעיון התכנון המרכזי של גרסה 3 בא מבחוץ: הגרסה הראשונה דחתה את שחרור כל דף שיצא מה-cache. שוטמוב הראה שבמכונה וירטואלית עם 2GB ו-64 ליבות זה הוביל להריגת תהליכים בגלל חוסר זיכרון. גרסה 3 מסמנת רק דפים ״חמים״, שנקראים שוב ושוב, והרעיון מגיע מהענף שלו.
• האטה שלא נמדדה: ב-16.10 שוטמוב דיווח שקריאות של 1MiB מקובץ ext4 איטיות ב-9% עם הסדרה, וקריאות של 64K ב-4%. הסיבה, לפי שוטמוב: בדפים גדולים הנתיב החדש מעתיק דף אחרי דף, במקום הכול בבת אחת. הוא הוסיף סף, וטורבאלדס ענה שזה ״סביר לגמרי״.
• באג של מערכת קבצים אחרת: הדיון חשף התנהגות של f2fs שמתחזק שלה, Jaegeuk Kim, הודה שהיא באג, ותיקון כבר בדרך.

שוטמוב העלה את הגרסה שלו לענף ‎rcu-free/rfc-v1‎ ושאל אם לפרסם אותה כ-RFC. דייוויד הילדנברנד, ממתחזקי ניהול הזיכרון, ענה ״Yes please״. שום דבר מזה עוד לא מוזג: לינוקס 7.3 יצא ב-18 באוקטובר בלי הסדרה.

מה לוקחים מזה לעבודה עם סוכן?

רשימת הסיכונים של הסוכן היא נקודת התחלה

הודעות הקומיט מתעדות שני מצבי race ומציינות פעמיים שהנימוק ״לא עבר מידול״. זה בדיוק מה שאנחנו ממליצים לבקש מקלוד. אבל הבאג שנמצא לא היה ברשימה. מה שקלוד מונה כסיכון מראה איפה הוא חיפש, לא איפה נגמרות הבעיות.

הבודק הנכון מכיר את התחום, לא את הכלי

את הבאג לא מצא כלי. מצא אותו האדם שניסה לפתור את אותה בעיה לפני שנה. לקוד רגיש, שלחו את מה שקלוד כתב למי שמכיר את המקום טוב ביותר, גם אם הוא לא משתמש בקלוד בכלל. כך עובד גם צוות קלוד קוד עצמו: אישור אנושי לפי רמת הסיכון של השינוי, לא לפי מי כתב אותו.

מדדו על מה שאתם לא מכירים

טבלת המדידות המרכזית של טורבאלדס נעשתה על קובץ של דף אחד ב-btrfs. ההאטה הופיעה בקריאות גדולות מ-ext4, על מכונה אחרת. כשקלוד מסיים לשפר ביצועים, הריצו את הבדיקה גם על עומס שלא תכננתם בשבילו. עוד על בדיקות שבאמת מסוגלות להיכשל בטיפ על בדיקה שקלוד יכול להריץ בעצמו.

שורה תחתונה

לפני שבוע הסיפור היה שטורבאלדס עובד עם קלוד קוד. השבוע הסיפור טוב יותר: הקוד הגיע לבודקים אמיתיים, אחד מהם מצא באג תוך ארבע שעות, ולמחרת הסדרה כבר עברה לידיים שלו. תוך שלושה ימים היו לה תיקון, האטה שנמצאה ותוכנית לגרסה הבאה. כך נראה קוד טוב שנכתב עם סוכן: הוא לא נכנס בלי בדיקה, והבדיקה עושה את העבודה.

מי שבונה את ההרגלים האלה בצוות ימצא אותם במדריך המלא לקלוד קוד.

מקורות: השרשור ברשימת התפוצה linux-mm, בארכיון MARC: ההודעה של טורבאלדס, דיווח ה-race, בקשת ההעברה, התיקון המעודכן וה-״Yes, can do״, דיווח ההאטה ו-תשובת f2fs. הקוד עצמו: הענף ‎rcu-free-v3‎ בעץ של טורבאלדס.