All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@lip6.fr>
To: wen.yang99@zte.com.cn
Cc: Markus.Elfring@web.de, yellowriver2010@hotmail.com,
	Gilles Muller <Gilles.Muller@lip6.fr>,
	nicolas.palix@imag.fr, michal.lkml@markovi.net,
	yamada.masahiro@socionext.com, cheng.shengyu@zte.com.cn,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	cocci@systeme.lip6.fr
Subject: Re: [v6] coccinelle: semantic code search for missing put_device()
Date: Mon, 18 Feb 2019 07:43:26 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.21.1902180740550.3111@hadrien> (raw)
In-Reply-To: <201902181122502228026@zte.com.cn>

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]



On Mon, 18 Feb 2019, wen.yang99@zte.com.cn wrote:

> > > when != e = id achieves this behavior.
> >
> > I can not agree to this view completely because of the meaning that is connected
> > with these variable identifiers.
> >
> > Both metavariables share the kind “expression”. So I can imagine
> > that there is an intersection for the source code match possibility.
> > But one was intentionally restricted to the kind “local idexpression” so far.
> >
> > 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.
> When != e = id achieves this behavior.

They are the same because neither issue arises.  I would have a hard time
saying which one is more reasonable to test, since both are extremely
unlikely.

julia


>
> In addition, we feel that we should probably accept this patch first, use it to find more memory leaks, and solve the actual problems in the kernel code.
> As for the patch itself, we can continue to pursue perfect in the process of using it to solve practical problems.
>
> Regards,
> Wen

WARNING: multiple messages have this Message-ID (diff)
From: Julia Lawall <julia.lawall@lip6.fr>
To: wen.yang99@zte.com.cn
Cc: kernel-janitors@vger.kernel.org, michal.lkml@markovi.net,
	yellowriver2010@hotmail.com, nicolas.palix@imag.fr,
	linux-kernel@vger.kernel.org, Markus.Elfring@web.de,
	cheng.shengyu@zte.com.cn, cocci@systeme.lip6.fr
Subject: Re: [v6] coccinelle: semantic code search for missing put_device()
Date: Mon, 18 Feb 2019 06:43:26 +0000	[thread overview]
Message-ID: <alpine.DEB.2.21.1902180740550.3111@hadrien> (raw)
In-Reply-To: <201902181122502228026@zte.com.cn>

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]



On Mon, 18 Feb 2019, wen.yang99@zte.com.cn wrote:

> > > when != e = id achieves this behavior.
> >
> > I can not agree to this view completely because of the meaning that is connected
> > with these variable identifiers.
> >
> > Both metavariables share the kind “expression”. So I can imagine
> > that there is an intersection for the source code match possibility.
> > But one was intentionally restricted to the kind “local idexpression” so far.
> >
> > 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.
> When != e = id achieves this behavior.

They are the same because neither issue arises.  I would have a hard time
saying which one is more reasonable to test, since both are extremely
unlikely.

julia


>
> In addition, we feel that we should probably accept this patch first, use it to find more memory leaks, and solve the actual problems in the kernel code.
> As for the patch itself, we can continue to pursue perfect in the process of using it to solve practical problems.
>
> Regards,
> Wen

WARNING: multiple messages have this Message-ID (diff)
From: Julia Lawall <julia.lawall@lip6.fr>
To: wen.yang99@zte.com.cn
Cc: kernel-janitors@vger.kernel.org, michal.lkml@markovi.net,
	yellowriver2010@hotmail.com, nicolas.palix@imag.fr,
	linux-kernel@vger.kernel.org, Markus.Elfring@web.de,
	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 07:43:26 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.21.1902180740550.3111@hadrien> (raw)
In-Reply-To: <201902181122502228026@zte.com.cn>

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]



On Mon, 18 Feb 2019, wen.yang99@zte.com.cn wrote:

> > > when != e = id achieves this behavior.
> >
> > I can not agree to this view completely because of the meaning that is connected
> > with these variable identifiers.
> >
> > Both metavariables share the kind “expression”. So I can imagine
> > that there is an intersection for the source code match possibility.
> > But one was intentionally restricted to the kind “local idexpression” so far.
> >
> > 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.
> When != e = id achieves this behavior.

They are the same because neither issue arises.  I would have a hard time
saying which one is more reasonable to test, since both are extremely
unlikely.

julia


