[PATCH 1/2][INET] Move the TCP ehash functions to include/net/inet_hashtables.h

2005-07-31 Thread Arnaldo Carvalho de Melo
Hi David,

Please consider pulling from:

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14-2.git

Best Regards,

- Arnaldo

tree ff1b5c1e2ce12615a99ce662d70b5cbbedc02034
parent 9bbaad8018f7af263d4d3364dcf8cd5d6d90a820
author Arnaldo Carvalho de Melo [EMAIL PROTECTED] 1122787805 -0300
committer Arnaldo Carvalho de Melo [EMAIL PROTECTED] 1122787805 -0300

[INET] Move the TCP ehash functions to include/net/inet_hashtables.h

To be shared with DCCP (and others), this is the start of a series of patches
that will expose the already generic TCP hash table routines.

The few changes noticed when calling gcc -S before/after on a pentium4 were of
this type:

movl40(%esp), %edx
cmpl%esi, 472(%edx)
je  .L168
-   pushl   $291
+   pushl   $272
pushl   $.LC0
pushl   $.LC1
pushl   $.LC2

[EMAIL PROTECTED] net-2.6.14]$ size net/ipv4/tcp_ipv4.before.o 
net/ipv4/tcp_ipv4.after.o
   textdata bss dec hex filename
  17804 516 140   18460481c net/ipv4/tcp_ipv4.before.o
  17804 516 140   18460481c net/ipv4/tcp_ipv4.after.o

Holler if some weird architecture has issues with things like this 8)

Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]

--

 include/net/inet_hashtables.h |   40 
 net/ipv4/tcp_ipv4.c   |   28 +---
 2 files changed, 45 insertions(+), 23 deletions(-)

--

diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
new file mode 100644
--- /dev/null
+++ b/include/net/inet_hashtables.h
@@ -0,0 +1,40 @@
+/*
+ * INETAn implementation of the TCP/IP protocol suite for the 
LINUX
+ * operating system.  INET is implemented using the BSD Socket
+ * interface as the means of communication with the user level.
+ *
+ * Authors:Lotsa people, from code originally in tcp
+ *
+ * This program is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU General Public License
+ *  as published by the Free Software Foundation; either version
+ *  2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _INET_HASHTABLES_H
+#define _INET_HASHTABLES_H
+
+#include linux/types.h
+
+static inline int inet_ehashfn(const __u32 laddr, const __u16 lport,
+  const __u32 faddr, const __u16 fport,
+  const int ehash_size)
+{
+   int h = (laddr ^ lport) ^ (faddr ^ fport);
+   h ^= h  16;
+   h ^= h  8;
+   return h  (ehash_size - 1);
+}
+
+static inline int inet_sk_ehashfn(const struct sock *sk, const int ehash_size)
+{
+   const struct inet_sock *inet = inet_sk(sk);
+   const __u32 laddr = inet-rcv_saddr;
+   const __u16 lport = inet-num;
+   const __u32 faddr = inet-daddr;
+   const __u16 fport = inet-dport;
+
+   return inet_ehashfn(laddr, lport, faddr, fport, ehash_size);
+}
+
+#endif /* _INET_HASHTABLES_H */
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -64,6 +64,7 @@
 #include linux/times.h
 
 #include net/icmp.h
+#include net/inet_hashtables.h
 #include net/tcp.h
 #include net/ipv6.h
 #include net/inet_common.h
@@ -104,26 +105,6 @@ struct tcp_hashinfo __cacheline_aligned 
 int sysctl_local_port_range[2] = { 1024, 4999 };
 int tcp_port_rover = 1024 - 1;
 
-static __inline__ int tcp_hashfn(__u32 laddr, __u16 lport,
-__u32 faddr, __u16 fport)
-{
-   int h = (laddr ^ lport) ^ (faddr ^ fport);
-   h ^= h  16;
-   h ^= h  8;
-   return h  (tcp_ehash_size - 1);
-}
-
-static __inline__ int tcp_sk_hashfn(struct sock *sk)
-{
-   struct inet_sock *inet = inet_sk(sk);
-   __u32 laddr = inet-rcv_saddr;
-   __u16 lport = inet-num;
-   __u32 faddr = inet-daddr;
-   __u16 fport = inet-dport;
-
-   return tcp_hashfn(laddr, lport, faddr, fport);
-}
-
 /* Allocate and initialize a new TCP local port bind bucket.
  * The bindhash mutex for snum's hash chain must be held here.
  */
