May 2019 - Linux-stable-mirror

by CKI Project

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: dafc674bbcb1 - Linux 4.19.44 The results of these automated tests are provided below. Overall result: PASSED Merge: OK 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 `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out the following commit: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: dafc674bbcb1 - Linux 4.19.44 We then merged the patchset with `git am`: locking-rwsem-prevent-decrement-of-reader-count-befo.patch Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: build options: -j25 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/kernel-stable_queue_4.19-a… kernel build: https://artifacts.cki-project.org/builds/aarch64/kernel-stable_queue_4.19-a… ppc64le: build options: -j25 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable_queue_4.19-p… kernel build: https://artifacts.cki-project.org/builds/ppc64le/kernel-stable_queue_4.19-p… s390x: build options: -j25 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/s390x/kernel-stable_queue_4.19-s39… kernel build: https://artifacts.cki-project.org/builds/s390x/kernel-stable_queue_4.19-s39… x86_64: build options: -j25 INSTALL_MOD_STRIP=1 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/kernel-stable_queue_4.19-x8… kernel build: https://artifacts.cki-project.org/builds/x86_64/kernel-stable_queue_4.19-x8… Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: ✅ Boot test [0] ✅ LTP lite [1] ✅ AMTU (Abstract Machine Test Utility) [2] ✅ audit: audit testsuite test [3] ✅ httpd: mod_ssl smoke sanity [4] ✅ iotop: sanity [5] ✅ tuned: tune-processes-through-perf [6] ✅ Usex - version 1.9-29 [7] ✅ stress: stress-ng [8] ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [9] ppc64le: ✅ Boot test [0] ✅ LTP lite [1] ✅ AMTU (Abstract Machine Test Utility) [2] ✅ audit: audit testsuite test [3] ✅ httpd: mod_ssl smoke sanity [4] ✅ iotop: sanity [5] ✅ tuned: tune-processes-through-perf [6] ✅ Usex - version 1.9-29 [7] ✅ stress: stress-ng [8] ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [9] s390x: ✅ Boot test [0] ✅ LTP lite [1] ✅ audit: audit testsuite test [3] ✅ httpd: mod_ssl smoke sanity [4] ✅ iotop: sanity [5] ✅ tuned: tune-processes-through-perf [6] ✅ Usex - version 1.9-29 [7] ✅ stress: stress-ng [8] ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [9] x86_64: ✅ Boot test [0] ✅ LTP lite [1] ✅ AMTU (Abstract Machine Test Utility) [2] ✅ audit: audit testsuite test [3] ✅ httpd: mod_ssl smoke sanity [4] ✅ iotop: sanity [5] ✅ tuned: tune-processes-through-perf [6] ✅ Usex - version 1.9-29 [7] ✅ stress: stress-ng [8] ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [9] 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#misc/amtu [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [4]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [5]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/iot… [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… [8]: https://github.com/CKI-project/tests-beaker/archive/master.zip#stress/stres… [9]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/packages/se…

5 years, 9 months

1
0
0 0

Re: [PATCH v3] lkdtm: support llvm-objcopy

by Nathan Chancellor

On Fri, May 17, 2019 at 12:10:02AM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all Nick, the stable tag should probably specify 4.8+ since the commit it fixes came in during 4.8-rc1. Cc: stable(a)vger.kernel.org # 4.8+ Might also help to add: Fixes: 9a49a528dcf3 ("lkdtm: add function for testing .rodata section") > > The bot has tested the following trees: v5.1.2, v5.0.16, v4.19.43, v4.14.119, v4.9.176, v4.4.179, v3.18.140. > > v5.1.2: Build OK! > v5.0.16: Build OK! > v4.19.43: Build OK! > v4.14.119: Failed to apply! Possible dependencies: > 039a1c42058d ("lkdtm: Relocate code to subdirectory") However, it will still need a manual backport because of the lack of this commit. I've attached the current patch backported for reference, the git am flags '-3 -p4 --directory=drivers/misc' help get it proper then the conflict is rather easy to resolve. Thanks, Nathan

5 years, 9 months

1
1
0 0

stable-rc/linux-4.14.y boot: 122 boots: 1 failed, 116 passed with 3 offline, 1 untried/unknown, 1 conflict (v4.14.120)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 122 boots: 1 failed, 116 passed with 3 offline, 1 untried/unknown, 1 conflict (v4.14.120) 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.120/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.120 Git Commit: e6fedb8802c7543852cc6b06d8c009f89b3af3d8 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 61 unique boards, 22 SoC families, 14 builds out of 201 Boot Regressions Detected: arm: multi_v7_defconfig: gcc-8: omap4-panda: lab-baylibre: new failure (last pass: v4.14.119) Boot Failure Detected: arm64: defconfig: gcc-8: rk3399-firefly: 1 failed lab Offline Platforms: arm: tegra_defconfig: gcc-8 tegra20-iris-512: 1 offline lab multi_v7_defconfig: gcc-8 stih410-b2120: 1 offline lab tegra20-iris-512: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: multi_v7_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 9 months

1
0
0 0

stable-rc/linux-5.0.y boot: 133 boots: 0 failed, 130 passed with 1 offline, 1 untried/unknown, 1 conflict (v5.0.17)

by kernelci.org bot

stable-rc/linux-5.0.y boot: 133 boots: 0 failed, 130 passed with 1 offline, 1 untried/unknown, 1 conflict (v5.0.17) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.0.y/kernel/v5.0.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.0.y/kernel/v5.0.17/ Tree: stable-rc Branch: linux-5.0.y Git Describe: v5.0.17 Git Commit: d59f5a01fa438635ae098b2e170a18644df73c06 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 71 unique boards, 22 SoC families, 14 builds out of 208 Boot Regressions Detected: arm: multi_v7_defconfig: gcc-8: omap4-panda: lab-baylibre: new failure (last pass: v5.0.16) 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: multi_v7_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 9 months

1
0
0 0

stable-rc/linux-4.19.y boot: 125 boots: 0 failed, 123 passed with 1 offline, 1 conflict (v4.19.44)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 125 boots: 0 failed, 123 passed with 1 offline, 1 conflict (v4.19.44) 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.44/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.44 Git Commit: dafc674bbcb11c6a5c63b75be5873b118e2add17 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 65 unique boards, 22 SoC families, 14 builds out of 206 Boot Regressions Detected: arm: omap2plus_defconfig: gcc-8: omap4-panda: lab-baylibre: new failure (last pass: v4.19.43-114-gb5001f5eab58) 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(a)kernelci.org>

5 years, 9 months

1
0
0 0

Re: [PATCH 3/4] ima: don't ignore INTEGRITY_UNKNOWN EVM status

by Mimi Zohar

On Fri, 2019-05-17 at 00:10 +0000, Sasha Levin wrote: > > How should we proceed with this patch? Yikes! This was posted earlier today. I haven't even had a chance to look at it yet. Similarly for "[PATCH 4/4] ima: only audit failed appraisal verifications". Mimi

5 years, 9 months

2
1
0 0

stable-rc/linux-4.9.y boot: 109 boots: 0 failed, 104 passed with 3 offline, 1 untried/unknown, 1 conflict (v4.9.177)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 109 boots: 0 failed, 104 passed with 3 offline, 1 untried/unknown, 1 conflict (v4.9.177) 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.177/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.177 Git Commit: 8baec4ebdf084961516f17cadbad14cac082ee4e 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 Boot Regressions Detected: arm: multi_v7_defconfig: gcc-8: omap4-panda: lab-baylibre: new failure (last pass: v4.9.176-52-g2647f24152a7) Offline Platforms: arm: tegra_defconfig: gcc-8 tegra20-iris-512: 1 offline lab multi_v7_defconfig: gcc-8 stih410-b2120: 1 offline lab tegra20-iris-512: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: multi_v7_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 9 months

1
0
0 0

FAILED: patch "[PATCH] PCI: hv: Fix a memory leak in hv_eject_device_work()" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 05f151a73ec2b23ffbff706e5203e729a995cdc2 Mon Sep 17 00:00:00 2001 From: Dexuan Cui <decui(a)microsoft.com> Date: Mon, 4 Mar 2019 21:34:48 +0000 Subject: [PATCH] PCI: hv: Fix a memory leak in hv_eject_device_work() When a device is created in new_pcichild_device(), hpdev->refs is set to 2 (i.e. the initial value of 1 plus the get_pcichild()). When we hot remove the device from the host, in a Linux VM we first call hv_pci_eject_device(), which increases hpdev->refs by get_pcichild() and then schedules a work of hv_eject_device_work(), so hpdev->refs becomes 3 (let's ignore the paired get/put_pcichild() in other places). But in hv_eject_device_work(), currently we only call put_pcichild() twice, meaning the 'hpdev' struct can't be freed in put_pcichild(). Add one put_pcichild() to fix the memory leak. The device can also be removed when we run "rmmod pci-hyperv". On this path (hv_pci_remove() -> hv_pci_bus_exit() -> hv_pci_devices_present()), hpdev->refs is 2, and we do correctly call put_pcichild() twice in pci_devices_present_work(). Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Signed-off-by: Dexuan Cui <decui(a)microsoft.com> [lorenzo.pieralisi(a)arm.com: commit log rework] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Reviewed-by: Stephen Hemminger <stephen(a)networkplumber.org> Reviewed-by: Michael Kelley <mikelley(a)microsoft.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index 95441a35eceb..30f16b882746 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -1900,6 +1900,9 @@ static void hv_eject_device_work(struct work_struct *work) sizeof(*ejct_pkt), (unsigned long)&ctxt.pkt, VM_PKT_DATA_INBAND, 0); + /* For the get_pcichild() in hv_pci_eject_device() */ + put_pcichild(hpdev); + /* For the two refs got in new_pcichild_device() */ put_pcichild(hpdev); put_pcichild(hpdev); put_hvpcibus(hpdev->hbus);

5 years, 9 months

3
3
0 0

FAILED: patch "[PATCH] PCI: hv: Add pci_destroy_slot() in" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 340d455699400f2c2c0f9b3f703ade3085cdb501 Mon Sep 17 00:00:00 2001 From: Dexuan Cui <decui(a)microsoft.com> Date: Mon, 4 Mar 2019 21:34:49 +0000 Subject: [PATCH] PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary When we hot-remove a device, usually the host sends us a PCI_EJECT message, and a PCI_BUS_RELATIONS message with bus_rel->device_count == 0. When we execute the quick hot-add/hot-remove test, the host may not send us the PCI_EJECT message if the guest has not fully finished the initialization by sending the PCI_RESOURCES_ASSIGNED* message to the host, so it's potentially unsafe to only depend on the pci_destroy_slot() in hv_eject_device_work() because the code path create_root_hv_pci_bus() -> hv_pci_assign_slots() is not called in this case. Note: in this case, the host still sends the guest a PCI_BUS_RELATIONS message with bus_rel->device_count == 0. In the quick hot-add/hot-remove test, we can have such a race before the code path pci_devices_present_work() -> new_pcichild_device() adds the new device into the hbus->children list, we may have already received the PCI_EJECT message, and since the tasklet handler hv_pci_onchannelcallback() may fail to find the "hpdev" by calling get_pcichild_wslot(hbus, dev_message->wslot.slot) hv_pci_eject_device() is not called; Later, by continuing execution create_root_hv_pci_bus() -> hv_pci_assign_slots() creates the slot and the PCI_BUS_RELATIONS message with bus_rel->device_count == 0 removes the device from hbus->children, and we end up being unable to remove the slot in hv_pci_remove() -> hv_pci_remove_slots() Remove the slot in pci_devices_present_work() when the device is removed to address this race. pci_devices_present_work() and hv_eject_device_work() run in the singled-threaded hbus->wq, so there is not a double-remove issue for the slot. We cannot offload hv_pci_eject_device() from hv_pci_onchannelcallback() to the workqueue, because we need the hv_pci_onchannelcallback() synchronously call hv_pci_eject_device() to poll the channel ringbuffer to work around the "hangs in hv_compose_msi_msg()" issue fixed in commit de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()") Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information") Signed-off-by: Dexuan Cui <decui(a)microsoft.com> [lorenzo.pieralisi(a)arm.com: rewritten commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Reviewed-by: Stephen Hemminger <stephen(a)networkplumber.org> Reviewed-by: Michael Kelley <mikelley(a)microsoft.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index b489412e3502..82acd6155adf 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -1776,6 +1776,10 @@ static void pci_devices_present_work(struct work_struct *work) hpdev = list_first_entry(&removed, struct hv_pci_dev, list_entry); list_del(&hpdev->list_entry); + + if (hpdev->pci_slot) + pci_destroy_slot(hpdev->pci_slot); + put_pcichild(hpdev); }

5 years, 9 months

3
2
0 0

FAILED: patch "[PATCH] PCI: hv: Add hv_pci_remove_slots() when we unload the driver" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 15becc2b56c6eda3d9bf5ae993bafd5661c1fad1 Mon Sep 17 00:00:00 2001 From: Dexuan Cui <decui(a)microsoft.com> Date: Mon, 4 Mar 2019 21:34:48 +0000 Subject: [PATCH] PCI: hv: Add hv_pci_remove_slots() when we unload the driver When we unload the pci-hyperv host controller driver, the host does not send us a PCI_EJECT message. In this case we also need to make sure the sysfs PCI slot directory is removed, otherwise a command on a slot file eg: "cat /sys/bus/pci/slots/2/address" will trigger a "BUG: unable to handle kernel paging request" and, if we unload/reload the driver several times we would end up with stale slot entries in PCI slot directories in /sys/bus/pci/slots/ root@localhost:~# ls -rtl /sys/bus/pci/slots/ total 0 drwxr-xr-x 2 root root 0 Feb 7 10:49 2 drwxr-xr-x 2 root root 0 Feb 7 10:49 2-1 drwxr-xr-x 2 root root 0 Feb 7 10:51 2-2 Add the missing code to remove the PCI slot and fix the current behaviour. Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information") Signed-off-by: Dexuan Cui <decui(a)microsoft.com> [lorenzo.pieralisi(a)arm.com: reformatted the log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Reviewed-by: Stephen Hemminger <sthemmin(a)microsoft.com> Reviewed-by: Michael Kelley <mikelley(a)microsoft.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index 30f16b882746..b489412e3502 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -1486,6 +1486,21 @@ static void hv_pci_assign_slots(struct hv_pcibus_device *hbus) } } +/* + * Remove entries in sysfs pci slot directory. + */ +static void hv_pci_remove_slots(struct hv_pcibus_device *hbus) +{ + struct hv_pci_dev *hpdev; + + list_for_each_entry(hpdev, &hbus->children, list_entry) { + if (!hpdev->pci_slot) + continue; + pci_destroy_slot(hpdev->pci_slot); + hpdev->pci_slot = NULL; + } +} + /** * create_root_hv_pci_bus() - Expose a new root PCI bus * @hbus: Root PCI bus, as understood by this driver @@ -2680,6 +2695,7 @@ static int hv_pci_remove(struct hv_device *hdev) pci_lock_rescan_remove(); pci_stop_root_bus(hbus->pci_bus); pci_remove_root_bus(hbus->pci_bus); + hv_pci_remove_slots(hbus); pci_unlock_rescan_remove(); hbus->state = hv_pcibus_removed; }

5 years, 9 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2019