linux-kernel - [PATCH] Coccinelle: uslee_range: ensure delta not zero

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Dec 2016 11:23:20 +0100
From:   Nicholas Mc Guire <hofrat@...dl.org>
To:     Julia Lawall <Julia.Lawall@...6.fr>
Cc:     Gilles Muller <Gilles.Muller@...6.fr>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        Michal Marek <mmarek@...e.com>,
        Thomas Gleixner <tglx@...utronix.de>, cocci@...teme.lip6.fr,
        linux-kernel@...r.kernel.org, Nicholas Mc Guire <hofrat@...dl.org>
Subject: [PATCH] Coccinelle: uslee_range: ensure delta not zero

usleep_range() min==max makes little sense at last for non-RT, so issue
a warning if delta is 0.

Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
---

As of 4.9.0 this finds about 20 cases - all of which look like the 
should be passing a range.

Patch is against 4.9.0 (localversion-next is next-20161213)

 scripts/coccinelle/api/bad_usleep_range.cocci | 55 +++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 scripts/coccinelle/api/bad_usleep_range.cocci

diff --git a/scripts/coccinelle/api/bad_usleep_range.cocci b/scripts/coccinelle/api/bad_usleep_range.cocci
new file mode 100644
index 0000000..7e05f3e
--- /dev/null
+++ b/scripts/coccinelle/api/bad_usleep_range.cocci
@@ -0,0 +1,55 @@
+/// bad uslee_range - warn if min == max
+//
+//The problem is that usleep_range is calculating the delay by
+//      exp = ktime_add_us(ktime_get(), min)
+//      delta = (u64)(max - min) * NSEC_PER_USEC
+//so delta is set to 0 if min==max
+//and then calls
+//      schedule_hrtimeout_range(exp, 0,...)
+//effectively this means that the clock subsystem has no room to
+//optimize. usleep_range() is in non-atomic context so a 0 range
+//makes very little sense as the task can be preempted anyway so
+//there is no guarantee that the 0 range would be adding much
+//precision - it just removes optimization potential, so it probably
+//never really makes sense for any non-RT systems.
+//
+//see: Documentation/timers/timers-howto.txt and
+//Link: http://lkml.org/lkml/2016/11/29/54 for some notes on
+//      when mdelay might not be a suitable replacement
+//
+// Confidence: Moderate
+// Copyright: (C) 2016 Nicholas Mc Guire, OSADL.  GPLv2.
+// Comments:
+// Options: --no-includes --include-headers
+
+virtual org
+virtual report
+
+@...lrange@
+expression E;
+constant C;
+position p;
+@@
+
+<+...
+(
+  usleep_range@p(C,C)
+|
+  usleep_range@p(E,E)
+)
+...+>
+
+
+@...ipt:python depends on org@
+p << nullrange.p;
+range << nullrange.C;
+@@
+
+cocci.print_main("WARNING: inefficient usleep_range with range 0 (min==max)",p)
+
+@...ipt:python depends on report@
+p << nullrange.p;
+@@
+
+coccilib.report.print_report(p[0],"WARNING: inefficient usleep_range with range 0 (min==max)")
+
-- 
2.1.4