linux-kernel - Re: linux-next: Tree for Oct 21 (panel-simple.c)

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: <20131022081019.GA15640@ulmo.nvidia.com>
Date:	Tue, 22 Oct 2013 10:10:20 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Randy Dunlap <rdunlap@...radead.org>
Cc:	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>,
	dri-devel@...ts.freedesktop.org
Subject: Re: linux-next: Tree for Oct 21 (panel-simple.c)

On Mon, Oct 21, 2013 at 04:20:02PM -0700, Randy Dunlap wrote:
> On 10/21/13 08:36, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://gitorious.org/thierryreding/linux-next.git
> > 
> > A next-20131021 tag is also provided for convenience.
> > 
> > Gained a couple new conflicts, loads of build failures. I've tried to
> > fix the most obvious ones, but as a downside haven't gotten around to
> > write up the specifics about the conflicts. I might still do that
> > tomorrow, but I figured most people wouldn't have time to look into
> > those anyway given that they'll be busy with the conferences.
> 
> on i386:
> 
> drivers/built-in.o: In function `panel_simple_probe':
> panel-simple.c:(.text+0x3c7ca): undefined reference to `of_find_backlight_by_node'

Hi Randy,

Thanks for running this. I'll come up with a patch to fix this, since I
originally wrote of_find_backlight_by_node().

Running the randconfig that you provided yielded some other interesting
warnings, though. There are a few occurrences where gcc compiles about
functions not returning a value, which is caused by people assuming that
BUG() never returns. But it happens that your randconfig also unsets
CONFIG_BUG, which turns BUG into a no-op and therefore causing gcc to
rightfully complain.

Before attempting to fix these, I was wondering whether that would be
considered useful. I personally think that we should eliminate warnings
as much as possible because it helps filtering out genuine problems. But
the BUG Kconfig option also depends on EXPERT, so I guess it's usually
not even visible and possibly not worth bothering about.

Thierry

Content of type "application/pgp-signature" skipped