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: <5a6a77d2-fc67-753f-7b9f-4a60c808ac92@codeaurora.org>
Date:   Tue, 16 Feb 2021 13:53:37 -0700
From:   Jeffrey Hugo <jhugo@...eaurora.org>
To:     bbhatt@...eaurora.org
Cc:     manivannan.sadhasivam@...aro.org, hemantk@...eaurora.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Fan Wu <wufan@...eaurora.org>,
        jhugo=codeaurora.org@...eaurora.org
Subject: Re: [PATCH] mhi_bus: core: Return EBUSY if MHI ring is full

On 2/16/2021 1:22 PM, Bhaumik Bhatt wrote:
> On 2021-02-16 10:48 AM, Jeffrey Hugo wrote:
>> From: Fan Wu <wufan@...eaurora.org>
>>
>> Currently ENOMEM is returned when MHI ring is full. This error code is
>> very misleading. Change to EBUSY instead.
>>
>> Signed-off-by: Fan Wu <wufan@...eaurora.org>
>> Signed-off-by: Jeffrey Hugo <jhugo@...eaurora.org>
>> ---
>>  drivers/bus/mhi/core/main.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
>> index f182736..21eb5fc 100644
>> --- a/drivers/bus/mhi/core/main.c
>> +++ b/drivers/bus/mhi/core/main.c
>> @@ -996,7 +996,7 @@ static int mhi_queue(struct mhi_device *mhi_dev,
>> struct mhi_buf_info *buf_info,
>>
>>      ret = mhi_is_ring_full(mhi_cntrl, tre_ring);
>>      if (unlikely(ret)) {
>> -        ret = -ENOMEM;
>> +        ret = -EBUSY;
>>          goto exit_unlock;
>>      }
> 
> ENOMEM is descriptive of the state of the ring since you basically 
> cannot queue any
> more packets as no memory is currently available.
> 
> But I agree, it can be misleading for this API. How about EAGAIN in 
> place of EBUSY,
> which tells the user to try the queue attempt again implying memory 
> should become
> available as more elements are consumed by the device/client?

Fan and I think EAGAIN is fine.  Will send a v2.

-- 
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