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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
