Re: [PATCH v4 1/2] mm, proc: Fix region lost in /proc/self/smaps

[Michal Hocko]

On Fri 07-10-16 10:17:22, Robert Hu wrote:
> On Mon, 2016-10-03 at 13:52 +0200, Michal Hocko wrote:
> > On Sat 01-10-16 12:42:37, Robert Ho wrote:
> > > Recently, Redhat reported that nvml test suite failed on QEMU/KVM,
> > > more detailed info please refer to:
> > >    https://bugzilla.redhat.com/show_bug.cgi?id=1365721
> > > 
> [trim...]
> > > 
> > > In order to fix this bug, we make 'file->version' indicate the end address
> > > of current VMA
> > 
> > I guess you wanted to finish that sentence, right?
> > "
> > m_start will then look up a vma which with vma_start < last_vm_end and
> > moves on to the next vma if we found the same or an overlapping vma.
> > This will guarantee that we will not miss an exclusive vma but we can
> > still miss one if the previous vma was shrunk. This is acceptable
> > because guaranteeing "never miss a vma" is simply not feasible. User has
> > to cope with some inconsistencies if the file is not read in one go.
> > "
> 
> Yes, you're right. Sorry that I didn't complement that in v4.
> I see the patch is already moved to -mm tree (by you?) with the above
> complemented. So I'm not supposed to work a v5 patch, am I right?

Andrew took the patch and updated the changelog. So there doesn't seem
to be any reason for v5 just for to update changelog. Unless you want to
have a different wording of course.

[...]
> > I am not sure how the two above are helpful as the patch has been
> > reworked basically.
> > 
> I might be wrong, I thought the change log should honestly write each
> version's changes, although it indeed looks confusing if looks at this
> single version only.
> 
> So I learned from you now that change log shall only reflect the final
> adopted changes only, right?

well, I would keep the changelog if it was helpful - aka small changes
along the way between different submissions - but it is much less useful
when the solution changes completely or way to much. Reader would have
a very limited context to understand those changes without reading the
original email threads anyway.

Anyway, thanks for your persistence!
-- 
Michal Hocko
SUSE Labs