Re: set_page_dirty vs set_page_dirty_lock

[Hugh Dickins <hugh@veritas.com>]

On Thu, 8 Dec 2005, Michael S. Tsirkin wrote:

> Hi!
> The comment at set_page_dirty_lock says:
> 
> /*
>  * set_page_dirty() is racy if the caller has no reference against
>  * page->mapping->host, and if the page is unlocked.  This is because another
>  * CPU could truncate the page off the mapping and then free the mapping.
>  *
>  * Usually, the page _is_ locked, or the caller is a user-space process which
>  * holds a reference on the inode by having an open file.
>  *
>  * In other cases, the page should be locked before running set_page_dirty().
>  */
> 
> Still, I wander whether it might be OK to use set_page_dirty
> in another case - if I previously got a reference to the page
> with get_user_pages?
> The page wouldnt be written back in this case, would it?

It might be, there's no guarantee not.  So if it was written back just
before you did your own dirtying of the page, you do need to set page dirty
again after (usually when releasing the pages got).  And get_user_pages is
a typical case when set_page_dirty_lock is really needed - you don't
usually have any hold on the inode (if any) that backs those pages.

It can be very inconvenient (I don't know what to do for drivers/scsi/sg.c
than set_page_dirty and hope for the best, since it cannot wait for a lock
where it needs to).  But I'm afraid you do have the very case where
set_page_dirty_lock is appropriate.

Many would be pleased if we could manage without set_page_dirty_lock.

> What if I'm in the middle of a system call?

What if you are?

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/