vsnprintf: Silence false positive GCC warning for va_format()

va_format() is using vsnprintf(), and GCC compiler (Debian 14.2.0-17)
is not happy about this:

lib/vsprintf.c:1704:9: error: function ‘

vsnprintf: Silence false positive GCC warning for va_format()

va_format() is using vsnprintf(), and GCC compiler (Debian 14.2.0-17)
is not happy about this:

lib/vsprintf.c:1704:9: error: function ‘va_format’ might be a candidate for ‘gnu_print ’ format attribute [-Werror=suggest-attribute=format]

Fix the compilation errors (`make W=1` when CONFIG_WERROR=y, which is default)
by silencing the false positive GCC warning.

Suggested-by: Rasmus Villemoes <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Petr Mladek <[email protected]>

show more ...

vsnprintf: Drop unused const char fmt * in va_format()

va_format() doesn't use original formatting string, drop that
argument as it's done elsewhere in similar cases.

Suggested-by: Rasmus Villemoes

vsnprintf: Drop unused const char fmt * in va_format()

va_format() doesn't use original formatting string, drop that
argument as it's done elsewhere in similar cases.

Suggested-by: Rasmus Villemoes <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Petr Mladek <[email protected]>

show more ...

print: use new #[export] macro for rust_fmt_argument

This moves the rust_fmt_argument function over to use the new #[export]
macro, which will verify at compile-time that the function signature
matc

print: use new #[export] macro for rust_fmt_argument

This moves the rust_fmt_argument function over to use the new #[export]
macro, which will verify at compile-time that the function signature
matches what is in the header file.

Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Tamir Duberstein <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Removed period as requested by Andy. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: fix signature of rust_fmt_argument

Without this change, the rest of this series will emit the following
error message:

error[E0308]: `if` and `else` have incompatible types
--> <linux>/rust

rust: fix signature of rust_fmt_argument

Without this change, the rest of this series will emit the following
error message:

error[E0308]: `if` and `else` have incompatible types
--> <linux>/rust/kernel/print.rs:22:22
|
21 | #[export]
| --------- expected because of this
22 | unsafe extern "C" fn rust_fmt_argument(
| ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
|
= note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument}`
found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument}`

The error may be different depending on the architecture.

To fix this, change the void pointer argument to use a const pointer,
and change the imports to use crate::ffi instead of core::ffi for
integer types.

Fixes: 787983da7718 ("vsprintf: add new `%pA` format specifier")
Reviewed-by: Tamir Duberstein <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Acked-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

vsprintf: add simple_strntoul

cpio extraction currently does a memcpy to ensure that the archive hex
fields are null terminated for simple_strtoul(). simple_strntoul() will
allow us to avoid the mem

vsprintf: add simple_strntoul

cpio extraction currently does a memcpy to ensure that the archive hex
fields are null terminated for simple_strtoul(). simple_strntoul() will
allow us to avoid the memcpy.

Signed-off-by: David Disseldorp <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Christian Brauner <[email protected]>

show more ...

vsnprintf: fix the number base for non-numeric formats

