In article <[EMAIL PROTECTED]> (at Sat, 27 May 2006 23:03:02 -0700 (PDT)),
David Miller <[EMAIL PROTECTED]> says:
> > Please don't get me wrong. What I removed here doesn't work at all to
> > begin with. I was just pointing out the possible reason why this code
> > existed in the first place.
>
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 27 May 2006 22:08:01 +1000
> YOSHIFUJI Hideaki / <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]> (at Sat, 27 May 2006 21:33:45 +1000),
> > Herbert Xu <[EMAIL PROTECTED]> says:
> >
> >> As far as I can gather it's an attempt to gu
YOSHIFUJI Hideaki / <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> (at Sat, 27 May 2006 21:33:45 +1000), Herbert
> Xu <[EMAIL PROTECTED]> says:
>
>> As far as I can gather it's an attempt to guard against the removal of
>> the corresponding modules. Since neither module can be
In article <[EMAIL PROTECTED]> (at Sat, 27 May 2006 21:33:45 +1000), Herbert Xu
<[EMAIL PROTECTED]> says:
> As far as I can gather it's an attempt to guard against the removal of
> the corresponding modules. Since neither module can be unloaded at all
> we can leave it to whoever fixes up IPv6 u
[IPSEC] xfrm: Undo afinfo lock proliferation
The number of locks used to manage afinfo structures can easily be reduced
down to one each for policy and state respectively. This is based on the
observation that the write locks are only held by module insertion/removal
which are very rare events so
