From 5bc585d35dea71a6e0c8252e59427ec03f870bcb Mon Sep 17 00:00:00 2001 From: Justin M. Forbes Date: Mar 18 2020 14:01:37 +0000 Subject: Linux v5.5.10 --- diff --git a/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch b/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch deleted file mode 100644 index 873509e..0000000 --- a/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch +++ /dev/null @@ -1,136 +0,0 @@ -From e3a36eb6dfaeea8175c05d5915dcf0b939be6dab Mon Sep 17 00:00:00 2001 -From: Christoph Hellwig -Date: Wed, 11 Mar 2020 17:07:10 +0100 -Subject: [PATCH] driver code: clarify and fix platform device DMA mask - allocation - -This does three inter-related things to clarify the usage of the -platform device dma_mask field. In the process, fix the bug introduced -by cdfee5623290 ("driver core: initialize a default DMA mask for -platform device") that caused Artem Tashkinov's laptop to not boot with -newer Fedora kernels. - -This does: - - - First off, rename the field to "platform_dma_mask" to make it - greppable. - - We have way too many different random fields called "dma_mask" in - various data structures, where some of them are actual masks, and - some of them are just pointers to the mask. And the structures all - have pointers to each other, or embed each other inside themselves, - and "pdev" sometimes means "platform device" and sometimes it means - "PCI device". - - So to make it clear in the code when you actually use this new field, - give it a unique name (it really should be something even more unique - like "platform_device_dma_mask", since it's per platform device, not - per platform, but that gets old really fast, and this is unique - enough in context). - - To further clarify when the field gets used, initialize it when we - actually start using it with the default value. - - - Then, use this field instead of the random one-off allocation in - platform_device_register_full() that is now unnecessary since we now - already have a perfectly fine allocation for it in the platform - device structure. - - - The above then allows us to fix the actual bug, where the error path - of platform_device_register_full() would unconditionally free the - platform device DMA allocation with 'kfree()'. - - That kfree() was dont regardless of whether the allocation had been - done earlier with the (now removed) kmalloc, or whether - setup_pdev_dma_masks() had already been used and the dma_mask pointer - pointed to the mask that was part of the platform device. - -It seems most people never triggered the error path, or only triggered -it from a call chain that set an explicit pdevinfo->dma_mask value (and -thus caused the unnecessary allocation that was "cleaned up" in the -error path) before calling platform_device_register_full(). - -Robin Murphy points out that in Artem's case the wdat_wdt driver failed -in platform_device_add(), and that was the one that had called -platform_device_register_full() with pdevinfo.dma_mask = 0, and would -have caused that kfree() of pdev.dma_mask corrupting the heap. - -A later unrelated kmalloc() then oopsed due to the heap corruption. - -Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device") -Reported-bisected-and-tested-by: Artem S. Tashkinov -Reviewed-by: Robin Murphy -Cc: Greg Kroah-Hartman -Signed-off-by: Christoph Hellwig -Signed-off-by: Linus Torvalds ---- - drivers/base/platform.c | 25 ++++++------------------- - include/linux/platform_device.h | 2 +- - 2 files changed, 7 insertions(+), 20 deletions(-) - -diff --git a/drivers/base/platform.c b/drivers/base/platform.c -index 7fa654f1288b..b5ce7b085795 100644 ---- a/drivers/base/platform.c -+++ b/drivers/base/platform.c -@@ -363,10 +363,10 @@ static void setup_pdev_dma_masks(struct platform_device *pdev) - { - if (!pdev->dev.coherent_dma_mask) - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); -- if (!pdev->dma_mask) -- pdev->dma_mask = DMA_BIT_MASK(32); -- if (!pdev->dev.dma_mask) -- pdev->dev.dma_mask = &pdev->dma_mask; -+ if (!pdev->dev.dma_mask) { -+ pdev->platform_dma_mask = DMA_BIT_MASK(32); -+ pdev->dev.dma_mask = &pdev->platform_dma_mask; -+ } - }; - - /** -@@ -662,20 +662,8 @@ struct platform_device *platform_device_register_full( - pdev->dev.of_node_reused = pdevinfo->of_node_reused; - - if (pdevinfo->dma_mask) { -- /* -- * This memory isn't freed when the device is put, -- * I don't have a nice idea for that though. Conceptually -- * dma_mask in struct device should not be a pointer. -- * See http://thread.gmane.org/gmane.linux.kernel.pci/9081 -- */ -- pdev->dev.dma_mask = -- kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL); -- if (!pdev->dev.dma_mask) -- goto err; -- -- kmemleak_ignore(pdev->dev.dma_mask); -- -- *pdev->dev.dma_mask = pdevinfo->dma_mask; -+ pdev->platform_dma_mask = pdevinfo->dma_mask; -+ pdev->dev.dma_mask = &pdev->platform_dma_mask; - pdev->dev.coherent_dma_mask = pdevinfo->dma_mask; - } - -@@ -700,7 +688,6 @@ struct platform_device *platform_device_register_full( - if (ret) { - err: - ACPI_COMPANION_SET(&pdev->dev, NULL); -- kfree(pdev->dev.dma_mask); - platform_device_put(pdev); - return ERR_PTR(ret); - } -diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h -index 276a03c24691..041bfa412aa0 100644 ---- a/include/linux/platform_device.h -+++ b/include/linux/platform_device.h -@@ -24,7 +24,7 @@ struct platform_device { - int id; - bool id_auto; - struct device dev; -- u64 dma_mask; -+ u64 platform_dma_mask; - u32 num_resources; - struct resource *resource; - --- -2.25.1 - diff --git a/iommu-WARN_TAINT-fixes.patch b/iommu-WARN_TAINT-fixes.patch deleted file mode 100644 index 34668f9..0000000 --- a/iommu-WARN_TAINT-fixes.patch +++ /dev/null @@ -1,164 +0,0 @@ -From 2f2265a8cbc6b43deb169c525204ea7df02e9363 Mon Sep 17 00:00:00 2001 -From: Hans de Goede -Date: Mon, 9 Mar 2020 13:55:02 +0100 -Subject: [PATCH 1/2] iommu/vt-d: dmar: replace WARN_TAINT with pr_warn + - add_taint - -Quoting from the comment describing the WARN functions in -include/asm-generic/bug.h: - - * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report - * significant kernel issues that need prompt attention if they should ever - * appear at runtime. - * - * Do not use these macros when checking for invalid external inputs - -The (buggy) firmware tables which the dmar code was calling WARN_TAINT -for really are invalid external inputs. They are not under the kernel's -control and the issues in them cannot be fixed by a kernel update. -So logging a backtrace, which invites bug reports to be filed about this, -is not helpful. - -Some distros, e.g. Fedora, have tools watching for the kernel backtraces -logged by the WARN macros and offer the user an option to file a bug for -this when these are encountered. The WARN_TAINT in warn_invalid_dmar() -+ another iommu WARN_TAINT, addressed in another patch, have lead to over -a 100 bugs being filed this way. - -This commit replaces the WARN_TAINT("...") calls, with -pr_warn(FW_BUG "...") + add_taint(TAINT_FIRMWARE_WORKAROUND, ...) calls -avoiding the backtrace and thus also avoiding bug-reports being filed -about this against the kernel. - -BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1564895 -Fixes: e625b4a95d50 ("iommu/vt-d: Parse ANDD records") -Fixes: fd0c8894893c ("intel-iommu: Set a more specific taint flag for invalid BI -Cc: stable@vger.kernel.org -Signed-off-by: Hans de Goede ---- - drivers/iommu/dmar.c | 11 ++++++----- - 1 file changed, 6 insertions(+), 5 deletions(-) - -diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c -index 071bb42bbbc5..87194a46cb0b 100644 ---- a/drivers/iommu/dmar.c -+++ b/drivers/iommu/dmar.c -@@ -440,12 +440,13 @@ static int __init dmar_parse_one_andd(struct acpi_dmar_header *header, - - /* Check for NUL termination within the designated length */ - if (strnlen(andd->device_name, header->length - 8) == header->length - 8) { -- WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND, -+ pr_warn(FW_BUG - "Your BIOS is broken; ANDD object name is not NUL-terminated\n" - "BIOS vendor: %s; Ver: %s; Product Version: %s\n", - dmi_get_system_info(DMI_BIOS_VENDOR), - dmi_get_system_info(DMI_BIOS_VERSION), - dmi_get_system_info(DMI_PRODUCT_VERSION)); -+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); - return -EINVAL; - } - pr_info("ANDD device: %x name: %s\n", andd->device_number, -@@ -471,14 +472,14 @@ static int dmar_parse_one_rhsa(struct acpi_dmar_header *header, void *arg) - return 0; - } - } -- WARN_TAINT( -- 1, TAINT_FIRMWARE_WORKAROUND, -+ pr_warn(FW_BUG - "Your BIOS is broken; RHSA refers to non-existent DMAR unit at %llx\n" - "BIOS vendor: %s; Ver: %s; Product Version: %s\n", - drhd->reg_base_addr, - dmi_get_system_info(DMI_BIOS_VENDOR), - dmi_get_system_info(DMI_BIOS_VERSION), - dmi_get_system_info(DMI_PRODUCT_VERSION)); -+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); - - return 0; - } -@@ -827,14 +828,14 @@ int __init dmar_table_init(void) - - static void warn_invalid_dmar(u64 addr, const char *message) - { -- WARN_TAINT_ONCE( -- 1, TAINT_FIRMWARE_WORKAROUND, -+ pr_warn_once(FW_BUG - "Your BIOS is broken; DMAR reported at address %llx%s!\n" - "BIOS vendor: %s; Ver: %s; Product Version: %s\n", - addr, message, - dmi_get_system_info(DMI_BIOS_VENDOR), - dmi_get_system_info(DMI_BIOS_VERSION), - dmi_get_system_info(DMI_PRODUCT_VERSION)); -+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); - } - - static int __ref --- -2.25.1 - -From 038ebd8952c5fb3ba3b5e09b0b55a4e617ae22bf Mon Sep 17 00:00:00 2001 -From: Hans de Goede -Date: Mon, 9 Mar 2020 14:12:37 +0100 -Subject: [PATCH 2/2] iommu/vt-d: dmar_parse_one_rmrr: replace WARN_TAINT with - pr_warn + add_taint - -Quoting from the comment describing the WARN functions in -include/asm-generic/bug.h: - - * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report - * significant kernel issues that need prompt attention if they should ever - * appear at runtime. - * - * Do not use these macros when checking for invalid external inputs - -The (buggy) firmware tables which the dmar code was calling WARN_TAINT -for really are invalid external inputs. They are not under the kernel's -control and the issues in them cannot be fixed by a kernel update. -So logging a backtrace, which invites bug reports to be filed about this, -is not helpful. - -Some distros, e.g. Fedora, have tools watching for the kernel backtraces -logged by the WARN macros and offer the user an option to file a bug for -this when these are encountered. The WARN_TAINT in dmar_parse_one_rmrr -+ another iommu WARN_TAINT, addressed in another patch, have lead to over -a 100 bugs being filed this way. - -This commit replaces the WARN_TAINT("...") call, with a -pr_warn(FW_BUG "...") + add_taint(TAINT_FIRMWARE_WORKAROUND, ...) call -avoiding the backtrace and thus also avoiding bug-reports being filed -about this against the kernel. - -BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1808874 -Fixes: f5a68bb0752e ("iommu/vt-d: Mark firmware tainted if RMRR fails sanity check") -Cc: Barret Rhoden -Cc: stable@vger.kernel.org -Signed-off-by: Hans de Goede ---- - drivers/iommu/intel-iommu.c | 6 ++++-- - 1 file changed, 4 insertions(+), 2 deletions(-) - -diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c -index 6fa6de2b6ad5..3857a5cd1a75 100644 ---- a/drivers/iommu/intel-iommu.c -+++ b/drivers/iommu/intel-iommu.c -@@ -4460,14 +4460,16 @@ int __init dmar_parse_one_rmrr(struct acpi_dmar_header *header, void *arg) - struct dmar_rmrr_unit *rmrru; - - rmrr = (struct acpi_dmar_reserved_memory *)header; -- if (arch_rmrr_sanity_check(rmrr)) -- WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND, -+ if (arch_rmrr_sanity_check(rmrr)) { -+ pr_warn(FW_BUG - "Your BIOS is broken; bad RMRR [%#018Lx-%#018Lx]\n" - "BIOS vendor: %s; Ver: %s; Product Version: %s\n", - rmrr->base_address, rmrr->end_address, - dmi_get_system_info(DMI_BIOS_VENDOR), - dmi_get_system_info(DMI_BIOS_VERSION), - dmi_get_system_info(DMI_PRODUCT_VERSION)); -+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); -+ } - - rmrru = kzalloc(sizeof(*rmrru), GFP_KERNEL); - if (!rmrru) --- -2.25.1 - diff --git a/kernel.spec b/kernel.spec index 14cf131..9b80143 100644 --- a/kernel.spec +++ b/kernel.spec @@ -89,7 +89,7 @@ Summary: The Linux kernel %if 0%{?released_kernel} # Do we have a -stable update to apply? -%define stable_update 9 +%define stable_update 10 # Set rpm version accordingly %if 0%{?stable_update} %define stablerev %{stable_update} @@ -864,16 +864,6 @@ Patch508: 20200310_chris_chris_wilson_co_uk.patch # Backport vboxsf from 5.6, can be dropped when we move to 5.6 Patch510: 0001-fs-Add-VirtualBox-guest-shared-folder-vboxsf-support.patch -# rhbz 1800335 -Patch511: v2_20200128_dmoulding_me_com.patch - -# Fix backtraces triggered by warnings about buggy BIOS (rhbz 1564895, 1808874) -# Submitted upstream -Patch512: iommu-WARN_TAINT-fixes.patch - -# Fix some HP x360 models not booting (rhbz 1790115) (in mainline now) -Patch513: 0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch - # Fix UCSI oopses, (rhbz 1785972) (in gkh's usb-linus, heading towards mainline) Patch514: ucsi-oops-fixes.patch @@ -2906,6 +2896,9 @@ fi # # %changelog +* Wed Mar 18 2020 Justin M. Forbes - 5.5.10-200 +- Linux v5.5.10 + * Sat Mar 14 2020 Hans de Goede - Fix UCSI oopses (rhbz 1785972) diff --git a/sources b/sources index 4d3dad4..dcd889c 100644 --- a/sources +++ b/sources @@ -1,3 +1,2 @@ SHA512 (linux-5.5.tar.xz) = fa74fdabb5e63384a39e54da05b86a9ae9ea16179524b041fbbdffc7177e80b53600ae98d76be127ba216148f9dc55fe07ab20637e22c6d6030cb4aa09eb2f86 -SHA512 (patch-5.5.8.xz) = 8daaea68d2eaa51966bae5de14c253daf6ae6dd65cf0541e2f94459df99031d3d4355f436d182b2b9cea5fbfee3c053ac2bc91030dfa23a9f4575996528fd508 -SHA512 (patch-5.5.9.xz) = 44f26e7bce86c149fb4ddae20306ae58dead5a4797c268409f12284c695de80bde4a1b8bb1492f51db0f36210543d4a277024481e43acda10c3bb03470bf5270 +SHA512 (patch-5.5.10.xz) = 7b83ce898dfab2fe67c8c931890470615b181b2b64b686103c0776a95f302cbca5f4b4e576dbde28af1408692ec6e7c18fb23dbec8f6255e935a137fc0b055d8 diff --git a/v2_20200128_dmoulding_me_com.patch b/v2_20200128_dmoulding_me_com.patch deleted file mode 100644 index 2cb28be..0000000 --- a/v2_20200128_dmoulding_me_com.patch +++ /dev/null @@ -1,51 +0,0 @@ -From MAILER-DAEMON Mon Feb 24 19:54:49 2020 -From: Dan Moulding -To: linux-wireless@vger.kernel.org -Cc: johannes.berg@intel.com, emmanuel.grumbach@intel.com, luciano.coelho@intel.com, linuxwifi@intel.com, Dan Moulding -Subject: [PATCH v2 5.5] iwlwifi: mvm: Do not require PHY_SKU NVM section for 3168 devices -Date: Tue, 28 Jan 2020 02:31:07 -0700 -Message-Id: <20200128093107.9740-1-dmoulding@me.com> -Sender: linux-wireless-owner@vger.kernel.org -List-ID: -X-Mailing-List: linux-wireless@vger.kernel.org -MIME-Version: 1.0 -Content-Type: text/plain; charset="utf-8" -Content-Transfer-Encoding: 7bit - -The logic for checking required NVM sections was recently fixed in -commit b3f20e098293 ("iwlwifi: mvm: fix NVM check for 3168 -devices"). However, with that fixed the else is now taken for 3168 -devices and within the else clause there is a mandatory check for the -PHY_SKU section. This causes the parsing to fail for 3168 devices. - -The PHY_SKU section is really only mandatory for the IWL_NVM_EXT -layout (the phy_sku parameter of iwl_parse_nvm_data is only used when -the NVM type is IWL_NVM_EXT). So this changes the PHY_SKU section -check so that it's only mandatory for IWL_NVM_EXT. - -Fixes: b3f20e098293 ("iwlwifi: mvm: fix NVM check for 3168 devices") -Signed-off-by: Dan Moulding ---- -v2: Fixed incorrect commit title in commit references in the commit message - - drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 3 ++- - 1 file changed, 2 insertions(+), 1 deletion(-) - -diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c b/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c -index 46128a2a9c6e..e98ce380c7b9 100644 ---- a/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c -+++ b/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c -@@ -308,7 +308,8 @@ iwl_parse_nvm_sections(struct iwl_mvm *mvm) - } - - /* PHY_SKU section is mandatory in B0 */ -- if (!mvm->nvm_sections[NVM_SECTION_TYPE_PHY_SKU].data) { -+ if (mvm->trans->cfg->nvm_type == IWL_NVM_EXT && -+ !mvm->nvm_sections[NVM_SECTION_TYPE_PHY_SKU].data) { - IWL_ERR(mvm, - "Can't parse phy_sku in B0, empty sections\n"); - return NULL; --- -2.24.1 - -