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

[latten@xxxxxxxxxxxxxx]

Hi,

Ok. Arrays are nicer. :-)

Joy 

>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 
>>