* Re: [PATCH net-next v4] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program
From: David Miller @ 2013-09-23 20:46 UTC (permalink / raw)
To: bluezhudong; +Cc: richardcochran, rob, netdev, linux-doc, linux-kernel
In-Reply-To: <20130917073235.GG23682@zhudong.nay.redhat.com>
From: Dong Zhu <bluezhudong@gmail.com>
Date: Tue, 17 Sep 2013 15:32:35 +0800
> This patch add a method into testptp.c to measure the time offset
> between phc and system clock through the ioctl PTP_SYS_OFFSET.
>
> Signed-off-by: Dong Zhu <bluezhudong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 01/12] tcp.h: Remove extern from function prototypes
From: David Miller @ 2013-09-23 20:45 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel
In-Reply-To: <1379969042.3575.65.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Mon, 23 Sep 2013 13:44:02 -0700
> On Mon, 2013-09-23 at 16:30 -0400, David Miller wrote:
>> Series applied,
>
> How about the same changes for the .h files in drivers/net ?
>
> (slowly of course, and by maintained subsystem)
>
> $ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" drivers/net/ | wc -l
> 1445
>
> Maybe something like groups of:
> $ git grep -E --name-only "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" drivers/net/ | \
> cut -f3- -d"/" | cut -f1,2 -d"/" | uniq | \
> while read file ; do if [ -d drivers/net/$file ] ; then echo $file ; fi ; done
Sure.
^ permalink raw reply
* Re: [PATCH 01/12] tcp.h: Remove extern from function prototypes
From: Joe Perches @ 2013-09-23 20:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20130923.163010.976299939444640897.davem@davemloft.net>
On Mon, 2013-09-23 at 16:30 -0400, David Miller wrote:
> Series applied,
How about the same changes for the .h files in drivers/net ?
(slowly of course, and by maintained subsystem)
$ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" drivers/net/ | wc -l
1445
Maybe something like groups of:
$ git grep -E --name-only "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" drivers/net/ | \
cut -f3- -d"/" | cut -f1,2 -d"/" | uniq | \
while read file ; do if [ -d drivers/net/$file ] ; then echo $file ; fi ; done
can/mscan
can/softing
ethernet/8390
ethernet/adi
ethernet/amd
ethernet/atheros
ethernet/broadcom
ethernet/brocade
ethernet/chelsio
ethernet/cirrus
ethernet/emulex
ethernet/freescale
ethernet/ibm
ethernet/intel
ethernet/mellanox
ethernet/natsemi
ethernet/octeon
ethernet/oki-semi
ethernet/qlogic
ethernet/sfc
ethernet/stmicro
ethernet/ti
ethernet/toshiba
fddi/skfp
wimax/i2400m
wireless/ath
wireless/brcm80211
wireless/ipw2x00
wireless/iwlegacy
wireless/iwlwifi
wireless/mwifiex
wireless/orinoco
wireless/rtlwifi
^ permalink raw reply
* Re: [PATCH -next] openvswitch: remove duplicated include from vport-gre.c
From: Jesse Gross @ 2013-09-23 20:41 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, yongjun_wei, dev@openvswitch.org, netdev
In-Reply-To: <CAPgLHd9a3ShUcYKn9Z4ES=AcAXUmRnHBNMMpni_Ot=zZekc7kw@mail.gmail.com>
On Mon, Sep 23, 2013 at 6:56 AM, Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Also applied.
^ permalink raw reply
* Re: [PATCH -next] openvswitch: remove duplicated include from vport-vxlan.c
From: Jesse Gross @ 2013-09-23 20:41 UTC (permalink / raw)
To: Wei Yongjun
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev,
yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY, David Miller
In-Reply-To: <CAPgLHd_r4p2hYiL9nnwK64vck=f=sbhWrRZr32BdeW14ae63KQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Sep 23, 2013 at 6:55 AM, Wei Yongjun <weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 12/12] sctp: Remove extern from function prototypes
From: Neil Horman @ 2013-09-23 20:39 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, David S. Miller, linux-kernel, Vlad Yasevich, linux-sctp
In-Reply-To: <6738b115d30d40f33c688863f5421d84d2aa706c.1379961014.git.joe@perches.com>
On Mon, Sep 23, 2013 at 11:37:59AM -0700, Joe Perches wrote:
> There are a mix of function prototypes with and without extern
> in the kernel sources. Standardize on not using extern for
> function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler. Its use is as unnecessary as
> using auto to declare automatic/local variables in a block.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> include/net/sctp/sctp.h | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 3794c5a..c5fe806 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -90,12 +90,11 @@
> /*
> * sctp/protocol.c
> */
> -extern int sctp_copy_local_addr_list(struct net *, struct sctp_bind_addr *,
> - sctp_scope_t, gfp_t gfp,
> - int flags);
> -extern struct sctp_pf *sctp_get_pf_specific(sa_family_t family);
> -extern int sctp_register_pf(struct sctp_pf *, sa_family_t);
> -extern void sctp_addr_wq_mgmt(struct net *, struct sctp_sockaddr_entry *, int);
> +int sctp_copy_local_addr_list(struct net *, struct sctp_bind_addr *,
> + sctp_scope_t, gfp_t gfp, int flags);
> +struct sctp_pf *sctp_get_pf_specific(sa_family_t family);
> +int sctp_register_pf(struct sctp_pf *, sa_family_t);
> +void sctp_addr_wq_mgmt(struct net *, struct sctp_sockaddr_entry *, int);
>
> /*
> * sctp/socket.c
> @@ -110,7 +109,7 @@ void sctp_sock_rfree(struct sk_buff *skb);
> void sctp_copy_sock(struct sock *newsk, struct sock *sk,
> struct sctp_association *asoc);
> extern struct percpu_counter sctp_sockets_allocated;
> -extern int sctp_asconf_mgmt(struct sctp_sock *, struct sctp_sockaddr_entry *);
> +int sctp_asconf_mgmt(struct sctp_sock *, struct sctp_sockaddr_entry *);
>
> /*
> * sctp/primitive.c
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] stable_kernel_rules.txt: Exclude networking from stable rules
From: Joe Perches @ 2013-09-23 20:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-doc, netdev, LKML, xfs, stephen, Mikulas Patocka,
Rob Landley, Greg Kroah-Hartman, David Miller
In-Reply-To: <20130922185104.GA7515@infradead.org>
On Sun, 2013-09-22 at 11:51 -0700, Christoph Hellwig wrote:
> This is also the preferred way to do it for XFS. Maybe word it in a way
> that we can easily add subsystems.
>
> To me it generally seems to be the best way to do it - having random Ccs
> and lots of stable trees doesn't seem like a very good way of handling
> it.
Maybe adding a mechanism to MAINTAINERS would be better.
Maybe a default B: (backport?) of stable@vger.kernel.org
with a per-subsystem override?
SUBSYSTEM TYPE
M: maintainer@email.address
L: list@email.address
S: Supported
F: file/pattern/
B: stable@email.address
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [Xen-devel] [PATCH net-next] xen-netfront: convert to GRO API and advertise this feature
From: Anirban Chakraborty @ 2013-09-23 20:32 UTC (permalink / raw)
To: annie li
Cc: Jason Wang, Wei Liu, <netdev@vger.kernel.org>, Ian Campbell,
<xen-devel@lists.xen.org>
In-Reply-To: <523FDE24.5060902@oracle.com>
On Sep 22, 2013, at 11:22 PM, annie li <annie.li@oracle.com> wrote:
>
> On 2013-9-23 13:02, Jason Wang wrote:
>> On 09/23/2013 07:04 AM, Anirban Chakraborty wrote:
>>> On Sep 22, 2013, at 5:09 AM, Wei Liu <wei.liu2@citrix.com> wrote:
>>>
>>>> On Sun, Sep 22, 2013 at 02:29:15PM +0800, Jason Wang wrote:
>>>>> On 09/22/2013 12:05 AM, Wei Liu wrote:
>>>>>> Anirban was seeing netfront received MTU size packets, which downgraded
>>>>>> throughput. The following patch makes netfront use GRO API which
>>>>>> improves throughput for that case.
>>>>>>
>>>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>>>>> Signed-off-by: Anirban Chakraborty <abchak@juniper.net>
>>>>>> Cc: Ian Campbell <ian.campbell@citrix.com>
>>>>> Maybe a dumb question: doesn't Xen depends on the driver of host card to
>>>>> do GRO and pass it to netfront? What the case that netfront can receive
>>>> The would be the ideal situation. Netback pushes large packets to
>>>> netfront and netfront sees large packets.
>>>>
>>>>> a MTU size packet, for a card that does not support GRO in host? Doing
>>>> However Anirban saw the case when backend interface receives large
>>>> packets but netfront sees MTU size packets, so my thought is there is
>>>> certain configuration that leads to this issue. As we cannot tell
>>>> users what to enable and what not to enable so I would like to solve
>>>> this within our driver.
>>>>
>>>>> GRO twice may introduce extra overheads.
>>>>>
>>>> AIUI if the packet that frontend sees is large already then the GRO path
>>>> is quite short which will not introduce heavy penalty, while on the
>>>> other hand if packet is segmented doing GRO improves throughput.
>>>>
>>> Thanks Wei, for explaining and submitting the patch. I would like add following to what you have already mentioned.
>>> In my configuration, I was seeing netback was pushing large packets to the guest (Centos 6.4) but the netfront was receiving MTU sized packets. With this patch on, I do see large packets received on the guest interface. As a result there was substantial throughput improvement in the guest side (2.8 Gbps to 3.8 Gbps). Also, note that the host NIC driver was enabled for GRO already.
>>>
>>> -Anirban
>> In this case, even if you still want to do GRO. It's better to find the
>> root cause of why the GSO packet were segmented
>
> Totally agree, we need to find the cause why large packets is segmented only in different host case.
It appears (from looking at the netback code) that although GSO is turned on at the netback, the guest receives large packet:
1. if it is a local packet (vm to vm on the same host), in which case netfront does a LRO or,
2. via turning on GRO explicitly (with this patch).
-Anirban
^ permalink raw reply
* Re: [PATCH 01/12] tcp.h: Remove extern from function prototypes
From: David Miller @ 2013-09-23 20:30 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel
In-Reply-To: <445209f8885ccd8234fa787c30d63e63fc7917d7.1379961014.git.joe@perches.com>
Series applied, thanks Joe.
^ permalink raw reply
* Re: [PATCH net-next] xen-netfront: convert to GRO API and advertise this feature
From: Anirban Chakraborty @ 2013-09-23 20:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: <netdev@vger.kernel.org>, Wei Liu, Ian Campbell,
<xen-devel@lists.xen.org>
In-Reply-To: <1379915907.3165.5.camel@edumazet-glaptop>
On Sep 22, 2013, at 10:58 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2013-09-22 at 23:09 +0000, Anirban Chakraborty wrote:
>> On Sep 22, 2013, at 7:55 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>> On Sat, 2013-09-21 at 17:05 +0100, Wei Liu wrote:
>>>> Anirban was seeing netfront received MTU size packets, which downgraded
>>>> throughput. The following patch makes netfront use GRO API which
>>>> improves throughput for that case.
>>>
>>>> - netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO;
>>>> + netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO |
>>>> + NETIF_F_GRO;
>>>
>>>
>>> This part is not needed.
>>
>> Shouldn't the flag be set? In dev_gro_receive() we do check if this flag is set or not:
>>
>> if (!(skb->dev->features & NETIF_F_GRO) || netpoll_rx_on(skb))
>> goto normal;
>
> Drivers do not set NETIF_F_GRO themselves, they do not need to.
>
> Look at other drivers which are GRO ready : NETIF_F_GRO is enabled by
> default by core networking stack, in register_netdevice()
>
>
> dev->hw_features |= NETIF_F_SOFT_FEATURES;
> dev->features |= NETIF_F_SOFT_FEATURES;
I didn't realize that the drivers no longer need to set the GRO flag explicitly. It looks like it has been changed since 3.2. I was looking at the kernel version 2.6.32.43 (which corresponds to the dom0 kernel) where the problem is happening.
-Anirban
^ permalink raw reply
* Re: [RESEND PATCH iproute2] vxlan: add ipv6 support
From: Stephen Hemminger @ 2013-09-23 20:20 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller
In-Reply-To: <1379730924-12433-1-git-send-email-amwang@redhat.com>
On Sat, 21 Sep 2013 10:35:24 +0800
Cong Wang <amwang@redhat.com> wrote:
> + if (!inet_pton(AF_INET, *argv, &gaddr)) {
> + if (!inet_pton(AF_INET6, *argv, &gaddr6)) {
> + fprintf(stderr, "Invalid address \"%s\"\n", *argv);
> + return -1;
> + } else if (!IN6_IS_ADDR_MULTICAST(&gaddr6))
> + invarg("invald group address", *argv);
> + } else if (!IN_MULTICAST(ntohl(gaddr)))
> + invarg("invald group address", *argv);
This is ugly, can't it be done more generically by checking for ':' in address.
Or even use getaddrinfo.
Hate to have lots of special code to handle both address types.
^ permalink raw reply
* Re: [PATCH net 0/6] bnx2x: Bug fixes patch series
From: David Miller @ 2013-09-23 20:18 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, ariele, eilong
In-Reply-To: <1379920375-10303-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Mon, 23 Sep 2013 10:12:49 +0300
> This patch contains various bug fixes, half of which are SR-IOV related
> (some fixing issues in the recently added VF RSS support), while the other fix
> a wide assortments of issues in the driver.
>
> Please consider applying these patches to `net'.
Series applied, thanks.
^ permalink raw reply
* Re: Pull request: sfc-next 2013-09-23
From: David Miller @ 2013-09-23 20:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1379962741.2485.58.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 23 Sep 2013 19:59:01 +0100
> The following changes since commit dcb30e659287a6b40dafed1362532da42ec27229:
>
> Merge tag 'arm64-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 (2013-09-20 08:18:51 -0500)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next.git for-davem
>
> for you to fetch changes up to c47b2d9d56832e7ff1a20bd598623de42701a3a3:
>
> sfc: Support ARFS for IPv6 flows (2013-09-20 19:32:00 +0100)
>
> 1. Some cleanup from Fengguang Wu and his kbuild robot.
> 2. Support for ethtool register dump on EF10.
> 3. Change soft-TSO to take advantage of firmware assistance on EF10.
> 4. Support for PIO TX buffers and descriptors on EF10, enabled on
> architectures that support write-combining mappings.
> 5. Accelerated RFS support for TCP/IPv6 and UDP/IPv6 on EF10.
>
> The same changes as in the last request, minus the tracepoints which
> I'll submit separately in a generic form. This branch has also been
> rebased on a more recent net-next (and re-tested).
Pulled, thanks Ben.
^ permalink raw reply
* [PATCH v5] IPv6 NAT: Do not drop DNATed 6to4/6rd packets
From: Catalin(ux) M. BOIE @ 2013-09-23 20:04 UTC (permalink / raw)
To: netdev; +Cc: hannes, yoshfuji, davem, joe
In-Reply-To: <1379963485.3575.53.camel@joe-AO722>
When a router is doing DNAT for 6to4/6rd packets the latest anti-spoofing
patch (218774dc) will drop them because the IPv6 address embedded
does not match the IPv4 destination. This patch will allow them to
pass by testing if we have an address that matches on 6to4/6rd interface.
I have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR.
Also, log the dropped packets (with rate limit).
Signed-off-by: Catalin(ux) M. BOIE <catab@embedromix.ro>
---
include/net/addrconf.h | 4 +++
net/ipv6/addrconf.c | 27 ++++++++++++++++
net/ipv6/sit.c | 84 +++++++++++++++++++++++++++++++++++++++++---------
3 files changed, 100 insertions(+), 15 deletions(-)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index fb314de..86505bf 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -67,6 +67,10 @@ int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
int ipv6_chk_home_addr(struct net *net, const struct in6_addr *addr);
#endif
+bool ipv6_chk_custom_prefix(const struct in6_addr *addr,
+ const unsigned int prefix_len,
+ struct net_device *dev);
+
int ipv6_chk_prefix(const struct in6_addr *addr, struct net_device *dev);
struct inet6_ifaddr *ipv6_get_ifaddr(struct net *net,
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index d6ff126..a0c3abe 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1499,6 +1499,33 @@ static bool ipv6_chk_same_addr(struct net *net, const struct in6_addr *addr,
return false;
}
+/* Compares an address/prefix_len with addresses on device @dev.
+ * If one is found it returns true.
+ */
+bool ipv6_chk_custom_prefix(const struct in6_addr *addr,
+ const unsigned int prefix_len, struct net_device *dev)
+{
+ struct inet6_dev *idev;
+ struct inet6_ifaddr *ifa;
+ bool ret = false;
+
+ rcu_read_lock();
+ idev = __in6_dev_get(dev);
+ if (idev) {
+ read_lock_bh(&idev->lock);
+ list_for_each_entry(ifa, &idev->addr_list, if_list) {
+ ret = ipv6_prefix_equal(addr, &ifa->addr, prefix_len);
+ if (ret)
+ break;
+ }
+ read_unlock_bh(&idev->lock);
+ }
+ rcu_read_unlock();
+
+ return ret;
+}
+EXPORT_SYMBOL(ipv6_chk_custom_prefix);
+
int ipv6_chk_prefix(const struct in6_addr *addr, struct net_device *dev)
{
struct inet6_dev *idev;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 7ee5cb9..afd5605 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -566,6 +566,70 @@ static inline bool is_spoofed_6rd(struct ip_tunnel *tunnel, const __be32 v4addr,
return false;
}
+/* Checks if an address matches an address on the tunnel interface.
+ * Used to detect the NAT of proto 41 packets and let them pass spoofing test.
+ * Long story:
+ * This function is called after we considered the packet as spoofed
+ * in is_spoofed_6rd.
+ * We may have a router that is doing NAT for proto 41 packets
+ * for an internal station. Destination a.a.a.a/PREFIX:bbbb:bbbb
+ * will be translated to n.n.n.n/PREFIX:bbbb:bbbb. And is_spoofed_6rd
+ * function will return true, dropping the packet.
+ * But, we can still check if is spoofed against the IP
+ * addresses associated with the interface.
+ */
+static bool only_dnatted(const struct ip_tunnel *tunnel,
+ const struct in6_addr *v6dst)
+{
+ int prefix_len;
+
+#ifdef CONFIG_IPV6_SIT_6RD
+ prefix_len = tunnel->ip6rd.prefixlen + 32
+ - tunnel->ip6rd.relay_prefixlen;
+#else
+ prefix_len = 48;
+#endif
+ return ipv6_chk_custom_prefix(v6dst, prefix_len, tunnel->dev);
+}
+
+/* Returns true if a packet is spoofed */
+static bool packet_is_spoofed(struct sk_buff *skb,
+ const struct iphdr *iph,
+ struct ip_tunnel *tunnel)
+{
+ const struct ipv6hdr *ipv6h;
+
+ if (tunnel->dev->priv_flags & IFF_ISATAP) {
+ if (!isatap_chksrc(skb, iph, tunnel))
+ return true;
+
+ return false;
+ }
+
+ if (tunnel->dev->flags & IFF_POINTOPOINT)
+ return false;
+
+ ipv6h = ipv6_hdr(skb);
+
+ if (unlikely(is_spoofed_6rd(tunnel, iph->saddr, &ipv6h->saddr))) {
+ net_warn_ratelimited("Src spoofed %pI4/%pI6c -> %pI4/%pI6c\n",
+ &iph->saddr, &ipv6h->saddr,
+ &iph->daddr, &ipv6h->daddr);
+ return true;
+ }
+
+ if (likely(!is_spoofed_6rd(tunnel, iph->daddr, &ipv6h->daddr)))
+ return false;
+
+ if (only_dnatted(tunnel, &ipv6h->daddr))
+ return false;
+
+ net_warn_ratelimited("Dst spoofed %pI4/%pI6c -> %pI4/%pI6c\n",
+ &iph->saddr, &ipv6h->saddr,
+ &iph->daddr, &ipv6h->daddr);
+ return true;
+}
+
static int ipip6_rcv(struct sk_buff *skb)
{
const struct iphdr *iph = ip_hdr(skb);
@@ -586,19 +650,9 @@ static int ipip6_rcv(struct sk_buff *skb)
IPCB(skb)->flags = 0;
skb->protocol = htons(ETH_P_IPV6);
- if (tunnel->dev->priv_flags & IFF_ISATAP) {
- if (!isatap_chksrc(skb, iph, tunnel)) {
- tunnel->dev->stats.rx_errors++;
- goto out;
- }
- } else if (!(tunnel->dev->flags&IFF_POINTOPOINT)) {
- if (is_spoofed_6rd(tunnel, iph->saddr,
- &ipv6_hdr(skb)->saddr) ||
- is_spoofed_6rd(tunnel, iph->daddr,
- &ipv6_hdr(skb)->daddr)) {
- tunnel->dev->stats.rx_errors++;
- goto out;
- }
+ if (packet_is_spoofed(skb, iph, tunnel)) {
+ tunnel->dev->stats.rx_errors++;
+ goto out;
}
__skb_tunnel_rx(skb, tunnel->dev, tunnel->net);
@@ -748,7 +802,7 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
neigh = dst_neigh_lookup(skb_dst(skb), &iph6->daddr);
if (neigh == NULL) {
- net_dbg_ratelimited("sit: nexthop == NULL\n");
+ net_dbg_ratelimited("nexthop == NULL\n");
goto tx_error;
}
@@ -777,7 +831,7 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
neigh = dst_neigh_lookup(skb_dst(skb), &iph6->daddr);
if (neigh == NULL) {
- net_dbg_ratelimited("sit: nexthop == NULL\n");
+ net_dbg_ratelimited("nexthop == NULL\n");
goto tx_error;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2.39 7/7] datapath: Add basic MPLS support to kernel
From: Pravin Shelar @ 2013-09-23 19:47 UTC (permalink / raw)
To: Simon Horman
Cc: Jesse Gross, dev@openvswitch.org, netdev, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <20130922053800.GA4890@verge.net.au>
On Sat, Sep 21, 2013 at 10:38 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Sep 19, 2013 at 12:31:51PM -0500, Jesse Gross wrote:
>> On Wed, Sep 18, 2013 at 5:07 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, Sep 17, 2013 at 11:38:18AM -0700, Pravin Shelar wrote:
>> >> On Mon, Sep 9, 2013 at 12:20 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> > diff --git a/datapath/datapath.h b/datapath/datapath.h
>> >> > index 5d50dd4..babae3b 100644
>> >> > --- a/datapath/datapath.h
>> >> > +++ b/datapath/datapath.h
>> >> > @@ -36,6 +36,10 @@
>> >> >
>> >> > #define SAMPLE_ACTION_DEPTH 3
>> >> >
>> >> > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,11,0)
>> >> > +#define HAVE_INNER_PROTOCOL
>> >> > +#endif
>> >> > +
>> >> > /**
>> >> > * struct dp_stats_percpu - per-cpu packet processing statistics for a given
>> >> > * datapath.
>> >> > @@ -93,11 +97,16 @@ struct datapath {
>> >> > * @pkt_key: The flow information extracted from the packet. Must be nonnull.
>> >> > * @tun_key: Key for the tunnel that encapsulated this packet. NULL if the
>> >> > * packet is not being tunneled.
>> >> > + * @inner_protocol: Provides a substitute for the skb->inner_protocol field on
>> >> > + * kernels before 3.11.
>> >> > */
>> >> > struct ovs_skb_cb {
>> >> > struct sw_flow *flow;
>> >> > struct sw_flow_key *pkt_key;
>> >> > struct ovs_key_ipv4_tunnel *tun_key;
>> >> > +#ifndef HAVE_INNER_PROTOCOL
>> >> > + __be16 inner_protocol;
>> >> > +#endif
>> >> > };
>> >> > #define OVS_CB(skb) ((struct ovs_skb_cb *)(skb)->cb)
>> >> >
>> >> Can you move this to compat struct ovs_gso_cb {}
>> >
>> > I think that you are correct and inner_protocol needs
>> > to be in struct ovs_gso_cb so that it can
>> > be accessed via skb_network_protocol() from
>> > rpl___skb_gso_segment().
>> >
>> > However I think it may also need to be present in struct ovs_cb
>> > so that it can be set correctly.
>> >
>> > Currently it is set unconditionally
>> > in ovs_execute_actions() and Jesse has suggested setting
>> > it conditionally in pop_mpls() (which is called by do_execute_actions()).
>> > But regardless it seems to me that the field would need to be available
>> > in struct ovs_cb.
>>
>> Since the helper functions are also in the compat code, I think they
>> should have access to ovs_gso_cb.
>
> Pravin also believes that is the case so I have moved inner_protocol
> to struct ovs_gso_cb as he requested.
>
>> >> I think we can simplify code by pushing vlan and then segmenting skb,
>> >> the way we do it for MPLS.
>> >
>> > Are you thinking of something like the following which applies
>> > prior to the MPLS code.
>>
>> This is basically what I was thinking about. We might actually be able
>> to move all of this to compat code by having a replacement for
>> dev_queue_xmit() similar to what we have for ip_local_out() in the
>> tunnel code.
>
> I would appreciate Pravin's opinion on this but it seems to me
> that it should be possible.
>
> The following applies on top of my previous proposed change
> in this thread - simplification of segmentation - and before
> the MPLS patch-set. Is this along the lines of what you were
> thinking of?
>
>
> From: Simon Horman <horms@verge.net.au>
>
> datapath: Move segmentation compatibility code into a compatibility function
>
> *** Do not apply: for informational purposes only
>
> Move segmentation compatibility code out of netdev_send and into
> rpl_dev_queue_xmit(), a compatibility function used in place
> of dev_queue_xmit() as necessary.
>
> As suggested by Jesse Gross.
>
> Some minor though verbose implementation notes:
>
> * This rpl_dev_queue_xmit() endeavours to return a valid error code or
> zero on success as per dev_queue_xmit(). The exception is that when
> dev_queue_xmit() is called in a loop only the status of the last call is
> taken into account, thus ignoring any errors returned by previous calls.
> This is derived from the previous calls to dev_queue_xmit() in a loop
> where netdev_send() ignores the return value of dev_queue_xmit()
> entirely.
>
> * netdev_send() continues to ignore the value of dev_queue_xmit().
> So the discussion of the return value of rpl_dev_queue_xmit()
> above is has no bearing on run-time behaviour.
>
> * The return value of netdev_send() may differ from the previous
> implementation in the case where segmentation is performed before
> calling the real dev_queue_xmit(). This is because previously in
> this case netdev_send() would return the combined length of the
> skbs resulting from segmentation. Whereas the current code
> always returns the length of the original skb.
This approach looks good to me.
>
> Compile tested only.
>
This patch does not work since vport-netdev does not include compat
gso header. after including gso.h it gives me compiler error.
Can you post combined patch with fixes?
It is better to move rpl_dev_queue_xmit definition from gso.h to
linux/netdevice.h.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] xfrm: Simplify SA looking up when using wildcard source address
From: Sergei Shtylyov @ 2013-09-23 19:46 UTC (permalink / raw)
To: Fan Du; +Cc: steffen.klassert, davem, netdev
In-Reply-To: <1379927917-17365-1-git-send-email-fan.du@windriver.com>
Hello.
On 09/23/2013 01:18 PM, Fan Du wrote:
> I'm not quite sure I get this "wildcard source address" right,
> IMHO if a host needs to protect every traffic for a given remote host,
> then the source address is wildcard address, i.e. all ZEROs.
> (Please correct me if I'm bloodly wrong。。。)
> Here is the argument if above statement stands true:
> __xfrm4/6_state_addr_check is a four steps check, all we need to do
> is checking whether the destination address match. Passing saddr from
> flow is worst option, as the checking needs to reach the fourth step.
> So, simply this process by only checking destination address only when
> using wildcard source address for looking up SAs.
> Signed-off-by: Fan Du <fan.du@windriver.com>
> ---
> include/net/xfrm.h | 31 +++++++++++++++++++++++++++++++
> net/xfrm/xfrm_state.c | 2 +-
> 2 files changed, 32 insertions(+), 1 deletion(-)
> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> index e253bf0..fdb9343 100644
> --- a/include/net/xfrm.h
> +++ b/include/net/xfrm.h
> @@ -1282,6 +1282,37 @@ xfrm_state_addr_check(const struct xfrm_state *x,
> }
>
> static __inline__ int
> +__xfrm4_state_daddr_check(const struct xfrm_state *x,
> + const xfrm_address_t *daddr)
> +{
> + return ((daddr->a4 == x->id.daddr.a4) ? 1 : 0);
() not needed around the *return* expression, and ?: not needed too.
WBR, Sergei
^ permalink raw reply
* Question on Netlink IPv6 routing table lookup
From: Fernando Gont @ 2013-09-23 19:41 UTC (permalink / raw)
To: netdev
Folks,
I'm performing IPv6 routing table lookups with a netlink socket, and it
seems that specifying the Source Address with the RTA_SRC element does
not have any effect on the result of the look-up.
In my network setup, I have two interfaces, as follows:
NET1 (fc00:1::/64) <------> MY_NODE <------> NET2 (fc00:2::/64)
For simplicity sake, let's say that my nodes' address on NET1 is
fc00:1::1, and my node's address on NET2 is fc00:2::1. And my node has
two default routes (one in NET1, and another in NET2).
I'd expect that if I set RTA_SRC to fc00:1::1, the default route on NET1
is selected, but if I set RTA_SRC to fc00:2::1, it is the default route
on NET2 that is selected.
However, the result of the routing tale look-up is always the same,
regardless of RTA_SRC.
I looked at /proc/net/ipv6_route, and it seems that, for all routes, the
"source network" is always set to :: (all zeroes), thus probably
explaining the above behavior.
Is there any way to influence the routing-table look-up based on the
IPv6 source address?
If that's not (currently) possible, should I expect RTA_SRC to work as
described above at some point in the future?
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply
* Re: [PATCH] ipvs: improved SH fallback strategy
From: Sergei Shtylyov @ 2013-09-23 19:42 UTC (permalink / raw)
To: Alexander Frolkin
Cc: Julian Anastasov, lvs-devel, Wensong Zhang, Simon Horman, netdev,
linux-kernel
In-Reply-To: <20130923115139.GA15034@eldamar.org.uk>
Hello.
On 09/23/2013 03:51 PM, Alexander Frolkin wrote:
> Improve the SH fallback realserver selection strategy.
> With sh and sh-fallback, if a realserver is down, this attempts to
> distribute the traffic that would have gone to that server evenly
> among the remaining servers.
> Signed-off-by: Alexander Frolkin <avf@eldamar.org.uk>
> ---
> diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
> index f16c027..1676354 100644
> --- a/net/netfilter/ipvs/ip_vs_sh.c
> +++ b/net/netfilter/ipvs/ip_vs_sh.c
> @@ -120,22 +120,35 @@ static inline struct ip_vs_dest *
> ip_vs_sh_get_fallback(struct ip_vs_service *svc, struct ip_vs_sh_state *s,
> const union nf_inet_addr *addr, __be16 port)
> {
> - unsigned int offset;
> - unsigned int hash;
> + unsigned int offset, roffset;
> + unsigned int hash, ihash;
> struct ip_vs_dest *dest;
>
> - for (offset = 0; offset < IP_VS_SH_TAB_SIZE; offset++) {
> - hash = ip_vs_sh_hashkey(svc->af, addr, port, offset);
> - dest = rcu_dereference(s->buckets[hash].dest);
> - if (!dest)
> - break;
> - if (is_unavailable(dest))
> - IP_VS_DBG_BUF(6, "SH: selected unavailable server "
> - "%s:%d (offset %d)",
> + ihash = ip_vs_sh_hashkey(svc->af, addr, port, 0);
> + dest = rcu_dereference(s->buckets[ihash].dest);
> +
Empty line net needed here (and it wasn't there in the original code).
> + if (!dest)
> + return NULL;
> +
Here too.
> + if (is_unavailable(dest)) {
> + IP_VS_DBG_BUF(6, "SH: selected unavailable server "
> + "%s:%d, reselecting",
> + IP_VS_DBG_ADDR(svc->af, &dest->addr),
> + ntohs(dest->port));
> + for (offset = 0; offset < IP_VS_SH_TAB_SIZE; offset++) {
> + roffset = (offset + ihash) % IP_VS_SH_TAB_SIZE;
> + hash = ip_vs_sh_hashkey(svc->af, addr, port, roffset);
> + dest = rcu_dereference(s->buckets[hash].dest);
> + if (is_unavailable(dest))
> + IP_VS_DBG_BUF(6, "SH: selected unavailable "
> + "server %s:%d (offset %d), reselecting",
> IP_VS_DBG_ADDR(svc->af, &dest->addr),
WBR, Sergei
^ permalink raw reply
* RE: [PATCH 11/19] wireless: Change variable type to bool
From: Bing Zhao @ 2013-09-23 19:40 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <1379802471-30252-11-git-send-email-peter.senna@gmail.com>
Hi Peter,
Thanks for your patch.
> The variables cancel_scan_cmd, enable_data, hs_activate and valid are
> only assigned the values true and false. Change its type to bool.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @exists@
> type T;
> identifier b;
> @@
> - T
> + bool
> b = ...;
> ... when any
> b = \(true\|false\)
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/cmdevt.c | 2 +-
> drivers/net/wireless/mwifiex/join.c | 2 +-
> drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
> drivers/net/wireless/mwifiex/wmm.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* RE: missing kfree_skb(skb) in ipv6_frag_rcv()?
From: Templin, Fred L @ 2013-09-23 19:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1379961431.3165.25.camel@edumazet-glaptop>
Hi Eric,
Thanks for the correction - I think I lost track of the code I
should have been looking at.
Fred
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Monday, September 23, 2013 11:37 AM
> To: Templin, Fred L
> Cc: netdev@vger.kernel.org
> Subject: Re: missing kfree_skb(skb) in ipv6_frag_rcv()?
>
> On Mon, 2013-09-23 at 17:42 +0000, Templin, Fred L wrote:
> > Hello,
> >
> > In the most recent kernel releases, in ./net/ipv6/reassembly.c,
> > I see the following code at the end of "ipv6_frag_rcv()":
> >
> > + IP6_INC_STATS_BH(net, ip6_dst_idev(skb_dst(skb)),
> IPSTATS_MIB_REASMFAILS);
> > + kfree_skb(skb);
> > + return -1;
> > +
> > +fail_hdr:
> > + IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
> IPSTATS_MIB_INHDRERRORS);
> > + icmpv6_param_prob(skb, ICMPV6_HDR_FIELD,
> skb_network_header_len(skb));
> > + return -1;
> > +}
> >
> > Perhaps I missed it, but I did not find anywhere that
> 'icmpv6_param_prob()'
> > frees the skb, and hence it appears that there is a missing
> kfree_skb()
> > in the above code. Is this a bug?
>
> void icmpv6_param_prob(struct sk_buff *skb, u8 code, int pos)
> {
> icmp6_send(skb, ICMPV6_PARAMPROB, code, pos);
> kfree_skb(skb);
> }
>
> Well, I do see kfree_skb(skb) here.
>
^ permalink raw reply
* Re: [PATCH net-next] dev: advertise rx_flags changes
From: Stephen Hemminger @ 2013-09-23 19:27 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem
In-Reply-To: <1379946334-4183-1-git-send-email-nicolas.dichtel@6wind.com>
On Mon, 23 Sep 2013 16:25:34 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> There is no netlink message/call to notifier chains when rx_flags are updated,
> let's advertise everybody.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> net/core/dev.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 5c713f2239cc..6c91d3919279 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4818,8 +4818,13 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
> {
> const struct net_device_ops *ops = dev->netdev_ops;
>
> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
> - ops->ndo_change_rx_flags(dev, flags);
> + if (dev->flags & IFF_UP) {
> + if (ops->ndo_change_rx_flags)
> + ops->ndo_change_rx_flags(dev, flags);
> +
> + call_netdevice_notifiers(NETDEV_CHANGE, dev);
> + rtmsg_ifinfo(RTM_NEWLINK, dev, flags);
> + }
> }
>
> static int __dev_set_promiscuity(struct net_device *dev, int inc)
This will cause duplicate notification if IFF_MULTICAST changes:
1. dev_change_flags
__dev_change_flags
dev_change_rx_flags
call_netdevice_notifiers...
2. dev_change_flags
__dev_notify_flags
call_netdevice_notifiers...
^ permalink raw reply
* Re: iproute2 and libnl3?
From: Stephen Hemminger @ 2013-09-23 19:19 UTC (permalink / raw)
To: Arvid Brodin; +Cc: netdev
In-Reply-To: <1902752B0C92F943AB7EA9EE13E2DEEC1272C74D80@HQ1-EXCH02.corp.brocade.com>
On Mon, 23 Sep 2013 11:17:40 -0700
Arvid Brodin <arvid.brodin@xdin.com> wrote:
> Hi Stephen (and others),
>
> I'm trying to move the functionality from a small user space tool I wrote for
> listening to HSR Netlink messages into iproute2. The tool uses generic netlink
> through libnl3.
>
> It seems iproute2 uses libnl-1 though:
>
> iphsr.c:325:6: warning: 'struct nl_sock' declared inside parameter list
> iphsr.c:334:30: error: 'NL_AUTO_PORT' undeclared (first use in this function)
> iphsr.c:341:2: warning: implicit declaration of function 'nl_send_auto'
> iphsr.c:417:2: warning: implicit declaration of function 'genl_ctrl_resolve_grp'
> iphsr.c:424:2: warning: implicit declaration of function 'nl_socket_add_memberships'
> iphsr.c:455:2: warning: implicit declaration of function 'nl_socket_alloc'
> iphsr.c:463:2: warning: implicit declaration of function 'nl_socket_disable_seq_check'
>
> Are there alternatives to the above functionality in libnl-1, or do I need to
> implement it myself (copy them from the libnl3 code perhaps)?
>
>
Upstream version of iproute does not use libnl.
Any patches to use libnl are rejected. iproute2 has its own internal libnetlink library.
^ permalink raw reply
* Re: [PATCH 12/12] sctp: Remove extern from function prototypes
From: Vlad Yasevich @ 2013-09-23 19:11 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, David S. Miller, linux-kernel, Neil Horman, linux-sctp
In-Reply-To: <6738b115d30d40f33c688863f5421d84d2aa706c.1379961014.git.joe@perches.com>
On 09/23/2013 02:37 PM, Joe Perches wrote:
> There are a mix of function prototypes with and without extern
> in the kernel sources. Standardize on not using extern for
> function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler. Its use is as unnecessary as
> using auto to declare automatic/local variables in a block.
>
> Signed-off-by: Joe Perches <joe@perches.com>
looks simple enough.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> include/net/sctp/sctp.h | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 3794c5a..c5fe806 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -90,12 +90,11 @@
> /*
> * sctp/protocol.c
> */
> -extern int sctp_copy_local_addr_list(struct net *, struct sctp_bind_addr *,
> - sctp_scope_t, gfp_t gfp,
> - int flags);
> -extern struct sctp_pf *sctp_get_pf_specific(sa_family_t family);
> -extern int sctp_register_pf(struct sctp_pf *, sa_family_t);
> -extern void sctp_addr_wq_mgmt(struct net *, struct sctp_sockaddr_entry *, int);
> +int sctp_copy_local_addr_list(struct net *, struct sctp_bind_addr *,
> + sctp_scope_t, gfp_t gfp, int flags);
> +struct sctp_pf *sctp_get_pf_specific(sa_family_t family);
> +int sctp_register_pf(struct sctp_pf *, sa_family_t);
> +void sctp_addr_wq_mgmt(struct net *, struct sctp_sockaddr_entry *, int);
>
> /*
> * sctp/socket.c
> @@ -110,7 +109,7 @@ void sctp_sock_rfree(struct sk_buff *skb);
> void sctp_copy_sock(struct sock *newsk, struct sock *sk,
> struct sctp_association *asoc);
> extern struct percpu_counter sctp_sockets_allocated;
> -extern int sctp_asconf_mgmt(struct sctp_sock *, struct sctp_sockaddr_entry *);
> +int sctp_asconf_mgmt(struct sctp_sock *, struct sctp_sockaddr_entry *);
>
> /*
> * sctp/primitive.c
>
^ permalink raw reply
* Re: [PATCH] Do not drop DNATed 6to4/6rd packets (v4)
From: Joe Perches @ 2013-09-23 19:11 UTC (permalink / raw)
To: Catalin(ux) M. BOIE; +Cc: netdev, hannes, yoshfuji, davem
In-Reply-To: <1379961413-21005-1-git-send-email-catab@embedromix.ro>
On Mon, 2013-09-23 at 21:36 +0300, Catalin(ux) M. BOIE wrote:
> From: "Catalin(ux) M. BOIE" <catab@embedromix.ro>
>
> When a router is doing DNAT for 6to4/6rd packets the latest anti-spoofing
> patch (218774dc) will drop them because the IPv6 address embedded
> does not match the IPv4 destination. This patch will allow them to
> pass by testing if we have an address that matches on 6to4/6rd interface.
> I have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR.
> Also, log the dropped packets (with rate limit).
A few more trivialities:
When you send revisions to patches, please put the
revision number inside the brackets like:
[PATCH V4] subject
Also, use a prefix for the patch like:
[PATCH V4] IPv6 NAT: Don't drop DNAT 6to4 or 6RD packets
> diff --git a/include/net/addrconf.h b/include/net/addrconf.h
[]
> @@ -67,6 +67,10 @@ int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
> int ipv6_chk_home_addr(struct net *net, const struct in6_addr *addr);
> #endif
>
> +extern bool ipv6_chk_custom_prefix(const struct in6_addr *addr,
> + const unsigned int prefix_len,
> + struct net_device *dev);
> +
extern isn't required.
> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
[]
> @@ -566,6 +566,70 @@ static inline bool is_spoofed_6rd(struct ip_tunnel *tunnel, const __be32 v4addr,
[]
> +/* Returns true if a packet is spoofed */
> +static bool packet_is_spoofed(struct sk_buff *skb,
> + const struct iphdr *iph,
> + struct ip_tunnel *tunnel)
> +{
[]
> + if ((tunnel->dev->flags & IFF_POINTOPOINT))
> + return false;
One too many parentheses
if (tunnel->dev->flags & IFF_POINTTOPOINT)
return false;
^ permalink raw reply
* Re: iSCSI support in Linux
From: Ben Hutchings @ 2013-09-23 19:04 UTC (permalink / raw)
To: Rayagond K; +Cc: netdev
In-Reply-To: <CAJ3bTp4SRmg78iU-NNF9WtxBdpXc08T+C+j5zPuEVcaxX-H-kA@mail.gmail.com>
On Mon, 2013-09-23 at 16:24 +0530, Rayagond K wrote:
> Hi All,
>
> I am checking iSCSI support in Linux, during the search over internet
> I got to know that iSCSI standard is implemented in Linux with kernel
> version 2.6.20 and later. But I didn't understand one thing clearly
> that is there any NIC offloading features related iSCSI ? if so, is
> there any support in Linux for such offloading features ? Any example
> NIC driver in LXR with iSCSI implementation ?
iSCSI drivers are under drivers/scsi not drivers/net.
There's no support for partial offload of iSCSI, beyond TCP offload
features.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox