[ovs-dev] [PATCH] lib: Add initalize when xmalloc ofproto: Add initalize when recv from sdn controller

孙文杰 findtheonlyway at gmail.com
Mon Jul 2 08:50:10 UTC 2018


Hi,by our talking before the memory issue
,could you provide the fixed patch?

孙文杰 <findtheonlyway at gmail.com>于2018年6月19日 周二10:25写道:

> We use ovs 2.9.0.
>
> Ben Pfaff <blp at ovn.org> 于2018年6月16日周六 上午2:24写道:
>
>> [Dropping invalid email address findtheonlyway at example.com.]
>>
>> Thanks.
>>
>> I believe that we've found and fixed related memory errors before.  What
>> version of OVS are you using?
>>
>> On Fri, Jun 15, 2018 at 02:48:11PM +0800, 孙文杰 wrote:
>> > Yes, I can.
>> >
>> > When the first packets send to sdn contoller(we use onos), and the onos
>> > will send the packets back to ovs, if the buffer is not initalized,
>> there
>> > may cause some Illegal memory pointer.
>> >
>> > There is a panic stack caused in my env:
>> >
>> > #0  0x0000000000914647 in memcpy_from_metadata (dst=0x7ffe2e6fdd90,
>> > src=0x7ffe2e6fdef0, loc=0x2784e40) at lib/tun-metadata.c:451
>> > #1  0x000000000091446c in tun_metadata_get_fmd (tnl=0x7ffe2e6fdeb0,
>> > flow_metadata=0x31f7288) at lib/tun-metadata.c:396
>> > #2  0x000000000083a4f9 in flow_get_metadata (flow=0x7ffe2e6fdeb0,
>> > flow_metadata=0x31f7288) at lib/flow.c:1045
>> > #3  0x00000000007e5b37 in process_upcall (udpif=0x2cef410,
>> > upcall=0x7ffe2e6fe220, odp_actions=0x7ffe2e6fed50, wc=0x0) at
>> > ofproto/ofproto-dpif-upcall.c:1488
>> > #4  0x00000000007e525c in upcall_cb (packet=0x2cfcd60,
>> flow=0x7ffe2e6feea0,
>> > ufid=0x7ffe2e6ff140, pmd_id=4294967295, type=DPIF_UC_ACTION,
>> > userdata=0x31f2934, actions=0x7ffe2e6fed50, wc=0x0, put_actions=0x0,
>> > aux=0x2cef410)
>> >     at ofproto/ofproto-dpif-upcall.c:1264
>> > #5  0x000000000082b9ef in dp_netdev_upcall (pmd=0x284e6d0,
>> > packet_=0x2cfcd60, flow=0x7ffe2e6feea0, wc=0x0, ufid=0x7ffe2e6ff140,
>> > type=DPIF_UC_ACTION, userdata=0x31f2934, actions=0x7ffe2e6fed50,
>> > put_actions=0x0) at lib/dpif-netdev.c:4990
>> > #6  0x000000000082d15e in dp_execute_userspace_action (pmd=0x284e6d0,
>> > packet=0x2cfcd60, may_steal=false, flow=0x7ffe2e6feea0,
>> > ufid=0x7ffe2e6ff140, actions=0x7ffe2e6fed50, userdata=0x31f2934) at
>> > lib/dpif-netdev.c:5568
>> > #7  0x000000000082d97e in dp_execute_cb (aux_=0x7ffe2e6ff650,
>> > packets_=0x7ffe2e6ff680, a=0x31f2928, may_steal=false) at
>> > lib/dpif-netdev.c:5742
>> > #8  0x000000000086e868 in odp_execute_actions (dp=0x7ffe2e6ff650,
>> > batch=0x7ffe2e6ff680, steal=false, actions=0x31f2928, actions_len=64,
>> > dp_execute_action=0x82d1e4 <dp_execute_cb>) at lib/odp-execute.c:717
>> > #9  0x000000000082e09a in dp_netdev_execute_actions (pmd=0x284e6d0,
>> > packets=0x7ffe2e6ff680, may_steal=false, flow=0x2cfd1c0,
>> actions=0x31f2928,
>> > actions_len=64) at lib/dpif-netdev.c:5945
>> > #10 0x0000000000826781 in dpif_netdev_execute (dpif=0x2cef370,
>> > execute=0x7ffe2e6ff888) at lib/dpif-netdev.c:2954
>> > #11 0x000000000082687e in dpif_netdev_operate (dpif=0x2cef370,
>> > ops=0x7ffe2e6ff8d8, n_ops=1) at lib/dpif-netdev.c:2984
>> > #12 0x0000000000831fde in dpif_operate (dpif=0x2cef370,
>> ops=0x7ffe2e6ff8d8,
>> > n_ops=1) at lib/dpif.c:1359
>> > #13 0x0000000000831f3b in dpif_execute (dpif=0x2cef370,
>> > execute=0x7ffe2e6ff900) at lib/dpif.c:1324
>> > #14 0x00000000007d0778 in packet_execute (ofproto_=0x27b4b10,
>> > opo=0x7ffe2e6ffde0) at ofproto/ofproto-dpif.c:4661
>> > #15 0x00000000007b864e in ofproto_packet_out_finish (ofproto=0x27b4b10,
>> > opo=0x7ffe2e6ffde0) at ofproto/ofproto.c:3543
>> > #16 0x00000000007b87b4 in handle_packet_out (ofconn=0x31cf500,
>> > oh=0x2cffe40) at ofproto/ofproto.c:3584
>> > #17 0x00000000007c1c94 in handle_openflow__ (ofconn=0x31cf500,
>> > msg=0x2784b20) at ofproto/ofproto.c:8071
>> > #18 0x00000000007c2072 in handle_openflow (ofconn=0x31cf500,
>> > ofp_msg=0x2784b20) at ofproto/ofproto.c:8246
>> > #19 0x000000000080296c in ofconn_run (ofconn=0x31cf500,
>> > handle_openflow=0x7c204f <handle_openflow>) at ofproto/connmgr.c:1432
>> > #20 0x0000000000800177 in connmgr_run (mgr=0x2765bd0,
>> > handle_openflow=0x7c204f <handle_openflow>) at ofproto/connmgr.c:363
>> > #21 0x00000000007b479f in ofproto_run (p=0x27b4b10) at
>> > ofproto/ofproto.c:1816
>> > #22 0x00000000007a4d31 in bridge_run__ () at vswitchd/bridge.c:2941
>> > #23 0x00000000007a4f0f in bridge_run () at vswitchd/bridge.c:2999
>> > #24 0x00000000007aa58b in main (argc=4, argv=0x7ffe2e700f78) at
>> > vswitchd/ovs-vswitchd.c:119
>> >
>> >
>> >
>> > Ben Pfaff <blp at ovn.org> 于2018年6月15日周五 上午1:43写道:
>> >
>> > > On Thu, Jun 14, 2018 at 04:18:27PM +0800, findtheonlyway at gmail.com
>> wrote:
>> > > > From: findtheonlway <findtheonlyway at example.com>
>> > > >
>> > > > When recv packet from onos, the ovs may report an error or
>> > > > crash due to the buffer is uninitalized.
>> > > >
>> > > > Signed-off-by: findtheonlway <findtheonlyway at gmail.com>
>> > > > Signed-off-by: sunwenjie <sunwenjie at didichuxing.com>
>> > >
>> > > Can you provide an example?  It's not really acceptable to make
>> > > xmalloc() initialize every allocation.
>> > >
>>
>


More information about the dev mailing list