From patchwork Sat Feb 4 00:00:49 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dan Williams X-Patchwork-Id: 723971 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3vFYm706vbz9s76 for ; Sat, 4 Feb 2017 11:00:54 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="gk3Vbh6e"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752825AbdBDAAw (ORCPT ); Fri, 3 Feb 2017 19:00:52 -0500 Received: from mail-oi0-f43.google.com ([209.85.218.43]:36119 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752871AbdBDAAv (ORCPT ); Fri, 3 Feb 2017 19:00:51 -0500 Received: by mail-oi0-f43.google.com with SMTP id u143so20165321oif.3 for ; Fri, 03 Feb 2017 16:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lKAfV3FOyT7pGwoyWP9db58D/noUIztH5ezXnzCPJiI=; b=gk3Vbh6e87pu9ZYFcbiHf2Wo+IT26Fxa22yL74gU2qeANsiCDeDuCE0pxoRhEhGYc4 +2MB1Yk1/f/u2jWSKwuHBiiSOcNt8kdU7eQIyfYDoOhOyLwVC5tNgYxhyYUrxIvRo4sE 2ovDgeOsvoRlGQBkJXsGI8AGyT1hSy64PeDIVuJqjSuOwzOkaMIl+k4RJrF2D8dqvpIH znadc177tViXtD36E4Ko0uZFmVttuq+9LQN2CMmFSmItlTe2aGfKh4ZccN4C4YNd/dmU ldVqSZ2r3vaeyv9PkQwFH/G0ZKSog/HcpURCFEGslw2cXaOhrqtkcYCxEYrKqTUxFZqD a5Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lKAfV3FOyT7pGwoyWP9db58D/noUIztH5ezXnzCPJiI=; b=NgWKY01NBPzelZRltswH1GermJUqggVPX9XCYO0b1CDjdhPYvIE1FR4sOZWg4Zrdnk F81k+3P6VRlpaRI4XgF/1uYWr4rwFAvHsRKb5e+4afrcNcVLwvJi4Um6wSFWc9o6lkxX DK8pXj7dINzQ63rrAr3i11W7ulN7/DW/fmXzJmdx65IVkWmv2/IR6PIJHEkB+piwtrI8 erMeSg3gx6BNn4W5XSMEuvnHAj4r7mBE8IRAY+ViKf7H0Kzwu6iTNPzZquApy+Kg4nKt EM0aSioRMAhtYCzOUlCNQp09iT7zSOARFGvIEXbmv780sh5N+x4uGMBPZb+Im5gFy98x Pu1g== X-Gm-Message-State: AIkVDXIrd0C9StrjZFnINM0QWu9ni47c1OIZKleuN91ld+emJwLlbFqowpR9K9IJJqEPUYSCaYFMUMklXDWTjxWI X-Received: by 10.202.181.11 with SMTP id e11mr8599098oif.57.1486166450345; Fri, 03 Feb 2017 16:00:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.27.228 with HTTP; Fri, 3 Feb 2017 16:00:49 -0800 (PST) In-Reply-To: References: <201702040648.oOjnlEcm%fengguang.wu@intel.com> <2020f442-8e77-cf14-a6b1-b4b00d0da80b@intel.com> From: Dan Williams Date: Fri, 3 Feb 2017 16:00:49 -0800 Message-ID: Subject: Re: [PATCH] mm: replace FAULT_FLAG_SIZE with parameter to huge_fault To: Dave Jiang Cc: kbuild test robot , kbuild-all@01.org, Andrew Morton , Matthew Wilcox , "linux-nvdimm@lists.01.org" , Dave Hansen , linux-xfs@vger.kernel.org, Linux MM , "Kirill A. Shutemov" , Jan Kara , linux-ext4 , Ross Zwisler , Vlastimil Babka Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri, Feb 3, 2017 at 3:26 PM, Dan Williams wrote: > On Fri, Feb 3, 2017 at 3:25 PM, Dave Jiang wrote: >> On 02/03/2017 03:56 PM, kbuild test robot wrote: >>> Hi Dave, >>> >>> [auto build test ERROR on mmotm/master] >>> [cannot apply to linus/master linux/master v4.10-rc6 next-20170203] >>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] >> >> This one is a bit odd. I just pulled mmotm tree master branch and built >> with the attached .config and it passed for me (and I don't see this >> commit in the master branch). I also built linux-next with this patch on >> top and it also passes with attached .config. Looking at the err log >> below it seems the code has a mix of partial from before and after the >> patch. I'm rather confused about it.... > > This is a false positive. It tried to build it against latest mainline > instead of linux-next. On second look it seems I ended up with a duplicate ext4_huge_dax_fault after "git am" when I apply this on top of next-20170202. The following fixes it up for me and tests fine: diff --git a/fs/ext4/file.c b/fs/ext4/file.c index f8f4f6d068e5..e8ab46efc4f9 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -276,27 +276,6 @@ static int ext4_dax_huge_fault(struct vm_fault *vmf, return result; } -static int -ext4_dax_huge_fault(struct vm_fault *vmf) -{ - int result; - struct inode *inode = file_inode(vmf->vma->vm_file); - struct super_block *sb = inode->i_sb; - bool write = vmf->flags & FAULT_FLAG_WRITE; - - if (write) { - sb_start_pagefault(sb); - file_update_time(vmf->vma->vm_file); - } - down_read(&EXT4_I(inode)->i_mmap_sem); - result = dax_iomap_fault(vmf, &ext4_iomap_ops); - up_read(&EXT4_I(inode)->i_mmap_sem); - if (write) - sb_end_pagefault(sb); - - return result; -} - static int ext4_dax_fault(struct vm_fault *vmf) { return ext4_dax_huge_fault(vmf, PE_SIZE_PTE);