From: Vitaliy Makkoveev <mvs@openbsd.org>
Subject: Re: wired pages vs sysctl(2)
To: tech@openbsd.org, kettenis@openbsd.org
Date: Thu, 6 Mar 2025 11:56:12 +0300

On Wed, Mar 05, 2025 at 01:20:36PM +0100, Claudio Jeker wrote:
> On Wed, Mar 05, 2025 at 01:11:59PM +0100, Martin Pieuchot wrote:
> > On 04/03/25(Tue) 16:58, Vitaliy Makkoveev wrote:
> > > On Tue, Mar 04, 2025 at 02:45:42PM +0100, Martin Pieuchot wrote:
> > > 
> > > > As long as we need vslock(9), which is something that I don't know, might
> > > > want to distinguish between userland vs kernel wiring like FreeBSD do.
> > > > 
> > > 
> > > We need vslock() userland pages to avoid context switch provides by
> > > copyin()/copyout(). In some cases, like kernel locked lists walkthrougs
> > > or netlocked sections this context switch is totally unwanted.
> > 
> > So this is about sysctl that do multiple copyout(9)?  To try to limit
> > side effects?
> 
> Yes. sysctl is supposed to return an atomic view of the kernel state
> (which is not really possible) and the more problematic one is that some
> sysctls requires a large amount of memory while holding some important
> lock at the same time. In that case you want to be sure the copyout wont
> hang.
>  

Not only. For example, `ps_threads' is protected with kernel lock, so
without pages wiring it could be broken during context switch.

	TAILQ_FOREACH(p, &pr->ps_threads, p_thr_link) {
		if (buflen >= elem_size && elem_count > 0) {
			fill_kproc(pr, kproc, p, show_pointers);
			error = copyout(kproc, dp, elem_size);
		/* skip */
	}

Netlock case is more complicated. With exclusive netlock we loose
atomicy like in kernel lock case, but with shared netlock it could
be deadlock. See uvn_io():

uvn_io(struct uvm_vnode *uvn, vm_page_t *pps, ...)
{
	/* skip */

	/*
	 * This process may already have the NET_LOCK(), if we
	 * faulted in copyin() or copyout() in the network stack.
	 */
	if (rw_status(&netlock) == RW_WRITE) {
		NET_UNLOCK();
		netunlocked = 1;
	}


> > > I'm slightly moving sysctl(2) paths out of vslock(), so if you are
> > > interesting I could share stalled vfs_sysctl() diff with you.
> > 
> > Thanks, I'm busy for the moment.  I'll try to look at it when you'll
> > post it to tech@.
> > 
> > 
> 
> -- 
> :wq Claudio
>