Received: by 10.223.185.116 with SMTP id b49csp3548053wrg; Mon, 26 Feb 2018 01:46:02 -0800 (PST) X-Google-Smtp-Source: AH8x2270SK5JeZldH0Mwn7Xxj7f82lLw+dBl8iZqEtL++Qg5V04jd1f4zMjEgF6h4BqjBMN5RrFX X-Received: by 2002:a17:902:8b88:: with SMTP id ay8-v6mr10122057plb.197.1519638362394; Mon, 26 Feb 2018 01:46:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519638362; cv=none; d=google.com; s=arc-20160816; b=o4tDXglMTNGj/L2EQv+UapjitvNuGQ6u8aiOku30KYbwRYBq4eBOVnX3gkPigF3VM5 IZBqa7RFnG5fSj7b+MK6N+gYXERvyYFXeRROTQqPutppr1rcmwgYHgDEzZNquY79Utfo rYa/AJ4V7osNRE42e534/5aQMknZYtquR7n+WL4/6RCz/yon4rfSuJN6oq0NPDcEPro3 Qvf6k0aAUJOi55Re1F9/HnDRExjdc9Lw4pN82jI1edKoaUUwL/k0B6T2avW7p624lwp+ txY2d7qQFsLkqGoJbFtqrvCtS2VD1R814ZWSps7EUcku+HEbMx2TkrLUHiK8OKXbTAeE 9NTg== 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:arc-authentication-results; bh=IhzyJFvgGrhuYdCJjJTbOmWjg5EEaeHCmfhglVYvDqQ=; b=o+jtROHJ9dNoICwSdxeJqxGVaWfbc8Lv9mJeFetp71gyFhwHQC6W8PJvzykiELxCrp fKIBD6kkwJWRCCoYv0PSjdD89ZPjzI9gabJNBxzEsQO7jcgXiyTUSZPrgnfugvNy2Goj 8kjpzVwmyydkLhwIK0uHcecjMXlmpl1yBxMMiBfNYdhQD+RK7kUtcRkuVT+PBNq4XWs9 7ZrrllfiAw0RjzINAvaDa+0C855DQr5lrXY/ZJVXd4FzvVdTBw77xB+HYakvVBTYgxi/ IbzIynjrcIaw3Ka8HPpwHaMgLu5/0c4slal6flnKwf4/H9tK/6GFomyAwetq6paYSMMw 0VZQ== 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 61-v6si6513884plc.343.2018.02.26.01.45.48; Mon, 26 Feb 2018 01:46:02 -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 S1752436AbeBZJoc (ORCPT + 99 others); Mon, 26 Feb 2018 04:44:32 -0500 Received: from mx2.suse.de ([195.135.220.15]:51431 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751022AbeBZJoa (ORCPT ); Mon, 26 Feb 2018 04:44:30 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C51CCAB3E; Mon, 26 Feb 2018 09:44:28 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 80EFA1E04F9; Mon, 26 Feb 2018 10:44:28 +0100 (CET) Date: Mon, 26 Feb 2018 10:44:28 +0100 From: Jan Kara To: Dan Williams Cc: linux-nvdimm@lists.01.org, Jan Kara , linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux-mm@kvack.org, Alexander Viro , linux-fsdevel@vger.kernel.org, kbuild test robot , Christoph Hellwig Subject: Re: [PATCH v2 2/5] dax: fix dax_mapping() definition in the FS_DAX=n + DEV_DAX=y case Message-ID: <20180226094428.awvicgxhohj4ezpq@quack2.suse.cz> References: <151937026001.18973.12034171121582300402.stgit@dwillia2-desk3.amr.corp.intel.com> <151937027102.18973.18360014199243139223.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151937027102.18973.18360014199243139223.stgit@dwillia2-desk3.amr.corp.intel.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 22-02-18 23:17:51, Dan Williams wrote: > An address_space will only have dax exceptional entries when FS_DAX is > enabled. The current reliance on S_DAX causes compile failures when > S_DAX is defined for DEV_DAX, but FS_DAX is disabled. Make dax_mapping() > always return false so that mm/truncate.c drops its link time > dependencies on fs/dax.c. > > Cc: Alexander Viro > Cc: linux-fsdevel@vger.kernel.org > Cc: Christoph Hellwig > Cc: Jan Kara > Cc: > Reported-by: kbuild test robot > Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap") > Signed-off-by: Dan Williams Looks good. You can add: Reviewed-by: Jan Kara Honza > --- > include/linux/dax.h | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/include/linux/dax.h b/include/linux/dax.h > index 0185ecdae135..62e8cf7eb566 100644 > --- a/include/linux/dax.h > +++ b/include/linux/dax.h > @@ -107,6 +107,10 @@ int dax_invalidate_mapping_entry_sync(struct address_space *mapping, > int __dax_zero_page_range(struct block_device *bdev, > struct dax_device *dax_dev, sector_t sector, > unsigned int offset, unsigned int length); > +static inline bool dax_mapping(struct address_space *mapping) > +{ > + return mapping->host && IS_DAX(mapping->host); > +} > #else > static inline int __dax_zero_page_range(struct block_device *bdev, > struct dax_device *dax_dev, sector_t sector, > @@ -114,12 +118,11 @@ static inline int __dax_zero_page_range(struct block_device *bdev, > { > return -ENXIO; > } > -#endif > - > static inline bool dax_mapping(struct address_space *mapping) > { > - return mapping->host && IS_DAX(mapping->host); > + return false; > } > +#endif > > struct writeback_control; > int dax_writeback_mapping_range(struct address_space *mapping, > -- Jan Kara SUSE Labs, CR