From: David Laight <David.Laight@ACULAB.COM>
To: 'Kent Overstreet' <kent.overstreet@linux.dev>,
Nathan Chancellor <nathan@kernel.org>
Cc: "llvm@lists.linux.dev" <llvm@lists.linux.dev>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"linux-bcachefs@vger.kernel.org" <linux-bcachefs@vger.kernel.org>
Subject: RE: static assertion failed in fs/bcachefs/journal_io.c
Date: Wed, 14 Feb 2024 10:41:59 +0000 [thread overview]
Message-ID: <b91d20f513e642669f716a217f15f9de@AcuMS.aculab.com> (raw)
In-Reply-To: <wl7u2f7gvrw5yeyoa4rit4fy5kepn5tmqgzelrduhpajqvcuxy@4imci5mhzecr>
From: Kent Overstreet
> Sent: 14 February 2024 01:17
>
> bcachefs bugs should go to the bcachefs mailing list; I assume this is
> just a case where we need min_t instead of min, if so I'll fix it
> shortly
You should pretty much never use min_t() - it contains casts that are just
waiting to cause grief.
I'm sure a bug got raised on clang so it outputting the source of the
_Static_assert() when there is a message.
That just makes the error message worse.
Hacking at the error message, it comes from (expanded by min()):
min(replicas_want, ({
do {
__attribute__((__noreturn__))
extern void __compiletime_assert_578(void)
__attribute__((__error__("Unsupported access size for {READ,WRITE}_ONCE().")));
if (...)
__compiletime_assert_578();
} while (0);
({
typeof(&(c->opts.metadata_replicas_required)) __x = &(c->opts.metadata_replicas_required);
int atomic = 1;
union {
typeof( _Generic((*__x),
char: (char)0,
unsigned char: (unsigned char)0,
signed char: (signed char)0,
unsigned short: (unsigned short)0,
signed short: (signed short)0,
unsigned int: (unsigned int)0,
signed int: (signed int)0,
unsigned long: (unsigned long)0,
signed long: (signed long)0,
unsigned long long: (unsigned long long)0,
signed long long: (signed long long)0,
default: (*__x))) __val;
char __c[1];
} __u;
switch (sizeof(c->opts.metadata_replicas_required)) {
case 1: asm volatile("..." : "=r" (*(__u8 *)__u.__c) : "Q" (*__x) : "memory");
break;
case 2: asm volatile("..." : "=r" (*(__u16 *)__u.__c) : "Q" (*__x) : "memory");
break;
case 4: asm volatile("..." : "=r" (*(__u32 *)__u.__c) : "Q" (*__x) : "memory");
break;
case 8: asm volatile("..." : "=r" (*(__u64 *)__u.__c) : "Q" (*__x) : "memory");
break;
default:
atomic = 0;
}
atomic ? (typeof(*__x))__u.__val : (*(volatile typeof(__x))__x);
});
}))
So I suspect it is min(replicas_want, READ_ONCE(replices_required)).
I think replicas_want is unsigned (int) and replicas_required u8.
>
> On Tue, Feb 13, 2024 at 02:56:40PM -0700, Nathan Chancellor wrote:
> > Hi all,
> >
> > I am not really sure where to go with this, so I figured I would loop
> > some people in and see if we can figure out what is going on here.
> >
> > After commit 67a8e7de7ef0 ("bcachefs: Clamp replicas_required to
> > replicas") in linux-next, I see a massive error occur when building for
> > ARCH=arm64 with both CONFIG_BCACHEFS_FS and CONFIG_LTO enabled, which is
> > important because arm64 defines its own __READ_ONCE() with LTO enabled.
> > The error appears to be related to the minmax.h changes that went into
> > 6.7; I think it is specifically around commit d03eba99f5bf ("minmax:
> > allow min()/max()/clamp() if the arguments have the same signedness.").
> >
> > As far as I can tell, replicas_want and the metadata_replicas_required
> > member in struct bch_opts should have the same signedness, unless the
> > __READ_ONCE() macro is messing something up, which is kind of hard to
> > tell at this point...
The last line of that READ_ONCE() expansion looks dubious to me.
The result type is independent of 'atomic' and I suspect ?: counts
as an arithmetic operation and u8 gets promoted to int.
That would fail the old min() as well as the new one.
Is this code new? I can see it online in 6.8.4-rc4.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2024-02-14 10:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240213215640.GA80329@dev-arch.thelio-3990X>
2024-02-14 1:17 ` static assertion failed in fs/bcachefs/journal_io.c Kent Overstreet
2024-02-14 10:41 ` David Laight [this message]
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=b91d20f513e642669f716a217f15f9de@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-bcachefs@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=nathan@kernel.org \
--cc=will@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 read-only IMAP folder(s) and NNTP newsgroup(s).