21 May, 2016
2 commits
-
There are new helpers in this patch:
uuid_is_valid checks if a UUID is valid
uuid_be_to_bin converts from string to binary (big endian)
uuid_le_to_bin converts from string to binary (little endian)They will be used in future, i.e. in the following patches in the series.
This also moves the indices arrays to lib/uuid.c to be shared accross
modules.[andriy.shevchenko@linux.intel.com: fix typo]
Signed-off-by: Andy Shevchenko
Reviewed-by: Matt Fleming
Cc: Dmitry Kasatkin
Cc: Mimi Zohar
Cc: Rasmus Villemoes
Cc: Arnd Bergmann
Cc: "Theodore Ts'o"
Cc: Al Viro
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There are few functions here and there along with type definitions that
provide UUID API. This series consolidates everything under one hood
and converts current users.This has been tested for a while internally, however it doesn't mean we
covered all possible cases (especially accuracy of UUID constants after
conversion). So, please test this as much as you can and provide your
tag. We appreciate the effort.The ACPI conversion is postponed for now to sort more generic things out
first.This patch (of 9):
Since we have hex_byte_pack_upper() we may use it directly and avoid
second loop.Signed-off-by: Andy Shevchenko
Reviewed-by: Matt Fleming
Cc: Dmitry Kasatkin
Cc: Mimi Zohar
Cc: Rasmus Villemoes
Cc: Arnd Bergmann
Cc: "Theodore Ts'o"
Cc: Al Viro
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
18 Mar, 2016
1 commit
-
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
16 Mar, 2016
1 commit
-
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
12 Feb, 2016
1 commit
-
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
17 Jan, 2016
8 commits
-
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 -
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 -
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<
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 -
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 -
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 -
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 -
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 -
Pull out the logic in dentry_name() which handles field width space
padding, in preparation for reusing it from string(). Rename the
widen() helper to move_right(), since it is used for handling the
!(flags & LEFT) case.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
07 Jan, 2016
1 commit
-
This allow to directly print block_device name.
Currently one should use bdevname() with temporal char buffer.
This is very ineffective because bloat stack usage for deep IO call-tracesExample:
%pg -> sda, sda1 or loop0p1[AV: fixed a minor braino - position updates should not be dependent
upon having reached the of buffer]Signed-off-by: Dmitry Monakhov
Signed-off-by: Al Viro
07 Nov, 2015
5 commits
-
%n is no longer just ignored; it results in early return from vsnprintf.
Also add a request to add test cases for future %p extensions.Signed-off-by: Rasmus Villemoes
Reviewed-by: Martin Kletzander
Reviewed-by: Andy Shevchenko
Cc: Jonathan Corbet
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
As a quick
git grep -E '%[ +0#-]*#[ +0#-]*(\*|[0-9]+)?(\.(\*|[0-9]+)?)?p'
shows, nobody uses the # flag with %p. Should one try to do so, one
will be met withwarning: `#' flag used with `%p' gnu_printf format [-Wformat]
(POSIX and C99 both say "... For other conversion specifiers, the
behavior is undefined.". Obviously, the kernel can choose to define
the behaviour however it wants, but as long as gcc issues that
warning, users are unlikely to show up.)Since default_width is effectively always 2*sizeof(void*), we can
simplify the prologue of pointer() and save a few instructions.Signed-off-by: Rasmus Villemoes
Reviewed-by: Andy Shevchenko
Acked-by: Kees Cook
Cc: Martin Kletzander
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Quoting from 2aa2f9e21e4e ("lib/vsprintf.c: improve sanity check in
vsnprintf()"):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.I should have seen this copy-pasted instance back then, but let's just
do it now.Signed-off-by: Rasmus Villemoes
Reviewed-by: Andy Shevchenko
Acked-by: Kees Cook
Cc: Martin Kletzander
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
If we meet any invalid or unsupported format specifier, 'handling' it by
just printing it as a literal string is not safe: Presumably the format
string and the arguments passed gcc's type checking, but that means
something like sprintf(buf, "%n %pd", &intvar, dentry) would end up
interpreting &intvar as a struct dentry*.When the offending specifier was %n it used to be at the end of the format
string, but we can't rely on that always being the case. Also, gcc
doesn't complain about some more or less exotic qualifiers (or 'length
modifiers' in posix-speak) such as 'j' or 'q', but being unrecognized by
the kernel's printf implementation, they'd be interpreted as unknown
specifiers, and the rest of arguments would be interpreted wrongly.So let's complain about anything we don't understand, not just %n, and
stop pretending that we'd be able to make sense of the rest of the
format/arguments. If the offending specifier is in a printk() call we
unfortunately only get a "BUG: recent printk recursion!", but at least
direct users of the sprintf family will be caught.Signed-off-by: Rasmus Villemoes
Reviewed-by: Andy Shevchenko
Acked-by: Kees Cook
Cc: Martin Kletzander
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Move all pointer-formatting documentation to one place in the code and one
place in the documentation instead of keeping it in three places with
different level of completeness. Documentation/printk-formats.txt has
detailed information about each modifier, docstring above pointer() has
short descriptions of them (as that is the function dealing with %p) and
docstring above vsprintf() is removed as redundant. Both docstrings in
the code that were modified are updated with a reminder of updating the
documentation upon any further change.[akpm@linux-foundation.org: fix comment]
Signed-off-by: Martin Kletzander
Reviewed-by: Andy Shevchenko
Cc: Rasmus Villemoes
Cc: Jonathan Corbet
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
21 Jul, 2015
1 commit
-
This file uses the clk API so it should include clk.h directly
instead of indirectly including it through clk-provider.h.Acked-by: Geert Uytterhoeven
Signed-off-by: Stephen Boyd
17 Apr, 2015
2 commits
-
I hadn't had enough coffee when I wrote this. Currently, the final
increment of buf depends on the value loaded from the table, and
causes gcc to emit a cmov immediately before the return. It is smarter
to let it depend on r, since the increment can then be computed in
parallel with the final load/store pair. It also shaves 16 bytes of
.text.Signed-off-by: Rasmus Villemoes
Cc: Tejun Heo
Cc: Peter Zijlstra
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The most expensive part of decimal conversion is the divisions by 10
(albeit done using reciprocal multiplication with appropriately chosen
constants). I decided to see if one could eliminate around half of
these multiplications by emitting two digits at a time, at the cost of a
200 byte lookup table, and it does indeed seem like there is something
to be gained, especially on 64 bits. Microbenchmarking shows
improvements ranging from -50% (for numbers uniformly distributed in [0,
2^64-1]) to -25% (for numbers heavily biased toward the smaller end, a
more realistic distribution).On a larger scale, perf shows that top, one of the big consumers of /proc
data, uses 0.5-1.0% fewer cpu cycles.I had to jump through some hoops to get the 32 bit code to compile and run
on my 64 bit machine, so I'm not sure how relevant these numbers are, but
just for comparison the microbenchmark showed improvements between -30%
and -10%.The bloat-o-meter costs are around 150 bytes (the generated code is a
little smaller, so it's not the full 200 bytes) on both 32 and 64 bit.
I'm aware that extra cache misses won't show up in a microbenchmark as
used above, but on the other hand decimal conversions often happen in bulk
(for example in the case of top).I have of course tested that the new code generates the same output as the
old, for both the first and last 1e10 numbers in [0,2^64-1] and 4e9
'random' numbers in-between.Test and verification code on github: https://github.com/Villemoes/dec.
Signed-off-by: Rasmus Villemoes
Tested-by: Jeff Epler
Cc: "Peter Zijlstra (Intel)"
Cc: Tejun Heo
Cc: Joe Perches
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
16 Apr, 2015
7 commits
-
The current semantics of string_escape_mem are inadequate for one of its
current users, vsnprintf(). If that is to honour its contract, it must
know how much space would be needed for the entire escaped buffer, and
string_escape_mem provides no way of obtaining that (short of allocating a
large enough buffer (~4 times input string) to let it play with, and
that's definitely a big no-no inside vsnprintf).So change the semantics for string_escape_mem to be more snprintf-like:
Return the size of the output that would be generated if the destination
buffer was big enough, but of course still only write to the part of dst
it is allowed to, and (contrary to snprintf) don't do '\0'-termination.
It is then up to the caller to detect whether output was truncated and to
append a '\0' if desired. Also, we must output partial escape sequences,
otherwise a call such as snprintf(buf, 3, "%1pE", "\123") would cause
printf to write a \0 to buf[2] but leaving buf[0] and buf[1] with whatever
they previously contained.This also fixes a bug in the escaped_string() helper function, which used
to unconditionally pass a length of "end-buf" to string_escape_mem();
since the latter doesn't check osz for being insanely large, it would
happily write to dst. For example, kasprintf(GFP_KERNEL, "something and
then %pE", ...); is an easy way to trigger an oops.In test-string_helpers.c, the -ENOMEM test is replaced with testing for
getting the expected return value even if the buffer is too small. We
also ensure that nothing is written (by relying on a NULL pointer deref)
if the output size is 0 by passing NULL - this has to work for
kasprintf("%pE") to work.In net/sunrpc/cache.c, I think qword_add still has the same semantics.
Someone should definitely double-check this.In fs/proc/array.c, I made the minimum possible change, but longer-term it
should stop poking around in seq_file internals.[andriy.shevchenko@linux.intel.com: simplify qword_add]
[andriy.shevchenko@linux.intel.com: add missed curly braces]
Signed-off-by: Rasmus Villemoes
Acked-by: Andy Shevchenko
Signed-off-by: Andy Shevchenko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The helper hex_string() is broken in two ways. First, it doesn't
increment buf regardless of whether there is room to print, so callers
such as kasprintf() that try to probe the correct storage to allocate will
get a too small return value. But even worse, kasprintf() (and likely
anyone else trying to find the size of the result) pass NULL for buf and 0
for size, so we also have end == NULL. But this means that the end-1 in
hex_string() is (char*)-1, so buf < end-1 is true and we get a NULL
pointer deref. I double-checked this with a trivial kernel module that
just did a kasprintf(GFP_KERNEL, "%14ph", "CrashBoomBang").Nobody seems to be using %ph with kasprintf, but we might as well fix it
before it hits someone.Signed-off-by: Rasmus Villemoes
Acked-by: Andy Shevchenko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add format specifiers for printing struct clk:
- '%pC' or '%pCn': name (Common Clock Framework) or address (legacy
clock framework) of the clock,
- '%pCr': rate of the clock.[akpm@linux-foundation.org: omit code if !CONFIG_HAVE_CLK]
Signed-off-by: Geert Uytterhoeven
Cc: Jonathan Corbet
Cc: Mike Turquette
Cc: Stephen Boyd
Cc: Tetsuo Handa
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Making ZEROPAD == '0'-' ', we can eliminate a few more instructions.
Signed-off-by: Rasmus Villemoes
Cc: Peter Zijlstra
Cc: Tejun Heo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
gcc doesn't merge or overlap const char[] objects with identical contents
(probably language lawyers would also insist that these things have
different addresses), but there's no reason to have the string
"0123456789ABCDEF" occur in multiple places. hex_asc_upper is declared in
kernel.h and defined in lib/hexdump.c, which is unconditionally compiled
in.Signed-off-by: Rasmus Villemoes
Cc: Peter Zijlstra
Cc: Tejun Heo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
At least since the initial git commit, when base was passed as a separate
parameter, number() has only been called with bases 8, 10 and 16. I'm
guessing that 66 was to accommodate 64 0/1, a sign and a '\0', but the
buffer is only used for the actual digits. Octal digits carry 3 bits of
information, so 24 is enough. Spell that 3*sizeof(num) so one less place
needs to be changed should long long ever be 128 bits. Also remove the
commented-out code that would handle an arbitrary base.Signed-off-by: Rasmus Villemoes
Cc: Peter Zijlstra
Cc: Tejun Heo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Since FORMAT_TYPE_INT is simply 1 more than FORMAT_TYPE_UINT, and
similarly for BYTE/UBYTE, SHORT/USHORT, LONG/ULONG, we can eliminate a few
instructions by making SIGN have the value 1 instead of 2, and then use
arithmetic instead of branches for computing the right spec->type. It's a
little hacky, but certainly in the same spirit as SMALL needing to have
the value 0x20. For example for the spec->qualifier == 'l' case, gcc now
generates75e: 0f b6 53 01 movzbl 0x1(%rbx),%edx
762: 83 e2 01 and $0x1,%edx
765: 83 c2 09 add $0x9,%edx
768: 88 13 mov %dl,(%rbx)instead of
763: 0f b6 53 01 movzbl 0x1(%rbx),%edx
767: 83 e2 02 and $0x2,%edx
76a: 80 fa 01 cmp $0x1,%dl
76d: 19 d2 sbb %edx,%edx
76f: 83 c2 0a add $0xa,%edx
772: 88 13 mov %dl,(%rbx)Signed-off-by: Rasmus Villemoes
Cc: Peter Zijlstra
Cc: Tejun Heo
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Feb, 2015
1 commit
-
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
13 Feb, 2015
3 commits
-
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 -
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 -
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
14 Oct, 2014
1 commit
-
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
09 Sep, 2014
1 commit
-
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
05 Jun, 2014
1 commit
-
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/1Signed-off-by: Fabian Frederick
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
04 Apr, 2014
1 commit
-
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
27 Feb, 2014
1 commit
-
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
24 Jan, 2014
1 commit
-
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
15 Nov, 2013
1 commit
-
This ignores %n in printf again, as was originally documented.
Implementing %n poses a greater security risk than utility, so it should
stay ignored. To help anyone attempting to use %n, a warning will be
emitted if it is encountered.Based on an earlier patch by Joe Perches.
Because %n was designed to write to pointers on the stack, it has been
frequently used as an attack vector when bugs are found that leak
user-controlled strings into functions that ultimately process format
strings. While this class of bug can still be turned into an
information leak, removing %n eliminates the common method of elevating
such a bug into an arbitrary kernel memory writing primitive,
significantly reducing the danger of this class of bug.For seq_file users that need to know the length of a written string for
padding, please see seq_setwidth() and seq_pad() instead.Signed-off-by: Kees Cook
Cc: Joe Perches
Cc: Tetsuo Handa
Cc: David Miller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
