* Re: [PATCH] Add me as maintainer of the RDC r6040 driver
From: Jeff Garzik @ 2008-01-12 22:22 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Francois Romieu
In-Reply-To: <200712191130.31897.florian.fainelli@telecomint.eu>
Florian Fainelli wrote:
> This patch adds me as maintainer of the RDC R6040 Fast Ethernet driver.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
applied
^ permalink raw reply
* Re: [PATCH] r6040 various cleanups
From: Jeff Garzik @ 2008-01-12 22:22 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Francois Romieu, Sten Wang, netdev
In-Reply-To: <200712121044.01820.florian.fainelli@telecomint.eu>
Florian Fainelli wrote:
> The following patch applies to Jeff's netdev-2.6 tree with Francois's r6040 recent changes pulled to this tree.
>
> - remove unused private structure members
> - functions to allocate/free TX and RX buffers
> - recover from transmit timeout
> - use netdev_alloc_skb instead of dev_alloc_skb
> - do not use a private stats structure to store statistics
> - break each TX/RX error to a separate line for better reading
> - better control of the timer
> - clean the IRQ handler
> - fix typos and spelling mistakes in the driver
>
> Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
ack, but the patch was corrupted...
^ permalink raw reply
* Re: [PATCH 2/4] [ROSE] rose_get_route() template
From: Bernard Pidoux @ 2008-01-12 21:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ralf Baechle DL5RB, Alexey Dobriyan, David Miller,
Linux Netdev List
In-Reply-To: <478923FD.9040704@cosmosbay.com>
Eric Dumazet wrote:
> Bernard Pidoux a écrit :
>> From 46bccce1e660a39bcc8f8cf87d4c17de33f4ba48 Mon Sep 17 00:00:00 2001
>> From: Bernard Pidoux <f6bvp@amsat.org>
>> Date: Thu, 10 Jan 2008 23:01:46 +0100
>> Subject: [PATCH 2/4] [ROSE] template declaration for rose_get_route()
>>
>> Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
>> ---
>> include/net/rose.h | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/net/rose.h b/include/net/rose.h
>> index e5bb084..d3ab453 100644
>> --- a/include/net/rose.h
>> +++ b/include/net/rose.h
>> @@ -202,6 +202,7 @@ extern struct net_device *rose_dev_first(void);
>> extern struct net_device *rose_dev_get(rose_address *);
>> extern struct rose_route *rose_route_free_lci(unsigned int, struct
>> rose_neigh *);
>> extern struct rose_neigh *rose_get_neigh(rose_address *, unsigned
>> char *, unsigned char *);
>> +extern struct rose_neigh *rose_get_route(rose_address *, unsigned
>> char *, unsigned char *);
>> extern int rose_rt_ioctl(unsigned int, void __user *);
>> extern void rose_link_failed(ax25_cb *, int);
>> extern int rose_route_frame(struct sk_buff *, ax25_cb *);
>> --
>
> Strange... if rose_get_route() is used only in net/rose/rose_route.c,
> why dont you define it static, and not extern in include/net/rose.h ?
>
>
>
I agree. You are perfectly right.
There is no need to declare rose_get_route() external.
I stupidly copied rose_get_neigh()definition from which I derived
rose_get_route();
Also I am not sure that setting cause and diagnostic is necessary, as
they are not used by the calling function.
By the way. I made a typo in [PATCH 4/4].
Instead of "Initial connection to rose neighbour nodes was unusually,
t0 timer was blocked and application program could not
use socket."
One should read
"Initial connection to rose neighbour nodes was unusually,
long, t0 timer was blocked and application program could not
use socket."
Bernard P.
^ permalink raw reply
* Re: [PATCH 1/8] [TCP]: Uninline tcp_set_state
From: Arnaldo Carvalho de Melo @ 2008-01-12 21:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080112130355.74c39ae7@deepthought>
Em Sat, Jan 12, 2008 at 01:03:55PM -0800, Stephen Hemminger escreveu:
> On Sat, 12 Jan 2008 11:40:10 +0200
> "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> wrote:
> > -
> > -#ifdef STATE_TRACE
> > - SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk, statename[oldstate],statename[state]);
> > -#endif
> > -}
> >
>
>
> Since the function is called with a constant state, I guess the assumption
> was that gcc would be smart enough to only include the code needed, it looks like
> either code was bigger or the compiler was dumber than expected
Yup, that is one more instance where having proper tools to check if our
assumptions are right proves fruitful. I'm very happy for Ilpo to be
doing this work and making the case for us to work even harder on having
such tools to check if our assumptions are right.
- Arnaldo
P.S. subscribe to dwarves@vger.kernel.org and help us produce even more
such compiler watchdogs, right now changes to the dwarves are being made
such that we can check if the layout we think is optimal really holds to
that promise :-)
Soon I'll be looking at Ulrich's promising new disasm stuff :-)
Archives: http://news.gmane.org/gmane.comp.debugging.dwarves
- Arnaldo
^ permalink raw reply
* Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: Herbert Xu @ 2008-01-12 21:19 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, Netdev
In-Reply-To: <Pine.LNX.4.64.0801121420220.19333@kivilampi-30.cs.helsinki.fi>
On Sat, Jan 12, 2008 at 02:59:50PM +0200, Ilpo Järvinen wrote:
>
> Here's one example...
>
> From: "=?utf-8?q?Ilpo_J=C3=A4rvinen?=" <ilpo.jarvinen@helsinki.fi>
> ...
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
>
> Something still needed besides these to declare email utf-8?
If that's what it said then it'd be perfect. However, quoting from this
very email that I'm replying to:
Content-Type: text/plain; charset=iso-8859-1
> > So you probably want to fix that up or your name may show up as Jävinen
> > on the reader's screen.
>
> Did you actually see this? I'd expect to see that as well but no, From is
> correctly decoded by my ISO-8859-1'ish MUA, aha, seems that I still have
> something to do to deal with the Signed-off line.
Yeah I did see that. Otherwise I wouldn't have noticed :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 9/9] fix sparse warnings
From: Stephen Hemminger @ 2008-01-12 21:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Robert Olsson, netdev
In-Reply-To: <4788A17D.5070903@cosmosbay.com>
On Sat, 12 Jan 2008 12:16:13 +0100
Eric Dumazet <dada1@cosmosbay.com> wrote:
> Stephen Hemminger a écrit :
> > Make FIB TRIE go through sparse checker without warnings.
> >
> > Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
>
> Hi Stephen
>
> While reviewing your patches (and fib code) I had some questions :
>
> 1) I was wondering isn't trie_collect_stats() a potential cpu hog
> (big latency) ?
>
> 2) struct tnode layout
> If tnode->bits is large enough, we allocate a big area
> of memory but roughly use only first half of it.
> We could use a better scheme with an extra indirection. For small
> nodes, we use space right after tnode, but for big nodes, we allocate
> a power of two set of pages, to exactly match the memory need.
>
> 3) 'pos' and 'bits' fields of 'struct tnode' might be converted to
> plain uchar, instead of 5-bits fields, to reduce complexity for
> generated code.
>
> 4) full_children & empty_children being 'unsigned short',
> we probably are limited to 2^15 elements, but I could not
> find this limit enforced somewhere.
>
> [FIB]: Reduce text size of net/ipv4/fib_trie.o
>
> In struct tnode, we use two fields of 5 bits for 'pos' and 'bits'.
> Switching to plain 'unsigned char' (8 bits) take the same space
> because of compiler alignments, and reduce text size by 435 bytes
> on i386.
>
> On i386 :
> $ size net/ipv4/fib_trie.o.before_patch net/ipv4/fib_trie.o
> text data bss dec hex filename
> 13714 4 64 13782 35d6 net/ipv4/fib_trie.o.before
> 13279 4 64 13347 3423 net/ipv4/fib_trie.o
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
I agree they should not have been bitfields in the first place.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH 9/9] fix sparse warnings
From: Stephen Hemminger @ 2008-01-12 21:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Robert Olsson, netdev
In-Reply-To: <4788A17D.5070903@cosmosbay.com>
On Sat, 12 Jan 2008 12:16:13 +0100
Eric Dumazet <dada1@cosmosbay.com> wrote:
> Stephen Hemminger a écrit :
> > Make FIB TRIE go through sparse checker without warnings.
> >
> > Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
>
> Hi Stephen
>
> While reviewing your patches (and fib code) I had some questions :
>
> 1) I was wondering isn't trie_collect_stats() a potential cpu hog
> (big latency) ?
>
> 2) struct tnode layout
> If tnode->bits is large enough, we allocate a big area
> of memory but roughly use only first half of it.
> We could use a better scheme with an extra indirection. For small
> nodes, we use space right after tnode, but for big nodes, we allocate
> a power of two set of pages, to exactly match the memory need.
>
> 3) 'pos' and 'bits' fields of 'struct tnode' might be converted to
> plain uchar, instead of 5-bits fields, to reduce complexity for
> generated code.
>
> 4) full_children & empty_children being 'unsigned short',
> we probably are limited to 2^15 elements, but I could not
> find this limit enforced somewhere.
Remember that the code should be optimized for lookup, not management
operations. We ran into this during testing (the test suite was looking
for number of routes), thats why I put in the size field.
The existing dump code is really slow:
1) FIB_TRIE Under KVM:
load 164393 routes 12.436 sec
ip route | wc -l 12.569 sec
grep /proc/net/route 25.357 sec
99% of the cpu time is spent in nextleaf() during these dump operations.
2) FIB_HASH Under KVM:
load 164393 routes 10.833 sec
ip route | wc -l 1.981 sec
grep /proc/net/route 0.204 sec
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH 1/8] [TCP]: Uninline tcp_set_state
From: Stephen Hemminger @ 2008-01-12 21:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <12001308171262-git-send-email-ilpo.jarvinen@helsinki.fi>
On Sat, 12 Jan 2008 11:40:10 +0200
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> wrote:
> net/ipv4/tcp.c:
> tcp_close_state | -226
> tcp_done | -145
> tcp_close | -564
> tcp_disconnect | -141
> 4 functions changed, 1076 bytes removed, diff: -1076
>
> net/ipv4/tcp_input.c:
> tcp_fin | -86
> tcp_rcv_state_process | -164
> 2 functions changed, 250 bytes removed, diff: -250
>
> net/ipv4/tcp_ipv4.c:
> tcp_v4_connect | -209
> 1 function changed, 209 bytes removed, diff: -209
>
> net/ipv4/arp.c:
> arp_ignore | +5
> 1 function changed, 5 bytes added, diff: +5
>
> net/ipv6/tcp_ipv6.c:
> tcp_v6_connect | -158
> 1 function changed, 158 bytes removed, diff: -158
>
> net/sunrpc/xprtsock.c:
> xs_sendpages | -2
> 1 function changed, 2 bytes removed, diff: -2
>
> net/dccp/ccids/ccid3.c:
> ccid3_update_send_interval | +7
> 1 function changed, 7 bytes added, diff: +7
>
> net/ipv4/tcp.c:
> tcp_set_state | +238
> 1 function changed, 238 bytes added, diff: +238
>
> built-in.o:
> 12 functions changed, 250 bytes added, 1695 bytes removed, diff: -1445
>
> I've no explanation why some unrelated changes seem to occur
> consistently as well (arp_ignore, ccid3_update_send_interval;
> I checked the arp_ignore asm and it seems to be due to some
> reordered of operation order causing some extra opcodes to be
> generated). Still, the benefits are pretty obvious from the
> codiff's results.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> Cc: Andi Kleen <andi@firstfloor.org>
> ---
> include/net/tcp.h | 35 +----------------------------------
> net/ipv4/tcp.c | 35 +++++++++++++++++++++++++++++++++++
> 2 files changed, 36 insertions(+), 34 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 48081ad..306580c 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -926,40 +926,7 @@ static const char *statename[]={
> "Close Wait","Last ACK","Listen","Closing"
> };
> #endif
> -
> -static inline void tcp_set_state(struct sock *sk, int state)
> -{
> - int oldstate = sk->sk_state;
> -
> - switch (state) {
> - case TCP_ESTABLISHED:
> - if (oldstate != TCP_ESTABLISHED)
> - TCP_INC_STATS(TCP_MIB_CURRESTAB);
> - break;
> -
> - case TCP_CLOSE:
> - if (oldstate == TCP_CLOSE_WAIT || oldstate == TCP_ESTABLISHED)
> - TCP_INC_STATS(TCP_MIB_ESTABRESETS);
> -
> - sk->sk_prot->unhash(sk);
> - if (inet_csk(sk)->icsk_bind_hash &&
> - !(sk->sk_userlocks & SOCK_BINDPORT_LOCK))
> - inet_put_port(&tcp_hashinfo, sk);
> - /* fall through */
> - default:
> - if (oldstate==TCP_ESTABLISHED)
> - TCP_DEC_STATS(TCP_MIB_CURRESTAB);
> - }
> -
> - /* Change state AFTER socket is unhashed to avoid closed
> - * socket sitting in hash tables.
> - */
> - sk->sk_state = state;
> -
> -#ifdef STATE_TRACE
> - SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk, statename[oldstate],statename[state]);
> -#endif
> -}
>
Since the function is called with a constant state, I guess the assumption
was that gcc would be smart enough to only include the code needed, it looks like
either code was bigger or the compiler was dumber than expected
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH 2/4] [ROSE] rose_get_route() template
From: Eric Dumazet @ 2008-01-12 20:33 UTC (permalink / raw)
To: Bernard Pidoux
Cc: Ralf Baechle DL5RB, Alexey Dobriyan, David Miller,
Linux Netdev List
In-Reply-To: <47892051.8000404@ccr.jussieu.fr>
Bernard Pidoux a écrit :
> From 46bccce1e660a39bcc8f8cf87d4c17de33f4ba48 Mon Sep 17 00:00:00 2001
> From: Bernard Pidoux <f6bvp@amsat.org>
> Date: Thu, 10 Jan 2008 23:01:46 +0100
> Subject: [PATCH 2/4] [ROSE] template declaration for rose_get_route()
>
> Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
> ---
> include/net/rose.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/rose.h b/include/net/rose.h
> index e5bb084..d3ab453 100644
> --- a/include/net/rose.h
> +++ b/include/net/rose.h
> @@ -202,6 +202,7 @@ extern struct net_device *rose_dev_first(void);
> extern struct net_device *rose_dev_get(rose_address *);
> extern struct rose_route *rose_route_free_lci(unsigned int, struct
> rose_neigh *);
> extern struct rose_neigh *rose_get_neigh(rose_address *, unsigned char
> *, unsigned char *);
> +extern struct rose_neigh *rose_get_route(rose_address *, unsigned char
> *, unsigned char *);
> extern int rose_rt_ioctl(unsigned int, void __user *);
> extern void rose_link_failed(ax25_cb *, int);
> extern int rose_route_frame(struct sk_buff *, ax25_cb *);
> --
Strange... if rose_get_route() is used only in net/rose/rose_route.c, why dont
you define it static, and not extern in include/net/rose.h ?
^ permalink raw reply
* [PATCH 4/4] [ROSE] ENETUNREACH held rose_connect()
From: Bernard Pidoux @ 2008-01-12 20:23 UTC (permalink / raw)
To: Ralf Baechle DL5RB, Alexey Dobriyan, David Miller,
Linux Netdev List
In-Reply-To: <47630274.1080706@ccr.jussieu.fr>
From 5c50971c6088f380eafdb1a6a7de5a5d3686c8c7 Mon Sep 17 00:00:00 2001
From: Bernard Pidoux <f6bvp@amsat.org>
Date: Sat, 12 Jan 2008 20:19:34 +0100
Subject: [PATCH 4/4] [ROSE] ENETUNREACH held rose_connect()
Initial connection to rose neighbour nodes was unusually,
t0 timer was blocked and application program could not
use socket.
I performed a number of trials in order to find what was
slowing rose_connect() and blocking ROSE t0 timer.
Replacing the type of error returned did not cure the problem.
Finally removing the error returned when rose->neighbour is NULL
is the solution.
Without err = -ENETUNREACH rose_connect() returns default err = 0.
Doing that, t0 timer is running, rose_connect() performs adjacent
rose node connections as needed and rose frames are well routed.
Also, application programs can access rose connect socket.
Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
---
net/rose/af_rose.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 9419946..5a8c886 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -752,7 +752,6 @@ static int rose_connect(struct socket *sock, struct
sockaddr *uaddr, int addr_le
rose->neighbour = rose_get_neigh(&addr->srose_addr, &cause,
&diagnostic);
if (!rose->neighbour)
- err = -ENETUNREACH;
goto out_release;
rose->lci = rose_new_lci(rose->neighbour);
--
1.5.3.7
^ permalink raw reply related
* [PATCH 3/4] [ROSE] return with lock held
From: Bernard Pidoux @ 2008-01-12 20:20 UTC (permalink / raw)
To: Ralf Baechle DL5RB, Alexey Dobriyan, David Miller,
Linux Netdev List
In-Reply-To: <47630274.1080706@ccr.jussieu.fr>
From bc108e5ee0b0353c3707df25e12e40038da0160a Mon Sep 17 00:00:00 2001
From: Bernard Pidoux <f6bvp@amsat.org>
Date: Fri, 11 Jan 2008 10:23:55 +0100
Subject: [PATCH 3/4] [ROSE] return with lock held
Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
================================================
[ BUG: lock held when returning to user space! ]
------------------------------------------------
fpacwpd/3057 is leaving the kernel with locks still held!
1 lock held by fpacwpd/3057:
#0: (sk_lock-AF_ROSE){--..}, at: [<d8bfda7f>] rose_connect+0x6c/0x357
[rose]
---
net/rose/af_rose.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 8f70ad8..9419946 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -752,7 +752,8 @@ static int rose_connect(struct socket *sock, struct
sockaddr *uaddr, int addr_le
rose->neighbour = rose_get_neigh(&addr->srose_addr, &cause,
&diagnostic);
if (!rose->neighbour)
- return -ENETUNREACH;
+ err = -ENETUNREACH;
+ goto out_release;
rose->lci = rose_new_lci(rose->neighbour);
if (!rose->lci) {
--
1.5.3.7
^ permalink raw reply related
* [PATCH 2/4] [ROSE] rose_get_route() template
From: Bernard Pidoux @ 2008-01-12 20:17 UTC (permalink / raw)
To: Ralf Baechle DL5RB, Alexey Dobriyan, David Miller,
Linux Netdev List
In-Reply-To: <47630274.1080706@ccr.jussieu.fr>
From 46bccce1e660a39bcc8f8cf87d4c17de33f4ba48 Mon Sep 17 00:00:00 2001
From: Bernard Pidoux <f6bvp@amsat.org>
Date: Thu, 10 Jan 2008 23:01:46 +0100
Subject: [PATCH 2/4] [ROSE] template declaration for rose_get_route()
Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
---
include/net/rose.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/net/rose.h b/include/net/rose.h
index e5bb084..d3ab453 100644
--- a/include/net/rose.h
+++ b/include/net/rose.h
@@ -202,6 +202,7 @@ extern struct net_device *rose_dev_first(void);
extern struct net_device *rose_dev_get(rose_address *);
extern struct rose_route *rose_route_free_lci(unsigned int, struct
rose_neigh *);
extern struct rose_neigh *rose_get_neigh(rose_address *, unsigned char
*, unsigned char *);
+extern struct rose_neigh *rose_get_route(rose_address *, unsigned char
*, unsigned char *);
extern int rose_rt_ioctl(unsigned int, void __user *);
extern void rose_link_failed(ax25_cb *, int);
extern int rose_route_frame(struct sk_buff *, ax25_cb *);
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] [ROSE] finding a connected ROSE neighbor node
From: Bernard Pidoux @ 2008-01-12 20:15 UTC (permalink / raw)
To: Ralf Baechle DL5RB, Alexey Dobriyan, David Miller,
Linux Netdev List
In-Reply-To: <47630274.1080706@ccr.jussieu.fr>
Hi,
I propose to drop the previously submitted patch for I performed more
investigations on ROSE frame routing and found that it was not
completely satisfactory.
Please find here another commit to net-2.6.25 with explanations.
From fd66cc115e058b2fc63a0e26aa73f1d27113105a Mon Sep 17 00:00:00 2001
From: Bernard Pidoux <f6bvp@amsat.org>
Date: Thu, 10 Jan 2008 23:10:44 +0100
Subject: [PATCH 1/4] [ROSE] new rose_get_route() function
rose_get_neigh() was called by two different functions.
Firstly, by rose_connect() in order to establish connections to
adjacent rose nodes. This worked correctly.
Secondly, it was called by rose_route_frame() to find a route
via an adjacent node. This was not working efficiently, for the
proper test was not performed in order to check if the node was
already connected.
A new function rose_get_route() is devoted to frame routing.
It returns a ROSE node address for sending a frame to the
specified destination via a connected node.
Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
---
net/rose/rose_route.c | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 540c0f2..ec79567 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -662,6 +662,38 @@ struct rose_route *rose_route_free_lci(unsigned int
lci, struct rose_neigh *neig
}
/*
+ * Find an opened route given a ROSE address.
+ */
+struct rose_neigh *rose_get_route(rose_address *addr, unsigned char *cause,
+ unsigned char *diagnostic)
+{
+ struct rose_node *node;
+ int failed = 0;
+ int i;
+
+ for (node = rose_node_list; node != NULL; node = node->next) {
+ if (rosecmpm(addr, &node->address, node->mask) == 0) {
+ for (i = 0; i < node->count; i++) {
+ if (node->neighbour[i]->restarted)
+ return node->neighbour[i];
+ failed = 1;
+ }
+ }
+ }
+
+ if (failed) {
+ *cause = ROSE_OUT_OF_ORDER;
+ *diagnostic = 0;
+ } else {
+ *cause = ROSE_NOT_OBTAINABLE;
+ *diagnostic = 0;
+ }
+
+ return NULL;
+}
+
+
+/*
* Find a neighbour given a ROSE address.
*/
struct rose_neigh *rose_get_neigh(rose_address *addr, unsigned char
*cause,
@@ -1019,7 +1051,7 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb
*ax25)
rose_route = rose_route->next;
}
- if ((new_neigh = rose_get_neigh(dest_addr, &cause, &diagnostic))
== NULL) {
+ if ((new_neigh = rose_get_route(dest_addr, &cause, &diagnostic))
== NULL) {
rose_transmit_clear_request(rose_neigh, lci, cause,
diagnostic);
goto out;
}
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH][ROSE][AX25] af_ax25: possible circular locking
From: Bernard Pidoux F6BVP @ 2008-01-12 19:48 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, ralf, adobriyan, netdev
In-Reply-To: <20080111094005.GA2708@ff.dom.local>
Jarek Poplawski wrote:
> On Thu, Jan 10, 2008 at 09:22:42PM -0800, David Miller wrote:
>> From: Jarek Poplawski <jarkao2@gmail.com>
>> Date: Sun, 30 Dec 2007 15:13:23 +0100
>>
>>> On Sat, Dec 29, 2007 at 07:14:43PM -0800, David Miller wrote:
> ...
>> I've removed the warning and made the branch back to 'again'
>> unconditional as I think this is the safest version of the
>> change.
>>
>> I'll push this upstream, thanks for fixing this Jarek.
>>
>
> Thanks for checking this and making safer!
>
> Regards,
> Jarek P.
>
>
I would also like to thank both Jarek and David for this patch.
It is very helpful and probably safe for after killing kissattach
we don't want to use attached ax25 devices.
Regards,
Bernard Pidoux
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: Rafael J. Wysocki @ 2008-01-12 19:13 UTC (permalink / raw)
To: supersud501
Cc: Stephen Hemminger, Andrew Morton, netdev, linux-acpi,
bugme-daemon
In-Reply-To: <4788B191.1060001@yahoo.de>
> http://bugzilla.kernel.org/show_bug.cgi?id=9721
On Saturday, 12 of January 2008, supersud501 wrote:
> I'll do the git-bisect (just downloading linux-2.6.git), but i forgot to
> mention one little thing: i'm using x64 version of kernel - does this
> play an important role?
No, it doesn't.
^ permalink raw reply
* Re: [PATCH 6/8] [NETFILTER] xt_policy.c: kill some bloat
From: Patrick McHardy @ 2008-01-12 19:03 UTC (permalink / raw)
To: David Miller; +Cc: ilpo.jarvinen, netdev, netfilter-devel
In-Reply-To: <20080112.032318.201654370.davem@davemloft.net>
David Miller wrote:
> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Sat, 12 Jan 2008 11:34:27 +0200
>
> Ilpo, please post netfilter patches to netfilter-devel,
> CC:'ing Patrick McHardy.
>
> Patrick, please review, thanks.
This looks fine to me, thanks Ilpo.
>> net/netfilter/xt_policy.c:
>> policy_mt | -906
>> 1 function changed, 906 bytes removed, diff: -906
>>
>> net/netfilter/xt_policy.c:
>> match_xfrm_state | +427
>> 1 function changed, 427 bytes added, diff: +427
>>
>> net/netfilter/xt_policy.o:
>> 2 functions changed, 427 bytes added, 906 bytes removed, diff: -479
>>
>> Alternatively, this could be done by combining identical
>> parts of the match_policy_in/out()
That would probably end up rather ugly because they walk
over different structures and have some minor differences.
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] fib_semantics: prevent long hash chains in access server config
From: Benjamin LaHaise @ 2008-01-12 18:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This is a patch from a while ago that I'm resending. Basically, in access
server configurations, a lot of routes have the same local ip address but on
different devices. This fixes the long chains that result from not including
the device index in the hash.
-ben
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 1351a26..5375824 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -196,11 +196,21 @@ static __inline__ int nh_comp(const struct fib_info *fi, const struct fib_info *
return 0;
}
+static inline unsigned int fib_devindex_hashfn(unsigned int val)
+{
+ unsigned int mask = DEVINDEX_HASHSIZE - 1;
+
+ return (val ^
+ (val >> DEVINDEX_HASHBITS) ^
+ (val >> (DEVINDEX_HASHBITS * 2))) & mask;
+}
+
static inline unsigned int fib_info_hashfn(const struct fib_info *fi)
{
unsigned int mask = (fib_hash_size - 1);
unsigned int val = fi->fib_nhs;
+ val ^= fib_devindex_hashfn(fi->fib_dev->ifindex);
val ^= fi->fib_protocol;
val ^= (__force u32)fi->fib_prefsrc;
val ^= fi->fib_priority;
@@ -234,15 +244,6 @@ static struct fib_info *fib_find_info(const struct fib_info *nfi)
return NULL;
}
-static inline unsigned int fib_devindex_hashfn(unsigned int val)
-{
- unsigned int mask = DEVINDEX_HASHSIZE - 1;
-
- return (val ^
- (val >> DEVINDEX_HASHBITS) ^
- (val >> (DEVINDEX_HASHBITS * 2))) & mask;
-}
-
/* Check, that the gateway is already configured.
Used only by redirect accept routine.
*/
^ permalink raw reply related
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Jay Vosburgh @ 2008-01-12 17:56 UTC (permalink / raw)
To: Krzysztof Oledzki
Cc: Andy Gospodarek, netdev, Jeff Garzik, David Miller, Herbert Xu
In-Reply-To: <Pine.LNX.4.64.0801121150001.16465@bizon.gios.gov.pl>
Krzysztof Oledzki <olel@ans.pl> wrote:
[...]
>Exactly. All I need to do is to reboot my server, I have 100% probability
>to get the warning.
I wish it were that easy for me; I'm not sure what magic thing
you've got on your server or network that I don't, but I haven't been
able to make this lockdep warning happen at all.
>Right. So, what is the final patch? I would like to test it if that's
>possible. ;)
Can you test the following and let me know if it triggers the
warning? I believe this is the minimum locking needed, and based on
input from Herbert, we shouldn't need to hold the lock at _bh. If this
one works, and nobody sees any other issues with it, then it's the final
patch for this lockdep problem. I'll add some deep, meaningful comments
to explain the locking a bit (i.e., we're called with rtnl for the
allmulti and promisc cases, so we're ok there without additional locks,
but the later code could be called from anywhere, so it needs locks to
prevent the slave list from changing, but the mc_lists themselves are
covered by the netif_tx_lock that all callers will hold), but this would
be the actual code change.
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 77d004d..6906dbc 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3937,8 +3937,6 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
struct bonding *bond = bond_dev->priv;
struct dev_mc_list *dmi;
- write_lock_bh(&bond->lock);
-
/*
* Do promisc before checking multicast_mode
*/
@@ -3959,6 +3957,8 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
bond_set_allmulti(bond, -1);
}
+ read_lock(&bond->lock);
+
bond->flags = bond_dev->flags;
/* looking for addresses to add to slaves' mc list */
@@ -3979,7 +3979,7 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
bond_mc_list_destroy(bond);
bond_mc_list_copy(bond_dev->mc_list, bond, GFP_ATOMIC);
- write_unlock_bh(&bond->lock);
+ read_unlock(&bond->lock);
}
/*
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply related
* [XFRM]: alg_key_len should be unsigned to avoid integer divides
From: Eric Dumazet @ 2008-01-12 17:29 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 235 bytes --]
alg_key_len is currently defined as 'signed int'. This unfortunatly leads
to integer divides in several paths.
Converting it to unsigned is safe and saves 208 bytes of text on i386.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: xfrm_alg_key_len.patch --]
[-- Type: text/plain, Size: 333 bytes --]
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 1131eab..f8507ee 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -92,7 +92,7 @@ struct xfrm_replay_state
struct xfrm_algo {
char alg_name[64];
- int alg_key_len; /* in bits */
+ unsigned int alg_key_len; /* in bits */
char alg_key[0];
};
^ permalink raw reply related
* Re: [PATCH 2.6.23+] ingress classify to [nf]mark
From: Dzianis Kahanovich @ 2008-01-12 17:56 UTC (permalink / raw)
To: netdev
In-Reply-To: <1200107027.4477.36.camel@localhost>
I in doubts only about "action continue".
To "and/or" behaviour one of best usage are (example):
# set bit 2 of mark to 0 (mark&0xfd|0) and continue
tc filter add ... prio 1 ... flowid fd:0 action continue
# continue
tc filter add ... prio 2 ...
- in current ingress_enqueue() code IMHO "case TC_ACT_OK:" will not reached
for action continue. I use old (mark=...) solution only by this.
I think, "skb->mark = (skb->mark&(res.classid>>16))|TC_H_MIN(res.classid);"
must be in the end of ingress_enqueue() before "return result". And not
depended to "NET_CLS_ACT". But while not test it.
Or this:
---
#ifdef CONFIG_NET_SCH_INGRESS_TC2MARK
#ifdef CONFIG_NET_CLS_ACT
skb->mark = (skb->mark&(res.classid>>16))|TC_H_MIN(res.classid);
#else
skb->mark = res.classid;
#endif
#endif
return result;
}
jamal wrote:
>> While I compose filter, I check flag ($TC_INDEX2MARK), tells me are patch
>> applied or no. If no - I use usual "-j MARK --set-mark", else I use classid to
>> change mark. All in ingress only. For example:
>> tc filter add dev eth0 parent ffff: protocol ip u32 ... action ipt -j MARK 0x10
>> are cname to:
>> tc filter add dev eth0 parent ffff: protocol ip u32 ... flowid :10
>
> I thought you were doing something like this (to achieve your policy):
>
> ----------
> major=1
> minor=12
> mark=`expr $major + $minor`
> #
> tc qdisc add dev XXX ingress
> tc filter add dev XXX parent ffff: protocol ip prio 5 \
> u32 blah bleh \
> flowid $major:$minor action \
> ipt -j mark --set-mark $mark
> ---------------
>
>> - it use less code/modules and, in many cases, may be single/main goal to
>> ingress usage - pre-marking packets.
>
> That is true and you would also have one less line in your policy; as an
> example in above the line "ipt -j mark --set-mark $mark" would be
> unnecessary; however, all the other lines in the policy setting _will be
> necessary_. And this + the fact there are many other values/shapes the
> default policy could take is essentially whats bothering me.
>
> In any case, scanning the current code it seems mark is no longer
> considered a netfilter-only metadatum - so it may not be semantically as
> obscene as i felt earlier; Can you pick something simpler for policy?
> example set the mark to whatever tc_index gets set?
> If you still could write the metadata action, we could use it to
> override mark, tc_index etc in addition.
>
> cheers,
> jamal
>
>
>
--
WBR,
Denis Kaganovich, mahatma@eu.by http://mahatma.bspu.unibel.by
^ permalink raw reply
* Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: Ilpo Järvinen @ 2008-01-12 12:59 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, Netdev
In-Reply-To: <20080112121740.GA4555@gondor.apana.org.au>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1134 bytes --]
On Sat, 12 Jan 2008, Herbert Xu wrote:
> On Sat, Jan 12, 2008 at 09:40:17AM +0000, Ilpo Järvinen wrote:
>
> Your emails are now using UTF-8 encoding but it's still declaring
> ISO-8859-1 as the charset.
Thanks for trying to help but my situation is such that I think it got
also you confused (this kind of mixed encoding is beoynd my skills
really)... :-) Besides, I wouldn't mind of having incorrect characters
in my name, I'm just used to that but somebody else wasn't that happy
about it.
Here's one example...
From: "=?utf-8?q?Ilpo_J=C3=A4rvinen?=" <ilpo.jarvinen@helsinki.fi>
...
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Something still needed besides these to declare email utf-8?
> So you probably want to fix that up or your name may show up as Jävinen
> on the reader's screen.
Did you actually see this? I'd expect to see that as well but no, From is
correctly decoded by my ISO-8859-1'ish MUA, aha, seems that I still have
something to do to deal with the Signed-off line.
...Maybe I just fall-back to changing my last name, it's the only
full-proof solution... ;-)
--
i.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: supersud501 @ 2008-01-12 12:24 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Hemminger, Andrew Morton, netdev, linux-acpi,
bugme-daemon
In-Reply-To: <200801120010.22440.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Friday, 11 of January 2008, supersud501 wrote:
>> Rafael J. Wysocki wrote:
>>>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
>
>> allright, didn't see that before, sorry, here are the results:
>>
>> kernel 2.6.23.12 acpi=off: when shutting down the system doesn't
>> poweroff (of course), but pressing the powerbutton does the trick. and
>> wake on lan: WORKS
>>
>> kernel 2.6.24-rc7 acpi=off: computer doesn't power off, either (so
>> acpi=off works), but wol still DOESN'T work :(
>>
>> so no acpi-problem?
>
> No, I don't think it's an ACPI problem.
>
> Since it seems to be 100% reproducible, it would be very helpful if you could
> use git-bisect to identify the offending commit.
>
I'll do the git-bisect (just downloading linux-2.6.git), but i forgot to
mention one little thing: i'm using x64 version of kernel - does this
play an important role?
^ permalink raw reply
* Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: Herbert Xu @ 2008-01-12 12:17 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, netdev
In-Reply-To: <12001308174189-git-send-email-ilpo.jarvinen@helsinki.fi>
Hi Ilpo:
On Sat, Jan 12, 2008 at 09:40:17AM +0000, Ilpo Järvinen wrote:
Your emails are now using UTF-8 encoding but it's still declaring
ISO-8859-1 as the charset. So you probably want to fix that up or
your name may show up as Jävinen on the reader's screen.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 9719] New: when a system is configured as a bridge, and at the same time configured to have multipath weighted route, with one leg goes thru NAT and another without NAT, the nat path will intermittently get packets leaking out using internal IP without being SNAT-ted
From: Ming-Ching Tiew @ 2008-01-13 1:04 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, Julian Anastasov
In-Reply-To: <47863CA8.1010301@trash.net>
Patrick McHardy wrote:
> Andrew Morton wrote:
>>> Distribution: iptables 1.4.0 was used with kernel 2.6.23 and
>>> iptables 1.3.8
>>> with 2.6.22.15
>>> Hardware Environment: 3 interfaces, 2 interfaces bridged to form
>>> br0, and
>>> another connects to internet using pppoe.
>>> Software Environment: bridge, multipath routing
>>> Problem Description: when a system is configured as a bridge with IP
>>> assigned
>>> to br0 interface, and at the same time it is configured to have
>>> multipath
>>> weighted default route, and one of the default route is NAT-ed and
>>> another of
>>> the default route is not NAT-ed, then it is NAT-ed interface will
>>> occasionally
>>> get packets leaking out to it with packets with private IPs.
>
>
> That is most likely because the route changes over time (when the cache
> is flushed) and the NAT mappings for the connection have been set up on
> a different interface. The way to properly do this is to add routing
> rules based on fwmark and use CONNMARK to bind a connection to one of
> the interfaces after the initial multipath routing decision.
>
First of all, I would like to say a big thank you to all of you takes
interest in replying my post/email. I have altered the distribution
slightly and the kernel bug list is removed.
It seems from your reply, what is implied is that I cannot change route
within a connection, and whatever things I do, I must make sure that the
route remains the same for a particular netfilter connection ?
Regards.
^ permalink raw reply
* [PATCH 1/2] [NET] core/utils.c: digit2bin is dead static inline
From: Ilpo Järvinen @ 2008-01-12 11:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/core/utils.c | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/net/core/utils.c b/net/core/utils.c
index 34459c4..8031eb5 100644
--- a/net/core/utils.c
+++ b/net/core/utils.c
@@ -91,17 +91,6 @@ EXPORT_SYMBOL(in_aton);
#define IN6PTON_NULL 0x20000000 /* first/tail */
#define IN6PTON_UNKNOWN 0x40000000
-static inline int digit2bin(char c, int delim)
-{
- if (c == delim || c == '\0')
- return IN6PTON_DELIM;
- if (c == '.')
- return IN6PTON_DOT;
- if (c >= '0' && c <= '9')
- return (IN6PTON_DIGIT | (c - '0'));
- return IN6PTON_UNKNOWN;
-}
-
static inline int xdigit2bin(char c, int delim)
{
if (c == delim || c == '\0')
--
1.5.0.6
^ permalink raw reply related
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