From nobody Wed Apr 6 14:24:18 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 56A581A93C09; Wed, 6 Apr 2022 14:24:28 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYRbb31r7z3NZt; Wed, 6 Apr 2022 14:24:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82f.google.com with SMTP id t2so4454146qtw.9; Wed, 06 Apr 2022 07:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=QgD5QV2shtKmK9WEuJmizJPsxWroq4tcHT2hYrZGsBI=; b=MiwfGr9OIh2ZsWjvNfeWaczOcJj+3MpBXn7Dni15BhJlG12eMNAsOrXwH2cKTMXjq0 NSE9jrBrKtG6u6NfQ1SOKmdtnt96Ad8KDEXBlmk/GmDQTYPlARu4zZYYfi5MBp6MVXZk sJ9xlRbqqaLVwBW++JCje43NxlvfyLDza2NTQ32RKcyUGzwmZXusX/Po4w8t0JDAKDqM QB7o9szEKjam4siDNQvUzDHPpuz2kYK2++qC+89nyRG14eACHpb6EBgA7xfs3d2l5Cgn nb7XtWeBS1LtM9/R9f351nFxf1ESQtafB5mBulKUKNt7NUUzf8nnWvxQF4fqpceVAtjd sU3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=QgD5QV2shtKmK9WEuJmizJPsxWroq4tcHT2hYrZGsBI=; b=Ne+Wf0YvRdYI+dLvfpQao4YoxR4b1KHJuMy/ATgSBas7LBeYKl47A7ckApy3eWj7KU qHB6M1t7vP4aum12lk7MtPNpVehCJMv/+prtcIp0VCQ78/gKyQpGxUwsbqCN2Ir11mPa qXY2kSD8OU7JDEjvn8uOMGRuAWUTucSGM+gdnKe8QURNlH1527Idw7mA0VqKEeKywDC2 A+1eoAqTHLqeG7oJi9epqaeKk2Jj1GaDkfJx5ogP5/3go4TF76g2jg69/Jp4cERhlgnz /CKLtSj4d67EmgdGmDs5T7qy9wEavn4UNtfg3KN/TIyOctkjjwUjio3Smf5daeS3acDY 8VEQ== X-Gm-Message-State: AOAM530t+dtMadiJZuOMdEhn3Op85gbT+wuGZ3dMt+AI4Rnl/e5nxZgk fp67K12g9F7A71vE1kEddvw= X-Google-Smtp-Source: ABdhPJzBNd120EqTlJGgxuuF/mlfxl/a/RycFbEE1iiSlp5Hj1MsmW4YDSN3WaXjySbF2CE2r/W/kw== X-Received: by 2002:a05:620a:4711:b0:67e:6c24:2b2b with SMTP id bs17-20020a05620a471100b0067e6c242b2bmr5881729qkb.588.1649255061144; Wed, 06 Apr 2022 07:24:21 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id y66-20020a37af45000000b0067dc0fc539fsm10172361qke.86.2022.04.06.07.24.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 07:24:20 -0700 (PDT) Date: Wed, 6 Apr 2022 10:24:18 -0400 From: Mark Johnston To: Konstantin Belousov Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 12fb39ec3e6b - main - proc: Relax proc_rwmem()'s assertion on the process hold count Message-ID: References: <202203011741.221Hftwu093303@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KYRbb31r7z3NZt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=MiwfGr9O; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82f as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.90)[-0.899]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82f:from]; MLMMJ_DEST(0.00)[dev-commits-src-all,dev-commits-src-main]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Apr 05, 2022 at 02:03:14AM +0300, Konstantin Belousov wrote: > On Tue, Apr 05, 2022 at 02:01:04AM +0300, Konstantin Belousov wrote: > > On Tue, Mar 01, 2022 at 05:41:55PM +0000, Mark Johnston wrote: > > > The branch main has been updated by markj: > > > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=12fb39ec3e6bc529feff3ba2862c6a4a30bd54eb > > > > > > commit 12fb39ec3e6bc529feff3ba2862c6a4a30bd54eb > > > Author: Mark Johnston > > > AuthorDate: 2022-03-01 16:48:39 +0000 > > > Commit: Mark Johnston > > > CommitDate: 2022-03-01 17:40:35 +0000 > > > > > > proc: Relax proc_rwmem()'s assertion on the process hold count > > > > > > This reference ensures that the process and its associated vmspace will > > > not be destroyed while proc_rwmem() is executing. If, however, the > > > calling thread belongs to the target process, then it is unnecessary to > > > hold the process. In particular, fasttrap - a module which enables > > > userspace dtrace - may frequently call proc_rwmem(), and we'd prefer to > > > avoid the overhead of locking and bumping the hold count when possible. > > In fact I am not sure it makes much sense to disable swap out for remote > > process as well. With the current definition of p_hold, it only prevents > > kstack pages reuse, which should be irrelevant for proc_rwmem(). > > What probably should be done is referencing the target process vmspace, > instead. You mean, callers should use something like this, with the proc locked: bool vmspace_reference_live(struct vmspace *vm) { return (refcount_acquire_if_not_zero(&vm->vm_refcnt)); } ? Yes, I think that'd be sufficient. Though, in practice most callers of proc_rwmem() really do need the proc to be held for other purposes, so the existing assertion serves as a close enough approximation. We could maybe just relax the assertion in proc_rwmem() to MPASS(refcount_load(&p->p_vmspace->vm_refcnt) > 0); since this is implied by p_hold > 0. > > > Thus, make the assertion conditional on "p != curproc". Also assert > > > that the process is not already exiting. No functional change intended. > > > > > > MFC after: 2 weeks > > > Sponsored by: The FreeBSD Foundation > > > --- > > > sys/kern/sys_process.c | 9 +++++---- > > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > > > diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c > > > index 582bff962f1a..8d8c5a1d34ff 100644 > > > --- a/sys/kern/sys_process.c > > > +++ b/sys/kern/sys_process.c > > > @@ -336,11 +336,12 @@ proc_rwmem(struct proc *p, struct uio *uio) > > > int error, fault_flags, page_offset, writing; > > > > > > /* > > > - * Assert that someone has locked this vmspace. (Should be > > > - * curthread but we can't assert that.) This keeps the process > > > - * from exiting out from under us until this operation completes. > > > + * Make sure that the process' vmspace remains live. > > > */ > > > - PROC_ASSERT_HELD(p); > > > + if (p != curproc) > > > + PROC_ASSERT_HELD(p); > > > + KASSERT((p->p_flag & P_WEXIT) == 0, > > > + ("%s: process %p is exiting", __func__, p)); > > > PROC_LOCK_ASSERT(p, MA_NOTOWNED); > > > > > > /*