linux-kernel - Re: [PATCH] ASoC: da7219: Improve the IRQ process to increase the stability

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, 15 Feb 2023 23:01:09 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Guenter Roeck <groeck@...gle.com>
Cc:     David Rau <David.Rau.opensource@...renesas.com>,
        support.opensource@...semi.com, lgirdwood@...il.com,
        perex@...ex.cz, tiwai@...e.com, alsa-devel@...a-project.org,
        linux-kernel@...r.kernel.org, bailideng@...gle.com,
        Guenter Roeck <groeck@...omium.org>
Subject: Re: [PATCH] ASoC: da7219: Improve the IRQ process to increase the
 stability

On Wed, Feb 15, 2023 at 08:06:35AM -0800, Guenter Roeck wrote:
> On Wed, Feb 15, 2023 at 5:10 AM Mark Brown <broonie@...nel.org> wrote:

> > Copying in Guenter given the issues he raised with this, not
> > deleting context for his benefit.  It looks like this should
> > avoid the issues with the interrupt appearing locked up.

> It should since it limits the delay to cases where jack_inserted is
> false, but on the other side it hides the delay in an odd way.
> 
...

> Effectively this seems to be quite similar to moving the conditional
> sleep to the place where cancel_work_sync() is called. I would assume
> that will fix the problem (after all, the msleep() is no longer called
> unconditionally), but I don't see the benefit of introducing a worker
> to do that. Also, since there is no guarantee that the worker actually
> started by the time cancel_work_sync() is called, I would suspect that
> it may result in unexpected behavior if the worker has not started by
> that time, which I would assume can happen if the system is heavily
> loaded. It also makes the use of the ground switch (i.e., when to set
> and when to drop it) even more of a mystery than it is right now.

> Having said that, I don't really know or understand the code, so maybe
> this all makes sense and my feedback should be ignored.

Yes, I would certainly welcome more clarity especially around the
ground switch.  OTOH it does seem like an improvement over the
current situation so I think I'll go ahead and apply it for now,
hopefully it can be improved upon in future.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)