[patch 1/2] ipvs: Bind connections on stanby if the destination exists
Find destination by {daddr,dport,vaddr,protocol}
+ * Cretaed to be used in ip_vs_process_message() in
+ * the backup synchronization daemon. It finds the
+ * destination to be bound to the received connection
+ * on the backup.
+ *
+ * ip_vs_lookup_real_service() looked promissing, but
+ * seems not working as expected.
+ */
+struct ip_vs_dest *ip_vs_find_dest(__be32 daddr, __be16 dport,
+ __be32 vaddr, __be16 vport, __u16 protocol)
+{
+ struct ip_vs_dest *dest;
+ struct ip_vs_service *svc;
+
+ svc = ip_vs_service_get(0, protocol, vaddr, vport);
+ if (!svc)
+ return NULL;
+ dest = ip_vs_lookup_dest(svc, daddr, dport);
+ if (dest)
+ atomic_inc(&dest->refcnt);
+ ip_vs_service_put(svc);
+ return dest;
+}
+EXPORT_SYMBOL(ip_vs_find_dest);
/*
* Lookup dest by {svc,addr,port} in the destination trash.
Index: net-2.6/net/ipv4/ipvs/ip_vs_sync.c
===
--- net-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2007-11-05 11:23:58.0
+0900
+++ net-2.6/net/ipv4/ipvs/ip_vs_sync.c 2007-11-05 11:26:16.0 +0900
@@ -284,6 +284,7 @@ static void ip_vs_process_message(const
struct ip_vs_sync_conn_options *opt;
struct ip_vs_conn *cp;
struct ip_vs_protocol *pp;
+ struct ip_vs_dest *dest;
char *p;
int i;
@@ -317,20 +318,35 @@ static void ip_vs_process_message(const
s->caddr, s->cport,
s->vaddr, s->vport);
if (!cp) {
+ /*
+* Find the appropriate destination for the connection.
+* If it is not found the connection will remain unbound
+* but still handled.
+*/
+ dest = ip_vs_find_dest(s->daddr, s->dport,
+ s->vaddr, s->vport,
+ s->protocol);
cp = ip_vs_conn_new(s->protocol,
s->caddr, s->cport,
s->vaddr, s->vport,
s->daddr, s->dport,
- flags, NULL);
+ flags, dest);
+ if (dest)
+ atomic_dec(&dest->refcnt);
if (!cp) {
IP_VS_ERR("ip_vs_conn_new failed\n");
return;
}
cp->state = ntohs(s->state);
} else if (!cp->dest) {
- /* it is an entry created by the synchronization */
- cp->state = ntohs(s->state);
- cp->flags = flags | IP_VS_CONN_F_HASHED;
+ dest = ip_vs_try_bind_dest(cp);
+ if (!dest) {
+ /* it is an unbound entry created by
+* synchronization */
+ cp->state = ntohs(s->state);
+ cp->flags = flags | IP_VS_CONN_F_HASHED;
+ } else
+ atomic_dec(&dest->refcnt);
} /* Note that we don't touch its state and flags
if it is a normal entry. */
--
--
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
[patch 0/2] ipvs: avoid overcommit on the standby, take III
Two related patches from Rumen G. Bogdanovski to help prevent overcommit on the standby. On the last two attempts I have managed to send somewhat bogus patches. So I started from scratch. I tool the original patches, fixed up what scripts/checkpatch.pl didn't like, then compared the output to my previous attempt, which happily showed the bogus bits that I know about have been fixed. -- -- 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
[patch 2/2] ipvs: Syncrhonise Closing of Connections
From: Rumen G. Bogdanovski <[EMAIL PROTECTED]>
This patch makes the master daemon to sync the connection when it is about
to close. This makes the connections on the backup to close or timeout
according their state. Before the sync was performed only if the
connection is in ESTABLISHED state which always made the connections to
timeout in the hard coded 3 minutes. However the Andy Gospodarek's patch
([IPVS]: use proper timeout instead of fixed value) effectively did nothing
more than increasing this to 15 minutes (Established state timeout). So
this patch makes use of proper timeout since it syncs the connections on
status changes to FIN_WAIT (2min timeout) and CLOSE (10sec timeout).
However if the backup misses CLOSE hopefully it did not miss FIN_WAIT.
Otherwise we will just have to wait for the ESTABLISHED state timeout. As
it is without this patch. This way the number of the hanging connections
on the backup is kept to minimum. And very few of them will be left to
timeout with a long timeout.
This is important if we want to make use of the fix for the real server
overcommit on master/backup fail-over.
Regards,
Rumen Bogdanovski
Signed-off-by: Rumen G. Bogdanovski <[EMAIL PROTECTED]>
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
---
Thu, 01 Nov 2007 18:25:10 +0900, Horms
* Redifed for net-2.6
* Ran through scripts/checkpatch.pl and fixed up everything
that it complains about except the use of volatile, as
its in keeping with other fields in the structure.
If its wrong, lets fix them all together.
WARNING: Use of volatile is usually wrong: see
Documentation/volatile-considered-harmful.txt
#49: FILE: include/net/ip_vs.h:523:
+ volatile __u16 old_state; /* old state, to be used for
Index: net-2.6/include/net/ip_vs.h
===
--- net-2.6.orig/include/net/ip_vs.h2007-11-05 11:37:45.0 +0900
+++ net-2.6/include/net/ip_vs.h 2007-11-05 11:37:49.0 +0900
@@ -520,6 +520,10 @@ struct ip_vs_conn {
spinlock_t lock; /* lock for state transition */
volatile __u16 flags; /* status flags */
volatile __u16 state; /* state info */
+ volatile __u16 old_state; /* old state, to be used for
+* state transition triggerd
+* synchronization
+*/
/* Control members */
struct ip_vs_conn *control; /* Master control connection */
Index: net-2.6/net/ipv4/ipvs/ip_vs_core.c
===
--- net-2.6.orig/net/ipv4/ipvs/ip_vs_core.c 2007-11-05 11:37:45.0
+0900
+++ net-2.6/net/ipv4/ipvs/ip_vs_core.c 2007-11-05 11:37:49.0 +0900
@@ -979,15 +979,23 @@ ip_vs_in(unsigned int hooknum, struct sk
ret = NF_ACCEPT;
}
- /* increase its packet counter and check if it is needed
- to be synchronized */
+ /* Increase its packet counter and check if it is needed
+* to be synchronized
+*
+* Sync connection if it is about to close to
+* encorage the standby servers to update the connections timeout
+*/
atomic_inc(&cp->in_pkts);
if ((ip_vs_sync_state & IP_VS_STATE_MASTER) &&
- (cp->protocol != IPPROTO_TCP ||
-cp->state == IP_VS_TCP_S_ESTABLISHED) &&
- (atomic_read(&cp->in_pkts) % sysctl_ip_vs_sync_threshold[1]
-== sysctl_ip_vs_sync_threshold[0]))
+ (((cp->protocol != IPPROTO_TCP ||
+ cp->state == IP_VS_TCP_S_ESTABLISHED) &&
+ (atomic_read(&cp->in_pkts) % sysctl_ip_vs_sync_threshold[1]
+ == sysctl_ip_vs_sync_threshold[0])) ||
+((cp->protocol == IPPROTO_TCP) && (cp->old_state != cp->state) &&
+ ((cp->state == IP_VS_TCP_S_FIN_WAIT) ||
+ (cp->state == IP_VS_TCP_S_CLOSE)
ip_vs_sync_conn(cp);
+ cp->old_state = cp->state;
ip_vs_conn_put(cp);
return ret;
Index: net-2.6/net/ipv4/ipvs/ip_vs_sync.c
===
--- net-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2007-11-05 11:37:45.0
+0900
+++ net-2.6/net/ipv4/ipvs/ip_vs_sync.c 2007-11-05 11:37:49.0 +0900
@@ -344,7 +344,6 @@ static void ip_vs_process_message(const
if (!dest) {
/* it is an unbound entry created by
* synchronization */
- cp->state = ntohs(s->state);
cp->flags = flags | IP_VS_CONN_F_HASHED;
Re: [patch] ipvs: force read of atomic_t in while loop
On Wed, Aug 08, 2007 at 11:33:00AM +0200, Heiko Carstens wrote:
> From: Heiko Carstens <[EMAIL PROTECTED]>
>
> For architectures that don't have a volatile atomic_ts constructs like
> while (atomic_read(&something)); might result in endless loops since a
> barrier() is missing which forces the compiler to generate code that
> actually reads memory contents.
> Fix this in ipvs by using the IP_VS_WAIT_WHILE macro which resolves to
> while (expr) { cpu_relax(); }
> (why isn't this open coded btw?)
>
> Cc: Wensong Zhang <[EMAIL PROTECTED]>
> Cc: Simon Horman <[EMAIL PROTECTED]>
> Cc: David Miller <[EMAIL PROTECTED]>
> Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
> ---
>
> Just saw this while grepping for atomic_reads in a while loops.
> Maybe we should re-add the volatile to atomic_t. Not sure.
This looks good to me. A little wile back I noticed a few places
where IP_VS_WAIT_WHILE seemed to be curiously unused, then I got
distracted...
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
>
> net/ipv4/ipvs/ip_vs_ctl.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
> ===
> --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ctl.c
> +++ linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
> @@ -909,7 +909,7 @@ ip_vs_edit_dest(struct ip_vs_service *sv
> write_lock_bh(&__ip_vs_svc_lock);
>
> /* Wait until all other svc users go away */
> - while (atomic_read(&svc->usecnt) > 1) {};
> + IP_VS_WAIT_WHILE(atomic_read(&svc->usecnt) > 1);
>
> /* call the update_service, because server weight may be changed */
> svc->scheduler->update_service(svc);
--
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
Re: [ipvs] BUG: soft lockup detected on CPU#3!
On Mon, May 28, 2007 at 04:20:32PM +0200, Sebastien Estienne wrote:
> On 5/28/07, Horms <[EMAIL PROTECTED]> wrote:
> >On Sat, May 26, 2007 at 11:22:40AM +0900, Horms wrote:
> >> On Fri, May 25, 2007 at 09:30:52AM +, Sebastien Estienne wrote:
> >> >
> >> > I didn't try 2.6.21 yet, but using ubuntu dapper kernel (2.6.15) i
> >> > can't reproduce the bug.
> >> > When i was using feisty kernel (2.6.20), i can reproduce in less than 5
> >> > minutes.
> >> >
> >> > I'm using lvs to loadbalance some mysql servers, i wrote a deamon that
> >> > check the synchro of the mysql replication on each slave and adjust
> >> > the wieght on the lvs every 500ms
> >>
> >> It does look a lot like there is some sort of locking problem in there.
> >> Would it be possible to send your kernel config, as the locking
> >> deatails to change a little with different configs.
> >
>
> About the kernel .config, i'm using the vanilla kernel "-server" from
> ubuntu feisty
>
> >If you also have some details of you ipvs configuration,
> >that might help narrow down which code-paths to investigate.
> >
>
> i attached the output of ipvsadm-save
>
> i'm adjusting the weight every 500ms by generating lines like this:
> -e -t 10.33.1.231:3306 -r 10.33.1.1 -w 100
Thanks.
> and piping all the needed changes in ipvadm -R
>
> it can represent something like 20 to 40 updates in one time.
>
> i also noticed that sometimes when i execute "ipvsadm" the display get
> locked in the middle for a second and then finish.
That is probably related. Though the fact that it eventually
exits seems to indicate that you're not hitting II.
> >II.
> >
> >ip_vs_set_ctl() does seem to leak svc->usecnt in one corner case,
> >but I doubt that is what you are seeing - if it was your ipvsadm
> >command(s) would hang. The problem is a bit wordy to describe,
> >but this fix should illustrate the problem.
> >
> >--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ctl.c
> >+++ linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
> >@@ -2000,7 +2000,7 @@ do_ip_vs_set_ctl(struct sock *sk, int cm
> >if (cmd != IP_VS_SO_SET_ADD
> >&& (svc == NULL || svc->protocol != usvc->protocol)) {
> >ret = -ESRCH;
> >- goto out_unlock;
> >+ goto out_svc;
> >}
> >
> >switch (cmd) {
> >@@ -2034,9 +2034,9 @@ do_ip_vs_set_ctl(struct sock *sk, int cm
> >ret = -EINVAL;
> >}
> >
> >+ out_svc:
> >if (svc)
> >ip_vs_service_put(svc);
> >-
> > out_unlock:
> >mutex_unlock(&__ip_vs_mutex);
> > out_dec:
--
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
Re: [ipvs] BUG: soft lockup detected on CPU#3!
On Sat, May 26, 2007 at 11:22:40AM +0900, Horms wrote:
> On Fri, May 25, 2007 at 09:30:52AM +, Sebastien Estienne wrote:
> >
> > I didn't try 2.6.21 yet, but using ubuntu dapper kernel (2.6.15) i
> > can't reproduce the bug.
> > When i was using feisty kernel (2.6.20), i can reproduce in less than 5
> > minutes.
> >
> > I'm using lvs to loadbalance some mysql servers, i wrote a deamon that
> > check the synchro of the mysql replication on each slave and adjust
> > the wieght on the lvs every 500ms
>
> It does look a lot like there is some sort of locking problem in there.
> Would it be possible to send your kernel config, as the locking
> deatails to change a little with different configs.
If you also have some details of you ipvs configuration,
that might help narrow down which code-paths to investigate.
I spent some time this afternoon looking into this probem,
and what I think is happening is:
1. Due to your weight-update operations, one processor
is sitting in ip_vs_edit_dest() called by do_ip_vs_set_ctl(),
holding write_lock_bh(&__ip_vs_svc_lock) and waiting
for svc->usecnt to go down to 1.
2. Another process is trying to grab
read_lock(&__ip_vs_svc_lock) in ip_vs_service_get(),
called from tcp_conn_schedule() and in turn ip_vs_in().
I guess that for some reason svc->usecnt isn't going down to 0.
Though I haven't been able to isolate anything particularly
interesting.
That said, the locking isn't that simple, IMHO, so there seems
to be quite a lot of scope for errors.
Some things that are of minor insterst are:
I.
ip_vs_edit_dest() loops with the following construct:
while (atomic_read(&svc->usecnt) > 1) {};
whereas similar code in the same file uses
IP_VS_WAIT_WHILE(atomic_read(&svc->usecnt) > 1);
which expands to
while (atomic_read(&svc->usecnt) > 1) { cpu_relax(); }
But I dount this is a problem, except for burning the cpu a bit harder
than it needs to.
II.
ip_vs_set_ctl() does seem to leak svc->usecnt in one corner case,
but I doubt that is what you are seeing - if it was your ipvsadm
command(s) would hang. The problem is a bit wordy to describe,
but this fix should illustrate the problem.
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ctl.c
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
@@ -2000,7 +2000,7 @@ do_ip_vs_set_ctl(struct sock *sk, int cm
if (cmd != IP_VS_SO_SET_ADD
&& (svc == NULL || svc->protocol != usvc->protocol)) {
ret = -ESRCH;
- goto out_unlock;
+ goto out_svc;
}
switch (cmd) {
@@ -2034,9 +2034,9 @@ do_ip_vs_set_ctl(struct sock *sk, int cm
ret = -EINVAL;
}
+ out_svc:
if (svc)
ip_vs_service_put(svc);
-
out_unlock:
mutex_unlock(&__ip_vs_mutex);
out_dec:
III.
Perhaps if you are calling ipvsadm a lot then there is a remote
possibility that write_lock_bh() could starve read_lock(). This
seems ludicrous, but I'm just mentioning it as it crossed my mind.
--
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
Re: [ipvs] BUG: soft lockup detected on CPU#3!
On Fri, May 25, 2007 at 09:30:52AM +, Sebastien Estienne wrote: > > I didn't try 2.6.21 yet, but using ubuntu dapper kernel (2.6.15) i > can't reproduce the bug. > When i was using feisty kernel (2.6.20), i can reproduce in less than 5 > minutes. > > I'm using lvs to loadbalance some mysql servers, i wrote a deamon that > check the synchro of the mysql replication on each slave and adjust > the wieght on the lvs every 500ms It does look a lot like there is some sort of locking problem in there. Would it be possible to send your kernel config, as the locking deatails to change a little with different configs. -- 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
Re: [ipvs] BUG: soft lockup detected on CPU#3!
[Adding netdev CC] On Tue, May 22, 2007 at 07:19:44PM +0200, Sebastien Estienne wrote: > Hello, > > I have the following bug (stacktrace in the attachment) and i think > it's related to ipvs, i reproduced it many time. > > kernel is from ubuntu: "2.6.20-15-server SMP x86_64" > on dell poweredge sc1425 > > i can trigger this bug when i adjust the weight of the real server > every 500ms using ipvsadm -R and piping the modifications > > there is 4 virtual server with 55 realserver each > > any idea? Not off hand. Though it does look some what unplesant :( I'll try my hand at trying to reproduce the problem. Is there any chance that you could try a vanilla (2.6.21) kernel to see if the problem exists there too? > > regards, > -- > Sebastien Estienne > BUG: soft lockup detected on CPU#3! > > Call Trace: >[softlockup_tick+249/288] softlockup_tick+0xf9/0x120 > [update_process_times+87/144] update_process_times+0x57/0x90 > [smp_local_timer_interrupt+52/96] smp_local_timer_interrupt+0x34/0x60 > [smp_apic_timer_interrupt+89/128] smp_apic_timer_interrupt+0x59/0x80 > [apic_timer_interrupt+102/112] apic_timer_interrupt+0x66/0x70 >[_end+130125309/2130038908] :ip_vs:do_ip_vs_set_ctl+0xad1/0xbf0 > [_end+130125305/2130038908] :ip_vs:do_ip_vs_set_ctl+0xacd/0xbf0 > [nf_sockopt+233/304] nf_sockopt+0xe9/0x130 > [nf_setsockopt+22/32] nf_setsockopt+0x16/0x20 > [ip_setsockopt+118/160] ip_setsockopt+0x76/0xa0 > [sys_setsockopt+166/240] sys_setsockopt+0xa6/0xf0 > [system_call+126/131] system_call+0x7e/0x83 > > BUG: soft lockup detected on CPU#0! > > Call Trace: >[softlockup_tick+249/288] softlockup_tick+0xf9/0x120 > [update_process_times+87/144] update_process_times+0x57/0x90 > [smp_local_timer_interrupt+52/96] smp_local_timer_interrupt+0x34/0x60 > [smp_apic_timer_interrupt+89/128] smp_apic_timer_interrupt+0x59/0x80 > [_end+130330509/2130038908] :nf_conntrack:nf_ct_invert_tuple+0x51/0xa0 > [apic_timer_interrupt+102/112] apic_timer_interrupt+0x66/0x70 > [__read_lock_failed+5/32] __read_lock_failed+0x5/0x20 > [_read_lock+11/16] _read_lock+0xb/0x10 > [_end+130122092/2130038908] :ip_vs:ip_vs_service_get+0x20/0x1e0 > [_end+130144732/2130038908] :ip_vs:tcp_conn_schedule+0xa0/0x150 > [_end+130144313/2130038908] :ip_vs:tcp_conn_in_get+0x7d/0xc0 > [_end+130111414/2130038908] :ip_vs:ip_vs_in+0xca/0x270 > [nf_iterate+92/160] nf_iterate+0x5c/0xa0 > [ip_local_deliver_finish+0/528] ip_local_deliver_finish+0x0/0x210 > [nf_hook_slow+113/240] nf_hook_slow+0x71/0xf0 > [ip_local_deliver_finish+0/528] ip_local_deliver_finish+0x0/0x210 > [ip_local_deliver+111/656] ip_local_deliver+0x6f/0x290 > [ip_rcv+1246/1360] ip_rcv+0x4de/0x550 > [netif_receive_skb+623/800] netif_receive_skb+0x26f/0x320 > [_end+129188049/2130038908] :e1000:e1000_clean_rx_irq+0x445/0x520 > [_end+129183152/2130038908] :e1000:e1000_clean+0x84/0x2b0 > [net_rx_action+186/512] net_rx_action+0xba/0x200 > [__do_softirq+95/208] __do_softirq+0x5f/0xd0 > [call_softirq+28/40] call_softirq+0x1c/0x28 > [do_softirq+44/144] do_softirq+0x2c/0x90 > [do_IRQ+217/256] do_IRQ+0xd9/0x100 > [mwait_idle+0/80] mwait_idle+0x0/0x50 > [ret_from_intr+0/10] ret_from_intr+0x0/0xa >[tcp_poll+0/336] tcp_poll+0x0/0x150 > [mwait_idle+66/80] mwait_idle+0x42/0x50 > [cpu_idle+155/208] cpu_idle+0x9b/0xd0 > [start_kernel+586/608] start_kernel+0x24a/0x260 > [x86_64_start_kernel+358/368] _sinittext+0x166/0x170 > -- 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
[PATCH] LVS: Send ICMP unreachable responses to end-users when real-servers are removed
Hi,
this is a small patch by Janusz Krzysztofik to ip_route_output_slow()
that allows VIP-less LVS linux director to generate packets originating
>From VIP if sysctl_ip_nonlocal_bind is set.
In a nutshell, the intention is for an LVS linux director to be able
to send ICMP unreachable responses to end-users when real-servers are
removed.
http://archive.linuxvirtualserver.org/html/lvs-users/2007-01/msg00106.html
I'm not really sure about the correctness of this approach,
so I am sending it here to netdev for review
Cc: Janusz Krzysztofik <[EMAIL PROTECTED]>
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: net-2.6/net/ipv4/route.c
===
--- net-2.6.orig/net/ipv4/route.c 2007-02-11 11:46:08.0 +0900
+++ net-2.6/net/ipv4/route.c2007-02-11 11:46:23.0 +0900
@@ -2397,7 +2397,7 @@
/* It is equivalent to inet_addr_type(saddr) == RTN_LOCAL */
dev_out = ip_dev_find(oldflp->fl4_src);
- if (dev_out == NULL)
+ if ((dev_out == NULL) && !(sysctl_ip_nonlocal_bind))
goto out;
/* I removed check for oif == dev_out->oif here.
@@ -2408,7 +2408,7 @@
of another iface. --ANK
*/
- if (oldflp->oif == 0
+ if (dev_out && oldflp->oif == 0
&& (MULTICAST(oldflp->fl4_dst) || oldflp->fl4_dst ==
htonl(0x))) {
/* Special hack: user can direct multicasts
and limited broadcast via necessary interface
-
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] [IPVS] replace if .. goto with while
On Tue, Jan 02, 2007 at 12:38:39AM -0800, David Miller wrote: > From: Horms <[EMAIL PROTECTED]> > Date: Mon, 18 Dec 2006 12:11:11 +0900 > > > I guess that this code used to be more complex, but replacing > > the goto with a while seems to make things a bit more readable. > > Or in other words, two fairly gratuitous goto are removed. > > > > On a related note, I wonder if there should be a limit to how > > many times it tries. > > > > Signed-Off-By: Simon Horman <[EMAIL PROTECTED]> > > Yes, there should be, something like a limit of one. :-) > > There is no reason to loop on something like this, just > return a failure immediately if creating the kernel thread > fails. Will do. > As a side note, if it's easy you might want to convert this > over the the include/linux/kthread.h interfaces. I just did > this for pktgen tonight and it cleaned a lot of stuff up. Thanks, I will look into it. -- 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
[PATCH] [IPVS] replace if .. goto with while
I guess that this code used to be more complex, but replacing
the goto with a while seems to make things a bit more readable.
Or in other words, two fairly gratuitous goto are removed.
On a related note, I wonder if there should be a limit to how
many times it tries.
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_sync.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2006-11-29 09:50:37.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_sync.c2006-11-29 10:03:11.0
+0900
@@ -822,12 +822,10 @@
/* fork the sync thread here, then the parent process of the
sync thread is the init process after this thread exits. */
- repeat:
- if ((pid = kernel_thread(sync_thread, startup, 0)) < 0) {
+ while ((pid = kernel_thread(sync_thread, startup, 0)) < 0) {
IP_VS_ERR("could not create sync_thread due to %d... "
"retrying.\n", pid);
msleep_interruptible(1000);
- goto repeat;
}
return 0;
@@ -856,12 +854,10 @@
ip_vs_backup_syncid = syncid;
}
- repeat:
- if ((pid = kernel_thread(fork_sync_thread, &startup, 0)) < 0) {
+ while ((pid = kernel_thread(fork_sync_thread, &startup, 0)) < 0) {
IP_VS_ERR("could not create fork_sync_thread due to %d... "
"retrying.\n", pid);
msleep_interruptible(1000);
- goto repeat;
}
wait_for_completion(&startup);
-
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] [IPVS] transparent proxying
On Wed, Nov 29, 2006 at 11:46:22PM +0900, Horms wrote:
> On Wed, Nov 29, 2006 at 03:15:23PM +0100, Thomas Graf wrote:
[split]
> > This patch seems to be based on an old tree, I've renamed nfmark
> > to mark in net-2.6.20. The term fwmark and nfmark shouldn't be
> > used anymore.
>
> Sorry, I based this patch on Linus's tree. I'll port it to net-2.6.20.
This took too long for me to get around to :(
Am I correct in thinking I just need to replace fwmark with mark?
If so, the updated version is below.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
[IPVS] transparent proxying
Patch from home_king <[EMAIL PROTECTED]> to allow a web cluseter using
transparent proxying. It works by simply grabing packets that have the
fwmark set and have not already been processed by ipvs (ip_vs_out) and
throwing them into ip_vs_in.
See: http://archive.linuxvirtualserver.org/html/lvs-users/2006-11/msg00261.html
Normally LVS packets are processed by ip_vs_in fron on the INPUT chain,
and packets that are processed in this way never show up on the FORWARD
chain, so they won't hit this rule.
This patch seems like a good precursor to moving LVS permanantly to
the FORWARD chain. As I'm struggling to think how it could break things.
Reformated to use tabs for indentation (instead of 4 spaces)
Reformated to be < 80 columns wide
Updated fwmark to mark
Cc: Jinhua Luo <[EMAIL PROTECTED]>
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: net-2.6/net/ipv4/ipvs/ip_vs_core.c
===
--- net-2.6.orig/net/ipv4/ipvs/ip_vs_core.c 2006-12-18 11:46:10.0
+0900
+++ net-2.6/net/ipv4/ipvs/ip_vs_core.c 2006-12-18 12:13:32.0 +0900
@@ -23,7 +23,9 @@
* Changes:
* Paul `Rusty' Russellproperly handle non-linear skbs
* Harald Weltedon't use nfcache
- *
+ * Jinhua Luo redirect packets with fwmark on
+ * NF_IP_FORWARD chain to ip_vs_in(),
+ * mainly for transparent cache cluster
*/
#include
@@ -1070,6 +1072,26 @@
return ip_vs_in_icmp(pskb, &r, hooknum);
}
+/*
+ * This is hooked into the NF_IP_FORWARD. It catches
+ * packets that have not already been handled by ipvs (out)
+ * and have a fwmark set. This is to allow transparent proxying
+ * of fwmark virtual services.
+ *
+ * It will not process packets that are handled by ipvs (in)
+ * as they never traverse the NF_IP_FORWARD.
+ */
+static unsigned int
+ip_vs_forward_with_fwmark(unsigned int hooknum, struct sk_buff **pskb,
+ const struct net_device *in,
+ const struct net_device *out,
+ int (*okfn)(struct sk_buff *))
+{
+ if ((*pskb)->ipvs_property || ! (*pskb)->mark)
+ return NF_ACCEPT;
+
+ return ip_vs_in(hooknum, pskb, in, out, okfn);
+}
/* After packet filtering, forward packet through VS/DR, VS/TUN,
or VS/NAT(change destination), so that filtering rules can be
@@ -1082,6 +1104,16 @@
.priority = 100,
};
+/* Allow transparent proxying by fishing packets
+ * out of the forward chain. */
+static struct nf_hook_ops ip_vs_forward_with_fwmark_ops = {
+ .hook = ip_vs_forward_with_fwmark,
+ .owner = THIS_MODULE,
+ .pf = PF_INET,
+ .hooknum= NF_IP_FORWARD,
+ .priority = 101,
+};
+
/* After packet filtering, change source only for VS/NAT */
static struct nf_hook_ops ip_vs_out_ops = {
.hook = ip_vs_out,
@@ -1160,9 +1192,17 @@
goto cleanup_postroutingops;
}
+ ret = nf_register_hook(&ip_vs_forward_with_fwmark_ops);
+ if (ret < 0) {
+ IP_VS_ERR("can't register forward_with_fwmark hook.\n");
+ goto cleanup_forwardicmpops;
+ }
+
IP_VS_INFO("ipvs loaded.\n");
return ret;
+ cleanup_forwardicmpops:
+ nf_unregister_hook(&ip_vs_forward_icmp_ops);
cleanup_postroutingops:
nf_unregister_hook(&ip_vs_post_routing_ops);
cleanup_outops:
@@ -1182,6 +1222,7 @@
static void __exit ip_vs_cleanup(void)
{
+ nf_unregister_hook(&ip_vs_forward_with_fwmark_ops);
nf_unregister_hook(&ip_vs_forward_icmp_ops);
nf_unregister_hook(&ip_vs_post_routing_ops);
nf_unregister_hook(&ip_vs_out_ops);
-
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] [IPVS] transparent proxying
On Wed, Nov 29, 2006 at 03:15:23PM +0100, Thomas Graf wrote:
> * Horms <[EMAIL PROTECTED]> 2006-11-29 15:21
> > This seems to be a pretty clean solution to a real problem.
> >
> > Ultimately I would like to see IPVS move into the forward chain.
> > This seems to be a nice way to explore that, without breaking
> > any existing setups.
> >
> > --
> > Horms
> > H: http://www.vergenet.net/~horms/
> > W: http://www.valinux.co.jp/en/
> >
> > [IPVS] transparent proxying
> >
> > Patch from Jinhua Luo <[EMAIL PROTECTED]> to allow a web cluseter using
> > transparent proxying. It works by simply grabing packets that have the
> > fwmark set and have not already been processed by ipvs (ip_vs_out) and
> > throwing them into ip_vs_in.
> >
> > See:
> > http://archive.linuxvirtualserver.org/html/lvs-users/2006-11/msg00261.html
> >
> > Normally LVS packets are processed by ip_vs_in fron on the INPUT chain,
> > and packets that are processed in this way never show up on the FORWARD
> > chain, so they won't hit this rule.
> >
> > This patch seems like a good precursor to moving LVS permanantly to
> > the FORWARD chain. As I'm struggling to think how it could break things.
> >
> > The changes to the original patch are:
> >
> > * Reformated to use tabs for indentation (instead of 4 spaces)
> > * Reformated to be < 80 columns wide
> > * Added some comments
> > * Rewrote description (this text)
> >
> > Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
> > Signed-off-by: Jinhua Luo <[EMAIL PROTECTED]>
> >
> > Index: linux-2.6/net/ipv4/ipvs/ip_vs_core.c
> > ===
> > --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_core.c 2006-11-28
> > 15:30:00.0 +0900
> > +++ linux-2.6/net/ipv4/ipvs/ip_vs_core.c2006-11-29 10:27:49.0
> > +0900
> > @@ -23,7 +23,9 @@
> > * Changes:
> > * Paul `Rusty' Russellproperly handle non-linear skbs
> > * Harald Weltedon't use nfcache
> > - *
> > + * Jinhua Luo redirect packets with fwmark on
> > + * NF_IP_FORWARD chain to ip_vs_in(),
> > + * mainly for transparent cache cluster
> > */
> >
> > #include
> > @@ -1070,6 +1072,26 @@
> > return ip_vs_in_icmp(pskb, &r, hooknum);
> > }
> >
> > +/*
> > + * This is hooked into the NF_IP_FORWARD. It catches
> > + * packets that have not already been handled by ipvs (out)
> > + * and have a fwmark set. This is to allow transparent proxying
> > + * of fwmark virtual services.
> > + *
> > + * It will not process packets that are handled by ipvs (in)
> > + * as they never traverse the NF_IP_FORWARD.
> > + */
> > +static unsigned int
> > +ip_vs_forward_with_fwmark(unsigned int hooknum, struct sk_buff **pskb,
> > + const struct net_device *in,
> > + const struct net_device *out,
> > + int (*okfn)(struct sk_buff *))
> > +{
> > + if ((*pskb)->ipvs_property || ! (*pskb)->nfmark)
> > + return NF_ACCEPT;
>
> This patch seems to be based on an old tree, I've renamed nfmark
> to mark in net-2.6.20. The term fwmark and nfmark shouldn't be
> used anymore.
Sorry, I based this patch on Linus's tree. I'll port it to net-2.6.20.
--
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
[PATCH] [IPVS] transparent proxying
This seems to be a pretty clean solution to a real problem.
Ultimately I would like to see IPVS move into the forward chain.
This seems to be a nice way to explore that, without breaking
any existing setups.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
[IPVS] transparent proxying
Patch from Jinhua Luo <[EMAIL PROTECTED]> to allow a web cluseter using
transparent proxying. It works by simply grabing packets that have the
fwmark set and have not already been processed by ipvs (ip_vs_out) and
throwing them into ip_vs_in.
See: http://archive.linuxvirtualserver.org/html/lvs-users/2006-11/msg00261.html
Normally LVS packets are processed by ip_vs_in fron on the INPUT chain,
and packets that are processed in this way never show up on the FORWARD
chain, so they won't hit this rule.
This patch seems like a good precursor to moving LVS permanantly to
the FORWARD chain. As I'm struggling to think how it could break things.
The changes to the original patch are:
* Reformated to use tabs for indentation (instead of 4 spaces)
* Reformated to be < 80 columns wide
* Added some comments
* Rewrote description (this text)
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Signed-off-by: Jinhua Luo <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_core.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_core.c 2006-11-28 15:30:00.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_core.c2006-11-29 10:27:49.0
+0900
@@ -23,7 +23,9 @@
* Changes:
* Paul `Rusty' Russellproperly handle non-linear skbs
* Harald Weltedon't use nfcache
- *
+ * Jinhua Luo redirect packets with fwmark on
+ * NF_IP_FORWARD chain to ip_vs_in(),
+ * mainly for transparent cache cluster
*/
#include
@@ -1070,6 +1072,26 @@
return ip_vs_in_icmp(pskb, &r, hooknum);
}
+/*
+ * This is hooked into the NF_IP_FORWARD. It catches
+ * packets that have not already been handled by ipvs (out)
+ * and have a fwmark set. This is to allow transparent proxying
+ * of fwmark virtual services.
+ *
+ * It will not process packets that are handled by ipvs (in)
+ * as they never traverse the NF_IP_FORWARD.
+ */
+static unsigned int
+ip_vs_forward_with_fwmark(unsigned int hooknum, struct sk_buff **pskb,
+ const struct net_device *in,
+ const struct net_device *out,
+ int (*okfn)(struct sk_buff *))
+{
+ if ((*pskb)->ipvs_property || ! (*pskb)->nfmark)
+ return NF_ACCEPT;
+
+ return ip_vs_in(hooknum, pskb, in, out, okfn);
+}
/* After packet filtering, forward packet through VS/DR, VS/TUN,
or VS/NAT(change destination), so that filtering rules can be
@@ -1082,6 +1104,16 @@
.priority = 100,
};
+/* Allow transparent proxying by fishing packets
+ * out of the forward chain. */
+static struct nf_hook_ops ip_vs_forward_with_fwmark_ops = {
+ .hook = ip_vs_forward_with_fwmark,
+ .owner = THIS_MODULE,
+ .pf = PF_INET,
+ .hooknum= NF_IP_FORWARD,
+ .priority = 101,
+};
+
/* After packet filtering, change source only for VS/NAT */
static struct nf_hook_ops ip_vs_out_ops = {
.hook = ip_vs_out,
@@ -1160,9 +1192,17 @@
goto cleanup_postroutingops;
}
+ ret = nf_register_hook(&ip_vs_forward_with_fwmark_ops);
+ if (ret < 0) {
+ IP_VS_ERR("can't register forward_with_fwmark hook.\n");
+ goto cleanup_forwardicmpops;
+ }
+
IP_VS_INFO("ipvs loaded.\n");
return ret;
+ cleanup_forwardicmpops:
+ nf_unregister_hook(&ip_vs_forward_icmp_ops);
cleanup_postroutingops:
nf_unregister_hook(&ip_vs_post_routing_ops);
cleanup_outops:
@@ -1182,6 +1222,7 @@
static void __exit ip_vs_cleanup(void)
{
+ nf_unregister_hook(&ip_vs_forward_with_fwmark_ops);
nf_unregister_hook(&ip_vs_forward_icmp_ops);
nf_unregister_hook(&ip_vs_post_routing_ops);
nf_unregister_hook(&ip_vs_out_ops);
-
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
[IPVS] make ip_vs_sync.c <= 80col wide
Make ip_vs_sync.c <= 80col wide
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_sync.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2006-11-29 09:53:51.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_sync.c2006-11-29 09:54:52.0
+0900
@@ -847,10 +847,12 @@
ip_vs_sync_state |= state;
if (state == IP_VS_STATE_MASTER) {
- strlcpy(ip_vs_master_mcast_ifn, mcast_ifn,
sizeof(ip_vs_master_mcast_ifn));
+ strlcpy(ip_vs_master_mcast_ifn, mcast_ifn,
+ sizeof(ip_vs_master_mcast_ifn));
ip_vs_master_syncid = syncid;
} else {
- strlcpy(ip_vs_backup_mcast_ifn, mcast_ifn,
sizeof(ip_vs_backup_mcast_ifn));
+ strlcpy(ip_vs_backup_mcast_ifn, mcast_ifn,
+ sizeof(ip_vs_backup_mcast_ifn));
ip_vs_backup_syncid = syncid;
}
@@ -876,7 +878,8 @@
IP_VS_DBG(7, "%s: pid %d\n", __FUNCTION__, current->pid);
IP_VS_INFO("stopping sync thread %d ...\n",
- (state == IP_VS_STATE_MASTER) ? sync_master_pid :
sync_backup_pid);
+ (state == IP_VS_STATE_MASTER) ?
+ sync_master_pid : sync_backup_pid);
__set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(&stop_sync_wait, &wait);
-
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] [IPVS] use msleep_interruptable() instead of ssleep() aka msleep()
On Tue, Nov 28, 2006 at 10:35:01AM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 28 Nov 2006, Horms wrote:
>
> > Dean Manners notices that when an IPVS synchonisation daemons are
> > started the system load slowly climbs up to 1. This seems to be related
> > to the call to ssleep(1) (aka msleep(1000) in the main loop. Replacing
> > this with a call to msleep_interruptable() seems to make the problem go
> > away. Though I'm not sure that it is correct.
>
> The same is needed for sync_backup_loop
Good point. It also seems as well to change it in fork_sync_thread()
and start_sync_thread(), though these are unlikely to be causing a problem.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
Dean Manners notices that when an IPVS synchonisation daemons are
started the system load slowly climbs up to 1. This seems to be related
to the call to ssleep(1) (aka msleep(1000) in the main loop. Replacing
this with a call to msleep_interruptable() seems to make the problem go
away. Though I'm not sure that it is correct.
This is the second edition of this patch, which replaces ssleep()
in the main loop for both the master and backup threads, as well
as some thread synchronisation code. The latter is just for thorougness
as it shouldn't be causing any problems.
Cc: Dean Manners <[EMAIL PROTECTED]>
Cc: Julian Anastasov <[EMAIL PROTECTED]>
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_sync.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2006-11-28 15:30:00.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_sync.c2006-11-29 09:46:27.0
+0900
@@ -657,7 +657,7 @@
if (stop_master_sync)
break;
- ssleep(1);
+ msleep_interruptible(1000);
}
/* clean up the sync_buff queue */
@@ -714,7 +714,7 @@
if (stop_backup_sync)
break;
- ssleep(1);
+ msleep_interruptible(1000);
}
/* release the sending multicast socket */
@@ -826,7 +826,7 @@
if ((pid = kernel_thread(sync_thread, startup, 0)) < 0) {
IP_VS_ERR("could not create sync_thread due to %d... "
"retrying.\n", pid);
- ssleep(1);
+ msleep_interruptible(1000);
goto repeat;
}
@@ -860,7 +860,7 @@
if ((pid = kernel_thread(fork_sync_thread, &startup, 0)) < 0) {
IP_VS_ERR("could not create fork_sync_thread due to %d... "
"retrying.\n", pid);
- ssleep(1);
+ msleep_interruptible(1000);
goto repeat;
}
-
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] [IPVS] use msleep_interruptable() instead of ssleep() aka msleep()
Dean Manners notices that when an IPVS synchonisation daemons are started the system load slowly climbs up to 1. This seems to be related to the call to ssleep(1) (aka msleep(1000) in the main loop. Replacing this with a call to msleep_interruptable() seems to make the problem go away. Though I'm not sure that it is correct. Cc: Dean Manners <[EMAIL PROTECTED]> Signed-Off-By: Simon Horman <[EMAIL PROTECTED]> Index: linux-2.6/net/ipv4/ipvs/ip_vs_sync.c === --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2006-11-10 15:33:42.0 +0900 +++ linux-2.6/net/ipv4/ipvs/ip_vs_sync.c2006-11-10 15:33:52.0 +0900 @@ -657,7 +657,7 @@ if (stop_master_sync) break; - ssleep(1); + msleep_interruptible(1000); } /* clean up the sync_buff queue */ - 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 0/2] [IPVS]: Make sure ip_vs_ftp ports are valid (again)
On Wed, Sep 27, 2006 at 10:53:54PM -0700, David Miller wrote: > From: Horms <[EMAIL PROTECTED]> > Date: Wed, 20 Sep 2006 23:44:57 +0900 > > > there are two patches floating around for this problem. > > It seems that the first incarntation has been committed > > to Linus's tree as 3f5af5b353ca36aca4f8a46e3da2172f669dbbbc. > > > > This series of 2 patches reverses that change, and > > adds the new, simpler, change in its place. > > Both applied, thanks Simon. Thanks > If you think it's serious enough to submit for -stable, just > let me know. I regard this as a cosmetic change, so it can wait for 2.6.19. -- 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
Re: ipvs locahost client patch for 2.6?
On Fri, 11 Aug 2006 01:18:38, Ryan Nowakowski wrote: > I found this patch for 2.4 that allows the host running ipvs to act > as it's own client via loopback connection. Does anyone have a similar > patch for 2.6? Not that I am aware of, though that kind of approach may well work for 2.6 with little effort. -- 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
Re: [patch 3/4] Make sure ip_vs_ftp ports are valid
On Wed, Sep 20, 2006 at 12:29:45PM +0200, Patrick McHardy wrote:
> Horms wrote:
> > Here is the revised patch.
> >
> >
> > [IPVS] Make sure ip_vs_ftp ports are valid
> >
> > I'm not entirely sure what happens in the case of a valid port,
> > at best it'll be silently ignored. This patch ensures that
> > the port values are unsigned short values, and thus always valid.
> >
> > Cc: Patrick McHardy <[EMAIL PROTECTED]>
> > Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
> >
> > Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
> > ===
> > --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-04
> 10:47:09.0 +0900
> > +++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-04 10:59:30.0
> +0900
> > @@ -44,8 +44,8 @@
> > * List of ports (up to IP_VS_APP_MAX_PORTS) to be handled by helper
> > * First port is set to the default port.
> > */
> > -static int ports[IP_VS_APP_MAX_PORTS] = {21, 0};
> > -module_param_array(ports, int, NULL, 0);
> > +static unsigned short ports[IP_VS_APP_MAX_PORTS] = {21, 0};
> > +module_param_array(ports, ushort, NULL, 0);
> > MODULE_PARM_DESC(ports, "Ports to monitor for FTP control commands");
> >
> > /*
>
> It looks like the wrong patch went in:
>
> http://marc.theaimsgroup.com/?l=git-commits-head&m=115862407021941&w=2
Thanks for pointing that out. I'll send out patches to reverse
the committed change, and add the newer incarntation.
--
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
Re: [patch 3/4] Make sure ip_vs_ftp ports are valid
On Mon, Sep 04, 2006 at 09:44:02AM +0900, Horms wrote:
> On Mon, Sep 04, 2006 at 01:09:59AM +0200, Patrick McHardy wrote:
> > Horms wrote:
> > > I'm not entirely sure what happens in the case of a valid port,
> > > at best it'll be silently ignored. This patch ignores them a little
> > > more verbosely.
> > >
> > > Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
> > > Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
> > > ===
> > > --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01
> > > 19:06:42.0 +0900
> > > +++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:08:19.0
> > > +0900
> > > @@ -373,6 +373,12 @@
> > > for (i=0; i > > if (!ports[i])
> > > continue;
> > > + if (ports[i] < 0 || ports[i] > 0x) {
> > > + IP_VS_WARNING("ip_vs_ftp: Ignoring invalid "
> > > + "configuration port[%d] = %d\n",
> > > + i, ports[i]);
> > > + continue;
> > > + }
> >
> > How about just changing the module parameter type to ushort, similar to
> > what ip_conntrack_ftp does?
>
> Sure. I wasn't sure if that was possible or not.
> But as it is, I will make it so.
Here is the revised patch.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
[IPVS] Make sure ip_vs_ftp ports are valid
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ensures that
the port values are unsigned short values, and thus always valid.
Cc: Patrick McHardy <[EMAIL PROTECTED]>
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-04 10:47:09.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-04 10:59:30.0 +0900
@@ -44,8 +44,8 @@
* List of ports (up to IP_VS_APP_MAX_PORTS) to be handled by helper
* First port is set to the default port.
*/
-static int ports[IP_VS_APP_MAX_PORTS] = {21, 0};
-module_param_array(ports, int, NULL, 0);
+static unsigned short ports[IP_VS_APP_MAX_PORTS] = {21, 0};
+module_param_array(ports, ushort, NULL, 0);
MODULE_PARM_DESC(ports, "Ports to monitor for FTP control commands");
/*
--
VGER BF report: U 0.832414
-
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 3/4] Make sure ip_vs_ftp ports are valid
On Mon, Sep 04, 2006 at 01:09:59AM +0200, Patrick McHardy wrote:
> Horms wrote:
> > I'm not entirely sure what happens in the case of a valid port,
> > at best it'll be silently ignored. This patch ignores them a little
> > more verbosely.
> >
> > Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
> > Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
> > ===
> > --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01
> > 19:06:42.0 +0900
> > +++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:08:19.0
> > +0900
> > @@ -373,6 +373,12 @@
> > for (i=0; i > if (!ports[i])
> > continue;
> > + if (ports[i] < 0 || ports[i] > 0x) {
> > + IP_VS_WARNING("ip_vs_ftp: Ignoring invalid "
> > + "configuration port[%d] = %d\n",
> > + i, ports[i]);
> > + continue;
> > + }
>
> How about just changing the module parameter type to ushort, similar to
> what ip_conntrack_ftp does?
Sure. I wasn't sure if that was possible or not.
But as it is, I will make it so.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
--
VGER BF report: U 0.575956
-
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 3/4] Make sure ip_vs_ftp ports are valid
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ignores them a little
more verbosely.
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01 19:06:42.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:08:19.0 +0900
@@ -373,6 +373,12 @@
for (i=0; i 0x) {
+ IP_VS_WARNING("ip_vs_ftp: Ignoring invalid "
+ "configuration port[%d] = %d\n",
+ i, ports[i]);
+ continue;
+ }
ret = register_ip_vs_app_inc(app, app->protocol, ports[i]);
if (ret)
break;
--
--
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
[patch 1/4] Document the ports option to ip_vs_ftp in kernel-parameters.txt
I'm not sure if documenting this here is appropriate, but if it is, here is some text to put there. Signed-Off-By: Simon Horman <[EMAIL PROTECTED]> Index: linux-2.6/Documentation/kernel-parameters.txt === --- linux-2.6.orig/Documentation/kernel-parameters.txt 2006-09-01 17:02:10.0 +0900 +++ linux-2.6/Documentation/kernel-parameters.txt 2006-09-01 17:02:49.0 +0900 @@ -697,6 +697,12 @@ ips=[HW,SCSI] Adaptec / IBM ServeRAID controller See header of drivers/scsi/ips.c. + ports= [IP_VS_FTP] IPVS ftp helper module + Default is 21. + Up to 8 (IP_VS_APP_MAX_PORTS) ports + may be specified. + Format: , + irqfixup[HW] When an interrupt is not handled search all handlers for it. Intended to get systems with badly broken -- -- 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
[patch 4/4] remove the debug option go ip_vs_ftp
This patch makes the debuging behaviour of this code more consistent
with the rest of IPVS.
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01 19:06:49.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:06:50.0 +0900
@@ -48,14 +48,6 @@
module_param_array(ports, int, NULL, 0);
MODULE_PARM_DESC(ports, "Ports to monitor for FTP control commands");
-/*
- * Debug level
- */
-#ifdef CONFIG_IP_VS_DEBUG
-static int debug=0;
-module_param(debug, int, 0);
-#endif
-
/* Dummy variable */
static int ip_vs_ftp_pasv;
@@ -178,7 +170,7 @@
&start, &end) != 1)
return 1;
- IP_VS_DBG(1-debug, "PASV response (%u.%u.%u.%u:%d) -> "
+ IP_VS_DBG(7, "PASV response (%u.%u.%u.%u:%d) -> "
"%u.%u.%u.%u:%d detected\n",
NIPQUAD(from), ntohs(port), NIPQUAD(cp->caddr), 0);
@@ -281,7 +273,7 @@
while (data <= data_limit - 6) {
if (strnicmp(data, "PASV\r\n", 6) == 0) {
/* Passive mode on */
- IP_VS_DBG(1-debug, "got PASV at %zd of %zd\n",
+ IP_VS_DBG(7, "got PASV at %zd of %zd\n",
data - data_start,
data_limit - data_start);
cp->app_data = &ip_vs_ftp_pasv;
@@ -303,7 +295,7 @@
&start, &end) != 1)
return 1;
- IP_VS_DBG(1-debug, "PORT %u.%u.%u.%u:%d detected\n",
+ IP_VS_DBG(7, "PORT %u.%u.%u.%u:%d detected\n",
NIPQUAD(to), ntohs(port));
/* Passive mode off */
@@ -312,7 +304,7 @@
/*
* Now update or create a connection entry for it
*/
- IP_VS_DBG(1-debug, "protocol %s %u.%u.%u.%u:%d %u.%u.%u.%u:%d\n",
+ IP_VS_DBG(7, "protocol %s %u.%u.%u.%u:%d %u.%u.%u.%u:%d\n",
ip_vs_proto_name(iph->protocol),
NIPQUAD(to), ntohs(port), NIPQUAD(cp->vaddr), 0);
@@ -382,8 +374,8 @@
ret = register_ip_vs_app_inc(app, app->protocol, ports[i]);
if (ret)
break;
- IP_VS_DBG(1-debug, "%s: loaded support on port[%d] = %d\n",
- app->name, i, ports[i]);
+ IP_VS_INFO("%s: loaded support on port[%d] = %d\n",
+ app->name, i, ports[i]);
}
if (ret)
--
--
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
[patch 2/4] auto-help for ip_vs_ftp
Fill in a help message for the ports option to ip_vs_ftp
Signed-Off-By: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ftp.c2006-09-01 19:02:38.0
+0900
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ftp.c 2006-09-01 19:06:42.0 +0900
@@ -46,6 +46,7 @@
*/
static int ports[IP_VS_APP_MAX_PORTS] = {21, 0};
module_param_array(ports, int, NULL, 0);
+MODULE_PARM_DESC(ports, "Ports to monitor for FTP control commands");
/*
* Debug level
--
--
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
[patch 0/4] ip_vs_ftp cleanups
Hi, This series of four patches has several minor cleanups for the options to the ip_vs_ftp modules. -- 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
Re: [PATCH] ipvs: Add sysctl documentation
On Mon, Jul 03, 2006 at 07:36:47PM -0700, David Miller wrote: > From: Horms <[EMAIL PROTECTED]> > Date: Mon, 3 Jul 2006 11:31:30 +0900 > > > * Derived from http://www.linuxvirtualserver.org/docs/sysctl.html, v1.4 > > maintained by Wensong Zhang > > > > * Adjusted preample to match ip-sysctl.txt > > > > * Sorted options into alphabetical order > > > > * Added expire_quiescent_template > > > > * Removed timeout_* which are no longer present > > > > * Incoporated doc/debug-levels.txt from IPVS source tree into > > description of ipvs_debug > > > > * Minor spelling fixes > > > > * Further editing more than welcome > > > > Signed-Off-By: Horms <[EMAIL PROTECTED]> > > Applied, thanks Simon. > > > * DaveM, do you need a 2.4 version of this document, > > it will likely be a slightly different list of options? > > I don't think it's really worthwhile, we should be touching 2.4.x > as little as possible at this point. Changes we make in 2.4.x > should be in the "absolutely necssary" category. Understood, I'm more than happy to let that sleeping dog lie. -- 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
[PATCH] ipvs: Add sysctl documentation
* Derived from http://www.linuxvirtualserver.org/docs/sysctl.html, v1.4 maintained by Wensong Zhang * Adjusted preample to match ip-sysctl.txt * Sorted options into alphabetical order * Added expire_quiescent_template * Removed timeout_* which are no longer present * Incoporated doc/debug-levels.txt from IPVS source tree into description of ipvs_debug * Minor spelling fixes * Further editing more than welcome * DaveM, do you need a 2.4 version of this document, it will likely be a slightly different list of options? Signed-Off-By: Horms <[EMAIL PROTECTED]> Documentation/networking/ipvs-sysctl.txt | 143 ++ 1 file changed, 143 insertions(+) --- /dev/null 2006-06-23 09:57:18.708345250 +0900 +++ b/Documentation/networking/ipvs-sysctl.txt 2006-07-03 11:20:33.0 +0900 @@ -0,0 +1,143 @@ +/proc/sys/net/ipv4/vs/* Variables: + +am_droprate - INTEGER +default 10 + +It sets the always mode drop rate, which is used in the mode 3 +of the drop_rate defense. + +amemthresh - INTEGER +default 1024 + +It sets the available memory threshold (in pages), which is +used in the automatic modes of defense. When there is no +enough available memory, the respective strategy will be +enabled and the variable is automatically set to 2, otherwise +the strategy is disabled and the variable is set to 1. + +cache_bypass - BOOLEAN +0 - disabled (default) +not 0 - enabled + +If it is enabled, forward packets to the original destination +directly when no cache server is available and destination +address is not local (iph->daddr is RTN_UNICAST). It is mostly +used in transparent web cache cluster. + +debug_level - INTEGER + 0 - transmission error messages (default) + 1 - non-fatal error messages + 2 - configuration + 3 - destination trash + 4 - drop entry + 5 - service lookup + 6 - scheduling + 7 - connection new/expire, lookup and synchronization + 8 - state transition + 9 - binding destination, template checks and applications + 10 - IPVS packet transmission + 11 - IPVS packet handling (ip_vs_in/ip_vs_out) + 12 or more - packet traversal + + Only available when IPVS is compiled with the CONFIG_IPVS_DEBUG + + Higher debugging levels include the messages for lower debugging + levels, so setting debug level 2, includes level 0, 1 and 2 + messages. Thus, logging becomes more and more verbose the higher + the level. + +drop_entry - INTEGER +0 - disabled (default) + +The drop_entry defense is to randomly drop entries in the +connection hash table, just in order to collect back some +memory for new connections. In the current code, the +drop_entry procedure can be activated every second, then it +randomly scans 1/32 of the whole and drops entries that are in +the SYN-RECV/SYNACK state, which should be effective against +syn-flooding attack. + +The valid values of drop_entry are from 0 to 3, where 0 means +that this strategy is always disabled, 1 and 2 mean automatic +modes (when there is no enough available memory, the strategy +is enabled and the variable is automatically set to 2, +otherwise the strategy is disabled and the variable is set to +1), and 3 means that that the strategy is always enabled. + +drop_packet - INTEGER +0 - disabled (default) + +The drop_packet defense is designed to drop 1/rate packets +before forwarding them to real servers. If the rate is 1, then +drop all the incoming packets. + +The value definition is the same as that of the drop_entry. In +the automatic mode, the rate is determined by the follow +formula: rate = amemthresh / (amemthresh - available_memory) +when available memory is less than the available memory +threshold. When the mode 3 is set, the always mode drop rate +is controlled by the /proc/sys/net/ipv4/vs/am_droprate. + +expire_nodest_conn - BOOLEAN +0 - disabled (default) +not 0 - enabled + +The default value is 0, the load balancer will silently drop +packets when its destination server is not available. It may +be useful, when user-space monitoring program deletes the +destination server (because of server overload or wrong +detection) and add back the server later, and the connections +to the server can continue. + +If this feature is enabled, the load balancer will expire the +connection immediately when a packet arrives and its +destination server is not available, then the client program +will be notified that the c
Re: IPVS Sysctl Variables
On Fri, Jun 30, 2006 at 02:20:45PM -0700, David Miller wrote: > From: Horms <[EMAIL PROTECTED]> > Date: Fri, 30 Jun 2006 15:19:41 +0900 > > > there are quite a number of entries under /proc/sys/net/ipv4/vs, > > I swear that they were documented in Documentation/networking/ > > at some stage, but perhaps I am dreaming. > > > > In any case, if I clean up the information at the following URL (which a > > probably complete list of what the options are and what they do, you don't > > have to check if you don't want to), is it appropriate for inclusion in > > Documentation/networking/, and if so, should it be in ip-sysctl.txt, or > > elsewhere? > > > > http://www.linuxvirtualserver.org/docs/sysctl.html > > Good question, maybe ip-sysctl.txt is getting a bit crowded. > I therefore wouldn't mind you putting this into networking/ipvs-sysctl.txt Thanks, I will make that so. -- 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
IPVS Sysctl Variables
Hi, there are quite a number of entries under /proc/sys/net/ipv4/vs, I swear that they were documented in Documentation/networking/ at some stage, but perhaps I am dreaming. In any case, if I clean up the information at the following URL (which a probably complete list of what the options are and what they do, you don't have to check if you don't want to), is it appropriate for inclusion in Documentation/networking/, and if so, should it be in ip-sysctl.txt, or elsewhere? http://www.linuxvirtualserver.org/docs/sysctl.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
Re: [rfc][patch] ipvs: use proper timeout instead of fixed value
On Sun, May 07, 2006 at 11:13:33PM -0400, Andy Gospodarek wrote: > On Sun, May 07, 2006 at 01:38:40PM +0900, Horms wrote: > > On Fri, May 05, 2006 at 02:57:26PM -0400, Andy Gospodarek wrote: > > > On Fri, May 05, 2006 at 12:20:54PM +0900, Horms wrote: > > > > > > > > Sorry, I missunderstood your patch completely the first time around. > > > > Yes I think this is an excellent idea. Assuming its tested and works > > > > I'm happy to sign off on it and prod DaveM. > > > > > > Horms, > > > > > > I'll get a setup together and post results when I have them. > > > > I was thinking that it would be nice if the timeout could be sent over > > the wire, though that might bring in some compatibility issues, > > and thus your approach might be the best idea. > > > > -- > > Horms > > http://www.vergenet.net/~horms/ > > > Horms, > > At first I too thought about including the timeout in the messages would > be nice, but it could raise compatibility issues with maybe the only > advantage being that it would allow quicker timeout of connections -- > something that might be undesirable in such an LVS environment. Yes, I agree. Wensong raised the issue of having many many connections on the backup, I personally think thats its unlikely that would be a problem in practice, though making it tunable might be nice in any case. -- Horms http://www.vergenet.net/~horms/ - 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: [rfc][patch] ipvs: use proper timeout instead of fixed value
On Fri, May 05, 2006 at 02:57:26PM -0400, Andy Gospodarek wrote: > On Fri, May 05, 2006 at 12:20:54PM +0900, Horms wrote: > > > > Sorry, I missunderstood your patch completely the first time around. > > Yes I think this is an excellent idea. Assuming its tested and works > > I'm happy to sign off on it and prod DaveM. > > Horms, > > I'll get a setup together and post results when I have them. I was thinking that it would be nice if the timeout could be sent over the wire, though that might bring in some compatibility issues, and thus your approach might be the best idea. -- Horms http://www.vergenet.net/~horms/ - 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: [rfc][patch] ipvs: use proper timeout instead of fixed value
On Thu, May 04, 2006 at 10:51:11PM -0400, Andy Gospodarek wrote: > On Fri, May 05, 2006 at 09:47:56AM +0900, Horms wrote: > > On Thu, May 04, 2006 at 04:11:16PM -0400, Andy Gospodarek wrote: > > > > > > Instead of using the default timeout of 3 minutes, this uses the timeout > > > specific to the protocol used for the connection. The 3 minute timeout > > > seems somewhat arbitrary (though I know it is used other places in the > > > ipvs code) and when failing over it would be much nicer to use one of > > > the configured timeout values. > > > > Hi Andy, > > > > I agree that the current value is somewhat arbitary, > > however I'm more in favour of setting it idependantly > > of other timeouts, perhaps via proc. In any case, > > won't pp->timeout_table[cp->state] be rather long in > > the ESTABLISHED case? > > > > Horms, > > I agree that there could be a long timeout for ESTABLISHED connections, > but I've run across a situation where I need exactly that. When testing > failover from master to backup I realize that all of my interactive > sessions get dropped much sooner than the timeout I've configured (mine > is currently set for much longer than 3 minutes). If I wanted > established connections to timeout quickly I would set the timeout to be > a small value. Sorry, I missunderstood your patch completely the first time around. Yes I think this is an excellent idea. Assuming its tested and works I'm happy to sign off on it and prod DaveM. -- Horms http://www.vergenet.net/~horms/ - 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: [rfc][patch] ipvs: use proper timeout instead of fixed value
On Thu, May 04, 2006 at 04:11:16PM -0400, Andy Gospodarek wrote:
>
> Instead of using the default timeout of 3 minutes, this uses the timeout
> specific to the protocol used for the connection. The 3 minute timeout
> seems somewhat arbitrary (though I know it is used other places in the
> ipvs code) and when failing over it would be much nicer to use one of
> the configured timeout values.
Hi Andy,
I agree that the current value is somewhat arbitary,
however I'm more in favour of setting it idependantly
of other timeouts, perhaps via proc. In any case,
won't pp->timeout_table[cp->state] be rather long in
the ESTABLISHED case?
> Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]>
> ---
>
> ip_vs_sync.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
> --- a/net/ipv4/ipvs/ip_vs_sync.c
> +++ b/net/ipv4/ipvs/ip_vs_sync.c
> @@ -67,7 +67,6 @@ struct ip_vs_sync_conn_options {
> struct ip_vs_seqout_seq;/* outgoing seq. struct */
> };
>
> -#define IP_VS_SYNC_CONN_TIMEOUT (3*60*HZ)
> #define SIMPLE_CONN_SIZE (sizeof(struct ip_vs_sync_conn))
> #define FULL_CONN_SIZE \
> (sizeof(struct ip_vs_sync_conn) + sizeof(struct ip_vs_sync_conn_options))
> @@ -279,6 +278,7 @@ static void ip_vs_process_message(const
> struct ip_vs_sync_conn *s;
> struct ip_vs_sync_conn_options *opt;
> struct ip_vs_conn *cp;
> + struct ip_vs_protocol *pp;
> char *p;
> int i;
>
> @@ -337,7 +337,8 @@ static void ip_vs_process_message(const
> p += SIMPLE_CONN_SIZE;
>
> atomic_set(&cp->in_pkts, sysctl_ip_vs_sync_threshold[0]);
> - cp->timeout = IP_VS_SYNC_CONN_TIMEOUT;
> + pp = ip_vs_proto_get(s->protocol);
> + cp->timeout = pp->timeout_table[cp->state];
> ip_vs_conn_put(cp);
>
> if (p > buffer+buflen) {
--
Horms http://www.vergenet.net/~horms/
-
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] net: ne2k.c won't compile if pci_clone_list is const
net: ne2k.c won't compile if pci_clone_list is const
f71e130966ba429dbd24be08ddbcdf263df9a5ad which (amongst other things)
made pci_clone_list in ne2k-pci.c const causes the following compile error.
This patch reverses that portion of that changeset
drivers/net/ne2k-pci.c:123: error: pci_clone_list causes a section type
conflict
~/ gcc --version
gcc (GCC) 4.0.3 (Debian 4.0.3-1)
~/ dpkg gcc-4.0 | grep Version
Version: 4.0.3-1
Signed-Off-By: Horms <[EMAIL PROTECTED]
ne2k-pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
cee0890cc97247b6a9decd94f5dc0719ac8f0b1b
diff --git a/drivers/net/ne2k-pci.c b/drivers/net/ne2k-pci.c
index e3ebb58..d11821d 100644
--- a/drivers/net/ne2k-pci.c
+++ b/drivers/net/ne2k-pci.c
@@ -117,7 +117,7 @@ enum ne2k_pci_chipsets {
};
-static const struct {
+static struct {
char *name;
int flags;
} pci_clone_list[] __devinitdata = {
-
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 04/39] [PATCH] [BRIDGE]: netfilter missing symbol has_bridge_parent
On Mon, Feb 27, 2006 at 02:32:04PM -0800, Chris Wright wrote:
> -stable review patch. If anyone has any objections, please let us know.
> --
>
> 5dce971acf2ae20c80d5e9d1f6bbf17376870911 in Linus' tree,
> otherwise known as bridge-netfilter-races-on-device-removal.patch in
> 2.5.15.4 removed has_bridge_parent, however this symbol is still
> called with NETFILTER_DEBUG is enabled.
>
> This patch uses the already seeded realoutdev value to detect if a parent
> exists, and if so, the value of the parent.
>
> Signed-Off-By: Horms <[EMAIL PROTECTED]>
> Acked-by: Stephen Hemminger <[EMAIL PROTECTED]>
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> ---
>
> net/bridge/br_netfilter.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-2.6.15.4.orig/net/bridge/br_netfilter.c
> +++ linux-2.6.15.4/net/bridge/br_netfilter.c
> @@ -794,8 +794,8 @@ static unsigned int br_nf_post_routing(u
> print_error:
> if (skb->dev != NULL) {
> printk("[%s]", skb->dev->name);
> - if (has_bridge_parent(skb->dev))
> - printk("[%s]", bridge_parent(skb->dev)->name);
> + if (realoutdev)
> + printk("[%s]", realoutdev->name);
> }
> printk(" head:%p, raw:%p, data:%p\n", skb->head, skb->mac.raw,
> skb->data);
>
> --
I double checked, and that is the aggregate fix that was added
to Linus' tree, it should solve the problem at hand.
--
Horms
-
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] [BRIDGE]: netfilter missing symbol has_bridge_parent
On Mon, Feb 13, 2006 at 10:59:07AM -0800, Stephen Hemminger wrote: > Horms patch was the best of the three fixes. Dave, already applied Harald's > version, so this patch converts that to the better one. Thanks, I was working of Linus' i2.6 tree rather than Dave's net-2.6, so I didn't see Harald's patch until now. -- Horms - 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] [BRIDGE]: netfilter missing symbol has_bridge_parent
On Sun, Feb 12, 2006 at 11:15:42PM +0100, Bernard Pidoux wrote:
> Hi,
>
> I would like to report that when compiling 2.6.15.4 kernel
> there is an error with undefined symbol 'has_bridge_parent'
> in compilation of bridge/br_netfilter.c
> due to CONFIG_NETFILTER_DEBUG 1 option.
I think that the following patch will resolve this problem.
--
Horms
[BRIDGE]: netfilter missing symbol has_bridge_parent
5dce971acf2ae20c80d5e9d1f6bbf17376870911 in Linus' tree,
otherwise known as bridge-netfilter-races-on-device-removal.patch in
2.5.15.4 removed has_bridge_parent, however this symbol is still
called with NETFILTER_DEBUG is enabled.
This patch uses the already seeded realoutdev value to detect if a parent
exists, and if so, the value of the parent.
Signed-Off-By: Horms <[EMAIL PROTECTED]>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index b501816..6bb0c7e 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -805,8 +805,8 @@ static unsigned int br_nf_post_routing(u
print_error:
if (skb->dev != NULL) {
printk("[%s]", skb->dev->name);
- if (has_bridge_parent(skb->dev))
- printk("[%s]", bridge_parent(skb->dev)->name);
+ if (realoutdev)
+ printk("[%s]", realoutdev->name);
}
printk(" head:%p, raw:%p, data:%p\n", skb->head, skb->mac.raw,
skb->data);
-
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,2.4,SECURITY,NET] orinoco: CVE-2005-3180: Information leakage due to incorrect padding
> [PATCH] Better fixup for the orinoco driver
>
> The latest kernel added a pretty ugly fix for the orinoco etherleak bug
> which contains bogus skb->len checks already done by the caller and causes
> copies of all odd sized frames (which are quite common)
>
> While the skb->len check should be ripped out the other fix is harder to do
> properly so I'm proposing for this the -mm tree only until next 2.6.x so
> that it gets tested.
>
> Instead of copying buffers around blindly this code implements a padding
> aware version of the hermes buffer writing function which does padding as
> the buffer is loaded and thus more cleanly and without bogus 1.5K copies.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
The above is a patch included in 2.6.16 as a fix for CVE-2005-3180. It to
be applicable to 2.4. I have made a backport below, with the only
semi-significant change being including the ALIGN macro in orinoco.c, as it
doesn't exist in 2.4.
As yet untested
Signed-off-by: Horms <[EMAIL PROTECTED]>
index 0c06b14..b99edd3 100644
--- a/drivers/net/wireless/hermes.c
+++ b/drivers/net/wireless/hermes.c
@@ -448,6 +448,43 @@ int hermes_bap_pwrite(hermes_t *hw, int
return err;
}
+/* Write a block of data to the chip's buffer with padding if
+ * neccessary, via the BAP. Synchronization/serialization is the
+ * caller's problem. len must be even.
+ *
+ * Returns: < 0 on internal failure (errno), 0 on success, > 0 on error from
firmware
+ */
+int hermes_bap_pwrite_pad(hermes_t *hw, int bap, const void *buf, unsigned
data_len, unsigned len,
+ u16 id, u16 offset)
+{
+ int dreg = bap ? HERMES_DATA1 : HERMES_DATA0;
+ int err = 0;
+
+ if (len < 0 || len % 2 || data_len > len)
+ return -EINVAL;
+
+ err = hermes_bap_seek(hw, bap, id, offset);
+ if (err)
+ goto out;
+
+ /* Transfer all the complete words of data */
+ hermes_write_words(hw, dreg, buf, data_len/2);
+ /* If there is an odd byte left over pad and transfer it */
+ if (data_len & 1) {
+ u8 end[2];
+ end[1] = 0;
+ end[0] = ((unsigned char *)buf)[data_len - 1];
+ hermes_write_words(hw, dreg, end, 1);
+ data_len ++;
+ }
+ /* Now send zeros for the padding */
+ if (data_len < len)
+ hermes_clear_words(hw, dreg, (len - data_len) / 2);
+ /* Complete */
+ out:
+ return err;
+}
+
/* Read a Length-Type-Value record from the card.
*
* If length is NULL, we ignore the length read from the card, and
@@ -534,6 +571,7 @@ EXPORT_SYMBOL(hermes_allocate);
EXPORT_SYMBOL(hermes_bap_pread);
EXPORT_SYMBOL(hermes_bap_pwrite);
+EXPORT_SYMBOL(hermes_bap_pwrite_pad);
EXPORT_SYMBOL(hermes_read_ltv);
EXPORT_SYMBOL(hermes_write_ltv);
index 5c01d0d..5a7e587 100644
--- a/drivers/net/wireless/hermes.h
+++ b/drivers/net/wireless/hermes.h
@@ -319,6 +319,8 @@ int hermes_bap_pread(hermes_t *hw, int b
u16 id, u16 offset);
int hermes_bap_pwrite(hermes_t *hw, int bap, const void *buf, unsigned len,
u16 id, u16 offset);
+int hermes_bap_pwrite_pad(hermes_t *hw, int bap, const void *buf,
+ unsigned data_len, unsigned len, u16 id, u16 offset);
int hermes_read_ltv(hermes_t *hw, int bap, u16 rid, unsigned buflen,
u16 *length, void *buf);
int hermes_write_ltv(hermes_t *hw, int bap, u16 rid,
index 5b5ca26..ec4003f 100644
--- a/drivers/net/wireless/orinoco.c
+++ b/drivers/net/wireless/orinoco.c
@@ -2312,6 +2312,8 @@ orinoco_stat_gather(struct net_device *d
}
}
+#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
+
static int
orinoco_xmit(struct sk_buff *skb, struct net_device *dev)
{
@@ -2407,14 +2409,22 @@ orinoco_xmit(struct sk_buff *skb, struct
stats->tx_errors++;
goto fail;
}
+ /* Actual xfer length - allow for padding */
+ len = ALIGN(data_len, 2);
+ if (len < ETH_ZLEN - ETH_HLEN)
+ len = ETH_ZLEN - ETH_HLEN;
} else { /* IEEE 802.3 frame */
data_len = len + ETH_HLEN;
data_off = HERMES_802_3_OFFSET;
p = skb->data;
+ /* Actual xfer length - round up for odd length packets */
+ len = ALIGN(data_len, 2);
+ if (len < ETH_ZLEN)
+ len = ETH_ZLEN;
}
- /* Round up for odd length packets */
- err = hermes_bap_pwrite(hw, USER_BAP, p, RUP_EVEN(data_len), txfid,
data_off);
+ err = hermes_bap_pwrite_pad(hw, USER_BAP, p, data_len, len,
+ txfid, dat
Re: [PATCH] [IPVS] Shrink ip_vs_*.c includes
On Tue, Feb 07, 2006 at 09:07:34PM -0800, David S. Miller wrote: > From: Horms <[EMAIL PROTECTED]> > Date: Wed, 8 Feb 2006 12:09:29 +0900 > > > Unfortunately this seems like it is going to be more tedious than > > we first thought. I would guess writing some sort of tool to analyse > > symbols and headers is the way to go. Else it seems more or less > > impossible to clean up headers, even on a small scale. > > It's doable on a small scale, you just have to approach the problem > from the other direction. Ie. pick a header file and audit the use of > that specific header file across the tree. > > Folks have done this with headers like linux/sched.h and friends in > the past. Point taken. I imagine a tool could digest this reasonably efficiently. Its just doing it by hand which is somewhat labourious. > And it's worthwhile because anything that minimises kernel rebuild > when touching a header file helps streamline development. Agreed -- Horms - 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] [IPVS] Shrink ip_vs_*.c includes
On Wed, Feb 08, 2006 at 01:36:11PM +1100, Herbert Xu wrote: > Horms <[EMAIL PROTECTED]> wrote: > > > >> Looks bogus to me. Why are we removing linux/modules.h from ip_vs_app.c > >> when it uses things like EXPORT_SYMBOL? > > > > Given that the code still compiles, I guess linux/modules.h is included > > in some other header that is included. I'm happy to put linux/modules.h > > back in. Do you have any more suggestions? > > This is the wrong way to go about it. You should never rely on indirect > inclusions because they might be removed one day and your file will not > compile anymore. > > The correct way to go about this is to go through each included header > file and check if any of its symbols are used in the source file. > > Or if this is too tedious just leave it alone. Hi Herbert, thanks for your feedback. Dave, please discard this patch for now. Ratz, Unfortunately this seems like it is going to be more tedious than we first thought. I would guess writing some sort of tool to analyse symbols and headers is the way to go. Else it seems more or less impossible to clean up headers, even on a small scale. -- Horms - 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] [IPVS] Shrink ip_vs_*.c includes
On Wed, Feb 08, 2006 at 12:19:32PM +1100, Herbert Xu wrote: > Horms <[EMAIL PROTECTED]> wrote: > > Dave, > > > > please apply. > > Looks bogus to me. Why are we removing linux/modules.h from ip_vs_app.c > when it uses things like EXPORT_SYMBOL? Given that the code still compiles, I guess linux/modules.h is included in some other header that is included. I'm happy to put linux/modules.h back in. Do you have any more suggestions? -- Horms - 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] [IPVS] Shrink ip_vs_*.c includes
Dave, please apply. -- Horms Hello, This patch against the latest GIT HEAD reduces the includes to the necessary ones. I've compile-tested it against following (and s/y/m/) configuration on x86: CONFIG_IP_VS=y CONFIG_IP_VS_DEBUG=y CONFIG_IP_VS_TAB_BITS=12 CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_RR=y CONFIG_IP_VS_WRR=y CONFIG_IP_VS_LC=y CONFIG_IP_VS_WLC=y CONFIG_IP_VS_LBLC=y CONFIG_IP_VS_LBLCR=y CONFIG_IP_VS_DH=y CONFIG_IP_VS_SH=y CONFIG_IP_VS_SED=y CONFIG_IP_VS_NQ=y CONFIG_IP_VS_FTP=y Please consider applying (but test it first on your local tree since we don't want stupid breakage resulting from such changes). Alternatively/additionally I could envision a patch on top of this one that completely removes the includes from the ../net/ipv4/ipvs/*.c except the ../include/net/ip_vs.h, which would carry all the needed header includes. Signed-off-by: Roberto Nibali <[EMAIL PROTECTED]> Signed-off-by: Horms <[EMAIL PROTECTED]> diff --git a/net/ipv4/ipvs/ip_vs_app.c b/net/ipv4/ipvs/ip_vs_app.c index 9b176a9..9f5676b 100644 --- a/net/ipv4/ipvs/ip_vs_app.c +++ b/net/ipv4/ipvs/ip_vs_app.c @@ -20,17 +20,9 @@ * */ -#include -#include #include -#include -#include -#include #include -#include -#include #include -#include #include diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c index 87b8381..157b9ad 100644 --- a/net/ipv4/ipvs/ip_vs_conn.c +++ b/net/ipv4/ipvs/ip_vs_conn.c @@ -24,13 +24,12 @@ * */ -#include #include #include -#include #include +#include #include -#include /* for proc_net_* */ +#include #include #include #include diff --git a/net/ipv4/ipvs/ip_vs_core.c b/net/ipv4/ipvs/ip_vs_core.c index 3f47ad8..927fbc0 100644 --- a/net/ipv4/ipvs/ip_vs_core.c +++ b/net/ipv4/ipvs/ip_vs_core.c @@ -26,19 +26,13 @@ * */ -#include -#include -#include #include #include #include -#include -#include #include/* for icmp_send */ -#include +#include /* for inet_addr_type */ -#include #include #include diff --git a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c index 7f0288b..a130c5f 100644 --- a/net/ipv4/ipvs/ip_vs_ctl.c +++ b/net/ipv4/ipvs/ip_vs_ctl.c @@ -20,26 +20,14 @@ * */ -#include -#include -#include -#include -#include -#include #include -#include -#include -#include -#include - -#include #include #include #include #include -#include +//#include #include diff --git a/net/ipv4/ipvs/ip_vs_dh.c b/net/ipv4/ipvs/ip_vs_dh.c index 9fee19c..e40998c 100644 --- a/net/ipv4/ipvs/ip_vs_dh.c +++ b/net/ipv4/ipvs/ip_vs_dh.c @@ -38,8 +38,6 @@ */ #include -#include -#include #include #include diff --git a/net/ipv4/ipvs/ip_vs_est.c b/net/ipv4/ipvs/ip_vs_est.c index c453e1e..ce3d3c3 100644 --- a/net/ipv4/ipvs/ip_vs_est.c +++ b/net/ipv4/ipvs/ip_vs_est.c @@ -13,12 +13,8 @@ * Changes: * */ -#include -#include #include #include -#include -#include #include diff --git a/net/ipv4/ipvs/ip_vs_ftp.c b/net/ipv4/ipvs/ip_vs_ftp.c index a19a33c..ab730b1 100644 --- a/net/ipv4/ipvs/ip_vs_ftp.c +++ b/net/ipv4/ipvs/ip_vs_ftp.c @@ -24,13 +24,7 @@ * */ -#include -#include -#include #include -#include -#include -#include #include #include diff --git a/net/ipv4/ipvs/ip_vs_lblc.c b/net/ipv4/ipvs/ip_vs_lblc.c index 6e5cb92..ae51ae8 100644 --- a/net/ipv4/ipvs/ip_vs_lblc.c +++ b/net/ipv4/ipvs/ip_vs_lblc.c @@ -42,14 +42,8 @@ */ #include -#include -#include #include -/* for sysctl */ -#include -#include - #include diff --git a/net/ipv4/ipvs/ip_vs_lblcr.c b/net/ipv4/ipvs/ip_vs_lblcr.c index 32ba37b..ebe05a8 100644 --- a/net/ipv4/ipvs/ip_vs_lblcr.c +++ b/net/ipv4/ipvs/ip_vs_lblcr.c @@ -40,16 +40,8 @@ */ #include -#include -#include #include -/* for sysctl */ -#include -#include -/* for proc_net_create/proc_net_remove */ -#include - #include diff --git a/net/ipv4/ipvs/ip_vs_lc.c b/net/ipv4/ipvs/ip_vs_lc.c index d88fef9..db63c0f 100644 --- a/net/ipv4/ipvs/ip_vs_lc.c +++ b/net/ipv4/ipvs/ip_vs_lc.c @@ -17,7 +17,6 @@ */ #include -#include #include diff --git a/net/ipv4/ipvs/ip_vs_nq.c b/net/ipv4/ipvs/ip_vs_nq.c index bc2a9e5..f1b4341 100644 --- a/net/ipv4/ipvs/ip_vs_nq.c +++ b/net/ipv4/ipvs/ip_vs_nq.c @@ -34,7 +34,6 @@ */ #include -#include #include diff --git a/net/ipv4/ipvs/ip_vs_proto.c b/net/ipv4/ipvs/ip_vs_proto.c index 867d4e9..9084338 100644 --- a/net/ipv4/ipvs/ip_vs_proto.c +++ b/net/ipv4/ipvs/ip_vs_proto.c @@ -15,17 +15,8 @@ * */ -#include -#include #include -#include -#include -#include #include -#include -#include -#include -#include #include diff --git a/net/ipv4/ipvs/ip_vs_proto_ah.c b/net/ipv4/ipvs/ip_vs_proto_ah.c index 8b0505b..cb95f58 100644 --- a/net/ipv4/ipvs/ip_vs_proto_ah.c +++ b/net/ipv4/ipvs/ip_vs_proto_ah.c @@ -14,
Re: [PATCH][RFC] Shrink ip_vs_*.c includes
In gmane.comp.linux.lvs.user Roberto Nibali <[EMAIL PROTECTED]> wrote:
>>>> CONFIG_IP_VS=m
>>>> # CONFIG_IP_VS_DEBUG is not set
>>>> CONFIG_IP_VS_TAB_BITS=12
>>>> CONFIG_IP_VS_PROTO_TCP=y
>>>> CONFIG_IP_VS_PROTO_UDP=y
>>>> CONFIG_IP_VS_PROTO_ESP=y
>>>> CONFIG_IP_VS_PROTO_AH=y
>
> These 'y' caused me to think that it wasn't modular.
Me too :)
>>>> CONFIG_IP_VS_RR=m
>>>> CONFIG_IP_VS_WRR=m
>>>> CONFIG_IP_VS_LC=m
>>>> CONFIG_IP_VS_WLC=m
>>>> CONFIG_IP_VS_LBLC=m
>>>> CONFIG_IP_VS_LBLCR=m
>>>> CONFIG_IP_VS_DH=m
>>>> CONFIG_IP_VS_SH=m
>>>> CONFIG_IP_VS_SED=m
>>>> CONFIG_IP_VS_NQ=m
>>>> CONFIG_IP_VS_FTP=m
>>> Ok, this is m/y mixed. Haven't tried it yet.
>>
>> Actually, I think that its completely modular.
>
> So why the heck didn't it trigger on my system? Is it because the
> include/net/* headers are not always included on ia64? Well, tant pis!
I can reproduce the problem on x86 too.
>>> I'll reproduce it with your config. I didn't think of trying it with
>>> mixed y/m settings. Following include is missing then:
>>>
>>> #include
>>
>> Thanks, I found that linux/module.h was also needed.
>
> Ok. I thought this would get included by any of the other headers. Well,
> so long as it also compiles fine on your system, I'm good.
>
>> After putting those two back into ip_vs_conn.c the build went
>> find. I also tried a few other combinations, all on ia64, without issue.
>> My diff is below. Could you recheck it?
>
> Seems fine to me, thanks for testing this. I would have felt really bad
> if I broke IPVS in mainline because of such changes.
>
>>> Or do you think we could put all the needed includes into ip_vs.h and
>>> simply be done with it?
>>
>> I spoke breifly with Dave about this, and he isn't very keen on it.
>
> Fair enough.
>
>> The problem with that approach, is that while its less work to
>> maintain the headers by hand, it will likely result in uneeded
>> includes in some cases.
>
> How so? All includes nota bene have the prevailing:
>
> #ifndef _FOOBAR_H
> #define _FOOBAR_H
> [...]
> #endif /* _FOOBAR_H */
>
> framework. So would this speak slightely against that?
I dare say that they do. However thats actually not the issue at hand.
The problem is, lets say that a.h is listed in ip_vs.h because
some of ipvs/*.c need it. Well, a.h is going to end up inclded in
all of ipvs/*.c, even the ones that don't need it, and thus would
otherwise not have it (assuming that we prune things by hand,
as you have done). So if a.h gets touched, for some reason,
then all of ipvs/*.c will be recompiled, some of which is not
neccessary.
This of course assumes that there is some variance in the includes
needed by the ipvs/*.c files. I think that is a fair assumption, though
I haven't done any analysis on it. Its also a reasonable expectation
that this could be the case in the future, even if it is not the case
now.
> Also, from the
> includes we take today, I reckon that in the end we half of the
> include/{net,linux}/*.h is in our objects :). But you guys decide. I
> could maybe run a call-graph.
Thats a slightly different issue. Perhaps the headers should be cleaned
up a little. But at least by taking the approach that your current patch
does, IPVS can get the benifit of any subsequent cleanups, rather than
partially annuling them.
>> So all of LVS will get built when
>> a given header is touched, where perhaps only half of it needed
>> to be built.
>
> Well, it does not happen so ofter that a core network related header is
> touched to my avail.
That I would tend to agree with. But Dave seemed to think it is worth
the effort to break the headers out in IPVS, as they currently are.
And I think its reasonable enough.
>> So with that in mind, could you continue in the vein of
>> your original patch?
>
> Sure thing. Your attached patch is fine; if you feel confident with our
> changes, submit it.
Will do. I'll drop the lvs-users CC as its a closed list whereas
netdev isn't. For the benifit of people who are on lvs-users and not
netdev, the patch will be the same as what I posted yesterday.
--
Horms
-
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][RFC] Shrink ip_vs_*.c includes
In gmane.comp.linux.lvs.user Roberto Nibali <[EMAIL PROTECTED]> wrote: >> Hi Rats, >> >> I'm all for this patch, but I get horrible breakage with the following >> config (I can give the rest if you need it). > > Darn! > >> CONFIG_IP_VS=m >> # CONFIG_IP_VS_DEBUG is not set >> CONFIG_IP_VS_TAB_BITS=12 >> CONFIG_IP_VS_PROTO_TCP=y >> CONFIG_IP_VS_PROTO_UDP=y >> CONFIG_IP_VS_PROTO_ESP=y >> CONFIG_IP_VS_PROTO_AH=y >> CONFIG_IP_VS_RR=m >> CONFIG_IP_VS_WRR=m >> CONFIG_IP_VS_LC=m >> CONFIG_IP_VS_WLC=m >> CONFIG_IP_VS_LBLC=m >> CONFIG_IP_VS_LBLCR=m >> CONFIG_IP_VS_DH=m >> CONFIG_IP_VS_SH=m >> CONFIG_IP_VS_SED=m >> CONFIG_IP_VS_NQ=m >> CONFIG_IP_VS_FTP=m > > Ok, this is m/y mixed. Haven't tried it yet. Actually, I think that its completely modular. [snip] > I'll reproduce it with your config. I didn't think of trying it with > mixed y/m settings. Following include is missing then: > > #include Thanks, I found that linux/module.h was also needed. After putting those two back into ip_vs_conn.c the build went find. I also tried a few other combinations, all on ia64, without issue. My diff is below. Could you recheck it? > Or do you think we could put all the needed includes into ip_vs.h and > simply be done with it? I spoke breifly with Dave about this, and he isn't very keen on it. The problem with that approach, is that while its less work to maintain the headers by hand, it will likely result in uneeded includes in some cases. So all of LVS will get built when a given header is touched, where perhaps only half of it needed to be built. So with that in mind, could you continue in the vein of your original patch? -- Horms Hello, This patch against the latest GIT HEAD reduces the includes to the necessary ones. I've compile-tested it against following (and s/y/m/) configuration on x86: CONFIG_IP_VS=y CONFIG_IP_VS_DEBUG=y CONFIG_IP_VS_TAB_BITS=12 CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_RR=y CONFIG_IP_VS_WRR=y CONFIG_IP_VS_LC=y CONFIG_IP_VS_WLC=y CONFIG_IP_VS_LBLC=y CONFIG_IP_VS_LBLCR=y CONFIG_IP_VS_DH=y CONFIG_IP_VS_SH=y CONFIG_IP_VS_SED=y CONFIG_IP_VS_NQ=y CONFIG_IP_VS_FTP=y Please consider applying (but test it first on your local tree since we don't want stupid breakage resulting from such changes). Alternatively/additionally I could envision a patch on top of this one that completely removes the includes from the ../net/ipv4/ipvs/*.c except the ../include/net/ip_vs.h, which would carry all the needed header includes. Signed-off-by: Roberto Nibali <[EMAIL PROTECTED]> Signed-off-by: Horms <[EMAIL PROTECTED]> diff --git a/net/ipv4/ipvs/ip_vs_app.c b/net/ipv4/ipvs/ip_vs_app.c index 9b176a9..9f5676b 100644 --- a/net/ipv4/ipvs/ip_vs_app.c +++ b/net/ipv4/ipvs/ip_vs_app.c @@ -20,17 +20,9 @@ * */ -#include -#include #include -#include -#include -#include #include -#include -#include #include -#include #include diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c index 87b8381..157b9ad 100644 --- a/net/ipv4/ipvs/ip_vs_conn.c +++ b/net/ipv4/ipvs/ip_vs_conn.c @@ -24,13 +24,12 @@ * */ -#include #include #include -#include #include +#include #include -#include /* for proc_net_* */ +#include #include #include #include diff --git a/net/ipv4/ipvs/ip_vs_core.c b/net/ipv4/ipvs/ip_vs_core.c index 3f47ad8..927fbc0 100644 --- a/net/ipv4/ipvs/ip_vs_core.c +++ b/net/ipv4/ipvs/ip_vs_core.c @@ -26,19 +26,13 @@ * */ -#include -#include -#include #include #include #include -#include -#include #include/* for icmp_send */ -#include +#include /* for inet_addr_type */ -#include #include #include diff --git a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c index 7f0288b..a130c5f 100644 --- a/net/ipv4/ipvs/ip_vs_ctl.c +++ b/net/ipv4/ipvs/ip_vs_ctl.c @@ -20,26 +20,14 @@ * */ -#include -#include -#include -#include -#include -#include #include -#include -#include -#include -#include - -#include #include #include #include #include -#include +//#include #include diff --git a/net/ipv4/ipvs/ip_vs_dh.c b/net/ipv4/ipvs/ip_vs_dh.c index 9fee19c..e40998c 100644 --- a/net/ipv4/ipvs/ip_vs_dh.c +++ b/net/ipv4/ipvs/ip_vs_dh.c @@ -38,8 +38,6 @@ */ #include -#include -#include #include #include diff --git a/net/ipv4/ipvs/ip_vs_est.c b/net/ipv4/ipvs/ip_vs_est.c index c453e1e..ce3d3c3 100644 --- a/net/ipv4/ipvs/ip_vs_est.c +++ b/net/ipv4/ipvs/ip_vs_est.c @@ -13,12 +13,8 @@ * Changes: * */ -#include -#include #include #include -#include -#include #include diff --git a/net/ipv4/ipvs/ip_vs_ftp.c b/net/ipv4/ipvs/ip_vs_ftp.c index a19a33c..ab
Re: [PATCH][RFC] Shrink ip_vs_*.c includes
On Mon, Feb 06, 2006 at 01:48:33AM +0100, Roberto Nibali wrote: > Hello, > > This patch against the latest GIT HEAD reduces the includes to the > necessary ones. I've compile-tested it against following (and s/y/m/) > configuration on x86: > > CONFIG_IP_VS=y > CONFIG_IP_VS_DEBUG=y > CONFIG_IP_VS_TAB_BITS=12 > CONFIG_IP_VS_PROTO_TCP=y > CONFIG_IP_VS_PROTO_UDP=y > CONFIG_IP_VS_PROTO_ESP=y > CONFIG_IP_VS_PROTO_AH=y > CONFIG_IP_VS_RR=y > CONFIG_IP_VS_WRR=y > CONFIG_IP_VS_LC=y > CONFIG_IP_VS_WLC=y > CONFIG_IP_VS_LBLC=y > CONFIG_IP_VS_LBLCR=y > CONFIG_IP_VS_DH=y > CONFIG_IP_VS_SH=y > CONFIG_IP_VS_SED=y > CONFIG_IP_VS_NQ=y > CONFIG_IP_VS_FTP=y > > Please consider applying (but test it first on your local tree since we > don't want stupid breakage resulting from such changes). > > Alternatively/additionally I could envision a patch on top of this one > that completely removes the includes from the ../net/ipv4/ipvs/*.c > except the ../include/net/ip_vs.h, which would carry all the needed > header includes. Hi Rats, I'm all for this patch, but I get horrible breakage with the following config (I can give the rest if you need it). CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m # make CHK include/linux/version.h CHK include/linux/compile.h CHK usr/initramfs_list CC [M] net/ipv4/ipvs/ip_vs_conn.o net/ipv4/ipvs/ip_vs_conn.c: In function 'ip_vs_conn_array': net/ipv4/ipvs/ip_vs_conn.c:672: error: dereferencing pointer to incomplete type net/ipv4/ipvs/ip_vs_conn.c: In function 'ip_vs_conn_seq_start': net/ipv4/ipvs/ip_vs_conn.c:684: error: dereferencing pointer to incomplete type net/ipv4/ipvs/ip_vs_conn.c:685: error: 'SEQ_START_TOKEN' undeclared (first use in this function) net/ipv4/ipvs/ip_vs_conn.c:685: error: (Each undeclared identifier is reported only once net/ipv4/ipvs/ip_vs_conn.c:685: error: for each function it appears in.) net/ipv4/ipvs/ip_vs_conn.c: In function 'ip_vs_conn_seq_next': net/ipv4/ipvs/ip_vs_conn.c:691: error: dereferencing pointer to incomplete type net/ipv4/ipvs/ip_vs_conn.c:695: error: 'SEQ_START_TOKEN' undeclared (first use in this function) net/ipv4/ipvs/ip_vs_conn.c:708: error: dereferencing pointer to incomplete type net/ipv4/ipvs/ip_vs_conn.c:713: error: dereferencing pointer to incomplete type net/ipv4/ipvs/ip_vs_conn.c: In function 'ip_vs_conn_seq_stop': net/ipv4/ipvs/ip_vs_conn.c:719: error: dereferencing pointer to incomplete type net/ipv4/ipvs/ip_vs_conn.c: In function 'ip_vs_conn_seq_show': net/ipv4/ipvs/ip_vs_conn.c:728: error: 'SEQ_START_TOKEN' undeclared (first use in this function) net/ipv4/ipvs/ip_vs_conn.c:729: warning: implicit declaration of function 'seq_puts' net/ipv4/ipvs/ip_vs_conn.c:734: warning: implicit declaration of function 'seq_printf' net/ipv4/ipvs/ip_vs_conn.c: At top level: net/ipv4/ipvs/ip_vs_conn.c:746: error: variable 'ip_vs_conn_seq_ops' has initializer but incomplete type net/ipv4/ipvs/ip_vs_conn.c:747: error: unknown field 'start' specified in initializer net/ipv4/ipvs/ip_vs_conn.c:747: warning: excess elements in struct initializer net/ipv4/ipvs/ip_vs_conn.c:747: warning: (near initialization for 'ip_vs_conn_seq_ops') net/ipv4/ipvs/ip_vs_conn.c:748: error: unknown field 'next' specified in initializer net/ipv4/ipvs/ip_vs_conn.c:748: warning: excess elements in struct initializer net/ipv4/ipvs/ip_vs_conn.c:748: warning: (near initialization for 'ip_vs_conn_seq_ops') net/ipv4/ipvs/ip_vs_conn.c:749: error: unknown field 'stop' specified in initializer net/ipv4/ipvs/ip_vs_conn.c:749: warning: excess elements in struct initializer net/ipv4/ipvs/ip_vs_conn.c:749: warning: (near initialization for 'ip_vs_conn_seq_ops') net/ipv4/ipvs/ip_vs_conn.c:750: error: unknown field 'show' specified in initializer net/ipv4/ipvs/ip_vs_conn.c:750: warning: excess elements in struct initializer net/ipv4/ipvs/ip_vs_conn.c:750: warning: (near initialization for 'ip_vs_conn_seq_ops') net/ipv4/ipvs/ip_vs_conn.c: In function 'ip_vs_conn_open': net/ipv4/ipvs/ip_vs_conn.c:755: warning: implicit declaration of function 'seq_open' net/ipv4/ipvs/ip_vs_conn.c: At top level: net/ipv4/ipvs/ip_vs_conn.c:759: error: 'THIS_MODULE' undeclared here (not in a function) net/ipv4/ipvs/ip_vs_conn.c:761: error: 'seq_read' undeclared here (not in a function) net/ipv4/ipvs/ip_vs_conn.c:762:
[PATCH] [IPV4] Document icmp_errors_use_inbound_ifaddr sysctl
(Sorry for the duplicate if you see it, the first attempt was to the old netdev addr) Taken largely from the commit of the patch that added this feature http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c2fb7f93cb20621772bf304f3dba0849942e5db I'm not sure about the ordering of the options in sysctl.txt, so I took a wild guess about where it fits. Signed-Off-By: Horms <[EMAIL PROTECTED]> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 2b7cf19..26364d0 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -427,6 +427,23 @@ icmp_ignore_bogus_error_responses - BOOL will avoid log file clutter. Default: FALSE +icmp_errors_use_inbound_ifaddr - BOOLEAN + + If zero, icmp error messages are sent with the primary address of + the exiting interface. + + If non-zero, the message will be sent with the primary address of + the interface that received the packet that caused the icmp error. + This is the behaviour network many administrators will expect from + a router. And it can make debugging complicated network layouts + much easier. + + Note that if no primary address exists for the interface selected, + then the primary address of the first non-loopback interface that + has one will be used regarldess of this setting. + + Default: 0 + igmp_max_memberships - INTEGER Change the maximum number of multicast groups we can subscribe to. Default: 20 - End forwarded message - -- Horms - 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] Remove suprious use of goto out: in icmp_reply
This seems to be an artifact of the follwoing commit in February '02. http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=history;h=e7e173af42dbf37b1d946f9ee00219cb3b2bea6a;f=net/ipv4/icmp.c In a nutshell, goto out and return actually do the same thing, and both are called in this function. This patch removes out. Signed-Off-By: Horms <[EMAIL PROTECTED]> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c index be5a519..eadbd55 100644 --- a/net/ipv4/icmp.c +++ b/net/ipv4/icmp.c @@ -385,7 +385,7 @@ static void icmp_reply(struct icmp_bxm * u32 daddr; if (ip_options_echo(&icmp_param->replyopts, skb)) - goto out; + return; if (icmp_xmit_lock()) return; @@ -416,7 +416,6 @@ static void icmp_reply(struct icmp_bxm * ip_rt_put(rt); out_unlock: icmp_xmit_unlock(); -out:; } - 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] fix ipvs compilation
On Thu, Jan 05, 2006 at 05:08:23PM +0100, Roberto Nibali wrote: > >>Sidenote: At first I was a bit confused as to why this broke since my > >>local copy of IPVS still works. But to be honest, I would like to clean > >>up the IPVS headers in general. I believe we can cut short maybe half of > >>the includes in the various ip_vs* modules. > > > >Cool, if nobody beats me to it I'll eventually get to cleanup the > >header usage in > >ipvs, but its not something pressing, I just don't like the include > >hell and from time > >to time clean it up a bit when adding new abstractions :-) > > Go for it, some of the headers are remnants of the 2.4 kernel and said > new abstractions. I will try to move some functionality into ip_vs.h, > which should be the only place with a large number of includes anyway. > > Of course Horms has to ack all of this, but I don't think he'll object, > so long as everything still compiles and works like before. BTW, Adrian, > if you have some time and lust and haven't gone through the ../ipvs/ > directory yet, your excellent cleanups are also very much appreciated :). Indeed, I have no objections to cleanups in ipvs/ -- Horms - 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] fix ipvs compilation
On Thu, Jan 05, 2006 at 03:34:09PM +0100, Roberto Nibali wrote: > [trimmed recipients a bit] > > >> CC net/ipv4/ipvs/ip_vs_sched.o > >>net/ipv4/ipvs/ip_vs_sched.c: In function 'ip_vs_sched_getbyname': > >>net/ipv4/ipvs/ip_vs_sched.c:110: warning: implicit declaration of > >>function 'local_bh_disable' > >>net/ipv4/ipvs/ip_vs_sched.c:124: warning: implicit declaration of > >>function 'local_bh_enable' > > > > > >Thanks Adrian, its related to some header sanitization work I did. > > > >Acked-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> > > Thanks for the heads-up and Adrian for the fix. Indeed. I notice that its now in Linus' tree, which is more than fine by me. -- Horms - 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-2.6] cleanup IP_VS_DBG statements
Dave, please apply.
--
Horms
tree 60d9ec661356d90c826b9e95d9d1feac04df0ceb
parent d7ba5e23dc0661bc1e79593e0a6fbd424def3dcb
author Horms <[EMAIL PROTECTED]> Fri, 30 Dec 2005 12:58:16 +0900
committer Horms <[EMAIL PROTECTED]> Fri, 30 Dec 2005 12:58:16 +0900
[PATCH-2.6] cleanup IP_VS_DBG statements
Hello,
The attached patch (against current -GIT) is a cleanup patch which does
following:
o lookup debug messages shifted back to 9
o added more informational value to flags and refcnt since those
entries can be in multiple referenced structures
o cleanup 80 char violation
It's the prepatch to the session pool implementation and helps very much
to debug and monitor important variables and structures regarding the
threshold limitation and persistency without the thousands of lookup
messages which noone is interested in.
Please consider applying,
Roberto Nibali, ratz
Signed-Off-By: Horms <[EMAIL PROTECTED]>
diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c
index 2a3a8c5..18b65c5 100644
--- a/net/ipv4/ipvs/ip_vs_conn.c
+++ b/net/ipv4/ipvs/ip_vs_conn.c
@@ -219,7 +219,7 @@ struct ip_vs_conn *ip_vs_conn_in_get
if (!cp && atomic_read(&ip_vs_conn_no_cport_cnt))
cp = __ip_vs_conn_in_get(protocol, s_addr, 0, d_addr, d_port);
- IP_VS_DBG(7, "lookup/in %s %u.%u.%u.%u:%d->%u.%u.%u.%u:%d %s\n",
+ IP_VS_DBG(9, "lookup/in %s %u.%u.%u.%u:%d->%u.%u.%u.%u:%d %s\n",
ip_vs_proto_name(protocol),
NIPQUAD(s_addr), ntohs(s_port),
NIPQUAD(d_addr), ntohs(d_port),
@@ -254,7 +254,7 @@ struct ip_vs_conn *ip_vs_ct_in_get
out:
ct_read_unlock(hash);
- IP_VS_DBG(7, "template lookup/in %s %u.%u.%u.%u:%d->%u.%u.%u.%u:%d
%s\n",
+ IP_VS_DBG(9, "template lookup/in %s %u.%u.%u.%u:%d->%u.%u.%u.%u:%d
%s\n",
ip_vs_proto_name(protocol),
NIPQUAD(s_addr), ntohs(s_port),
NIPQUAD(d_addr), ntohs(d_port),
@@ -295,7 +295,7 @@ struct ip_vs_conn *ip_vs_conn_out_get
ct_read_unlock(hash);
- IP_VS_DBG(7, "lookup/out %s %u.%u.%u.%u:%d->%u.%u.%u.%u:%d %s\n",
+ IP_VS_DBG(9, "lookup/out %s %u.%u.%u.%u:%d->%u.%u.%u.%u:%d %s\n",
ip_vs_proto_name(protocol),
NIPQUAD(s_addr), ntohs(s_port),
NIPQUAD(d_addr), ntohs(d_port),
@@ -391,8 +391,9 @@ ip_vs_bind_dest(struct ip_vs_conn *cp, s
cp->flags |= atomic_read(&dest->conn_flags);
cp->dest = dest;
- IP_VS_DBG(9, "Bind-dest %s c:%u.%u.%u.%u:%d v:%u.%u.%u.%u:%d "
- "d:%u.%u.%u.%u:%d fwd:%c s:%u flg:%X cnt:%d destcnt:%d\n",
+ IP_VS_DBG(7, "Bind-dest %s c:%u.%u.%u.%u:%d v:%u.%u.%u.%u:%d "
+ "d:%u.%u.%u.%u:%d fwd:%c s:%u conn->flags:%X conn->refcnt:%d "
+ "dest->refcnt:%d\n",
ip_vs_proto_name(cp->protocol),
NIPQUAD(cp->caddr), ntohs(cp->cport),
NIPQUAD(cp->vaddr), ntohs(cp->vport),
@@ -430,8 +431,9 @@ static inline void ip_vs_unbind_dest(str
if (!dest)
return;
- IP_VS_DBG(9, "Unbind-dest %s c:%u.%u.%u.%u:%d v:%u.%u.%u.%u:%d "
- "d:%u.%u.%u.%u:%d fwd:%c s:%u flg:%X cnt:%d destcnt:%d\n",
+ IP_VS_DBG(7, "Unbind-dest %s c:%u.%u.%u.%u:%d v:%u.%u.%u.%u:%d "
+ "d:%u.%u.%u.%u:%d fwd:%c s:%u conn->flags:%X conn->refcnt:%d "
+ "dest->refcnt:%d\n",
ip_vs_proto_name(cp->protocol),
NIPQUAD(cp->caddr), ntohs(cp->cport),
NIPQUAD(cp->vaddr), ntohs(cp->vport),
@@ -571,7 +573,7 @@ static void ip_vs_conn_expire(unsigned l
ip_vs_conn_hash(cp);
expire_later:
- IP_VS_DBG(7, "delayed: refcnt-1=%d conn.n_control=%d\n",
+ IP_VS_DBG(7, "delayed: conn->refcnt-1=%d conn->n_control=%d\n",
atomic_read(&cp->refcnt)-1,
atomic_read(&cp->n_control));
diff --git a/net/ipv4/ipvs/ip_vs_core.c b/net/ipv4/ipvs/ip_vs_core.c
index 1a0843c..1aca94a 100644
--- a/net/ipv4/ipvs/ip_vs_core.c
+++ b/net/ipv4/ipvs/ip_vs_core.c
@@ -426,7 +426,7 @@ ip_vs_schedule(struct ip_vs_service *svc
return NULL;
IP_VS_DBG(6, "Schedule fwd:%c c:%u.%u.%u.%u:%u v:%u.%u.%u.%u:%u "
- "d:%u.%u.%u.%u:%u flg:%X cnt:%d\n",
+ "d:%u.%u.%u.%u:%u conn->flags:%X conn->refcnt:%d\n",
ip_vs_fwd_tag(cp),
NIPQUAD(cp->caddr), ntohs(cp->cport),
NIPQUAD(cp->vaddr)
[IPVS] remove dead code
ip_vs_app.c | 28
ip_vs_lblc.c | 27 ---
ip_vs_lblcr.c | 27 ---
ip_vs_proto_tcp.c | 22 --
4 files changed, 104 deletions(-)
Please apply
--
Horms
[IPVS] remove dead code
This patch removes dead code. I don't see the reason to keep this cruft
around, besides cluttering the nice and functionally working code.
Trivial, please apply.
Signed-off-by: Roberto Nibali <[EMAIL PROTECTED]>
Signed-off-by: Horms <[EMAIL PROTECTED]>
diff --git a/net/ipv4/ipvs/ip_vs_app.c b/net/ipv4/ipvs/ip_vs_app.c
index d7eb680..9b176a9 100644
--- a/net/ipv4/ipvs/ip_vs_app.c
+++ b/net/ipv4/ipvs/ip_vs_app.c
@@ -224,34 +224,6 @@ void unregister_ip_vs_app(struct ip_vs_a
}
-#if
-/*
- * Get reference to app by name (called from user context)
- */
-struct ip_vs_app *ip_vs_app_get_by_name(char *appname)
-{
- struct ip_vs_app *app, *a = NULL;
-
- down(&__ip_vs_app_mutex);
-
- list_for_each_entry(ent, &ip_vs_app_list, a_list) {
- if (strcmp(app->name, appname))
- continue;
-
- /* softirq may call ip_vs_app_get too, so the caller
- must disable softirq on the current CPU */
- if (ip_vs_app_get(app))
- a = app;
- break;
- }
-
- up(&__ip_vs_app_mutex);
-
- return a;
-}
-#endif
-
-
/*
* Bind ip_vs_conn to its ip_vs_app (called by cp constructor)
*/
diff --git a/net/ipv4/ipvs/ip_vs_lblc.c b/net/ipv4/ipvs/ip_vs_lblc.c
index 561cda3..b6dad7e 100644
--- a/net/ipv4/ipvs/ip_vs_lblc.c
+++ b/net/ipv4/ipvs/ip_vs_lblc.c
@@ -228,33 +228,6 @@ ip_vs_lblc_hash(struct ip_vs_lblc_table
}
-#if
-/*
- * Unhash ip_vs_lblc_entry from ip_vs_lblc_table.
- * returns bool success.
- */
-static int ip_vs_lblc_unhash(struct ip_vs_lblc_table *tbl,
-struct ip_vs_lblc_entry *en)
-{
- if (list_empty(&en->list)) {
- IP_VS_ERR("ip_vs_lblc_unhash(): request for not hashed entry, "
- "called from %p\n", __builtin_return_address(0));
- return 0;
- }
-
- /*
-* Remove it from the table
-*/
- write_lock(&tbl->lock);
- list_del(&en->list);
- INIT_LIST_HEAD(&en->list);
- write_unlock(&tbl->lock);
-
- return 1;
-}
-#endif
-
-
/*
* Get ip_vs_lblc_entry associated with supplied parameters.
*/
diff --git a/net/ipv4/ipvs/ip_vs_lblcr.c b/net/ipv4/ipvs/ip_vs_lblcr.c
index ce456db..8c78ef7 100644
--- a/net/ipv4/ipvs/ip_vs_lblcr.c
+++ b/net/ipv4/ipvs/ip_vs_lblcr.c
@@ -414,33 +414,6 @@ ip_vs_lblcr_hash(struct ip_vs_lblcr_tabl
}
-#if
-/*
- * Unhash ip_vs_lblcr_entry from ip_vs_lblcr_table.
- * returns bool success.
- */
-static int ip_vs_lblcr_unhash(struct ip_vs_lblcr_table *tbl,
-struct ip_vs_lblcr_entry *en)
-{
- if (list_empty(&en->list)) {
- IP_VS_ERR("ip_vs_lblcr_unhash(): request for not hashed entry, "
- "called from %p\n", __builtin_return_address(0));
- return 0;
- }
-
- /*
-* Remove it from the table
-*/
- write_lock(&tbl->lock);
- list_del(&en->list);
- INIT_LIST_HEAD(&en->list);
- write_unlock(&tbl->lock);
-
- return 1;
-}
-#endif
-
-
/*
* Get ip_vs_lblcr_entry associated with supplied parameters.
*/
diff --git a/net/ipv4/ipvs/ip_vs_proto_tcp.c b/net/ipv4/ipvs/ip_vs_proto_tcp.c
index 0e878fd..638ba8c 100644
--- a/net/ipv4/ipvs/ip_vs_proto_tcp.c
+++ b/net/ipv4/ipvs/ip_vs_proto_tcp.c
@@ -275,28 +275,6 @@ static int tcp_timeouts[IP_VS_TCP_S_LAST
[IP_VS_TCP_S_LAST] = 2*HZ,
};
-
-#if 0
-
-/* FIXME: This is going to die */
-
-static int tcp_timeouts_dos[IP_VS_TCP_S_LAST+1] = {
- [IP_VS_TCP_S_NONE] = 2*HZ,
- [IP_VS_TCP_S_ESTABLISHED] = 8*60*HZ,
- [IP_VS_TCP_S_SYN_SENT] = 60*HZ,
- [IP_VS_TCP_S_SYN_RECV] = 10*HZ,
- [IP_VS_TCP_S_FIN_WAIT] = 60*HZ,
- [IP_VS_TCP_S_TIME_WAIT] = 60*HZ,
- [IP_VS_TCP_S_CLOSE] = 10*HZ,
- [IP_VS_TCP_S_CLOSE_WAIT]= 60*HZ,
- [IP_VS_TCP_S_LAST_ACK] = 30*HZ,
- [IP_VS_TCP_S_LISTEN]= 2*60*HZ,
- [IP_VS_TCP_S_SYNACK]= 100*HZ,
- [IP_VS_TCP_S_LAST] = 2*HZ,
-};
-
-#endif
-
static char * tcp_state_name_table[IP_VS_TCP_S_LAST+1] = {
[IP_VS_TCP_S_NONE] = "NONE",
[IP_VS_TCP_S_ESTABLISHED] = "ESTABLISHED",
-
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: Bug#337089: linux-image-2.6.14-1-powerpc: add CONFIG_TCP_CONG_BIC=y
On Sat, Nov 05, 2005 at 07:24:41AM +1300, Ian McDonald wrote: > > > But Debian .config has CONFIG_TCP_CONG_BIC=m (CONFIG_TCP_CONG_*=m) which > > > makes NewReno default. So this is like a "regression". I'd like debian > > > kernel > > > to have CONFIG_TCP_CONG_BIC=y provided that one can easily switch to > > > another > > > algorithm (using /proc/sys/net/ipv4/tcp_congestion_control). > > > > could someone please comment on what a good default congestion > > algorithm setup for distribution kernels is? > > > If you want BIC as default then do as suggested here. My personal > opinion is that is the correct thing to do for a standard > distribution. Thanks, the suggestion above will be incporated into the next release. -- Horms - 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
