March 2019 - Linux-stable-mirror

Re: [PATCH] device property: Fix the length used in PROPERTY_ENTRY_STRING

by Heikki Krogerus

On Sat, Jan 26, 2019 at 04:09:45PM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: a85f42047533 device property: helper macros for property entry creation. > > The bot has tested the following trees: v4.20.4, v4.19.17, v4.14.95, v4.9.152. > > v4.20.4: Build OK! > v4.19.17: Build OK! > v4.14.95: Failed to apply! Possible dependencies: > 63dcc7090137 ("device property: Get rid of union aliasing") > 6e98503dba64 ("efi/apple-properties: Remove redundant attribute initialization from unmarshal_key_value_pairs()") > b2ca8bdff60c ("device property: Reuse property_entry_free_data()") > d5f962fa269e ("device property: Move property_entry_free_data() upper") > > v4.9.152: Failed to apply! Possible dependencies: > 027b25b26447 ("ACPI: Add FWNODE_ACPI_STATIC fwnode type") > 07bb80d40b0e ("device property: Add support for remote endpoints") > 0f194992c85f ("device property: Fix reading pset strings using array access functions") > 1df09bc66f9b ("of: Move OF property and graph API from base.c to property.c") > 21ea73f54c6d ("device property: Add fwnode_get_named_child_node()") > 2475a2b6c877 ("drivers/of/base.c: Add of_property_read_u64_index") > 2bd5452d46df ("device property: Add support for fwnode endpoints") > 34055190b19d ("ACPI / property: Add fwnode_get_next_child_node()") > 3708184afc77 ("device property: Move FW type specific functionality to FW specific files") > 39e5aeed835d ("device property: Constify argument to pset fwnode backend") > 3b27d00e7b6d ("device property: Move fwnode graph ops to firmware specific locations") > 5fa23530d4fc ("of: base: add support to find the level of the last cache") > 63dcc7090137 ("device property: Get rid of union aliasing") > 79389a83bc38 ("ACPI / property: Add support for remote endpoints") > 99db5ff7fe0b ("ACPI / property: Hierarchical properties support update") > afaf26fd8458 ("device property: Add fwnode_get_parent()") > b85ad494098b ("of: introduce of_graph_get_remote_node") > bec84da8d1da ("device property: allow to constify properties") > db3e50f3234b ("device property: Get rid of struct fwnode_handle type field") > dfa672fbc0d9 ("ACPI / property: Add possiblity to retrieve parent firmware node") > e7887c284969 ("device property: Add fwnode_handle_get()") > > > How should we proceed with this patch? Can we use the attached separate patches with v4.9 and v4.14 ? thanks, -- heikki

5 years, 9 months

2
1
0 0

FAILED: patch "[PATCH] iommu/vt-d: Check identity map for hot-added devices" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-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 117266fd59ddf46e98e36df09326d861738c6180 Mon Sep 17 00:00:00 2001 From: Lu Baolu <baolu.lu(a)linux.intel.com> Date: Mon, 25 Feb 2019 10:46:36 +0800 Subject: [PATCH] iommu/vt-d: Check identity map for hot-added devices The Intel IOMMU driver will put devices into a static identity mapped domain during boot if the kernel parameter "iommu=pt" is used. That means the IOMMU hardware will translate a DMA address into the same memory address. Unfortunately, hot-added devices are not subject to this. That results in some devices not working properly after hot added. A quick way to reproduce this issue is to boot a system with iommu=pt and, remove then readd the pci device with echo 1 > /sys/bus/pci/devices/[pci_source_id]/remove echo 1 > /sys/bus/pci/rescan You will find the identity mapped domain was replaced with a normal domain. Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: stable(a)vger.kernel.org Reported-by: Jis Ben <jisben(a)google.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Tested-by: James Dong <xmdong(a)google.com> Fixes: 99dcadede42f ('intel-iommu: Support PCIe hot-plug') Signed-off-by: Joerg Roedel <jroedel(a)suse.de> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 00f46021d690..c30b73d41bf2 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4567,16 +4567,19 @@ static int device_notifier(struct notifier_block *nb, if (iommu_dummy(dev)) return 0; - if (action != BUS_NOTIFY_REMOVED_DEVICE) - return 0; - - domain = find_domain(dev); - if (!domain) - return 0; + if (action == BUS_NOTIFY_REMOVED_DEVICE) { + domain = find_domain(dev); + if (!domain) + return 0; - dmar_remove_one_dev_info(dev); - if (!domain_type_is_vm_or_si(domain) && list_empty(&domain->devices)) - domain_exit(domain); + dmar_remove_one_dev_info(dev); + if (!domain_type_is_vm_or_si(domain) && + list_empty(&domain->devices)) + domain_exit(domain); + } else if (action == BUS_NOTIFY_ADD_DEVICE) { + if (iommu_should_identity_map(dev, 1)) + domain_add_dev_info(si_domain, dev); + } return 0; }

