14 Feb, 2011
1 commit
-
The app_data priority may not be the same for all net devices.
In order for stacks with application notifiers to identify the
specific net device dcb_app_type should be passed in the ptr.This allows handlers to use dev_get_by_name() to pin priority
to net devices.Signed-off-by: John Fastabend
Signed-off-by: David S. Miller
12 Feb, 2011
4 commits
-
As it turns out we never need to walk through the list of multicast
groups subscribed by the bridge interface itself (the only time we'd
want to do that is when we shut down the bridge, in which case we
simply walk through all multicast groups), we don't really need to
keep an hlist for mp->mglist.This means that we can replace it with just a single bit to indicate
whether the bridge interface is subscribed to a group.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller -
In a couple of spots where we are supposed to modify the port
group timer (p->timer) we instead modify the bridge interface
group timer (mp->timer).The effect of this is mostly harmless. However, it can cause
port subscriptions to be longer than they should be, thus making
snooping less effective.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller -
The list mp->mglist is used to indicate whether a multicast group
is active on the bridge interface itself as opposed to one of the
constituent interfaces in the bridge.Unfortunately the operation that adds the mp->mglist node to the
list neglected to check whether it has already been added. This
leads to list corruption in the form of nodes pointing to itself.Normally this would be quite obvious as it would cause an infinite
loop when walking the list. However, as this list is never actually
walked (which means that we don't really need it, I'll get rid of
it in a subsequent patch), this instead is hidden until we perform
a delete operation on the affected nodes.As the same node may now be pointed to by more than one node, the
delete operations can then cause modification of freed memory.This was observed in practice to cause corruption in 512-byte slabs,
most commonly leading to crashes in jbd2.Thanks to Josef Bacik for pointing me in the right direction.
Reported-by: Ian Page Hands
Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller -
Commit 5811662b15db018c740c57d037523683fd3e6123 ("net: use the macros
defined for the members of flowi") accidentally removed the setting of
IPPROTO_GRE from the struct flowi in ipgre_tunnel_xmit. This patch
restores it.Signed-off-by: Steffen Klassert
Acked-by: Changli Gao
Signed-off-by: David S. Miller
11 Feb, 2011
1 commit
-
Commit 80c802f3073e84 (xfrm: cache bundles instead of policies for
outgoing flows) introduced possible oopse when dst_alloc returns NULL.Signed-off-by: Hiroaki SHIMODA
Signed-off-by: David S. Miller
10 Feb, 2011
2 commits
-
In x25_link_free(), we destroy 'nb' before dereferencing
'nb->dev'. Don't do this, because 'nb' might be freed
by then.Reported-by: Randy Dunlap
Tested-by: Randy Dunlap
Signed-off-by: David S. Miller
09 Feb, 2011
4 commits
-
The TCP tracking code has a special case that allows to return
NF_REPEAT if we receive a new SYN packet while in TIME_WAIT state.In this situation, the TCP tracking code destroys the existing
conntrack to start a new clean session.[DESTROY] tcp 6 src=192.168.0.2 dst=192.168.1.2 sport=38925 dport=8000 src=192.168.1.2 dst=192.168.1.100 sport=8000 dport=38925 [ASSURED]
[NEW] tcp 6 120 SYN_SENT src=192.168.0.2 dst=192.168.1.2 sport=38925 dport=8000 [UNREPLIED] src=192.168.1.2 dst=192.168.1.100 sport=8000 dport=38925However, this is a problem for the iptables' CT target event filtering
which will not work in this case since the conntrack template will not
be there for the new session. To fix this, we reassign the conntrack
template to the packet if we return NF_REPEAT.Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Patrick McHardy -
In commit aa9421041128abb4d269ee1dc502ff65fb3b7d69 ("net: init ingress
queue") we moved the allocation and lock initialization of the queues
into alloc_netdev_mq() since register_netdevice() is way too late.The problem is that dev->type is not setup until the setup()
callback is invoked by alloc_netdev_mq(), and the dev->type is
what determines the lockdep class to use for the locks in the
queues.Fix this by doing the queue allocation after the setup() callback
runs.This is safe because the setup() callback is not allowed to make any
state changes that need to be undone on error (memory allocations,
etc.). It may, however, make state changes that are undone by
free_netdev() (such as netif_napi_add(), which is done by the
ipoib driver's setup routine).The previous code also leaked a reference to the &init_net namespace
object on RX/TX queue allocation failures.Signed-off-by: David S. Miller
-
rtnl_link_ops->setup(), and the "setup" callback passed to alloc_netdev*(),
cannot make state changes which need to be undone on failure. There is
no cleanup mechanism available at this point.So we have to add the caif private instance to the global list once we
are sure that register_netdev() has succedded in ->newlink().Otherwise, if register_netdev() fails, the caller will invoke free_netdev()
and we will have a reference to freed up memory on the chnl_net_list.Signed-off-by: David S. Miller
08 Feb, 2011
4 commits
-
We access the data inside the skbs of two fragments directly using memmove
during the merge. The data of the skb could span over multiple skb pages. An
direct access without knowledge about the pages would lead to an invalid memory
access.Signed-off-by: Sven Eckelmann
[lindner_marek@yahoo.de: Move return from function to the end]
Signed-off-by: Marek Lindner -
Originally x25_parse_facilities returned
-1 for an error
0 meaning 0 length facilities
>0 the length of the facilities parsed.5ef41308f94dc ("x25: Prevent crashing when parsing bad X.25 facilities") introduced more
error checking in x25_parse_facilities however used 0 to indicate bad parsing
a6331d6f9a429 ("memory corruption in X.25 facilities parsing") followed this further for
DTE facilities, again using 0 for bad parsing.The meaning of 0 got confused in the callers.
If the facilities are messed up we can't determine where the data starts.
So patch makes all parsing errors return -1 and ensures callers close and don't use the skb further.Reported-by: Andy Whitcroft
Signed-off-by: Andrew Hendry
Signed-off-by: David S. Miller -
Using skb_header_cloned to check if it's safe to write to the skb is not
enough - mac80211 also touches the tailroom of the skb.
Initially this check was only used to increase a counter, however this
commit changed the code to also skip skb data reallocation if no extra
head/tailroom was needed:commit 4cd06a344db752f513437138953af191cbe9a691
mac80211: skip unnecessary pskb_expand_head callsIt added a regression at least with iwl3945, which is fixed by this patch.
Reported-by: Dmitry Torokhov
Signed-off-by: Felix Fietkau
Tested-by: Dmitry Torokhov
Signed-off-by: John W. Linville
05 Feb, 2011
1 commit
-
The fdb_create() puts a new fdb into hash with only addr set. This is
not good, since there are callers, that search the hash w/o the lock
and access all the other its fields.Applies to current netdev tree.
Signed-off-by: Pavel Emelyanov
Signed-off-by: David S. Miller
04 Feb, 2011
3 commits
-
Signed-off-by: David S. Miller
-
Signed-off-by: David S. Miller
-
Commit 709b46e8d90badda1898caea50483c12af178e96 ("net: Add compat
ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT") added the
correct plumbing to handle SIOCGETSGCNT properly.However, whilst definiting a proper "struct compat_sioc_sg_req" it
isn't actually used in ipmr_compat_ioctl().Correct this oversight.
Signed-off-by: David S. Miller
03 Feb, 2011
3 commits
-
Like Herbert's change from a few days ago:
66c46d741e2e60f0e8b625b80edb0ab820c46d7a gro: Reset dev pointer on reuse
this may not be necessary at this point, but we should still clean up
the skb->skb_iif. If not we may end up with an invalid valid for
skb->skb_iif when the skb is reused and the check is done in
__netif_receive_skb.Signed-off-by: Andy Gospodarek
Signed-off-by: David S. Miller -
When the off-channel TX is done with remain-on-channel
offloaded to hardware, the reported cookie is wrong as
in that case we shouldn't use the SKB as the cookie but
need to instead use the corresponding r-o-c cookie
(XOR'ed with 2 to prevent API mismatches).Fix this by keeping track of the hw_roc_skb pointer
just for the status processing and use the correct
cookie to report in this case. We can't use the
hw_roc_skb pointer itself because it is NULL'ed when
the frame is transmitted to prevent it being used
twice.This fixes a bug where the P2P state machine in the
supplicant gets stuck because it never gets a correct
result for its transmitted frame.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
01 Feb, 2011
5 commits
-
For the following rule:
iptables -I PREROUTING -t raw -j CT --ctevents assured
The event delivered looks like the following:
[UPDATE] tcp 6 src=192.168.0.2 dst=192.168.1.2 sport=37041 dport=80 src=192.168.1.2 dst=192.168.1.100 sport=80 dport=37041 [ASSURED]
Note that the TCP protocol state is not included. For that reason
the CT event filtering is not very useful for conntrackd.To resolve this issue, instead of conditionally setting the CT events
bits based on the ctmask, we always set them and perform the filtering
in the late stage, just before the delivery.Thus, the event delivered looks like the following:
[UPDATE] tcp 6 432000 ESTABLISHED src=192.168.0.2 dst=192.168.1.2 sport=37041 dport=80 src=192.168.1.2 dst=192.168.1.100 sport=80 dport=37041 [ASSURED]
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Patrick McHardy -
In 135367b "netfilter: xtables: change xt_target.checkentry return type",
the type returned by checkentry was changed from boolean to int, but the
return values where not adjusted.arptables: Input/output error
This broke arptables with the mangle target since it returns true
under success, which is interpreted by xtables as >0, thus
returning EIO.Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Patrick McHardy -
In my testing of 2.6.37 I was occassionally getting a warning about
sysctl table entries being unregistered in the wrong order. Digging
in it turns out this dates back to the last great sysctl reorg done
where Al Viro introduced the requirement that sysctl directories
needed to be created before and destroyed after the files in them.It turns out that in that great reorg /proc/sys/net/ipv6/neigh was
overlooked. So this patch fixes that oversight and makes an annoying
warning message go away.>------------[ cut here ]------------
>WARNING: at kernel/sysctl.c:1992 unregister_sysctl_table+0x134/0x164()
>Pid: 23951, comm: kworker/u:3 Not tainted 2.6.37-350888.2010AroraKernelBeta.fc14.x86_64 #1
>Call Trace:
> [] warn_slowpath_common+0x80/0x98
> [] warn_slowpath_null+0x15/0x17
> [] unregister_sysctl_table+0x134/0x164
> [] ? kfree+0xc4/0xd1
> [] neigh_sysctl_unregister+0x22/0x3a
> [] addrconf_ifdown+0x33f/0x37b [ipv6]
> [] ? skb_dequeue+0x5f/0x6b
> [] addrconf_notify+0x69b/0x75c [ipv6]
> [] ? ip6mr_device_event+0x98/0xa9 [ipv6]
> [] notifier_call_chain+0x32/0x5e
> [] raw_notifier_call_chain+0xf/0x11
> [] call_netdevice_notifiers+0x45/0x4a
> [] rollback_registered_many+0x118/0x201
> [] unregister_netdevice_many+0x16/0x6d
> [] default_device_exit_batch+0xa4/0xb8
> [] ? cleanup_net+0x0/0x194
> [] ops_exit_list+0x4e/0x56
> [] cleanup_net+0xf4/0x194
> [] process_one_work+0x187/0x280
> [] worker_thread+0xff/0x19f
> [] ? worker_thread+0x0/0x19f
> [] kthread+0x7d/0x85
> [] kernel_thread_helper+0x4/0x10
> [] ? kthread+0x0/0x85
> [] ? kernel_thread_helper+0x0/0x10
>---[ end trace 8a7e9310b35e9486 ]---Signed-off-by: Eric W. Biederman
Signed-off-by: David S. Miller -
In get_rps_cpu, add check that the rps_flow_table for the device is
NULL when trying to take fast path when RPS map length is one.
Without this, RFS is effectively disabled if map length is one which
is not correct.Signed-off-by: Tom Herbert
Signed-off-by: David S. Miller -
When an IPSEC SA is still being set up, __xfrm_lookup() will return
-EREMOTE and so ip_route_output_flow() will return a blackhole route.
This can happen in a sndmsg call, and after d33e455337ea ("net: Abstract
default MTU metric calculation behind an accessor.") this leads to a
crash in ip_append_data() because the blackhole dst_ops have no
default_mtu() method and so dst_mtu() calls a NULL pointer.Fix this by adding default_mtu() methods (that simply return 0, matching
the old behavior) to the blackhole dst_ops.The IPv4 part of this patch fixes a crash that I saw when using an IPSEC
VPN; the IPv6 part is untested because I don't have an IPv6 VPN, but it
looks to be needed as well.Signed-off-by: Roland Dreier
Signed-off-by: David S. Miller
31 Jan, 2011
1 commit
30 Jan, 2011
6 commits
-
The batman-adv vis server has to a stack which stores all information
about packets which should be send later. This stack is protected
with a spinlock that is used to prevent concurrent write access to it.The send_vis_packets function has to take all elements from the stack
and send them to other hosts over the primary interface. The send will
be initiated without the lock which protects the stack.The implementation using list_for_each_entry_safe has the problem that
it stores the next element as "safe ptr" to allow the deletion of the
current element in the list. The list may be modified during the
unlock/lock pair in the loop body which may make the safe pointer
not pointing to correct next element.It is safer to remove and use the first element from the stack until no
elements are available. This does not need reduntant information which
would have to be validated each time the lock was removed.Reported-by: Russell Senior
Signed-off-by: Sven Eckelmann -
The free_info function will be called when no reference to the info
object exists anymore. It must be ensured that the allocated memory
gets freed and not only the elements which are managed by the info
object.Signed-off-by: Sven Eckelmann
-
A newly created vis info object must be removed when it couldn't be
added to the hash. The old_info which has to be replaced was already
removed and isn't related to the hash anymore.Signed-off-by: Sven Eckelmann
-
SIOCGETSGCNT is not a unique ioctl value as it it maps tio SIOCPROTOPRIVATE +1,
which unfortunately means the existing infrastructure for compat networking
ioctls is insufficient. A trivial compact ioctl implementation would conflict
with:SIOCAX25ADDUID
SIOCAIPXPRISLT
SIOCGETSGCNT_IN6
SIOCGETSGCNT
SIOCRSSCAUSE
SIOCX25SSUBSCRIP
SIOCX25SDTEFACILITIESTo make this work I have updated the compat_ioctl decode path to mirror the
the normal ioctl decode path. I have added an ipv4 inet_compat_ioctl function
so that I can have ipv4 specific compat ioctls. I have added a compat_ioctl
function into struct proto so I can break out ioctls by which kind of ip socket
I am using. I have added a compat_raw_ioctl function because SIOCGETSGCNT only
works on raw sockets. I have added a ipmr_compat_ioctl that mirrors the normal
ipmr_ioctl.This was necessary because unfortunately the struct layout for the SIOCGETSGCNT
has unsigned longs in it so changes between 32bit and 64bit kernels.This change was sufficient to run a 32bit ip multicast routing daemon on a
64bit kernel.Reported-by: Bill Fenner
Signed-off-by: Eric W. Biederman
Signed-off-by: David S. Miller -
Ed Swierk writes:
> On 2.6.35.7
> ip link add link eth0 netns 9999 type macvlan
> where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang:
> [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d
> [10663.821917] IP: [] __dev_alloc_name+0x9a/0x170
> [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0
> [10663.821944] Oops: 0000 [#1] SMP
> [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
> [10663.821959] CPU 3
> [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class
> [10663.822155]
> [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO
> [10663.822167] RIP: 0010:[] [] __dev_alloc_name+0x9a/0x170
> [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286
> [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000
> [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000
> [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041
> [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818
> [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000
> [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000
> [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0
> [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0)
> [10663.822236] Stack:
> [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6
> [10663.822251] 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818
> [10663.822265] ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413
> [10663.822281] Call Trace:
> [10663.822290] [] ? dev_addr_init+0x75/0xb0
> [10663.822298] [] dev_alloc_name+0x43/0x90
> [10663.822307] [] rtnl_create_link+0xbe/0x1b0
> [10663.822314] [] rtnl_newlink+0x48a/0x570
> [10663.822321] [] ? rtnl_newlink+0x1ac/0x570
> [10663.822332] [] ? native_x2apic_icr_read+0x4/0x20
> [10663.822339] [] rtnetlink_rcv_msg+0x177/0x290
> [10663.822346] [] ? rtnetlink_rcv_msg+0x0/0x290
> [10663.822354] [] netlink_rcv_skb+0xa9/0xd0
> [10663.822360] [] rtnetlink_rcv+0x25/0x40
> [10663.822367] [] netlink_unicast+0x2de/0x2f0
> [10663.822374] [] netlink_sendmsg+0x1fe/0x2e0
> [10663.822383] [] sock_sendmsg+0xf3/0x120
> [10663.822391] [] ? _raw_spin_lock+0xe/0x20
> [10663.822400] [] ? __d_lookup+0x136/0x150
> [10663.822406] [] ? _raw_spin_lock+0xe/0x20
> [10663.822414] [] ? _atomic_dec_and_lock+0x4d/0x80
> [10663.822422] [] ? mntput_no_expire+0x30/0x110
> [10663.822429] [] ? move_addr_to_kernel+0x65/0x70
> [10663.822435] [] ? verify_iovec+0x88/0xe0
> [10663.822442] [] sys_sendmsg+0x240/0x3a0
> [10663.822450] [] ? __do_fault+0x479/0x560
> [10663.822457] [] ? _raw_spin_lock+0xe/0x20
> [10663.822465] [] ? alloc_fd+0x10a/0x150
> [10663.822473] [] ? do_page_fault+0x15e/0x350
> [10663.822482] [] system_call_fastpath+0x16/0x1b
> [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55
> [10663.822618] RIP [] __dev_alloc_name+0x9a/0x170
> [10663.822627] RSP
> [10663.822631] CR2: 000000000000006d
> [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]---This bug was introduced in:
commit 81adee47dfb608df3ad0b91d230fb3cef75f0060
Author: Eric W. Biederman
Date: Sun Nov 8 00:53:51 2009 -0800net: Support specifying the network namespace upon device creation.
There is no good reason to not support userspace specifying the
network namespace during device creation, and it makes it easier
to create a network device and pass it to a child network namespace
with a well known name.We have to be careful to ensure that the target network namespace
for the new device exists through the life of the call. To keep
that logic clear I have factored out the network namespace grabbing
logic into rtnl_link_get_net.In addtion we need to continue to pass the source network namespace
to the rtnl_link_ops.newlink method so that we can find the base
device source network namespace.Signed-off-by: Eric W. Biederman
Acked-by: Eric DumazetWhere apparently I forgot to add error handling to the path where we create
a new network device in a new network namespace, and pass in an invalid pid.Cc: stable@kernel.org
Reported-by: Ed Swierk
Signed-off-by: "Eric W. Biederman"
Signed-off-by: David S. Miller -
On older kernels the VLAN code may zero skb->dev before dropping
it and causing it to be reused by GRO.Unfortunately we didn't reset skb->dev in that case which causes
the next GRO user to get a bogus skb->dev pointer.This particular problem no longer happens with the current upstream
kernel due to changes in VLAN processing.However, for correctness we should still reset the skb->dev pointer
in the GRO reuse function in case a future user does the same thing.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller
28 Jan, 2011
4 commits
-
They are bogus. The basic idea is that I wanted to make sure
that prefixed routes never bind to peers.The test I used was whether RTF_CACHE was set.
But first of all, the RTF_CACHE flag is set at different spots
depending upon which ip6_rt_copy() caller you're talking about.I've validated all of the code paths, and even in the future
where we bind peers more aggressively (for route metric COW'ing)
we never bind to prefix'd routes, only fully specified ones.
This even applies when addrconf or icmp6 routes are allocated.Signed-off-by: David S. Miller
-
pskb_expand_head() triggers a kmemcheck warning when copy of
skb_shared_info is done in pskb_expand_head()This is because destructor_arg field is not necessarily initialized at
this point. Add kmemcheck_annotate_variable() call in __alloc_skb() to
instruct kmemcheck this is a normal situation.Resolves bugzilla.kernel.org 27212
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=27212
Reported-by: Christian Casteyde
Signed-off-by: Eric Dumazet
CC: Andrew Morton
Signed-off-by: David S. Miller -
I'm testing an API that uses IFLA_AF_SPEC attribute.
In the rtnetlink core , the set_link_af() member
of the rtnl_af_ops struct receives the nested attribute
(as I expected), but the validate_link_af() member
receives the parent attribute.
IMO, this patch fixes this.Signed-off-by: Kurt Van Dijck
Signed-off-by: David S. Miller -
net/econet/af_econet.c: In function ‘econet_sendmsg’:
net/econet/af_econet.c:494: warning: label ‘error’ defined but not used
net/econet/af_econet.c:268: warning: unused variable ‘sk’Signed-off-by: Eric Dumazet
Acked-by: Phil Blundell
Signed-off-by: David S. Miller
27 Jan, 2011
1 commit
-
Like ipv4, we have to propagate the ipv6 route peer into
the ipsec top-level route during instantiation.Signed-off-by: David S. Miller