Stephen Hemminger | 1 Apr 01:02 2010

Re: [Patch] bonding: fix potential deadlock in bond_uninit()

On Wed, 31 Mar 2010 04:28:33 -0700
ebiederm <at> xmission.com (Eric W. Biederman) wrote:

> Amerigo Wang <amwang <at> redhat.com> writes:
> 
> > bond_uninit() is invoked with rtnl_lock held, when it does destroy_workqueue()
> > which will potentially flush all works in this workqueue, if we hold rtnl_lock
> > again in the work function, it will deadlock.
> >
> > So unlock rtnl_lock before calling destroy_workqueue().
> 
> Ouch.  That seems rather rude to our caller, and likely very
> dangerous.
> 
> Is this a deadlock you actually hit, or is this something lockdep
> warned about?
> 
> My gut feel says we need to move the destroy_workqueue into
> the network device destructor.
> 
> Eric

Why is there one workqueue per bond device rather than just one workqueue for
all bonding devices controlled by the module instance? It would be cleaner
on removal and less space and overhead.  I can't see that doing arp/mii or alb
work is high parallel and load activity.
Stephen Hemminger | 1 Apr 01:06 2010

Re: iproute2: silence errors about kernel missing 6rd on "ip tun show".

On Wed, 31 Mar 2010 10:08:54 +0200
Andreas Henriksson <andreas <at> fatal.se> wrote:

> Hello!
> 
> As reported in http://bugs.debian.org/575970 there is currently a warning
> printed for every tunnel when using latest iproute2 on atleast <= 2.6.32
> kernels (missing 6rd?!).
> 
> The attached patch avoids perror when errno is EINVAL, which I assume
> is the way to detect missing 6rd support. A better/cleaner
> method to detect and avoid 6rd when there's no kernel support
> is more then welcome.
> 
> Regards,
> Andreas Henriksson
> 

I will wait (a little while) to see if Alexandre has a preferred alternative.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Stephen Hemminger | 1 Apr 01:08 2010

Re: [PATCH v3 04/12] l2tp: Add ppp device name to L2TP ppp session data

On Wed, 31 Mar 2010 08:43:09 +0100
James Chapman <jchapman <at> katalix.com> wrote:

> Stephen Hemminger wrote:
> > On Tue, 30 Mar 2010 17:17:46 +0100
> > James Chapman <jchapman <at> katalix.com> wrote:
> > 
> >> When dumping L2TP PPP sessions using /proc/net/l2tp, get
> >> the assigned PPP device name from PPP using ppp_dev_name().
> >>
> >> Signed-off-by: James Chapman <jchapman <at> katalix.com>
> >> Reviewed-by: Randy Dunlap <randy.dunlap <at> oracle.com>
> >>
> > 
> > Why is this a necessary API?
> > Why not put it in debugfs if just a debugging tool?
> 
> With the original driver (merged in 2.6.23), some people use horrible
> hacks in scripts to derive info about their L2TP connections from /proc.
> So I was reluctant to move it to debugfs in the new driver. If it is ok
> to move an existing /proc file to debugfs, I'm happy to do so. People
> should obtain such info from their L2TP userspace daemon, or through
> netlink anyway.
> 
> 

Sounds like a good use of sysfs either with attribute or symlink
back to underlying device
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
(Continue reading)

Ben Hutchings | 1 Apr 01:18 2010

Re: [PATCHv3] drivers/net/usb: Add new driver ipheth

On Wed, 2010-03-31 at 21:42 +0200, L. Alberto Giménez wrote:
[...]
> --- /dev/null
> +++ b/drivers/net/usb/ipheth.c
[...]
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/netdevice.h>
> +#include <linux/etherdevice.h>
> +#include <linux/ethtool.h>
> +#include <linux/uaccess.h>

I don't think you need this header.

