> On Wed, 13 Jun 2001 14:15:53 -0400
> Bosko Milekic <[EMAIL PROTECTED]> said:
> Yup, current KAME is based on 4.3-RELEASE which doesn't have
> mtx_lock() issue. It is my mistake during merging it into 5-CURRENT.
> The fix looks good to me. If there is no objection, I'll commit it.
bmi
On Thu, Jun 14, 2001 at 03:12:06AM +0900, Hajimu UMEMOTO wrote:
> > On Wed, 13 Jun 2001 13:42:51 -0400
> > Bosko Milekic <[EMAIL PROTECTED]> said:
>
> bmilekic> Yes, I certainly didn't write that. I think it was KAME.
>
> Yup, current KAME is based on 4.3-RELEASE which doesn't have
On Thu, 14 Jun 2001, Hajimu UMEMOTO wrote:
> > On Wed, 13 Jun 2001 13:42:51 -0400
> > Bosko Milekic <[EMAIL PROTECTED]> said:
>
> bmilekic> Yes, I certainly didn't write that. I think it was KAME.
>
> Yup, current KAME is based on 4.3-RELEASE which doesn't have
> mtx_lock() issue.
> On Wed, 13 Jun 2001 13:42:51 -0400
> Bosko Milekic <[EMAIL PROTECTED]> said:
bmilekic> Yes, I certainly didn't write that. I think it was KAME.
Yup, current KAME is based on 4.3-RELEASE which doesn't have
mtx_lock() issue. It is my mistake during merging it into 5-CURRENT.
The f
Yes, I certainly didn't write that. I think it was KAME.
On Wed, Jun 13, 2001 at 10:37:22AM -0700, Matthew Jacob wrote:
>
> A recent change to the MFREE macro was made as noted below:
>
> /*
> * MFREE(struct mbuf *m, struct mbuf *n)
> * Free a single mbuf and associated external stor
A recent change to the MFREE macro was made as noted below:
/*
* MFREE(struct mbuf *m, struct mbuf *n)
* Free a single mbuf and associated external storage.
* Place the successor, if any, in n.
*
* we do need to check non-first mbuf for m_aux, since some of existing
* code does not call M
