public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Julia Lawall <julia.lawall@lip6.fr>, cocci@systeme.lip6.fr
Cc: Gilles Muller <Gilles.Muller@lip6.fr>,
	Himanshu Jha <himanshujha199640@gmail.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Nicolas Palix <nicolas.palix@imag.fr>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors@vger.kernel.org
Subject: Re: Coccinelle: zalloc-simple: Delete function "kmem_cache_alloc" from SmPL rules
Date: Thu, 01 Feb 2018 11:00:09 +0000	[thread overview]
Message-ID: <f2793c7f-af1b-edc0-d9ea-0937c7241733@users.sourceforge.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1802011125460.3135@hadrien>

>> * Do we agree that a proper size determination is essential for every
>>   condition in the discussed SmPL rules together with forwarding
>>   this information?
> 
> No.  I don't mind a few false positives.

I have got other source code analysis expectations there.

This SmPL script contains the tag “Confidence: High”.


> The user can look at the answer and see if it is a false positive or not.

The situation is questionable because of a specific software design detail.

Unsafe source code search patterns could be stored under other script names
(or even different directories).
How do you think about to move the SmPL code (which I proposed for deletion)
to another script if you would insist to preserve it?


> Furthermore, I told you how to address this function so that the size
> issue would be taken care of.

You offered another bit of information.

I find your interpretation of this aspect also unclear at the moment.


> That is the patch that I would accept.

Are there any better development solutions left over?


>> * How can a name be ever relevant (within the published SmPL approach)
>>   for a function when it was designed in the way that it should generally
>>   work without a size parameter?
> 
> No idea what this means.

I am trying again to resolve corresponding communication difficulties.
Thus I suggest to take another look at the following SmPL code fragment.

…
  kmalloc_node(E1, ...)\|kmem_cache_alloc(...)\|kmem_alloc(E1, ...)\|
…
* memset((T2)x,0,E1);
…


How many constraints should be considered for function parameters here?

Regards,
Markus

  reply	other threads:[~2018-02-01 11:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAK7LNAR27r4j4c1FCh_ObpMpBKXgSP6Vq3P=reA-JKoTji6Q1A@mail.gmail.com>
2018-01-02 14:25 ` Rename the SmPL script “kzalloc-….cocci”? SF Markus Elfring
2018-01-02 14:28   ` Julia Lawall
2018-01-02 14:38     ` SF Markus Elfring
2018-01-02 14:43       ` Julia Lawall
2018-01-02 15:00         ` SF Markus Elfring
2018-01-08  9:55         ` SF Markus Elfring
2018-01-03 11:55     ` [PATCH] Coccinelle: Rename the script for a transformation of memory allocations SF Markus Elfring
2018-01-03 12:02       ` Julia Lawall
2018-01-03 12:13         ` SF Markus Elfring
2018-01-03 12:17           ` Julia Lawall
2018-01-03 12:31             ` SF Markus Elfring
2018-01-03 12:40               ` Julia Lawall
2018-01-03 12:45                 ` SF Markus Elfring
2018-01-04  8:36                 ` SF Markus Elfring
2018-01-04  8:54                   ` Julia Lawall
2018-01-04  9:43                     ` SF Markus Elfring
2018-01-17 16:47 ` [v2] Coccinelle: zalloc-simple: Safer transformations with SmPL SF Markus Elfring
2018-01-19 16:14 ` Coccinelle: zalloc-simple: Checking consequences from the usage of at signs in Python strings SF Markus Elfring
2018-01-19 16:18   ` Julia Lawall
2018-01-19 16:43     ` SF Markus Elfring
2018-01-24  8:41     ` SF Markus Elfring
2018-01-31 17:28 ` [v2] Coccinelle: zalloc-simple: Delete function =?UTF-8?B?4oCca21lbV9jYWNoZV9hbGxvY SF Markus Elfring
2018-01-31 17:38   ` =?UTF-8?Q?Re=3A_=5Bv2=5D_Coccinelle=3A_zalloc-simple=3A_Delete_function_=E2=80=9Ckmem=5Fcache=5Fallo Julia Lawall
2018-01-31 17:53     ` [v2] Coccinelle: zalloc-simple: Delete function =?UTF-8?B?4oCca21lbV9jYWNoZV9hbGxvY SF Markus Elfring
2018-02-01  9:35 ` [PATCH] Coccinelle: zalloc-simple: Delete function "kmem_cache_alloc" from SmPL rules SF Markus Elfring
2018-02-01  9:40   ` Julia Lawall
2018-02-01 10:17     ` SF Markus Elfring
2018-02-01 10:27       ` Julia Lawall
2018-02-01 11:00         ` SF Markus Elfring [this message]
2018-02-03  7:22         ` Coccinelle: zalloc-simple: Checking consistency for " SF 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=f2793c7f-af1b-edc0-d9ea-0937c7241733@users.sourceforge.net \
    --to=elfring@users.sourceforge.net \
    --cc=Gilles.Muller@lip6.fr \
    --cc=cocci@systeme.lip6.fr \
    --cc=himanshujha199640@gmail.com \
    --cc=julia.lawall@lip6.fr \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=nicolas.palix@imag.fr \
    --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