* Re: net: xfrm: Deletion of an unnecessary check before the function call "ipcomp_free_tfms"
From: David Miller @ 2014-11-19 18:19 UTC (permalink / raw)
To: dan.carpenter
Cc: elfring, herbert, steffen.klassert, netdev, linux-kernel,
kernel-janitors, julia.lawall
In-Reply-To: <20141119101003.GL4905@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 19 Nov 2014 13:10:03 +0300
> I have come to view you as a very clever troll.
+1
^ permalink raw reply
* [PATCH net-next v2] packet: make packet_snd fail on len smaller than l2 header
From: Willem de Bruijn @ 2014-11-19 18:10 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 | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 4cd13d8..58af5802 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(const struct net_device *dev, int len)
+{
+ /* 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(dev, tp_len))
return -EINVAL;
- }
skb_push(skb, dev->hard_header_len);
err = skb_store_bits(skb, 0, data,
@@ -2500,9 +2508,14 @@ 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(dev, len))
+ 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
* Re: [PATCH net-next] packet: make packet_snd fail on len smaller than l2 header
From: Willem de Bruijn @ 2014-11-19 18:07 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Network Development, David Miller, Eric Dumazet
In-Reply-To: <546CD087.9070003@redhat.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)
>> +{
>
>
> const struct net_device *dev
>
> [ if at it, I'd perhaps also swap the arg order ]
Thanks, Daniel. I'll resubmit with both changes.
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-11-19 17:54 UTC (permalink / raw)
To: Michael Tokarev
Cc: Maximilian Engelhardt, Rafał Miłecki, Seth Forshee,
brcm80211 development, linux-wireless@vger.kernel.org,
Network Development
In-Reply-To: <546C5D1F.108@msgid.tls.msk.ru>
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
On 11/19/14 10:04, Michael Tokarev wrote:
> 18.11.2014 01:36, Maximilian Engelhardt wrote:
> []
>> 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've no idea if there's any progress. Meanwhile I've an easy way of
> testing of my brcm4313 card in a mini-itx board with mini-PCIe slot.
> It works rather nicely and the stalls are easy to trigger.
> Running 3.16 kernel right now, tried to d/load a file from the
> AP, -- boom, it stalled after 77Kb.
>
> Since the previous discussion apparently ended prematurely and no patches
> to try emerged, I don't have anything to try on it...
In our last email exchange I got the impression you switch to Intel
board and did not want to keep replacing cards for testing. Nice to hear
you have an alternative setup for this and I assume are willing to do
some testing.
I submitted two patches upstream and additionally I have attached two
other that are still under review. Could you try these patches and sent
me the content of the two debugfs files 'macstat' and 'hardware' after a
stall has occurred.
Regards,
Arend
[-- Attachment #2: 0001-brcmutil-add-helper-function-to-format-board-revisio.patch --]
[-- Type: text/plain, Size: 2045 bytes --]
From dbc69f9769b92f3ce115fabf880f767d6bd4c436 Mon Sep 17 00:00:00 2001
From: Arend van Spriel <arend@broadcom.com>
Date: Thu, 13 Nov 2014 14:16:34 +0100
Subject: [PATCH 1/2] brcmutil: add helper function to format board revision
The board revision that is available in hardware can be translated
so it matches the labelling on the board. This is accomplished by
this helper function.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
drivers/net/wireless/brcm80211/brcmutil/utils.c | 16 ++++++++++++++++
drivers/net/wireless/brcm80211/include/brcmu_utils.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/drivers/net/wireless/brcm80211/brcmutil/utils.c b/drivers/net/wireless/brcm80211/brcmutil/utils.c
index 0f7e1c7..1575a1d 100644
--- a/drivers/net/wireless/brcm80211/brcmutil/utils.c
+++ b/drivers/net/wireless/brcm80211/brcmutil/utils.c
@@ -292,4 +292,20 @@ void brcmu_dbg_hex_dump(const void *data, size_t size, const char *fmt, ...)
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, data, size);
}
EXPORT_SYMBOL(brcmu_dbg_hex_dump);
+
+/* Produce a human-readable string for boardrev */
+char *brcmu_boardrev_str(u32 brev, char *buf)
+{
+ char c;
+
+ if (brev < 0x100) {
+ snprintf(buf, 8, "%d.%d", (brev & 0xf0) >> 4, brev & 0xf);
+ } else {
+ c = (brev & 0xf000) == 0x1000 ? 'P' : 'A';
+ snprintf(buf, 8, "%c%03x", c, brev & 0xfff);
+ }
+ return (buf);
+}
+EXPORT_SYMBOL(brcmu_boardrev_str);
+
#endif /* defined(DEBUG) */
diff --git a/drivers/net/wireless/brcm80211/include/brcmu_utils.h b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
index 8ba445b..a043e29 100644
--- a/drivers/net/wireless/brcm80211/include/brcmu_utils.h
+++ b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
@@ -218,4 +218,6 @@ void brcmu_dbg_hex_dump(const void *data, size_t size, const char *fmt, ...)
}
#endif
+char *brcmu_boardrev_str(u32 brev, char *buf);
+
#endif /* _BRCMU_UTILS_H_ */
--
1.9.1
[-- Attachment #3: 0002-brcmsmac-extend-hardware-info-shown-in-debugfs.patch --]
[-- Type: text/plain, Size: 2491 bytes --]
From a197cf44ef058942928b48223fce9d3f112be9d0 Mon Sep 17 00:00:00 2001
From: Arend van Spriel <arend@broadcom.com>
Date: Thu, 13 Nov 2014 14:19:49 +0100
Subject: [PATCH 2/2] brcmsmac: extend hardware info shown in debugfs
The hardware info now also include radio and phy information, which
can be helpful in debugging issues.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
drivers/net/wireless/brcm80211/brcmsmac/debug.c | 40 +++++++++++++++++--------
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/debug.c b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
index 19740c1..c9a8b93 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/debug.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/debug.c
@@ -30,6 +30,7 @@
#include "main.h"
#include "debug.h"
#include "brcms_trace_events.h"
+#include "phy/phy_int.h"
static struct dentry *root_folder;
@@ -74,20 +75,33 @@ static
int brcms_debugfs_hardware_read(struct seq_file *s, void *data)
{
struct brcms_pub *drvr = s->private;
+ struct brcms_hardware *hw = drvr->wlc->hw;
+ struct bcma_device *core = hw->d11core;
+ struct bcma_bus *bus = core->bus;
+ char boardrev[10];
- seq_printf(s, "board vendor: %x\n"
- "board type: %x\n"
- "board revision: %x\n"
- "board flags: %x\n"
- "board flags2: %x\n"
- "firmware revision: %x\n",
- drvr->wlc->hw->d11core->bus->boardinfo.vendor,
- drvr->wlc->hw->d11core->bus->boardinfo.type,
- drvr->wlc->hw->boardrev,
- drvr->wlc->hw->boardflags,
- drvr->wlc->hw->boardflags2,
- drvr->wlc->ucode_rev);
-
+ seq_printf(s, "chipnum 0x%x\n"
+ "chiprev 0x%x\n"
+ "chippackage 0x%x\n"
+ "corerev 0x%x\n"
+ "boardid 0x%x\n"
+ "boardvendor 0x%x\n"
+ "boardrev %s\n"
+ "boardflags 0x%x\n"
+ "boardflags2 0x%x\n"
+ "ucoderev 0x%x\n"
+ "radiorev 0x%x\n"
+ "phytype 0x%x\n"
+ "phyrev 0x%x\n"
+ "anarev 0x%x\n"
+ "nvramrev %d\n",
+ bus->chipinfo.id, bus->chipinfo.rev, bus->chipinfo.pkg,
+ core->id.rev, bus->boardinfo.type, bus->boardinfo.vendor,
+ brcmu_boardrev_str(hw->boardrev, boardrev),
+ drvr->wlc->hw->boardflags, drvr->wlc->hw->boardflags2,
+ drvr->wlc->ucode_rev, hw->band->radiorev,
+ hw->band->phytype, hw->band->phyrev, hw->band->pi->ana_rev,
+ hw->sromrev);
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [ovs-dev] [PATCH net] openvswitch: Fix mask generation for IPv6 labels.
From: Joe Stringer @ 2014-11-19 17:48 UTC (permalink / raw)
To: Pravin Shelar; +Cc: dev@openvswitch.org, netdev, LKML
In-Reply-To: <CALnjE+rr2tFdvD+X=BbAza_5ad4DYs6viwvZWHCebQYmpvKU3Q@mail.gmail.com>
On Wednesday, November 19, 2014 00:11:01 Pravin Shelar wrote:
> On Tue, Nov 18, 2014 at 11:25 PM, Joe Stringer <joestringer@nicira.com>
wrote:
> > On 18 November 2014 22:09, Pravin Shelar <pshelar@nicira.com> wrote:
> >> On Tue, Nov 18, 2014 at 10:54 AM, Joe Stringer <joestringer@nicira.com>
> >>
> >> wrote:
> >> > When userspace doesn't provide a mask, OVS datapath generates a fully
> >> > unwildcarded mask for the flow. This is done by taking a copy of the
> >> > flow key, then iterating across its attributes, setting all values to
> >> > 0xff. This works for most attributes, as the length of the netlink
> >> > attribute typically matches the length of the value. However, IPv6
> >> > labels only use the lower 20 bits of the field. This patch makes a
> >> > special case to handle this.
> >> >
> >> > This fixes the following error seen when installing IPv6 flows without
> >> > a mask:
> >> >
> >> > openvswitch: netlink: Invalid IPv6 flow label value (value=ffffffff,
> >> > max=fffff)
> >>
> >> We should allow exact match mask here rather than generating
> >> wildcarded mask. So that ovs can catch invalid ipv6.label.
> >
> > I don't quite follow, I thought this was exact-match? (The existing
> > function sets all bits to 1)
>
> With 0xffffffff value we can exact match on all ipv6.lable bits.
The label field is only 20 bits. The other bits in the same word of the IPv6
header are for version (fixed) and traffic class (handled separately). We don't
do anything with the other bits.
^ permalink raw reply
* Re: [PATCH net-next] packet: make packet_snd fail on len smaller than l2 header
From: Daniel Borkmann @ 2014-11-19 17:16 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, davem, eric.dumazet
In-Reply-To: <1416416165-24697-1-git-send-email-willemb@google.com>
On 11/19/2014 05:56 PM, Willem de Bruijn wrote:
> 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>
Ok, one thing below though, otherwise:
Acked-by: Daniel Borkmann <dborkman@redhat.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)
> +{
const struct net_device *dev
[ if at it, I'd perhaps also swap the arg order ]
> + /* 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);
>
^ permalink raw reply
* Re: [PATCH net] tcp: fix connect() invalid -EADDRNOTAVAIL error
From: Eric Dumazet @ 2014-11-19 17:12 UTC (permalink / raw)
To: Jon Maxwell
Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
jmaxwell
In-Reply-To: <1416379060-15685-1-git-send-email-jmaxwell37@gmail.com>
On Wed, 2014-11-19 at 17:37 +1100, Jon Maxwell wrote:
> Prerequisites for this to happen:
> 1) The local tcp port range must be exhausted.
> 2) A process must have called bind() followed by connect() for all
> local ports.
How the bind() is done exactly ? How SO_REUSEADDR is used ?
> 3) A different process calls connect() only which returns -EADDRNOTAVAIL.
> 4) The system more than 1 interface configured.
>
> If a system has 2 IP Addresses and all local tcp ports are in use
> for connection from IP Address (1). Connecting to the same ports
> via IP Address (2) should work based on the 4 tuple rule. But it
> fails under this condition.
I do not think this is generally true.
If process called bind() to reserve a port, another process should not
be able to use the same port.
Do you have a test program exhibiting the problem ?
Thanks !
^ permalink raw reply
* 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
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