Coccinelle Archive on lore.kernel.org
 help / color / Atom feed
From: Markus Elfring <Markus.Elfring@web.de>
To: Wen Yang <wen.yang99@zte.com.cn>, Julia Lawall <julia.lawall@lip6.fr>
Cc: kernel-janitors@vger.kernel.org,
	Michal Marek <michal.lkml@markovi.net>,
	Wen Yang <yellowriver2010@hotmail.com>,
	Nicolas Palix <nicolas.palix@imag.fr>,
	linux-kernel@vger.kernel.org,
	Cheng Shengyu <cheng.shengyu@zte.com.cn>,
	cocci@systeme.lip6.fr
Subject: Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()
Date: Mon, 18 Feb 2019 22:40:32 +0100
Message-ID: <730810ab-5bea-4a8d-54b9-37e1fe2d1498@web.de> (raw)
In-Reply-To: <201902181122502228026@zte.com.cn>

>> Which data element should not get reassigned here (before a corresponding
>> null pointer check)?
>>
>
> Thank you for your comments.
> We did some experiments:
> +id = of_find_device_by_node@p1(x)
> +... when != e = id
> ...
> Or:
> ...
> + ... when != id = e
>
> The number of issuses found by these two methods is the same.

Would you like to clarify the circumstances a bit more under which
you would notice corresponding differences?


> When != e = id achieves this behavior.

I try another explanation approach for a potentially safer source code search.


1. If you would look at the following SmPL code lines again,
   I imagine that you can determine also an useful constraint for this place.

…
+ id = of_find_device_by_node@p1(x)
+ ... when != ?????? = ??????
+ if (!id || ...) { ... return ...; }
…


2. Petr Strnad expressed the need for another constraint in the commit
   “scripts: Coccinelle script for pci_free_consistent()” (from 2013-05-08).
   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci?id=f7b167113753e95ae61383e234f8d10142782ace#n12

   I find that there are additional software development challenges
   to consider around another desirable assignment exclusion from the place
   of the return value storage and the data processing possibilities
   behind the corresponding null pointer check.
   The previous approach worked with the metavariables types (or kinds)
   “expression” and “local idexpression id” to some degree so far.
   But it is expected that an undesirable missed reference release
   can be safely pointed out only if the received platform device pointer
   is used only within a found function implementation.

   I would interpret this data flow requirement in the way
   that the pointer should not be forwarded to a data structure
   with a scope from outside (global?) the found function implementation.
   How would you like to express such an aspect by the current (or future)
   means of the semantic patch language?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

      parent reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-16 16:05 [Cocci] [PATCH v6] " Wen Yang
2019-02-16 16:33 ` Julia Lawall
2019-02-16 18:39 ` [Cocci] [v6] " Markus Elfring
2019-02-17  2:32   ` [Cocci] 答复: " Wen Yang
2019-02-17  7:42     ` Markus Elfring
2019-02-17  9:50 ` [Cocci] [PATCH v6] " Markus Elfring
2019-02-17 11:37   ` Julia Lawall
2019-02-17 11:42     ` Markus Elfring
2019-02-17 11:48       ` Julia Lawall
2019-02-17 12:00         ` [Cocci] [v6] " Markus Elfring
2019-02-17 12:05           ` Julia Lawall
2019-02-17 12:20             ` Markus Elfring
2019-02-17 12:52               ` Julia Lawall
2019-02-17 13:14                 ` Markus Elfring
2019-02-18  3:22                   ` wen.yang99
2019-02-18  6:43                     ` Julia Lawall
2019-02-18  8:19                       ` Markus Elfring
2019-02-19  2:14                         ` wen.yang99
2019-02-19  7:04                           ` Julia Lawall
2019-02-19  8:12                             ` Markus Elfring
2019-02-19  8:29                           ` Markus Elfring
2019-02-19  9:09                             ` wen.yang99
2019-02-19  9:30                               ` Markus Elfring
2019-03-06 11:18                           ` Markus Elfring
2019-02-18 21:40                     ` Markus Elfring [this message]

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=730810ab-5bea-4a8d-54b9-37e1fe2d1498@web.de \
    --to=markus.elfring@web.de \
    --cc=cheng.shengyu@zte.com.cn \
    --cc=cocci@systeme.lip6.fr \
    --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=wen.yang99@zte.com.cn \
    --cc=yellowriver2010@hotmail.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

Coccinelle Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/cocci/0 cocci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 cocci cocci/ https://lore.kernel.org/cocci \
		cocci@systeme.lip6.fr
	public-inbox-index cocci

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/fr.lip6.systeme.cocci


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git