* Re: [net-next 00/15][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2014-01-06 18:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, gospo, sassmann
In-Reply-To: <20140106.132628.418605275145035482.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
On Mon, 2014-01-06 at 13:26 -0500, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Mon, 6 Jan 2014 04:30:21 -0800
>
> > This series contains updates to i40e only.
> ...
> > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
>
> Pulled, please make sure the coding style feedback does actually
> get addressed.
>
> Thanks Jeff.
Yes, I will make sure it is in one of the upcoming series.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V1 net-next 2/2] net: Add UDP GRO support for vxlan traffic
From: Tom Herbert @ 2014-01-06 18:46 UTC (permalink / raw)
To: Or Gerlitz
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
Linux Netdev List, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CAJZOPZKfxws+S3ZtTqKQ_yXYhoV=UTOXscM+rVB24UA2d1Fopg@mail.gmail.com>
On Mon, Jan 6, 2014 at 10:13 AM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
> On Mon, Jan 6, 2014 at 6:50 PM, Tom Herbert <therbert@google.com> wrote:
>> I think this would be a good start. We can further optimize the encap
>> path later on.
>
> good, did you had the chance to look on the 2nd problem I was facing,
> e.g how to prevent gro-ing encapsulated VM (this issue will not happen
> for non-virtualization schemes, I think) udp packets which happen to
> carry a destination port which belongs to an encapsulation protocol?
> as I wrote earlier here, I was thinking to add some field to struct
> napi_gro_cb which will be zeroed when the gro stacks starts to work on
> the skb and set once we pass udp_gro_receive, such that if we arrive
> again to udp_gro_recieve and this field is set, which means the
> encapsulated
> packet is udp one, we flush.
I don't see what the problem is, GRO should not be recursively applied
to an inner UDP header for encapsulation. The guest may try to do it's
own version of GRO on an inner UDP packet, but interpreting the
destination port correctly is its responsibility then.
^ permalink raw reply
* Re: [PATCH net] r8152: add terminating newline
From: Joe Perches @ 2014-01-06 18:42 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1388999999-9218-1-git-send-email-hayeswang@realtek.com>
On Mon, 2014-01-06 at 17:19 +0800, Hayes Wang wrote:
> The netif_err() and netif_info() should have the terminating newline
> at the end of the message.
dev_<level> uses also need terminating newlines.
Perhaps it's a bit more comprehensive to convert the
pr_<level>_ratelimited uses to use net_ratelimit and
netdev_<level>.
---
drivers/net/usb/r8152.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 13fabbb..8ae97a5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -966,10 +966,12 @@ static void read_bulk_callback(struct urb *urb)
case -ENOENT:
return; /* the urb is in unlink state */
case -ETIME:
- pr_warn_ratelimited("may be reset is needed?..\n");
+ if (net_ratelimit())
+ netdev_warn(netdev, "maybe reset is needed?\n");
break;
default:
- pr_warn_ratelimited("Rx status %d\n", status);
+ if (net_ratelimit())
+ netdev_warn(netdev, "Rx status %d\n", status);
break;
}
@@ -1002,7 +1004,8 @@ static void write_bulk_callback(struct urb *urb)
stats = rtl8152_get_stats(tp->netdev);
if (status) {
- pr_warn_ratelimited("Tx status %d\n", status);
+ if (net_ratelimit())
+ netdev_warn(tp->netdev, "Tx status %d\n", status);
stats->tx_errors += agg->skb_num;
} else {
stats->tx_packets += agg->skb_num;
@@ -1079,7 +1082,7 @@ resubmit:
netif_device_detach(tp->netdev);
else if (res)
netif_err(tp, intr, tp->netdev,
- "can't resubmit intr, status %d\n", res);
+ "can't resubmit intr, status %d\n", res);
}
static inline void *rx_agg_align(void *data)
@@ -1490,7 +1493,7 @@ static void rtl8152_tx_timeout(struct net_device *netdev)
struct r8152 *tp = netdev_priv(netdev);
int i;
- netif_warn(tp, tx_err, netdev, "Tx timeout.\n");
+ netif_warn(tp, tx_err, netdev, "Tx timeout\n");
for (i = 0; i < RTL8152_MAX_TX; i++)
usb_unlink_urb(tp->tx_info[i].urb);
}
@@ -2284,8 +2287,8 @@ static int rtl8152_open(struct net_device *netdev)
if (res) {
if (res == -ENODEV)
netif_device_detach(tp->netdev);
- netif_warn(tp, ifup, netdev,
- "intr_urb submit failed: %d\n", res);
+ netif_warn(tp, ifup, netdev, "intr_urb submit failed: %d\n",
+ res);
return res;
}
@@ -2751,7 +2754,7 @@ static int rtl8152_probe(struct usb_interface *intf,
netdev = alloc_etherdev(sizeof(struct r8152));
if (!netdev) {
- dev_err(&intf->dev, "Out of memory");
+ dev_err(&intf->dev, "Out of memory\n");
return -ENOMEM;
}
@@ -2760,7 +2763,7 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->msg_enable = 0x7FFF;
if (!rtl_ops_init(tp, id)) {
- netif_err(tp, probe, netdev, "Unknown Device");
+ netif_err(tp, probe, netdev, "Unknown Device\n");
return -ENODEV;
}
@@ -2797,11 +2800,11 @@ static int rtl8152_probe(struct usb_interface *intf,
ret = register_netdev(netdev);
if (ret != 0) {
- netif_err(tp, probe, netdev, "couldn't register the device");
+ netif_err(tp, probe, netdev, "couldn't register the device\n");
goto out1;
}
- netif_info(tp, probe, netdev, "%s", DRIVER_VERSION);
+ netif_info(tp, probe, netdev, "%s\n", DRIVER_VERSION);
return 0;
^ permalink raw reply related
* Re: [PATCH 03/12] netfilter: nfnetlink_queue: enable UID/GID socket info retrieval
From: David Miller @ 2014-01-06 18:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: pablo, valentina.giusti, netfilter-devel, netdev
In-Reply-To: <1389022353.12212.176.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 06 Jan 2014 07:32:33 -0800
> net/netfilter/nfnetlink_queue_core.c: In function 'nfqnl_put_sk_uidgid':
> net/netfilter/nfnetlink_queue_core.c:304:35: error: 'TCP_TIME_WAIT' undeclared (first use in this function)
> net/netfilter/nfnetlink_queue_core.c:304:35: note: each undeclared identifier is reported only once for each function it appears in
> make[3]: *** [net/netfilter/nfnetlink_queue_core.o] Error 1
>
> Fix is obvious (#include <net/tcp_states.h>), but I have to run...
I just committed the following:
====================
[PATCH] netfilter: Fix build failure in nfnetlink_queue_core.c.
net/netfilter/nfnetlink_queue_core.c: In function 'nfqnl_put_sk_uidgid':
net/netfilter/nfnetlink_queue_core.c:304:35: error: 'TCP_TIME_WAIT' undeclared (first use in this function)
net/netfilter/nfnetlink_queue_core.c:304:35: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [net/netfilter/nfnetlink_queue_core.o] Error 1
Just a missing include of net/tcp_states.h
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/netfilter/nfnetlink_queue_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netfilter/nfnetlink_queue_core.c b/net/netfilter/nfnetlink_queue_core.c
index d3cf12b..b5e1f82 100644
--- a/net/netfilter/nfnetlink_queue_core.c
+++ b/net/netfilter/nfnetlink_queue_core.c
@@ -29,6 +29,7 @@
#include <linux/netfilter/nfnetlink_queue.h>
#include <linux/list.h>
#include <net/sock.h>
+#include <net/tcp_states.h>
#include <net/netfilter/nf_queue.h>
#include <net/netns/generic.h>
#include <net/netfilter/nfnetlink_queue.h>
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 00/13] nftables updates for net-next
From: David Miller @ 2014-01-06 18:30 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1389016002-9116-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 6 Jan 2014 14:46:29 +0100
> The following patchset contains nftables updates for your net-next tree,
> they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nftables.git master
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [net-next 00/15][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2014-01-06 18:26 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1389011436-18424-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 6 Jan 2014 04:30:21 -0800
> This series contains updates to i40e only.
...
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, please make sure the coding style feedback does actually
get addressed.
Thanks Jeff.
^ permalink raw reply
* Re: [PATCH V1 net-next 2/2] net: Add UDP GRO support for vxlan traffic
From: Or Gerlitz @ 2014-01-06 18:13 UTC (permalink / raw)
To: Tom Herbert
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
Linux Netdev List, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CA+mtBx_B+7CU3GDiod+n7tHfwBcA_3DEhD7tvPYhsZMebiwY8w@mail.gmail.com>
On Mon, Jan 6, 2014 at 6:50 PM, Tom Herbert <therbert@google.com> wrote:
> I think this would be a good start. We can further optimize the encap
> path later on.
good, did you had the chance to look on the 2nd problem I was facing,
e.g how to prevent gro-ing encapsulated VM (this issue will not happen
for non-virtualization schemes, I think) udp packets which happen to
carry a destination port which belongs to an encapsulation protocol?
as I wrote earlier here, I was thinking to add some field to struct
napi_gro_cb which will be zeroed when the gro stacks starts to work on
the skb and set once we pass udp_gro_receive, such that if we arrive
again to udp_gro_recieve and this field is set, which means the
encapsulated
packet is udp one, we flush.
^ permalink raw reply
* RE: [net-next 08/15] i40e: acknowledge VFLR when disabling SR-IOV
From: Williams, Mitch A @ 2014-01-06 18:10 UTC (permalink / raw)
To: Sergei Shtylyov, Kirsher, Jeffrey T, Rose, Gregory V
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com, Brandeburg, Jesse
In-Reply-To: <52CADD2C.2090103@cogentembedded.com>
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
> Sent: Monday, January 06, 2014 8:43 AM
> To: Kirsher, Jeffrey T; Williams, Mitch A
> Cc: davem@davemloft.net; netdev@vger.kernel.org; gospo@redhat.com;
> sassmann@redhat.com; Brandeburg, Jesse
> Subject: Re: [net-next 08/15] i40e: acknowledge VFLR when disabling SR-IOV
>
> On 06.01.2014 16:30, Jeff Kirsher wrote:
>
> > From: Mitch Williams <mitch.a.williams@intel.com>
>
> > When SR-IOV is disabled, the (now nonexistent) virtual function
> > devices undergo a VFLR event. We don't need to handle this event
> > because the VFs are gone, but we do need to tell the HW that they are
> > complete. This fixes an issue with a phantom VFLR and broken VFs when
> > SR-IOV is re-enabled.
>
> > Change-Id: I7580b49ded0158172a85b14661ec212af77000c8
> > Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> > Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > Tested-by: Sibai Li <sibai.li@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 15 +++++++++++++--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
>
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> > index f92404c..e91f9d7 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> [...]
> > @@ -748,8 +750,17 @@ void i40e_free_vfs(struct i40e_pf *pf)
> > kfree(pf->vf);
> > pf->vf = NULL;
> >
> > - if (!i40e_vfs_are_assigned(pf))
> > + if (!i40e_vfs_are_assigned(pf)) {
> > pci_disable_sriov(pf->pdev);
> > + /* Acknowledge VFLR for all VFS. Without this, VFs will fail to
> > + * work correctly when SR-IOV gets re-enabled.
> > + */
> > + for (vf_id = 0; vf_id < tmp; vf_id++) {
> > + reg_idx = (hw->func_caps.vf_base_id + vf_id) / 32;
> > + bit_idx = (hw->func_caps.vf_base_id + vf_id) % 32;
> > + wr32(hw, I40E_GLGEN_VFLRSTAT(reg_idx), (1 << bit_idx));
> > + }
> > + }
> > else
>
> } and *else* should be on the same line. And the *else* arm should also
> have {} now.
>
> > dev_warn(&pf->pdev->dev,
> > "unable to disable SR-IOV because VFs are assigned.\n");
>
> WBR, Sergei
You are absolutely correct, Sergei, and I apologize for not seeing this before I submitted the patch.
There will be a patch coming from Greg Rose in the next few weeks that will fix this problem in the process of adding a bug fix. Since this is just cosmetic, would it be all right with you if we just wait for Greg's patch to come through?
-Mitch
^ permalink raw reply
* Re: [PATCH 0/3] be2net: patch set
From: David Miller @ 2014-01-06 18:10 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1388993545-25634-1-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Mon, 6 Jan 2014 13:02:22 +0530
> Pls apply the following bug fixes to the 'net' tree. Thanks.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: nf_conntrack: release conntrack from rcu callback
From: Cyrill Gorcunov @ 2014-01-06 18:09 UTC (permalink / raw)
To: Florian Westphal
Cc: Andrey Vagin, netfilter-devel, netfilter, coreteam, netdev,
linux-kernel, vvs, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller
In-Reply-To: <20140106172130.GA2360@moon>
On Mon, Jan 06, 2014 at 09:21:30PM +0400, Cyrill Gorcunov wrote:
>
> No? Or there something obvious I'm missing?
Drop my assumption, it can't happen (iow either dying bit is set,
either it clean but tuple can't match then).
^ permalink raw reply
* Re: [PATCH net] ipv6: don't install anycast address for /128 addresses on routers
From: François-Xavier Le Bail @ 2014-01-06 18:06 UTC (permalink / raw)
To: netdev, Hannes Frederic Sowa; +Cc: thaller, jiri
In-Reply-To: <20140106165314.GC10204@order.stressinduktion.org>
On Mon, 1/6/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> It does not make sense to create an anycast address for an /128-prefix.
> Suppress it.
Exact !
BR,
François-Xavier
^ permalink raw reply
* [PATCH net-next] vxlan: keep original skb ownership
From: Eric Dumazet @ 2014-01-06 17:54 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev, edumazet, stephen
In-Reply-To: <1387803413-22152-1-git-send-email-sathya.perla@emulex.com>
From: Eric Dumazet <edumazet@google.com>
Sathya Perla posted a patch trying to address following problem :
<quote>
The vxlan driver sets itself as the socket owner for all the TX flows
it encapsulates (using vxlan_set_owner()) and assigns it's own skb
destructor. This causes all tunneled traffic to land up on only one TXQ
as all encapsulated skbs refer to the vxlan socket and not the original
socket. Also, the vxlan skb destructor breaks some functionality for
tunneled traffic like wmem accounting and as TCP small queues and
FQ/pacing packet scheduler.
</quote>
I reworked Sathya patch and added some explanations.
vxlan_xmit() can avoid one skb_clone()/dev_kfree_skb() pair
and gain better drop monitor accuracy, by calling kfree_skb() when
appropriate.
The UDP socket used by vxlan to perform encapsulation of xmit packets
do not need to be alive while packets leave vxlan code. Its better
to keep original socket ownership to get proper feedback from qdisc and
NIC layers.
We use skb->sk to
A) control amount of bytes/packets queued on behalf of a socket, but
prior vxlan code did the skb->sk transfert without any limit/control
on vxlan socket sk_sndbuf.
B) security purposes (as selinux) or netfilter uses, and I do not think
anything is prepared to handle vxlan stacked case in this area.
By not changing ownership, vxlan tunnels behave like other tunnels.
As Stephen mentioned, we might do the same change in L2TP.
Reported-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/vxlan.c | 31 ++++++++++---------------------
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 474a99ed0222..ab2e92eec949 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1381,20 +1381,6 @@ static bool route_shortcircuit(struct net_device *dev, struct sk_buff *skb)
return false;
}
-static void vxlan_sock_put(struct sk_buff *skb)
-{
- sock_put(skb->sk);
-}
-
-/* On transmit, associate with the tunnel socket */
-static void vxlan_set_owner(struct sock *sk, struct sk_buff *skb)
-{
- skb_orphan(skb);
- sock_hold(sk);
- skb->sk = sk;
- skb->destructor = vxlan_sock_put;
-}
-
/* Compute source port for outgoing packet
* first choice to use L4 flow hash since it will spread
* better and maybe available from hardware
@@ -1514,8 +1500,6 @@ static int vxlan6_xmit_skb(struct vxlan_sock *vs,
ip6h->daddr = *daddr;
ip6h->saddr = *saddr;
- vxlan_set_owner(vs->sock->sk, skb);
-
err = handle_offloads(skb);
if (err)
return err;
@@ -1572,8 +1556,6 @@ int vxlan_xmit_skb(struct vxlan_sock *vs,
uh->len = htons(skb->len);
uh->check = 0;
- vxlan_set_owner(vs->sock->sk, skb);
-
err = handle_offloads(skb);
if (err)
return err;
@@ -1786,7 +1768,7 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
struct vxlan_dev *vxlan = netdev_priv(dev);
struct ethhdr *eth;
bool did_rsc = false;
- struct vxlan_rdst *rdst;
+ struct vxlan_rdst *rdst, *fdst = NULL;
struct vxlan_fdb *f;
skb_reset_mac_header(skb);
@@ -1828,7 +1810,7 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
vxlan_fdb_miss(vxlan, eth->h_dest);
dev->stats.tx_dropped++;
- dev_kfree_skb(skb);
+ kfree_skb(skb);
return NETDEV_TX_OK;
}
}
@@ -1836,12 +1818,19 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
list_for_each_entry_rcu(rdst, &f->remotes, list) {
struct sk_buff *skb1;
+ if (!fdst) {
+ fdst = rdst;
+ continue;
+ }
skb1 = skb_clone(skb, GFP_ATOMIC);
if (skb1)
vxlan_xmit_one(skb1, dev, rdst, did_rsc);
}
- dev_kfree_skb(skb);
+ if (fdst)
+ vxlan_xmit_one(skb, dev, fdst, did_rsc);
+ else
+ kfree_skb(skb);
return NETDEV_TX_OK;
}
^ permalink raw reply related
* Re: [PATCH 1/1] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes
From: Jiri Pirko @ 2014-01-06 17:38 UTC (permalink / raw)
To: Thomas Haller; +Cc: Hannes Frederic Sowa, netdev, stephen, dcbw
In-Reply-To: <1389029375-17698-1-git-send-email-thaller@redhat.com>
Mon, Jan 06, 2014 at 06:29:35PM CET, thaller@redhat.com wrote:
>When adding/modifying an IPv6 address, the userspace application needs
>a way to suppress adding a prefix route. This is for example relevant
>together with IFA_F_MANAGERTEMPADDR, where userspace creates autoconf
>generated addresses, but depending on on-link, no route should for the
>prefix should be added.
>
>This flag will not be set as ifa_flags of the address, it is only
>considered as parameter while adding/modifying an address.
>
>Signed-off-by: Thomas Haller <thaller@redhat.com>
>---
> Hi, how about this?
>
> The flag is only a parameter for the netlink command.
> This might be unexpected, because when adding an address,
> you won't see the flag in `ip -6 addr`.
> Still, I think, it is better to do it this way, because having
> an address with the NOPREFIXROUTE flag, does not mean, that
> there is no route for this prefix. It only means, that at the
> moment of setting the address, no route was added.
>
> The alternative would be, not to add a prefix route, when
> IFA_F_MANAGERTEMPADDR is set.
>
> Thomas
>
> include/uapi/linux/if_addr.h | 1 +
> net/ipv6/addrconf.c | 19 +++++++++++++------
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
>diff --git a/include/uapi/linux/if_addr.h b/include/uapi/linux/if_addr.h
>index cfed10b..dea10a8 100644
>--- a/include/uapi/linux/if_addr.h
>+++ b/include/uapi/linux/if_addr.h
>@@ -49,6 +49,7 @@ enum {
> #define IFA_F_TENTATIVE 0x40
> #define IFA_F_PERMANENT 0x80
> #define IFA_F_MANAGETEMPADDR 0x100
>+#define IFA_F_NOPREFIXROUTE 0x200
>
> struct ifa_cacheinfo {
> __u32 ifa_prefered;
>diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>index 6c16345..51bd757 100644
>--- a/net/ipv6/addrconf.c
>+++ b/net/ipv6/addrconf.c
>@@ -2429,12 +2429,16 @@ static int inet6_addr_add(struct net *net, int ifindex,
> prefered_lft = timeout;
> }
>
>- ifp = ipv6_add_addr(idev, pfx, peer_pfx, plen, scope, ifa_flags,
>+ ifp = ipv6_add_addr(idev, pfx, peer_pfx, plen, scope,
>+ ifa_flags & ~IFA_F_NOPREFIXROUTE,
> valid_lft, prefered_lft);
>
> if (!IS_ERR(ifp)) {
>- addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev,
>- expires, flags);
>+ if (ifa_flags & IFA_F_NOPREFIXROUTE == 0) {
if (!(ifa_flags & IFA_F_NOPREFIXROUTE)) {
>+ addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev,
>+ expires, flags);
>+ }
>+
> /*
> * Note that section 3.1 of RFC 4429 indicates
> * that the Optimistic flag should not be set for
>@@ -3662,8 +3666,10 @@ static int inet6_addr_modify(struct inet6_ifaddr *ifp, u32 ifa_flags,
> if (!(ifp->flags&IFA_F_TENTATIVE))
> ipv6_ifa_notify(0, ifp);
>
>- addrconf_prefix_route(&ifp->addr, ifp->prefix_len, ifp->idev->dev,
>- expires, flags);
>+ if (ifa_flags & IFA_F_NOPREFIXROUTE == 0) {
>+ addrconf_prefix_route(&ifp->addr, ifp->prefix_len, ifp->idev->dev,
>+ expires, flags);
>+ }
>
> if (was_managetempaddr || ifp->flags & IFA_F_MANAGETEMPADDR) {
> if (was_managetempaddr && !(ifp->flags & IFA_F_MANAGETEMPADDR))
>@@ -3717,7 +3723,8 @@ inet6_rtm_newaddr(struct sk_buff *skb, struct nlmsghdr *nlh)
> ifa_flags = tb[IFA_FLAGS] ? nla_get_u32(tb[IFA_FLAGS]) : ifm->ifa_flags;
>
> /* We ignore other flags so far. */
>- ifa_flags &= IFA_F_NODAD | IFA_F_HOMEADDRESS | IFA_F_MANAGETEMPADDR;
>+ ifa_flags &= IFA_F_NODAD | IFA_F_HOMEADDRESS | IFA_F_MANAGETEMPADDR |
>+ IFA_F_NOPREFIXROUTE;
>
> ifa = ipv6_get_ifaddr(net, pfx, dev, 1);
> if (ifa == NULL) {
>--
>1.8.4.2
>
^ permalink raw reply
* [PATCH net-next] tcp: out_of_order_queue do not use its lock
From: Eric Dumazet @ 2014-01-06 17:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
TCP out_of_order_queue lock is not used, as queue manipulation
happens with socket lock held and we therefore use the lockless
skb queue routines (as __skb_queue_head())
We can use __skb_queue_head_init() instead of skb_queue_head_init()
to make this more consistent.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/tcp.h | 5 ++++-
net/ipv4/tcp.c | 2 +-
net/ipv4/tcp_minisocks.c | 2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index d68633452d9b..4ad0706d40eb 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -248,7 +248,10 @@ struct tcp_sock {
struct sk_buff* lost_skb_hint;
struct sk_buff *retransmit_skb_hint;
- struct sk_buff_head out_of_order_queue; /* Out of order segments go here */
+ /* OOO segments go in this list. Note that socket lock must be held,
+ * as we do not use sk_buff_head lock.
+ */
+ struct sk_buff_head out_of_order_queue;
/* SACKs data, these 2 need to be together (see tcp_options_write) */
struct tcp_sack_block duplicate_sack[1]; /* D-SACK block */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index d099f9a055c6..e2a40515e665 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -381,7 +381,7 @@ void tcp_init_sock(struct sock *sk)
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
- skb_queue_head_init(&tp->out_of_order_queue);
+ __skb_queue_head_init(&tp->out_of_order_queue);
tcp_init_xmit_timers(sk);
tcp_prequeue_init(tp);
INIT_LIST_HEAD(&tp->tsq_node);
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 97b684159861..3aa9e3247991 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -425,7 +425,7 @@ struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req,
tcp_set_ca_state(newsk, TCP_CA_Open);
tcp_init_xmit_timers(newsk);
- skb_queue_head_init(&newtp->out_of_order_queue);
+ __skb_queue_head_init(&newtp->out_of_order_queue);
newtp->write_seq = newtp->pushed_seq = treq->snt_isn + 1;
newtp->rx_opt.saw_tstamp = 0;
^ permalink raw reply related
* [PATCH 1/1] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes
From: Thomas Haller @ 2014-01-06 17:29 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Jiri Pirko, netdev, stephen, dcbw, Thomas Haller
In-Reply-To: <20140106160139.GB10204@order.stressinduktion.org>
When adding/modifying an IPv6 address, the userspace application needs
a way to suppress adding a prefix route. This is for example relevant
together with IFA_F_MANAGERTEMPADDR, where userspace creates autoconf
generated addresses, but depending on on-link, no route should for the
prefix should be added.
This flag will not be set as ifa_flags of the address, it is only
considered as parameter while adding/modifying an address.
Signed-off-by: Thomas Haller <thaller@redhat.com>
---
Hi, how about this?
The flag is only a parameter for the netlink command.
This might be unexpected, because when adding an address,
you won't see the flag in `ip -6 addr`.
Still, I think, it is better to do it this way, because having
an address with the NOPREFIXROUTE flag, does not mean, that
there is no route for this prefix. It only means, that at the
moment of setting the address, no route was added.
The alternative would be, not to add a prefix route, when
IFA_F_MANAGERTEMPADDR is set.
Thomas
include/uapi/linux/if_addr.h | 1 +
net/ipv6/addrconf.c | 19 +++++++++++++------
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/if_addr.h b/include/uapi/linux/if_addr.h
index cfed10b..dea10a8 100644
--- a/include/uapi/linux/if_addr.h
+++ b/include/uapi/linux/if_addr.h
@@ -49,6 +49,7 @@ enum {
#define IFA_F_TENTATIVE 0x40
#define IFA_F_PERMANENT 0x80
#define IFA_F_MANAGETEMPADDR 0x100
+#define IFA_F_NOPREFIXROUTE 0x200
struct ifa_cacheinfo {
__u32 ifa_prefered;
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 6c16345..51bd757 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2429,12 +2429,16 @@ static int inet6_addr_add(struct net *net, int ifindex,
prefered_lft = timeout;
}
- ifp = ipv6_add_addr(idev, pfx, peer_pfx, plen, scope, ifa_flags,
+ ifp = ipv6_add_addr(idev, pfx, peer_pfx, plen, scope,
+ ifa_flags & ~IFA_F_NOPREFIXROUTE,
valid_lft, prefered_lft);
if (!IS_ERR(ifp)) {
- addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev,
- expires, flags);
+ if (ifa_flags & IFA_F_NOPREFIXROUTE == 0) {
+ addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev,
+ expires, flags);
+ }
+
/*
* Note that section 3.1 of RFC 4429 indicates
* that the Optimistic flag should not be set for
@@ -3662,8 +3666,10 @@ static int inet6_addr_modify(struct inet6_ifaddr *ifp, u32 ifa_flags,
if (!(ifp->flags&IFA_F_TENTATIVE))
ipv6_ifa_notify(0, ifp);
- addrconf_prefix_route(&ifp->addr, ifp->prefix_len, ifp->idev->dev,
- expires, flags);
+ if (ifa_flags & IFA_F_NOPREFIXROUTE == 0) {
+ addrconf_prefix_route(&ifp->addr, ifp->prefix_len, ifp->idev->dev,
+ expires, flags);
+ }
if (was_managetempaddr || ifp->flags & IFA_F_MANAGETEMPADDR) {
if (was_managetempaddr && !(ifp->flags & IFA_F_MANAGETEMPADDR))
@@ -3717,7 +3723,8 @@ inet6_rtm_newaddr(struct sk_buff *skb, struct nlmsghdr *nlh)
ifa_flags = tb[IFA_FLAGS] ? nla_get_u32(tb[IFA_FLAGS]) : ifm->ifa_flags;
/* We ignore other flags so far. */
- ifa_flags &= IFA_F_NODAD | IFA_F_HOMEADDRESS | IFA_F_MANAGETEMPADDR;
+ ifa_flags &= IFA_F_NODAD | IFA_F_HOMEADDRESS | IFA_F_MANAGETEMPADDR |
+ IFA_F_NOPREFIXROUTE;
ifa = ipv6_get_ifaddr(net, pfx, dev, 1);
if (ifa == NULL) {
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH] netfilter: nf_conntrack: release conntrack from rcu callback
From: Cyrill Gorcunov @ 2014-01-06 17:21 UTC (permalink / raw)
To: Florian Westphal
Cc: Andrey Vagin, netfilter-devel, netfilter, coreteam, netdev,
linux-kernel, vvs, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller
In-Reply-To: <20140106170235.GJ28854@breakpoint.cc>
On Mon, Jan 06, 2014 at 06:02:35PM +0100, Florian Westphal wrote:
>
> Can you elaborate?
> Yes, nf_ct_is_dying(ct) might be called for the wrong conntrack.
>
> But, in case we _think_ that its the right one we call
> nf_ct_tuple_equal() to verify we indeed found the right one:
>
> h = ____nf_conntrack_find(net, zone, tuple, hash);
> if (h) { // might be released right now, but page won't go away (SLAB_BY_RCU)
> ct = nf_ct_tuplehash_to_ctrack(h);
> if (unlikely(nf_ct_is_dying(ct) ||
> !atomic_inc_not_zero(&ct->ct_general.use)))
> // which means we should hit this path (0 ref).
> h = NULL;
> else {
> // otherwise, it cannot go away from under us, since
> // we own a reference now.
> if (unlikely(!nf_ct_tuple_equal(tuple, &h->tuple) ||
> nf_ct_zone(ct) != zone)) {
> // if we get here, the entry got recycled on other cpu
> // for a different tuple, we can bail out and drop
> // the reference safely and re-try the lookup
> nf_ct_put(ct);
> goto begin;
> }
> }
I think tuple may match if
task 1 task 2 task 3
nf_conntrack_find_get
____nf_conntrack_find
destroy_conntrack
hlist_nulls_del_rcu
nf_conntrack_free
kmem_cache_free
__nf_conntrack_alloc
kmem_cache_alloc
if (nf_ct_is_dying(ct))
data is not yet cleaned
memset(&ct->tuplehash[IP_CT_DIR_MAX],
No? Or there something obvious I'm missing?
^ permalink raw reply
* Re: Possible to add netfilter hooks to IFB driver?
From: Alban Crequy @ 2014-01-06 17:18 UTC (permalink / raw)
To: Brad Johnson; +Cc: netdev
In-Reply-To: <522653F1.6090902@ecessa.com>
On Tue, 03 Sep 2013 16:26:09 -0500
Brad Johnson <bjohnson@ecessa.com> wrote:
> I would like to add netfilter hooks to the IFB driver so I can do
> iptables -j IFB (just like we can with IMQ). But I would like to know
> first if there are any reasons this can not work. Please advise if
> this is possible, and if so any tips would be appreciated.
I would like to have the same feature for ingress shaping via
connection marking. But this page says "wont go back to putting
netfilter hooks" but have a "contrack related action":
http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb
http://thread.gmane.org/gmane.linux.network/21224
I don't know if someone made a patch for either implementation.
Best regards,
Alban
^ permalink raw reply
* Re: [PATCH net-next] net: netdev_kobject_init: annotate with __init
From: Sergei Shtylyov @ 2014-01-06 17:13 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <52CAD74B.6070602@redhat.com>
On 06.01.2014 20:18, Daniel Borkmann wrote:
>>> netdev_kobject_init() is only being called from __init context,
>>> that is, net_dev_init(), so annotate it with __init as well, thus
>>> the kernel can take this as a hint that the function is used only
>>> during the initialization phase and free up used memory resources
>>> after its invocation.
>>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> [...]
>>> diff --git a/net/core/net-sysfs.h b/net/core/net-sysfs.h
>>> index bd7751e..2745a1b 100644
>>> --- a/net/core/net-sysfs.h
>>> +++ b/net/core/net-sysfs.h
>>> @@ -1,7 +1,7 @@
>>> #ifndef __NET_SYSFS_H__
>>> #define __NET_SYSFS_H__
>>>
>>> -int netdev_kobject_init(void);
>>> +int __init netdev_kobject_init(void);
>> There's no need to also annotate function prototype.
> Hm, is that general convention?
More or less, though I've seen some prototypes annotated.
> Having this in a header file
> annotated (even if not strictly necessary) would probably
> better prevent from possible misuse resp. section mismatches
> if people forget to look into the actual c file where the
> function is being defined.
Dunno about vi users, I'm using Alt-. in EMACS when I want to find a
function, and it gets me right to the definition, not the prototype.
>> WBR, Sergei
PS: The patch was merged already, so my comment seems to have been posted too
late anyway.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] netfilter: nf_conntrack: release conntrack from rcu callback
From: Florian Westphal @ 2014-01-06 17:02 UTC (permalink / raw)
To: Andrey Vagin
Cc: netfilter-devel, netfilter, coreteam, netdev, linux-kernel, vvs,
Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller, Cyrill Gorcunov
In-Reply-To: <1389023672-14351-1-git-send-email-avagin@openvz.org>
Andrey Vagin <avagin@openvz.org> wrote:
> Lets look at destroy_conntrack:
>
> hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
> ...
> nf_conntrack_free(ct)
> kmem_cache_free(net->ct.nf_conntrack_cachep, ct);
>
> The hash is protected by rcu, so readers look up conntracks without
> locks.
> A conntrack is removed from the hash, but in this moment a few readers
> still can use the conntrack, so if we call kmem_cache_free now, all
> readers will read released object.
>
> Bellow you can find more tricky race condition of three tasks.
>
> task 1 task 2 task 3
> nf_conntrack_find_get
> ____nf_conntrack_find
> destroy_conntrack
> hlist_nulls_del_rcu
> nf_conntrack_free
> kmem_cache_free
> __nf_conntrack_alloc
> kmem_cache_alloc
> memset(&ct->tuplehash[IP_CT_DIR_MAX],
> if (nf_ct_is_dying(ct))
>
> In this case the task 2 will not understand, that it uses a wrong
> conntrack.
Can you elaborate?
Yes, nf_ct_is_dying(ct) might be called for the wrong conntrack.
But, in case we _think_ that its the right one we call
nf_ct_tuple_equal() to verify we indeed found the right one:
h = ____nf_conntrack_find(net, zone, tuple, hash);
if (h) { // might be released right now, but page won't go away (SLAB_BY_RCU)
ct = nf_ct_tuplehash_to_ctrack(h);
if (unlikely(nf_ct_is_dying(ct) ||
!atomic_inc_not_zero(&ct->ct_general.use)))
// which means we should hit this path (0 ref).
h = NULL;
else {
// otherwise, it cannot go away from under us, since
// we own a reference now.
if (unlikely(!nf_ct_tuple_equal(tuple, &h->tuple) ||
nf_ct_zone(ct) != zone)) {
// if we get here, the entry got recycled on other cpu
// for a different tuple, we can bail out and drop
// the reference safely and re-try the lookup
nf_ct_put(ct);
goto begin;
}
}
^ permalink raw reply
* Re: [PATCH net-next] bonding: fix kstrtou8() return value verification in num_peer_notif
From: Scott Feldman @ 2014-01-06 17:02 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Netdev, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <1389005680-9063-1-git-send-email-vfalico@redhat.com>
On Jan 6, 2014, at 2:54 AM, Veaceslav Falico <vfalico@redhat.com> wrote:
> It returns 0 in case of success, !0 error otherwise. Fix the improper error
> verification.
>
> Fixes: 2c9839c143bbc ("bonding: add num_grat_arp attribute netlink support")
> CC: sfeldma@cumulusnetworks.com
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
> ---
> drivers/net/bonding/bond_sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
> index 9a1ea4a..011f163 100644
> --- a/drivers/net/bonding/bond_sysfs.c
> +++ b/drivers/net/bonding/bond_sysfs.c
> @@ -776,7 +776,7 @@ static ssize_t bonding_store_num_peer_notif(struct device *d,
> int ret;
>
> ret = kstrtou8(buf, 10, &new_value);
> - if (!ret) {
> + if (ret) {
> pr_err("%s: invalid value %s specified.\n",
> bond->dev->name, buf);
> return ret;
> --
> 1.8.4
Thanks!
Acked-by: Scott Feldman <sfeldma@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH 1/6][v3] phylib: Add Clause 45 read/write functions
From: Florian Fainelli @ 2014-01-06 16:55 UTC (permalink / raw)
To: Shaohui Xie
Cc: shh.xie@gmail.com, davem@davemloft.net, jg1.han@samsung.com,
mugunthanvnm@ti.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <51bdf0e57ba941bf92b1d969631e440b@BLUPR03MB067.namprd03.prod.outlook.com>
2014/1/5 Shaohui Xie <Shaohui.Xie@freescale.com>:
> Hi, All,
>
> I saw the state of this patch sets were set to "Deferred", may I know if there is any plan or request for these patches, or is there a big picture for supporting 10G PHYs?
Can you resubmit the latest version of the patchset, I somehow lost
track of which version is the last one, this would bring a new
patchset in patchwork for David to review.
>
> Best Regards,
> Shaohui Xie
>
>
>> -----Original Message-----
>> From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
>> Sent: Friday, November 29, 2013 1:45 PM
>> To: davem@davemloft.net; jg1.han@samsung.com; mugunthanvnm@ti.com;
>> f.fainelli@gmail.com; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org
>> Cc: Xie Shaohui-B21989
>> Subject: [PATCH 1/6][v3] phylib: Add Clause 45 read/write functions
>>
>> From: Andy Fleming <afleming@freescale.com>
>>
>> Need an extra parameter to read or write Clause 45 PHYs, so need a
>> different API with the extra parameter.
>>
>> Signed-off-by: Andy Fleming <afleming@freescale.com>
>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>> ---
>> v3 changes: add C45 check.
>>
>> include/linux/phy.h | 39 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 39 insertions(+)
>>
>> diff --git a/include/linux/phy.h b/include/linux/phy.h index
>> 48a4dc3..0ff2476 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -498,6 +498,24 @@ static inline int phy_read(struct phy_device *phydev,
>> u32 regnum) }
>>
>> /**
>> + * phy_read_mmd - Convenience function for reading a register
>> + * from an MMD on a given PHY.
>> + * @phydev: The phy_device struct
>> + * @devad: The MMD to read from
>> + * @regnum: The register on the MMD to read
>> + *
>> + * Same rules as for phy_read();
>> + */
>> +static inline int phy_read_mmd(struct phy_device *phydev, int devad,
>> +u32 regnum) {
>> + if (!phydev->is_c45)
>> + return -EOPNOTSUPP;
>> +
>> + return mdiobus_read(phydev->bus, phydev->addr,
>> + MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff)); }
>> +
>> +/**
>> * phy_write - Convenience function for writing a given PHY register
>> * @phydev: the phy_device struct
>> * @regnum: register number to write
>> @@ -533,6 +551,27 @@ static inline bool phy_is_internal(struct phy_device
>> *phydev)
>> return phydev->is_internal;
>> }
>>
>> +/**
>> + * phy_write_mmd - Convenience function for writing a register
>> + * on an MMD on a given PHY.
>> + * @phydev: The phy_device struct
>> + * @devad: The MMD to read from
>> + * @regnum: The register on the MMD to read
>> + * @val: value to write to @regnum
>> + *
>> + * Same rules as for phy_write();
>> + */
>> +static inline int phy_write_mmd(struct phy_device *phydev, int devad,
>> + u32 regnum, u16 val)
>> +{
>> + if (!phydev->is_c45)
>> + return -EOPNOTSUPP;
>> +
>> + regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0xffff);
>> +
>> + return mdiobus_write(phydev->bus, phydev->addr, regnum, val); }
>> +
>> struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int
>> phy_id,
>> bool is_c45, struct phy_c45_device_ids *c45_ids); struct
>> phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
>> --
>> 1.8.4.1
>
--
Florian
^ permalink raw reply
* [PATCH net] ipv6: don't install anycast address for /128 addresses on routers
From: Hannes Frederic Sowa @ 2014-01-06 16:53 UTC (permalink / raw)
To: netdev; +Cc: fx.lebail, thaller, jiri
It does not make sense to create an anycast address for an /128-prefix.
Suppress it.
As 32019e651c6fce ("ipv6: Do not leave router anycast address for /127
prefixes.") shows we also may not leave them, because we could accidentally
remove an anycast address the user has allocated or got added via another
prefix.
Cc: François-Xavier Le Bail <fx.lebail@yahoo.com>
Cc: Thomas Haller <thaller@redhat.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/addrconf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 6c16345..43c8220 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1677,7 +1677,7 @@ void addrconf_leave_solict(struct inet6_dev *idev, const struct in6_addr *addr)
static void addrconf_join_anycast(struct inet6_ifaddr *ifp)
{
struct in6_addr addr;
- if (ifp->prefix_len == 127) /* RFC 6164 */
+ if (ifp->prefix_len >= 127) /* RFC 6164 */
return;
ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len);
if (ipv6_addr_any(&addr))
@@ -1688,7 +1688,7 @@ static void addrconf_join_anycast(struct inet6_ifaddr *ifp)
static void addrconf_leave_anycast(struct inet6_ifaddr *ifp)
{
struct in6_addr addr;
- if (ifp->prefix_len == 127) /* RFC 6164 */
+ if (ifp->prefix_len >= 127) /* RFC 6164 */
return;
ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len);
if (ipv6_addr_any(&addr))
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH net-next] netfilter: nfnetlink_queue: fix compilation problem due missing header
From: Eric Dumazet @ 2014-01-06 16:52 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, davem, netdev
In-Reply-To: <1389026089-4917-1-git-send-email-pablo@netfilter.org>
On Mon, 2014-01-06 at 17:34 +0100, Pablo Neira Ayuso wrote:
> In 08c0cad ("netfilter: nfnetlink_queue: enable UID/GID socket info
> retrieval"), the header that defines TCP_TIME_WAIT.
>
> net/netfilter/nfnetlink_queue_core.c: In function 'nfqnl_put_sk_uidgid':
> net/netfilter/nfnetlink_queue_core.c:304:35: error: 'TCP_TIME_WAIT' undeclared (first use in this function)
> net/netfilter/nfnetlink_queue_core.c:304:35: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [net/netfilter/nfnetlink_queue_core.o] Error 1
>
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
Tested-by: Eric Dumazet <edumazet@google.com>
Thanks Pablo !
^ permalink raw reply
* Re: [PATCH V1 net-next 2/2] net: Add UDP GRO support for vxlan traffic
From: Tom Herbert @ 2014-01-06 16:50 UTC (permalink / raw)
To: Or Gerlitz
Cc: Or Gerlitz, Jerry Chu, Eric Dumazet, Herbert Xu,
Linux Netdev List, David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <CAJZOPZLZNEvao9PxtX78sfpg_4GVamgxNMNU52QQ1aFqAxQDZA@mail.gmail.com>
On Mon, Jan 6, 2014 at 8:38 AM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
> On Mon, Jan 6, 2014 at 3:32 PM, Or Gerlitz <or.gerlitz@gmail.com> wrote:
>> As the GUE RFC states, with UDP encapsulation, the encap protocol is
>> actually derived from the UDP destination port. With that assumption
>> at hand, we can have the udp gro code to export callbacks for upper
>> uncapsulation protocol to install a gro handler which has the
>> following trivial strucure:
>>
>> key = <PORT> data = <gro receive/complete callbacks>
>
>> which plugs nicely into the general framework of the gro stack. The
>> udp gro receive code would act as follows
>> -- if there's no gro handler set for the packet udp dest port, flush
>> - do the normal loop to find match on the packet dest/src udp ports
>> - call the protocol (e.g VXLAN) gro receive callback
>> This would avoid dealing with sockets etc and be very efficient, makes sense?
>
> Or in short -- the destination udp port takes a similar role to the
> ethertype for gro l3 handlers or the ip protocol for gro l4 handlers
> and we enable encapsulating protocols to plug into the existing
> offload_callbacks framework, simple.
I think this would be a good start. We can further optimize the encap
path later on.
^ permalink raw reply
* RE: [BUG] bnx2x : lockdep assertion
From: Eric Dumazet @ 2014-01-06 16:49 UTC (permalink / raw)
To: Ariel Elior
Cc: Yuval Mintz, davem@davemloft.net, netdev@vger.kernel.org,
Michal Kalderon
In-Reply-To: <6AE768456CEC4B4A9B2248CB6B87EB3E1BFBE6A6@SJEXCHMB05.corp.ad.broadcom.com>
On Mon, 2014-01-06 at 16:35 +0000, Ariel Elior wrote:
> Hi Eric,
> This was introduced by the low latency patch which added a 'might_sleep()' to napi_disable a while ago.
> There is a fix in the works.
> Thanks,
Hmm, commit 80c33ddd31d0e801953 is 3 months old.
Do you have an idea of ETA for the fix ?
Thanks !
^ 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