All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.