linux-kernel - Re: [alsa-devel] [PATCH 08/14] soundwire: Add Slave status handling helpers

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]

Message-ID: <11066ca7-f71c-5867-67f5-3c597b26bf61@linux.intel.com>
Date:   Wed, 1 Nov 2017 16:10:08 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Vinod Koul <vinod.koul@...el.com>
Cc:     ALSA <alsa-devel@...a-project.org>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Takashi Iwai <tiwai@...e.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        plai@...eaurora.org, LKML <linux-kernel@...r.kernel.org>,
        Sagar Dharia <sdharia@...eaurora.org>, patches.audio@...el.com,
        Mark <broonie@...nel.org>, srinivas.kandagatla@...aro.org,
        Shreyas NC <shreyas.nc@...el.com>,
        Sanyog Kale <sanyog.r.kale@...el.com>,
        Sudheer Papothi <spapothi@...eaurora.org>, alan@...ux.intel.com
Subject: Re: [alsa-devel] [PATCH 08/14] soundwire: Add Slave status handling
 helpers

On 11/1/17 4:08 AM, Vinod Koul wrote:
> On Wed, Nov 01, 2017 at 02:49:15AM +0530, Pierre-Louis Bossart wrote:
>>
>>>
>>>>> +		if (found == false) {
>>>>> +			/* TODO: Park this device in Group 13 */
>>>>> +			dev_err(bus->dev, "Slave Entry not found");
>>>>
>>>> No break here?  Otherwise...
>>>
>>> Thats intentional. We want to still read next device that show up
>>>
>>>>
>>>>> +		}
>>>>> +
>>>>> +	} while (ret == 0);
>>>>
>>>> ... the outer loop may go endlessly.
>>>> This condition doesn't look effective.
>>>
>>> not really. We cant keep reading successfully. At some point all slaves will
>>> ignore and return ENODATA and we exit. Bus errors will also make it exit
>>>
>>> BUT given that we have seen stuff i am inclined to add a counter, we cant
>>> have more than 11 device so that's a sane value to use :)
>>
>> Yep. Keep in mind however that there could be theoretical corner cases: if a
>> device is enumerated, loses sync and becomes attached again while you deal
>> with others, you'd have more than 11 iterations.
> 
> Not really as that would be another interrupt and another status report.

You are in a loop where you keep reading the devId registers, and that 
really has nothing to do with interrupts or status report. The point was 
that the number of times you read may be higher that the number of 
devices with a device being handled several times.
As mentioned above you need to limit this loop to a sane value.