From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755323AbcBCBnU (ORCPT <rfc822;w@1wt.eu>);
	Tue, 2 Feb 2016 20:43:20 -0500
Received: from out1-smtp.messagingengine.com ([66.111.4.25]:37333 "EHLO
	out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1755201AbcBCBnT (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 2 Feb 2016 20:43:19 -0500
X-Sasl-enc: +3lCu2/7zvP9Ll1nO3W/ulBd6yiDngtp497Dy1XNBN4P 1454463798
Subject: Re: Bug 4.1.16: self-detected stall in net/unix/?
To: Philipp Hahn <pmhahn@pmhahn.de>, Sasha Levin <sasha.levin@oracle.com>,
        Rainer Weikusat <rweikusat@mobileactivedefense.com>,
        Andrey Vagin <avagin@openvz.org>, Aaron Conole <aconole@bytheb.org>,
        "David S. Miller" <davem@davemloft.net>, linux-kernel@vger.kernel.org
References: <56B0D88A.1020609@pmhahn.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Message-ID: <56B15B32.1020701@stressinduktion.org>
Date: Wed, 3 Feb 2016 02:43:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <56B0D88A.1020609@pmhahn.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 02.02.2016 17:25, Philipp Hahn wrote:
> Hi,
>
> we recently updated our kernel to 4.1.16 + patch for "unix: properly
> account for FDs passed over unix sockets" and have since then
> self-detected stalls triggered by the Samba daemon:
>
 > >
 > > [...]
 > >
>
> We have not yet been able to reproduce the hang, but going back to our
> previous kernel 4.1.12 makes the problem go away.

Can you remove the patch "unix: properly account for FDs passed over 
unix sockets" and see if the problem still happens?

I couldn't quickly see any problems with your added patch. I currently 
suspect a tight loop because of a SOCK_DEAD flag set but the socket not 
removed from unix_socket_table or the vfs. Hmmm...

The stack trace is rather unreliable, maybe something completely 
different happend. Do you happend to see better reports?

> Is this a known issue or do you have an idea where to look?
> What information should I collect next time it happens?
>
> (Can unix_diag.ko with `ss` help?)

Would be interesting if it is a conventional file based socket or 
autobounded one (sun_path[0] != '\0').

Thanks,
Hannes