| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <576403D5.1070902@semihalf.com>
Date: Fri, 17 Jun 2016 16:06:13 +0200
From: Tomasz Nowicki <tn@...ihalf.com>
To: Marc Zyngier <marc.zyngier@....com>, rjw@...ysocki.net,
lorenzo.pieralisi@....com
Cc: tglx@...utronix.de, jason@...edaemon.net, bhelgaas@...gle.com,
robert.richter@...iumnetworks.com, shijie.huang@....com,
Suravee.Suthikulpanit@....com, hanjun.guo@...aro.org,
al.stone@...aro.org, mw@...ihalf.com, graeme.gregory@...aro.org,
Catalin.Marinas@....com, will.deacon@....com,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, ddaney.cavm@...il.com,
okaya@...eaurora.org, andrea.gallo@...aro.org,
linux-pci@...r.kernel.org
Subject: Re: [PATCH V6 1/7] ACPI: I/O Remapping Table (IORT) initial support
On 15.06.2016 10:31, Marc Zyngier wrote:
> On Mon, 13 Jun 2016 16:41:07 +0200
> Tomasz Nowicki <tn@...ihalf.com> wrote:
>
>> IORT shows representation of IO topology for ARM based systems.
>> It describes how various components are connected together on
>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
>>
>> Initial support allows to:
>> - register ITS MSI chip along with ITS translation ID and domain token
>> - deregister ITS MSI chip based on ITS translation ID
>> - find registered domain token based on ITS translation ID
>> - map MSI RID for a device
>> - find domain token for a device
>>
>> Signed-off-by: Tomasz Nowicki <tn@...ihalf.com>
>> ---
>> drivers/acpi/Kconfig | 3 +
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/iort.c | 386 ++++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/iort.h | 38 +++++
>> 4 files changed, 428 insertions(+)
>> create mode 100644 drivers/acpi/iort.c
>> create mode 100644 include/linux/iort.h
>>
[...]
>> +
>> +static struct acpi_iort_node *
>> +iort_node_map_rid(struct acpi_iort_node *node, u32 rid_in,
>> + u32 *rid_out, u8 type)
>> +{
>> +
>> + if (!node)
>> + goto out;
>> +
>> + /* Go upstream */
>> + while (node->type != type) {
>> + struct acpi_iort_id_mapping *id;
>> + int i, found = 0;
>> +
>> + /* Exit when no mapping array */
>> + if (!node->mapping_offset || !node->mapping_count)
>> + return NULL;
>> +
>> + id = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
>> + node->mapping_offset);
>> +
>> + for (i = 0, found = 0; i < node->mapping_count; i++, id++) {
>> + /*
>> + * Single mapping is not translation rule,
>> + * lets move on for this case
>> + */
>> + if (id->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
>> + if (node->type != ACPI_IORT_NODE_SMMU) {
>> + rid_in = id->output_base;
>> + found = 1;
>> + break;
>> + }
>> +
>> + pr_warn(FW_BUG "[node %p type %d] SINGLE MAPPING flag not allowed for SMMU node, skipping ID map\n",
>> + node, node->type);
>> + continue;
>> + }
>> +
>> + if (rid_in < id->input_base ||
>> + (rid_in > id->input_base + id->id_count))
>> + continue;
>> +
>> + rid_in = id->output_base + (rid_in - id->input_base);
>> + found = 1;
>> + break;
>> + }
>> +
>> + if (!found)
>> + return NULL;
>
> Why this special case? It would make more sense to use the normal
> epilogue, and update rid_out. Unless not finding a translation for a
> given rid is illegal?
We can use the same strategy as __of_msi_map_rid() which means we simply
use rid_in in case of any error. I will update accordingly.
>
>> +
>> + /* Firmware bug! */
>> + if (!id->output_reference) {
>> + pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
>> + node, node->type);
>> + return NULL;
>> + }
>> +
>> + node = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
>> + id->output_reference);
>> + }
>> +
>> +out:
>> + if (rid_out)
>> + *rid_out = rid_in;
>> + return node;
>> +}
>> +
>> +static struct acpi_iort_node *
>> +iort_find_dev_node(struct device *dev)
>> +{
>> + struct pci_bus *pbus;
>> +
>> + if (!dev_is_pci(dev))
>> + return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
>> + iort_match_node_callback, dev);
>> +
>> + /* Find a PCI root bus */
>> + pbus = to_pci_dev(dev)->bus;
>> + while (!pci_is_root_bus(pbus))
>> + pbus = pbus->parent;
>> +
>> + return iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
>> + iort_match_node_callback, &pbus->dev);
>> +}
>> +
>> +/**
>> + * iort_msi_map_rid() - Map a MSI requester ID for a device
>> + * @dev: The device for which the mapping is to be done.
>> + * @req_id: The device requester ID.
>> + *
>> + * Returns: mapped MSI RID on success, input requester ID otherwise
>> + */
>> +u32 iort_msi_map_rid(struct device *dev, u32 req_id)
>> +{
>> + struct acpi_iort_node *node;
>> + u32 dev_id;
>> +
>> + if (!iort_table)
>> + return req_id;
>> +
>> + node = iort_find_dev_node(dev);
>> + if (!node) {
>> + dev_err(dev, "can't find related IORT node\n");
>> + return req_id;
>> + }
>> +
>> + if (!iort_node_map_rid(node, req_id, &dev_id,
>> + ACPI_IORT_NODE_ITS_GROUP))
>> + return req_id;
>
> And once you've fixed the special case in iort_node_map_rid, you can
> unconditionally return dev_id.
Right.
>
>> +
>> + return dev_id;
>> +}
>> +
>> +/**
>> + * iort_dev_find_its_id() - Find the ITS identifier for a device
>> + * @dev: The device.
>> + * @idx: Index of the ITS identifier list.
>> + * @its_id: ITS identifier.
>> + *
>> + * Returns: 0 on success, appropriate error value otherwise
>> + */
>> +static int
>> +iort_dev_find_its_id(struct device *dev, u32 req_id, unsigned int idx,
>> + int *its_id)
>> +{
>> + struct acpi_iort_its_group *its;
>> + struct acpi_iort_node *node;
>> +
>> + node = iort_find_dev_node(dev);
>> + if (!node) {
>> + dev_err(dev, "can't find related IORT node\n");
>> + return -ENXIO;
>> + }
>> +
>> + node = iort_node_map_rid(node, req_id, NULL, ACPI_IORT_NODE_ITS_GROUP);
>> + if (!node) {
>> + dev_err(dev, "can't find related ITS node\n");
>> + return -ENXIO;
>> + }
>> +
>> + /* Move to ITS specific data */
>> + its = (struct acpi_iort_its_group *)node->node_data;
>> + if (idx > its->its_count) {
>> + dev_err(dev, "requested ITS ID index [%d] is greater than available [%d]\n",
>> + idx, its->its_count);
>> + return -ENXIO;
>> + }
>> +
>> + *its_id = its->identifiers[idx];
>> + return 0;
>> +}
>> +
>> +/**
>> + * iort_get_device_domain() - Find MSI domain related to a device
>> + * @dev: The device.
>> + * @req_id: Requester ID for the device.
>> + *
>> + * Returns: the MSI domain for this device, NULL otherwise
>> + */
>> +struct irq_domain *
>> +iort_get_device_domain(struct device *dev, u32 req_id)
>> +{
>> + static struct fwnode_handle *handle;
>> + int its_id;
>> +
>> + if (!iort_table)
>> + return NULL;
>> +
>> + if (iort_dev_find_its_id(dev, req_id, 0, &its_id))
>> + return NULL;
>> +
>> + handle = iort_find_domain_token(its_id);
>> + if (!handle)
>> + return NULL;
>
> Can this actually happen? I can't see how, unless you have a race
> between iort_dev_find_its_id and iort_find_domain_token. And given that
> both these functions are only called from here, maybe you're better off
> having a single function:
>
> struct fwnode_handle *iort_dev_find_its_domain_token(struct device *dev,
> u32 rid);
>
> which returns the atomic lookup of the ITS handle. Or is there any
> constraints preventing us from holding the lock?
Yes this may happen, let's say we have one ITS with ID = 0:
1. iort_register_domain_token() fails because of lack of memory (-ENOMEM)
2. iort_dev_find_its_id() would point us to ITS with ID = 0
3. iort_find_domain_token() return NULL due to no element on the list
for ITS ID = 0
Actually iort_dev_find_its_id() finds out ITS ID related to a given
device, it only interact with IORT content but not with
iort_msi_chip_list list. iort_find_domain_token() has its own lock for
iort_msi_chip_list so I am not sure why we need lock.
Thanks,
Tomasz
Powered by blists - more mailing lists