From: Calvin Owens <jcalvinowens@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>,
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: Sun, 18 Feb 2024 22:58:07 -0800 [thread overview]
Message-ID: <ZdL7_-2VCJqjn634@gmail.com> (raw)
In-Reply-To: <431dd956-ad31-4da8-ad42-34f7380824bb@app.fastmail.com>
On Monday 02/19 at 07:21 +0100, Arnd Bergmann wrote:
> On Mon, Feb 19, 2024, at 05:09, Calvin Owens wrote:
> > 32-bit arm builds uniquely emit a lot of spam like this:
> >
> > fs/bcachefs/backpointers.c: In function ‘extent_matches_bp’:
> > fs/bcachefs/backpointers.c:15:13: note: parameter passing for
> > argument of type ‘struct bch_backpointer’ changed in GCC 9.1
> >
> > Apply the arm64 change from commit ebcc5928c5d9 ("arm64: Silence gcc
> > warnings about arch ABI drift") to silence them. It seems like Dave's
> > original rationale applies here too.
> >
> > Cc: Dave Martin <Dave.Martin@arm.com>
> > Signed-off-by: Calvin Owens <jcalvinowens@gmail.com>
> > ---
>
> I think these should be addressed in bcachefs instead.
That seems reasonable to me. For clarity, I just happened to notice this
while doing allyesconfig cross builds for something entirely unrelated.
I'll take it up with them. It's not a big problem from my POV, the notes
don't cause -Werror builds to fail or anything like that.
Thanks,
Calvin
> 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.
>
> Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Calvin Owens <jcalvinowens@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>,
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: Sun, 18 Feb 2024 22:58:07 -0800 [thread overview]
Message-ID: <ZdL7_-2VCJqjn634@gmail.com> (raw)
In-Reply-To: <431dd956-ad31-4da8-ad42-34f7380824bb@app.fastmail.com>
On Monday 02/19 at 07:21 +0100, Arnd Bergmann wrote:
> On Mon, Feb 19, 2024, at 05:09, Calvin Owens wrote:
> > 32-bit arm builds uniquely emit a lot of spam like this:
> >
> > fs/bcachefs/backpointers.c: In function ‘extent_matches_bp’:
> > fs/bcachefs/backpointers.c:15:13: note: parameter passing for
> > argument of type ‘struct bch_backpointer’ changed in GCC 9.1
> >
> > Apply the arm64 change from commit ebcc5928c5d9 ("arm64: Silence gcc
> > warnings about arch ABI drift") to silence them. It seems like Dave's
> > original rationale applies here too.
> >
> > Cc: Dave Martin <Dave.Martin@arm.com>
> > Signed-off-by: Calvin Owens <jcalvinowens@gmail.com>
> > ---
>
> I think these should be addressed in bcachefs instead.
That seems reasonable to me. For clarity, I just happened to notice this
while doing allyesconfig cross builds for something entirely unrelated.
I'll take it up with them. It's not a big problem from my POV, the notes
don't cause -Werror builds to fail or anything like that.
Thanks,
Calvin
> 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.
>
> Arnd
_______________________________________________
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 6:58 UTC|newest]
Thread overview: 32+ 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 4:09 ` Calvin Owens
2024-02-19 6:21 ` Arnd Bergmann
2024-02-19 6:21 ` Arnd Bergmann
2024-02-19 6:25 ` Kent Overstreet
2024-02-19 6:25 ` Kent Overstreet
2024-02-19 7:56 ` Arnd Bergmann
2024-02-19 7:56 ` Arnd Bergmann
2024-02-19 6:58 ` Calvin Owens [this message]
2024-02-19 6:58 ` Calvin Owens
2024-02-19 7:03 ` Kent Overstreet
2024-02-19 7:03 ` Kent Overstreet
2024-02-19 7:36 ` Calvin Owens
2024-02-19 7:42 ` Kent Overstreet
2024-02-19 9:26 ` Russell King (Oracle)
2024-02-19 9:26 ` Russell King (Oracle)
2024-02-19 9:40 ` Kent Overstreet
2024-02-19 9:40 ` Kent Overstreet
2024-02-19 9:52 ` Russell King (Oracle)
2024-02-19 9:52 ` Russell King (Oracle)
2024-02-19 9:56 ` Kent Overstreet
2024-02-19 9:56 ` Kent Overstreet
2024-02-19 19:53 ` David Laight
2024-02-19 19:53 ` David Laight
2024-02-19 21:38 ` Kent Overstreet
2024-02-19 21:38 ` Kent Overstreet
2024-02-19 22:04 ` David Laight
2024-02-19 22:04 ` David Laight
2024-02-19 9:57 ` Arnd Bergmann
2024-02-19 9:57 ` Arnd Bergmann
2024-02-19 10:08 ` Kent Overstreet
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=ZdL7_-2VCJqjn634@gmail.com \
--to=jcalvinowens@gmail.com \
--cc=Dave.Martin@arm.com \
--cc=arnd@arndb.de \
--cc=kent.overstreet@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.