linux-toradex.git/net/core, branch v3.0.16

net: Handle different key sizes between address families in flow cache

2011-11-11T17:37:17+00:00

commit aa1c366e4febc7f5c2b84958a2dd7cd70e28f9d0 upstream.

With the conversion of struct flowi to a union of AF-specific structs, some
operations on the flow cache need to account for the exact size of the key.

Signed-off-by: David Ward 
Signed-off-by: David S. Miller 
Cc: Kim Phillips 
Signed-off-by: Greg Kroah-Hartman

net: Unlock sock before calling sk_free()

2011-11-11T17:36:50+00:00

[ Upstream commit b0691c8ee7c28a72748ff32e91b165ec12ae4de6 ]

Signed-off-by: Thomas Gleixner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: hold sock reference while processing tx timestamps

2011-11-11T17:35:52+00:00

commit da92b194cc36b5dc1fbd85206aeeffd80bee0c39 upstream.

The pair of functions,

 * skb_clone_tx_timestamp()
 * skb_complete_tx_timestamp()

were designed to allow timestamping in PHY devices. The first
function, called during the MAC driver's hard_xmit method, identifies
PTP protocol packets, clones them, and gives them to the PHY device
driver. The PHY driver may hold onto the packet and deliver it at a
later time using the second function, which adds the packet to the
socket's error queue.

As pointed out by Johannes, nothing prevents the socket from
disappearing while the cloned packet is sitting in the PHY driver
awaiting a timestamp. This patch fixes the issue by taking a reference
on the socket for each such packet. In addition, the comments
regarding the usage of these function are expanded to highlight the
rule that PHY drivers must use skb_complete_tx_timestamp() to release
the packet, in order to release the socket reference, too.

These functions first appeared in v2.6.36.

Reported-by: Johannes Berg 
Signed-off-by: Richard Cochran 
Signed-off-by: Eric Dumazet 
Reviewed-by: Johannes Berg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

rtnetlink: Add missing manual netlink notification in dev_change_net_namespaces

2011-11-11T17:35:50+00:00

commit d2237d35748e7f448a9c2d9dc6a85ef637466e24 upstream.

Renato Westphal noticed that since commit a2835763e130c343ace5320c20d33c281e7097b7
"rtnetlink: handle rtnl_link netlink notifications manually" was merged
we no longer send a netlink message when a networking device is moved
from one network namespace to another.

Fix this by adding the missing manual notification in dev_change_net_namespaces.

Since all network devices that are processed by dev_change_net_namspaces are
in the initialized state the complicated tests that guard the manual
rtmsg_ifinfo calls in rollback_registered and register_netdevice are
unnecessary and we can just perform a plain notification.

Tested-by: Renato Westphal 
Signed-off-by: Eric W. Biederman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

scm: Capture the full credentials of the scm sender

2011-10-03T18:40:54+00:00

[ Upstream commit e33f7a9f37d486f4c6cce5de18a6eea11d68f64f ]

This patch corrects an erroneous update of credential's gid with uid
introduced in commit 257b5358b32f17 since 2.6.36.

Signed-off-by: Tim Chen 
Acked-by: Eric Dumazet 
Reviewed-by: James Morris 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

fib:fix BUG_ON in fib_nl_newrule when add new fib rule

2011-10-03T18:40:51+00:00

[ Upstream commit 561dac2d410ffac0b57a23b85ae0a623c1a076ca ]

add new fib rule can cause BUG_ON happen
the reproduce shell is
ip rule add pref 38
ip rule add pref 38
ip rule add to 192.168.3.0/24 goto 38
ip rule del pref 38
ip rule add to 192.168.3.0/24 goto 38
ip rule add pref 38

then the BUG_ON will happen
del BUG_ON and use (ctarget == NULL) identify whether this rule is unresolved

Signed-off-by: Gao feng 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

arp: fix rcu lockdep splat in arp_process()

2011-10-03T18:40:50+00:00

[ Upstream commit 20e6074eb8e096b3a595c093d1cb222f378cd671 ]

Dave Jones reported a lockdep splat triggered by an arp_process() call
from parp_redo().

Commit faa9dcf793be (arp: RCU changes) is the origin of the bug, since
it assumed arp_process() was called under rcu_read_lock(), which is not
true in this particular path.

Instead of adding rcu_read_lock() in parp_redo(), I chose to add it in
neigh_proxy_process() to take care of IPv6 side too.

 ===================================================
 [ INFO: suspicious rcu_dereference_check() usage. ]
 ---------------------------------------------------
 include/linux/inetdevice.h:209 invoked rcu_dereference_check() without
protection!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 0
 4 locks held by setfiles/2123:
  #0:  (&sb->s_type->i_mutex_key#13){+.+.+.}, at: []
