Linux v5.5.10
This commit is contained in:
Justin M. Forbes
parent
a4bc4dcc75
commit
a1fe76173b
5 changed files with 5 additions and 364 deletions
|
|
@ -1,136 +0,0 @@
|
|||
From e3a36eb6dfaeea8175c05d5915dcf0b939be6dab Mon Sep 17 00:00:00 2001
|
||||
From: Christoph Hellwig <hch@lst.de>
|
||||
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 <aros@gmx.com>
|
||||
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
|
||||
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
||||
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
||||
---
|
||||
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
|
||||
|
||||
|
|
@ -1,164 +0,0 @@
|
|||
From 2f2265a8cbc6b43deb169c525204ea7df02e9363 Mon Sep 17 00:00:00 2001
|
||||
From: Hans de Goede <hdegoede@redhat.com>
|
||||
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 <hdegoede@redhat.com>
|
||||
---
|
||||
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 <hdegoede@redhat.com>
|
||||
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 <brho@google.com>
|
||||
Cc: stable@vger.kernel.org
|
||||
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
||||
---
|
||||
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
|
||||
|
||||
15
kernel.spec
15
kernel.spec
|
|
@ -56,7 +56,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}
|
||||
|
|
@ -568,16 +568,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
|
||||
|
||||
|
|
@ -1821,6 +1811,9 @@ fi
|
|||
#
|
||||
#
|
||||
%changelog
|
||||
* Wed Mar 18 2020 Justin M. Forbes <jforbes@fedoraproject.org> - 5.5.10-100
|
||||
- Linux v5.5.10
|
||||
|
||||
* Sat Mar 14 2020 Hans de Goede <hdegoede@redhat.com>
|
||||
- Fix UCSI oopses (rhbz 1785972)
|
||||
|
||||
|
|
|
|||
3
sources
3
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
|
||||
|
|
|
|||
|
|
@ -1,51 +0,0 @@
|
|||
From MAILER-DAEMON Mon Feb 24 19:54:49 2020
|
||||
From: Dan Moulding <dmoulding@me.com>
|
||||
To: linux-wireless@vger.kernel.org
|
||||
Cc: johannes.berg@intel.com, emmanuel.grumbach@intel.com, luciano.coelho@intel.com, linuxwifi@intel.com, Dan Moulding <dmoulding@me.com>
|
||||
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: <linux-wireless.vger.kernel.org>
|
||||
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 <dmoulding@me.com>
|
||||
---
|
||||
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
|
||||
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue