Dave Chinner wrote:
No this patch does not change the timing so it does not happen, it fixes
we don't properly understand. Using wait_event prevents the thread from
unless the test condition is actually true. The the bug here is we are
being woken up
No, it is not yet good. Pete cannot explain the underlying problem
and we need to understand if this is fixing the problem or just
with our test condition still being false.
And this patch catches that case and hence fixes the problem the
why is this happening in the first place. And yes that is an unanswered
Only the XFS code can cause it to be woken....
Do you know this for sure?
Wait queues are not affected by such events when they are
configured to be uninterruptable. The sv_t:
#define sv_wait(sv, pri, lock, s) \
_sv_wait(sv, lock, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT)
Is as uninterruptible as it comes. Which means only an explicit
wakeup will cause any waiters to wake up.
I added some tracing to sv_broadcast to trace anyone waking up the
the only time it was called was from the unpinning code well after the
thread had already
been woken up.
Done that, and it trips however it does not help us as there is no
Assert fail the machine when a dquot with a non-zero pincount is
woken in xfs_qm_dqunpin_wait(). If the assert trips, then we need
to work out how the pin count is getting elevated while we have
who woke us.
XFS does have references to wake_up in other spots for example in
xfs_super.c and xfs_buf.c
so I could add some tracing there, however the most ideal spot is in
so as soon as I have a chance I'll add some tracing there so we can work
out what's going on here.
Either way this patch resolves this issue and is a nice code cleanup.