| Message ID | 20240523074001.1775-1-15310488637@163.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [ovs-dev] ipf: Fix ovs ipf crash. | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
| ovsrobot/github-robot-_Build_and_Test | success | github build: passed |
| ovsrobot/intel-ovs-compilation | success | test: success |
On 5/23/24 09:40, laixiangwu wrote: > Description: > > when 1) The fragment timeout is between 15 seconds and 25 seconds; 2) > The ipf_list currently has received more than 32 fragments, and there > are other fragments of same big packet that have not been received. > > When the above two scenario conditions are met, due to exceeding the > capacity of the packet batch(here is 32), ipf_dp_packet_batch_add > returns false, and ipf_list will not be cleared. However, the 32 > fragments packets added to the packet batch will be processed normally. > When receiving the subsequent fragments of the ipf_list, because the > first 32 fragments have been processed, when processing subsequent > fragment packets, relevant information about the processed fragment > packets will be read，therefore will occur carsh. > One solution is do not forward timeout fragment packets from the above > scenarios, that is, do not add them to the packet batch, and handle > other scenarios according to the original logic. > Signed-off-by: laixiangwu <15310488637@163.com> > --- > lib/ipf.c | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) Hi, laixiangwu. This version of the patch looks the same as the previous one here: https://patchwork.ozlabs.org/project/openvswitch/patch/20240522021957.2292-1-15310488637@163.com/ And I see Mike asked a few questions for the approach there. Could you, please, answer those? For now, I'll mark this patch with 'Changes Requested'. If you plan to send a new version based on Mike's comments, please, add 'v6' to the subject prefix, i.e. [PATCH v6], since it's technically a 6th version of it. Best regards, Ilya Maximets.
diff --git a/lib/ipf.c b/lib/ipf.c index d45266374..9258173ab 100644 --- a/lib/ipf.c +++ b/lib/ipf.c @@ -1011,7 +1011,7 @@ ipf_purge_list_check(struct ipf *ipf, struct ipf_list *ipf_list, } /* Does the packet batch management and common accounting work associated - * with 'ipf_send_completed_frags()' and 'ipf_send_expired_frags()'. */ + * with 'ipf_send_completed_frags()'. */ static bool ipf_send_frags_in_list(struct ipf *ipf, struct ipf_list *ipf_list, struct dp_packet_batch *pb, @@ -1076,8 +1076,7 @@ ipf_send_completed_frags(struct ipf *ipf, struct dp_packet_batch *pb, * a packet batch to be processed by the calling application, typically * conntrack. Also cleans up the list context when it is empty.*/ static void -ipf_send_expired_frags(struct ipf *ipf, struct dp_packet_batch *pb, - long long now, bool v6) +ipf_clean_expired_frags(struct ipf *ipf, long long now) { enum { /* Very conservative, due to DOS probability. */ @@ -1099,8 +1098,7 @@ ipf_send_expired_frags(struct ipf *ipf, struct dp_packet_batch *pb, break; } - if (ipf_send_frags_in_list(ipf, ipf_list, pb, IPF_FRAG_EXPIRY_LIST, - v6, now)) { + if (ipf_purge_list_check(ipf, ipf_list, now)) { ipf_expiry_list_clean(&ipf->frag_lists, ipf_list); lists_removed++; } else { @@ -1249,7 +1247,7 @@ ipf_postprocess_conntrack(struct ipf *ipf, struct dp_packet_batch *pb, bool v6 = dl_type == htons(ETH_TYPE_IPV6); ipf_post_execute_reass_pkts(ipf, pb, v6); ipf_send_completed_frags(ipf, pb, now, v6); - ipf_send_expired_frags(ipf, pb, now, v6); + ipf_clean_expired_frags(ipf, now); } }
Description: when 1) The fragment timeout is between 15 seconds and 25 seconds; 2) The ipf_list currently has received more than 32 fragments, and there are other fragments of same big packet that have not been received. When the above two scenario conditions are met, due to exceeding the capacity of the packet batch(here is 32), ipf_dp_packet_batch_add returns false, and ipf_list will not be cleared. However, the 32 fragments packets added to the packet batch will be processed normally. When receiving the subsequent fragments of the ipf_list, because the first 32 fragments have been processed, when processing subsequent fragment packets, relevant information about the processed fragment packets will be read，therefore will occur carsh. One solution is do not forward timeout fragment packets from the above scenarios, that is, do not add them to the packet batch, and handle other scenarios according to the original logic. Signed-off-by: laixiangwu <15310488637@163.com> --- lib/ipf.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)