Hello, On Wed, Feb 12, 2014 at 04:57:53PM +0100, Borislav Petkov wrote: > Ha, so this sounds like the issue because the splat happens > when updating /sys/.../edac_mc_poll_msec and it goes and calls > edac_mc_workq_setup()... > > And this code is pretty old and edac_mc_workq_setup() is used both > when one inits an edac driver and also when one wants to change the > polling period (edac_mc_reset_delay_period) and thus needs to mod the > workqueue's timeout. > > So I'm guessing a simple fix would be to differentiate between the two > paths, something like the diff below. > > Or is there a reliable way to check whether a workqueue has been > initialized already, say, something like > > if (work->func)
Hah... can't you just do it on object initialization? It's a bit nasty and fragile to game initialization state. > or so... I.e., what PREPARE_WORK() does? It allows you to change the callback without breaking the synchronization. Of course, if there's a pending work item, it may or may not execute the newly assigned function. It's also a bit nasty and has only few users in the whole kernel and I think we might wanna get rid of them. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
