Date: Tue, 3 Jun 2003 10:48:35 -0700 From: "Sam Leffler" <sam@errno.com> To: "Nate Lawson" <nate@root.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ubsec ubsec.c ubsecvar.h Message-ID: <0a3101c329f8$5b938a90$52557f42@errno.com> References: <20030602233211.2492D37B4A2@hub.freebsd.org> <20030602234329.T22029@root.org> <088401c329de$e82f7a50$52557f42@errno.com> <20030603101652.V23167@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0a3101c329f8$5b938a90$52557f42>