All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [PATCH] mm: Don't forget to set softdirty on file mapped fault
Date: Wed, 9 Jul 2014 00:54:48 +0400	[thread overview]
Message-ID: <20140708205448.GH17860@moon.sw.swsoft.com> (raw)
In-Reply-To: <20140708134511.4a32b7400a952541a31e9078@linux-foundation.org>

On Tue, Jul 08, 2014 at 01:45:11PM -0700, Andrew Morton wrote:
> 
> The user doesn't know or care about pte bits.
> 
> What actually *happens*?  Does criu migration hang?  Does it lose data?
> Does it take longer?

Ah, I see. Yes, the softdirty bit might be lost that usespace program
won't see that a page was modified. So data lose is possible.

> IOW, what would an end-user's bug report look like?
> 
> It's important to think this way because a year from now some person
> we've never heard of may be looking at a user's bug report and
> wondering whether backporting this patch will fix it.  Amongst other
> reasons.

Here is updated changelog, sounds better?
---

In case if page fault happend on dirty filemapping the newly created pte
may loose softdirty bit thus if a userspace program is tracking memory
changes with help of a memory tracker (CONFIG_MEM_SOFT_DIRTY) it might
miss modification of a memory page (which in worts case may lead to
data inconsistency).

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [PATCH] mm: Don't forget to set softdirty on file mapped fault
Date: Wed, 9 Jul 2014 00:54:48 +0400	[thread overview]
Message-ID: <20140708205448.GH17860@moon.sw.swsoft.com> (raw)
In-Reply-To: <20140708134511.4a32b7400a952541a31e9078@linux-foundation.org>

On Tue, Jul 08, 2014 at 01:45:11PM -0700, Andrew Morton wrote:
> 
> The user doesn't know or care about pte bits.
> 
> What actually *happens*?  Does criu migration hang?  Does it lose data?
> Does it take longer?

Ah, I see. Yes, the softdirty bit might be lost that usespace program
won't see that a page was modified. So data lose is possible.

> IOW, what would an end-user's bug report look like?
> 
> It's important to think this way because a year from now some person
> we've never heard of may be looking at a user's bug report and
> wondering whether backporting this patch will fix it.  Amongst other
> reasons.

Here is updated changelog, sounds better?
---

In case if page fault happend on dirty filemapping the newly created pte
may loose softdirty bit thus if a userspace program is tracking memory
changes with help of a memory tracker (CONFIG_MEM_SOFT_DIRTY) it might
miss modification of a memory page (which in worts case may lead to
data inconsistency).

  reply	other threads:[~2014-07-08 20:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-08 19:21 [PATCH] mm: Don't forget to set softdirty on file mapped fault Cyrill Gorcunov
2014-07-08 19:21 ` Cyrill Gorcunov
2014-07-08 19:28 ` Pavel Emelyanov
2014-07-08 19:28   ` Pavel Emelyanov
2014-07-08 20:19 ` Andrew Morton
2014-07-08 20:19   ` Andrew Morton
2014-07-08 20:40   ` Cyrill Gorcunov
2014-07-08 20:40     ` Cyrill Gorcunov
2014-07-08 20:45     ` Andrew Morton
2014-07-08 20:45       ` Andrew Morton
2014-07-08 20:54       ` Cyrill Gorcunov [this message]
2014-07-08 20:54         ` Cyrill Gorcunov
2014-07-08 21:05         ` Andrew Morton
2014-07-08 21:05           ` Andrew Morton
2014-07-08 21:15           ` Cyrill Gorcunov
2014-07-08 21:15             ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140708205448.GH17860@moon.sw.swsoft.com \
    --to=gorcunov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.