* Re: [PATCH 2.6.24] fib_trie: apply fixes from fib_hash
From: Joonwoo Park @ 2008-01-26 5:18 UTC (permalink / raw)
To: Julian Anastasov
Cc: David S. Miller, Robert Olsson, netdev, Joonwoo Park,
Andrew Morton, Jarek Poplawski, schwab
In-Reply-To: <Pine.LNX.4.58.0801260427400.12635@u.domain.uli>
On Sat, Jan 26, 2008 at 04:40:30AM +0200, Julian Anastasov wrote:
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
> ---
>
> Not tested, someone please check the findings
>
> --- linux-2.6.24/net/ipv4/fib_trie.c_orig 2008-01-25 10:45:06.000000000 +0200
> +
> 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 && fa != fa_match)
> goto out;
> -
Isn't it possible to do this (fib_hash too)?
if (fa_match) {
if (fa != fa_match)
return 0;
goto out;
}
Thanks,
Joonwoo
^ permalink raw reply
* Re: [PATCH 2.6.24] fib_trie: apply fixes from fib_hash
From: Joonwoo Park @ 2008-01-26 5:20 UTC (permalink / raw)
To: Julian Anastasov
Cc: David S. Miller, Robert Olsson, netdev, Joonwoo Park,
Andrew Morton, Jarek Poplawski, schwab
In-Reply-To: <20080126051815.GA17278@ehus.geninetworks.com>
2008/1/26, Joonwoo Park <joonwpark81@gmail.com>:
> On Sat, Jan 26, 2008 at 04:40:30AM +0200, Julian Anastasov wrote:
> >
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > ---
> >
> > Not tested, someone please check the findings
> >
> > --- linux-2.6.24/net/ipv4/fib_trie.c_orig 2008-01-25 10:45:06.000000000 +0200
> > +
> > 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 && fa != fa_match)
> > goto out;
> > -
>
> Isn't it possible to do this (fib_hash too)?
> if (fa_match) {
> if (fa != fa_match)
Sorry!
if (fa == fa_match)
> return 0;
> goto out;
> }
>
> Thanks,
> Joonwoo
>
^ permalink raw reply
* Re: iproute2 (addr flush) infinite loop when unprivileged users
From: Alon Bar-Lev @ 2008-01-26 8:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <9e0cf0bf0801251622w203c515fn80cba5f233bd599d@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH 2.6.24] fib_trie: apply fixes from fib_hash
From: Julian Anastasov @ 2008-01-26 9:46 UTC (permalink / raw)
To: Joonwoo Park
Cc: David S. Miller, Robert Olsson, netdev, Andrew Morton,
Jarek Poplawski, schwab
In-Reply-To: <b25c3fa70801252120v1b928b15pd5a4e7bd2934161b@mail.gmail.com>
Hello,
On Sat, 26 Jan 2008, Joonwoo Park wrote:
> > > Not tested, someone please check the findings
news: simple testing of patched fib_trie seems to work
> > > - if (fi->fib_treeref > 1)
> > > + fa = fa_first;
> > > + if (fa_match && fa != fa_match)
> > > goto out;
> > > -
> >
> > Isn't it possible to do this (fib_hash too)?
> > if (fa_match) {
> > if (fa != fa_match)
> Sorry!
> if (fa == fa_match)
> > return 0;
> > goto out;
> > }
I see, your idea is to optimize the case when matched
parameters are same. Considering the used fi is same I don't see
any problems. I'll prepare 2nd version of both patches in
next hours.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Jarek Poplawski @ 2008-01-26 11:40 UTC (permalink / raw)
To: Joonwoo Park; +Cc: Andrew Morton, netdev, bugme-daemon, schwab
In-Reply-To: <b25c3fa70801252116h2b9f12c9j65a8a75dbd0d5662@mail.gmail.com>
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.
IMHO, there should be simply analyzed pros and cons of doing it in
this particular place, so: if there is any gain in doing this, and if
possible complications or problems with performance, security etc.
don't prevail such a gain.
And I don't think a regression argument should be valid at all if
there are removed any unlogical, error-prone or otherwise problematic
options (I don't know if this is such case), even if they are not
obvious bugs - especially if it's still possible to do the same
'proper' way.
Regards,
Jarek P.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9816] New: cannot replace route
From: Jarek Poplawski @ 2008-01-26 12:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, joonwpark81, bugme-daemon, schwab
In-Reply-To: <20080125192026.e667f396.akpm@linux-foundation.org>
On Fri, Jan 25, 2008 at 07:20:26PM -0800, Andrew Morton wrote:
...
> That's not a very good analogy - the source is a kernel object. A better
> example would be:
>
> linux-2.6.24-rc8:
>
> echo foo > /tmp/1
> echo bar > /tmp/2
> echo foo > /tmp/1
>
> linux-2.6.24:
>
> echo foo > /tmp/1
> echo bar > /tmp/2
> echo foo > /tmp/1
> sh: cannot write /tmp/1: Inalid argument
Probably you are right. When I have some time to build and boot 2.6.24
at last, I hope I'll find what this example is about...
> But whatever. It used to work. People's scripts will break. Regression.
Do you mean people didn't have to change their scripts before, e.g.
from linux 2.0.? Scripts are kind of programs, and both APIs and some
'undocumented' features are achanging...
Regards,
Jarek P.
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH net-2.6.25 4/7][ATM]: [br2864] routed support
From: chas williams - CONTRACTOR @ 2008-01-26 12:20 UTC (permalink / raw)
To: Chung-Chi Lo; +Cc: netdev, davem
In-Reply-To: <3f696b20801152016r52048016g7c293dbfdc6c9f29@mail.gmail.com>
In message <3f696b20801152016r52048016g7c293dbfdc6c9f29@mail.gmail.com>,"Chung-
Chi Lo" writes:
>Question to decode the encaps=VCMUX and bridge mode:
>
>This line
>skb_pull((skb, BR2684_PAD_LEN + ETH_HLEN);
>should be replaced by
>skb_pull((skb, BR2684_PAD_LEN);
you are correct.
>By the way, this routed mode patch doesn't include encaps=VCMUX and
>RFC2684 routed
>protocol decapsulation?
yep. eric believes the following should fix both problems:
commit 43e4b025ffe130cd6a292fa9ff909e39a88f849c
Author: Chas Williams - CONTRACTOR <chas@relax.cmf.nrl.navy.mil>
Date: Sat Jan 26 07:18:26 2008 -0500
[ATM]: [br2864] fix vcmux support
From: Eric Kinzie <ekinzie@cmf.nrl.navy.mil>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 31347cb..97b422c 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -400,15 +400,20 @@ static void br2684_push(struct atm_vcc *atmvcc, struct sk_buff *skb)
return;
}
- } else {
- /* first 2 chars should be 0 */
- if (*((u16 *) (skb->data)) != 0) {
- brdev->stats.rx_errors++;
- dev_kfree_skb(skb);
- return;
+ } else { /* vc-mux */
+ if (brdev->payload == p_routed) {
+ skb_reset_network_header(skb);
+ skb->pkt_type = PACKET_HOST;
+ } else { /* p_bridged */
+ /* first 2 chars should be 0 */
+ if (*((u16 *) (skb->data)) != 0) {
+ brdev->stats.rx_errors++;
+ dev_kfree_skb(skb);
+ return;
+ }
+ skb_pull(skb, BR2684_PAD_LEN);
+ skb->protocol = eth_type_trans(skb, net_dev);
}
- skb_pull(skb, BR2684_PAD_LEN + ETH_HLEN); /* pad, dstmac, srcmac, ethtype */
- skb->protocol = eth_type_trans(skb, net_dev);
}
#ifdef CONFIG_ATM_BR2684_IPFILTER
^ permalink raw reply related
* 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
* [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
* [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
* 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
* 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: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: 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: [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
* [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: 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
* 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: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
* 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: 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
* 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: [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: 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: [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
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