Re: [PATCH] Fix region lost in /proc/self/smaps
From: Xiao Guangrong
Date: Wed Sep 07 2016 - 23:41:59 EST
On 09/08/2016 12:34 AM, Dave Hansen wrote:
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().
Yes, I completely agree with you. :)
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.
Yes.
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?
You are right. Nothing can prevent it.
However, it is not easy to handle the case that the new VMA overlays with the old VMA
already got by userspace. I think we have some choices:
1: One way is completely skipping the new VMA region as current kernel code does but i
do not think this is good as the later VMAs will be dropped.
2: show the un-overlayed portion of new VMA. In your case, we just show the region
(0x2000 -> 0x3000), however, it can not work well if the VMA is a new created
region with different attributions.
3: completely show the new VMA as this patch does.
Which one do you prefer?
Thanks!