Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can I use f-stack without enabling DPDK? #5

Closed
choleraehyq opened this issue May 14, 2017 · 2 comments
Closed

Can I use f-stack without enabling DPDK? #5

choleraehyq opened this issue May 14, 2017 · 2 comments

Comments

@choleraehyq
Copy link

The DPDK support is optional in seastar. We can compile seastar with DPDK ./configure --enable-dpdk.
Can I use f-stack without DPDK? I just want to use the user space stack.
@whl739
Copy link
Member

whl739 commented May 15, 2017 •
edited
Loading

No, we don't support it currently.
But you can do it yourself. In ff_veth.c:ff_veth_setup_interface, set ifp->if_transmit = your_transmit_func, and
call ifp->if_input(ifp, mb) when recv packets.

@choleraehyq
Copy link
Author

OK, thanks.

@ghost ghost mentioned this issue Jun 19, 2017
Closed
@amjy amjy mentioned this issue Sep 6, 2017
Closed
@jinhao2 jinhao2 mentioned this issue Sep 26, 2017
Open
@shockx2 shockx2 mentioned this issue Jan 18, 2018
Open
@zhanghaisen zhanghaisen mentioned this issue Jun 8, 2018
Closed
@hit1943 hit1943 mentioned this issue Jun 14, 2018
Open
@arikachen arikachen mentioned this issue Oct 8, 2018
Closed
@kannawadi kannawadi mentioned this issue Jul 23, 2019
Open
@ygm521 ygm521 mentioned this issue Sep 2, 2020
Open
@jeffzhou-dev jeffzhou-dev mentioned this issue Nov 13, 2020
Open
tanjianfeng added a commit to tanjianfeng/f-stack that referenced this issue Dec 7, 2020
@tanjianfeng
[PATCH] fix use after free issue in mbuf free
8fb8822 
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
@tanjianfeng
fix use after free issue in mbuf free
cf62746 
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 tanjianfeng mentioned this issue Dec 7, 2020
Merged
tanjianfeng added a commit to tanjianfeng/f-stack that referenced this issue Dec 21, 2020
@tanjianfeng
fix use after free issue in mbuf free
664b9bf 
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 Mar 6, 2021
@tanjianfeng @jfb8856606
fix use after free issue in mbuf free
2e1f4e1 
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
@tanjianfeng @jfb8856606
fix use after free issue in mbuf free
8445611 
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
@tanjianfeng @jfb8856606
fix use after free issue in mbuf free
fa552ee 
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>
@jeff-lv-github jeff-lv-github mentioned this issue Feb 8, 2022
Open
@RockGo RockGo mentioned this issue Mar 25, 2022
Open
jfb8856606 pushed a commit that referenced this issue Jul 5, 2022
@tanjianfeng @jfb8856606
fix use after free issue in mbuf free
e6161e2 
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
@tanjianfeng @jfb8856606
fix use after free issue in mbuf free
06c3e57 
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>
@rajeshwarp2002 rajeshwarp2002 mentioned this issue Apr 9, 2023
Closed
@tengliu0929 tengliu0929 mentioned this issue Jul 7, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@whl739 @choleraehyq