@@ -362,7 +343,8 @@ static __inline__ void __tcp_v4_hash(str
lock = tcp_lhash_lock;
tcp_listen_wlock();
} else {
-   list = tcp_ehash[(sk-sk_hashent = tcp_sk_hashfn(sk))].chain;
+   sk-sk_hashent = inet_sk_ehashfn(sk, tcp_ehash_size);
+   list = tcp_ehash[sk-sk_hashent].chain;
lock = tcp_ehash[sk-sk_hashent].lock;
write_lock(lock);
}
@@ -495,7 +477,7 @@ static inline struct sock *__tcp_v4_look
/* Optimize here for direct hit, only listening connections can
 * have wildcards anyways.
 

Re: [git patches] new wireless stuffs

2005-07-31 Thread Christoph Hellwig
On Sat, Jul 30, 2005 at 07:24:46PM -0400, Jeff Garzik wrote:
 
 If this is post-2.6.13 material, that's fine.
 
 I've been getting tired of the slow movement of wireless.  A little bit 
 of that is my fault, certainly.  I've also been wanting to get these net 
 drivers out to Linux users.
 
 This adds HostAP, ipw2100, ipw2200, and the generic ieee80211 code.  The 
 only -changes- in this set are cosmetic.

Any chance we can give the hostap driver a better name?  hostap describes
the AP mode it can operate on, but it should really be named after the hardware
it supports in some way.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[patch 5/6] drivers/net/seeq8005.c : Use of the time_before() macro

2005-07-31 Thread domen
From: Marcelo Feitoza Parisi [EMAIL PROTECTED]



Use of the time_before() macro, defined at linux/jiffies.h, which deal
with wrapping correctly and are nicer to read.

Signed-off-by: Marcelo Feitoza Parisi [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]

---
 seeq8005.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

Index: quilt/drivers/net/seeq8005.c
===
--- quilt.orig/drivers/net/seeq8005.c
+++ quilt/drivers/net/seeq8005.c
@@ -699,7 +699,7 @@ static void hardware_send_packet(struct 
int ioaddr = dev-base_addr;
int status = inw(SEEQ_STATUS);
int transmit_ptr = 0;
-   int tmp;
+   unsigned long tmp;
 
if (net_debug4) {
printk(%s: send 0x%04x\n,dev-name,length);
@@ -724,7 +724,8 @@ static void hardware_send_packet(struct 

/* drain FIFO */
tmp = jiffies;
-   while ( (((status=inw(SEEQ_STATUS))  SEEQSTAT_FIFO_EMPTY) == 0)  
(jiffies - tmp  HZ))
+   while ( (((status=inw(SEEQ_STATUS))  SEEQSTAT_FIFO_EMPTY) == 0)
+time_before(jiffies, tmp + HZ))
mb();

/* doit ! */

--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [git patches] new wireless stuffs

2005-07-31 Thread Pavel Machek
Hi!

 If this is post-2.6.13 material, that's fine.
 
 I've been getting tired of the slow movement of wireless.  A little bit 
 of that is my fault, certainly.  I've also been wanting to get these net 
 drivers out to Linux users.
 
 This adds HostAP, ipw2100, ipw2200, and the generic ieee80211 code.  The 
 only -changes- in this set are cosmetic.
 
 Further work is pending from SuSE and Intel [*poke* *poke* to them], but 
 these should be working, and have been in -mm for quite a while.
 
 One big thing I'm still hoping for is that someone will merge HostAP 
 (where ieee80211 code came from) with the ieee80211 generic code.  The 
 HostAP maintainer has been unwilling to do it, even though he has been 
 good about keeping HostAP updated, so hopefully a volunteer will step up.
 
 Please pull from branch 'ieee80211-wifi' of
 rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
 
 to obtain the changes described by the attached diffstat/changelog.  The 
 file additions were too large to attach, so I only attached the changes 
 to existing files.  Existing drivers merely had some struct renames (for 
 new ieee80211 header), and some 'add static attribute' changes.

