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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.21.1902190804150.2570@hadrien>
Date:   Tue, 19 Feb 2019 08:04:31 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     wen.yang99@....com.cn
cc:     Markus.Elfring@....de, yellowriver2010@...mail.com,
        Gilles Muller <Gilles.Muller@...6.fr>, nicolas.palix@...g.fr,
        michal.lkml@...kovi.net, yamada.masahiro@...ionext.com,
        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()



On Tue, 19 Feb 2019, wen.yang99@....com.cn wrote:

> > > 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.
>
> Both cases are extremely unlikely.
> Although we have tested these two methods in the existing kernel code,
> considering the evolution of the kernel code, these special cases may occur, so we are willing to take them into account.
> We plan to modify the code like this:
>
>  id = of_find_device_by_node@p1(x)
> -... when != e = id
> +... when != e = (T)id
> +    when != id = (T)e

This change is fine with me.

julia

>
> Do you have any other questions?
> Thanks.
>
> Regards,
> Wen