From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBC69C433EF for ; Tue, 21 Jun 2022 22:59:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 557268E0068; Tue, 21 Jun 2022 18:59:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 506718E0059; Tue, 21 Jun 2022 18:59:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F5998E0068; Tue, 21 Jun 2022 18:59:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2C05A8E0059 for ; Tue, 21 Jun 2022 18:59:40 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EDF662071E for ; Tue, 21 Jun 2022 22:59:39 +0000 (UTC) X-FDA: 79603761678.06.12483B0 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by imf14.hostedemail.com (Postfix) with ESMTP id 5E935100003 for ; Tue, 21 Jun 2022 22:59:39 +0000 (UTC) Received: from dread.disaster.area (pa49-181-2-147.pa.nsw.optusnet.com.au [49.181.2.147]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 6F48610E87F4; Wed, 22 Jun 2022 08:59:36 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1o3mqM-009TtF-6p; Wed, 22 Jun 2022 08:59:34 +1000 Date: Wed, 22 Jun 2022 08:59:34 +1000 From: Dave Chinner To: kernel test robot Cc: Andrew Morton , linux-xfs@vger.kernel.org, Linux Memory Management List , Shiyang Ruan Subject: Re: [linux-next:master] BUILD REGRESSION 34d1d36073ea4d4c532e8c8345627a9702be799e Message-ID: <20220621225934.GR227878@dread.disaster.area> References: <62b241d3.CmOrZi26Vac8nqGm%lkp@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62b241d3.CmOrZi26Vac8nqGm%lkp@intel.com> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.4 cv=OJNEYQWB c=1 sm=1 tr=0 ts=62b24d59 a=ivVLWpVy4j68lT4lJFbQgw==:117 a=ivVLWpVy4j68lT4lJFbQgw==:17 a=kj9zAlcOel0A:10 a=JPEYwPQDsx4A:10 a=VwQbUJbxAAAA:8 a=QyXUC8HyAAAA:8 a=7-415B0cAAAA:8 a=TcNIDo5RizWzpbXBp64A:9 a=CjuIK1q_8ugA:10 a=AjGcO6oz07-iQ99wixmX:22 a=biEYGPWJfzWAr4FL6Ov7:22 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655852379; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CKULVMwjqXfLjeL174X1I4fvI1Ys408exaQ4Dzmnaco=; b=vfTRyKpjKWUOwNrrGixgImbs+aXb28xP1j2syZX8ravxijulup+BBy+HxjGlnltv13Hv4w oTXLNb7wDjaYHeHfVkdzaxNhH7b2K+LmUOSLOtXqGmzu22hJ8nPeE73FIc6xhhismyDLWl c3Us74h1BajjX5BVgZzs2teobXOO1Ro= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655852379; a=rsa-sha256; cv=none; b=eZA0WWBzrwAFGX6YXw0b04ANyopERTL232Pna2Qzs1XPXtiSXNa6O1SQndWRZX9gHQuBUj Qct/SB3NFWdlSDvEINfom8LE7xeJpBh408hhxK0Siht85F33+vIaduDO+MJyh8rHPmkG81 hMVMKtqh9HeyzaSM/bgyhBu7YgrIssw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=none (imf14.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 211.29.132.249) smtp.mailfrom=david@fromorbit.com; dmarc=none X-Stat-Signature: kdnkgquxir8h7ocwrw51d7hzk3serqgn Authentication-Results: imf14.hostedemail.com; dkim=none; spf=none (imf14.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 211.29.132.249) smtp.mailfrom=david@fromorbit.com; dmarc=none X-Rspamd-Queue-Id: 5E935100003 X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1655852379-714494 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: [trimmed cc list] On Wed, Jun 22, 2022 at 06:10:27AM +0800, kernel test robot wrote: > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: 34d1d36073ea4d4c532e8c8345627a9702be799e Add linux-next specific files for 20220621 > > Error/Warning reports: > > https://lore.kernel.org/linux-mm/202206212029.Yr5m7Cd3-lkp@intel.com > https://lore.kernel.org/linux-mm/202206212033.3lgl72Fw-lkp@intel.com SEP. (Networking) > https://lore.kernel.org/lkml/202206071511.FI7WLdZo-lkp@intel.com The XFS warnings are in on this code: 1258 #ifdef CONFIG_FS_DAX 1259 int > 1260 xfs_dax_fault( 1261 struct vm_fault *vmf, 1262 enum page_entry_size pe_size, 1263 bool write_fault, 1264 pfn_t *pfn) 1265 { > 1266 return dax_iomap_fault(vmf, pe_size, pfn, NULL, 1267 (write_fault && !vmf->cow_page) ? 1268 &xfs_dax_write_iomap_ops : 1269 &xfs_read_iomap_ops); 1270 } 1271 #else 1272 int 1273 xfs_dax_fault( 1274 struct vm_fault *vmf, 1275 enum page_entry_size pe_size, 1276 bool write_fault, 1277 pfn_t *pfn) 1278 { 1279 return 0; 1280 } 1281 #endif As it's not declared static and the return type should be vm_fault_t. This code is not in the XFS tree, so I have to assume that it is in Andrew's tree and needs fixing there. But I don't think just changing 'int' to 'static vm_fault_t' is right. This CONFIG_FS_DAX wrapper just smells wrong. That is, the call to xfs_dax_fault() should be completely elided by the compiler if CONFIG_FS_DAX is not set because it is only called from inside a if (IS_DAX(inode)) {...} context. IS_DAX(inode) will always evaluate as zero when CONFIG_FS_DAX is not set, and so xfs_dax_fault() becomes unreacheable and gets elided. That's the way the current code in 5.19-rc3 works, and has for years. We can call dax_iomap_fault() directly as long as it is only in a (IS_DAX(inode) == true) conditional context. We do this all over the place with fs-dax code - we did quite a bit of work to set up the FSDAX code to avoid needing config conditional code in the filesystems like the above wrappers. I can't see anything that has changes this, so I'm at a loss to explain why this wrapper is needed in the current linux-next tree... I think these wrappers should go away (needing them would be a potentially serious regression!) and be reverted to the existing 5.19-rc3 code, not just be patched to make the prototypes correct. Ruan, Andrew, can you two work together to massage the changes that are pending in Andrew's tree to get them fixed? Cheers, Dave. -- Dave Chinner david@fromorbit.com