linux-kernel - Re: [PATCH] soc: qcom: smem: introduce qcom_smem_virt_to

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]

Date:   Wed, 25 Apr 2018 20:31:59 -0500
From:   Alex Elder <elder@...aro.org>
To:     Chris Lew <clew@...eaurora.org>, andy.gross@...aro.org
Cc:     aneela@...eaurora.org, david.brown@...aro.org,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soc: qcom: smem: introduce qcom_smem_virt_to_phys()

On 04/25/2018 06:29 PM, Chris Lew wrote:
> Hi Alex,
> 
> Minor comment.
> 
> On 4/25/2018 8:18 AM, Alex Elder wrote:
>> Create function qcom_smem_virt_to_phys(), which returns the physical
>> address corresponding to a given SMEM item's virtual address.  This
>> feature is required for a driver that will soon be out for review.
>>
>> Signed-off-by: Alex Elder <elder@...aro.org>
>> ---
>>   drivers/soc/qcom/smem.c       | 27 +++++++++++++++++++++++++++
>>   include/linux/soc/qcom/smem.h |  2 ++
>>   2 files changed, 29 insertions(+)
>>
>> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
>> index 7d9a43da5084..70b2ee80d6bd 100644
>> --- a/drivers/soc/qcom/smem.c
>> +++ b/drivers/soc/qcom/smem.c
>> @@ -655,6 +655,33 @@ int qcom_smem_get_free_space(unsigned host)
>>   }
>>   EXPORT_SYMBOL(qcom_smem_get_free_space);
>>   +/**
>> + * qcom_smem_virt_to_phys() - return the physical address associated
>> + * with an smem item pointer (previously returned by qcom_smem_get()
>> + * @p:    the virtual address to convert
>> + *
>> + * Returns 0 if the pointer provided is not within any smem region.
>> + */
>> +phys_addr_t qcom_smem_virt_to_phys(void *p)
>> +{
>> +    unsigned i;
>> +
> 
> We have a null pointer check for __smem here since it is called by
> external clients. This case should probably never happen though.

I think you're suggesting that we should verify __smem is non-null first?

I'll make a few statements about that.
- This function can only be called with a pointer that was returned by
  qcom_smem_get().  That function won't return a valid pointer unless
  __smem was non-null.
- The only other way __smem would be null is if this were called after
  qcom_smem_remove(), which is erroneous.
- I think putting a null pointer check suggests that it's a condition
  that might be expected to occur.  If anything, I'd put an assertion
  in there (e.g. BUG_ON(!__smem)) but I don't think it's warranted.

I do understand why you suggest this--and it's a relatively harmless
check.   But I think it's better without it.

					-Alex


>> +    for (i = 0; i < __smem->num_regions; i++) {
>> +        struct smem_region *region = &__smem->regions[i];
>> +
>> +        if (p < region->virt_base)
>> +            continue;
>> +        if (p < region->virt_base + region->size) {
>> +            u64 offset = p - region->virt_base;
>> +
>> +            return (phys_addr_t)region->aux_base + offset;
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +EXPORT_SYMBOL(qcom_smem_virt_to_phys);
> 
> Thanks,
> Chris
>