5 years, 9 months

1
0
0 0

FAILED: patch "[PATCH] iommu/vt-d: Check identity map for hot-added devices" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-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 117266fd59ddf46e98e36df09326d861738c6180 Mon Sep 17 00:00:00 2001 From: Lu Baolu <baolu.lu(a)linux.intel.com> Date: Mon, 25 Feb 2019 10:46:36 +0800 Subject: [PATCH] iommu/vt-d: Check identity map for hot-added devices The Intel IOMMU driver will put devices into a static identity mapped domain during boot if the kernel parameter "iommu=pt" is used. That means the IOMMU hardware will translate a DMA address into the same memory address. Unfortunately, hot-added devices are not subject to this. That results in some devices not working properly after hot added. A quick way to reproduce this issue is to boot a system with iommu=pt and, remove then readd the pci device with echo 1 > /sys/bus/pci/devices/[pci_source_id]/remove echo 1 > /sys/bus/pci/rescan You will find the identity mapped domain was replaced with a normal domain. Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: stable(a)vger.kernel.org Reported-by: Jis Ben <jisben(a)google.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Tested-by: James Dong <xmdong(a)google.com> Fixes: 99dcadede42f ('intel-iommu: Support PCIe hot-plug') Signed-off-by: Joerg Roedel <jroedel(a)suse.de> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 00f46021d690..c30b73d41bf2 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4567,16 +4567,19 @@ static int device_notifier(struct notifier_block *nb, if (iommu_dummy(dev)) return 0; - if (action != BUS_NOTIFY_REMOVED_DEVICE) - return 0; - - domain = find_domain(dev); - if (!domain) - return 0; + if (action == BUS_NOTIFY_REMOVED_DEVICE) { + domain = find_domain(dev); + if (!domain) + return 0; - dmar_remove_one_dev_info(dev); - if (!domain_type_is_vm_or_si(domain) && list_empty(&domain->devices)) - domain_exit(domain); + dmar_remove_one_dev_info(dev); + if (!domain_type_is_vm_or_si(domain) && + list_empty(&domain->devices)) + domain_exit(domain); + } else if (action == BUS_NOTIFY_ADD_DEVICE) { + if (iommu_should_identity_map(dev, 1)) + domain_add_dev_info(si_domain, dev); + } return 0; }

5 years, 9 months

1
0
0 0

FAILED: patch "[PATCH] iommu/vt-d: Check identity map for hot-added devices" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-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 117266fd59ddf46e98e36df09326d861738c6180 Mon Sep 17 00:00:00 2001 From: Lu Baolu <baolu.lu(a)linux.intel.com> Date: Mon, 25 Feb 2019 10:46:36 +0800 Subject: [PATCH] iommu/vt-d: Check identity map for hot-added devices The Intel IOMMU driver will put devices into a static identity mapped domain during boot if the kernel parameter "iommu=pt" is used. That means the IOMMU hardware will translate a DMA address into the same memory address. Unfortunately, hot-added devices are not subject to this. That results in some devices not working properly after hot added. A quick way to reproduce this issue is to boot a system with iommu=pt and, remove then readd the pci device with echo 1 > /sys/bus/pci/devices/[pci_source_id]/remove echo 1 > /sys/bus/pci/rescan You will find the identity mapped domain was replaced with a normal domain. Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: stable(a)vger.kernel.org Reported-by: Jis Ben <jisben(a)google.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Tested-by: James Dong <xmdong(a)google.com> Fixes: 99dcadede42f ('intel-iommu: Support PCIe hot-plug') Signed-off-by: Joerg Roedel <jroedel(a)suse.de> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 00f46021d690..c30b73d41bf2 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4567,16 +4567,19 @@ static int device_notifier(struct notifier_block *nb, if (iommu_dummy(dev)) return 0; - if (action != BUS_NOTIFY_REMOVED_DEVICE) - return 0; - - domain = find_domain(dev); - if (!domain) - return 0; + if (action == BUS_NOTIFY_REMOVED_DEVICE) { + domain = find_domain(dev); + if (!domain) + return 0; - dmar_remove_one_dev_info(dev); - if (!domain_type_is_vm_or_si(domain) && list_empty(&domain->devices)) - domain_exit(domain); + dmar_remove_one_dev_info(dev); + if (!domain_type_is_vm_or_si(domain) && + list_empty(&domain->devices)) + domain_exit(domain); + } else if (action == BUS_NOTIFY_ADD_DEVICE) { + if (iommu_should_identity_map(dev, 1)) + domain_add_dev_info(si_domain, dev); + } return 0; }

