On Tue, Dec 15, 2015 at 11:50 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> Russell fixed this by having recordmcount detect that the object file
> has more than one hard link, and if it does, it unlinks the object file
> after it maps it and processes then. This appears to fix the issue.
Ugh. Can we please fix it by simply not writing things in place.
The code seems to already just read (or mmap) the whole file into
memory anyway, why not just change the memory image, and then at the
end do a single write (maybe just a single "did I change anything"
flag to either do it all or nothing).
Doing partial in-place writes is not a pattern we should encourage in
the first place.
Linus
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html