Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3747644imu; Tue, 18 Dec 2018 03:35:51 -0800 (PST) X-Google-Smtp-Source: AFSGD/XHv3Fgxg29pZezC+DnJFMOQspVuL18fcxdv0Kz1xNhGMYZ6ipDsELfIgqf4yS9ofyntQgH X-Received: by 2002:a17:902:bb05:: with SMTP id l5mr16492725pls.230.1545132951907; Tue, 18 Dec 2018 03:35:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545132951; cv=none; d=google.com; s=arc-20160816; b=KehjSTeDl4IP97KdBM6V4sywrdBu8MwXtS7m6WjZERUhifkD9XdcgZyjuSlbEAfXqb qw8k2BcTrLji34D6bQcQgmUkQq/A95XGjnxZt9qqMu8RauL5OlU/BHGjuJ0bb9dRjqX1 cyBQOW4OmRX4CNLXQSwh6A47aeo3gJDT9NTnlmBeKfPEnLNnTzC0UBLBetXRonowpcB7 msB5Z2W85ZEVSIwETdoPR/QjxHC2JFObUioo0AJ8E7O7QO5J5FpXgAiqWm66z1GBP1Vv eFxHDjOX5aCbtqF9mhZqJx1IHuztIL2RrMgC1jmsl4+Fth7gN2f3SIFnLjCNEn3fUhE8 rwDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=IaJOXImVkOsdHqVEx4jiQS5V9EVbv/21tKE0Vg6WhxQ=; b=aNoqaJ8a4pOkWs0vJoHMDilV0PEyU374B0mjvv/rnt9WUF3ohx2ENvm5K+uhAIas2V 68eigJN8NNG4kmfUsURevVcTk9iMxf0Bc2ZPwayitn0BGGNKU7hbCpnI++Pn03deSGfW EP14+O+6T6dIlTucMlNNT0UIddg5769HeyVwAsnvACwhulnZvaChKGKhLhglrhKxM7b+ TNgonYoTCX/6ITsm2dTePar4EFNzPnRLGN4sNdwhpcLEx8yvTG92mY0Q72RJlnBTqgLm JAb0kyWHF69d8DFVdkIOOxJgd2k3jlsC2s4KCFGyP9LvVnumMhl+NoyTSHdE0np1qDKa LQXQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l36si10897069plb.433.2018.12.18.03.35.35; Tue, 18 Dec 2018 03:35:51 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726594AbeLRLce (ORCPT + 99 others); Tue, 18 Dec 2018 06:32:34 -0500 Received: from mx2.suse.de ([195.135.220.15]:49422 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726341AbeLRLcd (ORCPT ); Tue, 18 Dec 2018 06:32:33 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D9D0BB14B; Tue, 18 Dec 2018 11:32:31 +0000 (UTC) Date: Tue, 18 Dec 2018 12:32:30 +0100 From: Michal Hocko To: Hou Tao Cc: Tetsuo Handa , Matthew Wilcox , phillip@squashfs.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] squashfs: enable __GFP_FS in ->readpage to prevent hang in mem alloc Message-ID: <20181218113230.GI30879@dhcp22.suse.cz> References: <20181204020840.49576-1-houtao1@huawei.com> <20181215143824.GJ10600@bombadil.infradead.org> <69457a5a-79c9-4950-37ae-eff7fa4f949a@huawei.com> <20181217035157.GK10600@bombadil.infradead.org> <20181217093337.GC30879@dhcp22.suse.cz> <00ff5d2d-a50f-4730-db8a-cea3d7a3eef7@I-love.SAKURA.ne.jp> <5ba9aba1-e00d-ae07-caf0-3e7eca7de4b6@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ba9aba1-e00d-ae07-caf0-3e7eca7de4b6@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 18-12-18 14:06:11, Hou Tao wrote: [...] > In my understanding (correct me if I am wrong), there are three ways through which > reclamation will invoked fs related code and may cause dead-lock: > > (1) write-back dirty pages. Not possible for squashfs. only from kswapd context. So not relevant to OOM killer/ > (2) the reclamation of inodes & dentries. The current file is in-use, so it will be not > reclaimed, and for other reclaimable inodes, squashfs_destroy_inode() will > be invoked and it doesn't take any locks. There are other inodes, not only those in use. Do you use any locks that could be taken from an inode teardown? -- Michal Hocko SUSE Labs