linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.11-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fvk7vjfz4f2c2x5hxjajiwz5doxeg54owgpzob2kskkftshcoo@5sl5lu6nenyu>
Date: Wed, 4 Sep 2024 14:55:13 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [GIT PULL] bcachefs fixes for 6.11-rc6

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@...erman.id.au 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.