This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.14.4-rc1
Greg Kroah-Hartman gregkh@linuxfoundation.org Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()"
Ville Syrjälä ville.syrjala@linux.intel.com drm/i915: Prevent zero length "index" write
Ville Syrjälä ville.syrjala@linux.intel.com drm/i915: Don't try indexed reads to alternate slave addresses
Xiong Zhang xiong.y.zhang@intel.com drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition
Chris Wilson chris@chris-wilson.co.uk drm/i915/fbdev: Serialise early hotplug events with async fbdev config
Hans de Goede j.w.r.degoede@gmail.com drm/i915: Re-register PMIC bus access notifier on runtime resume
Hans de Goede j.w.r.degoede@gmail.com drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2
NeilBrown neilb@suse.com md: forbid a RAID5 from having both a bitmap and a journal.
Sasha Neftin sasha.neftin@intel.com e1000e: fix the use of magic numbers for buffer overrun issue
Don Hiatt don.hiatt@intel.com IB/hfi1: Do not warn on lid conversions for OPA
Don Hiatt don.hiatt@intel.com IB/core: Do not warn on lid conversions for OPA
Sandipan Das sandipan@linux.vnet.ibm.com include/linux/compiler-clang.h: handle randomizable anonymous structs
Michel Dänzer michel.daenzer@amd.com drm/amdgpu: Set adev->vcn.irq.num_types for VCN
Leo Liu leo.liu@amd.com drm/amdgpu: move UVD/VCE and VCN structure out from union
Ville Syrjälä ville.syrjala@linux.intel.com drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
Laurent Pinchart laurent.pinchart+renesas@ideasonboard.com drm/fsl-dcu: Don't set connector DPMS property
Maarten Lankhorst maarten.lankhorst@linux.intel.com drm/fb_helper: Disable all crtc's when initial setup fails.
Rex Zhu Rex.Zhu@amd.com drm/amd/pp: fix typecast error in powerplay.
Christian König christian.koenig@amd.com drm/ttm: once more fix ttm_buffer_object_transfer
Peter Griffin peter.griffin@linaro.org drm/hisilicon: Ensure LDI regs are properly configured.
Jonathan Liu net147@gmail.com drm/panel: simple: Add missing panel_simple_unprepare() calls
Roman Kapl rka@sysgo.com drm/radeon: fix atombios on big endian
Jyri Sarha jsarha@ti.com drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()
Ville Syrjälä ville.syrjala@linux.intel.com drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug
Ville Syrjälä ville.syrjala@linux.intel.com drm/vblank: Fix flip event vblank count
Michel Dänzer michel.daenzer@amd.com drm/ttm: Always and only destroy bo->ttm_resv in ttm_bo_release_list
Christian König christian.koenig@amd.com drm/amdgpu: reserve root PD while releasing it
Christian König christian.koenig@amd.com dma-buf: make reservation_object_copy_fences rcu save
Christian König christian.koenig@amd.com drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more
Ken Wang Ken.Wang@amd.com drm/amdgpu: Remove check which is not valid for certain VBIOS
ozeng oak.zeng@amd.com drm/amdgpu: Properly allocate VM invalidate eng v2
Christian König christian.koenig@amd.com drm/amdgpu: fix error handling in amdgpu_bo_do_create
Ken Wang Ken.Wang@amd.com drm/amdgpu: correct reference clock value on vega10
Dan Carpenter dan.carpenter@oracle.com drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
Dan Carpenter dan.carpenter@oracle.com drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
Alex Deucher alexander.deucher@amd.com Revert "drm/radeon: dont switch vt on suspend"
Jeff Lien jeff.lien@wdc.com nvme-pci: add quirk for delay before CHK RDY for WDC SN200
Peter Rosin peda@axentia.se hwmon: (jc42) optionally try to disable the SMBUS timeout
Rui Hua huarui.dev@gmail.com bcache: recover data from backing when data is clean
Coly Li colyli@suse.de bcache: only permit to recovery read error when cache device is clean
Huacai Chen chenhc@lemote.com bcache: Fix building error on MIPS
Vaibhav Jain vaibhav@linux.vnet.ibm.com cxl: Check if vphb exists before iterating over AFU devices
Hans de Goede hdegoede@redhat.com i2c: i801: Fix Failed to allocate irq -2147483648 error
Heiner Kallweit hkallweit1@gmail.com eeprom: at24: check at24_read/write arguments
Bartosz Golaszewski brgl@bgdev.pl eeprom: at24: correctly set the size for at24mac402
Heiner Kallweit hkallweit1@gmail.com eeprom: at24: fix reading from 24MAC402/24MAC602
Lv Zheng lv.zheng@intel.com ACPI / EC: Fix regression related to PM ops support in ECDT device
Bastian Stender bst@pengutronix.de mmc: core: prepend 0x to OCR entry in sysfs
Bastian Stender bst@pengutronix.de mmc: core: prepend 0x to pre_eol_info entry in sysfs
Adrian Hunter adrian.hunter@intel.com mmc: block: Ensure that debugfs files are removed
Adrian Hunter adrian.hunter@intel.com mmc: core: Do not leave the block driver in a suspended state
Adrian Hunter adrian.hunter@intel.com mmc: block: Check return value of blk_get_request()
Adrian Hunter adrian.hunter@intel.com mmc: block: Fix missing blk_put_request()
Ulf Hansson ulf.hansson@linaro.org mmc: sdhci: Avoid swiotlb buffer being full
Dr. David Alan Gilbert dgilbert@redhat.com KVM: lapic: Fixup LDR on load in x2apic
Dr. David Alan Gilbert dgilbert@redhat.com KVM: lapic: Split out x2apic ldr calculation
Paolo Bonzini pbonzini@redhat.com KVM: x86: inject exceptions produced by x86_decode_insn
Liran Alon liran.alon@oracle.com KVM: x86: Exit to user-mode on #UD intercept when emulator requires
Liran Alon liran.alon@oracle.com KVM: x86: pvclock: Handle first-time write to pvclock-page contains random junk
Michael Ellerman mpe@ellerman.id.au powerpc/kexec: Fix kexec/kdump in P9 guest kernels
Mahesh Salgaonkar mahesh@linux.vnet.ibm.com powerpc/powernv: Fix kexec crashes caused by tlbie tracing
Ard Biesheuvel ard.biesheuvel@linaro.org arm64: ftrace: emit ftrace-mod.o contents through code
Ard Biesheuvel ard.biesheuvel@linaro.org arm64: module-plts: factor out PLT generation code for ftrace
John Johansen john.johansen@canonical.com apparmor: fix oops in audit_signal_cb hook
Peter Ujfalusi peter.ujfalusi@ti.com omapdrm: hdmi4: Correct the SoC revision matching
Laurent Pinchart laurent.pinchart@ideasonboard.com drm: omapdrm: Fix DPI on platforms using the DSI VDDS
Martin Schwidefsky schwidefsky@de.ibm.com s390: revert ELF_ET_DYN_BASE base changes
Vasily Averin vvs@virtuozzo.com lockd: lost rollback of set_grace_period() in lockd_down_net()
Ondrej Mosnáček omosnacek@gmail.com crypto: skcipher - Fix skcipher_walk_aead_common
Stephan Mueller smueller@chronox.de crypto: af_alg - remove locking in async callback
Stephan Mueller smueller@chronox.de crypto: algif_aead - skip SGL entries with NULL page
Naofumi Honda honda@math.sci.hokudai.ac.jp nfsd: fix panic in posix_unblock_lock called from nfs4_laundromat
Trond Myklebust trond.myklebust@primarydata.com nfsd: Fix another OPEN stateid race
Trond Myklebust trond.myklebust@primarydata.com nfsd: Fix stateid races between OPEN and CLOSE
Josef Bacik jbacik@fb.com btrfs: clear space cache inode generation always
Kirill A. Shutemov kirill.shutemov@linux.intel.com mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
Ian Kent raven@themaw.net autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
Ian Kent raven@themaw.net autofs: revert "autofs: take more care to not update last_used on path walk"
OGAWA Hirofumi hirofumi@mail.parknet.co.jp fs/fat/inode.c: fix sb_rdonly() change
Shakeel Butt shakeelb@google.com mm, memcg: fix mem_cgroup_swapout() for THPs
Zi Yan zi.yan@cs.rutgers.edu mm: migrate: fix an incorrect call of prep_transhuge_page()
chenjie chenjie6@huawei.com mm/madvise.c: fix madvise() infinite loop under special circumstances
Kees Cook keescook@chromium.org exec: avoid RLIMIT_STACK races with prlimit()
Dan Williams dan.j.williams@intel.com IB/core: disable memory registration of filesystem-dax vmas
Dan Williams dan.j.williams@intel.com v4l2: disable filesystem-dax mapping support
Dan Williams dan.j.williams@intel.com mm: fail get_vaddr_frames() for filesystem-dax mappings
Dan Williams dan.j.williams@intel.com mm: introduce get_user_pages_longterm
Dan Williams dan.j.williams@intel.com device-dax: implement ->split() to catch invalid munmap attempts
Dan Williams dan.j.williams@intel.com mm, hugetlbfs: introduce ->split() to vm_operations_struct
Dan Williams dan.j.williams@intel.com mm: fix device-dax pud write-faults triggered by get_user_pages()
Mike Kravetz mike.kravetz@oracle.com mm/cma: fix alloc_contig_range ret code/potential leak
Kirill A. Shutemov kirill.shutemov@linux.intel.com mm, thp: Do not make page table dirty unconditionally in touch_p[mu]d()
Wang Nan wangnan0@huawei.com mm, oom_reaper: gather each vma to prevent leaking TLB entry
Michal Hocko mhocko@suse.com mm, memory_hotplug: do not back off draining pcp free pages from kworker context
Stefan Brüns stefan.bruens@rwth-aachen.de platform/x86: hp-wmi: Fix tablet mode detection for convertibles
-------------
Diffstat:
Documentation/devicetree/bindings/hwmon/jc42.txt | 4 + Makefile | 4 +- arch/arm64/Makefile | 3 - arch/arm64/include/asm/module.h | 46 +++++++++- arch/arm64/kernel/Makefile | 3 - arch/arm64/kernel/ftrace-mod.S | 18 ---- arch/arm64/kernel/ftrace.c | 14 +-- arch/arm64/kernel/module-plts.c | 50 +++-------- arch/arm64/kernel/module.lds | 1 + arch/powerpc/kernel/misc_64.S | 2 + arch/powerpc/mm/hash_native_64.c | 15 +++- arch/s390/include/asm/elf.h | 15 ++-- arch/x86/entry/entry_64.S | 10 +-- arch/x86/include/asm/pgtable.h | 6 ++ arch/x86/kvm/lapic.c | 12 ++- arch/x86/kvm/svm.c | 2 + arch/x86/kvm/vmx.c | 2 + arch/x86/kvm/x86.c | 5 ++ crypto/af_alg.c | 21 +++-- crypto/algif_aead.c | 56 +++++++----- crypto/algif_skcipher.c | 23 ++--- crypto/skcipher.c | 3 + drivers/acpi/ec.c | 69 +++++++++------ drivers/acpi/internal.h | 1 + drivers/acpi/scan.c | 21 +++++ drivers/dax/device.c | 12 +++ drivers/dma-buf/reservation.c | 56 +++++++++--- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 20 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 38 ++++----- drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 6 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +++- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 15 +++- drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +- drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 2 +- .../amd/powerplay/hwmgr/process_pptables_v1_0.c | 4 +- drivers/gpu/drm/drm_edid.c | 12 ++- drivers/gpu/drm/drm_fb_helper.c | 4 + drivers/gpu/drm/drm_vblank.c | 6 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 + drivers/gpu/drm/i915/gvt/gtt.c | 6 +- drivers/gpu/drm/i915/i915_drv.c | 2 + drivers/gpu/drm/i915/intel_fbdev.c | 10 ++- drivers/gpu/drm/i915/intel_hdmi.c | 3 +- drivers/gpu/drm/i915/intel_i2c.c | 4 +- drivers/gpu/drm/i915/intel_uncore.c | 13 +++ drivers/gpu/drm/i915/intel_uncore.h | 1 + drivers/gpu/drm/omapdrm/dss/dpi.c | 4 +- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 23 +++-- drivers/gpu/drm/panel/panel-simple.c | 2 + drivers/gpu/drm/radeon/atombios_dp.c | 38 ++++----- drivers/gpu/drm/radeon/radeon_fb.c | 1 - drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 13 ++- drivers/gpu/drm/ttm/ttm_bo.c | 43 +++++----- drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +- drivers/hwmon/jc42.c | 21 +++++ drivers/i2c/busses/i2c-i801.c | 3 + drivers/infiniband/core/umem.c | 2 +- drivers/infiniband/core/user_mad.c | 11 ++- drivers/infiniband/hw/hfi1/mad.c | 7 +- drivers/md/bcache/alloc.c | 2 +- drivers/md/bcache/extents.c | 2 +- drivers/md/bcache/journal.c | 2 +- drivers/md/bcache/request.c | 9 +- drivers/md/bitmap.c | 6 ++ drivers/md/md.c | 2 +- drivers/md/raid5.c | 7 ++ drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +- drivers/misc/cxl/pci.c | 12 ++- drivers/misc/eeprom/at24.c | 19 ++++- drivers/mmc/core/block.c | 67 +++++++++++++-- drivers/mmc/core/bus.c | 3 + drivers/mmc/core/debugfs.c | 1 + drivers/mmc/core/mmc.c | 4 +- drivers/mmc/core/sd.c | 2 +- drivers/mmc/host/sdhci.c | 28 +++--- drivers/net/ethernet/intel/e1000e/ich8lan.h | 3 +- drivers/net/ethernet/intel/e1000e/netdev.c | 9 +- drivers/nvme/host/nvme.h | 2 +- drivers/nvme/host/pci.c | 2 + drivers/platform/x86/hp-wmi.c | 2 +- fs/autofs4/root.c | 17 ++-- fs/btrfs/extent-tree.c | 14 +-- fs/exec.c | 7 +- fs/fat/inode.c | 2 +- fs/lockd/svc.c | 2 + fs/namei.c | 15 +--- fs/nfsd/nfs4state.c | 99 ++++++++++++++++------ include/acpi/acpi_bus.h | 1 + include/acpi/acpi_drivers.h | 1 + include/asm-generic/pgtable.h | 8 ++ include/crypto/if_alg.h | 1 + include/drm/drm_edid.h | 3 +- include/linux/compiler-clang.h | 3 + include/linux/fs.h | 17 +++- include/linux/hugetlb.h | 8 -- include/linux/migrate.h | 2 +- include/linux/mm.h | 14 +++ include/uapi/linux/bcache.h | 2 +- mm/frame_vector.c | 12 +++ mm/gup.c | 64 ++++++++++++++ mm/huge_memory.c | 36 +++----- mm/hugetlb.c | 12 ++- mm/madvise.c | 4 +- mm/memcontrol.c | 2 +- mm/mmap.c | 8 +- mm/oom_kill.c | 7 +- mm/page_alloc.c | 13 +-- security/apparmor/include/audit.h | 12 +-- 112 files changed, 958 insertions(+), 445 deletions(-)
stable-rc/linux-4.14.y boot: 143 boots: 2 failed, 124 passed with 17 offline (v4.14.3-96-gc2bf04f2ec62)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14... Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.3-96-g...
Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.3-96-gc2bf04f2ec62 Git Commit: c2bf04f2ec6277782cbecd0c98a3c2a1a306dc16 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 77 unique boards, 23 SoC families, 18 builds out of 189
Boot Regressions Detected:
arm64:
defconfig: meson-gxl-s905d-p230: lab-baylibre-seattle: failing since 1 day (last pass: v4.14.2-194-g9ff910a1edbf - first fail: v4.14.3-89-g062b4a676f56) meson-gxl-s905x-nexbox-a95x: lab-baylibre-seattle: failing since 1 day (last pass: v4.14.2-194-g9ff910a1edbf - first fail: v4.14.3-89-g062b4a676f56)
Boot Failures Detected:
arm64:
defconfig meson-gxl-s905d-p230: 1 failed lab meson-gxl-s905x-nexbox-a95x: 1 failed lab
Offline Platforms:
arm64:
defconfig: juno-r2: 1 offline lab meson-gxl-s905x-khadas-vim: 1 offline lab mt8173-evb: 1 offline lab sun50i-a64-pine64-plus: 1 offline lab
arm:
multi_v7_defconfig: alpine-db: 1 offline lab at91-sama5d3_xplained: 1 offline lab at91-sama5d4_xplained: 1 offline lab mt7623n-bananapi-bpi-r2: 1 offline lab mt8135-evbp1: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab
bcm2835_defconfig: bcm2835-rpi-b: 1 offline lab
sama5_defconfig: at91-sama5d3_xplained: 1 offline lab at91-sama5d4_xplained: 1 offline lab
tegra_defconfig: tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab
--- For more info write to info@kernelci.org
On 12/04/2017 08:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
On Mon, Dec 04, 2017 at 01:29:42PM -0700, Shuah Khan wrote:
On 12/04/2017 08:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Great, thanks for testing all of these and letting me know.
greg k-h
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
How do the above tests stress the kernel? Aren't they just verifications that the source code in the package is correct?
I guess it proves something, but have you ever seen the above regress in _any_ kernel release?
I know the drm developers have a huge test suite that they use to verify their kernel changes, why not use that?
thanks,
greg k-h
On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
How do the above tests stress the kernel?
Depends entirely on the package in question.
Sure, of completely no surprise a lot of package unit tests don’t really do much that’s particularly interesting save to the package itself.
There are sometimes an interesting subset that drives some amount of work in kernel. That’s the useful stuff.
Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.
Aren't they just verifications that the source code in the package is correct?
So if there’s some useful subset, that’s what I’m looking for.
I guess it proves something, but have you ever seen the above regress in _any_ kernel release?
Past regressions make for a good test.
I know the drm developers have a huge test suite that they use to verify their kernel changes, why not use that?
Good feedback, thanks.
thanks,
greg k-h
On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
How do the above tests stress the kernel?
Depends entirely on the package in question.
Sure, of completely no surprise a lot of package unit tests don’t really do much that’s particularly interesting save to the package itself.
Then why run those tests? Like sqlite, what kernel functionality does that exercise that ltp does not?
There are sometimes an interesting subset that drives some amount of work in kernel. That’s the useful stuff.
Is that true with the above list? If so, why are those types of tests not part of any kernel test suite that I have seen before?
Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.
Nice, does that cover things that is not in LTP? Should those tests be added to LTP?
Aren't they just verifications that the source code in the package is correct?
So if there’s some useful subset, that’s what I’m looking for.
I guess it proves something, but have you ever seen the above regress in _any_ kernel release?
Past regressions make for a good test.
You are testing past regressions of the userspace code, not the kernel here. Why do I care about that? :)
Don't fall down the trap of running code for the sake of running code (i.e. like that web site that starts with a P) that doesn't actually test anything that actually matters.
thanks,
greg k-h
On Wed, Dec 06, 2017 at 07:49:49AM +0100, Greg Kroah-Hartman wrote:
Don't fall down the trap of running code for the sake of running code (i.e. like that web site that starts with a P) that doesn't actually test anything that actually matters.
I forgot to add:
Especially when there are already so many tests out there that _do_ matter that are not getting run on the stable kernels today.
On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
How do the above tests stress the kernel?
Depends entirely on the package in question.
Sure, of completely no surprise a lot of package unit tests don’t really do much that’s particularly interesting save to the package itself.
Then why run those tests? Like sqlite, what kernel functionality does that exercise that ltp does not?
Simply it beats on the system.
There are sometimes an interesting subset that drives some amount of work in kernel. That’s the useful stuff.
Is that true with the above list? If so, why are those types of tests not part of any kernel test suite that I have seen before?
Dunno. Can’t comment on the non-action by others. What we can do is either harvest (by adding to say LTP) or improve in the
Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.
Nice, does that cover things that is not in LTP? Should those tests be added to LTP?
Aren't they just verifications that the source code in the package is correct?
So if there’s some useful subset, that’s what I’m looking for.
I guess it proves something, but have you ever seen the above regress in _any_ kernel release?
Past regressions make for a good test.
You are testing past regressions of the userspace code, not the kernel here. Why do I care about that? :)
Like you, I only care things that are testing the kernel. I’m lazy. I’m not chopping out the things that go far afield, besides it’s not broken nor is it hurting anything.
Don't fall down the trap of running code for the sake of running code (i.e. like that web site that starts with a P) that doesn't actually test anything that actually matters.
Yup entirely agree. No emerge world going on here. 8-b
thanks,
greg k-h
On Wed, Dec 06, 2017 at 12:01:04PM -0600, Tom Gall wrote:
On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
How do the above tests stress the kernel?
Depends entirely on the package in question.
Sure, of completely no surprise a lot of package unit tests don’t really do much that’s particularly interesting save to the package itself.
Then why run those tests? Like sqlite, what kernel functionality does that exercise that ltp does not?
Simply it beats on the system.
There are "real" stress tests you could run if you want to do that. But I thought you all had a hard time keeping your boards alive, are you sure you want to stress them? :)
There are sometimes an interesting subset that drives some amount of work in kernel. That’s the useful stuff.
Is that true with the above list? If so, why are those types of tests not part of any kernel test suite that I have seen before?
Dunno. Can’t comment on the non-action by others. What we can do is either harvest (by adding to say LTP) or improve in the
I can not parse this sentence :(
You are testing past regressions of the userspace code, not the kernel here. Why do I care about that? :)
Like you, I only care things that are testing the kernel. I’m lazy. I’m not chopping out the things that go far afield, besides it’s not broken nor is it hurting anything.
Are you sure these are "testing" the kernel in any other way than the existing tests you are running are? Randomly running various userspace programs is not really a good judge of kernel functionality coverage.
Don't fall down the trap of running code for the sake of running code (i.e. like that web site that starts with a P) that doesn't actually test anything that actually matters.
Yup entirely agree. No emerge world going on here. 8-b
'emerge world' is a wonderful test for a compiler, don't knock it, it's found loads of bugs in the past.
But we aren't testing the compiler, we want to test the kernel, and really, I don't think the things you ran (with maybe the exception of the bluez test), do anything more than 'emerge world' would do :)
Why not work to incorporate one of the many tests that we already know _do_ test different kernel functionality that you are not running before adding random tests that no one really knows do anything at all?
thanks,
greg k-h
Hi Greg,
On 5 December 2017 at 11:54, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
How do the above tests stress the kernel? Aren't they just verifications that the source code in the package is correct?
I guess it proves something, but have you ever seen the above regress in _any_ kernel release?
I know the drm developers have a huge test suite that they use to verify their kernel changes, why not use that?
Are you referring to the igt-gpu-tools [1]? They also have a CI [2] that runs these tests, but almost 98% of the tests are i915 specific / can be only tested on i915 for now. Though I have chatted with Daniel V a couple of times, and we do see a good scope of collaboration in getting these tested on ARM as well.
Also, these are drm-specific tests, not testing generic kernel features per-se. Just my 2 cents here.
thanks,
greg k-h
Best, Sumit
[1]: https://cgit.freedesktop.org/drm/igt-gpu-tools [2]: https://intel-gfx-ci.01.org
On Wed, Dec 06, 2017 at 08:11:26PM +0530, Sumit Semwal wrote:
Hi Greg,
On 5 December 2017 at 11:54, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
How do the above tests stress the kernel? Aren't they just verifications that the source code in the package is correct?
I guess it proves something, but have you ever seen the above regress in _any_ kernel release?
I know the drm developers have a huge test suite that they use to verify their kernel changes, why not use that?
Are you referring to the igt-gpu-tools [1]? They also have a CI [2] that runs these tests, but almost 98% of the tests are i915 specific / can be only tested on i915 for now. Though I have chatted with Daniel V a couple of times, and we do see a good scope of collaboration in getting these tested on ARM as well.
Well, you all are testing x86 for the stable trees, right, why can't you run the i915 tests? :)
Also, these are drm-specific tests, not testing generic kernel features per-se. Just my 2 cents here.
drm-specific things _are_ part of the kernel api, right?
thanks,
greg k-h
On 6 December 2017 at 21:03, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, Dec 06, 2017 at 08:11:26PM +0530, Sumit Semwal wrote:
Hi Greg,
On 5 December 2017 at 11:54, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl : go test target:0/0/5764/5764/5764 PASS ssl_test : 10 pass crypto_test : 28 pass e2fsprogs: make check : 340 pass sqlite make test : 143914 pass drm make check : 15 pass modetest, drmdevice : pass alsa-lib make check : 2 pass bluez make check : 25 pass libusb stress : 4 pass
How do the above tests stress the kernel? Aren't they just verifications that the source code in the package is correct?
I guess it proves something, but have you ever seen the above regress in _any_ kernel release?
I know the drm developers have a huge test suite that they use to verify their kernel changes, why not use that?
Are you referring to the igt-gpu-tools [1]? They also have a CI [2] that runs these tests, but almost 98% of the tests are i915 specific / can be only tested on i915 for now. Though I have chatted with Daniel V a couple of times, and we do see a good scope of collaboration in getting these tested on ARM as well.
Well, you all are testing x86 for the stable trees, right, why can't you run the i915 tests? :)
I'll check with the DRM guys, but my guess is the DRM framework itself is a very fast changing one, and the current i915 tests might not even apply for the stable kernels. :)
Also, these are drm-specific tests, not testing generic kernel features per-se. Just my 2 cents here.
drm-specific things _are_ part of the kernel api, right?
True that :)
By writing this, I did want to highlight that the 'large bucket' wasn't generic features, but a very driver-specific one right now.
thanks,
greg k-h
On Mon, Dec 04, 2017 at 04:59:24PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 123 pass: 123 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
On Mon, Dec 04, 2017 at 03:46:31PM -0800, Guenter Roeck wrote:
On Mon, Dec 04, 2017 at 04:59:24PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 123 pass: 123 fail: 0
Details are available at http://kerneltests.org/builders.
Great, thanks for testing all of these and letting me know.
greg k-h
On 4 December 2017 at 21:29, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary ------------------------------------------------------------------------
kernel: 4.14.4-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 95aa1a118d82e935ec7065345cbaff945d4100bf git describe: v4.14.3-96-g95aa1a118d82 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.3-96-...
No regressions (compared to build v4.14.3-96-gc2bf04f2ec62)
Boards, architectures and test suites: -------------------------------------
hi6220-hikey - arm64 * boot - pass: 20, * kselftest - pass: 39, skip: 14 * libhugetlbfs - pass: 90, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1 * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 14, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 982, skip: 121 * ltp-timers-tests - pass: 12,
juno-r2 - arm64 * boot - pass: 20, * kselftest - pass: 38, skip: 14 * libhugetlbfs - pass: 90, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 939, skip: 156 * ltp-timers-tests - pass: 12,
x15 - arm * boot - pass: 20, * kselftest - pass: 35, skip: 18 * libhugetlbfs - pass: 87, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 20, skip: 2 * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 13, skip: 1 * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1036, skip: 66 * ltp-timers-tests - pass: 12,
x86_64 * boot - pass: 20, * kselftest - pass: 54, skip: 13 * libhugetlbfs - pass: 76, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 61, skip: 1 * ltp-fs_bind-tests - pass: 1, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 9, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 957, skip: 163 * ltp-timers-tests - pass: 12,
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju naresh.kamboju@linaro.org
On Tue, Dec 05, 2017 at 12:31:40PM +0530, Naresh Kamboju wrote:
On 4 December 2017 at 21:29, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.4 release. There are 95 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 Wed Dec 6 16:00:27 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Thanks for testing all 3 of these releases and letting me know.
greg k-h