> +#include <linux/usb.h>
> +#include <linux/workqueue.h>
> +
> +#define USB_VENDOR_APPLE        0x05ac
> +#define USB_PRODUCT_IPHETH     0x1290
> +#define USB_PRODUCT_IPHETH_3G   0x1292
> +#define USB_PRODUCT_IPHETH_3GS  0x1294

Apple doesn't assign device ids to ipheth so either the names are
incorrect or you should get proper device ids.  I believe the Linux
Foundation has a USB vendor id and could assign device ids under that.

> +struct ipheth_device {
(Continue reading)

Greg KH | 1 Apr 01:25 2010
Picon

Re: [PATCHv3] drivers/net/usb: Add new driver ipheth

On Thu, Apr 01, 2010 at 12:18:58AM +0100, Ben Hutchings wrote:
> On Wed, 2010-03-31 at 21:42 +0200, L. Alberto Gim??nez wrote:
> [...]
> > --- /dev/null
> > +++ b/drivers/net/usb/ipheth.c
> [...]
> > +#include <linux/kernel.h>
> > +#include <linux/errno.h>
> > +#include <linux/init.h>
> > +#include <linux/slab.h>
> > +#include <linux/module.h>
> > +#include <linux/netdevice.h>
> > +#include <linux/etherdevice.h>
> > +#include <linux/ethtool.h>
> > +#include <linux/uaccess.h>
> 
> I don't think you need this header.
> 
> > +#include <linux/usb.h>
> > +#include <linux/workqueue.h>
> > +
> > +#define USB_VENDOR_APPLE        0x05ac
> > +#define USB_PRODUCT_IPHETH     0x1290
> > +#define USB_PRODUCT_IPHETH_3G   0x1292
> > +#define USB_PRODUCT_IPHETH_3GS  0x1294
> 
> Apple doesn't assign device ids to ipheth so either the names are
> incorrect or you should get proper device ids.  I believe the Linux
> Foundation has a USB vendor id and could assign device ids under that.

(Continue reading)

Ben Hutchings | 1 Apr 01:26 2010

RE: re-submit2 [ANNOUNCEMENT] NET: usb: sierra_net.c driver

On Wed, 2010-03-31 at 13:58 -0700, Elina Pasheva wrote:
> On Tue, 2010-03-30 at 23:21 -0700, Rory Filer wrote:
> > -----Original Message-----
> > > >
> > > > Applied, thanks.
> > > 
> > > Nevermind, reverted, it doesn't even build.
> > > 
> > > drivers/net/usb/sierra_net.c: In function 'check_ethip_packet':
> > > drivers/net/usb/sierra_net.c:221:3: error: implicit declaration of
> > > function 'deverr'
> > > 
> > > Really, this should never ever happen, and there is simply
> > > no excuse at all for this.
> > 
> > Well actually there is an excuse, but I'm sure you don't want to
> > know what it is. 
> 
> The patch was posted saying it had only been tested on 2.6.33.1.
> There was failure-to-build and boot problems  beyond our control with 2.6.34-rc2.
> Now that 2.6.34-rc3 is available (and we are able to build and boot on our Ubuntu platform)
> I will modify the driver to reflect the fact that deverr is no longer in existence
> and is replaced by another function. I will submit the modified driver tested on 2.6.34-rc3 shortly.

You should be sending patches based on David Miller's net-next-2.6 or
net-2.6 git repository, where he will be applying them.  As this is a
new driver I assume it can go into net-2.6.

> Perhaps we should have waited until the build problem was fixed.

(Continue reading)

Ben Hutchings | 1 Apr 01:28 2010

Re: [PATCHv3] drivers/net/usb: Add new driver ipheth

On Wed, 2010-03-31 at 16:25 -0700, Greg KH wrote:
> On Thu, Apr 01, 2010 at 12:18:58AM +0100, Ben Hutchings wrote:
> > On Wed, 2010-03-31 at 21:42 +0200, L. Alberto Gim??nez wrote:
[...]
> > > +#include <linux/usb.h>
> > > +#include <linux/workqueue.h>
> > > +
> > > +#define USB_VENDOR_APPLE        0x05ac
> > > +#define USB_PRODUCT_IPHETH     0x1290
> > > +#define USB_PRODUCT_IPHETH_3G   0x1292
> > > +#define USB_PRODUCT_IPHETH_3GS  0x1294
> > 
> > Apple doesn't assign device ids to ipheth so either the names are
> > incorrect or you should get proper device ids.  I believe the Linux
> > Foundation has a USB vendor id and could assign device ids under that.
> 
> You mean there is an application on the iphone that sets the device id
> here?  I thought this was the iphone device ids already assigned to
> apple.
[...]

That's why my first suggestion was that the names are incorrect; they
should probably include IPHONE not IPHETH.

Ben.

--

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
(Continue reading)

Glen Turner | 1 Apr 01:42 2010
Picon

Re: UDP path MTU discovery

On Thu, 2010-03-25 at 20:26 -0700, David Miller wrote:
> We already provide this information.
> 
> The socket ends up with EMSGSIZE in it's error queue, so the next time
> the application does I/O it sees that error immediately from the
> read/write call and thus knows that path MTU arrived.

Thanks David.

Does select() return from its blocking so the application can make
use of this indication immediately, rather than after the
application's exponentially-increasing wait?

Is an incoming ICMP the only cause of EMSGSIZE?  That is, can an
application safely retransmit immediately?

--

-- 
 Glen Turner
 www.gdt.id.au/~gdt

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Glen Turner | 1 Apr 01:43 2010
Picon

Re: UDP path MTU discovery

On Mon, 2010-03-29 at 10:01 -0700, Rick Jones wrote:

> But which of the last N datagrams sent by the application should be retained for 
> retransmission?  It could be scores if not hundreds of datagrams depending on 
> the behaviour of the application and the latency to the narrow part of the network.

We don't need that sort of exotica from the kernel.  The applications
have to be prepared to retransmit lost packets in any case.

What we need is an API for an instant notification that a ICMP Packet
Too Big message has arrived concerning the socket.

Then the application simply retransmits immediately, without adding
to the exponential backoff penalty which the application maintains.
The application maintain a overall packet-transmitted limit to prevent
a DoS.

>From this application behaviour the kernel sees a stream of packets
it can use for UDP Path MTU Discovery (paced at the RTT, so not
contributing to congestion collapse). That stream halts when the
first packet makes it to the end system.

As for David Miller's rant, the applications currently have no choice
but to "do it stupidly" as the kernel doesn't pass enough information
for user space to do it intelligently.  If the kernel passed user space
the same indication as TCP gets, then we could -- and would -- do it
right.

Re-writing the applications to take advantage of the API is no great
shakes -- there aren't many of them, they are written by people with
(Continue reading)

Glen Turner | 1 Apr 01:57 2010
Picon

Re: UDP path MTU discovery

On Sun, 2010-03-28 at 10:41 +0200, Andi Kleen wrote:

> It means though that all IPv6 UDP applications essentially have
> to implement path mtu discovery support (which is non trivial) 

It is trivial from the applications point of view to let the
kernel find the UDP Path MTU. We just need more information
from the kernel as to when it would like to see those packets
(ie, for performance we'd like to feed in the packet to re-send
as soon as the ICMP Packet Too Big arrives for the previous
packet).

> Will be likely a long time until they're all fixed.

There's no need to make that assumption.  We'd very much like
transactional UDP protocols to work well in advanced networks.
The other choices -- holding down millions of TCP sockets,
or using new protocols (and there are competing proposals) --
don't exactly fill our operations teams with confidence.

We'd very much like to use UDP were we can and something else
where we must.

> Seems like a big hole not considered by the IPv6 designers?

Yeah. The sockets API for IPv6 required an additional feature that
the IETF did not foresee.

--

-- 
 Glen Turner
(Continue reading)


Gmane