In D41421#950671, @lwhsu wrote:

In D41421#950213, @minsoochoo0122_proton.me wrote:

In D41421#948012, @instructionset_gmail.com wrote:

In D41421#946051, @minsoochoo0122_proton.me wrote:

Parent revision D41461 is closed. Now we can test this on local machines on -CURRENT.

I've been testing this on main and stable/13 (with some tweaks). If there are any specific tests I can do that would be helpful let me know

In the release notes, there are some new features added in jemalloc 5.3.0. For example,

• Make the behavior of realloc(ptr, 0) configurable with opt.zero_realloc
• Add the thread.idle mallctl which hints that the calling thread will be idle for a nontrivial period of time.
• Add mallctl interfaces:
  • opt.zero_realloc (@davidtgoldblatt)
  • opt.cache_oblivious (@interwq)
  • opt.prof_leak_error (@yunxuo)
  • opt.stats_interval (@interwq)
  • opt.stats_interval_opts (@interwq)
  • opt.tcache_max (@interwq)
  • opt.trust_madvise (@azat)
  • prof.prefix (@zhxchen17)
  • stats.zero_reallocs (@davidtgoldblatt)
  • thread.idle (@davidtgoldblatt)
  • thread.peak.{read,reset} (@davidtgoldblatt)

and so on.

It would be really nice if we can test this against with the tests under /usr/tests . I know it is still very tricky to run it. If you are interested, please check the scripts at https://github.com/freebsd/freebsd-ci and let me know (and/or -testing mailing list) if you have any questions.

By the way, because this is not a major version bump (5.x.x), will this version bump be abled to be MFCed to stable/14?

Theoretically, yes, but it would be nice to check the compatibility thoroughly.

• Use memalign from jemalloc

I think it might make sense to split the switch to the jemalloc memalign() into a separate commit.

In D41421#950213, @minsoochoo0122_proton.me wrote:

In D41421#948012, @instructionset_gmail.com wrote:

In D41421#946051, @minsoochoo0122_proton.me wrote:

Parent revision D41461 is closed. Now we can test this on local machines on -CURRENT.

I've been testing this on main and stable/13 (with some tweaks). If there are any specific tests I can do that would be helpful let me know

In the release notes, there are some new features added in jemalloc 5.3.0. For example,

• Make the behavior of realloc(ptr, 0) configurable with opt.zero_realloc
• Add the thread.idle mallctl which hints that the calling thread will be idle for a nontrivial period of time.
• Add mallctl interfaces:
  • opt.zero_realloc (@davidtgoldblatt)
  • opt.cache_oblivious (@interwq)
  • opt.prof_leak_error (@yunxuo)
  • opt.stats_interval (@interwq)
  • opt.stats_interval_opts (@interwq)
  • opt.tcache_max (@interwq)
  • opt.trust_madvise (@azat)
  • prof.prefix (@zhxchen17)
  • stats.zero_reallocs (@davidtgoldblatt)
  • thread.idle (@davidtgoldblatt)
  • thread.peak.{read,reset} (@davidtgoldblatt)

and so on.

In D41421#948012, @instructionset_gmail.com wrote:

In D41421#946051, @minsoochoo0122_proton.me wrote:

Parent revision D41461 is closed. Now we can test this on local machines on -CURRENT.

I've been testing this on main and stable/13 (with some tweaks). If there are any specific tests I can do that would be helpful let me know

In D41421#946051, @minsoochoo0122_proton.me wrote:

Parent revision D41461 is closed. Now we can test this on local machines on -CURRENT.

Parent revision D41461 is closed. Now we can test this on local machines on -CURRENT.

You may send me the complete git patch by mail. Please ensure that the author metadata is correctly filled. Also it would be useful to add tags like Differential revision: etc.

Stores null string in name parameter for stub function.

In D41461#945982, @kib wrote:

In D41461#945966, @minsoochoo0122_proton.me wrote:

Is there any possible way to store null string in _pthread_stubs.c? I can't figure out how to store null string using STUB_FUNC3.

I do not understand neither your questions, nor can I guess the possible confusion behind them. Would it be simpler if I provide the compilable (not tested) changes for _pthread_stub.c?

diff --git a/lib/libc/gen/_pthread_stubs.c b/lib/libc/gen/_pthread_stubs.c
index 6741c6a5ec51..3fc0817b8655 100644
--- a/lib/libc/gen/_pthread_stubs.c
+++ b/lib/libc/gen/_pthread_stubs.c
@@ -58,6 +58,7 @@ static int		stub_fail(void);
 static int		stub_true(void);
 static void		stub_exit(void);
 static int		stub_esrch(void);