Wow, thanks!
Pavel

-- 
if you have sharp zaurus hardware you don't need... you know my address
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Resend: [RFC/PATCH] safer ipv4 reassembly

2005-07-31 Thread Herbert Xu
On Sun, Jul 31, 2005 at 05:17:56PM +1000, herbert wrote:

 However, this is even better :) Except that I'm confused by what you
 said here that we need to key on the ID.  Why do we need to key on
 the ID? I would've thought that the saddr is sufficient.

Anyway, here is a patch to use inetpeer instead of that icky ipc
structure.  It sure cuts down the size of the patch :)

I've only compile-tested this one so please don't apply it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -351,6 +351,7 @@ enum
NET_TCP_BIC_BETA=108,
NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR=109,
NET_TCP_CONG_CONTROL=110,
+   NET_IPV4_IPFRAG_MAX_DIST=111,
 };
 
 enum {
diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h
@@ -25,6 +25,7 @@ struct inet_peer
__u32   v4daddr;/* peer's address */
__u16   avl_height;
__u16   ip_id_count;/* IP ID for the next packet */
+   atomic_trid;/* Frag reception counter */
__u32   tcp_ts;
unsigned long   tcp_ts_stamp;
 };
diff --git a/include/net/ip.h b/include/net/ip.h
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -45,6 +45,7 @@ struct inet_skb_parm
 #define IPSKB_TRANSLATED   2
 #define IPSKB_FORWARDED4
 #define IPSKB_XFRM_TUNNEL_SIZE 8
