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