From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753937AbbIJOoU (ORCPT ); Thu, 10 Sep 2015 10:44:20 -0400 Received: from mail-pa0-f53.google.com ([209.85.220.53]:33894 "EHLO mail-pa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752842AbbIJOnz (ORCPT ); Thu, 10 Sep 2015 10:43:55 -0400 Date: Thu, 10 Sep 2015 10:43:51 -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: <20150910144351.GC8114@mtj.duckdns.org> References: <1441793590-23856-1-git-send-email-mlombard@redhat.com> <1441816432.17219.57.camel@perches.com> <87mvwv4ea2.fsf@rasmusvillemoes.dk> <55F12B94.30503@redhat.com> <1441870684.17219.132.camel@perches.com> <87613ik8r9.fsf@rasmusvillemoes.dk> <1441873056.17219.139.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441873056.17219.139.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, On Thu, Sep 10, 2015 at 01:17:36AM -0700, Joe Perches wrote: > > It also won't work for the case at hand if/when the actual bitmap ever > > gets a bit set beyond S16_MAX. > > But at least it should work for the bitmap sized <= S16_MAX > which should be the majority of uses. The failure mode is too subtle and this is a utility function which is too fundamental. I think we really should just get it working properly. > > A (somewhat ugly?) solution might be to teach %pb another flag, say h (for > > huge), meaning that the pointer is actually (struct printf_bitmap*), > > with > > > > struct printf_bitmap { unsigned long *bits; unsigned long nbits; } > > > > Then callers with potentially huge bitmaps would do > > > > struct printf_bitmap tmp = { my_bitmap, my_size }; > > snprintf("%pbhl", &tmp) > > Yes, but it still couldn't work without the ability to have > large output buffers and printk doesn't support that. printk overrunning its output buffer is fine. We've always had that and while we probably should do a better job of indicating those events, when the output line runs off that long, people (and it's usually human minds that process printk outputs) already kinda suspect that. Long bitmaps don't mean long output and silently formatting the wrong output sounds like a pretty bad idea and that because we can't make the width field 32bit? It doesn't make any sense. > seq_printf might have some performance issue with it too as > it would repetitively try to emit, fail, and grow the buffer. That's kinda beside the point here. Thanks. -- tejun