From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 22 10:14:07 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 5D8B4FD5 for ; Sun, 22 Mar 2015 10:14:07 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDD9AC3E for ; Sun, 22 Mar 2015 10:14:06 +0000 (UTC) Received: by wixw10 with SMTP id w10so31946825wix.0 for ; Sun, 22 Mar 2015 03:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=enmNX/pC0tvXxC/D7TESbcanoyus2UR7Do5U0E8QlaA=; b=CGzH8Gn25JdC6PaVZ6YnBTSqbNAXnfAHZrSLM0PqLV4xsWztFclQnkxBk1pSwH0Yov nZqoo+orXGMksTDz+YPmOVvvtjP/+4XeT1iv+gwCqq+9awOMowUGq4KK/5ABvAeZBdm6 bMsmxInl/OrpMiv4L/k2crEXiUmyv08PEba1DIrbUE4uGF+sGqkdhyr5GRu9Q9JI0/c+ bTNvMs2huso9VyONLaluPUiiJ7wvXV2RPwil0GiwmmshakZNd9DOJaX17Dn2jFggD5Mf 0MQ3VrCOJESuH/ssfc1Bm9DJJ+LZWkS5C6IXICwSLTRg1rr7/ebyim/6Bznym8SiKCxe xPqA== X-Received: by 10.180.24.162 with SMTP id v2mr10211097wif.80.1427019245330; Sun, 22 Mar 2015 03:14:05 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id ub1sm14233711wjc.43.2015.03.22.03.14.03 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 22 Mar 2015 03:14:03 -0700 (PDT) Date: Sun, 22 Mar 2015 11:14:01 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'Validate coredump format string' Message-ID: <20150322101401.GH14650@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org, Konstantin Belousov References: <1426946345-67889-1-git-send-email-btw@mail.ustc.edu.cn> <20150321200500.GC14650@dft-labs.eu> <20150322091853.GA89976@freebsd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150322091853.GA89976@freebsd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org 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:14:07 -0000 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. A dedicated sysinit func could fetch and validate the tunable, if any. If no tunable was provided it would alloc memory for the default. -- Mateusz Guzik