From owner-svn-src-head@FreeBSD.ORG Thu Mar 27 15:05:19 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 849FD576; Thu, 27 Mar 2014 15:05:19 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78253BD2; Thu, 27 Mar 2014 15:05:18 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w61so1893268wes.15 for ; Thu, 27 Mar 2014 08:05:16 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4LTqV07O4s18dEEpLfT6btMYOd7EB2/8DFhFMRHewdg=; b=BzIzwukBQBdaUNcbRu0BohpfQzxEPmaDi5wLmYkQYx9haHazF9F9HsPJTihLIVHjp1 zyVzNmr3K0TG39cSS3YNDYozdbC73PPsF9+rJJa67OTl5xv8F8jTbAnUyXUimyb38ico D9ltftfFrHyOZCaFjSWxI0OVc34ftnhnlj4dg+y2ZFbbZncHKsIA5RPJ0aNRidlKU2cd TiTSmC17vIsAJsbg0qDQqyjXgWGapC7CXm2i9912hyU3LyyPqqtQZR/gDY6ekbGDHbch ehJHQhNnPE6pCxomuumI5s4p/3VWeH9xF8zSjjDfCxW4nWBci6+msHSbMxKd5/0Jiti8 42qQ== X-Received: by 10.180.19.98 with SMTP id d2mr40412329wie.57.1395932716518; Thu, 27 Mar 2014 08:05:16 -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 bi8sm13103945wib.3.2014.03.27.08.05.14 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 27 Mar 2014 08:05:15 -0700 (PDT) Date: Thu, 27 Mar 2014 16:05:12 +0100 From: Mateusz Guzik To: David Xu Subject: Re: svn commit: r263755 - head/sys/kern Message-ID: <20140327150512.GB4730@dft-labs.eu> References: <201403252330.s2PNUaei052956@svn.freebsd.org> <5333D70D.7050306@freebsd.org> <20140327083730.GA22942@dft-labs.eu> <5333E581.1000100@freebsd.org> <20140327145819.GA4730@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140327145819.GA4730@dft-labs.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Mateusz Guzik X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:05:19 -0000 On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote: > On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote: > > On 2014/03/27 16:37, Mateusz Guzik wrote: > > >On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote: > > >>I think the async process pointer can be cleared when a process exits > > >>by registering an event handler. please see attached patch. > > >> > > > > > >Sure, but I'm not very fond of this solution. > > > > > >This is a rather obscure bug you wont hit unless you explicitly try, > > >and even then you need root privs by default. > > > > > OK, but I don't like the bug exists in kernel. It is not obscure for me, > > I can run "shutdown now" command, and insert a device, and then the > > kernel will write garbage data into freed memory space. > > > > Not sure what you mean. devd does not use this feature, and even if it > did async_proc is cleared on close, which happens while signal delivery > is still legal. > > That said, you are not going to encounter this bug unless you code > something up to specifically trigger it. > > fwiw, I think we could axe this feature if there was no way to fix it > without introducing a check for every process. > > > >As such writing a callback function which will be executed for all exiting > > >processes seems unjustified for me. > > > > > >Ideally we would get some mechanism which would allow to register > > >callbacks for events related to given entity. Then it could be used to > > >provide a "call this function when process p exits", amongst other things. > > > > > > > Yes, but the callback itself is cheap enough and is not worth to be > > per-entity entry. > > > > There is other code in the kernel which would benefit from such > functionality - dev/syscons/scmouse, dev/vt/vt_core.c, aio and possibly > more. > > As such I think this is worth pursuing. > We can hack around this one the way the other code is doing - apart from from proc pointer you store pid and then compare result of pfind(pid). This is still buggy as both proc and pid pointer can be recycled and end up being the same (but you have an entrirely new process). However, then in absolutely worst cae you send SIGIO to incorrect process, always an existing process so no more corruption. Would you be ok with such hack for the time being? -- Mateusz Guzik