walk_component+0x1ef/0x3e8
  #1:  (&isec->lock){+.+.+.}, at: []
inode_doinit_with_dentry+0x3f/0x41f
  #2:  (&tbl->proxy_timer){+.-...}, at: []
run_timer_softirq+0x157/0x372
  #3:  (class){+.-...}, at: [] neigh_proxy_process
+0x36/0x103

 stack backtrace:
 Pid: 2123, comm: setfiles Tainted: G        W
3.1.0-0.rc2.git7.2.fc16.x86_64 #1
 Call Trace:
    [] lockdep_rcu_dereference+0xa7/0xaf
  [] __in_dev_get_rcu+0x55/0x5d
  [] arp_process+0x25/0x4d7
  [] parp_redo+0xe/0x10
  [] neigh_proxy_process+0x9a/0x103
  [] run_timer_softirq+0x218/0x372
  [] ? run_timer_softirq+0x157/0x372
  [] ? neigh_stat_seq_open+0x41/0x41
  [] ? mark_held_locks+0x6d/0x95
  [] __do_softirq+0x112/0x25a
  [] call_softirq+0x1c/0x30
  [] do_softirq+0x4b/0xa2
  [] irq_exit+0x5d/0xcf
  [] smp_apic_timer_interrupt+0x7c/0x8a
  [] apic_timer_interrupt+0x73/0x80
    [] ? trace_hardirqs_on_caller+0x121/0x158
  [] ? __slab_free+0x30/0x24c
  [] ? __slab_free+0x2e/0x24c
  [] ? inode_doinit_with_dentry+0x2e9/0x41f
  [] ? inode_doinit_with_dentry+0x2e9/0x41f
  [] ? inode_doinit_with_dentry+0x2e9/0x41f
  [] kfree+0x108/0x131
  [] inode_doinit_with_dentry+0x2e9/0x41f
  [] selinux_d_instantiate+0x1c/0x1e
  [] security_d_instantiate+0x21/0x23
  [] d_instantiate+0x5c/0x61
  [] d_splice_alias+0xbc/0xd2
  [] ext4_lookup+0xba/0xeb
  [] d_alloc_and_lookup+0x45/0x6b
  [] walk_component+0x215/0x3e8
  [] lookup_last+0x3b/0x3d
  [] path_lookupat+0x82/0x2af
  [] ? might_fault+0xa5/0xac
  [] ? might_fault+0x5c/0xac
  [] ? getname_flags+0x31/0x1ca
  [] do_path_lookup+0x28/0x97
  [] user_path_at+0x59/0x96
  [] ? cp_new_stat+0xf7/0x10d
  [] vfs_fstatat+0x44/0x6e
  [] vfs_lstat+0x1e/0x20
  [] sys_newlstat+0x1a/0x33
  [] ? trace_hardirqs_on_caller+0x121/0x158
  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
  [] system_call_fastpath+0x16/0x1b

Reported-by: Dave Jones 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: allow netif_carrier to be called safely from IRQ

2011-08-16T01:31:39+00:00

[ Upstream commit 1821f7cd65ad9ea56580b830ac79bf4c4fef59cb ]

As reported by Ben Greer and Froncois Romieu. The code path in
the netif_carrier code leads it to try and disable
a late workqueue to reenable it immediately
netif_carrier_on
-> linkwatch_fire_event
   -> linkwatch_schedule_work
      -> cancel_delayed_work
         -> del_timer_sync

If __cancel_delayed_work is used instead then there is no
problem of waiting for running linkwatch_event.

There is a race between linkwatch_event running re-scheduling
but it is harmless to schedule an extra scan of the linkwatch queue.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: add IFF_SKB_TX_SHARED flag to priv_flags

2011-08-16T01:31:38+00:00

[ Upstream commit d8873315065f1f527c7c380402cf59b1e1d0ae36 ]

Pktgen attempts to transmit shared skbs to net devices, which can't be used by
some drivers as they keep state information in skbs.  This patch adds a flag
marking drivers as being able to handle shared skbs in their tx path.  Drivers
are defaulted to being unable to do so, but calling ether_setup enables this
flag, as 90% of the drivers calling ether_setup touch real hardware and can
handle shared skbs.  A subsequent patch will audit drivers to ensure that the
flag is set properly

Signed-off-by: Neil Horman 
Reported-by: Jiri Pirko 
CC: Robert Olsson 
CC: Eric Dumazet 
CC: Alexey Dobriyan 
CC: David S. Miller 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: Compute protocol sequence numbers and fragment IDs using MD5.

2011-08-16T01:31:35+00:00

Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky 
Tested-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman