linux-kernel - Re: [PATCH V23 2/3] misc: dcc: Add driver support for Data Capture and Compare unit(DCC)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Jun 2023 19:17:34 +0530
From:   Souradeep Chowdhury <quic_schowdhu@...cinc.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, Alex Elder <elder@...e.org>,
        Arnd Bergmann <arnd@...db.de>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, Sibi Sankar <quic_sibis@...cinc.com>,
        "Rajendra Nayak" <quic_rjendra@...cinc.com>
Subject: Re: [PATCH V23 2/3] misc: dcc: Add driver support for Data Capture
 and Compare unit(DCC)



On 6/15/2023 6:20 PM, Greg Kroah-Hartman wrote:
> On Thu, Jun 15, 2023 at 06:13:53PM +0530, Souradeep Chowdhury wrote:
>>
>>
>> On 6/15/2023 4:03 PM, Greg Kroah-Hartman wrote:
>>> On Thu, May 04, 2023 at 11:36:22PM -0700, Souradeep Chowdhury wrote:
>>>> +/**
>>>> + * struct dcc_config_entry - configuration information related to each dcc instruction
>>>> + * @base:                    Base address of the register to be configured in dcc
>>>
>>> Why is this a u32 and not a bigger size?
>>
>> Currently only 32 bit register addresses are supported for DCC
>> configuration.
>>
>>>
>>>> + * @offset:                  Offset to the base address to be configured in dcc
>>>> + * @len:                     Length of the address in words to be configured in dcc
>>>
>>> What is a "word" here, 16 bits?
>>
>> Each word is 4 bytes(32 bits)
> 
> See, I guess wrong, you should say what this is :)

Ack

> 
>>>> + * @loop_cnt:                The number of times to loop on the register address in case
>>>> +				of loop instructions
>>>> + * @write_val:               The value to be written on the register address in case of
>>>> +				write instructions
>>>> + * @mask:                    Mask corresponding to the value to be written in case of
>>>> +				write instructions
>>>> + * @apb_bus:                 Type of bus to be used for the instruction, can be either
>>>> +				'apb' or 'ahb'
>>>
>>> How can a bool be either "apb" or "ahb"?
>>
>> 1 stands for apb and 0 for ahb. Will update the same here.
> 
> Why not have an enum?  Will there ever be another "bus"?

No, only these two are supported for dcc.

> 
>>>> +static ssize_t ready_read(struct file *filp, char __user *userbuf,
>>>> +			  size_t count, loff_t *ppos)
>>>> +{
>>>> +	int ret = 0;
>>>> +	char *buf;
>>>> +	struct dcc_drvdata *drvdata = filp->private_data;
>>>> +
>>>> +	mutex_lock(&drvdata->mutex);
>>>> +
>>>> +	if (!is_dcc_enabled(drvdata)) {
>>>> +		ret = -EINVAL;
>>>> +		goto out_unlock;
>>>> +	}
>>>> +
>>>> +	if (!FIELD_GET(BIT(1), readl(drvdata->base + dcc_status(drvdata->mem_map_ver))))
>>>> +		buf = "Y\n";
>>>> +	else
>>>> +		buf = "N\n";
>>>> +out_unlock:
>>>> +	mutex_unlock(&drvdata->mutex);
>>>> +
>>>> +	if (ret < 0)
>>>> +		return -EINVAL;
>>>> +	else
>>>
>>> You do the "lock, get a value, unlock, do something with the value"
>>> thing a bunch, but what prevents the value from changing after the lock
>>> happens?  So why is the lock needed at all?
>>
>> The lock is used to prevent concurrent accesses of the drv_data when
>> scripts are being run from userspace.
> 
> How would that matter?  The state can change instantly after the lock is
> given up, and then the returned value is now incorrect.  So no need for
> a lock at all as you really aren't "protecting" anything, or am I
> missing something else?

This lock is needed to protect the access to the global instance of 
drv_data structure instantiated at probe time within each individual 
callbacks of debugfs.

> 
> thanks,
> 
> greg k-h