Re: linux-next: build failure after merge of the kspp-gustavo tree

Hi Gustavo,

On Thu, 14 Oct 2021 19:07:52 -0500 "Gustavo A. R. Silva" [off-list ref] wrote:

On Fri, Oct 15, 2021 at 10:48:40AM +1100, Stephen Rothwell wrote:

quoted

After merging the kspp-gustavo tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/bpf_verifier.h:9,
                 from kernel/bpf/verifier.c:12:
kernel/bpf/verifier.c: In function 'jit_subprogs':
include/linux/filter.h:366:4: error: cast between incompatible function types from 'unsigned int (*)(const void *, const struct bpf_insn *)' to 'u64 (*)(u64,  u64,  u64,  u64,  u64)' {aka 'long long unsigned int (*)(long long unsigned int,  long long unsigned int,  long long unsigned int,  long long unsigned int,  long long unsigned int)'} [-Werror=cast-function-type]
  366 |   ((u64 (*)(u64, u64, u64, u64, u64))(x))  

[..]

quoted

  21078041965e ("Makefile: Enable -Wcast-function-type")

I have used the kspp-gustavo tree from next-20211013 for today.  

Please, merge my -next tree. All the warnings above are already fixed in
bpf-next by commit:

	3d717fad5081 ("bpf: Replace "want address" users of BPF_CAST_CALL with BPF_CALL_IMM")

So, once you merge bpf-next, those warnings will go away.

Well, I really prefer for trees in linux-next to have no dependencies
like this.  For one thing, you cannot test your tree as Linus will
because an allmodconfig build of your tree alone fails.  For another,
if Linus merges your tree before net-next (which will merge bpf-next
before the merge window), he will yell at you (and me) for breaking his
tree.  And in the general case, it could be possible that Linus will
decide to not merge the tree containing the fix (unlikely for the
net-next tree).

Also, the trees in linux-next are merged in whatever order I take a
fancy to (and sometimes I do move them around).  I could not have known
that there was a dependency between these 2 trees (well, actually I
could have if I could remember back to Sept 30 when I first reported
this :-( ) and (given that I merge over 350 trees) it would be a pain
to have to keep track (and keep moving trees around.

So it is a pity that 3d717fad5081 was not in a small branch that could
be merged into both trees.  You could, of course, also apply it to your
tree and we could put up with any resulting conflicts.

This discussion has been had before ... trees that Linus is asked to
merge should be fairly much standalone ...
-- 
Cheers,
Stephen Rothwell