kernel - Fix page fault in the jail unmount check
sys_unmount() printed the "does not belong to this jail" message using
uap->path, a user-space pointer. With SMAP enabled, kprintf() -> strlen()
faults on it.
Use nd.nl_path, the kernel copy that nlookup_init() already made.
Panic reproduce steps, assuming a jail is prepared at `/jail`:
```
jail# umount /dev
```
Reported-by: tuxillo
Bug: https://bugs.dragonflybsd.org/issues/3386
gcc120,gcc80: Reuse COMPILE.cc to avoid duplicating explicit rules
Make use of COMPILE.cc from <sys.mk> to avoid duplicating explicit rules
(in particular the various flags) in libstdc++/components/libconv_2011.
In addition, create a ".USE" reusable rule to further reduce duplicate
code.
bsd.sys.mk: Adjust -Wno-unused-value for WARNS level
Without this adjustment, building gnu/usr.bin/gdb/libdecnumber with
WARNS=2 would fail with the -Werror=unused-value warning, but with
WARNS=3 the building would succeed.
Discussed-with: swildner
gcc120,gcc80: Get rid of duplicate explicit compile rules
Make use of the new features implemented in the last commit.
Actually, this fixed one mistake in gcc80/libgcc that the 'raise'
flags group was ignored, because the explicit compile rules didn't refer
to the group flags. Luckily, the build result was good; md5 checksums
of the libraries don't change.
stand/pxeldr_tftp: Remove obsolete AFLAGS
Two reasons:
- AFLAGS is not used by the .S suffix rule; should use CFLAGS instead.
- This is no longer needed after the commit
6c644be32975767831a57868196e63523af13989 that collapsed makefile with
parent to avoid duplication.
gnu/lib: Add missing WARNS to gcc120 and gcc80
Note that the following libraries require WARNS=0:
- gcc80/libstdc++/components/libconv_supc
- gcc120/libstdc++/components/libconv_1998
- gcc120/libstdc++/components/libconv_supc
share/mk: Support per-target flags and explicit source mapping
* Add the "FLAGS.<target>.o" variable to specify per-target flags for
compiling a library target of all kinds, i.e., <target>.o, <target>.po
and <target>.So.
* Implement the reusable "_LIB_COMPILE.<ext>" compile rules to support
explicit source mapping. This is required to support compiling one
source file into multiple objects with different defines/flags.
The two features are combined to avoid duplicating the explicit compile
commands in GCC libraries (i.e., libgcc, libgcov, and libatomic).
share/mk: Implement reusable COMPILE.<ext> compile commands
Implement per-extension COMPILE.<ext> compile commands and introduce the
per-mode flags (e.g., _CFLAGS_MODE.o) to make them reusable in
<bsd.lib.mk>, and therefore avoid duplicate code.
This refactoring helps further introduce the per-target flags and .USE
targets for explicit source mappings in the forthcoming commits.
share/mk: Update suffix rules to avoid duplicates
* Add ${STATIC_CFLAGS} and ${STATIC_CXXFLAGS} flags to the .c and .cc
rules in <sys.mk>, so that they can be reused by <bsd.lib.mk>. The
${STATIC_CFLAGS} is only used by lib/libpam.
* Use the .o suffix rules from <sys.mk> and remove the duplicates in
<bsd.lib.mk>.
* Fix the .s rule to compile with "${AS} ${AFLAGS}", the same rule as
defined in <sys.mk>.
* Fix the .S rule to compile with "${CC} -x assembler-with-cpp" instead
of plain ${CC}.
* Some minor tweaks for consistency.
Also referred to FreeBSD.
hammer2(8): hash inode numbers and media offsets together
The recovery secondary hash XORs inode numbers with shifted media
offsets. The two values are correlated, so the XOR often cancels and
puts many entries in one bucket. This is a real concern because the
recovery is basically a block scan on a copy-on-write filesystem, so
there can be *many* copies of the same inode in the scan.
Hash the two complete values with the existing HAMMER2 XXH64 and share
the helper between both inode insertion paths.
Reported-by: tkusumi
Reviewed-by: dillon
Bug: https://bugs.dragonflybsd.org/issues/3378
vkernel64: Fix -Waddress warning in trap_fatal()
Fixes building with gcc120 that has -Werror enabled.
```
/usr/src/sys/platform/vkernel64/x86_64/trap.c: In function 'trap_fatal':
/usr/src/sys/platform/vkernel64/x86_64/trap.c:937:61: error: the comparison will always evaluate as 'true' for the address of 'p_comm' will never be NULL [-Werror=address]
937 | (u_long)curproc->p_pid, curproc->p_comm ?
| ^
In file included from ./machine/cpufunc.h:70,
from /usr/src/sys/sys/systm.h:50,
from /usr/src/sys/platform/vkernel64/x86_64/trap.c:51:
/usr/src/sys/sys/proc.h:290:25: note: 'p_comm' declared here
290 | char p_comm[MAXCOMLEN+1]; /* typ 16+1 bytes */
| ^~~~~~
cc1: all warnings being treated as errors
```
vkernel64: Fix kern_envp building bug with multiple '-e' flags
The 'name=value' environment entries are separated by one NUL in the
'kern_envp' buffer, which is ended by another NUL.
The '-e' flag parsing code previously determined the write position from
the allocated size (i.e., pos = kenv_size - 1), which counted the
stripped quote characters, so any environment entries specified by later
'-e' flags were appended after a premature end-of-environment and
therefore invisible.
Fix the bug by using 'kenv_pos' (renamed from 'pos') to correctly track
the write position for every '-e' flag. Meanwhile, consolidate the
malloc() into realloc(), which can handle a NULL input.
Assisted-by: DeepSeek-v4.1-flash (with Pi Coding Agent)
netinet: fix ARP resolution during the first second of uptime
A cloned route created while time_uptime is zero passes a zero expiry
to its neighbors. Zero denotes a permanent entry, so unresolved dynamic
neighbors never send ARP requests.
Add the arp_expire_unresolved (= time_uptime + 1) to keep dynamic expiry
nonzero and track the last request time separately, using la_asked to
indicate whether that time is valid. This preserves same-second rate
limiting and permanent-entry semantics without changing the routing ABI.
While there, fix the code to add arpt_down to rt_expire only when it's a
cloned route.
Co-authored-by: Aaron LI <aly at aaronly.me>
GitHub-PR: https://github.com/DragonFlyBSD/DragonFlyBSD/pull/58
kernel - Fix cache_fullpath() races in procfs
* Address races where an exiting process can cause procfs to
crash when procfs is building its directory for the process.
cache_fullpath() can have its nchandle ripped out from under it.
* Generally solved by making cache_fullpath() create ref'd copies
of the nchandle. Also provide a cache_fullpath_refd() that avoids
this.
* Make the file paths returned by procfs be relative to the calling
process so the path is actually useful regardless of chroot. If
the calling process happens to be within the same chroot, or in
a parent root / real root.
If the calling process is in a different chroot than the target
process such that the path is inaccessible, the path will be
be shown as "unknown".
[5 lines not shown]
amdgpu: Fix #GP panic on module loading caused by misaligned accesses
After the FPU/SIMD flag changes (commits 8363c80b88 and c12d11212d),
loading the amdgpu.ko module could simply panic the system, as reported
by kentish on ThinkPad T495 with Ryzen 5 3500U.
Various tests showed that compiling only dcn_calcs.o with '-O0' and
gcc80 made the module work, but '-O0' with gcc120 didn't. Tracking this
down revealed the kernel-stack misalignment issue for these amdgpu
sources. After the flags change, GCC generates 16-byte aligned SSE
memory accesses on the kernel stack, but our kernel stack is only 8-byte
aligned (TF_SIZE = 200 bytes), so this misaligned accesses caused #GP
panic as reported.
Add '-mpreferred-stack-boundary=3' to tell GCC about the real alignment
so it realigns the stack where needed, and thus fix the loading panic.
Tested-on: ThinkPad T495 with Ryzen 5 3500U
Reported-by: kentish
Assisted-by: DeepSeek-v4.1-flash (with Pi Coding Agent)
dsynth - Do not cross mount boundaries when making template's /etc
* When making the template's /etc, do not cross mount boundaries.
* This is a bit of a hack but /etc/namedb sometimes has a "dev"
subdirectory for its chroot area that mounts devfs. This kinda
implodes when we later try to tmpfs it.
kernel - Fix I/O stalls caused by TRIM ops
* I/O can stall out in physstr when TRIM ops are delpoyed. The
cause is that the da_softc->outstanding_cmds_rd tracker used by
the I/O balancer was decrementing the field on TRIM completions.
* Fix by ensuring that the tracker only applies to READ commands.
* Refactor scheduling checks in dastart(). The checks were a bit broken
but worked due to a catch-all in dadone(). Refactor so they work properly.
* Refactor conditional/block syntax a bit for readability.
Reported-by: myself and numerous others
rc.conf: Enable dntpd service by default
Following my previous commit 5e4ae0baf5d3cb622cc44f4854b4df46d5193877
that enabled dntpd service via the installer, this commit takes another
method to also enable dntpd by default.
While there, correct the default value of 'syslogd_enable' in rc.conf(5)
man page as well.
Suggested-by: swildner
ufs: release fdvp on rename errors after the source checks
A rename that fails after the source directory's reference is taken,
for example ENOTEMPTY or EACCES, returns through bad:/out: labels
without releasing fdvp, so the filesystem stays busy. FreeBSD releases
fdvp before those paths; DragonFly's VFS conversion removed that release
but did not add it to the error paths.
Fix the issue by correctly releasing fdvp in the 'out:' label.
Bug: https://bugs.dragonflybsd.org/issues/3457
ext2fs: release fdvp on rename errors after the source checks
A rename that fails after the source directory's reference is taken,
for example ENOTEMPTY or EACCES, returns through bad:/out: labels
without releasing fdvp, so the filesystem stays busy. FreeBSD releases
fdvp before those paths; DragonFly's VFS conversion removed that release
but did not add it to the error paths.
Fix the issue by correctly releasing fdvp in the 'out:' label.
Bug: https://bugs.dragonflybsd.org/issues/3457
ext2fs: sync the device vnode before writing the clean flag on unmount
An inode freed by rmdir is deactivated during vflush(), after
ext2_unmount()'s VFS_SYNC(), so its inode-bitmap update is only queued
with bdwrite() and nothing writes it out. e2fsck -fn then reports the
inode still allocated and the group's free-inode count wrong.
After vflush(), do what ffs_flushfiles() does: lock the device vnode,
VOP_FSYNC() it with MNT_WAIT and return the error, before the group
descriptors and the clean flag are written. Test e2fs_ronly rather
than MNT_RDONLY, which sys_mount() sets before a downgrade.
This fixes unmount and forced unmount. A read-write to read-only
downgrade is not covered: the rmdir'd inode is not freed on that path
at all (pre-existing).
Reproducer: mount rw, mkdir d; rmdir d; sync; umount; e2fsck -fn.
Bug: https://bugs.dragonflybsd.org/issues/3458
ext2fs: pass dirbuf itself and the whole block to vn_rdwr in ext2_rename
ext2_rename() allocates a filesystem-block-sized buffer in dirbuf and
uses vn_rdwr() to read and rewrite the target directory's first block,
but passes (caddr_t)&dirbuf, the address of the pointer variable, and
only sizeof(struct dirtemplate) (24) bytes. vn_rdwr() therefore writes
the directory data over the pointer and 16 bytes of adjacent stack, and
the following dirbuf->dotdot_type read uses directory bytes as a pointer
address. The kernel takes a general protection fault in ext2_rename:
Fatal trap 9: general protection fault while in kernel mode
instruction pointer = 0x8:...8280e6b3 (ext2_rename+0x943)
A partial block is also wrong on checksummed filesystems:
ext2_dirent_csum_set() looks for the dirent tail at e2fs_bsize - 12,
which is zeroed memory outside the 24 bytes that were read, so the
directory checksum is left unchanged while the new ".." entry is
written.
[9 lines not shown]
