From: Julia Lawall <julia.lawall@inria.fr>
To: Wen Yang <wenyang@linux.alibaba.com>
Cc: Julia Lawall <julia.lawall@inria.fr>,
Julia Lawall <Julia.Lawall@lip6.fr>,
Gilles Muller <Gilles.Muller@lip6.fr>,
Nicolas Palix <nicolas.palix@imag.fr>,
Michal Marek <michal.lkml@markovi.net>,
Matthias Maennich <maennich@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Thomas Gleixner <tglx@linutronix.de>,
cocci@systeme.lip6.fr, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] coccinelle: semantic patch to check for inappropriate do_div() calls
Date: Sat, 4 Jan 2020 09:55:07 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.21.2001040951450.2636@hadrien> (raw)
In-Reply-To: <7d9d8f10-7eb6-ffc3-5084-5ed1a08d4bcb@linux.alibaba.com>
[-- Attachment #1: Type: text/plain, Size: 4779 bytes --]
On Sat, 4 Jan 2020, Wen Yang wrote:
>
>
> On 2020/1/4 3:00 下午, Julia Lawall wrote:
> > On Sat, 4 Jan 2020, Wen Yang wrote:
> >
> > > do_div() does a 64-by-32 division.
> > > When the divisor is unsigned long, u64, or s64,
> > > do_div() truncates it to 32 bits, this means it
> > > can test non-zero and be truncated to zero for division.
> > > This semantic patch is inspired by Mateusz Guzik's patch:
> > > commit b0ab99e7736a ("sched: Fix possible divide by zero in avg_atom()
> > > calculation")
> > >
> > > Signed-off-by: Wen Yang <wenyang@linux.alibaba.com>
> > > Cc: Julia Lawall <Julia.Lawall@lip6.fr>
> > > Cc: Gilles Muller <Gilles.Muller@lip6.fr>
> > > Cc: Nicolas Palix <nicolas.palix@imag.fr>
> > > Cc: Michal Marek <michal.lkml@markovi.net>
> > > Cc: Matthias Maennich <maennich@google.com>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: cocci@systeme.lip6.fr
> > > Cc: linux-kernel@vger.kernel.org
> > > ---
> > > scripts/coccinelle/misc/do_div.cocci | 66
> > > ++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 66 insertions(+)
> > > create mode 100644 scripts/coccinelle/misc/do_div.cocci
> > >
> > > diff --git a/scripts/coccinelle/misc/do_div.cocci
> > > b/scripts/coccinelle/misc/do_div.cocci
> > > new file mode 100644
> > > index 0000000..f1b72d1
> > > --- /dev/null
> > > +++ b/scripts/coccinelle/misc/do_div.cocci
> > > @@ -0,0 +1,66 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/// do_div() does a 64-by-32 division.
> > > +/// When the divisor is unsigned long, u64, or s64,
> > > +/// do_div() truncates it to 32 bits, this means it
> > > +/// can test non-zero and be truncated to zero for division.
> > > +///
> > > +//# This makes an effort to find those inappropriate do_div () calls.
> > > +//
> > > +// Confidence: Moderate
> > > +// Copyright: (C) 2020 Wen Yang, Alibaba.
> > > +// Comments:
> > > +// Options: --no-includes --include-headers
> > > +
> > > +virtual context
> > > +virtual org
> > > +virtual report
> > > +
> > > +@depends on context@
> > > +expression f;
> > > +long l;
> > > +unsigned long ul;
> > > +u64 ul64;
> > > +s64 sl64;
> > > +
> > > +@@
> > > +(
> > > +* do_div(f, l);
> > > +|
> > > +* do_div(f, ul);
> > > +|
> > > +* do_div(f, ul64);
> > > +|
> > > +* do_div(f, sl64);
> > > +)
> > > +
> > > +@r depends on (org || report)@
> > > +expression f;
> > > +long l;
> > > +unsigned long ul;
> > > +position p;
> > > +u64 ul64;
> > > +s64 sl64;
> > > +@@
> > > +(
> > > +do_div@p(f, l);
> > > +|
> > > +do_div@p(f, ul);
> > > +|
> > > +do_div@p(f, ul64);
> > > +|
> > > +do_div@p(f, sl64);
> > > +)
> > > +
> > > +@script:python depends on org@
> > > +p << r.p;
> > > +@@
> > > +
> > > +msg="WARNING: WARNING: do_div() does a 64-by-32 division, which may
> > > truncation the divisor to 32-bit"
> > > +coccilib.org.print_todo(p[0], msg)
> > > +
> > > +@script:python depends on report@
> > > +p << r.p;
> > > +@@
> > > +
> > > +msg="WARNING: WARNING: do_div() does a 64-by-32 division, which may
> > > truncation the divisor to 32-bit"
> > > +coccilib.report.print_report(p[0], msg)
> >
> > A few small issues: You have WARNING: twice in each case, and truncation
> > should be truncate.
> >
>
> Thanks for your comments, we will fix it soon.
>
> > Is there any generic strategy for fixing these issues?
> >
>
> We have done some experiments, such as:
> https://lkml.org/lkml/2020/1/2/1354
Thanks. Actually, I would appreciate knowing about such experiments when
the semantic patch is submitted, since eg in this case I am not really an
expert in this issue.
>
> - avg = rec->time;
> - do_div(avg, rec->counter);
> + avg = div64_ul(rec->time, rec->counter);
>
> --> Function replacement was performed here,
> and simple code cleanup was also performed.
>
>
> - do_div(stddev, rec->counter * (rec->counter - 1) * 1000);
> + stddev = div64_ul(stddev,
> + rec->counter * (rec->counter - 1) * 1000);
>
> --> Only the function replacement is performed here (because the variable
> ‘stddev’ corresponds to a more complicated equation, cleaning it will reduce
> readability).
Would it be reasonable to extend the warning to say "consider using
div64_ul instead"? Or do you think it is obvious to everyone?
> In addition, there are some codes that do not need to be modified:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/can/dev.c#n263
Would it be worth having a special case for constants and checking whether
the value is obviously safe and no warning is needed?
thanks,
julia
> So we just print a warning.
> As for how to fix it, we need to analyze the code carefully.
>
> --
> Best Wishes,
> Wen
>
>
>
next prev parent reply other threads:[~2020-01-04 8:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-04 6:44 Wen Yang
2020-01-04 7:00 ` Julia Lawall
2020-01-04 8:49 ` Wen Yang
2020-01-04 8:55 ` Julia Lawall [this message]
2020-01-04 13:50 ` Wen Yang
2020-01-04 13:54 ` Julia Lawall
2020-01-04 7:16 ` Julia Lawall
2020-01-05 10:33 ` Markus Elfring
2020-01-05 10:41 ` Julia Lawall
2020-01-05 12:07 ` Markus Elfring
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.21.2001040951450.2636@hadrien \
--to=julia.lawall@inria.fr \
--cc=Gilles.Muller@lip6.fr \
--cc=Julia.Lawall@lip6.fr \
--cc=cocci@systeme.lip6.fr \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maennich@google.com \
--cc=michal.lkml@markovi.net \
--cc=nicolas.palix@imag.fr \
--cc=tglx@linutronix.de \
--cc=wenyang@linux.alibaba.com \
--cc=yamada.masahiro@socionext.com \
/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®