5 years, 9 months

1
0
0 0

FAILED: patch "[PATCH] iommu/vt-d: Check identity map for hot-added devices" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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 117266fd59ddf46e98e36df09326d861738c6180 Mon Sep 17 00:00:00 2001 From: Lu Baolu <baolu.lu(a)linux.intel.com> Date: Mon, 25 Feb 2019 10:46:36 +0800 Subject: [PATCH] iommu/vt-d: Check identity map for hot-added devices The Intel IOMMU driver will put devices into a static identity mapped domain during boot if the kernel parameter "iommu=pt" is used. That means the IOMMU hardware will translate a DMA address into the same memory address. Unfortunately, hot-added devices are not subject to this. That results in some devices not working properly after hot added. A quick way to reproduce this issue is to boot a system with iommu=pt and, remove then readd the pci device with echo 1 > /sys/bus/pci/devices/[pci_source_id]/remove echo 1 > /sys/bus/pci/rescan You will find the identity mapped domain was replaced with a normal domain. Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: stable(a)vger.kernel.org Reported-by: Jis Ben <jisben(a)google.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Tested-by: James Dong <xmdong(a)google.com> Fixes: 99dcadede42f ('intel-iommu: Support PCIe hot-plug') Signed-off-by: Joerg Roedel <jroedel(a)suse.de> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 00f46021d690..c30b73d41bf2 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4567,16 +4567,19 @@ static int device_notifier(struct notifier_block *nb, if (iommu_dummy(dev)) return 0; - if (action != BUS_NOTIFY_REMOVED_DEVICE) - return 0; - - domain = find_domain(dev); - if (!domain) - return 0; + if (action == BUS_NOTIFY_REMOVED_DEVICE) { + domain = find_domain(dev); + if (!domain) + return 0; - dmar_remove_one_dev_info(dev); - if (!domain_type_is_vm_or_si(domain) && list_empty(&domain->devices)) - domain_exit(domain); + dmar_remove_one_dev_info(dev); + if (!domain_type_is_vm_or_si(domain) && + list_empty(&domain->devices)) + domain_exit(domain); + } else if (action == BUS_NOTIFY_ADD_DEVICE) { + if (iommu_should_identity_map(dev, 1)) + domain_add_dev_info(si_domain, dev); + } return 0; }

5 years, 9 months

1
0
0 0

