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]
Message-ID: <20200108171244.GT32742@smile.fi.intel.com>
Date:   Wed, 8 Jan 2020 19:12:44 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     Darren Hart <dvhart@...radead.org>,
        Lee Jones <lee.jones@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Zha Qipeng <qipeng.zha@...el.com>,
        Rajneesh Bhardwaj <rajneesh.bhardwaj@...ux.intel.com>,
        "David E . Box" <david.e.box@...ux.intel.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 07/36] platform/x86: intel_scu_ipc: Sleeping is fine
 when polling

On Wed, Jan 08, 2020 at 02:41:32PM +0300, Mika Westerberg wrote:
> There is no reason why the driver would need to block other threads from
> running the CPU while it is waiting for the SCU IPC to complete its
> work. For this reason switch the driver to use usleep_range() instead
> with a bit more relaxed polling loop.

I agree on this and if somebody finds a race condition that had been hidden by
the original code it will mean that somewhere else something is completely
broken.

> 
> Also add constant for the timeout and use the same value for both
> polling and interrupt modes.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>

> 
> Signed-off-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
> ---
>  drivers/platform/x86/intel_scu_ipc.c | 29 ++++++++++++++--------------
>  1 file changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/intel_scu_ipc.c
> index 43eaf9400c67..8db0644900a3 100644
> --- a/drivers/platform/x86/intel_scu_ipc.c
> +++ b/drivers/platform/x86/intel_scu_ipc.c
> @@ -79,6 +79,9 @@ static struct intel_scu_ipc_dev  ipcdev; /* Only one for now */
>  #define IPC_WRITE_BUFFER	0x80
>  #define IPC_READ_BUFFER		0x90
>  
> +/* Timeout in jiffies */
> +#define IPC_TIMEOUT		(3 * HZ)
> +
>  static DEFINE_MUTEX(ipclock); /* lock used to prevent multiple call to SCU */
>  
>  /*
> @@ -132,24 +135,20 @@ static inline u32 ipc_data_readl(struct intel_scu_ipc_dev *scu, u32 offset)
>  /* Wait till scu status is busy */
>  static inline int busy_loop(struct intel_scu_ipc_dev *scu)
>  {
> -	u32 status = ipc_read_status(scu);
> -	u32 loop_count = 100000;
> +	unsigned long end = jiffies + msecs_to_jiffies(IPC_TIMEOUT);
>  
> -	/* break if scu doesn't reset busy bit after huge retry */
> -	while ((status & IPC_STATUS_BUSY) && --loop_count) {
> -		udelay(1); /* scu processing time is in few u secods */
> -		status = ipc_read_status(scu);
> -	}
> +	do {
> +		u32 status;
>  
> -	if (status & IPC_STATUS_BUSY) {
> -		dev_err(scu->dev, "IPC timed out");
> -		return -ETIMEDOUT;
> -	}
> +		status = ipc_read_status(scu);
> +		if (!(status & IPC_STATUS_BUSY))
> +			return (status & IPC_STATUS_ERR) ? -EIO : 0;
>  
> -	if (status & IPC_STATUS_ERR)
> -		return -EIO;
> +		usleep_range(50, 100);
> +	} while (time_before(jiffies, end));
>  
> -	return 0;
> +	dev_err(scu->dev, "IPC timed out");
> +	return -ETIMEDOUT;
>  }
>  
>  /* Wait till ipc ioc interrupt is received or timeout in 3 HZ */
> @@ -157,7 +156,7 @@ static inline int ipc_wait_for_interrupt(struct intel_scu_ipc_dev *scu)
>  {
>  	int status;
>  
> -	if (!wait_for_completion_timeout(&scu->cmd_complete, 3 * HZ)) {
> +	if (!wait_for_completion_timeout(&scu->cmd_complete, IPC_TIMEOUT)) {
>  		dev_err(scu->dev, "IPC timed out\n");
>  		return -ETIMEDOUT;
>  	}
> -- 
> 2.24.1
> 

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