Changes in rump http://nxr.netbsd.org/rss/src/sys/rump/ en Copyright 2005 Java sppp: Enable SPPP_FILTER in i386/ALL, amd64/ALL, and rump_server Tue Jul 28 07:00:00 UTC 2026 yamaguchi sppp: Add BPF-based packet filtering for dial-on-demand and idle-timeout<br/><br/>Introduce active/dialing filtering using BPF to if_spppsubr.c. This allows<br/>sync PPP interfaces (e.g. pppoe(4)) to control which traffic triggers<br/>dial-on-demand or keeps idle connections alive.<br/><br/>This option is similar to PPP_FILTER. Tue Jul 28 07:00:00 UTC 2026 yamaguchi rump: Also skip renaming for RUMPCOMP_USER_SRCS .go objects.<br/><br/>Same as for .o/.po/.pico.<br/><br/>PR lib/60418: -current rump/wg(4) build failure Mon Jul 06 13:00:00 UTC 2026 riastradh wg-userspace(8): Tighten rump interface.<br/><br/>1. Don't abuse struct iov as a tuple of two buffers, one of which is<br/> conveying a sockaddr; just pass two separate arguments, one for the<br/> sockaddr and the other for the payload.<br/><br/>2. Avoid sketchy struct sockaddr * scabs; we're a union shop here.<br/><br/>It might seem like a regression to rip out all the scatter/gather<br/>iovecs and require contiguous buffers. But on the input path we<br/>already have a contiguous buffer filled by read(2) or recvfrom(2)<br/>(and there would be no advantage to using readv(v)). And on the<br/>output path, we always generate handshake messages and ciphertext in<br/>contiguous buffers anyway. So no scatter/gather support is actually<br/>lost here.<br/><br/>Cleanup prompted by:<br/><br/>PR bin/60392: assertion "mbuflen >= sizeof(struct wg_msg)" failed Sat Jul 04 22:00:00 UTC 2026 riastradh Make SPPP_KEEPALIVE_INTERVAL configurable for rump_server<br/><br/>This allows changing the keepalive interval when running inside<br/>rump_server, which is useful for testing. Thu Jun 18 09:00:00 UTC 2026 yamaguchi crypto(4): Disentangle initialization and attachment goo.<br/><br/>Lotta unnecessary boilerplate deleted here!<br/><br/>Disable module unloading: can't be done safely. Explain precisely<br/>why it can't be done safely.<br/><br/>This also fixes annoying `crypto: unable to register devsw, error 17'<br/>messages in rump dmesg by having exactly one path to devsw_attach.<br/><br/>PR kern/60281: crypto(4): bugs in reference counting and test Tue May 19 15:00:00 UTC 2026 riastradh Fix a longstanding bug on 64 bit ports with ABIs requiring sign-extension when returning 32-bit values in registers. Alpha, MIPS N64, RISCV.<br/><br/>With these ABIs it is necessary for the syscall return code to manually<br/>sign-extend all 32-bit return values. If we don't, everything may look<br/>just fine, until a syscall return value is spilled to the stack and then<br/>reloaded. At that point, the zero-extended form produced by C assignment<br/>into the 64-bit register for return to userspace will be sign-extended<br/>upon reload, producing a different, corrupt value which will fail comparisons.<br/>This was observed with a getuid() != geteuid() deep inside sshd on N64, on an<br/>unusual system that had some very large UIDs with bit 31 set - but is quite<br/>difficult to reproduce with small tests, since register pressure and compiler<br/>behavior determine whether the conditions necessary to trigger the bug will<br/>exist.<br/><br/>The easiest way to see whether a new target needs this treatment is to<br/>look at its GCC configuratrion; if its PROMOTE_MODE has UNSIGNEDP = 0<br/>for SImode, the sign-extension in syscall() is necessary. Sun May 10 23:00:00 UTC 2026 tls Fix MIN_PAGE_SHIFT for LP64 platforms that happen to use tiny mbufs. Mon May 04 19:00:00 UTC 2026 thorpej Hide pmap internals -- specifically, a call to pmap_resident_count() -- behind<br/>a proper functional API: uvm_resident_count(). Mon May 04 04:00:00 UTC 2026 thorpej Allow "attach" directives to have interface attributes, rather than<br/>restricting them to plain attributes only.<br/><br/>Consider the case of a USB controller for which there is a generic<br/>driver with multiple front-end bus attachments. Normally, a USB<br/>controller driver carries the interface attribute necessary to attach<br/>a USB root hub / bus instance. But, on some systems, a platform-specific<br/>attachment may have other nodes in the device tree that are needed to<br/>enable or configure the USB controller, that appear in the device tree<br/>as children of the USB controller. These devices may need to attach<br/>using a different interface attribute, unrelated to USB functionality.<br/><br/>Prior to this change, it would have been necessary to put the platform-<br/>specific interface attribute onto the generic driver. But that comes<br/>with side-effects on other platforms where that driver might be used.<br/><br/>In an ideal scenario, an attachment with special requirements should be<br/>able to carry attachment-specific interface attributes to handle those<br/>requirements, and this change enables that. When searching for prospective<br/>parents, the autoconfiguration machinery first consults the cfdriver for<br/>interface attributes, as before, and checks potential cfattach instances<br/>if a cfdriver match isn't found.<br/><br/>A separate list of attachment-specific interface attributes is maintained<br/>by the autoconfiguration machinery in the kernel. They are not hung off<br/>of the cfattach directly, as they are with cfdriver instances, because<br/>config(1) does not control the cfattach; individual driver front-ends do.<br/>By arranging it this way, there is minimal impact to non-generated code.<br/><br/>This changes the "cfattachinit" structure, and thus changes the ABI for<br/>kernel modules.<br/><br/>Bienvenidos a NetBSD 11.99.5! Sat Jan 17 02:00:00 UTC 2026 thorpej more rump help Sat Jan 10 10:00:00 UTC 2026 nia Add the new ass_keysched.c to the rump kernel crypto lib<br/><br/>This will hopefully unbreak the builds. Sun Nov 23 08:00:00 UTC 2025 kre Add in-kernel cleaner. Move cleaning-related routines into their own file.<br/>Document the fcntl calls better in lfs.h. Bounds-check inode numbers in<br/>segment parsing functions. Use the in-kernel cleaner in a greedy mode<br/>for tests in tests/fs/vfs, and add a test of the kernel cleaner. Thu Nov 06 15:00:00 UTC 2025 perseant kernel: extract rules, lookup socket, process filtering, reviews by christos@ Sun Jun 01 00:00:00 UTC 2025 joe rump: Set up the softint CPU bouncer only once, not once per CPU.<br/><br/>This is used for softint_schedule_cpu to schedule softints on other<br/>CPUs. There is one global lock, and one global condition variable,<br/>and really there only needs to be one thread to handle the requests.<br/>Without this change, we reinitialize the lock and condition variable,<br/>leaking them (and possibly leave some threads confused if they are<br/>currently taking the lock or waiting on the condition variable as<br/>they get reinitialized).<br/><br/>Leak found by lsan while investigating:<br/><br/>PR misc/59252: tests/rump/rumpkern/t_sp:sigsafe: out of memory Sun Apr 06 01:00:00 UTC 2025 riastradh rump: Nix leaked struct lwp on every rump_server syscall.<br/><br/>This leak was introduced by lwproc.c rev. 1.51 back in 2020, when the<br/>kmem_zalloc(sizeof(*l), KM_SLEEP) was factored out of callers and<br/>into lwproc_makelwp:<br/><br/>-static void<br/>-lwproc_makelwp(struct proc *p, struct lwp *l, bool doswitch, bool procmake)<br/>+static struct lwp *<br/>+lwproc_makelwp(struct proc *p, bool doswitch, bool procmake)<br/> {<br/>+ struct lwp *l = kmem_zalloc(sizeof(*l), KM_SLEEP);<br/>...<br/>@@ -435,8 +431,12 @@ rump_lwproc_newlwp(pid_t pid)<br/> kmem_free(l, sizeof(*l));<br/> return EBUSY;<br/> }<br/>+ mutex_exit(p->p_lock);<br/> mutex_exit(&proc_lock);<br/>- lwproc_makelwp(p, l, true, false);<br/>+<br/>+ /* XXX what holds proc? */<br/>+<br/>+ lwproc_makelwp(p, true, false);<br/><br/>Unfortunately, the kmem_zalloc in rump_lwproc_newlwp was not deleted.<br/>So it just leaked.<br/><br/>And this routine is called on _every_ syscall handled by rump_server<br/>(via struct rumpuser_hyperup::hyp_lwproc_newlwp):<br/><br/> 674 static void<br/> 675 serv_handlesyscall(struct spclient *spc, struct rsp_hdr *rhdr, uint8_t *data)<br/> 676 {<br/> 677 register_t retval[2] = {0, 0};<br/> 678 int rv, sysnum;<br/> 679<br/> 680 sysnum = (int)rhdr->rsp_sysnum;<br/> 681 DPRINTF(("rump_sp: handling syscall %d from client %d\n",<br/> 682 sysnum, spc->spc_pid));<br/> 683<br/> => 684 if (__predict_false((rv = lwproc_newlwp(spc->spc_pid)) != 0)) {<br/> 685 retval[0] = -1;<br/> 686 send_syscall_resp(spc, rhdr->rsp_reqno, rv, retval);<br/> 687 return;<br/> 688 }<br/> 689 spc->spc_syscallreq = rhdr->rsp_reqno;<br/> 690 rv = rumpsyscall(sysnum, data, retval);<br/><br/>https://nxr.netbsd.org/xref/src/lib/librumpuser/rumpuser_sp.c?r=1.77#684<br/><br/>So this leak would grow fairly quickly in processes issuing rump<br/>syscalls to rump_servers, which t_sp:sigsafe's helper h_sigcli does<br/>as fast as it can in a loop for 5sec -- which is just long enough for<br/>the i386 releng testbed with about 128 MB of RAM to run out of memory<br/>in roughly half of the test runs, but not long enough on my laptop<br/>with 64 GB of RAM to ever reproduce the problem.<br/><br/>Found by:<br/><br/>(a) running the test for 20sec rather than 5sec to amplify the leak;<br/>(b) counting bytes allocated by return addresses of rumpuser_malloc;<br/>(c) chasing that to rump_hypermalloc (culprit) vs uvm_km_alloc;<br/>(d) chasing that to pgctor, uvm_map, uvm_km_kmem_alloc (culprit),<br/> vmapbuf;<br/>(e) then to pool_page_alloc, then to pool_allocator_alloc, then to<br/> pool_grow, then to pool_get, then to pool_cache_get, then to<br/> kmem_zalloc;<br/>(f) finally to the call to kmem_zalloc in rump_lwproc_newlwp, which<br/> at last yielded to my stare.<br/><br/>This instrumentation was extremely ad hoc -- I just created a table<br/>of 4096 entries for each routine, and populated by linear scan with<br/>atomics:<br/><br/>struct {<br/> void *volatile ra;<br/> volatile unsigned long n;<br/>} pool_cache_get_bytes;<br/><br/>void *<br/>kmem_zalloc(size_t size, km_flags_t flags)<br/>{<br/> ...<br/> void *const ra = __builtin_return_address(0);<br/> size_t i;<br/> for (i = 0; i < __arraycount(kmem_zalloc_bytes); i++) {<br/> if (pool_cache_get_bytes[i].ra == ra ||<br/> (pool_cache_get_bytes[i].ra == NULL &&<br/> atomic_cas_ptr(&pool_cache_get_bytes[i].ra, NULL,<br/> ra) == NULL)) {<br/> atomic_add_long(&pool_cache_get_bytes[i].n, size);<br/> break;<br/> }<br/> }<br/> ...<br/>}<br/><br/>Would be nice to systematize this. Would also be nice to bring back<br/>malloc tags for accounting purposes so you don't need to match up the<br/>kmem_zalloc return addresses with the kmem_free return addresses to<br/>find leaks -- I got lucky here because there were very few return<br/>addresses to piece through.<br/><br/>PR misc/59252: tests/rump/rumpkern/t_sp:sigsafe: out of memory Sun Apr 06 01:00:00 UTC 2025 riastradh kern: Move some purely arithmetic routines to subr_time_arith.c.<br/><br/>Preparation for testing and fixing:<br/><br/>PR kern/58922: itimer(9): arithmetic overflow<br/>PR kern/58925: itimer(9) responds erratically to clock wound back<br/>PR kern/58926: itimer(9) integer overflow in overrun counting<br/>PR kern/58927: itimer(9): overrun accounting is broken Sun Dec 22 23:00:00 UTC 2024 riastradh shmif: Fix logics for media change and status<br/><br/>- shmif_mediachange: Drop check for if_link_state. Otherwise,<br/> there can be race b/w events in if_link_queue.<br/><br/>- shmif_mediastatus: Set ifm_status appropriately, by which<br/> link state appears in ifconfig(8) "status:" line.<br/><br/>Pointed out by roy@, and taken from his codes in vether(4). Thanks!! Tue Oct 01 08:00:00 UTC 2024 rin shmif: export LOCK_* definitions<br/><br/>They will be used by upcoming shmif_pcapin. Mon Sep 02 05:00:00 UTC 2024 ozaki-r initialize {sys,max}_{cb}devsws next to what they refer to<br/><br/>e.g. {sys,max}_cdevsws next to the definition of cdevsw. Sun Jul 28 13:00:00 UTC 2024 bad