On Wed, 2014-02-05 at 00:19 +0100, Daniel Vetter wrote: > On Wed, Feb 05, 2014 at 12:04:46AM +0200, Imre Deak wrote: > > On Tue, 2014-02-04 at 21:29 +0000, Chris Wilson wrote: > > > On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote: > > > > It's not signal safe and I got kms_flip in hung state with the backtrace > > > > below, while the parent process waiting for the signal helper to exit. > > > > It was quite easy to reproduce the bug by running > > > > > > > > kms_flip --run-subtest=flip-vs-dpms-off-vs-modeset > > > > > > snprintf is not signalsafe either (man 7 signal). X goes as far as > > > implementing its own limited pnprintf() instead. > > > > Thanks. I got only as far as to realize that asprintf is not signal-safe > > b/c of malloc and didn't remember any place with an official list of > > allowed functions.. > > > > I also missed at least igt_skip() calling vprintf(), so this needs some > > more thought. > > Hm, what calls igt_skip from exit handlers? That would be a fairly big bug > in the framework ... If it happens atm I guess we should splatter a few > more asserts all over the place. At least quiescent_gpu_at_exit()->__drm_open_any()->drm_get_card(). > For the actual issue at hand I dunno what to do. Trying to keep all exit > handlers signal-save seems like a lost cause since we'll always miss some > of them because normally they run as atexit callbacks. And libc isn't > friendly and tells us when we do something stupid. Overall this feels a > bit like a general reliability nightmare :( Yea, doing anything substantial in signal handlers doesn't seem like a good idea. I haven't found much info about what functions you can call from exit handlers, but I guess we should treat that case similarly to signal handlers. I think the only clean, safe and maintainable way is to run the actual test in a forked process and do any cleanup in case of error or normal exit in the parent wrapper process. We wouldn't install any cleanup signal handlers in the child (children), just let it die and have the wrapper process cleanup afterwards. If a signal handler for cleanup would be unavoidable it would be really simple and just communicate anything necessary to the wrapper so that it can do the actual cleanup. Forking helpers would happen with the control of the wrapper, using some IPC like a pipe/socket, where the wrapper would receive the pid of any newly forked helper and it could make sure none of those are left behind at exit. I would also use a different method for the (normal) termination of forked helpers. Atm, we do kill(SIGQUIT), but using some IPC (pipe) would be more robust imo. But, for the short term I would suggest auditing our current atexit handlers, and making them signal-safe. There are about 10 of those, so it's not (yet) unsurmountable. --Imre
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
