Subject: Re: Reminder that we are supporting two parallel IPsec implementations
To: Jun-ichiro itojun Hagino <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/11/2003 17:05:19
In message <20030911234732.7DD3E8A@coconut.itojun.org>Jun-ichiro itojun Hagino writes
>> Anyway ... if we go down that route, then during the transition
>> period, changes to the PF_KEY API have to be synchronized across both
>> IPsec implementations. Ad-hoc changes to the PF_KEY api (or abi) in
>> one will likely break the other.
> i remember no ad-hoc changes to PF_KEY API/ABI made to netbsd tree.
> which one do you think ad-hoc?
> i made changes with reasons. if you call it "ad-hoc" in public it's
> quite a insult.
There is a bug in the implementation PF_KEY which is triggered with
quite modest numbers of simultaneous SAs. Addding a kernfs hook to
access SAs in order to sidestep that bug is *definitionally*, ad-hoc.
Please bear keep in mind the long-established NetBSD principle that
kernfs is *optional*: subsystems should continue to work even if
kernfs is not present. You can use kernfs as an optimization, if its
present; but as I recall the consensus, we should never **equire* it.
(Perhaps I am misremembering, or perhaps this predates your involvement with NetBSD?)
Also please remember the NetBSD principle: "no code before its time".
We should not check in ad-hoc kludges in response to bugs. So, with
all due respect, please do not commit ad-hoc kludges like this in
future. Instead, please *fix the bug*.
I'm not 100% sure its the same bug which manifests on fast-ipsec (both
NetBSD and FreeBSD) under the same circumstances of medium numbers of
SAs; but the description sure sounds very similar.
I have been trying (and failing) to build a -current kernel for my
laptop that doens't panic immediately for almost a week now. Once I
get one built, I'd be glad to check whether this is the saem bug, and
to collaborate on a real fix.