Re: [2.6 patch] net/ipv4/ipvs/: remove unused exports
On Sun, Nov 11, 2007 at 07:48:40AM +0100, Adrian Bunk wrote:
This patch removes the following unused EXPORT_SYMBOL's:
- ip_vs_try_bind_dest
- ip_vs_find_dest
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Looks fine to me.
Should Dave Miller put this in his tree,
or do you want to handle it a different way?
Acked-by: Simon Horman [EMAIL PROTECTED]
---
net/ipv4/ipvs/ip_vs_conn.c |1 -
net/ipv4/ipvs/ip_vs_ctl.c |1 -
2 files changed, 2 deletions(-)
ad9f400d4f66ea3423f97e609d6ef2572055c603
diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c
index b7eeae6..0a9f3c3 100644
--- a/net/ipv4/ipvs/ip_vs_conn.c
+++ b/net/ipv4/ipvs/ip_vs_conn.c
@@ -441,7 +441,6 @@ struct ip_vs_dest *ip_vs_try_bind_dest(struct ip_vs_conn
*cp)
} else
return NULL;
}
-EXPORT_SYMBOL(ip_vs_try_bind_dest);
/*
diff --git a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c
index 3c4d22a..b64cf45 100644
--- a/net/ipv4/ipvs/ip_vs_ctl.c
+++ b/net/ipv4/ipvs/ip_vs_ctl.c
@@ -604,7 +604,6 @@ struct ip_vs_dest *ip_vs_find_dest(__be32 daddr, __be16
dport,
ip_vs_service_put(svc);
return dest;
}
-EXPORT_SYMBOL(ip_vs_find_dest);
/*
* Lookup dest by {svc,addr,port} in the destination trash.
-
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
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
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
drivers/net/ax88796.c compile error on sh64
Commit 8687991a734a67f1638782c968f46fff0f94bb1f causes the following compile error on sh64: -- snip -- ... CC [M] drivers/net/ax88796.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c: In function 'ax_get_8390_hdr': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:187: error: implicit declaration of function 'readsw' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:189: error: implicit declaration of function 'readsb' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c: In function 'ax_block_output': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:275: error: implicit declaration of function 'writesw' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:277: error: implicit declaration of function 'writesb' make[3]: *** [drivers/net/ax88796.o] Error 1 -- snip -- cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: drivers/net/ax88796.c compile error on sh64
On Sun, Nov 11, 2007 at 10:06:21AM +0100, Adrian Bunk wrote: Commit 8687991a734a67f1638782c968f46fff0f94bb1f causes the following compile error on sh64: -- snip -- ... CC [M] drivers/net/ax88796.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c: In function 'ax_get_8390_hdr': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:187: error: implicit declaration of function 'readsw' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:189: error: implicit declaration of function 'readsb' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c: In function 'ax_block_output': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:275: error: implicit declaration of function 'writesw' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/net/ax88796.c:277: error: implicit declaration of function 'writesb' make[3]: *** [drivers/net/ax88796.o] Error 1 -- snip -- That's a pretty good argument for the PLAT_HAS_xxx stuff in the Kconfig space. We could have a if (CONFIG_SUPERH !CONFIG_SUPERH64) thing here, but there's probably not much point. I'm planning on merging them in the 2.6.25 time period anyways, so adding a stop-gap solution to hide this driver's visibility doesn't really seem like a worthwhile endeavour. - 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 : Oops preceded by WARNING: at net/ipv4/tcp_input.c:1571 tcp_remove_reno_sacks()
Hi, I'm currently running bittorrent with all of this, I just saw this (for the first time ever), but otherwise it works fine: WARNING: at net/ipv4/tcp_output.c:1807 tcp_simple_retransmit() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f6a79] tcp_simple_retransmit+0xfa/0x185 [c02fa072] tcp_v4_err+0x35d/0x4cb [c0301f7d] icmp_unreach+0x327/0x352 [c030159d] icmp_rcv+0xe0/0xf7 [c02e2d75] ip_local_deliver_finish+0x124/0x1ba [c02e3178] ip_local_deliver+0x72/0x7e [c02e2c31] ip_rcv_finish+0x299/0x2b9 [c02e30e8] ip_rcv+0x1e1/0x1ff [c02c755c] netif_receive_skb+0x37d/0x401 [c02c9372] process_backlog+0x5b/0x96 [c02c9037] net_rx_action+0x87/0x152 [c0121c9f] __do_softirq+0x38/0x7a [c0105975] do_softirq+0x41/0x92 I don't know if it's caused by the disabling of tcp_sack, but bittorrenting the whole night, I have a lot more of tcp_verify_left_out() warnings in the logs: WARNING: at net/ipv4/tcp_output.c:1807 tcp_simple_retransmit() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f6a79] tcp_simple_retransmit+0xfa/0x185 [c02fa072] tcp_v4_err+0x35d/0x4cb [c0301f7d] icmp_unreach+0x327/0x352 [c030159d] icmp_rcv+0xe0/0xf7 [c02e2d75] ip_local_deliver_finish+0x124/0x1ba [c02e3178] ip_local_deliver+0x72/0x7e [c02e2c31] ip_rcv_finish+0x299/0x2b9 [c02e30e8] ip_rcv+0x1e1/0x1ff [c02c755c] netif_receive_skb+0x37d/0x401 [c02c9372] process_backlog+0x5b/0x96 [c02c9037] net_rx_action+0x87/0x152 [c0121c9f] __do_softirq+0x38/0x7a [c0105975] do_softirq+0x41/0x92 === WARNING: at net/ipv4/tcp_input.c:2405 tcp_fastretrans_alert() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f05a3] tcp_ack+0xd8c/0x17dd [c02f36bd] tcp_rcv_established+0xdb/0x5f2 [c02f8bc5] tcp_v4_do_rcv+0x2b/0x310 [c02faa0b] tcp_v4_rcv+0x82b/0x89d [c02e2d75] ip_local_deliver_finish+0x124/0x1ba [c02e3178] ip_local_deliver+0x72/0x7e [c02e2c31] ip_rcv_finish+0x299/0x2b9 [c02e30e8] ip_rcv+0x1e1/0x1ff [c02c755c] netif_receive_skb+0x37d/0x401 [c02c9372] process_backlog+0x5b/0x96 [c02c9037] net_rx_action+0x87/0x152 [c0121c9f] __do_softirq+0x38/0x7a [c0105975] do_softirq+0x41/0x92 === WARNING: at net/ipv4/tcp_input.c:2405 tcp_fastretrans_alert() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f05a3] tcp_ack+0xd8c/0x17dd [c02f3b03] tcp_rcv_established+0x521/0x5f2 [c02f8bc5] tcp_v4_do_rcv+0x2b/0x310 [c02faa0b] tcp_v4_rcv+0x82b/0x89d [c02e2d75] ip_local_deliver_finish+0x124/0x1ba [c02e3178] ip_local_deliver+0x72/0x7e [c02e2c31] ip_rcv_finish+0x299/0x2b9 [c02e30e8] ip_rcv+0x1e1/0x1ff [c02c755c] netif_receive_skb+0x37d/0x401 [c02c9372] process_backlog+0x5b/0x96 [c02c9037] net_rx_action+0x87/0x152 [c0121c9f] __do_softirq+0x38/0x7a [c0105975] do_softirq+0x41/0x92 === WARNING: at net/ipv4/tcp_input.c:1672 tcp_enter_frto() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f2a60] tcp_enter_frto+0x166/0x1db [c02f7a06] tcp_write_timer+0x3aa/0x5bc [c01249b4] run_timer_softirq+0x105/0x177 [c0121c9f] __do_softirq+0x38/0x7a [c0105975] do_softirq+0x41/0x92 === WARNING: at net/ipv4/tcp_input.c:2941 tcp_process_frto() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f014b] tcp_ack+0x934/0x17dd [c02f3b03] tcp_rcv_established+0x521/0x5f2 [c02f8bc5] tcp_v4_do_rcv+0x2b/0x310 [c02faa0b] tcp_v4_rcv+0x82b/0x89d [c02e2d75] ip_local_deliver_finish+0x124/0x1ba [c02e3178] ip_local_deliver+0x72/0x7e [c02e2c31] ip_rcv_finish+0x299/0x2b9 [c02e30e8] ip_rcv+0x1e1/0x1ff [c02c755c] netif_receive_skb+0x37d/0x401 [c02c9372] process_backlog+0x5b/0x96 [c02c9037] net_rx_action+0x87/0x152 [c0121c9f] __do_softirq+0x38/0x7a [c0105975] do_softirq+0x41/0x92 === WARNING: at net/ipv4/tcp_input.c:2405 tcp_fastretrans_alert() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f05a3] tcp_ack+0xd8c/0x17dd [c02f3b03] tcp_rcv_established+0x521/0x5f2 [c02f8bc5] tcp_v4_do_rcv+0x2b/0x310 [c02faa0b] tcp_v4_rcv+0x82b/0x89d [c02e2d75] ip_local_deliver_finish+0x124/0x1ba [c02e3178] ip_local_deliver+0x72/0x7e [c02e2c31] ip_rcv_finish+0x299/0x2b9 [c02e30e8] ip_rcv+0x1e1/0x1ff [c02c755c] netif_receive_skb+0x37d/0x401 [c02c9372] process_backlog+0x5b/0x96 [c02c9037] net_rx_action+0x87/0x152 [c0121c9f] __do_softirq+0x38/0x7a [c0105975] do_softirq+0x41/0x92 === WARNING: at net/ipv4/tcp_input.c:2306 tcp_try_to_open() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f0a8c] tcp_ack+0x1275/0x17dd [c02f3b03]
DaveM collecting netdev patches this week
I'm about to disappear (virtually) through Friday for vacation. David Miller has agreed to collect net driver bug fix patches in my absence, with Stephen and Francois (and others, hopefully) helping out with patch review. David -- note that my 2.6.25 was opened a little while ago. If you feel motivated enough to collect non-bugfix patches, please make sure to apply them on top of netdev-2.6.git#upstream. There is already quite a collection of stuff for 2.6.25 queued... 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: [PATCH] NET: Add the helper kernel_sock_shutdown()
On Thu, Nov 08, 2007 at 07:01:36PM -0500, Trond Myklebust wrote: From: Trond Myklebust [EMAIL PROTECTED] ...and fix a couple of bugs in the NBD, CIFS and OCFS2 socket handlers. Looking at the sock-op-shutdown() handlers, it looks as if all of them take a SHUT_RD/SHUT_WR/SHUT_RDWR argument instead of the RCV_SHUTDOWN/SEND_SHUTDOWN arguments. Add a helper, and then define the SHUT_* enum to ensure that kernel users of shutdown() don't get confused. That looks pretty good - any objection to naming the enum and using that name in the prototype for kernel_sock_shutdown() so it's even more obvious what type of shutdown argument this expects? --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - 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] NET: Add the helper kernel_sock_shutdown()
On Sun, 2007-11-11 at 10:03 -0800, Mark Fasheh wrote:
On Thu, Nov 08, 2007 at 07:01:36PM -0500, Trond Myklebust wrote:
From: Trond Myklebust [EMAIL PROTECTED]
...and fix a couple of bugs in the NBD, CIFS and OCFS2 socket handlers.
Looking at the sock-op-shutdown() handlers, it looks as if all of them
take a SHUT_RD/SHUT_WR/SHUT_RDWR argument instead of the
RCV_SHUTDOWN/SEND_SHUTDOWN arguments.
Add a helper, and then define the SHUT_* enum to ensure that kernel users
of shutdown() don't get confused.
That looks pretty good - any objection to naming the enum and using that
name in the prototype for kernel_sock_shutdown() so it's even more obvious
what type of shutdown argument this expects?
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
[EMAIL PROTECTED]
That would be fine by me. How about the attached patch?
Cheers
Trond
---BeginMessage---
...and fix a couple of bugs in the NBD, CIFS and OCFS2 socket handlers.
Looking at the sock-op-shutdown() handlers, it looks as if all of them
take a SHUT_RD/SHUT_WR/SHUT_RDWR argument instead of the
RCV_SHUTDOWN/SEND_SHUTDOWN arguments.
Add a helper, and then define the SHUT_* enum to ensure that kernel users
of shutdown() don't get confused.
Signed-off-by: Trond Myklebust [EMAIL PROTECTED]
Cc: Paul Clements [EMAIL PROTECTED]
Cc: Mark Fasheh [EMAIL PROTECTED]
Cc: Steve French [EMAIL PROTECTED]
Cc: David Howells [EMAIL PROTECTED]
Cc: David S Miller [EMAIL PROTECTED]
---
drivers/block/nbd.c|3 ++-
fs/cifs/connect.c |2 +-
fs/ocfs2/cluster/tcp.c |4 ++--
include/linux/net.h|8
net/rxrpc/ar-local.c |4 ++--
net/socket.c |6 ++
6 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 6332aca..b4c0888 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -28,6 +28,7 @@
#include linux/err.h
#include linux/kernel.h
#include net/sock.h
+#include linux/net.h
#include asm/uaccess.h
#include asm/system.h
@@ -126,7 +127,7 @@ static void sock_shutdown(struct nbd_device *lo, int lock)
if (lo-sock) {
printk(KERN_WARNING %s: shutting down socket\n,
lo-disk-disk_name);
- lo-sock-ops-shutdown(lo-sock, SEND_SHUTDOWN|RCV_SHUTDOWN);
+ kernel_sock_shutdown(lo-sock, SHUT_RDWR);
lo-sock = NULL;
}
if (lock)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 19ee11f..bea0d2e 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -160,7 +160,7 @@ cifs_reconnect(struct TCP_Server_Info *server)
if (server-ssocket) {
cFYI(1, (State: 0x%x Flags: 0x%lx, server-ssocket-state,
server-ssocket-flags));
- server-ssocket-ops-shutdown(server-ssocket, SEND_SHUTDOWN);
+ kernel_sock_shutdown(server-ssocket, SHUT_WR);
cFYI(1, (Post shutdown state: 0x%x Flags: 0x%lx,
server-ssocket-state,
server-ssocket-flags));
diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index 685c180..d84bd15 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
@@ -58,6 +58,7 @@
#include linux/slab.h
#include linux/idr.h
#include linux/kref.h
+#include linux/net.h
#include net/tcp.h
#include asm/uaccess.h
@@ -616,8 +617,7 @@ static void o2net_shutdown_sc(struct work_struct *work)
del_timer_sync(sc-sc_idle_timeout);
o2net_sc_cancel_delayed_work(sc, sc-sc_keepalive_work);
sc_put(sc);
- sc-sc_sock-ops-shutdown(sc-sc_sock,
- RCV_SHUTDOWN|SEND_SHUTDOWN);
+ kernel_sock_shutdown(sc-sc_sock, SHUT_RDWR);
}
/* not fatal so failed connects before the other guy has our
diff --git a/include/linux/net.h b/include/linux/net.h
index dd79cdb..596131e 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -95,6 +95,12 @@ enum sock_type {
#endif /* ARCH_HAS_SOCKET_TYPES */
+enum sock_shutdown_cmd {
+ SHUT_RD = 0,
+ SHUT_WR = 1,
+ SHUT_RDWR = 2,
+};
+
/**
* struct socket - general BSD socket
* @state: socket state (%SS_CONNECTED, etc)
@@ -223,6 +229,8 @@ extern int kernel_setsockopt(struct socket *sock, int
level, int optname,
extern int kernel_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags);
extern int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
+extern int kernel_sock_shutdown(struct socket *sock,
+ enum sock_shutdown_cmd how);
#ifndef CONFIG_SMP
#define SOCKOPS_WRAPPED(name) name
diff --git a/net/rxrpc/ar-local.c b/net/rxrpc/ar-local.c
index fe03f71..f3a2bd7 100644
--- a/net/rxrpc/ar-local.c
+++ b/net/rxrpc/ar-local.c
@@ -114,7 +114,7 @@ static int rxrpc_create_local(struct
Re: [Bugme-new] [Bug 9349] New: RTNLGRP_ND_USEROPT does not report ifindex
On Sun, 11 Nov 2007 10:52:41 -0800 (PST) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9349
Summary: RTNLGRP_ND_USEROPT does not report ifindex
Product: Networking
Version: 2.5
KernelVersion: 2.6.24-rc
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV6
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Most recent kernel where this bug did not occur: none
Distribution: N/A
Hardware Environment: any
Software Environment: any
Problem Description:
The RTNLGRP_ND_USEROPT NetLink message introduced in 2.6.24 does not seem to
include any information as to which netif the user options come from:
struct nduseroptmsg
{
unsigned char nduseropt_family;
unsigned char nduseropt_pad1;
unsigned short nduseropt_opts_len; /* Total length of options */
__u8nduseropt_icmp_type;
__u8nduseropt_icmp_code;
unsigned short nduseropt_pad2;
/* Followed by one or more ND options */
};
Considering this is meant to carry data that is heavily link-layer involved,
this seems like a feature bug. Could an ifindex field be added there??
-
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] NET: Add the helper kernel_sock_shutdown()
On Sun, Nov 11, 2007 at 01:40:14PM -0500, Trond Myklebust wrote: On Sun, 2007-11-11 at 10:03 -0800, Mark Fasheh wrote: That looks pretty good - any objection to naming the enum and using that name in the prototype for kernel_sock_shutdown() so it's even more obvious what type of shutdown argument this expects? That would be fine by me. How about the attached patch? Looks good to me, thanks! Acked-by: Mark Fasheh [EMAIL PROTECTED] --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - 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 : Oops preceded by WARNING: at net/ipv4/tcp_input.c:1571 tcp_remove_reno_sacks()
On Sun, 11 Nov 2007, Chazarain Guillaume wrote: Do you have GSO enabled? According to ethtool -k, no. Ok, thanks, it excludes lot of possibilities... Is this reproducable? Unfortunately not, I saw it only once. The messages you had in the other mail are very likely symptom of the same problem, it's just hard to tell from them where it really originates from (because it would requires expensive verification that nobody wants to do by default after simple operations). In many cases that WARN_ON is simply too late to tell when the problem causing adjustment/corruption occurred but it's still better than nothing as a starting point :-). You can try to provoke it by setting tcp_sack sysctl to 0 as this seems to be non-SACK related... If so, you could try the debug patch below # CONFIG_DEBUG_LIST is not set I'm currently running bittorrent with all of this, I just saw this (for the first time ever), but otherwise it works fine: WARNING: at net/ipv4/tcp_output.c:1807 tcp_simple_retransmit() [c0104cb3] show_trace_log_lvl+0x1a/0x2f [c0105563] show_trace+0x12/0x14 [c0105668] dump_stack+0x15/0x17 [c02f6a79] tcp_simple_retransmit+0xfa/0x185 [c02fa072] tcp_v4_err+0x35d/0x4cb [c0301f7d] icmp_unreach+0x327/0x352 Hmm, that's related to path MTU things... It might have something to do with this... I'm not at all sure how it handles pcounts... Have you run memtest recently? Just ran it with no errors for 6 minutes 30. The box is otherwise stable though. Yeah, it's more likely a miscount somewhere rather than corruption but that wasn't obvious from the first mail... ...but alas, I haven't yet been able to come up with any theory on how a miscount could occur I forgot to say that I have a kdump image of the crash (I had to recompile this 2.6.24-rc2 kernel as I deleted its vmlinux), so I could check that you are right on track with your assertions at the time of the crash. +if (WARN_ON(tcp_write_queue_head(sk) == NULL)) +return; (gdb) p sk-sk_write_queue.next $11 = (struct sk_buff *) 0xe43a04b0 (gdb) p sk-sk_write_queue $12 = (struct sk_buff_head *) 0xe43a04b0 +if (WARN_ON(!tp-packets_out)) +return; (gdb) p ((struct tcp_sock *) sk)-packets_out $13 = 0 Yeah, they are expected, the write_queue is empty. Another cause for those could have been corrupted write_queue (that's why I asked for the list debugging). +if (tp-lost_out tp-packets_out) +printk(KERN_ERR Lost underflowed to %u\n, tp-lost_out); (gdb) p ((struct tcp_sock *) sk)-lost_out $14 = 4294967295 Underflows by one. ...We should just find out what causes this and fix that and we're done with it. :-) Some more gdb output for information: Thanks about them, though they're not that useful because the problem occurred prior to its detection... :-) My naive attempt at understanding what's going on: My oops starts with: BUG: unable to handle kernel NULL pointer dereference at virtual address 0045 gdb tells me the crash is in: #0 tcp_xmit_retransmit_queue (sk=0xe43a0440) at net/ipv4/tcp_output.c:1962 1962__u8 sacked = TCP_SKB_CB(skb)-sacked; (gdb) p ((struct tcp_skb_cb *)((struct sk_buff *)0)-cb)-sacked Cannot access memory at address 0x45 A 0x45 offset is definitely a -sacked on a null skb, but: This is right. (gdb) p skb $5 = (struct sk_buff *) 0xe43a04b0 which is sk-sk_write_queue so I don't understand why the tcp_for_write_queue_from made an iteration. I don't know if gdb is playing tricks or if it's because I had to recompile the crashing kernel. No, it won't happen like that. ...I'd say that gdb is just confused. In case packets_out is zero (it occurs after a cumulative ACK only), for sure skb will become NULL because the retransmit_skb_hint was cleared due to cumulative ACK. The crash location is the expected one in case packets_out gets zero during recovery and lost_out is miscounted/corrupt, as your dump shows. Anyway, thanks for digging these out. Here's a bruteforce patch below... Since you had couple of them during your overnight test, I'm sure it's relatively easy to catch... The first place where the tcp_verify_lost is triggered is the most interesting, rest are likely ripples due to that earlier corruption... (Hopefully I've placed them this time to places where both queue and lost_out states should agree, once did similar patch that had incorrectly placed some verification calls which caused lot of spurious stacktraces :-)) ...I left those !packets_out things there to prevent crashing when it occurs though it's not the main problem itself. Please keep the tcp_sack set to 0, and once you have at least one stacktrace with it, you could try also with tcp_sack if the same thing occurs there as well. -- [PATCH] TCP DEBUG - Check if empty queue is passed to xmit_retrans... - Print lost_out underflow value - Track lost_out and LOST
[PATCH] Fix memory leak in discard case of sctp_sf_abort_violation()
From: Jesper Juhl [EMAIL PROTECTED]
In net/sctp/sm_statefuns.c::sctp_sf_abort_violation() we may leak
the storage allocated for 'abort' by returning from the function
without using or freeing it. This happens in case
sctp_auth_recv_cid(SCTP_CID_ABORT, asoc) is true and we jump to
the 'discard' label.
Spotted by the Coverity checker.
The simple fix is to simply move the creation of the abort chunk
to after the possible jump to the 'discard' label. This way we don't
even have to allocate the memory at all in the problem case.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
sm_statefuns.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index f01b408..4c5c5e7 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -4064,11 +4064,6 @@ static sctp_disposition_t sctp_sf_abort_violation(
struct sctp_chunk *chunk = arg;
struct sctp_chunk *abort = NULL;
- /* Make the abort chunk. */
- abort = sctp_make_abort_violation(asoc, chunk, payload, paylen);
- if (!abort)
- goto nomem;
-
/* SCTP-AUTH, Section 6.3:
*It should be noted that if the receiver wants to tear
*down an association in an authenticated way only, the
@@ -4083,6 +4078,11 @@ static sctp_disposition_t sctp_sf_abort_violation(
if (sctp_auth_recv_cid(SCTP_CID_ABORT, asoc))
goto discard;
+ /* Make the abort chunk. */
+ abort = sctp_make_abort_violation(asoc, chunk, payload, paylen);
+ if (!abort)
+ goto nomem;
+
if (asoc) {
sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
-
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] - in.h - IP4_ADDR
Add inline functions to in.h that make the IP4 address tests
a bit easier to read and also add some type safety.
gcc optimizes IP4_ADDR to a constant (O2 or Os)
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
include/linux/in.h | 75 ---
1 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/include/linux/in.h b/include/linux/in.h
index 3975cbf..17d1878 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -247,11 +247,76 @@ struct sockaddr_in {
#ifdef __KERNEL__
/* Some random defines to make it easier in the kernel.. */
-#define LOOPBACK(x)(((x) htonl(0xff00)) == htonl(0x7f00))
-#define MULTICAST(x) (((x) htonl(0xf000)) == htonl(0xe000))
-#define BADCLASS(x)(((x) htonl(0xf000)) == htonl(0xf000))
-#define ZERONET(x) (((x) htonl(0xff00)) == htonl(0x))
-#define LOCAL_MCAST(x) (((x) htonl(0xFF00)) == htonl(0xE000))
+
+static inline __be32 IP4_ADDR(unsigned char a, unsigned char b, unsigned char
c, unsigned char d)
+{
+ return htonl__u32)(a 0xff)) 24) |
+(((__u32)(b 0xff)) 16) |
+(((__u32)(c 0xff)) 8) |
+(((__u32)(d 0xff)) 0));
+}
+
+static inline bool LOOPBACK(__be32 x)
+{
+ return (x IP4_ADDR(255,0,0,0)) == IP4_ADDR(127,0,0,0);
+}
+
+static inline bool MULTICAST(__be32 x)
+{
+ return (x IP4_ADDR(240,0,0,0)) == IP4_ADDR(224,0,0,0);
+}
+
+static inline bool BADCLASS(__be32 x)
+{
+ return (x IP4_ADDR(240,0,0,0)) == IP4_ADDR(240,0,0,0);
+}
+
+static inline bool ZERONET(__be32 x)
+{
+ return (x IP4_ADDR(255,0,0,0)) == IP4_ADDR(0,0,0,0);
+}
+
+static inline bool LOCAL_MCAST(__be32 x)
+{
+ return (x IP4_ADDR(255,255,255,0)) == IP4_ADDR(224,0,0,0);
+}
+
+/* Special-Use IPv4 Addresses (RFC3330) */
+
+static inline bool PRIVATE_10(__be32 x)
+{
+ return (x IP4_ADDR(255,0,0,0)) == IP4_ADDR(10,0,0,0);
+}
+
+static inline bool PRIVATE_172(__be32 x)
+{
+ return (x IP4_ADDR(255,240,0,0)) == IP4_ADDR(172,16,0,0);
+}
+
+static inline bool PRIVATE_192(__be32 x)
+{
+ return (x IP4_ADDR(255,255,0,0)) == IP4_ADDR(192,168,0,0);
+}
+
+static inline bool TEST_192(__be32 x)
+{
+ return (x IP4_ADDR(255,255,255,0)) == IP4_ADDR(192,0,2,0);
+}
+
+static inline bool TEST_198(__be32 x)
+{
+ return (x IP4_ADDR(255,254,0,0)) == IP4_ADDR(198,18,0,0);
+}
+
+static inline bool ANYCAST_6TO4(__be32 x)
+{
+ return (x IP4_ADDR(255,255,255,0)) == IP4_ADDR(192,88,99,0);
+}
+
+static inline bool LINK_169(__be32 x)
+{
+ return (x IP4_ADDR(255,255,0,0)) == IP4_ADDR(169,254,0,0);
+}
#endif
-
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 patch] net/ipv4/ipvs/: remove unused exports
On Sun, Nov 11, 2007 at 04:09:40PM +0900, Simon Horman wrote: On Sun, Nov 11, 2007 at 07:48:40AM +0100, Adrian Bunk wrote: This patch removes the following unused EXPORT_SYMBOL's: - ip_vs_try_bind_dest - ip_vs_find_dest Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Looks fine to me. Should Dave Miller put this in his tree, or do you want to handle it a different way? ... If Dave applies it that would be perfect. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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
