Hi Tejun and linux-fsdevel,
I have a question about function mark_buffer_dirty and LOCKDEP.
Background: Func mark_buffer_dirty() has a calling sequence that looks kind
of like this (simplified):
mark_buffer_dirty()
__set_page_dirty()
account_page_dirtied()
inode_to_wb() which contains:
#ifdef CONFIG_LOCKDEP
WARN_ON_ONCE(debug_locks &&
(!lockdep_is_held(&inode->i_lock) &&
!lockdep_is_held(&inode->i_mapping->i_pages.xa_lock) &&
!lockdep_is_held(&inode->i_wb->list_lock)));
#endif
...
__mark_inode_dirty()
spin_lock(&inode->i_lock);
...
spin_unlock(&inode->i_lock);
...
The LOCKDEP checks were added with Tejun Heo's 2015 patch, aaa2cacf8184e2a92accb8e443b1608d65f9a13f.
Since mark_buffer_dirty()'s call to __mark_inode_dirty() locks the inode->i_lock,
functions must not call mark_buffer_dirty() with inode->i_lock locked: or deadlock.
If they're not doing anything with the xarrays or the i_wb list (i.e. holding the
other two locks), they get these LOCKDEP warnings.
So either:
(a) the LOCKDEP warnings are not valid in all cases -or-
(b) mark_buffer_dirty() should be grabbing inode->i_lock at some point like __mark_inode_dirty() does.
My question is: which is it, a or b? TIA.
(My situation is that the gfs2 file system gets these LOCKDEP warnings
when it calls mark_buffer_dirty() [obviously only if LOCKDEP is set], and it's
not appropriate to lock xa_lock or i_wb->list_lock, and we cannot lock i_lock
for the reasons stated above).
Regards,
Bob Peterson
GFS2 File System
