On 07/09, Frederic Weisbecker wrote: > > The UMH_WAIT_PROC handler runs in its own thread for obsolete reasons. > We couldn't launch and then wait for the exec kernel thread completion > without blocking other usermodehelper queued jobs since khelper was > implemented as a singlthread ordered workqueue. > > But now we replaced khelper with generic system unbound workqueues which > can handle concurrent blocking jobs. > > So lets run it from the workqueue.
Probably this is fine, but I am a bit worried... WQ_MAX_ACTIVE == 512, this should be enough "in practice". But nothing protects us from creative driver(s) which spawns 512 long-living user space tasks... Note also that userpace can ptrace these task and "block" sys_wait() forever. I am worried ;) > CHECK: I'm just worried about the signal handler that gets tweaked > and also the call to sys_wait() that might fiddle with internals. The > system workqueue must continue to work without surprise for other > works. Yes. This means that this patch is wrong without disallow_signal() at the end. Oleg. -- 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/
