From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 22 10:24:34 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6129936D for ; Sun, 22 Mar 2015 10:24:34 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4ADBD42 for ; Sun, 22 Mar 2015 10:24:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2MAOSkP029197 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 22 Mar 2015 12:24:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2MAOSkP029197 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2MAOSEc029196; Sun, 22 Mar 2015 12:24:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Mar 2015 12:24:28 +0200 From: Konstantin Belousov To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [PATCH] Finish the task 'Validate coredump format string' Message-ID: <20150322102428.GZ2379@kib.kiev.ua> References: <1426946345-67889-1-git-send-email-btw@mail.ustc.edu.cn> <20150321200500.GC14650@dft-labs.eu> <20150322091853.GA89976@freebsd> <20150322101401.GH14650@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150322101401.GH14650@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 10:24:34 -0000 On Sun, Mar 22, 2015 at 11:14:01AM +0100, Mateusz Guzik wrote: > On Sun, Mar 22, 2015 at 05:19:40PM +0800, Tiwei Bie wrote: > > Sorry, I introduced a bug... allproc_lock could not be used to protect > > the access to corefilename[]. > > > > First off I committed the code, so the fault is on me. > > > Because, sysctl_kern_corefile() could be called very early: > > > [..] > > That is to say, when the tunable `kern.corefile' is set in loader.conf, > > sysctl_kern_corefile() will be called as the priority of (SI_SUB_KMEM, > > SI_ORDER_FIRST). > > > > At this time, allproc_lock is not initialized. > > > > I couldn't find a proper existing lock for this task. Maybe a dedicated > > lock needs to be created. And initialize it together with sysctlmemlock: > > > [..] > > Or maybe sysctlmemlock could be used, which is only acuqired when > > req.oldlen > PAGE_SIZE. > > > > > > I was somehow convinced that tunables are dealt with other code. > > If such sysctl handler is also called for tunables, the kernel should > pass a flag or some other indicator so that the function knows it is > dealing with a tunable and that would avoid locking and thus solve the > problem. > > I'm wondering if we should go a little bit further and get rid of > static char corefilename[MAXPATHLEN] > > and have a static char *corefilename instead. Accessing the array through the pointer dereference is micro-pessimization, as well as having to maintain metadata for the malloced memory, isn't it ? > > A dedicated sysinit func could fetch and validate the tunable, if any. > If no tunable was provided it would alloc memory for the default. Or you could move initialization of the sx in question earlier.