From: Stephen Rothwell <sfr@canb.auug.org.au>
To: David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Networking <netdev@vger.kernel.org>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Suren Baghdasaryan <surenb@google.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>
Subject: Re: linux-next: manual merge of the net-next tree with the mm tree
Date: Mon, 29 Apr 2024 12:33:51 +1000 [thread overview]
Message-ID: <20240429123351.03b44797@canb.auug.org.au> (raw)
In-Reply-To: <20240429114302.7af809e8@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 5251 bytes --]
Hi all,
On Mon, 29 Apr 2024 11:43:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> include/linux/slab.h
>
> between commit:
>
> 7bd230a26648 ("mm/slab: enable slab allocation tagging for kmalloc and friends")
>
> from the mm_unstable branch of the mm tree and commit:
>
> a1d6063d9f2f ("slab: introduce kvmalloc_array_node() and kvcalloc_node()")
>
> from the net-next tree.
>
> I fixed it up (maybe? see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
I tried again, see below.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/slab.h
index 4cc37ef22aae,d1d1fa5e7983..88426b015faa
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@@ -773,40 -744,66 +773,54 @@@ static inline __alloc_size(1, 2) void *
* @size: how many bytes of memory are required.
* @flags: the type of memory to allocate (see kmalloc).
*/
-static inline __alloc_size(1) void *kzalloc(size_t size, gfp_t flags)
+static inline __alloc_size(1) void *kzalloc_noprof(size_t size, gfp_t flags)
{
- return kmalloc(size, flags | __GFP_ZERO);
+ return kmalloc_noprof(size, flags | __GFP_ZERO);
}
+#define kzalloc(...) alloc_hooks(kzalloc_noprof(__VA_ARGS__))
+#define kzalloc_node(_size, _flags, _node) kmalloc_node(_size, (_flags)|__GFP_ZERO, _node)
-/**
- * kzalloc_node - allocate zeroed memory from a particular memory node.
- * @size: how many bytes of memory are required.
- * @flags: the type of memory to allocate (see kmalloc).
- * @node: memory node from which to allocate
- */
-static inline __alloc_size(1) void *kzalloc_node(size_t size, gfp_t flags, int node)
-{
- return kmalloc_node(size, flags | __GFP_ZERO, node);
-}
+extern void *kvmalloc_node_noprof(size_t size, gfp_t flags, int node) __alloc_size(1);
+#define kvmalloc_node(...) alloc_hooks(kvmalloc_node_noprof(__VA_ARGS__))
-extern void *kvmalloc_node(size_t size, gfp_t flags, int node) __alloc_size(1);
-static inline __alloc_size(1) void *kvmalloc(size_t size, gfp_t flags)
-{
- return kvmalloc_node(size, flags, NUMA_NO_NODE);
-}
-static inline __alloc_size(1) void *kvzalloc_node(size_t size, gfp_t flags, int node)
-{
- return kvmalloc_node(size, flags | __GFP_ZERO, node);
-}
-static inline __alloc_size(1) void *kvzalloc(size_t size, gfp_t flags)
-{
- return kvmalloc(size, flags | __GFP_ZERO);
-}
+#define kvmalloc(_size, _flags) kvmalloc_node(_size, _flags, NUMA_NO_NODE)
+#define kvmalloc_noprof(_size, _flags) kvmalloc_node_noprof(_size, _flags, NUMA_NO_NODE)
+#define kvzalloc(_size, _flags) kvmalloc(_size, _flags|__GFP_ZERO)
-static inline __alloc_size(1, 2) void *
-kvmalloc_array_node(size_t n, size_t size, gfp_t flags, int node)
+#define kvzalloc_node(_size, _flags, _node) kvmalloc_node(_size, _flags|__GFP_ZERO, _node)
+
- static inline __alloc_size(1, 2) void *kvmalloc_array_noprof(size_t n, size_t size, gfp_t flags)
++static inline __alloc_size(1, 2) void *kvmalloc_array_node_noprof(size_t n, size_t size, gfp_t flags, int node)
{
size_t bytes;
if (unlikely(check_mul_overflow(n, size, &bytes)))
return NULL;
- return kvmalloc_node_noprof(bytes, flags, NUMA_NO_NODE);
- return kvmalloc_node(bytes, flags, node);
++ return kvmalloc_node_noprof(bytes, flags, node);
+ }
+
++#define kvmalloc_array_node(...) alloc_hooks(kvmalloc_array_node_noprof(__VA_ARGS__))
++
+ static inline __alloc_size(1, 2) void *
+ kvmalloc_array(size_t n, size_t size, gfp_t flags)
+ {
+ return kvmalloc_array_node(n, size, flags, NUMA_NO_NODE);
+ }
++#define kvmalloc_array_noprof(_n, _size, _flags) kvmalloc_array(_n, _size, _flags)
+
+ static inline __alloc_size(1, 2) void *
+ kvcalloc_node(size_t n, size_t size, gfp_t flags, int node)
+ {
- return kvmalloc_array_node(n, size, flags | __GFP_ZERO, node);
++ return kvmalloc_array_node_noprof(n, size, flags | __GFP_ZERO, node);
}
- #define kvmalloc_array(...) alloc_hooks(kvmalloc_array_noprof(__VA_ARGS__))
-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)
- #define kvcalloc_noprof(_n, _size, _flags) kvmalloc_array_noprof(_n, _size, _flags|__GFP_ZERO)
++#define kvcalloc_noprof(_n, _size, _flags) kvmalloc_array_node_noprof(_n, _size, _flags|__GFP_ZERO)
-extern void *kvrealloc(const void *p, size_t oldsize, size_t newsize, gfp_t flags)
+extern void *kvrealloc_noprof(const void *p, size_t oldsize, size_t newsize, gfp_t flags)
__realloc_size(3);
+#define kvrealloc(...) alloc_hooks(kvrealloc_noprof(__VA_ARGS__))
+
extern void kvfree(const void *addr);
DEFINE_FREE(kvfree, void *, if (_T) kvfree(_T))
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-04-29 2:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 1:43 linux-next: manual merge of the net-next tree with the mm tree Stephen Rothwell
2024-04-29 2:33 ` Stephen Rothwell [this message]
2024-05-15 22:51 ` Stephen Rothwell
2024-05-15 22:55 ` Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240429123351.03b44797@canb.auug.org.au \
--to=sfr@canb.auug.org.au \
--cc=akpm@linux-foundation.org \
--cc=aleksander.lobakin@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=kent.overstreet@linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=surenb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).