* [PATCH] revert TCP retransmission backoff on ICMP destination unreachable
From: Damian Lukowski @ 2009-08-11 11:27 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
This patch is a proof-of-concept related to the draft "Make TCP more
Robust to Long Connectivity Disruptions"
(http://tools.ietf.org/html/draft-zimmermann-tcp-lcd-01).
Exponential backoff is TCP's standard behaviour during long connectivity
disruptions, which is a countermeasure against network congestion.
If congestion can be excluded as the reason for RTO retransmission loss,
backoff is not desirable, as it yields longer TCP recovery times, when
the communication path is repaired shortly after an unsuccessful
retransmission probe.
Here, an ICMP host/network unreachable message, whose payload fits to
TCPs SND.UNA, is taken as an indication that the RTO retransmission has
not been lost due to congestion, but because of a route failure
somewhere along the path. On receipt of such a message, the timeout is
halved (in order to revert to doubling after the retransmission).
With true congestion, a router won't trigger such a message and the
patched TCP will operate as standard TCP.
Comments are appreciated, especially regarding eventual side effects
with the zero window probing mechanism.
In Linux, the RTO retransmisson mechanism is coupled to the zero window
probing mechanism, but is not intended to be changed. I hope I have not
missed something, here.
---
[-- Attachment #2: TCP_ICMP_2.6.30.4.patch --]
[-- Type: text/plain, Size: 4322 bytes --]
diff -Naur linux-2.6.30.4-vanilla/include/net/tcp.h linux-2.6.30.4-tcp-icmp/include/net/tcp.h
--- linux-2.6.30.4-vanilla/include/net/tcp.h 2009-07-31 00:34:47.000000000 +0200
+++ linux-2.6.30.4-tcp-icmp/include/net/tcp.h 2009-08-11 11:28:23.162009835 +0200
@@ -1220,6 +1220,8 @@
#define tcp_for_write_queue_from_safe(skb, tmp, sk) \
skb_queue_walk_from_safe(&(sk)->sk_write_queue, skb, tmp)
+#define retrans_overstepped(sk, boundary) (inet_csk(sk)->icsk_retransmits && (tcp_time_stamp - tcp_sk(sk)->retrans_stamp) >= TCP_RTO_MIN*(2 << boundary))
+
static inline struct sk_buff *tcp_send_head(struct sock *sk)
{
return sk->sk_send_head;
diff -Naur linux-2.6.30.4-vanilla/net/ipv4/tcp_ipv4.c linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_ipv4.c
--- linux-2.6.30.4-vanilla/net/ipv4/tcp_ipv4.c 2009-07-31 00:34:47.000000000 +0200
+++ linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_ipv4.c 2009-08-11 11:28:33.572009505 +0200
@@ -332,11 +332,14 @@
{
struct iphdr *iph = (struct iphdr *)skb->data;
struct tcphdr *th = (struct tcphdr *)(skb->data + (iph->ihl << 2));
+
+ struct inet_connection_sock *icsk;
struct tcp_sock *tp;
struct inet_sock *inet;
const int type = icmp_hdr(skb)->type;
const int code = icmp_hdr(skb)->code;
struct sock *sk;
+ struct sk_buff *skb_r;
__u32 seq;
int err;
struct net *net = dev_net(skb->dev);
@@ -367,6 +370,7 @@
if (sk->sk_state == TCP_CLOSE)
goto out;
+ icsk = inet_csk(sk);
tp = tcp_sk(sk);
seq = ntohl(th->seq);
if (sk->sk_state != TCP_LISTEN &&
@@ -393,6 +397,34 @@
}
err = icmp_err_convert[code].errno;
+
+ /* check if ICMP unreachable messages allow revert of back-off */
+ if ((code != ICMP_NET_UNREACH && code != ICMP_HOST_UNREACH) || seq != tp->snd_una
+ || !icsk->icsk_retransmits || !icsk->icsk_backoff) break;
+
+ icsk->icsk_backoff--;
+ icsk->icsk_rto >>= 1;
+
+ skb_r = skb_peek(&sk->sk_write_queue);
+ BUG_ON(!skb_r);
+
+ if (sock_owned_by_user(sk)) {
+ // Deferring retransmission clocked by ICMP due to locked socket.
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
+ min(icsk->icsk_rto, TCP_RESOURCE_PROBE_INTERVAL),
+ TCP_RTO_MAX);
+ }
+
+ if (tcp_time_stamp - TCP_SKB_CB(skb_r)->when > inet_csk(sk)->icsk_rto) {
+ // RTO revert clocked out retransmission.
+ tcp_retransmit_skb(sk, skb_r);
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX);
+ } else {
+ //RTO revert shortened timer.
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
+ icsk->icsk_rto - (tcp_time_stamp - TCP_SKB_CB(skb_r)->when), TCP_RTO_MAX);
+ }
+
break;
case ICMP_TIME_EXCEEDED:
err = EHOSTUNREACH;
diff -Naur linux-2.6.30.4-vanilla/net/ipv4/tcp_timer.c linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_timer.c
--- linux-2.6.30.4-vanilla/net/ipv4/tcp_timer.c 2009-07-31 00:34:47.000000000 +0200
+++ linux-2.6.30.4-tcp-icmp/net/ipv4/tcp_timer.c 2009-08-11 11:28:33.557009931 +0200
@@ -143,7 +143,7 @@
dst_negative_advice(&sk->sk_dst_cache);
retry_until = icsk->icsk_syn_retries ? : sysctl_tcp_syn_retries;
} else {
- if (icsk->icsk_retransmits >= sysctl_tcp_retries1) {
+ if (retrans_overstepped(sk, sysctl_tcp_retries1)) {
/* Black hole detection */
tcp_mtu_probing(icsk, sk);
@@ -156,12 +156,12 @@
retry_until = tcp_orphan_retries(sk, alive);
- if (tcp_out_of_resources(sk, alive || icsk->icsk_retransmits < retry_until))
+ if (tcp_out_of_resources(sk, alive || !retrans_overstepped(sk, retry_until)))
return 1;
}
}
- if (icsk->icsk_retransmits >= retry_until) {
+ if (retrans_overstepped(sk, retry_until)) {
/* Has it gone just too far? */
tcp_write_err(sk);
return 1;
@@ -385,7 +385,7 @@
out_reset_timer:
icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX);
- if (icsk->icsk_retransmits > sysctl_tcp_retries1)
+ if (retrans_overstepped(sk, sysctl_tcp_retries1))
__sk_dst_reset(sk);
out:;
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Bill Fink @ 2009-08-11 7:32 UTC (permalink / raw)
To: Neil Horman
Cc: Andrew Gallatin, Brice Goglin, Linux Network Developers,
Yinghai Lu
In-Reply-To: <20090808183251.GA23300@localhost.localdomain>
On Sat, 8 Aug 2009, Neil Horman wrote:
> On Sat, Aug 08, 2009 at 02:21:36PM -0400, Andrew Gallatin wrote:
> > Neil Horman wrote:
> >> On Sat, Aug 08, 2009 at 07:08:20AM -0400, Andrew Gallatin wrote:
> >>> Bill Fink wrote:
> >>>> On Fri, 07 Aug 2009, Andrew Gallatin wrote:
> >>>>
> >>>>> Bill Fink wrote:
> >>>>>
> >>>>>> All sysfs local_cpus values are the same (00000000,000000ff),
> >>>>>> so yes they are also wrong.
> >>>>> How were you handling IRQ binding? If local_cpus is wrong,
> >>>>> the irqbalance will not be able to make good decisions about
> >>>>> where to bind the NICs' IRQs. Did you try manually binding
> >>>>> each NICs's interrupt to a separate CPU on the correct node?
> >>>> Yes, all the NIC IRQs were bound to a CPU on the local NUMA node,
> >>>> and the nuttcp application had its CPU affinity set to the same
> >>>> CPU with its memory affinity bound to the same local NUMA node.
> >>>> And the irqbalance daemon wasn't running.
> >>> I must be misunderstanding something. I had thought that
> >>> alloc_pages() on NUMA would wind up doing alloc_pages_current(), which
> >>> would allocate based on default policy which (if not interleaved)
> >>> should allocate from the current NUMA node. And since restocking the
> >>> RX ring happens from a the driver's NAPI softirq context, then it
> >>> should always be restocking on the same node the memory is destined to
> >>> be consumed on.
> >>>
> >>> Do I just not understand how alloc_pages() works on NUMA?
> >>>
> >>
> >> Thats how alloc_works, but most drivers use netdev_alloc_skb to refill their rx
> >> ring in their napi context. netdev_alloc_skb specifically allocates an skb from
> >> memory in the node that the actually NIC is local to (rather than the cpu that
> >> the interrupt is running on). That cuts out cross numa node chatter when the
> >> device is dma-ing a frame from the hardware to the allocated skb. The offshoot
> >> of that however (especially in 10G cards with lots of rx queues whos interrupts
> >> are spread out through the system) is that the irq affinity for a given irq has
> >> an increased risk of not being on the same node as the skb memory. The ftrace
> >> module I referenced earlier will help illustrate this, as well as cases where
> >> its causing applications to run on processors that create lots of cross-node
> >> chatter.
> >
> > One thing worth noting is that myri10ge is rather unusual in that
> > it fills its RX rings with pages, then attaches them to skbs after
> > the receive is done. Given how (I think) alloc_page() works, I
> > don't understand why correct CPU binding does not have the same
> > benefit as Bill's patch to assign the NUMA node manually.
> >
> > I'm certainly willing to change to myri10ge to use alloc_pages_node()
> > based on NIC locality, if that provides a benefit, but I'd really
> > like to understand why CPU binding is not helping.
I originally tried to just use alloc_pages_node() instead of alloc_pages(),
but it didn't help. As mentioned in an earlier e-mail, that seems to
be because I discovered that doing:
find /sys -name numa_node -exec grep . {} /dev/null \;
revealed that the NUMA node associated with _all_ the PCI devices was
always 0, when at least some of them should have been associated with
NUMA node 2, including 6 of the 12 Myricom 10-GigE devices.
I discovered today that the NUMA node cpulist/cpumap is also wrong.
A cat of /sys/devices/system/node/node0/cpulist returns "0-7" (with a
cpumask of 00000000,000000ff), while the cpulist for node2 is empty
(with a cpumask of 00000000,00000000). The distance is correct,
with "10 20" for node 0 and "20 10" for node2.
Since there seems to be an underlying kernel issue here, what would
be the proper place to address the apparently incorrect assignment
of NUMA node information for this system?
Even with my hacked workaround, which basically doubled the receive
side performance without my patch, the performance level was still
subpar from what I would have expected should be possible based on
some other tests I ran, such as the following single and multiple
parallel nuttcp loopback tests.
On Asus P6T6 motherboard with single Intel i7 965 3.2 GHz (overclocked
to 3.4 GHz) quad-core processor (non-NUMA):
Single nuttcp loopback test using CPUs 0 and 1:
[root@i7test1 ~]# nuttcp -xc0/1 192.168.1.10
44948.3125 MB / 10.04 sec = 37554.1394 Mbps 99 %TX 75 %RX 0 retrans 0.04 msRTT
Two parallel nuttcp loopback tests using CPUs 0, 1, 2, and 3:
[root@i7test1 ~]# nuttcp -xc0/1 -p5101 192.168.1.10 & nuttcp -xc2/3 -p5102 192.168.1.10 &
43595.0000 MB / 10.04 sec = 36423.4339 Mbps 99 %TX 82 %RX 0 retrans 0.04 msRTT
43384.5000 MB / 10.04 sec = 36247.5115 Mbps 99 %TX 74 %RX 0 retrans 0.02 msRTT
Aggregate performance: 72.6709 Gbps
On SuperMicro X8DAH+-F motherboard with dual Intel Xeon 5580 3.2 GHz
quad-core processors (NUMA):
Single nuttcp loopback test using CPUs 0 and 2 on NUMA node 0:
[root@xeontest1 ~]# nuttcp -xc0/2 192.168.1.14
39348.0000 MB / 10.04 sec = 32875.4865 Mbps 99 %TX 59 %RX 0 retrans 0.06 msRTT
Two parallel nuttcp loopback tests using CPUs 0, 2, 4, and 6 on NUMA node 0:
[root@xeontest1 ~]# nuttcp -xc0/2 -p5101 192.168.1.14 & nuttcp -xc4/6 -p5102 192.168.1.14 &
36197.0625 MB / 10.04 sec = 30245.0918 Mbps 99 %TX 59 %RX 0 retrans 0.06 msRTT
38153.5000 MB / 10.04 sec = 31876.4556 Mbps 99 %TX 75 %RX 0 retrans 0.04 msRTT
Aggregate performance: 62.1215 Gbps
While the performance using a single Xeon 5580 quad-core processor on
the SuperMicro system was 12.5 % to 14.5 % slower than the single i7 965
quad-core processor on the Asus system, when you use both of the Xeon 5580
quad core processors:
Four parallel nuttcp loopback tests using CPUs 0, 2, 4, and 6 on NUMA node 0,
and CPUs 1, 3, 5, and 7 on NUMA node 2:
[root@xeontest1 ~]# nuttcp -xc0/2 -p5101 192.168.1.14 & nuttcp -xc4/6 -p5102 192.168.1.14 & numactl --membind=2 nuttcp -xc1/3 -p5103 192.168.1.14 & numactl --membind=2 nuttcp -xc5/7 -p5104 192.168.1.14 &
36340.4375 MB / 10.04 sec = 30363.2672 Mbps 99 %TX 71 %RX 0 retrans 0.06 msRTT
36344.1250 MB / 10.04 sec = 30365.1838 Mbps 99 %TX 70 %RX 0 retrans 0.04 msRTT
34134.5625 MB / 10.04 sec = 28519.0180 Mbps 98 %TX 67 %RX 0 retrans 0.06 msRTT
34812.6875 MB / 10.04 sec = 29085.5312 Mbps 99 %TX 66 %RX 0 retrans 0.04 msRTT
Aggregate performance: 118.3330 Gbps
Overall the SuperMicro system outperforms the Asus system by 62.8 %.
Since a test between a pair of the i7 test systems achieved an aggregate
performance of ~70 Gbps, and could probably have achieved 80 Gbps except
for a motherboard restriction, it would seem the dual Xeon system should
be able to achieve at least the same level of aggregate performance.
On the transmit side it excels, achieving 100 Gbps. But on the receive
side, even with my hacked workaround, it tops out at 56 Gbps. I would
welcome any further ideas on what might still be limiting the aggregate
receive side performance of the dual Xeon NUMA system.
> Thats hard to say. If binding the app to a cpu on the same node doesn't help,
> that would suggest to me:
>
> 1) That the process binding isn't being honored
> 2) The cpu you're binding to isn't actually on the same node
> 3) The node which the skb's are allocated on is not the one you think it is
> 4) The cross numa chatter is improved, but another problem has taken its place
> (like cpu contention between the process and the interrupt handler on the samme
> cpu)
> 5) The problem is something else entirely.
>
> Either way, I'd suggest applying and running the patch set that I referenced
> previously. It will give you a good table representation of how skbs for this
> process are being allocated and consumed, and let you confirm or eliminate items
> 1-4 above.
Unfortunately I haven't had a chance to try that yet, as I was away
for the weekend and then there was an emergency at work today. But
I will hopefully get a chance to try it out shortly. I had some
initial concerns about just how much trace data would be generated
for a 10-second 10-GigE (or 100-GigE) test, but after doing some
quick calculations for 9000 byte jumbo frames, I guess it's a manageable
amount of data.
-Thanks
-Bill
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Rene Mayrhofer @ 2009-08-11 8:54 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <4A7FF66A.1090506@mayrhofer.eu.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rene Mayrhofer wrote:
> Mike McCormack wrote:
>> Rene Mayrhofer wrote:
>
>>> What would be the simplest change to stop disabling phy when the last
>>> device goes down?
>> Commenting out the following line should stop all the phys from powering off:
>
>> sky2_phy_power_down(hw, port);
>
>> If you have a chance, please test "sky2: Add a mutex around ethtools operations" also.
>> it probably won't fix the problem you're seeing, but you never know...
>
> It seems that hardware is faulty, although in a very "interesting" way.
> We tried changing the "slot" modules with 4 NICs each, which did not
> change matters. However, another similar hardware appliance works.
Actually, it's not. After producing a bit of traffic, we still see the
same issue with the other hardware. It is therefore not likely to be a
real hardware fault in the sense that a specific appliances is broken.
Even after disabling the sky2_phy_power_down call in sky2_down, I get
the oops on restarting the interfaces:
[~]# /etc/init.d/networking restart
Reconfiguring network interfaces...Removed VLAN -:quara.6:-
RTNETLINK answers: Cannot assign requested address
run-parts: /etc/network/if-up.d/40address exited with return code 2
SIOCSIFFLAGS: Cannot assign requested address
Failed to bring up dmz.
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 6 to IF -:testnet:-
Starting radvd: radvd.
done.
[~]#
[~]#
[~]#
[~]# /etc/init.d/networking restart
Reconfiguring network interfaces...[ 707.000123] sky2 0000:01:00.0:
error interrupt status=0xffffffff
[ 707.006858] sky2 0000:01:00.0: PCI hardware error (0xffff)
[ 707.012977] sky2 0000:01:00.0: PCI Express error (0xffffffff)
[ 707.019381] sky2 wan: ram data read parity error
[ 707.024531] sky2 wan: ram data write parity error
[ 707.029775] sky2 wan: MAC parity error
[ 707.033969] sky2 wan: RX parity error
[ 707.038060] sky2 wan: TCP segmentation error
[ 707.042904] BUG: unable to handle kernel NULL pointer dereference at
0000038d
[ 707.046812] IP: [<f8068d2d>] sky2_mac_intr+0x30/0xc1 [sky2]
[ 707.046812] *pde = 00000000
[ 707.046812] Oops: 0000 [#1] PREEMPT SMP
[ 707.046812] last sysfs file:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 707.046812] Modules linked in: xt_multiport cpufreq_userspace
ip6t_REJECT xt_DSCP xt_length xt_mark xt_dscp xt_MARK xt_IMQ xt_CONNMARK
xt_comment xt_policy ip6t_LOG xt_tcpudp ip6table_mangle iptable_mangle
ip6table_filter ip6_tables sit tunnel4 8021q garp stp llc ipt_LOG
xt_limit xt_state iptable_nat iptable_filter ip_tables x_tables dm_mod
p4_clockmod speedstep_lib freq_table tun imq nf_nat_ftp nf_nat
nf_conntrack_ftp nf_conntrack_ipv6 nf_conntrack_ipv4 nf_conntrack
nf_defrag_ipv4 ipv6 evdev parport_pc parport i2c_i801 button i2c_core
iTCO_wdt processor serio_raw rng_core intel_agp pcspkr loop aufs
exportfs nls_utf8 nls_cp437 ide_generic sd_mod ata_generic pata_acpi
ata_piix ide_pci_generic skge ide_core sky2 thermal fan thermal_sys
[ 707.145223]
[ 707.145223] Pid: 11650, comm: 60address Not tainted (2.6.30.4 #3)
[ 707.145223] EIP: 0060:[<f8068d2d>] EFLAGS: 00010286 CPU: 0
[ 707.145223] EIP is at sky2_mac_intr+0x30/0xc1 [sky2]
[ 707.145223] EAX: f8080f88 EBX: 00000001 ECX: 00000008 EDX: 000000ff
[ 707.169707] ESI: 00000000 EDI: f68c8e80 EBP: e1983c08 ESP: e1983bf0
[ 707.169707] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 707.169707] Process 60address (pid: 11650, ti=e1982000 task=dc0ce030
task.ti=e1982000)
[ 707.195323] Stack:
[ 707.195323] 00000080 ff8c8e80 6f11c339 f71cef60 ffffffff ffffffff
e1983c94 f806c064
[ 707.195323] c04ee377 6f11c339 00000040 f68c8e88 f70c4bcc 00000000
f68c8e80 ffffffff
[ 707.212226] e1983ca4 f71d5800 c0243594 00000000 c06b7134 f707c230
00000001 00000000
[ 707.212226] Call Trace:
[ 707.212226] [<f806c064>] ? sky2_poll+0x1d2/0xb66 [sky2]
[ 707.232409] [<c04ee377>] ? _spin_unlock+0x29/0x3c
[ 707.232409] [<c0243594>] ? insert_work+0xa5/0xbf
[ 707.232409] [<c047732c>] ? __qdisc_run+0x73/0x1ca
[ 707.245403] [<c0463cf6>] ? net_rx_action+0x9e/0x1a2
[ 707.245403] [<c0237b6e>] ? __do_softirq+0xb2/0x188
[ 707.245403] [<c0237c83>] ? do_softirq+0x3f/0x5c
[ 707.245403] [<c0237e0d>] ? irq_exit+0x37/0x80
[ 707.245403] [<c0213cfd>] ? smp_apic_timer_interrupt+0x7c/0x9b
[ 707.245403] [<c02037dd>] ? apic_timer_interrupt+0x31/0x38
[ 707.245403] [<c029804c>] ? unmap_vmas+0x1df/0x655
[ 707.245403] [<c028d170>] ? ____pagevec_lru_add+0x10b/0x12a
[ 707.245403] [<c029c293>] ? exit_mmap+0xb8/0x158
[ 707.295480] [<c02305e1>] ? mmput+0x2f/0xa5
[ 707.295480] [<c02b43b1>] ? flush_old_exec+0x3a0/0x630
[ 707.295480] [<c02b46da>] ? kernel_read+0x40/0x63
[ 707.295480] [<c02e25e9>] ? load_elf_binary+0x355/0x11e4
[ 707.295480] [<c0299591>] ? __get_user_pages+0x28f/0x310
[ 707.295480] [<c029964a>] ? get_user_pages+0x38/0x50
[ 707.295480] [<c02b3825>] ? get_arg_page+0x38/0x9c
[ 707.295480] [<c02b3b80>] ? search_binary_handler+0xed/0x273
[ 707.295480] [<c02e2294>] ? load_elf_binary+0x0/0x11e4
[ 707.345549] [<c02b4ed8>] ? do_execve+0x24d/0x35c
[ 707.345549] [<c02016f0>] ? sys_execve+0x34/0x6d
[ 707.345549] [<c0202df3>] ? sysenter_do_call+0x12/0x28
[ 707.345549] Code: c7 56 53 89 d3 83 ec 0c 65 a1 14 00 00 00 89 45 f0
31 c0 8b 74 97 3c c1 e2 07 89 d0 05 08 0f 00 00 89 55 e8 03 07 8a 10 88
55 ef <f6> 86 8d 03 00 00 02 74 12 0f b6 c2 50 56 68 b4 e3 06 f8 e8 f3
[ 707.345549] EIP: [<f8068d2d>] sky2_mac_intr+0x30/0xc1 [sky2] SS:ESP
0068:e1983bf0
[ 707.395629] CR2: 000000000000038d
[ 707.401711] ---[ end trace 78f2d616187daf45 ]---
[ 707.406932] Kernel panic - not syncing: Fatal exception in interrupt
Message from[ 707.414147] Pid: 11650, comm: 60address Tainted: G D
2.6.30.4 #3
syslogd@gibralt[ 707.423018] Call Trace:
ar3-esys-master [ 707.427230] [<c04eb055>] ? printk+0x1d/0x30
at Aug 11 10:47:[ 707.433435] [<c04eaf93>] panic+0x53/0xf8
03 ...
kernel[ 707.439358] [<c0206368>] oops_end+0x9f/0xbf
:[ 707.046812] [ 707.445562] [<c021ceb4>] no_context+0x11a/0x135
Oops: 0000 [#1] [ 707.452146] [<c021d005>]
__bad_area_nosemaphore+0x136/0x14f
PREEMPT SMP
[ 707.459910] [<c0374f70>] ? vsnprintf+0x91/0x332
Message from [ 707.466510] [<c04ee2bd>] ?
_spin_unlock_irqrestore+0x31/0x44
syslogd@gibralta[ 707.474345] [<c04ee2bd>] ?
_spin_unlock_irqrestore+0x31/0x44
r3-esys-master a[ 707.482190] [<c0232f4f>] ?
release_console_sem+0x18b/0x1c9
t Aug 11 10:47:0[ 707.489813] [<c021d03b>]
bad_area_nosemaphore+0x1d/0x34
3 ...
kernel:[ 707.497163] [<c021d30b>] do_page_fault+0x110/0x21b
[ 707.046812] l[ 707.504052] [<c021d1fb>] ? do_page_fault+0x0/0x21b
ast sysfs file: [ 707.510906] [<c04ee732>] error_code+0x7a/0x80
/sys/devices/sys[ 707.517321] [<c037007b>] ? add_uevent_var+0x7/0xb9
tem/cpu/cpu0/cpu[ 707.524189] [<f8068d2d>] ? sky2_mac_intr+0x30/0xc1
[sky2]
freq/scaling_set[ 707.531735] [<f806c064>] sky2_poll+0x1d2/0xb66
[sky2]
speed
Mess[ 707.538873] [<c04ee377>] ? _spin_unlock+0x29/0x3c
age from syslogd[ 707.545648] [<c0243594>] ? insert_work+0xa5/0xbf
@gibraltar3-esys[ 707.552333] [<c047732c>] ? __qdisc_run+0x73/0x1ca
- -master at Aug 1[ 707.559115] [<c0463cf6>] net_rx_action+0x9e/0x1a2
[ 707.565893] [<c0237b6e>] __do_softirq+0xb2/0x188
kernel:[ 707.[ 707.572571] [<c0237c83>] do_softirq+0x3f/0x5c
169707] Process [ 707.578968] [<c0237e0d>] irq_exit+0x37/0x80
60address (pid: [ 707.585194] [<c0213cfd>]
smp_apic_timer_interrupt+0x7c/0x9b
11650, ti=e19820[ 707.592938] [<c02037dd>]
apic_timer_interrupt+0x31/0x38
00 task=dc0ce030[ 707.600296] [<c029804c>] ? unmap_vmas+0x1df/0x655
task.ti=e198200[ 707.607074] [<c028d170>] ?
____pagevec_lru_add+0x10b/0x12a
0)
Message[ 707.614707] [<c029c293>] exit_mmap+0xb8/0x158
from syslogd@gi[ 707.621097] [<c02305e1>] mmput+0x2f/0xa5
braltar3-esys-ma[ 707.627024] [<c02b43b1>] flush_old_exec+0x3a0/0x630
ster at Aug 11 1[ 707.633988] [<c02b46da>] ? kernel_read+0x40/0x63
0:47:03 ...
k[ 707.640669] [<c02e25e9>] load_elf_binary+0x355/0x11e4
ernel:[ 707.195[ 707.647821] [<c0299591>] ? __get_user_pages+0x28f/0x310
323] Stack:
[ 707.655179] [<c029964a>] ? get_user_pages+0x38/0x50
Message from s[ 707.662148] [<c02b3825>] ? get_arg_page+0x38/0x9c
yslogd@gibraltar[ 707.668929] [<c02b3b80>]
search_binary_handler+0xed/0x273
3-esys-master at[ 707.676471] [<c02e2294>] ?
load_elf_binary+0x0/0x11e4
Aug 11 10:47:03[ 707.683677] [<c02b4ed8>] do_execve+0x24d/0x35c
...
kernel:[[ 707.690143] [<c02016f0>] sys_execve+0x34/0x6d
707.195323] c[ 707.696519] [<c0202df3>] sysenter_do_call+0x12/0x28
04ee377 6f11c339[ 707.703480] Rebooting in 30 seconds..
Thus, there really seems to be an uncaught case in sky2.c. When
sky2_phy_power_down is not called, chip should not go down, right? But
still sky2_poll seems to be called (maybe by an interrupt belonging to
another network interface but the same chip)?
Any other hints?
Rene
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqBMdoACgkQq7SPDcPCS94SugCguCfe45JB+nNi+jE28JynRWtX
2M4Ani/SHmCaslHWy9gf0UT2Egp6Ql1+
=K4Qh
-----END PGP SIGNATURE-----
^ permalink raw reply
* swapper Not tainted 2.6.29.6
From: Bernard Pidoux F6BVP @ 2009-08-11 10:23 UTC (permalink / raw)
Cc: netdev, linux-kernel, linux-hams
In-Reply-To: <20090321.133428.05663162.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
Running kernel 2.6.29.6 compiled without SMP option there was a kernel panic.
I don't know if it is related to /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
or to AX25 module or a configuration problem.
Here is the netconsole capture.
[-- Attachment #2: nc_u_l_p_6666 --]
[-- Type: text/plain, Size: 3458 bytes --]
BUG: unable to handle kernel paging request at ffff880004c90648
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 7e2067 PTE 4c90160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm i2c_viapro snd_timer snd_page_alloc snd_mixer_oss snd i2c_core soundcore sr_mod 8139cp 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos thermal via_agp processor evdev button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff880004c90400 RCX: 0000000000000058
RDX: ffffe200009cb3d8 RSI: ffffffff8067f060 RDI: ffff880004c90618
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 0000000000000490
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff880004c90618
R13: ffff880004c90400 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff880004c90648 CR3: 0000000074843000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff880004c90400 ffff880004c90400 ffff880004c90400 ffffffffa035bb30
ffffffff80717e30 ffffffffa035b850 ffffffff80717e60 ffffffffa035edb4
ffff880004c90400 ffff880004c90400 0000000000000000 ffffffffa035bb30
Call Trace:
<IRQ> <0> [<ffffffffa035bb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa035b850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa035edb4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa035bb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa035b045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa035bb55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff880004c90648
---[ end trace 366e8cf762bbf316 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
^ permalink raw reply
* Re: [Bugme-new] [Bug 13954] New: Oops in rtnetlink code when creating can device
From: Oliver Hartkopp @ 2009-08-11 9:26 UTC (permalink / raw)
To: Patrick McHardy
Cc: Andrew Morton, Wolfgang Grandegger, dbaryshkov, bugzilla-daemon,
bugme-daemon, Thuermann, Urs, Dr. (K-EFFI/I), Lothar Wassmann,
netdev
In-Reply-To: <4A812A3C.10207@trash.net>
Patrick McHardy wrote:
> Oliver Hartkopp wrote:
>
>>>> I've got a nice oops when looking around new CAN code in kernel.
>>>>
>>>> root@qemux86:~# ip link add type can
>>>> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference
>>>> at (null)
>>>> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420
>>>> ...
>>>>
>> The problem is, that
>>
>> ip link add type can
>>
>> is not possible as you can not create 'real' CAN devices like can0,
>> can1, ...
>>
>> To create 'software CAN devices' like vcan0, vcan1, vcan2, ... we use
>>
>> ip link add type vcan
>>
>> see drivers/net/can/vcan.c
>>
>> ---
>>
>> For real hardware CAN devices the netlink interface is only used for the
>> configuration of already existing interfaces.
>> From a quick view on the rtnl_newlink() function in net/core/rtnetlink.c
>> i was not able to find any method to disallow the creation of
>> interfaces, will say: How can a netlink user provide the information,
>> that he's not able to create new devices via netlink???
>>
>> @Patrick: Do you have an idea for this? Is it a new use-case for netlink
>> that needs to be implemented?
>>
>
> You could add a ->newlink() function that unconditionally returns
> an error.
>
>
Yes, that fixed it.
I created a can_newlink() function just returning -EINVAL ...
I'll cook a patch and send it on netdev (when it gets online again).
Thanks (to all),
Oliver
^ permalink raw reply
* Re: [Bugme-new] [Bug 13954] New: Oops in rtnetlink code when creating can device
From: Patrick McHardy @ 2009-08-11 9:33 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Andrew Morton, Wolfgang Grandegger, dbaryshkov, bugzilla-daemon,
bugme-daemon, Thuermann, Urs, Dr. (K-EFFI/I), Lothar Wassmann,
netdev
In-Reply-To: <4A813963.10407@volkswagen.de>
Oliver Hartkopp wrote:
>>> For real hardware CAN devices the netlink interface is only used for the
>>> configuration of already existing interfaces.
>>> From a quick view on the rtnl_newlink() function in net/core/rtnetlink.c
>>> i was not able to find any method to disallow the creation of
>>> interfaces, will say: How can a netlink user provide the information,
>>> that he's not able to create new devices via netlink???
>>>
>>> @Patrick: Do you have an idea for this? Is it a new use-case for netlink
>>> that needs to be implemented?
>>>
>>
>> You could add a ->newlink() function that unconditionally returns
>> an error.
>>
>>
>
> Yes, that fixed it.
>
> I created a can_newlink() function just returning -EINVAL ...
>
> I'll cook a patch and send it on netdev (when it gets online again).
I'd suggest to use EOPNOTSUPP for consistency.
^ permalink raw reply
* Re: [Bugme-new] [Bug 13954] New: Oops in rtnetlink code when creating can device
From: Patrick McHardy @ 2009-08-11 8:22 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Andrew Morton, Wolfgang Grandegger, dbaryshkov, bugzilla-daemon,
bugme-daemon, Thuermann, Urs, Dr. (K-EFFI/I), Lothar Wassmann,
netdev
In-Reply-To: <4A812354.8090704@volkswagen.de>
Oliver Hartkopp wrote:
>>> I've got a nice oops when looking around new CAN code in kernel.
>>>
>>> root@qemux86:~# ip link add type can
>>> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference
>>> at (null)
>>> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420
>>> ...
> The problem is, that
>
> ip link add type can
>
> is not possible as you can not create 'real' CAN devices like can0,
> can1, ...
>
> To create 'software CAN devices' like vcan0, vcan1, vcan2, ... we use
>
> ip link add type vcan
>
> see drivers/net/can/vcan.c
>
> ---
>
> For real hardware CAN devices the netlink interface is only used for the
> configuration of already existing interfaces.
> From a quick view on the rtnl_newlink() function in net/core/rtnetlink.c
> i was not able to find any method to disallow the creation of
> interfaces, will say: How can a netlink user provide the information,
> that he's not able to create new devices via netlink???
>
> @Patrick: Do you have an idea for this? Is it a new use-case for netlink
> that needs to be implemented?
You could add a ->newlink() function that unconditionally returns
an error.
^ permalink raw reply
* [PATCH 2.6.31-rc5] can: fix oops caused by wrong rtnl newlink usage
From: Oliver Hartkopp @ 2009-08-11 12:41 UTC (permalink / raw)
To: David Miller
Cc: Patrick McHardy, Wolfgang Grandegger, Linux Netdev List,
Dmitry Eremin-Solenikov
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
For 'real' hardware CAN devices the netlink interface is used to set CAN
specific communication parameters. Real CAN hardware can not be created with
the ip tool ...
The invocation of 'ip link add type can' lead to an oops as the standard rtnl
newlink function was called:
http://bugzilla.kernel.org/show_bug.cgi?id=13954
This patch adds a private newlink function for the CAN device driver interface
that unconditionally returns -EOPNOTSUPP.
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Reported-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
CC: Patrick McHardy <kaber@trash.net>
CC: Wolfgang Grandegger <wg@grandegger.com>
---
[-- Attachment #2: can_newlink_oops_fix.patch --]
[-- Type: text/x-patch, Size: 616 bytes --]
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 9e4283a..e1a4f82 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -611,11 +611,18 @@ nla_put_failure:
return -EMSGSIZE;
}
+static int can_newlink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ return -EOPNOTSUPP;
+}
+
static struct rtnl_link_ops can_link_ops __read_mostly = {
.kind = "can",
.maxtype = IFLA_CAN_MAX,
.policy = can_policy,
.setup = can_setup,
+ .newlink = can_newlink,
.changelink = can_changelink,
.fill_info = can_fill_info,
.fill_xstats = can_fill_xstats,
^ permalink raw reply related
* Re: [Bugme-new] [Bug 13954] New: Oops in rtnetlink code when creating can device
From: Oliver Hartkopp @ 2009-08-11 9:36 UTC (permalink / raw)
To: Patrick McHardy
Cc: Andrew Morton, Wolfgang Grandegger, dbaryshkov, bugzilla-daemon,
bugme-daemon, Thuermann, Urs, Dr. (K-EFFI/I), Lothar Wassmann,
netdev
In-Reply-To: <4A813AEF.7000002@trash.net>
Patrick McHardy wrote:
>
>>> You could add a ->newlink() function that unconditionally returns
>>> an error.
>>>
>>>
>>>
>> Yes, that fixed it.
>>
>> I created a can_newlink() function just returning -EINVAL ...
>>
>> I'll cook a patch and send it on netdev (when it gets online again).
>>
>
> I'd suggest to use EOPNOTSUPP for consistency.
>
>
Ok. Will do so.
Thanks!
Oliver
^ permalink raw reply
* multicast over nbma gre tunnels
From: Timo Teräs @ 2009-08-11 8:07 UTC (permalink / raw)
To: netdev
Hi,
I'm trying to figure out the proper way to do multicast forwarding
over nbma gre tunnels. Currently, the userland opennhrp daemon just
listens of packet socket, and calls sendto() for each target it
wants to forward it. Obviously this is slow.
I started to look at how to do it kernel. And I'm playing with the
multicast forwarding code, and tried something like below (see patch
at end of mail).
However, there's several draw backs to this:
- ABI breaks: MAXVIFS is changed (used in userland visible struct)
- it does not forward locally originating link-local multicast
traffic (it does not traverse through mcast forwarding code)
- there can be only one mrouter application, so I can't have
opennhrp manage the gre device, and some app managing the
forwarding between interfaces
It looks like to me that the multicast forwarding code would need
a rewrite anyway, using netlink so that it can be managed by
multiple apps without hard limits such as MAXVIFS.
But then again, I'm thinking if the gre nbma part should be made
part of ipmr.c (have "vifs" for each nbma entity; and hook
link-local traffic to ipmr.c too) or ip_gre.c (specific api for
managing the nbma forwardings within gre code).
The other problem is that, each multicast packet could be
forwarded to, say hundred nodes, via same physical eth. I'm
wonder if just copying the skb hundred times and queuing them
on same device causes problems? Any suggestions how this could
be done in a smart way?
Incidentally, I noticed that using this, and having multicast
sender send to gre1, with forwarding gre1->multiple gre1 nbma
destinations, the sender application had a large soft-irq
usage. Forwarding from real interface to multiple nbma
destinations seemed had the expected cpu usage level. I suppose
I introduced (or there exists) some sort of routing loop that
the packets got handled TTL times, instead of once per packet.
Thanks,
Timo
diff --git a/include/linux/mroute.h b/include/linux/mroute.h
index 0d45b4e..406ef6f 100644
--- a/include/linux/mroute.h
+++ b/include/linux/mroute.h
@@ -33,7 +33,7 @@
#define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
-#define MAXVIFS 32
+#define MAXVIFS 256
typedef unsigned long vifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short vifi_t;
#define ALL_VIFS ((vifi_t)(-1))
@@ -66,6 +66,7 @@ struct vifctl {
#define VIFF_TUNNEL 0x1 /* IPIP tunnel */
#define VIFF_SRCRT 0x2 /* NI */
#define VIFF_REGISTER 0x4 /* register vif */
+#define VIFF_NBMA 0x10
/*
* Cache manipulation structures for mrouted and PIMd
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 13e9dd3..43c988b 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -105,6 +105,31 @@ static struct net_protocol pim_protocol;
static struct timer_list ipmr_expire_timer;
+static __be32 ipmr_get_skb_nbma(struct sk_buff *skb)
+{
+ union {
+ char addr[MAX_ADDR_LEN];
+ __be32 inaddr;
+ } u;
+
+ if (dev_parse_header(skb, u.addr) != 4)
+ return INADDR_ANY;
+
+ return u.inaddr;
+}
+
+static int ip_mr_match_vif_skb(struct vif_device *vif, struct sk_buff *skb)
+{
+ if (vif->dev != skb->dev)
+ return 0;
+
+ if (vif->flags & VIFF_NBMA)
+ return ipmr_get_skb_nbma(skb) == vif->remote;
+
+ return 1;
+}
+
+
/* Service routines creating virtual interfaces: DVMRP tunnels and PIMREG */
static void ipmr_del_tunnel(struct net_device *dev, struct vifctl *v)
@@ -470,6 +495,7 @@ static int vif_add(struct net *net, struct vifctl *vifc, int mrtsock)
return err;
}
break;
+ case VIFF_NBMA:
case 0:
dev = ip_dev_find(net, vifc->vifc_lcl_addr.s_addr);
if (!dev)
@@ -504,7 +530,7 @@ static int vif_add(struct net *net, struct vifctl *vifc, int mrtsock)
v->pkt_in = 0;
v->pkt_out = 0;
v->link = dev->ifindex;
- if (v->flags&(VIFF_TUNNEL|VIFF_REGISTER))
+ if (v->flags&(VIFF_TUNNEL|VIFF_REGISTER|VIFF_NBMA))
v->link = dev->iflink;
/* And finish update writing critical data */
@@ -1212,12 +1238,15 @@ static inline int ipmr_forward_finish(struct sk_buff *skb)
{
struct ip_options * opt = &(IPCB(skb)->opt);
- IP_INC_STATS_BH(dev_net(skb->dst->dev), IPSTATS_MIB_OUTFORWDATAGRAMS);
+ IP_INC_STATS_BH(dev_net(skb->dev), IPSTATS_MIB_OUTFORWDATAGRAMS);
if (unlikely(opt->optlen))
ip_forward_options(skb);
- return dst_output(skb);
+ if (skb->dst != NULL)
+ return dst_output(skb);
+ else
+ return dev_queue_xmit(skb);
}
/*
@@ -1230,7 +1259,8 @@ static void ipmr_queue_xmit(struct sk_buff *skb, struct mfc_cache *c, int vifi)
const struct iphdr *iph = ip_hdr(skb);
struct vif_device *vif = &net->ipv4.vif_table[vifi];
struct net_device *dev;
- struct rtable *rt;
+ struct net_device *fromdev = skb->dev;
+ struct rtable *rt = NULL;
int encap = 0;
if (vif->dev == NULL)
@@ -1257,6 +1287,19 @@ static void ipmr_queue_xmit(struct sk_buff *skb, struct mfc_cache *c, int vifi)
if (ip_route_output_key(net, &rt, &fl))
goto out_free;
encap = sizeof(struct iphdr);
+ dev = rt->u.dst.dev;
+ } else if (vif->flags&VIFF_NBMA) {
+ /* Fixme, we should take tunnel source address from the
+ * tunnel device binding if it exists */
+ struct flowi fl = { .oif = vif->link,
+ .nl_u = { .ip4_u =
+ { .daddr = vif->remote,
+ .tos = RT_TOS(iph->tos) } },
+ .proto = IPPROTO_GRE };
+ if (ip_route_output_key(&init_net, &rt, &fl))
+ goto out_free;
+ encap = LL_RESERVED_SPACE(rt->u.dst.dev);
+ dev = vif->dev;
} else {
struct flowi fl = { .oif = vif->link,
.nl_u = { .ip4_u =
@@ -1265,34 +1308,39 @@ static void ipmr_queue_xmit(struct sk_buff *skb, struct mfc_cache *c, int vifi)
.proto = IPPROTO_IPIP };
if (ip_route_output_key(net, &rt, &fl))
goto out_free;
+ dev = rt->u.dst.dev;
}
- dev = rt->u.dst.dev;
+ if (!(vif->flags & VIFF_NBMA)) {
+ if (skb->len+encap > dst_mtu(&rt->u.dst) && (ntohs(iph->frag_off) & IP_DF)) {
+ /* Do not fragment multicasts. Alas, IPv4 does not
+ allow to send ICMP, so that packets will disappear
+ to blackhole.
+ */
- if (skb->len+encap > dst_mtu(&rt->u.dst) && (ntohs(iph->frag_off) & IP_DF)) {
- /* Do not fragment multicasts. Alas, IPv4 does not
- allow to send ICMP, so that packets will disappear
- to blackhole.
- */
-
- IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
- ip_rt_put(rt);
- goto out_free;
+ IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
+ goto out_free_rt;
+ }
}
encap += LL_RESERVED_SPACE(dev) + rt->u.dst.header_len;
- if (skb_cow(skb, encap)) {
- ip_rt_put(rt);
- goto out_free;
- }
+ if (skb_cow(skb, encap))
+ goto out_free_rt;
vif->pkt_out++;
vif->bytes_out += skb->len;
dst_release(skb->dst);
- skb->dst = &rt->u.dst;
+ if (vif->flags & VIFF_NBMA) {
+ ip_rt_put(rt);
+ skb->dst = NULL;
+ rt = NULL;
+ } else {
+ skb->dst = &rt->u.dst;
+ }
ip_decrease_ttl(ip_hdr(skb));
+ skb->dev = dev;
/* FIXME: forward and output firewalls used to be called here.
* What do we do with netfilter? -- RR */
@@ -1301,6 +1349,10 @@ static void ipmr_queue_xmit(struct sk_buff *skb, struct mfc_cache *c, int vifi)
/* FIXME: extra output firewall step used to be here. --RR */
vif->dev->stats.tx_packets++;
vif->dev->stats.tx_bytes += skb->len;
+ } else if (vif->flags & VIFF_NBMA) {
+ if (dev_hard_header(skb, dev, ntohs(skb->protocol),
+ &vif->remote, NULL, 4) < 0)
+ goto out_free_rt;
}
IPCB(skb)->flags |= IPSKB_FORWARDED;
@@ -1316,21 +1368,30 @@ static void ipmr_queue_xmit(struct sk_buff *skb, struct mfc_cache *c, int vifi)
* not mrouter) cannot join to more than one interface - it will
* result in receiving multiple packets.
*/
- NF_HOOK(PF_INET, NF_INET_FORWARD, skb, skb->dev, dev,
+ NF_HOOK(PF_INET, NF_INET_FORWARD, skb, fromdev, dev,
ipmr_forward_finish);
return;
+out_free_rt:
+ if (rt != NULL)
+ ip_rt_put(rt);
out_free:
kfree_skb(skb);
return;
}
-static int ipmr_find_vif(struct net_device *dev)
+static int ipmr_find_vif(struct net_device *dev, __be32 nbma_origin)
{
struct net *net = dev_net(dev);
int ct;
for (ct = net->ipv4.maxvif-1; ct >= 0; ct--) {
- if (net->ipv4.vif_table[ct].dev == dev)
+ if (net->ipv4.vif_table[ct].dev != dev)
+ continue;
+
+ if (net->ipv4.vif_table[ct].flags & VIFF_NBMA) {
+ if (net->ipv4.vif_table[ct].remote == nbma_origin)
+ break;
+ } else if (nbma_origin == INADDR_ANY)
break;
}
return ct;
@@ -1351,7 +1412,7 @@ static int ip_mr_forward(struct sk_buff *skb, struct mfc_cache *cache, int local
/*
* Wrong interface: drop packet and (maybe) send PIM assert.
*/
- if (net->ipv4.vif_table[vif].dev != skb->dev) {
+ if (!ip_mr_match_vif_skb(&net->ipv4.vif_table[vif], skb)) {
int true_vifi;
if (skb->rtable->fl.iif == 0) {
@@ -1370,7 +1431,7 @@ static int ip_mr_forward(struct sk_buff *skb, struct mfc_cache *cache, int local
}
cache->mfc_un.res.wrong_if++;
- true_vifi = ipmr_find_vif(skb->dev);
+ true_vifi = ipmr_find_vif(skb->dev, ipmr_get_skb_nbma(skb));
if (true_vifi >= 0 && net->ipv4.mroute_do_assert &&
/* pimsm uses asserts, when switching from RPT to SPT,
@@ -1479,7 +1540,7 @@ int ip_mr_input(struct sk_buff *skb)
skb = skb2;
}
- vif = ipmr_find_vif(skb->dev);
+ vif = ipmr_find_vif(skb->dev, ipmr_get_skb_nbma(skb));
if (vif >= 0) {
int err = ipmr_cache_unresolved(net, vif, skb);
read_unlock(&mrt_lock);
@@ -1663,7 +1724,7 @@ int ipmr_get_route(struct net *net,
}
dev = skb->dev;
- if (dev == NULL || (vif = ipmr_find_vif(dev)) < 0) {
+ if (dev == NULL || (vif = ipmr_find_vif(dev, INADDR_ANY)) < 0) {
read_unlock(&mrt_lock);
return -ENODEV;
}
^ permalink raw reply related
* Re: [Bugme-new] [Bug 13954] New: Oops in rtnetlink code when creating can device
From: Oliver Hartkopp @ 2009-08-11 7:52 UTC (permalink / raw)
To: Andrew Morton, kaber, Wolfgang Grandegger
Cc: dbaryshkov, bugzilla-daemon, bugme-daemon,
Thuermann, Urs, Dr. (K-EFFI/I), Lothar Wassmann, netdev
In-Reply-To: <20090810215436.0bf47297.akpm@linux-foundation.org>
Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Mon, 10 Aug 2009 11:34:28 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
>
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=13954
>>
>
> Thanks.
>
>
>> Summary: Oops in rtnetlink code when creating can device
>> Product: Networking
>> Version: 2.5
>> Kernel Version: 2.6.30-rc5
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Other
>> AssignedTo: acme@ghostprotocols.net
>> ReportedBy: dbaryshkov@gmail.com
>> Regression: No
>>
>>
>> I've got a nice oops when looking around new CAN code in kernel.
>>
>> root@qemux86:~# ip link add type can
>> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference at (null)
>> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420
>> [ 713.114920] *pdpt = 00000000061bd001 *pde = 0000000000000000
>> [ 713.115627] Oops: 0000 [#1] SMP
>> [ 713.115972] last sysfs file:
>> /sys/devices/virtual/backlight/fujitsu-laptop/brightness
>> [ 713.116137] Modules linked in:
>> [ 713.116137]
>> [ 713.116137] Pid: 1803, comm: ip Not tainted (2.6.31-rc5 #68)
>> [ 713.116137] EIP: 0060:[<c13eecab>] EFLAGS: 00000246 CPU: 0
>> [ 713.116137] EIP is at register_netdevice+0xab/0x420
>> [ 713.116137] EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000001
>> [ 713.116137] ESI: c72c6000 EDI: 00000000 EBP: c61abb54 ESP: c61abb34
>> [ 713.116137] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>> [ 713.116137] Process ip (pid: 1803, ti=c61aa000 task=c6f395e0
>> task.ti=c61aa000)
>> [ 713.116137] Stack:
>> [ 713.116137] c61abb54 c13f732f 00000001 c61abbb4 894f908a 00000000 c72c6000
>> 00000000
>> [ 713.116137] <0> c61abc74 c13f8278 c61abbb4 00000010 c165d494 c1652090
>> c61abc18 c6f3d028
>> [ 713.116137] <0> 894f908a 894f908a c61abc18 c13f7da0 c61abc74 c13f7f46
>> 00000008 c1546f80
>> [ 713.116137] Call Trace:
>> [ 713.116137] [<c13f732f>] ? rtnl_create_link+0x4f/0x130
>> [ 713.116137] [<c13f8278>] ? rtnl_newlink+0x4d8/0x4e0
>> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0
>> [ 713.116137] [<c13f7f46>] ? rtnl_newlink+0x1a6/0x4e0
>> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0
>> [ 713.116137] [<c13f7d00>] ? rtnetlink_rcv_msg+0x180/0x220
>> [ 713.116137] [<c13f7b80>] ? rtnetlink_rcv_msg+0x0/0x220
>> [ 713.116137] [<c1400e56>] ? netlink_rcv_skb+0x86/0xb0
>> [ 713.116137] [<c13f7b5a>] ? rtnetlink_rcv+0x2a/0x50
>>
The problem is, that
ip link add type can
is not possible as you can not create 'real' CAN devices like can0,
can1, ...
To create 'software CAN devices' like vcan0, vcan1, vcan2, ... we use
ip link add type vcan
see drivers/net/can/vcan.c
---
For real hardware CAN devices the netlink interface is only used for the
configuration of already existing interfaces.
From a quick view on the rtnl_newlink() function in
net/core/rtnetlink.c i was not able to find any method to disallow the
creation of interfaces, will say: How can a netlink user provide the
information, that he's not able to create new devices via netlink???
@Patrick: Do you have an idea for this? Is it a new use-case for netlink
that needs to be implemented?
Regards,
Oliver
^ permalink raw reply
* [PATCH net-next] Phonet: fix /proc/net/phonet with network namespaces
From: Rémi Denis-Courmont @ 2009-08-11 13:12 UTC (permalink / raw)
To: netdev
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
seq_open_net() and seq_release() are needed for seq_file_net().
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
net/phonet/socket.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/phonet/socket.c b/net/phonet/socket.c
index aa1617a..5f26c37 100644
--- a/net/phonet/socket.c
+++ b/net/phonet/socket.c
@@ -498,7 +498,8 @@ static const struct seq_operations pn_sock_seq_ops = {
static int pn_sock_open(struct inode *inode, struct file *file)
{
- return seq_open(file, &pn_sock_seq_ops);
+ return seq_open_net(inode, file, &pn_sock_seq_ops,
+ sizeof(struct seq_net_private));
}
const struct file_operations pn_sock_seq_fops = {
@@ -506,5 +507,5 @@ const struct file_operations pn_sock_seq_fops = {
.open = pn_sock_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release,
+ .release = seq_release_net,
};
--
1.6.0.4
^ permalink raw reply related
* [PATCH] Fix Warnings from net/netlink/genetlink.c
From: vibi sreenivasan @ 2009-08-11 10:07 UTC (permalink / raw)
To: netdev; +Cc: Johannes Berg, Thomas Graf, linux-next
net/netlink/genetlink.c: In function `genl_register_mc_group':
net/netlink/genetlink.c:139: warning: 'err' might be used uninitialized in this function
Signed-off-by: vibi sreenivasan <vibi_sreenivasan@cms.com>
---
net/netlink/genetlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 575c643..66f6ba0 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -136,7 +136,7 @@ int genl_register_mc_group(struct genl_family *family,
{
int id;
unsigned long *new_groups;
- int err;
+ int err = 0;
BUG_ON(grp->name[0] == '\0');
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: Add networking wireless drivers section
From: Jiri Kosina @ 2009-08-11 13:55 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, linville, julia, netdev, linux-kernel,
kernel-janitors, linux-wireless
In-Reply-To: <1248806896.18284.14.camel@Joe-Laptop.home>
On Tue, 28 Jul 2009, Joe Perches wrote:
> > Why not just create a plain "WIRELESS" umbrella entry that contains
> > all of drivers/net/wireless, net/mac80211, and net/wireless?
> Whatever works for John I suppose. John, do you have a preference?
> I was trying to avoid the "S: Maintained" label
> and was copying the form of this section:
>
> NETWORKING DRIVERS
> L: netdev@vger.kernel.org
> W: http://www.linuxfoundation.org/en/Net
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> S: Odd Fixes
> F: drivers/net/
Just out of curiosity, why is drivers/net marked as "Odd fixes" and not
"Maintained"?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] libertas: name the network device wlan%d
From: Daniel Mack @ 2009-08-11 14:13 UTC (permalink / raw)
To: libertas-dev; +Cc: Daniel Mack, Roel Kluin, John W. Linville, netdev
Devices created by the libertas driver are currently called eth%d. Which
is wrong, because the device does not at all have anything to do with
Ethernet. And it is also confusing when used on devices with more than
one network device.
Fix this by calling it wlan%d.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Roel Kluin <roel.kluin@gmail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/libertas/main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index 89575e4..584022f 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1204,6 +1204,7 @@ struct lbs_private *lbs_add_card(void *card, struct device *dmdev)
SET_NETDEV_DEV(dev, dmdev);
priv->rtap_net_dev = NULL;
+ strcpy(dev->name, "wlan%d");
lbs_deb_thread("Starting main thread...\n");
init_waitqueue_head(&priv->waitq);
--
1.6.3.3
^ permalink raw reply related
* [PATCH] trivial: remove duplicate "different" from comment
From: Thadeu Lima de Souza Cascardo @ 2009-08-11 14:18 UTC (permalink / raw)
To: trivial
Cc: johannes, davem, linville, lrodriguez, linux-wireless, netdev,
linux-kernel, Thadeu Lima de Souza Cascardo
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
---
net/wireless/reg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index fc7a484..f256dff 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1424,7 +1424,7 @@ static int ignore_request(struct wiphy *wiphy,
if (last_wiphy != wiphy) {
/*
* Two cards with two APs claiming different
- * different Country IE alpha2s. We could
+ * Country IE alpha2s. We could
* intersect them, but that seems unlikely
* to be correct. Reject second one for now.
*/
--
1.6.3.3
^ permalink raw reply related
* RE: [PATCH][RFC] net/bridge: add basic VEPA support
From: Fischer, Anna @ 2009-08-11 14:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: 'Stephen Hemminger', bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org, evb@yahoogroups.com,
davem@davemloft.net, kaber@trash.net, adobriyan@gmail.com,
Paul Congdon (UC Davis), Eric Biederman
In-Reply-To: <200908101707.32751.arnd@arndb.de>
> Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
>
> On Monday 10 August 2009, Fischer, Anna wrote:
> > > Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
> > >
> > > On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
> > > > As I understand the macvlan code, it currently doesn't allow two
> VMs
> > > on the
> > > > same machine to communicate with one another.
> > >
> > > There are patches to do that. I think if we add that, there should
> be
> > > a way to choose the behavior between either bridging between the
> > > guests or VEPA.
> >
> > If you implement this direct bridging capability between local VMs
> for
> > macvlan, then would this not break existing applications that
> currently
> > use it? It would be quite a significant change to how macvlan works
> > today. I guess, ideally, you would want to have macvlan work in
> > separate modes, e.g. traditional macvlan, bridging, and VEPA.
>
> Right, that's what I meant with my sentence above. I'm not sure
> if we need to differentiate traditional macvlan and VEPA though.
> AFAICT, the only difference should be the handling of broadcast
> and multicast frames returning from the hairpin turn. Since this
> does not happen with a traditional macvlan, we can always send them
> to all macvlan ports except the source port.
Yes, if you add a check for the original source port on broadcast/
multicast delivery, then macvlan would be able to function in
basic VEPA mode.
Maybe it might still be worth preserving the old behaviour, and
just add an explicit VEPA mode.
> > > > I could imagine a hairpin mode on the adjacent bridge making this
> > > > possible, but the macvlan code would need to be updated to filter
> > > > reflected frames so a source did not receive his own packet.
> > >
> > > Right, I missed this point so far. I'll follow up with a patch
> > > to do that.
> >
> > Can you maybe point me to the missing patches for macvlan that you
> > have mentioned in other emails, and the one you mention above?
> > E.g. enabling multicast distribution and allowing local bridging etc.
> > I could not find any of those in the archives. Thanks.
>
> The patch from Eric Biederman to allow macvlan to bridge between
> its slave ports is at
>
> http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
Looking through the discussions here, it does not seem as if a decision
was made to integrate those patches, because they would make the macvlan
interface behave too much like a bridge. Also, it seems as if there was
still a problem with doing multicast/broadcast delivery when enabling
local VM-to-VM communication. Is that solved by now?
Thanks,
Anna
^ permalink raw reply
* [RFC patch] bridge GARP: prevent 20 wakeups/s when sitting idle
From: Andreas Mohr @ 2009-08-11 14:38 UTC (permalink / raw)
To: bridge
Cc: Patrick McHardy, Stephen Hemminger, netdev, power, linux-kernel,
andi
Hello all,
this is an RFC patch to avoid having the GARP timer remain in full speed
_forever_ (a full 20 superfluous wakeups per second as seen in powertop
on my server) as soon as one GARP applicant managed to show up.
The old behaviour was to simply initially arm the timer as soon as an applicant
showed up, then _unconditionally_ rearm the timer with a random
garp_join_time-based delay in the timer handler _itself_.
New behaviour is to arm the timer when a request comes in _and_ zero
previous requests exist (managed atomically, via locked operation
of list splicing). Then for further incoming requests,
as long as the random garp_join_time-based delay isn't expired
the producer queue fills up, and once the timer fires
this list is moved over into the dequeueing list, to be sent off
(with minimal locking in that case).
Unfortunately the patch hasn't really been tested since the affected box
(at a remote location) for some reason didn't activate GARP last time
despite manually enabling the bridge.
I'm sufficiently confident that it's working as expected, though, since it's
a pretty developed iteration with pretty robust behaviour code-wise,
with lots of communicative assistance by the GARP author, Patrick McHardy.
So, any comments about this? Any users of GARP bridging out there who
can confirm that it helps properly?
Thanks,
Andreas Mohr
--- linux-2.6.30.4/net/802/garp.c.org 2009-06-27 20:04:46.000000000 +0200
+++ linux-2.6.30.4/net/802/garp.c 2009-08-06 00:53:50.000000000 +0200
@@ -135,6 +135,10 @@ static const struct garp_state_trans {
},
};
+static void garp_join_timer_arm(struct garp_applicant *app);
+
+
+
static int garp_attr_cmp(const struct garp_attr *attr,
const void *data, u8 len, u8 type)
{
@@ -238,6 +242,7 @@ static int garp_pdu_append_end_mark(stru
static void garp_pdu_queue(struct garp_applicant *app)
{
+ bool need_arm_timer;
if (!app->pdu)
return;
@@ -250,15 +255,37 @@ static void garp_pdu_queue(struct garp_a
llc_mac_hdr_init(app->pdu, app->dev->dev_addr,
app->app->proto.group_address);
- skb_queue_tail(&app->queue, app->pdu);
+ printk(KERN_INFO "garp_pdu_queue app %p\n", app);
+ /*
+ * [this function always to be called under app lock under
+ * normal operation]
+ * Make sure to arm the timer upon encountering our first packet;
+ * further packets queued by us will then be allowed to accumulate
+ * until timer ultimately fires.
+ */
+ need_arm_timer = skb_queue_empty(&app->queue);
+ __skb_queue_tail(&app->queue, app->pdu);
app->pdu = NULL;
+ if (need_arm_timer)
+ garp_join_timer_arm(app);
}
static void garp_queue_xmit(struct garp_applicant *app)
{
struct sk_buff *skb;
+ struct sk_buff_head dequeue; /* accumul. requests to be handled */
+
+ printk(KERN_INFO "garp_queue_xmit app %p\n", app);
+
+ /* Atomically move over all incoming pdus into our processing queue.
+ This is needed to provide some reliable criteria whether our timer
+ should be rearmed or not. */
+ spin_lock_bh(&app->lock);
+ __skb_queue_head_init(&dequeue);
+ skb_queue_splice_init(&app->queue, &dequeue);
+ spin_unlock_bh(&app->lock);
- while ((skb = skb_dequeue(&app->queue)))
+ while ((skb = skb_dequeue(&dequeue)))
dev_queue_xmit(skb);
}
@@ -398,6 +425,7 @@ static void garp_join_timer_arm(struct g
unsigned long delay;
delay = (u64)msecs_to_jiffies(garp_join_time) * net_random() >> 32;
+ printk(KERN_INFO "garp_join_timer_arm app %p jiffies %lu delay %lu\n", app, jiffies, delay);
mod_timer(&app->join_timer, jiffies + delay);
}
@@ -411,7 +439,6 @@ static void garp_join_timer(unsigned lon
spin_unlock(&app->lock);
garp_queue_xmit(app);
- garp_join_timer_arm(app);
}
static int garp_pdu_parse_end_mark(struct sk_buff *skb)
@@ -586,7 +613,6 @@ int garp_init_applicant(struct net_devic
skb_queue_head_init(&app->queue);
rcu_assign_pointer(dev->garp_port->applicants[appl->type], app);
setup_timer(&app->join_timer, garp_join_timer, (unsigned long)app);
- garp_join_timer_arm(app);
return 0;
err3:
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add networking wireless drivers section
From: David Miller @ 2009-08-11 14:49 UTC (permalink / raw)
To: jkosina
Cc: joe, linville, julia, netdev, linux-kernel, kernel-janitors,
linux-wireless
In-Reply-To: <alpine.LRH.2.00.0908111555410.11142@twin.jikos.cz>
From: Jiri Kosina <jkosina@suse.cz>
Date: Tue, 11 Aug 2009 15:55:46 +0200 (CEST)
> On Tue, 28 Jul 2009, Joe Perches wrote:
>
>> > Why not just create a plain "WIRELESS" umbrella entry that contains
>> > all of drivers/net/wireless, net/mac80211, and net/wireless?
>> Whatever works for John I suppose. John, do you have a preference?
>> I was trying to avoid the "S: Maintained" label
>> and was copying the form of this section:
>>
>> NETWORKING DRIVERS
>> L: netdev@vger.kernel.org
>> W: http://www.linuxfoundation.org/en/Net
>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
>> S: Odd Fixes
>> F: drivers/net/
>
> Just out of curiosity, why is drivers/net marked as "Odd fixes" and not
> "Maintained"?
Because it depends upon the individual driver maintainers. For
example, I don't think one could claim 3c515.c or other ISA ethernet
drivers to be in any kind of "Maintained" state.
^ permalink raw reply
* RE: [PATCH][RFC] net/bridge: add basic VEPA support
From: Paul Congdon (UC Davis) @ 2009-08-11 14:55 UTC (permalink / raw)
To: 'Fischer, Anna', 'Arnd Bergmann'
Cc: 'Stephen Hemminger', bridge, linux-kernel, netdev,
virtualization, evb, davem, kaber, adobriyan,
'Eric Biederman'
In-Reply-To: <0199E0D51A61344794750DC57738F58E6D6AE99C53@GVW1118EXC.americas.hpqcorp.net>
> >
> > The patch from Eric Biederman to allow macvlan to bridge between
> > its slave ports is at
> >
> > http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
>
> Looking through the discussions here, it does not seem as if a decision
> was made to integrate those patches, because they would make the
> macvlan
> interface behave too much like a bridge. Also, it seems as if there was
> still a problem with doing multicast/broadcast delivery when enabling
> local VM-to-VM communication. Is that solved by now?
>
Also, is there a solution, or plans for a solution, to address macvtap
interfaces that are set to 'promiscuous' mode? It would seem fairly easy to
support this for interfaces that are simply trying to listen to the port
(e.g. Wireshark). If the port was being used by something like a firewall
then the VEPA filtering doesn't work too well.
Paul
^ permalink raw reply
* a question on net_device struct
From: 홍신 shin hong @ 2009-08-11 14:57 UTC (permalink / raw)
To: netdev
Hi. I have a question while I read the codes in net/core of Linux 2.6.30.4.
'net_device' struct defined in include/linux/netdevice.h has a field
'operstate'.
Is a 'operstate' field is protected by 'dev_base_lock'?
At set_operstate() in net/core/rtnetlink.c, it seems that dev->operstate
is protected by write_lock_bh(&dev_base_lock).
But, in other codes, the read operations to dev->operstate are not
consistently protected by read_lock_bh(&dev_base_lock).
Thank you.
Sincerely
Shin Hong
^ permalink raw reply
* Re: [PATCH] libertas: name the network device wlan%d
From: Daniel Mack @ 2009-08-11 15:33 UTC (permalink / raw)
To: libertas-dev; +Cc: Roel Kluin, John W. Linville, netdev
In-Reply-To: <20090811151051.GA18186@guralp.com>
On Tue, Aug 11, 2009 at 04:10:51PM +0100, Bob Dunlop wrote:
> On Tue, Aug 11 at 04:13, Daniel Mack wrote:
> > Devices created by the libertas driver are currently called eth%d. Which
> > is wrong, because the device does not at all have anything to do with
> > Ethernet. And it is also confusing when used on devices with more than
> > one network device.
> >
> > Fix this by calling it wlan%d.
>
> Just a nit pick but shouldn't the patch also include:
>
> @@ -1176,7 +1176,7 @@
> /* Allocate an Ethernet device and register it */
> dev = alloc_etherdev(sizeof(struct lbs_private));
> if (!dev) {
> - lbs_pr_err("init ethX device failed\n");
> + lbs_pr_err("init wlanX device failed\n");
> goto done;
> }
> priv = netdev_priv(dev);
>
>
> So collars and cuffs match.
Oh, of course.
Thanks,
Daniel
>From 63ace51c76ef513553f4b30da80603f1f81114d0 Mon Sep 17 00:00:00 2001
From: Daniel Mack <daniel@caiaq.de>
Date: Tue, 11 Aug 2009 16:09:34 +0200
Subject: [PATCH] libertas: name the network device wlan%d
Devices created by the libertas driver are currently called eth%d. Which
is wrong, because the device does not at all have anything to do with
Ethernet. And it is also confusing when used on devices with more than
one network device.
Fix this by calling it wlan%d.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Roel Kluin <roel.kluin@gmail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/libertas/main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index 89575e4..8df1cfd 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1176,7 +1176,7 @@ struct lbs_private *lbs_add_card(void *card, struct device *dmdev)
/* Allocate an Ethernet device and register it */
dev = alloc_etherdev(sizeof(struct lbs_private));
if (!dev) {
- lbs_pr_err("init ethX device failed\n");
+ lbs_pr_err("init wlanX device failed\n");
goto done;
}
priv = netdev_priv(dev);
@@ -1204,6 +1204,7 @@ struct lbs_private *lbs_add_card(void *card, struct device *dmdev)
SET_NETDEV_DEV(dev, dmdev);
priv->rtap_net_dev = NULL;
+ strcpy(dev->name, "wlan%d");
lbs_deb_thread("Starting main thread...\n");
init_waitqueue_head(&priv->waitq);
--
1.6.3.3
^ permalink raw reply related
* Re: a question on net_device struct
From: Stephen Hemminger @ 2009-08-11 16:12 UTC (permalink / raw)
To: 홍신 shin hong; +Cc: netdev
In-Reply-To: <2014bcab0908110757q5b255dcdm497414d04810c281@mail.gmail.com>
On Tue, 11 Aug 2009 23:57:31 +0900
홍신 shin hong <hongshin@gmail.com> wrote:
> Hi. I have a question while I read the codes in net/core of Linux 2.6.30.4.
>
> 'net_device' struct defined in include/linux/netdevice.h has a field
> 'operstate'.
> Is a 'operstate' field is protected by 'dev_base_lock'?
>
> At set_operstate() in net/core/rtnetlink.c, it seems that dev->operstate
> is protected by write_lock_bh(&dev_base_lock).
> But, in other codes, the read operations to dev->operstate are not
> consistently protected by read_lock_bh(&dev_base_lock).
>
Should be protected by RTNL mutex being held (see rtnl_lock() ).
The dev_base_lock is intended for the list of devices. Operations
that add and delete devices end up holding both.
^ permalink raw reply
* Re: [PATCH] libertas: name the network device wlan%d
From: John W. Linville @ 2009-08-11 14:34 UTC (permalink / raw)
To: Daniel Mack; +Cc: libertas-dev, Roel Kluin, netdev
In-Reply-To: <1250000012-25673-1-git-send-email-daniel@caiaq.de>
On Tue, Aug 11, 2009 at 04:13:32PM +0200, Daniel Mack wrote:
> Devices created by the libertas driver are currently called eth%d. Which
> is wrong, because the device does not at all have anything to do with
> Ethernet. And it is also confusing when used on devices with more than
> one network device.
>
> Fix this by calling it wlan%d.
>
> Signed-off-by: Daniel Mack <daniel@caiaq.de>
> Cc: Roel Kluin <roel.kluin@gmail.com>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: netdev@vger.kernel.org
I'm fine with changing it, but it isn't really wrong either -- it's
just a name, and afterall in most cases all the user will see is
ethernet frames.
Comments from the libertas driver crew?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] be2net: Implementation of request_firmware interface.
From: Andy Gospodarek @ 2009-08-11 16:55 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Sarveshwar Bandi, netdev, davem
In-Reply-To: <1246803604.3898.6.camel@deadeye>
On Sun, Jul 05, 2009 at 03:20:04PM +0100, Ben Hutchings wrote:
> On Sun, 2009-07-05 at 17:46 +0530, Sarveshwar Bandi wrote:
> > I understand that most drivers use request_firmware() to load volatile
> > firmware. I do see that there are other nic drivers that use this inferface to
> > flash persistent firmware.
> >
> > We have other tools for offline flashing; but there is requirement
> > to flash f/w through driver without having to use other proprietary tools.
>
> The firmware blob is proprietary and has to be distributed separately
> from the kernel. So does it really matter that you have to distribute a
> special tool as well?
>
I guess I don't share the same opinion that the binary firmware is
required to be distributed separately since it is not that way today.
If we get rid of all files in firmware/ that do not have source
included, there will not be much left.
I applaud efforts by hardware vendors and others to submit patches that
allow drivers to update their own firmware at load-time if the on-card
version isn't compatible with the driver getting ready to load. If one
does not want them updated, don't put the files in /lib/firmware.
Using a standard method (like using request_firmware) seems much more
logical than requiring users to download and compile some vendor
specific application to get new firmware. It also means that if a
vendor is willing to drop a binary blob into firmware/ it's a pretty
easy thing to do.
> (Based on requirements specified by major OEMs, I have implemented
> firmware update through the sfc driver (MDIO and MTD interfaces) but
> under the control of a separate tool.)
And there are plenty of OEMs out there that complain loudly if it's not
easy to move quickly from one on-card/in-memory firmware to another when
changing driver versions. Trust me, I hear from them.
^ 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