All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"cocci@systeme.lip6.fr" <cocci@systeme.lip6.fr>,
	Gilles Muller <Gilles.Muller@lip6.fr>,
	"nicolas.palix@imag.fr" <nicolas.palix@imag.fr>,
	"mmarek@suse.com" <mmarek@suse.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"ishkamiel@gmail.com" <ishkamiel@gmail.com>
Subject: RE: [PATCH] Coccinelle: add atomic_as_refcounter script
Date: Tue, 29 Aug 2017 09:01:52 +0000	[thread overview]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B6FF5F9CA@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1708171346010.3748@hadrien>


> > +identifier fname =~ ".*free.*";
> > +identifier fname2 =~ ".*destroy.*";
> > +identifier fname3 =~ ".*del.*";
> > +identifier fname4 =~ ".*queue_work.*";
> > +identifier fname5 =~ ".*schedule_work.*";
> > +identifier fname6 =~ ".*call_rcu.*";
> 
> Personally, I find the above regular expressions much easier to understand
> than the merged version that Markus proposed.  

I really don't have a strong opinion on the presentation side. 
One is more compact, the above one perhaps a bit clearer for unexperienced reader (like myself). 
Sometimes when I try to read patterns from cocci folder,
it takes me really a while to understand what is happening, which is not the case
with simple expression above. I have just considered myself to be too new into this
and therefore sticked to simple expressions to make sure I am minimizing functional mistakes. 

But the performance issue is
> only on whether to use regular expressions or not.  If you use regular
> expressions, Coccinelle will not do some optimizations.  But once you
> decide to use regular expressions, the performance hit is already taken -
> for a good cause here, to my understanding.  

Ok, so then performance is not even a factor. Thank you for the explanation! 

So just put whatever you find
> convenient, in terms of readability, precision, etc.  It seems that del is
> not very precise, because it is a substring of multiple words with
> different meanings.  Maybe it should be improved, or maybe one can just
> live with the false positives (eg delay), if they actually are false
> positives.

This is the problem that some of them might be and some not. 
I can call the queuing works explicitly:
identifier fname4 =~ ".*queue_work.*";
identifier fname5 =~ ".*queue_delayed_work.*";

Then there is no need to match "delay", but I still like to match both "delete" and "del". 

Best Regards,
Elena.
> 
> julia

WARNING: multiple messages have this Message-ID (diff)
From: elena.reshetova@intel.com (Reshetova, Elena)
To: cocci@systeme.lip6.fr
Subject: [Cocci] [PATCH] Coccinelle: add atomic_as_refcounter script
Date: Tue, 29 Aug 2017 09:01:52 +0000	[thread overview]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B6FF5F9CA@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1708171346010.3748@hadrien>


> > +identifier fname =~ ".*free.*";
> > +identifier fname2 =~ ".*destroy.*";
> > +identifier fname3 =~ ".*del.*";
> > +identifier fname4 =~ ".*queue_work.*";
> > +identifier fname5 =~ ".*schedule_work.*";
> > +identifier fname6 =~ ".*call_rcu.*";
> 
> Personally, I find the above regular expressions much easier to understand
> than the merged version that Markus proposed.  

I really don't have a strong opinion on the presentation side. 
One is more compact, the above one perhaps a bit clearer for unexperienced reader (like myself). 
Sometimes when I try to read patterns from cocci folder,
it takes me really a while to understand what is happening, which is not the case
with simple expression above. I have just considered myself to be too new into this
and therefore sticked to simple expressions to make sure I am minimizing functional mistakes. 

But the performance issue is
> only on whether to use regular expressions or not.  If you use regular
> expressions, Coccinelle will not do some optimizations.  But once you
> decide to use regular expressions, the performance hit is already taken -
> for a good cause here, to my understanding.  

Ok, so then performance is not even a factor. Thank you for the explanation! 

