Re: [GIT PULL] bcachefs updates fro 6.10-rc1

[Kent Overstreet]

On Tue, May 28, 2024 at 09:18:24AM +0200, Geert Uytterhoeven wrote:
> Hi Kent,
> 
> On Mon, May 20, 2024 at 4:39 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> > On Sun, May 19, 2024 at 12:14:34PM -0400, Kent Overstreet wrote:
> > > [...]
> > > bcachefs changes for 6.10-rc1
> > > [...]
> > >       bcachefs: bch2_btree_path_to_text()
> >
> > Hi Kent,
> >
> > I've asked after this before[1], but there continues to be a lot of
> > bcachefs development going on that is only visible when it appears in
> > -next or during the merge window. I cannot find the above commit on
> > any mailing list on lore.kernel.org[2]. The rules for -next are clear:
> > patches _must_ appear on a list _somewhere_ before they land in -next
> > (much less Linus's tree). The point is to get additional reviews, and
> > to serve as a focal point for any discussions that pop up over a given
> > change. Please adjust the bcachefs development workflow to address this.
> 
> This morning, the kisskb build service informed me about several build
> failures on m68k (e.g. [1]).
> 
> In fact, the kernel test robot had already detected them on multiple 32-bit
> platforms 4 days ago:
>   - Subject: [bcachefs:bcachefs-testing 21/23] fs/bcachefs/btree_io.c:542:7:
>     warning: format specifies type 'size_t' (aka 'unsigned int') but the
>     argument has type 'unsigned long'[2]
>   - Subject: [bcachefs:bcachefs-testing 21/23] fs/bcachefs/btree_io.c:541:33:
>     warning: format '%zu' expects argument of type 'size_t', but argument
>     3 has type 'long unsigned int'[3]
> 
> These are caused by commit 1d34085cde461893 ("bcachefs:
> Plumb bkey into __btree_err()"), which is nowhere to be found on
> any public mailing list archived by lore.
> 
> +               prt_printf(out, " bset byte offset %zu",
> +                          (unsigned long)(void *)k -
> +                          ((unsigned long)(void *)i & ~511UL));
> 
> Please stop committing private unreviewed patches to linux-next,
> as I have asked before [4].
> Thank you!

You seem to be complaining about test infrastructur eissues - you don't
seriously expect code review to be catching 32 bit build isues, do you?

0day takes awhile to run, so I don't always see these right away. I'll
add some 32 bit builds to my own test infrastructure.