This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. 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.19.45-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.19.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.19.45-rc1
Andreas Dilger adilger@dilger.ca ext4: don't update s_rev_level if not required
zhangyi (F) yi.zhang@huawei.com ext4: fix compile error when using BUFFER_TRACE
Theodore Ts'o tytso@mit.edu ext4: fix block validity checks for journal inodes using indirect blocks
Colin Ian King colin.king@canonical.com ext4: unsigned int compared against zero
Kees Cook keescook@chromium.org pstore: Refactor compression initialization
Joel Fernandes (Google) joel@joelfernandes.org pstore: Allocate compression during late_initcall()
Kees Cook keescook@chromium.org pstore: Centralize init/exit routines
Eric Dumazet edumazet@google.com iov_iter: optimize page_copy_sane()
Dan Williams dan.j.williams@intel.com libnvdimm/namespace: Fix label tracking error
Roger Pau Monne roger.pau@citrix.com xen/pvh: set xen_domain_type to HVM in xen_pvh_init
Masahiro Yamada yamada.masahiro@socionext.com kbuild: turn auto.conf.cmd into a mandatory include file
Sean Christopherson sean.j.christopherson@intel.com KVM: lapic: Busy wait for timer to expire when using hv_timer
Sean Christopherson sean.j.christopherson@intel.com KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated writes
Chengguang Xu cgxu519@gmail.com jbd2: fix potential double free
Michał Wadowski wadosm@gmail.com ALSA: hda/realtek - Fix for Lenovo B50-70 inverted internal microphone bug
Kailang Yang kailang@realtek.com ALSA: hda/realtek - Fixup headphone noise via runtime suspend
Jeremy Soller jeremy@system76.com ALSA: hda/realtek - Corrected fixup for System76 Gazelle (gaze14)
Jan Kara jack@suse.cz ext4: avoid panic during forced reboot due to aborted journal
Sahitya Tummala stummala@codeaurora.org ext4: fix use-after-free in dx_release()
Lukas Czerner lczerner@redhat.com ext4: fix data corruption caused by overlapping unaligned and aligned IO
Sriram Rajagopalan sriramr@arista.com ext4: zero out the unused memory region in the extent tree block
Anup Patel Anup.Patel@wdc.com tty: Don't force RISCV SBI console as preferred console
Jiufei Xue jiufei.xue@linux.alibaba.com fs/writeback.c: use rcu_barrier() to wait for inflight wb switches going into workqueue when umount
Eric Biggers ebiggers@google.com crypto: ccm - fix incompatibility between "ccm" and "ccm_base"
Kamlakant Patel kamlakantp@marvell.com ipmi:ssif: compare block number correctly for multi-part return messages
Coly Li colyli@suse.de bcache: never set KEY_PTRS of journal key to 0 in journal_reclaim()
Liang Chen liangchen.linux@gmail.com bcache: fix a race between cache register and cacheset unregister
Filipe Manana fdmanana@suse.com Btrfs: do not start a transaction at iterate_extent_inodes()
Filipe Manana fdmanana@suse.com Btrfs: do not start a transaction during fiemap
Filipe Manana fdmanana@suse.com Btrfs: send, flush dellaloc in order to avoid data loss
Nikolay Borisov nborisov@suse.com btrfs: Honour FITRIM range constraints during free space trim
Nikolay Borisov nborisov@suse.com btrfs: Correctly free extent buffer in case btree_read_extent_buffer_pages fails
Qu Wenruo wqu@suse.com btrfs: Check the first key and level for cached extent buffer
Debabrata Banerjee dbanerje@akamai.com ext4: fix ext4_show_options for file systems w/o journal
Kirill Tkhai ktkhai@virtuozzo.com ext4: actually request zeroing of inode table after grow
Barret Rhoden brho@google.com ext4: fix use-after-free race with debug_want_extra_isize
Pan Bian bianpan2016@163.com ext4: avoid drop reference to iloc.bh twice
Theodore Ts'o tytso@mit.edu ext4: ignore e_value_offs for xattrs with value-in-ea-inode
Theodore Ts'o tytso@mit.edu ext4: protect journal inode's blocks using block_validity
Jan Kara jack@suse.cz ext4: make sanity check in mballoc more strict
Jiufei Xue jiufei.xue@linux.alibaba.com jbd2: check superblock mapped prior to committing
Sergei Trofimovich slyfox@gentoo.org tty/vt: fix write/write race in ioctl(KDSKBSENT) handler
Yifeng Li tomli@tomli.me tty: vt.c: Fix TIOCL_BLANKSCREEN console blanking if blankinterval == 0
Alexander Sverdlin alexander.sverdlin@nokia.com mtd: spi-nor: intel-spi: Avoid crossing 4K address boundary on read/write
Dmitry Osipenko digetx@gmail.com mfd: max77620: Fix swapped FPS_PERIOD_MAX_US values
Steve Twiss stwiss.opensource@diasemi.com mfd: da9063: Fix OTP control register names to match datasheets for DA9063/63L
Rajat Jain rajatja@google.com ACPI: PM: Set enable_for_wake for wakeup GPEs during suspend-to-idle
Andrea Arcangeli aarcange@redhat.com userfaultfd: use RCU to free the task struct when fork fails
Shuning Zhang sunny.s.zhang@oracle.com ocfs2: fix ocfs2 read inode data panic in ocfs2_iget
Mike Kravetz mike.kravetz@oracle.com hugetlb: use same fault hash key for shared and private mappings
Kai Shen shenkai8@huawei.com mm/hugetlb.c: don't put_page in lock of hugetlb_lock
Dan Williams dan.j.williams@intel.com mm/huge_memory: fix vmf_insert_pfn_{pmd, pud}() crash, handle unaligned addresses
Jiri Kosina jkosina@suse.cz mm/mincore.c: make mincore() more conservative
Ofir Drang ofir.drang@arm.com crypto: ccree - handle tee fips error during power management resume
Ofir Drang ofir.drang@arm.com crypto: ccree - add function to handle cryptocell tee fips error
Ofir Drang ofir.drang@arm.com crypto: ccree - HOST_POWER_DOWN_EN should be the last CC access during suspend
Ofir Drang ofir.drang@arm.com crypto: ccree - pm resume first enable the source clk
Gilad Ben-Yossef gilad@benyossef.com crypto: ccree - don't map AEAD key and IV on stack
Gilad Ben-Yossef gilad@benyossef.com crypto: ccree - use correct internal state sizes for export
Gilad Ben-Yossef gilad@benyossef.com crypto: ccree - don't map MAC key on stack
Gilad Ben-Yossef gilad@benyossef.com crypto: ccree - fix mem leak on error path
Gilad Ben-Yossef gilad@benyossef.com crypto: ccree - remove special handling of chained sg
Daniel Borkmann daniel@iogearbox.net bpf, arm64: remove prefetch insn in xadd mapping
Libin Yang libin.yang@intel.com ASoC: codec: hdac_hdmi add device_link to card device
S.j. Wang shengjiu.wang@nxp.com ASoC: fsl_esai: Fix missing break in switch statement
Curtis Malainey cujomalainey@chromium.org ASoC: RT5677-SPI: Disable 16Bit SPI Transfers
Jon Hunter jonathanh@nvidia.com ASoC: max98090: Fix restore of DAPM Muxes
Jeremy Soller jeremy@system76.com ALSA: hdea/realtek - Headset fixup for System76 Gazelle (gaze14)
Kailang Yang kailang@realtek.com ALSA: hda/realtek - EAPD turn on later
Hui Wang hui.wang@canonical.com ALSA: hda/hdmi - Consider eld_valid when reporting jack event
Hui Wang hui.wang@canonical.com ALSA: hda/hdmi - Read the pin sense from register when repolling
Wenwen Wang wang6495@umn.edu ALSA: usb-audio: Fix a memory leak bug
Takashi Iwai tiwai@suse.de ALSA: line6: toneport: Fix broken usage of timer for delayed execution
Raul E Rangel rrangel@chromium.org mmc: core: Fix tag set memory leak
Eric Biggers ebiggers@google.com crypto: arm64/aes-neonbs - don't access already-freed walk.iv
Eric Biggers ebiggers@google.com crypto: arm/aes-neonbs - don't access already-freed walk.iv
Zhang Zhijie zhangzj@rock-chips.com crypto: rockchip - update IV buffer to contain the next IV
Eric Biggers ebiggers@google.com crypto: gcm - fix incompatibility between "gcm" and "gcm_base"
Eric Biggers ebiggers@google.com crypto: arm64/gcm-aes-ce - fix no-NEON fallback code
Eric Biggers ebiggers@google.com crypto: x86/crct10dif-pcl - fix use via crypto_shash_digest()
Eric Biggers ebiggers@google.com crypto: crct10dif-generic - fix use via crypto_shash_digest()
Eric Biggers ebiggers@google.com crypto: skcipher - don't WARN on unprocessed data after slow walk step
Daniel Axtens dja@axtens.net crypto: vmx - fix copy-paste error in CTR mode
Singh, Brijesh brijesh.singh@amd.com crypto: ccp - Do not free psp_master when PLATFORM_INIT fails
Eric Biggers ebiggers@google.com crypto: chacha20poly1305 - set cra_name correctly
Eric Biggers ebiggers@google.com crypto: salsa20 - don't access already-freed walk.iv
Christian Lamparter chunkeey@gmail.com crypto: crypto4xx - fix cfb and ofb "overran dst buffer" issues
Christian Lamparter chunkeey@gmail.com crypto: crypto4xx - fix ctr-aes missing output IV
Peter Zijlstra peterz@infradead.org sched/x86: Save [ER]FLAGS on context switch
Jean-Philippe Brucker jean-philippe.brucker@arm.com arm64: Save and restore OSDLR_EL1 across suspend/resume
Jean-Philippe Brucker jean-philippe.brucker@arm.com arm64: Clear OSDLR_EL1 on CPU boot
Vincenzo Frascino vincenzo.frascino@arm.com arm64: compat: Reduce address limit
Will Deacon will.deacon@arm.com arm64: arch_timer: Ensure counter register reads occur with seqlock held
Boyang Zhou zhouby_cn@126.com arm64: mmap: Ensure file offset is treated as unsigned
Hans de Goede hdegoede@redhat.com power: supply: axp288_fuel_gauge: Add ACEPC T8 and T11 mini PCs to the blacklist
Gustavo A. R. Silva gustavo@embeddedor.com power: supply: axp288_charger: Fix unchecked return value
Wen Yang wen.yang99@zte.com.cn ARM: exynos: Fix a leaked reference by adding missing of_node_put
Christoph Muellner christoph.muellner@theobroma-systems.com mmc: sdhci-of-arasan: Add DTS property to disable DCMDs.
Sylwester Nawrocki s.nawrocki@samsung.com ARM: dts: exynos: Fix audio (microphone) routing on Odroid XU3
Stuart Menefy stuart.menefy@mathembedded.com ARM: dts: exynos: Fix interrupt for shared EINTs on Exynos5260
Christoph Muellner christoph.muellner@theobroma-systems.com arm64: dts: rockchip: Disable DCMDs on RK3399's eMMC controller.
Josh Poimboeuf jpoimboe@redhat.com objtool: Fix function fallthrough detection
Andy Lutomirski luto@kernel.org x86/speculation/mds: Improve CPU buffer clear documentation
Andy Lutomirski luto@kernel.org x86/speculation/mds: Revert CPU buffer clear on double fault exit
Waiman Long longman@redhat.com locking/rwsem: Prevent decrement of reader count before increment
-------------
Diffstat:
Documentation/x86/mds.rst | 44 ++------ Makefile | 6 +- arch/arm/boot/dts/exynos5260.dtsi | 2 +- arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 2 +- arch/arm/crypto/aes-neonbs-glue.c | 2 + arch/arm/mach-exynos/firmware.c | 1 + arch/arm/mach-exynos/suspend.c | 2 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 + arch/arm64/crypto/aes-neonbs-glue.c | 2 + arch/arm64/crypto/ghash-ce-glue.c | 10 +- arch/arm64/include/asm/arch_timer.h | 33 +++++- arch/arm64/include/asm/processor.h | 8 ++ arch/arm64/kernel/debug-monitors.c | 1 + arch/arm64/kernel/sys.c | 2 +- arch/arm64/kernel/vdso/gettimeofday.S | 15 ++- arch/arm64/mm/proc.S | 34 ++++--- arch/arm64/net/bpf_jit.h | 6 -- arch/arm64/net/bpf_jit_comp.c | 1 - arch/x86/crypto/crct10dif-pclmul_glue.c | 13 +-- arch/x86/entry/entry_32.S | 2 + arch/x86/entry/entry_64.S | 2 + arch/x86/include/asm/switch_to.h | 1 + arch/x86/kernel/process_32.c | 7 ++ arch/x86/kernel/process_64.c | 8 ++ arch/x86/kernel/traps.c | 8 -- arch/x86/kvm/lapic.c | 2 +- arch/x86/kvm/x86.c | 37 ++++--- arch/x86/xen/enlighten_pvh.c | 1 + crypto/ccm.c | 44 ++++---- crypto/chacha20poly1305.c | 4 +- crypto/crct10dif_generic.c | 11 +- crypto/gcm.c | 34 ++----- crypto/salsa20_generic.c | 2 +- crypto/skcipher.c | 9 +- drivers/acpi/sleep.c | 4 + drivers/char/ipmi/ipmi_ssif.c | 6 +- drivers/crypto/amcc/crypto4xx_alg.c | 12 ++- drivers/crypto/amcc/crypto4xx_core.c | 31 ++++-- drivers/crypto/ccp/psp-dev.c | 2 +- drivers/crypto/ccree/cc_aead.c | 11 +- drivers/crypto/ccree/cc_buffer_mgr.c | 113 +++++++-------------- drivers/crypto/ccree/cc_driver.h | 1 + drivers/crypto/ccree/cc_fips.c | 23 +++-- drivers/crypto/ccree/cc_fips.h | 2 + drivers/crypto/ccree/cc_hash.c | 28 ++++- drivers/crypto/ccree/cc_ivgen.c | 9 +- drivers/crypto/ccree/cc_pm.c | 9 +- drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 25 +++-- drivers/crypto/vmx/aesp8-ppc.pl | 4 +- drivers/dax/device.c | 6 +- drivers/md/bcache/journal.c | 11 +- drivers/md/bcache/super.c | 2 +- drivers/mmc/core/queue.c | 1 + drivers/mmc/host/sdhci-of-arasan.c | 5 +- drivers/mtd/spi-nor/intel-spi.c | 8 ++ drivers/nvdimm/label.c | 29 +++--- drivers/nvdimm/namespace_devs.c | 15 +++ drivers/nvdimm/nd.h | 4 + drivers/power/supply/axp288_charger.c | 4 + drivers/power/supply/axp288_fuel_gauge.c | 20 ++++ drivers/tty/hvc/hvc_riscv_sbi.c | 1 - drivers/tty/vt/keyboard.c | 33 ++++-- drivers/tty/vt/vt.c | 2 - fs/btrfs/backref.c | 34 ++++--- fs/btrfs/ctree.c | 10 ++ fs/btrfs/disk-io.c | 27 +++-- fs/btrfs/disk-io.h | 3 + fs/btrfs/extent-tree.c | 25 +++-- fs/btrfs/send.c | 36 +++++++ fs/dax.c | 6 +- fs/ext4/block_validity.c | 54 ++++++++++ fs/ext4/ext4.h | 6 +- fs/ext4/extents.c | 17 +++- fs/ext4/file.c | 7 ++ fs/ext4/inode.c | 7 +- fs/ext4/ioctl.c | 2 +- fs/ext4/mballoc.c | 2 +- fs/ext4/namei.c | 5 +- fs/ext4/resize.c | 1 + fs/ext4/super.c | 63 +++++++----- fs/ext4/xattr.c | 2 +- fs/fs-writeback.c | 11 +- fs/hugetlbfs/inode.c | 7 +- fs/jbd2/journal.c | 53 ++++++---- fs/jbd2/revoke.c | 32 +++--- fs/jbd2/transaction.c | 8 +- fs/ocfs2/export.c | 30 +++++- fs/pstore/inode.c | 11 +- fs/pstore/internal.h | 5 +- fs/pstore/platform.c | 75 +++++++++++--- fs/pstore/ram.c | 2 +- include/linux/huge_mm.h | 6 +- include/linux/hugetlb.h | 4 +- include/linux/jbd2.h | 8 +- include/linux/mfd/da9063/registers.h | 6 +- include/linux/mfd/max77620.h | 4 +- kernel/fork.c | 31 +++++- kernel/locking/rwsem-xadd.c | 44 +++++--- lib/iov_iter.c | 17 +++- mm/huge_memory.c | 16 +-- mm/hugetlb.c | 25 ++--- mm/mincore.c | 23 ++++- mm/userfaultfd.c | 3 +- sound/pci/hda/patch_hdmi.c | 11 +- sound/pci/hda/patch_realtek.c | 68 ++++++++----- sound/soc/codecs/hdac_hdmi.c | 11 ++ sound/soc/codecs/max98090.c | 12 +-- sound/soc/codecs/rt5677-spi.c | 35 +++---- sound/soc/fsl/fsl_esai.c | 2 +- sound/usb/line6/toneport.c | 16 +-- sound/usb/mixer.c | 2 + tools/objtool/check.c | 3 +- 112 files changed, 1082 insertions(+), 584 deletions(-)
stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 118 passed with 1 offline, 1 conflict (v4.19.44-106-g6b27ffd29c43)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19... Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.44-106...
Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.44-106-g6b27ffd29c43 Git Commit: 6b27ffd29c43f07e11cc906154745c4e9b3d71c3 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 66 unique boards, 24 SoC families, 14 builds out of 206
Boot Regressions Detected:
arm:
omap2plus_defconfig: gcc-8: omap4-panda: lab-baylibre: failing since 3 days (last pass: v4.19.43-114-gb5001f5eab58 - first fail: v4.19.44)
Offline Platforms:
arm:
multi_v7_defconfig: gcc-8 stih410-b2120: 1 offline lab
Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
arm: omap2plus_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8)
--- For more info write to info@kernelci.org
On Mon, May 20, 2019 at 02:13:06PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. Anything received after that time might be too late.
We're seeing an ext4 issue previously reported at https://lore.kernel.org/lkml/20190514092054.GA6949@osiris.
[ 1916.032087] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 1916.073840] jbd2_journal_bmap: journal block not found at offset 4455 on sda-8 [ 1916.081071] Aborting journal on device sda-8. [ 1916.348652] EXT4-fs error (device sda): ext4_journal_check_start:61: Detected aborted journal [ 1916.357222] EXT4-fs (sda): Remounting filesystem read-only
This is seen on 4.19-rc, 5.0-rc, mainline, and next. We don't have data for 5.1-rc yet, which is presumably also affected in this RC round.
We only see this on x86_64 and i386 devices - though our hardware setups vary so it could be coincidence.
I have to run out now, but I'll come back and work on a reproducer and bisection later tonight and tomorrow.
Here is an example test run; link goes to the spot in the ltp syscalls test where the disk goes into read-only mode. https://lkft.validation.linaro.org/scheduler/job/735468#L8081
Dan
On Mon, May 20, 2019 at 05:23:42PM -0500, Dan Rue wrote:
On Mon, May 20, 2019 at 02:13:06PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. Anything received after that time might be too late.
We're seeing an ext4 issue previously reported at https://lore.kernel.org/lkml/20190514092054.GA6949@osiris.
[ 1916.032087] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 1916.073840] jbd2_journal_bmap: journal block not found at offset 4455 on sda-8 [ 1916.081071] Aborting journal on device sda-8. [ 1916.348652] EXT4-fs error (device sda): ext4_journal_check_start:61: Detected aborted journal [ 1916.357222] EXT4-fs (sda): Remounting filesystem read-only
This is seen on 4.19-rc, 5.0-rc, mainline, and next. We don't have data for 5.1-rc yet, which is presumably also affected in this RC round.
We only see this on x86_64 and i386 devices - though our hardware setups vary so it could be coincidence.
I have to run out now, but I'll come back and work on a reproducer and bisection later tonight and tomorrow.
Here is an example test run; link goes to the spot in the ltp syscalls test where the disk goes into read-only mode. https://lkft.validation.linaro.org/scheduler/job/735468#L8081
Odd, I keep hearing rumors of ext4 issues right now, but nothing actually solid that I can point to. Any help you can provide here would be great.
thanks,
greg k-h
On Tue, 21 May 2019 at 14:30, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, May 20, 2019 at 05:23:42PM -0500, Dan Rue wrote:
On Mon, May 20, 2019 at 02:13:06PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. Anything received after that time might be too late.
We're seeing an ext4 issue previously reported at https://lore.kernel.org/lkml/20190514092054.GA6949@osiris.
[ 1916.032087] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 1916.073840] jbd2_journal_bmap: journal block not found at offset 4455 on sda-8 [ 1916.081071] Aborting journal on device sda-8. [ 1916.348652] EXT4-fs error (device sda): ext4_journal_check_start:61: Detected aborted journal [ 1916.357222] EXT4-fs (sda): Remounting filesystem read-only
This is seen on 4.19-rc, 5.0-rc, mainline, and next. We don't have data for 5.1-rc yet, which is presumably also affected in this RC round.
We only see this on x86_64 and i386 devices - though our hardware setups vary so it could be coincidence.
I have to run out now, but I'll come back and work on a reproducer and bisection later tonight and tomorrow.
Here is an example test run; link goes to the spot in the ltp syscalls test where the disk goes into read-only mode. https://lkft.validation.linaro.org/scheduler/job/735468#L8081
Odd, I keep hearing rumors of ext4 issues right now, but nothing actually solid that I can point to. Any help you can provide here would be great.
git bisect helped me to land on this commit,
# git bisect bad e8fd3c9a5415f9199e3fc5279e0f1dfcc0a80ab2 is the first bad commit commit e8fd3c9a5415f9199e3fc5279e0f1dfcc0a80ab2 Author: Theodore Ts'o tytso@mit.edu Date: Tue Apr 9 23:37:08 2019 -0400
ext4: protect journal inode's blocks using block_validity
commit 345c0dbf3a30872d9b204db96b5857cd00808cae upstream.
Add the blocks which belong to the journal inode to block_validity's system zone so attempts to deallocate or overwrite the journal due a corrupted file system where the journal blocks are also claimed by another inode.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202879 Signed-off-by: Theodore Ts'o tytso@mit.edu Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
:040000 040000 b8b6ce2577d60c65021e5cc1c3a38b32e0cbb2ff 747c67b159b33e4e1da414b1d33567a5da9ae125 M fs
- Naresh
thanks,
greg k-h
On Tue, May 21, 2019 at 02:58:58PM +0530, Naresh Kamboju wrote:
On Tue, 21 May 2019 at 14:30, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, May 20, 2019 at 05:23:42PM -0500, Dan Rue wrote:
On Mon, May 20, 2019 at 02:13:06PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. Anything received after that time might be too late.
We're seeing an ext4 issue previously reported at https://lore.kernel.org/lkml/20190514092054.GA6949@osiris.
[ 1916.032087] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 1916.073840] jbd2_journal_bmap: journal block not found at offset 4455 on sda-8 [ 1916.081071] Aborting journal on device sda-8. [ 1916.348652] EXT4-fs error (device sda): ext4_journal_check_start:61: Detected aborted journal [ 1916.357222] EXT4-fs (sda): Remounting filesystem read-only
This is seen on 4.19-rc, 5.0-rc, mainline, and next. We don't have data for 5.1-rc yet, which is presumably also affected in this RC round.
We only see this on x86_64 and i386 devices - though our hardware setups vary so it could be coincidence.
I have to run out now, but I'll come back and work on a reproducer and bisection later tonight and tomorrow.
Here is an example test run; link goes to the spot in the ltp syscalls test where the disk goes into read-only mode. https://lkft.validation.linaro.org/scheduler/job/735468#L8081
Odd, I keep hearing rumors of ext4 issues right now, but nothing actually solid that I can point to. Any help you can provide here would be great.
git bisect helped me to land on this commit,
# git bisect bad e8fd3c9a5415f9199e3fc5279e0f1dfcc0a80ab2 is the first bad commit commit e8fd3c9a5415f9199e3fc5279e0f1dfcc0a80ab2 Author: Theodore Ts'o tytso@mit.edu Date: Tue Apr 9 23:37:08 2019 -0400
ext4: protect journal inode's blocks using block_validity commit 345c0dbf3a30872d9b204db96b5857cd00808cae upstream. Add the blocks which belong to the journal inode to block_validity's system zone so attempts to deallocate or overwrite the journal due a corrupted file system where the journal blocks are also claimed by another inode. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202879 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>:040000 040000 b8b6ce2577d60c65021e5cc1c3a38b32e0cbb2ff 747c67b159b33e4e1da414b1d33567a5da9ae125 M fs
Ah, many thanks for this bisection.
Ted, any ideas here? Should I drop this from the stable trees, and you revert it from Linus's? Or something else?
Note, I do also have 170417c8c7bb ("ext4: fix block validity checks for journal inodes using indirect blocks") in the trees, which was supposed to fix the problem with this patch, am I missing another one as well?
(side note, it was mean not to mark 170417c8c7bb for stable, when the patch it was fixing was marked for stable, I'm lucky I caught it...)
thanks,
greg k-h
On Tue, 21 May 2019 at 15:08, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 21, 2019 at 02:58:58PM +0530, Naresh Kamboju wrote:
On Tue, 21 May 2019 at 14:30, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, May 20, 2019 at 05:23:42PM -0500, Dan Rue wrote:
On Mon, May 20, 2019 at 02:13:06PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. Anything received after that time might be too late.
We're seeing an ext4 issue previously reported at https://lore.kernel.org/lkml/20190514092054.GA6949@osiris.
[ 1916.032087] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 1916.073840] jbd2_journal_bmap: journal block not found at offset 4455 on sda-8 [ 1916.081071] Aborting journal on device sda-8. [ 1916.348652] EXT4-fs error (device sda): ext4_journal_check_start:61: Detected aborted journal [ 1916.357222] EXT4-fs (sda): Remounting filesystem read-only
This is seen on 4.19-rc, 5.0-rc, mainline, and next. We don't have data for 5.1-rc yet, which is presumably also affected in this RC round.
We only see this on x86_64 and i386 devices - though our hardware setups vary so it could be coincidence.
I have to run out now, but I'll come back and work on a reproducer and bisection later tonight and tomorrow.
Here is an example test run; link goes to the spot in the ltp syscalls test where the disk goes into read-only mode. https://lkft.validation.linaro.org/scheduler/job/735468#L8081
Odd, I keep hearing rumors of ext4 issues right now, but nothing actually solid that I can point to. Any help you can provide here would be great.
git bisect helped me to land on this commit,
# git bisect bad e8fd3c9a5415f9199e3fc5279e0f1dfcc0a80ab2 is the first bad commit commit e8fd3c9a5415f9199e3fc5279e0f1dfcc0a80ab2 Author: Theodore Ts'o tytso@mit.edu Date: Tue Apr 9 23:37:08 2019 -0400
ext4: protect journal inode's blocks using block_validity commit 345c0dbf3a30872d9b204db96b5857cd00808cae upstream. Add the blocks which belong to the journal inode to block_validity's system zone so attempts to deallocate or overwrite the journal due a corrupted file system where the journal blocks are also claimed by another inode. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202879 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>:040000 040000 b8b6ce2577d60c65021e5cc1c3a38b32e0cbb2ff 747c67b159b33e4e1da414b1d33567a5da9ae125 M fs
Ah, many thanks for this bisection.
Ted, any ideas here? Should I drop this from the stable trees, and you revert it from Linus's? Or something else?
Note, I do also have 170417c8c7bb ("ext4: fix block validity checks for journal inodes using indirect blocks") in the trees, which was supposed to fix the problem with this patch, am I missing another one as well?
FYI, I have applied fix patch 170417c8c7bb ("ext4: fix block validity checks for journal inodes using indirect blocks") but did not fix this problem.
(side note, it was mean not to mark 170417c8c7bb for stable, when the patch it was fixing was marked for stable, I'm lucky I caught it...)
This problem occurring on stable rc 4.19, 5.0, 5.1 branches and master branch of mainline and -next trees also.
- Naresh
On Tue, May 21, 2019 at 03:58:15PM +0530, Naresh Kamboju wrote:
Ted, any ideas here? Should I drop this from the stable trees, and you revert it from Linus's? Or something else?
It's safe to drop this from the stable trees while we investigate. It was always borderline for stable anyway. (See below).
Note, I do also have 170417c8c7bb ("ext4: fix block validity checks for journal inodes using indirect blocks") in the trees, which was supposed to fix the problem with this patch, am I missing another one as well?
FYI, I have applied fix patch 170417c8c7bb ("ext4: fix block validity checks for journal inodes using indirect blocks") but did not fix this problem.
Hmm... are you _sure_? This bug was reported to me versus the mainline, and the person who reported it confirmed that it did fix the problem, he was seeing, and the symptoms are identical to yours. Can you double check, please? I can't reproduce it either with that patch applied.
(side note, it was mean not to mark 170417c8c7bb for stable, when the patch it was fixing was marked for stable, I'm lucky I caught it...)
Sorry, I had forgotten that I had marked 345c0dbf3a30 for stable; that's why I didn't mark 170417c8c7bb for stable. 345c0dbf3a30 fixes a crash triggered by a specially crafted (corrupted) file system, and I had thought I had decided it wasn't important enough for stable; I think what happened is I shrugged and said, "oh well, Sasha's automated ML system is going to pick it for stable anyway, so I might just mark it for stable anyway" --- and I forgot I had landed that way.
- Ted
On Tue, May 21, 2019 at 12:21:42PM -0400, Theodore Ts'o wrote:
On Tue, May 21, 2019 at 03:58:15PM +0530, Naresh Kamboju wrote:
Ted, any ideas here? Should I drop this from the stable trees, and you revert it from Linus's? Or something else?
It's safe to drop this from the stable trees while we investigate. It was always borderline for stable anyway. (See below).
Ok, will go drop both of these now, thanks.
greg k-h
On Tue, May 21, 2019 at 06:30:12PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 21, 2019 at 12:21:42PM -0400, Theodore Ts'o wrote:
On Tue, May 21, 2019 at 03:58:15PM +0530, Naresh Kamboju wrote:
Ted, any ideas here? Should I drop this from the stable trees, and you revert it from Linus's? Or something else?
It's safe to drop this from the stable trees while we investigate. It was always borderline for stable anyway. (See below).
Ok, will go drop both of these now, thanks.
I have now pushed out -rc2 releases for 5.1, 5.0, and 4.19 with 3 ext4 patches dropped from each series as there was the original patch here, and then 2 others on top of that.
thanks,
greg k-h
On Tue, 21 May 2019 at 21:52, Theodore Ts'o tytso@mit.edu wrote:
On Tue, May 21, 2019 at 03:58:15PM +0530, Naresh Kamboju wrote:
Ted, any ideas here? Should I drop this from the stable trees, and you revert it from Linus's? Or something else?
It's safe to drop this from the stable trees while we investigate. It was always borderline for stable anyway. (See below).
Note, I do also have 170417c8c7bb ("ext4: fix block validity checks for journal inodes using indirect blocks") in the trees, which was supposed to fix the problem with this patch, am I missing another one as well?
FYI, I have applied fix patch 170417c8c7bb ("ext4: fix block validity checks for journal inodes using indirect blocks") but did not fix this problem.
Hmm... are you _sure_? This bug was reported to me versus the mainline, and the person who reported it confirmed that it did fix the problem, he was seeing, and the symptoms are identical to yours. Can you double check, please? I can't reproduce it either with that patch applied.
This bug is specific to x86_64 and i386.
Steps to reproduce is, running LTP three test cases in sequence on x86 device. # cd ltp/runtest # cat syscalls ( only three test case) open12 open12 madvise06 madvise06 poll02 poll02 #
as Dan referring to,
LTP is run using '/opt/ltp/runltp -d /scratch -f syscalls', where the syscalls file has been replaced with three test case names, and /scratch is an ext4 SATA drive. /scratch is created using 'mkfs -t ext4 /dev/disk/by-id/ata-TOSHIBA_MG03ACA100_37O9KGKWF' and mounted to /scratch.
Please find full test log, https://lkft.validation.linaro.org/scheduler/job/738661#L1356
And you notice dmesg log, [ 53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8 [ 53.938480] Aborting journal on device sda-8. [ 55.431382] EXT4-fs error (device sda): ext4_journal_check_start:61: Detected aborted journal [ 55.439947] EXT4-fs (sda): Remounting filesystem read-only
- Naresh
On Tue, May 21, 2019 at 11:27:21PM +0530, Naresh Kamboju wrote:
Steps to reproduce is, running LTP three test cases in sequence on x86 device. # cd ltp/runtest # cat syscalls ( only three test case) open12 open12 madvise06 madvise06 poll02 poll02 #
as Dan referring to,
LTP is run using '/opt/ltp/runltp -d /scratch -f syscalls', where the syscalls file has been replaced with three test case names, and /scratch is an ext4 SATA drive. /scratch is created using 'mkfs -t ext4 /dev/disk/by-id/ata-TOSHIBA_MG03ACA100_37O9KGKWF' and mounted to /scratch.
I'm still having trouble reproducing the problem. I've followed the above exactly, and it doesn't trigger on my system. I think I know what is happening, but even given my theory, I'm still not able to trigger it. So, I'm not 100% sure this is the appropriate fix. If you can reproduce it, can you see if this patch, applied on top of the Linus's tip, fixes the problem for you?
- Ted
commit 3ad7621bfff343b16d59ed418f6d4420d4ec3e63 Author: Theodore Ts'o tytso@mit.edu Date: Tue May 21 17:01:01 2019 -0400
ext4: don't perform block validity checks on the journal inode
Since the journal inode is already checked when we added it to the block validity's system zone, if we check it again, we'll just trigger a failure.
This was causing failures like this:
[ 53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8 [ 53.938480] Aborting journal on device sda-8.
... but only if the system was under enough memory pressure that logical->physical mapping for the journal inode gets pushed out of the extent cache. (This is why it wasn't noticed earlier.)
Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Reported-by: Dan Rue dan.rue@linaro.org Signed-off-by: Theodore Ts'o tytso@mit.edu
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index f2c62e2a0c98..d40ed940001e 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -518,10 +518,14 @@ __read_extent_tree_block(const char *function, unsigned int line, } if (buffer_verified(bh) && !(flags & EXT4_EX_FORCE_CACHE)) return bh; - err = __ext4_ext_check(function, line, inode, - ext_block_hdr(bh), depth, pblk); - if (err) - goto errout; + if (!ext4_has_feature_journal(inode->i_sb) || + (inode->i_ino != + le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum))) { + err = __ext4_ext_check(function, line, inode, + ext_block_hdr(bh), depth, pblk); + if (err) + goto errout; + } set_buffer_verified(bh); /* * If this is a leaf block, cache all of its entries
On Wed, 22 May 2019 at 10:36, Theodore Ts'o tytso@mit.edu wrote:
On Tue, May 21, 2019 at 11:27:21PM +0530, Naresh Kamboju wrote:
Steps to reproduce is, running LTP three test cases in sequence on x86 device. # cd ltp/runtest # cat syscalls ( only three test case) open12 open12 madvise06 madvise06 poll02 poll02 #
as Dan referring to,
LTP is run using '/opt/ltp/runltp -d /scratch -f syscalls', where the syscalls file has been replaced with three test case names, and /scratch is an ext4 SATA drive. /scratch is created using 'mkfs -t ext4 /dev/disk/by-id/ata-TOSHIBA_MG03ACA100_37O9KGKWF' and mounted to /scratch.
I'm still having trouble reproducing the problem. I've followed the above exactly, and it doesn't trigger on my system. I think I know what is happening, but even given my theory, I'm still not able to trigger it. So, I'm not 100% sure this is the appropriate fix. If you can reproduce it, can you see if this patch, applied on top of the Linus's tip, fixes the problem for you?
Applied your patch on mainline master branch and tested on x86_64 and confirms that the reported problem fixed.
Thanks for your fix patch.
LTP syscalls full test output log, https://lkft.validation.linaro.org/scheduler/job/739075
--- Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Reported-by: Dan Rue dan.rue@linaro.org Signed-off-by: Theodore Ts'o tytso@mit.edu
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index f2c62e2a0c98..d40ed940001e 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -518,10 +518,14 @@ __read_extent_tree_block(const char *function, unsigned int line, } if (buffer_verified(bh) && !(flags & EXT4_EX_FORCE_CACHE)) return bh; - err = __ext4_ext_check(function, line, inode, - ext_block_hdr(bh), depth, pblk); - if (err) - goto errout; + if (!ext4_has_feature_journal(inode->i_sb) || + (inode->i_ino != + le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum))) { + err = __ext4_ext_check(function, line, inode, + ext_block_hdr(bh), depth, pblk); + if (err) + goto errout; + } set_buffer_verified(bh); /* * If this is a leaf block, cache all of its entries
- Naresh
On Tue, May 21, 2019 at 11:38:49AM +0200, Greg Kroah-Hartman wrote:
On Tue, May 21, 2019 at 02:58:58PM +0530, Naresh Kamboju wrote:
On Tue, 21 May 2019 at 14:30, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, May 20, 2019 at 05:23:42PM -0500, Dan Rue wrote:
On Mon, May 20, 2019 at 02:13:06PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. Anything received after that time might be too late.
We're seeing an ext4 issue previously reported at https://lore.kernel.org/lkml/20190514092054.GA6949@osiris.
[ 1916.032087] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 1916.073840] jbd2_journal_bmap: journal block not found at offset 4455 on sda-8 [ 1916.081071] Aborting journal on device sda-8. [ 1916.348652] EXT4-fs error (device sda): ext4_journal_check_start:61: Detected aborted journal [ 1916.357222] EXT4-fs (sda): Remounting filesystem read-only
This is seen on 4.19-rc, 5.0-rc, mainline, and next. We don't have data for 5.1-rc yet, which is presumably also affected in this RC round.
We only see this on x86_64 and i386 devices - though our hardware setups vary so it could be coincidence.
I have to run out now, but I'll come back and work on a reproducer and bisection later tonight and tomorrow.
Here is an example test run; link goes to the spot in the ltp syscalls test where the disk goes into read-only mode. https://lkft.validation.linaro.org/scheduler/job/735468#L8081
Odd, I keep hearing rumors of ext4 issues right now, but nothing actually solid that I can point to. Any help you can provide here would be great.
git bisect helped me to land on this commit,
# git bisect bad e8fd3c9a5415f9199e3fc5279e0f1dfcc0a80ab2 is the first bad commit commit e8fd3c9a5415f9199e3fc5279e0f1dfcc0a80ab2 Author: Theodore Ts'o tytso@mit.edu Date: Tue Apr 9 23:37:08 2019 -0400
ext4: protect journal inode's blocks using block_validity commit 345c0dbf3a30872d9b204db96b5857cd00808cae upstream. Add the blocks which belong to the journal inode to block_validity's system zone so attempts to deallocate or overwrite the journal due a corrupted file system where the journal blocks are also claimed by another inode. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202879 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>:040000 040000 b8b6ce2577d60c65021e5cc1c3a38b32e0cbb2ff 747c67b159b33e4e1da414b1d33567a5da9ae125 M fs
Ah, many thanks for this bisection.
Ted, any ideas here? Should I drop this from the stable trees, and you revert it from Linus's? Or something else?
Note, I do also have 170417c8c7bb ("ext4: fix block validity checks for journal inodes using indirect blocks") in the trees, which was supposed to fix the problem with this patch, am I missing another one as well?
(side note, it was mean not to mark 170417c8c7bb for stable, when the patch it was fixing was marked for stable, I'm lucky I caught it...)
My independent bisection agrees that e8fd3c9a5415 ("ext4: protect journal inode's blocks using block_validity") is the root cause. I was able to revert it along with 18b3c1c2827c ("ext4: unsigned int compared against zero") on 4.19 and then the issue went away.
I tested the same revert on mainline v5.2-rc1 and it fixed the issue there as well (git revert fbbbbd2f28ae 345c0dbf3a30).
The problem reproduces in our environment 100% of the time, but creating a reproducer is troublesome; it happens while running LTP syscalls, and requires some combination of syscall tests to happen. So far, we've been able to reduce it to the following ltp runfile: https://gist.github.com/danrue/61c663e1dc50dc7c13a232f0a062bdc6
LTP is run using '/opt/ltp/runltp -d /scratch -f syscalls', where the syscalls file has been replaced with the version in the gist, and /scratch is an ext4 SATA drive. /scratch is created using 'mkfs -t ext4 /dev/disk/by-id/ata-TOSHIBA_MG03ACA100_37O9KGKWF' and mounted to /scratch.
I'll update the gist as we reduce it further.
Dan
On 20/05/2019 13:13, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. 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.19.45-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.19.y and the diffstat can be found below.
thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.19: 12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 32 tests: 32 pass, 0 fail
Linux version: 4.19.45-rc1-g6b27ffd Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Cheers Jon
On 5/20/19 6:13 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. 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.19.45-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.19.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
On Mon, 20 May 2019 at 17:51, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.19.45 release. There are 105 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 22 May 2019 11:50:49 AM UTC. 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.19.45-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.19.y and the diffstat can be found below.
thanks,
greg k-h
4.19.45-rc2 report,
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Summary ------------------------------------------------------------------------
kernel: 4.19.45-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 84889965d346f29e8d1614f9c3cb35c389a40eec git describe: v4.19.44-103-g84889965d346 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.44-10...
No regressions (compared to build v4.19.44)
No fixes (compared to build v4.19.44)
Ran 21466 total tests in the following environments and test suites.
Environments -------------- - dragonboard-410c - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64
Test Suites ----------- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-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-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite
-
Dan Rue -
Greg Kroah-Hartman -
Jon Hunter -
kernelci.org bot -
Naresh Kamboju -
shuah -
Theodore Ts'o