Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp640123imu; Mon, 5 Nov 2018 06:39:26 -0800 (PST) X-Google-Smtp-Source: AJdET5cAkQrRY1LkYr2Veb+T3lkTkUbzqGXrd8EvNVnT0ch+BIU5d1CeC/chv2KCyD4t0mYN9ADg X-Received: by 2002:a17:902:4381:: with SMTP id j1-v6mr21916625pld.59.1541428765983; Mon, 05 Nov 2018 06:39:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541428765; cv=none; d=google.com; s=arc-20160816; b=Duifs6uavigPFVgIT+15cK93Bsjiyx2ixSrMNkcDWadYwoDDNZ64Sd3fiJseeM5xx7 BQxHSFEQ0nLK2DqAHyFvCwmIyf3YDYvRX7f9ckKAWqTs9SeZuiie9iSn4lQnNNNIG4Fj HjQEo/A7QnG9TS2+ocP5mFd3E5SKzvTuMUur1GrcyFVa6hl2RWg7oRIYERE8bR+Qn3x/ FI8nqE06hOYC8g2FfDKCsJ055mkiRq9IWly5pTAaX8oKORqvV0tCG08J14ZMSZpMcd8F KJiyX84MiUKACYWgSBSH6CElvwdQnEQuHph1/BU4ihgP+VIbP+lehnbH2vdLWftFgC+R 97vA== 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:dkim-signature; bh=8+8I/eQqiDXhce3J03v8grupt2D0goqdxCeIffJZIPI=; b=hL+j2w00cOr2ot0mqjVBMnKVuTZEfEyzBtNZ/FBTDx3g8e/EFwXKA1a/lPabvxGlV3 9oz8COLnOR0P6pypqnCrsYl3JkF5jxdV7IYcbVEW1ZchGvP7CShr4pqING/r8jWJTMrs HKEJZup/FacLAIg9QHrBGb/6FIySVHkCWNCm3Tu8g49+08XwhUpaE+fX6NWFRkOsJ2/5 bqTR4pztENOaltjmwnCbWWYPMkwIiHXfISlGGf1H6heFB/w8BWca30vzPHsuvqzwT8yz KuYXB2v7E43wPBEKgClUrPYPwXhf7pWEdmRz+prHOib2eq3atrKaL/wQh/1PYQQe3YiX 15GA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KHJHpcyy; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g2-v6si3126688plq.336.2018.11.05.06.39.10; Mon, 05 Nov 2018 06:39:25 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KHJHpcyy; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730074AbeKEX5W (ORCPT + 99 others); Mon, 5 Nov 2018 18:57:22 -0500 Received: from mail-pf1-f195.google.com ([209.85.210.195]:40981 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729449AbeKEX5W (ORCPT ); Mon, 5 Nov 2018 18:57:22 -0500 Received: by mail-pf1-f195.google.com with SMTP id e22-v6so4519852pfn.8; Mon, 05 Nov 2018 06:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8+8I/eQqiDXhce3J03v8grupt2D0goqdxCeIffJZIPI=; b=KHJHpcyyCjnMnhdCno+ewTY1WcXdICYeWpWYDzzSzXmb+oWV7Gl8EOY+YUuiOCqblL 2wy03AmSPYT/nr5QwAEjSEA8N8mPVSlRdGf8+TkxXBqZhv6/h2N6K5q41fDxdjLl3B/e gB4cWHppTTb6hkn5e0Y0QBIRES7iXmrCwgnBHEU2x9iluJn4yvybQoE90aulOQ0j5RAz wph1jiMtJ4DjV/peVX3hlnsc8WG2hYw/CGDTYLK/ei4vigX2pN0e7j/sXqzxn01UEgTV t22EFw6u+f0GWJQ76e65WRHUZNSf7bAmS7DdfOVjB9by4ni6+Sa35Zz9/LC3wvC4GLMl +5pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8+8I/eQqiDXhce3J03v8grupt2D0goqdxCeIffJZIPI=; b=til27UrWaFShjJRoYoib9PavsmCy4g8sMaWGc3xeCuEe83rlgDSfGcBuUVOyhJL6mT fhMA5XvZkPb76ozNlgJ6oKCRdV39VlSitH5hfdFQXB6dRrG2X84rGRbcTsO689BhbmJW Hk0pypM4th32f7KBVvBuz8d93lG2xgBM+nDj6ufNg/sTVh29vq1of9e3/n/onR9Pv4mj LXRSyQR9PU/qCiWTMMPIY9/Kwk8Q0ORiKoqf4QIh9foKUI6YsllCa7NsmktJeS/JfL3Q 3InuUr8b8nkRJgYvSPb9IMhJrLYN6IlPYgQIY5HeZlnnLHLoaYjLz5I72K7FVxd98FnH GpKQ== X-Gm-Message-State: AGRZ1gK0eBsQ0VI3rpCNYGd4GGXg61Z8yjLnMCz5yETBPmTH1Vi41Vuz 1QLDWkcf/m/8WkiQQ+ClMAg= X-Received: by 2002:a63:1342:: with SMTP id 2-v6mr20148687pgt.19.1541428641125; Mon, 05 Nov 2018 06:37:21 -0800 (PST) Received: from mail.google.com ([2001:19f0:6001:4ff6:5400:1ff:feb7:a195]) by smtp.gmail.com with ESMTPSA id p14-v6sm50648616pgn.45.2018.11.05.06.37.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Nov 2018 06:37:20 -0800 (PST) Date: Mon, 5 Nov 2018 14:37:18 +0000 From: Changbin Du To: Arnd Bergmann Cc: Chris Mason , Josef Bacik , David Sterba , Changbin Du , Anand Jain , Nikolay Borisov , Misono Tomohiro , Qu Wenruo , Gu Jinxiang , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] btrfs: avoid link error with CONFIG_NO_AUTO_INLINE Message-ID: <20181105143717.xrarjgcdgaipmsqd@mail.google.com> References: <20181103153941.1881966-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181103153941.1881966-1-arnd@arndb.de> User-Agent: NeoMutt/20180716-508-7c9a6d Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for this fix. Reviewed-by: Changbin Du On Sat, Nov 03, 2018 at 04:39:28PM +0100, Arnd Bergmann wrote: > On 32-bit ARM with gcc-8, I see a link error with the addition of the > CONFIG_NO_AUTO_INLINE option: > > fs/btrfs/super.o: In function `btrfs_statfs': > super.c:(.text+0x67b8): undefined reference to `__aeabi_uldivmod' > super.c:(.text+0x67fc): undefined reference to `__aeabi_uldivmod' > super.c:(.text+0x6858): undefined reference to `__aeabi_uldivmod' > super.c:(.text+0x6920): undefined reference to `__aeabi_uldivmod' > super.c:(.text+0x693c): undefined reference to `__aeabi_uldivmod' > fs/btrfs/super.o:super.c:(.text+0x6958): more undefined references to `__aeabi_uldivmod' follow > > So far this is the only file that shows the behavior, so I'd propose > to just work around it by marking the functions as 'static inline' > that normally get inlined here. > > The reference to __aeabi_uldivmod comes from a div_u64() which has an > optimization for a constant division that uses a straight '/' operator > when the result should be known to the compiler. My interpretation is > that as we turn off inlining, gcc still expects the result to be constant > but fails to use that constant value. > > Cc: Changbin Du > Fixes: 943b8435c3bd ("kernel hacking: add a config option to disable compiler auto-inlining") > Signed-off-by: Arnd Bergmann > --- > fs/btrfs/super.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c > index c3c1e7bee49d..b7af0b8936ad 100644 > --- a/fs/btrfs/super.c > +++ b/fs/btrfs/super.c > @@ -1922,7 +1922,7 @@ static int btrfs_remount(struct super_block *sb, int *flags, > } > > /* Used to sort the devices by max_avail(descending sort) */ > -static int btrfs_cmp_device_free_bytes(const void *dev_info1, > +static inline int btrfs_cmp_device_free_bytes(const void *dev_info1, > const void *dev_info2) > { > if (((struct btrfs_device_info *)dev_info1)->max_avail > > @@ -1951,8 +1951,8 @@ static inline void btrfs_descending_sort_devices( > * The helper to calc the free space on the devices that can be used to store > * file data. > */ > -static int btrfs_calc_avail_data_space(struct btrfs_fs_info *fs_info, > - u64 *free_bytes) > +static inline int btrfs_calc_avail_data_space(struct btrfs_fs_info *fs_info, > + u64 *free_bytes) > { > struct btrfs_device_info *devices_info; > struct btrfs_fs_devices *fs_devices = fs_info->fs_devices; > -- > 2.18.0 > -- Thanks, Changbin Du