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.
A new ESCAPE_QUOTE/ESCAPE_PRINTK option is also possible, but it seems
reasonable to use the simplest strategy first, since this is already
decoded properly.
Signed-off-by: Chris Down <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
---
lib/string_helpers.c | 4 ++++
lib/test-string_helpers.c | 14 +++++++-------
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index 5a35c7e16e96..3806a52ce697 100644
--- a/lib/string_helpers.c
+++ b/lib/string_helpers.c
@@ -361,6 +361,9 @@ static bool escape_special(unsigned char c, char **dst, char *end)
case '\e':
to = 'e';
break;
+ case '"':
+ to = '"';
+ break;
default:
return false;
}
@@ -474,6 +477,7 @@ static bool escape_hex(unsigned char c, char **dst, char *end)
* '\t' - horizontal tab
* '\v' - vertical tab
* %ESCAPE_SPECIAL:
+ * '\"' - double quote
* '\\' - backslash
* '\a' - alert (BEL)
* '\e' - escape
diff --git a/lib/test-string_helpers.c b/lib/test-string_helpers.c
index 2185d71704f0..437d8e6b7cb1 100644
--- a/lib/test-string_helpers.c
+++ b/lib/test-string_helpers.c
@@ -140,13 +140,13 @@ static const struct test_string_2 escape0[] __initconst = {{
},{
.in = "\\h\\\"\a\e\\",
.s1 = {{
- .out = "\\\\h\\\\\"\\a\\e\\\\",
+ .out = "\\\\h\\\\\\\"\\a\\e\\\\",
.flags = ESCAPE_SPECIAL,
},{
- .out = "\\\\\\150\\\\\\042\\a\\e\\\\",
+ .out = "\\\\\\150\\\\\\\"\\a\\e\\\\",
.flags = ESCAPE_SPECIAL | ESCAPE_OCTAL,
},{
- .out = "\\\\\\x68\\\\\\x22\\a\\e\\\\",
+ .out = "\\\\\\x68\\\\\\\"\\a\\e\\\\",
.flags = ESCAPE_SPECIAL | ESCAPE_HEX,
},{
/* terminator */
@@ -157,10 +157,10 @@ static const struct test_string_2 escape0[] __initconst = {{
.out = "\eb \\C\007\"\x90\\r]",
.flags = ESCAPE_SPACE,
},{
- .out = "\\eb \\\\C\\a\"\x90\r]",
+ .out = "\\eb \\\\C\\a\\\"\x90\r]",
.flags = ESCAPE_SPECIAL,
},{
- .out = "\\eb \\\\C\\a\"\x90\\r]",
+ .out = "\\eb \\\\C\\a\\\"\x90\\r]",
.flags = ESCAPE_SPACE | ESCAPE_SPECIAL,
},{
.out = "\\033\\142\\040\\134\\103\\007\\042\\220\\015\\135",
@@ -169,10 +169,10 @@ static const struct test_string_2 escape0[] __initconst = {{
.out = "\\033\\142\\040\\134\\103\\007\\042\\220\\r\\135",
.flags = ESCAPE_SPACE | ESCAPE_OCTAL,
},{
- .out = "\\e\\142\\040\\\\\\103\\a\\042\\220\\015\\135",
+ .out = "\\e\\142\\040\\\\\\103\\a\\\"\\220\\015\\135",
.flags = ESCAPE_SPECIAL | ESCAPE_OCTAL,
},{
- .out = "\\e\\142\\040\\\\\\103\\a\\042\\220\\r\\135",
+ .out = "\\e\\142\\040\\\\\\103\\a\\\"\\220\\r\\135",
.flags = ESCAPE_SPACE | ESCAPE_SPECIAL | ESCAPE_OCTAL,
},{
.out = "\eb \\C\007\"\x90\r]",
--
2.31.1
On Tue, May 18, 2021 at 01:00:32PM +0100, Chris Down wrote:
> 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.
>
> A new ESCAPE_QUOTE/ESCAPE_PRINTK option is also possible, but it seems
> reasonable to use the simplest strategy first, since this is already
> decoded properly.
We have only one direct user of ESCAPE_SPECIAL and there " is not used.
Indirect ones are %pE, but IIRC most of them are either debug messages or some
kind of (non-ABI) messages.
It would be nice if you can confirm this and put a note into commit message.
If the above is confirmed, feel free to add mine
Reviewed-by; Andy Shevchenko <[email protected]>
> Signed-off-by: Chris Down <[email protected]>
> Cc: Andy Shevchenko <[email protected]>
> Cc: Rasmus Villemoes <[email protected]>
> ---
> lib/string_helpers.c | 4 ++++
> lib/test-string_helpers.c | 14 +++++++-------
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/lib/string_helpers.c b/lib/string_helpers.c
> index 5a35c7e16e96..3806a52ce697 100644
> --- a/lib/string_helpers.c
> +++ b/lib/string_helpers.c
> @@ -361,6 +361,9 @@ static bool escape_special(unsigned char c, char **dst, char *end)
> case '\e':
> to = 'e';
> break;
> + case '"':
> + to = '"';
> + break;
> default:
> return false;
> }
> @@ -474,6 +477,7 @@ static bool escape_hex(unsigned char c, char **dst, char *end)
> * '\t' - horizontal tab
> * '\v' - vertical tab
> * %ESCAPE_SPECIAL:
> + * '\"' - double quote
> * '\\' - backslash
> * '\a' - alert (BEL)
> * '\e' - escape
> diff --git a/lib/test-string_helpers.c b/lib/test-string_helpers.c
> index 2185d71704f0..437d8e6b7cb1 100644
> --- a/lib/test-string_helpers.c
> +++ b/lib/test-string_helpers.c
> @@ -140,13 +140,13 @@ static const struct test_string_2 escape0[] __initconst = {{
> },{
> .in = "\\h\\\"\a\e\\",
> .s1 = {{
> - .out = "\\\\h\\\\\"\\a\\e\\\\",
> + .out = "\\\\h\\\\\\\"\\a\\e\\\\",
> .flags = ESCAPE_SPECIAL,
> },{
> - .out = "\\\\\\150\\\\\\042\\a\\e\\\\",
> + .out = "\\\\\\150\\\\\\\"\\a\\e\\\\",
> .flags = ESCAPE_SPECIAL | ESCAPE_OCTAL,
> },{
> - .out = "\\\\\\x68\\\\\\x22\\a\\e\\\\",
> + .out = "\\\\\\x68\\\\\\\"\\a\\e\\\\",
> .flags = ESCAPE_SPECIAL | ESCAPE_HEX,
> },{
> /* terminator */
> @@ -157,10 +157,10 @@ static const struct test_string_2 escape0[] __initconst = {{
> .out = "\eb \\C\007\"\x90\\r]",
> .flags = ESCAPE_SPACE,
> },{
> - .out = "\\eb \\\\C\\a\"\x90\r]",
> + .out = "\\eb \\\\C\\a\\\"\x90\r]",
> .flags = ESCAPE_SPECIAL,
> },{
> - .out = "\\eb \\\\C\\a\"\x90\\r]",
> + .out = "\\eb \\\\C\\a\\\"\x90\\r]",
> .flags = ESCAPE_SPACE | ESCAPE_SPECIAL,
> },{
> .out = "\\033\\142\\040\\134\\103\\007\\042\\220\\015\\135",
> @@ -169,10 +169,10 @@ static const struct test_string_2 escape0[] __initconst = {{
> .out = "\\033\\142\\040\\134\\103\\007\\042\\220\\r\\135",
> .flags = ESCAPE_SPACE | ESCAPE_OCTAL,
> },{
> - .out = "\\e\\142\\040\\\\\\103\\a\\042\\220\\015\\135",
> + .out = "\\e\\142\\040\\\\\\103\\a\\\"\\220\\015\\135",
> .flags = ESCAPE_SPECIAL | ESCAPE_OCTAL,
> },{
> - .out = "\\e\\142\\040\\\\\\103\\a\\042\\220\\r\\135",
> + .out = "\\e\\142\\040\\\\\\103\\a\\\"\\220\\r\\135",
> .flags = ESCAPE_SPACE | ESCAPE_SPECIAL | ESCAPE_OCTAL,
> },{
> .out = "\eb \\C\007\"\x90\r]",
> --
> 2.31.1
>
--
With Best Regards,
Andy Shevchenko
Andy Shevchenko writes:
>We have only one direct user of ESCAPE_SPECIAL and there " is not used.
>
>Indirect ones are %pE, but IIRC most of them are either debug messages or some
>kind of (non-ABI) messages.
>
>It would be nice if you can confirm this and put a note into commit message.
>
>If the above is confirmed, feel free to add mine
>Reviewed-by; Andy Shevchenko <[email protected]>
Thanks for reviewing! :-) I will triple check that and add for v7.
On Tue 2021-05-18 13:00:32, Chris Down wrote:
> >From an abstract point of view, escape_special's counterpart,
The first line starts with '<'. I guess that it is a typo ;-)
> unescape_special, already handles the unescaping of blackslashed double
> quote sequences.
Yup. Makes sense.
> Signed-off-by: Chris Down <[email protected]>
> Cc: Andy Shevchenko <[email protected]>
> Cc: Rasmus Villemoes <[email protected]>
I agree with Andy that you should double check the existing users and
add a note that none is affected.
With it, feel free to add:
Reviewed-by: Petr Mladek <[email protected]>
Best Regards,
Petr