flushing stdout for flow -r

Change-Id: I9ccaaa40a14e6b8e8a88c4e0e50f4644c3f89323
- when the packet hits the resolve nexthop, the packet is trapped to
agent for route creation (resolve is valid only in fabric network).
While arp responses from fabric are trapped to agent for route creation
it is possible that the route will have valid information only after
the first data packet hits the route table, and hence there could be
packet loss

BUG 1336787

Change-Id: I345a343f478ddd8a7b62303d04a2e246825c403c
Merge "flushing stdout for flow -r"
- Now that agent has removed uses of hdr_nh, remove that field from
agent_hdr

Change-Id: I9767a0160390481e37c78f43cfb42a2fbb3fe55c
- In case of mirroring, packet data pointer can be above skb data
pointer, since for mirroring new headers are added on top of the
original packet. This results in get_udp_port misbehavior when it
tries to make sure that the all the headers (network + transport
/part of it) are in the contiguous memory area by doing a skb pull.

Make sure that pull_len has a valid positive value before trying to
pull.

Change-Id: I140ff67d9b67ddb66f075ba6659fa6e50d9bb436
Correcting the format of VIF index print

Change-Id: I4bf909bf28910c06ac6271cbcd3c886585b349ca
Merge "Correcting the format of VIF index print"
- There are two paths in the vrouter code where interfaces (OS visible
interfaces - netdev to be specific) are manipulated. One is in the call chain
to process agent request and the other is when the interface is deleted by linux
(for e.g.: a pseudo or a tap interface going away resulting in the notifier call
chain). In the latter path, netlink lock is acquired by the notifier chain,
whereas in the former path there is no netlink lock.

However, the common functions that are called in both paths need netlink lock.
The logic we had till now to decide whether we need to acquire lock in the
common functions is embarassingly buggy. rtnl_is_locked just says whether the
lock is locked or not and not whether the lock is owned by the thread or not,
as is in usage right now. So, in many cases it is possible that the lock is not
acquired, resulting in kernel warnings.

I guess, the usage was good when it was first used, but the subsequent copies of
the usage is not what is needed. To fix this issue, restructure the code path in
such a way that when common functions are entered, the lock is already taken.

BUG 1349258

- In 2.6.32-358.123.2.openstack.el6 kernel (and I guess all openstack kernels), the
first field in the skb->cb is an offset field that is used to calculate header length.
In those kernels, skb->cb is a structure of type skb_gso_cb with one field. Need to
set that field to zero.

BUG 1349560

Change-Id: I1e7e7b0e2f7cc7ee74b6db5ee91c347b7193a83b
Changes to accomodate drop reason for a flow, and display in flow utility.

Change-Id: I23da4c2b5eba49a53a5eb47c038d404f1cbe3984