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:   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.

Powered by blists - more mailing lists