On Fri, Aug 2, 2013 at 2:27 AM, Sage Weil <sage@xxxxxxxxxxx> wrote:
> On Thu, 1 Aug 2013, Yan, Zheng wrote:
>> On Thu, Aug 1, 2013 at 7:51 PM, Sha Zhengju <handai.szj@xxxxxxxxx> wrote:
>> > From: Sha Zhengju <handai.szj@xxxxxxxxxx>
>> >
>> > Following we will begin to add memcg dirty page accounting around
>> __set_page_dirty_
>> > {buffers,nobuffers} in vfs layer, so we'd better use vfs interface to
>> avoid exporting
>> > those details to filesystems.
>> >
>> > Signed-off-by: Sha Zhengju <handai.szj@xxxxxxxxxx>
>> > ---
>> > fs/ceph/addr.c | 13 +------------
>> > 1 file changed, 1 insertion(+), 12 deletions(-)
>> >
>> > diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
>> > index 3e68ac1..1445bf1 100644
>> > --- a/fs/ceph/addr.c
>> > +++ b/fs/ceph/addr.c
>> > @@ -76,7 +76,7 @@ static int ceph_set_page_dirty(struct page *page)
>> > if (unlikely(!mapping))
>> > return !TestSetPageDirty(page);
>> >
>> > - if (TestSetPageDirty(page)) {
>> > + if (!__set_page_dirty_nobuffers(page)) {
>> it's too early to set the radix tree tag here. We should set page's snapshot
>> context and increase the i_wrbuffer_ref first. This is because once the tag
>> is set, writeback thread can find and start flushing the page.
>
> Unfortunately I only remember being frustrated by this code. :) Looking
> at it now, though, it seems like the minimum fix is to set the
> page->private before marking the page dirty. I don't know the locking
> rules around that, though. If that is potentially racy, maybe the safest
> thing would be if __set_page_dirty_nobuffers() took a void* to set
> page->private to atomically while holding the tree_lock.
>
Sorry, I don't catch the point of your last sentence... Could you
please explain it again?
I notice there is a check in __set_page_dirty_nobuffers():
WARN_ON_ONCE(!PagePrivate(page) && !PageUptodate(page));
So does it mean we can only set page->private after it? but if so the
__mark_inode_dirty is still ahead of setting snapc.
Thanks,
Sha
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
