linux-kernel - Re: ALSA: intel8x0: div by zero in snd_intel8x0

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:   Wed, 7 Jul 2021 13:33:22 -0700
From:   Max Filippov <jcmvbkbc@...il.com>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        alsa-devel@...a-project.org, Leon Romanovsky <leon@...nel.org>,
        Takashi Iwai <tiwai@...e.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>
Subject: Re: ALSA: intel8x0: div by zero in snd_intel8x0_update()

On Wed, Jul 7, 2021 at 11:14 AM Takashi Iwai <tiwai@...e.de> wrote:
> On Wed, 07 Jul 2021 19:50:07 +0200, Max Filippov wrote:
> > It didn't change anything in my case. My further observation is that
> > the snd_intel8x0_update is called before the ichdev->prepared
> > is set to one and as a result IRQ is apparently never cleared.
>
> So it's broken in anyway no matter whether
> intel8x0_measure_ac97_clock() is called or not, right?

The change that you suggested didn't eliminate the call to
intel8x0_measure_ac97_clock, it's still called and an interrupt
flood happens at the same place.

I've also tried the following change instead and it fixes my issue:

diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c
index 5b124c4ad572..13d1c9edea10 100644
--- a/sound/pci/intel8x0.c
+++ b/sound/pci/intel8x0.c
@@ -692,11 +692,14 @@ static inline void snd_intel8x0_update(struct
intel8x0 *chip, struct ichdev *ich
       int status, civ, i, step;
       int ack = 0;

-       if (!ichdev->prepared || ichdev->suspended)
-               return;
-
       spin_lock_irqsave(&chip->reg_lock, flags);
       status = igetbyte(chip, port + ichdev->roff_sr);
+       if (!ichdev->prepared || ichdev->suspended) {
+               spin_unlock_irqrestore(&chip->reg_lock, flags);
+               iputbyte(chip, port + ichdev->roff_sr,
+                        status & (ICH_FIFOE | ICH_BCIS | ICH_LVBCI));
+               return;
+       }
       civ = igetbyte(chip, port + ICH_REG_OFF_CIV);
       if (!(status & ICH_BCIS)) {
               step = 0;


> I'm afraid that something is wrong in VM, then.  The driver has been
> working over decades on thousands of real different boards.
>
> Skipping the clock measurement on VM would be still useful,
> independent from your problem, though.

-- 
Thanks.
-- Max