locking (or LOCKDEP) problem with mark_buffer_dirty()

[Bob Peterson <rpeterso@redhat.com>]

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