FAILED: patch "[PATCH] iommu/vt-d: Check identity map for hot-added devices" 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 117266fd59ddf46e98e36df09326d861738c6180 Mon Sep 17 00:00:00 2001 From: Lu Baolu <baolu.lu(a)linux.intel.com> Date: Mon, 25 Feb 2019 10:46:36 +0800 Subject: [PATCH] iommu/vt-d: Check identity map for hot-added devices The Intel IOMMU driver will put devices into a static identity mapped domain during boot if the kernel parameter "iommu=pt" is used. That means the IOMMU hardware will translate a DMA address into the same memory address. Unfortunately, hot-added devices are not subject to this. That results in some devices not working properly after hot added. A quick way to reproduce this issue is to boot a system with iommu=pt and, remove then readd the pci device with echo 1 > /sys/bus/pci/devices/[pci_source_id]/remove echo 1 > /sys/bus/pci/rescan You will find the identity mapped domain was replaced with a normal domain. Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: stable(a)vger.kernel.org Reported-by: Jis Ben <jisben(a)google.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Tested-by: James Dong <xmdong(a)google.com> Fixes: 99dcadede42f ('intel-iommu: Support PCIe hot-plug') Signed-off-by: Joerg Roedel <jroedel(a)suse.de> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 00f46021d690..c30b73d41bf2 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4567,16 +4567,19 @@ static int device_notifier(struct notifier_block *nb, if (iommu_dummy(dev)) return 0; - if (action != BUS_NOTIFY_REMOVED_DEVICE) - return 0; - - domain = find_domain(dev); - if (!domain) - return 0; + if (action == BUS_NOTIFY_REMOVED_DEVICE) { + domain = find_domain(dev); + if (!domain) + return 0; - dmar_remove_one_dev_info(dev); - if (!domain_type_is_vm_or_si(domain) && list_empty(&domain->devices)) - domain_exit(domain); + dmar_remove_one_dev_info(dev); + if (!domain_type_is_vm_or_si(domain) && + list_empty(&domain->devices)) + domain_exit(domain); + } else if (action == BUS_NOTIFY_ADD_DEVICE) { + if (iommu_should_identity_map(dev, 1)) + domain_add_dev_info(si_domain, dev); + } return 0; }

5 years, 9 months

1
0
0 0

FAILED: patch "[PATCH] iommu/vt-d: Check identity map for hot-added devices" failed to apply to 5.0-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.0-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 117266fd59ddf46e98e36df09326d861738c6180 Mon Sep 17 00:00:00 2001 From: Lu Baolu <baolu.lu(a)linux.intel.com> Date: Mon, 25 Feb 2019 10:46:36 +0800 Subject: [PATCH] iommu/vt-d: Check identity map for hot-added devices The Intel IOMMU driver will put devices into a static identity mapped domain during boot if the kernel parameter "iommu=pt" is used. That means the IOMMU hardware will translate a DMA address into the same memory address. Unfortunately, hot-added devices are not subject to this. That results in some devices not working properly after hot added. A quick way to reproduce this issue is to boot a system with iommu=pt and, remove then readd the pci device with echo 1 > /sys/bus/pci/devices/[pci_source_id]/remove echo 1 > /sys/bus/pci/rescan You will find the identity mapped domain was replaced with a normal domain. Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: stable(a)vger.kernel.org Reported-by: Jis Ben <jisben(a)google.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Tested-by: James Dong <xmdong(a)google.com> Fixes: 99dcadede42f ('intel-iommu: Support PCIe hot-plug') Signed-off-by: Joerg Roedel <jroedel(a)suse.de> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 00f46021d690..c30b73d41bf2 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4567,16 +4567,19 @@ static int device_notifier(struct notifier_block *nb, if (iommu_dummy(dev)) return 0; - if (action != BUS_NOTIFY_REMOVED_DEVICE) - return 0; - - domain = find_domain(dev); - if (!domain) - return 0; + if (action == BUS_NOTIFY_REMOVED_DEVICE) { + domain = find_domain(dev); + if (!domain) + return 0; - dmar_remove_one_dev_info(dev); - if (!domain_type_is_vm_or_si(domain) && list_empty(&domain->devices)) - domain_exit(domain); + dmar_remove_one_dev_info(dev); + if (!domain_type_is_vm_or_si(domain) && + list_empty(&domain->devices)) + domain_exit(domain); + } else if (action == BUS_NOTIFY_ADD_DEVICE) { + if (iommu_should_identity_map(dev, 1)) + domain_add_dev_info(si_domain, dev); + } return 0; }

5 years, 9 months

1
0
0 0

