On 2/27/2020 3:54 PM, Yi-Hung Wei wrote:
On Wed, Feb 26, 2020 at 9:41 AM Greg Rose <gvrose8...@gmail.com> wrote:
Since Linux kernel release 5.1 the fragments field of the inet_frag_queue
structure is removed and now only the rb_fragments structure with an
rb_node pointer is used for both ipv4 and ipv6. In addition, the
atomic_sub and atomic_add functions are replaced with their
equivalent long counterparts.
Signed-off-by: Greg Rose <gvrose8...@gmail.com>
---
acinclude.m4 | 2 ++
datapath/linux/compat/include/net/inet_frag.h | 21 +++++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/acinclude.m4 b/acinclude.m4
index db64267..cad76c7 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -1067,6 +1067,8 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
[OVS_DEFINE([HAVE_RBTREE_RB_LINK_NODE_RCU])])
OVS_GREP_IFELSE([$KSRC/include/net/dst_ops.h], [bool confirm_neigh],
[OVS_DEFINE([HAVE_DST_OPS_CONFIRM_NEIGH])])
+ OVS_GREP_IFELSE([$KSRC/include/net/inet_frag.h], [fqdir],
+ [OVS_DEFINE([HAVE_INET_FRAG_FQDIR])])
if cmp -s datapath/linux/kcompat.h.new \
datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/linux/compat/include/net/inet_frag.h
b/datapath/linux/compat/include/net/inet_frag.h
index 124c8be..e3c6df3 100644
--- a/datapath/linux/compat/include/net/inet_frag.h
+++ b/datapath/linux/compat/include/net/inet_frag.h
@@ -18,7 +18,16 @@ static inline bool inet_frag_evicting(struct inet_frag_queue
*q)
#ifdef HAVE_INET_FRAG_QUEUE_WITH_LIST_EVICTOR
return !hlist_unhashed(&q->list_evictor);
#else
+/*
+ * We can't use acinclude.m4 to check this as the field 'fragments'
+ * also matches 'rb_fragments'.
+ */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5,1,0)
return (q_flags(q) & INET_FRAG_FIRST_IN) && q->fragments != NULL;
+#else
+ return (q_flags(q) & INET_FRAG_FIRST_IN) &&
+ q->rb_fragments.rb_node != NULL;
+#endif
#endif /* HAVE_INET_FRAG_QUEUE_WITH_LIST_EVICTOR */
}
#endif /* HAVE_INET_FRAG_EVICTING */
Yes, it's a bummer if we can not check some fields in the acinclude.m4.
It looks like inet_frag_evicting() has been removed by upstream commit
399d1404be66 ("inet: frags: get rif of inet_frag_evicting()") since
kernel 4.17, and the only place that we use is in rpl_ipfrag_init() ->
ip_expire() when HAVE_CORRECT_MRU_HANDLING is not available.
Therefore, how about the following approach that avoids the less
reliable kernel version check.
--- a/datapath/linux/compat/include/net/inet_frag.h
+++ b/datapath/linux/compat/include/net/inet_frag.h
@@ -12,6 +12,7 @@
#define qp_flags(qp) (qp->q.flags)
#endif
+#ifndef HAVE_CORRECT_MRU_HANDLING
#ifndef HAVE_INET_FRAG_EVICTING
static inline bool inet_frag_evicting(struct inet_frag_queue *q)
{
@@ -22,6 +23,7 @@ static inline bool inet_frag_evicting(struct
inet_frag_queue *q)
#endif /* HAVE_INET_FRAG_QUEUE_WITH_LIST_EVICTOR */
}
#endif /* HAVE_INET_FRAG_EVICTING */
+#endif /* HAVE_CORRECT_MRU_HANDLING */
I am good with the rest of the backports in this patch.
Thanks,
-Yi-Hung
Sure, that looks fine to me, I'll update the patch.
- Greg
@@ -29,6 +38,10 @@ static inline bool inet_frag_evicting(struct inet_frag_queue
*q)
#define inet_frag_lru_move(q)
#endif
+#ifdef HAVE_INET_FRAG_FQDIR
+#define netns_frags fqdir
+#endif
+
#ifndef HAVE_SUB_FRAG_MEM_LIMIT_ARG_STRUCT_NETNS_FRAGS
#ifdef HAVE_FRAG_PERCPU_COUNTER_BATCH
static inline void rpl_sub_frag_mem_limit(struct netns_frags *nf, int i)
@@ -45,13 +58,21 @@ static inline void rpl_add_frag_mem_limit(struct
netns_frags *nf, int i)
#else /* !frag_percpu_counter_batch */
static inline void rpl_sub_frag_mem_limit(struct netns_frags *nf, int i)
{
+#ifdef HAVE_INET_FRAG_FQDIR
+ atomic_long_sub(i, &nf->mem);
+#else
atomic_sub(i, &nf->mem);
+#endif
}
#define sub_frag_mem_limit rpl_sub_frag_mem_limit
static inline void rpl_add_frag_mem_limit(struct netns_frags *nf, int i)
{
+#ifdef HAVE_INET_FRAG_FQDIR
+ atomic_long_add(i, &nf->mem);
+#else
atomic_add(i, &nf->mem);
+#endif
}
#define add_frag_mem_limit rpl_add_frag_mem_limit
#endif /* frag_percpu_counter_batch */
--
1.8.3.1
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
