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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B93FCC48BC3 for ; Mon, 19 Feb 2024 09:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5u7sN+3hExTsetEHE4DFKlePW1OwVec28RZ2Dn0R7ZA=; b=fs17by63naRB3o bYAJdetCriQwdAJGIJpcSI2fq2v7tZ66R+0QtiF8rE9BVCETrget1roib9eluzMcsbYT06JyYf2aA DQQMgWg8cMziZzxwUMcnqDBynn82MIHRDMvrXzQLuicZ0g1craB3FSn2XUy+QG02R8y9KWab4/9Mo mch+sBS9NQTrFkjgguVBXQ+yXcgQ9fugeG/8mlBlSrv8WkTuAwALOKWlZrEXseaFWqc9FDINmrzwt 4SfJaty1wftIKmyR8cMyt9hglxRV2BGVEiR6ttzVGiNgA8+m3CHBWtiThxP9iolMmaeQ7GIS7jFYs 3UjZlN+lWjKe7s1iicVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rc0Ju-00000009uNr-1MCt; Mon, 19 Feb 2024 09:52:18 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rc0Jr-00000009uNK-3mf4 for linux-arm-kernel@lists.infradead.org; Mon, 19 Feb 2024 09:52:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SAEbIdpnxZJOic0yg9YQ6ZUXZebSJ8Li6l2q0fhYTfo=; b=QHVceFGW6VtzeR2rM64t7MpGEC nyRWXzKzrKRue662A60xIZBsslQ+JApOwbvWHUg7ulSp9I7uxkwLdqVnlWsn0EJdScLJqTAAe4j9p ZhJR5TlYD2mMj8G5Hp9jbpRsZF2+jDo+7k8+/EKc6qDVxuAQlCOtlIgAWzIWl4e/sIxezwFCbZkr7 hYiN5p9GpfE0L9qOaknDySdeQ7PwNKZL2osMiPnx6jF8tnkfP6ONDp7GsUispu5WgqVlPJh/WXVWZ h4OBL9qSSVRyRHrGEH+PLW84VCetw8Vuk3rR5Ux7KuXyKCJmIjwSFW5IsPVbTYxC8JD7nS3PSHgO+ 7cMJhiCw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:34404) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rc0Jl-00062S-39; Mon, 19 Feb 2024 09:52:10 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rc0Jk-0008GW-Gj; Mon, 19 Feb 2024 09:52:08 +0000 Date: Mon, 19 Feb 2024 09:52:08 +0000 From: "Russell King (Oracle)" To: Kent Overstreet Cc: Arnd Bergmann , Calvin Owens , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "linux-bcachefs@vger.kernel.org" Subject: Re: [PATCH] arm: Silence gcc warnings about arch ABI drift Message-ID: References: <431dd956-ad31-4da8-ad42-34f7380824bb@app.fastmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240219_015215_969842_88AAA1A5 X-CRM114-Status: GOOD ( 24.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 19, 2024 at 04:40:00AM -0500, Kent Overstreet wrote: > On Mon, Feb 19, 2024 at 09:26:51AM +0000, Russell King (Oracle) wrote: > > On Mon, Feb 19, 2024 at 07:21:11AM +0100, Arnd Bergmann wrote: > > > I think these should be addressed in bcachefs instead. > > > While it's not the fault of bcachefs that the calling > > > convention changed between gcc versions, have a look at > > > the actual structure layout: > > > > > > struct bch_val { > > > __u64 __nothing[0]; > > > }; > > > struct bpos { > > > /* > > > * Word order matches machine byte order - btree code treats a bpos as a > > > * single large integer, for search/comparison purposes > > > * > > > * Note that wherever a bpos is embedded in another on disk data > > > * structure, it has to be byte swabbed when reading in metadata that > > > * wasn't written in native endian order: > > > */ > > > #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ > > > __u32 snapshot; > > > __u64 offset; > > > __u64 inode; > > > #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ > > > __u64 inode; > > > __u64 offset; /* Points to end of extent - sectors */ > > > __u32 snapshot; > > > #else > > > #error edit for your odd byteorder. > > > #endif > > > } __packed > > > struct bch_backpointer { > > > struct bch_val v; > > > __u8 btree_id; > > > __u8 level; > > > __u8 data_type; > > > __u64 bucket_offset:40; > > > __u32 bucket_len; > > > struct bpos pos; > > > } __packed __aligned(8); > > > > > > This is not something that should ever be passed by value > > > into a function. > > > > +1 - bcachefs definitely needs fixing. Passing all that as an argument > > not only means that it has to be read into registers, but also when > > accessing members, it has to be extracted from those registers as well. > > > > Passing that by argument is utterly insane. > > If the compiler people can't figure out a vaguely efficient way to pass > a small struct by value, that's their problem - from the way you > describe it, I have to wonder at what insanity is going on there. It sounds like you have a personal cruisade here. Passing structures on through function arguments is never efficient. The entire thing _has_ to be loaded from memory at function call and either placed onto the stack (creating an effective memcpy() on every function call) or into registers. Fundamentally. It's not something compiler people can mess around with. Sorry but it's bcachefs that's the problem here, and well done to the compiler people for pointing out stupid code. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel