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
| ||
|
Date: Wed, 6 Feb 2019 12:14:56 +0100 From: Krzysztof Kozlowski <krzk@...nel.org> To: Charles Keepax <ckeepax@...nsource.cirrus.com> Cc: Sylwester Nawrocki <s.nawrocki@...sung.com>, Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org, linux-kernel@...r.kernel.org, "linux-samsung-soc@...r.kernel.org" <linux-samsung-soc@...r.kernel.org>, Marek Szyprowski <m.szyprowski@...sung.com> Subject: Re: [PATCH] ASoC: dapm: Check for NULL widget in dapm_update_dai_unlocked On Wed, 6 Feb 2019 at 12:00, Charles Keepax <ckeepax@...nsource.cirrus.com> wrote: > > On Wed, Feb 06, 2019 at 11:22:33AM +0100, Krzysztof Kozlowski wrote: > > On Wed, 6 Feb 2019 at 11:05, Charles Keepax > > <ckeepax@...nsource.cirrus.com> wrote: > > > > > > DAIs linked to the dummy will not have an associated playback/capture > > > widget, so we need to skip the update in that case. > > > > > > Fixes: 078a85f2806f ("ASoC: dapm: Only power up active channels from a DAI") > > > Signed-off-by: Charles Keepax <ckeepax@...nsource.cirrus.com> > > > --- > > > > > > Ok so that all makes sense, this patch is probably the best fix? > > > > > > Thanks, > > > Charles > > > > For this particular issue (NULL-pointer): > > Reported-by: Krzysztof Kozlowski <krzk@...nel.org> > > Tested-by: Krzysztof Kozlowski <krzk@...nel.org> > > > > However now I see bug sleeping in atomic context: > > > > [ 64.000828] BUG: sleeping function called from invalid context at > > ../kernel/locking/mutex.c:908 > > Does this probably definitely get fixed by reverting my patch? > It's just a bit odd as this seems to be complaining about a clock > operation in i2s_trigger and I don't think my patch should have > any affect on the trigger callback. It should get run from either > the dai_link DAPM event or hw_params, neither of which should > happen in an atomic context. Before this fixup, probably NULL pointer happened before any of this. I tried it now few times and the possible deadlock and sleeping in invalid context did not appear. It might be random/racy or totally unrelated to your change. Best regards, Krzysztof
Powered by blists - more mailing lists