Re: [PATCH 4.10 000/167] 4.10.2-stable review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/10/2017 03:52 PM, Kevin Hilman wrote:
On Fri, Mar 10, 2017 at 3:24 PM, Kevin Hilman <khilman@xxxxxxxxxxxx> wrote:
kernelci.org bot <bot@xxxxxxxxxxxx> 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@xxxxxxx>
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@xxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>


Kevin





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]