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, 21 Jun 2017 17:30:10 +0200 From: Takashi Iwai <tiwai@...e.de> To: "Chris Wilson" <chris@...is-wilson.co.uk> Cc: "Intel Graphics Development" <intel-gfx@...ts.freedesktop.org>, "Daniel Vetter" <daniel.vetter@...ll.ch>, "Guneshwor Singh" <guneshwor.o.singh@...el.com>, "Hardik T Shah" <hardik.t.shah@...el.com>, "Libin Yang" <libin.yang@...el.com>, "Subhransu S. Prusty" <subhransu.s.prusty@...el.com>, "Vinod Koul" <vinod.koul@...el.com>, "Julia Lawall" <Julia.Lawall@...6.fr>, "Jaroslav Kysela" <perex@...ex.cz>, <tiwai@...e.de>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support On Wed, 21 Jun 2017 17:23:57 +0200, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-06-21 16:08:54) > > So back when the i915 power well support landed in > > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6 > > Author: Wang Xingchao <xingchao.wang@...ux.intel.com> > > Date: Thu May 30 22:07:10 2013 +0800 > > > > ALSA: hda - Add power-welll support for haswell HDA > > > > the logic to handle the cross-module depencies was hand-rolled using a > > async work item, and that just doesn't work. > > > > The correct way to handle cross-module deps is either: > > - request_module + failing when the other module isn't there > > > > OR > > > > - failing the module load with EPROBE_DEFER. > > > > You can't mix them, if you do then the entire load path just > > busy-spins blowing through cpu cycles forever with no way to stop > > this. > > > > snd-hda-intel does mix it, because the hda codec drivers are loaded > > using request_module, but the i915 depency is handled using > > PROBE_DEFER (or well, should be, but I haven't found any code at all). > > This is a major pain when trying to debug i915 load failures. > > > > This patch here is a horrible hackish attempt at somewhat correctly > > wriing EPROBE_DEFER through. Stuff that's missing: > > - Check all the other places where load errors are conveniently > > dropped on the floor. > > - Also fix up the firmware_cb path. > > - Drop the debug noise I've left in to make it clear this isn't > > anything for merging. > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was > continuously spewing previously, and now the system is usable again. Could you give a failing scenario? I'm not opposing to the suggested solution, we need to fix the mess in anyway, but I just would like to know how to trigger the problem easily. thanks, Takashi
Powered by blists - more mailing lists