From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753511AbbIJPrP (ORCPT ); Thu, 10 Sep 2015 11:47:15 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:34507 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751323AbbIJPrL (ORCPT ); Thu, 10 Sep 2015 11:47:11 -0400 Date: Thu, 10 Sep 2015 11:47:06 -0400 From: Tejun Heo To: Joe Perches Cc: Rasmus Villemoes , Maurizio Lombardi , akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] lib/vsprintf.c: increase the size of the field_width variable Message-ID: <20150910154706.GG8114@mtj.duckdns.org> References: <1441793590-23856-1-git-send-email-mlombard@redhat.com> <1441816432.17219.57.camel@perches.com> <87mvwv4ea2.fsf@rasmusvillemoes.dk> <1441826799.17219.80.camel@perches.com> <20150910143629.GB8114@mtj.duckdns.org> <1441899685.17219.158.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441899685.17219.158.camel@perches.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, Joe. On Thu, Sep 10, 2015 at 08:41:25AM -0700, Joe Perches wrote: > On Thu, 2015-09-10 at 10:36 -0400, Tejun Heo wrote: > > On Wed, Sep 09, 2015 at 12:26:39PM -0700, Joe Perches wrote: > > > > > %*pb is meant for smallish bitmaps, not big ones. > [] > > The use case isn't from me, but why not? > > Imagine the output of the 500k bitmap if every other > bit is set. Yeah, but the caller still should be able to call, say, scnprintf() with a limited buffer and get the output till the end of the buffer along with the indication that the output has been truncated. > %*pb isn't capable of multiple line output and > seq_printf output would also fail as it uses k.alloc > memory not vmalloc. Heh, and it should fail. > I think that a more limited mechanism might be to use a > multiple line oriented function like print_hex_debug > and not try to emit the entire thing in a single go. I'm not that worried about the berserk cases which try to print a really long output on consoles but the subtle failure modes are worrying. > > Why are we even copying the struct on invocations? > > Only some functions modify the values after all. > > We might as well pass around pointer to the struct > > and let the callees wihch modify them copy the > > fields in local vars like normal functions. > > You are of course welcome and able to change it. > > btw: the current implementation has a limitation > on 32 bit arches as it uses an int argument for the > unsigned long count of bits in a bitmap. > > That's a bitmap that should not be printed anyway. That's 256Mbytes of bitmap. I don't think we need to worry about that at the moment. Thanks. -- tejun