(usagi-users 00851) Re: IPSEC: problem add/delete policy from SPD

[miyazawa@xxxxxxxxxxxxxxxxx]

Hello,

I think your correction is right. It is owing to my carelessness.

By the way, I am going to change the "sa_index_list" in sturct ipsec_sp
from List to Array. 
#"sa_index_list" connects IPsec policy and SAs.


--- spd.h       Tue Oct  9 11:39:11 2001
+++ spd.h.array Tue Oct  9 19:19:38 2001
@@ -72,7 +72,7 @@
        rwlock_t lock;  
        atomic_t count;
        struct selector selector;
-       struct list_head sa_index_list;
+       struct sa_index *sa_index_list[3];
 };

#define IPSEC_SP_AH   0
#define IPSEC_SP_ESP  1
#define IPSEC_SP_COMP 2

At first, I thought the IPsec headers which is added to the packet
should be defined variously in the order and a kind of IPsec header.
[IP][AH][ESP][ESP][Payload]
[IP][AH][ESP][AH][Payload]
Therefore I defined sa_index_list as List.

But I think it is superfluous.
It is enough that the order of IPsec headers is fixed like
[IP][AH][ESP][COMP]{[IP]}[Payload]
A packet will have one header for each kind of IPsec headers. Of course
a packet may have only Ah or ESP. Therefore the IPsec policy has just
those headers (SAs) parameters; AH, ESP, and COMP.
I don't think this change affect the interoperability of IPsec for other OS. 

Thank you for your contribution.

--Kazunori Miyazawa

> 
> Hi, 
> 
> I think I may have a solution. In the 2.4.10 kernel that is part of the
> latest USAGI kit, it appears that linux/list.h has undergone some
> changes since 2.4.9. The list_for_each macro changed and was causing
> what I listed in the previous email. In list.h, there is now a
> list_for_each_safe macro that saves the next entry in the list in case
> the current entry which is being referenced to get the next entry is removed.
> I tried this and it works. Thus, I am including it in this email as a 
> patch in case it has not been fixed.
> 
> Thanks,
> Joy Latten
> 
> 
> sa_index.c.orig     Tue Oct  9 12:15:30 2001
> +++ sa_index.c  Tue Oct  9 12:16:01 2001
> @@ -272,6 +272,7 @@
>         int error = 0;
>         struct list_head *pos = NULL;
>         struct sa_index *tmp = NULL;
> +       struct list_head *nxt = NULL;
> 
>         if (!list) {
>                 pr_debug("sa_list_clear: list is null\n");
> @@ -279,7 +280,7 @@
>                 goto err;
>         }
> 
> -       list_for_each(pos, list){
> +       list_for_each_safe(pos, nxt, list){
>                 tmp = list_entry(pos, struct sa_index, entry);
>                 if (tmp) {
>                         list_del(&(tmp->entry));
> ~
> 
> 
> >Hi,
> >
> >I am not very sure, but was the problem in
> >the list_for_each in sa_list_clear() in sa_index.c? At least that
> >is what I have figured out so far in my oops. I am not
> >very sure. I am still learning to read oops. :-)
> >Was the entry being deleted, and the memory freed, 
> >but then try to reference it again in the "list_for_each"?
> >I think... 
> >
> >Thanks,
> >Joy
> >
> >>Hi,
> >>At Fri, 5 Oct 2001 14:33:23 -0500,
> >>latten@xxxxxxxxxxxxxx wrote:
> >>> 
> >>> 
> >>> Hi,
> >>> 
> >>> I recently udpated to the October 1st snapshot. Since then, 
> >>> at intermittent times I get a segmentation fault when adding
> >>> or deleting a policy to the SPD with the pfkey command.  
> >>> Has anyone else seen this? 
> >>
> >>Yes, I have.
> >>
> >>I'm now trying to fix this bug...
> >>
> >>
> >>-mk 
>