Re: glibc mutex deadlock in signal handler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> Perhaps we should reconsider whether f4c3edc (vreportf: avoid
> intermediate buffer, 2015-08-11) is a good idea.  Note that snprintf is
> not on the list of safe functions, but I imagine that in practice it is
> fine. Though just avoiding error()/warning() in signal handlers might be
> a more practical solution anyway.

I had exactly the same thought when I read the initial report here.

I wish we can just do "if (in_signal) return;" at the beginning of
vreportf(), but we would not want a global variable there, so... ;-)

Further, I briefly hoped that avoiding error/warning in the signal
handler codepath would allow us to be more lax around allocations,
but I suspect that it unfortunately would not help us that much, as
we may be calling these functions in low memory situations.

So let's queue Takashi's patch as-is for now and look at other
signal codepaths.

Thanks.

	
	
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]