linux-kernel - Re: [PATCH 2/2] x86/platform/amd: replace down_timeout with down

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] [day] [month] [year] [list]

Message-ID: <b579c4eb-058a-445f-b288-aef1daffeaf3@amd.com>
Date: Wed, 4 Jun 2025 16:55:00 +0530
From: Suma Hegde <Suma.Hegde@....com>
To: jake@...lion.co.uk,
 Naveen Krishna Chatradhi <naveenkrishna.chatradhi@....com>,
 Carlos Bilbao <carlos.bilbao@...nel.org>, Hans de Goede
 <hdegoede@...hat.com>, Ilpo Järvinen
 <ilpo.jarvinen@...ux.intel.com>
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
 sched-ext@...a.com
Subject: Re: [PATCH 2/2] x86/platform/amd: replace down_timeout with
 down_interruptible

Hi,


On 5/30/2025 9:45 PM, Jake Hillion via B4 Relay wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> From: Jake Hillion <jake@...lion.co.uk>
>
> Currently hsmp_send_message uses down_timeout with a 100ms timeout to
> take the semaphore. However __hsmp_send_message, the content of the
> critical section, has a sleep in it. On systems with significantly
> delayed scheduling behaviour this may take over 100ms.
>
> Convert this method to down_interruptible. Leave the error handling the
> same as the documentation currently is not specific about what error is
> returned.
>
> Previous behaviour: a caller who competes with another caller stuck in
> the critical section due to scheduler delays would receive -ETIMEDOUT.


down_timeout() will return -ETIME,  Please replace -ETIMEDOUT with -ETIME.

>
> New behaviour: a caller who competes with another caller stuck in the
> critical section due to scheduler delays will complete successfully.
>
> Signed-off-by: Jake Hillion <jake@...lion.co.uk>


Reviewed-by: Suma Hegde <suma.hegde@....com>
Tested-by: Suma Hegde <suma.hegde@....com>


> ---
>   drivers/platform/x86/amd/hsmp/hsmp.c | 8 +-------
>   1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/platform/x86/amd/hsmp/hsmp.c b/drivers/platform/x86/amd/hsmp/hsmp.c
> index f35c639457ac425e79dead2515c0eddea0759323..6c30bb3edc1d77939b10047b771a5c574e5f2a1e 100644
> --- a/drivers/platform/x86/amd/hsmp/hsmp.c
> +++ b/drivers/platform/x86/amd/hsmp/hsmp.c
> @@ -216,13 +216,7 @@ int hsmp_send_message(struct hsmp_message *msg)
>                  return -ENODEV;
>          sock = &hsmp_pdev.sock[msg->sock_ind];
>
> -       /*
> -        * The time taken by smu operation to complete is between
> -        * 10us to 1ms. Sometime it may take more time.
> -        * In SMP system timeout of 100 millisecs should
> -        * be enough for the previous thread to finish the operation
> -        */
> -       ret = down_timeout(&sock->hsmp_sem, msecs_to_jiffies(HSMP_MSG_TIMEOUT));
> +       ret = down_interruptible(&sock->hsmp_sem);
>          if (ret < 0)
>                  return ret;
>
>
> --
> 2.47.2

Thanks and Regards,

Suma

>
>