From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 00:10:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4BE19BFB; Thu, 22 Aug 2013 00:10:30 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADDE228B6; Thu, 22 Aug 2013 00:10:29 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so1011078wes.41 for ; Wed, 21 Aug 2013 17:10:27 -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=wOl17hxfMFjtzPE+95kfN1fyp2kqQeN80btnhmhbHNg=; b=dBBzXRO830jxiR8qTEzJ9ddBDaHOcDI3ygi6KdkbvcC7oR2P14xYPdZP6vFecgy+2z YAUU3kC4A/HVm1qBoESCPpdPvRIKEuepVWTiuZzUVJw79z11mtrMs2acMzy8PVG6o5zo +ySn42PT1ZlBpjgq4uRIKfxJZa36WUqq/Z4NvJml4ZF5AtP9WLC2GfbPhsBx0yU0kUlh TmlWeJO1nk+pcR47LsMOFVj2GmxaYD+1Xt4kzIaAEVnS8Nafj3W1FPi67uI+ZsL2XAPG rEbZ280NX/1KWctnxm9fiziPn1GQAr/PdR1KYxDC7XcRfzezEHSMlQOG+lbHLRYmkPcZ GOjw== X-Received: by 10.180.19.196 with SMTP id h4mr7296269wie.38.1377130227094; Wed, 21 Aug 2013 17:10:27 -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 fu13sm13091566wic.7.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 21 Aug 2013 17:10:26 -0700 (PDT) Date: Thu, 22 Aug 2013 02:10:23 +0200 From: Mateusz Guzik To: Yuri Subject: Re: How to best overload the fileops ? Message-ID: <20130822001022.GA18115@dft-labs.eu> References: <521508F4.6030502@rawbw.com> <20130821232113.GD94127@funkthat.com> <521552E2.2000008@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <521552E2.2000008@rawbw.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: John-Mark Gurney , Roman Divacky , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 00:10:30 -0000 On Wed, Aug 21, 2013 at 04:53:06PM -0700, Yuri wrote: > On 08/21/2013 16:21, John-Mark Gurney wrote: > >How did this memory get allocated in the first place? Why does it need > >to be free'd in fo_close and not another location? > > It is allocated by the epoll module right after kqueue object is > created and is attached to the opaque field in the file object. > And it should be deallocated when this fd is closed, hence fo_close. > Short answer is provide epollops with your own fo_close and the rest as it is currently in kqueueops. All function are static, but this is not a real problem since you have to modify kern_event.c anyway. I don't know how your code looks like in general, so in case its not clear, simply wrapping sys_kqueue is inherently racy (some other thread may close the fd or even reuse it for something else by the time you try to do anything with it), thus modification of current code is unavoidable. -- Mateusz Guzik