On Fri, Oct 17, 2014 at 06:20:57PM -0700, Madhu Challa wrote:
> I think I know whats happening. In case there is an error getting the
> datapath flow we should not try logging it since the flow is not valid.
>
> dpif_netlink_operate__
> {
> ...
> case DPIF_OP_FLOW_GET:
> op
I think I know whats happening. In case there is an error getting the
datapath flow we should not try logging it since the flow is not valid.
dpif_netlink_operate__
{
...
case DPIF_OP_FLOW_GET:
op->error = dpif_netlink_flow_from_ofpbuf(&reply,
txn->reply);
i
I am able to recreate it. I suspect its some bug at the dpif_netlink layer.
I am trying to narrow it down further. Anything in particular I could look
for ?
Thanks.
(gdb) print *get
$3 = {
key = 0x7fedec092190,
key_len = 0x60,
buffer = 0x7fee162a4b70,
flow = 0x7fee162a4b20
}
(gdb) print *
Forgot to attach the backtrace ::
(gdb) bt
#0 nl_attr_is_valid (maxlen=0xcfea1104, nla=0x0) at lib/netlink.h:139
#1 format_odp_actions (ds=0x7f77c7ffc800, actions=0x0,
actions_len=0x7f77cfea1104) at lib/odp-util.c:608
#2 0x00456749 in log_flow_message (error=0x2,
operation=0x506
You are correct Ben. I confused with the put that has actions in
dpif_flow_put. I guess I was not able to repro the issue then. Let me repro
it and I will resend the fix.
Thanks.
On Fri, Oct 17, 2014 at 4:17 PM, Ben Pfaff wrote:
> On Fri, Oct 17, 2014 at 04:07:25PM -0700, Madhu Challa wrote:
>
On Fri, Oct 17, 2014 at 04:07:25PM -0700, Madhu Challa wrote:
> dpif_flow_get initializes the flow_get part of the union, down the stack
> log_flow_message checks for actions || actions_len that could contain
> garbage leading to the crash.
>
> saw the crash once when running stress tests. can be
dpif_flow_get initializes the flow_get part of the union, down the stack
log_flow_message checks for actions || actions_len that could contain
garbage leading to the crash.
saw the crash once when running stress tests. can be easily recreated
by running ovs-dpctl del-flows in a loop when traffic i
