Re: [GIT PULL] bcachefs fixes for 6.11-rc6
From: Kent Overstreet
Date: Wed Sep 04 2024 - 14:55:45 EST
On Tue, Sep 03, 2024 at 03:53:56PM GMT, Geert Uytterhoeven wrote:
> Hi Kent,
>
> Replying here, as there is (again) no patch email to reply to to report issues.
>
> noreply@xxxxxxxxxxxxxx is reporting several build failures[1] in linux-next:
>
> fs/bcachefs/sb-members.c: In function ‘bch2_sb_member_alloc’:
> fs/bcachefs/sb-members.c:503:2: error: a label can only be part of
> a statement and a declaration is not a statement
> 503 | unsigned nr_devices = max_t(unsigned, dev_idx + 1,
> c->sb.nr_devices);
> | ^~~~~~~~
> fs/bcachefs/sb-members.c:505:2: error: expected expression before ‘struct’
> 505 | struct bch_sb_field_members_v2 *mi =
> bch2_sb_field_get(c->disk_sb.sb, members_v2);
> | ^~~~~~
>
> Apparently this fails with gcc-10 and older, but builds with gcc-11
> and gcc-12.
Thanks for the report - it's fixed now (thanks, Hongbo)
> The failure is due to commit 4e7795eda4459bf3 ("bcachefs:
> bch2_sb_member_alloc()"), which is nowhere to be found on
> lore.kernel.org. Please stop committing private unreviewed patches
> to linux-next, as several people have asked before.
They're still in git; I'd suggest just doing a git send-email and
tweaking the output if you want to start a review on a patch you find.
There's been some discussions in filesystem land about how/when we want
patches to hit the list - I'm not a huge fan of the patch bombs that
drown everything else out on the list, which is what it would be if I
did mail everything.
But if the email workflow is really what you want, and if it's going to
be generating useful review (list activity is growing...), I could be
convinced...
We're getting past the "just fix all the stupid shit" phase, and my
output is (I hope) trending toward something more stustainable, with a
stream of more _interesting_ patches to talk about, so - yeah, it's
starting to sound more reasonable, if that's what people want.
My priority is just going to be on fostering _useful_ technical
discussion. If the only reason you're wanting patches on the list is
because of trivial shit automated tests can and do catch - that's not a
win, to me. If I start posting patch series and we seem to be learning
from it, I'll stick with it.