Netdev List
 help / color / mirror / Atom feed
* Re: [RFC v2 2/4] net: enables interface option to skip IP
From: Dan Williams @ 2014-02-17 20:23 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: netdev, xen-devel, kvm, linux-kernel, Luis R. Rodriguez,
	David S. Miller, Alexey Kuznetsov, James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1392433180-16052-3-git-send-email-mcgrof@do-not-panic.com>

On Fri, 2014-02-14 at 18:59 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> Some interfaces do not need to have any IPv4 or IPv6
> addresses, so enable an option to specify this. One
> example where this is observed are virtualization
> backend interfaces which just use the net_device
> constructs to help with their respective frontends.
> 
> This should optimize boot time and complexity on
> virtualization environments for each backend interface
> while also avoiding triggering SLAAC and DAD, which is
> simply pointless for these type of interfaces.

Would it not be better/cleaner to use disable_ipv6 and then add a
disable_ipv4 sysctl, then use those with that interface?  The
IFF_SKIP_IP seems to duplicate at least part of what disable_ipv6 is
already doing.

Dan

> Cc: "David S. Miller" <davem@davemloft.net>
> cC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  include/uapi/linux/if.h | 1 +
>  net/ipv4/devinet.c      | 3 +++
>  net/ipv6/addrconf.c     | 6 ++++++
>  3 files changed, 10 insertions(+)
> 
> diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
> index 8d10382..566d856 100644
> --- a/include/uapi/linux/if.h
> +++ b/include/uapi/linux/if.h
> @@ -85,6 +85,7 @@
>  					 * change when it's running */
>  #define IFF_MACVLAN 0x200000		/* Macvlan device */
>  #define IFF_BRIDGE_NON_ROOT 0x400000    /* Don't consider for root bridge */
> +#define IFF_SKIP_IP	0x800000	/* Skip IPv4, IPv6 */
>  
> 
>  #define IF_GET_IFACE	0x0001		/* for querying only */
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index a1b5bcb..8e9ef07 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -1342,6 +1342,9 @@ static int inetdev_event(struct notifier_block *this, unsigned long event,
>  
>  	ASSERT_RTNL();
>  
> +	if (dev->priv_flags & IFF_SKIP_IP)
> +		goto out;
> +
>  	if (!in_dev) {
>  		if (event == NETDEV_REGISTER) {
>  			in_dev = inetdev_init(dev);
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 4b6b720..57f58e3 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -314,6 +314,9 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
>  
>  	ASSERT_RTNL();
>  
> +	if (dev->priv_flags & IFF_SKIP_IP)
> +		return NULL;
> +
>  	if (dev->mtu < IPV6_MIN_MTU)
>  		return NULL;
>  
> @@ -2749,6 +2752,9 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
>  	int run_pending = 0;
>  	int err;
>  
> +	if (dev->priv_flags & IFF_SKIP_IP)
> +		return NOTIFY_OK;
> +
>  	switch (event) {
>  	case NETDEV_REGISTER:
>  		if (!idev && dev->mtu >= IPV6_MIN_MTU) {

^ permalink raw reply

* Re: netmap, VALE and netmap pipes
From: Stephen Hemminger @ 2014-02-17 20:14 UTC (permalink / raw)
  To: Kevin Bowling; +Cc: netdev, freebsd-net
In-Reply-To: <ldtmun$dqj$1@ger.gmane.org>

On Mon, 17 Feb 2014 12:12:36 -0700
Kevin Bowling <kevin.bowling@kev009.com> wrote:

> On 2/17/2014 3:11 AM, Luigi Rizzo wrote:
> > Hi,
> > we have recently made a few extensions to netmap/VALE and put various
> > pieces of code on public repositories, so i thought i'd share the
> > pointers. All the code below runs with equal features and performance
> > on FreeBSD and Linux, and we are trying to upstream it in the relevant
> > projects if possible (as an example, QEMU recently added a netmap backend),
> > at which point some of these clone repositories will become unnecessary.
> 
> Just a thought, maybe this is a good time for The FreeBSD Foundation to 
> reach out to The Linux Foundation for lobbying netmap into their main 
> line kernel.  It would be nice if netmap becomes the de facto UNIX 
> standard for this type of programming (it is vendor neutral and broadly 
> applicable vs other solutions), and avoid not-invented-here APIs like 
> non-blocking I/O went through with all the UNIX flavors.
> 
> Regards,
> Kevin Bowling

You do not understand the role of Linux Foundation.
Lobbying would only serve to annoy the developers.

Netmap was submitted and rejected for a number of issues.
Read the netdev mailing list archives if you want to follow what
is going on.

^ permalink raw reply

* Re: [BUG] unable to handle kernel NULL pointer dereference
From: John @ 2014-02-17 20:12 UTC (permalink / raw)
  To: Trond Myklebust, Borislav Petkov, Linux NFS Mailing List
  Cc: lkml, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org,
	mlindner-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org, J. Bruce Fields
In-Reply-To: <1392571653.44773.4.camel-5lNtUQgoD8Pfa3cDbr2K10B+6BGkLq7r@public.gmane.org>





----- Original Message -----
> From: Trond Myklebust <trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
> To: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>; Linux NFS Mailing List <linux-nfs@vger.kernel.org>
> Cc: John <da_audiophile-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>; lkml <linux-kernel-u79uwXL29TaqPxH82wqD4g@public.gmane.orgg>; "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; "stephen@networkplumber.org" <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>; "mlindner-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org" <mlindner-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>; J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
> Sent: Sunday, February 16, 2014 12:27 PM
> Subject: Re: [BUG] unable to handle kernel NULL pointer dereference
> 
> Please ensure that you post to the linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org when
> reporting NFS and RPC related bugs.
>  
> Does the following patch help?
> 


Trond.  Yes, your patch fixes the regression for me; tested on v3.13.3,  I do not know the process by which patches get into the next stable release (minor version).  My hope is that once peer-reviewed, this patch gets into the 3.13.4 and since the 3.12 series is not EOL yet, into 3.12.12 as well.  Thank you for the time and effort!
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] bonding: fix arp requests sends with isolated routes
From: David Miller @ 2014-02-17 19:56 UTC (permalink / raw)
  To: f.cachereul; +Cc: fubar, vfalico, andy, netdev
In-Reply-To: <52FE3D5B.6060103@alphalink.fr>

From: François Cachereul <f.cachereul@alphalink.fr>
Date: Fri, 14 Feb 2014 16:59:23 +0100

> Make arp_send_all() try to send arp packets through slave devices event
> if no route to arp_ip_target is found. This is useful when the route
> is in an isolated routing table with routing rule parameters like oif or
> iif in which case ip_route_output() return an error.
> Thus, the arp packet is send without vlan and with the bond ip address
> as sender.
> 
> Signed-off-by: François CACHEREUL <f.cachereul@alphalink.fr>
> ---
> This previously worked, the problem was added in 2.6.35 with vlan 0
> added by default when the module 8021q is loaded. Before that no route
> lookup was done if the bond device did not have any vlan. The problem
> now exists event if the module 8021q is not loaded.

I don't like this at all, you're trying to paper over the fact that we
can't set the flow key correctly at this point.

Just assuming the route might be there and trying anyways is not really
acceptable in my opinion.  There's a reason we do a route lookup at all.

^ permalink raw reply

* Re: [PATCH net-next v2] IPv6: enable bind() to assign an anycast address
From: François-Xavier Le Bail @ 2014-02-17 19:52 UTC (permalink / raw)
  To: David Miller
  Cc: kuznet@ms2.inr.ac.ru, christoph.paasch@uclouvain.be,
	hannes@stressinduktion.org, netdev@vger.kernel.org,
	eric.dumazet@gmail.com
In-Reply-To: <20140217.144858.1324303687260941756.davem@davemloft.net>





----- Original Message -----
> From: David Miller <davem@davemloft.net>
> To: fx.lebail@yahoo.com
> Cc: kuznet@ms2.inr.ac.ru; christoph.paasch@uclouvain.be; hannes@stressinduktion.org; netdev@vger.kernel.org; eric.dumazet@gmail.com
> Sent: Monday, February 17, 2014 8:48 PM
> Subject: Re: [PATCH net-next v2] IPv6: enable bind() to assign an anycast address
> 
> From: François-Xavier Le Bail <fx.lebail@yahoo.com>
> 
> Date: Mon, 17 Feb 2014 11:42:45 -0800 (PST)
> 
>>  If I understand well the reviews, no change was ask for this patch.
>>  The sysctl was asked in case of patch for TCP.
>>  So, why the status is now "Changes Requested" ? 
> 
> This change is in generic bind() code, therefore it allows binding TCP
> sockets with anycast, therefore you need to make a change.

Understood, thanks.

^ permalink raw reply

* Re: [PATCH] bonding: 802.3ad: make aggregator_identifier bond-private
From: David Miller @ 2014-02-17 19:55 UTC (permalink / raw)
  To: jiri; +Cc: fubar, vfalico, andy, netdev
In-Reply-To: <20140214171350.GC11688@midget.suse.cz>

From: Jiri Bohac <jiri@boha.cz>
Date: Fri, 14 Feb 2014 18:13:50 +0100

> aggregator_identifier is used to assign unique aggregator identifiers
> to aggregators of a bond during device enslaving.
> 
> aggregator_identifier is currently a global variable that is zeroed in
> bond_3ad_initialize().
> 
> This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:
> 
> create bond0
> change bond0 mode to 802.3ad
> enslave eth0 to bond0 		//eth0 gets agg id 1
> enslave eth1 to bond0 		//eth1 gets agg id 2
> create bond1
> change bond1 mode to 802.3ad
> enslave eth2 to bond1		//aggregator_identifier is reset to 0
> 				//eth2 gets agg id 1
> enslave eth3 to bond0 		//eth3 gets agg id 2
> 
> Fix this by making aggregator_identifier private to the bond.
> 
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>

Looks good, and I think this matches what the original author of this
code probably intended.

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH net-next v2] IPv6: enable bind() to assign an anycast address
From: David Miller @ 2014-02-17 19:48 UTC (permalink / raw)
  To: fx.lebail; +Cc: kuznet, christoph.paasch, hannes, netdev, eric.dumazet
In-Reply-To: <1392666165.65245.YahooMailNeo@web125505.mail.ne1.yahoo.com>

From: François-Xavier Le Bail <fx.lebail@yahoo.com>
Date: Mon, 17 Feb 2014 11:42:45 -0800 (PST)

> If I understand well the reviews, no change was ask for this patch.
> The sysctl was asked in case of patch for TCP.
> So, why the status is now "Changes Requested" ? 

This change is in generic bind() code, therefore it allows binding TCP
sockets with anycast, therefore you need to make a change.

^ permalink raw reply

* Re: [PATCH net-next v2] IPv6: enable bind() to assign an anycast address
From: François-Xavier Le Bail @ 2014-02-17 19:42 UTC (permalink / raw)
  To: David Miller, kuznet@ms2.inr.ac.ru
  Cc: christoph.paasch@uclouvain.be, hannes@stressinduktion.org,
	netdev@vger.kernel.org, eric.dumazet@gmail.com
In-Reply-To: <20140217.141949.1387848185062797150.davem@davemloft.net>

> From: David Miller <davem@davemloft.net>

> From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
>>  On Mon, Feb 17, 2014 at 1:32 PM, Christoph Paasch
>>  <christoph.paasch@uclouvain.be> wrote:
>>>  I don't have strong opinions for or against this patch.
>>> 
>>>  I was only involved in the original thread because F-X claimed that
>>>  draft-iab-anycast-arch-implications (now RFC 7094) allows the use of 
> anycast
>>>  addresses for TCP, which is not what RFC 7094 is saying. There is no
>>>  recommendation concerning TCP in the RFC and the situation is rather 
> unclear.
>> 
>>  The same is here.
>> 
>>  Using anycast as source or bind address, why not?
>> 
>>  Use of anycast with TCP? Logically impossible, ergo prohibited.
>>  If someone wants to play with fire, the option can be left hidden behind
>>  a sysctl disabled by default.
> 
> Agreed.

If I understand well the reviews, no change was ask for this patch.
The sysctl was asked in case of patch for TCP.
So, why the status is now "Changes Requested" ? 

^ permalink raw reply

* Re: [REGRESSION v3.14-rc2] NULL dereference in icmp6_send()
From: Theodore Ts'o @ 2014-02-17 19:43 UTC (permalink / raw)
  To: netdev, linux-kernel
In-Reply-To: <20140217185053.GF22833@order.stressinduktion.org>

On Mon, Feb 17, 2014 at 07:50:53PM +0100, Hannes Frederic Sowa wrote:
> At that point the skb does not have a dst attached, so we panic in
> icmp6_send.
> 
> This is fixed here:
> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d94c1f92bbf2c42c5febd68bbea51fffeac90834

Thanks!!

BTW, apologies for the inadvertent share of the photo to my G+ stream.
I had taken the photo using my cell phone, and I was trying to make
sure the URL was publically viewable before I filed the bug report.

					- Ted

^ permalink raw reply

* Re: [PATCH v2] usbnet: remove generic hard_header_len check
From: David Miller @ 2014-02-17 19:36 UTC (permalink / raw)
  To: emilgoode
  Cc: steve.glendinning, oneukum, bjorn, freddy, edumazet, ming.lei,
	paul.gortmaker, jeffrey.t.kirsher, liujunliang_ljl,
	octavian.purdila, linux-usb, netdev, linux-kernel
In-Reply-To: <1392310219-5719-1-git-send-email-emilgoode@gmail.com>

From: Emil Goode <emilgoode@gmail.com>
Date: Thu, 13 Feb 2014 17:50:19 +0100

> This patch removes a generic hard_header_len check from the usbnet
> module that is causing dropped packages under certain circumstances
> for devices that send rx packets that cross urb boundaries.
> 
> One example is the AX88772B which occasionally send rx packets that
> cross urb boundaries where the remaining partial packet is sent with
> no hardware header. When the buffer with a partial packet is of less
> number of octets than the value of hard_header_len the buffer is
> discarded by the usbnet module.
> 
> With AX88772B this can be reproduced by using ping with a packet
> size between 1965-1976.
> 
> The bug has been reported here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=29082
> 
> This patch introduces the following changes:
> - Removes the generic hard_header_len check in the rx_complete
>   function in the usbnet module.
> - Introduces a ETH_HLEN check for skbs that are not cloned from
>   within a rx_fixup callback.
> - For safety a hard_header_len check is added to each rx_fixup
>   callback function that could be affected by this change.
>   These extra checks could possibly be removed by someone
>   who has the hardware to test.
> - Removes a call to dev_kfree_skb_any() and instead utilizes the
>   dev->done list to queue skbs for cleanup.
> 
> The changes place full responsibility on the rx_fixup callback
> functions that clone skbs to only pass valid skbs to the
> usbnet_skb_return function.
> 
> Signed-off-by: Emil Goode <emilgoode@gmail.com>
> Reported-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH next resend] tcp: use zero-window when free_space is low
From: David Miller @ 2014-02-17 19:34 UTC (permalink / raw)
  To: fw; +Cc: netdev, ncardwell, eric.dumazet, ycheng
In-Reply-To: <1392292350-28800-1-git-send-email-fw@strlen.de>

From: Florian Westphal <fw@strlen.de>
Date: Thu, 13 Feb 2014 12:52:30 +0100

>  V1 of this patch was deferred, resending to get discussion going again.
>  Changes since v1:
>   - add reproducer to commit message
> 
>  Unfortunately I couldn't come up with something that has no magic
>  ('allowed >> 4') value.  I chose >>4 (1/16th) because it didn't cause
>  tput limitations in my 'full-mss-sized, steady state' netcat tests.
> 
>  Maybe someone has better idea?

I know this is going to be frustrating, but I've marked this 'deferred'
again.  Please resubmit after the testing and further discussions have
been worked out.

Thank you.

^ permalink raw reply

* Re: [PATCH] irtty-sir.c: Do not set_termios() on irtty_close()
From: David Miller @ 2014-02-17 19:29 UTC (permalink / raw)
  To: tommie; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <52FC87B6.4070001@gannert.se>

From: Tommie Gannert <tommie@gannert.se>
Date: Thu, 13 Feb 2014 08:52:06 +0000

> --- linux-3.12/drivers/net/irda/irtty-sir.c.orig 2014-02-12
> --- 21:36:46.132496089 +0000
> +++ linux-3.12/drivers/net/irda/irtty-sir.c 2014-02-12
> 21:57:21.635843884 +0000
> @@ -521,7 +521,6 @@ static void irtty_close(struct tty_struc
>  	sirdev_put_instance(priv->dev);
>    	/* Stop tty */
> -	irtty_stop_receiver(tty, TRUE);
>  	clear_bit(TTY_DO_WRITE_WAKEUP, &tty->flags);
>  	if (tty->ops->stop)
>  		tty->ops->stop(tty);

This patch has been corrupted by your email client.  Please fix this
up and resubmit, thanks.

^ permalink raw reply

* Re: [PATCH net-next v2] IPv6: enable bind() to assign an anycast address
From: Hannes Frederic Sowa @ 2014-02-17 19:25 UTC (permalink / raw)
  To: David Miller; +Cc: kuznet, christoph.paasch, fx.lebail, netdev, eric.dumazet
In-Reply-To: <20140217.141949.1387848185062797150.davem@davemloft.net>

On Mon, Feb 17, 2014 at 02:19:49PM -0500, David Miller wrote:
> From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Date: Mon, 17 Feb 2014 14:02:02 +0400
> 
> > Hello!
> > 
> > On Mon, Feb 17, 2014 at 1:32 PM, Christoph Paasch
> > <christoph.paasch@uclouvain.be> wrote:
> >> I don't have strong opinions for or against this patch.
> >>
> >> I was only involved in the original thread because F-X claimed that
> >> draft-iab-anycast-arch-implications (now RFC 7094) allows the use of anycast
> >> addresses for TCP, which is not what RFC 7094 is saying. There is no
> >> recommendation concerning TCP in the RFC and the situation is rather unclear.
> > 
> > The same is here.
> > 
> > Using anycast as source or bind address, why not?
> > 
> > Use of anycast with TCP? Logically impossible, ergo prohibited.
> > If someone wants to play with fire, the option can be left hidden behind
> > a sysctl disabled by default.
> 
> Agreed.

If a knob seems necessary I would vote for per address flags on those
anycast addresses (via setsockopt and netlink) so an application can
decide itself if it wants to do so.

Greetings,

  Hannes

^ permalink raw reply

* Fw: [Bug 70681] New: broadcast gre causes oops
From: Stephen Hemminger @ 2014-02-17 19:24 UTC (permalink / raw)
  To: netdev



Begin forwarded message:

Date: Sun, 16 Feb 2014 14:17:44 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 70681] New: broadcast gre causes oops


https://bugzilla.kernel.org/show_bug.cgi?id=70681

            Bug ID: 70681
           Summary: broadcast gre causes oops
           Product: Networking
           Version: 2.5
    Kernel Version: 3.13.2
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: shemminger@linux-foundation.org
          Reporter: ast@domdv.de
        Regression: No

I was trying to use broaddast (ahem, multicast) gre. This repeatably results in
an Oops and a kernel panic:

htpc2 ~ # ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 4074
        inet 10.1.9.61  netmask 255.255.255.0  broadcast 10.1.9.255
        inet6 2001:a60:10b3:c00:201:c0ff:fe13:db43  prefixlen 64  scopeid
0x0<global>
        inet6 fe80::201:c0ff:fe13:db43  prefixlen 64  scopeid 0x20<link>
        inet6 fdf2:e35b:1a0e:2c28:201:c0ff:fe13:db43  prefixlen 64  scopeid
0x0<global>
        inet6 fdf2:e35b:1a0e:2c28::61  prefixlen 64  scopeid 0x0<global>
        ether 00:01:c0:13:db:43  txqueuelen 1000  (Ethernet)
        RX packets 1943144  bytes 403477948 (384.7 MiB)
        RX errors 0  dropped 65686  overruns 0  frame 0
        TX packets 2135358  bytes 367947113 (350.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xe0700000-e0720000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 264059  bytes 16600869 (15.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 264059  bytes 16600869 (15.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

htpc2 ~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.9.1        0.0.0.0         UG    2      0        0 eth0
10.1.9.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
224.0.0.0       0.0.0.0         240.0.0.0       U     10     0        0 eth0
htpc2 ~ # ip tunnel add test mode gre local 10.1.9.61 remote 224.66.66.66 ttl
16
htpc2 ~ # ip addr add 10.0.0.1/24 dev test
htpc2 ~ # ip link set test up



This results instantly in the following Oops (from /dev/pstore):

Oops#1 Part1
<4>R13: ffffffff816569c0 R14: ffff88043e250008 R15: ffffffff8166fc40
<4>FS:  0000000000000000(0000) GS:ffff88043e240000(0000) knlGS:0000000000000000
<4>CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>CR2: 00000000000000a2 CR3: 0000000410f41000 CR4: 00000000001407a0
<4>Stack:
<4> ffff880417fb2840 ffff88042c88a1c0 ffff88043e243dcc ffff8800a1644800
<4> ffffffff816569c0 ffffffffa016b33b 0000000000000012 ffff88042c88a1c0
<4> 0000000000000000 ffffffff816569c0 ffff88042d674000 ffffffffa015c4ac
<4>Call Trace:
<4> <IRQ> 
<4> [<ffffffffa016b33b>] ? ipgre_rcv+0xb4/0xc5 [ip_gre]
<4> [<ffffffffa015c4ac>] ? gre_cisco_rcv+0x3b/0x89 [gre]
<4> [<ffffffffa015c10b>] ? gre_rcv+0x66/0x8e [gre]
<4> [<ffffffff81342222>] ? ip_local_deliver_finish+0x92/0xfc
<4> [<ffffffff81313374>] ? __netif_receive_skb_core+0x612/0x6a5
<4> [<ffffffff813134e8>] ? process_backlog+0x8a/0x140
<4> [<ffffffff81313825>] ? net_rx_action+0xa5/0x1e4
<4> [<ffffffff81040f2e>] ? __do_softirq+0xf1/0x26d
<4> [<ffffffff8104128a>] ? irq_exit+0x35/0x7a
<4> [<ffffffff81020895>] ? smp_apic_timer_interrupt+0x3b/0x46
<4> [<ffffffff813ea60a>] ? apic_timer_interrupt+0x6a/0x70
<4> <EOI> 
<4> [<ffffffff812ee4dd>] ? cpuidle_enter_state+0x43/0xa6
<4> [<ffffffff812ee4d6>] ? cpuidle_enter_state+0x3c/0xa6
<4> [<ffffffff812ee649>] ? cpuidle_idle_call+0x109/0x1e3
<4> [<ffffffff81009b4d>] ? arch_cpu_idle+0x7/0x1a
<4> [<ffffffff8106f2ec>] ? cpu_startup_entry+0x133/0x206
<4>Code: 89 f3 50 44 0f b7 a6 ae 00 00 00 4c 03 a6 c0 00 00 00 41 8b 44 24 10
25 f0 00 00 00 3d e0 00 00 00 75 2c 48 8b 46 58 48 83 e0 fe <80> b8 a2 00 00 00
00 0f 84 53 03 00 00 48 8b 47 18 48 ff 80 48 
<1>RIP  [<ffffffff8137954f>] ip_tunnel_rcv+0x35/0x3d7
<4> RSP <ffff88043e243d68>
<4>CR2: 00000000000000a2
<4>---[ end trace 6a1568a07dacad07 ]---
Oops#1 Part2
<6>gre: GRE over IPv4 demultiplexor driver
<6>ip_gre: GRE over IPv4 tunneling driver
<1>BUG: unable to handle kernel NULL pointer dereference at 00000000000000a2
<1>IP: [<ffffffff8137954f>] ip_tunnel_rcv+0x35/0x3d7
<4>PGD 410f42067 PUD 410f43067 PMD 0 
<4>Oops: 0000 [#1] PREEMPT SMP 
<4>Modules linked in: ip_gre gre bnep autofs4 nls_iso8859_15 nls_cp850 vfat fat
configfs uinput snd_aloop snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi
snd_seq_device fuse tun hid_topseed hid_generic iwldvm led_class mac80211
usbhid cdc_acm snd_hda_codec_hdmi coretemp snd_hda_codec_realtek pcspkr iwlwifi
cfg80211 btusb i915 8250_pci snd_hda_intel i2c_algo_bit intel_agp snd_hda_codec
i2c_i801 intel_gtt r8169 snd_pcm drm_kms_helper snd_page_alloc rtc_cmos mii
iTCO_wdt drm snd_timer snd 8250 agpgart soundcore serial_core bluetooth
uhci_hcd ehci_pci ehci_hcd xhci_hcd usb_storage
<4>CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.2-gentoo-htpc2 #1
<4>Hardware name: CompuLab Intense-PC/Intense-PC, BIOS CR_2.2.0.400 X64
12/12/2013
<4>task: ffff88043c0fd9a0 ti: ffff88043c0fe000 task.ti: ffff88043c0fe000
<4>RIP: 0010:[<ffffffff8137954f>]  [<ffffffff8137954f>]
ip_tunnel_rcv+0x35/0x3d7
<4>RSP: 0018:ffff88043e243d68  EFLAGS: 00010246
<4>RAX: 0000000000000000 RBX: ffff88042c88a1c0 RCX: 0000000000000001
<4>RDX: ffff88043e243dcc RSI: ffff88042c88a1c0 RDI: ffff880417fb2840
<4>RBP: ffff880417fb2840 R08: 0000000000000000 R09: 00000000424242e0
<4>R10: ffff8800a1644a08 R11: ffff8800a1ca9680 R12: ffff880410eae054


The kernel then panics but I don't seem to get the panic reliably written to
/dev/pstore so I can't add it here.

-- 
You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply

* RE: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification
From: Kretschmer, Mathias @ 2014-02-17 19:20 UTC (permalink / raw)
  To: David Miller
  Cc: arend@broadcom.com, sw@simonwunderlich.de, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org
In-Reply-To: <20140217.141403.291320418395122009.davem@davemloft.net>

I see. OK. If that's the proper way to do it, then so be it.  The performance hit should be negligible since to 99% it's all the same etherType.

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, February 17, 2014 20:14
> To: Kretschmer, Mathias
> Cc: arend@broadcom.com; sw@simonwunderlich.de;
> netdev@vger.kernel.org; linux-wireless@vger.kernel.org
> Subject: Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification
> 
> From: "Kretschmer, Mathias" <mathias.kretschmer@fokus.fraunhofer.de>
> Date: Mon, 17 Feb 2014 19:11:05 +0000
> 
> > Will take a look. Thx. Need to check if there is also a way to set the
> > protocol number when using TX_RINGs, where we use one send() call to
> > signal the kernel that a bunch of frames (with potentially different
> > protocol numbers) is ready for consumption.
> 
> You will have to make seperate TX_RING sends() for each cluster where the
> protocol changes.

^ permalink raw reply

* Re: [PATCH net-next v2] IPv6: enable bind() to assign an anycast address
From: David Miller @ 2014-02-17 19:19 UTC (permalink / raw)
  To: kuznet; +Cc: christoph.paasch, hannes, fx.lebail, netdev, eric.dumazet
In-Reply-To: <CAMrnHh5osKyOpmObYmWNswZuxYAc0SYUrmfohkg2GaafKmPK0w@mail.gmail.com>

From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Date: Mon, 17 Feb 2014 14:02:02 +0400

> Hello!
> 
> On Mon, Feb 17, 2014 at 1:32 PM, Christoph Paasch
> <christoph.paasch@uclouvain.be> wrote:
>> I don't have strong opinions for or against this patch.
>>
>> I was only involved in the original thread because F-X claimed that
>> draft-iab-anycast-arch-implications (now RFC 7094) allows the use of anycast
>> addresses for TCP, which is not what RFC 7094 is saying. There is no
>> recommendation concerning TCP in the RFC and the situation is rather unclear.
> 
> The same is here.
> 
> Using anycast as source or bind address, why not?
> 
> Use of anycast with TCP? Logically impossible, ergo prohibited.
> If someone wants to play with fire, the option can be left hidden behind
> a sysctl disabled by default.

Agreed.

^ permalink raw reply

* Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification
From: David Miller @ 2014-02-17 19:14 UTC (permalink / raw)
  To: mathias.kretschmer; +Cc: arend, sw, netdev, linux-wireless
In-Reply-To: <D53252F45158EF44B1DF124FDC9AF2A35AD9E1FB@FEYNMAN.fokus.fraunhofer.de>

From: "Kretschmer, Mathias" <mathias.kretschmer@fokus.fraunhofer.de>
Date: Mon, 17 Feb 2014 19:11:05 +0000

> Will take a look. Thx. Need to check if there is also a way to set
> the protocol number when using TX_RINGs, where we use one send()
> call to signal the kernel that a bunch of frames (with potentially
> different protocol numbers) is ready for consumption.

You will have to make seperate TX_RING sends() for each cluster where
the protocol changes.

^ permalink raw reply

* Re: [REGRESSION v3.14-rc2] NULL dereference in icmp6_send()
From: David Miller @ 2014-02-17 19:13 UTC (permalink / raw)
  To: hannes; +Cc: tytso, netdev, linux-kernel
In-Reply-To: <20140217185053.GF22833@order.stressinduktion.org>

From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 17 Feb 2014 19:50:53 +0100

> At that point the skb does not have a dst attached, so we panic in
> icmp6_send.
> 
> This is fixed here:
> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d94c1f92bbf2c42c5febd68bbea51fffeac90834

Yep I'll get this to Linus soon.

^ permalink raw reply

* Re: netmap, VALE and netmap pipes
From: Kevin Bowling @ 2014-02-17 19:12 UTC (permalink / raw)
  To: freebsd-net; +Cc: netdev
In-Reply-To: <CA+hQ2+gbs9aBneUaDGAnKVoPHspzc=5o+h+f_K=T+Cy8sRxr+w@mail.gmail.com>

On 2/17/2014 3:11 AM, Luigi Rizzo wrote:
> Hi,
> we have recently made a few extensions to netmap/VALE and put various
> pieces of code on public repositories, so i thought i'd share the
> pointers. All the code below runs with equal features and performance
> on FreeBSD and Linux, and we are trying to upstream it in the relevant
> projects if possible (as an example, QEMU recently added a netmap backend),
> at which point some of these clone repositories will become unnecessary.

Just a thought, maybe this is a good time for The FreeBSD Foundation to 
reach out to The Linux Foundation for lobbying netmap into their main 
line kernel.  It would be nice if netmap becomes the de facto UNIX 
standard for this type of programming (it is vendor neutral and broadly 
applicable vs other solutions), and avoid not-invented-here APIs like 
non-blocking I/O went through with all the UNIX flavors.

Regards,
Kevin Bowling

_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

^ permalink raw reply

* RE: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification
From: Kretschmer, Mathias @ 2014-02-17 19:11 UTC (permalink / raw)
  To: David Miller
  Cc: arend@broadcom.com, sw@simonwunderlich.de, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org
In-Reply-To: <20140217.140653.1309552047403078220.davem@davemloft.net>

> > Thought so, as well. But it seems that skb->protocol is not properly
> > set when the packet originates from a packet socket.  And in our case
> > we cannot set it to a fixed etherType in the bind() call since we use
> > three different etherTypes on the same socket.
> 
> So many things break if the skb->protocol isn't set correctly that I would
> consider such SKBs mal-formed.

Agreed.

> You can specify the protocol number in the msghdr passed into the send.

Will take a look. Thx. Need to check if there is also a way to set the protocol number when using TX_RINGs, where  we use one send() call to signal the kernel that a bunch of frames (with potentially different protocol numbers) is ready for consumption.

^ permalink raw reply

* Re: [PATCH] net: add init-regs for of_phy support
From: David Miller @ 2014-02-17 19:11 UTC (permalink / raw)
  To: mark.rutland; +Cc: ben.dooks, f.fainelli, netdev, devicetree, linux-sh
In-Reply-To: <20140217180415.GD19308@e106331-lin.cambridge.arm.com>

From: Mark Rutland <mark.rutland@arm.com>
Date: Mon, 17 Feb 2014 18:04:15 +0000

> If you update the DTs to describe the hardware to the kernel, then the
> kernel can later be updated to handle specific PHYs better. That cannot
> happen if you try to hide information from the kernel by giving it a
> list of arbitrary magic numbers.
> 
> Drivers are the place such things should go. The DT is not a place for
> shoddy bytecode.

+1

^ permalink raw reply

* Re: [PATCH net] gre: add link local route when local addr is any
From: David Miller @ 2014-02-17 19:09 UTC (permalink / raw)
  To: nicolas.dichtel; +Cc: sesse, hannes, itk-intern, netdev
In-Reply-To: <1392643341-4288-1-git-send-email-nicolas.dichtel@6wind.com>

From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 17 Feb 2014 14:22:21 +0100

> This bug was reported by Steinar H. Gunderson and was introduced by commit
> f7cb8886335d ("sit/gre6: don't try to add the same route two times").
> 
> root@morgental:~# ip tunnel add foo mode gre remote 1.2.3.4 ttl 64
> root@morgental:~# ip link set foo up mtu 1468
> root@morgental:~# ip -6 route show dev foo
> fe80::/64  proto kernel  metric 256
> 
> but after the above commit, no such route shows up.
> 
> There is no link local route because dev->dev_addr is 0 (because local ipv4
> address is 0), hence no link local address is configured.
> 
> In this scenario, the link local address is added manually: 'ip -6 addr add
> fe80::1 dev foo' and because prefix is /128, no link local route is added by the
> kernel.
> 
> Even if the right things to do is to add the link local address with a /64
> prefix, we need to restore the previous behavior to avoid breaking userpace.
> 
> Reported-by: Steinar H. Gunderson <sesse@samfundet.no>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [net-next v2 3/3] cfg80211: add MPLS and 802.21 classification
From: David Miller @ 2014-02-17 19:06 UTC (permalink / raw)
  To: mathias.kretschmer; +Cc: arend, sw, netdev, linux-wireless
In-Reply-To: <D53252F45158EF44B1DF124FDC9AF2A35AD9E12C@FEYNMAN.fokus.fraunhofer.de>

From: "Kretschmer, Mathias" <mathias.kretschmer@fokus.fraunhofer.de>
Date: Mon, 17 Feb 2014 17:34:34 +0000

> Thought so, as well. But it seems that skb->protocol is not properly
> set when the packet originates from a packet socket.  And in our
> case we cannot set it to a fixed etherType in the bind() call since
> we use three different etherTypes on the same socket.

So many things break if the skb->protocol isn't set correctly that I
would consider such SKBs mal-formed.

You can specify the protocol number in the msghdr passed into the
send.

^ permalink raw reply

* Re: [PATCH iproute2 v2] iplink_bond: fix parameter value matching
From: Stephen Hemminger @ 2014-02-17 19:00 UTC (permalink / raw)
  To: Michal Kubecek; +Cc: netdev, Ding Tianhong
In-Reply-To: <20140213163159.7F73CE668E@unicorn.suse.cz>

On Thu, 13 Feb 2014 17:31:59 +0100 (CET)
Michal Kubecek <mkubecek@suse.cz> wrote:

> Lookup function get_index() compares argument with table entries
> only up to the length of the table entry so that if an entry
> with lower index is a substring of a later one, earlier entry is
> used even if the argument is equal to the other. For example,
> 
>   ip link set bond0 type bond xmit_hash_policy layer2+3
> 
> sets xmit_hash_policy to 0 (layer2) as this is found before
> "layer2+3" can be checked.
> 
> Use strcmp() to compare whole strings instead.
> 
> v2: look for an exact match only
> 
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>

Applied

^ permalink raw reply

* Re: [patch iproute2 net-next-for-3.13 0/2] iplink: add support for bonding slave
From: Stephen Hemminger @ 2014-02-17 18:57 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: netdev, davem, fubar, vfalico, andy, sfeldma, john.r.fastabend
In-Reply-To: <1390495974-11234-1-git-send-email-jiri@resnulli.us>

On Thu, 23 Jan 2014 17:52:52 +0100
Jiri Pirko <jiri@resnulli.us> wrote:

> Jiri Pirko (2):
>   introduce support for slave info data
>   iplink: add support for bonding slave
> 
>  include/linux/if_link.h | 19 ++++++-----
>  ip/Makefile             |  2 +-
>  ip/ip_common.h          |  4 +++
>  ip/ipaddress.c          | 54 +++++++++++++++++++----------
>  ip/iplink.c             | 21 ++++++++++--
>  ip/iplink_bond_slave.c  | 90 +++++++++++++++++++++++++++++++++++++++++++++++++
>  6 files changed, 160 insertions(+), 30 deletions(-)
>  create mode 100644 ip/iplink_bond_slave.c
> 

Both applied - header was already updated.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox