From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758151AbbKSJjm (ORCPT ); Thu, 19 Nov 2015 04:39:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34856 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755978AbbKSJjk (ORCPT ); Thu, 19 Nov 2015 04:39:40 -0500 Subject: Re: Asterisk deadlocks since Kernel 4.1 To: Stefan Priebe References: <564B3D35.50004@profihost.ag> <564B7F9D.5060701@profihost.ag> <564CDE2F.8000201@profihost.ag> <564CEB0C.40006@redhat.com> <564CEC65.4080901@profihost.ag> Cc: Thomas Gleixner , netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org From: Florian Weimer X-Enigmail-Draft-Status: N1110 Message-ID: <564D98D8.9050000@redhat.com> Date: Thu, 19 Nov 2015 10:39:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564CEC65.4080901@profihost.ag> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/18/2015 10:23 PM, Stefan Priebe wrote: >> please try to get a backtrace with debugging information. It is likely >> that this is the make_request/__check_pf functionality in glibc, but it >> would be nice to get some certainty. >> >> Which glibc version do you use? Has it got a fix for CVE-2013-7423? > > It's Debians 2.13-38+deb7u8 Debians issue tracker says it is fixed: > https://security-tracker.debian.org/tracker/CVE-2013-7423 I checked, and the patch is there and applied. >> Theoretically, recvmsg could also hang if the Netlink query was dropped >> by the kernel, or the final packet in the response was dropped. We >> never saw that happen, even under extreme load, but I didn't test with >> recent kernels. > > The load is very low in this system. Just 30 phones and only 1-6 calling. This is rather odd. I'm not sure if we can do anything simple on the glibc to help to debug this. If something in the process consumes the Netlink message from the kernel (incorrectly reading from the internal glibc file descriptor), this is fairly difficult detect inside glibc (it would require rather large changes which do not currently exist at all). Florian