This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 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.18.6-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.18.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.18.6-rc1
Arnd Bergmann arnd@arndb.de x86: kvm: avoid unused variable warning
Jann Horn jannh@google.com x86/dumpstack: Don't dump kernel memory based on usermode RIP
Scott Bauer scott.bauer@intel.com cdrom: Fix info leak/OOB read in cdrom_ioctl_drive_status
Vincent Whitchurch vincent.whitchurch@axis.com watchdog: Mark watchdog touch functions as notrace
H. Nikolaus Schaller hns@goldelico.com power: generic-adc-battery: check for duplicate properties copied from iio channels
H. Nikolaus Schaller hns@goldelico.com power: generic-adc-battery: fix out-of-bounds write when copying channel properties
Dan Carpenter dan.carpenter@oracle.com PM / clk: signedness bug in of_pm_clk_add_clks()
Gustavo A. R. Silva gustavo@embeddedor.com clk: npcm7xx: fix memory allocation
Alberto Panizzo alberto@amarulasolutions.com clk: rockchip: fix clk_i2sout parent selection bits on rk3399
Abhishek Sahu absahu@codeaurora.org mtd: rawnand: qcom: wait for desc completion in all BAM channels
Daniel Mack daniel@zonque.org mtd: rawnand: marvell: add suspend and resume hooks
Boris Brezillon boris.brezillon@bootlin.com mtd: rawnand: fsmc: Stop using chip->read_buf()
Boris Brezillon boris.brezillon@bootlin.com mtd: rawnand: hynix: Use ->exec_op() in hynix_nand_reg_write_op()
Mike Christie mchristi@redhat.com iscsi target: fix session creation failure handling
Bart Van Assche bart.vanassche@wdc.com scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock
Bart Van Assche bart.vanassche@wdc.com scsi: sysfs: Introduce sysfs_{un,}break_active_protection()
Bart Van Assche bart.vanassche@wdc.com scsi: mpt3sas: Fix _transport_smp_handler() error path
Sreekanth Reddy sreekanth.reddy@broadcom.com scsi: mpt3sas: Fix calltrace observed while running IO & reset
Tomas Winkler tomas.winkler@intel.com tpm: separate cmd_ready/go_idle from runtime_pm
Ricardo Schwarzmeier Ricardo.Schwarzmeier@infineon.com tpm: Return the actual size when receiving an unsupported command
Paul Burton paul.burton@mips.com MIPS: lib: Provide MIPS64r6 __multi3() for GCC < 7
Huacai Chen chenhc@lemote.com MIPS: Change definition of cpu_relax() for Loongson-3
Paul Burton paul.burton@mips.com MIPS: Always use -march=<arch>, not -<arch> shortcuts
Matt Redfearn matt.redfearn@mips.com MIPS: memset.S: Fix byte_fixup for MIPSr6
Maciej W. Rozycki macro@mips.com MIPS: Correct the 64-bit DSP accumulator register size
Masami Hiramatsu mhiramat@kernel.org kprobes: Make list and blacklist root user read only
Masami Hiramatsu mhiramat@kernel.org kprobes/arm: Fix %p uses in error messages
Masami Hiramatsu mhiramat@kernel.org kprobes: Replace %p with other pointer types
Masami Hiramatsu mhiramat@kernel.org kprobes: Show blacklist addresses as same as kallsyms does
Philipp Rudo prudo@linux.ibm.com s390/purgatory: Add missing FORCE to Makefile targets
Philipp Rudo prudo@linux.ibm.com s390/purgatory: Fix crash with expoline enabled
Sebastian Ott sebott@linux.ibm.com s390/pci: fix out of bounds access during irq setup
Martin Schwidefsky schwidefsky@de.ibm.com s390/numa: move initial setup of node_to_cpumask_map
Julian Wiedmann jwi@linux.ibm.com s390/qdio: reset old sbal_state flags
Martin Schwidefsky schwidefsky@de.ibm.com s390: fix br_r1_trampoline for machines without exrl
Martin Schwidefsky schwidefsky@de.ibm.com s390/lib: use expoline for all bcr instructions
Gerald Schaefer gerald.schaefer@de.ibm.com s390/mm: fix addressing exception after suspend/resume
Ben Hutchings ben@decadent.org.uk x86: Allow generating user-space headers without a compiler
Jann Horn jannh@google.com x86/entry/64: Wipe KASAN stack shadow before rewind_stack_do_exit()
Gustavo A. R. Silva gustavo@embeddedor.com hwmon: (nct6775) Fix potential Spectre v1
Andi Kleen ak@linux.intel.com x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+
Andi Kleen ak@linux.intel.com x86/spectre: Add missing family 6 check to microcode check
Nick Desaulniers ndesaulniers@google.com x86/irqflags: Mark native_restore_fl extern inline
Andy Lutomirski luto@kernel.org x86/nmi: Fix NMI uaccess race against CR3 switching
Samuel Neves sneves@dei.uc.pt x86/vdso: Fix lsl operand order
Himanshu Madhani himanshu.madhani@cavium.com scsi: qla2xxx: Fix stalled relogin
Dan Carpenter dan.carpenter@oracle.com pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show()
Johan Hovold johan@kernel.org soc: qcom: rmtfs-mem: fix memleak in probe error paths
Ajit Pandey ajit.pandey@cirrus.com ASoC: wm_adsp: Correct DSP pointer for preloader control
Gustavo A. R. Silva gustavo@embeddedor.com ASoC: sirf: Fix potential NULL pointer dereference
Takashi Iwai tiwai@suse.de ASoC: zte: Fix incorrect PCM format bit usages
Jerome Brunet jbrunet@baylibre.com ASoC: dpcm: don't merge format from invalid codec dai
Michael Buesch m@bues.ch b43/leds: Ensure NUL-termination of LED name string
Michael Buesch m@bues.ch b43legacy/leds: Ensure NUL-termination of LED name string
Mikulas Patocka mpatocka@redhat.com udl-kms: avoid division
Mikulas Patocka mpatocka@redhat.com udl-kms: fix crash due to uninitialized memory
Mikulas Patocka mpatocka@redhat.com udl-kms: handle allocation failure
Mikulas Patocka mpatocka@redhat.com udl-kms: change down_interruptible to down
Bart Van Assche bart.vanassche@wdc.com lib/vsprintf: Do not handle %pO[^F] as %px
Kirill Tkhai ktkhai@virtuozzo.com fuse: Add missed unlock_page() to fuse_readpages_fill()
Miklos Szeredi mszeredi@redhat.com fuse: Fix oops at process_init_reply()
Miklos Szeredi mszeredi@redhat.com fuse: umount should wait for all requests
Miklos Szeredi mszeredi@redhat.com fuse: fix unlocked access to processing queue
Miklos Szeredi mszeredi@redhat.com fuse: fix double request_end()
Miklos Szeredi mszeredi@redhat.com fuse: fix initial parallel dirops
Andrey Ryabinin aryabinin@virtuozzo.com fuse: Don't access pipe->buffers without pipe_lock()
Thomas Gleixner tglx@xxxxxxxxxxxxx KVM: x86: SVM: Call x86_spec_ctrl_set_guest/host() with interrupts disabled
Paolo Bonzini pbonzini@redhat.com KVM: x86: ensure all MSRs can always be KVM_GET/SET_MSR'd
Rian Hunter rian@alum.mit.edu x86/process: Re-export start_thread()
Andy Lutomirski luto@kernel.org x86/vdso: Fix vDSO build if a retpoline is emitted
Vlastimil Babka vbabka@suse.cz x86/speculation/l1tf: Suggest what to do on systems with too much RAM
Vlastimil Babka vbabka@suse.cz x86/speculation/l1tf: Fix off-by-one error when warning that system has too much RAM
Vlastimil Babka vbabka@suse.cz x86/speculation/l1tf: Fix overflow in l1tf_pfn_limit() on 32bit
Peter Zijlstra peterz@infradead.org mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE
Takashi Iwai tiwai@suse.de platform/x86: ideapad-laptop: Apply no_hw_rfkill to Y20-15IKBM, too
Kees Cook keescook@chromium.org platform/x86: wmi: Do not mix pages and kmalloc
Paulo Zanoni paulo.r.zanoni@intel.com x86/gpu: reserve ICL's graphics stolen memory
Michal Wnukowski wnukowski@google.com nvme-pci: add a memory barrier to nvme_dbbuf_update_and_check_event
Wang Shilong wshilong@ddn.com ext4: fix race when setting the bitmap corrupted flag
Eric Sandeen sandeen@redhat.com ext4: reset error code in ext4_find_entry in fallback
Arnd Bergmann arnd@arndb.de ext4: sysfs: print ext4_super_block fields as little-endian
Wang Shilong wshilong@ddn.com ext4: use ext4_warning() for sb_getblk failure
Theodore Ts'o tytso@mit.edu ext4: check for NUL characters in extended attribute's name
Prasad Sodagudi psodagud@codeaurora.org stop_machine: Atomically queue and wake stopper threads
Peter Zijlstra peterz@infradead.org stop_machine: Reflow cpu_stop_queue_two_works()
Thomas Richter tmricht@linux.ibm.com perf kvm: Fix subcommands on s390
Claudio Imbrenda imbrenda@linux.vnet.ibm.com s390/kvm: fix deadlock when killed by oom
Punit Agrawal punit.agrawal@arm.com KVM: arm/arm64: Skip updating PTE entry if no change
Punit Agrawal punit.agrawal@arm.com KVM: arm/arm64: Skip updating PMD entry if no change
Christoffer Dall christoffer.dall@arm.com KVM: arm/arm64: Fix lost IRQs from emulated physcial timer when blocked
Christoffer Dall christoffer.dall@arm.com KVM: arm/arm64: Fix potential loss of ptimer interrupts
Huibin Hong huibin.hong@rock-chips.com arm64: dts: rockchip: corrected uart1 clock-names for rk3328
Greg Hackmann ghackmann@android.com arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()
Suzuki K Poulose suzuki.poulose@arm.com arm64: Handle mismatched cache type
Suzuki K Poulose suzuki.poulose@arm.com arm64: Fix mismatched cache line size detection
Masami Hiramatsu mhiramat@kernel.org kprobes/arm64: Fix %p uses in error messages
Petr Mladek pmladek@suse.com printk/nmi: Prevent deadlock when accessing the main log buffer in NMI
Petr Mladek pmladek@suse.com printk: Create helper function to queue deferred console handling
Petr Mladek pmladek@suse.com printk: Split the code for storing a message into the log buffer
Vivek Gautam vivek.gautam@codeaurora.org iommu/arm-smmu: Error out only if not enough context interrupts
Charles Keepax ckeepax@opensource.cirrus.com regulator: arizona-ldo1: Use correct device to get enable GPIO
Daniel Borkmann daniel@iogearbox.net bpf, arm32: fix stack var offset in jit
Michael Larabel michael@phoronix.com hwmon: (k10temp) 27C Offset needed for Threadripper2
Filipe Manana fdmanana@suse.com Btrfs: send, fix incorrect file layout after hole punching beyond eof
Filipe Manana fdmanana@suse.com Btrfs: fix send failure when root has deleted files still open
Josef Bacik jbacik@fb.com Btrfs: fix btrfs_write_inode vs delayed iput deadlock
Filipe Manana fdmanana@suse.com Btrfs: fix mount failure after fsync due to hard link recreation
Josef Bacik josef@toxicpanda.com btrfs: don't leak ret from do_chunk_alloc
Ethan Lien ethanlien@synology.com btrfs: use correct compare function of dirty_metadata_bytes
Steve French stfrench@microsoft.com smb3: fill in statfs fsid and correct namelen
Steve French stfrench@microsoft.com smb3: don't request leases in symlink creation and query
Steve French stfrench@microsoft.com smb3: Do not send SMB3 SET_INFO if nothing changed
Steve French stfrench@microsoft.com smb3: enumerating snapshots was leaving part of the data off end
Nicholas Mc Guire hofrat@osadl.org cifs: check kmalloc before use
Ronnie Sahlberg lsahlber@redhat.com cifs: use a refcount to protect open/closing the cached file handle
Steve French stfrench@microsoft.com cifs: add missing debug entries for kconfig options
Aurelien Aptel aaptel@suse.com CIFS: fix uninitialized ptr deref in smb2 signing
Ronnie Sahlberg lsahlber@redhat.com cifs: add missing support for ACLs in SMB 3.11
Alexander Usyskin alexander.usyskin@intel.com mei: don't update offset in write
Chuck Lever chuck.lever@oracle.com xprtrdma: Fix disconnect regression
Jason Yan yanaijie@huawei.com scsi: libsas: dynamically allocate and free ata host
Ben Hutchings ben@decadent.org.uk scripts/kernel-doc: Escape all literal braces in regexes
Valdis Kletnieks valdis.kletnieks@vt.edu PATCH scripts/kernel-doc
-------------
Diffstat:
Makefile | 8 +- arch/Kconfig | 3 + arch/arm/net/bpf_jit_32.c | 2 +- arch/arm/probes/kprobes/core.c | 4 +- arch/arm/probes/kprobes/test-core.c | 1 - arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 +- arch/arm64/include/asm/cache.h | 4 + arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/kernel/cpu_errata.c | 23 +++- arch/arm64/kernel/cpufeature.c | 2 +- arch/arm64/kernel/probes/kprobes.c | 2 +- arch/arm64/mm/init.c | 6 +- arch/mips/Makefile | 12 +- arch/mips/include/asm/processor.h | 15 ++- arch/mips/kernel/ptrace.c | 2 +- arch/mips/kernel/ptrace32.c | 2 +- arch/mips/lib/memset.S | 3 +- arch/mips/lib/multi3.c | 6 +- arch/s390/include/asm/qdio.h | 1 - arch/s390/lib/mem.S | 16 ++- arch/s390/mm/fault.c | 2 + arch/s390/mm/page-states.c | 2 +- arch/s390/net/bpf_jit_comp.c | 2 - arch/s390/numa/numa.c | 16 +-- arch/s390/pci/pci.c | 2 + arch/s390/purgatory/Makefile | 7 +- arch/x86/Kconfig | 1 + arch/x86/Makefile | 11 +- arch/x86/entry/vdso/Makefile | 6 +- arch/x86/events/core.c | 2 +- arch/x86/include/asm/irqflags.h | 3 +- arch/x86/include/asm/processor.h | 6 +- arch/x86/include/asm/stacktrace.h | 2 +- arch/x86/include/asm/tlbflush.h | 40 +++++++ arch/x86/include/asm/vgtod.h | 2 +- arch/x86/kernel/cpu/bugs.c | 50 ++++++++- arch/x86/kernel/cpu/common.c | 1 + arch/x86/kernel/cpu/intel.c | 3 + arch/x86/kernel/dumpstack.c | 25 ++++- arch/x86/kernel/early-quirks.c | 18 +++ arch/x86/kernel/process_64.c | 1 + arch/x86/kvm/hyperv.c | 27 +++-- arch/x86/kvm/hyperv.h | 2 +- arch/x86/kvm/svm.c | 8 +- arch/x86/kvm/x86.c | 19 ++-- arch/x86/lib/usercopy.c | 5 + arch/x86/mm/fault.c | 2 +- arch/x86/mm/init.c | 4 +- arch/x86/mm/mmap.c | 2 +- arch/x86/mm/tlb.c | 7 ++ drivers/ata/libata-core.c | 3 + drivers/ata/libata.h | 2 - drivers/base/power/clock_ops.c | 2 +- drivers/cdrom/cdrom.c | 2 +- drivers/char/tpm/tpm-interface.c | 53 +++++++-- drivers/char/tpm/tpm.h | 12 +- drivers/char/tpm/tpm2-space.c | 16 ++- drivers/char/tpm/tpm_crb.c | 101 +++++------------ drivers/clk/clk-npcm7xx.c | 4 +- drivers/clk/rockchip/clk-rk3399.c | 2 +- drivers/gpu/drm/udl/udl_drv.h | 2 +- drivers/gpu/drm/udl/udl_fb.c | 17 +-- drivers/gpu/drm/udl/udl_main.c | 35 +++--- drivers/gpu/drm/udl/udl_transfer.c | 39 +++---- drivers/hwmon/k10temp.c | 2 + drivers/hwmon/nct6775.c | 2 + drivers/iommu/arm-smmu.c | 16 ++- drivers/misc/mei/main.c | 1 - drivers/mtd/nand/raw/fsmc_nand.c | 2 +- drivers/mtd/nand/raw/marvell_nand.c | 73 +++++++++++-- drivers/mtd/nand/raw/nand_hynix.c | 10 ++ drivers/mtd/nand/raw/qcom_nandc.c | 53 ++++++++- drivers/net/wireless/broadcom/b43/leds.c | 2 +- drivers/net/wireless/broadcom/b43legacy/leds.c | 2 +- drivers/nvme/host/pci.c | 8 ++ drivers/pinctrl/freescale/pinctrl-imx1-core.c | 2 +- drivers/platform/x86/ideapad-laptop.c | 4 +- drivers/platform/x86/wmi.c | 9 +- drivers/power/supply/generic-adc-battery.c | 25 +++-- drivers/regulator/arizona-ldo1.c | 27 ++++- drivers/s390/cio/qdio_main.c | 5 +- drivers/scsi/libsas/sas_ata.c | 40 ++++--- drivers/scsi/libsas/sas_discover.c | 2 + drivers/scsi/mpt3sas/mpt3sas_base.c | 1 + drivers/scsi/mpt3sas/mpt3sas_scsih.c | 2 +- drivers/scsi/mpt3sas/mpt3sas_transport.c | 5 +- drivers/scsi/qla2xxx/qla_init.c | 2 +- drivers/scsi/qla2xxx/qla_iocb.c | 1 + drivers/scsi/scsi_sysfs.c | 20 +++- drivers/soc/qcom/rmtfs_mem.c | 3 +- drivers/target/iscsi/iscsi_target_login.c | 35 +++--- fs/btrfs/disk-io.c | 10 +- fs/btrfs/extent-tree.c | 2 +- fs/btrfs/inode.c | 26 ----- fs/btrfs/send.c | 146 +++++++++++++++++++++++-- fs/btrfs/super.c | 1 - fs/btrfs/tree-log.c | 66 +++++++++++ fs/cifs/cifs_debug.c | 30 +++-- fs/cifs/cifsfs.c | 18 +-- fs/cifs/cifsglob.h | 1 + fs/cifs/inode.c | 2 + fs/cifs/link.c | 4 +- fs/cifs/sess.c | 6 + fs/cifs/smb2inode.c | 6 +- fs/cifs/smb2ops.c | 72 ++++++++++-- fs/cifs/smb2pdu.c | 8 ++ fs/cifs/smb2pdu.h | 11 ++ fs/cifs/smb2proto.h | 1 + fs/cifs/smb2transport.c | 5 +- fs/ext4/balloc.c | 6 +- fs/ext4/ialloc.c | 6 +- fs/ext4/namei.c | 1 + fs/ext4/super.c | 22 ++-- fs/ext4/sysfs.c | 13 ++- fs/ext4/xattr.c | 2 + fs/fuse/dev.c | 39 +++++-- fs/fuse/dir.c | 10 +- fs/fuse/file.c | 1 + fs/fuse/fuse_i.h | 5 +- fs/fuse/inode.c | 37 ++++--- fs/sysfs/file.c | 44 ++++++++ include/drm/i915_drm.h | 4 +- include/linux/libata.h | 2 + include/linux/printk.h | 4 + include/linux/sysfs.h | 14 +++ include/linux/tpm.h | 2 + include/scsi/libsas.h | 2 +- kernel/kprobes.c | 38 ++++--- kernel/printk/internal.h | 9 +- kernel/printk/printk.c | 57 ++++++---- kernel/printk/printk_safe.c | 58 ++++++---- kernel/stop_machine.c | 43 +++++--- kernel/trace/trace.c | 4 +- kernel/watchdog.c | 4 +- kernel/watchdog_hld.c | 2 +- kernel/workqueue.c | 2 +- lib/nmi_backtrace.c | 3 - lib/vsprintf.c | 1 + mm/memory.c | 18 +++ net/sunrpc/xprtrdma/verbs.c | 5 +- scripts/kernel-doc | 20 ++-- sound/soc/codecs/wm_adsp.c | 8 +- sound/soc/sirf/sirf-usp.c | 7 +- sound/soc/soc-pcm.c | 8 ++ sound/soc/zte/zx-tdm.c | 4 +- tools/perf/arch/s390/util/kvm-stat.c | 2 +- virt/kvm/arm/arch_timer.c | 15 ++- virt/kvm/arm/mmu.c | 42 +++++-- 148 files changed, 1438 insertions(+), 580 deletions(-)
On 09/03/18 18:55, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release.
Unfortunately this is busted. First blamed my custom patches, but as it turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, but later when starting services and esp. autofs (I think - too much output) explodes with:
... Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at 00000000ab58c99c (stack is 00000000382b9464..00000000d642b9d6) Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): 0000 [#1] SMP Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount Tainted: G O 4.18.6 #1 Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 Sep 3 20:19:38 ragnarok kernel: RIP: 0010:flush_tlb_func_common.constprop.4+0x23/0x260 Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f b7 c3 65 48 8b 15 Sep 3 20:19:38 ragnarok kernel: RSP: 0018:ffffc9000326bfe0 EFLAGS: 00010082 Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: ffff880601006cc0 RCX: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: RDX: 00007fb464e7e000 RSI: 0000000000000003 RDI: ffffc9000326c040 Sep 3 20:19:38 ragnarok kernel: RBP: ffffc9000326c030 R08: 00000005fca490e7 R09: 00000000004fa811 Sep 3 20:19:38 ragnarok kernel: R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000004 Sep 3 20:19:38 ragnarok kernel: R13: ffff8805fbab7600 R14: ffff880601006cc0 R15: ffff880602dfb540 Sep 3 20:19:38 ragnarok kernel: FS: 00007fb469245240(0000) GS:ffff88061f500000(0000) knlGS:0000000000000000 Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 3 20:19:38 ragnarok kernel: CR2: ffffc9000326bfd8 CR3: 00000005feadb001 CR4: 00000000000606e0 Sep 3 20:19:38 ragnarok kernel: Call Trace: Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 ..a few hundred times.. Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 f7 d8 89 01 48 83 Sep 3 20:19:38 ragnarok kernel: RSP: 002b:00007ffef83ba548 EFLAGS: 00000206 ORIG_RAX: 000000000000000b Sep 3 20:19:38 ragnarok kernel: RAX: ffffffffffffffda RBX: 0000562a1dca9010 RCX: 00007fb469081187 Sep 3 20:19:38 ragnarok kernel: RDX: 0000000000000002 RSI: 0000000000204028 RDI: 00007fb464c79000 Sep 3 20:19:38 ragnarok kernel: RBP: 00007ffef83ba720 R08: 00007fb46928e930 R09: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: R10: 00007fb464e7d000 R11: 0000000000000206 R12: 00007ffef83ba654 Sep 3 20:19:38 ragnarok kernel: R13: 00007ffef83ba610 R14: 00007ffef83ba655 R15: 00007fb46928e000 Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline fb_sys_fops ttm snd_hda_intel aesni_intel snd_hda_codec drm snd_hda_core aes_x86_64 crypto_simd drm_panel_orientation_quirks cryptd snd_pcm glue_helper backlight snd_timer snd i2c_i801 soundcore i2c_core r8169 parport_pc parport mii Sep 3 20:19:38 ragnarok kernel: ---[ end trace cf25033b43d98311 ]--- Sep 3 20:19:38 ragnarok kernel: RIP: 0010:flush_tlb_func_common.constprop.4+0x23/0x260 Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f b7 c3 65 48 8b 15 Sep 3 20:19:38 ragnarok kernel: RSP: 0018:ffffc9000326bfe0 EFLAGS: 00010082 Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: ffff880601006cc0 RCX: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: RDX: 00007fb464e7e000 RSI: 0000000000000003 RDI: ffffc9000326c040 Sep 3 20:19:38 ragnarok kernel: RBP: ffffc9000326c030 R08: 00000005fca490e7 R09: 00000000004fa811 Sep 3 20:19:38 ragnarok kernel: R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000004 Sep 3 20:19:38 ragnarok kernel: R13: ffff8805fbab7600 R14: ffff880601006cc0 R15: ffff880602dfb540 Sep 3 20:19:38 ragnarok kernel: FS: 00007fb469245240(0000) GS:ffff88061f500000(0000) knlGS:0000000000000000 Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 3 20:19:38 ragnarok kernel: CR2: ffffc9000326bfd8 CR3: 00000005feadb001 CR4: 00000000000606e0 Sep 3 20:19:40 ragnarok kernel: r8169 0000:04:00.0 eth0: link up Sep 3 20:19:40 ragnarok kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
This is repeatable; full log is available on request.
Reverting "mm-tlb-x86-mm-support-invalidating-tlb-caches-for-rcu_table_free" makes everything work.
I'm now going back to my custom tree with lazy TLB handling, that worked as advertised. :D
cheers Holger
Le 3/09/18 à 20:39, Holger Hoffstätte a écrit :
On 09/03/18 18:55, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release.
Unfortunately this is busted. First blamed my custom patches, but as it turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, but later when starting services and esp. autofs (I think - too much output) explodes with:
... Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at 00000000ab58c99c (stack is 00000000382b9464..00000000d642b9d6) Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): 0000 [#1] SMP Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount Tainted: G O 4.18.6 #1 Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 Sep 3 20:19:38 ragnarok kernel: RIP: 0010:flush_tlb_func_common.constprop.4+0x23/0x260 Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f b7 c3 65 48 8b 15 Sep 3 20:19:38 ragnarok kernel: RSP: 0018:ffffc9000326bfe0 EFLAGS: 00010082 Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: ffff880601006cc0 RCX: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: RDX: 00007fb464e7e000 RSI: 0000000000000003 RDI: ffffc9000326c040 Sep 3 20:19:38 ragnarok kernel: RBP: ffffc9000326c030 R08: 00000005fca490e7 R09: 00000000004fa811 Sep 3 20:19:38 ragnarok kernel: R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000004 Sep 3 20:19:38 ragnarok kernel: R13: ffff8805fbab7600 R14: ffff880601006cc0 R15: ffff880602dfb540 Sep 3 20:19:38 ragnarok kernel: FS: 00007fb469245240(0000) GS:ffff88061f500000(0000) knlGS:0000000000000000 Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 3 20:19:38 ragnarok kernel: CR2: ffffc9000326bfd8 CR3: 00000005feadb001 CR4: 00000000000606e0 Sep 3 20:19:38 ragnarok kernel: Call Trace: Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 ..a few hundred times.. Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 f7 d8 89 01 48 83 Sep 3 20:19:38 ragnarok kernel: RSP: 002b:00007ffef83ba548 EFLAGS: 00000206 ORIG_RAX: 000000000000000b Sep 3 20:19:38 ragnarok kernel: RAX: ffffffffffffffda RBX: 0000562a1dca9010 RCX: 00007fb469081187 Sep 3 20:19:38 ragnarok kernel: RDX: 0000000000000002 RSI: 0000000000204028 RDI: 00007fb464c79000 Sep 3 20:19:38 ragnarok kernel: RBP: 00007ffef83ba720 R08: 00007fb46928e930 R09: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: R10: 00007fb464e7d000 R11: 0000000000000206 R12: 00007ffef83ba654 Sep 3 20:19:38 ragnarok kernel: R13: 00007ffef83ba610 R14: 00007ffef83ba655 R15: 00007fb46928e000 Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline fb_sys_fops ttm snd_hda_intel aesni_intel snd_hda_codec drm snd_hda_core aes_x86_64 crypto_simd drm_panel_orientation_quirks cryptd snd_pcm glue_helper backlight snd_timer snd i2c_i801 soundcore i2c_core r8169 parport_pc parport mii Sep 3 20:19:38 ragnarok kernel: ---[ end trace cf25033b43d98311 ]--- Sep 3 20:19:38 ragnarok kernel: RIP: 0010:flush_tlb_func_common.constprop.4+0x23/0x260 Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f b7 c3 65 48 8b 15 Sep 3 20:19:38 ragnarok kernel: RSP: 0018:ffffc9000326bfe0 EFLAGS: 00010082 Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: ffff880601006cc0 RCX: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: RDX: 00007fb464e7e000 RSI: 0000000000000003 RDI: ffffc9000326c040 Sep 3 20:19:38 ragnarok kernel: RBP: ffffc9000326c030 R08: 00000005fca490e7 R09: 00000000004fa811 Sep 3 20:19:38 ragnarok kernel: R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000004 Sep 3 20:19:38 ragnarok kernel: R13: ffff8805fbab7600 R14: ffff880601006cc0 R15: ffff880602dfb540 Sep 3 20:19:38 ragnarok kernel: FS: 00007fb469245240(0000) GS:ffff88061f500000(0000) knlGS:0000000000000000 Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 3 20:19:38 ragnarok kernel: CR2: ffffc9000326bfd8 CR3: 00000005feadb001 CR4: 00000000000606e0 Sep 3 20:19:40 ragnarok kernel: r8169 0000:04:00.0 eth0: link up Sep 3 20:19:40 ragnarok kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
This is repeatable; full log is available on request.
Reverting "mm-tlb-x86-mm-support-invalidating-tlb-caches-for-rcu_table_free" makes everything work.
I'm now going back to my custom tree with lazy TLB handling, that worked as advertised. :D
cheers Holger
I confirm this also for the 4.14 tree. I get the same errors and reverting the same patch also fixes the problem.
François Valenduc
On 4 September 2018 at 02:46, François Valenduc francoisvalenduc@gmail.com wrote:
Le 3/09/18 à 20:39, Holger Hoffstätte a écrit :
On 09/03/18 18:55, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release.
Unfortunately this is busted. First blamed my custom patches, but as it turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts, but later when starting services and esp. autofs (I think - too much output) explodes with:
... Sep 3 20:19:36 ragnarok kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Sep 3 20:19:38 ragnarok kernel: BUG: stack guard page was hit at 00000000ab58c99c (stack is 00000000382b9464..00000000d642b9d6) Sep 3 20:19:38 ragnarok kernel: kernel stack overflow (double-fault): 0000 [#1] SMP Sep 3 20:19:38 ragnarok kernel: CPU: 4 PID: 3634 Comm: automount Tainted: G O 4.18.6 #1 Sep 3 20:19:38 ragnarok kernel: Hardware name: Gigabyte Technology Co., Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 Sep 3 20:19:38 ragnarok kernel: RIP: 0010:flush_tlb_func_common.constprop.4+0x23/0x260 Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f b7 c3 65 48 8b 15 Sep 3 20:19:38 ragnarok kernel: RSP: 0018:ffffc9000326bfe0 EFLAGS: 00010082 Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: ffff880601006cc0 RCX: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: RDX: 00007fb464e7e000 RSI: 0000000000000003 RDI: ffffc9000326c040 Sep 3 20:19:38 ragnarok kernel: RBP: ffffc9000326c030 R08: 00000005fca490e7 R09: 00000000004fa811 Sep 3 20:19:38 ragnarok kernel: R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000004 Sep 3 20:19:38 ragnarok kernel: R13: ffff8805fbab7600 R14: ffff880601006cc0 R15: ffff880602dfb540 Sep 3 20:19:38 ragnarok kernel: FS: 00007fb469245240(0000) GS:ffff88061f500000(0000) knlGS:0000000000000000 Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 3 20:19:38 ragnarok kernel: CR2: ffffc9000326bfd8 CR3: 00000005feadb001 CR4: 00000000000606e0 Sep 3 20:19:38 ragnarok kernel: Call Trace: Sep 3 20:19:38 ragnarok kernel: flush_tlb_mm_range+0xff/0x110 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: ? cpumask_any_but+0x1f/0x40 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 ..a few hundred times.. Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30 Sep 3 20:19:38 ragnarok kernel: unmap_region+0xdd/0x110 Sep 3 20:19:38 ragnarok kernel: ? __vma_rb_erase+0x128/0x250 Sep 3 20:19:38 ragnarok kernel: do_munmap+0x273/0x3f0 Sep 3 20:19:38 ragnarok kernel: vm_munmap+0x5f/0xa0 Sep 3 20:19:38 ragnarok kernel: __x64_sys_munmap+0x22/0x30 Sep 3 20:19:38 ragnarok kernel: do_syscall_64+0x3e/0xe0 Sep 3 20:19:38 ragnarok kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 3 20:19:38 ragnarok kernel: RIP: 0033:0x7fb469081187 Sep 3 20:19:38 ragnarok kernel: Code: ff ff ff f7 d8 89 05 58 df 20 00 48 c7 c0 ff ff ff ff eb 8a 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8d 0d 29 df 20 00 f7 d8 89 01 48 83 Sep 3 20:19:38 ragnarok kernel: RSP: 002b:00007ffef83ba548 EFLAGS: 00000206 ORIG_RAX: 000000000000000b Sep 3 20:19:38 ragnarok kernel: RAX: ffffffffffffffda RBX: 0000562a1dca9010 RCX: 00007fb469081187 Sep 3 20:19:38 ragnarok kernel: RDX: 0000000000000002 RSI: 0000000000204028 RDI: 00007fb464c79000 Sep 3 20:19:38 ragnarok kernel: RBP: 00007ffef83ba720 R08: 00007fb46928e930 R09: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: R10: 00007fb464e7d000 R11: 0000000000000206 R12: 00007ffef83ba654 Sep 3 20:19:38 ragnarok kernel: R13: 00007ffef83ba610 R14: 00007ffef83ba655 R15: 00007fb46928e000 Sep 3 20:19:38 ragnarok kernel: Modules linked in: autofs4 tcp_bbr sch_fq_codel pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) it87 hwmon_vid x86_pkg_temp_thermal uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio videobuf2_v4l2 snd_hwdep bfq snd_usbmidi_lib videodev snd_rawmidi coretemp snd_seq_device videobuf2_common radeon usbhid kvm_intel i2c_algo_bit kvm snd_hda_codec_realtek irqbypass drm_kms_helper snd_hda_codec_hdmi snd_hda_codec_generic pcbc syscopyarea sysfillrect sysimgblt mq_deadline fb_sys_fops ttm snd_hda_intel aesni_intel snd_hda_codec drm snd_hda_core aes_x86_64 crypto_simd drm_panel_orientation_quirks cryptd snd_pcm glue_helper backlight snd_timer snd i2c_i801 soundcore i2c_core r8169 parport_pc parport mii Sep 3 20:19:38 ragnarok kernel: ---[ end trace cf25033b43d98311 ]--- Sep 3 20:19:38 ragnarok kernel: RIP: 0010:flush_tlb_func_common.constprop.4+0x23/0x260 Sep 3 20:19:38 ragnarok kernel: Code: 0b eb e5 0f 1f 40 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 20 65 48 8b 04 25 28 00 00 00 <48> 89 44 24 18 31 c0 65 66 8b 1d 96 fd fc 7e 0f b7 c3 65 48 8b 15 Sep 3 20:19:38 ragnarok kernel: RSP: 0018:ffffc9000326bfe0 EFLAGS: 00010082 Sep 3 20:19:38 ragnarok kernel: RAX: cf0a75e3a0e78e00 RBX: ffff880601006cc0 RCX: 0000000000000000 Sep 3 20:19:38 ragnarok kernel: RDX: 00007fb464e7e000 RSI: 0000000000000003 RDI: ffffc9000326c040 Sep 3 20:19:38 ragnarok kernel: RBP: ffffc9000326c030 R08: 00000005fca490e7 R09: 00000000004fa811 Sep 3 20:19:38 ragnarok kernel: R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000004 Sep 3 20:19:38 ragnarok kernel: R13: ffff8805fbab7600 R14: ffff880601006cc0 R15: ffff880602dfb540 Sep 3 20:19:38 ragnarok kernel: FS: 00007fb469245240(0000) GS:ffff88061f500000(0000) knlGS:0000000000000000 Sep 3 20:19:38 ragnarok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 3 20:19:38 ragnarok kernel: CR2: ffffc9000326bfd8 CR3: 00000005feadb001 CR4: 00000000000606e0 Sep 3 20:19:40 ragnarok kernel: r8169 0000:04:00.0 eth0: link up Sep 3 20:19:40 ragnarok kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
This is repeatable; full log is available on request.
Reverting "mm-tlb-x86-mm-support-invalidating-tlb-caches-for-rcu_table_free" makes everything work.
I'm now going back to my custom tree with lazy TLB handling, that worked as advertised. :D
cheers Holger
I confirm this also for the 4.14 tree. I get the same errors and reverting the same patch also fixes the problem.
I do see this crash log on 4.18.6-rc1, 4.18.6-rc1 run full log, https://lkft.validation.linaro.org/scheduler/job/404027#L3244
François Valenduc
Best regards Naresh Kamboju
On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte holger@applied-asynchrony.com wrote:
Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 ..a few hundred times.. Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30
Yeah, so what seems to have happened is that commit db7ddef30112 ("mm: move tlb_table_flush to tlb_flush_mmu_free") wasn't applied to the stable tree (because it wasn't an obvious dependency).
And without that, the backport of d86564a2f085 ("mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE") ends up with recursion from tlb_flush_mmu_tlbonly() calling tlb_table_flush(), which in turn calls tlb_table_invalidate(), which calls back to tlb_flush_mmu_tlbonly().
So you have endless recursion - at least until you run out of stack. Then, if you have VMAP_STACK enabled (x86-64 without KASAN), you get a nice clean kernel stack overflow message like you did.
Or if you have KASAN enabled and no VMAP stack, you just end up with random hangs and huge memory corruption as the recursion stomps all over your memory.
Linus
On Tue, Sep 04, 2018 at 10:12:13AM -0700, Linus Torvalds wrote:
On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte holger@applied-asynchrony.com wrote:
Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0 Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 ..a few hundred times.. Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30 Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0 Sep 3 20:19:38 ragnarok kernel: arch_tlb_finish_mmu+0x3a/0x70 Sep 3 20:19:38 ragnarok kernel: tlb_finish_mmu+0x1f/0x30
Yeah, so what seems to have happened is that commit db7ddef30112 ("mm: move tlb_table_flush to tlb_flush_mmu_free") wasn't applied to the stable tree (because it wasn't an obvious dependency).
And without that, the backport of d86564a2f085 ("mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE") ends up with recursion from tlb_flush_mmu_tlbonly() calling tlb_table_flush(), which in turn calls tlb_table_invalidate(), which calls back to tlb_flush_mmu_tlbonly().
So you have endless recursion - at least until you run out of stack. Then, if you have VMAP_STACK enabled (x86-64 without KASAN), you get a nice clean kernel stack overflow message like you did.
Or if you have KASAN enabled and no VMAP stack, you just end up with random hangs and huge memory corruption as the recursion stomps all over your memory.
Ok, I will go queue this patch up now, it was in my very-long "to-apply" queue, but I didn't catch the dependancy here.
thanks,
greg k-h
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late.
Not directly related to v4.18.6-rc1. I have seen the following hang several times with v4.18.5. It happens on a quite regular basis after a suspend-resume cycle. CPU is Ryzen 1700X.
Guenter
--- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L 4.18.5+ #1 [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 [ 9990.762596] Workqueue: events free_work [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 [ 9990.762626] RSP: 0018:ffff95ebc3effd20 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 [ 9990.762628] RAX: 000000000000000c RBX: ffff94eeded63cc8 RCX: ffff94eedef27bc0 [ 9990.762629] RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff94eeded63cc8 [ 9990.762630] RBP: ffff95ebc3effd60 R08: 00000000fffffff0 R09: 00000000000000ff [ 9990.762631] R10: ffff94eeded63ce8 R11: ffff94eeded63cc8 R12: ffff94eeded63cc0 [ 9990.762632] R13: ffffffffa6076150 R14: 0000000000000000 R15: 0000000000000100 [ 9990.762633] FS: 0000000000000000(0000) GS:ffff94eeded40000(0000) knlGS:0000000000000000 [ 9990.762635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9990.762636] CR2: 0000000000a67000 CR3: 00000006f120c000 CR4: 00000000003406e0 [ 9990.762637] Call Trace: [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 [ 9990.762644] on_each_cpu+0x2d/0x60 [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 [ 9990.762654] remove_vm_area+0x74/0x80 [ 9990.762656] __vunmap+0x3b/0xc0 [ 9990.762657] free_work+0x25/0x40 [ 9990.762660] process_one_work+0x15e/0x3f0 [ 9990.762662] worker_thread+0x4a/0x440 [ 9990.762664] kthread+0x105/0x140 [ 9990.762666] ? process_one_work+0x3f0/0x3f0 [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 [ 9990.762670] ret_from_fork+0x22/0x40
On Tue, Sep 04, 2018 at 09:24:34AM -0700, Guenter Roeck wrote:
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late.
Not directly related to v4.18.6-rc1. I have seen the following hang several times with v4.18.5. It happens on a quite regular basis after a suspend-resume cycle. CPU is Ryzen 1700X.
Guenter
[ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L 4.18.5+ #1 [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 [ 9990.762596] Workqueue: events free_work [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 [ 9990.762626] RSP: 0018:ffff95ebc3effd20 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 [ 9990.762628] RAX: 000000000000000c RBX: ffff94eeded63cc8 RCX: ffff94eedef27bc0 [ 9990.762629] RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff94eeded63cc8 [ 9990.762630] RBP: ffff95ebc3effd60 R08: 00000000fffffff0 R09: 00000000000000ff [ 9990.762631] R10: ffff94eeded63ce8 R11: ffff94eeded63cc8 R12: ffff94eeded63cc0 [ 9990.762632] R13: ffffffffa6076150 R14: 0000000000000000 R15: 0000000000000100 [ 9990.762633] FS: 0000000000000000(0000) GS:ffff94eeded40000(0000) knlGS:0000000000000000 [ 9990.762635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9990.762636] CR2: 0000000000a67000 CR3: 00000006f120c000 CR4: 00000000003406e0 [ 9990.762637] Call Trace: [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 [ 9990.762644] on_each_cpu+0x2d/0x60 [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 [ 9990.762654] remove_vm_area+0x74/0x80 [ 9990.762656] __vunmap+0x3b/0xc0 [ 9990.762657] free_work+0x25/0x40 [ 9990.762660] process_one_work+0x15e/0x3f0 [ 9990.762662] worker_thread+0x4a/0x440 [ 9990.762664] kthread+0x105/0x140 [ 9990.762666] ? process_one_work+0x3f0/0x3f0 [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 [ 9990.762670] ret_from_fork+0x22/0x40
Odd. Do you see this on Linus's tree?
thanks,
greg k-h
On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote:
On Tue, Sep 04, 2018 at 09:24:34AM -0700, Guenter Roeck wrote:
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late.
Not directly related to v4.18.6-rc1. I have seen the following hang several times with v4.18.5. It happens on a quite regular basis after a suspend-resume cycle. CPU is Ryzen 1700X.
Guenter
[ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762549] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport sp5100_tco squashfs iptable_filter snd_hda_codec_hdmi binfmt_misc edac_mce_amd kvm snd_hda_codec_realtek irqbypass snd_hda_codec_generic snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel snd_rawmidi aesni_intel snd_hda_intel aes_x86_64 crypto_simd cryptd glue_helper snd_hda_codec snd_hda_core wmi_bmof snd_hwdep snd_seq snd_pcm k10temp snd_seq_device snd_timer snd soundcore sch_fq_codel parport_pc sunrpc ppdev lp parport ip_tables x_tables autofs4 hid_generic nouveau mxm_wmi video ttm drm_kms_helper usbhid syscopyarea sysfillrect hid sysimgblt igb fb_sys_fops dca drm i2c_algo_bit i2c_piix4 i2c_core r8169 ahci mii libahci wmi [ 9990.762589] CPU: 5 PID: 155 Comm: kworker/5:1 Tainted: G L 4.18.5+ #1 [ 9990.762591] Hardware name: Gigabyte Technology Co., Ltd. AB350M-Gaming 3/AB350M-Gaming 3-CF, BIOS F23 08/08/2018 [ 9990.762596] Workqueue: events free_work [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 [ 9990.762626] RSP: 0018:ffff95ebc3effd20 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 [ 9990.762628] RAX: 000000000000000c RBX: ffff94eeded63cc8 RCX: ffff94eedef27bc0 [ 9990.762629] RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff94eeded63cc8 [ 9990.762630] RBP: ffff95ebc3effd60 R08: 00000000fffffff0 R09: 00000000000000ff [ 9990.762631] R10: ffff94eeded63ce8 R11: ffff94eeded63cc8 R12: ffff94eeded63cc0 [ 9990.762632] R13: ffffffffa6076150 R14: 0000000000000000 R15: 0000000000000100 [ 9990.762633] FS: 0000000000000000(0000) GS:ffff94eeded40000(0000) knlGS:0000000000000000 [ 9990.762635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9990.762636] CR2: 0000000000a67000 CR3: 00000006f120c000 CR4: 00000000003406e0 [ 9990.762637] Call Trace: [ 9990.762642] ? load_new_mm_cr3+0xe0/0xe0 [ 9990.762644] on_each_cpu+0x2d/0x60 [ 9990.762647] flush_tlb_kernel_range+0x4b/0x80 [ 9990.762648] ? vunmap_page_range+0x1fe/0x310 [ 9990.762650] __purge_vmap_area_lazy+0x50/0xb0 [ 9990.762652] free_vmap_area_noflush+0x7d/0x90 [ 9990.762654] remove_vm_area+0x74/0x80 [ 9990.762656] __vunmap+0x3b/0xc0 [ 9990.762657] free_work+0x25/0x40 [ 9990.762660] process_one_work+0x15e/0x3f0 [ 9990.762662] worker_thread+0x4a/0x440 [ 9990.762664] kthread+0x105/0x140 [ 9990.762666] ? process_one_work+0x3f0/0x3f0 [ 9990.762668] ? kthread_destroy_worker+0x50/0x50 [ 9990.762670] ret_from_fork+0x22/0x40
Odd. Do you see this on Linus's tree?
Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further.
Either case, it is not a concern for the current release since it affects other kernel versions.
Guenter
On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck linux@roeck-us.net wrote:
On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote:
[ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89
It's stuck in this loop:
loop: pause mov 0x18(%rcx),%edx and $0x1,%edx jne loop
which is csd_lock_wait().
Judging by the offset in smp_call_function_many(), it's the final one (there's two: the other one is part of "csd_lock()"). But that's just a guess.
Anyway, it means that we're waiting for another CPU to finish processing an IPI - either a previous one we sent asynchronously (if it's the earlier csd_lock() case) or the TLB IPI we just sent and we're waiting for completion of.
Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further.
Ouch. Some IPI sending/receiving problem would be very very painful to debug if it's hw related.
Linus
On 09/05/2018 10:01 AM, Linus Torvalds wrote:
On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck linux@roeck-us.net wrote:
On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote:
[ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89
It's stuck in this loop:
loop: pause mov 0x18(%rcx),%edx and $0x1,%edx jne loopwhich is csd_lock_wait().
Judging by the offset in smp_call_function_many(), it's the final one (there's two: the other one is part of "csd_lock()"). But that's just a guess.
Anyway, it means that we're waiting for another CPU to finish processing an IPI - either a previous one we sent asynchronously (if it's the earlier csd_lock() case) or the TLB IPI we just sent and we're waiting for completion of.
Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further.
Ouch. Some IPI sending/receiving problem would be very very painful to debug if it's hw related.
Turns out this is a well known problem with Ryzen CPUs:
https://bugzilla.kernel.org/show_bug.cgi?id=196683
Guenter
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 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.18.6-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.18.y and the diffstat can be found below.
I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2....
On 09/04/2018 01:32 PM, Greg Kroah-Hartman wrote:
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 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.18.6-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.18.y and the diffstat can be found below.
I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2....
It hasn't shown up on kernel.org yet. Found patch-4.14.68-rc2.gz
thanks, -- Shuah
On 5 September 2018 at 01:02, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 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.18.6-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.18.y and the diffstat can be found below.
I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2....
I get to see 4.18.6-rc1 not rc2. With the current results on given commit id are looking good.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
Summary ------------------------------------------------------------------------
kernel: 4.18.6-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.18.y git commit: a6a229cf7e7f147eb6d118815a01758749fa6e8d git describe: v4.18.5-124-ga6a229cf7e7f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.5-124...
No regressions (compared to build v4.18.5)
Ran 21181 total tests in the following environments and test suites.
Environments -------------- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64
Test Suites ----------- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-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 * prep-inline * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none
On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote:
On 5 September 2018 at 01:02, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 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.18.6-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.18.y and the diffstat can be found below.
I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2....
I get to see 4.18.6-rc1 not rc2.
Odd. Something is up with the kernel.org mirroring right now. Let's wait for people to wake up to look into it...
With the current results on given commit id are looking good.
Wonderful, thanks for testing and letting me know.
greg k-h
On 09/05/2018 03:43 AM, Greg Kroah-Hartman wrote:
On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote:
On 5 September 2018 at 01:02, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 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.18.6-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.18.y and the diffstat can be found below.
I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2....
I get to see 4.18.6-rc1 not rc2.
Odd. Something is up with the kernel.org mirroring right now. Let's wait for people to wake up to look into it...
Same here (rc1 vs. rc2). The necessary added patch was there, so I figured you did not update the release number and ignored it.
Guenter
With the current results on given commit id are looking good.
Wonderful, thanks for testing and letting me know.
greg k-h
On Wed, Sep 05, 2018 at 04:08:35PM +0530, Naresh Kamboju wrote:
On 5 September 2018 at 01:02, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 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.18.6-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.18.y and the diffstat can be found below.
I have released -rc2 to fix a reported problem: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.6-rc2....
I get to see 4.18.6-rc1 not rc2. With the current results on given commit id are looking good.
Results from Linaro’s test farm. No regressions on arm64, arm and x86_64.
You may have noticed i386 listed below under Environments. This was added last week, and runs functional testing on an i386 kernel under QEMU emulation, as well as on x86_64 server hardware. This also accounts for our total test count (unique tests * test environments) surpassing 20,000.
We'll therefore be updating the email header to read:
No regressions on arm64, arm, x86_64, and i386.
Thanks, Dan
Summary
kernel: 4.18.6-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.18.y git commit: a6a229cf7e7f147eb6d118815a01758749fa6e8d git describe: v4.18.5-124-ga6a229cf7e7f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.5-124...
No regressions (compared to build v4.18.5)
Ran 21181 total tests in the following environments and test suites.
Environments
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
- boot
- kselftest
- libhugetlbfs
- ltp-cap_bounds-tests
- ltp-containers-tests
- ltp-cve-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
- prep-inline
- ltp-open-posix-tests
- kselftest-vsyscall-mode-native
- kselftest-vsyscall-mode-none
-- Linaro LKFT https://lkft.linaro.org
On 09/03/2018 09:55 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late.
Build results: total: 136 pass: 136 fail: 0 Qemu test results: total: 314 pass: 314 fail: 0
Details are available at https://kerneltests.org/builders/.
Guenter
On Tue, Sep 04, 2018 at 03:53:32PM -0700, Guenter Roeck wrote:
On 09/03/2018 09:55 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release. There are 123 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 Sep 5 16:56:53 UTC 2018. Anything received after that time might be too late.
Build results: total: 136 pass: 136 fail: 0 Qemu test results: total: 314 pass: 314 fail: 0
Details are available at https://kerneltests.org/builders/.
Thanks for testing all of these and letting me know.
greg k-h
-
Dan Rue -
François Valenduc -
Greg Kroah-Hartman -
Guenter Roeck -
Holger Hoffstätte -
Linus Torvalds -
Naresh Kamboju -
Shuah Khan