From owner-svn-src-all@freebsd.org Mon May 27 09:52:56 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D29B15BEAD5; Mon, 27 May 2019 09:52:56 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3ED818CBDD; Mon, 27 May 2019 09:52:56 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 137B715805; Mon, 27 May 2019 09:52:56 +0000 (UTC) Date: Mon, 27 May 2019 09:52:56 +0000 From: Alexey Dokuchaev To: Konstantin Belousov Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r232071 - head/sys/vm Message-ID: <20190527095256.GA52203@FreeBSD.org> References: <201202232107.q1NL7GHi023139@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201202232107.q1NL7GHi023139@svn.freebsd.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 3ED818CBDD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 09:52:56 -0000 On Thu, Feb 23, 2012 at 09:07:16PM +0000, Konstantin Belousov wrote: > New Revision: 232071 > URL: http://svn.freebsd.org/changeset/base/232071 > > Log: > Account the writeable shared mappings backed by file in the vnode > v_writecount. Keep the amount of the virtual address space used by > the mappings in the new vm_object un_pager.vnp.writemappings > counter. The vnode v_writecount is incremented when writemappings gets > non-zero value, and decremented when writemappings is returned to > zero. > > Writeable shared vnode-backed mappings are accounted for in vm_mmap(), > and vm_map_insert() is instructed to set MAP_ENTRY_VN_WRITECNT flag on > the created map entry. During deferred map entry deallocation, > vm_map_process_deferred() checks for MAP_ENTRY_VN_WRITECOUNT and > decrements writemappings for the vm object. > > Now, the writeable mount cannot be demoted to read-only while > writeable shared mappings of the vnodes from the mount point > exist. Also, execve(2) fails for such files with ETXTBUSY, as it > should be. > > ... > Modified: head/sys/vm/vnode_pager.c > ============================================================================== > --- head/sys/vm/vnode_pager.c Thu Feb 23 20:58:52 2012 (r232070) > +++ head/sys/vm/vnode_pager.c Thu Feb 23 21:07:16 2012 (r232071) > @@ -1215,3 +1222,81 @@ vnode_pager_undirty_pages(vm_page_t *ma, > } > VM_OBJECT_UNLOCK(obj); > } > + > +void > +vnode_pager_update_writecount(vm_object_t object, vm_offset_t start, > + vm_offset_t end) So, it is first `start, then `end', but below... > +{ > + struct vnode *vp; > + vm_ooffset_t old_wm; > + > + ... > +} > + > +void > +vnode_pager_release_writecount(vm_object_t object, vm_offset_t start, > + vm_offset_t end) > +{ > + struct vnode *vp; > + struct mount *mp; > + vm_offset_t inc; > + int vfslocked; > + > + VM_OBJECT_LOCK(object); > + > + /* > + * First, recheck the object type to account for the race when > + * the vnode is reclaimed. > + */ > + if (object->type != OBJT_VNODE) { > + VM_OBJECT_UNLOCK(object); > + return; > + } > + > + /* > + * Optimize for the case when writemappings is not going to > + * zero. > + */ > + inc = end - start; > + if (object->un_pager.vnp.writemappings != inc) { > + object->un_pager.vnp.writemappings -= inc; > + VM_OBJECT_UNLOCK(object); > + return; > + } > + > + vp = object->handle; > + vhold(vp); > + VM_OBJECT_UNLOCK(object); > + vfslocked = VFS_LOCK_GIANT(vp->v_mount); > + mp = NULL; > + vn_start_write(vp, &mp, V_WAIT); > + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); > + > + /* > + * Decrement the object's writemappings, by swapping the start > + * and end arguments for vnode_pager_update_writecount(). If > + * there was not a race with vnode reclaimation, then the > + * vnode's v_writecount is decremented. > + */ > + vnode_pager_update_writecount(object, end, start); ... here, first `end' is passed, then `start'. Is this intentional? PVS Studio complains: /usr/src/sys/vm/vnode_pager.c:1584:1: warning: V764 Possible incorrect order of arguments passed to 'vnode_pager_update_writecount' function: 'end' and 'start'. > + VOP_UNLOCK(vp, 0); > + vdrop(vp); > + if (mp != NULL) > + vn_finished_write(mp); > + VFS_UNLOCK_GIANT(vfslocked); > +}