From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753899AbeBFWz4 (ORCPT ); Tue, 6 Feb 2018 17:55:56 -0500 Received: from mail-pl0-f54.google.com ([209.85.160.54]:45859 "EHLO mail-pl0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753610AbeBFWzy (ORCPT ); Tue, 6 Feb 2018 17:55:54 -0500 X-Google-Smtp-Source: AH8x225UsqvXsUnBGpKZVJoIlLikfXHBXMbvcZwrOHoQmrQA4uV7YaLEiPnxhvl717IZT1oCHTMpAA== Date: Tue, 6 Feb 2018 14:55:48 -0800 From: Minchan Kim To: Joel Fernandes Cc: LKML , Peter Zilstra , Michal Hocko , "open list:MEMORY MANAGEMENT" Subject: Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive Message-ID: <20180206225548.GB9680@eng-minchan1.roam.corp.google.com> References: <20180206004903.224390-1-joelaf@google.com> <20180206220159.GA9680@eng-minchan1.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 02:32:13PM -0800, Joel Fernandes wrote: > Hi Minchan, > > On Tue, Feb 6, 2018 at 2:01 PM, Minchan Kim wrote: > [...] > > On Mon, Feb 05, 2018 at 04:49:03PM -0800, Joel Fernandes wrote: > >> During invocation of ashmem shrinker under memory pressure, ashmem > >> calls into VFS code via vfs_fallocate. We however make sure we > >> don't enter it if the allocation was GFP_FS to prevent looping > >> into filesystem code. However lockdep doesn't know this and prints > >> a lockdep splat as below. > >> > >> This patch fixes the issue by releasing the reclaim_fs lock after > >> checking for GFP_FS but before calling into the VFS path, and > >> reacquiring it after so that lockdep can continue reporting any > >> reclaim issues later. > > > > At first glance, it looks reasonable. However, Couldn't we return > > just 0 in ashmem_shrink_count when the context is under FS? > > > > We're already checking if GFP_FS in ashmem_shrink_scan and bailing out > though, did I miss something? I understand your concern now. Apart from that, if ashmem_shrink_count is called under GFP_FS, you can just return 0 for removing pointless ashmem_shrink_scan calling. But it might be trivial so up to you. :) > > The problem is not that there is a deadlock that occurs, the problem > that even when we're not under FS, lockdep reports an issue that can't > happen. The fix is for the lockdep false positive that occurs. Yub, you are right. I am happy to add Reviewed-by: Minchan Kim