Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp663276ybx; Wed, 6 Nov 2019 06:37:00 -0800 (PST) X-Google-Smtp-Source: APXvYqyLC/Cn0zgMAl5R0RX2J5sVAgkbKDgouX52GntyPTG5QrC+zjFPCdF3IZRNwBAy2pNnmBC5 X-Received: by 2002:a50:de0b:: with SMTP id z11mr3085097edk.33.1573051020535; Wed, 06 Nov 2019 06:37:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573051020; cv=none; d=google.com; s=arc-20160816; b=OL4I8YPioUCeCZzPI+68OehLmNb8QURqVz8ls7v2Raz2QhG/GXvaidNIf5MYm8MKwK 3M8vhLL35B8A3aiiDBzwbwTC6yLzz9QJCX+mCvSQ0xwuAA8Qmmnp26iXSShI4tBjVpgF lEJvb2Gnne9oEsZe1TYcgUhzEvPcXNlisKxcGVveKjfbY/4VLot5HJBfychA0Diiwpjz Denkp+kDIg2uH15ZoT66WVNiiCSghEzgu0ISpRB9NlhFOuZjFgMF1/h3/XLmrtDOHkaE Zty/DoApom85unaZvmU79wEXwZ/AT/RP6ZTnG9DJj72bZOt9hNOPBsvN9kjLcMACD0sc KN2g== 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=JYzDEhyUhw0/7MohmPtJbUD84Rfml3eTRe935TCsfYg=; b=BtpMiXOCCnjBdR4GAClk7BA2zkMR8oUPb75YFcDtKCAIeBR2CYIbHCAXEmJsQit/pm hQiRevcxB7HiDymYWH/0g94jFnwl2vU5iaQB0iKlBCr69f5h1rf+3CSDkPJshr0Mi4wi KlOUioS0LCJxeow2SUu2kxhyHXJWXUU0EVn78Vz6XVLZDhezn+824kUxkXDRcn/XmrhC OY6ABaky1egCcDR3lIG1b8cWRI4RFXGfSIA3BpoX3oocg7t9kiSIw2gXVK/quY0JBC2P X22G20lwfeLm6pgTpeEKNASi5pV1FA/jZ0VdTWNO2QiHYjaur51mldRl8WBWKJQLhFyD kRxA== 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 y27si6168239ejb.147.2019.11.06.06.36.36; Wed, 06 Nov 2019 06:37:00 -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 S1731918AbfKFOfn (ORCPT + 99 others); Wed, 6 Nov 2019 09:35:43 -0500 Received: from mx2.suse.de ([195.135.220.15]:53090 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727031AbfKFOfn (ORCPT ); Wed, 6 Nov 2019 09:35:43 -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 95AB7B332; Wed, 6 Nov 2019 14:35:39 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 2E5811E4353; Wed, 6 Nov 2019 15:35:37 +0100 (CET) Date: Wed, 6 Nov 2019 15:35:37 +0100 From: Jan Kara To: snazy@snazy.de Cc: Jan Kara , Johannes Weiner , Vlastimil Babka , Michal Hocko , Josef Bacik , "Kirill A. Shutemov" , Randy Dunlap , linux-kernel@vger.kernel.org, Linux MM , Andrew Morton , "Potyra, Stefan" Subject: Re: mlockall(MCL_CURRENT) blocking infinitely Message-ID: <20191106143537.GI16085@quack2.suse.cz> References: <20191025132700.GJ17610@dhcp22.suse.cz> <707b72c6dac76c534dcce60830fa300c44f53404.camel@gmx.de> <20191025135749.GK17610@dhcp22.suse.cz> <20191025140029.GL17610@dhcp22.suse.cz> <20191105182211.GA33242@cmpxchg.org> <20191106120315.GF16085@quack2.suse.cz> <4edf4dea97f6c1e3c7d4fed0e12c3dc6dff7575f.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4edf4dea97f6c1e3c7d4fed0e12c3dc6dff7575f.camel@gmx.de> 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 Wed 06-11-19 14:45:43, Robert Stupp wrote: > On Wed, 2019-11-06 at 13:03 +0100, Jan Kara wrote: > > On Tue 05-11-19 13:22:11, Johannes Weiner wrote: > > > What I don't quite understand yet is why the fault path doesn't > > > make > > > progress eventually. We must drop the mmap_sem without changing the > > > state in any way. How can we keep looping on the same page? > > > > That may be a slight suboptimality with Josef's patches. If the page > > is marked as PageReadahead, we always drop mmap_sem if we can and > > start > > readahead without checking whether that makes sense or not in > > do_async_mmap_readahead(). OTOH page_cache_async_readahead() then > > clears > > PageReadahead so the only way how I can see we could loop like this > > is when > > file->ra->ra_pages is 0. Not sure if that's what's happening through. > > We'd > > need to find which of the paths in filemap_fault() calls > > maybe_unlock_mmap_for_io() to tell more. > > Yes, ra_pages==0 OK, thanks for confirmation! > 5637e22a2000-5637e22a3000 r--p 00000000 103:02 49172550 /home/snazy/devel/misc/zzz/test What kind of device & fs does your /home stay on? I don't recognize the major number... Honza -- Jan Kara SUSE Labs, CR