From owner-cvs-src@FreeBSD.ORG Tue Jun 3 10:48:37 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E64437B401; Tue, 3 Jun 2003 10:48:37 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92FEA43F3F; Tue, 3 Jun 2003 10:48:36 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h53HmZpw077921 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 3 Jun 2003 10:48:36 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <0a3101c329f8$5b938a90$52557f42@errno.com> From: "Sam Leffler" To: "Nate Lawson" References: <20030602233211.2492D37B4A2@hub.freebsd.org> <20030602234329.T22029@root.org> <088401c329de$e82f7a50$52557f42@errno.com> <20030603101652.V23167@root.org> Date: Tue, 3 Jun 2003 10:48:35 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ubsec ubsec.c ubsecvar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 03 Jun 2003 17:48:37 -0000 > That disables the device's interrupts but does not unhook the ih. That > happens further down. So if interrupts occur, you are depending on > ubsec_intr()'s check whether it is enabled or not (BS_STAT) to see if the > interrupt is for ubsec. That seems fine to me (after further review). > But if an instance of ubsec_intr() is already active, might there be > problems? If an instance of the ISR is active then there could be problems. However the ISR can only be entered because of requests actively submitted by the "top half" of the driver. These take two forms: mcr1 operations which are requests submitted for symmetric crypto ops and mcr2 operations which are created for asym ops and/or rng polling requests. I meant to move the callout cancellation of the rng polling to above this so no rng-based mcr2 ops could be submitted and other operations need to be cancelled separately (as you noticed there is a comment). > I'm thinking of it locking mcr1lock and then detach() calling > mtx_destroy() while it is active or other similar issues. This is > probably why you have "/* XXX wait/abort active ops */" at the top. My > question was whether this should be a function of the underlying ithread > subsystem and not the responsibility of each driver. Correct, as you noted I still need to deal with cancelling active operations. This problem was present regardless of any locking that I changed. As to whether or not a general mechanism is needed to deal with issues like this; I doubt any general mechanism can deal with all the situations. FWIW I spent yesterday torture-testing the crypto code in several different ways. This commit and related ones are the fallout from that testing and a bunch of work that's been pending in my local tree. I have other changes; including some more performance improvements. Sam