* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: David Miller @ 2009-08-10 4:52 UTC (permalink / raw)
To: ebiederm; +Cc: herbert, paul.moore, netdev
In-Reply-To: <m1k51gqmlp.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 06 Aug 2009 21:22:42 -0700
> David Miller <davem@davemloft.net> writes:
>
>> From: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Fri, 7 Aug 2009 10:22:44 +1000
>>
>>> tun: Extend RTNL lock coverage over whole ioctl
>>>
>>> As it is, parts of the ioctl runs under the RTNL and parts of
>>> it do not. The unlocked section is still protected by the BKL,
>>> but there can be subtle races. For example, Eric Biederman and
>>> Paul Moore observed that if two threads tried to create two tun
>>> devices on the same file descriptor, then unexpected results
>>> may occur.
>>>
>>> As there isn't anything in the ioctl that is expected to sleep
>>> indefinitely, we can prevent this from occurring by extending
>>> the RTNL lock coverage.
>>>
>>> This also allows to get rid of the BKL.
>>>
>>> Finally, I changed tun_get_iff to take a tun device in order to
>>> avoid calling tun_put which would dead-lockt as it also tries to
>>> take the RTNL lock.
>>>
>>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>>
>> This looks good after a quick audit, Eric what say you?
>
> Looks good to me.
Applied, thanks everyone.
^ permalink raw reply
* Re: [patch 1/1] atlx: strncpy does not null terminate string
From: David Miller @ 2009-08-10 4:52 UTC (permalink / raw)
To: akpm; +Cc: jcliburn, csnook, jie.yang, netdev, roel.kluin
In-Reply-To: <200908062306.n76N6ug6007294@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Thu, 06 Aug 2009 16:06:56 -0700
> From: Roel Kluin <roel.kluin@gmail.com>
>
> strlcpy() will always null terminate the string.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [patch 1/1] irda: fix read buffer overflow
From: David Miller @ 2009-08-10 4:53 UTC (permalink / raw)
To: akpm; +Cc: samuel, netdev, roel.kluin
In-Reply-To: <200908062306.n76N63iE005813@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Thu, 06 Aug 2009 16:06:03 -0700
> From: Roel Kluin <roel.kluin@gmail.com>
>
> io[i] is read before the bounds check on i, order should be reversed.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] ixgbe: Pass rx_ring directly in ixgbe_configure_srrctl()
From: David Miller @ 2009-08-10 4:53 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20090806230514.28347.51172.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 06 Aug 2009 16:05:23 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Instead of passing the register index of the corresponding rx_ring and find
> the way back to get to corresponding rx_ring in ixgbe_configure_srrctl(),
> simplify the function ixgbe_configure_srrctl() by passing the rx_ring into
> it. Then the register index for that rx_ring is already available from
> rx_ring->reg_idx.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] ixgbe: Disable packet split only on FCoE queues in 82599
From: David Miller @ 2009-08-10 4:53 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20090806230544.28347.97373.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 06 Aug 2009 16:05:44 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> For 82599, packet split has to be disabled for FCoE direct data placement.
> However, this is only required on received queues allocated for FCoE. This
> patch adds a per ring flags to indicate if packet split is disabled on a
> per queue basis, particularly for FCoE, as packet split must be disabled
> for large receive using direct data placement (DDP).
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [Resent][PATCH 1/2] inet6: Conversion from u8 to int
From: Rémi Denis-Courmont @ 2009-08-10 6:33 UTC (permalink / raw)
To: ext Gerrit Renker; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1249841569-23706-2-git-send-email-gerrit@erg.abdn.ac.uk>
On Sunday 09 August 2009 21:12:48 ext Gerrit Renker wrote:
> case IPV6_TCLASS:
> val = np->tclass;
> - if (val < 0)
> - val = 0;
> break;
According to the IPv6 API RFC, if val is -1, the kernel shall pick the default
value (which is zero). Are you sure this still works??
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [PATCH] macvlan: add tap device backend
From: Patrick McHardy @ 2009-08-10 6:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev, Stephen Hemminger, davem, Michael S. Tsirkin, Herbert Xu,
Or Gerlitz, Fischer, Anna, bridge, linux-kernel,
Edge Virtual Bridging
In-Reply-To: <1249595428-21594-1-git-send-email-arnd@arndb.de>
Arnd Bergmann wrote:
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> new file mode 100644
> index 0000000..d99bfc0
> --- /dev/null
> +++ b/drivers/net/macvtap.c
> +static int macvtap_open(struct inode *inode, struct file *file)
> +{
> + struct net *net = current->nsproxy->net_ns;
> + int ifindex = iminor(inode);
> + struct net_device *dev = dev_get_by_index(net, ifindex);
> + int err;
> +
> + err = -ENODEV;
> + if (!dev)
> + goto out1;
> +
> + file->private_data = netdev_priv(dev);
> + err = 0;
> +out1:
> + return err;
> +}
macvlan will remove all macvlan/vtap devices when the underlying
device in unregistered, at which time you need to release the
device references you're holding. I'd suggest to change the
macvlan_device_event() handler to use
vlan->dev->rtnl_link_ops->dellink(vlan->dev)
instead of macvlan_dellink() so the macvtap_dellink callback
is invoked.
^ permalink raw reply
* Re: [Resent][PATCH 1/2] inet6: Conversion from u8 to int
From: ext Gerrit Renker @ 2009-08-10 7:08 UTC (permalink / raw)
To: R?mi Denis-Courmont; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <200908100933.11676.remi.denis-courmont@nokia.com>
Quoting R?mi Denis-Courmont:
| On Sunday 09 August 2009 21:12:48 ext Gerrit Renker wrote:
| > case IPV6_TCLASS:
| > val = np->tclass;
| > - if (val < 0)
| > - val = 0;
| > break;
|
| According to the IPv6 API RFC, if val is -1, the kernel shall pick the default
| value (which is zero). Are you sure this still works??
Yes exactly that is the point, but it does not work since np->tclass is __u8, i.e.
val will not be negative here.
What you refer to is done in the second patch and in the combination I think it
will work, please have a look.
^ permalink raw reply
* Re: [PATCH v2] netfilter: ebtables: Use %pM conversion specifier
From: Patrick McHardy @ 2009-08-10 8:11 UTC (permalink / raw)
To: Tobias Klauser
Cc: bart.de.schuymer, shemminger, davem, netfilter-devel, netdev
In-Reply-To: <1247729151-6210-1-git-send-email-klto@zhaw.ch>
Tobias Klauser wrote:
> ebt_log uses its own implementation of print_mac to print MAC addresses.
> This patch converts it to use the %pM conversion specifier for printk.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] macvlan: add tap device backend
From: Michael S. Tsirkin @ 2009-08-10 8:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev, Patrick McHardy, Stephen Hemminger, David S. Miller,
Herbert Xu, Or Gerlitz, Fischer, Anna, bridge, linux-kernel,
Edge Virtual Bridging
In-Reply-To: <200908092042.24686.arnd@arndb.de>
On Sun, Aug 09, 2009 at 08:42:24PM +0000, Arnd Bergmann wrote:
> On Sunday 09 August 2009 08:02:16 Michael S. Tsirkin wrote:
> > On Thu, Aug 06, 2009 at 09:50:28PM +0000, Arnd Bergmann wrote:
> > > * The same framework in macvlan can be used to add a third backend
> > > into a future kernel based virtio-net implementation.
> >
> > Could you split the patches up, to make this last easier?
> > patch 1 - export framework
> > patch 2 - code using it
>
> Sure, will do.
>
> > > +/* Get packet from user space buffer */
> > > +static ssize_t macvtap_get_user(struct macvtap_dev *vtap,
> > > + const struct iovec *iv, size_t count,
> > > + int noblock)
> > > +{
> > > + struct sk_buff *skb;
> > > + size_t len = count;
> > > +
> > > + if (unlikely(len < ETH_HLEN))
> > > + return -EINVAL;
> > > +
> > > + skb = alloc_skb(NET_IP_ALIGN + len, GFP_KERNEL);
> > > +
> > > + if (!skb) {
> > > + vtap->m.dev->stats.rx_dropped++;
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + skb_reserve(skb, NET_IP_ALIGN);
> > > + skb_put(skb, count);
> > > +
> > > + if (skb_copy_datagram_from_iovec(skb, 0, iv, 0, len)) {
> > > + vtap->m.dev->stats.rx_dropped++;
> > > + kfree_skb(skb);
> > > + return -EFAULT;
> > > + }
> > > +
> > > + skb_set_network_header(skb, ETH_HLEN);
> > > + skb->dev = vtap->m.lowerdev;
> > > +
> > > + macvlan_start_xmit(skb, vtap->m.dev);
> > > +
> > > + return count;
> > > +}
> >
> > With tap, we discovered that not limiting the number of outstanding
> > skbs hurts UDP performance. And the solution was to limit
> > the number of outstanding packets - with hacks to work around
> > the fact that userspace .
>
> Something seems to be missing in your last sentence here.
Most userspace does not seem to implement software flow control for UDP,
even though it probably should.
> My driver OTOH is also missing any sort of flow control in both
> RX and TX direction ;) For RX, there should probably just be
> a limit of frames that get buffered in the ring.
>
> For TX, I guess there should be a way to let the packet
> scheduler handle this and give us a chance to block and
> unblock at the right time. I haven't found out yet how to
> do that.
>
> Would it be enough to check the dev_queue_xmit() return
> code for NETDEV_TX_BUSY?
>
> How would I get notified when it gets free again?
You can do this by creating a socket. Look at how tun does
this now.
> > > + ret = skb_copy_datagram_iovec(skb, 0, iv, len);
> > > +
> > > + vtap->m.dev->stats.rx_packets++;
> > > + vtap->m.dev->stats.rx_bytes += len;
> >
> > where does atomicity guarantee for these counters come from?
>
> AFAIK, we never do for any driver. They are statistics only and
> need not be 100% correct, so the networking stack goes for
> lower overhead and 99.9% correct.
>
> > > +static ssize_t macvtap_aio_read(struct kiocb *iocb, const struct iovec *iv,
> > > + unsigned long count, loff_t pos)
> > > +{
> > > + struct file *file = iocb->ki_filp;
> > > + struct macvtap_dev *vtap = file->private_data;
> > > + DECLARE_WAITQUEUE(wait, current);
> > > + struct sk_buff *skb;
> > > + ssize_t len, ret = 0;
> > > +
> > > + if (!vtap)
> > > + return -EBADFD;
> > > +
> > > + len = iov_length(iv, count);
> > > + if (len < 0) {
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> > > +
> > > + add_wait_queue(&vtap->wait, &wait);
> > > + while (len) {
> > > + current->state = TASK_INTERRUPTIBLE;
> > > +
> > > + /* Read frames from the queue */
> > > + if (!(skb=skb_dequeue(&vtap->readq))) {
> > > + if (file->f_flags & O_NONBLOCK) {
> > > + ret = -EAGAIN;
> > > + break;
> > > + }
> > > + if (signal_pending(current)) {
> > > + ret = -ERESTARTSYS;
> > > + break;
> > > + }
> > > + /* Nothing to read, let's sleep */
> > > + schedule();
> > > + continue;
> > > + }
> > > + ret = macvtap_put_user(vtap, skb, (struct iovec *) iv, len);
> >
> > Don't cast away the constness. Instead, fix macvtap_put_user
> > to used skb_copy_datagram_const_iovec which does not modify the iovec.
>
> Ah, good catch. I had copied that from the tun driver before you
> fixed it there and failed to fix it the right way when I adapted
> it for the new interface.
>
> Thanks for the review,
>
> Arnd <><
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Changes to support the "-f" option of ethtool.
From: Ajit Khaparde @ 2009-08-10 9:04 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, jgarzik, netdev
In-Reply-To: <20090805.131723.120803503.davem@davemloft.net>
On 05/08/09 13:17 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Wed, 05 Aug 2009 14:06:07 +0100
>
> > request_firmware() is meant for loading firmware that is stored in
> > volatile memory (RAM) on the device and therefore needs to be installed
> > on the host.
> >
> > When the firmware is stored in flash on the device, updates only need to
> > be used once, and there should be no need to install them on the host.
> > So request_firmware() does not seem suitable.
> >
> > I believe the ethtool EEPROM commands were meant for updating firmware
> > on NICs. Although they assume random access and so are unsuitable for
> > flash-based firmware, they might be a better model for adding flash
> > update commands. However, this command set is already available through
> > the MTD device class, which is what we use for firmware update as far as
> > possible. Not only does this allow for an arbitrary number of separate
> > firmware partitions per network device, but it can be used in an
> > out-of-tree driver for older kernel versions.
>
> I mostly agree with this. Either use MTD or create an ethtool
> operation that explicitly specifies the file to flash onto the
> chip. If you want, I suppose you can take no explicit file
> specification to mean "whatever firmware was loaded into the
> chip by the driver and is running right now"
Thanks. I will go with the ethtool option which would also take the
filename and flash it onto the chip using the request_firmware() path.
-Ajit
>
> --
> 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 5/6] [NET] ixp2000/enp2611: don't set non-existent member get_stats
From: Uwe Kleine-König @ 2009-08-10 9:40 UTC (permalink / raw)
To: David Miller
Cc: tglx, linux-kernel, linux-rt-users, linux, dbaryshkov, kernel,
netdev
In-Reply-To: <20090809.214906.143672876.davem@davemloft.net>
Hello,
On Sun, Aug 09, 2009 at 09:49:06PM -0700, David Miller wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Date: Fri, 7 Aug 2009 22:42:40 +0200
>
> > This fixes a build failure for 2.6.31-rc5 (ARCH=arm, ixp2000_defconfig):
> >
> > CC drivers/net/ixp2000/enp2611.o
> > drivers/net/ixp2000/enp2611.c: In function 'enp2611_init_module':
> > drivers/net/ixp2000/enp2611.c:213: error: 'struct net_device' has no member named 'get_stats'
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> This is far from the way to fix this, unfortunately.
>
> We need to find a way to propagate this assignment into
> the netdev_ops method vector instead.
Yes, I tried that, but stopped when I saw it's declared const. I don't
know if this is required. If yes then the only way to fix it is to add
a platform callback that is called if non-NULL.
I don't want to invest time here without a word by the maintainers
though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Rene Mayrhofer @ 2009-08-10 10:28 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <4A7A0CBE.4020304@ring3k.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike McCormack wrote:
> Rene Mayrhofer wrote:
>
>> What would be the simplest change to stop disabling phy when the last
>> device goes down?
>
> Commenting out the following line should stop all the phys from powering off:
>
> sky2_phy_power_down(hw, port);
>
> If you have a chance, please test "sky2: Add a mutex around ethtools operations" also.
> it probably won't fix the problem you're seeing, but you never know...
It seems that hardware is faulty, although in a very "interesting" way.
We tried changing the "slot" modules with 4 NICs each, which did not
change matters. However, another similar hardware appliance works. I am
thus not sure which component is at fault here, as (parts of) the NICs
were changed. Maybe the interrupt controller is weird on the "faulty"
box? ACPI issues? If anybody wants to track this any further, I am still
willing to test patches.
best regards,
Rene
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp/9moACgkQq7SPDcPCS979XACfRD6e5ixtX3oPiQCpC78nowO4
TH4Anivuo53VZsRO9LAIDIg7zYurW8UI
=MwmU
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] include/netdevice.h: fix nanodoc mismatch
From: Wolfram Sang @ 2009-08-10 11:04 UTC (permalink / raw)
To: netdev; +Cc: trivial, Wolfram Sang, David S. Miller
nanodoc was missing an ndo_-prefix.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
---
include/linux/netdevice.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d4a4d98..277f1c2 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -557,7 +557,7 @@ struct netdev_queue {
* Callback uses when the transmitter has not made any progress
* for dev->watchdog ticks.
*
- * struct net_device_stats* (*get_stats)(struct net_device *dev);
+ * struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
* Called when a user wants to get the network device usage
* statistics. If not defined, the counters in dev->stats will
* be used.
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH] lmc: Read outside array bounds
From: Roel Kluin @ 2009-08-10 11:29 UTC (permalink / raw)
To: David Miller; +Cc: khc, netdev, akpm
In-Reply-To: <20090809.212725.218498673.davem@davemloft.net>
If dev_alloc_skb() fails on the first iteration of the allocation loop,
then we end up writing before the start of the array.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
>>> First of all, if we allocated at least one buffer we should
>>> mark the last one in the code right after this loop.
>>>
>>> Second of all, we should purge the TX skbs in the next
>>> loop even if we could not allocate even one RX buffer.
>>>
>>> The thing to do is probably to guard the set of "[i-1]" RX ring
>>> accesses with a "if (i != 0)" check.
>> Forgot a bit about this one, but I hope this is what you meant?
>
> It's not correct to limit the TX ring loop by how many RX
> ring buffers we've been able to successfully allocate,
> that doesn't make any sense.
>
> I'm talking about the second loop which you unexplainably
> changed to "for (j = 0; j < i; ..."
Ok, I apparently completely misunderstood. One remaining question is whether
the base address should still be written if i is 0?
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index 45b1822..8b61660 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -1897,11 +1897,12 @@ static void lmc_softreset (lmc_softc_t * const sc) /*fold00*/
/*
* Sets end of ring
*/
- sc->lmc_rxring[i - 1].length |= 0x02000000; /* Set end of buffers flag */
- sc->lmc_rxring[i - 1].buffer2 = virt_to_bus (&sc->lmc_rxring[0]); /* Point back to the start */
+ if (i != 0) {
+ sc->lmc_rxring[i - 1].length |= 0x02000000; /* Set end of buffers flag */
+ sc->lmc_rxring[i - 1].buffer2 = virt_to_bus(&sc->lmc_rxring[0]); /* Point back to the start */
+ }
LMC_CSR_WRITE (sc, csr_rxlist, virt_to_bus (sc->lmc_rxring)); /* write base address */
-
/* Initialize the transmit rings and buffers */
for (i = 0; i < LMC_TXDESCS; i++)
{
^ permalink raw reply related
* [PATCH net-2.6] can: Use WARN_ONCE() instead of BUG_ON() for sanity check in receive path
From: Oliver Hartkopp @ 2009-08-10 11:27 UTC (permalink / raw)
To: David Miller; +Cc: Urs Thuermann, Luotao Fu, Michael Olbrich, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
To ensure a proper handling of CAN frames transported in skbuffs some checks
need to be performed at receive time.
As stated by Michael Olbrich and Luotao Fu BUG_ON() might be to restrictive.
This is right as we can just drop the non conform skbuff and the Kernel can
continue working.
This patch replaces the BUG_ON() with a WARN_ONCE() so that the system remains
healthy but we made the problem visible (once).
Additionally it changes the return values to the common NET_RX_xxx constants.
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
CC: Michael Olbrich <m.olbrich@pengutronix.de>
CC: Luotao Fu <l.fu@pengutronix.de>
---
[-- Attachment #2: af_can_convert_bug_to_warn.patch --]
[-- Type: text/x-patch, Size: 1050 bytes --]
diff --git a/net/can/af_can.c b/net/can/af_can.c
index e733725..ef1c43a 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -651,12 +651,16 @@ static int can_rcv(struct sk_buff *skb, struct net_device *dev,
struct can_frame *cf = (struct can_frame *)skb->data;
int matches;
- if (dev->type != ARPHRD_CAN || !net_eq(dev_net(dev), &init_net)) {
- kfree_skb(skb);
- return 0;
- }
+ if (!net_eq(dev_net(dev), &init_net))
+ goto drop;
- BUG_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8);
+ if (WARN_ONCE(dev->type != ARPHRD_CAN ||
+ skb->len != sizeof(struct can_frame) ||
+ cf->can_dlc > 8,
+ "PF_CAN: dropped non conform skbuf: "
+ "dev type %d, len %d, can_dlc %d\n",
+ dev->type, skb->len, cf->can_dlc))
+ goto drop;
/* update statistics */
can_stats.rx_frames++;
@@ -682,7 +686,11 @@ static int can_rcv(struct sk_buff *skb, struct net_device *dev,
can_stats.matches_delta++;
}
- return 0;
+ return NET_RX_SUCCESS;
+
+drop:
+ kfree_skb(skb);
+ return NET_RX_DROP;
}
/*
^ permalink raw reply related
* [PATCH] netdevice: Correct function pointer name in comment
From: Tobias Klauser @ 2009-08-10 11:28 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Tobias Klauser
The function pointer in struct net_device_ops is called ndo_get_stats.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
include/linux/netdevice.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d4a4d98..277f1c2 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -557,7 +557,7 @@ struct netdev_queue {
* Callback uses when the transmitter has not made any progress
* for dev->watchdog ticks.
*
- * struct net_device_stats* (*get_stats)(struct net_device *dev);
+ * struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
* Called when a user wants to get the network device usage
* statistics. If not defined, the counters in dev->stats will
* be used.
--
1.6.0.4
^ permalink raw reply related
* RE: [Bridge] [PATCH] macvlan: add tap device backend
From: Fischer, Anna @ 2009-08-10 12:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Congdon (UC Davis), drobbins@funtoo.org,
herbert@gondor.apana.org.au, mst@redhat.com,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, ogerlitz@voltaire.com,
evb@yahoogroups.com, davem@davemloft.net
In-Reply-To: <200908080005.32443.arnd@arndb.de>
> Subject: Re: [Bridge] [PATCH] macvlan: add tap device backend
>
> On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
> > Responding to Daniel's questions...
>
> Thanks for the detailed responses. I'll add some more about the
> specifics of the macvlan implementation that differs from the
> bridge based VEPA implementation.
>
> > > Is this new interface to be used within a virtual machine or
> > > container, on the master node, or both?
> >
> > It is really an interface to a new type of virtual switch. When
> > you create virtual network, I would imagine it being a new mode
> > of operation (bridge, NAT, VEPA, etc).
>
> I think the question was whether the patch needs to applied in the
> host or the guest. Both the implementation that you and Anna did
> and the one that I posted only apply to the *host* (master node),
> the virtual machine does not need to know about it.
>
> > > What interface(s) would need to be configured for a single virtual
> > > machine to use VEPA to access the network?
> >
> > It would be the same as if that machine were configure to use a
> > bridge to access the network, but the bridge mode would be different.
>
> Right, with the bridge based VEPA, you would set up a kvm guest
> or a container with the regular tools, then use the sysfs interface
> to put the bridge device into VEPA mode.
>
> With the macvlan based mode, you use 'ip link' to add a new tap
> device to an external network interface and not use a bridge at
> all. Then you configure KVM to use that tap device instead of the
> regular bridge/tap setup.
>
> > > What are the current flexibility, security or performance
> limitations
> > > of tun/tap and bridge that make this new interface necessary or
> > > beneficial?
> >
> > If you have VMs that will be communicating with one another on
> > the same physical machine, and you want their traffic to be
> > exposed to an in-line network device such as a application
> > firewall/IPS/content-filter (without this feature) you will have
> > to have this device co-located within the same physical server.
> > This will use up CPU cycles that you presumable purchased to run
> > applications, it will require a lot of consistent configuration
> > on all physical machines, it could invoke potentially a lot of
> > software licensing, additional cost, etc.. Everything would
> > need to be replicated on each physical machine. With the VEPA
> > capability, you can leverage all this functionality in an
> > external network device and have it managed and configured in
> > one place. The external implementation is likely a higher
> > performance, silicon based implementation. It should make it
> > easier to migrate machines from one physical server to another
> > and maintain the same network policy enforcement.
>
> It's worth noting that depending on your network connectivity,
> performance is likely to go down significantly with VEPA over the
> existing bridge/tap setup, because all frames have to be sent
> twice through an external wire that has a limited capacity, so you may
> lose inter-guest bandwidth and get more latency in many cases, while
> you free up CPU cycles. With the bridge based VEPA, you might not
> even gain many cycles because much of the overhead is still there.
> On the cost side, external switches can also get quite expensive
> compared to x86 servers.
>
> IMHO the real win of VEPA is on the management side, where you can
> use a single set of tool for managing the network, rather than
> having your network admins deal with both the external switches
> and the setup of linux netfilter rules etc.
>
> The macvlan based VEPA has the same features as the bridge based
> VEPA, but much simpler code, which allows a number of shortcuts
> to save CPU cycles.
I am not yet convinced that the macvlan based VEPA would be significantly
better from a performance point-of-view. Really, once you have
implemented all the missing bits and pieces to make the macvlan
driver a VEPA-compatible device, the code path for packet processing
will be very similar. Also, I think you have to keep in mind that,
ultimately, if a user is seriously concerned about high performance,
then they would go for a hardware-based solution, e.g. a SRIOV NIC
with VEPA capabilities. Once you have made the decision for a software-
based approach, tiny performance differences should not have such a
big impact, and so I don't think that this should influence too much
the design decision on where VEPA capabilities should be placed in
the kernel.
If you compare macvtap with traditional QEMU networking interfaces that
are typically used in current bridged setups, then yes, performance will be
different. However, I think that this is not necessarily a fair
comparison, and the performance difference does not come from the
bridge being slow, but simply because you have implemented a better
solution to connect a virtual interface to a backend device that
can be assigned to a VM. There is no reason why you could not do this
for a bridge port as well.
Anna
^ permalink raw reply
* RE: [PATCH][RFC] net/bridge: add basic VEPA support
From: Fischer, Anna @ 2009-08-10 13:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: 'Stephen Hemminger', Fischer, Anna,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
evb@yahoogroups.com, davem@davemloft.net, kaber@trash.net,
adobriyan@gmail.com, Paul Congdon (UC Davis)
In-Reply-To: <200908081149.27409.arnd@arndb.de>
> Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
>
> On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
> > As I understand the macvlan code, it currently doesn't allow two VMs
> on the
> > same machine to communicate with one another.
>
> There are patches to do that. I think if we add that, there should be
> a way to choose the behavior between either bridging between the
> guests or VEPA.
If you implement this direct bridging capability between local VMs for
macvlan, then would this not break existing applications that currently
use it? It would be quite a significant change to how macvlan works
today. I guess, ideally, you would want to have macvlan work in
separate modes, e.g. traditional macvlan, bridging, and VEPA.
> > I could imagine a hairpin mode on the adjacent bridge making this
> > possible, but the macvlan code would need to be updated to filter
> > reflected frames so a source did not receive his own packet.
>
> Right, I missed this point so far. I'll follow up with a patch
> to do that.
Can you maybe point me to the missing patches for macvlan that you
have mentioned in other emails, and the one you mention above?
E.g. enabling multicast distribution and allowing local bridging etc.
I could not find any of those in the archives. Thanks.
> > I could imagine this being done as well, but to also
> > support selective multicast usage, something similar to the bridge
> > forwarding table would be needed. I think putting VEPA into a new
> driver
> > would cause you to implement many things the bridge code already
> supports.
> > Given that we expect the bridge standard to ultimately include VEPA,
> and the
> > new functions are basic forwarding operations, it seems to make most
> sense
> > to keep this consistent with the bridge module.
>
> This is the interesting part of the discussion. The bridge and macvlan
> drivers certainly have an overlap in functionality and you can argue
> that you only need one. Then again, the bridge code is a little crufty
> and we might not want to add much more to it for functionality that can
> be implemented in a much simpler way elsewhere. My preferred way would
> be to use bridge when you really need 802.1d MAC learning, netfilter-
> bridge
> and STP, while we put the optimizations for stuff like VMDq, zero-copy
> and multiqueue guest adapters only into the macvlan code.
I can see this being a possible solution.
My concern with putting VEPA into macvlan instead of the bridging code
is that there will be more work required to make it usable for other
virtualization solution as macvtap will only work for KVM type setups.
Basically, VEPA capabilities would rely on someone developing further
drivers to connect macvlan to different backend interfaces, e.g. one for
KVM (macvtap), one for Xen PV drivers, one for virtio, and whatever else
is out there, or will be there in the future. The bridging code is
already very generic in that respect, and all virtualization layers
can deal with connecting interfaces to a bridge.
Our extensions to the bridging code to enable VEPA for the Linux kernel
are only very minimal code changes and would allow to make VEPA available
to most virtualization solutions today.
Anna
^ permalink raw reply
* Re: [PATCH] macvlan: add tap device backend
From: Arnd Bergmann @ 2009-08-10 13:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, Patrick McHardy, Stephen Hemminger, David S. Miller,
Herbert Xu, Or Gerlitz, Fischer, Anna, bridge, linux-kernel,
Edge Virtual Bridging
In-Reply-To: <20090810085003.GA3654@redhat.com>
On Monday 10 August 2009, Michael S. Tsirkin wrote:
>
> > Would it be enough to check the dev_queue_xmit() return
> > code for NETDEV_TX_BUSY?
> >
> > How would I get notified when it gets free again?
>
> You can do this by creating a socket. Look at how tun does
> this now.
Hmm, I was hoping to be able to avoid this, because I can
interact more directly with the outbound physical interface
using dev_queue_xmit() instead of netif_rx_ni().
I'll have a look. Thanks,
Arnd <><
^ permalink raw reply
* [net-next-2.6 PATCH 1/3] be2net: Clear pending tx completions before destroying tx queue
From: Sathya Perla @ 2009-08-10 13:42 UTC (permalink / raw)
To: netdev
Clear pending tx completions in be_close() (ndo.stop method) so that after
unregister_netdev() calls be_close(), all tx skbs are freed and there are
no more tx completions when txq is destroyed.
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
---
drivers/net/benet/be_main.c | 52 +++++++++++++++++++++++++++---------------
1 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index d20235b..f7f8660 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1018,21 +1018,35 @@ static void be_rx_q_clean(struct be_adapter *adapter)
BUG_ON(atomic_read(&rxq->used));
}
-static void be_tx_q_clean(struct be_adapter *adapter)
+static void be_tx_compl_clean(struct be_adapter *adapter)
{
- struct sk_buff **sent_skbs = adapter->tx_obj.sent_skb_list;
- struct sk_buff *sent_skb;
+ struct be_queue_info *tx_cq = &adapter->tx_obj.cq;
struct be_queue_info *txq = &adapter->tx_obj.q;
- u16 last_index;
- bool dummy_wrb;
-
- while (atomic_read(&txq->used)) {
- sent_skb = sent_skbs[txq->tail];
- last_index = txq->tail;
- index_adv(&last_index,
- wrb_cnt_for_skb(sent_skb, &dummy_wrb) - 1, txq->len);
- be_tx_compl_process(adapter, last_index);
- }
+ struct be_eth_tx_compl *txcp;
+ u16 end_idx, cmpl = 0, timeo = 0;
+
+ /* Wait for a max of 200ms for all the tx-completions to arrive. */
+ do {
+ while ((txcp = be_tx_compl_get(tx_cq))) {
+ end_idx = AMAP_GET_BITS(struct amap_eth_tx_compl,
+ wrb_index, txcp);
+ be_tx_compl_process(adapter, end_idx);
+ cmpl++;
+ }
+ if (cmpl) {
+ be_cq_notify(adapter, tx_cq->id, false, cmpl);
+ cmpl = 0;
+ }
+
+ if (atomic_read(&txq->used) == 0 || ++timeo > 200)
+ break;
+
+ mdelay(1);
+ } while (true);
+
+ if (atomic_read(&txq->used))
+ dev_err(&adapter->pdev->dev, "%d pending tx-completions\n",
+ atomic_read(&txq->used));
}
static void be_mcc_queues_destroy(struct be_adapter *adapter)
@@ -1091,13 +1105,8 @@ static void be_tx_queues_destroy(struct be_adapter *adapter)
struct be_queue_info *q;
q = &adapter->tx_obj.q;
- if (q->created) {
+ if (q->created)
be_cmd_q_destroy(adapter, q, QTYPE_TXQ);
-
- /* No more tx completions can be rcvd now; clean up if there
- * are any pending completions or pending tx requests */
- be_tx_q_clean(adapter);
- }
be_queue_free(adapter, q);
q = &adapter->tx_obj.cq;
@@ -1645,6 +1654,11 @@ static int be_close(struct net_device *netdev)
napi_disable(&rx_eq->napi);
napi_disable(&tx_eq->napi);
+ /* Wait for all pending tx completions to arrive so that
+ * all tx skbs are freed.
+ */
+ be_tx_compl_clean(adapter);
+
return 0;
}
--
1.6.0.4
^ permalink raw reply related
* [net-next-2.6 PATCH 2/3] be2net: fix bad queue traversal in be_rx_q_clean()
From: Sathya Perla @ 2009-08-10 13:43 UTC (permalink / raw)
To: netdev
Using "for(tail != head)" to traverse a queue from tail to head
fails in the case of a fully filled queue. Use "for(used != 0)" instead.
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
---
drivers/net/benet/be_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index f7f8660..49c17ed 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1010,7 +1010,7 @@ static void be_rx_q_clean(struct be_adapter *adapter)
/* Then free posted rx buffer that were not used */
tail = (rxq->head + rxq->len - atomic_read(&rxq->used)) % rxq->len;
- for (; tail != rxq->head; index_inc(&tail, rxq->len)) {
+ for (; atomic_read(&rxq->used) > 0; index_inc(&tail, rxq->len)) {
page_info = get_rx_page_info(adapter, tail);
put_page(page_info->page);
memset(page_info, 0, sizeof(*page_info));
--
1.6.0.4
^ permalink raw reply related
* [net-next-2.6 PATCH 3/3] be2net: clear & notify residual events before destroying event queues
From: Sathya Perla @ 2009-08-10 13:43 UTC (permalink / raw)
To: netdev
Any events rcvd after interrupts are disabled (in the driver unload path),
must be cleared and notified before the event queues are destroyed
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
---
drivers/net/benet/be_main.c | 85 ++++++++++++++++++++++++++++---------------
1 files changed, 56 insertions(+), 29 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 49c17ed..647510f 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -993,6 +993,56 @@ static void be_tx_compl_process(struct be_adapter *adapter, u16 last_index)
kfree_skb(sent_skb);
}
+static inline struct be_eq_entry *event_get(struct be_eq_obj *eq_obj)
+{
+ struct be_eq_entry *eqe = queue_tail_node(&eq_obj->q);
+
+ if (!eqe->evt)
+ return NULL;
+
+ eqe->evt = le32_to_cpu(eqe->evt);
+ queue_tail_inc(&eq_obj->q);
+ return eqe;
+}
+
+static int event_handle(struct be_adapter *adapter,
+ struct be_eq_obj *eq_obj)
+{
+ struct be_eq_entry *eqe;
+ u16 num = 0;
+
+ while ((eqe = event_get(eq_obj)) != NULL) {
+ eqe->evt = 0;
+ num++;
+ }
+
+ /* Deal with any spurious interrupts that come
+ * without events
+ */
+ be_eq_notify(adapter, eq_obj->q.id, true, true, num);
+ if (num)
+ napi_schedule(&eq_obj->napi);
+
+ return num;
+}
+
+/* Just read and notify events without processing them.
+ * Used at the time of destroying event queues */
+static void be_eq_clean(struct be_adapter *adapter,
+ struct be_eq_obj *eq_obj)
+{
+ struct be_eq_entry *eqe;
+ u16 num = 0;
+
+ while ((eqe = event_get(eq_obj)) != NULL) {
+ eqe->evt = 0;
+ num++;
+ }
+
+ if (num)
+ be_eq_notify(adapter, eq_obj->q.id, false, true, num);
+}
+
static void be_rx_q_clean(struct be_adapter *adapter)
{
struct be_rx_page_info *page_info;
@@ -1114,6 +1164,9 @@ static void be_tx_queues_destroy(struct be_adapter *adapter)
be_cmd_q_destroy(adapter, q, QTYPE_CQ);
be_queue_free(adapter, q);
+ /* Clear any residual events */
+ be_eq_clean(adapter, &adapter->tx_eq);
+
q = &adapter->tx_eq.q;
if (q->created)
be_cmd_q_destroy(adapter, q, QTYPE_EQ);
@@ -1185,6 +1238,9 @@ static void be_rx_queues_destroy(struct be_adapter *adapter)
be_cmd_q_destroy(adapter, q, QTYPE_CQ);
be_queue_free(adapter, q);
+ /* Clear any residual events */
+ be_eq_clean(adapter, &adapter->rx_eq);
+
q = &adapter->rx_eq.q;
if (q->created)
be_cmd_q_destroy(adapter, q, QTYPE_EQ);
@@ -1251,35 +1307,6 @@ rx_eq_free:
be_queue_free(adapter, eq);
return rc;
}
-static bool event_get(struct be_eq_obj *eq_obj, u16 *rid)
-{
- struct be_eq_entry *entry = queue_tail_node(&eq_obj->q);
- u32 evt = entry->evt;
-
- if (!evt)
- return false;
-
- evt = le32_to_cpu(evt);
- *rid = (evt >> EQ_ENTRY_RES_ID_SHIFT) & EQ_ENTRY_RES_ID_MASK;
- entry->evt = 0;
- queue_tail_inc(&eq_obj->q);
- return true;
-}
-
-static int event_handle(struct be_adapter *adapter, struct be_eq_obj *eq_obj)
-{
- u16 rid = 0, num = 0;
-
- while (event_get(eq_obj, &rid))
- num++;
-
- /* We can see an interrupt and no event */
- be_eq_notify(adapter, eq_obj->q.id, true, true, num);
- if (num)
- napi_schedule(&eq_obj->napi);
-
- return num;
-}
static irqreturn_t be_intx(int irq, void *dev)
{
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] macvlan: add tap device backend
From: Michael S. Tsirkin @ 2009-08-10 13:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev, Patrick McHardy, Stephen Hemminger, David S. Miller,
Herbert Xu, Or Gerlitz, Fischer, Anna, bridge, linux-kernel,
Edge Virtual Bridging
In-Reply-To: <200908101529.46285.arnd@arndb.de>
On Mon, Aug 10, 2009 at 03:29:46PM +0200, Arnd Bergmann wrote:
> On Monday 10 August 2009, Michael S. Tsirkin wrote:
> >
> > > Would it be enough to check the dev_queue_xmit() return
> > > code for NETDEV_TX_BUSY?
> > >
> > > How would I get notified when it gets free again?
> >
> > You can do this by creating a socket. Look at how tun does
> > this now.
>
> Hmm, I was hoping to be able to avoid this, because I can
> interact more directly with the outbound physical interface
> using dev_queue_xmit() instead of netif_rx_ni().
Yea, that's what tun does. socket just notifies you when
packets are freed.
> I'll have a look. Thanks,
>
> Arnd <><
^ permalink raw reply
* [RFC 0/2] Software implementation of IEEE 802.15.4
From: Dmitry Eremin-Solenikov @ 2009-08-10 14:16 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi,
In this (small) patchset we'd like to present the grounds of our software
IEEE 802.15.4 MAC implementation. Especially this patchset contains only
packet dissection and data path (in generic parts) and virtual loopback
driver (as an example user).
Please review.
Dmitry Eremin-Solenikov (2):
mac802154: add a software MAC 802.15.4 implementation
ieee802154: add virtual loopback driver
MAINTAINERS | 1 +
drivers/ieee802154/Kconfig | 13 +
drivers/ieee802154/Makefile | 1 +
drivers/ieee802154/fakelb.c | 255 ++++++++++++
include/linux/mac802154.h | 35 ++
include/net/mac802154.h | 106 +++++
net/Kconfig | 1 +
net/Makefile | 1 +
net/mac802154/Kconfig | 17 +
net/mac802154/Makefile | 4 +
net/mac802154/dev.c | 924 +++++++++++++++++++++++++++++++++++++++++++
net/mac802154/mac802154.h | 85 ++++
net/mac802154/mac_cmd.c | 99 +++++
net/mac802154/mdev.c | 295 ++++++++++++++
net/mac802154/mib.h | 32 ++
net/mac802154/rx.c | 98 +++++
16 files changed, 1967 insertions(+), 0 deletions(-)
create mode 100644 drivers/ieee802154/fakelb.c
create mode 100644 include/linux/mac802154.h
create mode 100644 include/net/mac802154.h
create mode 100644 net/mac802154/Kconfig
create mode 100644 net/mac802154/Makefile
create mode 100644 net/mac802154/dev.c
create mode 100644 net/mac802154/mac802154.h
create mode 100644 net/mac802154/mac_cmd.c
create mode 100644 net/mac802154/mdev.c
create mode 100644 net/mac802154/mib.h
create mode 100644 net/mac802154/rx.c
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ 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