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-next>] [day] [month] [year] [list]
Date:	Sat, 25 Jun 2016 11:23:05 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	kernel-build-reports@...ts.linaro.org,
	Build bot for Mark Brown <broonie@...nel.org>,
	linaro-kernel@...ts.linaro.org, stable@...r.kernel.org,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: v4.4.14 build: 0 failures 1 warnings (v4.4.14)

On Saturday, June 25, 2016 12:37:17 AM CEST Build bot for Mark Brown wrote:
> Warnings Summary: 1
> arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
>           1 ../drivers/xen/balloon.c:155:13: warning:
>             'release_memory_resource' declared 'static' but never defined
> -------------------------------------------------------------------------------
> Passed with no errors, warnings or mismatches:
> 
> arm64-allnoconfig
> arm-multi_v5_defconfig
> arm-multi_v7_defconfig
> x86_64-defconfig
> arm-allmodconfig
> arm-allnoconfig
> x86_64-allnoconfig
> arm64-defconfig

Hi Greg,

It seems we're down to a single warning on ARM and ARM64 now, and
the fix just got merged as commit

842775f15090 ("xen/balloon: Fix declared-but-not-defined warning")

so we can for the first time have a stable kernel that builds
without warnings on these architectures, nice!

On 4.7-rc, there are currently two warnings:
> fs/reiserfs/ibalance.c:1156:2: warning: 'new_insert_key' may be
>         used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/staging/iio/adc/ad7606_spi.c:24:18: warning: 'data' may be
>         used uninitialized in this function [-Wmaybe-uninitialized]

The first one is an old issue that gcc recently started warning for,
a workaround (reiserfs: fix "new_insert_key may be used uninitialized
...") is currently in Andrew's akpm-current, but I think it's not
planned for 4.7 since it's not a regression and the code works
correctly.

The second one is a real bug, and the fix is now in the staging-linus
tree.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