+static int		stub_getname_np(pthread_t, char *, size_t);
 
 #define	PJT_DUAL_ENTRY(entry)	\
 	(pthread_func_t)entry, (pthread_func_t)entry
@@ -131,6 +132,7 @@ pthread_func_entry_t __thr_jtable[PJT_MAX] = {
 	[PJT_MUTEXATTR_SETROBUST] =	{PJT_DUAL_ENTRY(stub_zero)},
 	[PJT_GETTHREADID_NP] =		{PJT_DUAL_ENTRY(stub_zero)},
 	[PJT_ATTR_GET_NP] =		{PJT_DUAL_ENTRY(stub_esrch)},
+	[PJT_GETNAME_NP] =		{PJT_DUAL_ENTRY(stub_getname_np)},
 };
 
 /*
@@ -289,6 +291,7 @@ STUB_FUNC3(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, void *,
 STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, void, int)
 STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, void, int)
 STUB_FUNC2(pthread_attr_get_np, PJT_ATTR_GET_NP, int, pthread_t, pthread_attr_t *)
+STUB_FUNC3(pthread_gettname_np,	PJT_GETNAME_NP, int, pthread_t, char *, size_t)
 
 static int
 stub_zero(void)
@@ -337,3 +340,13 @@ stub_esrch(void)
 {
 	return (ESRCH);
 }
+
+static int
+stub_getname_np(pthread_t thread, char *buf, size_t len)
+{
+	if (thread != &main_thread)
+		return (ESRCH);
+	if (len >= 1)
+		buf[0] = '\0';
+	return (0);
+}

In D41461#945966, @minsoochoo0122_proton.me wrote:

Is there any possible way to store null string in _pthread_stubs.c? I can't figure out how to store null string using STUB_FUNC3.

I do not understand neither your questions, nor can I guess the possible confusion behind them. Would it be simpler if I provide the compilable (not tested) changes for _pthread_stub.c?

In D41461#945957, @kib wrote:

In D41461#945944, @minsoochoo0122_proton.me wrote:

In D41461#945942, @kib wrote:

In D41461#945941, @minsoochoo0122_proton.me wrote:

In D41461#945937, @kib wrote:

This is still wrong IMO. The main case is to return empty name for main thread, and it does not matter much if we do not detect invalid thread handle.

As was said before, stub pthread_getname_np() should store nul string in the target buffer.

How can I store null string to the name parameter? Does stub_null works for parameters as well?

You do if (len >= 1) name[0] = '\0'; as usual. What is the problem? stub_null() cannot be used, of course.

Sorry, my question was unclear. In `lib/libthr/thread/thr_info.c", I see

if (len > 0)
    buf[0] = '\0';

But I cannot find any file to write this for the stub function. Where can I write this code for stub functions? Like lib/libc/gen/__pthread_mutex_init_calloc_cb_stub.c, should I implement the stub function in a new file?

What is wrong with libc/gen/_pthread_stubs.c?

Example:

/* lib/libc/gen/__pthread_getname_np_stub.c */
#include <sys/cdefs.h>
#include <pthread.h>
#include <errno.h>
#include "libc_private.h"

int
_pthread_getname_np_stub(pthread_t thread, char *buf, size_t len)
{
    if (len > 0)
        buf[0] = '\0';
    return (ESRCH);

This should be `return (0);`

}

In D41461#945944, @minsoochoo0122_proton.me wrote:

In D41461#945942, @kib wrote:

In D41461#945941, @minsoochoo0122_proton.me wrote:

In D41461#945937, @kib wrote:

This is still wrong IMO. The main case is to return empty name for main thread, and it does not matter much if we do not detect invalid thread handle.

As was said before, stub pthread_getname_np() should store nul string in the target buffer.

How can I store null string to the name parameter? Does stub_null works for parameters as well?

You do if (len >= 1) name[0] = '\0'; as usual. What is the problem? stub_null() cannot be used, of course.