FAILED: patch "[PATCH] nfit: acpi_nfit_ctl(): Check out_obj->type in the right place" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-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 43f89877f26671c6309cd87d7364b1a3e66e71cf Mon Sep 17 00:00:00 2001 From: Dexuan Cui <decui(a)microsoft.com> Date: Wed, 30 Jan 2019 01:23:01 +0000 Subject: [PATCH] nfit: acpi_nfit_ctl(): Check out_obj->type in the right place In the case of ND_CMD_CALL, we should also check out_obj->type. The patch uses out_obj->type, which is a short alias to out_obj->package.type. Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism") Cc: <stable(a)vger.kernel.org> Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c index 95db6a2d0d6b..1598e3a121a6 100644 --- a/drivers/acpi/nfit/core.c +++ b/drivers/acpi/nfit/core.c @@ -535,6 +535,13 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm, return -EINVAL; } + if (out_obj->type != ACPI_TYPE_BUFFER) { + dev_dbg(dev, "%s unexpected output object type cmd: %s type: %d\n", + dimm_name, cmd_name, out_obj->type); + rc = -EINVAL; + goto out; + } + if (call_pkg) { call_pkg->nd_fw_size = out_obj->buffer.length; memcpy(call_pkg->nd_payload + call_pkg->nd_size_in, @@ -553,13 +560,6 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm, return 0; } - if (out_obj->package.type != ACPI_TYPE_BUFFER) { - dev_dbg(dev, "%s unexpected output object type cmd: %s type: %d\n", - dimm_name, cmd_name, out_obj->type); - rc = -EINVAL; - goto out; - } - dev_dbg(dev, "%s cmd: %s output length: %d\n", dimm_name, cmd_name, out_obj->buffer.length); print_hex_dump_debug(cmd_name, DUMP_PREFIX_OFFSET, 4, 4,

5 years, 9 months

2
2
0 0

[PATCH] ARM: dts: exynos: Fix audio (microphone) routing on Odroid XU3

by Sylwester Nawrocki

The name of CODEC input widget to which microphone is connected through the "Headphone" jack is "IN12" not "IN1". This fixes microphone support on Odroid XU3. Cc: <stable(a)vger.kernel.org> # v4.14+ Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> --- arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi index e84544b220b9..b90cea8b7368 100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi @@ -22,7 +22,7 @@ "Headphone Jack", "HPL", "Headphone Jack", "HPR", "Headphone Jack", "MICBIAS", - "IN1", "Headphone Jack", + "IN12", "Headphone Jack", "Speakers", "SPKL", "Speakers", "SPKR"; -- 2.17.1

5 years, 9 months

2
3
0 0

