* [-mm patch] net/core/sysctl_net_core.c: fix PROC_FS=n compile
From: Adrian Bunk @ 2005-08-20 19:03 UTC (permalink / raw)
To: Andrew Morton, davem; +Cc: linux-kernel, netdev
In-Reply-To: <20050819043331.7bc1f9a9.akpm@osdl.org>
On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc5-mm1:
>...
> git-net.patch
>...
> Subsystem trees
>...
This breaks the compilation with CONFIG_PROC_FS=n:
<-- snip -->
...
CC net/core/sysctl_net_core.o
net/core/sysctl_net_core.c:50: error: 'sysctl_wmem_default' undeclared here (not in a function)
net/core/sysctl_net_core.c:58: error: 'sysctl_rmem_default' undeclared here (not in a function)
make[2]: *** [net/core/sysctl_net_core.o] Error 1
<-- snip -->
The fix is simple.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-rc6-mm1-full/include/net/sock.h.old 2005-08-20 15:39:23.000000000 +0200
+++ linux-2.6.13-rc6-mm1-full/include/net/sock.h 2005-08-20 15:39:39.000000000 +0200
@@ -1372,9 +1372,7 @@
extern int sysctl_optmem_max;
#endif
-#ifdef CONFIG_PROC_FS
extern __u32 sysctl_wmem_default;
extern __u32 sysctl_rmem_default;
-#endif
#endif /* _SOCK_H */
^ permalink raw reply
* Re: [-mm patch] net/core/sysctl_net_core.c: fix PROC_FS=n compile
From: David S. Miller @ 2005-08-21 0:14 UTC (permalink / raw)
To: bunk; +Cc: akpm, linux-kernel, netdev
In-Reply-To: <20050820190309.GB3615@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Sat, 20 Aug 2005 21:03:09 +0200
> This breaks the compilation with CONFIG_PROC_FS=n:
..
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [patch 2.6.13-rc6] net/802/tr: use interrupt-safe locking
From: Andrew Morton @ 2005-08-21 8:38 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, linux-tr, mikep, jgarzik, davem, linux-kernel
In-Reply-To: <200508172148.j7HLmPAt005857@death.nxdomain.ibm.com>
Jay Vosburgh <fubar@us.ibm.com> wrote:
>
> >FWIW, this patch is currently being carried in the Fedora and RHEL
> >kernels. It certainly looks like it is necessary to me. Can we get
> >some movement on this?
>
> It's in the SuSE kernel as well.
For how long has this fix been in the vendor kernels?
Could someone please tell us why there are unmerged bugfixes in vendor
kernels?
Are there any more?
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Andrew Morton @ 2005-08-21 19:47 UTC (permalink / raw)
To: danial_thom; +Cc: linux-kernel, netdev
In-Reply-To: <20050821154654.63788.qmail@web33303.mail.mud.yahoo.com>
Danial Thom <danial_thom@yahoo.com> wrote:
>
> I just started fiddling with 2.6.12, and there
> seems to be a big drop-off in performance from
> 2.4.x in terms of networking on a uniprocessor
> system. Just bridging packets through the
> machine, 2.6.12 starts dropping packets at
> ~100Kpps, whereas 2.4.x doesn't start dropping
> until over 350Kpps on the same hardware (2.0Ghz
> Opteron with e1000 driver). This is pitiful
> prformance for this hardware. I've
> increased the rx ring in the e1000 driver to 512
> with little change (interrupt moderation is set
> to 8000 Ints/second). Has "tuning" for MP
> destroyed UP performance altogether, or is there
> some tuning parameter that could make a 4-fold
> difference? All debugging is off and there are
> no messages on the console or in the error logs.
> The kernel is the standard kernel.org dowload
> config with SMP turned off and the intel ethernet
> card drivers as modules without any other
> changes, which is exactly the config for my 2.4
> kernels.
>
(added netdev to cc)
^ permalink raw reply
* Re: tcpdump confused with NAT-T+IPSec Packets
From: Patrick McHardy @ 2005-08-22 0:31 UTC (permalink / raw)
To: Gopalakrishnan Raman; +Cc: linux-kernel, netdev
In-Reply-To: <20050821165608.A9993@portal.rgopal.com>
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
Gopalakrishnan Raman wrote:
> Hi
> I'm using 2.6.11.7 and debugging why my ESP tunnel mode does
> not work between two 2.6 machines one of which is behind a NAT.
> I'm using tcpdump to capture NAT-T packets on one of the hosts
> and using espdecrypt (http://www.cs.rpi.edu/~flemej/freebsd/espdecrypt/)
> to see it in the clear.
>
> Turns out, tcpdump will display an incoming NAT-T packet after it
> has been mangled by udp_encap_rcv(). udp_encap_rcv() changes the
> protocol field in the IP hdr to ESP from UDP and also moves other
> bytes in the sk_buff data area.
>
> The problem is that packet_rcv() calls skb_clone() which is the
> right thing to do in all cases except when the data portion of the
> incoming skb is being modified in place. I replaced it with a pskb_copy()
> in the case when the packet is likely to be NAT-T or ESP. The patch
> for this follows the end of this mail and seems to work quite well.
>
> Note that af_packet.c is the right place for the ESP/NAT-T check.
> Can't do it in ESP or UDP code because we can't tell if these packets
> are also being captured by tcpdump/ethereal.
Herbert already fixed it with this patch.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1114 bytes --]
[IPSEC]: COW skb header in UDP decap
The following patch just makes the header part of the skb writeable.
This is needed since we modify the IP headers just a few lines below.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
commit 4d78b6c78ae6d87e4c1c8072f42efa716f04afb9
tree e04f156e8d74c28b925bf53e62d3e4b424a6ffb7
parent c7f905f0f6d49ed8c1aa4566c31f0383a0ba0c9d
author Herbert Xu <herbert@gondor.apana.org.au> Tue, 19 Apr 2005 22:48:59 -0700
committer David S. Miller <davem@davemloft.net> Tue, 19 Apr 2005 22:48:59 -0700
net/ipv4/udp.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -955,6 +955,8 @@ static int udp_encap_rcv(struct sock * s
* header and optional ESP marker bytes) and then modify the
* protocol to ESP, and then call into the transform receiver.
*/
+ if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
+ return 0;
/* Now we can update and verify the packet length... */
iph = skb->nh.iph;
^ permalink raw reply
* No Gigabit with r8169 module
From: Dennis @ 2005-08-22 7:21 UTC (permalink / raw)
To: netdev
Hi!
I am trying to build up a gigabit network with the following equipment (all
from Netgear):
- Laptop: GA511 PCMCIA Gigabit Adapter
- PC: GA311 PCI Gigabit Card
- GS605 5-port Gigabit Switch
Both PCMCIA and PCI Cards are running with the r8169 driver. The PC as the
laptop are installed with Suse 9.3.
The Switch has dual color support on the connection LEDs and both ports (the
one connected to the PC and the one connected to the Laptop) are showing that
they are connected to gigabit ethernet cards.
What I tried to do is to copy a folder from the laptop to the PC, which size
is about 6.1 GB. I am using KDE 3.4 and the konqueror with fish-protocol. The
copy dialogue says that this wold take about 2.5 hours with a average of 850
kbit/s. This is quite too slow for gigabit.
Just to make sure that I didn´t make a hardware connection mistake, i tried
the connection with Windows XP and there, a folder which size is about 2.1 GB
takes about 10 minutes to copy - seems like gigabit is actually working with
all cables I am using. Another point was that suse could be the scapegoat, so
I used knoppix to test the connection under linux again. I got the same slow
speed here.
The laptop has three network interfaces, but I switched all of except the
gigabit card (ifdown <device>), so no mistake there possible from my point
of view (correct me if I am wrong here).
Now I wonder if this is due to the driver or did I do something wrong? I would
be happy for any help that gets me further to get my gigabit running. If
there are any more details I have to supply, please ask me.
Yours,
Mike
^ permalink raw reply
* [PATCH] Fix socket bitop damage
From: Ralf Baechle @ 2005-08-22 11:02 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: linux-hams
The socket flag cleanups that went into 2.6.12-rc1 are basically oring
the flags of an old socket into the socket just being created.
Unfortunately that one was just initialized by sock_init_data(), so already
has SOCK_ZAPPED set. As the result zapped sockets are created and all
incoming connection will fail due to this bug which again was carefully
replicated to at least AX.25, NET/ROM or ROSE.
In order to keep the abstraction alive I've introduced sock_copy_flags()
to copy the socket flags from one sockets to another and used that
instead of the bitwise copy thing. Anyway, the idea here has probably
been to copy all flags, so sock_copy_flags() should be the right thing.
With this the ham radio protocols are usable again, so I hope this will
make it into 2.6.13.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
include/net/sock.h | 5 +++++
net/ax25/af_ax25.c | 7 +------
net/netrom/af_netrom.c | 7 +------
net/rose/af_rose.c | 7 +------
4 files changed, 8 insertions(+), 18 deletions(-)
Index: linux-cvs/net/netrom/af_netrom.c
===================================================================
--- linux-cvs.orig/net/netrom/af_netrom.c
+++ linux-cvs/net/netrom/af_netrom.c
@@ -465,12 +465,7 @@ static struct sock *nr_make_new(struct s
sk->sk_sndbuf = osk->sk_sndbuf;
sk->sk_state = TCP_ESTABLISHED;
sk->sk_sleep = osk->sk_sleep;
-
- if (sock_flag(osk, SOCK_ZAPPED))
- sock_set_flag(sk, SOCK_ZAPPED);
-
- if (sock_flag(osk, SOCK_DBG))
- sock_set_flag(sk, SOCK_DBG);
+ sock_copy_flags(sk, osk);
skb_queue_head_init(&nr->ack_queue);
skb_queue_head_init(&nr->reseq_queue);
Index: linux-cvs/include/net/sock.h
===================================================================
--- linux-cvs.orig/include/net/sock.h
+++ linux-cvs/include/net/sock.h
@@ -384,6 +384,11 @@ enum sock_flags {
SOCK_QUEUE_SHRUNK, /* write queue has been shrunk recently */
};
+static inline void sock_copy_flags(struct sock *nsk, struct sock *osk)
+{
+ nsk->sk_flags = osk->sk_flags;
+}
+
static inline void sock_set_flag(struct sock *sk, enum sock_flags flag)
{
__set_bit(flag, &sk->sk_flags);
Index: linux-cvs/net/ax25/af_ax25.c
===================================================================
--- linux-cvs.orig/net/ax25/af_ax25.c
+++ linux-cvs/net/ax25/af_ax25.c
@@ -884,12 +884,7 @@ struct sock *ax25_make_new(struct sock *
sk->sk_sndbuf = osk->sk_sndbuf;
sk->sk_state = TCP_ESTABLISHED;
sk->sk_sleep = osk->sk_sleep;
-
- if (sock_flag(osk, SOCK_DBG))
- sock_set_flag(sk, SOCK_DBG);
-
- if (sock_flag(osk, SOCK_ZAPPED))
- sock_set_flag(sk, SOCK_ZAPPED);
+ sock_copy_flags(sk, osk);
oax25 = ax25_sk(osk);
Index: linux-cvs/net/rose/af_rose.c
===================================================================
--- linux-cvs.orig/net/rose/af_rose.c
+++ linux-cvs/net/rose/af_rose.c
@@ -556,12 +556,7 @@ static struct sock *rose_make_new(struct
sk->sk_sndbuf = osk->sk_sndbuf;
sk->sk_state = TCP_ESTABLISHED;
sk->sk_sleep = osk->sk_sleep;
-
- if (sock_flag(osk, SOCK_ZAPPED))
- sock_set_flag(sk, SOCK_ZAPPED);
-
- if (sock_flag(osk, SOCK_DBG))
- sock_set_flag(sk, SOCK_DBG);
+ sock_copy_flags(sk, osk);
init_timer(&rose->timer);
init_timer(&rose->idletimer);
^ permalink raw reply
* [PATCH] AX.25 UID fixes
From: Ralf Baechle @ 2005-08-22 11:10 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: linux-hams
o Brown paperbag bug - ax25_findbyuid() was always returning a NULL pointer
as the result. Breaks ROSE completly and AX.25 if UID policy set to deny.
o While the list structure of AX.25's UID to callsign mapping table was
properly protected by a spinlock, it's elements were not refcounted
resulting in a race between removal and usage of an element.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
include/net/ax25.h | 18 +++++++++-
net/ax25/af_ax25.c | 20 +++++++----
net/ax25/ax25_route.c | 12 ++++---
net/ax25/ax25_uid.c | 83 +++++++++++++++++++++----------------------------
net/netrom/af_netrom.c | 24 +++++++++-----
net/rose/af_rose.c | 20 +++++++----
6 files changed, 100 insertions(+), 77 deletions(-)
Index: linux-cvs/include/net/ax25.h
===================================================================
--- linux-cvs.orig/include/net/ax25.h
+++ linux-cvs/include/net/ax25.h
@@ -148,11 +148,25 @@ enum {
#define AX25_DEF_DS_TIMEOUT 180000 /* DAMA timeout 3 minutes */
typedef struct ax25_uid_assoc {
- struct ax25_uid_assoc *next;
+ struct hlist_node uid_node;
+ atomic_t refcount;
uid_t uid;
ax25_address call;
} ax25_uid_assoc;
+#define ax25_uid_for_each(__ax25, node, list) \
+ hlist_for_each_entry(__ax25, node, list, uid_node)
+
+#define ax25_uid_hold(ax25) \
+ atomic_inc(&((ax25)->refcount))
+
+static inline void ax25_uid_put(ax25_uid_assoc *assoc)
+{
+ if (atomic_dec_and_test(&assoc->refcount)) {
+ kfree(assoc);
+ }
+}
+
typedef struct {
ax25_address calls[AX25_MAX_DIGIS];
unsigned char repeated[AX25_MAX_DIGIS];
@@ -386,7 +400,7 @@ extern unsigned long ax25_display_timer(
/* ax25_uid.c */
extern int ax25_uid_policy;
-extern ax25_address *ax25_findbyuid(uid_t);
+extern ax25_uid_assoc *ax25_findbyuid(uid_t);
extern int ax25_uid_ioctl(int, struct sockaddr_ax25 *);
extern struct file_operations ax25_uid_fops;
extern void ax25_uid_free(void);
Index: linux-cvs/net/ax25/ax25_route.c
===================================================================
--- linux-cvs.orig/net/ax25/ax25_route.c
+++ linux-cvs/net/ax25/ax25_route.c
@@ -422,8 +422,8 @@ static inline void ax25_adjust_path(ax25
*/
int ax25_rt_autobind(ax25_cb *ax25, ax25_address *addr)
{
+ ax25_uid_assoc *user;
ax25_route *ax25_rt;
- ax25_address *call;
int err;
if ((ax25_rt = ax25_get_route(addr, NULL)) == NULL)
@@ -434,16 +434,18 @@ int ax25_rt_autobind(ax25_cb *ax25, ax25
goto put;
}
- if ((call = ax25_findbyuid(current->euid)) == NULL) {
+ user = ax25_findbyuid(current->euid);
+ if (user) {
+ ax25->source_addr = user->call;
+ ax25_uid_put(user);
+ } else {
if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) {
err = -EPERM;
goto put;
}
- call = (ax25_address *)ax25->ax25_dev->dev->dev_addr;
+ ax25->source_addr = *(ax25_address *)ax25->ax25_dev->dev->dev_addr;
}
- ax25->source_addr = *call;
-
if (ax25_rt->digipeat != NULL) {
if ((ax25->digipeat = kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
err = -ENOMEM;
Index: linux-cvs/net/ax25/ax25_uid.c
===================================================================
--- linux-cvs.orig/net/ax25/ax25_uid.c
+++ linux-cvs/net/ax25/ax25_uid.c
@@ -28,6 +28,7 @@
#include <linux/fcntl.h>
#include <linux/mm.h>
#include <linux/interrupt.h>
+#include <linux/list.h>
#include <linux/notifier.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
@@ -41,38 +42,41 @@
* Callsign/UID mapper. This is in kernel space for security on multi-amateur machines.
*/
-static ax25_uid_assoc *ax25_uid_list;
+HLIST_HEAD(ax25_uid_list);
static DEFINE_RWLOCK(ax25_uid_lock);
int ax25_uid_policy = 0;
-ax25_address *ax25_findbyuid(uid_t uid)
+ax25_uid_assoc *ax25_findbyuid(uid_t uid)
{
- ax25_uid_assoc *ax25_uid;
- ax25_address *res = NULL;
+ ax25_uid_assoc *ax25_uid, *res = NULL;
+ struct hlist_node *node;
read_lock(&ax25_uid_lock);
- for (ax25_uid = ax25_uid_list; ax25_uid != NULL; ax25_uid = ax25_uid->next) {
+ ax25_uid_for_each(ax25_uid, node, &ax25_uid_list) {
if (ax25_uid->uid == uid) {
- res = &ax25_uid->call;
+ ax25_uid_hold(ax25_uid);
+ res = ax25_uid;
break;
}
}
read_unlock(&ax25_uid_lock);
- return NULL;
+ return res;
}
int ax25_uid_ioctl(int cmd, struct sockaddr_ax25 *sax)
{
- ax25_uid_assoc *s, *ax25_uid;
+ ax25_uid_assoc *ax25_uid;
+ struct hlist_node *node;
+ ax25_uid_assoc *user;
unsigned long res;
switch (cmd) {
case SIOCAX25GETUID:
res = -ENOENT;
read_lock(&ax25_uid_lock);
- for (ax25_uid = ax25_uid_list; ax25_uid != NULL; ax25_uid = ax25_uid->next) {
+ ax25_uid_for_each(ax25_uid, node, &ax25_uid_list) {
if (ax25cmp(&sax->sax25_call, &ax25_uid->call) == 0) {
res = ax25_uid->uid;
break;
@@ -85,19 +89,22 @@ int ax25_uid_ioctl(int cmd, struct socka
case SIOCAX25ADDUID:
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- if (ax25_findbyuid(sax->sax25_uid))
+ user = ax25_findbyuid(sax->sax25_uid);
+ if (user) {
+ ax25_uid_put(user);
return -EEXIST;
+ }
if (sax->sax25_uid == 0)
return -EINVAL;
if ((ax25_uid = kmalloc(sizeof(*ax25_uid), GFP_KERNEL)) == NULL)
return -ENOMEM;
+ atomic_set(&ax25_uid->refcount, 1);
ax25_uid->uid = sax->sax25_uid;
ax25_uid->call = sax->sax25_call;
write_lock(&ax25_uid_lock);
- ax25_uid->next = ax25_uid_list;
- ax25_uid_list = ax25_uid;
+ hlist_add_head(&ax25_uid->uid_node, &ax25_uid_list);
write_unlock(&ax25_uid_lock);
return 0;
@@ -106,34 +113,21 @@ int ax25_uid_ioctl(int cmd, struct socka
if (!capable(CAP_NET_ADMIN))
return -EPERM;
+ ax25_uid = NULL;
write_lock(&ax25_uid_lock);
- for (ax25_uid = ax25_uid_list; ax25_uid != NULL; ax25_uid = ax25_uid->next) {
- if (ax25cmp(&sax->sax25_call, &ax25_uid->call) == 0) {
+ ax25_uid_for_each(ax25_uid, node, &ax25_uid_list) {
+ if (ax25cmp(&sax->sax25_call, &ax25_uid->call) == 0)
break;
- }
}
if (ax25_uid == NULL) {
write_unlock(&ax25_uid_lock);
return -ENOENT;
}
- if ((s = ax25_uid_list) == ax25_uid) {
- ax25_uid_list = s->next;
- write_unlock(&ax25_uid_lock);
- kfree(ax25_uid);
- return 0;
- }
- while (s != NULL && s->next != NULL) {
- if (s->next == ax25_uid) {
- s->next = ax25_uid->next;
- write_unlock(&ax25_uid_lock);
- kfree(ax25_uid);
- return 0;
- }
- s = s->next;
- }
+ hlist_del_init(&ax25_uid->uid_node);
+ ax25_uid_put(ax25_uid);
write_unlock(&ax25_uid_lock);
- return -ENOENT;
+ return 0;
default:
return -EINVAL;
@@ -147,13 +141,11 @@ int ax25_uid_ioctl(int cmd, struct socka
static void *ax25_uid_seq_start(struct seq_file *seq, loff_t *pos)
{
struct ax25_uid_assoc *pt;
- int i = 1;
+ struct hlist_node *node;
+ int i = 0;
read_lock(&ax25_uid_lock);
- if (*pos == 0)
- return SEQ_START_TOKEN;
-
- for (pt = ax25_uid_list; pt != NULL; pt = pt->next) {
+ ax25_uid_for_each(pt, node, &ax25_uid_list) {
if (i == *pos)
return pt;
++i;
@@ -164,8 +156,9 @@ static void *ax25_uid_seq_start(struct s
static void *ax25_uid_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
++*pos;
- return (v == SEQ_START_TOKEN) ? ax25_uid_list :
- ((struct ax25_uid_assoc *) v)->next;
+
+ return hlist_entry(((ax25_uid_assoc *)v)->uid_node.next,
+ ax25_uid_assoc, uid_node);
}
static void ax25_uid_seq_stop(struct seq_file *seq, void *v)
@@ -179,7 +172,6 @@ static int ax25_uid_seq_show(struct seq_
seq_printf(seq, "Policy: %d\n", ax25_uid_policy);
else {
struct ax25_uid_assoc *pt = v;
-
seq_printf(seq, "%6d %s\n", pt->uid, ax2asc(&pt->call));
}
@@ -213,16 +205,13 @@ struct file_operations ax25_uid_fops = {
*/
void __exit ax25_uid_free(void)
{
- ax25_uid_assoc *s, *ax25_uid;
+ ax25_uid_assoc *ax25_uid;
+ struct hlist_node *node;
write_lock(&ax25_uid_lock);
- ax25_uid = ax25_uid_list;
- while (ax25_uid != NULL) {
- s = ax25_uid;
- ax25_uid = ax25_uid->next;
-
- kfree(s);
+ ax25_uid_for_each(ax25_uid, node, &ax25_uid_list) {
+ hlist_del_init(&ax25_uid->uid_node);
+ ax25_uid_put(ax25_uid);
}
- ax25_uid_list = NULL;
write_unlock(&ax25_uid_lock);
}
Index: linux-cvs/net/netrom/af_netrom.c
===================================================================
--- linux-cvs.orig/net/netrom/af_netrom.c
+++ linux-cvs/net/netrom/af_netrom.c
@@ -542,7 +542,8 @@ static int nr_bind(struct socket *sock,
struct nr_sock *nr = nr_sk(sk);
struct full_sockaddr_ax25 *addr = (struct full_sockaddr_ax25 *)uaddr;
struct net_device *dev;
- ax25_address *user, *source;
+ ax25_uid_assoc *user;
+ ax25_address *source;
lock_sock(sk);
if (!sock_flag(sk, SOCK_ZAPPED)) {
@@ -581,16 +582,19 @@ static int nr_bind(struct socket *sock,
} else {
source = &addr->fsa_ax25.sax25_call;
- if ((user = ax25_findbyuid(current->euid)) == NULL) {
+ user = ax25_findbyuid(current->euid);
+ if (user) {
+ nr->user_addr = user->call;
+ ax25_uid_put(user);
+ } else {
if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE)) {
release_sock(sk);
dev_put(dev);
return -EPERM;
}
- user = source;
+ nr->user_addr = *source;
}
- nr->user_addr = *user;
nr->source_addr = *source;
}
@@ -610,7 +614,8 @@ static int nr_connect(struct socket *soc
struct sock *sk = sock->sk;
struct nr_sock *nr = nr_sk(sk);
struct sockaddr_ax25 *addr = (struct sockaddr_ax25 *)uaddr;
- ax25_address *user, *source = NULL;
+ ax25_address *source = NULL;
+ ax25_uid_assoc *user;
struct net_device *dev;
lock_sock(sk);
@@ -651,16 +656,19 @@ static int nr_connect(struct socket *soc
}
source = (ax25_address *)dev->dev_addr;
- if ((user = ax25_findbyuid(current->euid)) == NULL) {
+ user = ax25_findbyuid(current->euid);
+ if (user) {
+ nr->user_addr = user->call;
+ ax25_uid_put(user);
+ } else {
if (ax25_uid_policy && !capable(CAP_NET_ADMIN)) {
dev_put(dev);
release_sock(sk);
return -EPERM;
}
- user = source;
+ nr->user_addr = *source;
}
- nr->user_addr = *user;
nr->source_addr = *source;
nr->device = dev;
Index: linux-cvs/net/rose/af_rose.c
===================================================================
--- linux-cvs.orig/net/rose/af_rose.c
+++ linux-cvs/net/rose/af_rose.c
@@ -626,7 +626,8 @@ static int rose_bind(struct socket *sock
struct rose_sock *rose = rose_sk(sk);
struct sockaddr_rose *addr = (struct sockaddr_rose *)uaddr;
struct net_device *dev;
- ax25_address *user, *source;
+ ax25_address *source;
+ ax25_uid_assoc *user;
int n;
if (!sock_flag(sk, SOCK_ZAPPED))
@@ -651,14 +652,17 @@ static int rose_bind(struct socket *sock
source = &addr->srose_call;
- if ((user = ax25_findbyuid(current->euid)) == NULL) {
+ user = ax25_findbyuid(current->euid);
+ if (user) {
+ rose->source_call = user->call;
+ ax25_uid_put(user);
+ } else {
if (ax25_uid_policy && !capable(CAP_NET_BIND_SERVICE))
return -EACCES;
- user = source;
+ rose->source_call = *source;
}
rose->source_addr = addr->srose_addr;
- rose->source_call = *user;
rose->device = dev;
rose->source_ndigis = addr->srose_ndigis;
@@ -685,8 +689,8 @@ static int rose_connect(struct socket *s
struct rose_sock *rose = rose_sk(sk);
struct sockaddr_rose *addr = (struct sockaddr_rose *)uaddr;
unsigned char cause, diagnostic;
- ax25_address *user;
struct net_device *dev;
+ ax25_uid_assoc *user;
int n;
if (sk->sk_state == TCP_ESTABLISHED && sock->state == SS_CONNECTING) {
@@ -736,12 +740,14 @@ static int rose_connect(struct socket *s
if ((dev = rose_dev_first()) == NULL)
return -ENETUNREACH;
- if ((user = ax25_findbyuid(current->euid)) == NULL)
+ user = ax25_findbyuid(current->euid);
+ if (!user)
return -EINVAL;
memcpy(&rose->source_addr, dev->dev_addr, ROSE_ADDR_LEN);
- rose->source_call = *user;
+ rose->source_call = user->call;
rose->device = dev;
+ ax25_uid_put(user);
rose_insert_socket(sk); /* Finish the bind */
}
Index: linux-cvs/net/ax25/af_ax25.c
===================================================================
--- linux-cvs.orig/net/ax25/af_ax25.c
+++ linux-cvs/net/ax25/af_ax25.c
@@ -1011,7 +1011,8 @@ static int ax25_bind(struct socket *sock
struct sock *sk = sock->sk;
struct full_sockaddr_ax25 *addr = (struct full_sockaddr_ax25 *)uaddr;
ax25_dev *ax25_dev = NULL;
- ax25_address *call;
+ ax25_uid_assoc *user;
+ ax25_address call;
ax25_cb *ax25;
int err = 0;
@@ -1030,9 +1031,15 @@ static int ax25_bind(struct socket *sock
if (addr->fsa_ax25.sax25_family != AF_AX25)
return -EINVAL;
- call = ax25_findbyuid(current->euid);
- if (call == NULL && ax25_uid_policy && !capable(CAP_NET_ADMIN)) {
- return -EACCES;
+ user = ax25_findbyuid(current->euid);
+ if (user) {
+ call = user->call;
+ ax25_uid_put(user);
+ } else {
+ if (ax25_uid_policy && !capable(CAP_NET_ADMIN))
+ return -EACCES;
+
+ call = addr->fsa_ax25.sax25_call;
}
lock_sock(sk);
@@ -1043,10 +1050,7 @@ static int ax25_bind(struct socket *sock
goto out;
}
- if (call == NULL)
- ax25->source_addr = addr->fsa_ax25.sax25_call;
- else
- ax25->source_addr = *call;
+ ax25->source_addr = call;
/*
* User already set interface with SO_BINDTODEVICE
^ permalink raw reply
* Re: [PATCH] Fix socket bitop damage
From: Thomas Graf @ 2005-08-22 11:14 UTC (permalink / raw)
To: Ralf Baechle; +Cc: David S. Miller, netdev, linux-hams
In-Reply-To: <20050822110218.GA7514@linux-mips.org>
* Ralf Baechle <20050822110218.GA7514@linux-mips.org> 2005-08-22 12:02
> The socket flag cleanups that went into 2.6.12-rc1 are basically oring
> the flags of an old socket into the socket just being created.
> Unfortunately that one was just initialized by sock_init_data(), so already
> has SOCK_ZAPPED set. As the result zapped sockets are created and all
> incoming connection will fail due to this bug which again was carefully
> replicated to at least AX.25, NET/ROM or ROSE.
I'm probably to one to blame here but I don't get the point yet.
What I did was to change the bitfield based flags to use sk_flags
like this:
- sk->sk_zapped = osk->sk_zapped;
+
+ if (sock_flag(osk, SOCK_ZAPPED))
+ sock_set_flag(sk, SOCK_ZAPPED);
^ permalink raw reply
* Re: [PATCH] Fix socket bitop damage
From: Thomas Graf @ 2005-08-22 11:21 UTC (permalink / raw)
To: Ralf Baechle; +Cc: David S. Miller, netdev, linux-hams
In-Reply-To: <20050822111436.GE17371@postel.suug.ch>
* Thomas Graf <20050822111436.GE17371@postel.suug.ch> 2005-08-22 13:14
> * Ralf Baechle <20050822110218.GA7514@linux-mips.org> 2005-08-22 12:02
> > The socket flag cleanups that went into 2.6.12-rc1 are basically oring
> > the flags of an old socket into the socket just being created.
> > Unfortunately that one was just initialized by sock_init_data(), so already
> > has SOCK_ZAPPED set. As the result zapped sockets are created and all
> > incoming connection will fail due to this bug which again was carefully
> > replicated to at least AX.25, NET/ROM or ROSE.
>
> I'm probably to one to blame here but I don't get the point yet.
Never mind, I got it, sk->sk_flags may be be != 0.
^ permalink raw reply
* Annette Manuel
From: Katherine Carr @ 2005-08-22 12:23 UTC (permalink / raw)
To: netdev
Shelly,
http://uk.geocities.com/stock_market_miracles /9606734.html
Delores Landry
^ permalink raw reply
* This is your way to reduce the outflow on tiptop remeddies. clinch
From: nolan tufano @ 2005-08-22 15:50 UTC (permalink / raw)
To: Wally Antoniuk, craig, qarce, jensen
Once I notice my sister has eating disorderr. Thousand times, I ask her to
see a specialist. She always refused it. I have to find a way to help her. I
found your web and consults with your GPs on-line. As recommended, I bought
the anti depressant for her. 4 weeks passed, she is eating OK at this
moment. Thank you to your GPs and the magic tablets. We called it magic,
because it's magical remedyy effect but non-expensive. --Michelle Kizer in
WA.
Our E-zone supplies the right generrics for quicker alleviations.
With these marvellous deals on tablets, you are the smartest shopper of
all.
http://uk.geocities.com/goteemfunny/?gcfly
Check our web if you prefer timely and reliable distributiion services.
You've got nothing to loose! Try our pillss and feel its healing effect.
You'll regain your healthh quicker than expected.
It is a simple choice. For quick and professional case profile review, look
us up.
I'm high on believin'In love, in love, in love, in love
I swear my love to you hear and nowHeart to heart
enzinger fireware fenugree sz04 expterm evicudno
Where the air and the land meet foreverThe sea, the and
^ permalink raw reply
* Re: No Gigabit with r8169 module
From: Francois Romieu @ 2005-08-22 20:01 UTC (permalink / raw)
To: Dennis; +Cc: netdev
In-Reply-To: <200508220921.17956.dennismail@gmx.net>
Dennis <dennismail@gmx.net> :
[...]
> I am trying to build up a gigabit network with the following equipment (all
> from Netgear):
Same config here.
[...]
> Both PCMCIA and PCI Cards are running with the r8169 driver. The PC as the
> laptop are installed with Suse 9.3.
[...]
> What I tried to do is to copy a folder from the laptop to the PC, which size
> is about 6.1 GB. I am using KDE 3.4 and the konqueror with fish-protocol. The
> copy dialogue says that this wold take about 2.5 hours with a average of 850
> kbit/s. This is quite too slow for gigabit.
- Which kernel are you using ?
- Can you try plain old scp -c blowfish $BIG_FILE in a text console (i.e.
outside of X) and report the transfer rate ?
- If it still sucks, can you try 2.6.13-rc6 ?
- Please send:
o complete dmesg after boot
o lspci -vx
o lsmod
o cat /proc/interrupts + vmstat 1 during transfer
o ethtool ethX
Do not hesitate to use bugzilla.kernel.org.
> Just to make sure that I didn´t make a hardware connection mistake, i tried
> the connection with Windows XP and there, a folder which size is about 2.1 GB
> takes about 10 minutes to copy - seems like gigabit is actually working with
It means 3~4 Mo/s. Unimpressing.
--
Ueimor
^ permalink raw reply
* [2.6 patch] include/net/ieee80211.h: "extern inline" -> "static inline"
From: Adrian Bunk @ 2005-08-22 20:46 UTC (permalink / raw)
To: jkmaline; +Cc: hostap, jgarzik, netdev, linux-kernel
"extern inline" doesn't make much sense.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/net/ieee80211.h | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
--- linux-2.6.13-rc6-mm1-full/include/net/ieee80211.h.old 2005-08-22 02:48:16.000000000 +0200
+++ linux-2.6.13-rc6-mm1-full/include/net/ieee80211.h 2005-08-22 02:48:28.000000000 +0200
@@ -710,12 +710,12 @@
#define IEEE_G (1<<2)
#define IEEE_MODE_MASK (IEEE_A|IEEE_B|IEEE_G)
-extern inline void *ieee80211_priv(struct net_device *dev)
+static inline void *ieee80211_priv(struct net_device *dev)
{
return ((struct ieee80211_device *)netdev_priv(dev))->priv;
}
-extern inline int ieee80211_is_empty_essid(const char *essid, int essid_len)
+static inline int ieee80211_is_empty_essid(const char *essid, int essid_len)
{
/* Single white space is for Linksys APs */
if (essid_len == 1 && essid[0] == ' ')
@@ -731,7 +731,7 @@
return 1;
}
-extern inline int ieee80211_is_valid_mode(struct ieee80211_device *ieee, int mode)
+static inline int ieee80211_is_valid_mode(struct ieee80211_device *ieee, int mode)
{
/*
* It is possible for both access points and our device to support
@@ -757,7 +757,7 @@
return 0;
}
-extern inline int ieee80211_get_hdrlen(u16 fc)
+static inline int ieee80211_get_hdrlen(u16 fc)
{
int hdrlen = IEEE80211_3ADDR_LEN;
@@ -817,12 +817,12 @@
union iwreq_data *wrqu, char *key);
-extern inline void ieee80211_increment_scans(struct ieee80211_device *ieee)
+static inline void ieee80211_increment_scans(struct ieee80211_device *ieee)
{
ieee->scans++;
}
-extern inline int ieee80211_get_scans(struct ieee80211_device *ieee)
+static inline int ieee80211_get_scans(struct ieee80211_device *ieee)
{
return ieee->scans;
}
^ permalink raw reply
* [PATCH] [NET] mv643xx: add workaround for HW checksum generation bug
From: Dale Farnsworth @ 2005-08-22 22:53 UTC (permalink / raw)
To: netdev; +Cc: Jeff Garzik
[PATCH] [NET] mv643xx: add workaround for HW checksum generation bug
The hardware checksum generator on the mv64xxx occasionally generates
an incorrect checksum. This patch works around the issue and enables
hardware checksum generation.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
commit 42b926194c0e88445e654b8f11faf199d1409650
tree 0dfda571d490d3d67ee5fc14f473390efeabef84
parent f6fdd7d9c273bb2a20ab467cb57067494f932fa3
author Dale Farnsworth <dale@farnsworth.org> Mon, 22 Aug 2005 15:43:49 -0700
committer Dale Farnsworth <dale@farnsworth.org> Mon, 22 Aug 2005 15:43:49 -0700
drivers/net/mv643xx_eth.c | 29 ++++++++++++++++++-----------
drivers/net/mv643xx_eth.h | 4 +++-
2 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1157,16 +1157,20 @@ static int mv643xx_eth_start_xmit(struct
if (!skb_shinfo(skb)->nr_frags) {
linear:
if (skb->ip_summed != CHECKSUM_HW) {
+ /* Errata BTS #50, IHL must be 5 if no HW checksum */
pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT |
- ETH_TX_FIRST_DESC | ETH_TX_LAST_DESC;
+ ETH_TX_FIRST_DESC |
+ ETH_TX_LAST_DESC |
+ 5 << ETH_TX_IHL_SHIFT;
pkt_info.l4i_chk = 0;
} else {
- u32 ipheader = skb->nh.iph->ihl << 11;
pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT |
- ETH_TX_FIRST_DESC | ETH_TX_LAST_DESC |
- ETH_GEN_TCP_UDP_CHECKSUM |
- ETH_GEN_IP_V_4_CHECKSUM | ipheader;
+ ETH_TX_FIRST_DESC |
+ ETH_TX_LAST_DESC |
+ ETH_GEN_TCP_UDP_CHECKSUM |
+ ETH_GEN_IP_V_4_CHECKSUM |
+ skb->nh.iph->ihl << ETH_TX_IHL_SHIFT;
/* CPU already calculated pseudo header checksum. */
if (skb->nh.iph->protocol == IPPROTO_UDP) {
pkt_info.cmd_sts |= ETH_UDP_FRAME;
@@ -1193,7 +1197,6 @@ linear:
stats->tx_bytes += pkt_info.byte_cnt;
} else {
unsigned int frag;
- u32 ipheader;
/* Since hardware can't handle unaligned fragments smaller
* than 9 bytes, if we find any, we linearize the skb
@@ -1222,12 +1225,16 @@ linear:
DMA_TO_DEVICE);
pkt_info.l4i_chk = 0;
pkt_info.return_info = 0;
- pkt_info.cmd_sts = ETH_TX_FIRST_DESC;
- if (skb->ip_summed == CHECKSUM_HW) {
- ipheader = skb->nh.iph->ihl << 11;
- pkt_info.cmd_sts |= ETH_GEN_TCP_UDP_CHECKSUM |
- ETH_GEN_IP_V_4_CHECKSUM | ipheader;
+ if (skb->ip_summed != CHECKSUM_HW)
+ /* Errata BTS #50, IHL must be 5 if no HW checksum */
+ pkt_info.cmd_sts = ETH_TX_FIRST_DESC |
+ 5 << ETH_TX_IHL_SHIFT;
+ else {
+ pkt_info.cmd_sts = ETH_TX_FIRST_DESC |
+ ETH_GEN_TCP_UDP_CHECKSUM |
+ ETH_GEN_IP_V_4_CHECKSUM |
+ skb->nh.iph->ihl << ETH_TX_IHL_SHIFT;
/* CPU already calculated pseudo header checksum. */
if (skb->nh.iph->protocol == IPPROTO_UDP) {
pkt_info.cmd_sts |= ETH_UDP_FRAME;
diff --git a/drivers/net/mv643xx_eth.h b/drivers/net/mv643xx_eth.h
--- a/drivers/net/mv643xx_eth.h
+++ b/drivers/net/mv643xx_eth.h
@@ -49,7 +49,7 @@
/* Checksum offload for Tx works for most packets, but
* fails if previous packet sent did not use hw csum
*/
-#undef MV643XX_CHECKSUM_OFFLOAD_TX
+#define MV643XX_CHECKSUM_OFFLOAD_TX
#define MV643XX_NAPI
#define MV643XX_TX_FAST_REFILL
#undef MV643XX_RX_QUEUE_FILL_ON_TASK /* Does not work, yet */
@@ -217,6 +217,8 @@
#define ETH_TX_ENABLE_INTERRUPT (BIT23)
#define ETH_AUTO_MODE (BIT30)
+#define ETH_TX_IHL_SHIFT 11
+
/* typedefs */
typedef enum _eth_func_ret_status {
^ permalink raw reply
* [PATCH] [NET] mii: Add test for GigE support
From: Dale Farnsworth @ 2005-08-22 23:50 UTC (permalink / raw)
To: Jeff Garzik, Netdev
In-Reply-To: <20050323061446.GA6943@xyzzy>
[This patch was submitted on 22Mar2005 and jgarzik said,
"applied, thanks", but it may have been lost in the git transition.
I've updated it to current offsets.]
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: netdev-2.6-mv643xx-enet/drivers/net/mii.c
===================================================================
--- netdev-2.6-mv643xx-enet.orig/drivers/net/mii.c
+++ netdev-2.6-mv643xx-enet/drivers/net/mii.c
@@ -207,6 +207,21 @@
return 0;
}
+int mii_check_gmii_support(struct mii_if_info *mii)
+{
+ int reg;
+
+ reg = mii->mdio_read(mii->dev, mii->phy_id, MII_BMSR);
+ if (reg & BMSR_HAS_EXTSTAT1000) {
+ reg = mii->mdio_read(mii->dev, mii->phy_id, MII_EXTSTAT1000);
+ if (reg & (ESR_1000_BASE_X_FD | ESR_1000_BASE_T_FD |
+ ESR_1000_BASE_X_HD | ESR_1000_BASE_T_HD))
+ return 1;
+ }
+
+ return 0;
+}
+
int mii_link_ok (struct mii_if_info *mii)
{
/* first, a dummy read, needed to latch some MII phys */
@@ -394,5 +409,6 @@
EXPORT_SYMBOL(mii_ethtool_sset);
EXPORT_SYMBOL(mii_check_link);
EXPORT_SYMBOL(mii_check_media);
+EXPORT_SYMBOL(mii_check_gmii_support);
EXPORT_SYMBOL(generic_mii_ioctl);
Index: netdev-2.6-mv643xx-enet/include/linux/mii.h
===================================================================
--- netdev-2.6-mv643xx-enet.orig/include/linux/mii.h
+++ netdev-2.6-mv643xx-enet/include/linux/mii.h
@@ -22,6 +22,7 @@
#define MII_EXPANSION 0x06 /* Expansion register */
#define MII_CTRL1000 0x09 /* 1000BASE-T control */
#define MII_STAT1000 0x0a /* 1000BASE-T status */
+#define MII_EXTSTAT1000 0x0f /* 1000BASE-XX extended status */
#define MII_DCOUNTER 0x12 /* Disconnect counter */
#define MII_FCSCOUNTER 0x13 /* False carrier counter */
#define MII_NWAYTEST 0x14 /* N-way auto-neg test reg */
@@ -54,7 +55,8 @@
#define BMSR_ANEGCAPABLE 0x0008 /* Able to do auto-negotiation */
#define BMSR_RFAULT 0x0010 /* Remote fault detected */
#define BMSR_ANEGCOMPLETE 0x0020 /* Auto-negotiation complete */
-#define BMSR_RESV 0x07c0 /* Unused... */
+#define BMSR_HAS_EXTSTAT1000 0x0100 /* Has 1000BASE extended status*/
+#define BMSR_RESV 0x06c0 /* Unused... */
#define BMSR_10HALF 0x0800 /* Can do 10mbps, half-duplex */
#define BMSR_10FULL 0x1000 /* Can do 10mbps, full-duplex */
#define BMSR_100HALF 0x2000 /* Can do 100mbps, half-duplex */
@@ -129,6 +131,12 @@
#define LPA_1000FULL 0x0800 /* Link partner 1000BASE-T full duplex */
#define LPA_1000HALF 0x0400 /* Link partner 1000BASE-T half duplex */
+/* 1000BASE Ext Status register */
+#define ESR_1000_BASE_X_FD 0x8000
+#define ESR_1000_BASE_X_HD 0x4000
+#define ESR_1000_BASE_T_FD 0x2000
+#define ESR_1000_BASE_T_HD 0x1000
+
struct mii_if_info {
int phy_id;
int advertising;
@@ -151,6 +159,7 @@
extern int mii_nway_restart (struct mii_if_info *mii);
extern int mii_ethtool_gset(struct mii_if_info *mii, struct ethtool_cmd *ecmd);
extern int mii_ethtool_sset(struct mii_if_info *mii, struct ethtool_cmd *ecmd);
+extern int mii_check_gmii_support(struct mii_if_info *mii);
extern void mii_check_link (struct mii_if_info *mii);
extern unsigned int mii_check_media (struct mii_if_info *mii,
unsigned int ok_to_print,
^ permalink raw reply
* Re: [RESEND] [PATCH] bond inherits zero-copy flags of slaves
From: Jeff Garzik @ 2005-08-23 5:35 UTC (permalink / raw)
To: Arthur Kepner; +Cc: David S. Miller, netdev, bonding-devel
In-Reply-To: <Pine.LNX.4.61.0508111447370.14105@resonance.WorkGroup>
applied
^ permalink raw reply
* Re: [PATCH] Fix socket bitop damage
From: David S. Miller @ 2005-08-23 16:22 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20050822110218.GA7514@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 22 Aug 2005 12:02:18 +0100
> The socket flag cleanups that went into 2.6.12-rc1 are basically oring
> the flags of an old socket into the socket just being created.
> Unfortunately that one was just initialized by sock_init_data(), so already
> has SOCK_ZAPPED set. As the result zapped sockets are created and all
> incoming connection will fail due to this bug which again was carefully
> replicated to at least AX.25, NET/ROM or ROSE.
>
> In order to keep the abstraction alive I've introduced sock_copy_flags()
> to copy the socket flags from one sockets to another and used that
> instead of the bitwise copy thing. Anyway, the idea here has probably
> been to copy all flags, so sock_copy_flags() should be the right thing.
> With this the ham radio protocols are usable again, so I hope this will
> make it into 2.6.13.
>
> Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Applied, thanks Ralf.
^ permalink raw reply
* Re: [PATCH] AX.25 UID fixes
From: David S. Miller @ 2005-08-23 16:24 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20050822111038.GA7545@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 22 Aug 2005 12:10:38 +0100
> o Brown paperbag bug - ax25_findbyuid() was always returning a NULL pointer
> as the result. Breaks ROSE completly and AX.25 if UID policy set to deny.
>
> o While the list structure of AX.25's UID to callsign mapping table was
> properly protected by a spinlock, it's elements were not refcounted
> resulting in a race between removal and usage of an element.
>
> Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Applied, thanks Ralf.
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-08-23 19:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Robert Olsson, netdev
In-Reply-To: <43014E27.1070104@cosmosbay.com>
On Tue, Aug 16, 2005 at 04:23:35AM +0200, Eric Dumazet wrote:
> Hi Simon
Hi there!
> I think one of the reason linux 2.6 has worst results is because HZ=1000
> (instead of HZ=100 for linux 2.4)
> So if rt_garbage_collect() has heavy work to do, it usually break out of
> the loop because of :
>
> } while (!in_softirq() && time_before_eq(jiffies, now));
I was under the impression, however, that the code Alexei added last time
I brought up this problem was intended to always allow gc when the the
table is full and another entry is attempting to be created, even when
under gc_min_interval. I'm actually not even interested (yet) with
the gc_interval/timer case because I'm testing currently with a flow
creation rate of much larger than max_size per second (the minimum
gc_interval being one second).
> Could you please test latest 2.6.13-rc6 kernel on the Opteron machine,
> compiled with HZ=100, with the appended kernel argument :
>
> rhash_entries=8191 ( or rhash_entries=16383 )
>
> and
>
> echo 1 >/proc/sys/net/ipv4/route/gc_interval
> echo 2 >/proc/sys/net/ipv4/route/gc_elasticity
>
> Could you also post some data from your router (like : rtstat -c 20 -i 1)
Sure. Here are results from 2.6.13-rc6 with HZ=100 and
rhash_entries=8191, which sets the max_size to 131072. I'm using
lnstat becuase the rtstat version I could find doesn't work on
newer kernels:
lnstat -c -1 -i 1 -f rt_cache -k entries,in_hit,in_slow_tot,gc_total,gc_ignored,gc_goal_miss,gc_dst_overflow,in_hlist_search
The sender is running "juno 192.168.1.1 31313 0" (juno-z.101f.c):
pid 18492: ran for 40s, 13595333 packets out, 16241091 bytes/s
(~340kpps)
Without tweaks to gc_interval and gc_elasticity:
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|
| | tot| | ed| miss| verflow| _search|
32| 117| 419| 0| 0| 0| 0| 0|
32| 6| 0| 0| 0| 0| 0| 0|
32| 2| 0| 0| 0| 0| 0| 0|
33| 2| 4| 0| 0| 0| 0| 0|
9033| 2| 9002| 840| 839| 0| 0| 4962|
131062| 22| 125633| 125629| 125447| 182| 181| 837163|
131062| 0| 13511| 13509| 900| 12609| 12609| 10|
131062| 0| 8772| 8770| 600| 8170| 8170| 7|
131062| 0| 8709| 8706| 600| 8106| 8106| 8|
131062| 0| 8771| 8770| 600| 8170| 8170| 6|
131062| 0| 8770| 8768| 600| 8168| 8168| 6|
131062| 0| 8706| 8704| 600| 8104| 8104| 10|
131062| 0| 8770| 8770| 600| 8170| 8170| 5|
131062| 0| 8708| 8706| 600| 8106| 8106| 5|
131062| 0| 8770| 8769| 600| 8169| 8169| 6|
131062| 0| 8770| 8769| 600| 8169| 8169| 10|
131062| 0| 8713| 8706| 600| 8106| 8106| 7|
131062| 0| 8786| 8769| 600| 8169| 8169| 9|
With tweaks (and after 60 seconds to wait for timer expiry):
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|
| | tot| | ed| miss| verflow| _search|
28| 632| 424656| 413834| 145906| 267927| 267926| 842370|
28| 2| 3| 0| 0| 0| 0| 0|
28| 3| 2| 0| 0| 0| 0| 0|
28| 2| 4| 0| 0| 0| 0| 0|
35129| 3| 35999| 27826| 27825| 0| 0| 61913|
131062| 6| 102045| 102043| 99432| 2611| 2610| 288926|
131062| 0| 13446| 13442| 900| 12542| 12542| 11|
131062| 0| 11914| 11909| 800| 11109| 11109| 5|
131062| 0| 8772| 8770| 599| 8171| 8170| 5|
131062| 0| 8708| 8708| 600| 8108| 8108| 7|
131062| 0| 8774| 8771| 600| 8171| 8171| 2|
131062| 0| 8769| 8769| 600| 8169| 8169| 9|
131062| 0| 8706| 8704| 600| 8104| 8104| 4|
131062| 0| 8769| 8768| 599| 8169| 8168| 5|
131062| 0| 8707| 8706| 600| 8106| 8106| 7|
131062| 0| 8771| 8768| 600| 8168| 8168| 6|
131062| 0| 8770| 8768| 600| 8168| 8168| 8|
131062| 0| 8705| 8704| 600| 8104| 8104| 6|
131062| 0| 8771| 8768| 600| 8168| 8168| 5|
No visible difference to me.
On stock 2.4.31 with no alterations to the gc settings (and no
rhash_entries as it doesn't exist), lnstat shows:
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|
| | tot| | ed| miss| verflow| _search|
21| 85| 160| 0| 0| 0| 0| 0|
21| 4| 2| 0| 0| 0| 0| 0|
21| 2| 3| 0| 0| 0| 0| 0|
22| 2| 2| 0| 0| 0| 0| 0|
18432| 11| 136187| 134158| 134156| 1| 0| 1133784|
18432| 5| 195891| 195889| 195887| 2| 0| 1763070|
18432| 9| 195585| 195568| 195566| 2| 0| 1758397|
18432| 7| 195290| 195281| 195279| 0| 0| 1751884|
18432| 8| 195587| 195579| 195577| 0| 0| 1754813|
18432| 20| 195276| 195275| 195273| 0| 0| 1752216|
18432| 11| 194983| 194980| 194978| 0| 0| 1749822|
18432| 7| 195288| 195287| 195285| 0| 0| 1752655|
18432| 13| 195282| 195281| 195279| 0| 0| 1752869|
18432| 12| 194984| 194984| 194982| 1| 0| 1749589|
18432| 17| 194978| 194974| 194972| 0| 0| 1748817|
18432| 11| 194985| 194981| 194979| 0| 0| 1749182|
18432| 14| 194981| 194977| 194975| 0| 0| 1749287|
18432| 14| 194682| 194679| 194677| 0| 0| 1746847|
18432| 11| 194983| 194980| 194978| 0| 0| 1749679|
...and the machine is perfectly responsive. It's dropping packets
(managing to forward ~210 kpps, a little less than 2.4.27), but it's
at least working. 2.6.13-rc6 dribbles out ~33 kpps.
Simon-
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-08-23 19:56 UTC (permalink / raw)
To: Simon Kirby; +Cc: Eric Dumazet, Robert Olsson, netdev
In-Reply-To: <20050823190852.GA20794@netnation.com>
Hello!
Simon Kirby writes:
> I was under the impression, however, that the code Alexei added last time
> I brought up this problem was intended to always allow gc when the the
> table is full and another entry is attempting to be created, even when
> under gc_min_interval.
Yes your GC does not work at all in your 2.6 setups...Why?
> rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
> entries| in_hit|in_slow_|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|
> | | tot| | ed| miss| verflow| _search|
> 131062| 22| 125633| 125629| 125447| 182| 181| 837163|
> 131062| 0| 13511| 13509| 900| 12609| 12609| 10|
> 131062| 0| 8772| 8770| 600| 8170| 8170| 7|
> 131062| 0| 8709| 8706| 600| 8106| 8106| 8|
> 131062| 0| 8771| 8770| 600| 8170| 8170| 6|
> 131062| 0| 8770| 8768| 600| 8168| 8168| 6|
> 131062| 0| 8706| 8704| 600| 8104| 8104| 10|
Can you try
echo 50 > /proc/sys/net/ipv4/route/gc_min_interval_ms
Cheers.
--ro
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-08-24 0:01 UTC (permalink / raw)
To: Robert Olsson; +Cc: Eric Dumazet, netdev
In-Reply-To: <17163.32645.202453.145416@robur.slu.se>
On Tue, Aug 23, 2005 at 09:56:53PM +0200, Robert Olsson wrote:
> Yes your GC does not work at all in your 2.6 setups...Why?
Good question. :)
> echo 50 > /proc/sys/net/ipv4/route/gc_min_interval_ms
The output looks exactly the same with gc_min_interval_ms set to 50.
If I set it to 0, it does change a little but _still_ overflows:
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|
| | tot| | ed| miss| verflow| _search|
3| 3| 1| 1| 1| 0| 0| 0|
4| 11| 5| 0| 0| 0| 0| 0|
5| 5| 2| 0| 0| 0| 0| 0|
23615| 1| 24002| 15812| 0| 0| 0| 11470|
68692| 0| 46780| 46777| 0| 4687| 0| 4492|
86046| 0| 18763| 18754| 0| 18754| 0| 119|
94884| 0| 9540| 9538| 0| 9538| 0| 47|
104901| 0| 10819| 10817| 0| 10817| 0| 61|
114919| 0| 10817| 10818| 0| 10818| 0| 68|
127424| 0| 13512| 13505| 0| 13505| 0| 74|
131062| 0| 15113| 15106| 0| 15106| 10368| 28|
131062| 0| 12503| 12482| 0| 12482| 11582| 9|
131062| 0| 8146| 8130| 0| 8130| 7530| 5|
131062| 0| 8204| 8194| 0| 8194| 7594| 2|
131062| 0| 8132| 8131| 0| 8131| 7531| 5|
131062| 0| 8196| 8195| 0| 8195| 7595| 4|
131062| 0| 8130| 8129| 0| 8129| 7529| 8|
Something is definitely broken here. Are the interrupts (or in this
case, NAPI) able to starve the gc somehow?
Simon-
^ permalink raw reply
* Re: mv643xx(2/20): use MII library for PHY management
From: Benjamin Herrenschmidt @ 2005-08-24 0:33 UTC (permalink / raw)
To: Mark Huth
Cc: Dale Farnsworth, Netdev, Jeff Garzik, Ralf Baechle,
Manish Lachwani, Brian Waite, Steven J. Hill, James Chapman
In-Reply-To: <430BC09A.3090401@mvista.com>
On Tue, 2005-08-23 at 17:34 -0700, Mark Huth wrote:
> It's good to use the abstractions and common code, but in this case
> there is a significant performance difference. The MDIO read/write on
> this family does a cpu spin wait for the mdio operation to complete.
> Last time I measured this (back when fixing up a 2.4.20 implementation)
> I got around 100 us for the mii_ioctl path, of which a good bit was in
> the spin loop waiting for the MDIO operation to complete. A quick look
> seems to indicate the spin loop is still in this version of the driver.
>
> Given that the NIC chip gives cheap access to the link status and a
> couple of other interesting bits, the change to use the mii library has
> a performance impact.
Is it possible to implement the mdio functions without a spin loop ?
Also, it might be a good idea to use the PHY driver model (a-la sungem)
rather than miilib...
Ben.
^ permalink raw reply
* Re: mv643xx(2/20): use MII library for PHY management
From: Mark Huth @ 2005-08-24 0:34 UTC (permalink / raw)
To: Dale Farnsworth
Cc: Netdev, Jeff Garzik, Ralf Baechle, Manish Lachwani, Brian Waite,
Steven J. Hill, Benjamin Herrenschmidt, James Chapman
In-Reply-To: <20050328234225.GB29098@xyzzy>
It's good to use the abstractions and common code, but in this case
there is a significant performance difference. The MDIO read/write on
this family does a cpu spin wait for the mdio operation to complete.
Last time I measured this (back when fixing up a 2.4.20 implementation)
I got around 100 us for the mii_ioctl path, of which a good bit was in
the spin loop waiting for the MDIO operation to complete. A quick look
seems to indicate the spin loop is still in this version of the driver.
Given that the NIC chip gives cheap access to the link status and a
couple of other interesting bits, the change to use the mii library has
a performance impact.
Mark Huth
Dale Farnsworth wrote:
> Modify link up/down handling to use the functions from the MII
> library. Note that I track link state using the MII PHY registers
> rather than the mv643xx chip's link state registers because I think
> it's cleaner to use the MII library code rather than writing local
> driver support code. It is also useful to make the actual MII
> registers available to the user with maskable kernel printk messages
> so the MII registers are being read anyway
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
> Acked-by: Dale Farnsworth <dale@farnsworth.org>
>
> Index: linux-2.5-enet/drivers/net/mv643xx_eth.h
> ===================================================================
> --- linux-2.5-enet.orig/drivers/net/mv643xx_eth.h
> +++ linux-2.5-enet/drivers/net/mv643xx_eth.h
> @@ -6,6 +6,7 @@
> #include <linux/kernel.h>
> #include <linux/spinlock.h>
> #include <linux/workqueue.h>
> +#include <linux/mii.h>
>
> #include <linux/mv643xx.h>
>
> @@ -397,6 +398,9 @@
>
> u32 rx_int_coal;
> u32 tx_int_coal;
> +
> + u32 msg_enable;
> + struct mii_if_info mii;
> };
>
> /* ethernet.h API list */
> Index: linux-2.5-enet/drivers/net/mv643xx_eth.c
> ===================================================================
> --- linux-2.5-enet.orig/drivers/net/mv643xx_eth.c
> +++ linux-2.5-enet/drivers/net/mv643xx_eth.c
> @@ -74,7 +74,6 @@
> #define PHY_WAIT_MICRO_SECONDS 10
>
> /* Static function declarations */
> -static int eth_port_link_is_up(unsigned int eth_port_num);
> static void eth_port_uc_addr_get(struct net_device *dev,
> unsigned char *MacAddr);
> static int mv643xx_eth_real_open(struct net_device *);
> @@ -85,8 +84,11 @@
> #ifdef MV643XX_NAPI
> static int mv643xx_poll(struct net_device *dev, int *budget);
> #endif
> +static int ethernet_phy_get(unsigned int eth_port_num);
> static void ethernet_phy_set(unsigned int eth_port_num, int phy_addr);
> static int ethernet_phy_detect(unsigned int eth_port_num);
> +static int mv643xx_mdio_read(struct net_device *dev, int phy_id, int location);
> +static void mv643xx_mdio_write(struct net_device *dev, int phy_id, int location, int val);
> static struct ethtool_ops mv643xx_ethtool_ops;
>
> static char mv643xx_driver_name[] = "mv643xx_eth";
> @@ -550,16 +552,38 @@
> }
> /* PHY status changed */
> if (eth_int_cause_ext & (BIT16 | BIT20)) {
> - if (eth_port_link_is_up(port_num)) {
> - netif_carrier_on(dev);
> + struct ethtool_cmd cmd;
> +
> + /* mii library handles link maintenance tasks */
> +
> + mii_ethtool_gset(&mp->mii, &cmd);
> + if (netif_msg_link(mp))
> + printk(KERN_DEBUG "%s: link phy regs: "
> + "supported=%x advert=%x "
> + "autoneg=%x speed=%d duplex=%d\n",
> + dev->name,
> + cmd.supported, cmd.advertising,
> + cmd.autoneg, cmd.speed, cmd.duplex);
> +
> + if(mii_link_ok(&mp->mii) && !netif_carrier_ok(dev)) {
> + if (netif_msg_ifup(mp))
> + printk(KERN_INFO "%s: link up, %sMbps, %s-duplex\n",
> + dev->name,
> + cmd.speed == SPEED_1000 ? "1000" :
> + cmd.speed == SPEED_100 ? "100" : "10",
> + cmd.duplex == DUPLEX_FULL ? "full" : "half");
> +
> netif_wake_queue(dev);
> /* Start TX queue */
> - mv_write(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG
> - (port_num), 1);
> - } else {
> - netif_carrier_off(dev);
> + mv_write(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG(port_num), 1);
> +
> + } else if(!mii_link_ok(&mp->mii) && netif_carrier_ok(dev)) {
> netif_stop_queue(dev);
> + if (netif_msg_ifdown(mp))
> + printk(KERN_INFO "%s: link down\n", dev->name);
> }
> +
> + mii_check_link(&mp->mii);
> }
>
> /*
> @@ -1379,6 +1403,10 @@
>
> mp = netdev_priv(dev);
>
> + /* By default, log probe, interface up/down and error events */
> + mp->msg_enable = NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN |
> + NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR;
> +
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> BUG_ON(!res);
> dev->irq = res->start;
> @@ -1415,6 +1443,15 @@
> #endif
> #endif
>
> + /* Hook up MII support for ethtool */
> + mp->mii.dev = dev;
> + mp->mii.mdio_read = mv643xx_mdio_read;
> + mp->mii.mdio_write = mv643xx_mdio_write;
> + mp->mii.phy_id = ethernet_phy_get(mp->port_num);
> + mp->mii.phy_id_mask = 0x3f;
> + mp->mii.reg_num_mask = 0x1f;
> + mp->mii.supports_gmii = 1;
> +
> /* Configure the timeout task */
> INIT_WORK(&mp->tx_timeout_task,
> (void (*)(void *))mv643xx_eth_tx_timeout_task, dev);
> @@ -2323,21 +2360,6 @@
> return phy_reg_data0 & 0x1000;
> }
>
> -static int eth_port_link_is_up(unsigned int eth_port_num)
> -{
> - unsigned int phy_reg_data1;
> -
> - eth_port_read_smi_reg(eth_port_num, 1, &phy_reg_data1);
> -
> - if (eth_port_autoneg_supported(eth_port_num)) {
> - if (phy_reg_data1 & 0x20) /* auto-neg complete */
> - return 1;
> - } else if (phy_reg_data1 & 0x4) /* link up */
> - return 1;
> -
> - return 0;
> -}
> -
> /*
> * ethernet_get_config_reg - Get the port configuration register
> *
> @@ -2468,6 +2490,24 @@
> }
>
> /*
> + * Wrappers for MII support library.
> + */
> +static int mv643xx_mdio_read(struct net_device *dev, int phy_id, int location)
> +{
> + int val;
> + struct mv643xx_private *mp = netdev_priv(dev);
> +
> + eth_port_read_smi_reg(mp->port_num, location, &val);
> + return val;
> +}
> +
> +static void mv643xx_mdio_write(struct net_device *dev, int phy_id, int location, int val)
> +{
> + struct mv643xx_private *mp = netdev_priv(dev);
> + eth_port_write_smi_reg(mp->port_num, location, val);
> +}
> +
> +/*
> * eth_port_send - Send an Ethernet packet
> *
> * DESCRIPTION:
>
>
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-08-24 3:50 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Eric Dumazet, netdev
In-Reply-To: <20050824000158.GA8137@netnation.com>
Simon Kirby writes:
> Something is definitely broken here. Are the interrupts (or in this
> case, NAPI) able to starve the gc somehow?
Hmm no in 2.6 dst entries are freed via RCU callback this had problems
but was redesigned.
Reading your old email... Didn't you get "dst cache overflow" before
2.6.11-bk2?
In other case I like to have your detailed setup to see if I get any
idea or possible can reproduced.
Cheers.
--ro
^ 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