From owner-freebsd-current@FreeBSD.ORG Thu Aug 22 01:20:18 2013 Return-Path: Delivered-To: current@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 ESMTP id 7016F249; Thu, 22 Aug 2013 01:20:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D27AC2EDE; Thu, 22 Aug 2013 01:20:17 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id en1so14622wid.0 for ; Wed, 21 Aug 2013 18:20: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=5MKAO2f6WqAVOKeR6AaRsMLmKNk+4DSO6+usx+rouZU=; b=T4J8I6X8ZrrCGO16TGqJTKx7XrWX1dSwQ8TmKqPK7uqgHu/fF6AwmLd/NUoxRsjHuc lo42av8XwndhXrCI+YHotwcru4qOh82Li7zY4ZoopiQhHaqy9y2g4FUawVjv439H2P8N YpTthSROBqSz6jFx/FmwQDyP+FIwxRlbqgw7HaYeyQcW5Y0Ic9npV3I4MFHHwsKFGd5D ZE/TDVQeuYIyFf8wrMtyPCuSMJqLM4yNYuWXEesHGQz7gsRTUsB7e1aA3XCQrRnFBaaF +/H5Pk2LQY4gKs3XeNPxOSXFmdvWVdwVSxvgc7OymThOHlX9zVetJsATcvZ2ot6j5xpd 0dBw== X-Received: by 10.180.206.42 with SMTP id ll10mr18616184wic.50.1377134416075; Wed, 21 Aug 2013 18:20: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 l7sm34628963wiw.4.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 21 Aug 2013 18:20:15 -0700 (PDT) Date: Thu, 22 Aug 2013 03:20:11 +0200 From: Mateusz Guzik To: Yuri Subject: Re: How to best overload the fileops ? Message-ID: <20130822012011.GA11987@dft-labs.eu> References: <521508F4.6030502@rawbw.com> <20130821232113.GD94127@funkthat.com> <521552E2.2000008@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52155B8D.1020807@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 01:20:18 -0000 On Wed, Aug 21, 2013 at 05:30:05PM -0700, Yuri wrote: > On 08/21/2013 17:10, Mateusz Guzik wrote: > >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. > > This is exactly what this code I am asking about is doing. I somehow missed your first mail and reponsed only to your reply to jmg, sorry! > kqueueops functions are all static. This modification allows to > export fileops to child modules. > Since there is nothing similar in the kernel code, I am asking does > this way look ugly or not. > I don't think there is a need to provide anything like this right now, nor I have any good idea how to implement it. > > > >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. > > No, sys_kqueue calling code is all protected by the lock on this > file object. So nobody can close or reuse it. > I don't follow. sys_kqueue creates fp on its own, before that there is nothing to lock in the first place. By the time it returns, created fp can be long gone because some other thread closed it. FreeBSD idiom of dealing with that is creating fp with 2 refs and dropping one when initialization is finished. That way close() from userland does not kill fp until the code creating the object finishes. Just my $0,03. -- Mateusz Guzik