From owner-freebsd-firewire@FreeBSD.ORG Fri Jun 29 09:44:04 2007 Return-Path: X-Original-To: freebsd-firewire@freebsd.org Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65FB116A473; Fri, 29 Jun 2007 09:44:04 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.freebsd.org (Postfix) with ESMTP id 1588413C465; Fri, 29 Jun 2007 09:44:03 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from herring.rabson.org (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l5T9OvIp059594; Fri, 29 Jun 2007 10:24:57 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: freebsd-firewire@freebsd.org Date: Fri, 29 Jun 2007 10:24:56 +0100 User-Agent: KMail/1.9.6 References: <626eb4530706060746u44226cfajcedb3e169996a51a@mail.gmail.com> In-Reply-To: <626eb4530706060746u44226cfajcedb3e169996a51a@mail.gmail.com> MIME-Version: 1.0 Message-Id: <200706291024.56591.dfr@rabson.org> X-Spam-Status: No, score=0.9 required=5.0 tests=HTML_10_20,HTML_MESSAGE, UNPARSEABLE_RELAY autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.87.1/3551/Fri Jun 29 02:52:16 2007 on itchy.rabson.org X-Virus-Status: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Hidetoshi Shimokawa Subject: Re: [CFT] MPSAFE firewire X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2007 09:44:04 -0000 On Wednesday 06 June 2007, Hidetoshi Shimokawa wrote: > I have just committed MPSAFE(Giant free) firewire driver to -current. > If you have any problem, please let me know. I've been looking through the code and I have a few questions. In fwohci_rbuf_update(), you only call FW_GLOCK() if the FWXFERQ_HANDLER flag is zero. Doesn't this cause problems for the if_fwip driver (the only one to set this flag)? As far as I can see, if this flag is set, there is no mutex protection for any of the dma queues. Shouln't FW_GLOCK be used always? Also, additional protection is needed in fwip_stream_input where it manipulates the stvalid and stfree queues. I'm a bit confused about the async read path too. I'm looking at the code in fwohci_arcv() and I can't see any mutex protection in this function while it manipulates the buffers. Is this correct? I see some fossil use of splfw() here which is why I ask. Following the input path back to the fwip driver again, I can't see any mutex protection for the driver's unicast packet input queues. The last possible problem I noticed reading through the code is that there is no mutex protection of the fragmented packet reassembly queues in firewire_input_fragment. Perhaps the fw_com structure should have a mutex pointer in it which can be initialised to the if_fwip code's mutex and used in this case.