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: <20130729155609.bb9d635427d8eef1da954e3a@canb.auug.org.au>
Date:	Mon, 29 Jul 2013 15:56:09 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Mark Brown <broonie@...nel.org>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the spi tree

Hi Mark,

On Mon, 29 Jul 2013 06:00:11 +0100 Mark Brown <broonie@...nel.org> wrote:
>
> On Mon, Jul 29, 2013 at 01:42:23PM +1000, Stephen Rothwell wrote:
> 
> > drivers/spi/spi-pxa2xx-pxadma.c: In function 'wait_dma_channel_stop':
> > drivers/spi/spi-pxa2xx-pxadma.c:136:2: error: implicit declaration of function 'DCSR' [-Werror=implicit-function-declaration]
> >   while (!(DCSR(channel) & DCSR_STOPSTATE) && --limit)
> 
> > Frankly, Mark, if you are unable or unwilling to do some basic cross
> > build testing, please do not do any more of these patches that add
> > CONFIG_COMPILE_TEST.  Leave them to someone who can.
> 
> This was cross built.  It didn't show up due to the fact that the
> minimal configs I use for build coverage (and in fact every single
> config I was building) didn't have PCI turned on (which is a dependency
> for this option actually building anything) which allowed this config
> symbol to be enabled without showing the problem due to the slightly odd
> way the config for the driver is structured; any system with PCI that's
> not PXA would be affected.
> 
> Most (though not all) of the other issues have been due to similar
> stuff.  I do rely on the 0 day tester for the full builds but I do pretty
> routinely test (especially on x86) these days though with minimal
> configs and on my full working tree.

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.

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
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/>

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.
-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au

Content of type "application/pgp-signature" skipped