On Wed, Sep 24, 2008 at 10:41:21AM -0400, Christoph Hellwig wrote:
> On Wed, Sep 24, 2008 at 05:46:04PM +1000, Dave Chinner wrote:
> > On Wed, Sep 24, 2008 at 05:42:38PM +1000, Lachlan McIlroy wrote:
> > > Looks good Pete.
> > 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
> > changing the timing so it doesn't show up....
> The patch does not only cause timing but also makes sure
> xfs_qm_dqunpin_wait sleeps again when woken up but the condition it was
> waiting on is not met. That's the reason why we have wait_event in
> Linux instead of the more traditional sv-style conditional variables.
> Now the spurious wakeup from scheduler argument doesn't make any sense,
> so this spurious wakeup we're protecting from must come from XFS itself.
> The way this could happen is when a task trying to pin the dquot gets
> qi_pinlock before the one waiting for q_pincount to reach zero.
Can't happen. To pin the dquot you have to hold the dquot lock. That
dquot lock is held by the one waiting for the q_pincount to reach
zero. i.e. pin and unpin_wait are mutually exclusive.
Also, qi_pinlock is a spinlock, so it should not be triggering
any spurious scheduler events that wake up threads sleeping on some
unrelated wait queue....