From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Calvin Owens <jcalvinowens@gmail.com>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
"linux-bcachefs@vger.kernel.org" <linux-bcachefs@vger.kernel.org>,
Kent Overstreet <kent.overstreet@linux.dev>
Subject: Re: [PATCH] arm: Silence gcc warnings about arch ABI drift
Date: Mon, 19 Feb 2024 09:26:51 +0000 [thread overview]
Message-ID: <ZdMe24xN1Ej4QoVU@shell.armlinux.org.uk> (raw)
In-Reply-To: <431dd956-ad31-4da8-ad42-34f7380824bb@app.fastmail.com>
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.
--
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
next prev parent reply other threads:[~2024-02-19 9:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 4:09 [PATCH] arm: Silence gcc warnings about arch ABI drift Calvin Owens
2024-02-19 6:21 ` Arnd Bergmann
2024-02-19 6:25 ` Kent Overstreet
2024-02-19 7:56 ` Arnd Bergmann
2024-02-19 6:58 ` Calvin Owens
2024-02-19 7:03 ` Kent Overstreet
2024-02-19 9:26 ` Russell King (Oracle) [this message]
2024-02-19 9:40 ` Kent Overstreet
2024-02-19 9:52 ` Russell King (Oracle)
2024-02-19 9:56 ` Kent Overstreet
2024-02-19 19:53 ` David Laight
2024-02-19 21:38 ` Kent Overstreet
2024-02-19 22:04 ` David Laight
2024-02-19 9:57 ` Arnd Bergmann
2024-02-19 10:08 ` Kent Overstreet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZdMe24xN1Ej4QoVU@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Dave.Martin@arm.com \
--cc=arnd@arndb.de \
--cc=jcalvinowens@gmail.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).