Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp35657298rwd; Mon, 10 Jul 2023 10:28:41 -0700 (PDT) X-Google-Smtp-Source: APBJJlHfXw+H7kTOVl9dKj9hiM4MwwH/A408Th/0h6alKI/hSiOjtLiKicfrNx5ygZGJqTBUZw5a X-Received: by 2002:a05:6a00:1803:b0:666:ae6b:c484 with SMTP id y3-20020a056a00180300b00666ae6bc484mr18069179pfa.13.1689010120863; Mon, 10 Jul 2023 10:28:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689010120; cv=none; d=google.com; s=arc-20160816; b=0n9bn8LhgEt3bGIS22h8j6fCzwL2r/AWIlk5T+u8eFsIi8SUIWVA3Kt7gZjAUj21Aw 6XWXX6G9aBDNZ7TXMe1VJe6JROzE8SYHE71Y751neaVBcmAiHWFt+e2SMWb63WR+xgGi 8CFBWa6PyTUpAVHAqZoOEOwx7Q+7gA/M+tKXfLqPEj89NCaPSD8t++cxrqnrayPUIliH SoYQeTNthRecWJ9GpZUYgBkRmEOx/bjgZzB4fMmG/5fb7PcXt8xPoUtvRXOJSEbCoCuC 04q9NQqXlKD9i6NpSnCyjGc1Y6XFhH3fSlQQs4f3grrOFS41fHqUQz/L/HJSdIca0TGC 9a/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:reply-to:message-id:subject:cc:to:from:date :dkim-signature:dkim-signature; bh=2RuwFg7Qt+lIFK9XLSCxEld3QsD6i2kbNJ5/TBXk/78=; fh=vSLTjzRlUfkU8/7KGcEbi+kSiiQiElZf0jIoJrQZfoA=; b=izU7y5DHPQM9zE2K29BRtkPbdJFyES7MteOL7njUPmXPjKowqXtDuKJ/tCTZFKVPS7 jAaDXu2M9kknUM/brmPLlQpLGwdS/hMPLVvCU/Xd1KcoLV4WDNDMGyzWk2a9ppObPq5C 10apf/O0B+Uf5Dwj1I9nmVdUMiHit97oAeJthJODdmaHU/T0c4Z2vmqAhXxN0g7wFGi9 qhFY5nWiBhZ07uUUi8Lu3PRb+zmi7A9mXFv/wL8mrcIpzdxwX/9++8rRziJcoySTEZ8k 3QEXFxKSos2tamKmBRr83APZYGXEArQc+9LtdEeDgqvV72FPok74MoQJBOzhPuVsHYBO jFVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=jcE8bKuU; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 189-20020a6301c6000000b0055b6a7a2ab7si9382516pgb.573.2023.07.10.10.28.26; Mon, 10 Jul 2023 10:28:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=jcE8bKuU; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229538AbjGJRNI (ORCPT + 99 others); Mon, 10 Jul 2023 13:13:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230194AbjGJRNG (ORCPT ); Mon, 10 Jul 2023 13:13:06 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D52F910D; Mon, 10 Jul 2023 10:13:05 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 8D1B721954; Mon, 10 Jul 2023 17:13:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1689009184; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2RuwFg7Qt+lIFK9XLSCxEld3QsD6i2kbNJ5/TBXk/78=; b=jcE8bKuUh3ugJsbxHmwWMkGD7as0DV9IqJd2b1NBNnOJrmb9iN5GKBgGGl80UbkjehaSdr VyguTnvOlS/BWrnbCcXJH6HcTbeyK/JXooVU+89bm2Behf7vHRB2pXw7at0OIAx6QaILKq jvv5kNzTcHflZs5/gFtx3N01dqisBiY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1689009184; h=from:from:reply-to:reply-to:date:date:message-id:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2RuwFg7Qt+lIFK9XLSCxEld3QsD6i2kbNJ5/TBXk/78=; b=yybNXXD7wO+Dl2AW1oVh+vgzNN6P/pww4EZlVVb1hgO5yr47NEr6vbh9VLw2NJfBiO0euE xfcu0b9+ynwjszCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 42DE913A05; Mon, 10 Jul 2023 17:13:04 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id TXd3DyA8rGSJEAAAMHmgww (envelope-from ); Mon, 10 Jul 2023 17:13:04 +0000 Date: Mon, 10 Jul 2023 19:06:29 +0200 From: David Sterba To: Arnd Bergmann Cc: Chris Mason , Josef Bacik , David Sterba , Arnd Bergmann , Johannes Thumshirn , Qu Wenruo , Anand Jain , Nikolay Borisov , Changbin Du , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] btrfs: fix 64-bit division link failure Message-ID: <20230710170629.GB30916@twin.jikos.cz> Reply-To: dsterba@suse.cz References: <20230705140117.795478-1-arnd@kernel.org> <20230705140117.795478-2-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230705140117.795478-2-arnd@kernel.org> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 05, 2023 at 04:01:09PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > Some of the recent refactoring of the statfs code apparently > brought back a link failure on older gcc versions that I had > fixed before: > > arm-linux-gnueabi-ld: fs/btrfs/super.o: in function `btrfs_statfs': > super.c:(.text+0xec40): undefined reference to `__aeabi_uldivmod' > > I think what happened is that gcc is free to not inline a function > despite the 'inline' annotation, and when this happens it can end > up partially inlining the div_u64() helper in a way that breaks the > __builtin_constant_p() based optimization. > > I only see this behavior for gcc-9, but it's possible that the same > thing happens in later versions as well when the code changes again. This is second fix to work around compiler assumptions and dependency from other code, somehow this feels like the fix is being done in the wrong place. Filesystem code using a number division helpers that are supposed to abstract away 64bit division problems are as far as we should go. Speculating about partial inlining or working/not-working constant value detection maybe belongs to some highly optimized code but not to a plain API usage.