Hi Kent,
On Wed, Sep 4, 2024 at 8:55 PM Kent Overstreet
<kent.overstreet@xxxxxxxxx> wrote:
> On Tue, Sep 03, 2024 at 03:53:56PM GMT, Geert Uytterhoeven wrote:
> > 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:
[...]
> > 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.
Please follow the standard procedure. Posting patches is actually a
requirement for your branch being part of linux-next:
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
https://lore.kernel.org/all/20240807080423.45efb506@xxxxxxxxxxxxxxxx/
noreply@xxxxxxxxxxxxxx told me you broke 32-bit builds (again):
ERROR: modpost: "__udivdi3" [fs/bcachefs/bcachefs.ko] undefined!
http://kisskb.ellerman.id.au/kisskb/buildresult/15230339/
http://kisskb.ellerman.id.au/kisskb/buildresult/15230439/
I have bisected this to commit 7abab864a198fbb6 ("bcachefs: Progress
indicator for extents_to_backpointers"), which was not posted to
a public mailing list archived by lore (again), and does a plain
64-by-size_t division, which should use div64_ul() instead.
--- a/fs/bcachefs/backpointers.c
+++ b/fs/bcachefs/backpointers.c
@@ -810,7 +810,7 @@ static inline void progress_init(struct
progress_indicator_state *s,
u64 v;
bch2_accounting_mem_read(c,
disk_accounting_pos_to_bpos(&acc), &v, 1);
- s->nodes_total += v / btree_sectors(c);
+ s->nodes_total += div64_ul(v, btree_sectors(c));
}
}
Thanks for complying!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