Sorry, my question was unclear. In `lib/libthr/thread/thr_info.c", I see

if (len > 0)
    buf[0] = '\0';

But I cannot find any file to write this for the stub function. Where can I write this code for stub functions? Like lib/libc/gen/__pthread_mutex_init_calloc_cb_stub.c, should I implement the stub function in a new file?

What is wrong with libc/gen/_pthread_stubs.c?

In D41461#945942, @kib wrote:

In D41461#945941, @minsoochoo0122_proton.me wrote:

In D41461#945937, @kib wrote:

This is still wrong IMO. The main case is to return empty name for main thread, and it does not matter much if we do not detect invalid thread handle.

As was said before, stub pthread_getname_np() should store nul string in the target buffer.

How can I store null string to the name parameter? Does stub_null works for parameters as well?

You do if (len >= 1) name[0] = '\0'; as usual. What is the problem? stub_null() cannot be used, of course.

In D41461#945941, @minsoochoo0122_proton.me wrote:

In D41461#945937, @kib wrote:

This is still wrong IMO. The main case is to return empty name for main thread, and it does not matter much if we do not detect invalid thread handle.

As was said before, stub pthread_getname_np() should store nul string in the target buffer.

How can I store null string to the name parameter? Does stub_null works for parameters as well?

In D41461#945937, @kib wrote:

This is still wrong IMO. The main case is to return empty name for main thread, and it does not matter much if we do not detect invalid thread handle.

As was said before, stub pthread_getname_np() should store nul string in the target buffer.

This is still wrong IMO. The main case is to return empty name for main thread, and it does not matter much if we do not detect invalid thread handle.

Using stub_esrch when an invalid thread comes a parameter.

Updating diff file to conform recent changes in lib/libc/stdlib/malloc

In D41461#945003, @jrtc27 wrote:

In D41461#945002, @minsoochoo0122_proton.me wrote:

In D41461#945001, @jrtc27 wrote:

In D41461#944998, @minsoochoo0122_proton.me wrote:

pthread_getname_np returns 0 for success otherwise error code.

You didn't change the implementation, just the prototype? It's still not writing to the string, and it's reporting success even for garbage input threads.

Sorry, I'm new to contributing base system, and I don't understand which implementation you mean. From the code I read, pthread_getname_np is symbol of _thr_getname_np defined in lib/libthr/thread/thr_info.c, and it exports to libc. Is there any addition work to be done in stub? Thanks.

The stub needs to be a minimal implementation when there are no threads that satisfies the API documentation in the manpage. stub_zero does not do that, because it (a) doesn't validate the thread (b) doesn't initialise the buffer. This means that (a) if a caller provides junk to the function it returns 0 for success rather than ESRCH for failure (b) if a caller tries to use the buffer even after it gave it a pthread_t of &main_thread it'll be reading uninitialised junk (and may run off the end of the buffer if there doesn't happen to be a 0 byte in there). In short, stub_zero never works properly to implement pthread_getname_np.

In D41461#945002, @minsoochoo0122_proton.me wrote:

In D41461#945001, @jrtc27 wrote:

In D41461#944998, @minsoochoo0122_proton.me wrote:

pthread_getname_np returns 0 for success otherwise error code.

You didn't change the implementation, just the prototype? It's still not writing to the string, and it's reporting success even for garbage input threads.

Sorry, I'm new to contributing base system, and I don't understand which implementation you mean. From the code I read, pthread_getname_np is symbol of _thr_getname_np defined in lib/libthr/thread/thr_info.c, and it exports to libc. Is there any addition work to be done in stub? Thanks.

In D41461#945001, @jrtc27 wrote:

In D41461#944998, @minsoochoo0122_proton.me wrote:

pthread_getname_np returns 0 for success otherwise error code.

You didn't change the implementation, just the prototype? It's still not writing to the string, and it's reporting success even for garbage input threads.

In D41461#944998, @minsoochoo0122_proton.me wrote:

pthread_getname_np returns 0 for success otherwise error code.

pthread_getname_np returns 0 for success otherwise error code.

Don't export _pthread_getname_np

Removed gnu11 flag and fixed gnu99 incompatibility

pthread_getname_np goes to FBSD_1.6 to match version in pthread.map
pthread_getname_np STUB_FUNC3 not STUB_FUNC2 since it takes 3 parameters

In D41461#944269, @imp wrote:

I wonder why these were not exported... Is there any indication as to why? Was it intentoinal or an oversight?

In D41461#944269, @imp wrote:

I wonder why these were not exported... Is there any indication as to why? Was it intentoinal or an oversight?

Created separate revision for pthread_getname_np and _pthread_getname_np. This revision depends on D41461

I wonder why these were not exported... Is there any indication as to why? Was it intentoinal or an oversight?