Commit 8d4826cc8a8a ("vsnprintf: collapse the number format state into
one single state") changed the format specification decoding to be a bit

vsnprintf: fix the number base for non-numeric formats

Commit 8d4826cc8a8a ("vsnprintf: collapse the number format state into
one single state") changed the format specification decoding to be a bit
more straightforward but in the process ended up also resetting the
number base to zero for formats that aren't clearly numerical.

Now, the number base obviously doesn't matter for something like '%s',
so this wasn't all that obvious. But some of our specialized pointer
extension formatting (ie, things like "print out IPv6 address") did up
depending on the default base-10 setting, and when they then tried to
print out numbers in "base zero", things didn't work out so well.

Most pointer formatting (including things like the default raw hex value
conversion) didn't have this issue, because they used helpers that
explicitly set the base.

Reported-and-tested-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-lkp/[email protected]
Fixes: 8d4826cc8a8a ("vsnprintf: collapse the number format state into one single state")
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsnprintf: fix up kerneldoc for argument name changes

Stephen Rothwell reports that I missed fixing up the documentation when
the argument names changed in commit 938df695e98d ("vsprintf: associate

vsnprintf: fix up kerneldoc for argument name changes

Stephen Rothwell reports that I missed fixing up the documentation when
the argument names changed in commit 938df695e98d ("vsprintf: associate
the format state with the format pointer"), resulting in htmldoc
warnings like

lib/vsprintf.c:2760: warning: Function parameter or struct member 'fmt_str' not described in 'vsnprintf'
lib/vsprintf.c:2760: warning: Excess function parameter 'fmt' description in 'vsnprintf'
...

which I didn't notice because the doc build takes longer than the whole
"real" kernel build for me, so I never bother (and judging by the other
warnings, pretty much nobody else does either).

I guess the bigger issues won't be fixed until the doc build is much
faster (narrator: "That isn's in the cards") but at least linux-next
finds the new cases.

Reported-by: Stephen Rothwell <[email protected]>
Fixes: 938df695e98d ("vsprintf: associate the format state with the format pointer")
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsprintf: don't make the 'binary' version pack small integer arguments

The strange vbin_printf / bstr_printf interface used to save one- and
two-byte printf numerical arguments into their packed for

vsprintf: don't make the 'binary' version pack small integer arguments

The strange vbin_printf / bstr_printf interface used to save one- and
two-byte printf numerical arguments into their packed format.

That's more than a bit strange since the argument buffer is supposed to
be an array of 'u32' words, and it's also very different from how the
source of the data (varargs) work - which always do the normal integer
type conversions, so 'char' and 'short' are always passed as int-sized
anyway.

This odd packing causes extra code complexity, and it really isn't worth
it, since the space savings are simply not there: it only happens for
formats like '%hd' (short) and '%hhd' (char), which are very rare
indeed.

In fact, the only other user of this interface seems to be the bpf
helper code (bpf_bprintf_prepare()), and Alexei points out that that
case doesn't support those truncated integer formatting options at all
in the first place.

As a result, bpf_bprintf_prepare() doesn't need any changes for this,
and TRACE_BPRINT uses 'vbin_printf()' -> 'bstr_printf()' for the
formatting and hopefully doesn't expose the odd packing any other way
(knock wood).

Link: https://lore.kernel.org/all/CAADnVQJy65oOubjxM-378O3wDfhuwg8TGa9hc-cTv6NmmUSykQ@mail.gmail.com/
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsnprintf: collapse the number format state into one single state

We'll squirrel away the size of the number in 'struct fmt' instead.

We have two fairly separate state structures: the 'decode state

vsnprintf: collapse the number format state into one single state

We'll squirrel away the size of the number in 'struct fmt' instead.

We have two fairly separate state structures: the 'decode state' is in
'struct fmt', while the 'printout format' is in 'printf_spec'. Both
structures are small enough to pass around in registers even across
function boundaries (ie two words), even on 32-bit machines.

The goal here is to avoid the case statements on the format states,
which generate either deep conditionals or jump tables, while also
keeping the state size manageable.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsnprintf: mark the indirect width and precision cases unlikely

Make the format_decode() code generation easier to look at by getting
the strange and unlikely cases out of line.

Signed-off-by: Linu

vsnprintf: mark the indirect width and precision cases unlikely

Make the format_decode() code generation easier to look at by getting
the strange and unlikely cases out of line.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsnprintf: inline skip_atoi() again

At some point skip_atoi() had been marked 'noinline_for_stack', but it
turns out that this is now a pessimization, and not inlining it actually
results in a stack

vsnprintf: inline skip_atoi() again

At some point skip_atoi() had been marked 'noinline_for_stack', but it
turns out that this is now a pessimization, and not inlining it actually
results in a stack frame in format decoding due to the call and thus
hurts stack usage rather than helping.

With the simplistic atoi function inlined, the format decoding now needs
no frame at all.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsprintf: deal with format specifiers with a lookup table

We did the flags as an array earlier, they had simpler rules. The final
format specifiers are a bit more complex since they have more field

vsprintf: deal with format specifiers with a lookup table

We did the flags as an array earlier, they had simpler rules. The final
format specifiers are a bit more complex since they have more fields to
deal with, and we want to handle the length modifiers at the same time.
But like the flags, we're better off just making it a data-driven table
rather than some case statement.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsprintf: deal with format flags with a simple lookup table

Rather than a case statement, just look up the printf format flags
(justification, zero-padding etc) using a small table.

Signed-off-by:

vsprintf: deal with format flags with a simple lookup table

Rather than a case statement, just look up the printf format flags
(justification, zero-padding etc) using a small table.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsprintf: associate the format state with the format pointer

The vsnprintf() code is written as a state machine as it walks the
format pointer, but for various historical reasons the state is oddly

vsprintf: associate the format state with the format pointer

The vsnprintf() code is written as a state machine as it walks the
format pointer, but for various historical reasons the state is oddly
named and was encoded as the 'type' field in the 'struct printf_spec'.

That naming came from the fact that the states used to not just encode
the state of the state machine, but also the various integer types that
would then be printed out.

Let's make the state machine more obvious, and actually call it 'state',
and associate it with the format pointer itself, rather than the
'printf_spec' that contains the currently decoded formatting specs.

This also removes the bit packing from printf_spec, which makes it much
easier on the compiler.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsprintf: fix calling convention for format_decode()

Every single caller wants to know what the next format location is, but
instead the function returned the length of the processed part and so
eve

vsprintf: fix calling convention for format_decode()

Every single caller wants to know what the next format location is, but
instead the function returned the length of the processed part and so
every single return statement in the format_decode() function was
instead subtracting the start of the format string.

The callers that that did want to know the length (in addition to the
end of the format processing) already had to save off the start of the
format string anyway. So this was all just doing extra processing both
on the caller and callee sides.

Just change the calling convention to return the end of the format
processing, making everything simpler (and preparing for yet more
simplification to come).

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsprintf: avoid nested switch statement on same variable

Now that we have simplified the number format types, the top-level
switch table can easily just handle all the remaining cases, and we
don't

vsprintf: avoid nested switch statement on same variable

Now that we have simplified the number format types, the top-level
switch table can easily just handle all the remaining cases, and we
don't need to have a case statement with a conditional on the same
expression as the switch statement.

We do want to fall through to the common 'number()' case, but that's
trivially done by making the other case statements use 'continue'
instead of 'break'. They are just looping back to the top, after all.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

vsprintf: simplify number handling

Instead of dealing with all the different special types (size_t,
unsigned char, ptrdiff_t..) just deal with the size of the integer type
and the sign.

This avoids

vsprintf: simplify number handling

Instead of dealing with all the different special types (size_t,
unsigned char, ptrdiff_t..) just deal with the size of the integer type
and the sign.

This avoids a lot of unnecessary case statements, and the games we play
with the value of the 'SIGN' flags value

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

printf: Remove unused 'bprintf'

bprintf() is unused. Remove it. It was added in the commit 4370aa4aa753
("vsprintf: add binary printf") but as far as I can see was never used,
unlike the other two f

printf: Remove unused 'bprintf'

bprintf() is unused. Remove it. It was added in the commit 4370aa4aa753
("vsprintf: add binary printf") but as far as I can see was never used,
unlike the other two functions in that patch.

Link: https://lore.kernel.org/[email protected]
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Petr Mladek <[email protected]>
Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>

show more ...

printf: Add print format (%pra) for struct range

The use of struct range in the CXL subsystem is growing. In particular,
the addition of Dynamic Capacity devices uses struct range in a number
of pl

printf: Add print format (%pra) for struct range

The use of struct range in the CXL subsystem is growing. In particular,
the addition of Dynamic Capacity devices uses struct range in a number
of places which are reported in debug and error messages.

To wit requiring the printing of the start/end fields in each print
became cumbersome. Dan Williams mentions in [1] that it might be time
to have a print specifier for struct range similar to struct resource.

A few alternatives were considered including '%par', '%r', and '%pn'.
%pra follows that struct range is similar to struct resource (%p[rR])
but needs to be different. Based on discussions with Petr and Andy
'%pra' was chosen.[2]

Andy also suggested to keep the range prints similar to struct resource
though combined code. Add hex_range() to handle printing for both
pointer types.

Finally introduce DEFINE_RANGE() as a parallel to DEFINE_RES_*() and use
it in the tests.

Cc: Jonathan Corbet <[email protected]>
Cc: [email protected]
Cc: open list <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/ [1]
Link: https://lore.kernel.org/all/[email protected]/ [2]
Suggested-by: Dan Williams <[email protected]>
Signed-off-by: Ira Weiny <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Dave Jiang <[email protected]>

show more ...

move asm/unaligned.h to linux/unaligned.h

asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-

move asm/unaligned.h to linux/unaligned.h

asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.

auto-generated by the following:

for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h

show more ...

printf: remove %pGt support

Patch series "Increase the number of bits available in page_type".

Kent wants more than 16 bits in page_type, so I resurrected this old patch
and expanded it a bit. It'

printf: remove %pGt support

Patch series "Increase the number of bits available in page_type".

Kent wants more than 16 bits in page_type, so I resurrected this old patch
and expanded it a bit. It's a bit more efficient than our current scheme
(1 4-byte insn vs 3 insns of 13 bytes total) to test a single page type.


This patch (of 4):

An upcoming patch will convert page type from being a bitfield to a
single byte, so we will not be able to use %pG to print the page type
any more. The printing of the symbolic name will be restored in that
patch.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Cc: Hyeonggon Yoo <[email protected]>
Cc: Kent Overstreet <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

minmax: don't use max() in situations that want a C constant expression

We only had a couple of array[] declarations, and changing them to just
use 'MAX()' instead of 'max()' fixes the issue.

This

minmax: don't use max() in situations that want a C constant expression

We only had a couple of array[] declarations, and changing them to just
use 'MAX()' instead of 'max()' fixes the issue.

This will allow us to simplify our min/max macros enormously, since they
can now unconditionally use temporary variables to avoid using the
argument values multiple times.

Cc: David Laight <[email protected]>
Cc: Lorenzo Stoakes <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

wrapper for access to ->bd_partno

On the next step it's going to get folded into a field where flags will go.

Signed-off-by: Al Viro <[email protected]>

Use bdev_is_paritition() instead of open-coding it

Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Al Viro <[email protected]>

lib/vsprintf: Fix %pfwf when current node refcount == 0

A refcount issue can appeared in __fwnode_link_del() due to the
pr_debug() call:
WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn

lib/vsprintf: Fix %pfwf when current node refcount == 0

A refcount issue can appeared in __fwnode_link_del() due to the
pr_debug() call:
WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
Call Trace:
<TASK>
...
of_node_get+0x1e/0x30
of_fwnode_get+0x28/0x40
fwnode_full_name_string+0x34/0x90
fwnode_string+0xdb/0x140
...
vsnprintf+0x17b/0x630
...
__fwnode_link_del+0x25/0xa0
fwnode_links_purge+0x39/0xb0
of_node_release+0xd9/0x180
...

Indeed, an fwnode (of_node) is being destroyed and so, of_node_release()
is called because the of_node refcount reached 0.
From of_node_release() several function calls are done and lead to
a pr_debug() calls with %pfwf to print the fwnode full name.
The issue is not present if we change %pfwf to %pfwP.

To print the full name, %pfwf iterates over the current node and its
parents and obtain/drop a reference to all nodes involved.

In order to allow to print the full name (%pfwf) of a node while it is
being destroyed, do not obtain/drop a reference to this current node.

Fixes: a92eb7621b9f ("lib/vsprintf: Make use of fwnode API to obtain node names and separators")
Cc: [email protected]
Signed-off-by: Herve Codina <[email protected]>
Reviewed-by: Sakari Ailus <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...