Re: [rfc][patch] remove racy sync_page?

[Hugh Dickins <hugh@veritas.com>]

On Wed, 31 May 2006, Nick Piggin wrote:
> Hugh Dickins wrote:
> > lock_page forbids it from being called from anywhere that can't
> > sleep, which is often just where we want to call it from.  Neil's
> > suggestion, using a spin_lock against the mapping changing, would
> > help there; but seems like more work than I'd want to get into.
> 
> But making PG_lock a spinning lock is completely unrelated to the
> bug at hand.

Neil wasn't suggesting making PG_lock a spinning lock, he was
suggesting a further bit used that way.  And I thought his suggestion
was relevant to the bug at hand.  But it's not the way I'd like to go.

> > So, although I think lock_page_nosync fixes the bug (at least in
> > that one place we've identified there's likely to be such a bug),
> > it seems to be aiming at the wrong target.  I'm pacing and thinking,
> > doubt I'll come up with anything better, please don't hold breath.
> 
> It is the correct target. I know all about your set_page_dirty_lock
> problems, but they aren't what I'm trying to fix.

Yes, I had noticed yours is a different issue.  I'm saying that if we
can "fix" set_page_dirty_nolock not to sleep, then your issue is fixed
(as least as it affects set_page_dirty_lock, which is all your patch
is dealing with, and we hope all it needs to deal with).  Because your
issue is with the sync_page in the lock_page of set_page_dirty_nolock,
and it's that particular lock_page which I'm trying to be rid of.

I now think it can be done: in cases where TestSetPageLocked finds
the page already locked, then I believe we can fall back to inode_lock
to stabilize.  But I do need to consider the possibilities some more.

> AFAIKS, you could also make set_page_dirty_lock non sleeping quite
> easily by making inode slabs RCU freed.

Which would equally deal with your issue.  Yes, but it's always
seemed to me too great a risk, to add an RCU delay into such
significant slab shrinking - I don't want to handle the fallout.

> What places want to use set_page_dirty_lock without sleeping?
> The only place in drivers/ apart from sg/st that SetPageDirty are
> rd.c and via_dmablit.c, both of which look OK, if a bit crufty.

I've not looked recently, but bio.c sticks in the mind as one which
is pushed to the full contortions to allow for sleeping there.

Hugh