lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1410513954-28909-3-git-send-email-linux@rasmusvillemoes.dk>
Date:	Fri, 12 Sep 2014 11:25:50 +0200
From:	Rasmus Villemoes <linux@...musvillemoes.dk>
To:	Julia Lawall <Julia.Lawall@...6.fr>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: [PATCH 2/6] Coccinelle: Semantic patch for joining seq_puts calls

Consecutive calls of seq_puts with literal strings, where the return
value is not checked, might as well be replaced by a single call with
the combined string. This gives smaller generated code (less function
calls), a slight .rodata reduction, since nul and padding bytes are
eliminated, and hits fewer cache lines (nothing guarantees that the
linker places string literals which are used together close together
in the final image).

Signed-off-by: Rasmus Villemoes <linux@...musvillemoes.dk>
---
 scripts/coccinelle/api/seq_puts_concat.cocci | 71 ++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)
 create mode 100644 scripts/coccinelle/api/seq_puts_concat.cocci

diff --git a/scripts/coccinelle/api/seq_puts_concat.cocci b/scripts/coccinelle/api/seq_puts_concat.cocci
new file mode 100644
index 0000000..0e7afc3
--- /dev/null
+++ b/scripts/coccinelle/api/seq_puts_concat.cocci
@@ -0,0 +1,71 @@
+/// Consecutive calls of seq_puts with literal strings, where the
+/// return value is not checked, might as well be replaced by a single
+/// call with the combined string. This gives smaller generated code
+/// (less function calls), a slight .rodata reduction, since nul and
+/// padding bytes are eliminated, and hits fewer cache lines (nothing
+/// guarantees that the linker places string literals which are used
+/// together close together in the final image).
+///
+/// Two small, but in practice irrelevant, issues:
+///
+/// (1) If one of the strings is also used elsewhere, this reduces the
+/// possiblity for the linker to do string merging (thus increasing
+/// .rodata), but these multiple seq_puts calls are mostly to print
+/// multi-line headers in various /proc or /sys files.
+///
+/// (2) seq_puts is all-or-nothing, so if there is not room for the
+/// entire string, one would previously get some of the strings
+/// printed, but not all; combining the strings means nothing is
+/// printed. So this formally changes the semantics of the
+/// code. However, usually there is room.
+///
+///
+//
+// Run and apply repeatedly until no furter patches are generated,
+// then fix up the whitespace.
+//
+// Confidence: High
+// Options: --no-includes --include-headers
+
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+// Prevent "token already tagged" error
+@r@
+position p;
+@@
+  seq_puts(...);
+  seq_puts(...);
+  seq_puts@p(...);
+
+
+@...cat1 depends on patch@
+expression s;
+constant c1, c2;
+position p1 != r.p, p2 != r.p;
+@@
+  seq_puts@p1(s, c1);
+  seq_puts@p2(s, c2);
+
+@...ipt:python concat2@
+c1 << concat1.c1;
+c2 << concat1.c2;
+c3;
+@@
+
+// The indentation probably needs to be fixed manually
+coccinelle.c3 = c1 + "\n\t" + c2
+
+@...cat3 depends on patch@
+identifier concat2.c3;
+expression concat1.s;
+constant concat1.c1, concat1.c2;
+position concat1.p1, concat1.p2;
+@@
+- seq_puts@p1(s, c1);
+- seq_puts@p2(s, c2);
++ seq_puts(s, c3);
+
-- 
2.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