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]
Date:   Fri, 17 Nov 2017 10:31:47 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Arnd Bergmann <arnd@...db.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        arm-soc <arm@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Fengguang Wu <fengguang.wu@...el.com>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Vladimir Barinov <vladimir.barinov@...entembedded.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Simon Horman <horms+renesas@...ge.net.au>
Subject: Re: [GIT PULL 2/3] ARM: SoC driver updates for 4.15

Hi Arnd, Linus,

On Fri, Nov 17, 2017 at 12:25 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Thu, Nov 16, 2017 at 11:29 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> On Thu, Nov 16, 2017 at 2:02 PM, Arnd Bergmann <arnd@...db.de> wrote:
>>>
>>> ARM: SoC driver updates for v4.15
>>
>> No. This is completely broken, and I can't imagine that it has ever
>> compiled for *anybody*.
>>
>>   drivers/soc/renesas/r8a77970-sysc.c:14:10: fatal error:
>> dt-bindings/power/r8a77970-sysc.h: No such file or directory
>>    #include <dt-bindings/power/r8a77970-sysc.h>
>>
>> and the compiler is completely right. This branch added that
>> r8a77970-sysc.c file, but never added the header file.
>>
>> And it's not some odd merge mistake of mine: I checked. That error is
>> there in the original branch too.
>>
>> Tssk.
>
> Right, I need to figure out how this could have slipped through. I did
> get several "BUILD SUCCESS" mails from the kbuild bot (see
> https://pastebin.com/JDw3EKDZ), which claims to have built it
> successfully in all configurations, including allmodconfig builds on
> arm/arm64 and x86-64. Fengguang, do you remember problems
> with false-negatives recently?
>
> I also did my own tests based on the "for-next" branch and looked
> at the kernelci results of that branch, but that didn't catch the
> mistake as the file in question was added in the third "dt" branch.
>
> The dt-bindings/ files have caused endless problems like this
> in the past, and I've been very careful about spotting missing
> changes when they happen in my next/dt branch and complained
> a lot whenever someone sent me crap that didn't compile because
> of that. Now I've fallen into the same trap in the opposite direction,
> when the patch was in next/dt but missing in next/drivers.

What happened is that Simon queued up the header file in his
dt-bindings branch, without noticing it was needed by his drivers branch.

The dt-bindings header files are sometimes needed by both the drivers
and dt branches, while policy requests they are in their own branch.
For the dt branch, the current trend is to break the dependency by hardcoding
the numbers in the DTS files initially, and replacing them by defines during
the next merge window.
For the drivers branch, it looks like dt-bindings/power/r8a779*-sysc.h header
files were just queued up in the drivers branch previously, together with the
drivers, avoiding the issue, but breaking the policy...

Sorry for the mess. We'll be more careful.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