Received: by 10.223.176.5 with SMTP id f5csp1291038wra; Wed, 7 Feb 2018 16:37:02 -0800 (PST) X-Google-Smtp-Source: AH8x225Rr4L/eg0Sj9CsX5NAZp+W/BCXY7x/JY4ii6P57V5uak31oKq6zJZQrOJXdk7aCYFgcvWa X-Received: by 10.98.195.2 with SMTP id v2mr7560699pfg.141.1518050222015; Wed, 07 Feb 2018 16:37:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518050221; cv=none; d=google.com; s=arc-20160816; b=Kp2aY07993vqSdJls8vR92E6hPzUHWyZoFzBMKYp5PCRzgfBFICHMPpYYoJeQVro/U O2H2BxeKkTpHDLumUMsQHr7/RtvziSFwEGc+qtoqvN1cSegNFwGHgOViNMvtRPkM7fvb xapTiJrZ2mcr+yMONwWwfDCNWySPjGD8uCuFL03CDVZt4q2Bp04ykWFOH4jNOoMde5O2 EnfoLStnLQSF0o5yvS9nsqcGTr+s+NftJIYlMkRWPf2O+hciVZ8Ok52rqKhGztbjMqzZ P38RFkO3NOsto4icP3JvT259nyn1xZ52tePwtBkVPPS6MKEwqSUEBwF5hXETwAKZS3c/ A7zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:references :in-reply-to:subject:cc:date:to:from:arc-authentication-results; bh=XPn72AZ903ywK32JU5RTEE7p2KqHHONRFY+ZiIje4Yg=; b=RlUm73z+UUfK5JWx9/rL6SEJgAl04X26XrU9KlUkeJ19xJpePV9BXdflCbLXyxFwgq xo14k/nKrxpxry8DiGrp0bIokGBrLvPwCZdRPyKnnfv3oYgAYbGYeBiVi4jDcOcnGBkG bO5X/m9cO7Vsv9KgzG7jg3cnYCaqzgAJlCblMTRd570TZm5NduD1tHB5dDir+o5aOkfi o14KSduNcIT7mmmzgSO4rTNtaM7xi/j0pB29n3o/QN9StoiowrQeip/vWp7LAE2SjZJP qSOf//D+14EmtRUfzF9pm3aiKy1cxGYWK6UiQvtRx1zP8l23ySrVhtJvQiQOzHifDwi3 4NUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y3si1634330pgb.145.2018.02.07.16.36.47; Wed, 07 Feb 2018 16:37:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751788AbeBHAgA (ORCPT + 99 others); Wed, 7 Feb 2018 19:36:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:38904 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750806AbeBHAf6 (ORCPT ); Wed, 7 Feb 2018 19:35:58 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F0F78AB1D; Thu, 8 Feb 2018 00:35:56 +0000 (UTC) From: NeilBrown To: Joel Fernandes , Peter Zijlstra Date: Thu, 08 Feb 2018 11:35:43 +1100 Cc: LKML , Michal Hocko , Minchan Kim , "open list\:MEMORY MANAGEMENT" , Theodore Ts'o , linux-fsdevel@vger.kernel.org, Dave Chinner Subject: Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive In-Reply-To: References: <20180206004903.224390-1-joelaf@google.com> <20180207080740.GH2269@hirez.programming.kicks-ass.net> <20180207165802.GC25219@hirez.programming.kicks-ass.net> Message-ID: <87k1vomi74.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain On Wed, Feb 07 2018, Joel Fernandes wrote: > Hi Peter, > > On Wed, Feb 7, 2018 at 8:58 AM, Peter Zijlstra wrote: > [...] >> >>> Lockdep reports this issue when GFP_FS is infact set, and we enter >>> this path and acquire the lock. So lockdep seems to be doing the right >>> thing however by design it is reporting a false-positive. >> >> So I'm not seeing how its a false positive. fs/inode.c sets a different >> lock class per filesystem type. So recursing on an i_mutex within a >> filesystem does sound dodgy. > > But directory inodes and file inodes in the same filesystem share the > same lock class right? Not since v2.6.24 Commit: 14358e6ddaed ("lockdep: annotate dir vs file i_mutex") You were using 4.9.60. so they should be separate.... Maybe shmem_get_inode() needs to call unlock_new_inode() or just lockdep_annotate_inode_mutex_key() after inode_init_owner(). Maybe inode_init_owner() should call lockdep_annotate_inode_mutex_key() directly. NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlp7m2AACgkQOeye3VZi gbmNRRAAqi6V+r4APrjzTHcs4mwJs7pCOqF/4P0knHwKGEeWt4ZVlToQAKVo93bB Qm8g3Q80Xi242xobzmgDJBRSxdfU0E1TeqRU6UH+GWLAhLpZmGNhn6rDGmUDK/vQ SuAh52OUpGZ6qbe/1A3+4igCC1clK9kmhNyofLc6qt1OesiqlX7/P3EQ3/eLDu/A cF6RZJ2XtvxkHORl9eysHd131xOxvCH/0oC/h86qVUg/eqAU7P19BMJUU2veGY4t FwRqJlqo98vcdPVKMVqOjH2bNbRbR+ggS8BQ/cXKRIz9nH37tRT0NUDL6lLS50k+ tV9I9YLpXrA5dIIeC7Ruh6ny5uz1voFqH70Y+ILxy1BFdkoVGC2xMAEHpo5HoAj/ cImyNayfD5IoT2yYI6nbYmzAEo2pXDDxojDrN9XA46WSL0ToYwHoOdTFDFPmYlTC iSMWvM666qy/1DdF/woeHR2v9pIOn9D9N1r1lKGS8ou1sA8KSdnRoIj6ajeVybdP rQ7p5XWrnnYA2bmbZttyMstGCtgIUhCPyz9bWpZ8HMRlA/gKB03csfDOyCGGjnBg jY+C9DJei6mxKPFyZl/eSs8bhD3Np8v+PgU/Vm418QUCu4gSQ+tl7qX5F4wuq3Hg oWfWdrKz5jpXWKE7PwM0+DD7YubTtXY2QeBRqaNTnBcWQOG1+VU= =M4FL -----END PGP SIGNATURE----- --=-=-=--