| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
From an abstract point of view, escape_special's counterpart,
unescape_special, already handles the unescaping of blackslashed double
quote sequences.
As a more practical example, printk indexing is an example case where
this is already practically useful. Compare an example with
`ESCAPE_SPECIAL | ESCAPE_SPACE`, with quotes not escaped:
[root@ktst ~]# grep drivers/pci/pci-stub.c:69 /sys/kernel/debug/printk/index/vmlinux
<4> drivers/pci/pci-stub.c:69 pci_stub_init "pci-stub: invalid ID string "%s"\n"
...and the same after this patch:
[root@ktst ~]# grep drivers/pci/pci-stub.c:69 /sys/kernel/debug/printk/index/vmlinux
<4> drivers/pci/pci-stub.c:69 pci_stub_init "pci-stub: invalid ID string \"%s\"\n"
One can of course, alternatively, use ESCAPE_APPEND with a quote in
@only, but without this patch quotes are coerced into hex or octal which
can hurt readability quite significantly.
I've checked uses of ESCAPE_SPECIAL and %pE across the codebase, and I'm
pretty confident that this shouldn't affect any stable interfaces.
Signed-off-by: Chris Down <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
Link: https://lore.kernel.org/r/af144c5b75e41ce417386253ba2694456bc04118.1623775748.git.chris@chrisdown.name
|
|
We have got new flags and hence new features of string_escape_mem().
Add test cases for that.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Chuck Lever <[email protected]>
Cc: "J. Bruce Fields" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Terminators by definition shouldn't accept anything behind. Make them
robust by removing trailing commas.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Chuck Lever <[email protected]>
Cc: "J. Bruce Fields" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Since flags are bitmapped, it's better to print them in hexadecimal
format.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Chuck Lever <[email protected]>
Cc: "J. Bruce Fields" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Add few of simple tests for string_upper() and string_lower() helpers.
Signed-off-by: Vadim Pasternak <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
Recently added commit 564b026fbd0d ("string_helpers: fix precision loss
for some inputs") fixed precision issues for string_get_size() and broke
tests.
Fix and improve them: test both STRING_UNITS_2 and STRING_UNITS_10 at a
time, better failure reporting, test small an huge values.
Fixes: 564b026fbd0d28e9 ("string_helpers: fix precision loss for some inputs")
Signed-off-by: Vitaly Kuznetsov <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: James Bottomley <[email protected]>
Cc: James Bottomley <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Add a couple of simple tests for string_get_size(). The last one will
hang the kernel without the 'lib/string_helpers.c: fix infinite loop in
string_get_size()' fix.
Signed-off-by: Vitaly Kuznetsov <[email protected]>
Cc: James Bottomley <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: "K. Y. Srinivasan" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
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.
[[email protected]: simplify qword_add]
[[email protected]: add missed curly braces]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This is almost the opposite function to string_unescape(). Nevertheless
it handles \0 and could be used for any byte buffer.
The documentation is supplied together with the function prototype.
The test cases covers most of the scenarios and would be expanded later
on.
[[email protected]: avoid 1k stack consumption]
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: "John W . Linville" <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Wu Fengguang <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This patch prepares test suite for a following update. It introduces
test_string_check_buf() helper which checks the result and dumps an error.
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: "John W . Linville" <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
There are several places in kernel where modules unescapes input to convert
C-Style Escape Sequences into byte codes.
The patch provides generic implementation of such approach. Test cases are
also included into the patch.
[[email protected]: clarify comment]
[[email protected]: export get_random_int() to modules]
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: Samuel Thibault <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Jason Baron <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: William Hubbs <[email protected]>
Cc: Chris Brannon <[email protected]>
Cc: Kirk Reiser <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|