* Re: [PATCH 1/3] tun: move internal flag defines out of uapi
From: Dan Williams @ 2014-11-19 17:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, rusty, davem, Jason Wang, Zhi Yong Wu, Tom Herbert,
Ben Hutchings, Masatake YAMATO, Xi Wang, netdev, linux-api
In-Reply-To: <20141119170835.GA29928@redhat.com>
On Wed, 2014-11-19 at 19:08 +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 19, 2014 at 06:50:17PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Nov 19, 2014 at 10:47:14AM -0600, Dan Williams wrote:
> > > On Wed, 2014-11-19 at 18:18 +0200, Michael S. Tsirkin wrote:
> > > > TUN_ flags are internal and never exposed
> > > > to userspace. Any application using it is almost
> > > > certainly buggy.
> > >
> > > Except for TUN_TUN_DEV and TUN_TAP_DEV and TUN_TYPE_MASK... which we're
> > > using (for some reason) in NetworkManager, though I'll happily convert
> > > those to IFF_* instead. It might be worth #defining those to their
> > > IFF_* equivalents since their usage is not technically broken.
> > >
> > > Dan
> >
> > Hmm you are right, they happen to have the same value.
> > I'll send v2 leaving these in place.
> >
>
> Though I do think userspace shouldn't depend on them generally,
> so it might be a good idea to stop using them, even though
> I'll fix up my patches to avoid breaking this usecase.
Yeah, I'm doing an NM patch right now to use IFF_*.
Dan
>
>
> > > > Move them out to tun.c, we'll remove them in follow-up patches.
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> > > > include/uapi/linux/if_tun.h | 14 --------------
> > > > drivers/net/tun.c | 14 ++++++++++++++
> > > > 2 files changed, 14 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> > > > index e9502dd..b82c276 100644
> > > > --- a/include/uapi/linux/if_tun.h
> > > > +++ b/include/uapi/linux/if_tun.h
> > > > @@ -23,20 +23,6 @@
> > > > /* Read queue size */
> > > > #define TUN_READQ_SIZE 500
> > > >
> > > > -/* TUN device flags */
> > > > -#define TUN_TUN_DEV 0x0001
> > > > -#define TUN_TAP_DEV 0x0002
> > > > -#define TUN_TYPE_MASK 0x000f
> > > > -
> > > > -#define TUN_FASYNC 0x0010
> > > > -#define TUN_NOCHECKSUM 0x0020
> > > > -#define TUN_NO_PI 0x0040
> > > > -/* This flag has no real effect */
> > > > -#define TUN_ONE_QUEUE 0x0080
> > > > -#define TUN_PERSIST 0x0100
> > > > -#define TUN_VNET_HDR 0x0200
> > > > -#define TUN_TAP_MQ 0x0400
> > > > -
> > > > /* Ioctl defines */
> > > > #define TUNSETNOCSUM _IOW('T', 200, int)
> > > > #define TUNSETDEBUG _IOW('T', 201, int)
> > > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > > > index 2e18ddd..81735f5 100644
> > > > --- a/drivers/net/tun.c
> > > > +++ b/drivers/net/tun.c
> > > > @@ -103,6 +103,20 @@ do { \
> > > > } while (0)
> > > > #endif
> > > >
> > > > +/* TUN device flags */
> > > > +#define TUN_TUN_DEV 0x0001
> > > > +#define TUN_TAP_DEV 0x0002
> > > > +#define TUN_TYPE_MASK 0x000f
> > > > +
> > > > +#define TUN_FASYNC 0x0010
> > > > +#define TUN_NOCHECKSUM 0x0020
> > > > +#define TUN_NO_PI 0x0040
> > > > +/* This flag has no real effect */
> > > > +#define TUN_ONE_QUEUE 0x0080
> > > > +#define TUN_PERSIST 0x0100
> > > > +#define TUN_VNET_HDR 0x0200
> > > > +#define TUN_TAP_MQ 0x0400
> > > > +
> > > > #define GOODCOPY_LEN 128
> > > >
> > > > #define FLT_EXACT_COUNT 8
> > >
> --
> 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 1/3] tun: move internal flag defines out of uapi
From: Michael S. Tsirkin @ 2014-11-19 17:08 UTC (permalink / raw)
To: Dan Williams
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, rusty-8n+1lVoiYb80n/F98K4Iww,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Jason Wang, Zhi Yong Wu,
Tom Herbert, Ben Hutchings, Masatake YAMATO, Xi Wang,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141119165017.GA29759-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Wed, Nov 19, 2014 at 06:50:17PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 19, 2014 at 10:47:14AM -0600, Dan Williams wrote:
> > On Wed, 2014-11-19 at 18:18 +0200, Michael S. Tsirkin wrote:
> > > TUN_ flags are internal and never exposed
> > > to userspace. Any application using it is almost
> > > certainly buggy.
> >
> > Except for TUN_TUN_DEV and TUN_TAP_DEV and TUN_TYPE_MASK... which we're
> > using (for some reason) in NetworkManager, though I'll happily convert
> > those to IFF_* instead. It might be worth #defining those to their
> > IFF_* equivalents since their usage is not technically broken.
> >
> > Dan
>
> Hmm you are right, they happen to have the same value.
> I'll send v2 leaving these in place.
>
Though I do think userspace shouldn't depend on them generally,
so it might be a good idea to stop using them, even though
I'll fix up my patches to avoid breaking this usecase.
> > > Move them out to tun.c, we'll remove them in follow-up patches.
> > > Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > ---
> > > include/uapi/linux/if_tun.h | 14 --------------
> > > drivers/net/tun.c | 14 ++++++++++++++
> > > 2 files changed, 14 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> > > index e9502dd..b82c276 100644
> > > --- a/include/uapi/linux/if_tun.h
> > > +++ b/include/uapi/linux/if_tun.h
> > > @@ -23,20 +23,6 @@
> > > /* Read queue size */
> > > #define TUN_READQ_SIZE 500
> > >
> > > -/* TUN device flags */
> > > -#define TUN_TUN_DEV 0x0001
> > > -#define TUN_TAP_DEV 0x0002
> > > -#define TUN_TYPE_MASK 0x000f
> > > -
> > > -#define TUN_FASYNC 0x0010
> > > -#define TUN_NOCHECKSUM 0x0020
> > > -#define TUN_NO_PI 0x0040
> > > -/* This flag has no real effect */
> > > -#define TUN_ONE_QUEUE 0x0080
> > > -#define TUN_PERSIST 0x0100
> > > -#define TUN_VNET_HDR 0x0200
> > > -#define TUN_TAP_MQ 0x0400
> > > -
> > > /* Ioctl defines */
> > > #define TUNSETNOCSUM _IOW('T', 200, int)
> > > #define TUNSETDEBUG _IOW('T', 201, int)
> > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > > index 2e18ddd..81735f5 100644
> > > --- a/drivers/net/tun.c
> > > +++ b/drivers/net/tun.c
> > > @@ -103,6 +103,20 @@ do { \
> > > } while (0)
> > > #endif
> > >
> > > +/* TUN device flags */
> > > +#define TUN_TUN_DEV 0x0001
> > > +#define TUN_TAP_DEV 0x0002
> > > +#define TUN_TYPE_MASK 0x000f
> > > +
> > > +#define TUN_FASYNC 0x0010
> > > +#define TUN_NOCHECKSUM 0x0020
> > > +#define TUN_NO_PI 0x0040
> > > +/* This flag has no real effect */
> > > +#define TUN_ONE_QUEUE 0x0080
> > > +#define TUN_PERSIST 0x0100
> > > +#define TUN_VNET_HDR 0x0200
> > > +#define TUN_TAP_MQ 0x0400
> > > +
> > > #define GOODCOPY_LEN 128
> > >
> > > #define FLT_EXACT_COUNT 8
> >
^ permalink raw reply
* [PATCH net] pptp: fix stack info leak in pptp_getname()
From: Mathias Krause @ 2014-11-19 17:05 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Mathias Krause, Dmitry Kozlov
pptp_getname() only partially initializes the stack variable sa,
particularly only fills the pptp part of the sa_addr union. The code
thereby discloses 16 bytes of kernel stack memory via getsockname().
Fix this by memset(0)'ing the union before.
Cc: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
---
Probably material for stable, too -- v2.6.37+.
drivers/net/ppp/pptp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
index 1aff970be33e..1dc628ffce2b 100644
--- a/drivers/net/ppp/pptp.c
+++ b/drivers/net/ppp/pptp.c
@@ -506,7 +506,9 @@ static int pptp_getname(struct socket *sock, struct sockaddr *uaddr,
int len = sizeof(struct sockaddr_pppox);
struct sockaddr_pppox sp;
- sp.sa_family = AF_PPPOX;
+ memset(&sp.sa_addr, 0, sizeof(sp.sa_addr));
+
+ sp.sa_family = AF_PPPOX;
sp.sa_protocol = PX_PROTO_PPTP;
sp.sa_addr.pptp = pppox_sk(sock->sk)->proto.pptp.src_addr;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/1] net: sched: Deletion of an unnecessary check before the function call "kfree"
From: Daniel Borkmann @ 2014-11-19 17:00 UTC (permalink / raw)
To: John Fastabend
Cc: SF Markus Elfring, David S. Miller, Jamal Hadi Salim, netdev,
LKML, kernel-janitors, Coccinelle
In-Reply-To: <546CC9B3.5060405@gmail.com>
On 11/19/2014 05:47 PM, John Fastabend wrote:
> On 11/18/2014 12:26 PM, SF Markus Elfring wrote:
>> From: Markus Elfring <elfring@users.sourceforge.net>
...
>> if (fp_old)
>> bpf_prog_destroy(fp_old);
>> - if (bpf_old)
>> - kfree(bpf_old);
>> + kfree(bpf_old);
>>
>> return 0;
>>
>
> Maybe I need some coffee but I can't figure out what this
> patch is against...
>
> # grep bpf_old ./net/sched/cls_bpf.c
> #
Coffee is always good. :)
Yeah, you actually removed this in commit 1f947bf151e90ec ("net:
sched: rcu'ify cls_bpf"), so looks like Markus's tree is not
up to date ...
^ permalink raw reply
* [PATCH net-next] packet: make packet_snd fail on len smaller than l2 header
From: Willem de Bruijn @ 2014-11-19 16:56 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, dborkman, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
When sending packets out with PF_PACKET, SOCK_RAW, ensure that the
packet is at least as long as the device's expected link layer header.
This check already exists in tpacket_snd, but not in packet_snd.
Also rate limit the warning in tpacket_snd.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/packet/af_packet.c | 30 ++++++++++++++++++++++--------
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 4cd13d8..0d3cb44 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2095,6 +2095,18 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
sock_wfree(skb);
}
+static bool ll_header_truncated(int len, struct net_device *dev)
+{
+ /* net device doesn't like empty head */
+ if (unlikely(len <= dev->hard_header_len)) {
+ net_warn_ratelimited("%s: packet size is too short (%d < %d)\n",
+ current->comm, len, dev->hard_header_len);
+ return true;
+ }
+
+ return false;
+}
+
static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
void *frame, struct net_device *dev, int size_max,
__be16 proto, unsigned char *addr, int hlen)
@@ -2170,12 +2182,8 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
if (unlikely(err < 0))
return -EINVAL;
} else if (dev->hard_header_len) {
- /* net device doesn't like empty head */
- if (unlikely(tp_len <= dev->hard_header_len)) {
- pr_err("packet size is too short (%d < %d)\n",
- tp_len, dev->hard_header_len);
+ if (ll_header_truncated(tp_len, dev))
return -EINVAL;
- }
skb_push(skb, dev->hard_header_len);
err = skb_store_bits(skb, 0, data,
@@ -2500,9 +2508,15 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
skb_set_network_header(skb, reserve);
err = -EINVAL;
- if (sock->type == SOCK_DGRAM &&
- (offset = dev_hard_header(skb, dev, ntohs(proto), addr, NULL, len)) < 0)
- goto out_free;
+ if (sock->type == SOCK_DGRAM) {
+ offset = dev_hard_header(skb, dev, ntohs(proto), addr, NULL,
+ len);
+ if (unlikely(offset) < 0)
+ goto out_free;
+ } else {
+ if (ll_header_truncated(len, dev))
+ goto out_free;
+ }
/* Returns -EFAULT on error */
err = skb_copy_datagram_from_iovec(skb, offset, msg->msg_iov, 0, len);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Payment
From: Finance Department @ 2014-11-19 15:15 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* Re: [PATCH 1/3] tun: move internal flag defines out of uapi
From: Michael S. Tsirkin @ 2014-11-19 16:50 UTC (permalink / raw)
To: Dan Williams
Cc: linux-kernel, rusty, davem, Jason Wang, Zhi Yong Wu, Tom Herbert,
Ben Hutchings, Masatake YAMATO, Xi Wang, netdev, linux-api
In-Reply-To: <1416415634.4763.9.camel@dcbw.local>
On Wed, Nov 19, 2014 at 10:47:14AM -0600, Dan Williams wrote:
> On Wed, 2014-11-19 at 18:18 +0200, Michael S. Tsirkin wrote:
> > TUN_ flags are internal and never exposed
> > to userspace. Any application using it is almost
> > certainly buggy.
>
> Except for TUN_TUN_DEV and TUN_TAP_DEV and TUN_TYPE_MASK... which we're
> using (for some reason) in NetworkManager, though I'll happily convert
> those to IFF_* instead. It might be worth #defining those to their
> IFF_* equivalents since their usage is not technically broken.
>
> Dan
Hmm you are right, they happen to have the same value.
I'll send v2 leaving these in place.
> > Move them out to tun.c, we'll remove them in follow-up patches.
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > include/uapi/linux/if_tun.h | 14 --------------
> > drivers/net/tun.c | 14 ++++++++++++++
> > 2 files changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> > index e9502dd..b82c276 100644
> > --- a/include/uapi/linux/if_tun.h
> > +++ b/include/uapi/linux/if_tun.h
> > @@ -23,20 +23,6 @@
> > /* Read queue size */
> > #define TUN_READQ_SIZE 500
> >
> > -/* TUN device flags */
> > -#define TUN_TUN_DEV 0x0001
> > -#define TUN_TAP_DEV 0x0002
> > -#define TUN_TYPE_MASK 0x000f
> > -
> > -#define TUN_FASYNC 0x0010
> > -#define TUN_NOCHECKSUM 0x0020
> > -#define TUN_NO_PI 0x0040
> > -/* This flag has no real effect */
> > -#define TUN_ONE_QUEUE 0x0080
> > -#define TUN_PERSIST 0x0100
> > -#define TUN_VNET_HDR 0x0200
> > -#define TUN_TAP_MQ 0x0400
> > -
> > /* Ioctl defines */
> > #define TUNSETNOCSUM _IOW('T', 200, int)
> > #define TUNSETDEBUG _IOW('T', 201, int)
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index 2e18ddd..81735f5 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -103,6 +103,20 @@ do { \
> > } while (0)
> > #endif
> >
> > +/* TUN device flags */
> > +#define TUN_TUN_DEV 0x0001
> > +#define TUN_TAP_DEV 0x0002
> > +#define TUN_TYPE_MASK 0x000f
> > +
> > +#define TUN_FASYNC 0x0010
> > +#define TUN_NOCHECKSUM 0x0020
> > +#define TUN_NO_PI 0x0040
> > +/* This flag has no real effect */
> > +#define TUN_ONE_QUEUE 0x0080
> > +#define TUN_PERSIST 0x0100
> > +#define TUN_VNET_HDR 0x0200
> > +#define TUN_TAP_MQ 0x0400
> > +
> > #define GOODCOPY_LEN 128
> >
> > #define FLT_EXACT_COUNT 8
>
^ permalink raw reply
* Re: [PATCH 1/1] net: sched: Deletion of an unnecessary check before the function call "kfree"
From: John Fastabend @ 2014-11-19 16:47 UTC (permalink / raw)
To: SF Markus Elfring
Cc: David S. Miller, Jamal Hadi Salim, netdev, LKML, kernel-janitors,
Coccinelle
In-Reply-To: <546BAB93.4010406@users.sourceforge.net>
On 11/18/2014 12:26 PM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 18 Nov 2014 21:21:16 +0100
>
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> net/sched/cls_bpf.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
> index 0e30d58..f323944 100644
> --- a/net/sched/cls_bpf.c
> +++ b/net/sched/cls_bpf.c
> @@ -212,8 +212,7 @@ static int cls_bpf_modify_existing(struct net *net, struct tcf_proto *tp,
>
> if (fp_old)
> bpf_prog_destroy(fp_old);
> - if (bpf_old)
> - kfree(bpf_old);
> + kfree(bpf_old);
>
> return 0;
>
>
Maybe I need some coffee but I can't figure out what this
patch is against...
# grep bpf_old ./net/sched/cls_bpf.c
#
Marcus, what tree are you looking at?
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH 1/3] tun: move internal flag defines out of uapi
From: Dan Williams @ 2014-11-19 16:47 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, rusty-8n+1lVoiYb80n/F98K4Iww,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Jason Wang, Zhi Yong Wu,
Tom Herbert, Ben Hutchings, Masatake YAMATO, Xi Wang,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1416413891-29562-2-git-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Wed, 2014-11-19 at 18:18 +0200, Michael S. Tsirkin wrote:
> TUN_ flags are internal and never exposed
> to userspace. Any application using it is almost
> certainly buggy.
Except for TUN_TUN_DEV and TUN_TAP_DEV and TUN_TYPE_MASK... which we're
using (for some reason) in NetworkManager, though I'll happily convert
those to IFF_* instead. It might be worth #defining those to their
IFF_* equivalents since their usage is not technically broken.
Dan
> Move them out to tun.c, we'll remove them in follow-up patches.
> Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> include/uapi/linux/if_tun.h | 14 --------------
> drivers/net/tun.c | 14 ++++++++++++++
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index e9502dd..b82c276 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -23,20 +23,6 @@
> /* Read queue size */
> #define TUN_READQ_SIZE 500
>
> -/* TUN device flags */
> -#define TUN_TUN_DEV 0x0001
> -#define TUN_TAP_DEV 0x0002
> -#define TUN_TYPE_MASK 0x000f
> -
> -#define TUN_FASYNC 0x0010
> -#define TUN_NOCHECKSUM 0x0020
> -#define TUN_NO_PI 0x0040
> -/* This flag has no real effect */
> -#define TUN_ONE_QUEUE 0x0080
> -#define TUN_PERSIST 0x0100
> -#define TUN_VNET_HDR 0x0200
> -#define TUN_TAP_MQ 0x0400
> -
> /* Ioctl defines */
> #define TUNSETNOCSUM _IOW('T', 200, int)
> #define TUNSETDEBUG _IOW('T', 201, int)
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 2e18ddd..81735f5 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -103,6 +103,20 @@ do { \
> } while (0)
> #endif
>
> +/* TUN device flags */
> +#define TUN_TUN_DEV 0x0001
> +#define TUN_TAP_DEV 0x0002
> +#define TUN_TYPE_MASK 0x000f
> +
> +#define TUN_FASYNC 0x0010
> +#define TUN_NOCHECKSUM 0x0020
> +#define TUN_NO_PI 0x0040
> +/* This flag has no real effect */
> +#define TUN_ONE_QUEUE 0x0080
> +#define TUN_PERSIST 0x0100
> +#define TUN_VNET_HDR 0x0200
> +#define TUN_TAP_MQ 0x0400
> +
> #define GOODCOPY_LEN 128
>
> #define FLT_EXACT_COUNT 8
^ permalink raw reply
* [PATCH 3/3] tun: drop most type defines
From: Michael S. Tsirkin @ 2014-11-19 16:18 UTC (permalink / raw)
To: linux-kernel
Cc: rusty, davem, Jason Wang, Zhi Yong Wu, Tom Herbert, Ben Hutchings,
Masatake YAMATO, Xi Wang, netdev
In-Reply-To: <1416413891-29562-1-git-send-email-mst@redhat.com>
It's just as easy to use IFF_ flags directly,
there's no point in adding our own defines.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/tun.c | 64 ++++++++++++++++++++++++-------------------------------
1 file changed, 28 insertions(+), 36 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index e4bd542..06683af 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -104,20 +104,12 @@ do { \
#endif
/* TUN device flags */
-#define TUN_TUN_DEV IFF_TUN
-#define TUN_TAP_DEV IFF_TAP
#define TUN_TYPE_MASK (IFF_TUN | IFF_TAP)
/* IFF_ATTACH_QUEUE is never stored in device flags,
* overload it to mean fasync when stored there.
*/
#define TUN_FASYNC IFF_ATTACH_QUEUE
-#define TUN_NO_PI IFF_NO_PI
-/* This flag has no real effect */
-#define TUN_ONE_QUEUE IFF_ONE_QUEUE
-#define TUN_PERSIST IFF_PERSIST
-#define TUN_VNET_HDR IFF_VNET_HDR
-#define TUN_TAP_MQ IFF_MULTI_QUEUE
#define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
IFF_MULTI_QUEUE)
@@ -490,7 +482,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
if (tun && tun->numqueues == 0 && tun->numdisabled == 0) {
netif_carrier_off(tun->dev);
- if (!(tun->flags & TUN_PERSIST) &&
+ if (!(tun->flags & IFF_PERSIST) &&
tun->dev->reg_state == NETREG_REGISTERED)
unregister_netdevice(tun->dev);
}
@@ -541,7 +533,7 @@ static void tun_detach_all(struct net_device *dev)
}
BUG_ON(tun->numdisabled != 0);
- if (tun->flags & TUN_PERSIST)
+ if (tun->flags & IFF_PERSIST)
module_put(THIS_MODULE);
}
@@ -559,7 +551,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file, bool skip_filte
goto out;
err = -EBUSY;
- if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
+ if (!(tun->flags & IFF_MULTI_QUEUE) && tun->numqueues == 1)
goto out;
err = -E2BIG;
@@ -938,7 +930,7 @@ static void tun_net_init(struct net_device *dev)
struct tun_struct *tun = netdev_priv(dev);
switch (tun->flags & TUN_TYPE_MASK) {
- case TUN_TUN_DEV:
+ case IFF_TUN:
dev->netdev_ops = &tun_netdev_ops;
/* Point-to-Point TUN Device */
@@ -952,7 +944,7 @@ static void tun_net_init(struct net_device *dev)
dev->tx_queue_len = TUN_READQ_SIZE; /* We prefer our own queue length */
break;
- case TUN_TAP_DEV:
+ case IFF_TAP:
dev->netdev_ops = &tap_netdev_ops;
/* Ethernet TAP Device */
ether_setup(dev);
@@ -1043,7 +1035,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
int err;
u32 rxhash;
- if (!(tun->flags & TUN_NO_PI)) {
+ if (!(tun->flags & IFF_NO_PI)) {
if (len < sizeof(pi))
return -EINVAL;
len -= sizeof(pi);
@@ -1053,7 +1045,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
offset += sizeof(pi);
}
- if (tun->flags & TUN_VNET_HDR) {
+ if (tun->flags & IFF_VNET_HDR) {
if (len < tun->vnet_hdr_sz)
return -EINVAL;
len -= tun->vnet_hdr_sz;
@@ -1070,7 +1062,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
offset += tun->vnet_hdr_sz;
}
- if ((tun->flags & TUN_TYPE_MASK) == TUN_TAP_DEV) {
+ if ((tun->flags & TUN_TYPE_MASK) == IFF_TAP) {
align += NET_IP_ALIGN;
if (unlikely(len < ETH_HLEN ||
(gso.hdr_len && __virtio16_to_cpu(false, gso.hdr_len) < ETH_HLEN)))
@@ -1133,8 +1125,8 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
}
switch (tun->flags & TUN_TYPE_MASK) {
- case TUN_TUN_DEV:
- if (tun->flags & TUN_NO_PI) {
+ case IFF_TUN:
+ if (tun->flags & IFF_NO_PI) {
switch (skb->data[0] & 0xf0) {
case 0x40:
pi.proto = htons(ETH_P_IP);
@@ -1153,7 +1145,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb->protocol = pi.proto;
skb->dev = tun->dev;
break;
- case TUN_TAP_DEV:
+ case IFF_TAP:
skb->protocol = eth_type_trans(skb, tun->dev);
break;
}
@@ -1254,7 +1246,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
ssize_t total = 0;
int vlan_offset = 0, copied;
- if (!(tun->flags & TUN_NO_PI)) {
+ if (!(tun->flags & IFF_NO_PI)) {
if ((len -= sizeof(pi)) < 0)
return -EINVAL;
@@ -1268,7 +1260,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
total += sizeof(pi);
}
- if (tun->flags & TUN_VNET_HDR) {
+ if (tun->flags & IFF_VNET_HDR) {
struct virtio_net_hdr gso = { 0 }; /* no info leak */
if ((len -= tun->vnet_hdr_sz) < 0)
return -EINVAL;
@@ -1589,7 +1581,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
return -EINVAL;
if (!!(ifr->ifr_flags & IFF_MULTI_QUEUE) !=
- !!(tun->flags & TUN_TAP_MQ))
+ !!(tun->flags & IFF_MULTI_QUEUE))
return -EINVAL;
if (tun_not_capable(tun))
@@ -1602,7 +1594,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (err < 0)
return err;
- if (tun->flags & TUN_TAP_MQ &&
+ if (tun->flags & IFF_MULTI_QUEUE &&
(tun->numqueues + tun->numdisabled > 1)) {
/* One or more queue has already been attached, no need
* to initialize the device again.
@@ -1625,11 +1617,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
/* Set dev type */
if (ifr->ifr_flags & IFF_TUN) {
/* TUN device */
- flags |= TUN_TUN_DEV;
+ flags |= IFF_TUN;
name = "tun%d";
} else if (ifr->ifr_flags & IFF_TAP) {
/* TAP device */
- flags |= TUN_TAP_DEV;
+ flags |= IFF_TAP;
name = "tap%d";
} else
return -EINVAL;
@@ -1822,7 +1814,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
ret = tun_attach(tun, file, false);
} else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
tun = rtnl_dereference(tfile->tun);
- if (!tun || !(tun->flags & TUN_TAP_MQ) || tfile->detached)
+ if (!tun || !(tun->flags & IFF_MULTI_QUEUE) || tfile->detached)
ret = -EINVAL;
else
__tun_detach(tfile, false);
@@ -1928,12 +1920,12 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
/* Disable/Enable persist mode. Keep an extra reference to the
* module to prevent the module being unprobed.
*/
- if (arg && !(tun->flags & TUN_PERSIST)) {
- tun->flags |= TUN_PERSIST;
+ if (arg && !(tun->flags & IFF_PERSIST)) {
+ tun->flags |= IFF_PERSIST;
__module_get(THIS_MODULE);
}
- if (!arg && (tun->flags & TUN_PERSIST)) {
- tun->flags &= ~TUN_PERSIST;
+ if (!arg && (tun->flags & IFF_PERSIST)) {
+ tun->flags &= ~IFF_PERSIST;
module_put(THIS_MODULE);
}
@@ -1991,7 +1983,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case TUNSETTXFILTER:
/* Can be set only for TAPs */
ret = -EINVAL;
- if ((tun->flags & TUN_TYPE_MASK) != TUN_TAP_DEV)
+ if ((tun->flags & TUN_TYPE_MASK) != IFF_TAP)
break;
ret = update_filter(&tun->txflt, (void __user *)arg);
break;
@@ -2050,7 +2042,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case TUNATTACHFILTER:
/* Can be set only for TAPs */
ret = -EINVAL;
- if ((tun->flags & TUN_TYPE_MASK) != TUN_TAP_DEV)
+ if ((tun->flags & TUN_TYPE_MASK) != IFF_TAP)
break;
ret = -EFAULT;
if (copy_from_user(&tun->fprog, argp, sizeof(tun->fprog)))
@@ -2062,7 +2054,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case TUNDETACHFILTER:
/* Can be set only for TAPs */
ret = -EINVAL;
- if ((tun->flags & TUN_TYPE_MASK) != TUN_TAP_DEV)
+ if ((tun->flags & TUN_TYPE_MASK) != IFF_TAP)
break;
ret = 0;
tun_detach_filter(tun, tun->numqueues);
@@ -2070,7 +2062,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case TUNGETFILTER:
ret = -EINVAL;
- if ((tun->flags & TUN_TYPE_MASK) != TUN_TAP_DEV)
+ if ((tun->flags & TUN_TYPE_MASK) != IFF_TAP)
break;
ret = -EFAULT;
if (copy_to_user(argp, &tun->fprog, sizeof(tun->fprog)))
@@ -2263,10 +2255,10 @@ static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
strlcpy(info->version, DRV_VERSION, sizeof(info->version));
switch (tun->flags & TUN_TYPE_MASK) {
- case TUN_TUN_DEV:
+ case IFF_TUN:
strlcpy(info->bus_info, "tun", sizeof(info->bus_info));
break;
- case TUN_TAP_DEV:
+ case IFF_TAP:
strlcpy(info->bus_info, "tap", sizeof(info->bus_info));
break;
}
--
MST
^ permalink raw reply related
* [PATCH 2/3] tun: reuse IFF_ flags internally
From: Michael S. Tsirkin @ 2014-11-19 16:18 UTC (permalink / raw)
To: linux-kernel
Cc: rusty, davem, Jason Wang, Zhi Yong Wu, Ben Hutchings, Tom Herbert,
Masatake YAMATO, Xi Wang, netdev
In-Reply-To: <1416413891-29562-1-git-send-email-mst@redhat.com>
By reusing IFF_ flags for internal tun device flags,
we can get rid of a bunch of code translating back
and forth.
This cleanup exposes a bug: TUNGETFEATURES reports IFF_TUN and IFF_TAP
which aren't legal for TUNSETFEATURES (but, correctly, doesn't report
IFF_PERSIST which also isn't legal there).
I'm not fixing this bug at the moment, just in case some weird
userspace depends on it, using TUNGETFEATURES to check device type.
Follow-up patches will get rid of some of TUN_ macros,
using IFF_ directly instead.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/tun.c | 83 +++++++++++++++----------------------------------------
1 file changed, 22 insertions(+), 61 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 81735f5..e4bd542 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -104,19 +104,23 @@ do { \
#endif
/* TUN device flags */
-#define TUN_TUN_DEV 0x0001
-#define TUN_TAP_DEV 0x0002
-#define TUN_TYPE_MASK 0x000f
+#define TUN_TUN_DEV IFF_TUN
+#define TUN_TAP_DEV IFF_TAP
+#define TUN_TYPE_MASK (IFF_TUN | IFF_TAP)
-#define TUN_FASYNC 0x0010
-#define TUN_NOCHECKSUM 0x0020
-#define TUN_NO_PI 0x0040
+/* IFF_ATTACH_QUEUE is never stored in device flags,
+ * overload it to mean fasync when stored there.
+ */
+#define TUN_FASYNC IFF_ATTACH_QUEUE
+#define TUN_NO_PI IFF_NO_PI
/* This flag has no real effect */
-#define TUN_ONE_QUEUE 0x0080
-#define TUN_PERSIST 0x0100
-#define TUN_VNET_HDR 0x0200
-#define TUN_TAP_MQ 0x0400
+#define TUN_ONE_QUEUE IFF_ONE_QUEUE
+#define TUN_PERSIST IFF_PERSIST
+#define TUN_VNET_HDR IFF_VNET_HDR
+#define TUN_TAP_MQ IFF_MULTI_QUEUE
+#define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
+ IFF_MULTI_QUEUE)
#define GOODCOPY_LEN 128
#define FLT_EXACT_COUNT 8
@@ -1529,32 +1533,7 @@ static struct proto tun_proto = {
static int tun_flags(struct tun_struct *tun)
{
- int flags = 0;
-
- if (tun->flags & TUN_TUN_DEV)
- flags |= IFF_TUN;
- else
- flags |= IFF_TAP;
-
- if (tun->flags & TUN_NO_PI)
- flags |= IFF_NO_PI;
-
- /* This flag has no real effect. We track the value for backwards
- * compatibility.
- */
- if (tun->flags & TUN_ONE_QUEUE)
- flags |= IFF_ONE_QUEUE;
-
- if (tun->flags & TUN_VNET_HDR)
- flags |= IFF_VNET_HDR;
-
- if (tun->flags & TUN_TAP_MQ)
- flags |= IFF_MULTI_QUEUE;
-
- if (tun->flags & TUN_PERSIST)
- flags |= IFF_PERSIST;
-
- return flags;
+ return tun->flags & (TUN_FEATURES | IFF_PERSIST | IFF_TUN | IFF_TAP);
}
static ssize_t tun_show_flags(struct device *dev, struct device_attribute *attr,
@@ -1714,28 +1693,8 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
tun_debug(KERN_INFO, tun, "tun_set_iff\n");
- if (ifr->ifr_flags & IFF_NO_PI)
- tun->flags |= TUN_NO_PI;
- else
- tun->flags &= ~TUN_NO_PI;
-
- /* This flag has no real effect. We track the value for backwards
- * compatibility.
- */
- if (ifr->ifr_flags & IFF_ONE_QUEUE)
- tun->flags |= TUN_ONE_QUEUE;
- else
- tun->flags &= ~TUN_ONE_QUEUE;
-
- if (ifr->ifr_flags & IFF_VNET_HDR)
- tun->flags |= TUN_VNET_HDR;
- else
- tun->flags &= ~TUN_VNET_HDR;
-
- if (ifr->ifr_flags & IFF_MULTI_QUEUE)
- tun->flags |= TUN_TAP_MQ;
- else
- tun->flags &= ~TUN_TAP_MQ;
+ tun->flags = (tun->flags & ~TUN_FEATURES) |
+ (ifr->ifr_flags & TUN_FEATURES);
/* Make sure persistent devices do not get stuck in
* xoff state.
@@ -1898,9 +1857,11 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
if (cmd == TUNGETFEATURES) {
/* Currently this just means: "what IFF flags are valid?".
* This is needed because we never checked for invalid flags on
- * TUNSETIFF. */
- return put_user(IFF_TUN | IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE |
- IFF_VNET_HDR | IFF_MULTI_QUEUE,
+ * TUNSETIFF. Why do we report IFF_TUN and IFF_TAP which are
+ * not legal for TUNSETIFF here? It's probably a bug, but it
+ * doesn't seem to be worth fixing.
+ */
+ return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
(unsigned int __user*)argp);
} else if (cmd == TUNSETQUEUE)
return tun_set_queue(file, &ifr);
--
MST
^ permalink raw reply related
* [PATCH 1/3] tun: move internal flag defines out of uapi
From: Michael S. Tsirkin @ 2014-11-19 16:18 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: rusty-8n+1lVoiYb80n/F98K4Iww, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Jason Wang, Zhi Yong Wu, Tom Herbert, Ben Hutchings,
Masatake YAMATO, Xi Wang, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1416413891-29562-1-git-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
TUN_ flags are internal and never exposed
to userspace. Any application using it is almost
certainly buggy.
Move them out to tun.c, we'll remove them in follow-up patches.
Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
include/uapi/linux/if_tun.h | 14 --------------
drivers/net/tun.c | 14 ++++++++++++++
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index e9502dd..b82c276 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -23,20 +23,6 @@
/* Read queue size */
#define TUN_READQ_SIZE 500
-/* TUN device flags */
-#define TUN_TUN_DEV 0x0001
-#define TUN_TAP_DEV 0x0002
-#define TUN_TYPE_MASK 0x000f
-
-#define TUN_FASYNC 0x0010
-#define TUN_NOCHECKSUM 0x0020
-#define TUN_NO_PI 0x0040
-/* This flag has no real effect */
-#define TUN_ONE_QUEUE 0x0080
-#define TUN_PERSIST 0x0100
-#define TUN_VNET_HDR 0x0200
-#define TUN_TAP_MQ 0x0400
-
/* Ioctl defines */
#define TUNSETNOCSUM _IOW('T', 200, int)
#define TUNSETDEBUG _IOW('T', 201, int)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2e18ddd..81735f5 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -103,6 +103,20 @@ do { \
} while (0)
#endif
+/* TUN device flags */
+#define TUN_TUN_DEV 0x0001
+#define TUN_TAP_DEV 0x0002
+#define TUN_TYPE_MASK 0x000f
+
+#define TUN_FASYNC 0x0010
+#define TUN_NOCHECKSUM 0x0020
+#define TUN_NO_PI 0x0040
+/* This flag has no real effect */
+#define TUN_ONE_QUEUE 0x0080
+#define TUN_PERSIST 0x0100
+#define TUN_VNET_HDR 0x0200
+#define TUN_TAP_MQ 0x0400
+
#define GOODCOPY_LEN 128
#define FLT_EXACT_COUNT 8
--
MST
^ permalink raw reply related
* Re: [PATCH v2 07/19] selftests/firmware: add install target to enable installing test
From: Shuah Khan @ 2014-11-19 16:13 UTC (permalink / raw)
To: Kees Cook
Cc: Greg KH, Andrew Morton, Michal Marek, David S. Miller, Phong Tran,
David Herrmann, Hugh Dickins, pranith kumar, Eric W. Biederman,
Serge E. Hallyn, linux-kbuild, LKML, Linux API,
Network Development
In-Reply-To: <5462B2A3.9000007-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On 11/11/2014 06:06 PM, Shuah Khan wrote:
> On 11/11/2014 02:29 PM, Kees Cook wrote:
>> Hi,
>>
>> Sorry, I still really don't like this approach. While it is all in one
>> place (thank you for that), I think it isn't a form that is very
>> workable for the people maintaining the self tests. How about this,
>> instead of per-Makefile customization, why not define an execution
>> framework for these tests instead.
>
> If I understand correctly, sounds like you don't like the way
> install target is implemented in the individual test Makefiles
> and the changes I made to run_tests targets to address the code
> duplication concern.
>
> At the moment there is no duplicate code in this patch series
> between install and run_tests targets. This is a first step
> towards standardizing the framework and a definite improvement
> over what we have currently. As I mentioned earlier, my goal
> is to make it easier for developers to install and run the
> existing tests and evolve the framework as we go.
>
> Assuming my understanding is correct that:
>
> -- install and run_tests targets in individual tests can be
> refined and automated with a common Makefile approach you
> proposed.
> -- the rest of the user-interface kselftest_install and kselftest
> are good.
>
> I would like to propose that we get started with the current
> implementation and refine it based on the following ideas you
> suggested. The refinements you are recommending are confined
> to selftests and can be made after the kselftest_install
> gets added. Adding kselftest_install makes it easier to make
> the refinements as it defines overall UI.
>
Hi Kees,
Are you ok with the above proposal? I understand this approach
might not be perfect, however it is a step in the right direction
to enable and make it easier to run them. I would like to get some
initial work in for 3.19 if at all possible.
I plan to evolve the back-end to make it easier to write and
maintain for developers writing tests going forward.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH v2 02/19] kbuild: kselftest_install - add a new make target to install selftests
From: Shuah Khan @ 2014-11-19 15:59 UTC (permalink / raw)
To: mmarek, ebiederm, serge.hallyn
Cc: gregkh, akpm, davem, keescook, tranmanphong, dh.herrmann, hughd,
bobby.prani, linux-kbuild, linux-kernel, linux-api, netdev
In-Reply-To: <a2344d4df903d673afe1631118f40917f773cc9a.1415735831.git.shuahkh@osg.samsung.com>
On 11/11/2014 01:27 PM, Shuah Khan wrote:
> Add a new make target to install to install kernel selftests.
> This new target will build and install selftests. kselftest
> target now depends on kselftest_install and runs the generated
> kselftest script to reduce duplicate work and for common look
> and feel when running tests.
>
> Approach:
>
> make kselftest_target:
> -- exports kselftest INSTALL_KSFT_PATH
> default $(INSTALL_MOD_PATH)/lib/kselftest/$(KERNELRELEASE)
> -- exports path for ksefltest.sh
> -- runs selftests make install target:
>
> selftests make install target
> -- creates kselftest.sh script in install install dir
> -- runs install targets for all INSTALL_TARGETS
> (Note: ftrace and powerpc aren't included in INSTALL_TARGETS,
> to not add more content to patch v1 series. This work
> will happen soon. In this series these two targets are
> run after running the generated kselftest script, without
> any regression in the way these tests are run with
> "make kselftest" prior to this work.)
> -- install target can be run only from top level source dir.
>
> Individual test make install targets:
> -- install test programs and/or scripts in install dir
> -- append to the ksefltest.sh file to add commands to run test
> -- install target can be run only from top level source dir.
>
> Adds the following new ways to initiate selftests:
> -- Installing and running kselftest from install directory
> by running "make kselftest"
> -- Running kselftest script from install directory
>
> Maintains the following ways to run tests:
> -- make -C tools/testing/selftests run_tests
> -- make -C tools/testing/selftests TARGETS=target run_tests
> Ability specify targets: e.g TARGETS=net
> -- make run_tests from tools/testing/selftests
> -- make run_tests from individual test directories:
> e.g: make run_tests in tools/testing/selftests/breakpoints
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
> ---
> Makefile | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
Hi Marek,
Did you get a chance to take a look at this patch?
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply
* Re: [PATCH net-next v2] enic: support skb->xmit_more
From: Eric Dumazet @ 2014-11-19 15:33 UTC (permalink / raw)
To: Govindarajulu Varadarajan; +Cc: davem, netdev, ssujith, benve
In-Reply-To: <1416382172-28775-1-git-send-email-_govind@gmx.com>
On Wed, 2014-11-19 at 12:59 +0530, Govindarajulu Varadarajan wrote:
> Check and update posted_index only when skb->xmit_more is 0 or tx queue is full.
>
> v2:
> use txq_map instead of skb_get_queue_mapping(skb)
>
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
> ---
> drivers/net/ethernet/cisco/enic/enic_main.c | 8 ++++++--
> drivers/net/ethernet/cisco/enic/vnic_wq.h | 20 +++++++++++---------
> 2 files changed, 17 insertions(+), 11 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next] sky2: use new netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-19 15:28 UTC (permalink / raw)
To: Ian Morris; +Cc: netdev, Mirko Lindner, Stephen Hemminger, Eric Dumazet
In-Reply-To: <1416388011-10491-1-git-send-email-ipm@chirality.org.uk>
On Wed, 2014-11-19 at 09:06 +0000, Ian Morris wrote:
> Switch to a random RSS key rather than a fixed one.
> Using netdev_rss_key_fill helper also ensures that all ports share
> a common key.
>
> See also commit 960fb622f85180f36d3aff82af53e2be3db2f888.
>
> Signed-off-by: Ian Morris <ipm@chirality.org.uk>
> Cc: Mirko Lindner <mlindner@marvell.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Eric Dumazet <edumazet@google.com>
> ---
> drivers/net/ethernet/marvell/sky2.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
Nice catch, this one escaped from my scan ;)
(Another one is in drivers/net/ethernet/cisco/enic/enic_main.c )
Acked-by: Eric Dumazet <edumazet@google.com>
Nit : When referring a commit, use 12 digit sha1 followed by patch
title.
In this particular case you could have say :
See also commit 960fb622f851 ("net: provide a per host RSS key generic
infrastructure").
Or something like that.
Thanks Ian !
^ permalink raw reply
* Re: Device Tree Binding for Marvell DSA Switch on imx28 board over Mdio Interface
From: Andrew Lunn @ 2014-11-19 15:08 UTC (permalink / raw)
To: Oliver Graute
Cc: Florian Fainelli, Andrew Lunn, netdev@vger.kernel.org, buytenh
In-Reply-To: <CA+KjHfaHxkSY6py31ErXmerp=T68oGdz7D7pC+sXqRmkWEktcA@mail.gmail.com>
On Wed, Nov 19, 2014 at 08:49:50AM +0100, Oliver Graute wrote:
> On Tue, Nov 18, 2014 at 7:23 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > On 11/18/2014 12:30 AM, Oliver Graute wrote:
> >>> Hi Oliver
> >>>
> >>> How do you have the strapping pins on the switch set? They determine
> >>> what address on the mdio bus the chip responds to.
> >>
> >> On the circuit diagram the PIN 54 (P5_IND1/P5ID1) is set to
> >> "Configuration Address: 0101"
> >> P5_MODE[3:0]=0111 = Single RMII MAC Mode (100Mbps FD with 50 MHz clock input)
> >> PIN 59 R1_LED/NO_CPU Configuration: CPU is attached SMI address is 0x10 to 0x1F
> >>
> >> But what is the mdio address of the whole switch? or can I only
> >> address individual phy ports?
> >
> > You should specify in the Device Tree the switch pseudo-PHY address,
> > typically 16 for Marvell switches. You can still access the individual
> > ports' PHY addresses using address 0 through N.
> >
>
> How do I do that exactly? do you have an example Device Tree Snippet?
Here is an example for a Dlink DIR665.
http://www.spinics.net/lists/arm-kernel/msg374004.html
you need to modify this line:
reg = <0 0>; /* MDIO address 0, switch 0 in tree */
Change the first 0 to 0x10.
Andrew
^ permalink raw reply
* Re: Bug report: broadcast address as incomplete entry in arp table, effectively a blackhole; reproducer included
From: Lars Ellenberg @ 2014-11-19 14:39 UTC (permalink / raw)
To: netdev; +Cc: Olaf Kirch
In-Reply-To: <20140924161847.GG7118@soda.linbit>
Ping ...
Any ideas?
Lars
On Wed, Sep 24, 2014 at 06:18:47PM +0200, Lars Ellenberg wrote:
>
> You have some interface you want to broadcast on,
> so you resolve its broadcast address (once),
> and keep sending (e.g. some continuous status updates, or "heartbeat").
>
> For some reason that interface goes down.
> If you keep sending to the previously resolved address,
> that will create an incomplete arp entry.
>
> Unfortunately, that entry *stays* there, even if the interface is then
> brought back up (with the same network and broadcast settings).
> Once the interface is up, you won't be able to delete that entry
> (because, its a broadcast address; that arp entry is not supposed to be
> there anyways; that deletion request will be filtered out early...)
>
> Anyone trying to send to that broadcast address will now effectively
> send to a black hole: there is an incomplete arp entry.
>
>
> Fix is then to stop all processes sending to that address,
> bring down the device, delete the arp entry, bring it back up,
> and then continue all processes sending to that address.
>
>
> I can reproduce this easily with the script below, anywhere I tested,
> on a large variety of platforms and kernels.
> (you'll obviously have to adjust DEV, BROADCAST and possibly PORT).
>
>
> I suspect this is not intentional, but there is simply some
> neigh_flush_dev() or similar missing "somewhere".
>
> If you want to point me in the right direction as to probable values of
> "somewhere", I'll likely be able to figure out a minimal patch myself.
>
> If you know the right place to fix this from the top of your head,
> even better ;-)
>
> Thanks,
> Lars
>
> ------------------------------------------------------
>
> #!/bin/bash
>
> DEV=eth1
> BROADCAST=192.168.133.255
> PORT=6666
>
> send_udp_broadcast()
> {
> exec python -c '
> from socket import *
> from time import sleep
> from struct import pack
> from datetime import datetime
>
>
> s = socket(AF_INET, SOCK_DGRAM)
> s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
> s.setsockopt(SOL_SOCKET, SO_BINDTODEVICE, pack("'$(( 1+${#DEV} ))'s","'$DEV'"))
>
> while 1:
> s.sendto(datetime.now().strftime("hi there, it is now %T.%f"), ("'$BROADCAST'",'$PORT'))
> sleep(0.1)
> '
> }
>
> p() { printf "\n"; printf "::: %s\n" "$@"; printf "%s\n" "-----------"; }
>
> arp -n | grep $BROADCAST && {
> echo >&2 "Sorry, fix the arp table first!"
> exit 1
> }
>
> ( set +x ; send_udp_broadcast ) &
> kid=$!
> p "[$kid] Started to send udp broadcasts on $DEV to $BROADCAST:$PORT"
>
> p "We should see the packets being sent on $DEV"
> tcpdump -n -i $DEV -c 2 -xX udp and port $PORT
>
> p "We should not have any arp entries for $BROADCAST"
> arp -n | grep $BROADCAST
>
> p "But we soon will, after we take down $DEV"
> ip link set down $DEV
>
> sleep 2
>
> p "Now we should have an incomplete arp entry for $BROADCAST"
> arp -n | grep $BROADCAST
>
> p "It will still be there after we bring $DEV back up"
> ip link set up $DEV
>
> p "There won't be any packets now, this should timeout:"
> while read -r -t 5 line ; do
> echo "$line"
> done < <(tcpdump -n -i $DEV -c 2 -xX udp and port $PORT 2>&1)
>
> p "Because we still have that arp entry"
> arp -n | grep $BROADCAST
>
> p "And we cannot get rid of it, either, as long as this $DEV is up"
> arp -d $BROADCAST
> arp -n | grep $BROADCAST
>
> p "but we can stop the child," \
> "take down the device," \
> "remove the arp entry then," \
> "and bring the device back up"
>
> kill -STOP $kid
> ip link set down $DEV
> sleep 1
> arp -d $BROADCAST
> ip link set up $DEV
> arp -n | grep $BROADCAST
>
> p "continue the child" \
> "and now we should see outgoing packets again"
>
> kill -CONT $kid
> tcpdump -n -i $DEV -c 2 -xX udp and port $PORT
>
> p "and no more arp entry"
> arp -n | grep $BROADCAST
>
> p "Done."
> kill $kid
^ permalink raw reply
* Re: [PATCH v3] fix locking regression in ipx_sendmsg and ipx_recvmsg
From: Sergei Shtylyov @ 2014-11-19 14:38 UTC (permalink / raw)
To: Jiri Bohac, Arnd Bergmann; +Cc: Arnaldo Carvalho de Melo, netdev, David Miller
In-Reply-To: <20141119103814.GB19092@midget.suse.cz>
Hello.
On 11/19/2014 1:38 PM, Jiri Bohac wrote:
> This fixes an old regression introduced by commit
> b0d0d915 (ipx: remove the BKL).
> When a recvmsg syscall blocks waiting for new data, no data can be sent on the
> same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked.
> This breaks mars-nwe (NetWare emulator):
> - the ncpserv process reads the request using recvmsg
> - ncpserv forks and spawns nwconn
> - ncpserv calls a (blocking) recvmsg and waits for new requests
> - nwconn deadlocks in sendmsg on the same socket
> Commit b0d0d915 has simply replaced BKL locking with
> lock_sock/release_sock. Unlike now, BKL got unlocked while
> sleeping, so a blocking recvmsg did not block a concurrent
> sendmsg.
> Only keep the socket locked while actually working with the socket data and
> release it prior to calling skb_recv_datagram().
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
> diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
> index a0c7536..d0725d9 100644
> --- a/net/ipx/af_ipx.c
> +++ b/net/ipx/af_ipx.c
> @@ -1764,6 +1764,7 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
> struct ipxhdr *ipx = NULL;
> struct sk_buff *skb;
> int copied, rc;
> + int locked = 1;
Why not *bool*?
[...]
WBR, Sergei
^ permalink raw reply
* lånetilbud
From: CENTRAL TRUST LOAN LIMITED @ 2014-11-19 14:24 UTC (permalink / raw)
Vi er et selskap med økonomisk bistand. Vi låne penger ut til individer trenger økonomisk hjelp, som har en dårlig kreditt posten eller behov for penger til å betale regninger, å investere på forretningsreise. Jeg vil bruke dette mediet til å informere deg om at vi gjengi pålitelig Betalingsmottakers hjelp som jeg vil gjerne tilby deg et lån på 3% så ikke nøl med å søke om et lån fordi vi skal gi deg best av vår tjeneste.
SØKERINFORMASJON
* Navn på søkeren:
* Adressen til søkeren:
* By:
* Land:
* Kjønn:
* Sivilstand:
* Alder:
* Månedlig inntekt:
* Yrke:
* Tel :/ Mobil:
* Beløp:
* Lån varighet:
* E-post:
Du kan kontakte oss via vår e-postadresse: (centraltrust_ltd@webadicta.org)
TEL: +447053866981
Vi venter på ditt svar.
David Donald
--
Esta mensagem foi verificada pelo sistema de antivirus e
acredita-se estar livre de perigo.
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] r8152: adjust r8152_submit_rx
From: Sergei Shtylyov @ 2014-11-19 14:02 UTC (permalink / raw)
To: Hayes Wang, netdev; +Cc: nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-96-Taiwan-albertk@realtek.com>
Hello.
On 11/19/2014 8:20 AM, Hayes Wang wrote:
> The behavior of handling the returned status from r8152_submit_rx()
> is almost same, so let r8152_submit_rx() deal with the error
> directly. This could avoid the duplicate code.
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/usb/r8152.c | 41 +++++++++++++++++++++--------------------
> 1 file changed, 21 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 0a30fd3..df0868b 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
[...]
> @@ -1806,11 +1789,29 @@ static void bottom_half(unsigned long data)
> static
> int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags)
> {
> + int ret = 0;
Initialization not needed.
> +
> usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
> agg->head, agg_buf_sz,
> (usb_complete_t)read_bulk_callback, agg);
>
> - return usb_submit_urb(agg->urb, mem_flags);
> + ret = usb_submit_urb(agg->urb, mem_flags);
> +
Empty line not needed here either.
> + if (ret == -ENODEV) {
> + set_bit(RTL8152_UNPLUG, &tp->flags);
> + netif_device_detach(tp->netdev);
> + } else if (ret) {
> + struct urb *urb = agg->urb;
> + unsigned long flags;
> +
> + urb->actual_length = 0;
> + spin_lock_irqsave(&tp->rx_lock, flags);
> + list_add_tail(&agg->list, &tp->rx_done);
> + spin_unlock_irqrestore(&tp->rx_lock, flags);
> + tasklet_schedule(&tp->tl);
> + }
> +
> + return ret;
> }
[...]
WBR, Sergei
^ permalink raw reply
* Re: [patch net-next v2 02/10] net: introduce generic switch devices support
From: Roopa Prabhu @ 2014-11-19 13:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <20141119134645.GE1926@nanopsycho.orion>
On 11/19/14, 5:46 AM, Jiri Pirko wrote:
> Wed, Nov 19, 2014 at 02:28:10PM CET, roopa@cumulusnetworks.com wrote:
>> On 11/9/14, 2:51 AM, Jiri Pirko wrote:
>>> The goal of this is to provide a possibility to support various switch
>>> chips. Drivers should implement relevant ndos to do so. Now there is
>>> only one ndo defined:
>>> - for getting physical switch id is in place.
>>>
>>> Note that user can use random port netdevice to access the switch.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>> ---
>>> Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
>>> MAINTAINERS | 7 ++++
>>> include/linux/netdevice.h | 10 ++++++
>>> include/net/switchdev.h | 30 +++++++++++++++++
>>> net/Kconfig | 1 +
>>> net/Makefile | 3 ++
>>> net/switchdev/Kconfig | 13 ++++++++
>>> net/switchdev/Makefile | 5 +++
>>> net/switchdev/switchdev.c | 33 +++++++++++++++++++
>>> 9 files changed, 161 insertions(+)
>>> create mode 100644 Documentation/networking/switchdev.txt
>>> create mode 100644 include/net/switchdev.h
>>> create mode 100644 net/switchdev/Kconfig
>>> create mode 100644 net/switchdev/Makefile
>>> create mode 100644 net/switchdev/switchdev.c
>>>
>>> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
>>> new file mode 100644
>>> index 0000000..98be76c
>>> --- /dev/null
>>> +++ b/Documentation/networking/switchdev.txt
>>> @@ -0,0 +1,59 @@
>>> +Switch (and switch-ish) device drivers HOWTO
>>> +===========================
>>> +
>>> +Please note that the word "switch" is here used in very generic meaning.
>>> +This include devices supporting L2/L3 but also various flow offloading chips,
>>> +including switches embedded into SR-IOV NICs.
>>> +
>>> +Lets describe a topology a bit. Imagine the following example:
>>> +
>>> + +----------------------------+ +---------------+
>>> + | SOME switch chip | | CPU |
>>> + +----------------------------+ +---------------+
>>> + port1 port2 port3 port4 MNGMNT | PCI-E |
>>> + | | | | | +---------------+
>>> + PHY PHY | | | | NIC0 NIC1
>>> + | | | | | |
>>> + | | +- PCI-E -+ | |
>>> + | +------- MII -------+ |
>>> + +------------- MII ------------+
>>> +
>>> +In this example, there are two independent lines between the switch silicon
>>> +and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
>>> +separate from the switch driver. SOME switch chip is by managed by a driver
>>> +via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
>>> +connected to some other type of bus.
>>> +
>>> +Now, for the previous example show the representation in kernel:
>>> +
>>> + +----------------------------+ +---------------+
>>> + | SOME switch chip | | CPU |
>>> + +----------------------------+ +---------------+
>>> + sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT | PCI-E |
>>> + | | | | | +---------------+
>>> + PHY PHY | | | | eth0 eth1
>>> + | | | | | |
>>> + | | +- PCI-E -+ | |
>>> + | +------- MII -------+ |
>>> + +------------- MII ------------+
>>> +
>>> +Lets call the example switch driver for SOME switch chip "SOMEswitch". This
>>> +driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
>>> +created for each port of a switch. These netdevices are instances
>>> +of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"
>>> +of the switch chip. eth0 and eth1 are instances of some other existing driver.
>>> +
>>> +The only difference of the switch-port netdevice from the ordinary netdevice
>>> +is that is implements couple more NDOs:
>>> +
>>> + ndo_sw_parent_get_id - This returns the same ID for two port netdevices
>>> + of the same physical switch chip. This is
>>> + mandatory to be implemented by all switch drivers
>>> + and serves the caller for recognition of a port
>>> + netdevice.
>>> + ndo_sw_parent_* - Functions that serve for a manipulation of the switch
>>> + chip itself (it can be though of as a "parent" of the
>>> + port, therefore the name). They are not port-specific.
>>> + Caller might use arbitrary port netdevice of the same
>>> + switch and it will make no difference.
>>> + ndo_sw_port_* - Functions that serve for a port-specific manipulation.
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 3a41fb0..776e078 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -9003,6 +9003,13 @@ F: lib/swiotlb.c
>>> F: arch/*/kernel/pci-swiotlb.c
>>> F: include/linux/swiotlb.h
>>> +SWITCHDEV
>>> +M: Jiri Pirko <jiri@resnulli.us>
>>> +L: netdev@vger.kernel.org
>>> +S: Supported
>>> +F: net/switchdev/
>>> +F: include/net/switchdev.h
>>> +
>>> SYNOPSYS ARC ARCHITECTURE
>>> M: Vineet Gupta <vgupta@synopsys.com>
>>> S: Supported
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index 71922e0..97eade9 100644
>>> --- a/include/linux/netdevice.h
>>> +++ b/include/linux/netdevice.h
>>> @@ -1017,6 +1017,12 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
>>> * performing GSO on a packet. The device returns true if it is
>>> * able to GSO the packet, false otherwise. If the return value is
>>> * false the stack will do software GSO.
>>> + *
>>> + * int (*ndo_sw_parent_id_get)(struct net_device *dev,
>>> + * struct netdev_phys_item_id *psid);
>>> + * Called to get an ID of the switch chip this port is part of.
>>> + * If driver implements this, it indicates that it represents a port
>>> + * of a switch chip.
>>> */
>>> struct net_device_ops {
>>> int (*ndo_init)(struct net_device *dev);
>>> @@ -1168,6 +1174,10 @@ struct net_device_ops {
>>> int (*ndo_get_lock_subclass)(struct net_device *dev);
>>> bool (*ndo_gso_check) (struct sk_buff *skb,
>>> struct net_device *dev);
>>> +#ifdef CONFIG_NET_SWITCHDEV
>>> + int (*ndo_sw_parent_id_get)(struct net_device *dev,
>>> + struct netdev_phys_item_id *psid);
>> Can we keep the name generic and not include "sw" which implies switch here
>> ?.
>> I understand that it is under CONFIG_NET_SWITCHDEV but we might find use for
>> them in other offload scenarios in the future.
>> This particular ndo can be just ndo_parent_id_get().
>> And the others that do specific offloads can have "offload" in them if
>> required..?.
>
> But this is for getting parent switch id, sw should be there.
Since we have not figured out the details or namespace for switchd ids
yet, its still some parent id to me.
> If comes a
> time when this might be reused to something else, we change it then.
> This is internal api, easily changeable.
also, "sw" seems more "software" than "switch".
>
>>
>>
>>> +#endif
>>> };
>>> /**
>>> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>>> new file mode 100644
>>> index 0000000..79bf9bd
>>> --- /dev/null
>>> +++ b/include/net/switchdev.h
>>> @@ -0,0 +1,30 @@
>>> +/*
>>> + * include/net/switchdev.h - Switch device API
>>> + * Copyright (c) 2014 Jiri Pirko <jiri@resnulli.us>
>>> + *
>>> + * 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.
>>> + */
>>> +#ifndef _LINUX_SWITCHDEV_H_
>>> +#define _LINUX_SWITCHDEV_H_
>>> +
>>> +#include <linux/netdevice.h>
>>> +
>>> +#ifdef CONFIG_NET_SWITCHDEV
>>> +
>>> +int netdev_sw_parent_id_get(struct net_device *dev,
>>> + struct netdev_phys_item_id *psid);
>>> +
>>> +#else
>>> +
>>> +static inline int netdev_sw_parent_id_get(struct net_device *dev,
>>> + struct netdev_phys_item_id *psid)
>>> +{
>>> + return -EOPNOTSUPP;
>>> +}
>>> +
>>> +#endif
>>> +
>>> +#endif /* _LINUX_SWITCHDEV_H_ */
>>> diff --git a/net/Kconfig b/net/Kconfig
>>> index 99815b5..ff9ffc1 100644
>>> --- a/net/Kconfig
>>> +++ b/net/Kconfig
>>> @@ -228,6 +228,7 @@ source "net/vmw_vsock/Kconfig"
>>> source "net/netlink/Kconfig"
>>> source "net/mpls/Kconfig"
>>> source "net/hsr/Kconfig"
>>> +source "net/switchdev/Kconfig"
>>> config RPS
>>> boolean
>>> diff --git a/net/Makefile b/net/Makefile
>>> index 7ed1970..95fc694 100644
>>> --- a/net/Makefile
>>> +++ b/net/Makefile
>>> @@ -73,3 +73,6 @@ obj-$(CONFIG_OPENVSWITCH) += openvswitch/
>>> obj-$(CONFIG_VSOCKETS) += vmw_vsock/
>>> obj-$(CONFIG_NET_MPLS_GSO) += mpls/
>>> obj-$(CONFIG_HSR) += hsr/
>>> +ifneq ($(CONFIG_NET_SWITCHDEV),)
>>> +obj-y += switchdev/
>>> +endif
>>> diff --git a/net/switchdev/Kconfig b/net/switchdev/Kconfig
>>> new file mode 100644
>>> index 0000000..1557545
>>> --- /dev/null
>>> +++ b/net/switchdev/Kconfig
>>> @@ -0,0 +1,13 @@
>>> +#
>>> +# Configuration for Switch device support
>>> +#
>>> +
>>> +config NET_SWITCHDEV
>>> + boolean "Switch (and switch-ish) device support (EXPERIMENTAL)"
>>> + depends on INET
>>> + ---help---
>>> + This module provides glue between core networking code and device
>>> + drivers in order to support hardware switch chips in very generic
>>> + meaning of the word "switch". This include devices supporting L2/L3 but
>>> + also various flow offloading chips, including switches embedded into
>>> + SR-IOV NICs.
>>> diff --git a/net/switchdev/Makefile b/net/switchdev/Makefile
>>> new file mode 100644
>>> index 0000000..5ed63ed
>>> --- /dev/null
>>> +++ b/net/switchdev/Makefile
>>> @@ -0,0 +1,5 @@
>>> +#
>>> +# Makefile for the Switch device API
>>> +#
>>> +
>>> +obj-$(CONFIG_NET_SWITCHDEV) += switchdev.o
>>> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>>> new file mode 100644
>>> index 0000000..5010f646
>>> --- /dev/null
>>> +++ b/net/switchdev/switchdev.c
>>> @@ -0,0 +1,33 @@
>>> +/*
>>> + * net/switchdev/switchdev.c - Switch device API
>>> + * Copyright (c) 2014 Jiri Pirko <jiri@resnulli.us>
>>> + *
>>> + * 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/kernel.h>
>>> +#include <linux/types.h>
>>> +#include <linux/init.h>
>>> +#include <linux/netdevice.h>
>>> +#include <net/switchdev.h>
>>> +
>>> +/**
>>> + * netdev_sw_parent_id_get - Get ID of a switch
>>> + * @dev: port device
>>> + * @psid: switch ID
>>> + *
>>> + * Get ID of a switch this port is part of.
>>> + */
>>> +int netdev_sw_parent_id_get(struct net_device *dev,
>>> + struct netdev_phys_item_id *psid)
>>> +{
>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>> +
>>> + if (!ops->ndo_sw_parent_id_get)
>>> + return -EOPNOTSUPP;
>>> + return ops->ndo_sw_parent_id_get(dev, psid);
>>> +}
>>> +EXPORT_SYMBOL(netdev_sw_parent_id_get);
> --
> 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: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-11-19 13:49 UTC (permalink / raw)
To: Maximilian Engelhardt
Cc: Rafał Miłecki, Michael Tokarev, Seth Forshee,
brcm80211 development,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development
In-Reply-To: <546C9F2B.8090104-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 11/19/14 14:46, Arend van Spriel wrote:
> On 11/17/14 23:36, Maximilian Engelhardt wrote:
>> On Thursday 09 October 2014 10:21:12 Rafał Miłecki wrote:
>>> On 9 October 2014 09:52, Arend van Spriel<arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>>> I have been staring at differences brcmsmac and our internal driver
>>>> (which
>>>> wl is derived from as well). Would you be able to make an mmiotrace
>>>> loading
>>>> wl and brcmsmac.
>>>
>>> Arend,
>>>
>>> As you noticed earlier, this is a WiFi card with BT. I've checked
>>> siutils.c from SDK 7.14.43.7 (got it from Netgear R8000) and it has
>>> three BCM4313 workarounds:
>>>
>>>
>>> 1) si_doattach
>>> SI_MSG(("Applying 4313 WARs\n"));
>>> si_pmu_chipcontrol(sih, 0, CCTRL_4313_12MA_LED_DRIVE,
>>> CCTRL_4313_12MA_LED_DRIVE);
>>>
>>> It's already implemented in bcma, see driver_chipcommon_pmu.c
>>>
>>>
>>> 2) si_epa_4313war
>>> /* EPA Fix */
>>> W_REG(sii->osh,&cc->gpiocontrol,
>>> R_REG(sii->osh,&cc->gpiocontrol) | GPIO_CTRL_EPA_EN_MASK);
>>>
>>> This is what you already implement in ai_epa_4313war
>>>
>>>
>>> 3) si_pmu_synth_pwrsw_4313_war
>>> I don't think it's implemented.
>>>
>>>
>>> 4) si_btcombo_p250_4313_war
>>> I also don't think it's implemented
>>>
>>>
>>> The last one (si_btcombo_p250_4313_war) looks promising, the comment
>>> above the function says:
>>> /** WL/BT control for 4313 btcombo boards>= P250 */
>>> I guess you need to re-implement this function and call it somewhere
>>> in brcmsmac.
>>
>> Hi,
>>
>> I just wanted to ask if there is any progress on this issue since I
>> haven't
>> heard anything for a month. Please let me know if you need any additional
>> information.
>
> I had a bit of problem with the mmiotrace files. Well, my (virtual)
> linux machine had as it ended up swapping on my disk and went down the
> drain.
>
> I still wanted to look at items 3) and 4) that Rafal mentioned although
> item 4) does not seems to apply to Michael's 4313 it may help yours. I
> submitted a patch to get counter statistics from the 802.11 core on the
> chip [1] as I am curious whether that will show a possible lead.
>
> Regards,
> Arend
+ links
patch [1] depends on patch [2]
[1]
https://git.kernel.org/cgit/linux/kernel/git/linville/wireless-next.git/commit/drivers/net/wireless/brcm80211?id=3fe33c4ce
[2]
https://git.kernel.org/cgit/linux/kernel/git/linville/wireless-next.git/commit/drivers/net/wireless/brcm80211?id=9146782b1b
--
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 v2 02/10] net: introduce generic switch devices support
From: Jiri Pirko @ 2014-11-19 13:46 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma,
f.fainelli, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl
In-Reply-To: <546C9AEA.2020209@cumulusnetworks.com>
Wed, Nov 19, 2014 at 02:28:10PM CET, roopa@cumulusnetworks.com wrote:
>On 11/9/14, 2:51 AM, Jiri Pirko wrote:
>>The goal of this is to provide a possibility to support various switch
>>chips. Drivers should implement relevant ndos to do so. Now there is
>>only one ndo defined:
>>- for getting physical switch id is in place.
>>
>>Note that user can use random port netdevice to access the switch.
>>
>>Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>---
>> Documentation/networking/switchdev.txt | 59 ++++++++++++++++++++++++++++++++++
>> MAINTAINERS | 7 ++++
>> include/linux/netdevice.h | 10 ++++++
>> include/net/switchdev.h | 30 +++++++++++++++++
>> net/Kconfig | 1 +
>> net/Makefile | 3 ++
>> net/switchdev/Kconfig | 13 ++++++++
>> net/switchdev/Makefile | 5 +++
>> net/switchdev/switchdev.c | 33 +++++++++++++++++++
>> 9 files changed, 161 insertions(+)
>> create mode 100644 Documentation/networking/switchdev.txt
>> create mode 100644 include/net/switchdev.h
>> create mode 100644 net/switchdev/Kconfig
>> create mode 100644 net/switchdev/Makefile
>> create mode 100644 net/switchdev/switchdev.c
>>
>>diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
>>new file mode 100644
>>index 0000000..98be76c
>>--- /dev/null
>>+++ b/Documentation/networking/switchdev.txt
>>@@ -0,0 +1,59 @@
>>+Switch (and switch-ish) device drivers HOWTO
>>+===========================
>>+
>>+Please note that the word "switch" is here used in very generic meaning.
>>+This include devices supporting L2/L3 but also various flow offloading chips,
>>+including switches embedded into SR-IOV NICs.
>>+
>>+Lets describe a topology a bit. Imagine the following example:
>>+
>>+ +----------------------------+ +---------------+
>>+ | SOME switch chip | | CPU |
>>+ +----------------------------+ +---------------+
>>+ port1 port2 port3 port4 MNGMNT | PCI-E |
>>+ | | | | | +---------------+
>>+ PHY PHY | | | | NIC0 NIC1
>>+ | | | | | |
>>+ | | +- PCI-E -+ | |
>>+ | +------- MII -------+ |
>>+ +------------- MII ------------+
>>+
>>+In this example, there are two independent lines between the switch silicon
>>+and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are
>>+separate from the switch driver. SOME switch chip is by managed by a driver
>>+via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be
>>+connected to some other type of bus.
>>+
>>+Now, for the previous example show the representation in kernel:
>>+
>>+ +----------------------------+ +---------------+
>>+ | SOME switch chip | | CPU |
>>+ +----------------------------+ +---------------+
>>+ sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT | PCI-E |
>>+ | | | | | +---------------+
>>+ PHY PHY | | | | eth0 eth1
>>+ | | | | | |
>>+ | | +- PCI-E -+ | |
>>+ | +------- MII -------+ |
>>+ +------------- MII ------------+
>>+
>>+Lets call the example switch driver for SOME switch chip "SOMEswitch". This
>>+driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX
>>+created for each port of a switch. These netdevices are instances
>>+of "SOMEswitch" driver. sw0pX netdevices serve as a "representation"
>>+of the switch chip. eth0 and eth1 are instances of some other existing driver.
>>+
>>+The only difference of the switch-port netdevice from the ordinary netdevice
>>+is that is implements couple more NDOs:
>>+
>>+ ndo_sw_parent_get_id - This returns the same ID for two port netdevices
>>+ of the same physical switch chip. This is
>>+ mandatory to be implemented by all switch drivers
>>+ and serves the caller for recognition of a port
>>+ netdevice.
>>+ ndo_sw_parent_* - Functions that serve for a manipulation of the switch
>>+ chip itself (it can be though of as a "parent" of the
>>+ port, therefore the name). They are not port-specific.
>>+ Caller might use arbitrary port netdevice of the same
>>+ switch and it will make no difference.
>>+ ndo_sw_port_* - Functions that serve for a port-specific manipulation.
>>diff --git a/MAINTAINERS b/MAINTAINERS
>>index 3a41fb0..776e078 100644
>>--- a/MAINTAINERS
>>+++ b/MAINTAINERS
>>@@ -9003,6 +9003,13 @@ F: lib/swiotlb.c
>> F: arch/*/kernel/pci-swiotlb.c
>> F: include/linux/swiotlb.h
>>+SWITCHDEV
>>+M: Jiri Pirko <jiri@resnulli.us>
>>+L: netdev@vger.kernel.org
>>+S: Supported
>>+F: net/switchdev/
>>+F: include/net/switchdev.h
>>+
>> SYNOPSYS ARC ARCHITECTURE
>> M: Vineet Gupta <vgupta@synopsys.com>
>> S: Supported
>>diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>index 71922e0..97eade9 100644
>>--- a/include/linux/netdevice.h
>>+++ b/include/linux/netdevice.h
>>@@ -1017,6 +1017,12 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
>> * performing GSO on a packet. The device returns true if it is
>> * able to GSO the packet, false otherwise. If the return value is
>> * false the stack will do software GSO.
>>+ *
>>+ * int (*ndo_sw_parent_id_get)(struct net_device *dev,
>>+ * struct netdev_phys_item_id *psid);
>>+ * Called to get an ID of the switch chip this port is part of.
>>+ * If driver implements this, it indicates that it represents a port
>>+ * of a switch chip.
>> */
>> struct net_device_ops {
>> int (*ndo_init)(struct net_device *dev);
>>@@ -1168,6 +1174,10 @@ struct net_device_ops {
>> int (*ndo_get_lock_subclass)(struct net_device *dev);
>> bool (*ndo_gso_check) (struct sk_buff *skb,
>> struct net_device *dev);
>>+#ifdef CONFIG_NET_SWITCHDEV
>>+ int (*ndo_sw_parent_id_get)(struct net_device *dev,
>>+ struct netdev_phys_item_id *psid);
>Can we keep the name generic and not include "sw" which implies switch here
>?.
>I understand that it is under CONFIG_NET_SWITCHDEV but we might find use for
>them in other offload scenarios in the future.
>This particular ndo can be just ndo_parent_id_get().
>And the others that do specific offloads can have "offload" in them if
>required..?.
But this is for getting parent switch id, sw should be there. If comes a
time when this might be reused to something else, we change it then.
This is internal api, easily changeable.
>
>
>
>>+#endif
>> };
>> /**
>>diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>>new file mode 100644
>>index 0000000..79bf9bd
>>--- /dev/null
>>+++ b/include/net/switchdev.h
>>@@ -0,0 +1,30 @@
>>+/*
>>+ * include/net/switchdev.h - Switch device API
>>+ * Copyright (c) 2014 Jiri Pirko <jiri@resnulli.us>
>>+ *
>>+ * 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.
>>+ */
>>+#ifndef _LINUX_SWITCHDEV_H_
>>+#define _LINUX_SWITCHDEV_H_
>>+
>>+#include <linux/netdevice.h>
>>+
>>+#ifdef CONFIG_NET_SWITCHDEV
>>+
>>+int netdev_sw_parent_id_get(struct net_device *dev,
>>+ struct netdev_phys_item_id *psid);
>>+
>>+#else
>>+
>>+static inline int netdev_sw_parent_id_get(struct net_device *dev,
>>+ struct netdev_phys_item_id *psid)
>>+{
>>+ return -EOPNOTSUPP;
>>+}
>>+
>>+#endif
>>+
>>+#endif /* _LINUX_SWITCHDEV_H_ */
>>diff --git a/net/Kconfig b/net/Kconfig
>>index 99815b5..ff9ffc1 100644
>>--- a/net/Kconfig
>>+++ b/net/Kconfig
>>@@ -228,6 +228,7 @@ source "net/vmw_vsock/Kconfig"
>> source "net/netlink/Kconfig"
>> source "net/mpls/Kconfig"
>> source "net/hsr/Kconfig"
>>+source "net/switchdev/Kconfig"
>> config RPS
>> boolean
>>diff --git a/net/Makefile b/net/Makefile
>>index 7ed1970..95fc694 100644
>>--- a/net/Makefile
>>+++ b/net/Makefile
>>@@ -73,3 +73,6 @@ obj-$(CONFIG_OPENVSWITCH) += openvswitch/
>> obj-$(CONFIG_VSOCKETS) += vmw_vsock/
>> obj-$(CONFIG_NET_MPLS_GSO) += mpls/
>> obj-$(CONFIG_HSR) += hsr/
>>+ifneq ($(CONFIG_NET_SWITCHDEV),)
>>+obj-y += switchdev/
>>+endif
>>diff --git a/net/switchdev/Kconfig b/net/switchdev/Kconfig
>>new file mode 100644
>>index 0000000..1557545
>>--- /dev/null
>>+++ b/net/switchdev/Kconfig
>>@@ -0,0 +1,13 @@
>>+#
>>+# Configuration for Switch device support
>>+#
>>+
>>+config NET_SWITCHDEV
>>+ boolean "Switch (and switch-ish) device support (EXPERIMENTAL)"
>>+ depends on INET
>>+ ---help---
>>+ This module provides glue between core networking code and device
>>+ drivers in order to support hardware switch chips in very generic
>>+ meaning of the word "switch". This include devices supporting L2/L3 but
>>+ also various flow offloading chips, including switches embedded into
>>+ SR-IOV NICs.
>>diff --git a/net/switchdev/Makefile b/net/switchdev/Makefile
>>new file mode 100644
>>index 0000000..5ed63ed
>>--- /dev/null
>>+++ b/net/switchdev/Makefile
>>@@ -0,0 +1,5 @@
>>+#
>>+# Makefile for the Switch device API
>>+#
>>+
>>+obj-$(CONFIG_NET_SWITCHDEV) += switchdev.o
>>diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
>>new file mode 100644
>>index 0000000..5010f646
>>--- /dev/null
>>+++ b/net/switchdev/switchdev.c
>>@@ -0,0 +1,33 @@
>>+/*
>>+ * net/switchdev/switchdev.c - Switch device API
>>+ * Copyright (c) 2014 Jiri Pirko <jiri@resnulli.us>
>>+ *
>>+ * 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/kernel.h>
>>+#include <linux/types.h>
>>+#include <linux/init.h>
>>+#include <linux/netdevice.h>
>>+#include <net/switchdev.h>
>>+
>>+/**
>>+ * netdev_sw_parent_id_get - Get ID of a switch
>>+ * @dev: port device
>>+ * @psid: switch ID
>>+ *
>>+ * Get ID of a switch this port is part of.
>>+ */
>>+int netdev_sw_parent_id_get(struct net_device *dev,
>>+ struct netdev_phys_item_id *psid)
>>+{
>>+ const struct net_device_ops *ops = dev->netdev_ops;
>>+
>>+ if (!ops->ndo_sw_parent_id_get)
>>+ return -EOPNOTSUPP;
>>+ return ops->ndo_sw_parent_id_get(dev, psid);
>>+}
>>+EXPORT_SYMBOL(netdev_sw_parent_id_get);
>
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-11-19 13:46 UTC (permalink / raw)
To: Maximilian Engelhardt
Cc: Rafał Miłecki, Michael Tokarev, Seth Forshee,
brcm80211 development, linux-wireless@vger.kernel.org,
Network Development
In-Reply-To: <3543341.FmUQFH9nrl@eisbaer>
On 11/17/14 23:36, Maximilian Engelhardt wrote:
> On Thursday 09 October 2014 10:21:12 Rafał Miłecki wrote:
>> On 9 October 2014 09:52, Arend van Spriel<arend@broadcom.com> wrote:
>>> I have been staring at differences brcmsmac and our internal driver (which
>>> wl is derived from as well). Would you be able to make an mmiotrace
>>> loading
>>> wl and brcmsmac.
>>
>> Arend,
>>
>> As you noticed earlier, this is a WiFi card with BT. I've checked
>> siutils.c from SDK 7.14.43.7 (got it from Netgear R8000) and it has
>> three BCM4313 workarounds:
>>
>>
>> 1) si_doattach
>> SI_MSG(("Applying 4313 WARs\n"));
>> si_pmu_chipcontrol(sih, 0, CCTRL_4313_12MA_LED_DRIVE,
>> CCTRL_4313_12MA_LED_DRIVE);
>>
>> It's already implemented in bcma, see driver_chipcommon_pmu.c
>>
>>
>> 2) si_epa_4313war
>> /* EPA Fix */
>> W_REG(sii->osh,&cc->gpiocontrol,
>> R_REG(sii->osh,&cc->gpiocontrol) | GPIO_CTRL_EPA_EN_MASK);
>>
>> This is what you already implement in ai_epa_4313war
>>
>>
>> 3) si_pmu_synth_pwrsw_4313_war
>> I don't think it's implemented.
>>
>>
>> 4) si_btcombo_p250_4313_war
>> I also don't think it's implemented
>>
>>
>> The last one (si_btcombo_p250_4313_war) looks promising, the comment
>> above the function says:
>> /** WL/BT control for 4313 btcombo boards>= P250 */
>> I guess you need to re-implement this function and call it somewhere
>> in brcmsmac.
>
> Hi,
>
> I just wanted to ask if there is any progress on this issue since I haven't
> heard anything for a month. Please let me know if you need any additional
> information.
I had a bit of problem with the mmiotrace files. Well, my (virtual)
linux machine had as it ended up swapping on my disk and went down the
drain.
I still wanted to look at items 3) and 4) that Rafal mentioned although
item 4) does not seems to apply to Michael's 4313 it may help yours. I
submitted a patch to get counter statistics from the 802.11 core on the
chip [1] as I am curious whether that will show a possible lead.
Regards,
Arend
^ 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