Re: [PATCH] lib/drmtest: don't use asprintf on signal paths

[Imre Deak <imre.deak@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2892 bytes --]

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx