Russell King was reporting lots of warnings when he compiled his kernel

with ftrace enabled. With some investigation it was discovered that it
 was his compile setup. He was using ccache with hard links, which allowed
 recordmcount to process the same .o twice. When this happens, recordmcount
 will detect that it was already done and give a warning about it.
 
 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.
 
 As you did not like the fact that recordmcount modified the file in place
 and thought that it should do the modifications in memory and then write
 it out to disk and move it over the old file to prevent other more subtle
 issues like the one above, a second patch is added on top of Russell's to
 do just that. Luckily the original code had write and lseek wrappers that
 I was able to modify to not do inplace writes, but simply keep track
 of the changes made in memory. When a write is made, a "update" flag is
 set, and at the end of processing, if the update is set, then it writes
 the file with changes out to a new file, and then renames it over the
 original one.
 
 The file descriptor is still passed to the write and lseek wrappers because
 removing that would cause the change to be more intrusive. That can be
 removed in a follow up cleanup patch that can wait till the next merge
 window.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJWerqKAAoJEKKk/i67LK/80W0H/jbzBL4siTTenA0eZLmsxT8k
 nbAM4fpdylpqUc6ku3QwjqqvbYxaLhiQsDtsVgXEoV7eelDgBedOSvCCrpZXn5co
 y1VEunRfOIWMKLmoAdFUagWxdX25Pu9V6g74kdUwaiNnMtCy7+Ds7x8OwqASyd7t
 e1WAhQ63ovslN88hHpkQVxCApYaocyPgU1lysBpN9dmvUS7Vkt/Bl4xhlVclnQKS
 3QbPWXtS/alCOOYj/Fa71Lfi2GhDx41Z6KPq6hFgph//oPHOSIvceNnimfT+ejjw
 1dKzM5EN386PhF3R27P+I0ovXnLNlCKmMZQUCUvlU/CjOOHHcIQNj8WHw9XB20k=
 =5TS2
 -----END PGP SIGNATURE-----

Merge tag 'trace-v4.4-rc4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull ftrace/recordmcount fix from Steven Rostedt:
 "Russell King was reporting lots of warnings when he compiled his
  kernel with ftrace enabled.  With some investigation it was discovered
  that it was his compile setup.  He was using ccache with hard links,
  which allowed recordmcount to process the same .o twice.  When this
  happens, recordmcount will detect that it was already done and give a
  warning about it.

  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.

  As you did not like the fact that recordmcount modified the file in
  place and thought that it should do the modifications in memory and
  then write it out to disk and move it over the old file to prevent
  other more subtle issues like the one above, a second patch is added
  on top of Russell's to do just that.  Luckily the original code had
  write and lseek wrappers that I was able to modify to not do inplace
  writes, but simply keep track of the changes made in memory.  When a
  write is made, a "update" flag is set, and at the end of processing,
  if the update is set, then it writes the file with changes out to a
  new file, and then renames it over the original one.

  The file descriptor is still passed to the write and lseek wrappers
  because removing that would cause the change to be more intrusive.
  That can be removed in a follow up cleanup patch that can wait till
  the next merge window"

* tag 'trace-v4.4-rc4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ftrace/scripts: Have recordmcount copy the object file
  scripts: recordmcount: break hardlinks
This commit is contained in:
Linus Torvalds 2015-12-26 19:48:09 -08:00
commit e2b0a16132