* Re: [PATCH 10/14] [rndis_host] Add early_init function pointer to 'struct rndis_data'.
From: David Brownell @ 2008-01-27 16:14 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, netdev, bjd
In-Reply-To: <20080125225128.11716.59998.stgit@fate.lan>
On Friday 25 January 2008, Jussi Kivilinna wrote:
> Function pointer is for 'subminidrivers' that need to do work on device
> right after minidriver has initialized hardware.
>
> For example, rndis_wlan setting device specific configuration parameters
> with OID_GEN_RNDIS_CONFIG_PARAMETER right after rndis_host has
> initialized hardware with RNDIS_INIT.
>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
... though I'm not sure I'd coin a term like "subminidriver". ;)
> ---
>
> drivers/net/usb/rndis_host.c | 6 ++++++
> drivers/net/usb/usbnet.h | 5 +++++
> 2 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
> index 1d6bf0a..0813903 100644
> --- a/drivers/net/usb/rndis_host.c
> +++ b/drivers/net/usb/rndis_host.c
> @@ -336,6 +336,12 @@ int generic_rndis_bind(struct usbnet *dev, struct usb_interface *intf)
> dev->hard_mtu, tmp, dev->rx_urb_size,
> 1 << le32_to_cpu(u.init_c->packet_alignment));
>
> + /* module has some device initialization code needs to be done right
> + * after RNDIS_INIT */
> + if (dev->driver_info->early_init &&
> + dev->driver_info->early_init(dev) != 0)
> + goto halt_fail_and_release;
> +
> /* Get designated host ethernet address */
> reply_len = ETH_ALEN;
> retval = rndis_query(dev, intf, u.buf, OID_802_3_PERMANENT_ADDRESS,
> diff --git a/drivers/net/usb/usbnet.h b/drivers/net/usb/usbnet.h
> index 0b4bf09..25b63d3 100644
> --- a/drivers/net/usb/usbnet.h
> +++ b/drivers/net/usb/usbnet.h
> @@ -116,6 +116,11 @@ struct driver_info {
> struct sk_buff *(*tx_fixup)(struct usbnet *dev,
> struct sk_buff *skb, gfp_t flags);
>
> + /* early initialization code, can sleep. This is for minidrivers
> + * having 'subminidrivers' that need to do extra initialization
> + * right after minidriver have initialized hardware. */
> + int (*early_init)(struct usbnet *dev);
> +
> /* for new devices, use the descriptor-reading code instead */
> int in; /* rx endpoint */
> int out; /* tx endpoint */
>
^ permalink raw reply
* Re: [PATCH 12/14] [rndis_host] Add RNDIS physical medium checking into generic_rndis_bind()
From: David Brownell @ 2008-01-27 16:29 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, bjd-a1rhEgazXTw
In-Reply-To: <20080125225139.11716.91641.stgit-q/85JClnwdg@public.gmane.org>
On Friday 25 January 2008, Jussi Kivilinna wrote:
> + if(flags & FLAG_RNDIS_PHYM_WIRELESS &&
> + *phym != RNDIS_PHYSICAL_MEDIUM_WIRELESS_LAN) {
> + dev_err(&intf->dev, "driver requires wireless physical "
> + "medium, but device is not.\n");
> + retval = -ENODEV;
> + goto halt_fail_and_release;
> + }
> + if(flags & FLAG_RNDIS_PHYM_NOT_WIRELESS &&
> + *phym == RNDIS_PHYSICAL_MEDIUM_WIRELESS_LAN) {
> + dev_err(&intf->dev, "driver requires non-wireless physical "
> + "medium, but device is wireless.\n");
> + retval = -ENODEV;
Well, other than the obvious checkpatch.pl warnings waiting to trigger
("if" is not a function; put a space before the paren) and what I'd call
missing parens around the "flags & ...", those are *not* errors. No
wonder you thought this would cause too many messages!!
Just make those be dev_dbg() calls instead. The strongest message level
you can argue for there would be KERN_NOTICE, "normal but significant";
except it's not especially significant. Filtering by netif_msg_probe()
may be a good idea too; that's normally enabled in this framework.
- Dave
p.s. Before these get submitted, *all* of them need to pass "checkpatch.pl".
Ideally, "checkpatch.pl --strict" ...
^ permalink raw reply
* Re: [PATCH 11/14] [rndis_host] Add link_change function pointer to 'struct rndis_data'.
From: David Brownell @ 2008-01-27 16:15 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, bjd-a1rhEgazXTw
In-Reply-To: <20080125225134.11716.2264.stgit-q/85JClnwdg@public.gmane.org>
On Friday 25 January 2008, Jussi Kivilinna wrote:
> Callback to signal link state changes from minidriver to
> 'subminidrivers'.
>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna-E01nCVcF24I@public.gmane.org>
Acked-by: David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> ---
>
> drivers/net/usb/rndis_host.c | 24 ++++++++++++++++++++----
> drivers/net/usb/usbnet.h | 4 ++++
> 2 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
> index 0813903..800c9d0 100644
> --- a/drivers/net/usb/rndis_host.c
> +++ b/drivers/net/usb/rndis_host.c
> @@ -148,10 +148,26 @@ int rndis_command(struct usbnet *dev, struct rndis_msg_hdr *buf)
> request_id, xid);
> /* then likely retry */
> } else switch (buf->msg_type) {
> - case RNDIS_MSG_INDICATE: { /* fault */
> - // struct rndis_indicate *msg = (void *)buf;
> - dev_info(&info->control->dev,
> - "rndis fault indication\n");
> + case RNDIS_MSG_INDICATE: { /* fault/event */
> + struct rndis_indicate *msg = (void *)buf;
> + int state = 0;
> +
> + switch (msg->status) {
> + case RNDIS_STATUS_MEDIA_CONNECT:
> + state = 1;
> + case RNDIS_STATUS_MEDIA_DISCONNECT:
> + dev_info(&info->control->dev,
> + "rndis media %sconnect\n",
> + !state?"dis":"");
> + if (dev->driver_info->link_change)
> + dev->driver_info->link_change(
> + dev, state);
> + break;
> + default:
> + dev_info(&info->control->dev,
> + "rndis indication: 0x%08x\n",
> + le32_to_cpu(msg->status));
> + }
> }
> break;
> case RNDIS_MSG_KEEPALIVE: { /* ping */
> diff --git a/drivers/net/usb/usbnet.h b/drivers/net/usb/usbnet.h
> index 25b63d3..e0501da 100644
> --- a/drivers/net/usb/usbnet.h
> +++ b/drivers/net/usb/usbnet.h
> @@ -121,6 +121,10 @@ struct driver_info {
> * right after minidriver have initialized hardware. */
> int (*early_init)(struct usbnet *dev);
>
> + /* called by minidriver when link state changes, state: 0=disconnect,
> + * 1=connect */
> + void (*link_change)(struct usbnet *dev, int state);
> +
> /* for new devices, use the descriptor-reading code instead */
> int in; /* rx endpoint */
> int out; /* tx endpoint */
>
^ permalink raw reply
* [PATCH] natsemi: Update locking documentation
From: Mark Brown @ 2008-01-27 13:58 UTC (permalink / raw)
To: Jeff Garzik, Tim Hockin; +Cc: netdev, linux-kernel, Mark Brown
The documentation regarding synchronisation at the head of the natsemi
driver was badly bitrotted so replace it with a general statement about
the techniques used which is less likely to bitrot.
Also remove the note saying these chips are uncommon - it makes little
difference but they were used in a number of laptops and at least one mass
market PCI ethernet card.
Signed-off-by: Mark Brown <broonie@sirena.org.uk>
---
drivers/net/natsemi.c | 18 ++----------------
1 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index c329a4f..0a3e604 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -203,22 +203,8 @@ skbuff at an offset of "+2", 16-byte aligning the IP header.
IIId. Synchronization
Most operations are synchronized on the np->lock irq spinlock, except the
-performance critical codepaths:
-
-The rx process only runs in the interrupt handler. Access from outside
-the interrupt handler is only permitted after disable_irq().
-
-The rx process usually runs under the netif_tx_lock. If np->intr_tx_reap
-is set, then access is permitted under spin_lock_irq(&np->lock).
-
-Thus configuration functions that want to access everything must call
- disable_irq(dev->irq);
- netif_tx_lock_bh(dev);
- spin_lock_irq(&np->lock);
-
-IV. Notes
-
-NatSemi PCI network controllers are very uncommon.
+recieve and transmit paths which are synchronised using a combination of
+hardware descriptor ownership, disabling interrupts and NAPI poll scheduling.
IVb. References
--
1.5.3.8
^ permalink raw reply related
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Jarek Poplawski @ 2008-01-27 11:14 UTC (permalink / raw)
To: Julian Anastasov
Cc: Andreas Schwab, Joonwoo Park, Andrew Morton, netdev, bugme-daemon
In-Reply-To: <Pine.LNX.4.58.0801271127490.8409@u.domain.uli>
On Sun, Jan 27, 2008 at 11:49:06AM +0200, Julian Anastasov wrote:
...
> No, simply the last change in 2.6.24 is wrong to assume
> duplication is evident in fib_info reference counter. And such check
> is only on ip route replace/change. I'm appending brief FIB information
> for your reference:
Thank you very much! I've just planned to look more at this code today,
and maybe try to find how your new patch copes with this problem, so
this description should be really helpful!
But, since we agree now it's a bug and regression in 2.6.24, it seems
this should be fixed as soon as possible, and since your patch isn't
probably tested enough for stable, it looks like safe bet to revert
Joonwoo's patch, at least until this all is more verified.
Regards,
Jarek P.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Julian Anastasov @ 2008-01-27 9:49 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Andreas Schwab, Joonwoo Park, Andrew Morton, netdev, bugme-daemon
In-Reply-To: <20080127011126.GA3408@ami.dom.local>
Hello,
On Sun, 27 Jan 2008, Jarek Poplawski wrote:
> But comment#3 is "ambiguous"... It looks like you don't want to show
> us too much... So, apparently you change the route, but it seems this
> route exists; you have this:
> 10.0.0.0/8 dev eth0 scope link
> but probably also something like this:
> default via 192.168.1.1 dev eth0 src 10.204.0.116
On replace the problem arises when same fib_info (priority,
protocol, prefsrc, metrics, nexthops) is used in another route or routing
table. In such cases single copy of structure is used with reference
counter, all routes share pointer to such fib_info structure which
saves memory when we have many routes using same gateway, for example.
> So, I doubt there is any "real" change attempted here. It looks more
> like a question if program should allow for changing the form of route
> entries even if they mean the same, and if this should be reported as
> error at all? But maybe I miss something...
No, simply the last change in 2.6.24 is wrong to assume
duplication is evident in fib_info reference counter. And such check
is only on ip route replace/change. I'm appending brief FIB information
for your reference:
FIB - Forwarding Information Base
- Routes are organized in routing tables
- For "fib_hash" algorithm routing tables have 33 zones (for prefix
lengths 0..32), routing lookup walks them from 32 to 0 to find a
node containing all routing information
- Zones are implemented as hash tables where nodes are hashed by
key (prefix=network) because there can be lots of prefixes in a zone.
- Nodes can be stored with other methods, eg. trie, where nodes are
searched (we hope faster) by prefix and length, no zones are used
in this case
- Nodes have a list of aliases (tos+type+scope+fib_info ptr) sorted by
decreasing TOS because TOS=0 must be a last hit when looking for route.
type is unicast, local, prohibit, etc. scope is host, link, etc.
- fib_info is a structure containing protocol (kernel, boot, zebra, etc),
prefsrc, priority (metric), metrics, nexthop(s). Fallback routes have
higher value for priority, they are used if more priority routes
disappear or their nexthops are dead.
- fib_info structures are organized in 2 global hash tables, one
keyed by prefsrc and another by nexthop_count+protocol+prefsrc+priority
- fib_info is a shared structure, different aliases can point to same
fib_info, even aliases from different prefixes, from different routing
tables. By this way if fib_info contains multipath route then many
aliases share same route path scheduling context.
- Nexthop contains gateway, output device, scope and weight. Weight
is used for path scheduling where nexthops have relative priority
compared to other nexthops in multipath route.
- There can be many aliases with same tos, there can be alternative
routes (aliases) with same tos and priority (metric) but only one alias
with particular tos, type, scope and fib_info can exist to avoid duplicate
alternative routes.
- The operation to replace route includes replacing of alias. The alias
in node (table -> prefix/len) is matched by tos and fib_info priority and
they can not be changed. The parameters that are changed are type, scope
and fib_info (except priority).
* routing table
* node (prefix/len)
* alias (tos, type, scope)
-> fib_info (priority, protocol, prefsrc, metrics)
* nexthop (gateway, outdev, scope, weight)
read '*' for 'many' and '->' for 'counted reference'
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Jarek Poplawski @ 2008-01-27 7:58 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Joonwoo Park, Andrew Morton, netdev, bugme-daemon
In-Reply-To: <20080127011126.GA3408@ami.dom.local>
On Sun, Jan 27, 2008 at 02:11:26AM +0100, Jarek Poplawski wrote:
...
> But comment#3 is "ambiguous"... It looks like you don't want to show
> us too much... So, apparently you change the route, but it seems this
> route exists; you have this:
> 10.0.0.0/8 dev eth0 scope link
> but probably also something like this:
> default via 192.168.1.1 dev eth0 src 10.204.0.116
>
> So, I doubt there is any "real" change attempted here. It looks more
> like a question if program should allow for changing the form of route
> entries even if they mean the same, and if this should be reported as
> error at all? But maybe I miss something...
...But, on the other hand, default route shoudn't affect adding or
changing specific routes, so this behaviour is wrong, and IMHO this
change should be reverted or fixed.
Regards,
Jarek P.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9825] New: GPF in kernel when /sbin/ss used for display DCCP sockets.
From: Andrew Morton @ 2008-01-27 6:33 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon, spike
In-Reply-To: <bug-9825-10286@http.bugzilla.kernel.org/>
> On Sat, 26 Jan 2008 13:18:40 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9825
>
> Summary: GPF in kernel when /sbin/ss used for display DCCP
> sockets.
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.24
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: spike@ml.yaroslavl.ru
>
>
> Latest working kernel version: 2.6.23.14
> Earliest failing kernel version:2.6.24
A regression in 2.6.24.
> Distribution:gentoo
> Hardware Environment: i386
> Software Environment: ss utility, iproute2-ss070710
> Problem Description:
> GPF in kernel when ss used for display DCCP sockets.
>
> Jan 26 23:38:03 host general protection fault: 0000 [#1] PREEMPT
> Jan 26 23:38:03 host Modules linked in: iptable_mangle iptable_nat nf_nat
> ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state ipt_ULOG iptable_filter
> ip_tables x_
> Jan 26 23:38:03 host
> Jan 26 23:38:03 host Pid: 5573, comm: ss Not tainted (2.6.24 #1)
> Jan 26 23:38:03 host EIP: 0060:[<c031a14f>] EFLAGS: 00010282 CPU: 0
> Jan 26 23:38:03 host EIP is at inet_diag_dump+0x2a/0x88b
> Jan 26 23:38:03 host EAX: fffffffe EBX: e7095810 ECX: 00000001 EDX: fffffffe
> Jan 26 23:38:03 host ESI: ee264a00 EDI: e7035840 EBP: 000015c5 ESP: e70fdbd0
> Jan 26 23:38:03 host DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> Jan 26 23:38:03 host Process ss (pid: 5573, ti=e70fc000 task=e70f3680
> task.ti=e70fc000)
> Jan 26 23:38:03 host Stack: 00000001 c040c164 e70f3680 000040d0 00000000
> e7035840 ee264a00 c01690a7
> Jan 26 23:38:03 host effc6009 e70fdc20 e7095810 000240d0 c040c6c0 00000010
> c14e02c0 00000282
> Jan 26 23:38:03 host 8cab2e5a 000040d0 00000f00 000000d0 c0426e80 c0147e38
> ee264a00 c02c6dff
> Jan 26 23:38:03 host Call Trace:
> Jan 26 23:38:03 host [<c01690a7>] permission+0x51/0xe7
> Jan 26 23:38:03 host [<c0147e38>] __get_free_pages+0x4d/0x55
> Jan 26 23:38:03 host [<c02c6dff>] __alloc_skb+0x4b/0xfa
> Jan 26 23:38:03 host [<c02de333>] netlink_dump+0x47/0x178
> Jan 26 23:38:03 host [<c01426df>] file_read_actor+0xe1/0x10c
> Jan 26 23:38:03 host [<c02e062e>] netlink_dump_start+0xb8/0x15e
> Jan 26 23:38:03 host [<c0319bf0>] inet_diag_rcv_msg+0x5c/0x591
> Jan 26 23:38:03 host [<c031a125>] inet_diag_dump+0x0/0x88b
> Jan 26 23:38:03 host [<c0319b94>] inet_diag_rcv_msg+0x0/0x591
> Jan 26 23:38:03 host [<c0319152>] inet_diag_rcv+0x0/0x24
> Jan 26 23:38:03 host [<c02df335>] netlink_rcv_skb+0x6d/0x8e
> Jan 26 23:38:03 host [<c031916b>] inet_diag_rcv+0x19/0x24
> Jan 26 23:38:03 host [<c02df0e0>] netlink_unicast+0x1fa/0x224
> Jan 26 23:38:03 host [<c02df86e>] netlink_sendmsg+0x1d0/0x2b2
> Jan 26 23:38:03 host [<c01690a7>] permission+0x51/0xe7
> Jan 26 23:38:03 host [<c02c1423>] sock_sendmsg+0xbb/0xdd
> Jan 26 23:38:03 host [<c012c951>] autoremove_wake_function+0x0/0x37
> Jan 26 23:38:03 host [<c013090c>] __atomic_notifier_call_chain+0x24/0x4a
> Jan 26 23:38:03 host [<c0130949>] atomic_notifier_call_chain+0x17/0x1b
> Jan 26 23:38:03 host [<c0251ad0>] notify_update+0x1f/0x23
> Jan 26 23:38:03 host [<c0253f0f>] do_con_write+0x33d/0x1aac
> Jan 26 23:38:03 host [<c0253f0f>] do_con_write+0x33d/0x1aac
> Jan 26 23:38:03 host [<c02c8369>] verify_iovec+0x2a/0x91
> Jan 26 23:38:03 host [<c02c1572>] sys_sendmsg+0x12d/0x243
> Jan 26 23:38:03 host [<c024b40f>] n_tty_ioctl+0x0/0x1e1
> Jan 26 23:38:03 host [<c0247475>] tty_ioctl+0x114/0xeb5
> Jan 26 23:38:03 host [<c0142987>] find_lock_page+0x20/0xab
> Jan 26 23:38:03 host [<c0144d19>] filemap_fault+0x1d4/0x43e
> Jan 26 23:38:03 host [<c02c3618>] sk_prot_alloc+0x70/0x8a
> Jan 26 23:38:03 host [<c02c4d19>] sk_alloc+0x3d/0x47
> Jan 26 23:38:03 host [<c0172eee>] d_alloc+0x1b/0x192
> Jan 26 23:38:03 host [<c0172eb3>] d_instantiate+0x3b/0x5b
> Jan 26 23:38:03 host [<c02c1161>] sock_attach_fd+0x77/0xa2
> Jan 26 23:38:03 host [<c02c27d8>] sys_socketcall+0x24f/0x271
> Jan 26 23:38:03 host [<c0115952>] do_page_fault+0x0/0x5ce
> Jan 26 23:38:03 host [<c0103e72>] sysenter_past_esp+0x5f/0x85
> Jan 26 23:38:03 host [<c0350000>] __xfrm6_tunnel_spi_lookup+0x26/0x72
> Jan 26 23:38:03 host =======================
> Jan 26 23:38:03 host Code: ff 55 57 56 53 83 ec 74 89 44 24 18 89 54 24 14 8b
> 5a 04 0f b7 43 04 e8 36 f0 ff ff 85 c0 0f 84 a4 02 00 00 83 c3 10 89 5c 24 28
> <8
> Jan 26 23:38:03 host EIP: [<c031a14f>] inet_diag_dump+0x2a/0x88b SS:ESP
> 0068:e70fdbd0
> Jan 26 23:38:03 host ---[ end trace 57d7a9039abd2ede ]---
>
> All ss runned later sleep forewer in D state. Kill -9 don't work.
>
> Steps to reproduce:
> run /sbin/ss -d
>
>
^ permalink raw reply
* Re: netatalk slow after system upgrade (possibly kernel problem?)
From: Andrew Morton @ 2008-01-27 6:00 UTC (permalink / raw)
To: Michael Monnerie; +Cc: netatalk-admins, linux-kernel, netdev
In-Reply-To: <200801251255.48105@zmi.at>
(cc netdev)
> On Fri, 25 Jan 2008 12:55:42 +0100 Michael Monnerie <michael.monnerie@it-management.at> wrote:
> Dear lists,
>
> I've been spending a LOT of time trying to find out where's the problem,
> but can't find it and therefore seek urgent help now. We have the
> following system:
>
> Server with VMware server
> -> VM running a webserver and netatalk
> -> 2 other VMs not related
>
> The VM with netatalk was SUSE 10.0 with kernel 2.6.13-15.15-smp (from
> SUSE), and things were pretty fun and quick. Then we upgraded to SUSE
> 10.2 and now 10.3, where everything EXCEPT netatalk runs perfect. Since
> this upgrade, Apple clients (MacOS X) now do READ very very slowly
> (about 512KB/s over the gigabit LAN), while writing to the server still
> is normal (>20MB/s). I've even retried with the newest kernel
> 2.6.23.13, tried different /proc/sys/net/ipv4/tcp_congestion_control
> (cubic, reno, bic, etc.) and nothing helps. I've then tried to install
> Samba and found that we have similar problems reading with it from
> MacOS clients. Now I'm pretty sure it should be something with the
> linux kernel, but I don't understand what.
>
> Here are the wireshark dumps in pcap format:
> http://zmi.at/x/atalk-write-fast.pcap
> -> you can see writing to the server (192.168.120.9) is normal and fast
>
> http://zmi.at/x/atalk-read-slow.pcap
> -> reading is horribly slow. Lots of "unknown", because of netatalk or
> what?
>
> http://zmi.at/x/unknown-atalk.pcap
> -> another dump while reading, you see "unknown" reads. I'm not sure if
> it's just wireshark not understanding the packets or netatalk.
>
> And trying with samba:
> http://zmi.at/x/smb-read-slow.pcap
> http://zmi.at/x/smb-write-quick.pcap
> you can see that it's also slow.
>
> Now why did it work with the old 2.6.13 kernel? I still have that old
> VM, and when I start it, it is always perfectly fast. Only newer
> versions are slow. Can somebody give me a hint please?
It would be interesting if this could be repeated on bare hardware, so we
can eliminate the possibility that it is some weird interaction with vmware.
^ permalink raw reply
* Re: [Lksctp-developers] [PATCH] SCTP: Fix kernel panic while received retransmitted ASCONF chunk 3 times
From: Vlad Yasevich @ 2008-01-27 2:06 UTC (permalink / raw)
To: Wei Yongjun
Cc: lksctp-developers@lists.sourceforge.net, netdev@vger.kernel.org
In-Reply-To: <479B5B30.4020308@cn.fujitsu.com>
Ack. Good catch.
What do you use to generate this traffic? This also looks like a good
test to add to our regression test suite.
Thanks
-vlad
On Jan 26, 2008, at 11:09 AM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
> While endpoint recived the ASCONF chunk with the same serial number
> for
> 3 times, the endpoint will panic.
>
> Test as following:
>
> Endpoint A Endpoint B
> (ESTABLISHED) (ESTABLISHED)
> ASCONF ---------->
> (serial = 1)
> <---------- ASCONF-ACK
> ASCONF ---------->
> (serial = 1)
> <---------- ASCONF-ACK
> ASCONF ---------->
> (serial = 1)
> kernel panic
>
> This is besause if endpoint received the first ASCONF chunk, ASCONF-
> ACK
> chunk will be send to reponse this ASCONF chunk, and the ASCONF-ACK
> will
> be cached as asoc->addip_last_asconf_ack. After this, if ASCONF chunk
> with the same serial number received will be treat as retransmitted
> ASCONF chunk and just responsed with the cached
> asoc->addip_last_asconf_ack. But before we use this cached chunk, we
> not
> increase the user count of this chunk with sctp_chunk_hold() , after
> send ASCONF-ACK, sctp_chunk_free() will be used to free
> asoc->addip_last_asconf_ack. So when the third ASCONF chunk with the
> same serial number is received, it responsed with the cached
> asoc->addip_last_asconf_ack too, but asoc->addip_last_asconf_ack has
> been freed, So kernel panic is occurred.
>
> Folowing is the kernel panic message. And this patch fix this problem.
>
> kernel BUG at net/sctp/outqueue.c:789!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: md5 sctp ipv6 dm_mirror dm_mod sbs sbshc battery
> lp snd_ens1371
>
> Pid: 0, comm: swapper Not tainted (2.6.24 #1)
> EIP: 0060:[<c8a8f9ba>] EFLAGS: 00010216 CPU: 0
> EIP is at sctp_outq_flush+0x16b/0x5d3 [sctp]
> EAX: c735f43c EBX: c8a9dc64 ECX: 00000046 EDX: 00000000
> ESI: c7aa3b00 EDI: c794ea00 EBP: c7a953d0 ESP: c0757cf4
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> Process swapper (pid: 0, ti=c0757000 task=c06d63a0 task.ti=c070f000)
> Stack: c1107d80 c0441e6f c7aa3b00 00000064 00000000 c7a953bc
> c794eae0 c7a94000
> 034d0be8 00000001 00000000 00000000 00000001 00000000 c043bc66
> c7aa3b00
> c7a953bc c7a94000 c8a9c760 c042bfc6 c8a9f18d c7aa3b00 c7a953bc
> c8a90259
> Call Trace:
> [<c0441e6f>] tick_handle_periodic+0x17/0x5c
> [<c043bc66>] autoremove_wake_function+0x15/0x35
> [<c042bfc6>] printk+0x1b/0x1f
> [<c8a90259>] sctp_outq_tail+0x128/0x172 [sctp]
> [<c8a87631>] sctp_do_sm+0xeb0/0x103f [sctp]
> [<c8a8a639>] sctp_assoc_bh_rcv+0xc1/0xf4 [sctp]
> [<c8a8eb77>] sctp_inq_push+0x2a/0x2d [sctp]
> [<c8a9924b>] sctp_rcv+0x5c3/0x6a4 [sctp]
> [<c0425247>] try_to_wake_up+0x3bb/0x3c5
> [<c0421f8a>] __update_rq_clock+0x19/0x156
> [<c04409e1>] clocksource_get_next+0x39/0x3f
> [<c0421f8a>] __update_rq_clock+0x19/0x156
> [<c05dd9ba>] ip_local_deliver_finish+0xda/0x17d
> [<c05dd8c1>] ip_rcv_finish+0x2c5/0x2e4
> [<c0441e6f>] tick_handle_periodic+0x17/0x5c
> [<c041ae2a>] smp_apic_timer_interrupt+0x74/0x80
> [<c05ddb19>] ip_rcv+0x0/0x237
> [<c05c15ed>] netif_receive_skb+0x328/0x392
> [<c05c39c0>] process_backlog+0x5c/0x9a
> [<c05c34ce>] net_rx_action+0x8d/0x163
> [<c0432dbb>] run_timer_softirq+0x2f/0x156
> [<c042fdd7>] __do_softirq+0x5d/0xc1
> [<c0406f38>] do_softirq+0x59/0xa8
> [<c0441e6f>] tick_handle_periodic+0x17/0x5c
> [<c041ae2a>] smp_apic_timer_interrupt+0x74/0x80
> [<c0403c87>] default_idle+0x0/0x3e
> [<c0403c87>] default_idle+0x0/0x3e
> [<c04058c0>] apic_timer_interrupt+0x28/0x30
> [<c0403c87>] default_idle+0x0/0x3e
> [<c0403cb3>] default_idle+0x2c/0x3e
> [<c0403571>] cpu_idle+0x92/0xab
> [<c07148ea>] start_kernel+0x2f7/0x2ff
> [<c07140e0>] unknown_bootoption+0x0/0x195
> =======================
> Code: 00 89 f2 89 d8 e8 b3 88 00 00 89 d8 e8 1e 83 00 00 85 c0 89 44
> 24 2c
> EIP: [<c8a8f9ba>] sctp_outq_flush+0x16b/0x5d3 [sctp] SS:ESP
> 0068:c0757cf4
> Kernel panic - not syncing: Fatal exception in interrupt
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
> --- a/net/sctp/sm_statefuns.c 2008-01-25 00:50:27.000000000 -0500
> +++ b/net/sctp/sm_statefuns.c 2008-01-25 03:03:15.000000000 -0500
> @@ -3420,9 +3420,10 @@ sctp_disposition_t sctp_sf_do_asconf(con
> * time and instead of re-processing the ASCONF (with the same
> * serial number) it may just re-transmit the ASCONF-ACK.
> */
> - if (asoc->addip_last_asconf_ack)
> + if (asoc->addip_last_asconf_ack) {
> asconf_ack = asoc->addip_last_asconf_ack;
> - else
> + sctp_chunk_hold(asconf_ack);
> + } else
> return SCTP_DISPOSITION_DISCARD;
> } else {
> /* ADDIP 4.2 C4) Otherwise, the ASCONF Chunk is discarded since
>
>
>
>
> ---
> ----------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Jarek Poplawski @ 2008-01-27 1:11 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Joonwoo Park, Andrew Morton, netdev, bugme-daemon
In-Reply-To: <20080126151934.GA2969@ami.dom.local>
On Sat, Jan 26, 2008 at 04:19:34PM +0100, Jarek Poplawski wrote:
> On Sat, Jan 26, 2008 at 03:27:00PM +0100, Andreas Schwab wrote:
> > Jarek Poplawski <jarkao2@gmail.com> writes:
> >
> > > And, after re-reading this bugzilla report, I'm pretty sure the thing
> > > should be done with 'ip route change' (but I didn't check if 2.6.24
> > > knows about this...).
> >
> > $ man ip
> > [...]
> > ip route add - add new route
> > ip route change - change route
> > ip route replace - change or add new one
> > [...]
> >
> > According to this "replace" should be a superset of "change".
>
> According to this "replace" should be ...ambiguous. I could read this
> "my/proper(?) way":
>
> ip route replace - change with new one or add new one
>
> And ...man could be wrong too after all! (...but not me!)
After some checks it seems man is right - ie. WRT iproute.c! (...hmm?)
And you read this right: '"replace" should be a superset of "change"'.
> > Also, please check out comment#3, it also fails for replacing a route
> > with something different (it's a route to an ipsec tunnel).
But comment#3 is "ambiguous"... It looks like you don't want to show
us too much... So, apparently you change the route, but it seems this
route exists; you have this:
10.0.0.0/8 dev eth0 scope link
but probably also something like this:
default via 192.168.1.1 dev eth0 src 10.204.0.116
So, I doubt there is any "real" change attempted here. It looks more
like a question if program should allow for changing the form of route
entries even if they mean the same, and if this should be reported as
error at all? But maybe I miss something...
Jarek P.
^ permalink raw reply
* Re: iproute2 (addr flush) infinite loop when unprivileged users
From: Alon Bar-Lev @ 2008-01-26 21:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080126111931.69e579c1@deepthought>
On 1/26/08, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > iptunnel.c:(.text+0x51c): undefined reference to `__constant_htons'
> > iptunnel.o:iptunnel.c:(.text+0x535): more undefined references to
> > `__constant_htons' follow
> > collect2: ld returned 1 exit status
> > make[1]: *** [ip] Error 1
>
> This is defined via:
> /usr/i!vinclude/linux/ip.h
> #include <asm/byteorder.h>
Trace down the problem to Gentoo patch.
Sorry.
All working now!
Thanks!
Alon.
^ permalink raw reply
* Compex FreedomLine 32 PnP-PCI2 broken with de2104x
From: Ondrej Zary @ 2008-01-26 20:58 UTC (permalink / raw)
To: jgarzik; +Cc: Linux Kernel, netdev
Hello,
I was having problems with these FreedomLine cards with Linux before but
tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC
connectors:
00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip
21041 [Tulip Pass 3] [1011:0014] (rev 21)
de2104x driver was loaded automatically by udev and card seemed to work. Until
I disconnected the TP cable and putting it back after a while. The driver
then switched to (non-existing) AUI port and remained there. I tried to set
media to TP using ethtool - and the whole kernel crashed because of
BUG_ON(de_is_running(de));
in de_set_media(). Seems that the driver is unable to stop the DMA in
de_stop_rxtx().
I commented out AUI detection in the driver - this time it switched to BNC
after unplugging the cable and remained there. I also attempted to reset the
chip when de_stop_rxtx failed but failed to do it.
Then I found that there's de4x5 driver which supports the same cards as
de2104x (and some other too) - and this one works fine! I can plug and unplug
the cable and even change between TP and BNC ports just by unplugging one and
plugging the other cable in. Unfortunately, this driver is blacklisted by
default - at least in Slackware and Debian.
The question is: why does de2104x exist? Does it work better with some
hardware?
BTW. Found that the problem exist at least since 2003:
http://oss.sgi.com/archives/netdev/2003-08/msg00951.html
--
Ondrej Zary
^ permalink raw reply
* Re: iproute2 (addr flush) infinite loop when unprivileged users
From: Stephen Hemminger @ 2008-01-26 19:19 UTC (permalink / raw)
To: Alon Bar-Lev; +Cc: netdev
In-Reply-To: <9e0cf0bf0801260058s797d2ea3r7af013d0957554d8@mail.gmail.com>
On Sat, 26 Jan 2008 10:58:58 +0200
"Alon Bar-Lev" <alon.barlev@gmail.com> wrote:
> On 1/26/08, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > On 1/26/08, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > > The issue is that iproute is just blindly sending the deletes and
> > > not asking for acknowledgment status. Here is a trivial patch to iproute
> > > to fix that, but the problem is that it means it will slow down bulk removal.
> > >
> > > Maybe it should just check the first, or last delete to see if there are
> > > errors?
> > >
> > > diff --git a/ip/iproute.c b/ip/iproute.c
> > > index 7a885b0..b2ae879 100644
> > > --- a/ip/iproute.c
> > > +++ b/ip/iproute.c
> >
> > This should also be applied into ip/ipaddress.c, ip/ipneigh.c
> > Or even make one common function?
> >
> > I don't quite understand how "fast" is good if not complete... But
> > anyway... I will be happy to see this fix in next version... Maybe add
> > --fast argument? :)
> >
> > Alon.
> >
>
> Pulled your latest git head. See some updates but not this one...
> Just thought to report the following [new] build error:
>
>
> gcc -Wl,-export-dynamic ip.o ipaddress.o iproute.o iprule.o rtm_map.o
> iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o
> ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o ipxfrm.o xfrm_state.o
> xfrm_policy.o xfrm_monitor.o iplink_vlan.o link_veth.o
> ../lib/libnetlink.a ../lib/libutil.a -lresolv -L../lib -lnetlink
> -lutil -ldl -o ip
> iptunnel.o: In function `parse_args':
> iptunnel.c:(.text+0x2f6): undefined reference to `__constant_htons'
> iptunnel.c:(.text+0x434): undefined reference to `__constant_htons'
> iptunnel.c:(.text+0x4c1): undefined reference to `__constant_htons'
> iptunnel.c:(.text+0x4da): undefined reference to `__constant_htons'
> iptunnel.c:(.text+0x51c): undefined reference to `__constant_htons'
> iptunnel.o:iptunnel.c:(.text+0x535): more undefined references to
> `__constant_htons' follow
> collect2: ld returned 1 exit status
> make[1]: *** [ip] Error 1
This is defined via:
/usr/include/linux/ip.h
#include <asm/byteorder.h>
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: iproute2 (addr flush) infinite loop when unprivileged users
From: Stephen Hemminger @ 2008-01-26 19:14 UTC (permalink / raw)
To: Alon Bar-Lev; +Cc: netdev
In-Reply-To: <9e0cf0bf0801260058s797d2ea3r7af013d0957554d8@mail.gmail.com>
On Sat, 26 Jan 2008 10:58:58 +0200
"Alon Bar-Lev" <alon.barlev@gmail.com> wrote:
> On 1/26/08, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > On 1/26/08, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > > The issue is that iproute is just blindly sending the deletes and
> > > not asking for acknowledgment status. Here is a trivial patch to iproute
> > > to fix that, but the problem is that it means it will slow down bulk removal.
> > >
> > > Maybe it should just check the first, or last delete to see if there are
> > > errors?
> > >
> > > diff --git a/ip/iproute.c b/ip/iproute.c
> > > index 7a885b0..b2ae879 100644
> > > --- a/ip/iproute.c
> > > +++ b/ip/iproute.c
> >
> > This should also be applied into ip/ipaddress.c, ip/ipneigh.c
> > Or even make one common function?
> >
> > I don't quite understand how "fast" is good if not complete... But
> > anyway... I will be happy to see this fix in next version... Maybe add
> > --fast argument? :)
> >
> > Alon.
> >
>
> Pulled your latest git head. See some updates but not this one...
> Just thought to report the following [new] build error:
>
>
> gcc -Wl,-export-dynamic ip.o ipaddress.o iproute.o iprule.o rtm_map.o
> iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o
> ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o ipxfrm.o xfrm_state.o
> xfrm_policy.o xfrm_monitor.o iplink_vlan.o link_veth.o
> ../lib/libnetlink.a ../lib/libutil.a -lresolv -L../lib -lnetlink
> -lutil -ldl -o ip
> iptunnel.o: In function `parse_args':
> iptunnel.c:(.text+0x2f6): undefined reference to `__constant_htons'
> iptunnel.c:(.text+0x434): undefined reference to `__constant_htons'
> iptunnel.c:(.text+0x4c1): undefined reference to `__constant_htons'
> iptunnel.c:(.text+0x4da): undefined reference to `__constant_htons'
> iptunnel.c:(.text+0x51c): undefined reference to `__constant_htons'
> iptunnel.o:iptunnel.c:(.text+0x535): more undefined references to
> `__constant_htons' follow
> collect2: ld returned 1 exit status
> make[1]: *** [ip] Error 1
What system are you building on.
This is defined in linux/byteorder.h
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: iproute2 (addr flush) infinite loop when unprivileged users
From: Stephen Hemminger @ 2008-01-26 19:11 UTC (permalink / raw)
To: Alon Bar-Lev; +Cc: netdev
In-Reply-To: <9e0cf0bf0801260058s797d2ea3r7af013d0957554d8@mail.gmail.com>
On Sat, 26 Jan 2008 10:58:58 +0200
"Alon Bar-Lev" <alon.barlev@gmail.com> wrote:
> On 1/26/08, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> > On 1/26/08, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > > The issue is that iproute is just blindly sending the deletes and
> > > not asking for acknowledgment status. Here is a trivial patch to iproute
> > > to fix that, but the problem is that it means it will slow down bulk removal.
> > >
> > > Maybe it should just check the first, or last delete to see if there are
> > > errors?
> > >
> > > diff --git a/ip/iproute.c b/ip/iproute.c
> > > index 7a885b0..b2ae879 100644
> > > --- a/ip/iproute.c
> > > +++ b/ip/iproute.c
> >
> > This should also be applied into ip/ipaddress.c, ip/ipneigh.c
> > Or even make one common function?
> >
> > I don't quite understand how "fast" is good if not complete... But
> > anyway... I will be happy to see this fix in next version... Maybe add
> > --fast argument? :)
> >
> > Alon.
> >
I found the correct solution. The kernel will send back an error after a bad
netlink message, even without ACK. so the code now checks. Should be checked in
and pushed for next version.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* [PATCH] SCTP: Fix kernel panic while received retransmitted ASCONF chunk 3 times
From: Wei Yongjun @ 2008-01-26 16:09 UTC (permalink / raw)
To: lksctp-developers, netdev; +Cc: Vlad Yasevich
While endpoint recived the ASCONF chunk with the same serial number for
3 times, the endpoint will panic.
Test as following:
Endpoint A Endpoint B
(ESTABLISHED) (ESTABLISHED)
ASCONF ---------->
(serial = 1)
<---------- ASCONF-ACK
ASCONF ---------->
(serial = 1)
<---------- ASCONF-ACK
ASCONF ---------->
(serial = 1)
kernel panic
This is besause if endpoint received the first ASCONF chunk, ASCONF-ACK
chunk will be send to reponse this ASCONF chunk, and the ASCONF-ACK will
be cached as asoc->addip_last_asconf_ack. After this, if ASCONF chunk
with the same serial number received will be treat as retransmitted
ASCONF chunk and just responsed with the cached
asoc->addip_last_asconf_ack. But before we use this cached chunk, we not
increase the user count of this chunk with sctp_chunk_hold() , after
send ASCONF-ACK, sctp_chunk_free() will be used to free
asoc->addip_last_asconf_ack. So when the third ASCONF chunk with the
same serial number is received, it responsed with the cached
asoc->addip_last_asconf_ack too, but asoc->addip_last_asconf_ack has
been freed, So kernel panic is occurred.
Folowing is the kernel panic message. And this patch fix this problem.
kernel BUG at net/sctp/outqueue.c:789!
invalid opcode: 0000 [#1] SMP
Modules linked in: md5 sctp ipv6 dm_mirror dm_mod sbs sbshc battery lp snd_ens1371
Pid: 0, comm: swapper Not tainted (2.6.24 #1)
EIP: 0060:[<c8a8f9ba>] EFLAGS: 00010216 CPU: 0
EIP is at sctp_outq_flush+0x16b/0x5d3 [sctp]
EAX: c735f43c EBX: c8a9dc64 ECX: 00000046 EDX: 00000000
ESI: c7aa3b00 EDI: c794ea00 EBP: c7a953d0 ESP: c0757cf4
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c0757000 task=c06d63a0 task.ti=c070f000)
Stack: c1107d80 c0441e6f c7aa3b00 00000064 00000000 c7a953bc c794eae0 c7a94000
034d0be8 00000001 00000000 00000000 00000001 00000000 c043bc66 c7aa3b00
c7a953bc c7a94000 c8a9c760 c042bfc6 c8a9f18d c7aa3b00 c7a953bc c8a90259
Call Trace:
[<c0441e6f>] tick_handle_periodic+0x17/0x5c
[<c043bc66>] autoremove_wake_function+0x15/0x35
[<c042bfc6>] printk+0x1b/0x1f
[<c8a90259>] sctp_outq_tail+0x128/0x172 [sctp]
[<c8a87631>] sctp_do_sm+0xeb0/0x103f [sctp]
[<c8a8a639>] sctp_assoc_bh_rcv+0xc1/0xf4 [sctp]
[<c8a8eb77>] sctp_inq_push+0x2a/0x2d [sctp]
[<c8a9924b>] sctp_rcv+0x5c3/0x6a4 [sctp]
[<c0425247>] try_to_wake_up+0x3bb/0x3c5
[<c0421f8a>] __update_rq_clock+0x19/0x156
[<c04409e1>] clocksource_get_next+0x39/0x3f
[<c0421f8a>] __update_rq_clock+0x19/0x156
[<c05dd9ba>] ip_local_deliver_finish+0xda/0x17d
[<c05dd8c1>] ip_rcv_finish+0x2c5/0x2e4
[<c0441e6f>] tick_handle_periodic+0x17/0x5c
[<c041ae2a>] smp_apic_timer_interrupt+0x74/0x80
[<c05ddb19>] ip_rcv+0x0/0x237
[<c05c15ed>] netif_receive_skb+0x328/0x392
[<c05c39c0>] process_backlog+0x5c/0x9a
[<c05c34ce>] net_rx_action+0x8d/0x163
[<c0432dbb>] run_timer_softirq+0x2f/0x156
[<c042fdd7>] __do_softirq+0x5d/0xc1
[<c0406f38>] do_softirq+0x59/0xa8
[<c0441e6f>] tick_handle_periodic+0x17/0x5c
[<c041ae2a>] smp_apic_timer_interrupt+0x74/0x80
[<c0403c87>] default_idle+0x0/0x3e
[<c0403c87>] default_idle+0x0/0x3e
[<c04058c0>] apic_timer_interrupt+0x28/0x30
[<c0403c87>] default_idle+0x0/0x3e
[<c0403cb3>] default_idle+0x2c/0x3e
[<c0403571>] cpu_idle+0x92/0xab
[<c07148ea>] start_kernel+0x2f7/0x2ff
[<c07140e0>] unknown_bootoption+0x0/0x195
=======================
Code: 00 89 f2 89 d8 e8 b3 88 00 00 89 d8 e8 1e 83 00 00 85 c0 89 44 24 2c
EIP: [<c8a8f9ba>] sctp_outq_flush+0x16b/0x5d3 [sctp] SS:ESP 0068:c0757cf4
Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
--- a/net/sctp/sm_statefuns.c 2008-01-25 00:50:27.000000000 -0500
+++ b/net/sctp/sm_statefuns.c 2008-01-25 03:03:15.000000000 -0500
@@ -3420,9 +3420,10 @@ sctp_disposition_t sctp_sf_do_asconf(con
* time and instead of re-processing the ASCONF (with the same
* serial number) it may just re-transmit the ASCONF-ACK.
*/
- if (asoc->addip_last_asconf_ack)
+ if (asoc->addip_last_asconf_ack) {
asconf_ack = asoc->addip_last_asconf_ack;
- else
+ sctp_chunk_hold(asconf_ack);
+ } else
return SCTP_DISPOSITION_DISCARD;
} else {
/* ADDIP 4.2 C4) Otherwise, the ASCONF Chunk is discarded since
^ permalink raw reply
* Re: [PATCH] FIXED_MII_100_FDX
From: Kumar Gala @ 2008-01-26 15:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list, netdev, Jeff Garzik
In-Reply-To: <479AD93D.30202@pikatech.com>
On Jan 26, 2008, at 12:54 AM, Sean MacLennan wrote:
> On the last git pull, FIXED_MII_100_FDX was removed from the phy
> Kconfig, but the Kconfig for CPMAC still tried to select it.
>
> Cheers,
> Sean
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 9af05a2..297a4b5 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1710,7 +1710,6 @@ config CPMAC
> depends on NET_ETHERNET && EXPERIMENTAL && AR7
> select PHYLIB
> select FIXED_PHY
> - select FIXED_MII_100_FDX
> help
> TI AR7 CPMAC Ethernet support
This patch isn't sufficient. AntonV has posted a proper fix that we
need Jeff to pick up.
http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050330.html
- k
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Jarek Poplawski @ 2008-01-26 15:19 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Joonwoo Park, Andrew Morton, netdev, bugme-daemon
In-Reply-To: <jeve5gd5mz.fsf@sykes.suse.de>
On Sat, Jan 26, 2008 at 03:27:00PM +0100, Andreas Schwab wrote:
> Jarek Poplawski <jarkao2@gmail.com> writes:
>
> > And, after re-reading this bugzilla report, I'm pretty sure the thing
> > should be done with 'ip route change' (but I didn't check if 2.6.24
> > knows about this...).
>
> $ man ip
> [...]
> ip route add - add new route
> ip route change - change route
> ip route replace - change or add new one
> [...]
>
> According to this "replace" should be a superset of "change".
According to this "replace" should be ...ambiguous. I could read this
"my/proper(?) way":
ip route replace - change with new one or add new one
And ...man could be wrong too after all! (...but not me!)
> Also, please check out comment#3, it also fails for replacing a route
> with something different (it's a route to an ipsec tunnel).
It all depends on which routes should be considered different (and it
should be specified somewhere BTW...).
But, I should've added my all reasoning was more about logic, and since
in real life change and replace are often equivalent, and iproute is
famous from using such equivalents in many places, your claim WRT this
man page could be completely right!
There should be only considered, if realization of this doesn't imply
bugs in some other places, like the one which fix caused this
"regression".
Regards,
Jarek P.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Jarek Poplawski @ 2008-01-26 14:32 UTC (permalink / raw)
To: Joonwoo Park; +Cc: Andrew Morton, netdev, bugme-daemon, schwab
In-Reply-To: <20080126141010.GC2624@ami.dom.local>
On Sat, Jan 26, 2008 at 03:10:10PM +0100, Jarek Poplawski wrote:
...
> [...] so old thing is always supposed to be
> destroyed (of course it's a matter of implementation or conditions in
> which moment this destruction takes place).
>
> So, 'replace with itself' is simply ambiguous: we can always delete the
> object first, to prepare the place for replacement, and find there is
> nothing to do after this - and it's probably not what somebody wanted.
As a matter of fact, the moment of destruction doesn't even matter:
assuming the replaced thing is destroyed in all 'common' cases, doing
this at the end isn't probably wanted as well - and skipping this
action makes an exception - what IMHO proves the concept is at least
inconsistent.
Jarek P.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Andreas Schwab @ 2008-01-26 14:27 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Joonwoo Park, Andrew Morton, netdev, bugme-daemon
In-Reply-To: <20080126141010.GC2624@ami.dom.local>
Jarek Poplawski <jarkao2@gmail.com> writes:
> And, after re-reading this bugzilla report, I'm pretty sure the thing
> should be done with 'ip route change' (but I didn't check if 2.6.24
> knows about this...).
$ man ip
[...]
ip route add - add new route
ip route change - change route
ip route replace - change or add new one
[...]
According to this "replace" should be a superset of "change".
Also, please check out comment#3, it also fails for replacing a route
with something different (it's a route to an ipsec tunnel).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Jarek Poplawski @ 2008-01-26 14:10 UTC (permalink / raw)
To: Joonwoo Park; +Cc: Andrew Morton, netdev, bugme-daemon, schwab
In-Reply-To: <20080126114036.GA2624@ami.dom.local>
On Sat, Jan 26, 2008 at 12:40:36PM +0100, Jarek Poplawski wrote:
> On Sat, Jan 26, 2008 at 02:16:01PM +0900, Joonwoo Park wrote:
> > 2008/1/26, Andrew Morton <akpm@linux-foundation.org>:
> > >
> > > But whatever. It used to work. People's scripts will break. Regression.
> > >
> >
> > Also I thought that 'replace with itself' should be error as like Jarek.
> > But it used to work and patch made a regression, it's my bad :(
>
> Actually, I don't think 'replace with itself' should be an error. I've
> only meant that lack of this possibility shouldn't be necessarily seen
> as error - there could be arguments for both sides.
...On the other hand, after some re-thinking, I actually think 'replace
with itself' should be considered a bug. I wondered about the possible
reason of this behaviour in a file system, and it seems replace just
means things like overwrite, so old thing is always supposed to be
destroyed (of course it's a matter of implementation or conditions in
which moment this destruction takes place).
So, 'replace with itself' is simply ambiguous: we can always delete the
object first, to prepare the place for replacement, and find there is
nothing to do after this - and it's probably not what somebody wanted.
And, after re-reading this bugzilla report, I'm pretty sure the thing
should be done with 'ip route change' (but I didn't check if 2.6.24
knows about this...).
Jarek P.
^ permalink raw reply
* [PATCHv2 2.6.24] fib_trie: apply fixes from fib_hash
From: Julian Anastasov @ 2008-01-26 12:44 UTC (permalink / raw)
To: David S. Miller; +Cc: Robert Olsson, netdev, Joonwoo Park
Update fib_trie with some fib_hash fixes:
- check for duplicate alternative routes for prefix+tos+priority when
replacing route
- properly insert by matching tos together with priority
- fix alias walking to use list_for_each_entry_continue for insertion
and deletion when fa_head is not NULL
- copy state from fa to new_fa on replace (not a problem for now)
- additionally, avoid replacement without error if new route is same,
as Joonwoo Park suggests.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
--- linux-2.6.24/net/ipv4/fib_trie.c_orig 2008-01-25 10:45:06.000000000 +0200
+++ linux-2.6.24/net/ipv4/fib_trie.c 2008-01-26 14:11:27.000000000 +0200
@@ -1203,20 +1203,45 @@ static int fn_trie_insert(struct fib_tab
* and we need to allocate a new one of those as well.
*/
- if (fa && fa->fa_info->fib_priority == fi->fib_priority) {
- struct fib_alias *fa_orig;
+ if (fa && fa->fa_tos == tos &&
+ fa->fa_info->fib_priority == fi->fib_priority) {
+ struct fib_alias *fa_first, *fa_match;
err = -EEXIST;
if (cfg->fc_nlflags & NLM_F_EXCL)
goto out;
+ /* We have 2 goals:
+ * 1. Find exact match for type, scope, fib_info to avoid
+ * duplicate routes
+ * 2. Find next 'fa' (or head), NLM_F_APPEND inserts before it
+ */
+ fa_match = NULL;
+ fa_first = fa;
+ fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list);
+ list_for_each_entry_continue(fa, fa_head, fa_list) {
+ if (fa->fa_tos != tos)
+ break;
+ if (fa->fa_info->fib_priority != fi->fib_priority)
+ break;
+ if (fa->fa_type == cfg->fc_type &&
+ fa->fa_scope == cfg->fc_scope &&
+ fa->fa_info == fi) {
+ fa_match = fa;
+ break;
+ }
+ }
+
if (cfg->fc_nlflags & NLM_F_REPLACE) {
struct fib_info *fi_drop;
u8 state;
- if (fi->fib_treeref > 1)
+ fa = fa_first;
+ if (fa_match) {
+ if (fa == fa_match)
+ err = 0;
goto out;
-
+ }
err = -ENOBUFS;
new_fa = kmem_cache_alloc(fn_alias_kmem, GFP_KERNEL);
if (new_fa == NULL)
@@ -1228,7 +1253,7 @@ static int fn_trie_insert(struct fib_tab
new_fa->fa_type = cfg->fc_type;
new_fa->fa_scope = cfg->fc_scope;
state = fa->fa_state;
- new_fa->fa_state &= ~FA_S_ACCESSED;
+ new_fa->fa_state = state & ~FA_S_ACCESSED;
list_replace_rcu(&fa->fa_list, &new_fa->fa_list);
alias_free_mem_rcu(fa);
@@ -1245,20 +1270,11 @@ static int fn_trie_insert(struct fib_tab
* uses the same scope, type, and nexthop
* information.
*/
- fa_orig = fa;
- list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) {
- if (fa->fa_tos != tos)
- break;
- if (fa->fa_info->fib_priority != fi->fib_priority)
- break;
- if (fa->fa_type == cfg->fc_type &&
- fa->fa_scope == cfg->fc_scope &&
- fa->fa_info == fi) {
- goto out;
- }
- }
+ if (fa_match)
+ goto out;
+
if (!(cfg->fc_nlflags & NLM_F_APPEND))
- fa = fa_orig;
+ fa = fa_first;
}
err = -ENOENT;
if (!(cfg->fc_nlflags & NLM_F_CREATE))
@@ -1614,9 +1630,8 @@ static int fn_trie_delete(struct fib_tab
pr_debug("Deleting %08x/%d tos=%d t=%p\n", key, plen, tos, t);
fa_to_delete = NULL;
- fa_head = fa->fa_list.prev;
-
- list_for_each_entry(fa, fa_head, fa_list) {
+ fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list);
+ list_for_each_entry_continue(fa, fa_head, fa_list) {
struct fib_info *fi = fa->fa_info;
if (fa->fa_tos != tos)
^ permalink raw reply
* [PATCHv2 2.6.24] fib: fix route replacement, fib_info is shared
From: Julian Anastasov @ 2008-01-26 12:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Joonwoo Park
fib_info can be shared by many route prefixes but we don't
want duplicate alternative routes for a prefix+tos+priority. Last
change was not correct to check fib_treeref because it accounts usage
from other prefixes. Additionally, avoid replacement without error
if new route is same, as Joonwoo Park suggests.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
--- linux-2.6.24/net/ipv4/fib_hash.c_orig 2008-01-25 10:45:06.000000000 +0200
+++ linux-2.6.24/net/ipv4/fib_hash.c 2008-01-26 14:11:34.000000000 +0200
@@ -434,19 +434,43 @@ static int fn_hash_insert(struct fib_tab
if (fa && fa->fa_tos == tos &&
fa->fa_info->fib_priority == fi->fib_priority) {
- struct fib_alias *fa_orig;
+ struct fib_alias *fa_first, *fa_match;
err = -EEXIST;
if (cfg->fc_nlflags & NLM_F_EXCL)
goto out;
+ /* We have 2 goals:
+ * 1. Find exact match for type, scope, fib_info to avoid
+ * duplicate routes
+ * 2. Find next 'fa' (or head), NLM_F_APPEND inserts before it
+ */
+ fa_match = NULL;
+ fa_first = fa;
+ fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list);
+ list_for_each_entry_continue(fa, &f->fn_alias, fa_list) {
+ if (fa->fa_tos != tos)
+ break;
+ if (fa->fa_info->fib_priority != fi->fib_priority)
+ break;
+ if (fa->fa_type == cfg->fc_type &&
+ fa->fa_scope == cfg->fc_scope &&
+ fa->fa_info == fi) {
+ fa_match = fa;
+ break;
+ }
+ }
+
if (cfg->fc_nlflags & NLM_F_REPLACE) {
struct fib_info *fi_drop;
u8 state;
- if (fi->fib_treeref > 1)
+ fa = fa_first;
+ if (fa_match) {
+ if (fa == fa_match)
+ err = 0;
goto out;
-
+ }
write_lock_bh(&fib_hash_lock);
fi_drop = fa->fa_info;
fa->fa_info = fi;
@@ -469,20 +493,11 @@ static int fn_hash_insert(struct fib_tab
* uses the same scope, type, and nexthop
* information.
*/
- fa_orig = fa;
- fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list);
- list_for_each_entry_continue(fa, &f->fn_alias, fa_list) {
- if (fa->fa_tos != tos)
- break;
- if (fa->fa_info->fib_priority != fi->fib_priority)
- break;
- if (fa->fa_type == cfg->fc_type &&
- fa->fa_scope == cfg->fc_scope &&
- fa->fa_info == fi)
- goto out;
- }
+ if (fa_match)
+ goto out;
+
if (!(cfg->fc_nlflags & NLM_F_APPEND))
- fa = fa_orig;
+ fa = fa_first;
}
err = -ENOENT;
^ permalink raw reply
* Re: [PATCH 00/14][v3]: Driver for Wireless RNDIS USB devices.
From: Jussi Kivilinna @ 2008-01-26 12:21 UTC (permalink / raw)
To: David Brownell
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, bjd-a1rhEgazXTw
In-Reply-To: <200801251509.24377.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
On Fri, 2008-01-25 at 15:09 -0800, David Brownell wrote:
> If they're the same, my ack (as maintainer for that infrastructure
> and, for now, rndis_host) still stands. I won't look at them again.
>
Ah, ok.
^ 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