Hi Ross, ----- Original Message ----- > 6. gfs2_log_flush() continues and calls revoke_lo_after_commit() and > uses the freed glock (stack trace above). > > Should evict_inode call gfs2_ail_flush() or something so that the revoke > is written before it drops its reference to the glock? > > Or is there something else that is meant to keep the glock around if the > inode is evicted while there is a linked gfs2_bufdata sitting on some > AIL list? > > Let me know if any more specific information is needed since I now have > a test setup that can usually reproduce this within 10 minutes.
Very interesting. It's not unusual for glocks to outlive their inodes, but I'm not sure what the right answer is in this case. Either the revoke should take an additional reference to the glock, and not let go until the revoke is written by some log flush, or else the evict needs to do the log flush to make sure the revoke is committed. But we've had issues with evict in the past, so we need to be careful about how we fix it. Andreas and I will look into the best way to fix it. Thanks again for your help. Regards, Bob Peterson Red Hat File Systems
