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  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]
Date:   Mon, 18 Feb 2019 09:19:30 +0100
From:   Markus Elfring <>
To:     Julia Lawall <>,
        Wen Yang <>
Cc:     Wen Yang <>,
        Gilles Muller <>,
        Nicolas Palix <>,
        Michal Marek <>,
        Masahiro Yamada <>,
        Cheng Shengyu <>,,,
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).

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?


Powered by blists - more mailing lists