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] [day] [month] [year] [list]

Message-ID: <CAMuHMdVVVz34NBT7aBeupZvgJNEC3oE_np-ZcZMbFT00KyVP6Q@mail.gmail.com>
Date: Sat, 7 Sep 2024 13:18:15 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
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

Hi Kent,

On Wed, Sep 4, 2024 at 8:55 PM Kent Overstreet
<kent.overstreet@...ux.dev> 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@...erman.id.au 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@canb.auug.org.au/

noreply@...erman.id.au 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@...ux-m68k.org

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