From owner-svn-src-all@freebsd.org Tue Sep 3 14:07:32 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B7171DCF17; Tue, 3 Sep 2019 14:06:46 +0000 (UTC) (envelope-from yuripv@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 46N7zp2Fftz4PtX; Tue, 3 Sep 2019 14:06:46 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 052AF1AB5C; Tue, 3 Sep 2019 14:06:17 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 924FE169AC; Fri, 12 Apr 2019 17:07:07 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 3374783A3F; Fri, 12 Apr 2019 17:07:07 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 1911E169AB; Fri, 12 Apr 2019 17:07:07 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id F1529169A7; Fri, 12 Apr 2019 17:07:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E392A83A3B; Fri, 12 Apr 2019 17:07:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x3CH6sp9077561 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Apr 2019 20:06:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x3CH6sp9077561 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x3CH6sJu077560; Fri, 12 Apr 2019 20:06:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f From: Konstantin Belousov To: Edward Napierala Cc: Conrad Meyer , src-committers , svn-src-all , svn-src-head Subject: Re: svn commit: r346120 - head/sys/kern Message-ID: <20190412170654.GI1923@kib.kiev.ua> References: <201904111121.x3BBLj2K023087@repo.freebsd.org> <20190412151958.GB1923@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 3374783A3F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.958,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: , Date: Tue, 03 Sep 2019 14:07:33 -0000 X-Original-Date: Fri, 12 Apr 2019 20:06:54 +0300 X-List-Received-Date: Tue, 03 Sep 2019 14:07:33 -0000 On Fri, Apr 12, 2019 at 04:23:35PM +0100, Edward Napierala wrote: > On Fri, 12 Apr 2019 at 16:20, Konstantin Belousov wrote: > > > > On Fri, Apr 12, 2019 at 03:28:26PM +0100, Edward Napierala wrote: > > > On Thu, 11 Apr 2019 at 17:26, Conrad Meyer wrote: > > > > > > > > Hi Edward, > > > > > > > > I have a question about this change below. > > > > > > > > On Thu, Apr 11, 2019 at 4:22 AM Edward Tomasz Napierala > > > > wrote: > > > > > > > > > > Author: trasz > > > > > Date: Thu Apr 11 11:21:45 2019 > > > > > New Revision: 346120 > > > > > URL: https://svnweb.freebsd.org/changeset/base/346120 > > > > > > > > > > Log: > > > > > Use shared vnode locks for the ELF interpreter. > > > > > > [..] > > > > > > > On the one hand, perhaps VOP_IS_TEXT() is rarely false for common > > > > interpreters anyway. On the other hand, there is sort of a > > > > renaissance of static linking happening. So maybe the thought is, > > > > !VOP_IS_TEXT is likely to be rare, and LK_UPGRADE success even more > > > > rare, so why bother writing additional code for it? > > > > > > Konstantin already answered to most of the points, but regarding > > > this one: that's exactly the case. In a typical case, the number of times > > > this code path will be executed is zero. I'd expect one - when running > > > dynamically linked ELF binary for the first time - but for some reason in > > > that case lookup() returns with the exclusive vnode lock already held. > > > > This is strange. Which filesystem do you use ? > > UFS. I see. UFS has to use exclusive locking in ffs_vget() when the vnode is created, i.e. de-facto when inode is read from the volume. See the manipulations of flags in ffs_vgetf() right after vfs_hash_get() was unable to find a cached vnode. But if you just installed new /libexec/ld-elf.so.1, or the binary uses some other interpreter which was written right before the execve(2) call, then vnode most likely is still cached and is returned shared-locked. Use this scenario to actually test the code.