April 2019 - Linux-stable-mirror

[PATCH] ext4: fix use-after-free race with debug_want_extra_isize

by Barret Rhoden

When remounting with debug_want_extra_isize, we were not performing the same checks that we do during a normal mount. That allowed us to set a value for s_want_extra_isize that reached outside the s_inode_size. Reported-by: syzbot+f584efa0ac7213c226b7(a)syzkaller.appspotmail.com Signed-off-by: Barret Rhoden <brho(a)google.com> Cc: stable(a)vger.kernel.org --- - In the current code, it looks like someone could mount with want_extra_isize with some value > 0 but less than the minimums in the s_es. If that's a bug, I can submit a follow-on patch. - Similarly, on a failed remount, sbi->s_want_extra_isize is changed to the remounted value. I can fix that too if it's a problem. - Is it OK to remount with a smaller s_want_extra_isize than the previous mount? I thought it was, but figured I'd ask while I'm looking at it. fs/ext4/super.c | 58 +++++++++++++++++++++++++++++-------------------- 1 file changed, 34 insertions(+), 24 deletions(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 6ed4eb81e674..184944d4d8d1 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3513,6 +3513,37 @@ int ext4_calculate_overhead(struct super_block *sb) return 0; } +static void ext4_clamp_want_extra_isize(struct super_block *sb) +{ + struct ext4_sb_info *sbi = EXT4_SB(sb); + struct ext4_super_block *es = sbi->s_es; + + /* determine the minimum size of new large inodes, if present */ + if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE && + sbi->s_want_extra_isize == 0) { + sbi->s_want_extra_isize = sizeof(struct ext4_inode) - + EXT4_GOOD_OLD_INODE_SIZE; + if (ext4_has_feature_extra_isize(sb)) { + if (sbi->s_want_extra_isize < + le16_to_cpu(es->s_want_extra_isize)) + sbi->s_want_extra_isize = + le16_to_cpu(es->s_want_extra_isize); + if (sbi->s_want_extra_isize < + le16_to_cpu(es->s_min_extra_isize)) + sbi->s_want_extra_isize = + le16_to_cpu(es->s_min_extra_isize); + } + } + /* Check if enough inode space is available */ + if (EXT4_GOOD_OLD_INODE_SIZE + sbi->s_want_extra_isize > + sbi->s_inode_size) { + sbi->s_want_extra_isize = sizeof(struct ext4_inode) - + EXT4_GOOD_OLD_INODE_SIZE; + ext4_msg(sb, KERN_INFO, + "required extra inode space not available"); + } +} + static void ext4_set_resv_clusters(struct super_block *sb) { ext4_fsblk_t resv_clusters; @@ -4387,30 +4418,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) } else if (ret) goto failed_mount4a; - /* determine the minimum size of new large inodes, if present */ - if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE && - sbi->s_want_extra_isize == 0) { - sbi->s_want_extra_isize = sizeof(struct ext4_inode) - - EXT4_GOOD_OLD_INODE_SIZE; - if (ext4_has_feature_extra_isize(sb)) { - if (sbi->s_want_extra_isize < - le16_to_cpu(es->s_want_extra_isize)) - sbi->s_want_extra_isize = - le16_to_cpu(es->s_want_extra_isize); - if (sbi->s_want_extra_isize < - le16_to_cpu(es->s_min_extra_isize)) - sbi->s_want_extra_isize = - le16_to_cpu(es->s_min_extra_isize); - } - } - /* Check if enough inode space is available */ - if (EXT4_GOOD_OLD_INODE_SIZE + sbi->s_want_extra_isize > - sbi->s_inode_size) { - sbi->s_want_extra_isize = sizeof(struct ext4_inode) - - EXT4_GOOD_OLD_INODE_SIZE; - ext4_msg(sb, KERN_INFO, "required extra inode space not" - "available"); - } + ext4_clamp_want_extra_isize(sb); ext4_set_resv_clusters(sb); @@ -5194,6 +5202,8 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data) goto restore_opts; } + ext4_clamp_want_extra_isize(sb); + if ((old_opts.s_mount_opt & EXT4_MOUNT_JOURNAL_CHECKSUM) ^ test_opt(sb, JOURNAL_CHECKSUM)) { ext4_msg(sb, KERN_ERR, "changing journal_checksum " -- 2.21.0.392.gf8f6787159e-goog

5 years, 5 months

4
4
0 0

stable-rc/linux-4.14.y boot: 110 boots: 0 failed, 98 passed with 12 offline (v4.14.113-73-g7c2e346c78ca)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 110 boots: 0 failed, 98 passed with 12 offline (v4.14.113-73-g7c2e346c78ca) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.113-7… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.113-73-g7c2e346c78ca Git Commit: 7c2e346c78ca2bab8ef936899f99801d754ccc83 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 64 unique boards, 24 SoC families, 14 builds out of 201 Offline Platforms: arm: davinci_all_defconfig: gcc-7 da850-lcdk: 1 offline lab imx_v6_v7_defconfig: gcc-7 vf610-colibri-eval-v3: 1 offline lab multi_v7_defconfig: gcc-7 meson8b-odroidc1: 1 offline lab tegra20-iris-512: 1 offline lab vf610-colibri-eval-v3: 1 offline lab tegra_defconfig: gcc-7 tegra20-iris-512: 1 offline lab arm64: defconfig: gcc-7 meson-gxbb-odroidc2: 1 offline lab meson-gxl-s905d-p230: 1 offline lab meson-gxl-s905x-nexbox-a95x: 1 offline lab meson-gxl-s905x-p212: 1 offline lab meson-gxm-nexbox-a1: 1 offline lab rk3399-firefly: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 5 months

1
0
0 0

patch "usb: dwc3: Allow building USB_DWC3_QCOM without EXTCON" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: Allow building USB_DWC3_QCOM without EXTCON to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 77a4946516fe488b6a33390de6d749f934a243ba Mon Sep 17 00:00:00 2001 From: Marc Gonzalez <marc.w.gonzalez(a)free.fr> Date: Wed, 24 Apr 2019 17:00:57 +0200 Subject: usb: dwc3: Allow building USB_DWC3_QCOM without EXTCON Keep EXTCON support optional, as some platforms do not need it. Do the same for USB_DWC3_OMAP while we're at it. Fixes: 3def4031b3e3f ("usb: dwc3: add EXTCON dependency for qcom") Signed-off-by: Marc Gonzalez <marc.w.gonzalez(a)free.fr> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/Kconfig | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 2b1494460d0c..784309435916 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -54,7 +54,8 @@ comment "Platform Glue Driver Support" config USB_DWC3_OMAP tristate "Texas Instruments OMAP5 and similar Platforms" - depends on EXTCON && (ARCH_OMAP2PLUS || COMPILE_TEST) + depends on ARCH_OMAP2PLUS || COMPILE_TEST + depends on EXTCON || !EXTCON depends on OF default USB_DWC3 help @@ -115,7 +116,8 @@ config USB_DWC3_ST config USB_DWC3_QCOM tristate "Qualcomm Platform" - depends on EXTCON && (ARCH_QCOM || COMPILE_TEST) + depends on ARCH_QCOM || COMPILE_TEST + depends on EXTCON || !EXTCON depends on OF default USB_DWC3 help -- 2.21.0

5 years, 5 months

1
0
0 0

patch "TTY: serial_core, add ->install" added to tty-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled TTY: serial_core, add ->install to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 4cdd17ba1dff20ffc99fdbd2e6f0201fc7fe67df Mon Sep 17 00:00:00 2001 From: Jiri Slaby <jslaby(a)suse.cz> Date: Wed, 17 Apr 2019 10:58:53 +0200 Subject: TTY: serial_core, add ->install We need to compute the uart state only on the first open. This is usually what is done in the ->install hook. serial_core used to do this in ->open on every open. So move it to ->install. As a side effect, it ensures the state is set properly in the window after tty_init_dev is called, but before uart_open. This fixes a bunch of races between tty_open and flush_to_ldisc we were dealing with recently. One of such bugs was attempted to fix in commit fedb5760648a (serial: fix race between flush_to_ldisc and tty_open), but it only took care of a couple of functions (uart_start and uart_unthrottle). I was able to reproduce the crash on a SLE system, but in uart_write_room which is also called from flush_to_ldisc via process_echoes. I was *unable* to reproduce the bug locally. It is due to having this patch in my queue since 2012! general protection fault: 0000 [#1] SMP KASAN PTI CPU: 1 PID: 5 Comm: kworker/u4:0 Tainted: G L 4.12.14-396-default #1 SLE15-SP1 (unreleased) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c89-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound flush_to_ldisc task: ffff8800427d8040 task.stack: ffff8800427f0000 RIP: 0010:uart_write_room+0xc4/0x590 RSP: 0018:ffff8800427f7088 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 000000000000002f RSI: 00000000000000ee RDI: ffff88003888bd90 RBP: ffffffffb9545850 R08: 0000000000000001 R09: 0000000000000400 R10: ffff8800427d825c R11: 000000000000006e R12: 1ffff100084fee12 R13: ffffc900004c5000 R14: ffff88003888bb28 R15: 0000000000000178 FS: 0000000000000000(0000) GS:ffff880043300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561da0794148 CR3: 000000000ebf4000 CR4: 00000000000006e0 Call Trace: tty_write_room+0x6d/0xc0 __process_echoes+0x55/0x870 n_tty_receive_buf_common+0x105e/0x26d0 tty_ldisc_receive_buf+0xb7/0x1c0 tty_port_default_receive_buf+0x107/0x180 flush_to_ldisc+0x35d/0x5c0 ... 0 in rbx means tty->driver_data is NULL in uart_write_room. 0x178 is tried to be dereferenced (0x178 >> 3 is 0x2f in rdx) at uart_write_room+0xc4. 0x178 is exactly (struct uart_state *)NULL->refcount used in uart_port_lock from uart_write_room. So revert the upstream commit here as my local patch should fix the whole family. Signed-off-by: Jiri Slaby <jslaby(a)suse.cz> Cc: Li RongQing <lirongqing(a)baidu.com> Cc: Wang Li <wangli39(a)baidu.com> Cc: Zhang Yu <zhangyu31(a)baidu.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/serial_core.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 69f48717546b..0decb0bf991d 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -130,9 +130,6 @@ static void uart_start(struct tty_struct *tty) struct uart_port *port; unsigned long flags; - if (!state) - return; - port = uart_port_lock(state, flags); __uart_start(tty); uart_port_unlock(port, flags); @@ -730,9 +727,6 @@ static void uart_unthrottle(struct tty_struct *tty) upstat_t mask = UPSTAT_SYNC_FIFO; struct uart_port *port; - if (!state) - return; - port = uart_port_ref(state); if (!port) return; @@ -1747,6 +1741,16 @@ static void uart_dtr_rts(struct tty_port *port, int raise) uart_port_deref(uport); } +static int uart_install(struct tty_driver *driver, struct tty_struct *tty) +{ + struct uart_driver *drv = driver->driver_state; + struct uart_state *state = drv->state + tty->index; + + tty->driver_data = state; + + return tty_standard_install(driver, tty); +} + /* * Calls to uart_open are serialised by the tty_lock in * drivers/tty/tty_io.c:tty_open() @@ -1759,11 +1763,8 @@ static void uart_dtr_rts(struct tty_port *port, int raise) */ static int uart_open(struct tty_struct *tty, struct file *filp) { - struct uart_driver *drv = tty->driver->driver_state; - int retval, line = tty->index; - struct uart_state *state = drv->state + line; - - tty->driver_data = state; + struct uart_state *state = tty->driver_data; + int retval; retval = tty_port_open(&state->port, tty, filp); if (retval > 0) @@ -2448,6 +2449,7 @@ static void uart_poll_put_char(struct tty_driver *driver, int line, char ch) #endif static const struct tty_operations uart_ops = { + .install = uart_install, .open = uart_open, .close = uart_close, .write = uart_write, -- 2.21.0

5 years, 5 months

1
0
0 0

stable-rc/linux-4.19.y boot: 112 boots: 0 failed, 102 passed with 10 offline (v4.19.36-99-gc60b2d434e04)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 112 boots: 0 failed, 102 passed with 10 offline (v4.19.36-99-gc60b2d434e04) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.36-99… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.36-99-gc60b2d434e04 Git Commit: c60b2d434e0425761d71b18a178b2c4141471e3e 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 Offline Platforms: arm: davinci_all_defconfig: gcc-7 da850-lcdk: 1 offline lab imx_v6_v7_defconfig: gcc-7 vf610-colibri-eval-v3: 1 offline lab multi_v7_defconfig: gcc-7 meson8b-odroidc1: 1 offline lab vf610-colibri-eval-v3: 1 offline lab arm64: defconfig: gcc-7 meson-gxbb-odroidc2: 1 offline lab meson-gxl-s905d-p230: 1 offline lab meson-gxl-s905x-nexbox-a95x: 1 offline lab meson-gxl-s905x-p212: 1 offline lab meson-gxm-nexbox-a1: 1 offline lab rk3399-firefly: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 5 months

1
0
0 0

stable-rc/linux-3.18.y boot: 47 boots: 1 failed, 44 passed with 2 offline (v3.18.138-105-g24b000f66a9d)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 47 boots: 1 failed, 44 passed with 2 offline (v3.18.138-105-g24b000f66a9d) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.138-1… Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.138-105-g24b000f66a9d Git Commit: 24b000f66a9d1038e8e353b274ab27e0e0d73fad Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 22 unique boards, 12 SoC families, 13 builds out of 189 Boot Failure Detected: x86_64: x86_64_defconfig: gcc-7: minnowboard-turbot-E3826: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-7 tegra20-iris-512: 1 offline lab tegra_defconfig: gcc-7 tegra20-iris-512: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 5 months

1
0
0 0

✅ PASS: Test report for kernel 5.0.10-rc2-35aa4a7.cki (stable)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: e428bc9cd366 - Linux 5.0.10-rc2 The results of these automated tests are provided below. Overall result: PASSED Compile: OK Tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/kernel-stable-aarch64-e428… kernel build: https://artifacts.cki-project.org/builds/aarch64/kernel-stable-aarch64-e428… ppc64le: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable-ppc64le-e428… kernel build: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable-ppc64le-e428… s390x: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/s390x/kernel-stable-s390x-e428bc9c… kernel build: https://artifacts.cki-project.org/builds/s390x/kernel-stable-s390x-e428bc9c… x86_64: build options: -j20 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/kernel-stable-x86_64-e428bc… kernel build: https://artifacts.cki-project.org/builds/x86_64/kernel-stable-x86_64-e428bc… Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: ✅ Boot test [0] ✅ LTP lite [1] ✅ Loopdev Sanity [2] ✅ Memory function: memfd_create [3] ✅ AMTU (Abstract Machine Test Utility) [4] ✅ Ethernet drivers sanity [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ redhat-rpm-config: detect-kabi-provides sanity [8] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [9] ✅ tuned: tune-processes-through-perf [10] ✅ Usex - version 1.9-29 [11] ✅ lvm thinp sanity [12] ✅ Boot test [0] ✅ xfstests: ext4 [13] ✅ xfstests: xfs [13] 🚧 ✅ Networking route: pmtu [14] 🚧 ✅ audit: audit testsuite test [15] 🚧 ✅ Storage blktests [16] 🚧 ✅ stress: stress-ng [17] ppc64le: ✅ Boot test [0] ✅ xfstests: ext4 [13] ✅ xfstests: xfs [13] ✅ Boot test [0] ✅ LTP lite [1] ✅ Loopdev Sanity [2] ✅ Memory function: memfd_create [3] ✅ AMTU (Abstract Machine Test Utility) [4] ✅ Ethernet drivers sanity [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ redhat-rpm-config: detect-kabi-provides sanity [8] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [9] ✅ tuned: tune-processes-through-perf [10] ✅ Usex - version 1.9-29 [11] ✅ lvm thinp sanity [12] 🚧 ✅ Networking route: pmtu [14] 🚧 ✅ audit: audit testsuite test [15] 🚧 ✅ selinux-policy: serge-testsuite [18] 🚧 ✅ Storage blktests [16] 🚧 ✅ stress: stress-ng [17] s390x: ✅ Boot test [0] ✅ LTP lite [1] ✅ Loopdev Sanity [2] ✅ Memory function: memfd_create [3] ✅ Ethernet drivers sanity [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ redhat-rpm-config: detect-kabi-provides sanity [8] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [9] ✅ tuned: tune-processes-through-perf [10] ✅ Usex - version 1.9-29 [11] ✅ lvm thinp sanity [12] ✅ Boot test [0] 🚧 ✅ Networking route: pmtu [14] 🚧 ✅ audit: audit testsuite test [15] 🚧 ✅ Storage blktests [16] 🚧 ✅ stress: stress-ng [17] 🚧 ❎ kdump: sysrq-c [19] x86_64: ✅ Boot test [0] ✅ Boot test [0] ✅ LTP lite [1] ✅ Loopdev Sanity [2] ✅ Memory function: memfd_create [3] ✅ AMTU (Abstract Machine Test Utility) [4] ✅ Ethernet drivers sanity [5] ✅ httpd: mod_ssl smoke sanity [6] ✅ iotop: sanity [7] ✅ redhat-rpm-config: detect-kabi-provides sanity [8] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [9] ✅ tuned: tune-processes-through-perf [10] ✅ Usex - version 1.9-29 [11] ✅ lvm thinp sanity [12] ✅ Boot test [0] ✅ xfstests: ext4 [13] ✅ xfstests: xfs [13] 🚧 ✅ kdump: sysrq-c [19] 🚧 ✅ Networking route: pmtu [14] 🚧 ✅ audit: audit testsuite test [15] 🚧 ✅ selinux-policy: serge-testsuite [18] 🚧 ✅ Storage blktests [16] 🚧 ✅ stress: stress-ng [17] Test source: [0]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [1]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [2]: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/memory/func… [4]: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu [5]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/iot… [8]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/red… [9]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/red… [10]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [11]: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… [12]: https://github.com/CKI-project/tests-beaker/archive/master.zip#storage/lvm/… [13]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… [14]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [15]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [16]: https://github.com/CKI-project/tests-beaker/archive/master.zip#storage/blk [17]: https://github.com/CKI-project/tests-beaker/archive/master.zip#stress/stres… [18]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/packages/se… [19]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/kdump/kdump… Waived tests (marked with 🚧) ----------------------------- This test run included waived tests. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed.

5 years, 5 months

1
0
0 0

stable-rc/linux-4.9.y boot: 95 boots: 0 failed, 86 passed with 9 offline (v4.9.170-47-gde1fb2f4bad0)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 95 boots: 0 failed, 86 passed with 9 offline (v4.9.170-47-gde1fb2f4bad0) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.170-47-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.170-47-gde1fb2f4bad0 Git Commit: de1fb2f4bad06405747cc22a63ca308266443939 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 51 unique boards, 22 SoC families, 15 builds out of 197 Offline Platforms: arm: davinci_all_defconfig: gcc-7 da850-lcdk: 1 offline lab imx_v6_v7_defconfig: gcc-7 vf610-colibri-eval-v3: 1 offline lab multi_v7_defconfig: gcc-7 bcm72521-bcm97252sffe: 1 offline lab bcm7445-bcm97445c: 1 offline lab meson8b-odroidc1: 1 offline lab tegra20-iris-512: 1 offline lab vf610-colibri-eval-v3: 1 offline lab tegra_defconfig: gcc-7 tegra20-iris-512: 1 offline lab arm64: defconfig: gcc-7 meson-gxbb-odroidc2: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 5 months

1
0
0 0

stable-rc/linux-4.4.y boot: 83 boots: 2 failed, 74 passed with 7 offline (v4.4.178-170-gc824a7e447d3)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 83 boots: 2 failed, 74 passed with 7 offline (v4.4.178-170-gc824a7e447d3) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.178-170… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.178-170-gc824a7e447d3 Git Commit: c824a7e447d39c4a7e9b5c436f0933b23e7e66b1 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 43 unique boards, 21 SoC families, 14 builds out of 190 Boot Failures Detected: arm: multi_v7_defconfig: gcc-7: stih410-b2120: 1 failed lab arm64: defconfig: gcc-7: qcom-qdf2400: 1 failed lab Offline Platforms: arm: imx_v6_v7_defconfig: gcc-7 vf610-colibri-eval-v3: 1 offline lab multi_v7_defconfig: gcc-7 bcm72521-bcm97252sffe: 1 offline lab bcm7445-bcm97445c: 1 offline lab meson8b-odroidc1: 1 offline lab tegra20-iris-512: 1 offline lab vf610-colibri-eval-v3: 1 offline lab tegra_defconfig: gcc-7 tegra20-iris-512: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 5 months

1
0
0 0

[PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

by Lyude Paul

On a very specific subset of ThinkPad P50 SKUs, particularly ones that come with a Quadro M1000M chip instead of the M2000M variant, the BIOS seems to have a very nasty habit of not always resetting the secondary Nvidia GPU between full reboots if the laptop is configured in Hybrid Graphics mode. The reason for this happening is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 2. Allow the nvidia GPU to runtime suspend itself after being idle 3. Reboot the machine, the more sudden the better (e.g sysrq-b may help) 4. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will quite literally be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad sideaffects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau 0000:01:00.0: disp: chid 0 mthd 0000 data 00000400 00001000 00000002 Later on, this causes us to timeout trying to bring up the GR ctx: ------------[ cut here ]------------ nouveau 0000:01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Modules linked in: nouveau mxm_wmi i915 crc32c_intel ttm i2c_algo_bit serio_raw drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops xhci_pci drm xhci_hcd i2c_core wmi video CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.0.0-rc5Lyude-Test+ #29 Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] RIP: 0010:gf100_grctx_generate+0x7b2/0x850 [nouveau] Code: 85 d2 75 04 48 8b 57 10 48 89 95 28 ff ff ff e8 b4 37 0e e1 48 8b 95 28 ff ff ff 48 c7 c7 b1 97 57 a0 48 89 c6 e8 5a 38 c0 e0 <0f> 0b e9 b9 fd ff ff 48 8b 85 60 ff ff ff 48 8b 40 10 48 8b 78 10 RSP: 0018:ffffc900000b77f0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888871af8000 RCX: 0000000000000000 RDX: ffff88887f41dfe0 RSI: ffff88887f415698 RDI: ffff88887f415698 RBP: ffffc900000b78c8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888872118000 R13: 0000000000000000 R14: ffffffffa0551420 R15: ffffc900000b7818 FS: 0000000000000000(0000) GS:ffff88887f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005644d0556ca8 CR3: 0000000002214006 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: gf100_gr_init_ctxctl+0x27b/0x2d0 [nouveau] gf100_gr_init+0x5bd/0x5e0 [nouveau] gf100_gr_init_+0x61/0x70 [nouveau] nvkm_gr_init+0x1d/0x20 [nouveau] nvkm_engine_init+0xcb/0x210 [nouveau] nvkm_subdev_init+0xd6/0x230 [nouveau] nvkm_engine_ref.part.0+0x52/0x70 [nouveau] nvkm_engine_ref+0x13/0x20 [nouveau] nvkm_ioctl_new+0x12c/0x260 [nouveau] ? nvkm_fifo_chan_child_del+0xa0/0xa0 [nouveau] ? gf100_gr_dtor+0xe0/0xe0 [nouveau] nvkm_ioctl+0xe2/0x180 [nouveau] nvkm_client_ioctl+0x12/0x20 [nouveau] nvif_object_ioctl+0x47/0x50 [nouveau] nvif_object_init+0xc8/0x120 [nouveau] nvc0_fbcon_accel_init+0x5c/0x960 [nouveau] nouveau_fbcon_create+0x5a5/0x5d0 [nouveau] ? drm_setup_crtcs+0x27b/0xcb0 [drm_kms_helper] ? __lock_is_held+0x5e/0xa0 __drm_fb_helper_initial_config_and_unlock+0x27c/0x520 [drm_kms_helper] drm_fb_helper_hotplug_event.part.29+0xae/0xc0 [drm_kms_helper] drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper] nouveau_fbcon_output_poll_changed+0xb8/0x110 [nouveau] drm_kms_helper_hotplug_event+0x2a/0x40 [drm_kms_helper] drm_dp_send_link_address+0x176/0x1c0 [drm_kms_helper] drm_dp_check_and_send_link_address+0xa0/0xb0 [drm_kms_helper] drm_dp_mst_link_probe_work+0xa4/0xc0 [drm_kms_helper] process_one_work+0x22f/0x5c0 worker_thread+0x44/0x3a0 kthread+0x12b/0x150 ? wq_pool_ids_show+0x140/0x140 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x3a/0x50 irq event stamp: 22490 hardirqs last enabled at (22489): [<ffffffff8113281d>] console_unlock+0x44d/0x5f0 hardirqs last disabled at (22490): [<ffffffff81001c03>] trace_hardirqs_off_thunk+0x1a/0x1c softirqs last enabled at (22486): [<ffffffff81c00330>] __do_softirq+0x330/0x44d softirqs last disabled at (22479): [<ffffffff810c3105>] irq_exit+0xe5/0xf0 WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] ---[ end trace bf0976ed88b122a8 ]--- nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: fifo: fault 01 [WRITE] at 0000000000008000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [0000000000 unknown] >From which the GPU never manages to recover. Booting without nouveau loading causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) … handlers: [<000000007faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 … serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus 0000:00:1f.4: Timeout waiting for interrupt! i801_smbus 0000:00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus 0000:00:1f.4: Timeout waiting for interrupt! i801_smbus 0000:00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! Which in turn causes the touchpad and sometimes even other things to get disabled. Since the GPU staying on causes problems even without nouveau's intervention, we can't fix this problem from nouveau itself. We have to fix it as early as possible in the boot sequence in order to make sure that the GPU is in a clean state before it has a chance to spam us with interrupts and break things. So to do this, we add a new pci quirk using DECLARE_PCI_FIXUP_CLASS_FINAL that will be invoked before the PCI probe at boot finishes. From there, we check to make sure that this is indeed the specific P50 variant of this GPU. We also make sure that the GPU PCI device is advertising NoReset- in order to prevent us from trying to reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Finally, we try mapping the MMIO space for the GPU which should only work if the GPU is actually active in D0 mode. We can then read the magic 0x2240c register on the GPU, which will have bit 1 set if the GPU's firmware has already been posted during a previous boot. Once we've confirmed all of this, we reset the PCI device and re-disable it - bringing the GPU back into a healthy state. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: nouveau(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Cc: Karol Herbst <kherbst(a)redhat.com> Cc: Ben Skeggs <skeggsb(a)gmail.com> Cc: stable(a)vger.kernel.org --- drivers/pci/quirks.c | 65 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index b0a413f3f7ca..948492fda8bf 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5117,3 +5117,68 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3 */ SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */ SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */ SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */ + +/* + * On certain Lenovo Thinkpad P50 SKUs, specifically those with a Nvidia + * Quadro M1000M, the BIOS will occasionally make the mistake of not resetting + * the nvidia GPU between reboots if the system is configured to use hybrid + * graphics mode. This results in the GPU being left in whatever state it was + * in during the previous boot which causes spurious interrupts from the GPU, + * which in turn cause us to disable the wrong IRQs and end up breaking the + * touchpad. Unsurprisingly, this also completely breaks nouveau. + * + * Luckily, it seems a simple reset of the PCI device for the nvidia GPU + * manages to bring the GPU back into a clean state and fix all of these + * issues. Additionally since the GPU will report NoReset+ when the machine is + * configured in Dedicated display mode, we don't need to worry about + * accidentally resetting the GPU when it's supposed to already be + * initialized. + */ +static void +quirk_lenovo_thinkpad_p50_nvgpu_survives_reboot(struct pci_dev *pdev) +{ + void __iomem *map; + int ret; + + if (pdev->subsystem_vendor != PCI_VENDOR_ID_LENOVO || + pdev->subsystem_device != 0x222e || + !pdev->reset_fn) + return; + + /* + * If we can't enable the device's mmio space, it's probably not even + * initialized. This is fine, and means we can just skip the quirk + * entirely. + */ + if (pci_enable_device_mem(pdev)) { + pci_dbg(pdev, "Can't enable device mem, no reset needed\n"); + return; + } + + /* Taken from drivers/gpu/drm/nouveau/engine/device/base.c */ + map = ioremap(pci_resource_start(pdev, 0), 0x102000); + if (!map) { + pci_err(pdev, "Can't map MMIO space, this is probably very bad\n"); + goto out_disable; + } + + /* + * Be extra careful, and make sure that the GPU firmware is posted + * before trying a reset + */ + if (ioread32(map + 0x2240c) & 0x2) { + pci_info(pdev, + FW_BUG "GPU left initialized by EFI, resetting\n"); + ret = pci_reset_function(pdev); + if (ret < 0) + pci_err(pdev, "Failed to reset GPU: %d\n", ret); + } + + iounmap(map); +out_disable: + pci_disable_device(pdev); +} + +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, 0x13b1, + PCI_CLASS_DISPLAY_VGA, 8, + quirk_lenovo_thinkpad_p50_nvgpu_survives_reboot); -- 2.20.1

5 years, 5 months

2
17
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2019