Should we add security ?

Remove unnecessary slash

update information

There are several cases where we use "WWW mirrors". Should this be replaced? If so, should we replace that with "HTTPS mirrors" or "Web mirrors"?

Remove cd /usr/src

Remove unrelated change

Remove unrelated change

Any update?

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

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

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

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#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#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#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.

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#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.

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?

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

Fixed build error with missing _pthread_getname_np symbol reference

I still get error

cd /usr/src; _PARALLEL_SUBDIR_OK=1 time env MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE= BUILD_TOOLS_META=.NOMETA CC="cc -target x86_64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++  -target x86_64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP="cpp -target x86_64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS="as" AR="ar" ELFCTL="elfctl" LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  SYSROOT=/usr/obj/usr/src/amd64.amd64/tmp make  -f Makefile.inc1  BWPHASE=everything  DESTDIR=/usr/obj/usr/src/amd64.amd64/tmp all
(cd /usr/src/lib/csu/tests/dynamic &&  DEPENDFILE=.depend.init_test  NO_SUBDIR=1 make -f /usr/src/lib/csu/tests/dynamic/Makefile _RECURSING_PROGS=t  PROG=init_test )
Building /usr/obj/usr/src/amd64.amd64/lib/csu/tests/dynamic/init_test.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/tests/dynamic/init_test.full
ld: error: undefined reference due to --no-allow-shlib-undefined: _pthread_getname_np
>>> referenced by /usr/obj/usr/src/amd64.amd64/tmp/lib/libc.so.7
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Updated FREEBSD-diffs

In D41421#943650, @imp wrote:

In D41421#943562, @minsoochoo0122_proton.me wrote:

In D41421#943128, @lwhsu wrote:

Thanks for the work! One thing I would like to mention is that it seems having some issue building or running on 32-bit older CURRENT: https://github.com/jemalloc/jemalloc/pull/2228

I did some test on 32-bit FreeBSD and I found out that when clock_gettime is used on 64bit machine but compiled in 32bit, it sets tv_sec (time_t) as -1. On 32bit FreeBSD, clock_gettime works as expected.

that seems like it's a bug. On powerpc and amrv7 tv_sec should be the same. On i386, tv_sec is only32-bit, but we still have a dozen years left until it's inadequate. Can you finle a bug, if you haven't already, with a way to reproduce this?

In D41421#943128, @lwhsu wrote:

Thanks for the work! One thing I would like to mention is that it seems having some issue building or running on 32-bit older CURRENT: https://github.com/jemalloc/jemalloc/pull/2228

In D41421#943128, @lwhsu wrote:

Thanks for the work! One thing I would like to mention is that it seems having some issue building or running on 32-bit older CURRENT: https://github.com/jemalloc/jemalloc/pull/2228

Solved libc build error. However, linking fails with error that _pthread_getname_np is undefined symbol.

Building /usr/obj/usr/src/amd64.amd64/lib/csu/tests/dynamic/init_test.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/tests/dynamic/init_test.full
ld: error: undefined reference due to --no-allow-shlib-undefined: _pthread_getname_np
>>> referenced by /usr/obj/usr/src/amd64.amd64/tmp/lib/libc.so.7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

When I build new jemalloc, clang generates an error:

jemalloc_prof_sys.c:310:9: error: call to undeclared function 'pthread_getname_np'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration]
        return pthread_getname_np(pthread_self(), buf, limit);
               ^
jemalloc_prof_sys.c:310:9: note: did you mean '_pthread_getname_np'?
/usr/src/include/pthread.h:305:6: note: '_pthread_getname_np' declared here
int             pthread_getname_np(pthread_t, char *, size_t);
                ^
/usr/src/lib/libc/include/namespace.h:141:30: note: expanded from macro 'pthread_getname_np'
#define         pthread_getname_np              _pthread_getname_np
                                                ^
1 error generated.
*** [jemalloc_prof_sys.o] Error code 1

although <pthread.h> is already included. Any ideas?

This is now resolved in Hugo 115.4 git log. Closing revision.

