Skip to content
  • Bob Peterson's avatar
    GFS2: Flush work queue before clearing glock hash tables · 222cb538
    Bob Peterson authored
    
    
    There was a timing window when a GFS2 file system was unmounted
    that caused GFS2 to call BUG() and panic the kernel. The call
    to BUG() is meant to ensure that the glock reference count,
    gl_ref, never gets down to zero and bounce back up again. What was
    happening during umount is that function gfs2_put_super was dequeing
    its glocks for well-known files. In particular, we saw it on the
    journal glock, sd_jinode_gh. The dequeue caused delayed work to be
    queued for the glock state machine, to transition the lock to an
    "unlocked" state. While the work was still queued, gfs2_put_super
    called gfs2_gl_hash_clear to clear out the glock hash tables.
    If the timing was just so, the glock work function would drop the
    reference count at the time when it was being checked for zero,
    and that caused BUG() to be called. This patch calls
    flush_workqueue before clearing the glock hash tables, thereby
    ensuring that the delayed work is executed before the hash tables
    are cleared, and therefore the reference count never goes to zero
    until the glock is cleared.
    
    Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
    Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
    222cb538