* Re: [PATCH net] netlink: fix wrong subscription bitmask to group mapping in
From: Pablo Neira Ayuso @ 2015-01-30 19:26 UTC (permalink / raw)
To: Ivan Delalande; +Cc: netdev, davem, andre
In-Reply-To: <20150129222701.GP17877@ycc.fr>
On Thu, Jan 29, 2015 at 11:27:01PM +0100, Ivan Delalande wrote:
> On Thu, Jan 29, 2015 at 10:51:53AM +0100, Pablo Neira Ayuso wrote:
> > The subscription bitmask passed via struct sockaddr_nl is converted to
> > the group number when calling the netlink_bind() and netlink_unbind()
> > callbacks.
> >
> > The conversion is however incorrect since bitmask (1 << 0) needs to be
> > mapped to group number 1. Note that you cannot specify the group number 0
> > (usually known as _NONE) from setsockopt() using NETLINK_ADD_MEMBERSHIP
> > since this is rejected through -EINVAL.
> >
> > This problem became noticeable since 97840cb ("netfilter: nfnetlink:
> > fix insufficient validation in nfnetlink_bind") when binding to bitmask
> > (1 << 0) in ctnetlink.
> >
> > Reported-by: Andre Tomt <andre@tomt.net>
> > Reported-by: Ivan Delalande <colona@arista.com>
> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
> Thanks a lot for this fix!
>
> > ---
> > v2: Rebased upon current net tree. Previous patch:
> >
> > http://patchwork.ozlabs.org/patch/426205/
> >
> > did not apply cleanly.
> >
> > net/netlink/af_netlink.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> > index 02fdde2..75532ef 100644
> > --- a/net/netlink/af_netlink.c
> > +++ b/net/netlink/af_netlink.c
> > @@ -1438,7 +1438,7 @@ static void netlink_undo_bind(int group, long unsigned int groups,
> >
> > for (undo = 0; undo < group; undo++)
> > if (test_bit(undo, &groups))
> > - nlk->netlink_unbind(sock_net(sk), undo);
> > + nlk->netlink_unbind(sock_net(sk), undo + 1);
> > }
> >
> > static int netlink_bind(struct socket *sock, struct sockaddr *addr,
> > @@ -1476,7 +1476,7 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
> > for (group = 0; group < nlk->ngroups; group++) {
> > if (!test_bit(group, &groups))
> > continue;
> > - err = nlk->netlink_bind(net, group);
> > + err = nlk->netlink_bind(net, group + 1);
> > if (!err)
> > continue;
> > netlink_undo_bind(group, groups, sk);
>
> I guess this should also be group + 1 there:
>
> netlink_undo_bind(group + 1, groups, sk);
We don't need that change you suggest.
Asumming nlk->netlink_bind(...) fails when 'group' is 0, then we have
nothing to undo.
See netlink_undo_bind():
for (undo = 0; undo < group; undo++)
if (test_bit(undo, &groups))
nlk->netlink_unbind(sock_net(sk), undo + 1);
'undo' and 'group' will be both 0, so nothing is undone as expected.
So my patch seems good to me after second look. Let me know if you
have more concerns, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: Add STT support.
From: Andy Gospodarek @ 2015-01-30 18:44 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Tom Herbert, Alexander Duyck, David Miller, netdev
In-Reply-To: <CALnjE+rjoRXnKsT9z2CK0BuYrxwqk+0FZq1=QwoPiysPN0gxZw@mail.gmail.com>
On Thu, Jan 29, 2015 at 09:03:14PM -0800, Pravin Shelar wrote:
> On Thu, Jan 29, 2015 at 8:17 PM, Tom Herbert <therbert@google.com> wrote:
> > On Thu, Jan 29, 2015 at 8:04 PM, Pravin Shelar <pshelar@nicira.com> wrote:
> >> On Thu, Jan 29, 2015 at 7:46 PM, Alexander Duyck
> >> <alexander.duyck@gmail.com> wrote:
> >>> On 01/29/2015 03:29 PM, Pravin B Shelar wrote:
> >>>> Following patch series adds support for Stateless Transport
> >>>> Tunneling protocol.
> >>>> STT uses TCP segmentation offload available in most of NIC. On
> >>>> packet xmit STT driver appends STT header along with TCP header
> >>>> to the packet. For GSO packet GSO parameters are set according
> >>>> to tunnel configuration and packet is handed over to networking
> >>>> stack. This allows use of segmentation offload available in NICs
> >>>>
> >>>> The protocol is documented at
> >>>> http://www.ietf.org/archive/id/draft-davie-stt-06.txt
> >>>>
> >>>> I will send out OVS userspace patch on ovs-dev mailing list.
> >>>>
> >>>> Following are test results. All tests are done on net-next with
> >>>> STT and VXLAN kernel device without OVS.
> >>>>
> >>>> Single Netperf session:
> >>>> =======================
> >>>> VXLAN:
> >>>> CPU utilization
> >>>> - Send local: 1.26
> >>>> - Recv remote: 8.62
> >>>> Throughput: 4.9 Gbit/sec
> >>>> STT:
> >>>> CPU utilization
> >>>> - Send local: 1.01
> >>>> - Recv remote: 1.8
> >>>> Throughput: 9.45 Gbit/sec
> >>>>
> >>>> Five Netperf sessions:
> >>>> ======================
> >>>> VXLAN:
> >>>> CPU utilization
> >>>> - Send local: 9.7
> >>>> - Recv remote: 70 (varies from 60 to 80)
> >>>> Throughput: 9.05 Gbit/sec
> >>>> STT:
> >>>> CPU utilization
> >>>> - Send local: 5.85
> >>>> - Recv remote: 14
> >>>> Throughput: 9.47 Gbit/sec
> >>>>
> >>>
> >>> What does the small packet or non-TCP performance look like for STT vs
> >>> VXLAN? My concern is that STT looks like it is a one trick pony since
> >>> all your numbers show is TCP TSO performance, and based on some of the
> >>> comments in your patches it seems like other protocols such as UDP are
> >>> going to suffer pretty badly due to things like the linearization overhead.
> >>>
> >>
> >> Current implementation is targeted for TCP workloads thats why I
> >> posted numbers with TCP, once UDP is optimized we can discuss UDP
> >> numbers. I am pretty sure the STT code can be optimized further
> >> specially for protocols other than TCP.
> >> --
> > There are many TCP workloads that use small packets, it is critical to
> > test for these also. E.g. "super_netperf 200 -H <addr> -l 120 -t
> > TCP_RR -- -r 1,1"
> >
> I have not tried it on STT device, I will collect those numbers.
>
> > Please provide the *exact* commands that you are using to configure
> > stt for optimal performance.
> >
> To create STT tunnel device.
> `ip link add stt1 type stt key 1 remote 1.1.2.128`
>
> No other configuration is needed.
Thanks for posting some performance numbers with your patch. I also
don't want to 'pile on' with additional complaints, but I do have one
request.
Can you share any specs (including number of cores and NIC hardware
used) for the systems that gave you the above results? If you do not
want to endorse a particular NIC that is fine -- I'm mostly curious how
many cores were used and if UDP and TCP RSS were both being used in this
configuration.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v2 1/6] skbuff: Add skb_list_linearize()
From: Sergei Shtylyov @ 2015-01-30 18:32 UTC (permalink / raw)
To: Pravin B Shelar, davem; +Cc: netdev
In-Reply-To: <1422574164-1860-1-git-send-email-pshelar@nicira.com>
Hello.
On 01/30/2015 02:29 AM, Pravin B Shelar wrote:
> similar to skb_linearize(), this API takes skb list as arg and
> linearize it into one big skb. STT driver patch will use this.
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
[...]
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 56db472..d6358a7 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2329,6 +2329,40 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to)
> }
> EXPORT_SYMBOL(skb_copy_and_csum_dev);
>
> +int skb_list_linearize(struct sk_buff *head, gfp_t gfp_mask)
> +{
> + struct sk_buff *skb;
> + int tlen = 0;
> + int err;
> +
> + err = skb_linearize(head);
> + if (err)
> + return err;
> +
> + skb = head->next;
> + while (skb) {
> + tlen += skb->len;
> + skb = skb->next;
> + }
for (skb = head->next; skb; skb = skb->next)
tlen += skb->len;
> + err = pskb_expand_head(head, 0, tlen, gfp_mask);
> + if (err)
> + return err;
> +
> + skb = head->next;
> + while (skb) {
> + err = skb_copy_bits(skb, 0, skb_tail_pointer(head), skb->len);
> + if (err)
> + return err;
> + head->tail += skb->len;
> + skb = skb->next;
> + }
Likewise, this can easily be converted into a *for* loop.
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/3] net: socket: enable async read and write
From: Tadeusz Struk @ 2015-01-30 18:30 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, netdev, davem, qat-linux, linux-kernel
In-Reply-To: <20150129231345.25156.51764.stgit@tstruk-mobl1>
On 01/29/2015 03:13 PM, Tadeusz Struk wrote:
> AIO read or write are not currently supported on sockets.
> This patch enables real socket async read/write.
>
> Please note - this patch is generated against cryptodev.
>
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> ---
> include/net/sock.h | 2 ++
> net/socket.c | 48 ++++++++++++++++++++++++++++++++++++++----------
> 2 files changed, 40 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 2210fec..2c7d160 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1397,6 +1397,8 @@ static inline struct kiocb *siocb_to_kiocb(struct sock_iocb *si)
> return si->kiocb;
> }
>
> +void sock_aio_complete(struct kiocb *iocb, long res, long res2);
> +
> struct socket_alloc {
> struct socket socket;
> struct inode vfs_inode;
> diff --git a/net/socket.c b/net/socket.c
> index a2c33a4..368fa9f 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -866,14 +866,25 @@ static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
> return sock->ops->splice_read(sock, ppos, pipe, len, flags);
> }
>
> +void sock_aio_complete(struct kiocb *iocb, long res, long res2)
> +{
> + struct sock_iocb *siocb = kiocb_to_siocb(iocb);
> +
> + kfree(siocb);
> + aio_complete(iocb, res, res2);
> +}
> +EXPORT_SYMBOL(sock_aio_complete);
> +
> static struct sock_iocb *alloc_sock_iocb(struct kiocb *iocb,
> struct sock_iocb *siocb)
> {
> - if (!is_sync_kiocb(iocb))
> - BUG();
> + if (!siocb)
> + siocb = kmalloc(sizeof(*siocb), GFP_KERNEL);
>
> - siocb->kiocb = iocb;
> - iocb->private = siocb;
> + if (siocb) {
> + siocb->kiocb = iocb;
> + iocb->private = siocb;
> + }
> return siocb;
> }
>
> @@ -901,7 +912,8 @@ static ssize_t do_sock_read(struct msghdr *msg, struct kiocb *iocb,
> static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
> unsigned long nr_segs, loff_t pos)
> {
> - struct sock_iocb siocb, *x;
> + struct sock_iocb siocb, *x = NULL;
> + int ret;
>
> if (pos != 0)
> return -ESPIPE;
> @@ -909,11 +921,18 @@ static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
> if (iocb->ki_nbytes == 0) /* Match SYS5 behaviour */
> return 0;
>
> + if (is_sync_kiocb(iocb))
> + x = &siocb;
>
> - x = alloc_sock_iocb(iocb, &siocb);
> + x = alloc_sock_iocb(iocb, x);
> if (!x)
> return -ENOMEM;
> - return do_sock_read(&x->async_msg, iocb, iocb->ki_filp, iov, nr_segs);
> + ret = do_sock_read(&x->async_msg, iocb, iocb->ki_filp, iov, nr_segs);
> +
> + if (!is_sync_kiocb(iocb) && ret != -EIOCBQUEUED)
> + kfree(x);
> +
> + return ret;
> }
>
> static ssize_t do_sock_write(struct msghdr *msg, struct kiocb *iocb,
> @@ -942,16 +961,25 @@ static ssize_t do_sock_write(struct msghdr *msg, struct kiocb *iocb,
> static ssize_t sock_aio_write(struct kiocb *iocb, const struct iovec *iov,
> unsigned long nr_segs, loff_t pos)
> {
> - struct sock_iocb siocb, *x;
> + struct sock_iocb siocb, *x = NULL;
> + int ret;
>
> if (pos != 0)
> return -ESPIPE;
>
> - x = alloc_sock_iocb(iocb, &siocb);
> + if (is_sync_kiocb(iocb))
> + x = &siocb;
> +
> + x = alloc_sock_iocb(iocb, x);
> if (!x)
> return -ENOMEM;
>
> - return do_sock_write(&x->async_msg, iocb, iocb->ki_filp, iov, nr_segs);
> + ret = do_sock_write(&x->async_msg, iocb, iocb->ki_filp, iov, nr_segs);
> +
> + if (!is_sync_kiocb(iocb) && ret != -EIOCBQUEUED)
> + kfree(x);
> +
> + return ret;
> }
>
> /*
Hi Herbert,
Just noticed that the struct sock_iocb has just been removed on net-next
(see [1]). What we can do is to call aio_complete() directly from
algif_skcipher, assuming that it is ok to call asynchronous read or
write with the struct msghdr allocated on the stack.
Please let me know what you think.
Thanks,
Tadeusz
[1]
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=7cc05662682da4b0e0a4fdf3c3f190577803ae81
^ permalink raw reply
* [PATCH net-next v3 3/3] net-timestamp: no-payload option in txtimestamp test
From: Willem de Bruijn @ 2015-01-30 18:29 UTC (permalink / raw)
To: netdev; +Cc: davem, richardcochran, luto, Willem de Bruijn
In-Reply-To: <1422642573-6126-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Demonstrate how SOF_TIMESTAMPING_OPT_TSONLY can be used and
test the implementation.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
.../networking/timestamping/txtimestamp.c | 28 ++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/timestamping/txtimestamp.c b/Documentation/networking/timestamping/txtimestamp.c
index 05694fe..8217510 100644
--- a/Documentation/networking/timestamping/txtimestamp.c
+++ b/Documentation/networking/timestamping/txtimestamp.c
@@ -70,6 +70,7 @@ static int do_ipv6 = 1;
static int cfg_payload_len = 10;
static bool cfg_show_payload;
static bool cfg_do_pktinfo;
+static bool cfg_loop_nodata;
static uint16_t dest_port = 9000;
static struct sockaddr_in daddr;
@@ -141,6 +142,9 @@ static void print_payload(char *data, int len)
{
int i;
+ if (!len)
+ return;
+
if (len > 70)
len = 70;
@@ -177,6 +181,7 @@ static void __recv_errmsg_cmsg(struct msghdr *msg, int payload_len)
struct sock_extended_err *serr = NULL;
struct scm_timestamping *tss = NULL;
struct cmsghdr *cm;
+ int batch = 0;
for (cm = CMSG_FIRSTHDR(msg);
cm && cm->cmsg_len;
@@ -209,10 +214,18 @@ static void __recv_errmsg_cmsg(struct msghdr *msg, int payload_len)
} else
fprintf(stderr, "unknown cmsg %d,%d\n",
cm->cmsg_level, cm->cmsg_type);
+
+ if (serr && tss) {
+ print_timestamp(tss, serr->ee_info, serr->ee_data,
+ payload_len);
+ serr = NULL;
+ tss = NULL;
+ batch++;
+ }
}
- if (serr && tss)
- print_timestamp(tss, serr->ee_info, serr->ee_data, payload_len);
+ if (batch > 1)
+ fprintf(stderr, "batched %d timestamps\n", batch);
}
static int recv_errmsg(int fd)
@@ -244,7 +257,7 @@ static int recv_errmsg(int fd)
if (ret == -1 && errno != EAGAIN)
error(1, errno, "recvmsg");
- if (ret > 0) {
+ if (ret >= 0) {
__recv_errmsg_cmsg(&msg, ret);
if (cfg_show_payload)
print_payload(data, cfg_payload_len);
@@ -309,6 +322,9 @@ static void do_test(int family, unsigned int opt)
opt |= SOF_TIMESTAMPING_SOFTWARE |
SOF_TIMESTAMPING_OPT_CMSG |
SOF_TIMESTAMPING_OPT_ID;
+ if (cfg_loop_nodata)
+ opt |= SOF_TIMESTAMPING_OPT_TSONLY;
+
if (setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING,
(char *) &opt, sizeof(opt)))
error(1, 0, "setsockopt timestamping");
@@ -378,6 +394,7 @@ static void __attribute__((noreturn)) usage(const char *filepath)
" -h: show this message\n"
" -I: request PKTINFO\n"
" -l N: send N bytes at a time\n"
+ " -n: set no-payload option\n"
" -r: use raw\n"
" -R: use raw (IP_HDRINCL)\n"
" -p N: connect to port N\n"
@@ -392,7 +409,7 @@ static void parse_opt(int argc, char **argv)
int proto_count = 0;
char c;
- while ((c = getopt(argc, argv, "46hIl:p:rRux")) != -1) {
+ while ((c = getopt(argc, argv, "46hIl:np:rRux")) != -1) {
switch (c) {
case '4':
do_ipv6 = 0;
@@ -403,6 +420,9 @@ static void parse_opt(int argc, char **argv)
case 'I':
cfg_do_pktinfo = true;
break;
+ case 'n':
+ cfg_loop_nodata = true;
+ break;
case 'r':
proto_count++;
cfg_proto = SOCK_RAW;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next v3 1/3] net-timestamp: no-payload option
From: Willem de Bruijn @ 2015-01-30 18:29 UTC (permalink / raw)
To: netdev; +Cc: davem, richardcochran, luto, Willem de Bruijn
In-Reply-To: <1422642573-6126-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Add timestamping option SOF_TIMESTAMPING_OPT_TSONLY. For transmit
timestamps, this loops timestamps on top of empty packets.
Doing so reduces the pressure on SO_RCVBUF. Payload inspection and
cmsg reception (aside from timestamps) are no longer possible. This
works together with a follow on patch that allows administrators to
only allow tx timestamping if it does not loop payload or metadata.
Signed-off-by: Willem de Bruijn <willemb@google.com>
----
Changes (rfc -> v1)
- add documentation
- remove unnecessary skb->len test (thanks to Richard Cochran)
---
Documentation/networking/timestamping.txt | 21 +++++++++++++++++++++
include/uapi/linux/net_tstamp.h | 3 ++-
net/core/skbuff.c | 19 ++++++++++++++-----
net/ipv4/ip_sockglue.c | 7 ++++---
net/ipv6/datagram.c | 5 ++---
net/rxrpc/ar-error.c | 5 +++++
6 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index a5c784c..5f09226 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -162,6 +162,27 @@ SOF_TIMESTAMPING_OPT_CMSG:
option IP_PKTINFO simultaneously.
+SOF_TIMESTAMPING_OPT_TSONLY:
+
+ Applies to transmit timestamps only. Makes the kernel return the
+ timestamp as a cmsg alongside an empty packet, as opposed to
+ alongside the original packet. This reduces the amount of memory
+ charged to the socket's receive budget (SO_RCVBUF) and delivers
+ the timestamp even if sysctl net.core.tstamp_allow_data is 0.
+ This option disables SOF_TIMESTAMPING_OPT_CMSG.
+
+
+New applications are encouraged to pass SOF_TIMESTAMPING_OPT_ID to
+disambiguate timestamps and SOF_TIMESTAMPING_OPT_TSONLY to operate
+regardless of the setting of sysctl net.core.tstamp_allow_data.
+
+An exception is when a process needs additional cmsg data, for
+instance SOL_IP/IP_PKTINFO to detect the egress network interface.
+Then pass option SOF_TIMESTAMPING_OPT_CMSG. This option depends on
+having access to the contents of the original packet, so cannot be
+combined with SOF_TIMESTAMPING_OPT_TSONLY.
+
+
1.4 Bytestream Timestamps
The SO_TIMESTAMPING interface supports timestamping of bytes in a
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index edbc888..6d1abea 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -24,8 +24,9 @@ enum {
SOF_TIMESTAMPING_TX_SCHED = (1<<8),
SOF_TIMESTAMPING_TX_ACK = (1<<9),
SOF_TIMESTAMPING_OPT_CMSG = (1<<10),
+ SOF_TIMESTAMPING_OPT_TSONLY = (1<<11),
- SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_CMSG,
+ SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_TSONLY,
SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_LAST - 1) |
SOF_TIMESTAMPING_LAST
};
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 56db472..65a3798 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3710,19 +3710,28 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
struct sock *sk, int tstype)
{
struct sk_buff *skb;
+ bool tsonly = sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TSONLY;
if (!sk)
return;
- if (hwtstamps)
- *skb_hwtstamps(orig_skb) = *hwtstamps;
+ if (tsonly)
+ skb = alloc_skb(0, GFP_ATOMIC);
else
- orig_skb->tstamp = ktime_get_real();
-
- skb = skb_clone(orig_skb, GFP_ATOMIC);
+ skb = skb_clone(orig_skb, GFP_ATOMIC);
if (!skb)
return;
+ if (tsonly) {
+ skb_shinfo(skb)->tx_flags = skb_shinfo(orig_skb)->tx_flags;
+ skb_shinfo(skb)->tskey = skb_shinfo(orig_skb)->tskey;
+ }
+
+ if (hwtstamps)
+ *skb_hwtstamps(skb) = *hwtstamps;
+ else
+ skb->tstamp = ktime_get_real();
+
__skb_complete_tx_timestamp(skb, sk, tstype);
}
EXPORT_SYMBOL_GPL(__skb_tstamp_tx);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index db5e0f8..31d8c71 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -483,7 +483,7 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
serr = SKB_EXT_ERR(skb);
- if (sin) {
+ if (sin && skb->len) {
sin->sin_family = AF_INET;
sin->sin_addr.s_addr = *(__be32 *)(skb_network_header(skb) +
serr->addr_offset);
@@ -496,8 +496,9 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
sin = &errhdr.offender;
memset(sin, 0, sizeof(*sin));
- if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
- ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin)) {
+ if (skb->len &&
+ (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
+ ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin))) {
sin->sin_family = AF_INET;
sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
if (inet_sk(sk)->cmsg_flags)
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 49f5e73..c215be7 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -369,7 +369,7 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
serr = SKB_EXT_ERR(skb);
- if (sin) {
+ if (sin && skb->len) {
const unsigned char *nh = skb_network_header(skb);
sin->sin6_family = AF_INET6;
sin->sin6_flowinfo = 0;
@@ -394,8 +394,7 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
sin = &errhdr.offender;
memset(sin, 0, sizeof(*sin));
-
- if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {
+ if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL && skb->len) {
sin->sin6_family = AF_INET6;
if (np->rxopt.all) {
if (serr->ee.ee_origin != SO_EE_ORIGIN_ICMP &&
diff --git a/net/rxrpc/ar-error.c b/net/rxrpc/ar-error.c
index 74c0fcd..5394b6b 100644
--- a/net/rxrpc/ar-error.c
+++ b/net/rxrpc/ar-error.c
@@ -42,6 +42,11 @@ void rxrpc_UDP_error_report(struct sock *sk)
_leave("UDP socket errqueue empty");
return;
}
+ if (!skb->len) {
+ _leave("UDP empty message");
+ kfree_skb(skb);
+ return;
+ }
rxrpc_new_skb(skb);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next v3 2/3] net-timestamp: no-payload only sysctl
From: Willem de Bruijn @ 2015-01-30 18:29 UTC (permalink / raw)
To: netdev; +Cc: davem, richardcochran, luto, Willem de Bruijn
In-Reply-To: <1422642573-6126-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Tx timestamps are looped onto the error queue on top of an skb. This
mechanism leaks packet headers to processes unless the no-payload
options SOF_TIMESTAMPING_OPT_TSONLY is set.
Add a sysctl that optionally drops looped timestamp with data. This
only affects processes without CAP_NET_RAW.
The policy is checked when timestamps are generated in the stack.
It is possible for timestamps with data to be reported after the
sysctl is set, if these were queued internally earlier.
No vulnerability is immediately known that exploits knowledge
gleaned from packet headers, but it may still be preferable to allow
administrators to lock down this path at the cost of possible
breakage of legacy applications.
Signed-off-by: Willem de Bruijn <willemb@google.com>
----
Changes
(v1 -> v2)
- test socket CAP_NET_RAW instead of capable(CAP_NET_RAW)
(rfc -> v1)
- document the sysctl in Documentation/sysctl/net.txt
- fix access control race: read .._OPT_TSONLY only once,
use same value for permission check and skb generation.
---
Documentation/sysctl/net.txt | 8 ++++++++
include/net/sock.h | 1 +
net/core/skbuff.c | 21 ++++++++++++++++++++-
net/core/sock.c | 3 +++
net/core/sysctl_net_core.c | 9 +++++++++
5 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
index 666594b..6294b51 100644
--- a/Documentation/sysctl/net.txt
+++ b/Documentation/sysctl/net.txt
@@ -97,6 +97,14 @@ rmem_max
The maximum receive socket buffer size in bytes.
+tstamp_allow_data
+-----------------
+Allow processes to receive tx timestamps looped together with the original
+packet contents. If disabled, transmit timestamp requests from unprivileged
+processes are dropped unless socket option SOF_TIMESTAMPING_OPT_TSONLY is set.
+Default: 1 (on)
+
+
wmem_default
------------
diff --git a/include/net/sock.h b/include/net/sock.h
index 1534149..511ef7c8 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2239,6 +2239,7 @@ bool sk_net_capable(const struct sock *sk, int cap);
extern __u32 sysctl_wmem_max;
extern __u32 sysctl_rmem_max;
+extern int sysctl_tstamp_allow_data;
extern int sysctl_optmem_max;
extern __u32 sysctl_wmem_default;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 65a3798..a5bff27 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -74,6 +74,8 @@
#include <asm/uaccess.h>
#include <trace/events/skb.h>
#include <linux/highmem.h>
+#include <linux/capability.h>
+#include <linux/user_namespace.h>
struct kmem_cache *skbuff_head_cache __read_mostly;
static struct kmem_cache *skbuff_fclone_cache __read_mostly;
@@ -3690,11 +3692,28 @@ static void __skb_complete_tx_timestamp(struct sk_buff *skb,
kfree_skb(skb);
}
+static bool skb_may_tx_timestamp(struct sock *sk, bool tsonly)
+{
+ bool ret;
+
+ if (likely(sysctl_tstamp_allow_data || tsonly))
+ return true;
+
+ read_lock_bh(&sk->sk_callback_lock);
+ ret = sk->sk_socket && sk->sk_socket->file &&
+ file_ns_capable(sk->sk_socket->file, &init_user_ns, CAP_NET_RAW);
+ read_unlock_bh(&sk->sk_callback_lock);
+ return ret;
+}
+
void skb_complete_tx_timestamp(struct sk_buff *skb,
struct skb_shared_hwtstamps *hwtstamps)
{
struct sock *sk = skb->sk;
+ if (!skb_may_tx_timestamp(sk, false))
+ return;
+
/* take a reference to prevent skb_orphan() from freeing the socket */
sock_hold(sk);
@@ -3712,7 +3731,7 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
struct sk_buff *skb;
bool tsonly = sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TSONLY;
- if (!sk)
+ if (!sk || !skb_may_tx_timestamp(sk, tsonly))
return;
if (tsonly)
diff --git a/net/core/sock.c b/net/core/sock.c
index 1c7a33d..93c8b20 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -325,6 +325,8 @@ __u32 sysctl_rmem_default __read_mostly = SK_RMEM_MAX;
int sysctl_optmem_max __read_mostly = sizeof(unsigned long)*(2*UIO_MAXIOV+512);
EXPORT_SYMBOL(sysctl_optmem_max);
+int sysctl_tstamp_allow_data __read_mostly = 1;
+
struct static_key memalloc_socks = STATIC_KEY_INIT_FALSE;
EXPORT_SYMBOL_GPL(memalloc_socks);
@@ -840,6 +842,7 @@ set_rcvbuf:
ret = -EINVAL;
break;
}
+
if (val & SOF_TIMESTAMPING_OPT_ID &&
!(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_ID)) {
if (sk->sk_protocol == IPPROTO_TCP) {
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 31baba2..fde21d1 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -321,6 +321,15 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "tstamp_allow_data",
+ .data = &sysctl_tstamp_allow_data,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &one
+ },
#ifdef CONFIG_RPS
{
.procname = "rps_sock_flow_entries",
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next v3 0/3] net-timestamp: blinding
From: Willem de Bruijn @ 2015-01-30 18:29 UTC (permalink / raw)
To: netdev; +Cc: davem, richardcochran, luto, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Changes
(v2 -> v3)
- rebase only: v2 did not make it to patchwork / netdev
(v1 -> v2)
- fix capability check in patch 2
this could be moved into net/core/sock.c as sk_capable_nouser()
(rfc -> v1)
- dropped patch 4: timestamp batching
due to complexity, as discussed
- dropped patch 5: default mode
because it does not really cover all use cases, as discussed
- added documentation
- minor fix, see patch 2
Two issues were raised during recent timestamping discussions:
1. looping full packets on the error queue exposes packet headers
2. TCP timestamping with retransmissions generates many timestamps
This RFC patchset is an attempt at addressing both without breaking
legacy behavior.
Patch 1 reintroduces the "no payload" timestamp option, which loops
timestamps onto an empty skb. This reduces the pressure on SO_RCVBUF
from looping many timestamps. It does not reduce the number of recv()
calls needed to process them. The timestamp cookie mechanism developed
in http://patchwork.ozlabs.org/patch/427213/ did, but this is
considerably simpler.
Patch 2 then gives administrators the power to block all timestamp
requests that contain data by unprivileged users. I proposed this
earlier as a backward compatible workaround in the discussion of
net-timestamp: pull headers for SOCK_STREAM
http://patchwork.ozlabs.org/patch/414810/
Patch 3 only updates the txtimestamp example to test this option.
Verified that with option '-n', length is zero in all cases and
option '-I' (PKTINFO) stops working.
Willem de Bruijn (3):
net-timestamp: no-payload option
net-timestamp: no-payload only sysctl
net-timestamp: no-payload option in txtimestamp test
Documentation/networking/timestamping.txt | 21 ++++++++++++
.../networking/timestamping/txtimestamp.c | 28 ++++++++++++---
Documentation/sysctl/net.txt | 8 +++++
include/net/sock.h | 1 +
include/uapi/linux/net_tstamp.h | 3 +-
net/core/skbuff.c | 40 ++++++++++++++++++----
net/core/sock.c | 3 ++
net/core/sysctl_net_core.c | 9 +++++
net/ipv4/ip_sockglue.c | 7 ++--
net/ipv6/datagram.c | 5 ++-
net/rxrpc/ar-error.c | 5 +++
11 files changed, 113 insertions(+), 17 deletions(-)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply
* Re: [PATCH V2 5/6] rtlwifi: btcoexist: Add routines for RTL8812AE kernel socket communications
From: Marcel Holtmann @ 2015-01-30 18:05 UTC (permalink / raw)
To: Larry Finger
Cc: Kalle Valo, linux-wireless, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54CBA0CE.8030800-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Hi Larry,
>>> I'm adding bluetooth list to the discussion. Full patch is available
>>> here:
>>>
>>> https://patchwork.kernel.org/patch/5712591/
<snip>
>>> So the wireless driver communicates with the bluetooth driver (which is
>>> not in upstream) via a localhost UDP connection?
>>
>> I think the first order of business should be to get the Bluetooth driver upstream. Until that has happened this is all kinda pointless discussion.
>
> I agree with this; however, the last time I tried to submit a BT driver for Realtek, I was told that this driver should use some (as yet included) feature. I have watched the driver development, and if that feature was ever included, it was in a form that I did not recognize. I'm sorry that this is vague, but this happened a long time ago.
if the Bluetooth side is running over USB, then it should be driven from the existing btusb.ko module with a vendor specific ->setup() callback. However nothing materialized that I could merge it.
>>> I know there's a general need for something similar like this, but it
>>> needs to properly discussed and designed.
>>
>> This is just insane. Clear NAK.
>>
>> Two kernel modules will not use UDP ports over the loopback interface to communicate with each other.
>
> I will work on combining the latest BT drivers from Realtek with btusb to see if I can achieve a patch that will both work with the Realtek hardware, and get approval from the reviewers.
>
> What would be an approved method of communicating between two kernel modules? Is there some example in the kernel that I could study?
We need a btcoex subsystem that both WiFi and Bluetooth can register to and communicate with.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/9] nftables: reject NFT_SET_ELEM_INTERVAL_END flag for non-interval sets
From: Pablo Neira Ayuso @ 2015-01-30 18:00 UTC (permalink / raw)
To: Patrick McHardy
Cc: herbert, tgraf, davem, David.Laight, ying.xue, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150130175525.GA8670@acer.localdomain>
On Fri, Jan 30, 2015 at 05:55:26PM +0000, Patrick McHardy wrote:
> On 30.01, Pablo Neira Ayuso wrote:
> > Hi Patrick,
> >
> > Unless you have any concern, I'm going to apply this and 8/9 to
> > nf-next, so you don't need to resend these two sanitization fixes.
>
> This one is not needed for mainline so far since nft_hash validates
> on its own. It is only required since my series centralizes that
> validation once the set extensions are added.
>
> For 8/9, sure.
OK, I'll take 8/9 then, thanks!
^ permalink raw reply
* Re: [PATCH 2/9] nftables: reject NFT_SET_ELEM_INTERVAL_END flag for non-interval sets
From: Patrick McHardy @ 2015-01-30 17:55 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: herbert, tgraf, davem, David.Laight, ying.xue, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150130173107.GA9243@salvia>
On 30.01, Pablo Neira Ayuso wrote:
> Hi Patrick,
>
> Unless you have any concern, I'm going to apply this and 8/9 to
> nf-next, so you don't need to resend these two sanitization fixes.
This one is not needed for mainline so far since nft_hash validates
on its own. It is only required since my series centralizes that
validation once the set extensions are added.
For 8/9, sure.
^ permalink raw reply
* Re: [PATCH net-next] tcp: use SACK RTTs for CC
From: Yuchung Cheng @ 2015-01-30 17:47 UTC (permalink / raw)
To: Kenneth Klette Jonassen; +Cc: netdev, Neal Cardwell
In-Reply-To: <CAK6E8=c6uAeAMvRfdxYNcqBLWmFTywbpvaqmzf7XmajkGSNqeg@mail.gmail.com>
On Fri, Jan 30, 2015 at 9:21 AM, Yuchung Cheng <ycheng@google.com> wrote:
> On Thu, Jan 29, 2015 at 11:08 AM, Kenneth Klette Jonassen
> <kennetkl@ifi.uio.no> wrote:
>> Current behavior only passes RTTs from sequentially acked data to CC.
>>
>> If sender gets a combined ACK for segment 1 and SACK for segment 3, then the
>> computed RTT for CC is the time between sending segment 1 and receiving SACK
>> for segment 3.
> since segment 3 is sent after segment 1, sack_rtt_us <= ca_seq_rtt so
> taking a min is not necessary?
ah i didn't notice you are taking a min_t of ulong for invalid
sack_rtt_us now i get it.
>
>>
>> Pass the minimum computed RTT from any acked data to CC, i.e. time between
>> sending segment 3 and receiving SACK for segment 3.
>>
>> Signed-off-by: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
>> ---
>> net/ipv4/tcp_input.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 71fb37c..ed11931 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -3183,8 +3183,10 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
>>
>> tp->fackets_out -= min(pkts_acked, tp->fackets_out);
>>
>> - if (ca_ops->pkts_acked)
>> - ca_ops->pkts_acked(sk, pkts_acked, ca_seq_rtt_us);
>> + if (ca_ops->pkts_acked) {
>> + long rtt_us = min_t(ulong, ca_seq_rtt_us, sack_rtt_us);
>> + ca_ops->pkts_acked(sk, pkts_acked, rtt_us);
>> + }
>>
>> } else if (skb && rtt_update && sack_rtt_us >= 0 &&
>> sack_rtt_us > skb_mstamp_us_delta(&now, &skb->skb_mstamp)) {
>> --
>> 1.9.1
>>
>> --
>> 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 2/9] nftables: reject NFT_SET_ELEM_INTERVAL_END flag for non-interval sets
From: Pablo Neira Ayuso @ 2015-01-30 17:31 UTC (permalink / raw)
To: Patrick McHardy
Cc: herbert, tgraf, davem, David.Laight, ying.xue, paulmck, netdev,
netfilter-devel
In-Reply-To: <1422603994-5836-3-git-send-email-kaber@trash.net>
Hi Patrick,
Unless you have any concern, I'm going to apply this and 8/9 to
nf-next, so you don't need to resend these two sanitization fixes.
Thanks.
On Fri, Jan 30, 2015 at 07:46:27AM +0000, Patrick McHardy wrote:
> Signed-off-by: Patrick McHardy <kaber@trash.net>
> ---
> net/netfilter/nf_tables_api.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> index 129a8da..92ba4a0 100644
> --- a/net/netfilter/nf_tables_api.c
> +++ b/net/netfilter/nf_tables_api.c
> @@ -3112,6 +3112,9 @@ static int nft_add_set_elem(struct nft_ctx *ctx, struct nft_set *set,
> elem.flags = ntohl(nla_get_be32(nla[NFTA_SET_ELEM_FLAGS]));
> if (elem.flags & ~NFT_SET_ELEM_INTERVAL_END)
> return -EINVAL;
> + if (!(set->flags & NFT_SET_INTERVAL) &&
> + elem.flags & NFT_SET_ELEM_INTERVAL_END)
> + return -EINVAL;
> }
>
> if (set->flags & NFT_SET_MAP) {
> --
> 2.1.0
>
> --
> 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
* [PATCH net] sunvnet: set queue mapping when doing packet copies
From: David L Stevens @ 2015-01-30 17:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sowmini Varadhan, Eric Dumazet
In-Reply-To: <54C90AED.7040404@oracle.com>
This patch fixes a bug where vnet_skb_shape() didn't set the already-selected
queue mapping when a packet copy was required. This results in using the
wrong queue index for stops/starts, hung tx queues and watchdog timeouts
under heavy load.
Signed-off-by: David L Stevens <david.stevens@oracle.com>
Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
--
I'm resubmitting this in its original form. Since skb_segment() doesn't do
TCP flow control either, due to an incorrect destructor check, and those
issues raised by Eric are a matter of fairness, while this missing queue_mapping
assignment results in crashes, I'd like to get this piece fixed separately.
---
drivers/net/ethernet/sun/sunvnet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/sun/sunvnet.c b/drivers/net/ethernet/sun/sunvnet.c
index 2b719cc..2b10b85 100644
--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -1123,6 +1123,7 @@ static inline struct sk_buff *vnet_skb_shape(struct sk_buff *skb, int ncookies)
skb_shinfo(nskb)->gso_size = skb_shinfo(skb)->gso_size;
skb_shinfo(nskb)->gso_type = skb_shinfo(skb)->gso_type;
}
+ nskb->queue_mapping = skb->queue_mapping;
dev_kfree_skb(skb);
skb = nskb;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] tcp: use SACK RTTs for CC
From: Yuchung Cheng @ 2015-01-30 17:21 UTC (permalink / raw)
To: Kenneth Klette Jonassen; +Cc: netdev, Neal Cardwell
In-Reply-To: <1422558483-6168-1-git-send-email-kennetkl@ifi.uio.no>
On Thu, Jan 29, 2015 at 11:08 AM, Kenneth Klette Jonassen
<kennetkl@ifi.uio.no> wrote:
> Current behavior only passes RTTs from sequentially acked data to CC.
>
> If sender gets a combined ACK for segment 1 and SACK for segment 3, then the
> computed RTT for CC is the time between sending segment 1 and receiving SACK
> for segment 3.
since segment 3 is sent after segment 1, sack_rtt_us <= ca_seq_rtt so
taking a min is not necessary?
>
> Pass the minimum computed RTT from any acked data to CC, i.e. time between
> sending segment 3 and receiving SACK for segment 3.
>
> Signed-off-by: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
> ---
> net/ipv4/tcp_input.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 71fb37c..ed11931 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -3183,8 +3183,10 @@ static int tcp_clean_rtx_queue(struct sock *sk, int prior_fackets,
>
> tp->fackets_out -= min(pkts_acked, tp->fackets_out);
>
> - if (ca_ops->pkts_acked)
> - ca_ops->pkts_acked(sk, pkts_acked, ca_seq_rtt_us);
> + if (ca_ops->pkts_acked) {
> + long rtt_us = min_t(ulong, ca_seq_rtt_us, sack_rtt_us);
> + ca_ops->pkts_acked(sk, pkts_acked, rtt_us);
> + }
>
> } else if (skb && rtt_update && sack_rtt_us >= 0 &&
> sack_rtt_us > skb_mstamp_us_delta(&now, &skb->skb_mstamp)) {
> --
> 1.9.1
>
> --
> 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 -mainline] fm10k: drop upper bits of VLAN ID
From: Vick, Matthew @ 2015-01-30 17:05 UTC (permalink / raw)
To: Dan Carpenter, Kirsher, Jeffrey T, Alexander Duyck
Cc: kernel-janitors@vger.kernel.org,
e1000-devel@lists.sourceforge.net, Allan, Bruce W,
Brandeburg, Jesse, Linux NICS, Ronciak, John,
netdev@vger.kernel.org
In-Reply-To: <20150130105038.GL6507@mwanda>
On 1/30/15, 2:50 AM, "Dan Carpenter" <dan.carpenter@oracle.com> wrote:
>On Fri, Jan 30, 2015 at 11:41:27AM +0300, Dan Carpenter wrote:
>> Static checkers complain that the shifts in "(vid << 4) >> 4" perfectly
>> cancel each other out and the code is a no-op. "vid" is a u16. The
>> comment says that the intention here is to drop the upper bits so I have
>> added a cast to "u16" to do that.
>>
>> Fixes: 401b5383c6c9 ('fm10k: Add support for configuring PF interface')
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
>Oh... Rasmus Villemoes already fixed this.
>
>regards,
>dan carpenter
Yep, we have a patch coming through Jeff's tree now to resolve the issue
(technically my version of the patch, which doesn't try to mask off the
bits but instead rejects an out-of-bounds VLAN ID). Thanks, Dan!
Cheers,
Matthew
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next v4 0/7] switchdev offload flags
From: Jiri Pirko @ 2015-01-30 16:59 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, vyasevic,
ronen.arad, netdev, davem, shm, gospo
In-Reply-To: <1422600017-42393-1-git-send-email-roopa@cumulusnetworks.com>
Fri, Jan 30, 2015 at 07:40:10AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This patch series introduces new offload flags for switchdev.
>Kernel network subsystems can use this flag to accelerate
>network functions by offloading to hw.
>
>I expect that there will be need for subsystem specific feature
>flag in the future.
>
>This patch series currently only addresses bridge driver link
>attribute offloads to hardware.
>
>Looking at the current state of bridge l2 offload in the kernel,
> - flag 'self' is the way to directly manage the bridge device in hw via
> the ndo_bridge_setlink/ndo_bridge_getlink calls
>
> - flag 'master' is always used to manage the in kernel bridge devices
> via the same ndo_bridge_setlink/ndo_bridge_getlink calls
>
>Today these are used separately. The nic offloads use hwmode "vepa/veb" to go
>directly to hw with the "self" flag.
>
>At this point i am trying not to introduce any new user facing flags/attributes.
>In the model where we want the kernel bridging to be accelerated with
>hardware, we very much want the bridge driver to be involved.
>
>In this proposal,
>- The offload flag/bit helps switch asic drivers to indicate that they
> accelerate the kernel networking objects/functions
>- The user does not have to specify a new flag to do so. A bridge created with
> switch asic ports will be accelerated if the switch driver supports it.
>- The user can continue to directly manage l2 in nics (ixgbe) using the
> existing hwmode/self flags
>- It also does not stop users from using the 'self' flag to talk to the
> switch asic driver directly
>- Involving the bridge driver makes sure the add/del notifications to user
> space go out after both kernel and hardware are programmed
>
>(To selectively offload bridge port attributes,
>example learning in hw only etc, we can introduce offload bits for
>per bridge port flag attribute as in my previous patch
>https://patchwork.ozlabs.org/patch/413211/. I have not included that in this
>series)
>
>v2
> - try a different name for the offload flag/bit
> - tries to solve the stacked netdev case by traversing the lowerdev
> list to reach the switch port
>
>v3 -
> - Tested with bond as bridge port for the stacked device case.
> Includes a bond_fix_features change to not ignore the
> NETIF_F_HW_NETFUNC_OFFLOAD flag
> - Some checkpatch fixes
>
>v4 -
> - rename flag to NETIF_F_HW_SWITCH_OFFLOAD
> - add ndo_bridge_setlink/dellink handlers in bond and team drivers as
> suggested by jiri.
> - introduce default ndo_dflt_netdev_switch_port_bridge_setlink/dellink
> handlers that masters can use to call offload api on lowerdevs.
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Having a flu and being completely unusable, I gave this patchset a quick
peek and looks allright. I will review once I recover (Sun/Mon).
Not sure if Dave wants to hold the patchset until then.
>
>Roopa Prabhu (7):
> netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for
> switch device offloads
> bridge: add flags argument to ndo_bridge_setlink and
> ndo_bridge_dellink
> swdevice: add new apis to set and del bridge port attributes
> bridge: offload bridge port attributes to switch asic if feature flag
> set
> rocker: set feature NETIF_F_HW_SWITCH_OFFLOAD
> bonding: handle NETIF_F_HW_SWITCH_OFFLOAD flag and add
> ndo_bridge_setlink/dellink handlers
> team: handle NETIF_F_HW_SWITCH_OFFLOAD flag and add
> ndo_bridge_setlink/dellink handlers
>
> drivers/net/bonding/bond_main.c | 9 +-
> drivers/net/ethernet/emulex/benet/be_main.c | 3 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
> drivers/net/ethernet/rocker/rocker.c | 5 +-
> drivers/net/team/team.c | 5 +-
> include/linux/netdev_features.h | 6 +-
> include/linux/netdevice.h | 6 +-
> include/net/switchdev.h | 37 ++++++++-
> net/bridge/br_netlink.c | 30 +++++--
> net/bridge/br_private.h | 4 +-
> net/core/rtnetlink.c | 10 ++-
> net/switchdev/switchdev.c | 110 +++++++++++++++++++++++++
> 12 files changed, 206 insertions(+), 21 deletions(-)
>
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH v2 11/11] hso: fix rfkill name conflicts
From: Dan Williams @ 2015-01-30 16:59 UTC (permalink / raw)
To: Olivier Sobrie; +Cc: Jan Dumon, linux-kernel, linux-usb, netdev
In-Reply-To: <20150130161555.GA22140@thinkoso.home>
On Fri, 2015-01-30 at 17:15 +0100, Olivier Sobrie wrote:
> Hello Dan,
>
> On Fri, Jan 30, 2015 at 09:47:59AM -0600, Dan Williams wrote:
> > On Fri, 2015-01-30 at 13:22 +0100, Olivier Sobrie wrote:
> > > By using only the usb interface number for the rfkill name, we might
> > > have a name conflicts in case two similar hso devices are connected.
> > >
> > > In this patch, the name of the hso rfkill interface embed the value
> > > of a counter that is incremented each time a new rfkill interface is
> > > added.
> > >
> > > Suggested-by: Dan Williams <dcbw@redhat.com>
> > > Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
> > > ---
> > > drivers/net/usb/hso.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> > > index c14fc80..d31a165 100644
> > > --- a/drivers/net/usb/hso.c
> > > +++ b/drivers/net/usb/hso.c
> > > @@ -153,7 +153,7 @@ struct hso_net {
> > > struct hso_device *parent;
> > > struct net_device *net;
> > > struct rfkill *rfkill;
> > > - char name[8];
> > > + char name[24];
> > >
> > > struct usb_endpoint_descriptor *in_endp;
> > > struct usb_endpoint_descriptor *out_endp;
> > > @@ -2469,9 +2469,10 @@ static void hso_create_rfkill(struct hso_device *hso_dev,
> > > {
> > > struct hso_net *hso_net = dev2net(hso_dev);
> > > struct device *dev = &hso_net->net->dev;
> > > + static u32 rfkill_counter;
> >
> > It'll probably be initialized to 0, but still, it would feel safer with
> > an explicit "rfkill_counter = 0"...
> >
>
> If I set explicitly rfkill_counter = 0, checkpatch triggers an error:
>
> ERROR: do not initialise statics to 0 or NULL
> #36: FILE: drivers/net/usb/hso.c:2472:
> + static u32 rfkill_counter = 0;
Well OK then, life has changed since I last submitted a patch with a
static variable :) If checkpatch complains, then it is almost always
correct, and you can ignore me.
Dan
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: Add STT support.
From: Rick Jones @ 2015-01-30 16:46 UTC (permalink / raw)
To: Pravin Shelar, Alexander Duyck; +Cc: David Miller, netdev
In-Reply-To: <CALnjE+pPh5nSvaLTnM-a0r2Gm6K8Hz5BU_CsiWzYmwijPCOgHg@mail.gmail.com>
On 01/29/2015 08:04 PM, Pravin Shelar wrote:
> On Thu, Jan 29, 2015 at 7:46 PM, Alexander Duyck
>> What does the small packet or non-TCP performance look like for STT vs
>> VXLAN? My concern is that STT looks like it is a one trick pony since
>> all your numbers show is TCP TSO performance, and based on some of the
>> comments in your patches it seems like other protocols such as UDP are
>> going to suffer pretty badly due to things like the linearization overhead.
>>
>
> Current implementation is targeted for TCP workloads thats why I
> posted numbers with TCP, once UDP is optimized we can discuss UDP
> numbers. I am pretty sure the STT code can be optimized further
> specially for protocols other than TCP.
Not to pile-on or anything but indeed, there is much more to "TCP
workloads" than just bulk transfer (TCP_STREAM), which is precisely why
netperf was created oh so many years ago with its TCP_RR test to try to
replace ttcp, and why there are the methods of mine and others to do
aggregate PPS with it and other benchmarks.
Of course that comment applies not only to STT but also to any other
"get to link-rate" on a (single|smallnumberof) stream" change.
rick
^ permalink raw reply
* Re: [PATCH 1/9] rhashtable: simplify rhashtable_remove()
From: Thomas Graf @ 2015-01-30 16:36 UTC (permalink / raw)
To: Patrick McHardy
Cc: herbert, davem, David.Laight, ying.xue, paulmck, netdev,
netfilter-devel
In-Reply-To: <1422603994-5836-2-git-send-email-kaber@trash.net>
On 01/30/15 at 07:46am, Patrick McHardy wrote:
> Remove some duplicated code by moving the restart label up a few
> lines. Also use rcu_access_pointer() for the pointer comparison
> instead of rht_dereference_rcu().
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
BTW, everything except the rcu_access_pointer() optimization is
also covered in the "rhashtable fixes" series I posted.
^ permalink raw reply
* Re: [PATCH v2 11/11] hso: fix rfkill name conflicts
From: Olivier Sobrie @ 2015-01-30 16:15 UTC (permalink / raw)
To: Dan Williams; +Cc: Jan Dumon, linux-kernel, linux-usb, netdev
In-Reply-To: <1422632879.30854.0.camel@dcbw.local>
Hello Dan,
On Fri, Jan 30, 2015 at 09:47:59AM -0600, Dan Williams wrote:
> On Fri, 2015-01-30 at 13:22 +0100, Olivier Sobrie wrote:
> > By using only the usb interface number for the rfkill name, we might
> > have a name conflicts in case two similar hso devices are connected.
> >
> > In this patch, the name of the hso rfkill interface embed the value
> > of a counter that is incremented each time a new rfkill interface is
> > added.
> >
> > Suggested-by: Dan Williams <dcbw@redhat.com>
> > Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
> > ---
> > drivers/net/usb/hso.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> > index c14fc80..d31a165 100644
> > --- a/drivers/net/usb/hso.c
> > +++ b/drivers/net/usb/hso.c
> > @@ -153,7 +153,7 @@ struct hso_net {
> > struct hso_device *parent;
> > struct net_device *net;
> > struct rfkill *rfkill;
> > - char name[8];
> > + char name[24];
> >
> > struct usb_endpoint_descriptor *in_endp;
> > struct usb_endpoint_descriptor *out_endp;
> > @@ -2469,9 +2469,10 @@ static void hso_create_rfkill(struct hso_device *hso_dev,
> > {
> > struct hso_net *hso_net = dev2net(hso_dev);
> > struct device *dev = &hso_net->net->dev;
> > + static u32 rfkill_counter;
>
> It'll probably be initialized to 0, but still, it would feel safer with
> an explicit "rfkill_counter = 0"...
>
If I set explicitly rfkill_counter = 0, checkpatch triggers an error:
ERROR: do not initialise statics to 0 or NULL
#36: FILE: drivers/net/usb/hso.c:2472:
+ static u32 rfkill_counter = 0;
Olivier
^ permalink raw reply
* Re: [PATCH 4/7] rtlwifi: Remove unused RTL_SUPPORTED_CTRL_FILTER define
From: Larry Finger @ 2015-01-30 16:06 UTC (permalink / raw)
To: Priit Laes, Chaoming Li, Kalle Valo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1422341373-22196-4-git-send-email-plaes@plaes.org>
On 01/27/2015 12:49 AM, Priit Laes wrote:
> Signed-off-by: Priit Laes <plaes@plaes.org>
> ---
> drivers/net/wireless/rtlwifi/core.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/core.h b/drivers/net/wireless/rtlwifi/core.h
> index 624e1dc..3b37557 100644
> --- a/drivers/net/wireless/rtlwifi/core.h
> +++ b/drivers/net/wireless/rtlwifi/core.h
> @@ -33,8 +33,6 @@
> FIF_FCSFAIL | \
> FIF_BCN_PRBRESP_PROMISC)
>
> -#define RTL_SUPPORTED_CTRL_FILTER 0xFF
> -
> extern const struct ieee80211_ops rtl_ops;
> void rtl_fw_cb(const struct firmware *firmware, void *context);
> void rtl_addr_delay(u32 addr);
Priit,
I have a couple of points to make. First, when you submit a series of patches
like this, it is customary to use the cover letter feature of git to generate a
0/X patch in which to explain the set of patches. In this case, the cover letter
is not necessary, but it is a good habit to cultivate.
The second point is more important. I'm not sure what source you used to
generate your patches, but it was clearly not wireless-drivers-next. Commit
6f8214b69057 ("rtlwifi: Create new routine to initialize the DM tables") moved a
lot of stuff from the individual drivers into the core. Some of the new stuff
was included right after the definition of RTL_SUPPORTED_CTRL_FILTER, thus your
patch fails to apply.
Once you fix this problem, and resubmit V2 of the series, I will approve them.
FYI, Kalle prefers that all patches be resubmitted, not just the one that changes.
Larry
^ permalink raw reply
* Re: [PATCH v2 11/11] hso: fix rfkill name conflicts
From: Dan Williams @ 2015-01-30 15:47 UTC (permalink / raw)
To: Olivier Sobrie; +Cc: Jan Dumon, linux-kernel, linux-usb, netdev
In-Reply-To: <1422620523-15021-12-git-send-email-olivier@sobrie.be>
On Fri, 2015-01-30 at 13:22 +0100, Olivier Sobrie wrote:
> By using only the usb interface number for the rfkill name, we might
> have a name conflicts in case two similar hso devices are connected.
>
> In this patch, the name of the hso rfkill interface embed the value
> of a counter that is incremented each time a new rfkill interface is
> added.
>
> Suggested-by: Dan Williams <dcbw@redhat.com>
> Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
> ---
> drivers/net/usb/hso.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index c14fc80..d31a165 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -153,7 +153,7 @@ struct hso_net {
> struct hso_device *parent;
> struct net_device *net;
> struct rfkill *rfkill;
> - char name[8];
> + char name[24];
>
> struct usb_endpoint_descriptor *in_endp;
> struct usb_endpoint_descriptor *out_endp;
> @@ -2469,9 +2469,10 @@ static void hso_create_rfkill(struct hso_device *hso_dev,
> {
> struct hso_net *hso_net = dev2net(hso_dev);
> struct device *dev = &hso_net->net->dev;
> + static u32 rfkill_counter;
It'll probably be initialized to 0, but still, it would feel safer with
an explicit "rfkill_counter = 0"...
Dan
> snprintf(hso_net->name, sizeof(hso_net->name), "hso-%d",
> - interface->altsetting->desc.bInterfaceNumber);
> + rfkill_counter++);
>
> hso_net->rfkill = rfkill_alloc(hso_net->name,
> &interface_to_usbdev(interface)->dev,
^ permalink raw reply
* Re: [PATCH V2 1/6] rtlwifi: Change logging level for key change
From: Larry Finger @ 2015-01-30 15:47 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1422304934-9239-2-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 01/26/2015 02:42 PM, Larry Finger wrote:
> A recent change in key handling included logging of these changes for
> all debug levels. Such key changes should only be logged when a high
> level of debugging is enabled.
>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
> drivers/net/wireless/rtlwifi/cam.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/cam.c b/drivers/net/wireless/rtlwifi/cam.c
> index 3ef870d..6e64792 100644
> --- a/drivers/net/wireless/rtlwifi/cam.c
> +++ b/drivers/net/wireless/rtlwifi/cam.c
> @@ -406,7 +406,7 @@ u8 rtl_cam_get_free_entry(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
> }
> }
> if (found) {
> - RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG,
> + RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
> "key_index=%d,cam_bitmap: 0x%x entry_idx=%d\n",
> key_index, rtlpriv->sec.cam_bitmap, entry_idx);
> return entry_idx;
>
Kalle,
Please include this patch even though the rest of this set should be dropped.
Once the wifi-BT communications problem is resolved, new versions of those will
be presented.
I'm sorry that my commit message was not as informative as it could have been. I
was presented with this material that I did not understand. One saving grace is
that the RTL8812AE hardware is apparently rare - I certainly do not have any
samples. I'm not sure of the value of a 1x1 implementation of 802.11ac, but that
may be another example of my ignorance.
Thanks,
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] drivers: net: cpsw: make cpsw_ale.c a module to allow re-use on Keystone
From: Murali Karicheri @ 2015-01-30 15:39 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: w-kwok2, David S. Miller, Mugunthan V N, Tony Lindgren,
Grygorii Strashko, lokeshvutla, mpa, lsorense, netdev, LKML,
Arnd Bergmann
In-Reply-To: <CA+V-a8v0SYQtMEXWtivUu=MF-DNuF5n_fBqtABuSrhrxNLYMBw@mail.gmail.com>
On 01/30/2015 03:03 AM, Lad, Prabhakar wrote:
> On Thu, Jan 29, 2015 at 11:15 PM, Murali Karicheri<m-karicheri2@ti.com> wrote:
>> NetCP on Keystone has cpsw ale function similar to other TI SoCs
>> and this driver is re-used. To allow both ti cpsw and keystone netcp
>> to re-use the driver, convert the cpsw ale to a module and configure
>> it through Kconfig option CONFIG_TI_CPSW_ALE. Currently it is statically
>> linked to both TI CPSW and NetCP and this causes issues when the above
>> drivers are built as dynamic modules. This patch addresses this issue
>>
>> While at it, fix the Makefile and code to build both netcp_core and
>> netcp_ethss as dynamic modules. This is needed to support arm allmodconfig.
>> This also requires exporting of API calls provided by netcp_core so that
>> both the above can be dynamic modules.
>>
>> Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
>
> Acked-by: Lad, Prabhakar<prabhakar.csengg@gmail.com>
>
Prabhakar,
Thanks
Mruali
> Regards,
> --Prabhakar Lad
>
>> ---
>> drivers/net/ethernet/ti/Kconfig | 19 +++++++++++++++++--
>> drivers/net/ethernet/ti/Makefile | 8 +++++---
>> drivers/net/ethernet/ti/cpsw_ale.c | 26 ++++++++++++++++++++++++--
>> drivers/net/ethernet/ti/netcp_core.c | 8 ++++++++
>> drivers/net/ethernet/ti/netcp_ethss.c | 5 +++++
>> 5 files changed, 59 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
>> index 4ea1663..3bc992c 100644
>> --- a/drivers/net/ethernet/ti/Kconfig
>> +++ b/drivers/net/ethernet/ti/Kconfig
>> @@ -56,12 +56,18 @@ config TI_CPSW_PHY_SEL
>> This driver supports configuring of the phy mode connected to
>> the CPSW.
>>
>> +config TI_CPSW_ALE
>> + tristate "TI CPSW ALE Support"
>> + ---help---
>> + This driver supports TI's CPSW ALE module.
>> +
>> config TI_CPSW
>> tristate "TI CPSW Switch Support"
>> depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
>> select TI_DAVINCI_CPDMA
>> select TI_DAVINCI_MDIO
>> select TI_CPSW_PHY_SEL
>> + select TI_CPSW_ALE
>> select MFD_SYSCON
>> select REGMAP
>> ---help---
>> @@ -80,15 +86,24 @@ config TI_CPTS
>> and Layer 2 packets, and the driver offers a PTP Hardware Clock.
>>
>> config TI_KEYSTONE_NETCP
>> - tristate "TI Keystone NETCP Ethernet subsystem Support"
>> + tristate "TI Keystone NETCP Core Support"
>> + select TI_CPSW_ALE
>> depends on OF
>> depends on KEYSTONE_NAVIGATOR_DMA&& KEYSTONE_NAVIGATOR_QMSS
>> ---help---
>> - This driver supports TI's Keystone NETCP Ethernet subsystem.
>> + This driver supports TI's Keystone NETCP Core.
>>
>> To compile this driver as a module, choose M here: the module
>> will be called keystone_netcp.
>>
>> +config TI_KEYSTONE_NETCP_ETHSS
>> + depends on TI_KEYSTONE_NETCP
>> + tristate "TI Keystone NETCP Ethernet subsystem Support"
>> + ---help---
>> +
>> + To compile this driver as a module, choose M here: the module
>> + will be called keystone_netcp_ethss.
>> +
>> config TLAN
>> tristate "TI ThunderLAN support"
>> depends on (PCI || EISA)
>> diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
>> index 0a9813b..02ddad5 100644
>> --- a/drivers/net/ethernet/ti/Makefile
>> +++ b/drivers/net/ethernet/ti/Makefile
>> @@ -8,9 +8,11 @@ obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
>> obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
>> obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
>> obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
>> +obj-$(CONFIG_TI_CPSW_ALE) += cpsw_ale.o
>> obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
>> -ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o
>> +ti_cpsw-y := cpsw.o cpts.o
>>
>> obj-$(CONFIG_TI_KEYSTONE_NETCP) += keystone_netcp.o
>> -keystone_netcp-y := netcp_core.o netcp_ethss.o netcp_sgmii.o \
>> - netcp_xgbepcsr.o cpsw_ale.o
>> +keystone_netcp-y := netcp_core.o
>> +obj-$(CONFIG_TI_KEYSTONE_NETCP_ETHSS) += keystone_netcp_ethss.o
>> +keystone_netcp_ethss-y := netcp_ethss.o netcp_sgmii.o netcp_xgbepcsr.o
>> diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
>> index 5246b3a..6e927b4 100644
>> --- a/drivers/net/ethernet/ti/cpsw_ale.c
>> +++ b/drivers/net/ethernet/ti/cpsw_ale.c
>> @@ -13,6 +13,7 @@
>> * GNU General Public License for more details.
>> */
>> #include<linux/kernel.h>
>> +#include<linux/module.h>
>> #include<linux/platform_device.h>
>> #include<linux/seq_file.h>
>> #include<linux/slab.h>
>> @@ -146,7 +147,7 @@ static int cpsw_ale_write(struct cpsw_ale *ale, int idx, u32 *ale_entry)
>> return idx;
>> }
>>
>> -int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
>> +static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
>> {
>> u32 ale_entry[ALE_ENTRY_WORDS];
>> int type, idx;
>> @@ -167,7 +168,7 @@ int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
>> return -ENOENT;
>> }
>>
>> -int cpsw_ale_match_vlan(struct cpsw_ale *ale, u16 vid)
>> +static int cpsw_ale_match_vlan(struct cpsw_ale *ale, u16 vid)
>> {
>> u32 ale_entry[ALE_ENTRY_WORDS];
>> int type, idx;
>> @@ -265,6 +266,7 @@ int cpsw_ale_flush_multicast(struct cpsw_ale *ale, int port_mask, int vid)
>> }
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_flush_multicast);
>>
>> static void cpsw_ale_flush_ucast(struct cpsw_ale *ale, u32 *ale_entry,
>> int port_mask)
>> @@ -297,6 +299,7 @@ int cpsw_ale_flush(struct cpsw_ale *ale, int port_mask)
>> }
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_flush);
>>
>> static inline void cpsw_ale_set_vlan_entry_type(u32 *ale_entry,
>> int flags, u16 vid)
>> @@ -334,6 +337,7 @@ int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
>> cpsw_ale_write(ale, idx, ale_entry);
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_add_ucast);
>>
>> int cpsw_ale_del_ucast(struct cpsw_ale *ale, u8 *addr, int port,
>> int flags, u16 vid)
>> @@ -349,6 +353,7 @@ int cpsw_ale_del_ucast(struct cpsw_ale *ale, u8 *addr, int port,
>> cpsw_ale_write(ale, idx, ale_entry);
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_del_ucast);
>>
>> int cpsw_ale_add_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
>> int flags, u16 vid, int mcast_state)
>> @@ -380,6 +385,7 @@ int cpsw_ale_add_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
>> cpsw_ale_write(ale, idx, ale_entry);
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_add_mcast);
>>
>> int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
>> int flags, u16 vid)
>> @@ -401,6 +407,7 @@ int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
>> cpsw_ale_write(ale, idx, ale_entry);
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_del_mcast);
>>
>> int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
>> int reg_mcast, int unreg_mcast)
>> @@ -430,6 +437,7 @@ int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
>> cpsw_ale_write(ale, idx, ale_entry);
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_add_vlan);
>>
>> int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port_mask)
>> {
>> @@ -450,6 +458,7 @@ int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port_mask)
>> cpsw_ale_write(ale, idx, ale_entry);
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_del_vlan);
>>
>> void cpsw_ale_set_allmulti(struct cpsw_ale *ale, int allmulti)
>> {
>> @@ -479,6 +488,7 @@ void cpsw_ale_set_allmulti(struct cpsw_ale *ale, int allmulti)
>> cpsw_ale_write(ale, idx, ale_entry);
>> }
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_set_allmulti);
>>
>> struct ale_control_info {
>> const char *name;
>> @@ -704,6 +714,7 @@ int cpsw_ale_control_set(struct cpsw_ale *ale, int port, int control,
>>
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_control_set);
>>
>> int cpsw_ale_control_get(struct cpsw_ale *ale, int port, int control)
>> {
>> @@ -727,6 +738,7 @@ int cpsw_ale_control_get(struct cpsw_ale *ale, int port, int control)
>> tmp = __raw_readl(ale->params.ale_regs + offset)>> shift;
>> return tmp& BITMASK(info->bits);
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_control_get);
>>
>> static void cpsw_ale_timer(unsigned long arg)
>> {
>> @@ -750,6 +762,7 @@ int cpsw_ale_set_ageout(struct cpsw_ale *ale, int ageout)
>> }
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_set_ageout);
>>
>> void cpsw_ale_start(struct cpsw_ale *ale)
>> {
>> @@ -769,11 +782,13 @@ void cpsw_ale_start(struct cpsw_ale *ale)
>> add_timer(&ale->timer);
>> }
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_start);
>>
>> void cpsw_ale_stop(struct cpsw_ale *ale)
>> {
>> del_timer_sync(&ale->timer);
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_stop);
>>
>> struct cpsw_ale *cpsw_ale_create(struct cpsw_ale_params *params)
>> {
>> @@ -788,6 +803,7 @@ struct cpsw_ale *cpsw_ale_create(struct cpsw_ale_params *params)
>>
>> return ale;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_create);
>>
>> int cpsw_ale_destroy(struct cpsw_ale *ale)
>> {
>> @@ -797,6 +813,7 @@ int cpsw_ale_destroy(struct cpsw_ale *ale)
>> kfree(ale);
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_destroy);
>>
>> void cpsw_ale_dump(struct cpsw_ale *ale, u32 *data)
>> {
>> @@ -807,3 +824,8 @@ void cpsw_ale_dump(struct cpsw_ale *ale, u32 *data)
>> data += ALE_ENTRY_WORDS;
>> }
>> }
>> +EXPORT_SYMBOL_GPL(cpsw_ale_dump);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("TI CPSW ALE driver");
>> +MODULE_AUTHOR("Texas Instruments");
>> diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
>> index ba3002e..a31a8c3 100644
>> --- a/drivers/net/ethernet/ti/netcp_core.c
>> +++ b/drivers/net/ethernet/ti/netcp_core.c
>> @@ -354,6 +354,7 @@ fail:
>> netcp_unregister_module(module);
>> return ret;
>> }
>> +EXPORT_SYMBOL_GPL(netcp_register_module);
>>
>> static void netcp_release_module(struct netcp_device *netcp_device,
>> struct netcp_module *module)
>> @@ -414,6 +415,7 @@ void netcp_unregister_module(struct netcp_module *module)
>>
>> mutex_unlock(&netcp_modules_lock);
>> }
>> +EXPORT_SYMBOL_GPL(netcp_unregister_module);
>>
>> void *netcp_module_get_intf_data(struct netcp_module *module,
>> struct netcp_intf *intf)
>> @@ -425,6 +427,7 @@ void *netcp_module_get_intf_data(struct netcp_module *module,
>> return intf_modpriv->module_priv;
>> return NULL;
>> }
>> +EXPORT_SYMBOL_GPL(netcp_module_get_intf_data);
>>
>> /* Module TX and RX Hook management */
>> struct netcp_hook_list {
>> @@ -459,6 +462,7 @@ int netcp_register_txhook(struct netcp_intf *netcp_priv, int order,
>>
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(netcp_register_txhook);
>>
>> int netcp_unregister_txhook(struct netcp_intf *netcp_priv, int order,
>> netcp_hook_rtn *hook_rtn, void *hook_data)
>> @@ -480,6 +484,7 @@ int netcp_unregister_txhook(struct netcp_intf *netcp_priv, int order,
>> spin_unlock_irqrestore(&netcp_priv->lock, flags);
>> return -ENOENT;
>> }
>> +EXPORT_SYMBOL_GPL(netcp_unregister_txhook);
>>
>> int netcp_register_rxhook(struct netcp_intf *netcp_priv, int order,
>> netcp_hook_rtn *hook_rtn, void *hook_data)
>> @@ -1226,6 +1231,7 @@ int netcp_txpipe_close(struct netcp_tx_pipe *tx_pipe)
>> }
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(netcp_txpipe_close);
>>
>> int netcp_txpipe_open(struct netcp_tx_pipe *tx_pipe)
>> {
>> @@ -1267,6 +1273,7 @@ err:
>> tx_pipe->dma_channel = NULL;
>> return ret;
>> }
>> +EXPORT_SYMBOL_GPL(netcp_txpipe_open);
>>
>> int netcp_txpipe_init(struct netcp_tx_pipe *tx_pipe,
>> struct netcp_device *netcp_device,
>> @@ -1278,6 +1285,7 @@ int netcp_txpipe_init(struct netcp_tx_pipe *tx_pipe,
>> tx_pipe->dma_queue_id = dma_queue_id;
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(netcp_txpipe_init);
>>
>> static struct netcp_addr *netcp_addr_find(struct netcp_intf *netcp,
>> const u8 *addr,
>> diff --git a/drivers/net/ethernet/ti/netcp_ethss.c b/drivers/net/ethernet/ti/netcp_ethss.c
>> index fa1041a..345cd25 100644
>> --- a/drivers/net/ethernet/ti/netcp_ethss.c
>> +++ b/drivers/net/ethernet/ti/netcp_ethss.c
>> @@ -19,6 +19,7 @@
>> */
>>
>> #include<linux/io.h>
>> +#include<linux/module.h>
>> #include<linux/of_mdio.h>
>> #include<linux/of_address.h>
>> #include<linux/if_vlan.h>
>> @@ -2154,3 +2155,7 @@ static void __exit keystone_gbe_exit(void)
>> netcp_unregister_module(&xgbe_module);
>> }
>> module_exit(keystone_gbe_exit);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("TI NETCP ETHSS driver for Keystone SOCs");
>> +MODULE_AUTHOR("Sandeep Nair<sandeep_n@ti.com");
>> --
>> 1.7.9.5
>>
--
Murali Karicheri
Linux Kernel, Texas Instruments
^ 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