From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2807D7F3F for ; Fri, 11 Oct 2013 16:59:09 -0500 (CDT) Message-ID: <525874AA.9020300@sgi.com> Date: Fri, 11 Oct 2013 16:59:06 -0500 From: Mark Tinguely MIME-Version: 1.0 Subject: Re: [PATCH 1/4] xfs: remove newlines from 3 xfs_alert_tag error strings References: <52584C8A.1060808@redhat.com> <52584D04.3020907@sandeen.net> In-Reply-To: <52584D04.3020907@sandeen.net> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Eric Sandeen Cc: Eric Sandeen , xfs-oss On 10/11/13 14:09, Eric Sandeen wrote: > xfs_alert_tag passes the format string to __xfs_printk, > which adds its own "\n". Having it in the original string > leads to unintentional blank lines from these messages. > > Most format strings have no newline, but these 3 do, leading to > i.e.: > > [ 7347.119911] XFS (sdb2): Access to block zero in inode 132 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a05 > [ 7347.119911] > [ 7347.119919] XFS (sdb2): Access to block zero in inode 132 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a05 > [ 7347.119919] > > Signed-off-by: Eric Sandeen > Reviewed-by: Carlos Maiolino > --- Is this true of xfs_alert() too? ie the newline in xfs_alert in xfs_dir2_leafn_rebalance(). The newline in xfs_alert() in xlog_unpack_data_crc() looks intentional. --Mark. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs