Coccinelle archive on lore.kernel.org
 help / color / Atom feed
From: Markus Elfring <Markus.Elfring@web.de>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Coccinelle <cocci@systeme.lip6.fr>
Subject: Re: [Cocci] Software analysis with SmPL around unchecked pointer function calls
Date: Sat, 19 Oct 2019 21:40:08 +0200
Message-ID: <958b4a11-e45b-3795-a3cb-08f98aaa40d6@web.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1910191740020.3272@hadrien>

>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/arm/display/komeda/komeda_dev.c?id=c4b9850b3676869ac0def5885d781d17f64b3a86#n222
>>
>> …
>> @@ -222,… @@ struct komeda_dev *komeda_dev_create(str
>>
>>  	clk_prepare_enable(mdev->aclk);
>>
>> -	mdev->funcs = product->identify(mdev->reg_base, &mdev->chip);
>>  	if (!komeda_product_match(mdev, product->product_id)) {
>> …
>> 	mdev->funcs->init_format_table(mdev);
>>
>> 	err = mdev->funcs->enum_resources(mdev);
>> …
>>
>>
>> Now I would appreciate once more if the description for the supported
>> software behaviour can be completed for the safe usage of SmPL
>> code exclusion specifications.
> I have no idea what you are asking about here.

I hope that another wording approach can contribute another bit
to a better common understanding of the involved source code
analysis expectations.


> Are you concerned that you don't know the return type of mdev->funcs->init_format_table?

No, not in this test case.

This member function is declared with the return type “void”.
https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/gpu/drm/arm/display/komeda/komeda_dev.h#L83
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/arm/display/komeda/komeda_dev.h?id=c4b9850b3676869ac0def5885d781d17f64b3a86#n94

I would find this function call questionable otherwise.

The desired function is determined over the pointer “mdev->funcs”
which was provided by a call of the function “product->identify(…)”.
The provided function pointer is actually not directly checked
after the data structure member assignment.
This could be an analysis concern. (But it can be determined by inspection
of involved source files that a valid pointer will probably be set.
I assume that the exclusion of null pointers would be too challenging
for the discussed tiny SmPL script.)

The uncertainty around the partly (un)documented software behaviour
for SmPL when constraints makes it unclear then if the presented
source code place should finally be treated as a false positive.
Should it have been excluded because pointer expressions should be detectable
for the metavariable “y” (a bit later)?

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

  parent reply index

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 12:56 [Cocci] Software analysis with SmPL around unchecked " Markus Elfring
2019-10-10 13:13 ` Julia Lawall
2019-10-10 13:35   ` Markus Elfring
2019-10-10 13:38     ` Julia Lawall
2019-10-10 14:04       ` Markus Elfring
     [not found]         ` <alpine.DEB.2.21.1910101606420.2305@hadrien>
2019-10-10 14:15           ` Markus Elfring
     [not found]             ` <alpine.DEB.2.21.1910102053440.2500@hadrien>
2019-10-11  5:11               ` Markus Elfring
2019-10-11  6:07                 ` Julia Lawall
2019-10-11  7:03                   ` Markus Elfring
     [not found]                     ` <alpine.DEB.2.21.1910110906390.2662@hadrien>
2019-10-11  7:30                       ` Markus Elfring
2019-10-11  9:23                       ` Markus Elfring
2019-10-10 16:25       ` Markus Elfring
2019-10-18 12:54   ` [Cocci] Software analysis with SmPL around unchecked pointer " Markus Elfring
2019-10-18 13:31     ` Julia Lawall
2019-10-18 13:42       ` Markus Elfring
2019-10-18 13:49         ` Julia Lawall
2019-10-18 14:20           ` Markus Elfring
2019-10-18 14:30             ` Julia Lawall
2019-10-18 14:34               ` Markus Elfring
2019-10-18 14:39                 ` Julia Lawall
2019-10-18 14:46                   ` Markus Elfring
2019-10-18 14:52                     ` Julia Lawall
2019-10-18 14:56                       ` Markus Elfring
2019-10-18 16:00       ` Markus Elfring
2019-10-18 16:06         ` Julia Lawall
2019-10-18 16:32           ` Markus Elfring
2019-10-19 15:33         ` Markus Elfring
2019-10-19 15:41           ` Julia Lawall
2019-10-19 16:04             ` Markus Elfring
2019-10-19 19:40             ` Markus Elfring [this message]
2019-10-20  5:42               ` Julia Lawall
2019-10-20  6:04                 ` Markus Elfring
2019-10-20  9:22                 ` Markus Elfring

Reply instructions:

You may reply publically 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=958b4a11-e45b-3795-a3cb-08f98aaa40d6@web.de \
    --to=markus.elfring@web.de \
    --cc=cocci@systeme.lip6.fr \
    --cc=julia.lawall@lip6.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

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