From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 14 Jan 2016 17:13:41 +0000 From: Al Viro To: Tomeu Vizoso Cc: "linux-kernel@vger.kernel.org" , Linus Torvalds , Neil Brown , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2 06/11] don't put symlink bodies in pagecache into highmem Message-ID: <20160114171341.GY17997@ZenIV.linux.org.uk> References: <20151209053209.GV20997@ZenIV.linux.org.uk> <1449639295-20512-6-git-send-email-viro@ZenIV.linux.org.uk> <20160114152553.GW17997@ZenIV.linux.org.uk> <20160114162333.GX17997@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: On Thu, Jan 14, 2016 at 05:57:42PM +0100, Tomeu Vizoso wrote: > Here it is: > > [ 170.715356] inode: ec8c30b0, pages: 1 > [ 170.719014] page_address: (null) > > https://lava.collabora.co.uk/scheduler/job/127698/log_file Lovely... And that looks like the first time that inode hits nfs_get_link(). Ho-hum... Could you add WARN_ON(inode->i_mapping.nrpages) in inode_nohighmem() and see if that triggers? It really shouldn't (we hit it after iget5_locked() in nfs_fhget() has returned us a new inode, and there shouldn't be a chance for any pages to get in there between struct inode allocation and that point), but then neither should highmem pages be added to address_space without __GFP_HIGHMEM in ->flags...