+#define IPSKB_FRAG_COMPLETE16
 };
 
 struct ipcm_cookie
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -401,6 +401,7 @@ struct inet_peer *inet_getpeer(__u32 dad
return NULL;
n-v4daddr = daddr;
atomic_set(n-refcnt, 1);
+   atomic_set(n-rid, 0);
n-ip_id_count = secure_ip_id(daddr);
n-tcp_ts_stamp = 0;
 
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -22,6 +22,7 @@
  * Patrick McHardy :   LRU queue of frag heads for evictor.
  */
 
+#include linux/compiler.h
 #include linux/config.h
 #include linux/module.h
 #include linux/types.h
@@ -38,6 +39,7 @@
 #include net/ip.h
 #include net/icmp.h
 #include net/checksum.h
+#include net/inetpeer.h
 #include linux/tcp.h
 #include linux/udp.h
 #include linux/inet.h
@@ -56,6 +58,8 @@
 int sysctl_ipfrag_high_thresh = 256*1024;
 int sysctl_ipfrag_low_thresh = 192*1024;
 
+int sysctl_ipfrag_max_dist;
+
 /* Important NOTE! Fragment queue must be destroyed before MSL expires.
  * RFC791 is wrong proposing to prolongate timer each fragment arrival by TTL.
  */
@@ -90,8 +94,11 @@ struct ipq {
atomic_trefcnt;
struct timer_list timer;/* when will this queue expire? 
*/
struct ipq  **pprev;
-   int iif;
struct timeval  stamp;
+   int iif;
+
+   unsigned intrid;
+   struct inet_peer *peer;
 };
 
 /* Hash table. */
@@ -207,6 +214,9 @@ static void ip_frag_destroy(struct ipq *
BUG_TRAP(qp-last_inCOMPLETE);
BUG_TRAP(del_timer(qp-timer) == 0);
 
+   if (qp-peer)
+   inet_putpeer(qp-peer);
+
/* Release all fragment data. */
fp = qp-fragments;
while (fp) {
@@ -366,6 +376,7 @@ static struct ipq *ip_frag_create(unsign
qp-meat = 0;
qp-fragments = NULL;
qp-iif = 0;
+   qp-peer = sysctl_ipfrag_max_dist ? inet_getpeer(iph-saddr, 1) : NULL;
 
/* Initialize a timer for this entry. */
init_timer(qp-timer);
@@ -410,6 +421,48 @@ static inline struct ipq *ip_find(struct
return ip_frag_create(hash, iph, user);
 }
 
+/* Is the fragment too far ahead to be part of ipq? */
+static inline int ip_frag_too_far(struct ipq *qp)
+{
+   struct inet_peer *peer = qp-peer;
+   unsigned int max = sysctl_ipfrag_max_dist;
+   unsigned int start, end;
+
+   if (!peer || !max)
+   return 0;
+
+   start = qp-rid;
+   end = atomic_inc_return(peer-rid);
+   qp-rid = end;
+
+   return qp-fragments  (unsigned int)(end - start) = max;
+}
+
+static int ip_frag_reinit(struct ipq *qp)
+{
+   struct sk_buff *fp;
+
+   if (!mod_timer(qp-timer, jiffies + sysctl_ipfrag_time)) {
+   atomic_inc(qp-refcnt);
+   return -ETIMEDOUT;
+   }
+
+   fp = qp-fragments;
+   do {
+   struct sk_buff *xp = fp-next;
+   frag_kfree_skb(fp, NULL);
+   fp = xp;
+   } while (fp);
+
+   qp-last_in = 0;
+   qp-len = 0;
+   qp-meat = 0;
+   qp-fragments = NULL;
+   qp-iif = 0;
+
+   return 0;
+}
+
 /* Add new 

Re: [git patches] new wireless stuffs

2005-07-31 Thread Jeff Garzik

Christoph Hellwig wrote:

Any chance we can give the hostap driver a better name?  hostap describes
the AP mode it can operate on, but it should really be named after the hardware
it supports in some way.



If the driver gets rewritten, sure.  Otherwise, users are already 
familiar with the name.


Jeff


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Resend: [RFC/PATCH] safer ipv4 reassembly

2005-07-31 Thread David S. Miller
From: Herbert Xu [EMAIL PROTECTED]
Date: Sun, 31 Jul 2005 17:17:56 +1000

 On Sat, Jul 30, 2005 at 11:44:55PM -0700, David S. Miller wrote:
  
  I wish I could come up with a sane way to use the inetpeer cache to
  store this info.  Unfortunately we need to key on address _and_ ID.
 
 However, this is even better :) Except that I'm confused by what you
 said here that we need to key on the ID.  Why do we need to key on
 the ID? I would've thought that the saddr is sufficient.

Well... Looking at your code, I came away understanding that
you needed to make the IPC objects unique per saddr/ID.  That's
what you hash them by.

But thinking some more, this appears to be no more than an
implementation detail, ie. so that the IPCs show up on the
same hash chains as the queues using them, thus making them
easy to find.

So do you need these window measurements IPC object to be per saddr or
per saddr+ID?  If they only need to be per saddr alone, then we can
and should use the inetpeer cache for this.

I would also suggest that some reasonable non-zero default max_win
be choosen.  This stuff will not get tested otherwise.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [EMAIL PROTECTED]: Re: weird sysctl behaviour]

2005-07-31 Thread David S. Miller

This is way many global+per-device sysctls work in the
networking.

The global setting is the default unless the per-device value
is set, in which case it overrides the global value.

Changing the global value does not change the per-device values.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Resend: [RFC/PATCH] safer ipv4 reassembly

2005-07-31 Thread Arthur Kepner

On Sun, 31 Jul 2005, David S. Miller wrote:

 .
 I would also suggest that some reasonable non-zero default max_win
 be choosen.  This stuff will not get tested otherwise.
 

Agree with this. 

(And I'll comment on the previous several mails in this thread once 
I've had time to review more carefully.)

--
Arthur
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Resend: [RFC/PATCH] safer ipv4 reassembly

2005-07-31 Thread David S. Miller
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 1 Aug 2005 00:13:59 +1000

 Anyway, here is a patch to use inetpeer instead of that icky ipc
 structure.  It sure cuts down the size of the patch :)

Yes, that is so much nicer.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Fw: 2.6.13-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918

2005-07-31 Thread Andrew Morton


Begin forwarded message:

Date: Sun, 31 Jul 2005 17:02:01 +0200
From: Guillaume Pelat [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Cc: [EMAIL PROTECTED]
Subject: 2.6.13-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918


Hi,

I've been trying to upgrade kernel from 2.6.12.3 to 2.6.13-rc4 on a 
rather loaded http server, but i'm currently having a kernel panic a few 
minutes only after booting. The bug was reproductible (the crash 
happened after every reboot, with the same backtrace).

Here is the error log:
[ cut here ]
kernel BUG at net/ipv4/tcp_output.c:918!
invalid operand:  [#1]
CPU:0
EIP:0060:[c027dd56]Not tainted VLI
EFLAGS: 00010293   (2.6.13-rc4-endy)
EIP is at tcp_tso_should_defer+0xd6/0xf0
eax: 0007   ebx: f1258080   ecx: 0007   edx: f297f800
esi: 0008   edi: 0004   ebp: c031fd80   esp: c031fd70
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c031e000 task=c02dbb80)
Stack: f5f547b8 f1258080 0008 f297f800 c031fdb8 c027de4b f297f800 
f297f800
f1258080 0009 f297f800 d039250c  0002 0002 
f297f800
f297f800 0100 c031fddc c027e192 f297f800 0218 0001 
f5fd4034
Call Trace:
  [c0102e5f] show_stack+0x7f/0xa0
  [c0103002] show_registers+0x152/0x1c0
  [c01031f8] die+0xc8/0x140
  [c0103325] do_trap+0xb5/0xc0
  [c010366c] do_invalid_op+0xbc/0xd0
  [c0102aa3] error_code+0x4f/0x54
  [c027de4b] tcp_write_xmit+0xdb/0x3f0
  [c027e192] __tcp_push_pending_frames+0x32/0xd0
  [c027c04e] tcp_rcv_state_process+0x2be/0x9c0
  [c0283ee9] tcp_v4_do_rcv+0x99/0x120
  [c02844e2] tcp_v4_rcv+0x572/0x750
  [c026a62b] ip_local_deliver+0xcb/0x1d0
  [c026aa52] ip_rcv+0x322/0x4a0
  [c0256a97] netif_receive_skb+0x137/0x1a0
  [c0256b8f] process_backlog+0x8f/0x110
  [c0256c82] net_rx_action+0x72/0x100
  [c01172dc] __do_softirq+0x8c/0xa0
  [c011731a] do_softirq+0x2a/0x30
  [c01173d5] irq_exit+0x35/0x40
  [c01044fc] do_IRQ+0x3c/0x70
  [c0102a46] common_interrupt+0x1a/0x20
  [c0100997] cpu_idle+0x57/0x60
  [c010024b] _stext+0x2b/0x30
  [c0320847] start_kernel+0x147/0x170
  [c0100199] 0xc0100199
Code: 89 f8 0f af c2 3b 45 f0 0f 47 45 f0 31 d2 89 45 f0 f7 f3 31 d2 39 
c1 73 ce ba 01 00 00 00 eb c7 6b c2 03 31 d2 39 c1 77 be eb ee 0f 0b 
96 03 ae 54 2d c0 e9 76 ff ff ff 8b ba 78 02 00 00 eb eb
  0Kernel panic - not syncing: Fatal exception in interrupt

Some infos about my system:

My network card is an e1000.

root # cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 3
model name  : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping: 3
cpu MHz : 2995.045
cache size  : 1024 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dtsacpi mmx fxsr sse sse2 ss ht tm pbe pni 
monitor ds_cpl cid
bogomips: 5914.62

http00 root # uname -a
Linux http00 2.6.13-rc4 #1 Thu May 19 14:19:19 CEST 2005 i686 Intel(R) 
Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

You can find dmesg, lspci and config at the following address:
http://82.196.5.50/20050731/config.txt
http://82.196.5.50/20050731/dmesg.txt
http://82.196.5.50/20050731/lspci.txt
http://82.196.5.50/20050731/sysctl.txt

Best regards,

Guillaume Pelat
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Resend: [RFC/PATCH] safer ipv4 reassembly

2005-07-31 Thread David S. Miller
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 1 Aug 2005 08:33:00 +1000

 Actually that reminds me, we better add some accounting stuff so
 that we know that it is being used.

I agree.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Resend: [RFC/PATCH] safer ipv4 reassembly

2005-07-31 Thread Herbert Xu
On Sun, Jul 31, 2005 at 11:40:11AM -0700, David S. Miller wrote:
 
 Well... Looking at your code, I came away understanding that
 you needed to make the IPC objects unique per saddr/ID.  That's
 what you hash them by.

I see.  The ID is actually a constant in my original patch.  The
idea is that as a packet passes through the stack, we only perform
this check for the first time that ip_defrag is applied.  For example,
if both PREROUTING and SNAT are used for a forwarded packet, then
the check is only applied at PREROUTING.

Given that, we don't really care about the value of user passed
to ip_defrag since we'll only be seeing each packet from saddr
exactly once as far as this check is concerned.
 
 I would also suggest that some reasonable non-zero default max_win
 be choosen.  This stuff will not get tested otherwise.

Actually that reminds me, we better add some accounting stuff so
that we know that it is being used.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 2.6.13-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918

2005-07-31 Thread David S. Miller
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 1 Aug 2005 09:03:14 +1000

 I suspect that the MSS stored in the skb disagrees with the
 mss_now.  So when tso_fragment chops it up we end up with a TSO count
 that's greater than what we started with.

Oh yes, that would bolix things up.  If we get a sequence of
events like this:

initialize tcp_skb_pcount(skb), but skb cannot be sent
for some reason

PMTU event, or addition of SACK blocks, decreases mss_now

try again to send SKB, whoops it needs fragmenting and
MSS is different

then that could easily happen.

However, if that actually occurs, cwnd_quota would decrement past zero
in tcp_write_xmit() and hit negative, something we also BUG() on way
before the next tcp_tso_should_defer() call.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [git patches] net driver fixes

2005-07-31 Thread Linus Torvalds


On Sun, 31 Jul 2005, Jeff Garzik wrote:

 Please pull from the 'upstream-fixes' branch of
 rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
 
 to obtain the fixes described in the attached diffstat/changelog/patch.

Could you please try to edit the emails you apply to something prettier 
than this:


[PATCH] Fix OMAP specific typo in smc91x.h

--ReaqsoxgOBHFXBhH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi Jeff,

Here's a little patch fixing a typo in smc91x.h.

Regards,

Tony

--ReaqsoxgOBHFXBhH
Content-Type: text/x-chdr; charset=us-ascii
Content-Disposition: inline; filename=patch-fix-typo-smc91x.h
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]

Ugh. It's not like we want people saying Hi there in our changelogs.

Linus
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Bugme-new] [Bug 4952] New: IPSec incompabilty. Linux kernel waits to long to start using new SA for outbound traffic.

2005-07-31 Thread David S. Miller
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 1 Aug 2005 14:30:46 +1000

 Well the problem is that the kernel simply doesn't have the information
 to selectively flush dst's given a new SA.  All it can do is flush out
 all cached dst entries when a new SA is added.  Because SA changes are
 actually pretty common (as opposed to policy changes which shouldn't
 occur in a stable system) this is something I'd like to avoid if
 possible.

I see.

We can avoid the flushing damage to DSTs of the effected policy.
At least I think we can do that cleanly.  Do you think that is
a middle ground that might be acceptable to you?

The idea is this:

1) Add to xfrm_policy

struct  list_head   sa_dst_list;

2) Add to xfrm_dst

struct  xfrm_policy *policy;
struct  list_head   policy_list;

   struct dst_entry already has an xfrm pointer that allows
   us to get back to the state, but that unfortunately doesn't
   allow one to get back to the policy.

My mind is fuzzy on this, is there a many to one relationship
from SAs to policies?  If so, my idea is dead in the water.
If not, read on :-)

The idea is that when we build a bundle, the top xfrm_dst gets
linked into the sa_dst_list of the policy we matched.

When an SA changes, we walk that assosciated policies DST list
marking them -obsolete

When a policy is destroyed, we walk the list marking the DSTs
obsolete and unlinking them from the policy list.

When top-level xfrm_dst objects are freed up, we unlink them
from the policy list.

The xfrm_policy-lock protects the policy list.

One nice aspect of this is that it keeps us from having to
(for example) consider schemes such as incrementing the flow
cache generation ID and checking that in the socket dst cache
verify code.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH][INET] Move the TCP hashtable functions/structs to inet_hashtables.[ch]

2005-07-31 Thread David S. Miller
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo)
Date: Mon, 1 Aug 2005 02:10:30 -0300

 rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14-2.git

All pulled, thanks Arnaldo.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html