We may miscalculate the sequence number difference from the
last time we send a notification if a sequence number wrap
occured in the meantime. We fix this by adding a separate
replay notify function for esn. Here we take the high bits
of the sequence number into account to calculate the
difference.
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>

This field was left uninitialized. Some user daemons perform check against this
field.
Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>

Eric Dumazet wrote:
| Some strange crashes happen in rt6_check_expired(), with access
| to random addresses.
|
| At first glance, it looks like the RTF_EXPIRES and
| stuff added in commit 1716a961
| (ipv6: fix problem with expired dst cache)
| are racy : same dst could be manipulated at the same time
| on different cpus.
|
| At some point, our stack believes rt->dst.from contains a dst pointer,
| while its really a jiffie value (as rt->dst.expires shares the same area
| of memory)
|
| rt6_update_expires() should be fixed, or am I missing something ?
|
| CC Neil because of https://bugzilla.redhat.com/show_bug.cgi?id=892060

Because we do not have any locks for dst_entry, we cannot change
essential structure in the entry; e.g., we cannot change reference
to other entity.

To fix this issue, split 'from' and 'expires' field in dst_entry
out of union.  Once it is 'from' is assigned in the constructor,
keep the reference until the very last stage of the life time of
the object.

Of course, it is unsafe to change 'from', so make rt6_set_from simple
just for fresh entries.
Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
Reported-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Gao Feng <gaofeng@cn.fujitsu.com>
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Reported-by: NSteinar H. Gunderson <sesse@google.com>
Reviewed-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit c9af6db4 (net: Fix possible wrong checksum generation)
has a suspicous piece:

	-       skb_shinfo(skb1)->gso_type = skb_shinfo(skb)->gso_type;
	-
	+       skb_shinfo(skb)->tx_flags = skb_shinfo(skb1)->tx_flags & SKBTX_SHARED_FRAG;

skb1 is the new skb, therefore should be on the left side of the assignment.
This patch fixes it.

Cc: Pravin B Shelar <pshelar@nicira.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: NCong Wang <amwang@redhat.com>
Acked-by: NPravin B Shelar <pshelar@nicira.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit 68c33163 (v4 GRE: Add TCP segmentation offload for GRE)
introduced a bug in error path.

dst is attached to skb, so will be released when skb is freed.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Acked-by: NPravin B Shelar <pshelar@nicira.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When !CONFIG_PROC_FS dev_mcast_init() is not defined,
actually we can just merge dev_mcast_init() into
dev_proc_init().
Reported-by: NGao feng <gaofeng@cn.fujitsu.com>
Cc: Gao feng <gaofeng@cn.fujitsu.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

the vars ip_rt_gc_timeout is used only when
CONFIG_SYSCTL is selected.

move these vars into CONFIG_SYSCTL.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Similar to net/core/net-sysfs.c, group procfs code to
a single unit.

Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If device is not able to handle checksumming it will
be handled in dev_xmit
Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Connection tracking helpers have to drop packets under exceptional
situations. Currently, the user gets the following logging message
in case that happens:

	nf_ct_%s: dropping packet ...

However, depending on the helper, there are different reasons why a
packet can be dropped.

This patch modifies the existing code to provide more specific
error message in the scope of each helper to help users to debug
the reason why the packet has been dropped, ie:

	nf_ct_%s: dropping packet: reason ...

Thanks to Joe Perches for many formatting suggestions.
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

net/ipv6/reassembly.c:82:72: warning: incorrect type in argument 3 (different base types)
net/ipv6/reassembly.c:82:72:    expected unsigned int [unsigned] [usertype] c
net/ipv6/reassembly.c:82:72:    got restricted __be32 [usertype] id
Signed-off-by: NEric Dumazet <edumazet@google.com>
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Allow our own family as the protocol value for socket creation.
Reported-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAndy King <acking@vmware.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There isn't really a need to have a separate file for it.
Acked-by: NAndy King <acking@vmware.com>
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is the default behavior for a looooooong time.
Acked-by: NAndy King <acking@vmware.com>
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Neighbor is cloned in xfrm6_fill_dst but seems to never be released.
Neighbor entry should be released when XFRM6 dst entry is destroyed
in xfrm6_dst_destroy, otherwise references may be kept forever on
the device pointed by the neighbor entry.

I may not have understood all the subtleties of XFRM & dst so I would
be happy to receive comments on this patch.
Signed-off-by: NRomain Kuntz <r.kuntz@ipflavors.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