So just put whatever you find
> convenient, in terms of readability, precision, etc.  It seems that del is
> not very precise, because it is a substring of multiple words with
> different meanings.  Maybe it should be improved, or maybe one can just
> live with the false positives (eg delay), if they actually are false
> positives.

This is the problem that some of them might be and some not. 
I can call the queuing works explicitly:
identifier fname4 =~ ".*queue_work.*";
identifier fname5 =~ ".*queue_delayed_work.*";

Then there is no need to match "delay", but I still like to match both "delete" and "del". 

Best Regards,
Elena.
> 
> julia

  reply	other threads:[~2017-08-29  9:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 11:52 [PATCH v3] provide rule for finding refcounters Elena Reshetova
2017-08-16 11:52 ` [Cocci] " Elena Reshetova
2017-08-16 11:52 ` [PATCH] Coccinelle: add atomic_as_refcounter script Elena Reshetova
2017-08-16 11:52   ` [Cocci] " Elena Reshetova
2017-08-16 17:00   ` [Cocci] " SF Markus Elfring
2017-08-17  7:22     ` Reshetova, Elena
2017-08-17 11:31       ` SF Markus Elfring
2017-08-17 11:50   ` [PATCH] " Julia Lawall
2017-08-17 11:50     ` [Cocci] " Julia Lawall
2017-08-29  9:01     ` Reshetova, Elena [this message]
2017-08-29  9:01       ` Reshetova, Elena
2017-08-16 14:16 ` [PATCH v3] provide rule for finding refcounters Julia Lawall
2017-08-16 14:16   ` [Cocci] " Julia Lawall
2017-08-29  8:54   ` Reshetova, Elena
2017-08-29  8:54     ` [Cocci] " Reshetova, Elena
2017-08-29  9:23     ` Julia Lawall
2017-08-29  9:23       ` [Cocci] " Julia Lawall
2017-08-29 10:57       ` Reshetova, Elena
2017-08-29 10:57         ` [Cocci] " Reshetova, Elena
  -- strict thread matches above, loose matches on Subject: below --
2017-09-01  9:40 [PATCH] Coccinelle: add atomic_as_refcounter script Elena Reshetova
2018-06-14 23:58 ` Kees Cook
2018-06-15  5:06   ` Julia Lawall
2018-06-18 13:47     ` Masahiro Yamada
2017-08-30  6:15 [PATCH v4] provide rule for finding refcounters Elena Reshetova
2017-08-30  6:15 ` [PATCH] Coccinelle: add atomic_as_refcounter script Elena Reshetova
2017-08-30 12:26   ` Julia Lawall
2017-08-30 12:44     ` Reshetova, Elena
2017-08-30 13:06       ` Julia Lawall
2017-08-31  9:46         ` Reshetova, Elena
2017-08-14  5:59 [PATCH v2] coccinelle: provide rule for finding refcounters Elena Reshetova
2017-08-14  5:59 ` [PATCH] Coccinelle: add atomic_as_refcounter script Elena Reshetova
2017-08-14 14:16   ` Julia Lawall
2017-08-15 12:19     ` Reshetova, Elena
2017-07-18  7:48 [PATCH] Coccinelle report script for refcounters Elena Reshetova
2017-07-18  7:48 ` [PATCH] Coccinelle: add atomic_as_refcounter script Elena Reshetova
2017-07-18 16:21   ` Kees Cook
2017-07-19 10:54     ` Reshetova, Elena
2017-08-04 15:23   ` Julia Lawall
2017-08-07 11:06     ` Reshetova, Elena

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=2236FBA76BA1254E88B949DDB74E612B6FF5F9CA@IRSMSX102.ger.corp.intel.com \
    --to=elena.reshetova@intel.com \
    --cc=Gilles.Muller@lip6.fr \
    --cc=cocci@systeme.lip6.fr \
    --cc=ishkamiel@gmail.com \
    --cc=julia.lawall@lip6.fr \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.