Re: CVS commit: src

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Sun, Apr 13, 2008 at 10:58:47AM +0100, Mindaugas Rasiukevicius wrote:
> Thor Lancelot Simon <tls%rek.tjls.com@localhost> wrote:
> > On Sat, Apr 12, 2008 at 08:03:47PM +0100, Mindaugas Rasiukevicius wrote:
> > > Thor Lancelot Simon <tls%rek.tjls.com@localhost> wrote:
> > > > On Sat, Apr 12, 2008 at 02:14:27PM +0100, Mindaugas Rasiukevicius wrote:
> > > > > Thor Lancelot Simon <tls%rek.tjls.com@localhost> wrote:
> > > > > > > - Why crypto_mtx is not set to IPL_SOFTNET, but IPL_NET?
> > > > > > 
> > > > > > It replaced calls to "splcrypto()", which was splnet().  The actual
> > > > > > hardware drivers currently in the tree all use splnet() for mutual
> > > > > > exclusion and there are a couple of cases where driver done routines
> > > > > > can need the crypto_mtx -- so I think it probably has to be at
> > > > > > IPL_NET, no?
> > > > > 
> > > > > The current code uses software interrupt, and IPL_SOFT* levels are
> > > > > used to block them. Why blocking of hard interrupts (at IPL_NET) is
> > > > > needed?
> > > > 
> > > > But the hardware drivers take the mutex before calling the done
> > > > function, when requests finish at the hardware.  Most of the existing
> > > > drivers run at splnet() -- if they might be running at IPL_NET when
> > > > they take the mutex, doesn't the mutex have to be initialized with
> > > > IPL_NET?
> > > 
> > > Yes, if code is correct, mutex would use IPL_NET (or IPL_VM, since reduce
> > > of the levels). We are not discussing the correct way to convert from spl*
> > > () to mutex, though. Question is - why blocking of hard interrupts is
> > > needed?
> > 
> > It's not a question of converting from spl* to mutex, as far as I can see:
> > Existing drivers in the tree (hifn, ubsec, etc.) assume that if they splnet
> > (), they exclude the code in crypto.c.  For that to be true, the mutex _has
> > to_ be IPL_NET, AFAICT.
> > 
> > Is this wrong?
> 
> How other existing drivers are related to my question, and crypto.c ?

The code in crypto.c dispatches requests to these drivers, and they return
requests to it.  The drivers call crypto_done(), possibly from interrupt
context -- that is, while running at splnet() -- and there may be other
cases where the drivers and code in crypto.c manipulate the same requests.

-- 
  Thor Lancelot Simon                                        
tls%rek.tjls.com@localhost

  "The inconsistency is startling, though admittedly, if consistency is to
   be abandoned or transcended, there is no problem."         - Noam Chomsky