linux-kernel - Re: [PATCH v5 3/3] coccinelle: Add script to check for platform_get

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7debc03d-0bed-e0d7-a793-089fcc85c9ee@web.de>
Date:   Tue, 30 Jul 2019 10:49:00 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Stephen Boyd <swboyd@...omium.org>,
        Julia Lawall <Julia.Lawall@...6.fr>,
        Gilles Muller <Gilles.Muller@...6.fr>,
        Michal Marek <michal.lkml@...kovi.net>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        kernel-janitors@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, cocci@...teme.lip6.fr,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh@...nel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Mark Brown <broonie@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v5 3/3] coccinelle: Add script to check for
 platform_get_irq() excessive prints

> I'm not sure this will be accepted or not

The patch review and corresponding clarification will become more interesting,
won't it?

I am missing more constructive feedback to remaining software development concerns.
https://lore.kernel.org/patchwork/comment/1301194/
https://lore.kernel.org/lkml/3baa3e3c-c122-e868-55a0-597e279496ac@web.de/
https://systeme.lip6.fr/pipermail/cocci/2019-July/006143.html
https://lkml.org/lkml/2019/7/24/886

> given that Markus indicates a similar patch was made for other error messages

I am also curious how the acceptance will evolve around such change possibilities.
Did you get any useful development ideas from this approach?

> that this may be able to be merged into.

I find it unlikely that a merge will be useful in this case because of specific
property differences in SmPL specifications.
But I imagine that improved SmPL script variants will be helpful.

>  create mode 100644 scripts/coccinelle/api/platform_get_irq.cocci

On which storage locations would we like to agree?

> +@...ends on context@
> +expression ret;
> +struct platform_device *E;

How much does this specification matter for the parameters
of the mentioned functions (in the SmPL script)?
Will the selection of function names be sufficient for the discussed
source code search pattern?

> +@@
> +
> +ret =
> +(
> +platform_get_irq
> +|
> +platform_get_irq_byname
> +)(E, ...);

* Would you eventually like to extend the function name selection?

* Will the SmPL ellipsis be appropriate without the metavariable “E”?

> +if ( ret \( < \| <= \) 0 )
> +{
> +(
> +if (ret != -EPROBE_DEFER)
> +{ ...
> +*dev_err(...);
> +... }
> +|
> +...
> +*dev_err(...);
> +)
> +...
> +}

I suggest to reconsider SmPL implementation details once more.

* Case distinction for curly brackets of compound statements

* Application of the SmPL construct “<+... … ...+>”

> +@...ipt:python depends on org@
> +p1 << r.p1;
> +@@
> +
> +cocci.print_main(p1)
> +
> +@...ipt:python depends on report@
> +p1 << r.p1;
> +@@
> +
> +msg = "line %s is redundant because platform_get_irq() already prints an error" % (p1[0].line)
> +coccilib.report.print_report(p1[0],msg)

Will the message constructions be adjusted?

Regards,
Markus