FAILED: patch "[PATCH] cxl: Wrap iterations over afu slices inside 'afu_list_lock'" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-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 edeb304f659792fb5bab90d7d6f3408b4c7301fb Mon Sep 17 00:00:00 2001 From: Vaibhav Jain <vaibhav(a)linux.ibm.com> Date: Tue, 29 Jan 2019 16:36:18 +0530 Subject: [PATCH] cxl: Wrap iterations over afu slices inside 'afu_list_lock' Within cxl module, iteration over array 'adapter->afu' may be racy at few points as it might be simultaneously read during an EEH and its contents being set to NULL while driver is being unloaded or unbound from the adapter. This might result in a NULL pointer to 'struct afu' being de-referenced during an EEH thereby causing a kernel oops. This patch fixes this by making sure that all access to the array 'adapter->afu' is wrapped within the context of spin-lock 'adapter->afu_list_lock'. Fixes: 9e8df8a21963 ("cxl: EEH support") Cc: stable(a)vger.kernel.org # v4.3+ Acked-by: Andrew Donnellan <andrew.donnellan(a)au1.ibm.com> Acked-by: Frederic Barrat <fbarrat(a)linux.ibm.com> Acked-by: Christophe Lombard <clombard(a)linux.vnet.ibm.com> Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c index 5d28d9e454f5..08f4a512afad 100644 --- a/drivers/misc/cxl/guest.c +++ b/drivers/misc/cxl/guest.c @@ -267,6 +267,7 @@ static int guest_reset(struct cxl *adapter) int i, rc; pr_devel("Adapter reset request\n"); + spin_lock(&adapter->afu_list_lock); for (i = 0; i < adapter->slices; i++) { if ((afu = adapter->afu[i])) { pci_error_handlers(afu, CXL_ERROR_DETECTED_EVENT, @@ -283,6 +284,7 @@ static int guest_reset(struct cxl *adapter) pci_error_handlers(afu, CXL_RESUME_EVENT, 0); } } + spin_unlock(&adapter->afu_list_lock); return rc; } diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c index c79ba1c699ad..300531d6136f 100644 --- a/drivers/misc/cxl/pci.c +++ b/drivers/misc/cxl/pci.c @@ -1805,7 +1805,7 @@ static pci_ers_result_t cxl_vphb_error_detected(struct cxl_afu *afu, /* There should only be one entry, but go through the list * anyway */ - if (afu->phb == NULL) + if (afu == NULL || afu->phb == NULL) return result; list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) { @@ -1832,7 +1832,8 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev, { struct cxl *adapter = pci_get_drvdata(pdev); struct cxl_afu *afu; - pci_ers_result_t result = PCI_ERS_RESULT_NEED_RESET, afu_result; + pci_ers_result_t result = PCI_ERS_RESULT_NEED_RESET; + pci_ers_result_t afu_result = PCI_ERS_RESULT_NEED_RESET; int i; /* At this point, we could still have an interrupt pending. @@ -1843,6 +1844,7 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev, /* If we're permanently dead, give up. */ if (state == pci_channel_io_perm_failure) { + spin_lock(&adapter->afu_list_lock); for (i = 0; i < adapter->slices; i++) { afu = adapter->afu[i]; /* @@ -1851,6 +1853,7 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev, */ cxl_vphb_error_detected(afu, state); } + spin_unlock(&adapter->afu_list_lock); return PCI_ERS_RESULT_DISCONNECT; } @@ -1932,11 +1935,17 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev, * * In slot_reset, free the old resources and allocate new ones. * * In resume, clear the flag to allow things to start. */ + + /* Make sure no one else changes the afu list */ + spin_lock(&adapter->afu_list_lock); + for (i = 0; i < adapter->slices; i++) { afu = adapter->afu[i]; - afu_result = cxl_vphb_error_detected(afu, state); + if (afu == NULL) + continue; + afu_result = cxl_vphb_error_detected(afu, state); cxl_context_detach_all(afu); cxl_ops->afu_deactivate_mode(afu, afu->current_mode); pci_deconfigure_afu(afu); @@ -1948,6 +1957,7 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev, (result == PCI_ERS_RESULT_NEED_RESET)) result = PCI_ERS_RESULT_NONE; } + spin_unlock(&adapter->afu_list_lock); /* should take the context lock here */ if (cxl_adapter_context_lock(adapter) != 0) @@ -1980,14 +1990,18 @@ static pci_ers_result_t cxl_pci_slot_reset(struct pci_dev *pdev) */ cxl_adapter_context_unlock(adapter); + spin_lock(&adapter->afu_list_lock); for (i = 0; i < adapter->slices; i++) { afu = adapter->afu[i]; + if (afu == NULL) + continue; + if (pci_configure_afu(afu, adapter, pdev)) - goto err; + goto err_unlock; if (cxl_afu_select_best_mode(afu)) - goto err; + goto err_unlock; if (afu->phb == NULL) continue; @@ -1999,16 +2013,16 @@ static pci_ers_result_t cxl_pci_slot_reset(struct pci_dev *pdev) ctx = cxl_get_context(afu_dev); if (ctx && cxl_release_context(ctx)) - goto err; + goto err_unlock; ctx = cxl_dev_context_init(afu_dev); if (IS_ERR(ctx)) - goto err; + goto err_unlock; afu_dev->dev.archdata.cxl_ctx = ctx; if (cxl_ops->afu_check_and_enable(afu)) - goto err; + goto err_unlock; afu_dev->error_state = pci_channel_io_normal; @@ -2029,8 +2043,13 @@ static pci_ers_result_t cxl_pci_slot_reset(struct pci_dev *pdev) result = PCI_ERS_RESULT_DISCONNECT; } } + + spin_unlock(&adapter->afu_list_lock); return result; +err_unlock: + spin_unlock(&adapter->afu_list_lock); + err: /* All the bits that happen in both error_detected and cxl_remove * should be idempotent, so we don't need to worry about leaving a mix @@ -2051,10 +2070,11 @@ static void cxl_pci_resume(struct pci_dev *pdev) * This is not the place to be checking if everything came back up * properly, because there's no return value: do that in slot_reset. */ + spin_lock(&adapter->afu_list_lock); for (i = 0; i < adapter->slices; i++) { afu = adapter->afu[i]; - if (afu->phb == NULL) + if (afu == NULL || afu->phb == NULL) continue; list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) { @@ -2063,6 +2083,7 @@ static void cxl_pci_resume(struct pci_dev *pdev) afu_dev->driver->err_handler->resume(afu_dev); } } + spin_unlock(&adapter->afu_list_lock); } static const struct pci_error_handlers cxl_err_handler = {

5 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2019