* [PATCH] tcp: Fix a connect() race with timewait sockets
From: Eric Dumazet @ 2009-12-01 15:00 UTC (permalink / raw)
To: kapil dakhane; +Cc: netdev, netfilter, David S. Miller, Evgeniy Polyakov
In-Reply-To: <99d458640911301802i4bde20f4wa314668d543e3170@mail.gmail.com>
kapil dakhane a écrit :
> Hello,
>
> I am trying to analyze the capacity of linux network stack on x6270
> which has 16 Hyper threads on two 8-core Intel(r) Xeon(r) CPU. I see
> that at around 150000 simultaneous connections, after around 1.6 gbps,
> a cpu get stuck in an infinite loop in inet_csk_bind_conflict, then
> other cpus get locked up doing spin_lock. Before the lockup cpu usage
> was around 25%. It appears to be a bug, unless I am hitting some kind
> of resource limit. It would be good if someone familiar with network
> code would confirm this, or point me in the right direction.
>
> Important details are:
>
> I am using kernel version 2.6.31.4 recompiled with TPROXY related
> options: NF_CONNTRACK, NETFILTER_TPROXY, NETFILTER_XT_MATCH_SOCKET,
> NETFILTER_XT_TARGET_TPROXY.
>
>
> I have enabled transparent capture and transparent forward using
> iptables and ip rules. I have 10 instances of a single threaded user
> space bits-forwarding-proxy (fast), each bound to different
> hyper-threads (CPUs). Rest 6 CPUs are dedicated to interrupt
> processing, each handling interrupts from six different network cards.
> TCP flow from a 4-tuple always get handled by the same proxy process,
> interrupt thread, and network card. In this way, network traffic is
> segregated as much as possible to achieve high degree of parallelism.
>
> First /var/log/message entry shows CPU#7 is stuck in inet_csk_bind_conflict
>
> Nov 17 23:02:04 cap-x6270-01 kernel: BUG: soft lockup - CPU#7 stuck
> for 61s! [fast:20701]
After some more audit and coffee, I finally found one subtle bug in our
connect() code, that periodically triggers but never got tracked.
Here is a patch cooked on top of current linux-2.6 git tree, it should probably
apply on 2.6.31.6 as well...
Thanks
[PATCH] tcp: Fix a connect() race with timewait sockets
When we find a timewait connection in __inet_hash_connect() and reuse
it for a new connection request, we have a race window, releasing bind
list lock and reacquiring it in __inet_twsk_kill() to remove timewait
socket from list.
Another thread might find the timewait socket we already chose, leading to
list corruption and crashes.
Fix is to remove timewait socket from bind list before releasing the lock.
Reported-by: kapil dakhane <kdakhane@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/inet_timewait_sock.h | 4 +++
net/ipv4/inet_hashtables.c | 4 +++
net/ipv4/inet_timewait_sock.c | 37 ++++++++++++++++++++---------
3 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/include/net/inet_timewait_sock.h b/include/net/inet_timewait_sock.h
index f93ad90..e18e5df 100644
--- a/include/net/inet_timewait_sock.h
+++ b/include/net/inet_timewait_sock.h
@@ -206,6 +206,10 @@ extern void __inet_twsk_hashdance(struct inet_timewait_sock *tw,
struct sock *sk,
struct inet_hashinfo *hashinfo);
+extern void inet_twsk_unhash(struct inet_timewait_sock *tw,
+ struct inet_hashinfo *hashinfo,
+ bool mustlock);
+
extern void inet_twsk_schedule(struct inet_timewait_sock *tw,
struct inet_timewait_death_row *twdr,
const int timeo, const int timewait_len);
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 625cc5f..76d81e4 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -488,6 +488,10 @@ ok:
inet_sk(sk)->sport = htons(port);
hash(sk);
}
+
+ if (tw)
+ inet_twsk_unhash(tw, hinfo, false);
+
spin_unlock(&head->lock);
if (tw) {
diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
index 13f0781..2d6d543 100644
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -14,12 +14,34 @@
#include <net/inet_timewait_sock.h>
#include <net/ip.h>
+
+void inet_twsk_unhash(struct inet_timewait_sock *tw,
+ struct inet_hashinfo *hashinfo,
+ bool mustlock)
+{
+ struct inet_bind_hashbucket *bhead;
+ struct inet_bind_bucket *tb = tw->tw_tb;
+
+ if (!tb)
+ return;
+
+ /* Disassociate with bind bucket. */
+ bhead = &hashinfo->bhash[inet_bhashfn(twsk_net(tw),
+ tw->tw_num,
+ hashinfo->bhash_size)];
+ if (mustlock)
+ spin_lock(&bhead->lock);
+ __hlist_del(&tw->tw_bind_node);
+ tw->tw_tb = NULL;
+ inet_bind_bucket_destroy(hashinfo->bind_bucket_cachep, tb);
+ if (mustlock)
+ spin_unlock(&bhead->lock);
+}
+
/* Must be called with locally disabled BHs. */
static void __inet_twsk_kill(struct inet_timewait_sock *tw,
struct inet_hashinfo *hashinfo)
{
- struct inet_bind_hashbucket *bhead;
- struct inet_bind_bucket *tb;
/* Unlink from established hashes. */
spinlock_t *lock = inet_ehash_lockp(hashinfo, tw->tw_hash);
@@ -32,15 +54,8 @@ static void __inet_twsk_kill(struct inet_timewait_sock *tw,
sk_nulls_node_init(&tw->tw_node);
spin_unlock(lock);
- /* Disassociate with bind bucket. */
- bhead = &hashinfo->bhash[inet_bhashfn(twsk_net(tw), tw->tw_num,
- hashinfo->bhash_size)];
- spin_lock(&bhead->lock);
- tb = tw->tw_tb;
- __hlist_del(&tw->tw_bind_node);
- tw->tw_tb = NULL;
- inet_bind_bucket_destroy(hashinfo->bind_bucket_cachep, tb);
- spin_unlock(&bhead->lock);
+ inet_twsk_unhash(tw, hashinfo, true);
+
#ifdef SOCK_REFCNT_DEBUG
if (atomic_read(&tw->tw_refcnt) != 1) {
printk(KERN_DEBUG "%s timewait_sock %p refcnt=%d\n",
^ permalink raw reply related
* [PATCH] Update embedded copy of ethtool.h from kernel 2.6.30
From: Jesper Nilsson @ 2009-12-01 15:17 UTC (permalink / raw)
To: Jeff Garzik, netdev
Commit 0c09c1a49cc7b819b33566a49d9901f7cfdd6889 in the Linux kernel
added a new field mdio_support inside the struct ethtool_cmd,
changing the struct size for architectures that does not pad structs.
(for example the CRIS architecture)
This size mismatch lead to the ethtool_cmd struct being written
as 44 bytes in the kernel, but only 43 bytes allocated on stack,
overwriting one byte in the stack frame.
Update the ethtool copy of the definition to match the 2.6.30 kernel.
Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
---
ethtool-copy.h | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index eadba25..fa92515 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -23,11 +23,14 @@ struct ethtool_cmd {
__u8 phy_address;
__u8 transceiver; /* Which transceiver to use */
__u8 autoneg; /* Enable or disable autonegotiation */
+ __u8 mdio_support;
__u32 maxtxpkt; /* Tx pkts before generating tx int */
__u32 maxrxpkt; /* Rx pkts before generating rx int */
__u16 speed_hi;
- __u16 reserved2;
- __u32 reserved[3];
+ __u8 eth_tp_mdix;
+ __u8 reserved2;
+ __u32 lp_advertising; /* Features the link partner advertises */
+ __u32 reserved[2];
};
static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
--
1.6.4.GIT
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply related
* Re: [PATCH] Update embedded copy of ethtool.h from kernel 2.6.30
From: Ben Hutchings @ 2009-12-01 15:21 UTC (permalink / raw)
To: Jesper Nilsson; +Cc: Jeff Garzik, netdev
In-Reply-To: <20091201151750.GG5694@axis.com>
On Tue, 2009-12-01 at 16:17 +0100, Jesper Nilsson wrote:
> Commit 0c09c1a49cc7b819b33566a49d9901f7cfdd6889 in the Linux kernel
> added a new field mdio_support inside the struct ethtool_cmd,
> changing the struct size for architectures that does not pad structs.
> (for example the CRIS architecture)
CRIS has no alignment requirements?! Wow. Sorry for changing the
structure, then.
> This size mismatch lead to the ethtool_cmd struct being written
> as 44 bytes in the kernel, but only 43 bytes allocated on stack,
> overwriting one byte in the stack frame.
>
> Update the ethtool copy of the definition to match the 2.6.30 kernel.
[...]
This has already been done.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] Update embedded copy of ethtool.h from kernel 2.6.30
From: Jesper Nilsson @ 2009-12-01 15:42 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Jeff Garzik, netdev@vger.kernel.org
In-Reply-To: <1259680878.2831.3.camel@achroite.uk.solarflarecom.com>
On Tue, Dec 01, 2009 at 04:21:18PM +0100, Ben Hutchings wrote:
> On Tue, 2009-12-01 at 16:17 +0100, Jesper Nilsson wrote:
> > Commit 0c09c1a49cc7b819b33566a49d9901f7cfdd6889 in the Linux kernel
> > added a new field mdio_support inside the struct ethtool_cmd,
> > changing the struct size for architectures that does not pad structs.
> > (for example the CRIS architecture)
>
> CRIS has no alignment requirements?! Wow.
Yep, we don't even have the choice of adding padding inside structs. :-(
> Sorry for changing the
> structure, then.
We're used to tripping over this kind of thing. :-)
> > This size mismatch lead to the ethtool_cmd struct being written
> > as 44 bytes in the kernel, but only 43 bytes allocated on stack,
> > overwriting one byte in the stack frame.
> >
> > Update the ethtool copy of the definition to match the 2.6.30 kernel.
> [...]
>
> This has already been done.
Ah? Could someone point me to the correct git-tree for ethtool then?
I've been using http://www.kernel.org/pub/scm/network/ethtool/ethtool.git
which still has this problem...
> Ben.
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH] Update embedded copy of ethtool.h from kernel 2.6.30
From: Ben Hutchings @ 2009-12-01 15:52 UTC (permalink / raw)
To: Jesper Nilsson; +Cc: Jeff Garzik, netdev
In-Reply-To: <20091201154246.GH5694@axis.com>
On Tue, 2009-12-01 at 16:42 +0100, Jesper Nilsson wrote:
> On Tue, Dec 01, 2009 at 04:21:18PM +0100, Ben Hutchings wrote:
> > On Tue, 2009-12-01 at 16:17 +0100, Jesper Nilsson wrote:
[...]
> > > This size mismatch lead to the ethtool_cmd struct being written
> > > as 44 bytes in the kernel, but only 43 bytes allocated on stack,
> > > overwriting one byte in the stack frame.
> > >
> > > Update the ethtool copy of the definition to match the 2.6.30 kernel.
> > [...]
> >
> > This has already been done.
>
> Ah? Could someone point me to the correct git-tree for ethtool then?
> I've been using http://www.kernel.org/pub/scm/network/ethtool/ethtool.git
> which still has this problem...
That's the correct repository. It is possible that the extra static
information needed to serve it over HTTP is not up-to-date. Try using
git protocol instead?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] ethtool: Report MDI-X status for twisted-pair interfaces
From: Ben Hutchings @ 2009-12-01 16:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Chaitanya Lala
Based on a patch by Chaitanya Lala <clala@riverbed.com>.
The MDI-X status can be a useful tool for diagnosing network
connectivity issues.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
ethtool.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 827f16c..df02e91 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1018,6 +1018,22 @@ static int dump_ecmd(struct ethtool_cmd *ep)
fprintf(stdout, " Auto-negotiation: %s\n",
(ep->autoneg == AUTONEG_DISABLE) ?
"off" : "on");
+
+ if (ep->port == PORT_TP) {
+ fprintf(stdout, " MDI-X: ");
+ switch (ep->eth_tp_mdix) {
+ case ETH_TP_MDI:
+ fprintf(stdout, "off\n");
+ break;
+ case ETH_TP_MDI_X:
+ fprintf(stdout, "on\n");
+ break;
+ default:
+ fprintf(stdout, "Unknown\n");
+ break;
+ }
+ }
+
return 0;
}
--
1.5.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* RE: Bridge + Conntrack + SKB Recycle: Fragment Reassembly Errors
From: ben @ 2009-12-01 16:00 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, netdev
In-Reply-To: <4B088600.8090209@trash.net>
> Ben, please give this patch a try.
I have not been able to recreate the issue after applying the patch,
which is great. Is this the only case in which large-ish SKBs might be
recycled and cause the reassembly overflow?
- Ben Menchaca
^ permalink raw reply
* Re: [PATCH] ethtool: Report MDI-X status for twisted-pair interfaces
From: Jeff Garzik @ 2009-12-01 16:06 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Chaitanya Lala
In-Reply-To: <1259683230.2831.14.camel@achroite.uk.solarflarecom.com>
On 12/01/2009 11:00 AM, Ben Hutchings wrote:
> Based on a patch by Chaitanya Lala<clala@riverbed.com>.
>
> The MDI-X status can be a useful tool for diagnosing network
> connectivity issues.
>
> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
> ---
> ethtool.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
applied
^ permalink raw reply
* [PATCH] ethtool: Fix switch on port type
From: Ben Hutchings @ 2009-12-01 16:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: PJ Waskiewicz, netdev
The new port type cases in commit 6e0512c 'ethtool: Add Direct Attach
to the available connector ports' were somehow inserted into the
switch on duplex type, not on port type. Move them to the correct
place.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
ethtool.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index df02e91..10dfc80 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -965,12 +965,6 @@ static int dump_ecmd(struct ethtool_cmd *ep)
case DUPLEX_FULL:
fprintf(stdout, "Full\n");
break;
- case PORT_DA:
- fprintf(stdout, "Direct Attach Copper\n");
- break;
- case PORT_NONE:
- fprintf(stdout, "None\n");
- break;
default:
fprintf(stdout, "Unknown! (%i)\n", ep->duplex);
break;
@@ -993,6 +987,12 @@ static int dump_ecmd(struct ethtool_cmd *ep)
case PORT_FIBRE:
fprintf(stdout, "FIBRE\n");
break;
+ case PORT_DA:
+ fprintf(stdout, "Direct Attach Copper\n");
+ break;
+ case PORT_NONE:
+ fprintf(stdout, "None\n");
+ break;
case PORT_OTHER:
fprintf(stdout, "Other\n");
break;
--
1.5.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: warning: massive change to conditional coding style in net?
From: William Allen Simpson @ 2009-12-01 16:08 UTC (permalink / raw)
To: Joe Perches; +Cc: Linux Kernel Developers, Linux Kernel Network Developers
In-Reply-To: <1259603798.29779.293.camel@Joe-Laptop.home>
Joe Perches wrote:
> On Mon, 2009-11-30 at 05:36 -0500, William Allen Simpson wrote:
>> Over the past several days, David Miller (with help from Joe Perches)
>> made sweeping changes to the format of conditional statements in the
>> net tree -- the equivalent of mass patches that change spaces.
>> This makes writing patches for multiple versions of the tree very
>> difficult, and will make future pullups problematic.
>
> If it makes getting tcp cookies accepted difficult,
> a reversion is simple. That style isn't as important.
>
Then why make an *un*important (yet sweeping) change?
> I think writing a single set of patches for multiple
> versions of linux is not feasible. Feature changes
> occur in kernel source daily.
>
My patches were carefully written and applied with small fuzz to .30,
and .31, and .32-rc3.
>> if (condition
>> && condition
>> && (condition
>> || condition
>> || condition)) {
>
> The above is my personally preferred style.
>
That seems fine to me. And in some areas of the tree, nearly 100% of
other contributors, too.
My personally preferred style is the single spaced variant, that also
conforms to the strict letter of CodingStyle, to wit:
Use one space around (on each side of) most binary and ternary operators
>> if (condition &&
>> condition && (condition || condition ||
>> condition)) {
>
> Except for the odd spacing, this is the significant
> majority of net/ style.
>
> The leading style was < 10%. It's less now.
>
That's only true in net/ -- since the overall tree was 18.7%, with
net/ < 10%, the density was *much* higher elsewhere.
But more important, at least to my thinking, is keeping patches simple
by conforming to the *existing* style in the section of code. No
sweeping changes!
^ permalink raw reply
* Re: [PATCH] ethtool: Fix switch on port type
From: Jeff Garzik @ 2009-12-01 16:11 UTC (permalink / raw)
To: Ben Hutchings; +Cc: PJ Waskiewicz, netdev
In-Reply-To: <1259683615.2831.16.camel@achroite.uk.solarflarecom.com>
On 12/01/2009 11:06 AM, Ben Hutchings wrote:
> The new port type cases in commit 6e0512c 'ethtool: Add Direct Attach
> to the available connector ports' were somehow inserted into the
> switch on duplex type, not on port type. Move them to the correct
> place.
>
> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
> ---
> ethtool.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
ouch - one of the downsides of git happily merging away without complaint.
applied
^ permalink raw reply
* Re: seeing strange values for tcp sk_rmem_alloc
From: Chris Friesen @ 2009-12-01 16:18 UTC (permalink / raw)
To: netdev, Linux kernel
In-Reply-To: <4B15416A.2060202@nortel.com>
I forgot to mention that this was on 2.6.27. I haven't tried it on
current git.
Chris
^ permalink raw reply
* seeing strange values for tcp sk_rmem_alloc
From: Chris Friesen @ 2009-12-01 16:16 UTC (permalink / raw)
To: netdev, Linux kernel
I'm hoping someone might be able to explain some odd behaviour that I'm
seeing.
Some of our developers wanted to be able to see how much of their rx
socket buffer space was in use, so I added the following to sock_ioctl()
case SIOCGSKRMEMALLOC:
{
int tmp;
err = -EINVAL;
if(!sock->sk)
break;
tmp = atomic_read(&sock->sk->sk_rmem_alloc);
err = copy_to_user(argp, &tmp, sizeof(tmp));
break;
}
To validate it, I wrote a testcase that opened a tcp socket, then looped
sending 2k of data at a time to it and calling the above ioctl to check
the sk_rmem_alloc value (without ever reading from the socket).
The results were odd--I've copied them below. Can anyone explain how I
can send 20K of data but sk_rmem_alloc still only shows 4.8K used, then
it suddenly jumps by a lot on the next packet to something that more
reflects reality, then repeats that pattern again? Is there some
additional buffering happening somewhere in the TCP stack?
Thanks,
Chris
used: 2424
used: 4848
used: 4848
used: 4848
used: 4848
used: 4848
used: 4848
used: 4848
used: 4848
used: 4848
used: 23696
used: 23696
used: 23696
used: 23696
used: 23696
used: 23696
used: 23696
used: 23696
used: 23696
used: 42544
used: 42544
used: 42544
used: 42544
used: 42544
used: 42544
used: 42544
used: 42544
used: 42544
used: 61392
used: 61392
used: 61392
used: 61392
used: 61392
used: 61392
used: 61392
used: 61392
used: 61392
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
used: 80240
^ permalink raw reply
* Re: Bridge + Conntrack + SKB Recycle: Fragment Reassembly Errors
From: Patrick McHardy @ 2009-12-01 16:24 UTC (permalink / raw)
To: ben; +Cc: David Miller, netdev
In-Reply-To: <767BAF49E93AFB4B815B11325788A8ED4B1FDC@L01SLCXDB03.calltower.com>
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
ben@bigfootnetworks.com wrote:
>> Ben, please give this patch a try.
>
> I have not been able to recreate the issue after applying the patch,
> which is great.
Thanks for testing.
> Is this the only case in which large-ish SKBs might be
> recycled and cause the reassembly overflow?
I'm not aware of any other cases at least.
Dave, attached is the patch again with a proper changelog.
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 1421 bytes --]
commit d45f8b9ff2b7c1c5787348a39d3778931beca7e3
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Dec 1 17:19:14 2009 +0100
ip_fragment: also adjust skb->truesize for packets not owned by a socket
When a large packet gets reassembled by ip_defrag(), the head skb
accounts for all the fragments in skb->truesize. If this packet is
refragmented again, skb->truesize is not re-adjusted to reflect only
the head size since its not owned by a socket. If the head fragment
then gets recycled and reused for another received fragment, it might
exceed the defragmentation limits due to its large truesize value.
skb_recycle_check() explicitly checks for linear skbs, so any recycled
skb should reflect its true size in skb->truesize. Change ip_fragment()
to also adjust the truesize value of skbs not owned by a socket.
Reported-and-tested-by: Ben Menchaca <ben@bigfootnetworks.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index b78e615..e34013a 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -503,8 +503,8 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
if (skb->sk) {
frag->sk = skb->sk;
frag->destructor = sock_wfree;
- truesizes += frag->truesize;
}
+ truesizes += frag->truesize;
}
/* Everything is OK. Generate! */
^ permalink raw reply related
* Re: [PATCH] Update embedded copy of ethtool.h from kernel 2.6.30
From: Jesper Nilsson @ 2009-12-01 15:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Jeff Garzik, netdev@vger.kernel.org
In-Reply-To: <1259682754.2831.11.camel@achroite.uk.solarflarecom.com>
On Tue, Dec 01, 2009 at 04:52:34PM +0100, Ben Hutchings wrote:
> On Tue, 2009-12-01 at 16:42 +0100, Jesper Nilsson wrote:
> > On Tue, Dec 01, 2009 at 04:21:18PM +0100, Ben Hutchings wrote:
> > > On Tue, 2009-12-01 at 16:17 +0100, Jesper Nilsson wrote:
> That's the correct repository. It is possible that the extra static
> information needed to serve it over HTTP is not up-to-date. Try using
> git protocol instead?
Yep, that was it, looks much better now. Thanks.
> Ben.
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [Bridge] notifier chain on br0
From: Stephen Hemminger @ 2009-12-01 16:32 UTC (permalink / raw)
To: ratheesh k; +Cc: bridge, netdev
In-Reply-To: <cfeab66d0912010626n43e2a971gdc8a23b976256c56@mail.gmail.com>
On Tue, 1 Dec 2009 19:56:03 +0530
ratheesh k <ratheesh.ksz@gmail.com> wrote:
> Hi All ,
>
> i have a software bridge br0 on eth0 and eth1 . Can i use NETLINK
> sockets to get ip address change notification on br0 .???
>
> Thanks,
> Ratheesh
Netlink reports all interfaces including br0
^ permalink raw reply
* [PATCH] crypto: gmac - Add RFC4543 wrapper for GCM
From: Tobias Brunner @ 2009-12-01 16:49 UTC (permalink / raw)
To: David S. Miller, Herbert Xu; +Cc: netdev, linux-crypto
This patch adds the RFC4543 (GMAC) wrapper for GCM similar to the
existing RFC4106 wrapper. The main differences between GCM and GMAC are
the contents of the AAD and that the plaintext is empty for the latter.
Signed-off-by: Tobias Brunner <tobias@strongswan.org>
---
crypto/gcm.c | 275 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pfkeyv2.h | 1 +
net/xfrm/xfrm_algo.c | 16 +++
3 files changed, 292 insertions(+), 0 deletions(-)
diff --git a/crypto/gcm.c b/crypto/gcm.c
index 5fc3292..b097eb4 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -37,6 +37,15 @@ struct crypto_rfc4106_ctx {
u8 nonce[4];
};
+struct crypto_rfc4543_ctx {
+ struct crypto_aead *child;
+ u8 nonce[4];
+ u8 auth_tag[16];
+ struct scatterlist cipher[1];
+ struct scatterlist payload[2];
+ struct scatterlist assoc[2];
+};
+
struct crypto_gcm_ghash_ctx {
unsigned int cryptlen;
struct scatterlist *src;
@@ -1008,6 +1017,264 @@ static struct crypto_template crypto_rfc4106_tmpl = {
.module = THIS_MODULE,
};
+static int crypto_rfc4543_setkey(struct crypto_aead *parent, const u8 *key,
+ unsigned int keylen)
+{
+ struct crypto_rfc4543_ctx *ctx = crypto_aead_ctx(parent);
+ struct crypto_aead *child = ctx->child;
+ int err;
+
+ if (keylen < 4)
+ return -EINVAL;
+
+ keylen -= 4;
+ memcpy(ctx->nonce, key + keylen, 4);
+
+ crypto_aead_clear_flags(child, CRYPTO_TFM_REQ_MASK);
+ crypto_aead_set_flags(child, crypto_aead_get_flags(parent) &
+ CRYPTO_TFM_REQ_MASK);
+ err = crypto_aead_setkey(child, key, keylen);
+ crypto_aead_set_flags(parent, crypto_aead_get_flags(child) &
+ CRYPTO_TFM_RES_MASK);
+
+ return err;
+}
+
+static int crypto_rfc4543_setauthsize(struct crypto_aead *parent,
+ unsigned int authsize)
+{
+ struct crypto_rfc4543_ctx *ctx = crypto_aead_ctx(parent);
+
+ if (authsize != 16)
+ return -EINVAL;
+
+ return crypto_aead_setauthsize(ctx->child, authsize);
+}
+
+/* this is the same as crypto_authenc_chain */
+static void crypto_rfc4543_chain(struct scatterlist *head,
+ struct scatterlist *sg, int chain)
+{
+ if (chain) {
+ head->length += sg->length;
+ sg = scatterwalk_sg_next(sg);
+ }
+
+ if (sg)
+ scatterwalk_sg_chain(head, 2, sg);
+ else
+ sg_mark_end(head);
+}
+
+static struct aead_request *crypto_rfc4543_crypt(struct aead_request *req,
+ int enc)
+{
+ struct aead_request *subreq = aead_request_ctx(req);
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct crypto_rfc4543_ctx *ctx = crypto_aead_ctx(aead);
+ struct crypto_aead *child = ctx->child;
+ struct scatterlist *dst = req->dst;
+ struct scatterlist *cipher = ctx->cipher;
+ struct scatterlist *payload = ctx->payload;
+ struct scatterlist *assoc = ctx->assoc;
+ unsigned int authsize = crypto_aead_authsize(aead);
+ unsigned int assoclen = req->assoclen;
+ struct page *dstp;
+ u8 *vdst;
+ u8 *iv = PTR_ALIGN((u8 *)(subreq + 1) + crypto_aead_reqsize(child),
+ crypto_aead_alignmask(child) + 1);
+
+ memcpy(iv, ctx->nonce, 4);
+ memcpy(iv + 4, req->iv, 8);
+
+ /* construct cipher/plaintext */
+ if (enc)
+ memset(ctx->auth_tag, 0, authsize);
+ else
+ scatterwalk_map_and_copy(ctx->auth_tag, dst,
+ req->cryptlen - authsize,
+ authsize, 0);
+
+ sg_init_one(cipher, ctx->auth_tag, authsize);
+
+ /* construct the aad */
+ dstp = sg_page(dst);
+ vdst = PageHighMem(dstp) ? NULL : page_address(dstp) + dst->offset;
+
+ sg_init_table(payload, 2);
+ sg_set_buf(payload, req->iv, 8);
+ crypto_rfc4543_chain(payload, dst, vdst == req->iv + 8);
+ assoclen += 8 + req->cryptlen - (enc ? 0 : authsize);
+
+ sg_init_table(assoc, 2);
+ sg_set_page(assoc, sg_page(req->assoc), req->assoc->length,
+ req->assoc->offset);
+ crypto_rfc4543_chain(assoc, payload, 0);
+
+ aead_request_set_tfm(subreq, child);
+ aead_request_set_callback(subreq, req->base.flags, req->base.complete,
+ req->base.data);
+ aead_request_set_crypt(subreq, cipher, cipher, enc ? 0 : authsize, iv);
+ aead_request_set_assoc(subreq, assoc, assoclen);
+
+ return subreq;
+}
+
+static int crypto_rfc4543_encrypt(struct aead_request *req)
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct crypto_rfc4543_ctx *ctx = crypto_aead_ctx(aead);
+ struct aead_request *subreq;
+ int err;
+
+ subreq = crypto_rfc4543_crypt(req, 1);
+ err = crypto_aead_encrypt(subreq);
+ if (err)
+ return err;
+
+ scatterwalk_map_and_copy(ctx->auth_tag, req->dst, req->cryptlen,
+ crypto_aead_authsize(aead), 1);
+
+ return 0;
+}
+
+static int crypto_rfc4543_decrypt(struct aead_request *req)
+{
+ req = crypto_rfc4543_crypt(req, 0);
+
+ return crypto_aead_decrypt(req);
+}
+
+static int crypto_rfc4543_init_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_instance *inst = (void *)tfm->__crt_alg;
+ struct crypto_aead_spawn *spawn = crypto_instance_ctx(inst);
+ struct crypto_rfc4543_ctx *ctx = crypto_tfm_ctx(tfm);
+ struct crypto_aead *aead;
+ unsigned long align;
+
+ aead = crypto_spawn_aead(spawn);
+ if (IS_ERR(aead))
+ return PTR_ERR(aead);
+
+ ctx->child = aead;
+
+ align = crypto_aead_alignmask(aead);
+ align &= ~(crypto_tfm_ctx_alignment() - 1);
+ tfm->crt_aead.reqsize = sizeof(struct aead_request) +
+ ALIGN(crypto_aead_reqsize(aead),
+ crypto_tfm_ctx_alignment()) +
+ align + 16;
+
+ return 0;
+}
+
+static void crypto_rfc4543_exit_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_rfc4543_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ crypto_free_aead(ctx->child);
+}
+
+static struct crypto_instance *crypto_rfc4543_alloc(struct rtattr **tb)
+{
+ struct crypto_attr_type *algt;
+ struct crypto_instance *inst;
+ struct crypto_aead_spawn *spawn;
+ struct crypto_alg *alg;
+ const char *ccm_name;
+ int err;
+
+ algt = crypto_get_attr_type(tb);
+ err = PTR_ERR(algt);
+ if (IS_ERR(algt))
+ return ERR_PTR(err);
+
+ if ((algt->type ^ CRYPTO_ALG_TYPE_AEAD) & algt->mask)
+ return ERR_PTR(-EINVAL);
+
+ ccm_name = crypto_attr_alg_name(tb[1]);
+ err = PTR_ERR(ccm_name);
+ if (IS_ERR(ccm_name))
+ return ERR_PTR(err);
+
+ inst = kzalloc(sizeof(*inst) + sizeof(*spawn), GFP_KERNEL);
+ if (!inst)
+ return ERR_PTR(-ENOMEM);
+
+ spawn = crypto_instance_ctx(inst);
+ crypto_set_aead_spawn(spawn, inst);
+ err = crypto_grab_aead(spawn, ccm_name, 0,
+ crypto_requires_sync(algt->type, algt->mask));
+ if (err)
+ goto out_free_inst;
+
+ alg = crypto_aead_spawn_alg(spawn);
+
+ err = -EINVAL;
+
+ /* We only support 16-byte blocks. */
+ if (alg->cra_aead.ivsize != 16)
+ goto out_drop_alg;
+
+ /* Not a stream cipher? */
+ if (alg->cra_blocksize != 1)
+ goto out_drop_alg;
+
+ err = -ENAMETOOLONG;
+ if (snprintf(inst->alg.cra_name, CRYPTO_MAX_ALG_NAME,
+ "rfc4543(%s)", alg->cra_name) >= CRYPTO_MAX_ALG_NAME ||
+ snprintf(inst->alg.cra_driver_name, CRYPTO_MAX_ALG_NAME,
+ "rfc4543(%s)", alg->cra_driver_name) >=
+ CRYPTO_MAX_ALG_NAME)
+ goto out_drop_alg;
+
+ inst->alg.cra_flags = CRYPTO_ALG_TYPE_AEAD;
+ inst->alg.cra_flags |= alg->cra_flags & CRYPTO_ALG_ASYNC;
+ inst->alg.cra_priority = alg->cra_priority;
+ inst->alg.cra_blocksize = 1;
+ inst->alg.cra_alignmask = alg->cra_alignmask;
+ inst->alg.cra_type = &crypto_nivaead_type;
+
+ inst->alg.cra_aead.ivsize = 8;
+ inst->alg.cra_aead.maxauthsize = 16;
+
+ inst->alg.cra_ctxsize = sizeof(struct crypto_rfc4543_ctx);
+
+ inst->alg.cra_init = crypto_rfc4543_init_tfm;
+ inst->alg.cra_exit = crypto_rfc4543_exit_tfm;
+
+ inst->alg.cra_aead.setkey = crypto_rfc4543_setkey;
+ inst->alg.cra_aead.setauthsize = crypto_rfc4543_setauthsize;
+ inst->alg.cra_aead.encrypt = crypto_rfc4543_encrypt;
+ inst->alg.cra_aead.decrypt = crypto_rfc4543_decrypt;
+
+ inst->alg.cra_aead.geniv = "seqiv";
+
+out:
+ return inst;
+
+out_drop_alg:
+ crypto_drop_aead(spawn);
+out_free_inst:
+ kfree(inst);
+ inst = ERR_PTR(err);
+ goto out;
+}
+
+static void crypto_rfc4543_free(struct crypto_instance *inst)
+{
+ crypto_drop_spawn(crypto_instance_ctx(inst));
+ kfree(inst);
+}
+
+static struct crypto_template crypto_rfc4543_tmpl = {
+ .name = "rfc4543",
+ .alloc = crypto_rfc4543_alloc,
+ .free = crypto_rfc4543_free,
+ .module = THIS_MODULE,
+};
+
static int __init crypto_gcm_module_init(void)
{
int err;
@@ -1028,8 +1295,14 @@ static int __init crypto_gcm_module_init(void)
if (err)
goto out_undo_gcm;
+ err = crypto_register_template(&crypto_rfc4543_tmpl);
+ if (err)
+ goto out_undo_rfc4106;
+
return 0;
+out_undo_rfc4106:
+ crypto_unregister_template(&crypto_rfc4106_tmpl);
out_undo_gcm:
crypto_unregister_template(&crypto_gcm_tmpl);
out_undo_base:
@@ -1042,6 +1315,7 @@ out:
static void __exit crypto_gcm_module_exit(void)
{
kfree(gcm_zeroes);
+ crypto_unregister_template(&crypto_rfc4543_tmpl);
crypto_unregister_template(&crypto_rfc4106_tmpl);
crypto_unregister_template(&crypto_gcm_tmpl);
crypto_unregister_template(&crypto_gcm_base_tmpl);
@@ -1055,3 +1329,4 @@ MODULE_DESCRIPTION("Galois/Counter Mode");
MODULE_AUTHOR("Mikko Herranen <mh1@iki.fi>");
MODULE_ALIAS("gcm_base");
MODULE_ALIAS("rfc4106");
+MODULE_ALIAS("rfc4543");
diff --git a/include/linux/pfkeyv2.h b/include/linux/pfkeyv2.h
index 228b0b6..0b80c80 100644
--- a/include/linux/pfkeyv2.h
+++ b/include/linux/pfkeyv2.h
@@ -315,6 +315,7 @@ struct sadb_x_kmaddress {
#define SADB_X_EALG_AES_GCM_ICV12 19
#define SADB_X_EALG_AES_GCM_ICV16 20
#define SADB_X_EALG_CAMELLIACBC 22
+#define SADB_X_EALG_NULL_AES_GMAC 23
#define SADB_EALG_MAX 253 /* last EALG */
/* private allocations should use 249-255 (RFC2407) */
#define SADB_X_EALG_SERPENTCBC 252 /* draft-ietf-ipsec-ciph-aes-cbc-00 */
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index ef8d61d..c9182fb 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -125,6 +125,22 @@ static struct xfrm_algo_desc aead_list[] = {
.sadb_alg_maxbits = 256
}
},
+{
+ .name = "rfc4543(gcm(aes))",
+
+ .uinfo = {
+ .aead = {
+ .icv_truncbits = 128,
+ }
+ },
+
+ .desc = {
+ .sadb_alg_id = SADB_X_EALG_NULL_AES_GMAC,
+ .sadb_alg_ivlen = 8,
+ .sadb_alg_minbits = 128,
+ .sadb_alg_maxbits = 256
+ }
+},
};
static struct xfrm_algo_desc aalg_list[] = {
--
1.6.3.3
^ permalink raw reply related
* Re: warning: massive change to conditional coding style in net?
From: Eric Dumazet @ 2009-12-01 16:49 UTC (permalink / raw)
To: William Allen Simpson
Cc: Joe Perches, Linux Kernel Developers,
Linux Kernel Network Developers
In-Reply-To: <4B153F9B.7050502@gmail.com>
William Allen Simpson a écrit :
> Joe Perches wrote:
>> If it makes getting tcp cookies accepted difficult,
>> a reversion is simple. That style isn't as important.
>>
> Then why make an *un*important (yet sweeping) change?
Because this is time :
We usually makes cleanup patches just before the release
of a new linux kernel, to minimize effects on developer trees.
We know linux-2.6.32 is about to be released by Linus,
and all major 2.6.33 patches are already queued in net-next-2.6
to be pushed to Linus as soon as the window opens.
This is the perfect time for cleanups. Doing cleanups is a good
way to learn linux code, before doing more complex things.
If you take a look at queued patches in net-next-2.6, maybe less
than 5 % are cleanups.
But this rule can be changed, if your patches are ready for inclusion,
David might revert the jumbo cleanup to ease your job. Just ask.
^ permalink raw reply
* Re: seeing strange values for tcp sk_rmem_alloc
From: Eric Dumazet @ 2009-12-01 16:58 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev, Linux kernel
In-Reply-To: <4B15416A.2060202@nortel.com>
Chris Friesen a écrit :
> I'm hoping someone might be able to explain some odd behaviour that I'm
> seeing.
>
> Some of our developers wanted to be able to see how much of their rx
> socket buffer space was in use, so I added the following to sock_ioctl()
>
>
> case SIOCGSKRMEMALLOC:
> {
> int tmp;
> err = -EINVAL;
> if(!sock->sk)
> break;
> tmp = atomic_read(&sock->sk->sk_rmem_alloc);
> err = copy_to_user(argp, &tmp, sizeof(tmp));
> break;
> }
>
> To validate it, I wrote a testcase that opened a tcp socket, then looped
> sending 2k of data at a time to it and calling the above ioctl to check
> the sk_rmem_alloc value (without ever reading from the socket).
>
> The results were odd--I've copied them below. Can anyone explain how I
> can send 20K of data but sk_rmem_alloc still only shows 4.8K used, then
> it suddenly jumps by a lot on the next packet to something that more
> reflects reality, then repeats that pattern again? Is there some
> additional buffering happening somewhere in the TCP stack?
>
Me wondering why you think sk_rmem_alloc is about TX side.
Its used in RX path. rmem means ReadMemory.
You can send 1 Gbytes of data, and sk_rmem_alloc doesnt change, if your
TCP stream is unidirectionnal.
sk_rmem_alloc grows when skb are queued into receive queue
sk_rmem_alloc shrinks when application reads this receive queue.
^ permalink raw reply
* Re: net 04/05: fib_rules: allow to delete local rule
From: Alexey Kuznetsov @ 2009-12-01 17:12 UTC (permalink / raw)
To: jamal; +Cc: Patrick McHardy, netdev, robert
In-Reply-To: <1259673821.3168.35.camel@bigi>
Hello!
> Nice. I recall there was a lot of sentiment against this back
> when - in particular from Alexey. I cant remember the details
Indeed, I refused to do this.
Sometimes, we have to determine that an address is local in a context
where we do not have information to form a proper request to rule database.
In this case we do direct lookup in fixed table, which is designated
to contain local routes. So that rule 0 was hardwired to lookup in the
same table.
Frankly, it will work provided we do not require too much of self-consistency.
Those days I could not stand this, but it is not illegal.
Alexey
^ permalink raw reply
* Re: seeing strange values for tcp sk_rmem_alloc
From: Chris Friesen @ 2009-12-01 17:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Linux kernel
In-Reply-To: <4B154B29.1030807@cosmosbay.com>
On 12/01/2009 10:58 AM, Eric Dumazet wrote:
> Me wondering why you think sk_rmem_alloc is about TX side.
> Its used in RX path. rmem means ReadMemory.
Yep, I realize this.
> You can send 1 Gbytes of data, and sk_rmem_alloc doesnt change, if your
> TCP stream is unidirectionnal.
>
> sk_rmem_alloc grows when skb are queued into receive queue
> sk_rmem_alloc shrinks when application reads this receive queue.
I realize this. I sent the data from a socket to itself. It could just
as easily be done with two tcp sockets. The important thing is that I
control both the tx and rx sides, so I know how much data should be
present in the rx queue at any point in time.
The part that surprised me was that I could send multiple chunks of data
without sk_rmem_alloc changing on the socket to which the data was being
sent. Then it would jump up by a large amount (up to 20K) all at once.
I'm starting to suspect that the discrepency might have something to do
with the skb_copy_datagram_iovec() call in tcp_data_queue(), and how
skb_set_owner_r() is only called if "eaten" is <= 0. This could be
totally off-base though.
Chris
^ permalink raw reply
* Re: net 04/05: fib_rules: allow to delete local rule
From: Patrick McHardy @ 2009-12-01 17:38 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: jamal, netdev, robert
In-Reply-To: <20091201171214.GA7544@ms2.inr.ac.ru>
Alexey Kuznetsov wrote:
> Hello!
>
>> Nice. I recall there was a lot of sentiment against this back
>> when - in particular from Alexey. I cant remember the details
>
> Indeed, I refused to do this.
>
> Sometimes, we have to determine that an address is local in a context
> where we do not have information to form a proper request to rule database.
> In this case we do direct lookup in fixed table, which is designated
> to contain local routes. So that rule 0 was hardwired to lookup in the
> same table.
Yes, you have to carefully set up your rules preceeding the local
rule when using this. Using marks or oif should work fine without
affecting the cases where we just need some information like the
device or addresses.
> Frankly, it will work provided we do not require too much of self-consistency.
> Those days I could not stand this, but it is not illegal.
In fact, you should already be able to do this by moving the
contents of the local table to a different one :)
^ permalink raw reply
* Re: warning: massive change to conditional coding style in net?
From: Jarek Poplawski @ 2009-12-01 17:43 UTC (permalink / raw)
To: William Allen Simpson
Cc: Joe Perches, Linux Kernel Developers,
Linux Kernel Network Developers
In-Reply-To: <4B153F9B.7050502@gmail.com>
William Allen Simpson wrote, On 12/01/2009 05:08 PM:
> But more important, at least to my thinking, is keeping patches simple
> by conforming to the *existing* style in the section of code. No
> sweeping changes!
How about new sections in between transit smoothly from one style
to another? (Or 50/50?)
Jarek P.
^ permalink raw reply
* Re: [linux-pm] intermittent suspend problem again
From: Ferenc Wagner @ 2009-12-01 17:46 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, Andrew Morton, LKML, netdev
In-Reply-To: <200912011328.15551.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Tuesday 01 December 2009, Ferenc Wagner wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>>> On Sunday 29 November 2009, Ferenc Wagner wrote:
>>>
>>>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>>>
>>>>> On Saturday 28 November 2009, Ferenc Wagner wrote:
>>>>>
>>>>>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>>>>>
>>>>>>> Compile with CONFIG_PM_VERBOSE (it does mean exactly that).
>>>>>>
>>>>>> The last message now was:
>>>>>>
>>>>>> e100: 0000:02:08.0: hibernate, may wakeup
>>>>>>
>>>>>> Looks like hibernating the e100 driver is unstable.
>>>>>
>>>>> Can you verify that by trying to hibernate without the e100 driver?
>>>>
>>>> Not really, as I still can't reliable reproduce the issue. Since I'm
>>>> running with suspend loglevel = 8, it's happened only twice (in a row),
>>>> with seemingly exact same console output. Some earlier freezes also
>>>> happened in dpm_suspend_start, at least. However, I can certainly add
>>>> e100 to SUSPEND_MODULES under /etc/pm/config.d, and continue running
>>>> with that.
>>>
>>> That's what I'd do.
>>
>> That worked out mosty OK (no freeze in quite some hibernation cycles),
>> but I'm continuing testing it.
>
> Great, please let me know how it works out.
Will do. On the negative side, this tends to confuse NetworkManager.
>> On the other hand, I reverted 8fbd962e3, recompiled and replaced the
>> module, and got the freeze during hibernation. And that was the bulk of
>> the changes since 2.6.31... I'll revert the rest and test again, but
>> that seems purely cosmetic, so no high hopes.
>>
>>> In addition to that, you can run multiple hibernation/resume cycles in
>>> a tight loop using the RTC wakealarm.
>>
>> I'll do so, as soon as I find a way to automatically supply the dm-crypt
>> passphrase... or even better, learn to hibernate to ramdisk from the
>> initramfs. :)
>
> Well, you don't need to use swap encryption for _testing_. :-)
I use partition encryption, everything except for /boot is encrypted.
Apropos: does s2disk perform encryption with a temporary key even if I
don't supply and RSA key, to protect mlocked application data from being
present in the swap after restore?
--
Thanks,
Feri.
^ permalink raw reply
* Re: seeing strange values for tcp sk_rmem_alloc
From: Eric Dumazet @ 2009-12-01 17:52 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev, Linux kernel
In-Reply-To: <4B155252.1040604@nortel.com>
Chris Friesen a écrit :
> I realize this. I sent the data from a socket to itself. It could just
> as easily be done with two tcp sockets. The important thing is that I
> control both the tx and rx sides, so I know how much data should be
> present in the rx queue at any point in time.
>
> The part that surprised me was that I could send multiple chunks of data
> without sk_rmem_alloc changing on the socket to which the data was being
> sent. Then it would jump up by a large amount (up to 20K) all at once.
>
> I'm starting to suspect that the discrepency might have something to do
> with the skb_copy_datagram_iovec() call in tcp_data_queue(), and how
> skb_set_owner_r() is only called if "eaten" is <= 0. This could be
> totally off-base though.
>
If you dont read() your socket, then skb_copy_datagram_iovec() is not called
But be careful of sender tcp stack : It might be delayed a bit,
because it waits for receiver to open its window (slow start)
You probably need something like
while (1) {
send(fd1, buffer, 2Kbytes);
sleep(2); // let tcp stack flush its write buffers
display_sk_rmem_alloc(fd2);
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox