* Re: [iproute2] iproute2: Allow 'ip addr flush' to loop more than 10 times.
From: Alexander Clouter @ 2010-06-29 8:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <1277790959-28075-1-git-send-email-greearb@candelatech.com>
greearb@gmail.com wrote:
>
> The default remains at 10 for backwards compatibility.
>
> For instance:
> # ip addr flush dev eth2
> *** Flush remains incomplete after 10 rounds. ***
> # ip -l 20 addr flush dev eth2
> *** Flush remains incomplete after 20 rounds. ***
> # ip -loops 0 addr flush dev eth2
> #
>
> This is useful for getting rid of large numbers of IP
> addresses in scripts.
>
Maybe I am missing a trick, but what is wrong with putting this trivial
logic into the script:
ip addr show ${DEV} | awk '/inet6? / { print $2 }' | xargs -I{} ip addr del '{}' dev ${DEV}
You can probably speed things up with '-P' too, '-P 2' gives me a huge
huge speed up for the work I do with 'ip route'.
If you still have addresses on your interface after the above command,
your looping approach probably would have failed also.
Why the need to cram more functionality and options into iproute when
it is something that can be pushed into the wrapper script?
Cheers
--
Alexander Clouter
.sigmonster says: Lend money to a bad debtor and he will hate you.
^ permalink raw reply
* Re: [PATCH net-2.6 2/2] ethtool: Fix potential user buffer overflow for ETHTOOL_{G,S}RXFH
From: David Miller @ 2010-06-29 8:01 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, santwona.behera
In-Reply-To: <1277750759.2089.21.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 28 Jun 2010 19:45:58 +0100
> struct ethtool_rxnfc was originally defined in 2.6.27 for the
> ETHTOOL_{G,S}RXFH command with only the cmd, flow_type and data
> fields. It was then extended in 2.6.30 to support various additional
> commands. These commands should have been defined to use a new
> structure, but it is too late to change that now.
>
> Since user-space may still be using the old structure definition
> for the ETHTOOL_{G,S}RXFH commands, and since they do not need the
> additional fields, only copy the originally defined fields to and
> from user-space.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Cc: stable@kernel.org
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6 1/2] ethtool: Fix potential kernel buffer overflow in ETHTOOL_GRXCLSRLALL
From: David Miller @ 2010-06-29 8:01 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, santwona.behera
In-Reply-To: <1277750647.2089.19.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 28 Jun 2010 19:44:07 +0100
> On a 32-bit machine, info.rule_cnt >= 0x40000000 leads to integer
> overflow and the buffer may be smaller than needed. Since
> ETHTOOL_GRXCLSRLALL is unprivileged, this can presumably be used for at
> least denial of service.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Cc: stable@kernel.org
Applied.
^ permalink raw reply
* Re: [PATCH linux-2.6.35-rc3] micrel phy driver - updated(1)
From: David Miller @ 2010-06-29 7:58 UTC (permalink / raw)
To: David.Choi; +Cc: netdev, bhutchings
In-Reply-To: <C43529A246480145B0A6D0234BDB0F0D0212A3@MELANITE.micrel.com>
From: "Choi, David" <David.Choi@Micrel.Com>
Date: Mon, 28 Jun 2010 18:23:41 -0700
>
> Hello all:
>
> This patch fixes what Ben mentioned, namely duplicated ids.
>
> From: David J. Choi <david.choi@micrel.com>
>
> Body of the explanation: This patch has changes as followings;
> -support the interrupt from phy devices from Micrel Inc.
> -support more phy devices, ks8737, ks8721, ks8041, ks8051 from Micrel.
> -remove vsc8201 because this device was used only internal test at Micrel.
>
> Signed-off-by: David J. Choi <david.choi@micrel.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH -next] netxen: fail when try to setup unsupported features
From: David Miller @ 2010-06-29 7:55 UTC (permalink / raw)
To: sgruszka; +Cc: netdev, amwang, amit.salecha
In-Reply-To: <20100628113329.3206bdbe@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon, 28 Jun 2010 11:33:29 +0200
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] qlcnic: fail when try to setup unsupported features
From: David Miller @ 2010-06-29 7:55 UTC (permalink / raw)
To: sgruszka; +Cc: netdev, amwang, amit.salecha, anirban.chakraborty
In-Reply-To: <20100628113134.0c5208b0@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon, 28 Jun 2010 11:31:34 +0200
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] vmxnet3: fail when try to setup unsupported features
From: David Miller @ 2010-06-29 7:55 UTC (permalink / raw)
To: sgruszka; +Cc: netdev, amwang, sbhatewara
In-Reply-To: <20100628112942.0c919746@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon, 28 Jun 2010 11:29:42 +0200
> Return EOPNOTSUPP in ethtool_ops->set_flags.
>
> Fix coding style while at it.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] bnx2x: fail when try to setup unsupported features
From: David Miller @ 2010-06-29 7:55 UTC (permalink / raw)
To: sgruszka; +Cc: netdev, amwang, eilong
In-Reply-To: <20100628112811.29881285@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon, 28 Jun 2010 11:28:11 +0200
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] e1000e: fail when try to setup unsupported features
From: David Miller @ 2010-06-29 7:55 UTC (permalink / raw)
To: sgruszka; +Cc: netdev, amwang, jeffrey.t.kirsher
In-Reply-To: <20100628112623.492adfcb@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon, 28 Jun 2010 11:26:23 +0200
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: David Miller @ 2010-06-29 7:36 UTC (permalink / raw)
To: mst
Cc: arozansk, herbert.xu, quintela, kvm, virtualization, netdev,
linux-kernel, ykaul, markmc
In-Reply-To: <20100628100807.GA30685@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 28 Jun 2010 13:08:07 +0300
> Userspace virtio server has the following hack
> so guests rely on it, and we have to replicate it, too:
>
> Use port number to detect incoming IPv4 DHCP response packets,
> and fill in the checksum for these.
>
> The issue we are solving is that on linux guests, some apps
> that use recvmsg with AF_PACKET sockets, don't know how to
> handle CHECKSUM_PARTIAL;
> The interface to return the relevant information was added
> in 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
> and older userspace does not use it.
> One important user of recvmsg with AF_PACKET is dhclient,
> so we add a work-around just for DHCP.
>
> Don't bother applying the hack to IPv6 as userspace virtio does not
> have a work-around for that - let's hope guests will do the right
> thing wrt IPv6.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Yikes, this is awful too.
Nothing in the kernel should be mucking around with procotol packets
like this by default. In particular, what the heck does port 67 mean?
Locally I can use it for whatever I want for my own purposes, I don't
have to follow the conventions for service ports as specified by the
IETF.
But I can't have the packet checksum state be left alone for port 67
traffic on a box using virtio because you have this hack there.
And yes it's broken on machines using the qemu thing, but at least the
hack there is restricted to userspace.
I really don't want anything in the kernel that looks like this.
These applications are broken, and we've provided a way for them to
work properly. What's the point of having fixed applications if
all of these hacks grow like fungus over every virtualization transport?
It just means that people won't fix the apps, since they don't have
to. There is no incentive, and the mechanism we created to properly
handle this loses it's value.
At best, you can write a netfilter module that mucks up the packet
checksum state in these situations. At least in that case, you can
make it generic (it mangles iff a packet matches a certain rule,
so for your virtio guests you'd make it match for DHCP frames) instead
of being some hard-coded DHCP thing by design.
And since this is so cleanly seperated and portable you don't even
need to push it upstream. It's a temporary workaround for a temporary
problem. You can just delete it as soon as the majority of guests
have the fixed dhcp. The qemu crap should disappear similarly.
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/2] qlcnic: Driver fixes
From: David Miller @ 2010-06-29 7:14 UTC (permalink / raw)
To: anirban.chakraborty
Cc: netdev, Dept_NX_Linux_NIC_Driver, ameen.rahman, rajesh.borundia
In-Reply-To: <alpine.OSX.2.00.1006251513390.27246@macintosh-2.qlogic.org>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Fri, 25 Jun 2010 15:23:41 -0700
> Please apply the following two patches.
Patch #2 doesn't even come close to applying cleanly to net-next-2.6,
nearly every hunk rejects.
Fix this up and resubmit both patches of this patch set, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: David Miller @ 2010-06-29 7:12 UTC (permalink / raw)
To: ospite-aNJ+ML1ZbiP93QAQaVx+gl6hYfS7NtTn
Cc: alan-yzvJWuRpmD1zbRFIqnYvSA, marcel-kz+m5ild9QBg9hUCZPvPmw,
jkosina-AlSwsSmVLrQ, mdpoole-IZmAEv5cUt1AfugRpC6u6w,
hadess-0MeiytkfxGOsTnJN9+BGXg,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100628131437.bde782b6.ospite-aNJ+ML1ZbiP93QAQaVx+gl6hYfS7NtTn@public.gmane.org>
From: Antonio Ospite <ospite-aNJ+ML1ZbiP93QAQaVx+gl6hYfS7NtTn@public.gmane.org>
Date: Mon, 28 Jun 2010 13:14:37 +0200
> On Sun, 13 Jun 2010 18:20:01 -0400
> Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org> wrote:
>
>> This patch adds support or getting and setting feature reports for bluetooth
>> HID devices from HIDRAW.
>>
>> Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
>> ---
>
> Ping.
We effectively don't have a bluetooth maintainer at the current point
in time. I've tried to let patches sit for a while hoping the listed
maintainer would do something, at least occaisionally, but that simply
isn't happening.
So I'll just pick patches up directly as I find time to review them,
but I have to warn that for me it's going to be done in a very low
priority way because I really don't find bluetooth all that exciting. :-)
^ permalink raw reply
* Re: [PATCH v4 2/2] caif-driver: Add CAIF-SPI Protocol driver.
From: David Miller @ 2010-06-29 7:10 UTC (permalink / raw)
To: sjur.brandeland; +Cc: sjurbr, netdev, marcel, daniel.martensson, linus.walleij
In-Reply-To: <1277587889-17314-2-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Sat, 26 Jun 2010 23:31:29 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> This patch introduces the CAIF SPI Protocol Driver for
> CAIF Link Layer.
>
> This driver implements a platform driver to accommodate for a
> platform specific SPI device. A general platform driver is not
> possible as there are no SPI Slave side Kernel API defined.
> A sample CAIF SPI Platform device can be found in
> .../Documentation/networking/caif/spi_porting.txt
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied, but:
> +
> +config CAIF_SPI_SYNC
> + bool "Next command and length in start of frame"
> + depends on CAIF_SPI_SLAVE
> + default n
> + ---help---
> + Putting the next command and length in the start of the frame can
> + help to synchronize to the next transfer in case of over or under-runs.
> + This option also needs to be enabled on the modem.
> +
This adds an extra new-line at the end of the file, which I corrected
when applying this.
GIT warns when trying to apply a patch with this problem,
checkpatch.pl probably does too, so you really can (in an automated
way) prevent these things from showing up in your submission.
^ permalink raw reply
* Re: [PATCH 1/2] caif: Kconfig and Makefile fixes
From: David Miller @ 2010-06-29 7:08 UTC (permalink / raw)
To: sjur.brandeland; +Cc: sjurbr, netdev, marcel, daniel.martensson, linus.walleij
In-Reply-To: <1277587889-17314-1-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Sat, 26 Jun 2010 23:31:28 +0200
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Use "depends on" instead of "if" in Kconfig files.
> Fixed CAIF debug flag, and removed unnecessary clean-* options.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/9] New cxgb4vf network driver for Chelsio T4 Virtual Function NIC
From: David Miller @ 2010-06-29 7:01 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <201006251507.48604.leedom@chelsio.com>
Applied, but this submission was a mess.
First, your email client broke up long lines in the patch
with newlines, thus corrupting the patch.
Secondly, patch #3 ("cxgb4vf: Add new macros and definitions for
hardware constants") did not apply cleanly to net-next-2.6,
there were line differences.
I fixed these up, but next time I will just toss the patch
set back at you to fix up.
^ permalink raw reply
* Re: [PATCH 2/2] netdev: mdio-octeon: Fix section mismatch errors.
From: David Miller @ 2010-06-29 7:00 UTC (permalink / raw)
To: ddaney; +Cc: netdev, linux-mips
In-Reply-To: <1277406888-26309-3-git-send-email-ddaney@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Thu, 24 Jun 2010 12:14:48 -0700
> We started getting:
>
> WARNING: vmlinux.o(.data+0x20bd0): Section mismatch in reference from
> the variable octeon_mdiobus_driver to the function
> .init.text:octeon_mdiobus_probe()
>
> This fixes it.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/2] netdev: octeon_mgmt: Fix section mismatch errors.
From: David Miller @ 2010-06-29 7:00 UTC (permalink / raw)
To: ddaney; +Cc: netdev, linux-mips
In-Reply-To: <1277406888-26309-2-git-send-email-ddaney@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Thu, 24 Jun 2010 12:14:47 -0700
> We started getting:
>
> WARNING: drivers/net/built-in.o(.data+0x10f0): Section mismatch in
> reference from the variable octeon_mgmt_driver to the function
> .init.text:octeon_mgmt_probe()
>
> This fixes it.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: Michael S. Tsirkin @ 2010-06-29 6:55 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Aristeu Rozanski, Herbert Xu, Juan Quintela, David S. Miller, kvm,
virtualization, netdev, linux-kernel, ykaul, markmc
In-Reply-To: <1277763581.23755.16.camel@w-sridhar.beaverton.ibm.com>
On Mon, Jun 28, 2010 at 03:19:41PM -0700, Sridhar Samudrala wrote:
> On Mon, 2010-06-28 at 13:08 +0300, Michael S. Tsirkin wrote:
> > Userspace virtio server has the following hack
> > so guests rely on it, and we have to replicate it, too:
> >
> > Use port number to detect incoming IPv4 DHCP response packets,
> > and fill in the checksum for these.
> >
> > The issue we are solving is that on linux guests, some apps
> > that use recvmsg with AF_PACKET sockets, don't know how to
> > handle CHECKSUM_PARTIAL;
> > The interface to return the relevant information was added
> > in 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
> > and older userspace does not use it.
> > One important user of recvmsg with AF_PACKET is dhclient,
> > so we add a work-around just for DHCP.
> >
> > Don't bother applying the hack to IPv6 as userspace virtio does not
> > have a work-around for that - let's hope guests will do the right
> > thing wrt IPv6.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > Dave, I'm going to put this patch on the vhost tree,
> > no need for you to bother merging it - you'll get
> > it with a pull request.
> >
> >
> > drivers/vhost/net.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
> > 1 files changed, 43 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > index cc19595..03bba6a 100644
> > --- a/drivers/vhost/net.c
> > +++ b/drivers/vhost/net.c
> > @@ -24,6 +24,10 @@
> > #include <linux/if_tun.h>
> > #include <linux/if_macvlan.h>
> >
> > +#include <linux/ip.h>
> > +#include <linux/udp.h>
> > +#include <linux/netdevice.h>
> > +
> > #include <net/sock.h>
> >
> > #include "vhost.h"
> > @@ -186,6 +190,44 @@ static void handle_tx(struct vhost_net *net)
> > unuse_mm(net->dev.mm);
> > }
> >
> > +static int peek_head(struct sock *sk)
>
> This routine is doing more than just peeking the head of sk's receive
> queue. May be this should be named similar to what qemu calls
> 'work_around_broken_dhclient()'
> > +{
> > + struct sk_buff *skb;
> > +
> > + lock_sock(sk);
> > + skb = skb_peek(&sk->sk_receive_queue);
> > + if (unlikely(!skb)) {
> > + release_sock(sk);
> > + return 0;
> > + }
> > + /* Userspace virtio server has the following hack so
> > + * guests rely on it, and we have to replicate it, too: */
> > + /* Use port number to detect incoming IPv4 DHCP response packets,
> > + * and fill in the checksum. */
> > +
> > + /* The issue we are solving is that on linux guests, some apps
> > + * that use recvmsg with AF_PACKET sockets, don't know how to
> > + * handle CHECKSUM_PARTIAL;
> > + * The interface to return the relevant information was added in
> > + * 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
> > + * and older userspace does not use it.
> > + * One important user of recvmsg with AF_PACKET is dhclient,
> > + * so we add a work-around just for DHCP. */
> > + if (skb->ip_summed == CHECKSUM_PARTIAL &&
> > + skb_headlen(skb) >= skb_transport_offset(skb) +
> > + sizeof(struct udphdr) &&
> > + udp_hdr(skb)->dest == htons(68) &&
> > + skb_network_header_len(skb) >= sizeof(struct iphdr) &&
> > + ip_hdr(skb)->protocol == IPPROTO_UDP &&
> > + skb->protocol == htons(ETH_P_IP)) {
>
> Isn't it more logical to check for skb->protocol, followed by ip_hdr and
> then udp_hdr?
Yes, but then we'll only exit after checking them all.
My way we'll almost always exit after port check.
> > + skb_checksum_help(skb);
> > + /* Restore ip_summed value: tun passes it to user. */
> > + skb->ip_summed = CHECKSUM_PARTIAL;
> > + }
> > + release_sock(sk);
> > + return 1;
> > +}
> > +
> > /* Expects to be always run from workqueue - which acts as
> > * read-size critical section for our kind of RCU. */
> > static void handle_rx(struct vhost_net *net)
> > @@ -222,7 +264,7 @@ static void handle_rx(struct vhost_net *net)
> > vq_log = unlikely(vhost_has_feature(&net->dev, VHOST_F_LOG_ALL)) ?
> > vq->log : NULL;
> >
> > - for (;;) {
> > + while (peek_head(sock->sk)) {
> > head = vhost_get_vq_desc(&net->dev, vq, vq->iov,
> > ARRAY_SIZE(vq->iov),
> > &out, &in,
^ permalink raw reply
* Re: [PATCH 2.6.35] bonding: prevent netpoll over bonded interfaces
From: David Miller @ 2010-06-29 6:54 UTC (permalink / raw)
To: andy; +Cc: netdev, amwang, fubar
In-Reply-To: <20100625195044.GQ7497@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Fri, 25 Jun 2010 15:50:44 -0400
>
> Support for netpoll over bonded interfaces was added here:
>
> commit f6dc31a85cd46a959bdd987adad14c3b645e03c1
> Author: WANG Cong <amwang@redhat.com>
> Date: Thu May 6 00:48:51 2010 -0700
>
> bonding: make bonding support netpoll
>
> but it is bad enough that we should probably just disable netpoll over
> bonding until some of the locking logic in the bonding driver is changed
> or converted completely to RCU. Simple actions like changing the active
> slave in active-backup mode will hang the box if a high enough printk
> debugging level is enabled.
>
> Keeping the old code around will be good for anyone that wants to work
> on it (and for after the RCU conversion), so I propose this small patch
> rather than ripping it all out.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Applied, thanks a lot Andy.
^ permalink raw reply
* Re: [PATCH] s2io: read rx_packets count from the hardware stats
From: David Miller @ 2010-06-29 6:52 UTC (permalink / raw)
To: mschmidt; +Cc: netdev, Ramkrishna.Vepa, sivakumar.subramani, sreenivasa.honnur
In-Reply-To: <20100624233230.5864.67401.stgit@leela.lan>
From: Michal Schmidt <mschmidt@redhat.com>
Date: Fri, 25 Jun 2010 01:32:32 +0200
> Most of the statistics the s2io driver provides in /proc/net/dev
> it reads directly from the hardware counters. For some reason it does
> not do that for rx_packets. It counts rx_packets purely in software.
>
> A customer reported a bug where in /proc/net/dev the 'multicast' counter
> was increasing faster than 'packets' ( = rx_packets in the source code).
> This confuses userspace, especially snmpd.
>
> The hardware provides a counter for the total number of received
> frames (RMAC_VLD_FRMS) which the driver can use for the rx_packets
> statistic. By reading both statistics from the hardware it makes sure
> that all multicast frames are included in the total.
>
> The customer tested a patch like this (only modified for RHEL5) with
> S2io Inc. Xframe II 10Gbps Ethernet (rev 02)
> and it fixed the problem.
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Please also use the rmac_data_octets HW statistic for rx_bytes
otherwise rx_bytes will be out of sync with the other stats too.
^ permalink raw reply
* Re: [RFC][BUG-FIX] the problem of checksum checking in UDP protocol
From: Shan Wei @ 2010-06-29 6:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Ronciak, John, netdev
In-Reply-To: <1277757512.4235.750.camel@edumazet-laptop>
Eric Dumazet wrote, at 06/29/2010 04:38 AM:
> If a change is needed, I would vote for a change in NIC firmware,
Eric, thanks for your explanation very much.
My solution is ugly. Modify UDP protocol stack is just a way to circumvent.
Most in need of modification should be the NIC's fireware. However,
such as the e1000e network card for years, and no serious problems have been reported.
So, I think this thread can be closed now.
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH v3] act_mirred: don't clone skb when skb isn't shared
From: David Miller @ 2010-06-29 6:38 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, netdev
In-Reply-To: <1277469551.5438.0.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Fri, 25 Jun 2010 08:39:11 -0400
> On Fri, 2010-06-25 at 10:25 +0800, Changli Gao wrote:
>> don't clone skb when skb isn't shared
>>
>> When the tcf_action is TC_ACT_STOLEN, and the skb isn't shared, we don't need
>> to clone a new skb. As the skb will be freed after this function returns, we
>> can use it freely once we get a reference to it.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] 3c59x: Use fine-grained locks for MII and windowed register access
From: Steffen Klassert @ 2010-06-29 6:39 UTC (permalink / raw)
To: David Miller; +Cc: ben, netdev, chase.douglas, nordmark
In-Reply-To: <20100628.231812.35040625.davem@davemloft.net>
On Mon, Jun 28, 2010 at 11:18:12PM -0700, David Miller wrote:
>
> Once Ben posts a new version of this second patch with the
> proper spin_lock_init() calls added I am going to apply both
> of his changes.
Yes, of course apply them. It was just a recommendation to avoid the locks
in the cases they are not needed. These patches are a real improvement,
so I'm fine with them.
Steffen
^ permalink raw reply
* Re: [PATCH net-next-2.6] netfilter: allow nf_tproxy_core module to be removed
From: David Miller @ 2010-06-29 6:38 UTC (permalink / raw)
To: kaber; +Cc: fw, jpirko, netdev, bazsi, hidden
In-Reply-To: <4C2379D9.2080608@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 24 Jun 2010 17:29:29 +0200
> David Miller wrote:
>> From: Florian Westphal <fw@strlen.de>
>> Date: Wed, 23 Jun 2010 20:46:11 +0200
>>
>>
>>> tproxy assigns skb->destructor, what prevents module unload while such
>>> skbs may
>>> still be around?
>>>
>>
>> The only reference to nf_tproxy_core.ko is for the symbol,
>> "nf_tproxy_assign_sock".
>> xt_TPROXY.c, which references this symbol, thus creates a symbol
>> dependency on this
>> module, so xt_TPROXY.o needs to unload before nf_tproxy_core.ko can
>> unload, and
>> xt_TPROXY.o has it's own manner for handling module references
>> properly.
>>
>
> I don't see anything waiting for skbs in flight using the tproxy
> destructor in either xt_TPROXY or nf_tproxy_core though, so I think
> Florian is correct.
Ok.
^ permalink raw reply
* Re: [PATCH net-next-2.6] tcp: tso_fragment() might avoid GFP_ATOMIC
From: David Miller @ 2010-06-29 6:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1277377222.2816.296.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 24 Jun 2010 13:00:22 +0200
> We can pass a gfp argument to tso_fragment() and avoid GFP_ATOMIC
> allocations sometimes.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
Slow down Eric, you're on fire :-)
^ 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