Tea Inside Mailing List <[email protected]>
 help / color / mirror / Atom feed
From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: io-uring Mailing List <[email protected]>,
	GNU/Weeb Mailing List <[email protected]>,
	Tea Inside Mailing List <[email protected]>,
	Ammar Faizi <[email protected]>,
	Miyasaki Kohaku <[email protected]>,
	Alviro Iskandar Setiawan <[email protected]>
Subject: [PATCH] nolibc: Don't use `malloc()` and `free()` as the function name
Date: Sun, 23 Jan 2022 14:42:30 +0700	[thread overview]
Message-ID: <[email protected]> (raw)

Miyasaki reports that liburing with CONFIG_NOLIBC breaks apps that
use libc. The first spotted issue was a realloc() call that results
in an invalid pointer, and then the program exits with SIGABRT.

The cause is liburing nolibc overrides malloc() and free() from the
libc (especially when we statically link the "liburing.a" to the apps
that use libc).

The malloc() and free() from liburing nolibc use hand-coded Assembly
to invoke mmap() and munmap() syscall directly. That means any
allocation from malloc() is not a valid object with respect to the
libc, and free() will also break the app if we use it to free a
pointer from a libc function (e.g., strdup()).

liburing nolibc should not break any libc app.

This renames the malloc() and free() to __uring_malloc() and
__uring_free(). Also, add new inline functions to wrap the malloc()
and free(), they are uring_malloc() and uring_free(). These wrappers
will call the appropriate functions depending on CONFIG_NOLIBC.

Fixes: f48ee3168cdc325233825603269f304d348d323c ("Add nolibc build support")
Cc: Tea Inside Mailing List <[email protected]>
Reported-by: Miyasaki Kohaku <[email protected]>
Tested-by: Miyasaki Kohaku <[email protected]>
Co-authored-by: Alviro Iskandar Setiawan <[email protected]>
Signed-off-by: Alviro Iskandar Setiawan <[email protected]>
Signed-off-by: Ammar Faizi <[email protected]>
---
 src/lib.h    | 20 ++++++++++++++++++++
 src/nolibc.c |  4 ++--
 src/setup.c  |  6 +++---
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/src/lib.h b/src/lib.h
index 58d91be..bd02805 100644
--- a/src/lib.h
+++ b/src/lib.h
@@ -25,6 +25,26 @@
 })
 #endif
 
+void *__uring_malloc(size_t len);
+void __uring_free(void *p);
+
+static inline void *uring_malloc(size_t len)
+{
+#ifdef CONFIG_NOLIBC
+	return __uring_malloc(len);
+#else
+	return malloc(len);
+#endif
+}
+
+static inline void uring_free(void *ptr)
+{
+#ifdef CONFIG_NOLIBC
+	__uring_free(ptr);
+#else
+	free(ptr);
+#endif
+}
 
 static inline long get_page_size(void)
 {
diff --git a/src/nolibc.c b/src/nolibc.c
index 251780b..f7848d3 100644
--- a/src/nolibc.c
+++ b/src/nolibc.c
@@ -23,7 +23,7 @@ struct uring_heap {
 	char		user_p[] __attribute__((__aligned__));
 };
 
-void *malloc(size_t len)
+void *__uring_malloc(size_t len)
 {
 	struct uring_heap *heap;
 
@@ -36,7 +36,7 @@ void *malloc(size_t len)
 	return heap->user_p;
 }
 
-void free(void *p)
+void __uring_free(void *p)
 {
 	struct uring_heap *heap;
 
diff --git a/src/setup.c b/src/setup.c
index 891fc43..1e4dbf4 100644
--- a/src/setup.c
+++ b/src/setup.c
@@ -178,7 +178,7 @@ struct io_uring_probe *io_uring_get_probe_ring(struct io_uring *ring)
 	int r;
 
 	len = sizeof(*probe) + 256 * sizeof(struct io_uring_probe_op);
-	probe = malloc(len);
+	probe = uring_malloc(len);
 	if (!probe)
 		return NULL;
 	memset(probe, 0, len);
@@ -187,7 +187,7 @@ struct io_uring_probe *io_uring_get_probe_ring(struct io_uring *ring)
 	if (r >= 0)
 		return probe;
 
-	free(probe);
+	uring_free(probe);
 	return NULL;
 }
 
@@ -208,7 +208,7 @@ struct io_uring_probe *io_uring_get_probe(void)
 
 void io_uring_free_probe(struct io_uring_probe *probe)
 {
-	free(probe);
+	uring_free(probe);
 }
 
 static inline int __fls(int x)
-- 
2.32.0



             reply	other threads:[~2022-01-23  7:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-23  7:42 Ammar Faizi [this message]
2022-01-23 16:36 ` [PATCH] nolibc: Don't use `malloc()` and `free()` as the function name Jens Axboe

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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