First Issues, hoping f-stack back soon. #1
Comments
|
done |
ghost
mentioned this issue
Closed
whl739
pushed a commit
that referenced
this issue
Feb 24, 2018
Nginx :directive ```proxy_kernel_network_stack```
jfb8856606
pushed a commit
that referenced
this issue
Jun 25, 2019
Nginx :directive ```proxy_kernel_network_stack```
tanjianfeng
added a commit
to tanjianfeng/f-stack
that referenced
this issue
Dec 7, 2020
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf.
freebsd mbufs are metadata used in freebsd stack, and their data
pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have
their own chain, like this:
bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3
\ \ \
dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3
Considering the map relationship,
- m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole
chain of mbufs.
- m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the
specified mbuf segment.
The current implementation in f-stack uses rte_pktmbuf_free() for
m_free(). This leads to mbufs, which are still in use, be freed
unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length,
bsd will invoke m_free() to free the specified segment, however, the
whole mbuf chain is freed by calling rte_pktmbuf_free().
#0 rte_pktmbuf_free (m=0x22006fb480)
F-Stack#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480)
F-Stack#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0)
F-Stack#3 in mb_free_ext (m=0x7ffff7f82800)
F-Stack#4 in m_free (m=0x7ffff7f82800)
F-Stack#5 in sbcompress (sb=, m=0x7ffff7f82800, n=)
F-Stack#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0)
The fix is straightforward. Use the correct API for segment free.
Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com>
Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
tanjianfeng
added a commit
to tanjianfeng/f-stack
that referenced
this issue
Dec 7, 2020
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf.
freebsd mbufs are metadata used in freebsd stack, and their data
pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have
their own chain, like this:
bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3
\ \ \
dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3
Considering the map relationship,
- m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole
chain of mbufs.
- m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the
specified mbuf segment.
The current implementation in f-stack uses rte_pktmbuf_free() for
m_free(). This leads to mbufs, which are still in use, be freed
unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length,
bsd will invoke m_free() to free the specified segment, however, the
whole mbuf chain is freed by calling rte_pktmbuf_free().
#0 rte_pktmbuf_free (m=0x22006fb480)
F-Stack#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480)
F-Stack#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0)
F-Stack#3 in mb_free_ext (m=0x7ffff7f82800)
F-Stack#4 in m_free (m=0x7ffff7f82800)
F-Stack#5 in sbcompress (sb=, m=0x7ffff7f82800, n=)
F-Stack#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0)
The fix is straightforward. Use the correct API for segment free.
Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com>
Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
tanjianfeng
added a commit
to tanjianfeng/f-stack
that referenced
this issue
Dec 21, 2020
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf.
freebsd mbufs are metadata used in freebsd stack, and their data
pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have
their own chain, like this:
bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3
\ \ \
dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3
Considering the map relationship,
- m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole
chain of mbufs.
- m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the
specified mbuf segment.
The current implementation in f-stack uses rte_pktmbuf_free() for
m_free(). This leads to mbufs, which are still in use, be freed
unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length,
bsd will invoke m_free() to free the specified segment, however, the
whole mbuf chain is freed by calling rte_pktmbuf_free().
#0 rte_pktmbuf_free (m=0x22006fb480)
F-Stack#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480)
F-Stack#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0)
F-Stack#3 in mb_free_ext (m=0x7ffff7f82800)
F-Stack#4 in m_free (m=0x7ffff7f82800)
F-Stack#5 in sbcompress (sb=, m=0x7ffff7f82800, n=)
F-Stack#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0)
The fix is straightforward. Use the correct API for segment free.
Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com>
Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Jan 7, 2021
Replace deprecated filter api with generic flowapi (#563)
jfb8856606
pushed a commit
that referenced
this issue
Mar 6, 2021
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf.
freebsd mbufs are metadata used in freebsd stack, and their data
pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have
their own chain, like this:
bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3
\ \ \
dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3
Considering the map relationship,
- m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole
chain of mbufs.
- m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the
specified mbuf segment.
The current implementation in f-stack uses rte_pktmbuf_free() for
m_free(). This leads to mbufs, which are still in use, be freed
unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length,
bsd will invoke m_free() to free the specified segment, however, the
whole mbuf chain is freed by calling rte_pktmbuf_free().
#0 rte_pktmbuf_free (m=0x22006fb480)
#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480)
#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0)
#3 in mb_free_ext (m=0x7ffff7f82800)
#4 in m_free (m=0x7ffff7f82800)
#5 in sbcompress (sb=, m=0x7ffff7f82800, n=)
#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0)
The fix is straightforward. Use the correct API for segment free.
Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com>
Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Mar 6, 2021
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf.
freebsd mbufs are metadata used in freebsd stack, and their data
pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have
their own chain, like this:
bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3
\ \ \
dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3
Considering the map relationship,
- m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole
chain of mbufs.
- m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the
specified mbuf segment.
The current implementation in f-stack uses rte_pktmbuf_free() for
m_free(). This leads to mbufs, which are still in use, be freed
unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length,
bsd will invoke m_free() to free the specified segment, however, the
whole mbuf chain is freed by calling rte_pktmbuf_free().
#0 rte_pktmbuf_free (m=0x22006fb480)
#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480)
#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0)
#3 in mb_free_ext (m=0x7ffff7f82800)
#4 in m_free (m=0x7ffff7f82800)
#5 in sbcompress (sb=, m=0x7ffff7f82800, n=)
#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0)
The fix is straightforward. Use the correct API for segment free.
Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com>
Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Mar 6, 2021
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf.
freebsd mbufs are metadata used in freebsd stack, and their data
pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have
their own chain, like this:
bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3
\ \ \
dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3
Considering the map relationship,
- m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole
chain of mbufs.
- m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the
specified mbuf segment.
The current implementation in f-stack uses rte_pktmbuf_free() for
m_free(). This leads to mbufs, which are still in use, be freed
unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length,
bsd will invoke m_free() to free the specified segment, however, the
whole mbuf chain is freed by calling rte_pktmbuf_free().
#0 rte_pktmbuf_free (m=0x22006fb480)
#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480)
#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0)
#3 in mb_free_ext (m=0x7ffff7f82800)
#4 in m_free (m=0x7ffff7f82800)
#5 in sbcompress (sb=, m=0x7ffff7f82800, n=)
#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0)
The fix is straightforward. Use the correct API for segment free.
Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com>
Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Jul 5, 2022
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf.
freebsd mbufs are metadata used in freebsd stack, and their data
pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have
their own chain, like this:
bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3
\ \ \
dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3
Considering the map relationship,
- m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole
chain of mbufs.
- m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the
specified mbuf segment.
The current implementation in f-stack uses rte_pktmbuf_free() for
m_free(). This leads to mbufs, which are still in use, be freed
unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length,
bsd will invoke m_free() to free the specified segment, however, the
whole mbuf chain is freed by calling rte_pktmbuf_free().
#0 rte_pktmbuf_free (m=0x22006fb480)
#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480)
#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0)
#3 in mb_free_ext (m=0x7ffff7f82800)
#4 in m_free (m=0x7ffff7f82800)
#5 in sbcompress (sb=, m=0x7ffff7f82800, n=)
#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0)
The fix is straightforward. Use the correct API for segment free.
Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com>
Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Sep 2, 2022
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf.
freebsd mbufs are metadata used in freebsd stack, and their data
pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have
their own chain, like this:
bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3
\ \ \
dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3
Considering the map relationship,
- m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole
chain of mbufs.
- m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the
specified mbuf segment.
The current implementation in f-stack uses rte_pktmbuf_free() for
m_free(). This leads to mbufs, which are still in use, be freed
unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length,
bsd will invoke m_free() to free the specified segment, however, the
whole mbuf chain is freed by calling rte_pktmbuf_free().
#0 rte_pktmbuf_free (m=0x22006fb480)
#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480)
#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0)
#3 in mb_free_ext (m=0x7ffff7f82800)
#4 in m_free (m=0x7ffff7f82800)
#5 in sbcompress (sb=, m=0x7ffff7f82800, n=)
#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0)
The fix is straightforward. Use the correct API for segment free.
Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com>
Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
hope this issue can be closed at 23/04 on time :-)
The text was updated successfully, but these errors were encountered: