Re: [PATCH v19 36/40] dept: track PG_writeback with dept

[sashiko-bot@kernel.org]

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 <byungchul@sk.com>

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/20260706061928.66713-1-byungchul@sk.com?part=36