From owner-cvs-src@FreeBSD.ORG Sat Aug 9 04:35:57 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 907601065680; Sat, 9 Aug 2008 04:35:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 26BB48FC16; Sat, 9 Aug 2008 04:35:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m794ZoTx016219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 14:35:52 +1000 Date: Sat, 9 Aug 2008 14:35:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200808081226.32089.jhb@freebsd.org> Message-ID: <20080809130929.P77335@delplex.bde.org> References: <200808081343.m78DhwYE068477@repoman.freebsd.org> <200808081226.32089.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Ed Schouten , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/io iodev.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 04:35:57 -0000 On Fri, 8 Aug 2008, John Baldwin wrote: > On Friday 08 August 2008 09:43:56 am Ed Schouten wrote: >> ed 2008-08-08 13:43:56 UTC >> >> Apart from this change, I think some fishy things may happen when using >> /dev/io in multithreaded applications. I haven't tested, but looking at >> the code, the flag doesn't get cleared when close() is called from >> another thread, but this may not be this important. Of course it isn't. The flag only gets cleared on last close. Threads probably involve mainly file descriptors, and for file descriptors close() doesn't even reach vn_close() until the fd reference count drops to 0. Then for files, vn_close() normally doesn't reach device close until the file reference count drops to 0. > It should be setting D_TRACKCLOSE though so that close() reliably clears the > flag even in single-threaded processes. You can still get odd behavior if You mean "should _not_ be setting D_TRACKCLOSE", so that close() works normally. close() can never reliably clear the flag, since even vn_close() is not reached after open()/dup()/close() or open()/fork()/close()... > you explicitly open it twice in an app and then close one of the two fd's. > You will no longer have IO permission even though you still have one fd open. > However, if you do that I think you deserve what you asked for. :) You asked for normal last-close behaviour and deserve that not being broken by setting D_TRACKCLOSE. D_TRACKCLOSE allows different handling of non-last closes, but this is rarely wanted, and in theory it allows better determination of last closes, since vfs doesn't count last closes right. However, it is difficult to count last closes right, and most uses of D_TRACKCLOSE handle last closes are worse than vfs: - ast: uses D_TRACKCLOSE to trash (write a filemark) and/or rewind tapes on non-last closes. After the trash and rewind, astclose() uses count_dev() to avoid doing a full hardware close if the device is still open. This involves using count_dev(), but count_dev() is just an interface to the vfs count, so it miscounts in the same way as vfs. In particular, it doesn't count incompleted opens. I don't know if ast's locking is sufficient to prevent close() being called while a new open is in progress. For most devices, it isn't. - drm: it uses its own count of opens and closes, and it doesn't use count_dev(). The own count has some chance of working, but needs delicate locking of device open and device close to prevent them running into each other, and some defense against the vfs bugs which at least used to result in missing and/or extra closes. - smb: like drm, except it limits its own count to 0 or 1 to give half- baked exclusive access (fork() and dup(), etc, still give non-exclusive access). D_TRACKCLOSE thus has no effect except for its interaction with other bugs. - geom: unlike most or all of the others, this may actually need D_TRACKCLOSE, to implement multiple logical drivers per physical device. I don't understand its details. - apm: like drm - bpf: like smb Bruce