* Re: [PATCH] net: bnx2x: fix error value sign
From: Eric Dumazet @ 2010-11-14 20:32 UTC (permalink / raw)
To: Vasiliy Kulikov; +Cc: kernel-janitors, Eilon Greenstein, netdev, linux-kernel
In-Reply-To: <1289766583.2743.144.camel@edumazet-laptop>
Le dimanche 14 novembre 2010 à 21:29 +0100, Eric Dumazet a écrit :
> I remember sending same patch in the past... it was lost somehow...
Ah, it was another issue, patch was not lost ;)
^ permalink raw reply
* Re: [PATCH] net: bnx2x: fix error value sign
From: Eric Dumazet @ 2010-11-14 20:29 UTC (permalink / raw)
To: Vasiliy Kulikov; +Cc: kernel-janitors, Eilon Greenstein, netdev, linux-kernel
In-Reply-To: <1289765315-6028-1-git-send-email-segoon@openwall.com>
Le dimanche 14 novembre 2010 à 23:08 +0300, Vasiliy Kulikov a écrit :
> bnx2x_init_one() should return negative value on error.
> By mistake it returns ENODEV instead of -ENODEV.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
> ---
> Compile tested.
>
> drivers/net/bnx2x/bnx2x_main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
> index 4a6f0ea..be52edc 100644
> --- a/drivers/net/bnx2x/bnx2x_main.c
> +++ b/drivers/net/bnx2x/bnx2x_main.c
> @@ -9064,7 +9064,7 @@ static int __devinit bnx2x_init_one(struct pci_dev *pdev,
> default:
> pr_err("Unknown board_type (%ld), aborting\n",
> ent->driver_data);
> - return ENODEV;
> + return -ENODEV;
> }
>
> cid_count += CNIC_CONTEXT_USE;
I remember sending same patch in the past... it was lost somehow...
^ permalink raw reply
* Re: [PATCH] tcp: restrict net.ipv4.tcp_adv_min_scale (#20312)
From: Alexey Dobriyan @ 2010-11-14 20:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, shemminger, netdev
In-Reply-To: <1289764183.2743.94.camel@edumazet-laptop>
On Sun, Nov 14, 2010 at 08:49:43PM +0100, Eric Dumazet wrote:
> > +static int _minus_31 = -31;
> > +static int _31 = 31;
>
> Please use normal symbols, not starting by underscore.
static int thirty_one = 31? :-)
^ permalink raw reply
* Re: [PATCH] net: bnx2x: fix error value sign
From: Eilon Greenstein @ 2010-11-14 20:26 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1289765315-6028-1-git-send-email-segoon@openwall.com>
On Sun, 2010-11-14 at 12:08 -0800, Vasiliy Kulikov wrote:
> bnx2x_init_one() should return negative value on error.
> By mistake it returns ENODEV instead of -ENODEV.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Thanks Vasiliy!
Acked-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> Compile tested.
>
> drivers/net/bnx2x/bnx2x_main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
> index 4a6f0ea..be52edc 100644
> --- a/drivers/net/bnx2x/bnx2x_main.c
> +++ b/drivers/net/bnx2x/bnx2x_main.c
> @@ -9064,7 +9064,7 @@ static int __devinit bnx2x_init_one(struct pci_dev *pdev,
> default:
> pr_err("Unknown board_type (%ld), aborting\n",
> ent->driver_data);
> - return ENODEV;
> + return -ENODEV;
> }
>
> cid_count += CNIC_CONTEXT_USE;
^ permalink raw reply
* Re: [RFC] pull linux-2.6 into net-next-2.6 ?
From: David Miller @ 2010-11-14 20:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1289636478.2743.19.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 13 Nov 2010 09:21:18 +0100
> Andrew pushed to Linus the patch introducing atomic_inc_not_zero_hint()
>
> (commit 3f9d35b9514da675)
>
> Would it be possible to get it in net-next-2.6 so that I can start using
> it in network stack ?
Done.
^ permalink raw reply
* [PATCH] net: bnx2x: fix error value sign
From: Vasiliy Kulikov @ 2010-11-14 20:08 UTC (permalink / raw)
To: kernel-janitors; +Cc: Eilon Greenstein, netdev, linux-kernel
bnx2x_init_one() should return negative value on error.
By mistake it returns ENODEV instead of -ENODEV.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
Compile tested.
drivers/net/bnx2x/bnx2x_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 4a6f0ea..be52edc 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -9064,7 +9064,7 @@ static int __devinit bnx2x_init_one(struct pci_dev *pdev,
default:
pr_err("Unknown board_type (%ld), aborting\n",
ent->driver_data);
- return ENODEV;
+ return -ENODEV;
}
cid_count += CNIC_CONTEXT_USE;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH/RFC] netfilter: nf_conntrack_sip: Handle quirky Cisco phones
From: Eric Dumazet @ 2010-11-14 19:57 UTC (permalink / raw)
To: Kevin Cernekee
Cc: Patrick McHardy, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, linux-kernel, netdev
In-Reply-To: <AANLkTik4PLga8mX73c8iONPeOtpDiuDhfu3xiPmF07jC@mail.gmail.com>
Le dimanche 14 novembre 2010 à 10:33 -0800, Kevin Cernekee a écrit :
> On Sun, Nov 14, 2010 at 12:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > I would like to get an exact SIP exchange to make sure their is not
> > another way to handle this without adding a "Cisco" string somewhere...
> >
> > Please provide a pcap or tcpdump -A
>
> Existing nf_nat_sip: phone sends unauthenticated REGISTER requests
> over and over again, because it is not seeing the replies sent back to
> port 50070:
>
> 10:05:53.496479 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723
> E`...[..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
> Via: SIP/2.0/
>
Hmm, partial tcpdump... you should use" tcpdump -s 1000 -A"
We miss the
Via: SIP/2.0/UDP 192.168.2.28:5060;branch=xxxxxxxx
Maybe a fix would be to use this "5060" port, instead of hardcoding it
like you did ?
>
> Patched nf_nat_sip: router sends the replies back to port 5060, so the
> phone is now able to register itself and make calls:
>
> 10:09:46.221631 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 723
> E`...G..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
> Via: SIP/2.0/
>
> 10:09:46.253052 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491
> E....+..4..$C...............SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 192.168.2.28:5060
>
> 10:09:46.253472 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 550
> E..B.,..4...C...............SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP 192.168.2.2
>
> 10:09:46.261602 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 900
> E`...H..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
> Via: SIP/2.0/
>
> 10:09:46.290211 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491
> E....-..4.."C...............SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 192.168.2.28:5060
>
> 10:09:46.295041 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 579
> E.._....4...C............K..SIP/2.0 200 OK
> Via: SIP/2.0/UDP 192.168.2.28:5060;bra
>
>
> BTW, I thought of two possible issues with the original patch:
>
> 1) Might need to call skb_make_writable() prior to modifying the
> packet. Presumably the second invocation inside
> nf_nat_mangle_udp_packet() will have no effect.
>
> (Is there a cleaner way to mangle just the port number? Most of the
> utility functions only help with modifying the data area.)
>
> 2) I should probably be checking to make sure request == 0 before
> mangling the packet. The current behavior is harmless if the SIP
> proxy is on port 5060, but that might not always be the case.
>
> I can roll these, along with any other suggestions, into v2.
^ permalink raw reply
* Re: [PATCH] ipv4: mitigate an integer underflow when comparing tcp timestamps
From: David Miller @ 2010-11-14 19:55 UTC (permalink / raw)
To: eric.dumazet
Cc: r0bertz, netdev, linux-kernel, kuznet, pekkas, jmorris, yoshfuji,
kaber
In-Reply-To: <1289724745.2743.61.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 14 Nov 2010 09:52:25 +0100
> Really, if you have multiple clients behind a common NAT, you cannot use
> this code at all, since NAT doesnt usually change TCP timestamps.
NAT is %100 incompatible with TW recycling, full stop.
There is no maybe, or maybe not.
If you are behind NAT you must not turn this feature on, ever.
^ permalink raw reply
* Re: [PATCH] tcp: restrict net.ipv4.tcp_adv_min_scale (#20312)
From: Eric Dumazet @ 2010-11-14 19:49 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, shemminger, netdev
In-Reply-To: <20101114151825.GA25137@core2.telecom.by>
Le dimanche 14 novembre 2010 à 17:18 +0200, Alexey Dobriyan a écrit :
> tcp_win_from_space() does the following:
>
> if (sysctl_tcp_adv_win_scale <= 0)
> return space >> (-sysctl_tcp_adv_win_scale);
> else
> return space - (space >> sysctl_tcp_adv_win_scale);
>
> "space" is int.
>
> As per C99 6.5.7 (3) shifting int for 32 or more bits is
> undefined behaviour.
>
> Indeed, if sysctl_tcp_adv_win_scale is exactly 32, space >> 32 equals
> space and function returns 0;
>
> Which means we busyloop in tcp_fixup_rcvbuf().
>
> Restrict net.ipv4.tcp_adv_win_scale to [-31, 31].
>
> Fix https://bugzilla.kernel.org/show_bug.cgi?id=20312
>
> Steps to reproduce:
>
> echo 32 >/proc/sys/net/ipv4/tcp_adv_win_scale
> wget www.kernel.org
> [softlockup]
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
>
Please fix your patch title, you speak of adv_min_scale ...
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -26,6 +26,8 @@ static int zero;
> static int tcp_retr1_max = 255;
> static int ip_local_port_range_min[] = { 1, 1 };
> static int ip_local_port_range_max[] = { 65535, 65535 };
> +static int _minus_31 = -31;
> +static int _31 = 31;
Please use normal symbols, not starting by underscore.
>
> /* Update system visible IP port range */
> static void set_local_port_range(int range[2])
> @@ -426,7 +428,9 @@ static struct ctl_table ipv4_table[] = {
> .data = &sysctl_tcp_adv_win_scale,
> .maxlen = sizeof(int),
> .mode = 0644,
> - .proc_handler = proc_dointvec
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = &_minus_31,
> + .extra2 = &_31,
> },
> {
> .procname = "tcp_tw_reuse",
Please change Documentation/networking/ip-sysctl.txt to reflect possible
values of adv_win_scale
Thanks
^ permalink raw reply
* Re: [BUG]: skge not working (as module) in 2.6.37-rc1
From: Maciej Rutecki @ 2010-11-14 19:45 UTC (permalink / raw)
To: Marin Mitov
Cc: Stephen Hemminger, Stephen Hemminger, netdev, linux-kernel,
David S. Miller
In-Reply-To: <201011072345.52784.mitov@issp.bas.bg>
On niedziela, 7 listopada 2010 o 22:45:52 Marin Mitov wrote:
> Hi Stephen,
>
> skge as in 2.6.36 (and before) is working.
> As in 2.6.37-rc1 it is not:
>
I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=22892
for your bug report, please add your address to the CC list in there, thanks!
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* Re: sky2 for on-board 88e8055 fails to detect mac address
From: Stephen Hemminger @ 2010-11-14 18:58 UTC (permalink / raw)
To: Guillaume Leclanche; +Cc: netdev
In-Reply-To: <AANLkTinR9vpuGoizvNsvnpMBM-UnWS66yMjwMQaKSk_c@mail.gmail.com>
On Sun, 14 Nov 2010 12:42:06 +0100
Guillaume Leclanche <guillaume@leclanche.net> wrote:
> Hello,
>
> I use a "Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit Ethernet
> Controller".
> It seems that the sky2 module doesn't manage to grab the mac address
> from the HW :
>
> [ 0.741173] sky2: driver version 1.28
> [ 0.741206] sky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [ 0.741216] sky2 0000:02:00.0: setting latency timer to 64
> [ 0.741244] sky2 0000:02:00.0: Yukon-2 EC Ultra chip revision 2
> [ 0.741339] sky2 0000:02:00.0: irq 44 for MSI/MSI-X
> [ 0.744781] sky2 0000:02:00.0: eth0: addr 00:00:00:00:00:00
>
> Of course I can set the mac address manually with "ip link set eth0
> addr ..." (and then it works fine) but I guess that's not the normal
> behavior from the driver?
>
> I'd be happy to troubleshoot but I'm not very used to kernel
> internals, so tell me if you need some output.
> Below a few targeted info about my system.
>
> Guillaume
>
> 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux
>
> 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8055
> PCI-E Gigabit Ethernet Controller
> Subsystem: Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit
> Ethernet Controller
> Flags: bus master, fast devsel, latency 0, IRQ 44
> Memory at fe8fc000 (64-bit, non-prefetchable) [size=16K]
> I/O ports at a800 [size=256]
> Expansion ROM at fe8c0000 [disabled] [size=128K]
> Capabilities: [48] Power Management version 3
> Capabilities: [50] Vital Product Data
> Capabilities: [5c] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [e0] Express Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Kernel driver in use: sky2
> Kernel modules: sky2
The driver reads the MAC address from EEPROM.
There are a couple of possibilities:
1. The driver could have problem when reading the value because of a timing issue.
BUT I doubt that because when that happens the driver would see ff:ff:ff:ff:ff:ff
2. The BIOS is screwing it up on boot.
Did you enable the device in the BIOS?
3. The vendor screwed up and didn't program the address into the hardware.
It doesn't look like a kernel/driver problem at all.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bridge: add __rcu annotations
From: Stephen Hemminger @ 2010-11-14 18:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1289685861.2743.38.camel@edumazet-laptop>
On Sat, 13 Nov 2010 23:04:21 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le samedi 13 novembre 2010 à 10:13 -0800, Stephen Hemminger a écrit :
> > On Sat, 13 Nov 2010 18:58:50 +0100
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > > Le samedi 13 novembre 2010 à 09:35 -0800, Stephen Hemminger a écrit :
> > > > On Sat, 13 Nov 2010 09:15:28 +0100
> > > > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > >
> > > > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > > > > index 578debb..ffbd177 100644
> > > > > --- a/include/linux/netdevice.h
> > > > > +++ b/include/linux/netdevice.h
> > > > > @@ -996,7 +996,10 @@ struct net_device {
> > > > > #endif
> > > > >
> > > > > rx_handler_func_t *rx_handler;
> > > > > - void *rx_handler_data;
> > > > > + union {
> > > > > + void *rx_handler_data;
> > > > > + struct net_bridge_port __rcu *br_port_rcu;
> > > > > + };
> > > > >
> > > > > struct netdev_queue __rcu *ingress_queue;
> > > >
> > > > I don't like making the generic hook typed again.
> > > > We don't do this for other callbacks, timers, workqueues, ...
> > > > Why is it necessary for RCU notation.
> > > >
> > >
> > > because rcu_dereference() needs the type for __CHECKER__/sparse checks
> > >
> > > #define __rcu_dereference_check(p, c, space) \
> > > ({ \
> > > typeof(*p) *_________p1 = (typeof(*p)*__force )ACCESS_ONCE(p); \
> > > rcu_lockdep_assert(c); \
> > > rcu_dereference_sparse(p, space); \
> > > smp_read_barrier_depends(); \
> > > ((typeof(*p) __force __kernel *)(_________p1)); \
> > > })
> > >
> > > So using a "void *ptr" is not an option
> > >
> > > Its also cleaner to use
> > >
> > > rcu_dereference(dev->br_port_rcu)
> > >
> > > instead of
> > >
> > > (struct net_bridge_port *)rcu_dereference(dev->rx_handler_data)
> >
> > There must be a better way. What about use of that hook by macvlan and openvswitch?
>
> macvlan and openvswitch (is it part of linux yet ???)
>
> I honestly dont understand your point Stephen, maybe you could explain a
> bit more what is the problem ?
>
> I use a union, like many other ones in the kernel. This is the first
> time I ear this is not good to add type safety.
>
> You can use either one or other field at your convenience.
>
> If you are talking about stacking hooks, that has nothing to do with
> this (cleanup) rcu patch, but previous introduction of
> rx_handler_data/rx_handler ?
>
> Please run sparse on x86_64 machine and watch all the warnings in bridge
> code. (with CONFIG_SPARSE_RCU_POINTER=y)
>
> Me confused.
>
>
You combined three different sets of changes and introduced a needless
union. I will split them up and show you what I want.
--
^ permalink raw reply
* Re: [PATCH/RFC] netfilter: nf_conntrack_sip: Handle quirky Cisco phones
From: Kevin Cernekee @ 2010-11-14 18:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, linux-kernel, netdev
In-Reply-To: <1289725175.2743.65.camel@edumazet-laptop>
On Sun, Nov 14, 2010 at 12:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> I would like to get an exact SIP exchange to make sure their is not
> another way to handle this without adding a "Cisco" string somewhere...
>
> Please provide a pcap or tcpdump -A
Existing nf_nat_sip: phone sends unauthenticated REGISTER requests
over and over again, because it is not seeing the replies sent back to
port 50070:
10:05:53.496479 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723
E`...[..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:05:53.587370 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 486
E.......3..fC...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:05:53.587807 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 550
E..B....3..%C...............SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.2
10:05:57.496541 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723
E`...\..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:05:57.526716 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 486
E.......3..dC...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:05:57.527162 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 550
E..B....3..#C...............SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.2
10:06:01.486821 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723
E`...]..@.r.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:06:01.515611 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 486
E.......3..bC...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:06:01.516024 IP 67.215.241.250.5060 > 192.168.2.28.50070: SIP, length: 550
E..B....3..!C...............SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.2
... continues forever ...
Patched nf_nat_sip: router sends the replies back to port 5060, so the
phone is now able to register itself and make calls:
10:09:46.221631 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 723
E`...G..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:09:46.253052 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491
E....+..4..$C...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:09:46.253472 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 550
E..B.,..4...C...............SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.2
10:09:46.261602 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 900
E`...H..@.p.....C...........REGISTER sip:losangeles.voip.ms SIP/2.0
Via: SIP/2.0/
10:09:46.290211 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491
E....-..4.."C...............SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.28:5060
10:09:46.295041 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 579
E.._....4...C............K..SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.28:5060;bra
BTW, I thought of two possible issues with the original patch:
1) Might need to call skb_make_writable() prior to modifying the
packet. Presumably the second invocation inside
nf_nat_mangle_udp_packet() will have no effect.
(Is there a cleaner way to mangle just the port number? Most of the
utility functions only help with modifying the data area.)
2) I should probably be checking to make sure request == 0 before
mangling the packet. The current behavior is harmless if the SIP
proxy is on port 5060, but that might not always be the case.
I can roll these, along with any other suggestions, into v2.
^ permalink raw reply
* Attention Please, Investment Initiative From Jozef Ruud Roosevelt.
From: Jozef Ruud Roosevelt @ 2010-11-14 14:47 UTC (permalink / raw)
Attention Please,
I am Jozef Ruud Roosevelt, a Dutch National presently residing in
Newcastle United Kingdom, I have a proposition Involving an investment
initiative in your country economy to discuss with you, It will be of
mutual benefit to both of us, and I believe we can handle it together,
once we have a common understanding and mutual cooperation in the
execution of the modalities. I work with Abn Amro Bank as an auditor.
Should you be interested, please e-mail back to me through this email
address: (jozef.rosevelt@live.co.uk) or you can give me a call (+44 702
4056 175).
I await your earliest response.
Yours Sincerely,
Jozef Ruud Roosevel.
^ permalink raw reply
* [PATCH] net: ipv4: tcp_probe: cleanup snprintf() use
From: Vasiliy Kulikov @ 2010-11-14 17:06 UTC (permalink / raw)
To: kernel-janitors
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev,
linux-kernel
snprintf() returns number of bytes that were copied if there is no overflow.
This code uses return value as number of copied bytes. Theoretically format
string '%lu.%09lu %pI4:%u %pI4:%u %d %#x %#x %u %u %u %u\n' may be expanded
up to 163 bytes. In reality tv.tv_sec is just few bytes instead of 20, 2 ports
are just 5 bytes each instead of 10, length is 5 bytes instead of 10. The rest
is an unstrusted input. Theoretically if tv_sec is big then copy_to_user() would
overflow tbuf.
tbuf was increased to fit in 163 bytes. snprintf() is used to follow return
value semantic.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
Compile tested.
Format length:
20 for '%lu'
1 for '.'
9 for '%09lu'
1 for ' '
15 for '%pI4'
1 for ':'
10 for '%u'
1 for ' '
15 for '%pI4'
1 for ':'
10 for '%u'
1 for ' '
11 for '%d'
1 for ' '
10 for '%#x'
1 for ' '
10 for '%#x'
1 for ' '
10 for '%u'
1 for ' '
10 for '%u'
1 for ' '
10 for '%u'
1 for ' '
10 for '%u'
1 for '\n'
163 for '%lu.%09lu %pI4:%u %pI4:%u %d %#x %#x %u %u %u %u\n'
net/ipv4/tcp_probe.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
index 6211e21..3b7bf19 100644
--- a/net/ipv4/tcp_probe.c
+++ b/net/ipv4/tcp_probe.c
@@ -154,7 +154,7 @@ static int tcpprobe_sprint(char *tbuf, int n)
struct timespec tv
= ktime_to_timespec(ktime_sub(p->tstamp, tcp_probe.start));
- return snprintf(tbuf, n,
+ return scnprintf(tbuf, n,
"%lu.%09lu %pI4:%u %pI4:%u %d %#x %#x %u %u %u %u\n",
(unsigned long) tv.tv_sec,
(unsigned long) tv.tv_nsec,
@@ -174,7 +174,7 @@ static ssize_t tcpprobe_read(struct file *file, char __user *buf,
return -EINVAL;
while (cnt < len) {
- char tbuf[128];
+ char tbuf[164];
int width;
/* Wait for data in buffer */
--
1.7.0.4
^ permalink raw reply related
* [PATCH] tcp: restrict net.ipv4.tcp_adv_min_scale (#20312)
From: Alexey Dobriyan @ 2010-11-14 15:18 UTC (permalink / raw)
To: davem; +Cc: shemminger, netdev
tcp_win_from_space() does the following:
if (sysctl_tcp_adv_win_scale <= 0)
return space >> (-sysctl_tcp_adv_win_scale);
else
return space - (space >> sysctl_tcp_adv_win_scale);
"space" is int.
As per C99 6.5.7 (3) shifting int for 32 or more bits is
undefined behaviour.
Indeed, if sysctl_tcp_adv_win_scale is exactly 32, space >> 32 equals
space and function returns 0;
Which means we busyloop in tcp_fixup_rcvbuf().
Restrict net.ipv4.tcp_adv_win_scale to [-31, 31].
Fix https://bugzilla.kernel.org/show_bug.cgi?id=20312
Steps to reproduce:
echo 32 >/proc/sys/net/ipv4/tcp_adv_win_scale
wget www.kernel.org
[softlockup]
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -26,6 +26,8 @@ static int zero;
static int tcp_retr1_max = 255;
static int ip_local_port_range_min[] = { 1, 1 };
static int ip_local_port_range_max[] = { 65535, 65535 };
+static int _minus_31 = -31;
+static int _31 = 31;
/* Update system visible IP port range */
static void set_local_port_range(int range[2])
@@ -426,7 +428,9 @@ static struct ctl_table ipv4_table[] = {
.data = &sysctl_tcp_adv_win_scale,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &_minus_31,
+ .extra2 = &_31,
},
{
.procname = "tcp_tw_reuse",
^ permalink raw reply
* Re: [PATCH] ipv4: mitigate an integer underflow when comparing tcp timestamps
From: Zhang Le @ 2010-11-14 15:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <1289724745.2743.61.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 3712 bytes --]
On 09:52 Sun 14 Nov , Eric Dumazet wrote:
> Le dimanche 14 novembre 2010 à 15:35 +0800, Zhang Le a écrit :
> > Behind a loadbalancer which does NAT, peer->tcp_ts could be much smaller than
> > req->ts_recent. In this case, theoretically the req should not be ignored.
> >
> > But in fact, it could be ignored, if peer->tcp_ts is so small that the
> > difference between this two number is larger than 2 to the power of 31.
> >
> > I understand that under this situation, timestamp does not make sense any more,
> > because it actually comes from difference machines. However, if anyone
> > ever need to do the same investigation which I have done, this will
> > save some time for him.
> >
> > Signed-off-by: Zhang Le <r0bertz@gentoo.org>
> > ---
> > net/ipv4/tcp_ipv4.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> > index 8f8527d..1eb4974 100644
> > --- a/net/ipv4/tcp_ipv4.c
> > +++ b/net/ipv4/tcp_ipv4.c
> > @@ -1352,8 +1352,8 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
> > peer->v4daddr == saddr) {
> > inet_peer_refcheck(peer);
> > if ((u32)get_seconds() - peer->tcp_ts_stamp < TCP_PAWS_MSL &&
> > - (s32)(peer->tcp_ts - req->ts_recent) >
> > - TCP_PAWS_WINDOW) {
> > + ((s32)(peer->tcp_ts - req->ts_recent) > TCP_PAWS_WINDOW &&
> > + peer->tcp_ts > req->ts_recent)) {
> > NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
> > goto drop_and_release;
> > }
>
> This seems very wrong to me.
>
> Adding a : if (peer->tcp_ts > req->ts_recent) condition is _not_ going
> to help. And it might break some working setups, because of wrap around.
Yeah, you are right. And sorry for overlooking this.
I should have reviewed time_{before,after}'s implementation before posting this.
So it seems we can't do anything to improve this except to add some warning in
documentation. Maybe some comments in the code too.
>
> Really, if you have multiple clients behind a common NAT, you cannot use
> this code at all, since NAT doesnt usually change TCP timestamps.
>
> What about following patch instead ?
>
> [PATCH] doc: extend tcp_tw_recycle documentation
>
> tcp_tw_recycle should not be used on a server if there is a chance
> clients are behind a same NAT. Document this fact before too many users
> discover this too late.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> Documentation/networking/ip-sysctl.txt | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index c7165f4..406f0d5 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -446,7 +446,12 @@ tcp_tso_win_divisor - INTEGER
> tcp_tw_recycle - BOOLEAN
> Enable fast recycling TIME-WAIT sockets. Default value is 0.
> It should not be changed without advice/request of technical
> - experts.
> + experts. If you set it to 1, make sure you dont miss connections
> + attempts (check LINUX_MIB_PAWSPASSIVEREJECTED netstat counter).
> + In particular, this might break if several clients are behind
> + a common NAT device, since their TCP timestamp wont be changed
> + by the NAT. tcp_tw_recycle should be used with care, most
> + probably in private networks.
>
> tcp_tw_reuse - BOOLEAN
> Allow to reuse TIME-WAIT sockets for new connections when it is
>
>
--
Zhang, Le
Gentoo/Loongson Developer
http://zhangle.is-a-geek.org
0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: Fix deadlock
From: Joakim Tjernlund @ 2010-11-14 14:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, netdev
In-Reply-To: <20101112140947.GB28223@oksana.dev.rtsoft.ru>
Anton Vorontsov <cbouatmailru@gmail.com> wrote on 2010/11/12 15:09:47:
>
> On Fri, Nov 12, 2010 at 02:55:09PM +0100, Joakim Tjernlund wrote:
> > This script:
> > while [ 1==1 ] ; do ifconfig eth0 up; usleep 1950000 ;ifconfig eth0 down; dmesg -c ;done
> > causes in just a second or two:
> > INFO: task ifconfig:572 blocked for more than 120 seconds.
> [...]
> > The reason appears to be ucc_geth_stop meets adjust_link as the
> > PHY reports PHY changes. I belive adjust_link hangs somewhere,
> > holding the PHY lock, because ucc_geth_stop disabled the
> > controller HW.
> > Fix is to stop the PHY before disabling the controller.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> It's unclear where exactly adjust_link() hangs, but the patch
> looks as the right thing overall.
Yes, I too cannot find where it is hanging, just that it is hanging somewhere.
I am starting to think it is hanging somewhere else. Anyhow, the hang
goes away 100% when this patch is applied.
Jocke
^ permalink raw reply
* Re: [PATCH update 2] firewire: net: throttle TX queue before running out of tlabels
From: Stefan Richter @ 2010-11-14 13:35 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: netdev, linux1394-devel, linux-kernel
In-Reply-To: <1289735532.24539.12.camel@maxim-laptop>
On 14 Nov, Maxim Levitsky wrote:
> On Sun, 2010-11-14 at 10:25 +0100, Stefan Richter wrote:
>> Maxim Levitsky wrote:
>> > However the 'update 2' (maybe update 1 too, didn't test), lowers
>> > desktop->laptop throughput somewhat.
>> > (250 vs 227 Mbits/s). I tested this many times.
>> >
>> > Actuall raw troughput possible with UDP stream and ether no throttling
>> > or higher packets in flight count (I tested 50/30), it 280 Mbits/s.
>>
>> Good, I will test deeper queues with a few different controllers here. As
>> long as we keep a margin to 64 so that other traffic besides IPover1394 still
>> has a chance to acquire transaction labels, it's OK.
> Just tested the 'update 2' with 8-16 margin. Gives me ~250 Mbits/s TCP
> easily, and ~280 Mbit/s UDP. Pretty much the maximum its possible to get
> out of this hardware.
Good, update below. Tested also with an OS X peer on my side to exclude
throughput regression.
>> > BTW, I still don't understand fully why my laptop sends only at 180
>> > Mbits/s pretty much always regardless of patches or TCP/UDP.
>>
>> If it is not CPU bound, then it is because Ricoh did not optimize the AR DMA
>> unit as well as Texas Instruments did.
> You mean AT, because in the fast case (desktop->laptop), the TI
> transmits and Ricoh receives. In slow case Ricoh receives and TI
> transmits.
Yes, I meant to write 'AT'.
> Anyway speeds of new stack beat the old one by significant margin.
Gap count optimization surely plays a big role in this.
---- 8< ----
[PATCH update 3] firewire: net: throttle TX queue before running out of tlabels
This prevents firewire-net from submitting write requests in fast
succession until failure due to all 64 transaction labels were used up
for unfinished split transactions. The netif_stop/wake_queue API is
used for this purpose.
Without this stop/wake mechanism, datagrams were simply lost whenever
the tlabel pool was exhausted. Plus, tlabel exhaustion by firewire-net
also prevented other unrelated outbound transactions to be initiated.
The chosen queue depth was checked by me to hit the maximum possible
throughput with an OS X peer whose receive DMA is good enough to never
reject requests due to busy inbound request FIFO. Current Linux peers
show a mixed picture of -5%...+15% change in bandwidth; their current
bottleneck are RCODE_BUSY situations (fewer or more, depending on TX
queue depth) due to too small AR buffer in firewire-ohci.
Maxim Levitsky tested this change with similar watermarks with a Linux
peer and some pending firewire-ohci improvements that address the
RCODE_BUSY problem and confirmed that these TX queue limits are good.
Note: This removes some netif_wake_queue from reception code paths.
They were apparently copy&paste artefacts from a nonsensical
netif_wake_queue use in the older eth1394 driver. This belongs only
into the transmit path.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
drivers/firewire/net.c | 59 ++++++++++++++++++++++++-----------------
1 file changed, 35 insertions(+), 24 deletions(-)
Index: b/drivers/firewire/net.c
===================================================================
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -28,8 +28,14 @@
#include <asm/unaligned.h>
#include <net/arp.h>
-#define FWNET_MAX_FRAGMENTS 25 /* arbitrary limit */
-#define FWNET_ISO_PAGE_COUNT (PAGE_SIZE < 16 * 1024 ? 4 : 2)
+/* rx limits */
+#define FWNET_MAX_FRAGMENTS 30 /* arbitrary, > TX queue depth */
+#define FWNET_ISO_PAGE_COUNT (PAGE_SIZE < 16*1024 ? 4 : 2)
+
+/* tx limits */
+#define FWNET_MAX_QUEUED_DATAGRAMS 20 /* < 64 = number of tlabels */
+#define FWNET_MIN_QUEUED_DATAGRAMS 10 /* should keep AT DMA busy enough */
+#define FWNET_TX_QUEUE_LEN FWNET_MAX_QUEUED_DATAGRAMS /* ? */
#define IEEE1394_BROADCAST_CHANNEL 31
#define IEEE1394_ALL_NODES (0xffc0 | 0x003f)
@@ -641,8 +647,6 @@ static int fwnet_finish_incoming_packet(
net->stats.rx_packets++;
net->stats.rx_bytes += skb->len;
}
- if (netif_queue_stopped(net))
- netif_wake_queue(net);
return 0;
@@ -651,8 +655,6 @@ static int fwnet_finish_incoming_packet(
net->stats.rx_dropped++;
dev_kfree_skb_any(skb);
- if (netif_queue_stopped(net))
- netif_wake_queue(net);
return -ENOENT;
}
@@ -784,15 +786,10 @@ static int fwnet_incoming_packet(struct
* Datagram is not complete, we're done for the
* moment.
*/
- spin_unlock_irqrestore(&dev->lock, flags);
-
- return 0;
+ retval = 0;
fail:
spin_unlock_irqrestore(&dev->lock, flags);
- if (netif_queue_stopped(net))
- netif_wake_queue(net);
-
return retval;
}
@@ -892,6 +889,13 @@ static void fwnet_free_ptask(struct fwne
kmem_cache_free(fwnet_packet_task_cache, ptask);
}
+/* Caller must hold dev->lock. */
+static void dec_queued_datagrams(struct fwnet_device *dev)
+{
+ if (--dev->queued_datagrams == FWNET_MIN_QUEUED_DATAGRAMS)
+ netif_wake_queue(dev->netdev);
+}
+
static int fwnet_send_packet(struct fwnet_packet_task *ptask);
static void fwnet_transmit_packet_done(struct fwnet_packet_task *ptask)
@@ -908,7 +912,7 @@ static void fwnet_transmit_packet_done(s
/* Check whether we or the networking TX soft-IRQ is last user. */
free = (ptask->outstanding_pkts == 0 && ptask->enqueued);
if (free)
- dev->queued_datagrams--;
+ dec_queued_datagrams(dev);
if (ptask->outstanding_pkts == 0) {
dev->netdev->stats.tx_packets++;
@@ -979,7 +983,7 @@ static void fwnet_transmit_packet_failed
/* Check whether we or the networking TX soft-IRQ is last user. */
free = ptask->enqueued;
if (free)
- dev->queued_datagrams--;
+ dec_queued_datagrams(dev);
dev->netdev->stats.tx_dropped++;
dev->netdev->stats.tx_errors++;
@@ -1064,7 +1068,7 @@ static int fwnet_send_packet(struct fwne
if (!free)
ptask->enqueued = true;
else
- dev->queued_datagrams--;
+ dec_queued_datagrams(dev);
spin_unlock_irqrestore(&dev->lock, flags);
@@ -1083,7 +1087,7 @@ static int fwnet_send_packet(struct fwne
if (!free)
ptask->enqueued = true;
else
- dev->queued_datagrams--;
+ dec_queued_datagrams(dev);
spin_unlock_irqrestore(&dev->lock, flags);
@@ -1249,6 +1253,15 @@ static netdev_tx_t fwnet_tx(struct sk_bu
struct fwnet_peer *peer;
unsigned long flags;
+ spin_lock_irqsave(&dev->lock, flags);
+
+ /* Can this happen? */
+ if (netif_queue_stopped(dev->netdev)) {
+ spin_unlock_irqrestore(&dev->lock, flags);
+
+ return NETDEV_TX_BUSY;
+ }
+
ptask = kmem_cache_alloc(fwnet_packet_task_cache, GFP_ATOMIC);
if (ptask == NULL)
goto fail;
@@ -1267,9 +1280,6 @@ static netdev_tx_t fwnet_tx(struct sk_bu
proto = hdr_buf.h_proto;
dg_size = skb->len;
- /* serialize access to peer, including peer->datagram_label */
- spin_lock_irqsave(&dev->lock, flags);
-
/*
* Set the transmission type for the packet. ARP packets and IP
* broadcast packets are sent via GASP.
@@ -1291,7 +1301,7 @@ static netdev_tx_t fwnet_tx(struct sk_bu
peer = fwnet_peer_find_by_guid(dev, be64_to_cpu(guid));
if (!peer || peer->fifo == FWNET_NO_FIFO_ADDR)
- goto fail_unlock;
+ goto fail;
generation = peer->generation;
dest_node = peer->node_id;
@@ -1345,7 +1355,8 @@ static netdev_tx_t fwnet_tx(struct sk_bu
max_payload += RFC2374_FRAG_HDR_SIZE;
}
- dev->queued_datagrams++;
+ if (++dev->queued_datagrams == FWNET_MAX_QUEUED_DATAGRAMS)
+ netif_stop_queue(dev->netdev);
spin_unlock_irqrestore(&dev->lock, flags);
@@ -1356,9 +1367,9 @@ static netdev_tx_t fwnet_tx(struct sk_bu
return NETDEV_TX_OK;
- fail_unlock:
- spin_unlock_irqrestore(&dev->lock, flags);
fail:
+ spin_unlock_irqrestore(&dev->lock, flags);
+
if (ptask)
kmem_cache_free(fwnet_packet_task_cache, ptask);
@@ -1415,7 +1426,7 @@ static void fwnet_init_dev(struct net_de
net->addr_len = FWNET_ALEN;
net->hard_header_len = FWNET_HLEN;
net->type = ARPHRD_IEEE1394;
- net->tx_queue_len = 10;
+ net->tx_queue_len = FWNET_TX_QUEUE_LEN;
SET_ETHTOOL_OPS(net, &fwnet_ethtool_ops);
}
--
Stefan Richter
-=====-==-=- =-== -===-
http://arcgraph.de/sr/
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
^ permalink raw reply
* PLEASE REPLY, I NEED YOUR HELP
From: Jurisprudencia @ 2010-11-14 11:48 UTC (permalink / raw)
I am Mrs. Sarah Grant, the wife of Late Mr.Robert Grant, my husband was a business merchant in Russia before he died in the year 2003. When he was alive he deposited the sum of 7.5 Million Pounds with a Bank. Presently, I'm suffering from esophageal cancer, Please Stand-in as the beneficiary and collect the Funds from the Bank to finance Charity Organizations. If interested, please reply to this email address: mrssarahgrant@yahoo.com.hk
^ permalink raw reply
* Re: [PATCH update 2] firewire: net: throttle TX queue before running out of tlabels
From: Maxim Levitsky @ 2010-11-14 11:52 UTC (permalink / raw)
To: Stefan Richter; +Cc: netdev, linux1394-devel, linux-kernel
In-Reply-To: <4CDFAB10.5050800@s5r6.in-berlin.de>
On Sun, 2010-11-14 at 10:25 +0100, Stefan Richter wrote:
> Maxim Levitsky wrote:
> > In fact after lot of testing I see that original patch,
> > '[PATCH 4/4] firewire: net: throttle TX queue before running out of
> > tlabels' works the best here.
> > With AR fixes, I don't see even a single fwnet_write_complete error on
> > ether side.
>
> Well, that version missed that the rx path opened up the tx queue again. I.e.
> it did not work as intended.
>
> > However the 'update 2' (maybe update 1 too, didn't test), lowers
> > desktop->laptop throughput somewhat.
> > (250 vs 227 Mbits/s). I tested this many times.
> >
> > Actuall raw troughput possible with UDP stream and ether no throttling
> > or higher packets in flight count (I tested 50/30), it 280 Mbits/s.
>
> Good, I will test deeper queues with a few different controllers here. As
> long as we keep a margin to 64 so that other traffic besides IPover1394 still
> has a chance to acquire transaction labels, it's OK.
Just tested the 'update 2' with 8-16 margin. Gives me ~250 Mbits/s TCP
easily, and ~280 Mbit/s UDP. Pretty much the maximum its possible to get
out of this hardware.
>
> > BTW, I still don't understand fully why my laptop sends only at 180
> > Mbits/s pretty much always regardless of patches or TCP/UDP.
>
> If it is not CPU bound, then it is because Ricoh did not optimize the AR DMA
> unit as well as Texas Instruments did.
You mean AT, because in the fast case (desktop->laptop), the TI
transmits and Ricoh receives. In slow case Ricoh receives and TI
transmits.
Anyway speeds of new stack beat the old one by significant margin.
Best regards,
Maxim Levitsky
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
^ permalink raw reply
* [PATCH] netfilter: define nat_pptp_info as needed
From: Changli Gao @ 2010-11-14 11:47 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
include/net/netfilter/nf_nat.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/netfilter/nf_nat.h b/include/net/netfilter/nf_nat.h
index f5f09f0..d082938 100644
--- a/include/net/netfilter/nf_nat.h
+++ b/include/net/netfilter/nf_nat.h
@@ -56,7 +56,9 @@ struct nf_nat_multi_range_compat {
/* per conntrack: nat application helper private data */
union nf_conntrack_nat_help {
/* insert nat helper private data here */
+#if defined(CONFIG_NF_NAT_PPTP) || defined(CONFIG_NF_NAT_PPTP_MODULE)
struct nf_nat_pptp nat_pptp_info;
+#endif
};
struct nf_conn;
^ permalink raw reply related
* sky2 for on-board 88e8055 fails to detect mac address
From: Guillaume Leclanche @ 2010-11-14 11:42 UTC (permalink / raw)
To: netdev
Hello,
I use a "Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit Ethernet
Controller".
It seems that the sky2 module doesn't manage to grab the mac address
from the HW :
[ 0.741173] sky2: driver version 1.28
[ 0.741206] sky2 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 0.741216] sky2 0000:02:00.0: setting latency timer to 64
[ 0.741244] sky2 0000:02:00.0: Yukon-2 EC Ultra chip revision 2
[ 0.741339] sky2 0000:02:00.0: irq 44 for MSI/MSI-X
[ 0.744781] sky2 0000:02:00.0: eth0: addr 00:00:00:00:00:00
Of course I can set the mac address manually with "ip link set eth0
addr ..." (and then it works fine) but I guess that's not the normal
behavior from the driver?
I'd be happy to troubleshoot but I'm not very used to kernel
internals, so tell me if you need some output.
Below a few targeted info about my system.
Guillaume
2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8055
PCI-E Gigabit Ethernet Controller
Subsystem: Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit
Ethernet Controller
Flags: bus master, fast devsel, latency 0, IRQ 44
Memory at fe8fc000 (64-bit, non-prefetchable) [size=16K]
I/O ports at a800 [size=256]
Expansion ROM at fe8c0000 [disabled] [size=128K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [5c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: sky2
Kernel modules: sky2
^ permalink raw reply
* Re: Fwd: a Great Idea - include Kademlia networking protocol in kernel -- REVISITED
From: Eric Dumazet @ 2010-11-14 9:39 UTC (permalink / raw)
To: Marcos; +Cc: netdev, Stephen Guerin
In-Reply-To: <AANLkTimkPpWob8ANySeWBvDE+Pq2wy4SQWJOSYzbS7QG@mail.gmail.com>
Le dimanche 14 novembre 2010 à 02:14 -0700, Marcos a écrit :
> > I have no idea why and how kademlia would be added to "linux kernel"
> >
> > Its a protocol based on UDP, and probably already done on userland.
> >
> > What am I missing ?
>
> The idea is to tightly couple it to the operating system to create a
> sort of "super operating system" that is seamless to the application
> layers above. Just like memory stores are tightly integrated as to be
> unnoticeable....
>
But we dont want a "super operating system". We want a good one.
Memory stores done in userland are as fast as memory stores done in
kernel.
Once you need to access files, perform complex searches, timers,
logging, and all the stuff, you really want to do it from userland, in
high level language that many programmers master, or get something that
is too complex/buggy.
^ permalink raw reply
* Re: [PATCH update 2] firewire: net: throttle TX queue before running out of tlabels
From: Stefan Richter @ 2010-11-14 9:25 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux1394-devel, linux-kernel, netdev
In-Reply-To: <1289710228.8581.16.camel@maxim-laptop>
Maxim Levitsky wrote:
> In fact after lot of testing I see that original patch,
> '[PATCH 4/4] firewire: net: throttle TX queue before running out of
> tlabels' works the best here.
> With AR fixes, I don't see even a single fwnet_write_complete error on
> ether side.
Well, that version missed that the rx path opened up the tx queue again. I.e.
it did not work as intended.
> However the 'update 2' (maybe update 1 too, didn't test), lowers
> desktop->laptop throughput somewhat.
> (250 vs 227 Mbits/s). I tested this many times.
>
> Actuall raw troughput possible with UDP stream and ether no throttling
> or higher packets in flight count (I tested 50/30), it 280 Mbits/s.
Good, I will test deeper queues with a few different controllers here. As
long as we keep a margin to 64 so that other traffic besides IPover1394 still
has a chance to acquire transaction labels, it's OK.
> BTW, I still don't understand fully why my laptop sends only at 180
> Mbits/s pretty much always regardless of patches or TCP/UDP.
If it is not CPU bound, then it is because Ricoh did not optimize the AR DMA
unit as well as Texas Instruments did.
--
Stefan Richter
-=====-==-=- =-== -===-
http://arcgraph.de/sr/
^ 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