On Fri, Aug 29, 2003 at 10:03:57PM -0600, Kenneth D. Merry wrote: +> I've been working on a set of patches to remove the sysctl variable creation +> from interrupt context in the cd(4) and da(4) drivers. +> +> To fix the problem, I've created a new taskqueue that runs in a thread +> context, instead of inside a software interrupt like the current task +> queues. (The eventual fix will involve moving the CAM probe inside a +> thread; this will provide a more temporary solution that will hopefully +> also work on -stable, until we can change the CAM probe code.) +> +> I think I have everything setup correctly, but I keep getting panics inside +> the GEOM code with these patches. (Memory modified after free.) I don't +> know whether I've just exposed some race condition, or whether I've done +> something wrong. +> +> I've seen several different panics, all with the same root cause (memory +> modified after free), and with two different previous memory pools -- geom +> and devbuf. I was getting same panics while I was working on GEOM Gate. After many hours of debugging I've tracked this down - I've initialized a mutex, but I haven't destroy it. As I susspect you're loading cd(4) as kld module? It seems, that you're making exactly same bug: mtx_init(&kthread_mutex, "taskqueue kthread", NULL, MTX_DEF); And where is mtx_destroy()? -- Pawel Jakub Dawidek pawel_at_dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:20 UTC