user/sven/linux.git/lib/vsprintf.c, branch v4.0

lib/vsprintf: implement bitmap printing through '%*pb[l]'

2015-02-14T05:21:36Z

bitmap and its derivatives such as cpumask and nodemask currently only provide formatting functions which put the output string into the provided buffer; however, how long this buffer should be isn't defined anywhere and given that some of these bitmaps can be too large to be formatted into an on-stack buffer it users sometimes are unnecessarily forced to come up with creative solutions and compromises for the buffer just to printk these bitmaps. There have been a couple different attempts at making this easier. 1. Way back, PeterZ tried printk '%pb' extension with the precision for bit width - '%.*pb'. This was intuitive and made sense but unfortunately triggered a compile warning about using precision for a pointer. http://lkml.kernel.org/g/1336577562.2527.58.camel@twins 2. I implemented bitmap_pr_cont[_list]() and its wrappers for cpumask and nodemask. This works but PeterZ pointed out that pr_cont's tendency to produce broken lines when multiple CPUs are printing is bothering considering the usages. http://lkml.kernel.org/g/1418226774-30215-3-git-send-email-tj@kernel.org So, this patch is another attempt at teaching printk and friends how to print bitmaps. It's almost identical to what PeterZ tried with precision but it uses the field width for the number of bits instead of precision. The format used is '%*pb[l]', with the optional trailing 'l' specifying list format instead of hex masks. This is a valid format string and doesn't trigger compiler warnings; however, it does make it impossible to specify output field width when printing bitmaps. I think this is an acceptable trade-off given how much easier it makes printing bitmaps and that we don't have any in-kernel user which is using the field width specification. If any future user wants to use field width with a bitmap, it'd have to format the bitmap into a string buffer and then print that buffer with width spec, which isn't different from how it should be done now. This patch implements bitmap[_list]_string() which are called from the vsprintf pointer() formatting function. The implementation is mostly identical to bitmap_scn[list]printf() except that the output is performed in the vsprintf way. These functions handle formatting into too small buffers and sprintf() family of functions report the correct overrun output length. bitmap_scn[list]printf() are now thin wrappers around scnprintf(). Signed-off-by: Tejun Heo Acked-by: Peter Zijlstra (Intel) Cc: "David S. Miller" Cc: "James E.J. Bottomley" Cc: "John W. Linville" Cc: "Paul E. McKenney" Cc: Benjamin Herrenschmidt Cc: Chris Metcalf Cc: Chris Zankel Cc: Christoph Lameter Cc: Dmitry Torokhov Cc: Fenghua Yu Cc: Greg Kroah-Hartman Cc: Ingo Molnar Cc: Li Zefan Cc: Max Filippov Cc: Mike Travis Cc: Pekka Enberg Cc: Russell King Cc: Rusty Russell Cc: Steffen Klassert Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Tony Luck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib/vsprintf.c: replace while with do-while in skip_atoi

2015-02-13T02:54:13Z

All callers of skip_atoi have already checked for the first character being a digit. In this case, gcc generates simpler code for a do while-loop. Signed-off-by: Rasmus Villemoes Cc: Jiri Kosina Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib/vsprintf.c: improve sanity check in vsnprintf()

2015-02-13T02:54:13Z

On 64 bit, size may very well be huge even if bit 31 happens to be 0. Somehow it doesn't feel right that one can pass a 5 GiB buffer but not a 3 GiB one. So cap at INT_MAX as was probably the intention all along. This is also the made-up value passed by sprintf and vsprintf. Signed-off-by: Rasmus Villemoes Cc: Jiri Kosina Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib/vsprintf.c: consume 'p' in format_decode

2015-02-13T02:54:13Z

It seems a little simpler to consume the p from a %p specifier in format_decode, just as it is done for the surrounding %c, %s and %% cases. While there, delete a redundant and misplaced comment. Signed-off-by: Rasmus Villemoes Cc: Jiri Kosina Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib/vsprintf: add %*pE[achnops] format specifier

2014-10-14T00:18:26Z

This allows user to print a given buffer as an escaped string. The rules are applied according to an optional mix of flags provided by additional format letters. For example, if the given buffer is: 1b 62 20 5c 43 07 22 90 0d 5d The result strings would be: %*pE "\eb \C\a"\220\r]" %*pEhp "\x1bb \C\x07"\x90\x0d]" %*pEa "\e\142\040\\\103\a\042\220\r\135" Please, read Documentation/printk-formats.txt and lib/string_helpers.c kernel documentation to get further information. [akpm@linux-foundation.org: tidy up comment layout, per Joe] Signed-off-by: Andy Shevchenko Suggested-by: Joe Perches Cc: "John W . Linville" Cc: Johannes Berg Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Documentation: Docbook: Fix generated DocBook/kernel-api.xml

2014-09-09T08:34:56Z

This patch fix spelling typo found in DocBook/kernel-api.xml. It is because the file is generated from the source comments, I have to fix the comments in source codes. Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina

lib/vsprintf.c: fix comparison to bool

2014-06-04T23:54:18Z

Fixing 2 coccinelle warnings: lib/vsprintf.c:2350:2-9: WARNING: Assignment of bool to 0/1 lib/vsprintf.c:2389:3-10: WARNING: Assignment of bool to 0/1 Signed-off-by: Fabian Frederick Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vsprintf: remove %n handling

2014-04-03T23:21:07Z

All in-kernel users of %n in format strings have now been removed and the %n directive is ignored. Remove the handling of %n so that it is treated the same as any other invalid format string directive. Keep a warning in place to deter new instances of %n in format strings. Signed-off-by: Ryan Mallon Acked-by: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vsprintf: Add support for IORESOURCE_UNSET in %pR

2014-02-26T21:42:09Z

Sometimes we have a struct resource where we know the type (MEM/IO/etc.) and the size, but we haven't assigned address space for it. The IORESOURCE_UNSET flag is a way to indicate this situation. For these "unset" resources, the start address is meaningless, so print only the size, e.g., - pci 0000:0c:00.0: reg 184: [mem 0x00000000-0x00001fff 64bit] + pci 0000:0c:00.0: reg 184: [mem size 0x2000 64bit] For %pr (printing with raw flags), we still print the address range, because %pr is mostly used for debugging anyway. Thanks to Fengguang Wu for suggesting resource_size(). Signed-off-by: Bjorn Helgaas

vsprintf: add %pad extension for dma_addr_t use

2014-01-24T00:36:56Z

dma_addr_t's can be either u32 or u64 depending on a CONFIG option. There are a few hundred dma_addr_t's printed via either cast to unsigned long long, unsigned long or no cast at all. Add %pad to be able to emit them without the cast. Update Documentation/printk-formats.txt too. Signed-off-by: Joe Perches Cc: "Shevchenko, Andriy" Cc: Rob Landley Cc: Laurent Pinchart Cc: Julia Lawall Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds