Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] False lock acquisition registered in DEPT for SHARED waits on PG_writeback, permanently corrupting the task's dependency graph. --
commit 9dc48dc95eded487307805ef6bce49ac459667ad Author: Byungchul Park <[email protected]> dept: track PG_writeback with dept This commit adds DEPT tracking for PG_writeback to track writeback waits and events. It extends the existing page bit tracking machinery to cover PG_writeback in addition to PG_locked. > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > index 0b0655354b084..ec736811a2c66 100644 > --- a/include/linux/page-flags.h > +++ b/include/linux/page-flags.h [ ... ] > @@ -292,6 +293,8 @@ static inline void dept_page_set_bit(struct page *p, int > bit_nr) > > if (bit_nr == PG_locked) > dept_request_event(&pg_locked_map, &p->pg_locked_wgen); > + else if (bit_nr == PG_writeback) > + dept_request_event(&pg_writeback_map, &p->pg_writeback_wgen); [Severity: High] Does wiring PG_writeback into this tracking logic cause false lock acquisitions for shared waits? In the wait queue logic, tasks can wait for writeback to complete without actually acquiring the bit (a SHARED wait). However, when a task waits on PG_writeback and the bit is already clear on the fast path, folio_trylock_flag() sets WQ_FLAG_DONE: mm/filemap.c:folio_trylock_flag() { ... } else if (test_bit(bit_nr, &folio->flags.f)) return false; wait->flags |= WQ_FLAG_WOKEN | WQ_FLAG_DONE; return true; } Then in folio_wait_bit_common(), it unconditionally registers an acquisition if WQ_FLAG_DONE is set: mm/filemap.c:folio_wait_bit_common() { ... if (wait->flags & WQ_FLAG_DONE) dept_page_set_bit(&folio->page, bit_nr); ... } Because the task never actually acquired the bit, it will never clear it, leaving DEPT recording the lock as permanently held. Could this cause DEPT resource leaks and false positive deadlock reports? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=36
