From owner-svn-src-all@freebsd.org Fri Apr 12 17:07:04 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 19DFB1581945; Fri, 12 Apr 2019 17:07:04 +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 Date: Fri, 12 Apr 2019 20:06:54 +0300 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 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: Fri, 12 Apr 2019 17:07:04 -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.