From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753233AbbD0QaH (ORCPT ); Mon, 27 Apr 2015 12:30:07 -0400 Received: from mail-vn0-f47.google.com ([209.85.216.47]:40732 "EHLO mail-vn0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753037AbbD0QaE (ORCPT ); Mon, 27 Apr 2015 12:30:04 -0400 Date: Mon, 27 Apr 2015 12:30:00 -0400 From: Tejun Heo To: Sudeep Holla Cc: "linux-kernel@vger.kernel.org" , Pawel Moll , Andrew Morton , "Peter Zijlstra (Intel)" Subject: Re: [PATCH] bitmap: remove explicit newline handling using scnprintf format string Message-ID: <20150427163000.GG1499@htj.duckdns.org> References: <1430128018-14667-1-git-send-email-sudeep.holla@arm.com> <20150427161434.GF1499@htj.duckdns.org> <553E6328.2040904@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <553E6328.2040904@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Sudeep. On Mon, Apr 27, 2015 at 05:26:16PM +0100, Sudeep Holla wrote: > Completely agree and in-fact we did discuss that internally too. > But since this function deals only with page size buffers, we thought > it's highly unlikely to hit that corner case. Ah, yeah, right. It'd probably be worthwhile to document the above in the description tho. > >Given that bitmap outputs can be pretty long, this behavior > >difference has a minute but still non-zero chance of causing something > >surprising. There are multiple copies of the above function in arch > >codes too. > > I assumed that I had consolidated most of them in commit 5aaba36318e5 > ("cpumask: factor out show_cpumap into separate helper function"). > I might have missed, will have a look at it again. I noticed them while %pb[l] conversion but was too lazy to actually do anything. Thanks a lot for actually taking care of them. > >We prolly want to audit the usages to verify that the > >passed in buffer is always big enough at which point the above > >function and its copies can simply be replaced with direct scnprintf() > >calls. This function doesn't actually add anything. > > Ah, right that would be much simpler. Yeah, let's get rid of it. Thanks. -- tejun