linux-toradex.git/lib/vsprintf.c, branch v4.6-rc3

sscanf: implement basic character sets

2016-03-17T22:09:34+00:00

Implement basic character sets for the '%[' conversion specifier.

The '%[' conversion specifier matches a nonempty sequence of characters
from the specified set of accepted (or with '^', rejected) characters
between the brackets.  The substring matched is to be made up of
characters in (or not in) the set.  This is useful for matching
substrings that are delimited by something other than spaces.

This implementation differs from its glibc counterpart in the following ways:
 (1) No support for character ranges (e.g., 'a-z' or '0-9')
 (2) The hyphen '-' is not a special character
 (3) The closing bracket ']' cannot be matched
 (4) No support (yet) for discarding matching input ('%*[')

The bitmap code is largely based upon sample code which was provided by
Rasmus.

The motivation for adding character set support to sscanf originally
stemmed from the kernel livepatching project.  An ongoing patchset
utilizes new livepatch Elf symbol and section names to store important
metadata livepatch needs to properly apply its patches.  Such metadata
is stored in these section and symbol names as substrings delimited by
periods '.' and commas ','.  For example, a livepatch symbol name might
look like this:

.klp.sym.vmlinux.printk,0

However, sscanf currently can only extract "substrings" delimited by
whitespace using the "%s" specifier.  Thus for the above symbol name,
one cannot not use sscanf() to extract substrings "vmlinux" or
"printk", for example.  A number of discussions on the livepatch
mailing list dealing with string parsing code for extracting these '.'
and ',' delimited substrings eventually led to the conclusion that such
code would be completely unnecessary if the kernel sscanf() supported
character sets.  Thus only a single sscanf() call would be necessary to
extract these substrings.  In addition, such an addition to sscanf()
could benefit other areas of the kernel that might have a similar need
in the future.

[akpm@linux-foundation.org: 80-col tweaks]
Signed-off-by: Jessica Yu 
Signed-off-by: Rasmus Villemoes 
Cc: Andy Shevchenko 
Cc: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm, printk: introduce new format string for flags

2016-03-15T23:55:16+00:00

In mm we use several kinds of flags bitfields that are sometimes printed
for debugging purposes, or exported to userspace via sysfs.  To make
them easier to interpret independently on kernel version and config, we
want to dump also the symbolic flag names.  So far this has been done
with repeated calls to pr_cont(), which is unreliable on SMP, and not
usable for e.g.  sysfs export.

To get a more reliable and universal solution, this patch extends
printk() format string for pointers to handle the page flags (%pGp),
gfp_flags (%pGg) and vma flags (%pGv).  Existing users of
dump_flag_names() are converted and simplified.

It would be possible to pass flags by value instead of pointer, but the
%p format string for pointers already has extensions for various kernel
structures, so it's a good fit, and the extra indirection in a
non-critical path is negligible.

[linux@rasmusvillemoes.dk: lots of good implementation suggestions]
Signed-off-by: Vlastimil Babka 
Acked-by: Michal Hocko 
Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Rasmus Villemoes 
Cc: Joonsoo Kim 
Cc: Minchan Kim 
Cc: Sasha Levin 
Cc: "Kirill A. Shutemov" 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vsprintf: kptr_restrict is okay in IRQ when 2

2016-02-12T02:35:48+00:00

The kptr_restrict flag, when set to 1, only prints the kernel address
when the user has CAP_SYSLOG.  When it is set to 2, the kernel address
is always printed as zero.  When set to 1, this needs to check whether
or not we're in IRQ.

However, when set to 2, this check is unneccessary, and produces
confusing results in dmesg.  Thus, only make sure we're not in IRQ when
mode 1 is used, but not mode 2.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Jason A. Donenfeld 
Cc: Rasmus Villemoes 
Cc: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/vsprintf: factor out %pN[F] handler as netdev_bits()

2016-01-16T19:17:30+00:00

Move switch case to the netdev_features_string() and rename it to
netdev_bits().  In the future we can extend it as needed.

Here we replace the fallback of %pN from '%p' with possible flags to
sticter '0x%p' without any flags variation.

Signed-off-by: Andy Shevchenko 
Cc: Rasmus Villemoes 
Cc: Joe Perches 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/vsprintf: refactor duplicate code to special_hex_number()

2016-01-16T19:17:30+00:00

special_hex_number() is a helper to print a fixed size type in a hex
format with '0x' prefix, zero padding, and small letters.  In the module
we have already several copies of such code.  Consolidate them under
special_hex_number() helper.

There are couple of differences though.

It seems nobody cared about the output in case of CONFIG_KALLSYMS=n,
when printing symbol address, because the asked field width is not
enough to care last 2 characters in the string represantation of the
pointer.  Fixed here.

