| 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
| ||
|
Date: Tue, 2 Feb 2021 12:38:17 -0800
From: Russ Weight <russell.h.weight@...el.com>
To: Tom Rix <trix@...hat.com>, mdf@...nel.org,
linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: lgoncalv@...hat.com, yilun.xu@...el.com, hao.wu@...el.com,
matthew.gerlach@...el.com
Subject: Re: [PATCH v2 1/1] fpga: dfl: afu: harden port enable logic
On 2/2/21 12:32 PM, Russ Weight wrote:
>
> On 9/17/20 1:28 PM, Tom Rix wrote:
>> On 9/17/20 11:32 AM, Russ Weight wrote:
>>> Port enable is not complete until ACK = 0. Change
>>> __afu_port_enable() to guarantee that the enable process
>>> is complete by polling for ACK == 0.
>>>
>>> Signed-off-by: Russ Weight <russell.h.weight@...el.com>
>>> ---
>>> drivers/fpga/dfl-afu-error.c | 2 +-
>>> drivers/fpga/dfl-afu-main.c | 29 +++++++++++++++++++++--------
>>> drivers/fpga/dfl-afu.h | 2 +-
>>> 3 files changed, 23 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/fpga/dfl-afu-error.c b/drivers/fpga/dfl-afu-error.c
>>> index c4691187cca9..0806532a3e9f 100644
>>> --- a/drivers/fpga/dfl-afu-error.c
>>> +++ b/drivers/fpga/dfl-afu-error.c
>>> @@ -103,7 +103,7 @@ static int afu_port_err_clear(struct device *dev, u64 err)
>>> __afu_port_err_mask(dev, false);
>>>
>> There is an earlier bit that sets ret = -EINVAL.
>>
>> This error will be lost or not handled well.
>>
>> Right now it doesn't seem to be handled.
> Good catch. I'll give priority to -EINVAL in the next version of the
> patch, as it is more informative in the context of this function.
Actually - Hao pointed out in his response that the falure to re-enable the port
is a more serious error, so the code flow OK, but needs a comment.
- Russ
>>> /* Enable the Port by clear the reset */
>>> - __afu_port_enable(pdev);
>>> + ret = __afu_port_enable(pdev);
>>>
>>> done:
>>> mutex_unlock(&pdata->lock);
>>> diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
>>> index 753cda4b2568..f73b06cdf13c 100644
>>> --- a/drivers/fpga/dfl-afu-main.c
>>> +++ b/drivers/fpga/dfl-afu-main.c
>>> @@ -21,6 +21,9 @@
>>>
>>> #include "dfl-afu.h"
>>>
>>> +#define RST_POLL_INVL 10 /* us */
>>> +#define RST_POLL_TIMEOUT 1000 /* us */
>>> +
>>> /**
>>> * __afu_port_enable - enable a port by clear reset
>>> * @pdev: port platform device.
>>> @@ -32,7 +35,7 @@
>>> *
>>> * The caller needs to hold lock for protection.
>>> */
>>> -void __afu_port_enable(struct platform_device *pdev)
>>> +int __afu_port_enable(struct platform_device *pdev)
>>> {
>>> struct dfl_feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
>>> void __iomem *base;
>>> @@ -41,7 +44,7 @@ void __afu_port_enable(struct platform_device *pdev)
>>> WARN_ON(!pdata->disable_count);
>>>
>>> if (--pdata->disable_count != 0)
>>> - return;
>>> + return 0;
>> Is this really a success ? Maybe -EBUSY ?
> Yilun addressed this question in his previous response. This isessentially a
> reference count for nested disable calls. Weonly do the enable if the
> disable count has gone to zero, so this isn't an error condition.
>>>
>>> base = dfl_get_feature_ioaddr_by_id(&pdev->dev, PORT_FEATURE_ID_HEADER);
>>>
>>> @@ -49,10 +52,20 @@ void __afu_port_enable(struct platform_device *pdev)
>>> v = readq(base + PORT_HDR_CTRL);
>>> v &= ~PORT_CTRL_SFTRST;
>>> writeq(v, base + PORT_HDR_CTRL);
>>> -}
>>>
>>> -#define RST_POLL_INVL 10 /* us */
>>> -#define RST_POLL_TIMEOUT 1000 /* us */
>>> + /*
>>> + * HW clears the ack bit to indicate that the port is fully out
>>> + * of reset.
>>> + */
>>> + if (readq_poll_timeout(base + PORT_HDR_CTRL, v,
>>> + !(v & PORT_CTRL_SFTRST_ACK),
>>> + RST_POLL_INVL, RST_POLL_TIMEOUT)) {
>>> + dev_err(&pdev->dev, "timeout, failure to enable device\n");
>>> + return -ETIMEDOUT;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>>
>>> /**
>>> * __afu_port_disable - disable a port by hold reset
>>> @@ -111,7 +124,7 @@ static int __port_reset(struct platform_device *pdev)
>>>
>>> ret = __afu_port_disable(pdev);
>>> if (!ret)
>>> - __afu_port_enable(pdev);
>>> + ret = __afu_port_enable(pdev);
>>>
>>> return ret;
>>> }
>>> @@ -872,11 +885,11 @@ static int afu_dev_destroy(struct platform_device *pdev)
>>> static int port_enable_set(struct platform_device *pdev, bool enable)
>>> {
>>> struct dfl_feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
>>> - int ret = 0;
>>> + int ret;
>>>
>>> mutex_lock(&pdata->lock);
>>> if (enable)
>>> - __afu_port_enable(pdev);
>>> + ret = __afu_port_enable(pdev);
>>> else
>>> ret = __afu_port_disable(pdev);
>>> mutex_unlock(&pdata->lock);
>>> diff --git a/drivers/fpga/dfl-afu.h b/drivers/fpga/dfl-afu.h
>>> index 576e94960086..e5020e2b1f3d 100644
>>> --- a/drivers/fpga/dfl-afu.h
>>> +++ b/drivers/fpga/dfl-afu.h
>>> @@ -80,7 +80,7 @@ struct dfl_afu {
>>> };
>>>
>>> /* hold pdata->lock when call __afu_port_enable/disable */
>>> -void __afu_port_enable(struct platform_device *pdev);
>>> +int __afu_port_enable(struct platform_device *pdev);
>>> int __afu_port_disable(struct platform_device *pdev);
>> The other functions in this file have afu_* since the __afu_port_enable/disable
>>
>> are used other places would it make sense to remove the '__' prefix ?
>>
>> If you think so, maybe a cleanup patch later.
> Yilun and Hao addressed this comment in their previous responses. We are using the
> '__' prefix to indicate highlight the fact caller needs to use care in managing
> the locking associated with these functions.
>
> Thanks,
> - Russ
>> Tom
>>
>>>
>>> void afu_mmio_region_init(struct dfl_feature_platform_data *pdata);
Powered by blists - more mailing lists