From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753250AbbLWPU2 (ORCPT ); Wed, 23 Dec 2015 10:20:28 -0500 Received: from mail.kernel.org ([198.145.29.136]:60413 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752673AbbLWPUZ (ORCPT ); Wed, 23 Dec 2015 10:20:25 -0500 Message-Id: <20151223151703.225805170@goodmis.org> User-Agent: quilt/0.61-1 Date: Wed, 23 Dec 2015 10:17:03 -0500 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Linus Torvalds , Ingo Molnar , Andrew Morton , Russell King Subject: [PATCH 0/2] [GIT PULL] ftrace/recordmcount: Fix hardlink issue with ccache Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus, [ Well, as you know, my test box was not suffering from a harddrive failure, but a bug in the block layer. After wasting several days to figure that out, I got my test box up and running again, and was able to complete my testing. ] 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. Please pull the latest trace-v4.4-rc4-2 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-v4.4-rc4-2 Tag SHA1: c8eaa389dd82351cf142d7b5419964dede5e797b Head SHA1: a50bd43935586420fb75f4558369eb08566fac5e Russell King (1): scripts: recordmcount: break hardlinks Steven Rostedt (Red Hat) (1): ftrace/scripts: Have recordmcount copy the object file ---- scripts/recordmcount.c | 137 ++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 113 insertions(+), 24 deletions(-)