linux-kernel - Re: [PATCH] ALSA: pcm: fix incorrect hw

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]

Date:   Fri, 15 May 2020 14:01:57 +0200
From:   Jaroslav Kysela <perex@...ex.cz>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     "Lu, Brent" <brent.lu@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        Takashi Iwai <tiwai@...e.com>,
        Baolin Wang <baolin.wang@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Richard Fontana <rfontana@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        paulhsia <paulhsia@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ALSA: pcm: fix incorrect hw_base increase

Dne 15. 05. 20 v 12:39 Takashi Iwai napsal(a):
> On Fri, 15 May 2020 11:30:54 +0200,
> Jaroslav Kysela wrote:
>>
>> Dne 15. 05. 20 v 11:04 Lu, Brent napsal(a):
>>>>
>>>> Is this a bugfix needed for older kernels as well?  When did this issue show
>>>> up?
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>
>>> It happens when DMA stop moving data from host to DSP/DAI for a long time
>>> (> half of buffer time). I know host driver should do something about it. But if
>>> not, the HWSYNC will keep increasing the hw_base and hw_ptr and confuses
>>> user space program.
>>
>> I'm afraid, but with this code, you turn off the hw_ptr jiffies
>> code. It would be better to fix the driver in this case (return the
>> updated / estimated DMA pointer, increase DMA buffer size etc.). This
>> "lag" is unacceptable.
> 
> The problem is obviously in the driver's side and it's best to be
> addressed there.  But, I think it's still worth to apply this change.
> 
> The hw_ptr jiffies check is performed basically in two places: one is
> snd_pcm_period_elapsed() call from ISR, and another is with the
> no_period_wakeup flag.  In both cases, it calculates the diff of
> jiffies from the previous update, and corrects the hw_ptr_base if that
> exceeds the threshold.
> 
> And the bug here is that the "previous" jiffies is kept as long as the
> hwptr itself is updated.  What we need is the correction of the base
> when it really has processed the period size; i.e. hwptr got the same
> value (with no_period_wakeup) and yet the jiffies diff is big.  For
> this check, it's correct to update hw_ptr_jiffies at each call no
> matter whether hwptr moved or not; we need to evaluate from the
> previous update, after all.
> 
> But I might overlook something.  Jaroslav, could you check it again?
> The jiffies check code is your black magic :)

I tried to imagine a negative impact for this hw_ptr_jiffies update when the 
DMA position is not updated from the driver and I haven't found any so far.

Let's apply this and we'll see in future :-)

And yes, the patch description should be improved (DMA ptr is not updated / 
streaming is inactive).

Reviewed-by: Jaroslav Kysela <perex@...ex.cz>

> 
> 
> thanks,
> 
> Takashi
> 


-- 
Jaroslav Kysela <perex@...ex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.