>
> In addition, we feel that we should probably accept this patch first, use it to find more memory leaks, and solve the actual problems in the kernel code.
> As for the patch itself, we can continue to pursue perfect in the process of using it to solve practical problems.
>
> Regards,
> Wen

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

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

  reply	other threads:[~2019-02-18  6:43 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-16 16:05 [Cocci] [PATCH v6] coccinelle: semantic code search for missing put_device() Wen Yang
2019-02-16 16:33 ` Julia Lawall
2019-02-16 16:33   ` [Cocci] " Julia Lawall
2019-02-16 18:39 ` [v6] " Markus Elfring
2019-02-16 18:39   ` [Cocci] " Markus Elfring
2019-02-16 18:39   ` Markus Elfring
2019-02-17  2:32   ` [Cocci] 答复: " Wen Yang
2019-02-17  7:42     ` Markus Elfring
2019-02-17  7:42       ` [Cocci] " Markus Elfring
2019-02-17  7:42       ` 答复: [v6] coccinelle: semantic code =?UTF-8?Q?_search_for_missing_p Markus Elfring
2019-02-17  9:50 ` [PATCH v6] coccinelle: semantic code search for missing put_device() Markus Elfring
2019-02-17  9:50   ` [Cocci] " Markus Elfring
2019-02-17  9:50   ` Markus Elfring
2019-02-17 11:37   ` Julia Lawall
2019-02-17 11:37     ` [Cocci] " Julia Lawall
2019-02-17 11:37     ` Julia Lawall
2019-02-17 11:42     ` Markus Elfring
2019-02-17 11:42       ` [Cocci] " Markus Elfring
2019-02-17 11:42       ` Markus Elfring
2019-02-17 11:48       ` Julia Lawall
2019-02-17 11:48         ` [Cocci] " Julia Lawall
2019-02-17 11:48         ` Julia Lawall
2019-02-17 12:00         ` [v6] " Markus Elfring
2019-02-17 12:00           ` [Cocci] " Markus Elfring
2019-02-17 12:00           ` Markus Elfring
2019-02-17 12:05           ` Julia Lawall
2019-02-17 12:05             ` [Cocci] " Julia Lawall
2019-02-17 12:05             ` Julia Lawall
2019-02-17 12:20             ` Markus Elfring
2019-02-17 12:20               ` [Cocci] " Markus Elfring
2019-02-17 12:20               ` Markus Elfring
2019-02-17 12:52               ` Julia Lawall
2019-02-17 12:52                 ` [Cocci] " Julia Lawall
2019-02-17 12:52                 ` Julia Lawall
2019-02-17 13:14                 ` Markus Elfring
2019-02-17 13:14                   ` [Cocci] " Markus Elfring
2019-02-17 13:14                   ` Markus Elfring
2019-02-18  3:22                   ` [Cocci] " wen.yang99
2019-02-18  6:43                     ` Julia Lawall [this message]
2019-02-18  6:43                       ` Julia Lawall
2019-02-18  6:43                       ` Julia Lawall
2019-02-18  8:19                       ` Markus Elfring
2019-02-18  8:19                         ` [Cocci] " Markus Elfring
2019-02-18  8:19                         ` Markus Elfring
2019-02-19  2:14                         ` [Cocci] " wen.yang99
2019-02-19  7:04                           ` Julia Lawall
2019-02-19  7:04                             ` [Cocci] " Julia Lawall
2019-02-19  7:04                             ` Julia Lawall
2019-02-19  8:12                             ` Markus Elfring
2019-02-19  8:12                               ` [Cocci] " Markus Elfring
2019-02-19  8:12                               ` Markus Elfring
2019-02-19  8:29                           ` Markus Elfring
2019-02-19  8:29                             ` [Cocci] " Markus Elfring
2019-02-19  8:29                             ` Markus Elfring
2019-02-19  9:09                             ` [Cocci] " wen.yang99
2019-02-19  9:30                               ` Markus Elfring
2019-02-19  9:30                                 ` [Cocci] " Markus Elfring
2019-02-19  9:30                                 ` Markus Elfring
2019-03-06 11:18                           ` Markus Elfring
2019-03-06 11:18                             ` [Cocci] " Markus Elfring
2019-03-06 11:18                             ` Markus Elfring
2019-02-18 21:40                     ` Markus Elfring
2019-02-18 21:40                       ` [Cocci] " Markus Elfring
2019-02-18 21:40                       ` 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.1902180740550.3111@hadrien \
    --to=julia.lawall@lip6.fr \
    --cc=Gilles.Muller@lip6.fr \
    --cc=Markus.Elfring@web.de \
    --cc=cheng.shengyu@zte.com.cn \
    --cc=cocci@systeme.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=yamada.masahiro@socionext.com \
    --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
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.