* Re: [PATCH net-2.6] ethtool: Compat handling for struct ethtool_rxnfc
From: Alexander Duyck @ 2011-03-17 19:50 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev@vger.kernel.org, Santwona Behera
In-Reply-To: <1300383272.2569.13.camel@bwh-desktop>
On 3/17/2011 10:34 AM, Ben Hutchings wrote:
> This structure was accidentally defined such that its layout can
> differ between 32-bit and 64-bit processes. Add compat structure
> definitions and an ioctl wrapper function.
>
> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
> Cc: stable@kernel.org [2.6.30+]
> ---
> David,
>
> I still haven't received any response on whether the ETHTOOL_GRXCLSRLALL
> wrapping works with a real driver, but perhaps you could test it against
> niu? I think sparc32 and sparc64 have the same alignment for u64 so
> this wrapper isn't strictly necessary, but it would still be used. (Or
> we can arrange to disable the conversion when compat_ethtool_rxnfc is
> equivalent to ethtool_rxnfc.)
>
> Ben.
I'll try to pull this into my current development tree and test it while
working on the next set of RFC patches for ixgbe w/ updated flow
director. I probably won't have it done until the middle of next week
though.
Thanks,
Alex
^ permalink raw reply
* why dev_watchdog() timer freezes TX queues
From: Jean-Mickael Guerin @ 2011-03-17 19:25 UTC (permalink / raw)
To: netdev
Hello,
Is it required to set FROZEN all tx queues in dev_watchdog() timer?
On timeout netif_tx_lock() blocks TX on all queues, even if STOPPED
was not set on any queue.
Jean-Mickael
^ permalink raw reply
* Re: sky2, vlan and nat/masquerading
From: Jesse Gross @ 2011-03-17 19:23 UTC (permalink / raw)
To: Christian Hesse; +Cc: netdev
In-Reply-To: <20110315085326.1a1019aa@leda.vpn.lugor.de>
On Tue, Mar 15, 2011 at 12:53 AM, Christian Hesse <mail@eworm.de> wrote:
> On Mon, 14 Mar 2011 18:55:17 -0700 Jesse Gross <jesse@nicira.com> wrote:
>> On Mon, Mar 14, 2011 at 3:11 AM, Christian Hesse <mail@eworm.de> wrote:
>> > Ok, let me explain step by step:
>>
>> Thank you, this helps a lot in understanding your setup.
>>
>> >
>> > * Host sends icmp echo request (172.16.0.21 -> 192.168.100.3) to router
>> > 172.16.0.1, the packet is untagged.
>> > * Switch receives the packet on native interface with vid 2, tags it and
>> > sends it to the trunk)
>> > * Netbook receives the packet from trunk, untags it an queues it to vlan
>> > interface 2.
>> > * Netbook nats the packet (192.168.x.140 > 192.168.100.3), tags it with
>> > vlan 2 and sends it to the trunk.
>>
>> For clarity, I'm assuming that this is supposed to be vlan 1?
>
> Sorry, little typo. Yes, you are right.
>
>> > * Switch receives the packet from trunk, untags it and sends it to native
>> > interface with vlan 1.
>> > * The packet and its answer (192.168.100.3 -> 192.168.x.140) make their
>> > way through the network.
>> > * Switch receives the icmp echo reply on native interface with vlan 1,
>> > tags it and sends it to the trunk
>> > * Netbook receives the packet from trunk, untags it an queues it to vlan
>> > interface 1.
>> > * Netbooks restores the original addresses from nat (192.168.100.3 ->
>> > 172.16.0.21), _tags_it_with_vlan_0_, tags it with vlan 2 and sends it to
>> > the trunk
>>
>> Can you capture a packet trace on the netbook's Ethernet interface to
>> see what it thinks it is sending?
>
> Ok, I have two traces for you: from the vlan interface and from the native
> interface. First ping to 172.16.0.65 is ok, second one to 192.168.100.3 fails.
>
> Please don't be confused, vlan 1 is vlan 3 this time and addresses
> changed a little bit. ;)
Hmm, it's pretty interesting that the extra vlan tag magically
appears. I'll have to reproduce it to investigate further, as the
source isn't readily obvious to me. You said that if you swap out a
different NIC but keep everything else the same the problem goes away?
That also is strange because the packet capture should take place
before the driver.
Can you try using ethtool to turn off txvlan and see if that makes a difference?
^ permalink raw reply
* Re: Poll about irqsafe_cpu_add and others
From: Christoph Lameter @ 2011-03-17 19:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, linux-kernel, linux-arch, netdev, netfilter-devel
In-Reply-To: <1300388139.6315.418.camel@edumazet-laptop>
On Thu, 17 Mar 2011, Eric Dumazet wrote:
> > > I wonder why we dont use :
> > >
> > > addl $0x2,%fs:xt_u64
> > > addcl $0x0,%fs:xt_u64+4
> >
> > The compiler is fed the following
> >
> > *__this_cpu_ptr(xt_u64) += 2
> >
> > __this_cpu_ptr makes it:
> >
> > *(xt_u64 + __my_cpu_offset) += 2
> >
> > So the compiler calculates the address first and then increments it.
> >
> > The compiler could optimize this I think. Wonder why that does not happen.
>
> Compiler is really forced to compute addr, thats why.
>
> Hmm, we should not fallback to generic ops I think, but tweak
>
> percpu_add_op() {
percpu_add_op() is not used. This is a 64 bit operation on a 32 bit
machine thus we fall back to this_cpu_generic_to_op()
#define __this_cpu_generic_to_op(pcp, val, op) \
do { \
*__this_cpu_ptr(&(pcp)) op val; \
} while (0)
^ permalink raw reply
* Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Grant Likely @ 2011-03-17 19:21 UTC (permalink / raw)
To: Richard Cochran
Cc: Scott Wood, Mike Frysinger, Russell King, Arnd Bergmann,
Peter Zijlstra, linux-api-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Miller, Paul Mackerras,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, John Stultz, Thomas Gleixner,
Rodolfo Giometti, Christoph Lameter, Alan Cox, Krzysztof Halasa
In-Reply-To: <20110225075320.GA4032-7KxsofuKt4IfAd9E5cN8NEzG7cXyKsk/@public.gmane.org>
On Fri, Feb 25, 2011 at 08:53:20AM +0100, Richard Cochran wrote:
> On Thu, Feb 24, 2011 at 11:27:31AM -0600, Scott Wood wrote:
>
> > My vote, if it goes in a separate node at all, is "fsl,etsec-ptp",
>
> So, that is what the patch does.
>
> > and let the driver use SVR.
>
> What is SVR?
An on chip register that provides the exact version of the SoC. (As
opposed to PVR which is the version of the cpu core).
g.
^ permalink raw reply
* Re: bnx2 vlan issue
From: Jesse Gross @ 2011-03-17 19:16 UTC (permalink / raw)
To: Seblu; +Cc: netdev
In-Reply-To: <AANLkTi=rOjHZt_F01UfunrTm=2r1BO5QGFDeV9XyKX4G@mail.gmail.com>
On Thu, Mar 17, 2011 at 11:02 AM, Seblu <seblu@seblu.net> wrote:
> On Thu, Mar 17, 2011 at 3:51 PM, Seblu <seblu@seblu.net> wrote:
>> Good Afternoon Gentleman,
>>
>> I've an issue with a 2.6.38 (vanilla) on a debian unstable distro. I
>> attached an lspci and lshw about hardware. I also attached debian
>> network config file.
>>
>> My host is a host kvm which run vm on different networks (vlan). I
>> have 2 1Gbit/s card (eth0, eth1) and 1 10Gbit/s card (eth2).
>> I use bonding (bond0) mode 1 on the 1Gbit/s cards.
>>
>> vlan 14 and 15 are only availlable trought 1G cards. Same tagging on
>> both cards in switch. 14 is untagged (need for pxe) and 15 is tagged.
>>
>> Every network on my host is in a bridge. Eg:
>> vlan 15 is in br15 by bond0.15 as member,
>> vlan 14 is in br14 by bond0 as member,
>> vlan 20 is in br20 by eth2.20
>>
>> The issue is simple, packets from vlan 15 which are tagged are not
>> visible on bond0.15 but in bond0 (see capture). Like if there is no
>> vlan.
>>
>>
>> in dmesg in see something like : "8021q: adding VLAN 0 to HW filter on
>> device bond0".
>> Maybe there is something wrong with hardware filtering?
>>
>> I don't find a way to disable hw vlan filtering.
>> # ethtool -K eth1 rxvlan off
>> Cannot set device flag settings: Invalid argument
>>
>> I found a way to make thing work and don't work by one command.
>> # rmmod bonding
>> # ifdown br14
>> # ifdown br15
>> # ifup --force bond0
>> # ifup --force bond0.15
>> # ifup --force br15
>> => i can ping my ip on 15 working
>> if i make ifup --force br14, i lost connectivity on vlan 15.
>>
>> I don't have isssue when bond0 is not member of br14. So vlan on
>> bonding seems to be broken.
>>
> I done more test this afternoon.
>
> I set an ip on bond0, ip on bond0.15 is still pingeable.
> I created a bridge. Until I don't add bond0 in my bridge, bond0.15 is
> still pingeable.
>
>
>
> Now is see a relation with a similar issue come with 2.6.37. This become
> eth0 => network 1
> eth0.42 => network 2
> br0 => eth0 + eth1 (network1)
>
> Since 2.6.37, eth0.42 (network2) become unavailable, and it is only
> possible to do something like:
> br0 => eth0 + eth1 (network1)
> br0.42 => network 2
>
> To conclude:
> add a bonding interface in a bridge, kill vlan setted on it.
> add a real interface in a bridge, kill vlan setted on it.
>
> So, i don't see how we can restore a per bridge vlan. Why do you
> remove this possibility in 2.6.37?
It was a bug that it worked at all and whether it worked depended on
the hardware/firmware/driver. If an interface is attached to a
bridge, the bridge takes all the packets received on that interface,
including vlan packets.
There are a few ways to setup vlans and bridging that work on all
kernels and with all NICs:
* vlans on interface, bridges contain vlan devices. This gives you a
bridge for each vlan.
* bridge on interface, vlans on bridge device. This gives you a
bridge with all packets and vlan devices can give you specific vlans.
* Use ebtables rules in the bridge to accept/reject certain packets as desired.
^ permalink raw reply
* Re: Poll about irqsafe_cpu_add and others
From: Eric Dumazet @ 2011-03-17 18:55 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Miller, linux-kernel, linux-arch, netdev, netfilter-devel
In-Reply-To: <alpine.DEB.2.00.1103171338350.18529@router.home>
Le jeudi 17 mars 2011 à 13:42 -0500, Christoph Lameter a écrit :
> On Thu, 17 Mar 2011, Eric Dumazet wrote:
>
> > By the way, I noticed :
> >
> > DECLARE_PER_CPU(u64, xt_u64);
> > __this_cpu_add(xt_u64, 2) translates to following x86_32 code :
> >
> > mov $xt_u64,%eax
> > add %fs:0x0,%eax
> > addl $0x2,(%eax)
> > adcl $0x0,0x4(%eax)
> >
> >
> > I wonder why we dont use :
> >
> > addl $0x2,%fs:xt_u64
> > addcl $0x0,%fs:xt_u64+4
>
> The compiler is fed the following
>
> *__this_cpu_ptr(xt_u64) += 2
>
> __this_cpu_ptr makes it:
>
> *(xt_u64 + __my_cpu_offset) += 2
>
> So the compiler calculates the address first and then increments it.
>
> The compiler could optimize this I think. Wonder why that does not happen.
Compiler is really forced to compute addr, thats why.
Hmm, we should not fallback to generic ops I think, but tweak
percpu_add_op() {
...
case 8:
#if CONFIG_X86_64_SMP
if (pao_ID__ == 1) \
asm("incq "__percpu_arg(0) : "+m" (var)); \
else if (pao_ID__ == -1) \
asm("decq "__percpu_arg(0) : "+m" (var)); \
else \
asm("addq %1, "__percpu_arg(0) \
: "+m" (var) \
: "re" ((pao_T__)(val))); \
break; \
#else
asm("addl %1, "__percpu_arg(0) \
: "+m" (var) \
: "ri" ((u32)(val))); \
asm("adcl %1, "__percpu_arg(0) \
: "+m" ((char *)var+4) \
: "ri" ((u32)(val>>32)); \
break; \
#endif
....
}
^ permalink raw reply
* Re: [PATCH] SUNRPC: Remove resource leak in svc_rdma_send_error()
From: Tom Tucker @ 2011-03-17 18:54 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Jesper Juhl, linux-nfs, netdev, linux-kernel, Pavel Emelyanov,
Chuck Lever, Tejun Heo, David S. Miller, Trond Myklebust,
Neil Brown
In-Reply-To: <20110317183752.GH30180@fieldses.org>
Hi Bruce,
I believe this fix is correct.
Tom
On 3/17/11 12:37 PM, J. Bruce Fields wrote:
> On Sat, Jan 22, 2011 at 10:40:20PM +0100, Jesper Juhl wrote:
>> We leak the memory allocated to 'ctxt' when we return after
>> 'ib_dma_mapping_error()' returns !=0.
>>
>> Signed-off-by: Jesper Juhl<jj@chaosbits.net>
> I don't know this code, but I can't see how that could be wrong....
> Applying unless Tom tells me otherwise.
>
> --b.
>
>> ---
>> svc_rdma_transport.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> compile tested only
>>
>> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
>> index 9df1ead..1a10dcd 100644
>> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
>> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
>> @@ -1335,6 +1335,7 @@ void svc_rdma_send_error(struct svcxprt_rdma *xprt, struct rpcrdma_msg *rmsgp,
>> p, 0, length, DMA_FROM_DEVICE);
>> if (ib_dma_mapping_error(xprt->sc_cm_id->device, ctxt->sge[0].addr)) {
>> put_page(p);
>> + svc_rdma_put_context(ctxt, 1);
>> return;
>> }
>> atomic_inc(&xprt->sc_dma_used);
>>
>>
>> --
>> Jesper Juhl<jj@chaosbits.net> http://www.chaosbits.net/
>> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
>> Plain text mails only, please.
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] virtio: Avoid virtio_net TX queue over run
From: Shirley Ma @ 2011-03-17 18:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Michael S. Tsirkin, Rusty Russell, David Miller, kvm, netdev
In-Reply-To: <1300387758.3255.56.camel@localhost.localdomain>
On Thu, 2011-03-17 at 11:49 -0700, Shirley Ma wrote:
> With a single CPU, before/after with this patch the performance has no
> difference for both UDP and TCP, and it seems hitting TX overrun, CPU
> is
> 100% used.
Sorry, should be: it seems never hitting TX overrun.
Shirley
^ permalink raw reply
* Re: [PATCH] virtio: Avoid virtio_net TX queue over run
From: Shirley Ma @ 2011-03-17 18:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Michael S. Tsirkin, Rusty Russell, David Miller, kvm, netdev
In-Reply-To: <1300381265.3255.54.camel@localhost.localdomain>
On Thu, 2011-03-17 at 10:01 -0700, Shirley Ma wrote:
> On Thu, 2011-03-17 at 17:58 +0100, Eric Dumazet wrote:
> > Could you run your tests with only one cpu ?
> > (offline all cpus but cpu0 on your hypervisor)
> >
> > Dropping packets is fine, unless consumer cant run ;)
>
> Sure, will report the data soon.
With a single CPU, before/after with this patch the performance has no
difference for both UDP and TCP, and it seems hitting TX overrun, CPU is
100% used.
Thanks
Shirley
^ permalink raw reply
* Re: Poll about irqsafe_cpu_add and others
From: Christoph Lameter @ 2011-03-17 18:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, linux-kernel, linux-arch, netdev, netfilter-devel
In-Reply-To: <1300386569.6315.404.camel@edumazet-laptop>
On Thu, 17 Mar 2011, Eric Dumazet wrote:
> By the way, I noticed :
>
> DECLARE_PER_CPU(u64, xt_u64);
> __this_cpu_add(xt_u64, 2) translates to following x86_32 code :
>
> mov $xt_u64,%eax
> add %fs:0x0,%eax
> addl $0x2,(%eax)
> adcl $0x0,0x4(%eax)
>
>
> I wonder why we dont use :
>
> addl $0x2,%fs:xt_u64
> addcl $0x0,%fs:xt_u64+4
The compiler is fed the following
*__this_cpu_ptr(xt_u64) += 2
__this_cpu_ptr makes it:
*(xt_u64 + __my_cpu_offset) += 2
So the compiler calculates the address first and then increments it.
The compiler could optimize this I think. Wonder why that does not happen.
^ permalink raw reply
* Re: [PATCH] SUNRPC: Remove resource leak in svc_rdma_send_error()
From: J. Bruce Fields @ 2011-03-17 18:37 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Pavel Emelyanov, Chuck Lever,
Tejun Heo, Tom Tucker, David S. Miller, Trond Myklebust,
Neil Brown
In-Reply-To: <alpine.LNX.2.00.1101222233260.7746-h2p7t3/P30RzeRGmFJ5qR7ZzlVVXadcDXqFh9Ls21Oc@public.gmane.org>
On Sat, Jan 22, 2011 at 10:40:20PM +0100, Jesper Juhl wrote:
> We leak the memory allocated to 'ctxt' when we return after
> 'ib_dma_mapping_error()' returns !=0.
>
> Signed-off-by: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
I don't know this code, but I can't see how that could be wrong....
Applying unless Tom tells me otherwise.
--b.
> ---
> svc_rdma_transport.c | 1 +
> 1 file changed, 1 insertion(+)
>
> compile tested only
>
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> index 9df1ead..1a10dcd 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> @@ -1335,6 +1335,7 @@ void svc_rdma_send_error(struct svcxprt_rdma *xprt, struct rpcrdma_msg *rmsgp,
> p, 0, length, DMA_FROM_DEVICE);
> if (ib_dma_mapping_error(xprt->sc_cm_id->device, ctxt->sge[0].addr)) {
> put_page(p);
> + svc_rdma_put_context(ctxt, 1);
> return;
> }
> atomic_inc(&xprt->sc_dma_used);
>
>
> --
> Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org> http://www.chaosbits.net/
> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
> Plain text mails only, please.
>
--
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: Poll about irqsafe_cpu_add and others
From: Eric Dumazet @ 2011-03-17 18:29 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Miller, linux-kernel, linux-arch, netdev, netfilter-devel
In-Reply-To: <alpine.DEB.2.00.1103171245430.16620@router.home>
Le jeudi 17 mars 2011 à 12:46 -0500, Christoph Lameter a écrit :
> On Thu, 17 Mar 2011, Eric Dumazet wrote:
>
> > When we know we run from BH context, we can use __this_cpu_inc(), but if
> > we dont know or run from user/process context, we would need irqsafe_inc
> > variant.
>
> If the BH context is the only one where we care about performance then its
> ok I would think.
Hmm... yes.
By the way, I noticed :
DECLARE_PER_CPU(u64, xt_u64);
__this_cpu_add(xt_u64, 2) translates to following x86_32 code :
mov $xt_u64,%eax
add %fs:0x0,%eax
addl $0x2,(%eax)
adcl $0x0,0x4(%eax)
I wonder why we dont use :
addl $0x2,%fs:xt_u64
addcl $0x0,%fs:xt_u64+4
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: bnx2 vlan issue
From: Seblu @ 2011-03-17 18:02 UTC (permalink / raw)
To: netdev
In-Reply-To: <AANLkTik0BOuDj5wmfHabZx_OzXDROtDLR2qtqUqQu4ko@mail.gmail.com>
On Thu, Mar 17, 2011 at 3:51 PM, Seblu <seblu@seblu.net> wrote:
> Good Afternoon Gentleman,
>
> I've an issue with a 2.6.38 (vanilla) on a debian unstable distro. I
> attached an lspci and lshw about hardware. I also attached debian
> network config file.
>
> My host is a host kvm which run vm on different networks (vlan). I
> have 2 1Gbit/s card (eth0, eth1) and 1 10Gbit/s card (eth2).
> I use bonding (bond0) mode 1 on the 1Gbit/s cards.
>
> vlan 14 and 15 are only availlable trought 1G cards. Same tagging on
> both cards in switch. 14 is untagged (need for pxe) and 15 is tagged.
>
> Every network on my host is in a bridge. Eg:
> vlan 15 is in br15 by bond0.15 as member,
> vlan 14 is in br14 by bond0 as member,
> vlan 20 is in br20 by eth2.20
>
> The issue is simple, packets from vlan 15 which are tagged are not
> visible on bond0.15 but in bond0 (see capture). Like if there is no
> vlan.
>
>
> in dmesg in see something like : "8021q: adding VLAN 0 to HW filter on
> device bond0".
> Maybe there is something wrong with hardware filtering?
>
> I don't find a way to disable hw vlan filtering.
> # ethtool -K eth1 rxvlan off
> Cannot set device flag settings: Invalid argument
>
> I found a way to make thing work and don't work by one command.
> # rmmod bonding
> # ifdown br14
> # ifdown br15
> # ifup --force bond0
> # ifup --force bond0.15
> # ifup --force br15
> => i can ping my ip on 15 working
> if i make ifup --force br14, i lost connectivity on vlan 15.
>
> I don't have isssue when bond0 is not member of br14. So vlan on
> bonding seems to be broken.
>
I done more test this afternoon.
I set an ip on bond0, ip on bond0.15 is still pingeable.
I created a bridge. Until I don't add bond0 in my bridge, bond0.15 is
still pingeable.
Now is see a relation with a similar issue come with 2.6.37. This become
eth0 => network 1
eth0.42 => network 2
br0 => eth0 + eth1 (network1)
Since 2.6.37, eth0.42 (network2) become unavailable, and it is only
possible to do something like:
br0 => eth0 + eth1 (network1)
br0.42 => network 2
To conclude:
add a bonding interface in a bridge, kill vlan setted on it.
add a real interface in a bridge, kill vlan setted on it.
So, i don't see how we can restore a per bridge vlan. Why do you
remove this possibility in 2.6.37?
--
Sébastien Luttringer
www.seblu.net
^ permalink raw reply
* Re: Poll about irqsafe_cpu_add and others
From: Christoph Lameter @ 2011-03-17 17:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, linux-kernel, linux-arch, netdev, netfilter-devel
In-Reply-To: <1300380801.6315.306.camel@edumazet-laptop>
On Thu, 17 Mar 2011, Eric Dumazet wrote:
> When we know we run from BH context, we can use __this_cpu_inc(), but if
> we dont know or run from user/process context, we would need irqsafe_inc
> variant.
If the BH context is the only one where we care about performance then its
ok I would think.
^ permalink raw reply
* Re: [PATCH net-dev2.6] bxn2x: Fix location of PCI-ids defines
From: Michael Chan @ 2011-03-17 17:32 UTC (permalink / raw)
To: David Miller; +Cc: Eilon Greenstein, Ariel Elior, netdev@vger.kernel.org
In-Reply-To: <20110317.081046.193692423.davem@davemloft.net>
On Thu, 2011-03-17 at 08:10 -0700, David Miller wrote:
> From: "Eilon Greenstein" <eilong@broadcom.com>
> Date: Thu, 17 Mar 2011 15:13:33 +0200
>
> > On Thu, 2011-03-17 at 06:06 -0700, David Miller wrote:
> >> From: "Ariel Elior" <ariele@broadcom.com>
> >> Date: Thu, 17 Mar 2011 14:27:04 +0200
> >>
> >> > Signed-off-by: Ariel Elior <ariele@broadcom.com>
> >> > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> >>
> >> Unless you intend to reference these symbols elsewhere in the
> >> kernel, they should stay private in your driver.
> >>
> >
> > The bnx2i will need it as well. Isn't it better to keep all the PCI IDs
> > in the same global location?
>
> If they are used in more than one driver, yes.
We already sent a similar patch through the scsi tree. It is now in the
linux-next tree:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=8a4a0f3ad071e258a9637c5491c34005a9a97903
^ permalink raw reply
* [PATCH net-2.6] ethtool: Compat handling for struct ethtool_rxnfc
From: Ben Hutchings @ 2011-03-17 17:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Alexander Duyck, Santwona Behera
This structure was accidentally defined such that its layout can
differ between 32-bit and 64-bit processes. Add compat structure
definitions and an ioctl wrapper function.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Cc: stable@kernel.org [2.6.30+]
---
David,
I still haven't received any response on whether the ETHTOOL_GRXCLSRLALL
wrapping works with a real driver, but perhaps you could test it against
niu? I think sparc32 and sparc64 have the same alignment for u64 so
this wrapper isn't strictly necessary, but it would still be used. (Or
we can arrange to disable the conversion when compat_ethtool_rxnfc is
equivalent to ethtool_rxnfc.)
Ben.
include/linux/ethtool.h | 34 ++++++++++++++
net/socket.c | 114 ++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 141 insertions(+), 7 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index aac3e2e..b297f28 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -13,6 +13,9 @@
#ifndef _LINUX_ETHTOOL_H
#define _LINUX_ETHTOOL_H
+#ifdef __KERNEL__
+#include <linux/compat.h>
+#endif
#include <linux/types.h>
#include <linux/if_ether.h>
@@ -450,6 +453,37 @@ struct ethtool_rxnfc {
__u32 rule_locs[0];
};
+#ifdef __KERNEL__
+#ifdef CONFIG_COMPAT
+
+struct compat_ethtool_rx_flow_spec {
+ u32 flow_type;
+ union {
+ struct ethtool_tcpip4_spec tcp_ip4_spec;
+ struct ethtool_tcpip4_spec udp_ip4_spec;
+ struct ethtool_tcpip4_spec sctp_ip4_spec;
+ struct ethtool_ah_espip4_spec ah_ip4_spec;
+ struct ethtool_ah_espip4_spec esp_ip4_spec;
+ struct ethtool_usrip4_spec usr_ip4_spec;
+ struct ethhdr ether_spec;
+ u8 hdata[72];
+ } h_u, m_u;
+ compat_u64 ring_cookie;
+ u32 location;
+};
+
+struct compat_ethtool_rxnfc {
+ u32 cmd;
+ u32 flow_type;
+ compat_u64 data;
+ struct compat_ethtool_rx_flow_spec fs;
+ u32 rule_cnt;
+ u32 rule_locs[0];
+};
+
+#endif /* CONFIG_COMPAT */
+#endif /* __KERNEL__ */
+
/**
* struct ethtool_rxfh_indir - command to get or set RX flow hash indirection
* @cmd: Specific command number - %ETHTOOL_GRXFHINDIR or %ETHTOOL_SRXFHINDIR
diff --git a/net/socket.c b/net/socket.c
index 937d0fcf..5212447 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2588,23 +2588,123 @@ static int dev_ifconf(struct net *net, struct compat_ifconf __user *uifc32)
static int ethtool_ioctl(struct net *net, struct compat_ifreq __user *ifr32)
{
+ struct compat_ethtool_rxnfc __user *compat_rxnfc;
+ bool convert_in = false, convert_out = false;
+ size_t buf_size = ALIGN(sizeof(struct ifreq), 8);
+ struct ethtool_rxnfc __user *rxnfc;
struct ifreq __user *ifr;
+ u32 rule_cnt = 0, actual_rule_cnt;
+ u32 ethcmd;
u32 data;
- void __user *datap;
+ int ret;
+
+ if (get_user(data, &ifr32->ifr_ifru.ifru_data))
+ return -EFAULT;
- ifr = compat_alloc_user_space(sizeof(*ifr));
+ compat_rxnfc = compat_ptr(data);
- if (copy_in_user(&ifr->ifr_name, &ifr32->ifr_name, IFNAMSIZ))
+ if (get_user(ethcmd, &compat_rxnfc->cmd))
return -EFAULT;
- if (get_user(data, &ifr32->ifr_ifru.ifru_data))
+ /* Most ethtool structures are defined without padding.
+ * Unfortunately struct ethtool_rxnfc is an exception.
+ */
+ switch (ethcmd) {
+ default:
+ break;
+ case ETHTOOL_GRXCLSRLALL:
+ /* Buffer size is variable */
+ if (get_user(rule_cnt, &compat_rxnfc->rule_cnt))
+ return -EFAULT;
+ if (rule_cnt > KMALLOC_MAX_SIZE / sizeof(u32))
+ return -ENOMEM;
+ buf_size += rule_cnt * sizeof(u32);
+ /* fall through */
+ case ETHTOOL_GRXRINGS:
+ case ETHTOOL_GRXCLSRLCNT:
+ case ETHTOOL_GRXCLSRULE:
+ convert_out = true;
+ /* fall through */
+ case ETHTOOL_SRXCLSRLDEL:
+ case ETHTOOL_SRXCLSRLINS:
+ buf_size += sizeof(struct ethtool_rxnfc);
+ convert_in = true;
+ break;
+ }
+
+ ifr = compat_alloc_user_space(buf_size);
+ rxnfc = (void *)ifr + ALIGN(sizeof(struct ifreq), 8);
+
+ if (copy_in_user(&ifr->ifr_name, &ifr32->ifr_name, IFNAMSIZ))
return -EFAULT;
- datap = compat_ptr(data);
- if (put_user(datap, &ifr->ifr_ifru.ifru_data))
+ if (put_user(convert_in ? rxnfc : compat_ptr(data),
+ &ifr->ifr_ifru.ifru_data))
return -EFAULT;
- return dev_ioctl(net, SIOCETHTOOL, ifr);
+ if (convert_in) {
+ /* We expect there to be holes between fs.m_u and
+ * fs.ring_cookie and at the end of fs, but nowhere else.
+ */
+ BUILD_BUG_ON(offsetof(struct compat_ethtool_rxnfc, fs.m_u) +
+ sizeof(compat_rxnfc->fs.m_u) !=
+ offsetof(struct ethtool_rxnfc, fs.m_u) +
+ sizeof(rxnfc->fs.m_u));
+ BUILD_BUG_ON(
+ offsetof(struct compat_ethtool_rxnfc, fs.location) -
+ offsetof(struct compat_ethtool_rxnfc, fs.ring_cookie) !=
+ offsetof(struct ethtool_rxnfc, fs.location) -
+ offsetof(struct ethtool_rxnfc, fs.ring_cookie));
+
+ if (copy_in_user(rxnfc, compat_rxnfc,
+ (void *)(&rxnfc->fs.m_u + 1) -
+ (void *)rxnfc) ||
+ copy_in_user(&rxnfc->fs.ring_cookie,
+ &compat_rxnfc->fs.ring_cookie,
+ (void *)(&rxnfc->fs.location + 1) -
+ (void *)&rxnfc->fs.ring_cookie) ||
+ copy_in_user(&rxnfc->rule_cnt, &compat_rxnfc->rule_cnt,
+ sizeof(rxnfc->rule_cnt)))
+ return -EFAULT;
+ }
+
+ ret = dev_ioctl(net, SIOCETHTOOL, ifr);
+ if (ret)
+ return ret;
+
+ if (convert_out) {
+ if (copy_in_user(compat_rxnfc, rxnfc,
+ (const void *)(&rxnfc->fs.m_u + 1) -
+ (const void *)rxnfc) ||
+ copy_in_user(&compat_rxnfc->fs.ring_cookie,
+ &rxnfc->fs.ring_cookie,
+ (const void *)(&rxnfc->fs.location + 1) -
+ (const void *)&rxnfc->fs.ring_cookie) ||
+ copy_in_user(&compat_rxnfc->rule_cnt, &rxnfc->rule_cnt,
+ sizeof(rxnfc->rule_cnt)))
+ return -EFAULT;
+
+ if (ethcmd == ETHTOOL_GRXCLSRLALL) {
+ /* As an optimisation, we only copy the actual
+ * number of rules that the underlying
+ * function returned. Since Mallory might
+ * change the rule count in user memory, we
+ * check that it is less than the rule count
+ * originally given (as the user buffer size),
+ * which has been range-checked.
+ */
+ if (get_user(actual_rule_cnt, &rxnfc->rule_cnt))
+ return -EFAULT;
+ if (actual_rule_cnt < rule_cnt)
+ rule_cnt = actual_rule_cnt;
+ if (copy_in_user(&compat_rxnfc->rule_locs[0],
+ &rxnfc->rule_locs[0],
+ rule_cnt * sizeof(u32)))
+ return -EFAULT;
+ }
+ }
+
+ return 0;
}
static int compat_siocwandev(struct net *net, struct compat_ifreq __user *uifr32)
--
1.7.4
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [ANNOUNCE] iproute 2.6.38
From: Stephen Hemminger @ 2011-03-17 17:16 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Due to popular demand, there is an iproute2 release for 2.6.38 after all.
This version of iproute2 utilities intended for use with 2.6.38 or
later kernel, but should be backward compatible with older releases.
New features are support for macvlan passthru and xfrm security context.
Source: (note old developer.osdl.org address works as well)
http://devresources.linuxfoundation.org/dev/iproute2/download/iproute2-2.6.38.tar.bz2
Repository:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
For more info on iproute2 see:
http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2
Report problems (or enhancements) to the netdev@vger.kernel.org mailing list.
Changelog:
Gerrit Renker (3):
utils: get_jiffies always uses base=0
iproute: fix unit conversion of rtt/rttvar/rto_min
iproute: rename 'get_jiffies' since it uses msecs
Joy Latten (3):
xfrm security context support
xfrm security context support
xfrm security context support
Nicolas Dichtel (1):
iproute2: allow to specify truncation bits on auth algo
Sridhar Samudrala (1):
macvlan/macvtap: support 'passthru' mode
Stephen Hemminger (2):
Update to lasest kernel headers
v2.6.38.1
Vlad Dogaru (1):
iproute2: fix man page whitespace
^ permalink raw reply
* Re: [PATCH] RPC: killing RPC tasks races fixed
From: Stanislav Kinsbursky @ 2011-03-17 17:04 UTC (permalink / raw)
To: Trond Myklebust
Cc: linux-nfs@vger.kernel.org, Pavel Emelianov, neilb@suse.de,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bfields@fieldses.org, davem@davemloft.net, skinsbursky@openvz.org
In-Reply-To: <1300380254.28305.1.camel@lade.trondhjem.org>
17.03.2011 19:44, Trond Myklebust пишет:
>
> Are you sure? Why would the 2.6.32 rhel kernel differ from the mainline
> 2.6.32 kernel in this respect?
>
Checked again and realized, that was wrong.
This set sequence is the same in 2.6.32 rhel, 2.6.32 and 2.6.38 kernels.
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [PATCH] virtio: Avoid virtio_net TX queue over run
From: Shirley Ma @ 2011-03-17 17:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Michael S. Tsirkin, Rusty Russell, David Miller, kvm, netdev
In-Reply-To: <1300381096.6315.315.camel@edumazet-laptop>
On Thu, 2011-03-17 at 17:58 +0100, Eric Dumazet wrote:
> Could you run your tests with only one cpu ?
> (offline all cpus but cpu0 on your hypervisor)
>
> Dropping packets is fine, unless consumer cant run ;)
Sure, will report the data soon.
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH] ethtool: __ethtool_set_sg: check for function pointer before using it
From: Michał Mirosław @ 2011-03-17 17:00 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev, David Miller
In-Reply-To: <20110317163720.GA26284@core.hellgate.ch>
2011/3/17 Roger Luethi <rl@hellgate.ch>:
> __ethtool_set_sg does not check if dev->ethtool_ops->set_sg is defined
> which can result in a NULL pointer dereference when ethtool is used to
> change SG settings for drivers without SG support.
>
> Signed-off-by: Roger Luethi <rl@hellgate.ch>
> ---
>
> Bug verified. Patch only compile-tested.
>
> net/core/ethtool.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index c1a71bb..a1086fb 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -1457,6 +1457,9 @@ static int __ethtool_set_sg(struct net_device *dev, u32 data)
> {
> int err;
>
> + if (!dev->ethtool_ops->set_sg)
> + return -EOPNOTSUPP;
> +
> if (data && !(dev->features & NETIF_F_ALL_CSUM))
> return -EINVAL;
>
Yes. __ethtool_set_sg() is the only function that was already there
before my unification series and I did tests only on drivers which had
set_sg() defined. :-/
This should go into 2.6.39 as a bugfix (adding Cc: DaveM).
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] virtio: Avoid virtio_net TX queue over run
From: Eric Dumazet @ 2011-03-17 16:58 UTC (permalink / raw)
To: Shirley Ma; +Cc: Michael S. Tsirkin, Rusty Russell, David Miller, kvm, netdev
In-Reply-To: <1300380626.3255.53.camel@localhost.localdomain>
Le jeudi 17 mars 2011 à 09:50 -0700, Shirley Ma a écrit :
> On Thu, 2011-03-17 at 07:05 +0200, Michael S. Tsirkin wrote:
> > Could you add CPU utilization data pls? I also wonder what does this
> > do
> > to UDP? Won't a lot of packets be dropped?
>
> Guest CPU utilization slightly increased a few %.
>
> UDP performance send rate increased 200% - 400%, recv rate increased
> from 10% to around 40% w/i recv errors. I will tune the buffers to see
> any better.
>
> I am putting all data together and post the results here soon.
Could you run your tests with only one cpu ?
(offline all cpus but cpu0 on your hypervisor)
Dropping packets is fine, unless consumer cant run ;)
^ permalink raw reply
* Re: Poll about irqsafe_cpu_add and others
From: Eric Dumazet @ 2011-03-17 16:53 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Miller, linux-kernel, linux-arch, netdev, netfilter-devel
In-Reply-To: <alpine.DEB.2.00.1103171016270.12540@router.home>
Le jeudi 17 mars 2011 à 10:18 -0500, Christoph Lameter a écrit :
> On Thu, 17 Mar 2011, David Miller wrote:
>
> >
> > I had been meaning to bring this up from another perspective.
> >
> > In networking, we often only ever access objects in base or
> > BH context. Therefore in BH context cases we can do just
> > normal counter bumps without any of the special atomic or
> > IRQ disabling code at all.
>
> We have the __ functions for that purpose. __this_cpu_inc f.e. falls back
> to a simply ++ operation if the arch cannot provide something better.
> irqsafe_xx are only used if the context does not provide any protection
> and if there is the potential of the counter being incremented from an
> interrupt context.
>
What David and I have in mind is to use one array per mib instead of
two. This is an old idea.
https://patchwork.kernel.org/patch/15883/
When we know we run from BH context, we can use __this_cpu_inc(), but if
we dont know or run from user/process context, we would need irqsafe_inc
variant.
For x86 this maps to same single instruction, but for other arches, this
might be too expensive.
BTW, I think following patch is possible to save some text and useless
tests (on 64bit platform at least)
size vmlinux.old vmlinux
Thanks
[PATCH] snmp: SNMP_UPD_PO_STATS_BH() always called from softirq
We dont need to test if we run from softirq context.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
---
include/net/snmp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/snmp.h b/include/net/snmp.h
index 762e2ab..be2424d 100644
--- a/include/net/snmp.h
+++ b/include/net/snmp.h
@@ -149,8 +149,8 @@ struct linux_xfrm_mib {
} while (0)
#define SNMP_UPD_PO_STATS_BH(mib, basefield, addend) \
do { \
- __typeof__(*mib[0]) *ptr = \
- __this_cpu_ptr((mib)[!in_softirq()]); \
+ __typeof__(*mib[0]) *ptr = __this_cpu_ptr((mib)[0]); \
+ \
ptr->mibs[basefield##PKTS]++; \
ptr->mibs[basefield##OCTETS] += addend;\
} while (0)
^ permalink raw reply related
* Re: [PATCH] ethtool: __ethtool_set_sg: check for function pointer before using it
From: Ben Hutchings @ 2011-03-17 16:52 UTC (permalink / raw)
To: Roger Luethi, Michał Mirosław; +Cc: netdev
In-Reply-To: <20110317163720.GA26284@core.hellgate.ch>
On Thu, 2011-03-17 at 17:37 +0100, Roger Luethi wrote:
> __ethtool_set_sg does not check if dev->ethtool_ops->set_sg is defined
> which can result in a NULL pointer dereference when ethtool is used to
> change SG settings for drivers without SG support.
>
> Signed-off-by: Roger Luethi <rl@hellgate.ch>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Michał, was this just an oversight or is there some reason why we
shouldn't check set_sg immediately?
Ben.
> ---
>
> Bug verified. Patch only compile-tested.
>
> net/core/ethtool.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index c1a71bb..a1086fb 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -1457,6 +1457,9 @@ static int __ethtool_set_sg(struct net_device *dev, u32 data)
> {
> int err;
>
> + if (!dev->ethtool_ops->set_sg)
> + return -EOPNOTSUPP;
> +
> if (data && !(dev->features & NETIF_F_ALL_CSUM))
> return -EINVAL;
>
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] virtio: Avoid virtio_net TX queue over run
From: Shirley Ma @ 2011-03-17 16:50 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Rusty Russell, David Miller, kvm, netdev
In-Reply-To: <20110317050538.GD32049@redhat.com>
On Thu, 2011-03-17 at 07:05 +0200, Michael S. Tsirkin wrote:
> Could you add CPU utilization data pls? I also wonder what does this
> do
> to UDP? Won't a lot of packets be dropped?
Guest CPU utilization slightly increased a few %.
UDP performance send rate increased 200% - 400%, recv rate increased
from 10% to around 40% w/i recv errors. I will tune the buffers to see
any better.
I am putting all data together and post the results here soon.
Thanks
Shirley
^ 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