From: Dave Hansen <dave.hansen@intel.com>
To: Xiao Guangrong <guangrong.xiao@linux.intel.com>,
pbonzini@redhat.com, akpm@linux-foundation.org, mhocko@suse.com,
dan.j.williams@intel.com
Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, stefanha@redhat.com,
yuhuang@redhat.com, linux-mm@kvack.org,
ross.zwisler@linux.intel.com
Subject: Re: [PATCH] Fix region lost in /proc/self/smaps
Date: Wed, 7 Sep 2016 09:34:26 -0700 [thread overview]
Message-ID: <57D04192.5070704@intel.com> (raw)
In-Reply-To: <1473231111-38058-1-git-send-email-guangrong.xiao@linux.intel.com>
On 09/06/2016 11:51 PM, Xiao Guangrong wrote:
> In order to fix this bug, we make 'file->version' indicate the next VMA
> we want to handle
This new approach makes it more likely that we'll skip a new VMA that
gets inserted in between the read()s. But, I guess that's OK. We don't
exactly claim to be giving super up-to-date data at the time of read().
With the old code, was there also a case that we could print out the
same virtual address range more than once? It seems like that could
happen if we had a VMA split between two reads.
I think this introduces one oddity: if you have a VMA merge between two
reads(), you might get the same virtual address range twice in your
output. This didn't happen before because we would have just skipped
over the area that got merged.
Take two example VMAs:
vma-A: (0x1000 -> 0x2000)
vma-B: (0x2000 -> 0x3000)
read() #1: prints vma-A, sets m->version=0x2000
Now, merge A/B to make C:
vma-C: (0x1000 -> 0x3000)
read() #2: find_vma(m->version=0x2000), returns vma-C, prints vma-C
The user will see two VMAs in their output:
A: 0x1000->0x2000
C: 0x1000->0x3000
Will it confuse them to see the same virtual address range twice? Or is
there something preventing that happening that I'm missing?
--
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>
next prev parent reply other threads:[~2016-09-07 23:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-07 6:51 [PATCH] Fix region lost in /proc/self/smaps Xiao Guangrong
2016-09-07 7:05 ` Xiao Guangrong
2016-09-07 16:34 ` Dave Hansen [this message]
2016-09-08 3:36 ` Xiao Guangrong
2016-09-08 14:05 ` Dave Hansen
2016-09-09 8:19 ` Xiao Guangrong
2016-09-09 16:47 ` Dave Hansen
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=57D04192.5070704@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=gleb@kernel.org \
--cc=guangrong.xiao@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=ross.zwisler@linux.intel.com \
--cc=stefanha@redhat.com \
--cc=yuhuang@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).