From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751539AbaLCRfg (ORCPT ); Wed, 3 Dec 2014 12:35:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39156 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750730AbaLCRfe (ORCPT ); Wed, 3 Dec 2014 12:35:34 -0500 Date: Wed, 3 Dec 2014 18:34:48 +0100 From: Oleg Nesterov To: "Kirill A. Shutemov" Cc: "David S. Miller" , Linus Torvalds , Andrew Morton , Alexander Viro , Cyrill Gorcunov , David Howells , "Eric W. Biederman" , "Kirill A. Shutemov" , Peter Zijlstra , Sasha Levin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Alexey Dobriyan , netdev@vger.kernel.org Subject: Re: [PATCH v2 4/7] fs/proc/task_mmu.c: shift mm_access() from m_start() to proc_maps_open() Message-ID: <20141203173448.GA4003@redhat.com> References: <20140805194627.GA30693@redhat.com> <20140805194655.GA30728@redhat.com> <20141203141433.GA25683@node.dhcp.inet.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141203141433.GA25683@node.dhcp.inet.fi> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/03, Kirill A. Shutemov wrote: > > On Tue, Aug 05, 2014 at 09:46:55PM +0200, Oleg Nesterov wrote: > > A simple test-case from Kirill Shutemov > > > > cat /proc/self/maps >/dev/null > > chmod +x /proc/self/net/packet > > exec /proc/self/net/packet > > > > makes lockdep unhappy, cat/exec take seq_file->lock + cred_guard_mutex in > > the opposite order. > > Oleg, I see it again with almost the same test-case: > > cat /proc/self/stack >/dev/null > chmod +x /proc/self/net/packet > exec /proc/self/net/packet Yes, there are more lock_trace/mm_access (ab)users. Fortunately, they are much simpler than proc/pid/maps (which also asked for other cleanups and fixes). I'll try to take a look, thanks for reminding. And I agree with Eric, chmod+x probably makes no sense. Still I think this code deserves some cleanups regardless. To the point I think that lock_trace() should probably die. Thanks! Oleg.