On Fri, 17 May 2024 at 19:22, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > include/linux/slab.h > https://lkml.kernel.org/r/20240429114302.7af809e8@xxxxxxxxxxxxxxxx This is not only a merge conflict, your tree is actively buggy. You have introduced changes like this: -static inline __alloc_size(1, 2) void *kvcalloc(size_t n, size_t size, gfp_t flags) -{ - return kvmalloc_array(n, size, flags | __GFP_ZERO); -} +#define kvcalloc(_n, _size, _flags) kvmalloc_array(_n, _size, _flags|__GFP_ZERO) and that's just completely wrong. Note the "_flags|__GFP_ZERO": yes, the bitwise or is fairly low down in the operator precedence rules, and it probably work sin practice because most cases will just pass in a simple expression for the flags, but it's still *horribly* wrong. I'm going to take this pull and fix up the cases I find, but I'm not happy with this kind of trivial C preprocessor misuse. I also note that you have *SEVEN* pointless merges that have no explanation for them. I'm happy that you use git, but that means that you also need to either (a) not do merges at all and treat it as a patch queue (b) do merges _properly_ and not throw them around like some madman And doing them properly means not only writing good commit messages, but actually having good reasons for them. As it is, we have 5d1bc760583f ("merge mm-hotfixes-stable into mm-nonmm-stable to pick up needed changes") 640958fde130 ("Merge branch 'master' into mm-stable") 4e2e36129225 ("Merge branch 'master' into mm-stable") 1dd4505cf4c8 ("Merge branch 'master' into mm-stable") 71919308943d ("Merge branch 'master' into mm-stable") b228ab57e51b ("Merge branch 'master' into mm-stable") 5e2806112864 ("Merge branch 'master' into mm-stable") and those one-liners are all the explanation there are for the merges, and NONE OF THOSE MERGES ARE VALID IN THE FIRST PLACE! They shouldn't have been merges! You literally have no new code on the other side. You should have just fast-forwarded to the new state, since your side didn't contain anything relevant any more. So the merges are doubly wrong. They have no explanation, but part of the reason that they have no explanation is probably exactly the fact that there *IS* no explanation for them. There is one fundamental rule of merges: if you can't explain why you'd need to merge, DON'T DO IT. There are lots of smaller rules too. See Documentation/maintainer/rebasing-and-merging.rst for at least some of them. Linus Linus
