[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1837c4b3-7f41-224a-bb04-e321ba407bd7@roeck-us.net>
Date: Fri, 10 Mar 2017 17:04:27 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Kevin Hilman <khilman@...libre.com>,
"kernelci.org bot" <bot@...nelci.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
lkml <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
akpm@...ux-foundation.org, Shuah Khan <shuahkh@....samsung.com>,
patches@...nelci.org,
Ben Hutchings <ben.hutchings@...ethink.co.uk>,
stable@...r.kernel.org, Andy Gross <andy.gross@...aro.org>
Subject: Re: [PATCH 4.10 000/167] 4.10.2-stable review
On 03/10/2017 03:52 PM, Kevin Hilman wrote:
> On Fri, Mar 10, 2017 at 3:24 PM, Kevin Hilman <khilman@...libre.com> wrote:
>> kernelci.org bot <bot@...nelci.org> writes:
>>
>>> stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict (v4.10.1-168-gcdc1f9d24aac)
>>>
>>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/
>>> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/
>>>
>>> Tree: stable-rc
>>> Branch: local/linux-4.10.y
>>> Git Describe: v4.10.1-168-gcdc1f9d24aac
>>> Git Commit: cdc1f9d24aac385a7fe4611d7b42f51e20f49cdb
>>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>>> Tested: 101 unique boards, 25 SoC families, 30 builds out of 204
>>>
>>> Boot Regressions Detected:
>>>
>>> arm:
>>>
>>> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>>> am335x-pepper:
>>> lab-baylibre-seattle: new failure (last pass: v4.10-21-gd23a9821d397)
>>
>> This one is a new regression, and a first attempt at bisect was
>> inconclusive.
>
> Bisect fingered the commit below. I confirmed that reverting that
> commit on top of stable-rc/linux-4.10.y gets this am335x-pepper
> platform booting again. What's rather strange is that this boot test
> is using a .cpio.gz initramfs, and not using any ext4 filesystem.
>
Does that even make sense ? Just wondering, after the problems we are currently
experiencing with nios2. Those "bisected" as well to a commit associated with
code which never executed. It turned out that the change in code size caused
completely unrelated memory overwrites to be observed. Reverting the patch in
question also seemed to "fix" the problem. Only, of course, that wasn't true.
Maybe something similar is happening here ?
Guenter
> 04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8 is the first bad commit
> commit 04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8
> Author: Theodore Ts'o <tytso@....edu>
> Date: Sat Feb 4 23:04:00 2017 -0500
>
> ext4: fix inline data error paths
>
> commit eb5efbcb762aee4b454b04f7115f73ccbcf8f0ef upstream.
>
> The write_end() function must always unlock the page and drop its ref
> count, even on an error.
>
> Signed-off-by: Theodore Ts'o <tytso@....edu>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>
>
> Kevin
>
Powered by blists - more mailing lists