linux-kernel - Re: [v6] coccinelle: semantic code search for missing put

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ab463e94-287a-6188-6795-06eeb832e861@web.de>
Date:   Mon, 18 Feb 2019 09:19:30 +0100
From:   Markus Elfring <Markus.Elfring@....de>
To:     Julia Lawall <julia.lawall@...6.fr>,
        Wen Yang <wen.yang99@....com.cn>
Cc:     Wen Yang <yellowriver2010@...mail.com>,
        Gilles Muller <Gilles.Muller@...6.fr>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        Michal Marek <michal.lkml@...kovi.net>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Cheng Shengyu <cheng.shengyu@....com.cn>,
        kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org,
        cocci@...teme.lip6.fr
Subject: Re: [v6] coccinelle: semantic code search for missing put_device()

>>> 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.

This can be because these SmPL specifications share some source code search functionality.

>> When != e = id achieves this behavior.
>
> They are the same because neither issue arises.

You might not notice a difference from a specific source file selection so far.

> I would have a hard time saying which one is more reasonable to test,

I suggest to reconsider the interpretation of this software situation once more.

> since both are extremely unlikely.

I disagree to this view because two ellipses were intentionally specified
in published SmPL scripts.
So some software developers found these “special use cases” important enough.

>> In addition, we feel that we should probably accept this patch first,

I disagree to this imagination because I would prefer to integrate a source code variant
without a bug (which was copied from a version on 2013-05-08 by Petr Strnad).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci?id=f7b167113753e95ae61383e234f8d10142782ace#n12

I hope that nicer run time behaviour can become also relevant here.

>> use it to find more memory leaks, and solve the actual problems in the kernel code.

Your are not hindered to achieve specific software improvements with evolving
development approaches while the clarification and the final integration
of useful scripts for the semantic patch language can take a bit longer.

>> As for the patch itself, we can continue to pursue perfect in the process
>> of using it to solve practical problems.

I am curious on how your attention will evolve further for the corresponding
software correctness.

1. How much will you care for the order of identifiers within the application
   of SmPL assignment exclusions?

2. Would you like to take additional data type restrictions into account?

Regards,
Markus