linux-kernel - Re: coccinelle: api/devm_platform_ioremap

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]

Date:   Tue, 29 Oct 2019 09:55:02 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
cc:     Julia Lawall <julia.lawall@...6.fr>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Joe Perches <joe@...ches.com>, Marc Zyngier <maz@...nel.org>,
        Markus Elfring <Markus.Elfring@....de>,
        Himanshu Jha <himanshujha199640@...il.com>,
        kernel-janitors@...r.kernel.org,
        Coccinelle <cocci@...teme.lip6.fr>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Gilles Muller <Gilles.Muller@...6.fr>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        Thomas Gleixner <tglx@...utronix.de>,
        YueHaibing <yuehaibing@...wei.com>
Subject: Re: coccinelle: api/devm_platform_ioremap_resource: remove useless
 script



On Tue, 29 Oct 2019, Masahiro Yamada wrote:

> Hi Julia
>
> On Fri, Oct 25, 2019 at 5:38 PM Julia Lawall <julia.lawall@...6.fr> wrote:
> >
> >
> >
> > On Fri, 25 Oct 2019, Andy Shevchenko wrote:
> >
> > > On Fri, Oct 25, 2019 at 12:40:52AM +0900, Masahiro Yamada wrote:
> > > > On Sun, Oct 20, 2019 at 7:13 AM Joe Perches <joe@...ches.com> wrote:
> > > > > On Sat, 2019-10-19 at 21:43 +0100, Marc Zyngier wrote:
> > >
> > > > Alexandre Belloni used
> > > > https://lore.kernel.org/lkml/9bbcce19c777583815c92ce3c2ff2586@www.loen.fr/
> > > > as a reference, but this is not the output from coccicheck.
> > > > The patch author just created a wrong patch by hand.
> > >
> > > Exactly. Removal of the script is a mistake. Like I said before is a healing
> > > (incorrect by the way!) by symptoms.
> > >
> > > > The deleted semantic patch supports MODE=patch,
> > > > which creates a correct patch, and is useful.
> > >
> > > Right!
> >
> > I ran it on the version of Linux that still has the script:
> >
> > fe7d2c23d748e4206f4bef9330d0dff9abed7411
> >
> > and managed to compile 341 of the generated files in the time I had
> > available, and all compiled successfully.
>
> Yeah, this semantic patch did the correct conversion
> as its header part showed the confidence.
>
> // Confidence: High
>
>
>
> >  I can let it run again, and see
> > how it goes for the rest.  Perhaps it would be acceptable if there was no
> > report, and people would be forced to use the generated patch?
>
> I do not think this is the right thing.
> MODE=report is the default, and it is fine.
>
> >
> > If someone is writing lots of patches on this issue by hand, then perhaps
> > they don't have make coccicheck to produce patches, and then would
> > overlook this case completely.
> >
> > If it would be helpful, I could group the generated patches by maintainer
> > or by subdirectory and send them out, if it would be easier to review them
> > all at once.
>
> Yes, please.
>
> Subsystem maintainers trust you,
> so I think it will make things move smoothly.
>
> After converting most of files,
> I want 283ea345934d277e30c841c577e0e2142b4bfcae reverted.

OK.  I got 477 of the files to compile directly.  I can send patches on
them, and then look into the issues on the remaining ones (probably
configuration issues).

julia

>
>
> >
> > Anyway, the rule is not in the kernel at the moment.  For it's future, I'm
> > open to whatever people find best.  Personally, I prefer when same things
> > are done in the same way - it makes the code easier to understand and
> > makes it simpler to address other issues when they arise.
>
>
> We always did the same things in the same way
> except commit 283ea345934d277e30c841c577e0e2142b4bfcae
>
>
>
>
> --
> Best Regards
> Masahiro Yamada
>