proc_net_remove is only used to remove proc entries
that under /proc/net,it's not a general function for
removing proc entries of netns. if we want to remove
some proc entries which under /proc/net/stat/, we still
need to call remove_proc_entry.

this patch use remove_proc_entry to replace proc_net_remove.
we can remove proc_net_remove after this patch.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Right now, some modules such as bonding use proc_create
to create proc entries under /proc/net/, and other modules
such as ipv4 use proc_net_fops_create.

It looks a little chaos.this patch changes all of
proc_net_fops_create to proc_create. we can remove
proc_net_fops_create after this patch.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Same problem as IPv6
Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Should not use assignment in conditional:
 warning: suggest parentheses around assignment used as truth value [-Wparentheses]

Problem introduced by:
commit 14bbd6a5
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Thu Feb 14 09:44:49 2013 +0000

    net: Add skb_unclone() helper function.
Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They well deserve a separated unit.

Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Larry noticed (and bisected) that commit df881293
"cfg80211: Pass TDLS peer's QoS/HT/VHT information during set_station"
broke secure connections. This is is the case only for drivers that
don't support TDLS, where any kind of change, even just the change of
authorized flag that is required for normal operation, was rejected
now. To fix this, remove the checks. I have some patches that will add
proper verification for all the different cases later.

Cc: Jouni Malinen <j@w1.fi>
Bisected-by: NLarry Finger <Larry.Finger@lwfinger.net>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Use ipv6_addr_hash() and a single jhash invocation.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If mesh plink debugging is enabled, this gets annoying in
a crowded environment, fast.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Convert mesh peering events into strings and make the
debug output a little easier to read. Also stop printing
the llid and plid since these don't change across peering
states and are random numbers anyway so they just amount
to noise.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

ieee80211_ht_cap_ie_to_sta_ht_cap() will clean up the
ht_supported flag and station bandwidth field for us
if the peer beacon doesn't have an HT capability element
(is operating as non-HT).

Also, we don't really need a special station ch_width
member to track the station operating mode any more so use
sta.bandwidth instead.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If an interface is set down while authenticating or
associating, there's a station entry that will be
removed by the flushing in do_stop() and that will
cause a warning. It's otherwise harmless, but avoid
the warning by calling ieee80211_mgd_stop() first.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As the number of iovecs in a send request is already limited within
UIO_MAXIOV(i.e. 1024) in __sys_sendmsg(), it's unnecessary to check it
again in TIPC stack.
Signed-off-by: NYing Xue <ying.xue@windriver.com>
Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Change overload control to be purely byte-based, using
sk->sk_rmem_alloc as byte counter, and compare it to a calculated
upper limit for the socket receive queue.

For all connection messages, irrespective of message importance,
the overload limit is set to a constant value (i.e, 67MB). This
limit should normally never be reached because of the lower
limit used by the flow control algorithm, and is there only
as a last resort in case a faulty peer doesn't respect the send
window limit.

For datagram messages, message importance is taken into account
when calculating the overload limit. The calculation is based
on sk->sk_rcvbuf, and is hence configurable via the socket option
SO_RCVBUF.

Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: NYing Xue <ying.xue@windriver.com>
Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

The tipc function discard_rx_queue() is just a duplicated
implementation of __skb_queue_purge().  Remove the former
and directly invoke __skb_queue_purge().

In doing so, the underscores convey to the code reader, more
information about the current locking state that is assumed.
Signed-off-by: NYing Xue <ying.xue@windriver.com>
Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

After commit 3c294cb3 "tipc: remove the bearer congestion mechanism",
we try to grab the broadcast bearer lock when sending multicast
messages over the broadcast link. This will cause an oops because
the lock is never initialized. This is an old bug, but the lock
was never actually used before commit 3c294cb3, so that why it was
not visible until now.  The oops will look something like:

	BUG: spinlock bad magic on CPU#2, daemon/147
	lock: bcast_bearer+0x48/0xffffffffffffd19a [tipc],
	.magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
	Pid: 147, comm: daemon Not tainted 3.8.0-rc3+ #206
	Call Trace:
	spin_dump+0x8a/0x8f
	spin_bug+0x21/0x26
	do_raw_spin_lock+0x114/0x150
	_raw_spin_lock_bh+0x19/0x20
	tipc_bearer_blocked+0x1f/0x40 [tipc]
	tipc_link_send_buf+0x82/0x280 [tipc]
	? __alloc_skb+0x9f/0x2b0
	tipc_bclink_send_msg+0x77/0xa0 [tipc]
	tipc_multicast+0x11b/0x1b0 [tipc]
	send_msg+0x225/0x530 [tipc]
	sock_sendmsg+0xca/0xe0