The %pNF specifier used to be allowed with a specific field width,
though there is neither any user of it nor mention the possibility in
the documentation.

Signed-off-by: Andy Shevchenko 
Cc: Rasmus Villemoes 
Cc: Joe Perches 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/vsprintf.c: warn about too large precisions and field widths

2016-01-16T19:17:27+00:00

The field width is overloaded to pass some extra information for some %p
extensions (e.g.  #bits for %pb).  But we might silently truncate the
passed value when we stash it in struct printf_spec (see e.g.
"lib/vsprintf.c: expand field_width to 24 bits").  Hopefully 23 value
bits should now be enough for everybody, but if not, let's make some
noise.

Do the same for the precision.  In both cases, clamping seems more
sensible than truncating.  While, according to POSIX, "A negative
precision is taken as if the precision were omitted.", the kernel's
printf has always treated that case as if the precision was 0, so we use
that as lower bound.  For the field width, the smallest representable
value is actually -(1<<23), but a negative field width means 'set the
LEFT flag and use the absolute value', so we want the absolute value to
fit.

Signed-off-by: Rasmus Villemoes 
Cc: Al Viro 
Cc: Andy Shevchenko 
Cc: Ingo Molnar 
Cc: Joe Perches 
Cc: Kees Cook 
Cc: Maurizio Lombardi 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/vsprintf.c: help gcc make number() smaller

2016-01-16T19:17:26+00:00

One consequence of the reorganization of struct printf_spec to make
field_width 24 bits was that number() gained about 180 bytes.  Since
spec is never passed to other functions, we can help gcc make number()
lose most of that extra weight by using local variables for the field
width and precision.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Rasmus Villemoes 
Cc: Al Viro 
Cc: Ingo Molnar 
Cc: Joe Perches 
Cc: Kees Cook 
Cc: Maurizio Lombardi 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/vsprintf.c: expand field_width to 24 bits

2016-01-16T19:17:26+00:00

Maurizio Lombardi reported a problem [1] with the %pb extension: It
doesn't work for sufficiently large bitmaps, since the size is stashed
in the field_width field of the struct printf_spec, which is currently
an s16.  Concretely, this manifested itself in
/sys/bus/pseudo/drivers/scsi_debug/map being empty, since the bitmap
printer got a size of 0, which is the 16 bit truncation of the actual
bitmap size.

We do want to keep struct printf_spec at 8 bytes so that it can cheaply
be passed by value.  The qualifier field is only used for internal
bookkeeping in format_decode, so we might as well use a local variable
for that.  This gives us an additional 8 bits, which we can then use for
the field width.

To stay in 8 bytes, we need to do a little rearranging and make the type
member a bitfield as well.  For consistency, change all the members to
bit fields.  gcc doesn't generate much worse code with these changes (in
fact, bloat-o-meter says we save 300 bytes - which I think is a little
surprising).

I didn't find a BUILD_BUG/compiletime_assertion/... which would work
outside function context, so for now I just open-coded it.

[1] http://thread.gmane.org/gmane.linux.kernel/2034835

[akpm@linux-foundation.org: avoid open-coded BUILD_BUG_ON]
Signed-off-by: Rasmus Villemoes 
Reported-by: Maurizio Lombardi 
Acked-by: Tejun Heo 
Cc: Al Viro 
Cc: Andy Shevchenko 
Cc: Ingo Molnar 
Cc: Joe Perches 
Cc: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/vsprintf.c: eliminate potential race in string()

2016-01-16T19:17:26+00:00

If the string corresponding to a %s specifier can change under us, we
might end up copying a \0 byte to the output buffer.  There might be
callers who expect the output buffer to contain a genuine C string whose
length is exactly the snprintf return value (assuming truncation hasn't
happened or has been checked for).

We can avoid this by only passing over the source string once, stopping
the first time we meet a nul byte (or when we reach the given
precision), and then letting widen_string() handle left/right space
padding.  As a small bonus, this code reuse also makes the generated
code slightly smaller.

Signed-off-by: Rasmus Villemoes 
Cc: Al Viro 
Cc: Andy Shevchenko 
Cc: Ingo Molnar 
Cc: Joe Perches 
Cc: Kees Cook 
Cc: Maurizio Lombardi 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/vsprintf.c: move string() below widen_string()

2016-01-16T19:17:26+00:00

This is pure code movement, making sure the widen_string() helper is
defined before the string() function.

Signed-off-by: Rasmus Villemoes 
Cc: Al Viro 
Cc: Andy Shevchenko 
Cc: Ingo Molnar 
Cc: Joe Perches 
Cc: Kees Cook 
Cc: Maurizio Lombardi 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds