linux-kernel - Re: linux-next: build failure after merge of the spi tree

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: <20130729064028.GR9858@sirena.org.uk>
Date:	Mon, 29 Jul 2013 07:40:28 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the spi tree

On Mon, Jul 29, 2013 at 03:56:09PM +1000, Stephen Rothwell wrote:

> Did the 0 day tester find these?  If so, then maybe you should wait a
> while longer before adding these things to your published trees.  If not,
> then I wonder why not.

No, it didn't.  The latency from the zero day tester seems to be quite
variable at the minute - sometimes it's just not reporting things at
all before they get found and fixed otherwise, sometimes it's as
astonishingly prompt as ever and sometimes it's reporting things other
than build issues but not the build issues.

> Even so as a developer, you should not really be submitting patches that
> have not been at least build tested.   You can find out which files are

Right, I don't submit stuff that's not been build tested at all except
in unusual situations - the issues have been coverage and dependency
ones.

> affected by these config changes and then really simply do:
> (assuming an x86 native platform - adjust for cross compiling)

> $ mkdir ../test.obj
> $ make O=../test.obj allmodconfig
> <make sure that the CONFIG options got turned on>
> $ make O=../test.obj <files affected s/.c/.o/>

When I change source files I do take steps to ensure that they've been
built including variations on the above, this specific issue is a fairly
unusual situation.

> You don't need to do full builds to find most of this stuff.  Of course,
> this will not find link time errors or missing module symbols.

Yeah, unfortunately those issues are a good proportion of what gets
caught by this sort of testing that wouldn't get caught in normal
development so it doesn't seem worth doing something that won't at least
give a linking kernel.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)