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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 13 Feb 2018 15:44:16 +0530
From:   Vivek Gautam <vivek.gautam@...eaurora.org>
To:     Tomasz Figa <tfiga@...omium.org>
Cc:     "list@....net:IOMMU DRIVERS <iommu@...ts.linux-foundation.org>, Joerg
        Roedel <joro@...tes.org>," <joro@...tes.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Robin Murphy <robin.murphy@....com>,
        Will Deacon <will.deacon@....com>,
        Rob Clark <robdclark@...il.com>,
        "list@....net:IOMMU DRIVERS <iommu@...ts.linux-foundation.org>, Joerg
        Roedel <joro@...tes.org>," <iommu@...ts.linux-foundation.org>,
        devicetree@...r.kernel.org,
        open list <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        freedreno@...ts.freedesktop.org, David Airlie <airlied@...ux.ie>,
        Greg KH <gregkh@...uxfoundation.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v7 4/6] iommu/arm-smmu: Add the device_link between
 masters and smmu

Hi Tomasz,


On Tue, Feb 13, 2018 at 2:01 PM, Tomasz Figa <tfiga@...omium.org> wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.

Thanks for reviewing the patch series.

>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> <vivek.gautam@...eaurora.org> wrote:
>> From: Sricharan R <sricharan@...eaurora.org>
>>
>> Finally add the device link between the master device and
>> smmu, so that the smmu gets runtime enabled/disabled only when the
>> master needs it. This is done from add_device callback which gets
>> called once when the master is added to the smmu.
>>
>> Signed-off-by: Sricharan R <sricharan@...eaurora.org>
>> Signed-off-by: Vivek Gautam <vivek.gautam@...eaurora.org>
>> ---
>>  drivers/iommu/arm-smmu.c | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index c024f69c1682..c7e924d553bd 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -215,6 +215,9 @@ struct arm_smmu_device {
>>
>>         /* IOMMU core code handle */
>>         struct iommu_device             iommu;
>> +
>> +       /* runtime PM link to master */
>> +       struct device_link *link;
>>  };
>>
>>  enum arm_smmu_context_fmt {
>> @@ -1425,6 +1428,17 @@ static int arm_smmu_add_device(struct device *dev)
>>
>>         pm_runtime_put_sync(smmu->dev);
>>
>> +       /*
>> +        * Establish the link between smmu and master, so that the
>> +        * smmu gets runtime enabled/disabled as per the master's
>> +        * needs.
>> +        */
>> +       smmu->link = device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME);
>> +       if (!smmu->link)
>> +               dev_warn(smmu->dev,
>> +                        "Unable to create device link between %s and %s\n",
>> +                        dev_name(smmu->dev), dev_name(dev));
>
> How likely it is that the master can work normally even if the link
> add fails? Perhaps we should just return an error here?

Right. We are assuming that the power is handled for most of the
smmu operations, after we add the master with smmu, based on the fact
that the device link is successful.
We should return error code here. Will make the necessary change.

>
>> +
>>         return 0;
>>
>>  out_rpm_put:
>> @@ -1449,6 +1463,8 @@ static void arm_smmu_remove_device(struct device *dev)
>>         cfg  = fwspec->iommu_priv;
>>         smmu = cfg->smmu;
>>
>> +       device_link_del(smmu->link);
>
> We allowed smmu->link in arm_smmu_add_device(), but here we don't
> check it. Looking at the code, device_link_del() doesn't seem to check
> either.
>
> Note that this problem would go away if we fail add_device on
> device_link_add() failure, as I suggested above, so no change would be
> necessary.

Sure. After making the above change, this should also be handled.

Best regards
Vivek

>
> Best regards,
> Tomasz



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