* [PATCH v2 0/2] CS89x0: add QQ2440 networking support
From: Domenico Andreoli @ 2011-03-14 13:46 UTC (permalink / raw)
To: David S. Miller, Andrew Morton; +Cc: linux-arm-kernel, netdev
Hi,
this patchset cleans some bit left from the CS89x0_NONISA_IRQ
transition and then enables the support of CS89x0 on QQ2440.
Thanks,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Changli Gao @ 2011-03-14 12:42 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1103141310140.27542@obet.zrqbmnf.qr>
On Mon, Mar 14, 2011 at 8:26 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Monday 2011-03-14 07:50, Changli Gao wrote:
>
>>We use the reply tuples when limiting the connections by the destination
>>addresses, however, in SNAT scenario, the final reply tuples won't be
>>ready until SNAT is done in POSTROUING or INPUT chain
>
> If I am not mistaken: if you do daddr counting, SNAT is irrelevant.
> Consider ruleset
> -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 1.2.3.4:80
> -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to 1.2.3.5:443
>
> The tuple will first be (as per conntrack -L):
> src=home dst=router src=router dst=home
> After DNAT:
> src=home dst=router src=1.2.3.4 dst=home
>
> Thus looking at the src of the reply tuple seems correct — at least this
> is what was wanted, counting per stashed servers (=1 customer), not per
> globally visible address.
>
Yes, you are correct only when there is no SNAT rule. If there is an SNAT rule:
-t nat -A POSTROUTING -p tcp --dport 80 -j SNAT --to-source 192.168.0.1
the final tuples will be:
src = home dst = router src=1.2.3.4 dst=192.168.0.1
However, the tuple saved by connlimit is src=1.2.3.4 dst=home, so this
conn will be removed later as there isn't any conntrack, which has
this tuple in any direction.
You can't prevent a user from doing such a configuration, although you
might think it is stupid to do that.
Thanks for your review.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Jan Engelhardt @ 2011-03-14 12:26 UTC (permalink / raw)
To: Changli Gao; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <1300085414-27275-1-git-send-email-xiaosuo@gmail.com>
On Monday 2011-03-14 07:50, Changli Gao wrote:
>We use the reply tuples when limiting the connections by the destination
>addresses, however, in SNAT scenario, the final reply tuples won't be
>ready until SNAT is done in POSTROUING or INPUT chain
If I am not mistaken: if you do daddr counting, SNAT is irrelevant.
Consider ruleset
-t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 1.2.3.4:80
-t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to 1.2.3.5:443
The tuple will first be (as per conntrack -L):
src=home dst=router src=router dst=home
After DNAT:
src=home dst=router src=1.2.3.4 dst=home
Thus looking at the src of the reply tuple seems correct — at least this
is what was wanted, counting per stashed servers (=1 customer), not per
globally visible address.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: dccp test-tree [RFC] [Patch 1/1] dccp: Only activate NN values after receiving the Confirm option
From: Gerrit Renker @ 2011-03-14 11:55 UTC (permalink / raw)
To: Samuel Jero; +Cc: dccp, netdev
In-Reply-To: <1300048497.31664.158.camel@jero-laptop>
[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]
Thank you for the comments, there is also some update (attached).
| > Well done, this looks good. I did some minor editing:
| > * whitespace/formatting/comments,
| > * simplification/subsumption,
| > * function should not be called for non-NN or non-known
| > feature, hence turned that into a DCCP_BUG() condition.
|
| Okay
|
I revised this some more, the function remains the same, but it is shorter
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=commitdiff;h=94da7d70003e8185fe189146f336db72c8fa1f0b
(If there is disagreement regarding allowing a get_nn_ function to query non-nn
features, I will add the test for type == NN back in.)
| > 1) Since ccid2_ack_ratio_next(sk) is just a wrapper around
| > dccp_feat_get_nn_next_val(sk, DCCPF_ACK_RATIO), ok to
| > use this instead?
|
| It's just fine to use dccp_feat_get_nn_next_val() instead. My primary
| reason for creating ccid2_ack_ratio_next() was to keep line lengths
| down.
|
Perhaps a shorter name, e.g. dccp_feat_nn_get()
(since it returns either the current or next value, and there is no other
accessor function defined).
| > 3) There is room for some refactoring:
| > a) dccp_feat_signal_nn_change() always implies also in part
| > dccp_feat_get_nn_next_val(): if the latter function returns
| > the same value as the supposedly 'new' one, it is not
| > necessary to start a new negotiation. So all the repeated
| > tests could be folded into that function.
|
|
| The problem here is that the ack ratio should only be changed after a
| loss, idle period, etc if the new cwnd is going to be less than the
| (negotiating) ack ratio. We need to call dccp_feat_get_nn_next_val() to
| decide whether we need to adjust the ack ratio or not.
|
That is a good point, maybe I need to reread the patch again. From what I saw,
dccp_nn_get_next_val() is so far only called immediately before changing the
value, whereas the above comment hints more at a peek/read-only functionality.
This understanding was also the basis of the attached patch - actually I was
quite happy since its use further simplified the interface.
I think once the above is resolved (which also includes the point below), then
there is quite a good milestone for ccid-2.
| We don't want to change the ack ratio every time we have a loss, etc.
| Doing so will result in pointless negotiations and more fluctuations in
| the ack ratio, neither of which is desirable.
|
Agree, having done some testing over the weekend I found that some kind of
hysteresis would be desirable.
I don't know if blocking the Ack Ratio code is the reason, but during the
initial slow-start there were ChangeL requests for Sequence Window on nearly
every packet, which seems too much.
If low_threshold == high_threshold, it oscillates. I think you have already done
some work on this in the code using CCID2_WIN_CHANGE_FACTOR.
During steady state of the connection I did not see many ChangeL requests.
[-- Attachment #2: simplify_dynamic_nn_negotation.diff --]
[-- Type: text/x-diff, Size: 1964 bytes --]
dccp ccid-2: use new interface to refactor dynamic negotiation
Using the new function dccp_feat_get_nn_next_val(), this simplifies existing
code to not trigger a new negotiation if the requested new value equals the
old one.
---
net/dccp/ccids/ccid2.c | 22 +++++-----------------
net/dccp/feat.c | 5 +++--
2 files changed, 8 insertions(+), 19 deletions(-)
--- a/net/dccp/feat.c
+++ b/net/dccp/feat.c
@@ -815,10 +815,11 @@ int dccp_feat_signal_nn_change(struct so
!dccp_feat_is_valid_nn_val(feat, nn_val))
return -EINVAL;
+ if (nn_val == dccp_feat_get_nn_next_val(sk, feat))
+ return 0; /* already set or negotiation under way */
+
entry = dccp_feat_list_lookup(fn, feat, 1);
if (entry != NULL) {
- if (entry->val.nn == fval.nn)
- return 0;
dccp_pr_debug("Clobbering existing NN entry %llu -> %llu\n",
(unsigned long long)entry->val.nn,
(unsigned long long)nn_val);
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -102,27 +102,15 @@ static void ccid2_change_l_ack_ratio(str
DCCP_WARN("Limiting Ack Ratio (%u) to %u\n", val, max_ratio);
val = max_ratio;
}
- if (val > DCCPF_ACK_RATIO_MAX)
- val = DCCPF_ACK_RATIO_MAX;
-
- if (val == ccid2_ack_ratio_next(sk))
- return;
-
- ccid2_pr_debug("changing local ack ratio to %u\n", val);
- dccp_feat_signal_nn_change(sk, DCCPF_ACK_RATIO, val);
+ dccp_feat_signal_nn_change(sk, DCCPF_ACK_RATIO,
+ min_t(u32, val, DCCPF_ACK_RATIO_MAX));
}
static void ccid2_change_l_seq_window(struct sock *sk, u64 val)
{
- struct dccp_sock *dp = dccp_sk(sk);
-
- if (val < DCCPF_SEQ_WMIN)
- val = DCCPF_SEQ_WMIN;
- if (val > DCCPF_SEQ_WMAX)
- val = DCCPF_SEQ_WMAX;
-
- if (val != dp->dccps_l_seq_win)
- dccp_feat_signal_nn_change(sk, DCCPF_SEQUENCE_WINDOW, val);
+ dccp_feat_signal_nn_change(sk, DCCPF_SEQUENCE_WINDOW,
+ clamp_val(val, DCCPF_SEQ_WMIN,
+ DCCPF_SEQ_WMAX));
}
static void ccid2_hc_tx_rto_expire(unsigned long data)
^ permalink raw reply
* [PATCH net-2.6] bnx2x: fix swap of rx-ticks and tx-ticks parameters in interrupt coalescing flow
From: Ariel Elior @ 2011-03-14 11:07 UTC (permalink / raw)
To: David Miller; +Cc: Eilon Greenstein, netdev
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index aa03233..10bc0a6 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -4208,7 +4208,7 @@ void bnx2x_update_coalesce(struct bnx2x *bp)
for_each_eth_queue(bp, i)
bnx2x_update_coalesce_sb(bp, bp->fp[i].fw_sb_id,
- bp->rx_ticks, bp->tx_ticks);
+ bp->tx_ticks, bp->rx_ticks);
}
static void bnx2x_init_sp_ring(struct bnx2x *bp)
--
1.7.4.1
^ permalink raw reply related
* Re: kernel 2.6.37 : oops in cleanup_once
From: Yann Dupont @ 2011-03-14 10:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1296659336.20445.22.camel@edumazet-laptop>
Le 02/02/2011 16:08, Eric Dumazet a écrit :
> I suspect a mem corruption from another layer (not inetpeer)
>
> Unfortunately many kmem caches share the "64 bytes" cache.
>
> Could you please add "slub_nomerge" on your boot command ?
>
...
>
>> -Is there a very severe impact on performance ?
>>
> not at all
>
Maybe there is an impact after all : since then, we don't have problems
anymore !
linkwood:~# uptime
11:42:03 up 39 days, 17:08, 3 users, load average: 0.01, 0.03, 0.05
So... could slub_nomerge hide or simply avoid the problem ?
Or are we just lucky this time ?
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
^ permalink raw reply
* Re: possible issue between bridge igmp/multicast handling & bnx2x on kernel 2.6.34 and >
From: Yann Dupont @ 2011-03-14 10:40 UTC (permalink / raw)
To: Yann Dupont; +Cc: Eric Dumazet, netdev
In-Reply-To: <4D495C39.6020002@univ-nantes.fr>
Le 02/02/2011 14:29, Yann Dupont a écrit :
>> Le vendredi 07 janvier 2011 à 11:40 +0100, Yann Dupont a écrit :
>>> Le 04/01/2011 14:40, Yann Dupont a écrit :
>>> ...
>>>> We just added BCM57711 10G cards (bnx2x driver) on our blade servers
>>>> (connected to 10G Power Connect M8024).
>>>> Since then, we are experiencing random lost of packets.
>>>>
>>>> Symptom : packets are lost on some vlans for a few seconds, then
>>>> things go back to normal (and stops again a few minutes later)
>>>>
>>> As I didn't had answer so far , I digged a little more and captured
>>> more
>>> packets.
>>> I just noticed that an event trigger that problem : IPv6 neighbor
>>> discovery packet .
>>>
>>> This is , of course, a multicast packet.
>>>
>>> Just saw that 2.6.36.3 should include this fix :
>>>
> Just a little update, the problem doesn't seem to be what we thought
> at first.
>
> It may not be related to the bnx2x driver after all.
> We noticed that we had the same symptoms on target machine using bnx2
> drivers (we missed that at first since the outages are way briefer).
>
> We're now rather suspecting our own firewall (also a linux in a kvm
> machine) since without it we don't get any more problem and the packet
> drops occurs on _THIS_ network, when packets are routed by _THIS_
> firewall.
>
> Anyway, all of that is very puzzling, we have made a lot of network
> dumps and we have really no clue of what's happening there.
> We don't understand why, if the problem is really on our firewall
> machine, setting CONFIG_BRIDGE_IGMP_SNOOPING to 'n' on the target
> machine efficiently fix the problem, Especially since it doesn't seem
> related at all with our setup and we don't see anything in our network
> dumps that could explain this.
>
> It's probably not a single problem, but a sum of different problems.
> We continue to search.
> Sorry for the noise.
>
> Regards,
>
One of my collegue noticied that :
https://lists.linux-foundation.org/pipermail/bridge/2010-October/007362.html
Exact same problem.
In fact, the problem **really** seems to be on the network switch.
Our servers are DELL M605 on a DELL M1000e chassis, with powerconnect
M6220 (G) and M8024 (10G)
IGMP snooping is also activated on those switches. If we turn igmp
snooping off on M8024 for exemple, we don't have problems anymore, that
is, we can activate IGMP snooping ON the linux bridge without loosing
packets.
M6220 & M8024 seems concerned. Time to make a bug report (again and
again...if you ask me, I can tell you they are crap.)
Sorry for the noise,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
^ permalink raw reply
* Re: [PATCH] macb: detect IP version to determin if we are on at91 or avr32
From: Jamie Iles @ 2011-03-14 10:39 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-arm-kernel, netdev, linux-kernel, Hans-Christian Egtvedt,
Nicolas Ferre, Jamie Iles
In-Reply-To: <1299863585-17263-1-git-send-email-plagnioj@jcrosoft.com>
Hi,
I agree with Russell's comments about providing a fake hclk to remove
the conditional clock stuff. I was planning on posting the patch below
in my next spin of the gem support patches which also renames macb_clk
to pclk to be consistent with avr32 and enables us to remove all of the
conditional clock stuff.
On Fri, Mar 11, 2011 at 06:13:05PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> this will make macb soc generic and will allow to use it on other arch
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Jamie Iles <jamie@jamieiles.com>
> ---
[...]
> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
> index d3212f6..56a4fcb 100644
> --- a/drivers/net/macb.h
> +++ b/drivers/net/macb.h
> @@ -59,6 +59,7 @@
> #define MACB_TPQ 0x00bc
> #define MACB_USRIO 0x00c0
> #define MACB_WOL 0x00c4
> +#define MACB_VERSION 0x00fc
>
> /* Bitfields in NCR */
> #define MACB_LB_OFFSET 0
> @@ -389,6 +390,14 @@ struct macb {
> unsigned int link;
> unsigned int speed;
> unsigned int duplex;
> +
> + uint32_t version;
Minor nitpick, this should be u32 to be consistent with the rest of the
fields.
> };
>
> +#define MACB_VERSION_MASK 0xffff0000
> +#define macb_is_at91(bp) \
> + (((bp)->version & MACB_VERSION_MASK) == 0x06010000)
> +#define macb_is_avr32(bp) \
> + (((bp)->version & MACB_VERSION_MASK) == 0x00010000)
> +
> #endif /* _MACB_H */
I can't convince myself that this is safe and correct. From the Cadence
GEM spec:
31:16 Module identification number - for the GEM, this
value is fixed at 0x0002.
15:0 Module revision - fixed byte value specific to the
revision of the design which is incremented after
each release of the IP.
I don't have access to the MACB spec, but it seems that 31:16 are
defined by Cadence so there could well be other chips with a module ID
of 0x0001 that aren't avr32.
We can certainly use this to tell us if we are GEM/MACB but if we need
to know if we are AT91/AVR32 for the RMII/MII USRIO stuff, then couldn't
we just keep the #ifdef CONFIG_ARCH_AT91 and factor that out into a
macb_set_usrio() type method?
Jamie
8<---------
diff --git a/arch/arm/mach-at91/at572d940hf.c b/arch/arm/mach-at91/at572d940hf.c
index a6b9c68..9b3a37e 100644
--- a/arch/arm/mach-at91/at572d940hf.c
+++ b/arch/arm/mach-at91/at572d940hf.c
@@ -71,10 +71,15 @@ static struct clk pioC_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT572D940HF_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
+static struct clk macb_hclk = {
+ .name = "hclk",
+ .pmc_mask = 0,
+ .type = CLK_TYPE_PERIPHERAL,
+};
static struct clk usart0_clk = {
.name = "usart0_clk",
.pmc_mask = 1 << AT572D940HF_ID_US0,
@@ -182,6 +187,7 @@ static struct clk *periph_clocks[] __initdata = {
&pioB_clk,
&pioC_clk,
&macb_clk,
+ &macb_hclk,
&usart0_clk,
&usart1_clk,
&usart2_clk,
diff --git a/arch/arm/mach-at91/at91cap9.c b/arch/arm/mach-at91/at91cap9.c
index 7337617..0d38ce7 100644
--- a/arch/arm/mach-at91/at91cap9.c
+++ b/arch/arm/mach-at91/at91cap9.c
@@ -150,10 +150,15 @@ static struct clk pwm_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT91CAP9_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
+static struct clk macb_hclk = {
+ .name = "hclk",
+ .pmc_mask = 0,
+ .type = CLK_TYPE_PERIPHERAL,
+};
static struct clk aestdes_clk = {
.name = "aestdes_clk",
.pmc_mask = 1 << AT91CAP9_ID_AESTDES,
@@ -212,6 +217,7 @@ static struct clk *periph_clocks[] __initdata = {
&tcb_clk,
&pwm_clk,
&macb_clk,
+ &macb_hclk,
&aestdes_clk,
&adc_clk,
&isi_clk,
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index 195208b..f00774c 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -162,10 +162,15 @@ static struct clk ohci_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT91SAM9260_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
+static struct clk macb_hclk = {
+ .name = "hclk",
+ .pmc_mask = 0,
+ .type = CLK_TYPE_PERIPHERAL,
+};
static struct clk isi_clk = {
.name = "isi_clk",
.pmc_mask = 1 << AT91SAM9260_ID_ISI,
@@ -221,6 +226,7 @@ static struct clk *periph_clocks[] __initdata = {
&tc2_clk,
&ohci_clk,
&macb_clk,
+ &macb_hclk,
&isi_clk,
&usart3_clk,
&usart4_clk,
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 249f900..25cbae1 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -136,10 +136,15 @@ static struct clk pwm_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT91SAM9263_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
+static struct clk macb_hclk = {
+ .name = "hclk",
+ .pmc_mask = 0,
+ .type = CLK_TYPE_PERIPHERAL,
+};
static struct clk dma_clk = {
.name = "dma_clk",
.pmc_mask = 1 << AT91SAM9263_ID_DMA,
@@ -190,6 +195,7 @@ static struct clk *periph_clocks[] __initdata = {
&tcb_clk,
&pwm_clk,
&macb_clk,
+ &macb_hclk,
&twodge_clk,
&udc_clk,
&isi_clk,
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index c67b47f..a4d4a2d 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -157,10 +157,15 @@ static struct clk ac97_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT91SAM9G45_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
+static struct clk macb_hclk = {
+ .name = "hclk",
+ .pmc_mask = 0,
+ .type = CLK_TYPE_PERIPHERAL,
+};
static struct clk isi_clk = {
.name = "isi_clk",
.pmc_mask = 1 << AT91SAM9G45_ID_ISI,
@@ -224,6 +229,7 @@ static struct clk *periph_clocks[] __initdata = {
&lcdc_clk,
&ac97_clk,
&macb_clk,
+ &macb_hclk,
&isi_clk,
&udphs_clk,
&mmc1_clk,
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] tcp: avoid cwnd moderation in undo
From: Carsten Wolff @ 2011-03-14 10:06 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, Ilpo Jarvinen, Nandita Dukkipati, netdev
In-Reply-To: <1299894051-13820-1-git-send-email-ycheng@google.com>
Hi,
On Saturday 12 March 2011, Yuchung Cheng wrote:
> In the current undo logic, cwnd is moderated after it was restored
> to the value prior entering fast-recovery. It was moderated first
> in tcp_try_undo_recovery then again in tcp_complete_cwr.
>
> Since the undo indicates recovery was false, these moderations
> are not necessary. If the undo is triggered when most of the
> outstanding data have been acknowledged, the (restored) cwnd is
> falsely pulled down to a small value.
>
> This patch removes these cwnd moderations if cwnd is undone during
> the fast-recovery.
The moderation is in place to avoid gigantic segment bursts, which could cause
unnecessary pressure on buffers. In my eyes it's already suboptimal that the
moderation is weakened in the presence of (detected) reordering, let alone
removing it completely.
More importantly, the prior ssthresh is restored and not affected by
moderation. This means, if moderation reduces cwnd to a small value, then cwnd
< ssthresh and TCP will quickly slow-start back to the previous state, without
sending a big burst of segments.
Also, you intended to remove cwnd moderation only from an undo during
recovery, but I think your patch also removes cwnd moderation when the undo is
caused by D-SACK, i.e. most likely after recovery already ended.
Carsten
--
/\-´-/\
( @ @ )
________o0O___^___O0o________
^ permalink raw reply
* Re: [PATCH] macb: detect IP version to determin if we are on at91 or avr32
From: Russell King - ARM Linux @ 2011-03-14 10:15 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-arm-kernel, netdev, Nicolas Ferre, linux-kernel, Jamie Iles,
Hans-Christian Egtvedt
In-Reply-To: <1299863585-17263-1-git-send-email-plagnioj@jcrosoft.com>
On Fri, Mar 11, 2011 at 06:13:05PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> + if (macb_is_at91(bp)) {
> + bp->pclk = clk_get(&pdev->dev, "macb_clk");
> + if (IS_ERR(bp->pclk)) {
> + dev_err(&pdev->dev, "failed to get macb_clk\n");
> + goto err_out_free_dev;
> + }
> + clk_enable(bp->pclk);
> + } else {
> + bp->pclk = clk_get(&pdev->dev, "pclk");
> + if (IS_ERR(bp->pclk)) {
> + dev_err(&pdev->dev, "failed to get pclk\n");
> + goto err_out_free_dev;
> + }
> + bp->hclk = clk_get(&pdev->dev, "hclk");
> + if (IS_ERR(bp->hclk)) {
> + dev_err(&pdev->dev, "failed to get hclk\n");
> + goto err_out_put_pclk;
> + }
> +
> + clk_enable(bp->pclk);
> + clk_enable(bp->hclk);
> + }
This is the same kind of sillyness that started getting OMAP into problems
with the clk API. Just do this instead:
bp->pclk = clk_get(&pdev->dev, "pclk");
if (IS_ERR(bp->pclk)) {
dev_err(&pdev->dev, "failed to get pclk\n");
goto err_out_free_dev;
}
bp->hclk = clk_get(&pdev->dev, "hclk");
if (IS_ERR(bp->hclk)) {
dev_err(&pdev->dev, "failed to get hclk\n");
goto err_out_put_pclk;
}
clk_enable(bp->pclk);
clk_enable(bp->hclk);
And then require _all_ platforms using this driver to provide a pclk and
a hclk for this device, whether they exist in the SoC or not. Where they
don't, provide dummy clocks for it.
This probably means you end up with _less_ bloat overall because you're
not having to build the above code. You've less lines of source code to
maintain. You have a simplified dirver with consistent requirements
across all platforms. You don't need to read the version register, and
you don't need macb_is_at91() and macb_is_avr32().
With clkdev it's _cheap_ to provide these dummy clocks once you have one
dummy clock already in place.
^ permalink raw reply
* Re: sky2, vlan and nat/masquerading
From: Christian Hesse @ 2011-03-14 10:11 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev
In-Reply-To: <AANLkTi=AJJA0d0=CFuS66=+O6b80Ejj0w3NfKQ+OWzsK@mail.gmail.com>
On Fri, 11 Mar 2011 16:39:02 -0800 Jesse Gross <jesse@nicira.com> wrote:
> On Wed, Mar 9, 2011 at 9:15 AM, Christian Hesse <mail@eworm.de> wrote:
> > Hello everybody,
> >
> > I have a Samsung NF310, running kernel 2.6.37.3 with a patch to make my
> > ethernet controller work for vlans. It was discussed with the subject
> > "sky2: convert to new VLAN model (v0.2)" and made it to to kernel tree
> > with commit 86aa77854f47ab6f5f9c687507af1f57d2b89004.
>
> Does that commit actually change the behavior that you are seeing? It
> shouldn't be necessary for correct functionality.
Plain 2.6.37 did not work at all. Received packets with vlan tag did not make
it to the vlan interface but ended on the native ethernet interface iirc.
> Do you know if this
> worked at some point in the past?
This was the first time I used nat with two vlan interfaces.
> > However it does not work properly, here are the details:
> >
> > * Switch with one trunk port and several port in corresponding vlan ports
> > * Host connected to one of the vlan ports
> > * Samsung Netbook (see above) connected to the trunk port.
> >
> > I get an IP address 192.168.x.x/24 via DHCP on interface connected to
> > vlan 1. The interface connected to vlan 2 has 172.16.0.1/24 and serves
> > addresses via DHCP. The system is set up to masquerade from 172.16.0.1/24.
> >
> > I can access my netbook from the host in vlan 2, however I can not access
> > anything behind. The packets contain a broken vlan tag and the host does
> > not recognize them.
>
> When you say "the host does not recognize them", what host do you
> mean? This is a different host on vlan 1?
No, this is the host in vlan2.
The packet contains the vlan tag with vid 0. It should not. The host discards
it as it does not have a vlan interface with vid 0.
> > I've attached a tcpdump log. Please take a look at the icmp echo request
> > and reply packets, especially the last one.
>
> What do you mean by broken? I only see one tag in the trace, which is
> on the packet originating from 192.168.100.3 and it has a vid of 0.
The tag itself is valid. But it should not be there as it comes from
a native ethernet port.
> Where was this trace captured?
This trace was captured on the host in vlan2.
Ok, let me explain step by step:
* Host sends icmp echo request (172.16.0.21 -> 192.168.100.3) to router
172.16.0.1, the packet is untagged.
* Switch receives the packet on native interface with vid 2, tags it and sends
it to the trunk)
* Netbook receives the packet from trunk, untags it an queues it to vlan
interface 2.
* Netbook nats the packet (192.168.x.140 > 192.168.100.3), tags it with vlan
2 and sends it to the trunk.
* Switch receives the packet from trunk, untags it and sends it to native
interface with vlan 1.
* The packet and its answer (192.168.100.3 -> 192.168.x.140) make their way
through the network.
* Switch receives the icmp echo reply on native interface with vlan 1, tags
it and sends it to the trunk
* Netbook receives the packet from trunk, untags it an queues it to vlan
interface 1.
* Netbooks restores the original addresses from nat (192.168.100.3 ->
172.16.0.21), _tags_it_with_vlan_0_, tags it with vlan 2 and sends it to the
trunk.
* Switch receives packet from trunk, untags it (the tag with vid 2) and sends
it to native interface with vid 2.
* Host receives the packet and discards it as it still contains a vlan tag
with vid 0.
--
Schoene Gruesse
Chris
^ permalink raw reply
* Re: [RFC v2 PATCH 1/9] crypto: authencesn - Add algorithm to handle IPsec extended sequence numbers
From: Steffen Klassert @ 2011-03-14 10:02 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, Alex Badea, Andreas Gruenbacher, netdev,
linux-crypto
In-Reply-To: <20110314093907.GA25957@gondor.apana.org.au>
On Mon, Mar 14, 2011 at 05:39:07PM +0800, Herbert Xu wrote:
> >
> > Not sure if I get you right, but we do not set this flag here.
> > We use it to mask the flags we got from the request, so we pass
> > this flag to the ahash algorithm just if it was set by the
> > original aead request.
>
> Indeed you are right. As long as it is only a mask and only
> used on the sync path it should be OK.
>
Yes, that's how it is used in both, authenc and authencesn.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Thomas Gleixner @ 2011-03-14 9:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, bhutchings, netdev, linux-next, linux-kernel, mingo,
hpa, peterz
In-Reply-To: <20110314170546.af552b4e.sfr@canb.auug.org.au>
On Mon, 14 Mar 2011, Stephen Rothwell wrote:
> Hi Dave,
>
> On Sun, 13 Mar 2011 22:53:12 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 14 Mar 2011 16:31:35 +1100
> >
> > > Maybe some config option changed ...
> >
> > Perhaps GENERIC_HARDIRQS_NO_DEPRECATED?
>
> Yep, that has been turned on for powerpc now. I guess you will have the
> same problem on sparc64 of you merge the net-next and sparc trees ...
Yeah, powerpc alone compiles with GENERIC_HARDIRQS_NO_DEPRECATED as it
does not have that notify commit.
If you add net which has that notify commit, but not the fix it
breaks. I wonder whether Dave should pick that fix into net.
Thanks,
tglx
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Thomas Gleixner @ 2011-03-14 9:44 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, bhutchings, netdev, linux-next, linux-kernel, mingo,
hpa, peterz
In-Reply-To: <20110314170546.af552b4e.sfr@canb.auug.org.au>
On Mon, 14 Mar 2011, Stephen Rothwell wrote:
> Hi Dave,
>
> On Sun, 13 Mar 2011 22:53:12 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 14 Mar 2011 16:31:35 +1100
> >
> > > Maybe some config option changed ...
> >
> > Perhaps GENERIC_HARDIRQS_NO_DEPRECATED?
>
> Yep, that has been turned on for powerpc now. I guess you will have the
> same problem on sparc64 of you merge the net-next and sparc trees ...
Hmm, the tip/irq/core has the fix for that. /me wonders
^ permalink raw reply
* Re: [RFC v2 PATCH 1/9] crypto: authencesn - Add algorithm to handle IPsec extended sequence numbers
From: Herbert Xu @ 2011-03-14 9:39 UTC (permalink / raw)
To: Steffen Klassert
Cc: David Miller, Alex Badea, Andreas Gruenbacher, netdev,
linux-crypto
In-Reply-To: <20110314083741.GN31402@secunet.com>
On Mon, Mar 14, 2011 at 09:37:41AM +0100, Steffen Klassert wrote:
> On Sun, Mar 13, 2011 at 02:30:17PM +0800, Herbert Xu wrote:
> > On Tue, Mar 08, 2011 at 11:04:58AM +0100, Steffen Klassert wrote:
> > >
> > > + return crypto_authenc_esn_genicv(req, iv, CRYPTO_TFM_REQ_MAY_SLEEP);
> >
> > BTW, we should get rid of these MAY_SLEEP flags. Originally I
> > included them for the IPsec encryption path because that happens
> > to be sleepable. We should instead be getting it from the request
> > itself.
> >
>
> Not sure if I get you right, but we do not set this flag here.
> We use it to mask the flags we got from the request, so we pass
> this flag to the ahash algorithm just if it was set by the
> original aead request.
Indeed you are right. As long as it is only a mask and only
used on the sync path it should be OK.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] arp_notify: unconditionally send gratuitous ARP for NETDEV_NOTIFY_PEERS.
From: Anders Franzen @ 2011-03-14 9:26 UTC (permalink / raw)
To: David Miller; +Cc: Ian.Campbell@eu.citrix.com, netdev@vger.kernel.org
In-Reply-To: <20110215.105114.226760606.davem@davemloft.net>
Nice, so this is a generic way of getting out gratuitous arps.
Can it be used by drivers (macvlan) on top of bonding.
Bonding is sending the BOND_FAILOVER event that could be mapped
to NOTIFY_PEERS in the higher level devices.
And bonding is implementing its own grat arps functions, maybe it could
be broken out to use the NOTIFY_PEERS instead.
And what about IPv6, would it be ok to implement an unsolicited NA on
the event?
I will happily implement the above, if anyone thinks it's worth it?
BR
Anders
On Tue, 2011-02-15 at 19:51 +0100, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Date: Tue, 15 Feb 2011 09:13:45 +0000
>
> > On Tue, 2011-02-15 at 01:46 +0000, David Miller wrote:
> >> From: Ian Campbell <ian.campbell@citrix.com>
> >> Date: Fri, 11 Feb 2011 17:44:16 +0000
> >>
> >> > NETDEV_NOTIFY_PEER is an explicit request by the driver to send a link
> >> > notification while NETDEV_UP/NETDEV_CHANGEADDR generate link
> >> > notifications as a sort of side effect.
> ...
> > I nearly forgot -- the NETDEV_NOTIFY_PEER stuff was tagged for
> > stable/longterm backport (it appeared in 2.6.32.19 or so). I think this
> > change should likewise go back, what do you think?
>
> Sure, I've queued it up for -stable.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 02/20] ipvs: reorganize tot_stats
From: Julian Anastasov @ 2011-03-14 9:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Simon Horman, netdev, netfilter-devel, netfilter, lvs-devel,
Hans Schillstrom
In-Reply-To: <1300076903.2761.64.camel@edumazet-laptop>
Hello,
On Mon, 14 Mar 2011, Eric Dumazet wrote:
>> Also, make sure ip_vs_stats_percpu_show reads properly
>> the u64 stats from user context.
>>
>> Signed-off-by: Julian Anastasov <ja@ssi.bg>
>> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> One comment : per cpu stats are really good to avoid cache misses, but I
> see tot_stats is included in struct netns_ipvs right after "conn_count",
> possibly sharing a hot cache line ?
conn_count and tcp_app_lock, udp_app_lock, sctp_app_lock
are used when packet creates new connection, probably on the
same time depending on the protocol in packet. May be conn_count
better to be before tcp_apps, far away from some sysctl vars
that are mostly read?
For tot_stats: cpustats ptr is always read,
other fields in tot_stats are updated from the 2-second
timer. May be it is better just to move tot_stats before
est_list, it is written at the same time?
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH 18/24] IPVS: Conditinally use sysctl_lblc{r}_expiration
From: Simon Horman @ 2011-03-14 9:06 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Eric Dumazet, Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1300093596-3824-1-git-send-email-horms@verge.net.au>
In preparation for not including sysctl_lblc{r}_expiration in
struct netns_ipvs when CONFIG_SYCTL is not defined.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_lblc.c | 16 +++++++++++++---
net/netfilter/ipvs/ip_vs_lblcr.c | 21 +++++++++++++++------
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_lblc.c b/net/netfilter/ipvs/ip_vs_lblc.c
index 6bf7a80..51a27f5 100644
--- a/net/netfilter/ipvs/ip_vs_lblc.c
+++ b/net/netfilter/ipvs/ip_vs_lblc.c
@@ -63,6 +63,8 @@
#define CHECK_EXPIRE_INTERVAL (60*HZ)
#define ENTRY_TIMEOUT (6*60*HZ)
+#define DEFAULT_EXPIRATION (24*60*60*HZ)
+
/*
* It is for full expiration check.
* When there is no partial expiration check (garbage collection)
@@ -238,6 +240,15 @@ static void ip_vs_lblc_flush(struct ip_vs_lblc_table *tbl)
}
}
+static int sysctl_lblc_expiration(struct ip_vs_service *svc)
+{
+#ifdef CONFIG_SYSCTL
+ struct netns_ipvs *ipvs = net_ipvs(svc->net);
+ return ipvs->sysctl_lblc_expiration;
+#else
+ return DEFAULT_EXPIRATION;
+#endif
+}
static inline void ip_vs_lblc_full_check(struct ip_vs_service *svc)
{
@@ -245,7 +256,6 @@ static inline void ip_vs_lblc_full_check(struct ip_vs_service *svc)
struct ip_vs_lblc_entry *en, *nxt;
unsigned long now = jiffies;
int i, j;
- struct netns_ipvs *ipvs = net_ipvs(svc->net);
for (i=0, j=tbl->rover; i<IP_VS_LBLC_TAB_SIZE; i++) {
j = (j + 1) & IP_VS_LBLC_TAB_MASK;
@@ -254,7 +264,7 @@ static inline void ip_vs_lblc_full_check(struct ip_vs_service *svc)
list_for_each_entry_safe(en, nxt, &tbl->bucket[j], list) {
if (time_before(now,
en->lastuse +
- ipvs->sysctl_lblc_expiration))
+ sysctl_lblc_expiration(svc)))
continue;
ip_vs_lblc_free(en);
@@ -550,7 +560,7 @@ static int __net_init __ip_vs_lblc_init(struct net *net)
return -ENOMEM;
} else
ipvs->lblc_ctl_table = vs_vars_table;
- ipvs->sysctl_lblc_expiration = 24*60*60*HZ;
+ ipvs->sysctl_lblc_expiration = DEFAULT_EXPIRATION;
ipvs->lblc_ctl_table[0].data = &ipvs->sysctl_lblc_expiration;
#ifdef CONFIG_SYSCTL
diff --git a/net/netfilter/ipvs/ip_vs_lblcr.c b/net/netfilter/ipvs/ip_vs_lblcr.c
index 0063176..7fb9190 100644
--- a/net/netfilter/ipvs/ip_vs_lblcr.c
+++ b/net/netfilter/ipvs/ip_vs_lblcr.c
@@ -63,6 +63,8 @@
#define CHECK_EXPIRE_INTERVAL (60*HZ)
#define ENTRY_TIMEOUT (6*60*HZ)
+#define DEFAULT_EXPIRATION (24*60*60*HZ)
+
/*
* It is for full expiration check.
* When there is no partial expiration check (garbage collection)
@@ -410,6 +412,15 @@ static void ip_vs_lblcr_flush(struct ip_vs_lblcr_table *tbl)
}
}
+static int sysctl_lblcr_expiration(struct ip_vs_service *svc)
+{
+#ifdef CONFIG_SYSCTL
+ struct netns_ipvs *ipvs = net_ipvs(svc->net);
+ return ipvs->sysctl_lblcr_expiration;
+#else
+ return DEFAULT_EXPIRATION;
+#endif
+}
static inline void ip_vs_lblcr_full_check(struct ip_vs_service *svc)
{
@@ -417,15 +428,14 @@ static inline void ip_vs_lblcr_full_check(struct ip_vs_service *svc)
unsigned long now = jiffies;
int i, j;
struct ip_vs_lblcr_entry *en, *nxt;
- struct netns_ipvs *ipvs = net_ipvs(svc->net);
for (i=0, j=tbl->rover; i<IP_VS_LBLCR_TAB_SIZE; i++) {
j = (j + 1) & IP_VS_LBLCR_TAB_MASK;
write_lock(&svc->sched_lock);
list_for_each_entry_safe(en, nxt, &tbl->bucket[j], list) {
- if (time_after(en->lastuse
- + ipvs->sysctl_lblcr_expiration, now))
+ if (time_after(en->lastuse +
+ sysctl_lblcr_expiration(svc), now))
continue;
ip_vs_lblcr_free(en);
@@ -650,7 +660,6 @@ ip_vs_lblcr_schedule(struct ip_vs_service *svc, const struct sk_buff *skb)
read_lock(&svc->sched_lock);
en = ip_vs_lblcr_get(svc->af, tbl, &iph.daddr);
if (en) {
- struct netns_ipvs *ipvs = net_ipvs(svc->net);
/* We only hold a read lock, but this is atomic */
en->lastuse = jiffies;
@@ -662,7 +671,7 @@ ip_vs_lblcr_schedule(struct ip_vs_service *svc, const struct sk_buff *skb)
/* More than one destination + enough time passed by, cleanup */
if (atomic_read(&en->set.size) > 1 &&
time_after(jiffies, en->set.lastmod +
- ipvs->sysctl_lblcr_expiration)) {
+ sysctl_lblcr_expiration(svc))) {
struct ip_vs_dest *m;
write_lock(&en->set.lock);
@@ -746,7 +755,7 @@ static int __net_init __ip_vs_lblcr_init(struct net *net)
return -ENOMEM;
} else
ipvs->lblcr_ctl_table = vs_vars_table;
- ipvs->sysctl_lblcr_expiration = 24*60*60*HZ;
+ ipvs->sysctl_lblcr_expiration = DEFAULT_EXPIRATION;
ipvs->lblcr_ctl_table[0].data = &ipvs->sysctl_lblcr_expiration;
#ifdef CONFIG_SYSCTL
--
1.7.2.3
^ permalink raw reply related
* [PATCH 23/24] IPVS: Add __ip_vs_control_{init,cleanup}_sysctl()
From: Simon Horman @ 2011-03-14 9:06 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Eric Dumazet, Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1300093596-3824-1-git-send-email-horms@verge.net.au>
Break out the portions of __ip_vs_control_init() and
__ip_vs_control_cleanup() where aren't necessary when
CONFIG_SYSCTL is undefined.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ctl.c | 98 +++++++++++++++++++++++++---------------
1 files changed, 62 insertions(+), 36 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 364520f..fa6d44c 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -88,6 +88,8 @@ static int __ip_vs_addr_is_local_v6(struct net *net,
return 0;
}
#endif
+
+#ifdef CONFIG_SYSCTL
/*
* update_defense_level is called from keventd and from sysctl,
* so it needs to protect itself from softirqs
@@ -229,6 +231,7 @@ static void defense_work_handler(struct work_struct *work)
ip_vs_random_dropentry(ipvs->net);
schedule_delayed_work(&ipvs->defense_work, DEFENSE_TIMER_PERIOD);
}
+#endif
int
ip_vs_use_count_inc(void)
@@ -1511,7 +1514,7 @@ static int ip_vs_zero_all(struct net *net)
return 0;
}
-
+#ifdef CONFIG_SYSCTL
static int
proc_do_defense_mode(ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
@@ -1533,7 +1536,6 @@ proc_do_defense_mode(ctl_table *table, int write,
return rc;
}
-
static int
proc_do_sync_threshold(ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
@@ -1767,6 +1769,7 @@ const struct ctl_path net_vs_ctl_path[] = {
{ }
};
EXPORT_SYMBOL_GPL(net_vs_ctl_path);
+#endif
#ifdef CONFIG_PROC_FS
@@ -3511,7 +3514,8 @@ static void ip_vs_genl_unregister(void)
/*
* per netns intit/exit func.
*/
-int __net_init __ip_vs_control_init(struct net *net)
+#ifdef CONFIG_SYSCTL
+int __net_init __ip_vs_control_init_sysctl(struct net *net)
{
int idx;
struct netns_ipvs *ipvs = net_ipvs(net);
@@ -3521,33 +3525,11 @@ int __net_init __ip_vs_control_init(struct net *net)
spin_lock_init(&ipvs->dropentry_lock);
spin_lock_init(&ipvs->droppacket_lock);
spin_lock_init(&ipvs->securetcp_lock);
- ipvs->rs_lock = __RW_LOCK_UNLOCKED(ipvs->rs_lock);
-
- /* Initialize rs_table */
- for (idx = 0; idx < IP_VS_RTAB_SIZE; idx++)
- INIT_LIST_HEAD(&ipvs->rs_table[idx]);
-
- INIT_LIST_HEAD(&ipvs->dest_trash);
- atomic_set(&ipvs->ftpsvc_counter, 0);
- atomic_set(&ipvs->nullsvc_counter, 0);
-
- /* procfs stats */
- ipvs->tot_stats.cpustats = alloc_percpu(struct ip_vs_cpu_stats);
- if (!ipvs->tot_stats.cpustats) {
- pr_err("%s() alloc_percpu failed\n", __func__);
- goto err_alloc;
- }
- spin_lock_init(&ipvs->tot_stats.lock);
-
- proc_net_fops_create(net, "ip_vs", 0, &ip_vs_info_fops);
- proc_net_fops_create(net, "ip_vs_stats", 0, &ip_vs_stats_fops);
- proc_net_fops_create(net, "ip_vs_stats_percpu", 0,
- &ip_vs_stats_percpu_fops);
if (!net_eq(net, &init_net)) {
tbl = kmemdup(vs_vars, sizeof(vs_vars), GFP_KERNEL);
if (tbl == NULL)
- goto err_dup;
+ return -ENOMEM;
} else
tbl = vs_vars;
/* Initialize sysctl defaults */
@@ -3576,25 +3558,73 @@ int __net_init __ip_vs_control_init(struct net *net)
tbl[idx++].data = &ipvs->sysctl_nat_icmp_send;
-#ifdef CONFIG_SYSCTL
ipvs->sysctl_hdr = register_net_sysctl_table(net, net_vs_ctl_path,
tbl);
if (ipvs->sysctl_hdr == NULL) {
if (!net_eq(net, &init_net))
kfree(tbl);
- goto err_dup;
+ return -ENOMEM;
}
-#endif
ip_vs_start_estimator(net, &ipvs->tot_stats);
ipvs->sysctl_tbl = tbl;
/* Schedule defense work */
INIT_DELAYED_WORK(&ipvs->defense_work, defense_work_handler);
schedule_delayed_work(&ipvs->defense_work, DEFENSE_TIMER_PERIOD);
+
return 0;
+}
+
+void __net_init __ip_vs_control_cleanup_sysctl(struct net *net)
+{
+ struct netns_ipvs *ipvs = net_ipvs(net);
+
+ cancel_delayed_work_sync(&ipvs->defense_work);
+ cancel_work_sync(&ipvs->defense_work.work);
+ unregister_net_sysctl_table(ipvs->sysctl_hdr);
+}
-err_dup:
+#else
+
+int __net_init __ip_vs_control_init_sysctl(struct net *net) { return 0; }
+void __net_init __ip_vs_control_cleanup_sysctl(struct net *net) { }
+
+#endif
+
+int __net_init __ip_vs_control_init(struct net *net)
+{
+ int idx;
+ struct netns_ipvs *ipvs = net_ipvs(net);
+
+ ipvs->rs_lock = __RW_LOCK_UNLOCKED(ipvs->rs_lock);
+
+ /* Initialize rs_table */
+ for (idx = 0; idx < IP_VS_RTAB_SIZE; idx++)
+ INIT_LIST_HEAD(&ipvs->rs_table[idx]);
+
+ INIT_LIST_HEAD(&ipvs->dest_trash);
+ atomic_set(&ipvs->ftpsvc_counter, 0);
+ atomic_set(&ipvs->nullsvc_counter, 0);
+
+ /* procfs stats */
+ ipvs->tot_stats.cpustats = alloc_percpu(struct ip_vs_cpu_stats);
+ if (ipvs->tot_stats.cpustats) {
+ pr_err("%s(): alloc_percpu.\n", __func__);
+ return -ENOMEM;
+ }
+ spin_lock_init(&ipvs->tot_stats.lock);
+
+ proc_net_fops_create(net, "ip_vs", 0, &ip_vs_info_fops);
+ proc_net_fops_create(net, "ip_vs_stats", 0, &ip_vs_stats_fops);
+ proc_net_fops_create(net, "ip_vs_stats_percpu", 0,
+ &ip_vs_stats_percpu_fops);
+
+ if (__ip_vs_control_init_sysctl(net))
+ goto err;
+
+ return 0;
+
+err:
free_percpu(ipvs->tot_stats.cpustats);
-err_alloc:
return -ENOMEM;
}
@@ -3604,11 +3634,7 @@ static void __net_exit __ip_vs_control_cleanup(struct net *net)
ip_vs_trash_cleanup(net);
ip_vs_stop_estimator(net, &ipvs->tot_stats);
- cancel_delayed_work_sync(&ipvs->defense_work);
- cancel_work_sync(&ipvs->defense_work.work);
-#ifdef CONFIG_SYSCTL
- unregister_net_sysctl_table(ipvs->sysctl_hdr);
-#endif
+ __ip_vs_control_cleanup_sysctl(net);
proc_net_remove(net, "ip_vs_stats_percpu");
proc_net_remove(net, "ip_vs_stats");
proc_net_remove(net, "ip_vs");
--
1.7.2.3
^ permalink raw reply related
* [PATCH 20/24] IPVS: Conditional ip_vs_conntrack_enabled()
From: Simon Horman @ 2011-03-14 9:06 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Eric Dumazet, Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1300093596-3824-1-git-send-email-horms@verge.net.au>
ip_vs_conntrack_enabled() becomes a noop when CONFIG_SYSCTL is undefined.
In preparation for not including sysctl_conntrack in
struct netns_ipvs when CONFIG_SYCTL is not defined.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 77ebece..299aeb5 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1359,7 +1359,11 @@ static inline void ip_vs_notrack(struct sk_buff *skb)
*/
static inline int ip_vs_conntrack_enabled(struct netns_ipvs *ipvs)
{
+#ifdef CONFIG_SYSCTL
return ipvs->sysctl_conntrack;
+#else
+ return 0;
+#endif
}
extern void ip_vs_update_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp,
--
1.7.2.3
^ permalink raw reply related
* [PATCH 12/24] IPVS: Add sysctl_snat_reroute()
From: Simon Horman @ 2011-03-14 9:06 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Eric Dumazet, Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1300093596-3824-1-git-send-email-horms@verge.net.au>
In preparation for not including sysctl_snat_reroute in
struct netns_ipvs when CONFIG_SYCTL is not defined.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_core.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 299c7f3..1d8a2a2 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -599,6 +599,20 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
return NF_DROP;
}
+#ifdef CONFIG_SYSCTL
+
+static int sysctl_snat_reroute(struct sk_buff *skb)
+{
+ struct netns_ipvs *ipvs = net_ipvs(skb_net(skb));
+ return ipvs->sysctl_snat_reroute;
+}
+
+#else
+
+static int sysctl_snat_reroute(struct sk_buff *skb) { return 0; }
+
+#endif
+
__sum16 ip_vs_checksum_complete(struct sk_buff *skb, int offset)
{
return csum_fold(skb_checksum(skb, offset, skb->len - offset, 0));
@@ -633,15 +647,13 @@ static inline int ip_vs_gather_frags_v6(struct sk_buff *skb, u_int32_t user)
static int ip_vs_route_me_harder(int af, struct sk_buff *skb)
{
- struct netns_ipvs *ipvs = net_ipvs(skb_net(skb));
-
#ifdef CONFIG_IP_VS_IPV6
if (af == AF_INET6) {
- if (ipvs->sysctl_snat_reroute && ip6_route_me_harder(skb) != 0)
+ if (sysctl_snat_reroute(skb) && ip6_route_me_harder(skb) != 0)
return 1;
} else
#endif
- if ((ipvs->sysctl_snat_reroute ||
+ if ((sysctl_snat_reroute(skb) ||
skb_rtable(skb)->rt_flags & RTCF_LOCAL) &&
ip_route_me_harder(skb, RTN_LOCAL) != 0)
return 1;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 03/24] netfilter:ipvs: use kmemdup
From: Simon Horman @ 2011-03-14 9:06 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Eric Dumazet, Julian Anastasov, Hans Schillstrom, Shan Wei,
Simon Horman
In-Reply-To: <1300093596-3824-1-git-send-email-horms@verge.net.au>
From: Shan Wei <shanwei@cn.fujitsu.com>
The semantic patch that makes this output is available
in scripts/coccinelle/api/memdup.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_pe_sip.c | 9 ++++-----
net/netfilter/ipvs/ip_vs_sync.c | 3 +--
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_pe_sip.c b/net/netfilter/ipvs/ip_vs_pe_sip.c
index 0d83bc0..13d607a 100644
--- a/net/netfilter/ipvs/ip_vs_pe_sip.c
+++ b/net/netfilter/ipvs/ip_vs_pe_sip.c
@@ -92,14 +92,13 @@ ip_vs_sip_fill_param(struct ip_vs_conn_param *p, struct sk_buff *skb)
if (get_callid(dptr, dataoff, datalen, &matchoff, &matchlen))
return -EINVAL;
- p->pe_data = kmalloc(matchlen, GFP_ATOMIC);
- if (!p->pe_data)
- return -ENOMEM;
-
/* N.B: pe_data is only set on success,
* this allows fallback to the default persistence logic on failure
*/
- memcpy(p->pe_data, dptr + matchoff, matchlen);
+ p->pe_data = kmemdup(dptr + matchoff, matchlen, GFP_ATOMIC);
+ if (!p->pe_data)
+ return -ENOMEM;
+
p->pe_data_len = matchlen;
return 0;
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index fecf24d..c5d13b0 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -697,13 +697,12 @@ ip_vs_conn_fill_param_sync(struct net *net, int af, union ip_vs_sync_conn *sc,
return 1;
}
- p->pe_data = kmalloc(pe_data_len, GFP_ATOMIC);
+ p->pe_data = kmemdup(pe_data, pe_data_len, GFP_ATOMIC);
if (!p->pe_data) {
if (p->pe->module)
module_put(p->pe->module);
return -ENOMEM;
}
- memcpy(p->pe_data, pe_data, pe_data_len);
p->pe_data_len = pe_data_len;
}
return 0;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 02/24] ipvs: remove _bh from percpu stats reading
From: Simon Horman @ 2011-03-14 9:06 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Eric Dumazet, Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1300093596-3824-1-git-send-email-horms@verge.net.au>
From: Julian Anastasov <ja@ssi.bg>
ip_vs_read_cpu_stats is called only from timer, so
no need for _bh locks.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_est.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_est.c b/net/netfilter/ipvs/ip_vs_est.c
index f560a05..88bd716 100644
--- a/net/netfilter/ipvs/ip_vs_est.c
+++ b/net/netfilter/ipvs/ip_vs_est.c
@@ -69,10 +69,10 @@ static void ip_vs_read_cpu_stats(struct ip_vs_stats_user *sum,
sum->inpkts += s->ustats.inpkts;
sum->outpkts += s->ustats.outpkts;
do {
- start = u64_stats_fetch_begin_bh(&s->syncp);
+ start = u64_stats_fetch_begin(&s->syncp);
inbytes = s->ustats.inbytes;
outbytes = s->ustats.outbytes;
- } while (u64_stats_fetch_retry_bh(&s->syncp, start));
+ } while (u64_stats_fetch_retry(&s->syncp, start));
sum->inbytes += inbytes;
sum->outbytes += outbytes;
} else {
@@ -80,10 +80,10 @@ static void ip_vs_read_cpu_stats(struct ip_vs_stats_user *sum,
sum->inpkts = s->ustats.inpkts;
sum->outpkts = s->ustats.outpkts;
do {
- start = u64_stats_fetch_begin_bh(&s->syncp);
+ start = u64_stats_fetch_begin(&s->syncp);
sum->inbytes = s->ustats.inbytes;
sum->outbytes = s->ustats.outbytes;
- } while (u64_stats_fetch_retry_bh(&s->syncp, start));
+ } while (u64_stats_fetch_retry(&s->syncp, start));
}
}
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 04/24] Fix variable assignment in ip_vs_notrack
From: Simon Horman @ 2011-03-14 9:06 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Eric Dumazet, Julian Anastasov, Hans Schillstrom, Jesper Juhl,
Simon Horman
In-Reply-To: <1300093596-3824-1-git-send-email-horms@verge.net.au>
From: Jesper Juhl <jj@chaosbits.net>
There's no sense to 'ct = ct = ' in ip_vs_notrack(). Just assign
nf_ct_get()'s return value directly to the pointer variable 'ct' once.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index e74da41e..1dcb75d 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1190,7 +1190,7 @@ static inline void ip_vs_notrack(struct sk_buff *skb)
{
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
enum ip_conntrack_info ctinfo;
- struct nf_conn *ct = ct = nf_ct_get(skb, &ctinfo);
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
if (!ct || !nf_ct_is_untracked(ct)) {
nf_reset(skb);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 24/24] IPVS: Conditionally include sysctl members of struct netns_ipvs
From: Simon Horman @ 2011-03-14 9:06 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Eric Dumazet, Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1300093596-3824-1-git-send-email-horms@verge.net.au>
There is now no need to include sysctl members of struct netns_ipvs
unless CONFIG_SYSCTL is defined.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 299aeb5..272f593 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -839,6 +839,17 @@ struct netns_ipvs {
struct ip_vs_stats tot_stats; /* Statistics & est. */
int num_services; /* no of virtual services */
+
+ rwlock_t rs_lock; /* real services table */
+ /* semaphore for IPVS sockopts. And, [gs]etsockopt may sleep. */
+ struct lock_class_key ctl_key; /* ctl_mutex debuging */
+ /* Trash for destinations */
+ struct list_head dest_trash;
+ /* Service counters */
+ atomic_t ftpsvc_counter;
+ atomic_t nullsvc_counter;
+
+#ifdef CONFIG_SYSCTL
/* 1/rate drop and drop-entry variables */
struct delayed_work defense_work; /* Work handler */
int drop_rate;
@@ -848,18 +859,12 @@ struct netns_ipvs {
spinlock_t dropentry_lock; /* drop entry handling */
spinlock_t droppacket_lock; /* drop packet handling */
spinlock_t securetcp_lock; /* state and timeout tables */
- rwlock_t rs_lock; /* real services table */
- /* semaphore for IPVS sockopts. And, [gs]etsockopt may sleep. */
- struct lock_class_key ctl_key; /* ctl_mutex debuging */
- /* Trash for destinations */
- struct list_head dest_trash;
- /* Service counters */
- atomic_t ftpsvc_counter;
- atomic_t nullsvc_counter;
/* sys-ctl struct */
struct ctl_table_header *sysctl_hdr;
struct ctl_table *sysctl_tbl;
+#endif
+
/* sysctl variables */
int sysctl_amemthresh;
int sysctl_am_droprate;
--
1.7.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox