* Fw: [Bug 68821] New: splittcp with tproxy has issues when timestamp is enabled
From: Stephen Hemminger @ 2014-01-16 17:34 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Thu, 16 Jan 2014 05:39:52 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 68821] New: splittcp with tproxy has issues when timestamp is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=68821
Bug ID: 68821
Summary: splittcp with tproxy has issues when timestamp is
enabled
Product: Networking
Version: 2.5
Kernel Version: 3.2
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: shemminger@linux-foundation.org
Reporter: shailendra7479@gmail.com
Regression: No
Hi,
I am having an application which does splittcp with transparency. I have a NAT
box which reuses the 5-tuple frequently. Due to this there is a possibility
that some connections with the same tuple go through our splittcp and some may
go directly to the webserver.
Due to this, the webserver is getting confused and not responding with
SYN-ACKs.
Is there a way to enable transparency in TIMESTAMPs when tproxy is involved for
eg., preserve the incoming timestamp in the outgoing SYN.
Shouldn't the kernel be using the client's timestamp in the outgoing SYNs when
transparency is enabled?
Thanks
Shailendra
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next 2/2] r6040: use ETH_ZLEN instead of MISR for SKB length checking
From: Ben Hutchings @ 2014-01-16 17:33 UTC (permalink / raw)
To: David Laight
Cc: 'Ben Hutchings', Florian Fainelli, netdev@vger.kernel.org,
davem@davemloft.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D45D812@AcuExch.aculab.com>
On Thu, 2014-01-16 at 09:10 +0000, David Laight wrote:
> From: Ben Hutchings
> > On Wed, 2014-01-15 at 13:04 -0800, Florian Fainelli wrote:
> > > Ever since this driver was merged the following code was included:
> ...
> > > - if (skb->len < MISR)
> > > - descptr->len = MISR;
> > > + if (skb->len < ETH_ZLEN)
> > > + descptr->len = ETH_ZLEN;
> >
> > It looks like this is just increasing the TX descriptor length so the
> > packet is tail-padded with whatever happens to come next in the skb.
> > This is absolutely incorrect behaviour and may leak sensitive
> > information.
>
> And possibly page fault if the data is right at the end of a page.
If the CPU was accessing it, it would be fine as the skb linear area
ends with struct skb_shared_info. (sfc actually takes advantage of that
in efx_enqueue_skb_pio() which can add padding (*not* transmitted) to
ensure that the CPU does write-combining.)
But the NIC, if it's connected through an IOMMU, might get a page fault
due to the incorrect length of the DMA mapping.
> > Presumably it is necessary to pad the frame because the MAC is too lame
> > to do it, and the correct way to do that is using skb_padto(skb,
> > ETH_ZLEN). But this may fail as it might have to allocate memory
>
> Alternatively use two ring entries with the 'more' bit set on
> the first one and transmit the padding from a permanently allocated
> and dma-mapped block of zeros.
> Assuming the hardware support SG transmit and doesn't have a
> constraint on the length of the first fragment.
Do you see NETIF_F_SG in this driver?
Ben.
> Or have a pre-allocated an dma-mapped array of short buffers (one
> for each ring slot) and copy short packets into the array instead
> of dma-mapping the skb data.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: ipv6 addrconfg warn_on hit: WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
From: Hannes Frederic Sowa @ 2014-01-16 17:31 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev
In-Reply-To: <20140116172706.GC7961@minipsycho.orion>
On Thu, Jan 16, 2014 at 06:27:06PM +0100, Jiri Pirko wrote:
> Thu, Jan 16, 2014 at 04:18:12PM CET, hannes@stressinduktion.org wrote:
> >On Thu, Jan 16, 2014 at 03:38:17PM +0100, Hannes Frederic Sowa wrote:
> >> On Thu, Jan 16, 2014 at 03:07:01PM +0100, Jiri Pirko wrote:
> >> > Thu, Jan 16, 2014 at 02:53:23PM CET, jiri@resnulli.us wrote:
> >> > >Hi Hannes.
> >> > >
> >> > >WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
> >> > >
> >> > >We did hit once this warning during the tests. The person who hit this
> >> > >says that it was during the setup of many macvlan devices.
> >> > >
> >> > >I examined the code but I'm not sure how this could happen. Looks like a
> >> > >race condition between addrconf_dad_completed() and addrconf_ifdown().
> >> > >Not sure how to easily resolve that though.
> >>
> >> That seems to be the case. Actually we don't need to count precisiely
> >> here, we just must precisiely identify the situation where the first
> >> LL address comes into operational state. Maybe we can implement this
> >> somehow differently. I'll play with the code soon.
> >
> >Maybe something like this and then throw out the whole ll counting stuff:
> >
> >diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> >index 6913a82..105105a 100644
> >--- a/net/ipv6/addrconf.c
> >+++ b/net/ipv6/addrconf.c
> >@@ -3233,6 +3233,19 @@ out:
> > in6_ifa_put(ifp);
> > }
> >
> >+/* idev must be at least read locked */
> >+static bool ipv6_lonely_lladdr(struct inet6_dev *idev, struct inet6_ifaddr *ifp)
> >+{
> >+ bool ret = true;
> >+ struct inet6_ifaddr *ifpiter;
> >+
> >+ list_for_each_entry(ifpiter, &idev->addr_list, if_list) {
> >+ if (ifp != ifpiter && ifpiter->scope == IFA_LINK)
> >+ ret = false;
> >+ }
> >+ return ret;
> >+}
> >+
> > static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
> > {
> > struct net_device *dev = ifp->idev->dev;
> >@@ -3253,8 +3266,7 @@ static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
> >
> > read_lock_bh(&ifp->idev->lock);
> > spin_lock(&ifp->lock);
> >- send_mld = ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL &&
> >- ifp->idev->valid_ll_addr_cnt == 1;
> >+ send_mld = ifp->scope == IFA_LINK && ipv6_lonely_lladdr(ifp->idev, ifp);
> > send_rs = send_mld &&
> > ipv6_accept_ra(ifp->idev) &&
> > ifp->idev->cnf.rtr_solicits > 0 &&
>
> Sounds sane to me. Would you care to submit this please?
> Do not forget to remove all the valid_ll_addr_cnt stuff :)
I'll do. ;) Currently testing the changes.
Thanks,
Hannes
^ permalink raw reply
* Re: ipv6 addrconfg warn_on hit: WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
From: Jiri Pirko @ 2014-01-16 17:27 UTC (permalink / raw)
To: netdev; +Cc: hannes
In-Reply-To: <20140116151812.GI7436@order.stressinduktion.org>
Thu, Jan 16, 2014 at 04:18:12PM CET, hannes@stressinduktion.org wrote:
>On Thu, Jan 16, 2014 at 03:38:17PM +0100, Hannes Frederic Sowa wrote:
>> On Thu, Jan 16, 2014 at 03:07:01PM +0100, Jiri Pirko wrote:
>> > Thu, Jan 16, 2014 at 02:53:23PM CET, jiri@resnulli.us wrote:
>> > >Hi Hannes.
>> > >
>> > >WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
>> > >
>> > >We did hit once this warning during the tests. The person who hit this
>> > >says that it was during the setup of many macvlan devices.
>> > >
>> > >I examined the code but I'm not sure how this could happen. Looks like a
>> > >race condition between addrconf_dad_completed() and addrconf_ifdown().
>> > >Not sure how to easily resolve that though.
>>
>> That seems to be the case. Actually we don't need to count precisiely
>> here, we just must precisiely identify the situation where the first
>> LL address comes into operational state. Maybe we can implement this
>> somehow differently. I'll play with the code soon.
>
>Maybe something like this and then throw out the whole ll counting stuff:
>
>diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>index 6913a82..105105a 100644
>--- a/net/ipv6/addrconf.c
>+++ b/net/ipv6/addrconf.c
>@@ -3233,6 +3233,19 @@ out:
> in6_ifa_put(ifp);
> }
>
>+/* idev must be at least read locked */
>+static bool ipv6_lonely_lladdr(struct inet6_dev *idev, struct inet6_ifaddr *ifp)
>+{
>+ bool ret = true;
>+ struct inet6_ifaddr *ifpiter;
>+
>+ list_for_each_entry(ifpiter, &idev->addr_list, if_list) {
>+ if (ifp != ifpiter && ifpiter->scope == IFA_LINK)
>+ ret = false;
>+ }
>+ return ret;
>+}
>+
> static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
> {
> struct net_device *dev = ifp->idev->dev;
>@@ -3253,8 +3266,7 @@ static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
>
> read_lock_bh(&ifp->idev->lock);
> spin_lock(&ifp->lock);
>- send_mld = ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL &&
>- ifp->idev->valid_ll_addr_cnt == 1;
>+ send_mld = ifp->scope == IFA_LINK && ipv6_lonely_lladdr(ifp->idev, ifp);
> send_rs = send_mld &&
> ipv6_accept_ra(ifp->idev) &&
> ifp->idev->cnf.rtr_solicits > 0 &&
Sounds sane to me. Would you care to submit this please?
Do not forget to remove all the valid_ll_addr_cnt stuff :)
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] virtio-net: initial rx sysfs support, export mergeable rx buffer size
From: Michael Dalton @ 2014-01-16 17:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, lf-virt, Eric Dumazet, David S. Miller
In-Reply-To: <CANJ5vPJZACr=y3uRv0Rnq330jQCi4dLvhyQd88ascZjBg_jfUw@mail.gmail.com>
Sorry, just realized - I think disabling NAPI is necessary but not
sufficient. There is also the issue that refill_work() could be
scheduled. If refill_work() executes, it will re-enable NAPI. We'd need
to cancel the vi->refill delayed work to prevent this AFAICT, and also
ensure that no other function re-schedules vi->refill or re-enables NAPI
(virtnet_open/close, virtnet_set_queues, and virtnet_freeze/restore).
How is the following sequence of operations:
rtnl_lock();
cancel_delayed_work_sync(&vi->refill);
napi_disable(&rq->napi);
read rq->mrg_avg_pkt_len
virtnet_enable_napi();
rtnl_unlock();
Additionally, if we disable NAPI when reading this file, perhaps
the permissions should be changed to 400 so that an unprivileged
user cannot temporarily disable network RX processing by reading these
sysfs files. Does that sound reasonable?
Best,
Mike
^ permalink raw reply
* Re: [PATCH] net: introduce SO_BPF_EXTENSIONS
From: Michal Sekletar @ 2014-01-16 17:26 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, Michael Kerrisk, David Miller
In-Reply-To: <52D80BCA.7030400@redhat.com>
On Thu, Jan 16, 2014 at 05:41:46PM +0100, Daniel Borkmann wrote:
> On 01/16/2014 05:14 PM, Michal Sekletar wrote:
> >userspace packet capturing libraries (e.g. libpcap) don't have a way how to find
> >out which BPF extensions are supported by the kernel, except compiling a filter
> >which uses extensions and trying to apply filter to the socket. This is very
> >inconvenient.
> >
> >Therefore this commit introduces new option which can be used as an argument for
> >getsockopt() and allows one to obtain information about which BPF extensions are
> >supported by the kernel.
> >
> >On Tue, Dec 10, 2013 at 1:25 AM, David Miller <davem@davemloft.net> wrote:
> >
> >>And therefore, you do not need to define any actual bits yet. The
> >>socket option will for now just return "0", and that will mean that
> >>all the extensions Linux implements currently are presnet.
> >
> >Signed-off-by: Michal Sekletar <msekleta@redhat.com>
> >Cc: Michael Kerrisk <mtk.manpages@gmail.com>
> >Cc: Daniel Borkmann <dborkman@redhat.com>
> >Cc: David Miller <davem@davemloft.net>
> >---
> > arch/alpha/include/uapi/asm/socket.h | 2 ++
> > arch/avr32/include/uapi/asm/socket.h | 2 ++
> > arch/cris/include/uapi/asm/socket.h | 2 ++
> > arch/frv/include/uapi/asm/socket.h | 2 ++
> > arch/ia64/include/uapi/asm/socket.h | 2 ++
> > arch/m32r/include/uapi/asm/socket.h | 2 ++
> > arch/mips/include/uapi/asm/socket.h | 2 ++
> > arch/mn10300/include/uapi/asm/socket.h | 2 ++
> > arch/parisc/include/uapi/asm/socket.h | 2 ++
> > arch/powerpc/include/uapi/asm/socket.h | 2 ++
> > arch/s390/include/uapi/asm/socket.h | 2 ++
> > arch/sparc/include/uapi/asm/socket.h | 2 ++
> > arch/xtensa/include/uapi/asm/socket.h | 2 ++
> > include/net/sock.h | 5 +++++
> > include/uapi/asm-generic/socket.h | 2 ++
> > net/core/sock.c | 4 ++++
> > 16 files changed, 37 insertions(+)
> >
> ...
> >--- a/include/net/sock.h
> >+++ b/include/net/sock.h
> >@@ -2292,4 +2292,9 @@ extern int sysctl_optmem_max;
> > extern __u32 sysctl_wmem_default;
> > extern __u32 sysctl_rmem_default;
> >
> >+static inline int bpf_get_extensions(void)
> >+{
> >+ return 0;
> >+}
> >+
>
> This should rather be in: include/linux/filter.h
Yes, having that function there makes more sense.
>
> And then, maybe be renamed into something like bpf_tell_extensions()
> for example, but that's just nit.
Renamed.
>
> Also, please add a comment, saying if people add new extensions, they
> need to enumerate them within this function from now on so that user
> space who enquires for that can be made aware of.
Let me know if even more explanatory comment is desired.
>
> Still, grepping through latest libpcap sources, tells me, so far over
> the years they have included SKF_AD_PROTOCOL and SKF_AD_PKTTYPE, wow!
>
> That's very disappointing, so I have high hopes with this getsockopt().
>
> ;)
>
> Thanks,
Thank you for the review. Btw, what do you think about define for parisc? I am
not sure I grok 0x4048 for SO_MAX_PACING_RATE and hence not sure about 0x4029
for SO_BPF_EXTENSIONS.
>
> Daniel
Michal
>
> > #endif /* _SOCK_H */
> >diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
> >index 38f14d0..ea0796b 100644
> >--- a/include/uapi/asm-generic/socket.h
> >+++ b/include/uapi/asm-generic/socket.h
> >@@ -80,4 +80,6 @@
> >
> > #define SO_MAX_PACING_RATE 47
> >
> >+#define SO_BPF_EXTENSIONS 48
> >+
> > #endif /* __ASM_GENERIC_SOCKET_H */
> >diff --git a/net/core/sock.c b/net/core/sock.c
> >index 85ad6f0..70e5a6e 100644
> >--- a/net/core/sock.c
> >+++ b/net/core/sock.c
> >@@ -1167,6 +1167,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
> > v.val = sock_flag(sk, SOCK_FILTER_LOCKED);
> > break;
> >
> >+ case SO_BPF_EXTENSIONS:
> >+ v.val = bpf_get_extensions();
> >+ break;
> >+
> > case SO_SELECT_ERR_QUEUE:
> > v.val = sock_flag(sk, SOCK_SELECT_ERR_QUEUE);
> > break;
> >
^ permalink raw reply
* Re: [PATCH net-next 2/2] reciprocal_divide: correction/update of the algorithm
From: Hannes Frederic Sowa @ 2014-01-16 17:24 UTC (permalink / raw)
To: Christoph Lameter
Cc: Daniel Borkmann, davem, netdev, linux-kernel, Eric Dumazet,
Austin S Hemmelgarn, Jesse Gross, Jamal Hadi Salim,
Stephen Hemminger, Matt Mackall, Pekka Enberg, Andy Gospodarek,
Veaceslav Falico, Jay Vosburgh, Jakub Zawadzki
In-Reply-To: <alpine.DEB.2.10.1401161036110.29778@nuc>
On Thu, Jan 16, 2014 at 10:37:37AM -0600, Christoph Lameter wrote:
> On Thu, 16 Jan 2014, Daniel Borkmann wrote:
>
> > - * or else the performance is slower than a normal divide.
> > - */
> > -extern u32 reciprocal_value(u32 B);
> > +struct reciprocal_value {
> > + u32 m;
> > + u8 sh1, sh2;
> > +};
> >
> > +#define RECIPROCAL_VALUE_RESULT_TO_ZERO ((struct reciprocal_value){.sh1 = 32})
> >
> > -static inline u32 reciprocal_divide(u32 A, u32 R)
> > +struct reciprocal_value reciprocal_value(u32 d);
>
> A function that returns a struct? That works? Which gcc versions support
> it?
Sure, that works and I actually like it. This is supported by the c standard,
but please don't ask me since which one. ;)
Greetings,
Hannes
^ permalink raw reply
* [PATCH] net: introduce SO_BPF_EXTENSIONS
From: Michal Sekletar @ 2014-01-16 17:13 UTC (permalink / raw)
To: dborkman; +Cc: netdev, Michal Sekletar, Michael Kerrisk, David Miller
In-Reply-To: <52D80BCA.7030400@redhat.com>
userspace packet capturing libraries (e.g. libpcap) don't have a way how to find
out which BPF extensions are supported by the kernel, except compiling a filter
which uses extensions and trying to apply filter to the socket. This is very
inconvenient.
Therefore this commit introduces new option which can be used as an argument for
getsockopt() and allows one to obtain information about which BPF extensions are
supported by the kernel.
On Tue, Dec 10, 2013 at 1:25 AM, David Miller <davem@davemloft.net> wrote:
> And therefore, you do not need to define any actual bits yet. The
> socket option will for now just return "0", and that will mean that
> all the extensions Linux implements currently are presnet.
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Daniel Borkmann <dborkman@redhat.com>
Cc: David Miller <davem@davemloft.net>
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/avr32/include/uapi/asm/socket.h | 2 ++
arch/cris/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
include/linux/filter.h | 10 ++++++++++
include/uapi/asm-generic/socket.h | 2 ++
net/core/sock.c | 4 ++++
16 files changed, 42 insertions(+)
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index e3a1491..3de1394 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -85,4 +85,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/avr32/include/uapi/asm/socket.h b/arch/avr32/include/uapi/asm/socket.h
index cbf902e..6e6cd15 100644
--- a/arch/avr32/include/uapi/asm/socket.h
+++ b/arch/avr32/include/uapi/asm/socket.h
@@ -78,4 +78,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _UAPI__ASM_AVR32_SOCKET_H */
diff --git a/arch/cris/include/uapi/asm/socket.h b/arch/cris/include/uapi/asm/socket.h
index 13829aa..ed94e5e 100644
--- a/arch/cris/include/uapi/asm/socket.h
+++ b/arch/cris/include/uapi/asm/socket.h
@@ -80,6 +80,8 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index 5d42997..ca2c6e6 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -78,5 +78,7 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index c25302f..a1b49ba 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -87,4 +87,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index 5296665..6c9a24b 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -78,4 +78,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 0df9787..a14baa2 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -96,4 +96,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 71dedca..6aa3ce1 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -78,4 +78,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index f33113a..a586f61 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -77,4 +77,6 @@
#define SO_MAX_PACING_RATE 0x4048
+#define SO_BPF_EXTENSIONS 0x4029
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index fa69832..a9c3e2e 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -85,4 +85,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index c286c2e..e031332 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -84,4 +84,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 0f21e9a..54d9608 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -74,6 +74,8 @@
#define SO_MAX_PACING_RATE 0x0031
+#define SO_BPF_EXTENSIONS 0x0032
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 7db5c22..39acec0 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -89,4 +89,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _XTENSA_SOCKET_H */
diff --git a/include/linux/filter.h b/include/linux/filter.h
index ff4e40c..3c9a7fc 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -83,6 +83,16 @@ static inline void bpf_jit_free(struct sk_filter *fp)
#define SK_RUN_FILTER(FILTER, SKB) sk_run_filter(SKB, FILTER->insns)
#endif
+static inline int bpf_tell_extensions(void)
+{
+ /* When adding new BPF extension it is necessary to enumerate it here, so
+ * userspace software which wants to know what is supported can do so by inspecting
+ * return value of this function
+ */
+
+ return 0;
+}
+
enum {
BPF_S_RET_K = 1,
BPF_S_RET_A,
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index 38f14d0..ea0796b 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -80,4 +80,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/net/core/sock.c b/net/core/sock.c
index 85ad6f0..4a32e52 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1167,6 +1167,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
v.val = sock_flag(sk, SOCK_FILTER_LOCKED);
break;
+ case SO_BPF_EXTENSIONS:
+ v.val = bpf_tell_extensions();
+ break;
+
case SO_SELECT_ERR_QUEUE:
v.val = sock_flag(sk, SOCK_SELECT_ERR_QUEUE);
break;
--
1.8.4.2
^ permalink raw reply related
* Re: Fwd: [RFC PATCH net-next 0/3] virtio_net: add aRFS support
From: Tom Herbert @ 2014-01-16 17:12 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Zhi Yong Wu, Linux Netdev List, Eric Dumazet, David S. Miller,
Zhi Yong Wu, Michael S. Tsirkin, Rusty Russell, Jason Wang
In-Reply-To: <20140116085253.GA32073@stefanha-thinkpad.redhat.com>
On Thu, Jan 16, 2014 at 12:52 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> On Thu, Jan 16, 2014 at 04:34:10PM +0800, Zhi Yong Wu wrote:
>> CC: stefanha, MST, Rusty Russel
>>
>> ---------- Forwarded message ----------
>> From: Jason Wang <jasowang@redhat.com>
>> Date: Thu, Jan 16, 2014 at 12:23 PM
>> Subject: Re: [RFC PATCH net-next 0/3] virtio_net: add aRFS support
>> To: Zhi Yong Wu <zwu.kernel@gmail.com>
>> Cc: netdev@vger.kernel.org, therbert@google.com, edumazet@google.com,
>> davem@davemloft.net, Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>>
>>
>> On 01/15/2014 10:20 PM, Zhi Yong Wu wrote:
>> >
>> > From: Zhi Yong Wu<wuzhy@linux.vnet.ibm.com>
>> >
>> > HI, folks
>> >
>> > The patchset is trying to integrate aRFS support to virtio_net. In this case,
>> > aRFS will be used to select the RX queue. To make sure that it's going ahead
>> > in the correct direction, although it is still one RFC and isn't tested, it's
>> > post out ASAP. Any comment are appreciated, thanks.
>> >
>> > If anyone is interested in playing with it, you can get this patchset from my
>> > dev git on github:
>> > git://github.com/wuzhy/kernel.git virtnet_rfs
>> >
>> > Zhi Yong Wu (3):
>> > virtio_pci: Introduce one new config api vp_get_vq_irq()
>> > virtio_net: Introduce one dummy function virtnet_filter_rfs()
>> > virtio-net: Add accelerated RFS support
>> >
>> > drivers/net/virtio_net.c | 67 ++++++++++++++++++++++++++++++++++++++++-
>> > drivers/virtio/virtio_pci.c | 11 +++++++
>> > include/linux/virtio_config.h | 12 +++++++
>> > 3 files changed, 89 insertions(+), 1 deletions(-)
>> >
>>
>> Please run get_maintainter.pl before sending the patch. You'd better
>> at least cc virtio maintainer/list for this.
>>
>> The core aRFS method is a noop in this RFC which make this series no
>> much sense to discuss. You should at least mention the big picture
>> here in the cover letter. I suggest you should post a RFC which can
>> run and has expected result or you can just raise a thread for the
>> design discussion.
>>
>> And this method has been discussed before, you can search "[net-next
>> RFC PATCH 5/5] virtio-net: flow director support" in netdev archive
>> for a very old prototype implemented by me. It can work and looks like
>> most of this RFC have already done there.
>>
>> A basic question is whether or not we need this, not all the mq cards
>> use aRFS (see ixgbe ATR). And whether or not it can bring extra
>> overheads? For virtio, we want to reduce the vmexits as much as
>> possible but this aRFS seems introduce a lot of more of this. Making a
>> complex interfaces just for an virtual device may not be good, simple
>> method may works for most of the cases.
>>
>> We really should consider to offload this to real nic. VMDq and L2
>> forwarding offload may help in this case.
>
Adding flow director support would be a good step, Zhi's patches for
support in tun have been merged, so support in virtio-net would be a
good follow on. But, flow-director does have some limitations and
performance issues of it's own (forced pairing between TX and RX
queues, lookup on every TX packet). In the case of virtualization,
aRFS, RSS, ntuple filtering, LRO, etc. can be implemented as software
emulations and so far seems to be wins in most cases. Extending these
down into the stack so that they can leverage HW mechanisms is a good
goal for best performance. It's probably generally true that most of
the offloads commonly available for NICs we'll want in virtualization
path. Of course, we need to deomonstrate that they provide real
performance benefit in this use case.
I believe tying in aRFS (or flow director) into a real aRFS is just a
matter of programming the RFS table properly. This is not the complex
side of the interface, I believe this already works with the tun
patches.
> Zhi Yong and I had an IRC chat. I wanted to post my questions on the
> list - it's still the same concern I had in the old email thread that
> Jason mentioned.
>
> In order for virtio-net aRFS to make sense there needs to be an overall
> plan for pushing flow mapping information down to the physical NIC.
> That's the only way to actually achieve the benefit of steering:
> processing the packet on the CPU where the application is running.
>
I don't think this is necessarily true. Per flow steering amongst
virtual queues should be beneficial in itself. virtio-net can leverage
RFS or aRFS where it's available.
> If it's not possible or too hard to implement aRFS down the entire
> stack, we won't be able to process the packet on the right CPU.
> Then we might as well not bother with aRFS and just distribute uniformly
> across the rx virtqueues.
>
> Please post an outline of how rx packets will be steered up the stack so
> we can discuss whether aRFS can bring any benefit.
>
1. The aRFS interface for the guest to specify which virtual queue to
receive a packet on is fairly straight forward.
2. To hook into RFS, we need to match the virtual queue to the real
CPU it will processed on, and then program the RFS table for that flow
and CPU.
3. NIC aRFS keys off the RFS tables so it can program the HW with the
correct queue for the CPU.
> Stefan
^ permalink raw reply
* Re: [PATCH v2] net: can: Disable flexcan driver build for big endian CPU on ARM
From: Marc Kleine-Budde @ 2014-01-16 16:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Wolfgang Grandegger, linux-can, netdev
In-Reply-To: <3157541.PQSkPAVrH7@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
On 01/14/2014 11:44 AM, Arnd Bergmann wrote:
>> On 01/06/2014 02:21 PM, Guenter Roeck wrote:
>>> Building arm:allmodconfig fails with
>>>
>>> flexcan.c: In function 'flexcan_read':
>>> flexcan.c:243:2: error: implicit declaration of function 'in_be32'
>>> flexcan.c: In function 'flexcan_write':
>>> flexcan.c:248:2: error: implicit declaration of function 'out_be32'
>>>
>>> in_be32 and out_be32 do not (or no longer) exist for ARM targets.
>>> Disable the build for ARM on big endian CPUs.
>>>
>>> Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
>>
>> Applied to can-next.
>
> Sorry, this patch was wrong.
>
> There is no reason to disallow building the driver on big-endian
> ARM kernels. Furthermore, the current behavior is actually broken
> on little-endian PowerPC as well.
> The choice of register accessor functions must purely depend
> on the CPU architecture, not which endianess the CPU is running
> on. Note that we nowadays allow both big-endian ARM and little-endian
> PowerPC kernels.
> With this patch applied, we will do the right thing in all four
> combinations.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks Arnd, I've squashed in the revert of Guenter's patch.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]
^ permalink raw reply
* Re: [PATCH] net: introduce SO_BPF_EXTENSIONS
From: Daniel Borkmann @ 2014-01-16 16:41 UTC (permalink / raw)
To: Michal Sekletar; +Cc: netdev, Michael Kerrisk, David Miller
In-Reply-To: <1389888898-31744-1-git-send-email-msekleta@redhat.com>
On 01/16/2014 05:14 PM, Michal Sekletar wrote:
> userspace packet capturing libraries (e.g. libpcap) don't have a way how to find
> out which BPF extensions are supported by the kernel, except compiling a filter
> which uses extensions and trying to apply filter to the socket. This is very
> inconvenient.
>
> Therefore this commit introduces new option which can be used as an argument for
> getsockopt() and allows one to obtain information about which BPF extensions are
> supported by the kernel.
>
> On Tue, Dec 10, 2013 at 1:25 AM, David Miller <davem@davemloft.net> wrote:
>
>> And therefore, you do not need to define any actual bits yet. The
>> socket option will for now just return "0", and that will mean that
>> all the extensions Linux implements currently are presnet.
>
> Signed-off-by: Michal Sekletar <msekleta@redhat.com>
> Cc: Michael Kerrisk <mtk.manpages@gmail.com>
> Cc: Daniel Borkmann <dborkman@redhat.com>
> Cc: David Miller <davem@davemloft.net>
> ---
> arch/alpha/include/uapi/asm/socket.h | 2 ++
> arch/avr32/include/uapi/asm/socket.h | 2 ++
> arch/cris/include/uapi/asm/socket.h | 2 ++
> arch/frv/include/uapi/asm/socket.h | 2 ++
> arch/ia64/include/uapi/asm/socket.h | 2 ++
> arch/m32r/include/uapi/asm/socket.h | 2 ++
> arch/mips/include/uapi/asm/socket.h | 2 ++
> arch/mn10300/include/uapi/asm/socket.h | 2 ++
> arch/parisc/include/uapi/asm/socket.h | 2 ++
> arch/powerpc/include/uapi/asm/socket.h | 2 ++
> arch/s390/include/uapi/asm/socket.h | 2 ++
> arch/sparc/include/uapi/asm/socket.h | 2 ++
> arch/xtensa/include/uapi/asm/socket.h | 2 ++
> include/net/sock.h | 5 +++++
> include/uapi/asm-generic/socket.h | 2 ++
> net/core/sock.c | 4 ++++
> 16 files changed, 37 insertions(+)
>
...
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -2292,4 +2292,9 @@ extern int sysctl_optmem_max;
> extern __u32 sysctl_wmem_default;
> extern __u32 sysctl_rmem_default;
>
> +static inline int bpf_get_extensions(void)
> +{
> + return 0;
> +}
> +
This should rather be in: include/linux/filter.h
And then, maybe be renamed into something like bpf_tell_extensions()
for example, but that's just nit.
Also, please add a comment, saying if people add new extensions, they
need to enumerate them within this function from now on so that user
space who enquires for that can be made aware of.
Still, grepping through latest libpcap sources, tells me, so far over
the years they have included SKF_AD_PROTOCOL and SKF_AD_PKTTYPE, wow!
That's very disappointing, so I have high hopes with this getsockopt().
;)
Thanks,
Daniel
> #endif /* _SOCK_H */
> diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
> index 38f14d0..ea0796b 100644
> --- a/include/uapi/asm-generic/socket.h
> +++ b/include/uapi/asm-generic/socket.h
> @@ -80,4 +80,6 @@
>
> #define SO_MAX_PACING_RATE 47
>
> +#define SO_BPF_EXTENSIONS 48
> +
> #endif /* __ASM_GENERIC_SOCKET_H */
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 85ad6f0..70e5a6e 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1167,6 +1167,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
> v.val = sock_flag(sk, SOCK_FILTER_LOCKED);
> break;
>
> + case SO_BPF_EXTENSIONS:
> + v.val = bpf_get_extensions();
> + break;
> +
> case SO_SELECT_ERR_QUEUE:
> v.val = sock_flag(sk, SOCK_SELECT_ERR_QUEUE);
> break;
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] reciprocal_divide: correction/update of the algorithm
From: Christoph Lameter @ 2014-01-16 16:37 UTC (permalink / raw)
To: Daniel Borkmann
Cc: davem, netdev, linux-kernel, Hannes Frederic Sowa, Eric Dumazet,
Austin S Hemmelgarn, Jesse Gross, Jamal Hadi Salim,
Stephen Hemminger, Matt Mackall, Pekka Enberg, Andy Gospodarek,
Veaceslav Falico, Jay Vosburgh, Jakub Zawadzki
In-Reply-To: <1389828228-30312-3-git-send-email-dborkman@redhat.com>
On Thu, 16 Jan 2014, Daniel Borkmann wrote:
> - * or else the performance is slower than a normal divide.
> - */
> -extern u32 reciprocal_value(u32 B);
> +struct reciprocal_value {
> + u32 m;
> + u8 sh1, sh2;
> +};
>
> +#define RECIPROCAL_VALUE_RESULT_TO_ZERO ((struct reciprocal_value){.sh1 = 32})
>
> -static inline u32 reciprocal_divide(u32 A, u32 R)
> +struct reciprocal_value reciprocal_value(u32 d);
A function that returns a struct? That works? Which gcc versions support
it?
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] virtio-net: initial rx sysfs support, export mergeable rx buffer size
From: Michael Dalton @ 2014-01-16 16:33 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, lf-virt, Eric Dumazet, David S. Miller
In-Reply-To: <20140116115340.GC29061@redhat.com>
Hi Michael,
On Thu, Jan 16, 2014 at 3:53 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> Hmm this adds overhead just to prevent sysfs from getting wrong value.
> Can't sysfs simply disable softirq while it's reading the value?
Yes I think this would work, we could call napi_disable(), read the
average packet length from the receive_queue, and then call
virtnet_napi_enable(). That would eliminate the need for the seqcount.
Best,
Mike
^ permalink raw reply
* Re: [PATCH] net: sk == 0xffffffff fix - not for commit
From: Eric Dumazet @ 2014-01-16 16:29 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: linux-kernel, linux-usb, Kyungmin Park, Felipe Balbi,
Greg Kroah-Hartman, Marek Szyprowski, Michal Nazarewicz,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <52D7F8EF.1050407@samsung.com>
On Thu, 2014-01-16 at 16:21 +0100, Andrzej Pietrasiewicz wrote:
> W dniu 10.12.2013 15:25, Eric Dumazet pisze:
> > On Tue, 2013-12-10 at 07:55 +0100, Andrzej Pietrasiewicz wrote:
> >> W dniu 09.12.2013 16:31, Eric Dumazet pisze:
> >>> On Mon, 2013-12-09 at 12:47 +0100, Andrzej Pietrasiewicz wrote:
> >>>> NOT FOR COMMITTING TO MAINLINE.
> >>>>
> >>>> With g_ether loaded the sk occasionally becomes 0xffffffff.
> >>>> It happens usually after transferring few hundreds of kilobytes to few
> >>>> tens of megabytes. If sk is 0xffffffff then dereferencing it causes
> >>>> kernel panic.
> >>>>
> >>>> This is a *workaround*. I don't know enough net code to understand the core
> >>>> of the problem. However, with this patch applied the problems are gone,
> >>>> or at least pushed farther away.
> >>>
> >>> Is it happening on SMP or UP ?
> >>
> >> UP build, S5PC110
> >
> > OK
> >
> > I believe you need additional debugging to track the exact moment
> > 0xffffffff is fed to 'sk'
> >
> > It looks like a very strange bug, involving a problem in some assembly
> > helper, register save/restore, compiler bug or stack corruption or
> > something.
> >
>
> I started with adding WARN_ON(sk == 0xffffffff); just before return in
> __inet_lookup_established(), and the problem was gone. So this looks
> very strange, like a toolchain problem.
Or a timing issue. Adding a WARN_ON() adds extra instructions and might
really change the assembly output.
>
> I used gcc-linaro-arm-linux-gnueabihf-4.8-2013.05.
>
> If I change the toolchain to
>
> gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415
>
> the problem seems to have gone away.
Its totally possible some barrier was not properly handled by the
compiler. You could disassemble the function on both toolchains and
try to spot the issue.
^ permalink raw reply
* Re: [PATCH] sch_htb: let skb->priority refer to non-leaf class
From: Eric Dumazet @ 2014-01-16 16:25 UTC (permalink / raw)
To: Harry Mason; +Cc: Jamal Hadi Salim, linux-netdev
In-Reply-To: <1389883519.4703.5.camel@azathoth.dev.smoothwall.net>
On Thu, 2014-01-16 at 14:45 +0000, Harry Mason wrote:
> If the class in skb->priority is not a leaf, apply filters from the
> selected class, not the qdisc. This allows netfilter or user space
> to partially classify the packet and tc filters to finish it off.
>
> Signed-off-by: Harry Mason <harry.mason@smoothwall.net>
> ---
> net/sched/sch_htb.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
> index 717b210..e50ab65 100644
> --- a/net/sched/sch_htb.c
> +++ b/net/sched/sch_htb.c
> @@ -223,7 +223,13 @@ static struct htb_class *htb_classify(struct
> sk_buff *skb, struct Qdisc *sch,
> return cl;
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> - tcf = q->filter_list;
> +
> + /* Start with inner filter chain if a non-leaf class is selected */
> + if (cl)
> + tcf = cl->filter_list;
> + else
> + tcf = q->filter_list;
> +
Interesting idea.
Could this break some existing htb setups ?
Also we test cl being NULL at line 222, it would be nice to not test it
again...
^ permalink raw reply
* [PATCH net-next] ipv6: tcp: fix flowlabel value in ACK messages send from TIME_WAIT
From: Florent Fourcot @ 2014-01-16 16:21 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
This patch is following the commit b903d324bee262 (ipv6: tcp: fix TCLASS
value in ACK messages sent from TIME_WAIT).
For the same reason than tclass, we have to store the flow label in the
inet_timewait_sock to provide consistency of flow label on the last ACK.
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
include/net/inet_timewait_sock.h | 6 +++---
net/ipv4/tcp_minisocks.c | 1 +
net/ipv6/tcp_ipv6.c | 17 +++++++++++------
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/include/net/inet_timewait_sock.h b/include/net/inet_timewait_sock.h
index 71c6e26..61474ea 100644
--- a/include/net/inet_timewait_sock.h
+++ b/include/net/inet_timewait_sock.h
@@ -133,9 +133,9 @@ struct inet_timewait_sock {
/* And these are ours. */
unsigned int tw_ipv6only : 1,
tw_transparent : 1,
- tw_pad : 6, /* 6 bits hole */
- tw_tos : 8,
- tw_pad2 : 16; /* 16 bits hole */
+ tw_flowlabel : 20,
+ tw_pad : 2, /* 2 bits hole */
+ tw_tos : 8;
kmemcheck_bitfield_end(flags);
u32 tw_ttd;
struct inet_bind_bucket *tw_tb;
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 3aa9e32..7a436c5 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -297,6 +297,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo)
tw->tw_v6_daddr = sk->sk_v6_daddr;
tw->tw_v6_rcv_saddr = sk->sk_v6_rcv_saddr;
tw->tw_tclass = np->tclass;
+ tw->tw_flowlabel = np->flow_label >> 12;
tw->tw_ipv6only = np->ipv6only;
}
#endif
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index f61bedc..c3d1341 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -726,7 +726,8 @@ static const struct tcp_request_sock_ops tcp_request_sock_ipv6_ops = {
static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
u32 tsval, u32 tsecr,
- struct tcp_md5sig_key *key, int rst, u8 tclass)
+ struct tcp_md5sig_key *key, int rst, u8 tclass,
+ u32 label)
{
const struct tcphdr *th = tcp_hdr(skb);
struct tcphdr *t1;
@@ -788,6 +789,7 @@ static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
memset(&fl6, 0, sizeof(fl6));
fl6.daddr = ipv6_hdr(skb)->saddr;
fl6.saddr = ipv6_hdr(skb)->daddr;
+ fl6.flowlabel = label;
buff->ip_summed = CHECKSUM_PARTIAL;
buff->csum = 0;
@@ -873,7 +875,7 @@ static void tcp_v6_send_reset(struct sock *sk, struct sk_buff *skb)
ack_seq = ntohl(th->seq) + th->syn + th->fin + skb->len -
(th->doff << 2);
- tcp_v6_send_response(skb, seq, ack_seq, 0, 0, 0, key, 1, 0);
+ tcp_v6_send_response(skb, seq, ack_seq, 0, 0, 0, key, 1, 0, 0);
#ifdef CONFIG_TCP_MD5SIG
release_sk1:
@@ -886,9 +888,11 @@ release_sk1:
static void tcp_v6_send_ack(struct sk_buff *skb, u32 seq, u32 ack,
u32 win, u32 tsval, u32 tsecr,
- struct tcp_md5sig_key *key, u8 tclass)
+ struct tcp_md5sig_key *key, u8 tclass,
+ u32 label)
{
- tcp_v6_send_response(skb, seq, ack, win, tsval, tsecr, key, 0, tclass);
+ tcp_v6_send_response(skb, seq, ack, win, tsval, tsecr, key, 0, tclass,
+ label);
}
static void tcp_v6_timewait_ack(struct sock *sk, struct sk_buff *skb)
@@ -900,7 +904,7 @@ static void tcp_v6_timewait_ack(struct sock *sk, struct sk_buff *skb)
tcptw->tw_rcv_wnd >> tw->tw_rcv_wscale,
tcp_time_stamp + tcptw->tw_ts_offset,
tcptw->tw_ts_recent, tcp_twsk_md5_key(tcptw),
- tw->tw_tclass);
+ tw->tw_tclass, (tw->tw_flowlabel << 12));
inet_twsk_put(tw);
}
@@ -910,7 +914,8 @@ static void tcp_v6_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
{
tcp_v6_send_ack(skb, tcp_rsk(req)->snt_isn + 1, tcp_rsk(req)->rcv_isn + 1,
req->rcv_wnd, tcp_time_stamp, req->ts_recent,
- tcp_v6_md5_do_lookup(sk, &ipv6_hdr(skb)->daddr), 0);
+ tcp_v6_md5_do_lookup(sk, &ipv6_hdr(skb)->daddr),
+ 0, 0);
}
--
1.8.5.2
^ permalink raw reply related
* [PATCH V3 net-next 3/3] ipv6: add flowlabel_consistency sysctl
From: Florent Fourcot @ 2014-01-16 16:19 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
In-Reply-To: <1389889158-1710-1-git-send-email-florent.fourcot@enst-bretagne.fr>
With the introduction of IPV6_FL_F_REFLECT, there is no guarantee of
flow label unicity. This patch introduces a new sysctl to protect the old
behaviour, enable by default.
Changelog of V3:
* rename ip6_flowlabel_consistency to flowlabel_consistency
* use net_info_ratelimited()
* checkpatch cleanups
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
Documentation/networking/ip-sysctl.txt | 8 ++++++++
include/net/netns/ipv6.h | 1 +
net/ipv6/af_inet6.c | 1 +
net/ipv6/ip6_flowlabel.c | 7 +++++++
net/ipv6/sysctl_net_ipv6.c | 8 ++++++++
5 files changed, 25 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index c97932c..5de0374 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1118,6 +1118,14 @@ bindv6only - BOOLEAN
Default: FALSE (as specified in RFC3493)
+flowlabel_consistency - BOOLEAN
+ Protect the consistency (and unicity) of flow label.
+ You have to disable it to use IPV6_FL_F_REFLECT flag on the
+ flow label manager.
+ TRUE: enabled
+ FALSE: disabled
+ Default: TRUE
+
anycast_src_echo_reply - BOOLEAN
Controls the use of anycast addresses as source addresses for ICMPv6
echo reply
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 592fecd..21edaf1 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -27,6 +27,7 @@ struct netns_sysctl_ipv6 {
int ip6_rt_gc_elasticity;
int ip6_rt_mtu_expires;
int ip6_rt_min_advmss;
+ int flowlabel_consistency;
int icmpv6_time;
int anycast_src_echo_reply;
};
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index c921d5d..d935889 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -775,6 +775,7 @@ static int __net_init inet6_net_init(struct net *net)
net->ipv6.sysctl.bindv6only = 0;
net->ipv6.sysctl.icmpv6_time = 1*HZ;
+ net->ipv6.sysctl.flowlabel_consistency = 1;
atomic_set(&net->ipv6.rt_genid, 0);
err = ipv6_init_mibs(net);
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 01bf252..dfa41bb 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -588,8 +588,15 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
case IPV6_FL_A_GET:
if (freq.flr_flags & IPV6_FL_F_REFLECT) {
+ struct net *net = sock_net(sk);
+ if (net->ipv6.sysctl.flowlabel_consistency) {
+ net_info_ratelimited("Can not set IPV6_FL_F_REFLECT if flowlabel_consistency sysctl is enable\n");
+ return -EPERM;
+ }
+
if (sk->sk_protocol != IPPROTO_TCP)
return -ENOPROTOOPT;
+
np->repflow = 1;
return 0;
}
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index b51b268..7f405a1 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -31,6 +31,13 @@ static struct ctl_table ipv6_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "flowlabel_consistency",
+ .data = &init_net.ipv6.sysctl.flowlabel_consistency,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
{ }
};
@@ -59,6 +66,7 @@ static int __net_init ipv6_sysctl_net_init(struct net *net)
goto out;
ipv6_table[0].data = &net->ipv6.sysctl.bindv6only;
ipv6_table[1].data = &net->ipv6.sysctl.anycast_src_echo_reply;
+ ipv6_table[2].data = &net->ipv6.sysctl.flowlabel_consistency;
ipv6_route_table = ipv6_route_sysctl_init(net);
if (!ipv6_route_table)
--
1.8.5.2
^ permalink raw reply related
* [PATCH V3 net-next 2/3] ipv6: add a flag to get the flow label used remotly
From: Florent Fourcot @ 2014-01-16 16:19 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
In-Reply-To: <1389889158-1710-1-git-send-email-florent.fourcot@enst-bretagne.fr>
This information is already available via IPV6_FLOWINFO
of IPV6_2292PKTOPTIONS, and them a filtering to get the flow label
information. But it is probably logical and easier for users to add this
here, and to control both sent/received flow label values with the
IPV6_FLOWLABEL_MGR option.
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
include/net/ipv6.h | 3 ++-
include/uapi/linux/in6.h | 1 +
net/ipv6/ip6_flowlabel.c | 8 +++++++-
net/ipv6/ipv6_sockglue.c | 5 ++++-
4 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 6d80f51..78d3d51 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -253,7 +253,8 @@ struct ipv6_txoptions *fl6_merge_options(struct ipv6_txoptions *opt_space,
struct ipv6_txoptions *fopt);
void fl6_free_socklist(struct sock *sk);
int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen);
-int ipv6_flowlabel_opt_get(struct sock *sk, struct in6_flowlabel_req *freq);
+int ipv6_flowlabel_opt_get(struct sock *sk, struct in6_flowlabel_req *freq,
+ int flags);
int ip6_flowlabel_init(void);
void ip6_flowlabel_cleanup(void);
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index 02c0cd6..633b93c 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -86,6 +86,7 @@ struct in6_flowlabel_req {
#define IPV6_FL_F_CREATE 1
#define IPV6_FL_F_EXCL 2
#define IPV6_FL_F_REFLECT 4
+#define IPV6_FL_F_REMOTE 8
#define IPV6_FL_S_NONE 0
#define IPV6_FL_S_EXCL 1
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 55823f1..01bf252 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -481,11 +481,17 @@ static inline void fl_link(struct ipv6_pinfo *np, struct ipv6_fl_socklist *sfl,
spin_unlock_bh(&ip6_sk_fl_lock);
}
-int ipv6_flowlabel_opt_get(struct sock *sk, struct in6_flowlabel_req *freq)
+int ipv6_flowlabel_opt_get(struct sock *sk, struct in6_flowlabel_req *freq,
+ int flags)
{
struct ipv6_pinfo *np = inet6_sk(sk);
struct ipv6_fl_socklist *sfl;
+ if (flags & IPV6_FL_F_REMOTE) {
+ freq->flr_label = np->rcv_flowinfo & IPV6_FLOWLABEL_MASK;
+ return 0;
+ }
+
if (np->repflow) {
freq->flr_label = np->flow_label;
return 0;
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 2855b00..7024a87 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1221,6 +1221,7 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
case IPV6_FLOWLABEL_MGR:
{
struct in6_flowlabel_req freq;
+ int flags;
if (len < sizeof(freq))
return -EINVAL;
@@ -1232,9 +1233,11 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
return -EINVAL;
len = sizeof(freq);
+ flags = freq.flr_flags;
+
memset(&freq, 0, sizeof(freq));
- val = ipv6_flowlabel_opt_get(sk, &freq);
+ val = ipv6_flowlabel_opt_get(sk, &freq, flags);
if (val < 0)
return val;
--
1.8.5.2
^ permalink raw reply related
* [PATCH V3 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
From: Florent Fourcot @ 2014-01-16 16:19 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
With this option, the socket will reply with the flow label value read
on received packets.
The goal is to have a connection with the same flow label in both
direction of the communication.
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
include/linux/ipv6.h | 1 +
include/uapi/linux/in6.h | 1 +
net/ipv6/ip6_flowlabel.c | 21 +++++++++++++++++++++
net/ipv6/tcp_ipv6.c | 10 ++++++++++
4 files changed, 33 insertions(+)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 7e1ded0..1084304 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -191,6 +191,7 @@ struct ipv6_pinfo {
/* sockopt flags */
__u16 recverr:1,
sndflow:1,
+ repflow:1,
pmtudisc:3,
ipv6only:1,
srcprefs:3, /* 001: prefer temporary address
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index f94f1d0..02c0cd6 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -85,6 +85,7 @@ struct in6_flowlabel_req {
#define IPV6_FL_F_CREATE 1
#define IPV6_FL_F_EXCL 2
+#define IPV6_FL_F_REFLECT 4
#define IPV6_FL_S_NONE 0
#define IPV6_FL_S_EXCL 1
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index cbc9351..55823f1 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -486,6 +486,11 @@ int ipv6_flowlabel_opt_get(struct sock *sk, struct in6_flowlabel_req *freq)
struct ipv6_pinfo *np = inet6_sk(sk);
struct ipv6_fl_socklist *sfl;
+ if (np->repflow) {
+ freq->flr_label = np->flow_label;
+ return 0;
+ }
+
rcu_read_lock_bh();
for_each_sk_fl_rcu(np, sfl) {
@@ -527,6 +532,15 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
switch (freq.flr_action) {
case IPV6_FL_A_PUT:
+ if (freq.flr_flags & IPV6_FL_F_REFLECT) {
+ if (sk->sk_protocol != IPPROTO_TCP)
+ return -ENOPROTOOPT;
+ if (!np->repflow)
+ return -ESRCH;
+ np->flow_label = 0;
+ np->repflow = 0;
+ return 0;
+ }
spin_lock_bh(&ip6_sk_fl_lock);
for (sflp = &np->ipv6_fl_list;
(sfl = rcu_dereference(*sflp))!=NULL;
@@ -567,6 +581,13 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
return -ESRCH;
case IPV6_FL_A_GET:
+ if (freq.flr_flags & IPV6_FL_F_REFLECT) {
+ if (sk->sk_protocol != IPPROTO_TCP)
+ return -ENOPROTOOPT;
+ np->repflow = 1;
+ return 0;
+ }
+
if (freq.flr_label & ~IPV6_FLOWLABEL_MASK)
return -EINVAL;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index ffd5fa8..f61bedc 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -483,6 +483,8 @@ static int tcp_v6_send_synack(struct sock *sk, struct dst_entry *dst,
&ireq->ir_v6_rmt_addr);
fl6->daddr = ireq->ir_v6_rmt_addr;
+ if (np->repflow)
+ fl6->flowlabel = np->flow_label;
skb_set_queue_mapping(skb, queue_mapping);
err = ip6_xmit(sk, skb, fl6, np->opt, np->tclass);
err = net_xmit_eval(err);
@@ -1000,6 +1002,8 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
ireq = inet_rsk(req);
ireq->ir_v6_rmt_addr = ipv6_hdr(skb)->saddr;
ireq->ir_v6_loc_addr = ipv6_hdr(skb)->daddr;
+ if (np->repflow)
+ np->flow_label = ip6_flowlabel(ipv6_hdr(skb));
if (!want_cookie || tmp_opt.tstamp_ok)
TCP_ECN_create_request(req, skb, sock_net(sk));
@@ -1138,6 +1142,8 @@ static struct sock *tcp_v6_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
newnp->mcast_oif = inet6_iif(skb);
newnp->mcast_hops = ipv6_hdr(skb)->hop_limit;
newnp->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(skb));
+ if (np->repflow)
+ newnp->flow_label = ip6_flowlabel(ipv6_hdr(skb));
/*
* No need to charge this sock to the relevant IPv6 refcnt debug socks count
@@ -1218,6 +1224,8 @@ static struct sock *tcp_v6_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
newnp->mcast_oif = inet6_iif(skb);
newnp->mcast_hops = ipv6_hdr(skb)->hop_limit;
newnp->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(skb));
+ if (np->repflow)
+ newnp->flow_label = ip6_flowlabel(ipv6_hdr(skb));
/* Clone native IPv6 options from listening socket (if any)
@@ -1429,6 +1437,8 @@ ipv6_pktoptions:
np->mcast_hops = ipv6_hdr(opt_skb)->hop_limit;
if (np->rxopt.bits.rxflow || np->rxopt.bits.rxtclass)
np->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(opt_skb));
+ if (np->repflow)
+ np->flow_label = ip6_flowlabel(ipv6_hdr(opt_skb));
if (ipv6_opt_accepted(sk, opt_skb)) {
skb_set_owner_r(opt_skb, sk);
opt_skb = xchg(&np->pktoptions, opt_skb);
--
1.8.5.2
^ permalink raw reply related
* Re: [PATCH] net: fix "queues" uevent between network namespaces
From: Greg KH @ 2014-01-16 16:19 UTC (permalink / raw)
To: Chen Weilong; +Cc: davem, netdev
In-Reply-To: <1389864271-24212-1-git-send-email-chenweilong@huawei.com>
On Thu, Jan 16, 2014 at 05:24:31PM +0800, Chen Weilong wrote:
> From: Weilong Chen <chenweilong@huawei.com>
>
> When I create a new namespace with 'ip netns add net0', or add/remove
> new links in a namespace with 'ip link add/delete type veth', rx/tx
> queues events can be got in all namespaces. That is because rx/tx queue
> ktypes do not have namespace support, and their kobj parents are setted to
> NULL. This patch is to fix it.
>
> Reported-by: Libo Chen <chenlibo@huawei.com>
> Signed-off-by: Libo Chen <chenlibo@huawei.com>
> Signed-off-by: Weilong Chen <chenweilong@huawei.com>
> ---
> lib/kobject_uevent.c | 10 ++++++++--
> net/core/net-sysfs.c | 26 ++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+), 2 deletions(-)
I can't test this, but it looks good to me:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH] net: introduce SO_BPF_EXTENSIONS
From: Michal Sekletar @ 2014-01-16 16:14 UTC (permalink / raw)
To: netdev; +Cc: Michal Sekletar, Michael Kerrisk, Daniel Borkmann, David Miller
userspace packet capturing libraries (e.g. libpcap) don't have a way how to find
out which BPF extensions are supported by the kernel, except compiling a filter
which uses extensions and trying to apply filter to the socket. This is very
inconvenient.
Therefore this commit introduces new option which can be used as an argument for
getsockopt() and allows one to obtain information about which BPF extensions are
supported by the kernel.
On Tue, Dec 10, 2013 at 1:25 AM, David Miller <davem@davemloft.net> wrote:
> And therefore, you do not need to define any actual bits yet. The
> socket option will for now just return "0", and that will mean that
> all the extensions Linux implements currently are presnet.
Signed-off-by: Michal Sekletar <msekleta@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Daniel Borkmann <dborkman@redhat.com>
Cc: David Miller <davem@davemloft.net>
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/avr32/include/uapi/asm/socket.h | 2 ++
arch/cris/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
include/net/sock.h | 5 +++++
include/uapi/asm-generic/socket.h | 2 ++
net/core/sock.c | 4 ++++
16 files changed, 37 insertions(+)
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index e3a1491..3de1394 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -85,4 +85,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/avr32/include/uapi/asm/socket.h b/arch/avr32/include/uapi/asm/socket.h
index cbf902e..6e6cd15 100644
--- a/arch/avr32/include/uapi/asm/socket.h
+++ b/arch/avr32/include/uapi/asm/socket.h
@@ -78,4 +78,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _UAPI__ASM_AVR32_SOCKET_H */
diff --git a/arch/cris/include/uapi/asm/socket.h b/arch/cris/include/uapi/asm/socket.h
index 13829aa..ed94e5e 100644
--- a/arch/cris/include/uapi/asm/socket.h
+++ b/arch/cris/include/uapi/asm/socket.h
@@ -80,6 +80,8 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index 5d42997..ca2c6e6 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -78,5 +78,7 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index c25302f..a1b49ba 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -87,4 +87,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index 5296665..6c9a24b 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -78,4 +78,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 0df9787..a14baa2 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -96,4 +96,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 71dedca..6aa3ce1 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -78,4 +78,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index f33113a..a586f61 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -77,4 +77,6 @@
#define SO_MAX_PACING_RATE 0x4048
+#define SO_BPF_EXTENSIONS 0x4029
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index fa69832..a9c3e2e 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -85,4 +85,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index c286c2e..e031332 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -84,4 +84,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 0f21e9a..54d9608 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -74,6 +74,8 @@
#define SO_MAX_PACING_RATE 0x0031
+#define SO_BPF_EXTENSIONS 0x0032
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 7db5c22..39acec0 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -89,4 +89,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* _XTENSA_SOCKET_H */
diff --git a/include/net/sock.h b/include/net/sock.h
index 5c3f7c3..ae8ff52 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2292,4 +2292,9 @@ extern int sysctl_optmem_max;
extern __u32 sysctl_wmem_default;
extern __u32 sysctl_rmem_default;
+static inline int bpf_get_extensions(void)
+{
+ return 0;
+}
+
#endif /* _SOCK_H */
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index 38f14d0..ea0796b 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -80,4 +80,6 @@
#define SO_MAX_PACING_RATE 47
+#define SO_BPF_EXTENSIONS 48
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/net/core/sock.c b/net/core/sock.c
index 85ad6f0..70e5a6e 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1167,6 +1167,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
v.val = sock_flag(sk, SOCK_FILTER_LOCKED);
break;
+ case SO_BPF_EXTENSIONS:
+ v.val = bpf_get_extensions();
+ break;
+
case SO_SELECT_ERR_QUEUE:
v.val = sock_flag(sk, SOCK_SELECT_ERR_QUEUE);
break;
--
1.8.4.2
^ permalink raw reply related
* [PATCH] net: rds: fix per-cpu helper usage
From: Gerald Schaefer @ 2014-01-16 15:54 UTC (permalink / raw)
To: Shan Wei, Christoph Lameter, David S. Miller, Venkat Venkatsubra
Cc: rds-devel, netdev, linux-kernel, Martin Schwidefsky,
Frank Blaschka, Sebastian Ott, Gerald Schaefer
commit ae4b46e9d "net: rds: use this_cpu_* per-cpu helper" broke per-cpu
handling for rds. chpfirst is the result of __this_cpu_read(), so it is
an absolute pointer and not __percpu. Therefore, __this_cpu_write()
should not operate on chpfirst, but rather on cache->percpu->first, just
like __this_cpu_read() did before.
Cc: <stable@vger.kernel.org> # 3.8+
Signed-off-byd Gerald Schaefer <gerald.schaefer@de.ibm.com>
---
net/rds/ib_recv.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
index 8eb9501..b7ebe23 100644
--- a/net/rds/ib_recv.c
+++ b/net/rds/ib_recv.c
@@ -421,8 +421,7 @@ static void rds_ib_recv_cache_put(struct list_head *new_item,
struct rds_ib_refill_cache *cache)
{
unsigned long flags;
- struct list_head *old;
- struct list_head __percpu *chpfirst;
+ struct list_head *old, *chpfirst;
local_irq_save(flags);
@@ -432,7 +431,7 @@ static void rds_ib_recv_cache_put(struct list_head *new_item,
else /* put on front */
list_add_tail(new_item, chpfirst);
- __this_cpu_write(chpfirst, new_item);
+ __this_cpu_write(cache->percpu->first, new_item);
__this_cpu_inc(cache->percpu->count);
if (__this_cpu_read(cache->percpu->count) < RDS_IB_RECYCLE_BATCH_COUNT)
@@ -452,7 +451,7 @@ static void rds_ib_recv_cache_put(struct list_head *new_item,
} while (old);
- __this_cpu_write(chpfirst, NULL);
+ __this_cpu_write(cache->percpu->first, NULL);
__this_cpu_write(cache->percpu->count, 0);
end:
local_irq_restore(flags);
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH v4 net-next 2/4] sh_eth: Add support for r7s72100
From: Sergei Shtylyov @ 2014-01-16 15:36 UTC (permalink / raw)
To: Simon Horman
Cc: David S. Miller, netdev, linux-sh, linux-arm-kernel, Magnus Damm
In-Reply-To: <20140116004943.GF12550@verge.net.au>
Hello.
On 16-01-2014 4:49, Simon Horman wrote:
>>>>> This is a fast ethernet controller.
>>>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>>>> [...]
>>>>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
>>>>> index 4b38533..cc6d4af 100644
>>>>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>>>>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>>>>> @@ -190,6 +190,59 @@ static const u16 sh_eth_offset_fast_rcar[SH_ETH_MAX_REGISTER_OFFSET] = {
>> [...]
>>>>> @@ -701,6 +762,35 @@ static struct sh_eth_cpu_data r8a7740_data = {
>>>>> .shift_rd0 = 1,
>>>>> };
>>>>>
>>>>> +/* R7S72100 */
>>>>> +static struct sh_eth_cpu_data r7s72100_data = {
>>>>> + .chip_reset = sh_eth_chip_reset,
>>>>> + .set_duplex = sh_eth_set_duplex,
>>>>> +
>>>>> + .register_type = SH_ETH_REG_FAST_RZ,
>>>>> +
>>>>> + .ecsr_value = ECSR_ICD,
>>>>> + .ecsipr_value = ECSIPR_ICDIP,
>>>>> + .eesipr_value = 0xff7f009f,
>>>>> +
>>>>> + .tx_check = EESR_TC1 | EESR_FTC,
>>>>> + .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
>>>>> + EESR_RFE | EESR_RDE | EESR_RFRMER | EESR_TFE |
>>>>> + EESR_TDE | EESR_ECI,
>>>>> + .fdr_value = 0x0000070f,
>>>>> + .rmcr_value = RMCR_RNC,
>>>>> +
>>>>> + .apr = 1,
>>>>> + .mpr = 1,
>>>>> + .tpauser = 1,
>>>>> + .hw_swap = 1,
>>>>> + .rpadir = 1,
>>>>> + .rpadir_value = 2 << 16,
>>>>> + .no_trimd = 1,
>>>>> + .tsu = 1,
>>>>> + .shift_rd0 = 1,
>>
>>>> Perhaps this field should be renamed to something talking about
>>>> check summing support (since bits 0..15 of RD0 contain a frame check
>>>> sum for those SoCs). Or maybe it should be just merged with the
>>>> 'hw_crc' field...
>>> I have no feelings about that one way or another.
>> Do you happen to have R8A7740 manual by chance? If so, does it
>> talk about RX check summing support and using RD0 for that?
> Yes and yes.
> I have taken a quick look and the documentation for RX checksumming on the
> R8A7740 appears to be very similar if not the same as that of the R7S72100.
> In particular both refer to using the bottom 16 bits of RD0 as
> containing the packet checksum.
OK, now if you had SH7734 manual to completely confirm that check sum is
stored in the same place there... most probably it is, of course, and we
should merge 'hw_crc' and 'shift_rd0' into a single field.
[...]
>>>>> diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
>>>>> index 0fe35b7..0bcde90 100644
>>>>> --- a/drivers/net/ethernet/renesas/sh_eth.h
>>>>> +++ b/drivers/net/ethernet/renesas/sh_eth.h
>> [...]
>>>>> @@ -191,6 +192,7 @@ enum DMAC_M_BIT {
>>>>> /* EDTRR */
>>>>> enum DMAC_T_BIT {
>>>>> EDTRR_TRNS_GETHER = 0x03,
>>>>> + EDTRR_TRNS_RZ_ETHER = 0x03,
>>>> I doubt we need a special case here. You didn't introduce one for
>>>> the software reset bits.
>>> True, but RZ is not Gigabit. So I think we either need two names
>>> or to choose a more generic name.
>> Well, R7S72100 manual calls these bits just TR[1:0]. Don't know
>> what SoCs having Gigabit call it in the manuals...
>>>>> EDTRR_TRNS_ETHER = 0x01,
>> R-Car manuals seem to call the bit TRNS (as well as the
>> prehistoric SH manuals probably). Perhaps we could use that
>> difference, TRNS vs TR, don't know...
> Perhaps we should just leave it as-is, using EDTRR_TRNS_GETHER and
> EDTRR_TRNS_RZ_ETHER, after all.
No, I liked your last version more. At least it's more consistent, not
adding separate values for either TR[1:0] or soft reset bits.
> At least until we can think of a better names :)
I doubt we can come up with something better.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 1/2] bonding: add sysfs /slave dir for bond slave devices.
From: Veaceslav Falico @ 2014-01-16 15:31 UTC (permalink / raw)
To: Scott Feldman; +Cc: fubar, andy, netdev, roopa, shm
In-Reply-To: <20140116055434.32220.89883.stgit@monster-03.cumulusnetworks.com>
On Wed, Jan 15, 2014 at 09:54:34PM -0800, Scott Feldman wrote:
>Add sub-directory under /sys/class/net/<interface>/slave with
>read-only attributes for slave. Directory only appears when
><interface> is a slave.
>
>$ tree /sys/class/net/eth2/slave/
>/sys/class/net/eth2/slave/
>├── ad_aggregator_id
>├── link_failure_count
>├── mii_status
>├── perm_hwaddr
>├── queue_id
>└── state
>
>$ cat /sys/class/net/eth2/slave/*
>2
>0
>up
>40:02:10:ef:06:01
>0
>active
>
>Signed-off-by: Scott Feldman <sfeldma@cumulusnetworks.com>
>---
> drivers/net/bonding/Makefile | 2
> drivers/net/bonding/bond_main.c | 27 ++++++
> drivers/net/bonding/bond_procfs.c | 12 ---
> drivers/net/bonding/bond_sysfs_slave.c | 142 ++++++++++++++++++++++++++++++++
> drivers/net/bonding/bonding.h | 4 +
> 5 files changed, 174 insertions(+), 13 deletions(-)
> create mode 100644 drivers/net/bonding/bond_sysfs_slave.c
>
>diff --git a/drivers/net/bonding/Makefile b/drivers/net/bonding/Makefile
>index 5a5d720..6f4e808 100644
>--- a/drivers/net/bonding/Makefile
>+++ b/drivers/net/bonding/Makefile
>@@ -4,7 +4,7 @@
>
> obj-$(CONFIG_BONDING) += bonding.o
>
>-bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o bond_debugfs.o bond_netlink.o bond_options.o
>+bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o bond_sysfs_slave.o bond_debugfs.o bond_netlink.o bond_options.o
>
> proc-$(CONFIG_PROC_FS) += bond_procfs.o
> bonding-objs += $(proc-y)
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index f2fe6cb..4f1adae 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -466,6 +466,22 @@ static void bond_update_speed_duplex(struct slave *slave)
> return;
> }
>
>+const char *bond_slave_link_status(s8 link)
>+{
>+ switch (link) {
>+ case BOND_LINK_UP:
>+ return "up";
>+ case BOND_LINK_FAIL:
>+ return "going down";
>+ case BOND_LINK_DOWN:
>+ return "down";
>+ case BOND_LINK_BACK:
>+ return "going back";
>+ default:
>+ return "unknown";
>+ }
>+}
>+
> /*
> * if <dev> supports MII link status reporting, check its link status.
> *
>@@ -1576,6 +1592,12 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> goto err_unregister;
> }
>
>+ res = bond_sysfs_slave_add(new_slave);
>+ if (res) {
>+ pr_debug("Error %d calling bond_sysfs_slave_add\n", res);
>+ goto err_upper_unlink;
>+ }
>+
> bond->slave_cnt++;
> bond_compute_features(bond);
> bond_set_carrier(bond);
>@@ -1595,6 +1617,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> return 0;
>
> /* Undo stages on error */
>+err_upper_unlink:
>+ bond_upper_dev_unlink(bond_dev, slave_dev);
>+
> err_unregister:
> netdev_rx_handler_unregister(slave_dev);
>
>@@ -1687,6 +1712,8 @@ static int __bond_release_one(struct net_device *bond_dev,
> /* release the slave from its bond */
> bond->slave_cnt--;
>
>+ bond_sysfs_slave_del(slave);
>+
> bond_upper_dev_unlink(bond_dev, slave_dev);
> /* unregister rx_handler early so bond_handle_frame wouldn't be called
> * for this slave anymore.
>diff --git a/drivers/net/bonding/bond_procfs.c b/drivers/net/bonding/bond_procfs.c
>index fb868d6..8515b344 100644
>--- a/drivers/net/bonding/bond_procfs.c
>+++ b/drivers/net/bonding/bond_procfs.c
>@@ -159,18 +159,6 @@ static void bond_info_show_master(struct seq_file *seq)
> }
> }
>
>-static const char *bond_slave_link_status(s8 link)
>-{
>- static const char * const status[] = {
>- [BOND_LINK_UP] = "up",
>- [BOND_LINK_FAIL] = "going down",
>- [BOND_LINK_DOWN] = "down",
>- [BOND_LINK_BACK] = "going back",
>- };
>-
>- return status[link];
>-}
>-
> static void bond_info_show_slave(struct seq_file *seq,
> const struct slave *slave)
> {
>diff --git a/drivers/net/bonding/bond_sysfs_slave.c b/drivers/net/bonding/bond_sysfs_slave.c
>new file mode 100644
>index 0000000..28390af
>--- /dev/null
>+++ b/drivers/net/bonding/bond_sysfs_slave.c
>@@ -0,0 +1,142 @@
>+/* Sysfs attributes of bond slaves
>+ *
>+ * Copyright (c) 2014 Scott Feldman <sfeldma@cumulusnetworks.com>
>+ *
>+ * This program is free software; you can redistribute it and/or
>+ * modify it under the terms of the GNU General Public License
>+ * as published by the Free Software Foundation; either version
>+ * 2 of the License, or (at your option) any later version.
>+ */
>+
>+#include <linux/capability.h>
>+#include <linux/kernel.h>
>+#include <linux/netdevice.h>
>+
>+#include "bonding.h"
>+
>+struct slave_attribute {
>+ struct attribute attr;
>+ ssize_t (*show)(struct slave *, char *);
>+};
>+
>+#define SLAVE_ATTR(_name, _mode, _show) \
>+const struct slave_attribute slave_attr_##_name = { \
>+ .attr = {.name = __stringify(_name), \
>+ .mode = _mode }, \
>+ .show = _show, \
>+};
>+#define SLAVE_ATTR_RO(_name) \
>+ SLAVE_ATTR(_name, S_IRUGO, _name##_show)
>+
>+static ssize_t state_show(struct slave *slave, char *buf)
>+{
>+ switch (bond_slave_state(slave)) {
>+ case BOND_STATE_ACTIVE:
>+ return sprintf(buf, "active\n");
>+ case BOND_STATE_BACKUP:
>+ return sprintf(buf, "backup\n");
>+ default:
>+ return sprintf(buf, "UNKONWN\n");
>+ }
>+}
>+static SLAVE_ATTR_RO(state);
Am I missing something or does it really completely lacks any locking?
What prevents the slave to be freed in between?
>+
>+static ssize_t mii_status_show(struct slave *slave, char *buf)
>+{
>+ return sprintf(buf, "%s\n", bond_slave_link_status(slave->link));
>+}
>+static SLAVE_ATTR_RO(mii_status);
>+
>+static ssize_t link_failure_count_show(struct slave *slave, char *buf)
>+{
>+ return sprintf(buf, "%d\n", slave->link_failure_count);
>+}
>+static SLAVE_ATTR_RO(link_failure_count);
>+
>+static ssize_t perm_hwaddr_show(struct slave *slave, char *buf)
>+{
>+ return sprintf(buf, "%pM\n", slave->perm_hwaddr);
>+}
>+static SLAVE_ATTR_RO(perm_hwaddr);
>+
>+static ssize_t queue_id_show(struct slave *slave, char *buf)
>+{
>+ return sprintf(buf, "%d\n", slave->queue_id);
>+}
>+static SLAVE_ATTR_RO(queue_id);
>+
>+static ssize_t ad_aggregator_id_show(struct slave *slave, char *buf)
>+{
>+ const struct aggregator *agg;
>+
>+ if (slave->bond->params.mode == BOND_MODE_8023AD) {
>+ agg = SLAVE_AD_INFO(slave).port.aggregator;
>+ if (agg)
>+ return sprintf(buf, "%d\n",
>+ agg->aggregator_identifier);
>+ }
>+
>+ return sprintf(buf, "N/A\n");
>+}
>+static SLAVE_ATTR_RO(ad_aggregator_id);
>+
>+static const struct slave_attribute *slave_attrs[] = {
>+ &slave_attr_state,
>+ &slave_attr_mii_status,
>+ &slave_attr_link_failure_count,
>+ &slave_attr_perm_hwaddr,
>+ &slave_attr_queue_id,
>+ &slave_attr_ad_aggregator_id,
>+ NULL
>+};
>+
>+#define to_slave_attr(_at) container_of(_at, struct slave_attribute, attr)
>+#define to_slave(obj) container_of(obj, struct slave, kobj)
>+
>+static ssize_t slave_show(struct kobject *kobj,
>+ struct attribute *attr, char *buf)
>+{
>+ struct slave_attribute *slave_attr = to_slave_attr(attr);
>+ struct slave *slave = to_slave(kobj);
>+
>+ return slave_attr->show(slave, buf);
>+}
>+
>+const struct sysfs_ops slave_sysfs_ops = {
>+ .show = slave_show,
>+};
>+
>+static struct kobj_type slave_ktype = {
>+#ifdef CONFIG_SYSFS
>+ .sysfs_ops = &slave_sysfs_ops,
>+#endif
>+};
>+
>+int bond_sysfs_slave_add(struct slave *slave)
>+{
>+ const struct slave_attribute **a;
>+ int err;
>+
>+ err = kobject_init_and_add(&slave->kobj, &slave_ktype,
>+ &(slave->dev->dev.kobj), "slave");
>+ if (err)
>+ return err;
>+
>+ for (a = slave_attrs; *a; ++a) {
>+ err = sysfs_create_file(&slave->kobj, &((*a)->attr));
>+ if (err)
>+ return err;
>+ }
>+
>+ return 0;
>+}
>+
>+void bond_sysfs_slave_del(struct slave *slave)
>+{
>+ const struct slave_attribute **a;
>+
>+ for (a = slave_attrs; *a; ++a)
>+ sysfs_remove_file(&slave->kobj, &((*a)->attr));
>+
>+ kobject_del(&slave->kobj);
>+}
>diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>index 955dc48..309757d 100644
>--- a/drivers/net/bonding/bonding.h
>+++ b/drivers/net/bonding/bonding.h
>@@ -203,6 +203,7 @@ struct slave {
> #ifdef CONFIG_NET_POLL_CONTROLLER
> struct netpoll *np;
> #endif
>+ struct kobject kobj;
> };
>
> /*
>@@ -421,6 +422,8 @@ int bond_create(struct net *net, const char *name);
> int bond_create_sysfs(struct bond_net *net);
> void bond_destroy_sysfs(struct bond_net *net);
> void bond_prepare_sysfs_group(struct bonding *bond);
>+int bond_sysfs_slave_add(struct slave *slave);
>+void bond_sysfs_slave_del(struct slave *slave);
> int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev);
> int bond_release(struct net_device *bond_dev, struct net_device *slave_dev);
> int bond_xmit_hash(struct bonding *bond, struct sk_buff *skb, int count);
>@@ -469,6 +472,7 @@ int bond_option_lacp_rate_set(struct bonding *bond, int lacp_rate);
> int bond_option_ad_select_set(struct bonding *bond, int ad_select);
> struct net_device *bond_option_active_slave_get_rcu(struct bonding *bond);
> struct net_device *bond_option_active_slave_get(struct bonding *bond);
>+const char *bond_slave_link_status(s8 link);
>
> struct bond_net {
> struct net * net; /* Associated network namespace */
>
^ permalink raw reply
* VS: GOODNEWS
From: Ali Abdalla @ 2014-01-16 15:10 UTC (permalink / raw)
To: Ali Abdalla
In-Reply-To: <49E7F7F29A24D841A6C66C392779F2DB1E8C4E30@exch-mbx-01.utu.fi>
________________________________________
Lähettäjä: Ali Abdalla
Lähetetty: 16. tammikuuta 2014 16:57
Vastaanottaja: Ali Abdalla
Aihe: GOODNEWS
Donation to you, Contact Mrs Allen Large On ( allen_violet2010@outlook.com ) for more information.
^ 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