Well I added some tracing code to the __wake_up_common, however it never
which made me think "are we even being woken up from the wait queue", or
directly waking us up from the task struct. So I had a look and found
Still, don't check it in until we understand whether sv_t's are
completely broken or not...
mp->m_ail.xa_target = threshold_lsn;
Which is indirectly called from xlog_grant_push_ail, which is called
from various other
In fact this bug is not restricted to the aild the xfssyncd also hit
this issue a number of times
during todays testing where it was woken while waiting on sv_wait for
the pincount to drop
It also is woken up from a number of functions in xfs_super.c including
xfs_syncd_queue_work(), xfs_sync_worker(), xfs_fs_sync_super()
The change that introduced the wake_up on the aild was introduced from
Move AIL pushing into it's own thread
However xfssyncd has had a long history of the task being woken up from
so it looks like it's simply not safe for either the aild or xfssyncd to
sleep on a queue assuming that
no one else will wake the processes up.
So I would say the fix I proposed is a good solution for this issue.
However there are other functions that use sv_wait and should also be
fixed in a similar way so I'll
look into the other callers and prepare a patch tomorrow.