This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.133-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.4.133-rc1
Tetsuo Handa penguin-kernel@I-love.SAKURA.ne.jp x86/kexec: Avoid double free_page() upon do_kexec_load() failure
Tetsuo Handa penguin-kernel@I-love.SAKURA.ne.jp hfsplus: stop workqueue when fill_super() failed
Johannes Berg johannes.berg@intel.com cfg80211: limit wiphy names to 128 bytes
Geert Uytterhoeven geert+renesas@glider.be gpio: rcar: Add Runtime PM handling for interrupts
John Stultz john.stultz@linaro.org time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
Vinod Koul vinod.koul@intel.com dmaengine: ensure dmaengine helpers check valid callback
Jens Remus jremus@linux.ibm.com scsi: zfcp: fix infinite iteration on ERP ready list
Alexander Potapenko glider@google.com scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()
Jason Yan yanaijie@huawei.com scsi: libsas: defer ata device eh commands to libata
Martin Schwidefsky schwidefsky@de.ibm.com s390: use expoline thunks in the BPF JIT
Martin Schwidefsky schwidefsky@de.ibm.com s390: extend expoline to BC instructions
Martin Schwidefsky schwidefsky@de.ibm.com s390: move spectre sysfs attribute code
Martin Schwidefsky schwidefsky@de.ibm.com s390/kernel: use expoline for indirect branches
Martin Schwidefsky schwidefsky@de.ibm.com s390/ftrace: use expoline for indirect branches
Martin Schwidefsky schwidefsky@de.ibm.com s390/lib: use expoline for indirect branches
Martin Schwidefsky schwidefsky@de.ibm.com s390: move expoline assembler macros to a header
Martin Schwidefsky schwidefsky@de.ibm.com s390: add assembler macros for CPU alternatives
Al Viro viro@zeniv.linux.org.uk ext2: fix a block leak
Eric Dumazet edumazet@google.com tcp: purge write queue in tcp_connect_init()
Eric Dumazet edumazet@google.com sock_diag: fix use-after-free read in __sk_free
Willem de Bruijn willemb@google.com packet: in packet_snd start writing at link layer allocation
Willem de Bruijn willemb@google.com net: test tailroom before appending to linear skb
Liu Bo bo.liu@linux.alibaba.com btrfs: fix reading stale metadata blocks after degraded raid1 mounts
Anand Jain anand.jain@oracle.com btrfs: fix crash when trying to resume balance without the resume flag
Filipe Manana fdmanana@suse.com Btrfs: fix xattr loss after power failure
Masami Hiramatsu mhiramat@kernel.org ARM: 8772/1: kprobes: Prohibit kprobes on get_user functions
Masami Hiramatsu mhiramat@kernel.org ARM: 8770/1: kprobes: Prohibit probing on optimized_callback
Masami Hiramatsu mhiramat@kernel.org ARM: 8769/1: kprobes: Fix to use get_kprobe_ctlblk after irq-disabed
Dexuan Cui decui@microsoft.com tick/broadcast: Use for_each_cpu() specially on UP kernels
Masami Hiramatsu mhiramat@kernel.org ARM: 8771/1: kprobes: Prohibit kprobes on do_undefinstr
Ard Biesheuvel ard.biesheuvel@linaro.org efi: Avoid potential crashes, fix the 'struct efi_pci_io_protocol_32' definition for mixed mode
Martin Schwidefsky schwidefsky@de.ibm.com s390: remove indirect branch from do_softirq_own_stack
Julian Wiedmann jwi@linux.ibm.com s390/qdio: don't release memory in qdio_setup_irq()
Hendrik Brueckner brueckner@linux.ibm.com s390/cpum_sf: ensure sample frequency of perf event attributes is non-zero
Julian Wiedmann jwi@linux.ibm.com s390/qdio: fix access to uninitialized qdio_q fields
Pavel Tatashin pasha.tatashin@oracle.com mm: don't allow deferred pages with NEED_PER_CPU_KM
Nicholas Piggin npiggin@gmail.com powerpc/powernv: Fix NVRAM sleep in invalid context when crashing
Janis Danisevskis jdanis@google.com procfs: fix pthread cross-thread naming if !PR_DUMPABLE
Mateusz Guzik mguzik@redhat.com proc read mm's {arg,env}_{start,end} with mmap semaphore taken.
Steven Rostedt (VMware) rostedt@goodmis.org tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}
Srinivas Pandruvada srinivas.pandruvada@linux.intel.com cpufreq: intel_pstate: Enable HWP by default
Waiman Long Waiman.Long@hpe.com signals: avoid unnecessary taking of sighand->siglock
Mel Gorman mgorman@techsingularity.net mm: filemap: avoid unnecessary calls to lock_page when waiting for IO to complete during a read
Mel Gorman mgorman@techsingularity.net mm: filemap: remove redundant code in do_read_cache_page
Johannes Weiner hannes@cmpxchg.org proc: meminfo: estimate available memory more conservatively
Vladimir Davydov vdavydov@virtuozzo.com vmscan: do not force-scan file lru if its absolute size is small
Benjamin Herrenschmidt benh@kernel.crashing.org powerpc: Don't preempt_disable() in show_cpuinfo()
Anders Roxell anders.roxell@linaro.org cpuidle: coupled: remove unused define cpuidle_coupled_lock
Stewart Smith stewart@linux.vnet.ibm.com powerpc/powernv: remove FW_FEATURE_OPALv3 and just use FW_FEATURE_OPAL
Stewart Smith stewart@linux.vnet.ibm.com powerpc/powernv: Remove OPALv2 firmware define and references
Stewart Smith stewart@linux.vnet.ibm.com powerpc/powernv: panic() on OPAL < V3
Andy Shevchenko andriy.shevchenko@linux.intel.com spi: pxa2xx: Allow 64-bit DMA
Wenwen Wang wang6495@umn.edu ALSA: control: fix a redundant-copy issue
Hans de Goede hdegoede@redhat.com ALSA: hda: Add Lenovo C50 All in one to the power_save blacklist
Federico Cuello fedux@fedux.com.ar ALSA: usb: mixer: volume quirk for CM102-A+/102S+
Shuah Khan (Samsung OSG) shuah@kernel.org usbip: usbip_host: fix bad unlock balance during stub_probe()
Shuah Khan (Samsung OSG) shuah@kernel.org usbip: usbip_host: fix NULL-ptr deref and use-after-free errors
Shuah Khan (Samsung OSG) shuah@kernel.org usbip: usbip_host: run rebind from exit when module is removed
Shuah Khan (Samsung OSG) shuah@kernel.org usbip: usbip_host: delete device from busid_table after rebind
Shuah Khan shuahkh@osg.samsung.com usbip: usbip_host: refine probe and disconnect debug msgs to be useful
zhongjiang zhongjiang@huawei.com kernel/exit.c: avoid undefined behaviour when calling wait4()
Jiri Slaby jslaby@suse.cz futex: futex_wake_op, fix sign_extend32 sign bits
Michael Kerrisk (man-pages) mtk.manpages@gmail.com pipe: cap initial pipe capacity according to pipe-max-size limit
James Chapman jchapman@katalix.com l2tp: revert "l2tp: fix missing print session offset info"
Greg Kroah-Hartman gregkh@linuxfoundation.org Revert "ARM: dts: imx6qdl-wandboard: Fix audio channel swap"
Vasily Averin vvs@virtuozzo.com lockd: lost rollback of set_grace_period() in lockd_down_net()
Antony Antony antony@phenome.org xfrm: fix xfrm_do_migrate() with AEAD e.g(AES-GCM)
Jiri Slaby jslaby@suse.cz futex: Remove duplicated code and fix undefined behaviour
Mel Gorman mgorman@suse.de futex: Remove unnecessary warning from get_futex_key
Suzuki K Poulose suzuki.poulose@arm.com arm64: Add work around for Arm Cortex-A55 Erratum 1024718
Ard Biesheuvel ard.biesheuvel@linaro.org arm64: introduce mov_q macro to move a constant into a 64-bit register
Richard Guy Briggs rgb@redhat.com audit: move calcs after alloc and check when logging set loginuid
Takashi Iwai tiwai@suse.de ALSA: timer: Call notifier in the same spinlock
Xin Long lucien.xin@gmail.com sctp: delay the authentication for the duplicated cookie-echo chunk
Xin Long lucien.xin@gmail.com sctp: fix the issue that the cookie-ack with auth can't get processed
Yuchung Cheng ycheng@google.com tcp: ignore Fast Open on repair mode
Debabrata Banerjee dbanerje@akamai.com bonding: do not allow rlb updates to invalid mac
Michael Chan michael.chan@broadcom.com tg3: Fix vunmap() BUG_ON() triggered from tg3_free_consistent().
Xin Long lucien.xin@gmail.com sctp: use the old asoc when making the cookie-ack chunk in dupcook_d
Xin Long lucien.xin@gmail.com sctp: handle two v4 addrs comparison in sctp_inet6_cmp_addr
Heiner Kallweit hkallweit1@gmail.com r8169: fix powering up RTL8168h
Bjørn Mork bjorn@mork.no qmi_wwan: do not steal interfaces from class drivers
Stefano Brivio sbrivio@redhat.com openvswitch: Don't swap table in nlattr_set() after OVS_ATTR_NESTED is found
Lance Richardson lance.richardson.net@gmail.com net: support compat 64-bit time in {s,g}etsockopt
Eric Dumazet edumazet@google.com net_sched: fq: take care of throttled flows before reuse
Moshe Shemesh moshe@mellanox.com net/mlx4_en: Verify coalescing parameters are in range
Rob Taglang rob@taglang.io net: ethernet: sun: niu set correct packet size in skb
Eric Dumazet edumazet@google.com llc: better deal with too small mtu
Andrey Ignatov rdna@fb.com ipv4: fix memory leaks in udp_sendmsg, ping_v4_sendmsg
Eric Dumazet edumazet@google.com dccp: fix tasklet usage
Hangbin Liu liuhangbin@gmail.com bridge: check iface upper dev when setting master via ioctl
Ingo Molnar mingo@elte.hu 8139too: Use disable_irq_nosync() in rtl8139_poll_controller()
-------------
Diffstat:
Makefile | 4 +- arch/alpha/include/asm/futex.h | 26 +-- arch/arc/include/asm/futex.h | 40 +---- arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 1 - arch/arm/include/asm/assembler.h | 10 ++ arch/arm/include/asm/futex.h | 26 +-- arch/arm/kernel/traps.c | 5 +- arch/arm/lib/getuser.S | 10 ++ arch/arm/probes/kprobes/opt-arm.c | 4 +- arch/arm64/Kconfig | 14 ++ arch/arm64/include/asm/assembler.h | 60 +++++++ arch/arm64/include/asm/cputype.h | 11 ++ arch/arm64/include/asm/futex.h | 26 +-- arch/arm64/mm/proc.S | 5 + arch/frv/include/asm/futex.h | 3 +- arch/frv/kernel/futex.c | 27 +-- arch/hexagon/include/asm/futex.h | 38 +--- arch/ia64/include/asm/futex.h | 25 +-- arch/microblaze/include/asm/futex.h | 38 +--- arch/mips/include/asm/futex.h | 25 +-- arch/parisc/include/asm/futex.h | 25 +-- arch/powerpc/include/asm/firmware.h | 5 +- arch/powerpc/include/asm/futex.h | 26 +-- arch/powerpc/kernel/setup-common.c | 11 -- arch/powerpc/platforms/powernv/eeh-powernv.c | 4 +- arch/powerpc/platforms/powernv/idle.c | 2 +- arch/powerpc/platforms/powernv/opal-nvram.c | 14 +- arch/powerpc/platforms/powernv/opal-xscom.c | 2 +- arch/powerpc/platforms/powernv/opal.c | 36 ++-- arch/powerpc/platforms/powernv/pci-ioda.c | 2 +- arch/powerpc/platforms/powernv/setup.c | 12 +- arch/powerpc/platforms/powernv/smp.c | 74 ++++---- arch/s390/include/asm/alternative-asm.h | 108 ++++++++++++ arch/s390/include/asm/futex.h | 23 +-- arch/s390/include/asm/nospec-insn.h | 193 +++++++++++++++++++++ arch/s390/kernel/Makefile | 1 + arch/s390/kernel/asm-offsets.c | 1 + arch/s390/kernel/base.S | 24 +-- arch/s390/kernel/entry.S | 105 +++-------- arch/s390/kernel/irq.c | 5 +- arch/s390/kernel/mcount.S | 14 +- arch/s390/kernel/nospec-branch.c | 43 +++-- arch/s390/kernel/nospec-sysfs.c | 21 +++ arch/s390/kernel/perf_cpum_sf.c | 4 + arch/s390/kernel/reipl.S | 5 +- arch/s390/kernel/swsusp.S | 10 +- arch/s390/lib/mem.S | 9 +- arch/s390/net/bpf_jit.S | 16 +- arch/s390/net/bpf_jit_comp.c | 63 ++++++- arch/sh/include/asm/futex.h | 26 +-- arch/sparc/include/asm/futex_64.h | 26 +-- arch/tile/include/asm/futex.h | 40 +---- arch/x86/boot/compressed/eboot.c | 6 +- arch/x86/include/asm/futex.h | 40 +---- arch/x86/kernel/machine_kexec_32.c | 6 +- arch/x86/kernel/machine_kexec_64.c | 4 +- arch/x86/xen/mmu.c | 4 - arch/xtensa/include/asm/futex.h | 27 +-- drivers/cpufreq/intel_pstate.c | 34 ++-- drivers/cpufreq/powernv-cpufreq.c | 2 +- drivers/cpuidle/coupled.c | 1 - drivers/cpuidle/cpuidle-powernv.c | 2 +- drivers/gpio/gpio-rcar.c | 46 +++++ drivers/net/bonding/bond_alb.c | 2 +- drivers/net/ethernet/broadcom/tg3.c | 9 +- drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 16 ++ drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 7 +- drivers/net/ethernet/realtek/8139too.c | 2 +- drivers/net/ethernet/realtek/r8169.c | 3 + drivers/net/ethernet/sun/niu.c | 5 +- drivers/net/usb/qmi_wwan.c | 12 ++ drivers/s390/cio/qdio_setup.c | 12 +- drivers/s390/scsi/zfcp_dbf.c | 23 ++- drivers/s390/scsi/zfcp_ext.h | 5 +- drivers/s390/scsi/zfcp_scsi.c | 14 +- drivers/scsi/libsas/sas_scsi_host.c | 33 ++-- drivers/scsi/sg.c | 2 +- drivers/spi/spi-pxa2xx.h | 2 +- drivers/usb/usbip/stub.h | 2 + drivers/usb/usbip/stub_dev.c | 43 +++-- drivers/usb/usbip/stub_main.c | 105 +++++++++-- fs/btrfs/ctree.c | 6 +- fs/btrfs/tree-log.c | 7 + fs/btrfs/volumes.c | 9 + fs/ext2/inode.c | 10 -- fs/hfsplus/super.c | 1 + fs/lockd/svc.c | 2 + fs/pipe.c | 3 + fs/proc/base.c | 55 +++++- fs/proc/meminfo.c | 5 +- include/asm-generic/futex.h | 50 +----- include/linux/dmaengine.h | 20 ++- include/linux/efi.h | 8 +- include/linux/signal.h | 17 ++ include/linux/timekeeper_internal.h | 4 +- include/trace/events/xen.h | 16 -- include/uapi/linux/nl80211.h | 2 + kernel/auditsc.c | 7 +- kernel/exit.c | 4 + kernel/futex.c | 44 ++++- kernel/signal.c | 7 + kernel/time/tick-broadcast.c | 8 + kernel/time/timekeeping.c | 20 +-- mm/Kconfig | 1 + mm/filemap.c | 90 ++++++---- mm/util.c | 16 +- mm/vmscan.c | 12 +- net/bridge/br_if.c | 4 +- net/compat.c | 6 +- net/core/sock.c | 2 +- net/dccp/ccids/ccid2.c | 14 +- net/dccp/timer.c | 2 +- net/ipv4/ip_output.c | 3 +- net/ipv4/ping.c | 7 +- net/ipv4/tcp.c | 2 +- net/ipv4/tcp_output.c | 7 +- net/ipv4/udp.c | 7 +- net/ipv6/ip6_output.c | 3 +- net/l2tp/l2tp_netlink.c | 2 - net/llc/af_llc.c | 3 + net/openvswitch/flow_netlink.c | 9 +- net/packet/af_packet.c | 4 +- net/sched/sch_fq.c | 37 ++-- net/sctp/associola.c | 30 +++- net/sctp/inqueue.c | 2 +- net/sctp/ipv6.c | 3 + net/sctp/sm_statefuns.c | 89 +++++----- net/wireless/core.c | 3 + net/xfrm/xfrm_state.c | 1 + sound/core/control_compat.c | 3 +- sound/core/timer.c | 220 +++++++++++------------- sound/pci/hda/hda_intel.c | 2 + sound/usb/mixer.c | 8 + 133 files changed, 1605 insertions(+), 1109 deletions(-)
On 05/24/2018 02:37 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Building s390:allmodconfig ... failed
arch/s390/built-in.o: In function `__s390x_indirect_jump_r1use_r1': (.text.__s390x_indirect_jump_r1use_r1[__s390x_indirect_jump_r1use_r1]+0x2): undefined reference to `_LC_BR_R1' make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2
Complete report follows later.
Guenter
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.133-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below.
thanks,
greg k-h
Merged, compiled with -Werror, and installed onto my Pixel 2 XL and OnePlus 5.
No initial issues noticed in dmesg or general usage.
Thanks! Nathan
stable-rc/linux-4.4.y boot: 95 boots: 1 failed, 93 passed with 1 conflict (v4.4.132-93-g915a3d7cdea9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.1... Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.132-93-g...
Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.132-93-g915a3d7cdea9 Git Commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 45 unique boards, 21 SoC families, 15 builds out of 178
Boot Regressions Detected:
x86:
x86_64_defconfig: qemu: lab-baylibre: failing since 2 days (last pass: v4.4.132-70-gaa7ab28e9c5e - first fail: v4.4.132-71-g180635995c36)
Boot Failure Detected:
arm64:
defconfig synquacer-acpi: 1 failed lab
Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
x86:
x86_64_defconfig: qemu: lab-linaro-lkft: PASS lab-mhart: PASS lab-collabora: PASS lab-baylibre: FAIL
--- For more info write to info@kernelci.org
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Build results: total: 146 pass: 145 fail: 1 Failed builds: s390:allmodconfig Qemu test results: total: 127 pass: 127 fail: 0
Build error (s390:allmodconfig):
arch/s390/built-in.o: In function `__s390x_indirect_jump_r1use_r1': (.text.__s390x_indirect_jump_r1use_r1[__s390x_indirect_jump_r1use_r1]+0x2): undefined reference to `_LC_BR_R1'
Details are available at http://kerneltests.org/builders/.
Guenter
On Thu, May 24, 2018 at 10:32:08AM -0700, Guenter Roeck wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Build results: total: 146 pass: 145 fail: 1 Failed builds: s390:allmodconfig Qemu test results: total: 127 pass: 127 fail: 0
Build error (s390:allmodconfig):
arch/s390/built-in.o: In function `__s390x_indirect_jump_r1use_r1': (.text.__s390x_indirect_jump_r1use_r1[__s390x_indirect_jump_r1use_r1]+0x2): undefined reference to `_LC_BR_R1'
I'll look into the s390 stuff in the morning, I think I know what I messed up there...
thanks,
greg k-h
On Thu, May 24, 2018 at 09:47:42PM +0200, Greg Kroah-Hartman wrote:
On Thu, May 24, 2018 at 10:32:08AM -0700, Guenter Roeck wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Build results: total: 146 pass: 145 fail: 1 Failed builds: s390:allmodconfig Qemu test results: total: 127 pass: 127 fail: 0
Build error (s390:allmodconfig):
arch/s390/built-in.o: In function `__s390x_indirect_jump_r1use_r1': (.text.__s390x_indirect_jump_r1use_r1[__s390x_indirect_jump_r1use_r1]+0x2): undefined reference to `_LC_BR_R1'
I'll look into the s390 stuff in the morning, I think I know what I messed up there...
Nope, I don't think this was my fault :)
Oddly 'defconfig' worked for s390 with the offending patch, but not allmodconfig. I've now dropped the patch I think was causing the problem and pushed out a -rc2.
thanks,
greg k-h
On Fri, May 25, 2018 at 04:11:45PM +0200, Greg Kroah-Hartman wrote:
On Thu, May 24, 2018 at 09:47:42PM +0200, Greg Kroah-Hartman wrote:
On Thu, May 24, 2018 at 10:32:08AM -0700, Guenter Roeck wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Build results: total: 146 pass: 145 fail: 1 Failed builds: s390:allmodconfig Qemu test results: total: 127 pass: 127 fail: 0
Build error (s390:allmodconfig):
arch/s390/built-in.o: In function `__s390x_indirect_jump_r1use_r1': (.text.__s390x_indirect_jump_r1use_r1[__s390x_indirect_jump_r1use_r1]+0x2): undefined reference to `_LC_BR_R1'
I'll look into the s390 stuff in the morning, I think I know what I messed up there...
Nope, I don't think this was my fault :)
Oddly 'defconfig' worked for s390 with the offending patch, but not allmodconfig. I've now dropped the patch I think was causing the problem and pushed out a -rc2.
Confirmed to build with v4.4.132-92-g8330f2b.
Guenter
On Fri, May 25, 2018 at 09:39:19AM -0700, Guenter Roeck wrote:
On Fri, May 25, 2018 at 04:11:45PM +0200, Greg Kroah-Hartman wrote:
On Thu, May 24, 2018 at 09:47:42PM +0200, Greg Kroah-Hartman wrote:
On Thu, May 24, 2018 at 10:32:08AM -0700, Guenter Roeck wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Build results: total: 146 pass: 145 fail: 1 Failed builds: s390:allmodconfig Qemu test results: total: 127 pass: 127 fail: 0
Build error (s390:allmodconfig):
arch/s390/built-in.o: In function `__s390x_indirect_jump_r1use_r1': (.text.__s390x_indirect_jump_r1use_r1[__s390x_indirect_jump_r1use_r1]+0x2): undefined reference to `_LC_BR_R1'
I'll look into the s390 stuff in the morning, I think I know what I messed up there...
Nope, I don't think this was my fault :)
Oddly 'defconfig' worked for s390 with the offending patch, but not allmodconfig. I've now dropped the patch I think was causing the problem and pushed out a -rc2.
Confirmed to build with v4.4.132-92-g8330f2b.
Wonderful, thanks for testing and letting me know.
greg k-h
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary ------------------------------------------------------------------------
kernel: 4.4.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
No regressions (compared to build v4.4.132-71-g180635995c36)
Ran 6863 total tests in the following environments and test suites.
Environments -------------- - juno-r2 - arm64 - qemu_arm - qemu_x86_64 - x15 - arm - x86_64
Test Suites ----------- * boot * kselftest * ltp-cap_bounds-tests * ltp-containers-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * libhugetlbfs * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none
Summary ------------------------------------------------------------------------
kernel: 4.4.133-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.133-rc1-hikey-20180524-200 git commit: 9a1fc06621f38daaaa47feeaa1eeaf38db532433 git describe: 4.4.133-rc1-hikey-20180524-200 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.1...
No regressions (compared to build 4.4.133-rc1-hikey-20180521-198)
Ran 2610 total tests in the following environments and test suites.
Environments -------------- - hi6220-hikey - arm64 - qemu_arm64
Test Suites ----------- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests
On Thu, May 24, 2018 at 01:06:52PM -0500, Dan Rue wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary
kernel: 4.4.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
No regressions (compared to build v4.4.132-71-g180635995c36)
Shouldn't this compare against v4.4.132 ?
I looked into kselftest/rtnetlink.sh test results. The test history is a bit confusing.
- v4.4.131-57-ge33795f7a573 and earlier passed - v4.4.132 failed - v4.4.132-30-ga102378c6551 passed ... - v4.4.132-70-gaa7ab28e9c5e passed - v4.4.132-71-g180635995c36 and later failed
Does that mean that this specific test is unreliable ?
Thanks, Guenter
Ran 6863 total tests in the following environments and test suites.
Environments
- juno-r2 - arm64
- qemu_arm
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
- boot
- kselftest
- ltp-cap_bounds-tests
- ltp-containers-tests
- ltp-fcntl-locktests-tests
- ltp-filecaps-tests
- ltp-fs-tests
- ltp-fs_bind-tests
- ltp-fs_perms_simple-tests
- ltp-fsx-tests
- ltp-hugetlb-tests
- ltp-io-tests
- ltp-ipc-tests
- ltp-math-tests
- ltp-nptl-tests
- ltp-pty-tests
- ltp-sched-tests
- ltp-securebits-tests
- ltp-syscalls-tests
- ltp-timers-tests
- libhugetlbfs
- kselftest-vsyscall-mode-native
- kselftest-vsyscall-mode-none
Summary
kernel: 4.4.133-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.133-rc1-hikey-20180524-200 git commit: 9a1fc06621f38daaaa47feeaa1eeaf38db532433 git describe: 4.4.133-rc1-hikey-20180524-200 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.1...
No regressions (compared to build 4.4.133-rc1-hikey-20180521-198)
Ran 2610 total tests in the following environments and test suites.
Environments
- hi6220-hikey - arm64
- qemu_arm64
Test Suites
- boot
- kselftest
- libhugetlbfs
- ltp-cap_bounds-tests
- ltp-containers-tests
- ltp-fcntl-locktests-tests
- ltp-filecaps-tests
- ltp-fs-tests
- ltp-fs_bind-tests
- ltp-fs_perms_simple-tests
- ltp-fsx-tests
- ltp-hugetlb-tests
- ltp-io-tests
- ltp-ipc-tests
- ltp-math-tests
- ltp-nptl-tests
- ltp-pty-tests
- ltp-sched-tests
- ltp-securebits-tests
- ltp-syscalls-tests
- ltp-timers-tests
-- Linaro LKFT https://lkft.linaro.org
On 24 May 2018 at 23:47, Guenter Roeck linux@roeck-us.net wrote:
On Thu, May 24, 2018 at 01:06:52PM -0500, Dan Rue wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary
kernel: 4.4.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
No regressions (compared to build v4.4.132-71-g180635995c36)
Shouldn't this compare against v4.4.132 ?
I looked into kselftest/rtnetlink.sh test results. The test history is a bit confusing.
- v4.4.131-57-ge33795f7a573 and earlier passed
- v4.4.132 failed
- v4.4.132-30-ga102378c6551 passed
...
- v4.4.132-70-gaa7ab28e9c5e passed
- v4.4.132-71-g180635995c36 and later failed
Does that mean that this specific test is unreliable ?
kselftest rtnetlink.sh test case failure is not a regression on 4.16, 4.14, 4.9 and 4.4 builds. Because it used to skip due to missing tc tool.
Now the ''tc' tool added to Open Embedded build and test running and reported failed. This is not a regression in the kernel. It is a change in the user space.
Old output ============ SKIP: Could not run test without the tc tool selftests: rtnetlink.sh [PASS] https://lkft.validation.linaro.org/scheduler/job/225015#L2255
New output ============= RTNETLINK answers: Operation not supported Cannot find device "test-dummy0" FAIL: cannot add dummy interface selftests: rtnetlink.sh [FAIL] https://lkft.validation.linaro.org/scheduler/job/226352#L3375
Ref bug link: https://bugs.linaro.org/show_bug.cgi?id=3834
- Naresh
On 05/24/2018 03:34 PM, Naresh Kamboju wrote:
On 24 May 2018 at 23:47, Guenter Roeck linux@roeck-us.net wrote:
On Thu, May 24, 2018 at 01:06:52PM -0500, Dan Rue wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary
kernel: 4.4.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
No regressions (compared to build v4.4.132-71-g180635995c36)
Shouldn't this compare against v4.4.132 ?
I looked into kselftest/rtnetlink.sh test results. The test history is a bit confusing.
- v4.4.131-57-ge33795f7a573 and earlier passed
- v4.4.132 failed
- v4.4.132-30-ga102378c6551 passed
...
- v4.4.132-70-gaa7ab28e9c5e passed
- v4.4.132-71-g180635995c36 and later failed
Does that mean that this specific test is unreliable ?
kselftest rtnetlink.sh test case failure is not a regression on 4.16, 4.14, 4.9 and 4.4 builds. Because it used to skip due to missing tc tool.
Now the ''tc' tool added to Open Embedded build and test running and reported failed. This is not a regression in the kernel. It is a change in the user space.
Old output
SKIP: Could not run test without the tc tool selftests: rtnetlink.sh [PASS] https://lkft.validation.linaro.org/scheduler/job/225015#L2255
New output
RTNETLINK answers: Operation not supported Cannot find device "test-dummy0" FAIL: cannot add dummy interface selftests: rtnetlink.sh [FAIL] https://lkft.validation.linaro.org/scheduler/job/226352#L3375
Ref bug link: https://bugs.linaro.org/show_bug.cgi?id=3834
- Naresh
Which kselftest versdion do you run? Is this from linux-next?
thanks, -- Shuah
On Thu, May 24, 2018 at 03:52:49PM -0600, Shuah Khan wrote:
On 05/24/2018 03:34 PM, Naresh Kamboju wrote:
On 24 May 2018 at 23:47, Guenter Roeck linux@roeck-us.net wrote:
On Thu, May 24, 2018 at 01:06:52PM -0500, Dan Rue wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary
kernel: 4.4.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
No regressions (compared to build v4.4.132-71-g180635995c36)
Shouldn't this compare against v4.4.132 ?
I looked into kselftest/rtnetlink.sh test results. The test history is a bit confusing.
- v4.4.131-57-ge33795f7a573 and earlier passed
- v4.4.132 failed
- v4.4.132-30-ga102378c6551 passed
...
- v4.4.132-70-gaa7ab28e9c5e passed
- v4.4.132-71-g180635995c36 and later failed
Does that mean that this specific test is unreliable ?
kselftest rtnetlink.sh test case failure is not a regression on 4.16, 4.14, 4.9 and 4.4 builds. Because it used to skip due to missing tc tool.
Now the ''tc' tool added to Open Embedded build and test running and reported failed. This is not a regression in the kernel. It is a change in the user space.
Old output
SKIP: Could not run test without the tc tool selftests: rtnetlink.sh [PASS] https://lkft.validation.linaro.org/scheduler/job/225015#L2255
New output
RTNETLINK answers: Operation not supported Cannot find device "test-dummy0" FAIL: cannot add dummy interface selftests: rtnetlink.sh [FAIL] https://lkft.validation.linaro.org/scheduler/job/226352#L3375
Ref bug link: https://bugs.linaro.org/show_bug.cgi?id=3834
- Naresh
Which kselftest versdion do you run? Is this from linux-next?
It's using kselftest from 4.16 (latest stable, as a rule). I think this patch will fix the 'Operation not supported' issue: https://patchwork.kernel.org/patch/10424807/
Dan
On Thu, May 24, 2018 at 01:06:52PM -0500, Dan Rue wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary
kernel: 4.4.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
No regressions (compared to build v4.4.132-71-g180635995c36)
It should have gotten better, as there was a fix in here for at least 2 LTP tests that we previously were not passing. I don't know why you all were not reporting that in the past, it took someone else randomly deciding to run LTP to report it to me...
Why did an improvement in results not show up?
thanks,
greg k-h
kernel: 4.4.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
No regressions (compared to build v4.4.132-71-g180635995c36)
It should have gotten better, as there was a fix in here for at least 2 LTP tests that we previously were not passing. I don't know why you all were not reporting that in the past, it took someone else randomly deciding to run LTP to report it to me...
Why did an improvement in results not show up?
Are you referring to the CLOCK_MONOTONIC_RAW fix for the arm64 vDSO ? I think that CLOCK_MONOTONIC_RAW in VDSO wasn't backported to 4.4.y (commit 49eea433b326 in mainline) so this "fix" is changing the timekeeping sauce (that would fix MONOTONIC RAW) but not for 4.4.y in ARM64. Needs review though :\
Hello Rafael,
The tests fcntl35 and fcntl35_64 should have go from FAIL to PASS. https://www.spinics.net/lists/stable/msg239475.html
Looking at https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-... I see that these two tests (and other important tests as well) are being SKIPPED.
By the way, I see that select04 FAILS in your case. But in my setup, select04 was working fine (x86_64) in 4.4.132. I will confirm that it still works in 4.4.133
Thanks, Daniel Sangorrin
-----Original Message----- From: stable-owner@vger.kernel.org [mailto:stable-owner@vger.kernel.org] On Behalf Of Rafael Tinoco Sent: Friday, May 25, 2018 5:32 AM To: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org; shuah@kernel.org; patches@kernelci.org; lkft-triage@lists.linaro.org; ben.hutchings@codethink.co.uk; stable@vger.kernel.org; akpm@linux-foundation.org; torvalds@linux-foundation.org; linux@roeck-us.net Subject: Re: [PATCH 4.4 00/92] 4.4.133-stable review
kernel: 4.4.133-rc1 git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-... 3d7cdea9
No regressions (compared to build v4.4.132-71-g180635995c36)
It should have gotten better, as there was a fix in here for at least 2 LTP tests that we previously were not passing. I don't know why you all were not reporting that in the past, it took someone else randomly deciding to run LTP to report it to me...
Why did an improvement in results not show up?
Are you referring to the CLOCK_MONOTONIC_RAW fix for the arm64 vDSO ? I think that CLOCK_MONOTONIC_RAW in VDSO wasn't backported to 4.4.y (commit 49eea433b326 in mainline) so this "fix" is changing the timekeeping sauce (that would fix MONOTONIC RAW) but not for 4.4.y in ARM64. Needs review though :\
Thank you Daniel! Will investigate those.
Meanwhile, Greg, I referred to:
time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
Since we're not using this type of clock on arm64's 4.4 kernel vdso functions. This commit's description calls attention for it to be responsible for fixing kselftest flacking tests, we wouldn't get that on 4.4 according to bellow:
stable-rc-linux-4.14.y dbb236c1ceb6 arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW 49eea433b326 arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO 82e88ff1ea94 hrtimer: Revert CLOCK_MONOTONIC_RAW support 9c808765e88e hrtimer: Add support for CLOCK_MONOTONIC_RAW
stable-rc-linux-4.16.y dbb236c1ceb6 arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW 49eea433b326 arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO 82e88ff1ea94 hrtimer: Revert CLOCK_MONOTONIC_RAW support 9c808765e88e hrtimer: Add support for CLOCK_MONOTONIC_RAW
stable-rc-linux-4.4.y <none>
stable-rc-linux-4.9.y 99f66b5182a4 arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW 49eea433b326 arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO 82e88ff1ea94 hrtimer: Revert CLOCK_MONOTONIC_RAW support 9c808765e88e hrtimer: Add support for CLOCK_MONOTONIC_RAW
Yet, the second fix was backported to all (including 4.4.y):
stable-rc-linux-4.14.y 3d88d56c5873 time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting stable-rc-linux-4.16.y 3d88d56c5873 time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting stable-rc-linux-4.4.y 7c8bd6e07430 time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting stable-rc-linux-4.9.y a53bfdda06ac time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
Not sure you want to keep it in 4.4, thought it was worth mentioning it.
Cheers.
On 24 May 2018 at 22:34, Daniel Sangorrin daniel.sangorrin@toshiba.co.jp wrote:
Hello Rafael,
The tests fcntl35 and fcntl35_64 should have go from FAIL to PASS. https://www.spinics.net/lists/stable/msg239475.html
Looking at https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-... I see that these two tests (and other important tests as well) are being SKIPPED.
By the way, I see that select04 FAILS in your case. But in my setup, select04 was working fine (x86_64) in 4.4.132. I will confirm that it still works in 4.4.133
Thanks, Daniel Sangorrin
-----Original Message----- From: stable-owner@vger.kernel.org [mailto:stable-owner@vger.kernel.org] On Behalf Of Rafael Tinoco Sent: Friday, May 25, 2018 5:32 AM To: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org; shuah@kernel.org; patches@kernelci.org; lkft-triage@lists.linaro.org; ben.hutchings@codethink.co.uk; stable@vger.kernel.org; akpm@linux-foundation.org; torvalds@linux-foundation.org; linux@roeck-us.net Subject: Re: [PATCH 4.4 00/92] 4.4.133-stable review
kernel: 4.4.133-rc1 git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-... 3d7cdea9
No regressions (compared to build v4.4.132-71-g180635995c36)
It should have gotten better, as there was a fix in here for at least 2 LTP tests that we previously were not passing. I don't know why you all were not reporting that in the past, it took someone else randomly deciding to run LTP to report it to me...
Why did an improvement in results not show up?
Are you referring to the CLOCK_MONOTONIC_RAW fix for the arm64 vDSO ? I think that CLOCK_MONOTONIC_RAW in VDSO wasn't backported to 4.4.y (commit 49eea433b326 in mainline) so this "fix" is changing the timekeeping sauce (that would fix MONOTONIC RAW) but not for 4.4.y in ARM64. Needs review though :\
-----Original Message----- From: Rafael Tinoco [mailto:rafael.tinoco@linaro.org]
Thank you Daniel! Will investigate those.
OK, thank you :). Notice that I did those tests on x86_64. It seems you are testing on arm, so there may be some differences.
I just checked these tests on 4.4.133 (on x86_64): fcntl35: PASS fcntl35_64: PASS select04: PASS
I am currently investigating other tests that are failing as well. They are not regressions, just some patches have not been backported yet.
Thanks, Daniel
Meanwhile, Greg, I referred to:
time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
Since we're not using this type of clock on arm64's 4.4 kernel vdso functions. This commit's description calls attention for it to be responsible for fixing kselftest flacking tests, we wouldn't get that on 4.4 according to bellow:
stable-rc-linux-4.14.y dbb236c1ceb6 arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW 49eea433b326 arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO 82e88ff1ea94 hrtimer: Revert CLOCK_MONOTONIC_RAW support 9c808765e88e hrtimer: Add support for CLOCK_MONOTONIC_RAW
stable-rc-linux-4.16.y dbb236c1ceb6 arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW 49eea433b326 arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO 82e88ff1ea94 hrtimer: Revert CLOCK_MONOTONIC_RAW support 9c808765e88e hrtimer: Add support for CLOCK_MONOTONIC_RAW
stable-rc-linux-4.4.y
<none>
stable-rc-linux-4.9.y 99f66b5182a4 arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW 49eea433b326 arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO 82e88ff1ea94 hrtimer: Revert CLOCK_MONOTONIC_RAW support 9c808765e88e hrtimer: Add support for CLOCK_MONOTONIC_RAW
Yet, the second fix was backported to all (including 4.4.y):
stable-rc-linux-4.14.y 3d88d56c5873 time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting stable-rc-linux-4.16.y 3d88d56c5873 time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting stable-rc-linux-4.4.y 7c8bd6e07430 time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting stable-rc-linux-4.9.y a53bfdda06ac time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
Not sure you want to keep it in 4.4, thought it was worth mentioning it.
Cheers.
On 24 May 2018 at 22:34, Daniel Sangorrin daniel.sangorrin@toshiba.co.jp wrote:
Hello Rafael,
The tests fcntl35 and fcntl35_64 should have go from FAIL to PASS. https://www.spinics.net/lists/stable/msg239475.html
Looking at
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-... 3d7cdea9/testrun/228569/suite/ltp-syscalls-tests/tests/
I see that these two tests (and other important tests as well) are being SKIPPED.
By the way, I see that select04 FAILS in your case. But in my setup, select04 was
working fine (x86_64) in 4.4.132. I will confirm that it still works in 4.4.133
Thanks, Daniel Sangorrin
-----Original Message----- From: stable-owner@vger.kernel.org [mailto:stable-owner@vger.kernel.org]
On
Behalf Of Rafael Tinoco Sent: Friday, May 25, 2018 5:32 AM To: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org; shuah@kernel.org; patches@kernelci.org; lkft-triage@lists.linaro.org; ben.hutchings@codethink.co.uk; stable@vger.kernel.org; akpm@linux-foundation.org; torvalds@linux-foundation.org; linux@roeck-us.net Subject: Re: [PATCH 4.4 00/92] 4.4.133-stable review
kernel: 4.4.133-rc1 git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
3d7cdea9
No regressions (compared to build v4.4.132-71-g180635995c36)
It should have gotten better, as there was a fix in here for at least 2 LTP tests that we previously were not passing. I don't know why you all were not reporting that in the past, it took someone else randomly deciding to run LTP to report it to me...
Why did an improvement in results not show up?
Are you referring to the CLOCK_MONOTONIC_RAW fix for the arm64 vDSO ? I think that CLOCK_MONOTONIC_RAW in VDSO wasn't backported to 4.4.y (commit 49eea433b326 in mainline) so this "fix" is changing the timekeeping sauce (that would fix MONOTONIC RAW) but not for 4.4.y in ARM64. Needs review though :\
Hi Daniel,
On 25 May 2018 at 07:04, Daniel Sangorrin daniel.sangorrin@toshiba.co.jp wrote:
Hello Rafael,
The tests fcntl35 and fcntl35_64 should have go from FAIL to PASS. https://www.spinics.net/lists/stable/msg239475.html
Thanks for the patch.
Now i have manually tested LTP syscalls and confirms, fcntl35 and fcntl35_64 pass on qemu_x86_64, (arm64) Hikey, Juno and (arm32) x15.
Linux version 4.4.133-rc1 (buildslave@x86-64-07) (gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #1 SMP Thu May 24 10:24:11 UTC 2018
[ 131.873912] LTP: starting fcntl35 tst_test.c:980: INFO: Timeout per run is 0h 05m 00s fcntl35.c:101: PASS: an unprivileged user init the capacity of a pipe to 4096 successfully fcntl35.c:101: PASS: a privileged user init the capacity of a pipe to 65536 successfully Summary: passed 2 failed 0 skipped 0
[ 132.090096] LTP: starting fcntl35_64 incrementing stop tst_test.c:980: INFO: Timeout per run is 0h 05m 00s fcntl35.c:101: PASS: an unprivileged user init the capacity of a pipe to 4096 successfully fcntl35.c:101: PASS: a privileged user init the capacity of a pipe to 65536 successfully Summary: passed 2 failed 0 skipped 0 warnings 0
Looking at https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-... I see that these two tests (and other important tests as well) are being SKIPPED.
fcntl35 and fcntl35_64 will be unskipped from now on.
By the way, I see that select04 FAILS in your case. But in my setup, select04 was working fine (x86_64) in 4.4.132. I will confirm that it still works in 4.4.133
select04 failed on (slow) qemu_arm only and PASS on real hardware of arm32 x15, arm64 Juno and x86_64. Test case verdict comparison across all boards and qemu, https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/tests/ltp-syscalls...
LTP select04 failed log on slow qemu_arm32, tst_test.c:980: INFO: Timeout per run is 0h 15m 00s tst_timer_test.c:356: INFO: CLOCK_MONOTONIC resolution 1ns tst_timer_test.c:368: INFO: prctl(PR_GET_TIMERSLACK) = 50us tst_timer_test.c:275: INFO: select() sleeping for 1000us 500 iterations, threshold 450.01us tst_timer_test.c:318: INFO: min 1336us, max 2282us, median 1522us, trunc mean 1542.82us (discarded 25) tst_timer_test.c:321: FAIL: select() slept for too long
Full log: https://lkft.validation.linaro.org/scheduler/job/228569#L8792
Best regards Naresh Kamboju
On Thu, May 24, 2018 at 09:08:06PM +0200, Greg Kroah-Hartman wrote:
On Thu, May 24, 2018 at 01:06:52PM -0500, Dan Rue wrote:
On Thu, May 24, 2018 at 11:37:37AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary
kernel: 4.4.133-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 git describe: v4.4.132-93-g915a3d7cdea9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.132-93-...
No regressions (compared to build v4.4.132-71-g180635995c36)
It should have gotten better, as there was a fix in here for at least 2 LTP tests that we previously were not passing. I don't know why you all were not reporting that in the past, it took someone else randomly deciding to run LTP to report it to me...
Why did an improvement in results not show up?
Our normal process for failing tests is to skip them and then fix/report/etc separately until they're fixed, at which time we re-enable them. Otherwise, we would have to wade through too many failures in every result set, and we could miss actual regressions. We've never really reported things as they've been fixed - just immediate regressions.
However! We are working on 'known issue' support in qa-reports (SQUAD), so that we can run failing tests and the system will mark them as a known failure. This will allow us to keep our baseline 'green', and also let us run the failing tests so that we can see in realtime as issues get fixed. Once we have that, the only tests that we'll carry on our skiplists are those that cause boards to crash or reboot.
If you have the test cases in mind, I can check them. Otherwise, I can run our full set of tests in staging (without a skiplist) tomorrow and see if any are now passing.
Dan
On 05/24/2018 03:37 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.133 release. There are 92 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 Sat May 26 09:31:28 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.133-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
-
Dan Rue -
Daniel Sangorrin -
Greg Kroah-Hartman -
Guenter Roeck -
kernelci.org bot -
Naresh Kamboju -
Nathan Chancellor -
Rafael Tinoco -
Shuah Khan