Additionally, when my usb keyboard (Corsair K65 RGB) is connected my raspberry pi during boot, the boot process becomes really slow especially when loading kernel. I don't know if this problem only occurs only on the 8GB rpi4 though.

Fixed build error on sysutils/rockpro64

In D41193#938512, @manu wrote:

In D41193#938505, @minsoochoo0122_proton.me wrote:

u-boot-rockpro64 build fails.

# make install
===>  Building for u-boot-rockpro64-2023.07.02
gmake[1]: Entering directory '/usr/ports/sysutils/u-boot-rockpro64/work/u-boot-2023.07.02'
  ENVC    include/generated/env.txt
  UPD     include/generated/timestamp_autogenerated.h
  ENVP    include/generated/env.in
  ENVT    include/generated/environment.h
  CC      cmd/version.o
  CC      env/common.o
  AR      cmd/built-in.o
  CC      lib/efi_loader/dtbdump.o
  CC      lib/efi_loader/initrddump.o
  AR      env/built-in.o
  LD      lib/efi_loader/initrddump_efi.so
aarch64-none-elf-ld.bfd: warning: -z norelro ignored
  OBJCOPY lib/efi_loader/initrddump.efi
  LD      lib/efi_loader/dtbdump_efi.so
aarch64-none-elf-ld.bfd: warning: -z norelro ignored
  OBJCOPY lib/efi_loader/dtbdump.efi
  KSL     keep-syms-lto.c
/bin/sh: ./scripts/gen_ll_addressable_symbols.sh: not found
gmake[1]: *** [Makefile:1718: keep-syms-lto.c] Error 127
gmake[1]: *** Deleting file 'keep-syms-lto.c'
gmake[1]: Leaving directory '/usr/ports/sysutils/u-boot-rockpro64/work/u-boot-2023.07.02'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/u-boot-rockpro64

although scripts/gen_ll_addressable_symbols.sh exists.

I couldn't find any solutions on the internet. Can this be fixed by modifying u-boot-master/Makefile or should I report this to u-boot project?

Likely because of https://github.com/u-boot/u-boot/blob/master/scripts/gen_ll_addressable_symbols.sh#L1

Check if that can be patched to be /bin/sh, if not we need to add bash to the build depends and add a BINARY_ALIAS for it to be in /bin/

u-boot-rockpro64 build fails.

# make install
===>  Building for u-boot-rockpro64-2023.07.02
gmake[1]: Entering directory '/usr/ports/sysutils/u-boot-rockpro64/work/u-boot-2023.07.02'
  ENVC    include/generated/env.txt
  UPD     include/generated/timestamp_autogenerated.h
  ENVP    include/generated/env.in
  ENVT    include/generated/environment.h
  CC      cmd/version.o
  CC      env/common.o
  AR      cmd/built-in.o
  CC      lib/efi_loader/dtbdump.o
  CC      lib/efi_loader/initrddump.o
  AR      env/built-in.o
  LD      lib/efi_loader/initrddump_efi.so
aarch64-none-elf-ld.bfd: warning: -z norelro ignored
  OBJCOPY lib/efi_loader/initrddump.efi
  LD      lib/efi_loader/dtbdump_efi.so
aarch64-none-elf-ld.bfd: warning: -z norelro ignored
  OBJCOPY lib/efi_loader/dtbdump.efi
  KSL     keep-syms-lto.c
/bin/sh: ./scripts/gen_ll_addressable_symbols.sh: not found
gmake[1]: *** [Makefile:1718: keep-syms-lto.c] Error 127
gmake[1]: *** Deleting file 'keep-syms-lto.c'
gmake[1]: Leaving directory '/usr/ports/sysutils/u-boot-rockpro64/work/u-boot-2023.07.02'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

In D41192#938225, @manu wrote:

On what RPI model have this been tested ? Because updating rpi-firmware sometimes break some models.

Made sentence more clear. Release related docs are automatically generated after it is added to doc repository.

Approver list is now handled by gitadm@FreeBSD.org
Removed thermite.sh part.

I made comments in diff because there are things that I don't know about, like svnadmin. Can you check them please?