* [PATCH net-next] net: fix build errors if ipv6 is disabled
From: Eric Dumazet @ 2013-10-09 5:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
CONFIG_IPV6=n is still a valid choice ;)
It appears we can remove dead code.
Reported-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/ip6_checksum.h | 2 ++
net/ipv4/ping.c | 8 +++++---
net/ipv4/tcp_metrics.c | 4 ++++
net/sunrpc/svcsock.c | 2 ++
security/lsm_audit.c | 2 ++
5 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/include/net/ip6_checksum.h b/include/net/ip6_checksum.h
index 1944406..9e3c540 100644
--- a/include/net/ip6_checksum.h
+++ b/include/net/ip6_checksum.h
@@ -66,12 +66,14 @@ static inline void __tcp_v6_send_check(struct sk_buff *skb,
}
}
+#if IS_ENABLED(CONFIG_IPV6)
static inline void tcp_v6_send_check(struct sock *sk, struct sk_buff *skb)
{
struct ipv6_pinfo *np = inet6_sk(sk);
__tcp_v6_send_check(skb, &np->saddr, &sk->sk_v6_daddr);
}
+#endif
int udp6_csum_init(struct sk_buff *skb, struct udphdr *uh, int proto);
#endif
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index ccefc07..a10988a 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -415,10 +415,12 @@ int ping_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
(int)sk->sk_bound_dev_if);
err = 0;
- if ((sk->sk_family == AF_INET && isk->inet_rcv_saddr) ||
- (sk->sk_family == AF_INET6 &&
- !ipv6_addr_any(&sk->sk_v6_rcv_saddr)))
+ if (sk->sk_family == AF_INET && isk->inet_rcv_saddr)
sk->sk_userlocks |= SOCK_BINDADDR_LOCK;
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == AF_INET6 && !ipv6_addr_any(&sk->sk_v6_rcv_saddr)
+ sk->sk_userlocks |= SOCK_BINDADDR_LOCK;
+#endif
if (snum)
sk->sk_userlocks |= SOCK_BINDPORT_LOCK;
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 27535fd..8fcc2cb 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -251,10 +251,12 @@ static struct tcp_metrics_block *__tcp_get_metrics_tw(struct inet_timewait_sock
addr.addr.a4 = tw->tw_daddr;
hash = (__force unsigned int) addr.addr.a4;
break;
+#if IS_ENABLED(CONFIG_IPV6)
case AF_INET6:
*(struct in6_addr *)addr.addr.a6 = tw->tw_v6_daddr;
hash = ipv6_addr_hash(&tw->tw_v6_daddr);
break;
+#endif
default:
return NULL;
}
@@ -286,10 +288,12 @@ static struct tcp_metrics_block *tcp_get_metrics(struct sock *sk,
addr.addr.a4 = inet_sk(sk)->inet_daddr;
hash = (__force unsigned int) addr.addr.a4;
break;
+#if IS_ENABLED(CONFIG_IPV6)
case AF_INET6:
*(struct in6_addr *)addr.addr.a6 = sk->sk_v6_daddr;
hash = ipv6_addr_hash(&sk->sk_v6_daddr);
break;
+#endif
default:
return NULL;
}
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 0045c7c..b6e59f0 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -291,12 +291,14 @@ static int svc_one_sock_name(struct svc_sock *svsk, char *buf, int remaining)
&inet_sk(sk)->inet_rcv_saddr,
inet_sk(sk)->inet_num);
break;
+#if IS_ENABLED(CONFIG_IPV6)
case PF_INET6:
len = snprintf(buf, remaining, "ipv6 %s %pI6 %d\n",
proto_name,
&sk->sk_v6_rcv_saddr,
inet_sk(sk)->inet_num);
break;
+#endif
default:
len = snprintf(buf, remaining, "*unknown-%d*\n",
sk->sk_family);
diff --git a/security/lsm_audit.c b/security/lsm_audit.c
index 80554fc..234bc2a 100644
--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c
@@ -302,6 +302,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
"faddr", "fport");
break;
}
+#if IS_ENABLED(CONFIG_IPV6)
case AF_INET6: {
struct inet_sock *inet = inet_sk(sk);
@@ -313,6 +314,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
"faddr", "fport");
break;
}
+#endif
case AF_UNIX:
u = unix_sk(sk);
if (u->path.dentry) {
^ permalink raw reply related
* [PATCH net-next] udp: fix a typo in __udp4_lib_mcast_demux_lookup
From: Eric Dumazet @ 2013-10-09 4:47 UTC (permalink / raw)
To: David Miller; +Cc: shawn.bohrer, netdev, tomk, sbohrer
In-Reply-To: <20131008.165147.1204109363656237950.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
At this point sk might contain garbage.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 4226c53..9f27bb8 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1847,7 +1847,7 @@ begin:
if (count != 1 ||
unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
result = NULL;
- else if (unlikely(!__udp_is_mcast_sock(net, sk,
+ else if (unlikely(!__udp_is_mcast_sock(net, result,
loc_port, loc_addr,
rmt_port, rmt_addr,
dif, hnum))) {
^ permalink raw reply related
* Re: [Xen-devel] [PATCH net-next v2 5/5] xen-netback: enable IPv6 TCP GSO to the guest
From: annie li @ 2013-10-09 4:41 UTC (permalink / raw)
To: Paul Durrant; +Cc: xen-devel, netdev, Wei Liu, David Vrabel, Ian Campbell
In-Reply-To: <1381229896-18657-6-git-send-email-paul.durrant@citrix.com>
On 2013-10-8 18:58, Paul Durrant wrote:
> This patch adds code to handle SKB_GSO_TCPV6 skbs and construct appropriate
> extra or prefix segments to pass the large packet to the frontend. New
> xenstore flags, feature-gso-tcpv6 and feature-gso-tcpv6-prefix, are sampled
> to determine if the frontend is capable of handling such packets.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> ---
> drivers/net/xen-netback/common.h | 6 +++--
> drivers/net/xen-netback/interface.c | 8 ++++--
> drivers/net/xen-netback/netback.c | 47 +++++++++++++++++++++++++++--------
> drivers/net/xen-netback/xenbus.c | 29 +++++++++++++++++++--
> 4 files changed, 74 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index b4a9a3c..720b1ca 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -87,6 +87,7 @@ struct pending_tx_info {
> struct xenvif_rx_meta {
> int id;
> int size;
> + int gso_type;
> int gso_size;
> };
>
> @@ -150,9 +151,10 @@ struct xenvif {
> u8 fe_dev_addr[6];
>
> /* Frontend feature information. */
> + int gso_mask;
> + int gso_prefix_mask;
I assume it is a flag instead of mask here, right? If it is mask, then 1
means disabling the gso.
> +
> u8 can_sg:1;
> - u8 gso:1;
> - u8 gso_prefix:1;
> u8 ip_csum:1;
> u8 ipv6_csum:1;
>
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index cb0d8ea..3d11387 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -214,8 +214,12 @@ static netdev_features_t xenvif_fix_features(struct net_device *dev,
>
> if (!vif->can_sg)
> features &= ~NETIF_F_SG;
> - if (!vif->gso && !vif->gso_prefix)
> + if (~(vif->gso_mask | vif->gso_prefix_mask) &
> + (1 << XEN_NETIF_GSO_TYPE_TCPV4))
Is it better to use XEN_NETIF_GSO_TYPE_TCPV4 directly and setting
gso_mask(gso_prefix_mask) with "|= XEN_NETIF_GSO_TYPE_TCPV4" or "|=
XEN_NETIF_GSO_TYPE_TCPV6" instead of "1 <<"?
> features &= ~NETIF_F_TSO;
> + if (~(vif->gso_mask | vif->gso_prefix_mask) &
> + (1 << XEN_NETIF_GSO_TYPE_TCPV6))
Same as above.
> + features &= ~NETIF_F_TSO6;
> if (!vif->ip_csum)
> features &= ~NETIF_F_IP_CSUM;
> if (!vif->ipv6_csum)
> @@ -320,7 +324,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> dev->netdev_ops = &xenvif_netdev_ops;
> dev->hw_features = NETIF_F_SG |
> NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> - NETIF_F_TSO;
> + NETIF_F_TSO | NETIF_F_TSO6;
> dev->features = dev->hw_features | NETIF_F_RXCSUM;
> SET_ETHTOOL_OPS(dev, &xenvif_ethtool_ops);
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index ac42f73..ee0d55c 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -140,7 +140,7 @@ static int max_required_rx_slots(struct xenvif *vif)
> int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
>
> /* XXX FIXME: RX path dependent on MAX_SKB_FRAGS */
> - if (vif->can_sg || vif->gso || vif->gso_prefix)
> + if (vif->can_sg || vif->gso_mask || vif->gso_prefix_mask)
> max += MAX_SKB_FRAGS + 1; /* extra_info + frags */
>
> return max;
> @@ -334,6 +334,7 @@ static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> struct gnttab_copy *copy_gop;
> struct xenvif_rx_meta *meta;
> unsigned long bytes;
> + int gso_type;
>
> /* Data must not cross a page boundary. */
> BUG_ON(size + offset > PAGE_SIZE<<compound_order(page));
> @@ -392,7 +393,14 @@ static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> }
>
> /* Leave a gap for the GSO descriptor. */
> - if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
> + if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4)
> + gso_type = XEN_NETIF_GSO_TYPE_TCPV4;
> + else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
> + gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
> + else
> + gso_type = 0;
> +
> + if (*head && ((1 << gso_type) & vif->gso_prefix_mask))
Same
> vif->rx.req_cons++;
>
> *head = 0; /* There must be something in this buffer now. */
> @@ -423,14 +431,28 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> unsigned char *data;
> int head = 1;
> int old_meta_prod;
> + int gso_type;
> + int gso_size;
>
> old_meta_prod = npo->meta_prod;
>
> + if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4) {
> + gso_type = XEN_NETIF_GSO_TYPE_TCPV4;
> + gso_size = skb_shinfo(skb)->gso_size;
> + } else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6) {
> + gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
> + gso_size = skb_shinfo(skb)->gso_size;
> + } else {
> + gso_type = 0;
> + gso_size = 0;
> + }
> +
> /* Set up a GSO prefix descriptor, if necessary */
> - if (skb_shinfo(skb)->gso_size && vif->gso_prefix) {
> + if ((1 << gso_type) & vif->gso_prefix_mask) {
Same
> req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
> meta = npo->meta + npo->meta_prod++;
> - meta->gso_size = skb_shinfo(skb)->gso_size;
> + meta->gso_type = gso_type;
> + meta->gso_size = gso_size;
> meta->size = 0;
> meta->id = req->id;
> }
> @@ -438,10 +460,13 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
> meta = npo->meta + npo->meta_prod++;
>
> - if (!vif->gso_prefix)
> - meta->gso_size = skb_shinfo(skb)->gso_size;
> - else
> + if ((1 << gso_type) & vif->gso_mask) {
Same
> + meta->gso_type = gso_type;
> + meta->gso_size = gso_size;
> + } else {
> + meta->gso_type = 0;
> meta->gso_size = 0;
> + }
>
> meta->size = 0;
> meta->id = req->id;
> @@ -587,7 +612,8 @@ void xenvif_rx_action(struct xenvif *vif)
>
> vif = netdev_priv(skb->dev);
>
> - if (vif->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
> + if ((1 << vif->meta[npo.meta_cons].gso_type) &
> + vif->gso_prefix_mask) {
> resp = RING_GET_RESPONSE(&vif->rx,
> vif->rx.rsp_prod_pvt++);
>
> @@ -624,7 +650,8 @@ void xenvif_rx_action(struct xenvif *vif)
> vif->meta[npo.meta_cons].size,
> flags);
>
> - if (vif->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
> + if ((1 << vif->meta[npo.meta_cons].gso_type) &
Same
> + vif->gso_mask) {
> struct xen_netif_extra_info *gso =
> (struct xen_netif_extra_info *)
> RING_GET_RESPONSE(&vif->rx,
> @@ -632,8 +659,8 @@ void xenvif_rx_action(struct xenvif *vif)
>
> resp->flags |= XEN_NETRXF_extra_info;
>
> + gso->u.gso.type = vif->meta[npo.meta_cons].gso_type;
> gso->u.gso.size = vif->meta[npo.meta_cons].gso_size;
> - gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
> gso->u.gso.pad = 0;
> gso->u.gso.features = 0;
>
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 389fa72..4894256 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -573,15 +573,40 @@ static int connect_rings(struct backend_info *be)
> val = 0;
> vif->can_sg = !!val;
>
> + vif->gso_mask = 0;
> + vif->gso_prefix_mask = 0;
> +
> if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4",
> "%d", &val) < 0)
> val = 0;
> - vif->gso = !!val;
> + if (val)
> + vif->gso_mask = 1 << XEN_NETIF_GSO_TYPE_TCPV4;
Same: |= XEN_NETIF_GSO_TYPE_TCPV4;
>
> if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4-prefix",
> "%d", &val) < 0)
> val = 0;
> - vif->gso_prefix = !!val;
> + if (val)
> + vif->gso_prefix_mask = 1 << XEN_NETIF_GSO_TYPE_TCPV4;
Same as above.
Thanks
Annie
^ permalink raw reply
* Re: [PATCH] net: sh_eth: Fix RX packets errors on R8A7740
From: Simon Horman @ 2013-10-09 4:28 UTC (permalink / raw)
To: Nguyen Hong Ky; +Cc: David S. Miller, netdev, Ryusuke Sakato, Sergei Shtylyov
In-Reply-To: <1381127365-6521-2-git-send-email-nh-ky@jinso.co.jp>
On Mon, Oct 07, 2013 at 03:29:25PM +0900, Nguyen Hong Ky wrote:
> This patch will fix RX packets errors when receiving big size
> of data by set bit RNC = 1.
>
> RNC - Receive Enable Control
>
> 0: Upon completion of reception of one frame, the E-DMAC writes
> the receive status to the descriptor and clears the RR bit in
> EDRRR to 0.
>
> 1: Upon completion of reception of one frame, the E-DMAC writes
> (writes back) the receive status to the descriptor. In addition,
> the E-DMAC reads the next descriptor and prepares for reception
> of the next frame.
>
> In addition, for get more stable when receiving packets, I set
> maximum size for the transmit/receive FIFO and inserts padding
> in receive data.
>
> Signed-off-by: Nguyen Hong Ky <nh-ky@jinso.co.jp>
I realise that this patch has been applied but regardless
I would like to acknowledge that it resolve a problem that
I observed this afternoon.
Without this patch I see the following on the console, many times:
net eth0: Receive FIFO Overflow
With this patch I do not see the warning message at all.
^ permalink raw reply
* Re: [PATCH net-next 2/2] ipv6: make lookups simpler and faster
From: Eric Dumazet @ 2013-10-09 4:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20131009.000750.1849276529051781060.davem@davemloft.net>
On Wed, 2013-10-09 at 00:07 -0400, David Miller wrote:
> Eric, I had to fix up l2tp_core.c to accomodate these changes due to
> something that came in during the net --> net-next merge, please
> double check my work.
Sure I am doing a full check, because I received a kbuild-bot report
right now anyway.
Thanks !
^ permalink raw reply
* Re: [PATCH] net: sh_eth: Fix RX packets errors on R8A7740
From: Simon Horman @ 2013-10-09 4:24 UTC (permalink / raw)
To: David Miller; +Cc: nh-ky, netdev, ryusuke.sakato.bx, sergei.shtylyov
In-Reply-To: <20131008.160446.1960731810404939922.davem@davemloft.net>
On Tue, Oct 08, 2013 at 04:04:46PM -0400, David Miller wrote:
> From: Nguyen Hong Ky <nh-ky@jinso.co.jp>
> Date: Mon, 7 Oct 2013 15:29:24 +0900
>
> > This patch will fix RX packets errors when receiving big size of data.
> > Moreover, I set suitable parameters for get more stable when receiving
> > packets.
> >
> > It was created on the top of mainline kernel v3.11.
> >
> > I tested this patch on Armadillo800eva, it appears to be working well.
> >
> > Would you please review and apply it for me.
>
> Applied, but at some point someone has to add definitions for the
> RMCR register fields so that this driver is not full of magic constants.
Sergei, would it be possible for you to address this?
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Benjamin Herrenschmidt @ 2013-10-09 4:24 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Alexander Gordeev, linux-kernel, Bjorn Helgaas, Ralf Baechle,
Michael Ellerman, Martin Schwidefsky, Ingo Molnar, Tejun Heo,
Dan Williams, Andy King, Jon Mason, Matt Porter, linux-pci,
linux-mips, linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver
In-Reply-To: <5254D397.9030307@zytor.com>
On Tue, 2013-10-08 at 20:55 -0700, H. Peter Anvin wrote:
> Why not add a minimum number to pci_enable_msix(), i.e.:
>
> pci_enable_msix(pdev, msix_entries, nvec, minvec)
>
> ... which means "nvec" is the number of interrupts *requested*, and
> "minvec" is the minimum acceptable number (otherwise fail).
Which is exactly what Ben (the other Ben :-) suggested and that I
supports...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH net-next 2/2] ipv6: make lookups simpler and faster
From: David Miller @ 2013-10-09 4:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20131008.232125.1605815898898029345.davem@davemloft.net>
Eric, I had to fix up l2tp_core.c to accomodate these changes due to
something that came in during the net --> net-next merge, please
double check my work.
Thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: H. Peter Anvin @ 2013-10-09 3:55 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-dr
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
On 10/02/2013 03:29 AM, Alexander Gordeev wrote:
>
> As result, device drivers will cease to use the overcomplicated
> repeated fallbacks technique and resort to a straightforward
> pattern - determine the number of MSI/MSI-X interrupts required
> before calling pci_enable_msi_block() and pci_enable_msix()
> interfaces:
>
>
> rc = pci_msix_table_size(adapter->pdev);
> if (rc < 0)
> return rc;
>
> nvec = min(nvec, rc);
> if (nvec < FOO_DRIVER_MINIMUM_NVEC) {
> return -ENOSPC;
>
> for (i = 0; i < nvec; i++)
> adapter->msix_entries[i].entry = i;
>
> rc = pci_enable_msix(adapter->pdev,
> adapter->msix_entries, nvec);
> return rc;
>
Why not add a minimum number to pci_enable_msix(), i.e.:
pci_enable_msix(pdev, msix_entries, nvec, minvec)
... which means "nvec" is the number of interrupts *requested*, and
"minvec" is the minimum acceptable number (otherwise fail).
-hpa
^ permalink raw reply
* Re: [PATCH net-next 2/2] ipv6: make lookups simpler and faster
From: David Miller @ 2013-10-09 3:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1380840149.19002.256.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Oct 2013 15:42:29 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP listener refactoring, part 4 :
>
> To speed up inet lookups, we moved IPv4 addresses from inet to struct
> sock_common
>
> Now is time to do the same for IPv6, because it permits us to have fast
> lookups for all kind of sockets, including upcoming SYN_RECV.
>
> Getting IPv6 addresses in TCP lookups currently requires two extra cache
> lines, plus a dereference (and memory stall).
>
> inet6_sk(sk) does the dereference of inet_sk(__sk)->pinet6
>
> This patch is way bigger than its IPv4 counter part, because for IPv4,
> we could add aliases (inet_daddr, inet_rcv_saddr), while on IPv6,
> it's not doable easily.
>
> inet6_sk(sk)->daddr becomes sk->sk_v6_daddr
> inet6_sk(sk)->rcv_saddr becomes sk->sk_v6_rcv_saddr
>
> And timewait socket also have tw->tw_v6_daddr & tw->tw_v6_rcv_saddr
> at the same offset.
>
> We get rid of INET6_TW_MATCH() as INET6_MATCH() is now the generic
> macro.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks a lot Eric.
^ permalink raw reply
* [PATCH net-next] openvswitch: fix vport-netdev unregister
From: Alexei Starovoitov @ 2013-10-09 3:07 UTC (permalink / raw)
To: David S. Miller; +Cc: Jesse Gross, Pravin B Shelar, Jiri Pirko, dev, netdev
The combination of two commits
commit 8e4e1713e4
("openvswitch: Simplify datapath locking.")
and
commit 2537b4dd0a
("openvswitch:: link upper device for port devices")
introduced a bug where upper_dev wasn't unlinked upon
netdev_unregister notification
The following steps:
modprobe openvswitch
ovs-dpctl add-dp test
ip tuntap add dev tap1 mode tap
ovs-dpctl add-if test tap1
ip tuntap del dev tap1 mode tap
are causing multiple warnings:
[ 62.747557] gre: GRE over IPv4 demultiplexor driver
[ 62.749579] openvswitch: Open vSwitch switching datapath
[ 62.755087] device test entered promiscuous mode
[ 62.765911] device tap1 entered promiscuous mode
[ 62.766033] IPv6: ADDRCONF(NETDEV_UP): tap1: link is not ready
[ 62.769017] ------------[ cut here ]------------
[ 62.769022] WARNING: CPU: 1 PID: 3267 at net/core/dev.c:5501 rollback_registered_many+0x20f/0x240()
[ 62.769023] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[ 62.769051] CPU: 1 PID: 3267 Comm: ip Not tainted 3.12.0-rc3+ #60
[ 62.769052] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 62.769053] 0000000000000009 ffff8807f25cbd28 ffffffff8175e575 0000000000000006
[ 62.769055] 0000000000000000 ffff8807f25cbd68 ffffffff8105314c ffff8807f25cbd58
[ 62.769057] ffff8807f2634000 ffff8807f25cbdc8 ffff8807f25cbd88 ffff8807f25cbdc8
[ 62.769059] Call Trace:
[ 62.769062] [<ffffffff8175e575>] dump_stack+0x55/0x76
[ 62.769065] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[ 62.769067] [<ffffffff8105319a>] warn_slowpath_null+0x1a/0x20
[ 62.769069] [<ffffffff8162a04f>] rollback_registered_many+0x20f/0x240
[ 62.769071] [<ffffffff8162a101>] rollback_registered+0x31/0x40
[ 62.769073] [<ffffffff8162a488>] unregister_netdevice_queue+0x58/0x90
[ 62.769075] [<ffffffff8154f900>] __tun_detach+0x140/0x340
[ 62.769077] [<ffffffff8154fb36>] tun_chr_close+0x36/0x60
[ 62.769080] [<ffffffff811bddaf>] __fput+0xff/0x260
[ 62.769082] [<ffffffff811bdf5e>] ____fput+0xe/0x10
[ 62.769084] [<ffffffff8107b515>] task_work_run+0xb5/0xe0
[ 62.769087] [<ffffffff810029b9>] do_notify_resume+0x59/0x80
[ 62.769089] [<ffffffff813a41fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 62.769091] [<ffffffff81770f5a>] int_signal+0x12/0x17
[ 62.769093] ---[ end trace 838756c62e156ffb ]---
[ 62.769481] ------------[ cut here ]------------
[ 62.769485] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
[ 62.769486] sysfs: can not remove 'master', no directory
[ 62.769486] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[ 62.769514] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G W 3.12.0-rc3+ #60
[ 62.769515] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 62.769518] Workqueue: events ovs_dp_notify_wq [openvswitch]
[ 62.769519] 0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
[ 62.769521] ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b28
[ 62.769523] 0000000000000000 ffffffff81a87a1f ffff8807f2634000 ffff880037038500
[ 62.769525] Call Trace:
[ 62.769528] [<ffffffff8175e575>] dump_stack+0x55/0x76
[ 62.769529] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[ 62.769531] [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
[ 62.769533] [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
[ 62.769535] [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
[ 62.769538] [<ffffffff81631ef7>] __netdev_adjacent_dev_remove+0xf7/0x150
[ 62.769540] [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
[ 62.769542] [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
[ 62.769544] [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
[ 62.769548] [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
[ 62.769550] [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
[ 62.769552] [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
[ 62.769555] [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
[ 62.769557] [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
[ 62.769559] [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
[ 62.769562] [<ffffffff8107659b>] worker_thread+0x11b/0x370
[ 62.769564] [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
[ 62.769566] [<ffffffff8107f44a>] kthread+0xea/0xf0
[ 62.769568] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[ 62.769570] [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
[ 62.769572] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[ 62.769573] ---[ end trace 838756c62e156ffc ]---
[ 62.769574] ------------[ cut here ]------------
[ 62.769576] WARNING: CPU: 1 PID: 92 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
[ 62.769577] sysfs: can not remove 'upper_test', no directory
[ 62.769577] Modules linked in: openvswitch gre vxlan ip_tunnel libcrc32c ip6table_filter ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap macvlan vhost kvm_intel kvm dm_crypt iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi hid_generic mxm_wmi eeepc_wmi asus_wmi sparse_keymap dm_multipath psmouse serio_raw usbhid hid parport_pc ppdev firewire_ohci lpc_ich firewire_core e1000e crc_itu_t binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config i2o_block video
[ 62.769603] CPU: 1 PID: 92 Comm: kworker/1:2 Tainted: G W 3.12.0-rc3+ #60
[ 62.769604] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
[ 62.769606] Workqueue: events ovs_dp_notify_wq [openvswitch]
[ 62.769607] 0000000000000009 ffff880807ad3ac8 ffffffff8175e575 0000000000000006
[ 62.769609] ffff880807ad3b18 ffff880807ad3b08 ffffffff8105314c ffff880807ad3b58
[ 62.769611] 0000000000000000 ffff880807ad3bd9 ffff8807f2634000 ffff880037038500
[ 62.769613] Call Trace:
[ 62.769615] [<ffffffff8175e575>] dump_stack+0x55/0x76
[ 62.769617] [<ffffffff8105314c>] warn_slowpath_common+0x8c/0xc0
[ 62.769619] [<ffffffff81053236>] warn_slowpath_fmt+0x46/0x50
[ 62.769621] [<ffffffff8123e7e9>] sysfs_hash_and_remove+0xa9/0xb0
[ 62.769622] [<ffffffff81240e96>] sysfs_remove_link+0x26/0x30
[ 62.769624] [<ffffffff81631f22>] __netdev_adjacent_dev_remove+0x122/0x150
[ 62.769627] [<ffffffff81632037>] __netdev_adjacent_dev_unlink_lists+0x27/0x50
[ 62.769629] [<ffffffff8163213a>] __netdev_adjacent_dev_unlink_neighbour+0x3a/0x50
[ 62.769631] [<ffffffff8163218d>] netdev_upper_dev_unlink+0x3d/0x140
[ 62.769633] [<ffffffffa033c2db>] netdev_destroy+0x4b/0x80 [openvswitch]
[ 62.769636] [<ffffffffa033b696>] ovs_vport_del+0x46/0x60 [openvswitch]
[ 62.769638] [<ffffffffa0335314>] ovs_dp_detach_port+0x44/0x60 [openvswitch]
[ 62.769640] [<ffffffffa0336574>] ovs_dp_notify_wq+0xb4/0x150 [openvswitch]
[ 62.769642] [<ffffffff81075c28>] process_one_work+0x1d8/0x6a0
[ 62.769644] [<ffffffff81075bc8>] ? process_one_work+0x178/0x6a0
[ 62.769646] [<ffffffff8107659b>] worker_thread+0x11b/0x370
[ 62.769648] [<ffffffff81076480>] ? rescuer_thread+0x350/0x350
[ 62.769650] [<ffffffff8107f44a>] kthread+0xea/0xf0
[ 62.769652] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[ 62.769654] [<ffffffff81770bac>] ret_from_fork+0x7c/0xb0
[ 62.769656] [<ffffffff8107f360>] ? flush_kthread_worker+0x150/0x150
[ 62.769657] ---[ end trace 838756c62e156ffd ]---
[ 62.769724] device tap1 left promiscuous mode
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
net/openvswitch/dp_notify.c | 5 +++++
net/openvswitch/vport-netdev.c | 16 +++++++++++++---
net/openvswitch/vport-netdev.h | 1 +
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/dp_notify.c b/net/openvswitch/dp_notify.c
index c323567..e9380bd 100644
--- a/net/openvswitch/dp_notify.c
+++ b/net/openvswitch/dp_notify.c
@@ -88,6 +88,11 @@ static int dp_device_event(struct notifier_block *unused, unsigned long event,
return NOTIFY_DONE;
if (event == NETDEV_UNREGISTER) {
+ /* rx_handler_unregister and upper_dev_unlink immediately */
+ if (dev->reg_state == NETREG_UNREGISTERING)
+ ovs_netdev_unlink_dev(vport);
+
+ /* schedule vport destroy, dev_put and genl notification */
ovs_net = net_generic(dev_net(dev), ovs_net_id);
queue_work(system_wq, &ovs_net->dp_notify_work);
}
diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
index 09d93c1..cce933a 100644
--- a/net/openvswitch/vport-netdev.c
+++ b/net/openvswitch/vport-netdev.c
@@ -150,15 +150,25 @@ static void free_port_rcu(struct rcu_head *rcu)
ovs_vport_free(vport_from_priv(netdev_vport));
}
-static void netdev_destroy(struct vport *vport)
+void ovs_netdev_unlink_dev(struct vport *vport)
{
struct netdev_vport *netdev_vport = netdev_vport_priv(vport);
- rtnl_lock();
+ ASSERT_RTNL();
netdev_vport->dev->priv_flags &= ~IFF_OVS_DATAPATH;
netdev_rx_handler_unregister(netdev_vport->dev);
- netdev_upper_dev_unlink(netdev_vport->dev, get_dpdev(vport->dp));
+ netdev_upper_dev_unlink(netdev_vport->dev,
+ netdev_master_upper_dev_get(netdev_vport->dev));
dev_set_promiscuity(netdev_vport->dev, -1);
+}
+
+static void netdev_destroy(struct vport *vport)
+{
+ struct netdev_vport *netdev_vport = netdev_vport_priv(vport);
+
+ rtnl_lock();
+ if (netdev_vport->dev->reg_state != NETREG_UNREGISTERING)
+ ovs_netdev_unlink_dev(vport);
rtnl_unlock();
call_rcu(&netdev_vport->rcu, free_port_rcu);
diff --git a/net/openvswitch/vport-netdev.h b/net/openvswitch/vport-netdev.h
index dd298b5..21e3770 100644
--- a/net/openvswitch/vport-netdev.h
+++ b/net/openvswitch/vport-netdev.h
@@ -39,5 +39,6 @@ netdev_vport_priv(const struct vport *vport)
}
const char *ovs_netdev_get_name(const struct vport *);
+void ovs_netdev_unlink_dev(struct vport *);
#endif /* vport_netdev.h */
--
1.7.9.5
^ permalink raw reply related
* You’re ATM CARD Compensation Gift
From: Mr. Alpha Isoko @ 2013-10-09 2:44 UTC (permalink / raw)
You’re ATM CARD Compensation Gift
Dear,
I am ( Mr Alpha Isoko ) glad to inform you that I have successfully concluded the transaction. The money/fund has been transferred to China through the assistance of Mr.Pong Euge, who is a business man base in China Currently I am in China righty now with him.
However, I did not forget you assists/helps because of your passed efforts also you are the source of my success to achieve the fund.
In appreciate of your effort/assistance I already mapped out/deposited ATM CARD sum of Four Hundred And Fifty Thousand United States Dollars ( US$ 450,000.00 ) as a Compensation and wrote on your favour) I left the ATM CARD sum of ( US$ 450,000.00 ) with my Secretary mr.John Mark in country Burkina Faso, on my departure to China. I would like you to contact him in Burkina Faso with the below information and instruct him where to send the ATM CARD sum of Four Hundred And Fifty Thousand United States Dollars ( US$ 450,000.00 ) to you.
Post Office Burkina Faso
Name: mr.John Mark
CONTACT HIM THROUGH EMAIL ADDRESS ON THE ABOVE SUBJECT.
( mrmark_john01@yahoo.fr )
His Direct telephone number in Burkina Faso: +22676302353
You should follow up his instructions, so that he will send the ATM CARD to you immediately, to avoid any delay / mistake.
Note: I can not check my email any more; because I am very much busy here in china investing many projects with my new partner Mr.Pong Euge,
Best Regards,
Mr Alpha Isoko.
^ permalink raw reply
* [PATCH] Stmmac: fix a bug when clk_csr == 0x0
From: Wan ZongShun @ 2013-10-09 2:37 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, Wan ZongShun
Hi Giuseppe,
According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2] = 0000
but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not used
since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic tune
the MDC clock. So I add other judge condition.
Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
include/linux/stmmac.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8d4ccd3..a849092c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2741,7 +2741,7 @@ struct stmmac_priv *stmmac_dvr_probe(struct
device *device,
* set the MDC clock dynamically according to the csr actual
* clock input.
*/
- if (!priv->plat->clk_csr)
+ if (priv->plat->dynamic_mdc_clk_en)
stmmac_clk_csr_set(priv);
else
priv->clk_csr = priv->plat->clk_csr;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index bb5deb0..e2552ce 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -101,6 +101,7 @@ struct plat_stmmacenet_data {
struct stmmac_mdio_bus_data *mdio_bus_data;
struct stmmac_dma_cfg *dma_cfg;
int clk_csr;
+ int dynamic_mdc_clk_en;
int has_gmac;
int enh_desc;
int tx_coe;
--
1.8.1.2
--
Wan ZongShun.
www.mcuos.com
^ permalink raw reply related
* Re: Pull request: sfc 2013-10-08
From: David Miller @ 2013-10-09 1:56 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1381254091.1530.9.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 8 Oct 2013 18:41:31 +0100
> Some more fixes for EF10 support; hopefully the last lot:
>
> 1. Fixes for reading statistics, from Edward Cree and Jon Cooper.
> 2. Addition of ethtool statistics for packets dropped by the hardware
> before they were associated with a specific function, from Edward Cree.
> 3. Only bind to functions that are in control of their associated port,
> as the driver currently assumes this is the case.
Pulled, thanks Ben.
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Mark Lord @ 2013-10-09 1:55 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers, VMware,
"Inc." <pv-drive
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in mysterious ways,
please invent new function names for the replacements to the
existing pci_enable_msix() and pci_enable_msi_block() functions.
That way, both in-tree and out-of-tree drivers will notice the API change,
rather than having it go unseen and just failing for unknown reasons.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 net] pkt_sched: fq: fix non TCP flows pacing
From: David Miller @ 2013-10-09 1:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, sesse
In-Reply-To: <1381270560.12191.64.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 08 Oct 2013 15:16:00 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Steinar reported FQ pacing was not working for UDP flows.
>
> It looks like the initial sk->sk_pacing_rate value of 0 was
> a wrong choice. We should init it to ~0U (unlimited)
>
> Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
> no real sense. The default rate is really unlimited, and we
> need to avoid a zero divide.
>
> Reported-by: Steinar H. Gunderson <sesse@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> I removed the ACCESS_ONCE() stuff, as it adds conflicts for
> next (net / net-next) merge. I'll send a separate patch later.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: David Miller @ 2013-10-09 1:52 UTC (permalink / raw)
To: stephen; +Cc: yamato, netdev
In-Reply-To: <20131008141337.1a8a556c@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 8 Oct 2013 14:13:37 -0700
> Please revert this. It is incorrect.
Ok, done.
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Hannes Frederic Sowa @ 2013-10-09 1:43 UTC (permalink / raw)
To: Duan Jiong, David Miller, netdev
In-Reply-To: <20130918041337.GD8947@order.stressinduktion.org>
Hi Duan!
On Wed, Sep 18, 2013 at 06:13:37AM +0200, Hannes Frederic Sowa wrote:
> Especially because redirects also help in the on-link determination (same
> RFC, section 8), I changed my mind and am still in favour of updating it
> in the ndisc layer. In my opinion we just have to consider all routing
> tables and apply the update to every one which carries a valid next hop
> to the source of the redirect (under consideration of the destination).
>
> This will be important if we actually try to get linux to correctly
> implement the ipv6 subnet model (RFC 5942, Section 4 Rule 1). In that
> case we are not allowed to assume nodes on-link even if they would match
> the same prefix as a locally configured address.
I am playing around with a simple patch which does suppress adding routing
information for the on-link assumption we currently do in linux.
Are you intereseted in following up on this? I still do think we should update
not only the routing table the socket uses but all routing tables which have a
valid route towards the router which emitted the redirect.
I try to check if we actually handle redirect messages when ECMP routes are in
use correctly.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: transition to CLOSED when removing a VIF
From: David Miller @ 2013-10-09 1:34 UTC (permalink / raw)
To: david.vrabel
Cc: xen-devel, konrad.wilk, boris.ostrovsky, netdev, ian.campbell,
wei.liu2, Paul.Durrant
In-Reply-To: <1381150519-14557-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 7 Oct 2013 13:55:19 +0100
> From: David Vrabel <david.vrabel@citrix.com>
>
> If a guest is destroyed without transitioning its frontend to CLOSED,
> the domain becomes a zombie as netback was not grant unmapping the
> shared rings.
>
> When removing a VIF, transition the backend to CLOSED so the VIF is
> disconnected if necessary (which will unmap the shared rings etc).
>
> This fixes a regression introduced by
> 279f438e36c0a70b23b86d2090aeec50155034a9 (xen-netback: Don't destroy
> the netdev until the vif is shut down).
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Michael Ellerman @ 2013-10-09 1:34 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Benjamin Herrenschmidt,
Martin Schwidefsky, Ingo Molnar, Tejun Heo, Dan Williams,
Andy King, Jon Mason, Matt Porter, linux-pci, linux-mips,
linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver, Solarflare linux maintainers, VMware, Inc.,
linux-scsi
In-Reply-To: <20131008073301.GC10669@dhcp-26-207.brq.redhat.com>
On Tue, Oct 08, 2013 at 09:33:02AM +0200, Alexander Gordeev wrote:
> On Tue, Oct 08, 2013 at 03:33:30PM +1100, Michael Ellerman wrote:
> > On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote:
> > > This technique proved to be confusing and error-prone. Vast share
> > > of device drivers simply fail to follow the described guidelines.
> >
> > To clarify "Vast share of device drivers":
> >
> > - 58 drivers call pci_enable_msix()
> > - 24 try a single allocation and then fallback to MSI/LSI
> > - 19 use the loop style allocation as above
> > - 14 try an allocation, and if it fails retry once
> > - 1 incorrectly continues when pci_enable_msix() returns > 0
> >
> > So 33 drivers (> 50%) successfully make use of the "confusing and
> > error-prone" return value.
>
> Ok, you caught me - 'vast share' is incorrect and is a subject to
> rewording. But out of 19/58 how many drivers tested fallbacks on the
> real hardware? IOW, which drivers are affected by the pSeries quota?
It's not 19/58, it's 33/58.
As to how many we care about on powerpc I can't say, so you have a point
there. But I still think the interface is not actually that terrible.
cheers
^ permalink raw reply
* [PATCH] rtlwifi: Add new firmware files for rtl8188eu
From: Larry Finger @ 2013-10-08 23:28 UTC (permalink / raw)
To: dwmw2, Ben Hutchings; +Cc: Larry Finger, netdev
The vendor driver RTL8188EUS_linux_v4.1.4_6773.20130222 contains
firmware in the form of data statements. This info has been extracted
into a binary file.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
WHENCE | 9 +++++++++
rtlwifi/rtl8188eufw.bin | Bin 0 -> 13904 bytes
2 files changed, 9 insertions(+)
create mode 100644 rtlwifi/rtl8188eufw.bin
diff --git a/WHENCE b/WHENCE
index 27865b6..ee963a0 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1893,6 +1893,15 @@ Licence: Redistributable. See
LICENCE.rtlwifi_firmware.txt for details.
--------------------------------------------------------------------------
+Driver: rtl8188eu - Realtek 802.11n WLAN driver for RTL8188EU
+
+Info: Taken from Realtek version RTL8188EUS_linux_v4.1.4_6773.20130222
+File: rtlwifi/rtl8188eufw.bin
+
+Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
+
+--------------------------------------------------------------------------
+
Driver: r8169 - RealTek 8169/8168/8101 ethernet driver.
File: rtl_nic/rtl8168d-1.fw
diff --git a/rtlwifi/rtl8188eufw.bin b/rtlwifi/rtl8188eufw.bin
new file mode 100644
index
0000000000000000000000000000000000000000..4ae7e1c5deb7846e59c461546a49679504ffed28
GIT binary patch
literal 13904
zcmeHud2|%Vx$ksO&mtkTv{-#@BZgs*(1^ug2ZI0s#%7UB3p?HzJ9vQ@GniI9#DVD+
zFAiR=X$6v#dy{KB8OQO4^|(*IFE?J0Eu3IG!NNE>j^7Cs!;J8PG|iX+fi%<a_f^kG
z2s_C==l=8lcsi%2wy&zb`s%B1tJ3kErH&yE!6A$-n;5vt;i&XD2K|YPR}Lzp@YbeF
zYyN)u7oB#yxaQp72mJr7|L;-Y?G`ONU0x{tpkqj5hxbMH_7jQ6{P(6GOFS`iYx;=~
zpE%`zw5RiRr>I)(Kh|4o95siwN?~n8r#Cd@?Uv5KacAwQvmds2|I+pO;~l<4ku}b*
z_mp_O`z0yj2<x4Jc*>C|YJa+}!d0a19ADJanR!n4cD_>dCJp(=o=-OhnYXizX=f8f
zN1m>km?)z8a?P1hoqy~}=o^FX4t92wmPX^wgJ*{qX-5)8G*3h#6qvI#Rupjrj(Y+p
zq=;8JqkR8&AGRpkLXR)J^Eq902HlqTyVkMZh!hWNXT4{=$1a5R?*@#;M^#~W8;j#x
z^r+DISg`Sltsg$|VT;e1JhI1G<BV87Rj;b*>8wbc!9=wIEcBJ4ZY*YOvAT0wPv?1W
z=P168OxOBgLBYw<qt6u-XkU&Pp?%Vg#YisQrBlX7(B97T-LDpjFX*G(?oQre^yrfX
z1?NU<UtX#GCF$SU(<${Nt0bVc`>Z!vwfk(u;p;~vN$c$la72_RfJma~RZpS16WFD7
zap8)(Y3ifM?<cB)Z0D(^x3llF`-9%+T_?|8F<LwGyz@EN80vNc19Rxis7Hhnf_zT!
zJ|a<*__E%GE<+2RcXgiA&QR6SNA<5DLS#?40!;ic{$UKn2K8e?iMVk2E;DXrX>+um
zw_gaH8yfL;28UFh4F>9_X`aAoch}kA`0b)MV3uNt(v#zg1F<4>mo%A|%av0ru{NwH
z;`JtLcYy3`_+GBEeD9b&Q8vj$l4u&<6cUH;U~^1g@>Z++mTcFzGN*3t^CfSvy06c6
zEz6v`uFuE%qAU|-*(kGou|97s<Bes#G30x_vGd;81#j&A9^a{yw=3oCPI;3l-?QVJ
z(oG3-){gWJAM1^>3sH97_k|h#+>Cx^`Z{)WH1))Hhh*?fXlOLLy9b$c)6O07EvmTt
zzF;yMjcUil#ZQO}{~F&N1!%O!c~%or-eYI9$yB3w{6z=bXB<#UYAX)zsFBXB(S#*u
zkHxhif+%@QD{3@j@!|M(VR!KLsHMygBnp%<S#%5v#UChb<5}?en%|&!fyTmj@SUcE
z@4d6*J+nV|?6adMwKp9LnhNk0;v4DsR_r$a9k;LjMH_1~+jg`ywRJRhINBU-LYvs;
zY?IntZSFRYAskRUO?7e9JUmP7lu+b_4o`=>!_^^mI6K4+p~KP9(a{7dm>q1o;ZRt^
ztn}4U)^Jt&8vM>qe-poR(sTD-9Z}@zSMI$g(m=^KBWoy`8@UO|>gJ^HA0o2JRF_0e
z`TlTXK_D(g#O8^}bUNkx|CCsSqb}FKjr6!vUQvWJ=9HJeh4cj4V@Tspd833hfpiAa
zPVsa}qL#qxBkCr5Wf=YMtxP-0T7_~$pU8qk4Sgz8vZmq*iKnOd41EkU^vMC{VwR}x
zV%9d{NNJ1E-qv9>m3NtjK7|=g!;tz}_CR^L;sm<lb<cDoU#<vt0RSw!DMa;2`W@-d
zQc~y72J8KOlzrUa7o_Iy)?%l;><;P>azzAr*>1|Vx=}fk=cE!$%dDVF-qNT!<$ESj
z?K&^-EN?l2A^vvX;sW`)U+ow26Rax=io!Exze=tXc;<q@`?eN)$^a!+b1YijVzoVU
zkzHMOfzK#~Zj&EOqiaa1ep9RCxcyf;hNOs4Z7)i?Oy2UEHk@}YDmL`-%mT^gL%vk+
z>*)AVi|_DDgqqh7exnMeb}f+@5ar640OOUSsZC1aVC9OEsg1@?u_Jq=8s6?THA>@V
zMDQ8Hf2yJhk!E14fps;_r({gS<x@8S;PlY_f=n~iYP6?nF@DFHyqjQR5D9toFx*lF
zD`K@Z90)TOGbO_FMZ5!si`$Ux<rTmZBNdt2mFPx&@`Fp5cA{Mvr&57;Y8sw2W#w+8
zX*dhIcpY^|Ga*uaf(l-{KuBBW>1zyOHWrnMIO}h!J`o4NCCxv0O|JOl52m9n^2Bzp
zJnfeTuYff&EE3vYOcnZhK#+M7&scK9<&p0LuJX21wOXIi<dQ26(QoZvc)vru5q$)Q
zI^T@i#9Pg3D~L)n)fzJsx72H)jaFpOs)4F>Q+%e7-qCIPa>oVuy>H56p0yMqONUCy
zuFRTAMYOt=%qojovWk>RD!nT#G@IRuH=9(>t<1HQq9vJcsX)uImDGi(EZ%tsjb{be
zMogiOHIp_Q4XIy=GOGm}6k+lTGiq+Dv6?3ka3;q`9u6U!U7U^V5*_9->_EBV2{5~c
zSmJ$#JwxhaK~WzW5x}^Z47`!6T_;h!C9f{lM{;xsv6BQ-{WS==x7EbI78P+2Dzy3e
ziN~>ZV(5xYM3R?YE7xz?FBA~7LmX*N+PtOLY74*tkX7Ss?y51hz{MzzW38fln*gml
z1Td`C>p`Ii{SME>K=RV7<y(HukKHyA@^=CnMZTTct}}OBvZKk+>}_EVBu1P7Js1(?
z&ASZYrZ|quT(D$rWI9jEIa5iRhP#j{J;W(jsbMopAYrTiCQJq1rN&whmO4EOBHwJ%
z5p5MfU!2fhR8L_Qv0}npTnZsDp4IZh$afqkjOY@)hD3KrN(NXV!J}r<z8wUc+vj11
zUdgN|+Y~B1{m16Z4SgEJHVd6BH&lSR4Sg(aC&mdbrk;6GBOAguSs*@ydR4MvhHHyy
zG!2P2nu1*WLc7sa#P(>YVC%F!TFnqc_$et5Rx6ltW6$9~8~S_}U`6rt717hZppfdq
zv~TihxgZLPZ;j))^K=3OA3{3$4EIae$!Vb5i%2VR+^i7RTFJ7O=0F1|Y7+vC9k_^c
z16#ngSccPHpTI1P>(A7QS_$zcl$pFS1@-a3yBE<2BAC<YRgVN3am7c+3rD~vImB^D
zJUkZ-6G?*JV_;mRBv?-b4>>JJb)tMxkZUF3R+|?j)0X0MKmkL)hP9U~k@S`E-c01?
z?SfqAGK5=+B<>$^+C%($Nqk~J;!a|9pCMhw&IFw#x}|?&if5fC0)2&|To>%$5#m`e
zlD-gYtF-wCnsFrP%vuY<@3qLqQ2|obGRT)j>{X8|9yL!7@x`rOs}1Q2790(+%F=7N
zWF;-B_M#%O#sr;^mBy$Qq)0GI2_%W(>S3XhC<_h2=fUSh+YzIwl<oNx5DcC~p&_)9
zcm%4E>DwLh^cT^P;~Q<iI;N6DWM6s*Q|6n=;1%lF{)*aC^P*;GB;Q4iI87Hf*1#IJ
znNpaqmXb117w3fVoQs4os})VY1y?hh{K|IW$<ezmOI)dV4$M&44@U3!!DUTm;tIQH
zC9dQrXI0evB42ZbT>~%xN2BH&LJ{&$A{$kmrY~O~#ZH1s`U?9j-JDanb*P~|Ag1Ol
zi1SS%$;Cmdw<JT7-Dd?0`iXf#1dec(yefZiz!w#<e#St@<$R8iIQBt%mLTPF>>l*N
zymCsRvG!qy&4eQ!V8ODaeUhRkouuWQ@90QegwJv_hYyXvoCO!<@ZtTPtwI4uEWos(
zxlE(!eAb@@UsW-n+m}1%gV8lyix@nnlOkCoB&~3;Xx=hA@l->kyB6Fkubi9Ln1+5O
z<e)?nn;Ky`X<+ls#av1o`VA~tf<xwl4i=I0fyM2iN~5_&S?%RyO+8h1z!pQE=DWFF
zf%&=ggftz;wmVuyal1g8ZJVQ261NFmD?{UwyzAJf>LCkBS-9hwNRbAWGmeGawi3c9
zgdZdd7s0eIA`UDU4`L7!my3rYc_riqx{#{LPdxu`PCPz8v8=w#XD*_dy&A+i(2!6d
zRX0GP_vOW7$fy7=Cb!^FF~V>N@|ZVZJC4;LbOzOM`B%Z*acgt22GVd^<_&s~z-Ss_
zZVHLIlpGeEH!OJ9u#kA?Z|LWkpA@`=c4oCoQu6|Uw2D%5UB1pKH7lqiV_KJ*7v-w~
z`ehFE=6oGMKSf<=Tk}+HD~;GHxnwn{ZRB}DY96cI#j{RSZ`RgOK2+B{Mq5rfOpog2
z+WaJ#qj{z_o8xgztKwjjo2P5zZ7}Nnur`W=4be&oY@Zt@F^wiR7x1MwPbFh=6E_)@
z{a_#;EKXnZRC(E7DKC;V_R)#90WA)J)870gnXu@AQ|LqSW-ZzLsrE&V!BB@$@?;eR
z&Y`dy(cS&O)dKvss*jj?Yg389+7!6837vY0wQ1Y1a9#)7ux*#xu+Diw@W#H&?N!}P
zSOZPY?lv}dmh5ga-t9HfarnyOb7;4D+FWEG10g*D<lq#0<X}2?_zr^alJeq74VxVe
z-xC^khz*ZB8}>*IKd)$bc5K7maSgBf8{Qn>@cRi3AGA3f4IdjidW;Y^{LftGZr#o-
zXv<YJ=0LPsyW*`Iat#}L?9B1wxr*!W&t<+d&(3JMRQ%3Lu5z$j@+~*?o7#)X)HeCK
z8fKpiLtkPV4iRU>(3b)@Z<NpHkTy)#a4D?)DMPO@lQ07MHx@90A-oO})-XeOBiB2E
zQ*S11pBKuJpFc}6VRdA=957d+(uoNbVLU?>?7|FiQc4aeCeAKNidBG+I7*Yv!@nbc
zjXPeLXd)*1Ez-$IUqedJFrtVx`SE}7e-Vr&FP}##^!P<bUMaEcm1g7z5B%de#5q%4
zLve^-C6-bAVAEElG4V7N5pCG?&xz|P8nNkJq=-6%e2E(Z$Hn?E63AH#$qDf^ODqo@
zcSW3X?L_1Nw(<Z{1SdjskRqrNI;5VnqY{|w??okOH8WuwK}(F|n&uMwscew>1afe5
zTV6WFM|*1M)gX~@Fb;DiYCbG{Pv2S}v9j{iiQIRnXX~6nr%!kZCwL90x`tWpd&C-1
z=xkTBPh0Uljx6tUBRY_u|B#{I$SkET8+0X=qR<Gt7zo~*RGh)P41G2BOCxQ*8iTE7
zXbwSEb(1e<=nD3_h_cYSLs?b{P*u0$1h41{TNel^QF3oq8jdtmY7G4*lZ6(Lo1m2%
z`pq;ltlu@za6%cytv)l=o2cu};E01rZ$$boQcNqnXF_3&LEuUIlh1IRV-+V0SVXAk
zEQ*M{jPOvz=_@;FXmgWhb-5v|!|-C|udDUyebqJ9Yvbuz>8sMS({uLDiqugU>#9gS
zC9@+pQZgs9TAY4m<F%#n^t{ITp2ix{5CVy7&1hmCJ~+k+SY(ZhiyM~+i<Xo&E_F6u
zcb6f|Ni0Uo5`0VXT}S&8u=fSa5a#e5io$rK34uOMh=e9YLKBjUZRNn=WA%5Su-i6^
zhux4+*bT`|)WM-4!jOq*s4_AR64mlepVdDkPk*TX-TFHaTUrE*X8}lT**OpwJj*MQ
ztrqI%^C4>NAsQ>J`upn7*GJ-(xag_+yXrU9|9bPP`p4>jZ0ICl;L|yQ6in(UtiSXM
zSb*A55aLs3<MaQ63LjI0A?zW~2x(j$f-aPWgM{wri0nejBA^mg3v)FTComDGfg@;p
zlFBiA5=?~93Pyr*f#D<kT-}bEAK`ljpC2_pQ<vfQUsZ<Re~IJgr_f2@&w5}&ZW@fS
zIE*pU*z?+nhxY75BimD6gQ(G4WPbvq`kcWY8OAO6BOGozhjY~Yry=}~1y1}sjXIG=
z<)X<{Oyo$y<xqx~f|XJ;Dtjq((o1TS{I)8U`@LWVYy|42+CW((ld(MB;}{YOBk{t1
zPM$nb&Y^N<E`kGohBby`Qmy`rsmWACzSZec4O4R>K4a)}2o1Pfz(A;-#Iv+v9Mg;F
zOIn?F(a^tzPTzvFXZrm-K71Q3VhTA>li4OXdP}Dq_U;$N=C%7$^7N;W+jp<LaE10>
zUh`wY0p`zHo0pME>Dku{GtD;Vte_KyW%ExovH7`+?XZ2m=HKSjEF8h1hpYAr-sYbe
zLIQm0+xMm6@G>O{qmWLAwW|(z-om#O=iIihlXutgExna*=`Fb}g)_#t^p>w|Dd4cB
zfXi<w`*&=8HOoYH)9KMCu^^%VRV;AQ1s6+mBM+hy9<`-59ucAWJ;Pyuxib+1eTZGe
z=`ZH!AXol6p2lH*DjD4J?Hh%}jsAN%Id2C!9XnaNE?o~t`dFeaz=l*nVN8B!b$z!s
zALZjCDiXzV*&7HOFRHIF1b5tAU7ykXXo?M~fG)Y$y}G_v8;0_U5=c7v&IdTCwz~e@
z-ulQ+prZYd(-N}JU=_IAfb9cOoAaR~B4hx|CflE?8<iZ-_-#`hL5$xZ)EFhtwM08g
z{)+fR7UVHiNaB%(_z0^w&WnhE4hpe)sZYH3LI(1s7U8!yl4j66yjeSy=Lq2sq`dVv
z!AEbhOh`QbbEBz%S*ozz@w~^Yx!PwOnsMmk^H%b9wEdXc8cpcR4ta4Q*m=L%SS~aU
z(;J8HZyX_T_0%R$?dk_RY=gap2u-fzhjz`|12sqNn)ZPj)2=x%P;=U@d1s&|W!L;}
zpyo@v=J$Lh7EPE{h3DN~O>Cd>ao?G>e3ACrXl1<C5dHx0HfC|u-;x{VQ$GYL6sP%C
z6F1&OlW*5WH0&T6%J+}fzA*HUl4i8ajOK&3h8{B`ejc+m^iRlw)<0ss<llY*yHy+U
zMWg9`)_+$TfrcL<&_K6h2=5yDQ4abiX2tt5+3-lY;<e|c7hEs8UxH716g|6?NamEH
z^~tq=;IZIb2O9JgS?gq!AL0{J4EZDM(WTS0(G3$H%LXPhhX<Vb7!+T=bPU`KRFH%D
z5v16N$Rxg~uve~lKB)*6&UlPsUNJDiN5Nuy!h86-v?9B-?vhn@DJ7YBpP~Pmul3I&
z+3_cm=1VZ@Kg-dt#mUz{Y|#1>eErmyR<D#`2*87~C+vBG7tdoa^D}fASf)7bm-%zQ
z_CNS$hD%i;WrzhV>_~aliqxnWg4Hf>%&(<jmK&K;Gc3gX4jP!^L1AZVofI4zvv9BD
zNzygVok!zgF%@>ktWhysL|4W#qhggL_Lw!$EvrhEJ>98ftL4U!;Ht0~lTzBdVJQ}t
zQ&!j&3zwzB?pU}y752o!!%|^yEIcC>E{KI^rox4>@T^pLNGyC+DqIu`&rXGh#=>(_
z;o?~M>QuNS7QQAG4-Zcz{XM}(e_!x^zZYn=h09{Cf(ruc&UYv)x*)6UtW!GewsWN;
z!^2|PQL#*y6&}%@%Hr15LNLs3Ec@C<yXP6q@Xn|d0EdHq7=N7yH7|x|#%#U?bG+7;
z<J<5IyRyT9U2Dr-afWB*AWH$6ztBW`c$8e54G)jOt>2Bk0BY51!<SRtoUa>t_SX%4
z_1_q}f`-8lT*jZ#n5X61{r&i0-UKyL<yY{bMt&i4C|pkW)^s7G{S)#QuCcNDUSMqK
zubZ2XYc6mU_@OjLCVO3JGFXVc#yYA}V-1LF$l#YfU3;alKh@<;ebFj;!V^J3t@w-Z
z#8#IJU11PNsUzX>u|4Ru$5Hp~cz8l8Jdwu8wm)4X{vx8znAQ^uPfB4%7OYffQ)zmt
z+d`izK+SaQY9dyhoC;5mS!c50$+0_VkCV5rOojbG-V3nsq*w+TC_I7q@E85ldFs~x
zgXz!%?-^p1_+~o(IX96yyNcuRmFXtMEOZzIpET`Bf5y=-3H$jg0LZ@ZH0;ly+3Ri}
zwA85tkwEWW5^CprAb`S?lPPufRD1I5nYDaf-M6nwVSRk&cGdZB88}RR4`<aWmFHD$
z?uDd0=5t#0Ps3AaTe+~yV=?WQK4@WbU2~3d7T#K>9oCVYcU^7Y`~x^thW-HwzC+#k
z`G8#KL(DqzRNWjK5*-yGs~+W%UX8BX2J*NMIXqs26h@DI8YR%yzokHF2qqaUE6Jk!
zW#mZ29G<}KOMY7e0}w_yki@kmU2oF;q-}!&?=G%__Bvk{A(YeH@H(JgZL0S~%~Q&J
z#6D}f%vYptvJ|^uPy}cCKM7v$pBq|W=-uqVj2SZ&;F5yzxgMWpYTuxG#1weluTTdQ
zV-$x~O6^MW2Vi#bD**jVxOi@ionpaaLs*F1Y1Ax&TZvynGle2mpMjYwEM#k8tfpYB
zcB@z0J~!~>kT@q;zy{O!;aVt_^<;g27v1imk6huJy5Z_pPFFp>gCbX`1_6%)j$qc4
z6?_k))8Z8GlhtF>&c|my0`nw2?9t(kBMP~Ozm<#={WfUbs)<R-p5Ruxhswy+pC|nX
z4LxiUn_;}$xLx!Rp>a2g_tHmbNOic@c!*_f8>0N<z6ypg$Gr>}ROrpB{97@ve&J!E
z&DjPb-VG%sKI^~zysFPKA1}9&5%G}2$x*o*OQ7CZ$kRZ_UPF~B-dlrtK?{8Y!^&&K
z1uf7lTS*~d@gUFrCY*K(=VT21J8;}fvQbn0UY<Gt*l6~3XHWHh0i+)6Hls<i3&FAb
z9(UaLwy=JSxZxS+`X{CJEw1$~?)5F6^)22FGYU4WFLXFIw9uRx|M&BAWz~oIJqXPU
zjbZ3&x7mmBFa?qECx(6>T%`riP`80z0}5flkU{&y`B8cMMVf*4-ZrQ;e2J3C3vCX%
zeK6>#!TQ9|AK(_k1KbYy3C}-hTU*mW*ZUAsC4@IJQ14=_dgGQH_&vQ^`1+;|)K}nr
zY0>}PCEuU3_bypz9{cYwf3MXBdBK-KF9Tro05OC;p@?v|PPo_$AeQTAb>ZRc_q44u
zIDcV}z$`3-RljaNENQq}rqzE<FX?aga?9U7j&95^Vyq3U$`nSz0V%+l!4rWNSJyN{
zyB2;Eh4`(mDnpxx0?A8Wn2!R*8F>LdFAphNueb<s0UUZ8GQcMA0NI?}IEH>T0#sQX
zOhuqLB#mI`-=qM*94z`0pV<zsVOo72WX(w)0yXsO`^UOrAoQ(g_+j8-5kt=qPo!~W
z291iFV+Y+8>K5G<!sUW{s=<4rcLi47LoMV%2ko7R!0pJq6Q#q?8DlgRG7F@22+%cs
zk(TYk=3tU8!qGV5@$$zYh73nB7UCDvBOr~0t<Uf+qGr3n5MII3AlZcXaeHn19l0su
zmZALx+D7}BWnOhl+i~->-O-Im$#g?#VWIM_MziEu|3av`Stex9=Knw(B{+h>;mkxF
zt%Vd=2_hPZxDQ8t*HGWCVrUd$CTqAhy#UX~=A{?ncYb;ierwXTXh|$UY-}OEMfhqd
zwlkMCEKV;2z>@U!_+6U50l(L!m!l=I3_#c8y8+*Fb9M7EY!<)T=EU~d7lI+2t%)p%
zC|~|<g1qXCeLa_lfZhW{#Q+5MmB(rFH|U-a1v)r*tAJ}QKo{GQ9y~J;HRs_7Zl<pQ
zQNW5gVVQmFpIo_Xm3?8{e+SZ3jJIM<Lz4(j_MM*neaBu8O3aYPqqZ0WswG^QlKBrd
zXmP3Dd^v8a1^GNfXzAjs;B(NlEiRkDD^K6BUl?U*HS{KA-}=3tm)$KZ<yB2NL=5)}
z5Yx*|mQmV5aI^RuH|@c$KqoF5aG@`TrqH@^Wmv&@GvajGq})1%5WEds$s$B3?E6rw
z-~|!}6p9BGq<yQjA%`Oxga;p&ZcUL5oGg=9owmtMgQLHXf=$@jwQ;cBTtpeZ64$;h
z_by;<?p*-MJ#;Na!Y!2|L`3N>5wdgDP*UNzq|L7lOB<R)0n>;}v83fJ&^eZ`Pze3E
z@s1->Ql7yp6LGr+AFIo3arf^qJt4RZrV>+(ARbrZIODYz#RreaajJ11_%?C&amrgD
z;pQVYhPQZs1>b_DX7M=xasPjT9_RoD#bYsWrM&q%T$_`6^y3W+1y?oLY!p9SfrTSj
zPEji<o(o!OoR$H08Q$7Z%#jBlbB}JMQ%w0Qwgzb}ZuB6~2JV-!)vgSVHlNwbJ#(Cx
zgq>(e3_CqOKX)mgJAZcr$qyVMOAsOsFd({&Wr7R766>KcdXu*X-Pp`!G{;hQ<lpK_
z4dM4N`^w(T1(<#Esv$H2VS(5txXxp^DdIMORk?x(m)}T|$(lp!I7os^gc9Pq{wpQY
zN1!;J>WCmb(B8dAs3{!U#U1f@mF43Vej`)HHij-Ugpur37mUle`jCk_B4w9^j7gxt
zcqL3=n3N7OljxQUVHRYV^{QL&A*@`-_N+7XRTNvqAm9oL#G)C?T$O(e@-~06k$Y%$
z@vDuzz;BXCdXy#2BYQk`AqtoEhm_9XerqXPn~5xirv;cnjc8lKR%Iefc$>_EqrL`W
zF<XV0-X%S0*u^yLVr@IM`Fl*}moA-n5kV~a`iU3O#C97dzJd=jXaLNxkYE;Smw&a9
z=7;f)R*arIIb14(;uJWaif1o)-%%umAfxQ?y00r#2&Ii}sN{ZACB4qAWaNn80TbR8
z(MtrVuzVczUXm0RF0Xh6xMU55wX<==Li4fB+GHTc^LRrDk83L4f$<`|k;ybF-DuG>
zPsB?rObu6J^KxNQ_%&49|MV1s6VLjC3v*ftS{iTLa7uCgTmtchBa4_j2{itO0pgCh
zWQt0T&N%RQ|AC^{QG>6nr*Oj%K=gDpcTYfFAR=<lY0L1Y65~KH<3hp{T1YQx12{&!
ziX=w>PYMK4qxTGMyuag3bI6bjF#H=s3E|u-;OqhAUd%(+i-v1zKG@C?f)O!rv+g7$
z`91r<D*}1h3A%Kr_XLCS=kE<(@$eUoaDVwzlEM}|RD_7PLmAK?EO?!*FKlIyTUgOW
z3&Vm3t!V)NVjF*`CL4c4n@<{2-njlrWmm)AhL@F=)licy4X-GMq(Pr$UiPSE-ynmZ
zYh%H@s00F_b;LmH1ydb9P#Qz6?twD)R$2|rr5o|plc^=usTorp)(@hzt;ndu^7_5Y
z^u6SH(cLw*H-629c0>C=>}Q7d3H#T&@+k8Qu*p7QGacFXFP`rG{HY6{lMrfgst(?}
z7nXxXmZ_!C`&zn5%U${x+O{$ty%AfGB!)7-4!cZSyaW&7@I3iPOu0NXq+i0~iUTk5
OE+=Occa@IUp8UUyqelq<
literal 0
HcmV?d00001
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH 1/3] net: bpf jit: ppc: optimize choose_load_func error path
From: Jan Seiffert @ 2013-10-08 22:50 UTC (permalink / raw)
To: Vladimir Murzin, netdev
Cc: av1474, Benjamin Herrenschmidt, Paul Mackerras, Daniel Borkmann,
Matt Evans
In-Reply-To: <1381249910-17338-1-git-send-email-murzin.v@gmail.com>
Vladimir Murzin schrieb:
> Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> were not passed. At the same time handlers for "any offset" cases make
> the same checks against r_addr at run-time, that will always lead to
> bpf_error.
>
Hmmm, if i only would remember why i wrote it that way....
I memory serves me right the idea was to always have a solid fall back, no
matter what, to the generic load function which works more like the load_pointer
from filter.c.
This way the COOSE-macro may could have been used at more places, but that
never played out.
And since all i wanted was to get the negative indirect load fixed,
optimizing the constant error case was not on my plate.
That you can get your negative K filter JITed in the first place, even
if the constant error case was slower than necessary, was good enough ;)
The ARM JIT is broken till this date...
You can have my
I'm-OK-with-this: Jan Seiffert <kaffeemonster@googlemail.com>
for all three patches, -ENOTIME for a full review ATM.
> Run-time checks are still necessary for indirect load operations, but
> error path for absolute and mesh loads are worth to optimize during bpf
> compile time.
>
> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
>
> Cc: Jan Seiffert <kaffeemonster@googlemail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Daniel Borkmann <dborkman@redhat.com>
> Cc: Matt Evans <matt@ozlabs.org>
>
> ---
> arch/powerpc/net/bpf_jit_comp.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index bf56e33..754320a 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -132,7 +132,7 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
> }
>
> #define CHOOSE_LOAD_FUNC(K, func) \
> - ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
> + ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
>
> /* Assemble the body code between the prologue & epilogue. */
> static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> @@ -427,6 +427,11 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> case BPF_S_LD_B_ABS:
> func = CHOOSE_LOAD_FUNC(K, sk_load_byte);
> common_load:
> + if (!func) {
> + PPC_LI(r_ret, 0);
> + PPC_JMP(exit_addr);
> + break;
> + }
> /* Load from [K]. */
> ctx->seen |= SEEN_DATAREF;
> PPC_LI64(r_scratch1, func);
>
--
An UDP packet walks into a
^ permalink raw reply
* RE: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement code
From: Himanshu Madhani @ 2013-10-08 22:46 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux390@de.ibm.com,
linux-s390@vger.kernel.org, x86@kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <c92efbde96541d08f37510422c096d543bb01279.1380703263.git.agordeev@redhat.com>
> -----Original Message-----
> From: Alexander Gordeev [mailto:agordeev@redhat.com]
> Sent: Wednesday, October 02, 2013 3:49 AM
> To: linux-kernel
> Cc: Alexander Gordeev; Bjorn Helgaas; Ralf Baechle; Michael Ellerman;
> Benjamin Herrenschmidt; Martin Schwidefsky; Ingo Molnar; Tejun Heo; Dan
> Williams; Andy King; Jon Mason; Matt Porter; linux-pci; linux-mips@linux-
> mips.org; linuxppc-dev@lists.ozlabs.org; linux390@de.ibm.com; linux-
> s390@vger.kernel.org; x86@kernel.org; linux-ide@vger.kernel.org;
> iss_storagedev@hp.com; linux-nvme@lists.infradead.org; linux-
> rdma@vger.kernel.org; netdev; e1000-devel@lists.sourceforge.net; Dept-
> Eng Linux Driver; Solarflare linux maintainers; VMware, Inc.; linux-scsi
> Subject: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement
> code
>
> As result of recent re-design of the MSI/MSI-X interrupts enabling pattern
> this driver has to be updated to use the new technique to obtain a optimal
> number of MSI/MSI-X interrupts required.
>
"We will test this change for the driver and provide feedback."
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Thanks,
Himanshu
^ permalink raw reply
* [PATCH v2 net] pkt_sched: fq: fix non TCP flows pacing
From: Eric Dumazet @ 2013-10-08 22:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Steinar H. Gunderson
In-Reply-To: <1381182269.12191.27.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
Steinar reported FQ pacing was not working for UDP flows.
It looks like the initial sk->sk_pacing_rate value of 0 was
a wrong choice. We should init it to ~0U (unlimited)
Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
no real sense. The default rate is really unlimited, and we
need to avoid a zero divide.
Reported-by: Steinar H. Gunderson <sesse@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
I removed the ACCESS_ONCE() stuff, as it adds conflicts for
next (net / net-next) merge. I'll send a separate patch later.
net/core/sock.c | 1 +
net/sched/sch_fq.c | 20 +++++++++-----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 5b6beba..0b39e7a 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2319,6 +2319,7 @@ void sock_init_data(struct socket *sock, struct sock *sk)
sk->sk_ll_usec = sysctl_net_busy_read;
#endif
+ sk->sk_pacing_rate = ~0U;
/*
* Before updating sk_refcnt, we must commit prior changes to memory
* (Documentation/RCU/rculist_nulls.txt for details)
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 48501a2..a9dfdda 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -472,20 +472,16 @@ begin:
if (f->credit > 0 || !q->rate_enable)
goto out;
- if (skb->sk && skb->sk->sk_state != TCP_TIME_WAIT) {
- rate = skb->sk->sk_pacing_rate ?: q->flow_default_rate;
+ rate = q->flow_max_rate;
+ if (skb->sk && skb->sk->sk_state != TCP_TIME_WAIT)
+ rate = min(skb->sk->sk_pacing_rate, rate);
- rate = min(rate, q->flow_max_rate);
- } else {
- rate = q->flow_max_rate;
- if (rate == ~0U)
- goto out;
- }
- if (rate) {
+ if (rate != ~0U) {
u32 plen = max(qdisc_pkt_len(skb), q->quantum);
u64 len = (u64)plen * NSEC_PER_SEC;
- do_div(len, rate);
+ if (likely(rate))
+ do_div(len, rate);
/* Since socket rate can change later,
* clamp the delay to 125 ms.
* TODO: maybe segment the too big skb, as in commit
@@ -735,12 +731,14 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
if (opts == NULL)
goto nla_put_failure;
+ /* TCA_FQ_FLOW_DEFAULT_RATE is not used anymore,
+ * do not bother giving its value
+ */
if (nla_put_u32(skb, TCA_FQ_PLIMIT, sch->limit) ||
nla_put_u32(skb, TCA_FQ_FLOW_PLIMIT, q->flow_plimit) ||
nla_put_u32(skb, TCA_FQ_QUANTUM, q->quantum) ||
nla_put_u32(skb, TCA_FQ_INITIAL_QUANTUM, q->initial_quantum) ||
nla_put_u32(skb, TCA_FQ_RATE_ENABLE, q->rate_enable) ||
- nla_put_u32(skb, TCA_FQ_FLOW_DEFAULT_RATE, q->flow_default_rate) ||
nla_put_u32(skb, TCA_FQ_FLOW_MAX_RATE, q->flow_max_rate) ||
nla_put_u32(skb, TCA_FQ_BUCKETS_LOG, q->fq_trees_log))
goto nla_put_failure;
^ permalink raw reply related
* Re: [PATCH] pkt_sched: fq: fix non TCP flows pacing
From: Eric Dumazet @ 2013-10-08 21:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sesse
In-Reply-To: <20131008.165318.1392122841162708841.davem@davemloft.net>
On Tue, 2013-10-08 at 16:53 -0400, David Miller wrote:
> Is this meant for net or net-next? It doesn't apply cleanly to the
> former.
Oh right, I need to respin for net tree, sorry for the confusion.
^ 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