The above can be triggered by running the multicast demo program.
Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We no longer need to use mac_len, lets cleanup things.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Following patch adds GRE protocol offload handler so that
skb_gso_segment() can segment GRE packets.
SKB GSO CB is added to keep track of total header length so that
skb_segment can push entire header. e.g. in case of GRE, skb_segment
need to push inner and outer headers to every segment.
New NETIF_F_GRE_GSO feature is added for devices which support HW
GRE TSO offload. Currently none of devices support it therefore GRE GSO
always fall backs to software GSO.

[ Compute pkt_len before ip_local_out() invocation. -DaveM ]
Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This function will be used in next GRE_GSO patch. This patch does
not change any functionality. It only exports skb_mac_gso_segment()
function.

[ Use skb_reset_mac_len() -DaveM ]
Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
Acked-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This function will be used in next GRE_GSO patch. This patch does
not change any functionality.
Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
Acked-by: NEric Dumazet <edumazet@google.com>

Several tracepoints are using STA_PR_FMT where STA_PR_ARG should be
used, resulting in messages like "phy0 sta:ARG TYPE NOT FIELD BUT 1".
Change these to STA_PR_ARG.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since mesh powersaving was added, pending bcast/mcast frames may go out the
CAB queue now.  Unfortunately, the queue was only set up for AP mode, so we
would try to tx on the IEEE80211_INVAL_HW_QUEUE.  Allow cab_queue for mesh
interfaces as well.

Fixes the following warning (or crash without MAC80211_VERBOSE_DEBUG):

WARNING: at net/mac80211/tx.c:1223 __ieee80211_tx+0x162/0x35f [mac80211]()
Modules linked in: mac80211_hwsim mac80211 cfg80211 [...]
Pid: 3085, comm: avahi-daemon Tainted: G        W    3.8.0-rc1+ #377
Call Trace:
 [<ffffffff81045c20>] warn_slowpath_common+0x83/0x9c
 [<ffffffff81045c53>] warn_slowpath_null+0x1a/0x1c
 [<ffffffffa083aef0>] __ieee80211_tx+0x162/0x35f [mac80211]
 [<ffffffffa083cb1d>] ieee80211_tx+0xd3/0xf9 [mac80211]
 [<ffffffffa083cc0f>] ieee80211_xmit+0xcc/0xd5 [mac80211]
 [<ffffffffa083db59>] ieee80211_subif_start_xmit+0xc53/0xcd8 [mac80211]
 [<ffffffff81319acd>] dev_hard_start_xmit+0x259/0x3ce
 [<ffffffff81333d6b>] sch_direct_xmit+0x74/0x17d
 [<ffffffff8131a0b1>] dev_queue_xmit+0x230/0x414
 [<ffffffff8134877a>] ip_finish_output2+0x348/0x3aa
 [<ffffffff81349029>] ip_finish_output+0x6c/0x71
 [<ffffffff81349046>] NF_HOOK_COND.constprop.44+0x18/0x58
 [<ffffffff8134a03a>] ip_mc_output+0x134/0x13c
 [<ffffffff8134835a>] dst_output+0x18/0x1c
 [<ffffffff81349a24>] ip_local_out+0x20/0x24
 [<ffffffff8134a8cf>] ip_send_skb+0x16/0x3c
 [<ffffffff8136bfba>] udp_send_skb+0x254/0x2b9
 [<ffffffff8136c85e>] udp_sendmsg+0x5a8/0x7d4
Signed-off-by: NBob Copeland <bob@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's various code with strange indentation,
questionable loop and locking constructs, etc.

The bigger change is moving the "sdata" argument
to the first argument of all functions, like all
other mac80211 functions that have one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Even when connecting to an AP that doesn't support VHT,
and even when the local device doesn't support it either,
the downgrade message gets printed. Suppress the message
if HT and/or VHT is disabled.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Adding the flag to mac80211 already without testing was
clearly a mistake, one that we now pay for by having to
reserve bit 13 forever. The problem is cfg80211 doesn't
allow capability/rate changes for station entries that
were added unassociated, so the station entries cannot
be set up properly when marked associated.

Change the NL80211_FEATURE_FULL_AP_CLIENT_STATE value
to make it clear to userspace implementations that all
current kernels don't actually support it, even though
the previous bit is set, and of course also remove the
flag from mac80211 until we test and fix the issues.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>