From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755350AbcDMTA3 (ORCPT ); Wed, 13 Apr 2016 15:00:29 -0400 Received: from mail-yw0-f193.google.com ([209.85.161.193]:33721 "EHLO mail-yw0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755064AbcDMTA2 (ORCPT ); Wed, 13 Apr 2016 15:00:28 -0400 Date: Wed, 13 Apr 2016 15:00:25 -0400 From: Tejun Heo To: Ben Greear Cc: Linux Kernel Mailing List Subject: Re: Deadlock related to file permissions and/or cgroup, 4.4.6+ Message-ID: <20160413190025.GJ3676@htj.duckdns.org> References: <5706D84D.6070706@candelatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5706D84D.6070706@candelatech.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Thu, Apr 07, 2016 at 02:59:41PM -0700, Ben Greear wrote: > This is from a modified 4.4.6+ kernel, with local patches. Git tree found > below, but I don't think this lockup is related to any local changes we have made. > > http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary > > The test case involves using a libcurl based application that > is making an ftp request to a second port on the same machine. > vsftp is serving up the ftp file. > The ports are looped together with an ethernet cable, and routing rules > are set up so that traffic flows over the external interface. > > The key change from a working solution and kernel deadlock, is that > with the file-to-be-read has permissions 700, it fails, but 600 > does not. (As I was writing this up, our system-test guy managed to > lock it up with 600 permissions as well, so it is not *just* related to > permission 700). > > This is very repeatable permissions 700. > > The tainting probably comes from a warning in another (GPL, but out-of-tree module that we write), > but very unlikely that has anything to do with this issue. Can you please try to reproduce the problem with lockdep turned on and without the out-of-tree module? Lockdep should be able to point to where the actual deadlock is happening. Thanks. -- tejun