linux-kernel - Re: [PATCH 4.2 000/134] 4.2.2-stable review

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: <56095820.1070404@roeck-us.net>
Date:	Mon, 28 Sep 2015 08:09:20 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, shuah.kh@...sung.com,
	stable@...r.kernel.org
Subject: Re: [PATCH 4.2 000/134] 4.2.2-stable review

On 09/28/2015 07:01 AM, Greg Kroah-Hartman wrote:
> On Mon, Sep 28, 2015 at 11:19:41AM +0530, Sudip Mukherjee wrote:
>> On Sat, Sep 26, 2015 at 01:54:12PM -0700, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.2.2 release.
>>> There are 134 patches in this series, all will be posted as a response
>>> to this one.  If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Mon Sep 28 20:51:27 UTC 2015.
>>> Anything received after that time might be too late.
>> Compiled and booted on x86_32. No errors in dmesg.
>>
>> BTW, avr32 allmodconfig failed. Not new failure. 3 patches will be
>> needed to fix that. 2 are already in Linus tree. My doubt is if it is
>> accepted to fix known build failure in stable?
>
> Yes, that would be fine, what are the git commit ids and why aren't
> others seeing this problem?
>

avr32:allmodconfig never built for me if I recall correctly, so I never
added it to my build tests.

There are actually several allmodconfig/allyesconfig builds which historically
never built. Some of them have been addressed over time, but it requires a
substantial effort to keep it that way. On top of that, related failures don't
always have a high priority with developers and/or architecture maintainers.

It is also a matter of resources - while I run several allmodconfig builds,
my test systems are just not powerful enough to do it for all architectures.

So, overall, my approach is to only run allmodconfig for an architecture
if I see an effort by the architecture maintainer(s) to keep it building.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/