From: Julia Lawall <julia.lawall@lip6.fr>
To: Nicholas Mc Guire <hofrat@osadl.org>
Cc: Gilles Muller <Gilles.Muller@lip6.fr>,
Nicolas Palix <nicolas.palix@imag.fr>,
Michal Marek <mmarek@suse.cz>,
cocci@systeme.lip6.fr, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] coccinelle: flag constants being passed for jiffies
Date: Thu, 28 May 2015 07:50:24 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.02.1505280744580.2027@localhost6.localdomain6> (raw)
In-Reply-To: <1432754908-8297-1-git-send-email-hofrat@osadl.org>
On Wed, 27 May 2015, Nicholas Mc Guire wrote:
> schedule_timeout_* takes a jiffies value as timeout - passing in a constant
> makes the timeout HZ dependent which is wrong. Checking for contstants only
> yields many false positives so they are filtered for digits only. A numeric
> value of 1 is though commonly in use for "shortest possible delay" so those
> cases are treated as false positives as well and not reported.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> ---
>
> The cases reported all look like they are actual API inconsistencies but
> not reporting does not mean there is no bug with respect to jiffies. This
> still can miss some values e.g. like in:
> drivers/staging/rts5208/rtsx_chip.h:66 #define POLLING_INTERVAL 30
> drivers/staging/rts5208/rtsx.c:540 schedule_timeout(POLLING_INTERVAL);
>
> For schedule_timeout_*() it reports 23 cases - all of which look like
> they are correct findings.
>
> Further the list of functions taking jiffies as arguments is much longer
> but they can be added once the basic script is sound - which it probably
> is not at this point.
>
> scripts/coccinelle/api/timeout_HZ_dependent.cocci | 62 +++++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 scripts/coccinelle/api/timeout_HZ_dependent.cocci
>
> diff --git a/scripts/coccinelle/api/timeout_HZ_dependent.cocci b/scripts/coccinelle/api/timeout_HZ_dependent.cocci
> new file mode 100644
> index 0000000..6e98da1
> --- /dev/null
> +++ b/scripts/coccinelle/api/timeout_HZ_dependent.cocci
> @@ -0,0 +1,62 @@
> +/* check for hardcoded timeout values which are thus HZ dependent
> + * only report findings if the value is digits and != 1 as hardcoded
> + * 1 seems to be in use for short delays.
> + *
> + * No patch mode for this as converting the value from C to
> + * msecs_to_jiffies(C) could be changing the effective timeout by
> + * more than a factor of 10 so this always needs manual inspection
> + *
> + * Options: --no-includes --include-headers
> + */
> +virtual context
> +virtual patch
> +virtual org
> +virtual report
> +
> +@ep depends on !patch && (org || report)@
> +identifier f;
> +constant C;
> +position p1,p2;
> +@@
> +
> +f@p1(...) {
Do you need the function for anything? This would be more efficient with
just the calls.
> + <+...
> +(
> +* schedule_timeout@p2(C)
If you put in the argument list \(i\|1\|C@p2\) then you can get rid of the
python code (i would be an identifier metavariable).
What kind of false positives do you get for the macro case? Would it be
sufficient to do:
@r@
expression e != 1;
identifier i,
@@
#define i e
@@
identifier r.i,
@@
*schedule_timeout(i)
(and all the other cases?)
julia
> +|
> +* schedule_timeout_interruptible@p2(C)
> +|
> +* schedule_timeout_killable@p2(C)
> +|
> +* schedule_timeout_uninterruptible@p2(C)
> +)
> + ...+>
> +}
> +
> +@script:python depends on org@
> +p1 << ep.p1;
> +p2 << ep.p2;
> +timeout << ep.C;
> +@@
> +
> +# schedule_timeout(1) for a "short" delay is not HZ dependent
> +# as it always would be converted to 1 by msecs_to_jiffies as well
> +# so count this as false positive
> +if str.isdigit(timeout):
> + if (int(timeout) != 1):
> + msg="WARNING: timeout is HZ dependent"
> + coccilib.org.print_todo(p2[0], msg)
> +
> +@script:python depends on report@
> +p1 << ep.p1;
> +p2 << ep.p2;
> +timeout << ep.C;
> +@@
> +
> +# schedule_timeout(1) for a "short" delay is not HZ dependent
> +# as it always would be converted to 1 by msecs_to_jiffies as well
> +# so count this as false positive
> +if str.isdigit(timeout):
> + if (int(timeout) != 1):
> + msg="WARNING: timeout (%s) seems HZ dependent" % (timeout)
> + coccilib.report.print_report(p2[0], msg)
> --
> 1.7.10.4
>
>
next prev parent reply other threads:[~2015-05-28 5:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 19:28 Nicholas Mc Guire
2015-05-28 5:50 ` Julia Lawall [this message]
2015-05-28 8:19 ` [Cocci] " Nicholas Mc Guire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1505280744580.2027@localhost6.localdomain6 \
--to=julia.lawall@lip6.fr \
--cc=Gilles.Muller@lip6.fr \
--cc=cocci@systeme.lip6.fr \
--cc=hofrat@osadl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=nicolas.palix@imag.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®