From: Tejun Heo <tj@kernel.org>
To: David Fries <david@fries.net>
Cc: netdev@vger.kernel.org, linux-pm@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: hiberante hangs TCP Re: [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking
Date: Sun, 30 Oct 2011 13:16:18 -0700 [thread overview]
Message-ID: <20111030201618.GA7696@google.com> (raw)
In-Reply-To: <20111030044821.GA23741@spacedout.fries.net>
(cc'ing Rafael and linux-pm)
On Sat, Oct 29, 2011 at 11:48:21PM -0500, David Fries wrote:
> I saw the write up on this on lwn.net, pretty creative by the way, and
> it got me thinking about a different checkpoint/restart problem I've
> been running into. Specifically in hibernating to disk. In the
> hibernate case active TCP connections hang after resuming, while an
> idle TCP connection will continue after the system is back up. My
> observation is the kernel checkpoints itself to memory, enables
> devices, writes out that checkpoint image to storage, then powers off.
> The problem is if TCP packets are received while writing to storage,
> the kernel will continue to queue and ack those TCP packets, but the
> running kernel and it's network state is shortly lost. When the
> computer resumes, those TCP byte sequences hang the TCP connection for
> an extended period of time while the resumed computer refuses to
> acknowledge the data that was received after checkpointing and the now
> running kernel knew nothing about, and the other computer tries in
> vain to resend any data that hadn't yet been acknowledged, which is
> always after the data that was lost, until one of them eventually
> gives up.
>
> I've been wondering if it was safe or possible to leave any network
> interfaces down after the checkpoint, or what the right solution would
> be. I didn't think marking every TCP connection with a ZOMBIE_KERNEL
> bit just after the kernel checkpoint (for the kernel is walking dead
> and won't remember anything that happens), and then prevent any TCP
> acks from being sent for those connections would be the right
> solution. I've taken to unplugging the physical lan cable,
> hibernating to disk, and plugging it back in after the system is down,
> to avoid the problem. Any ideas?
Hmmm... sounds like taking down network interfaces before starting
hibernation sequence should be enough, which shouldn't be too
difficult to implement from userland. Rafael, what do you think?
Thanks.
--
tejun
next prev parent reply other threads:[~2011-10-30 20:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-06 12:12 [EXAMPLE CODE] Parasite thread injection and TCP connection hijacking Tejun Heo
2011-08-06 12:45 ` Andy Lutomirski
2011-08-06 13:00 ` Tejun Heo
2011-08-06 13:15 ` Andrew Lutomirski
2011-08-06 13:20 ` Tejun Heo
2011-08-08 10:20 ` Tejun Heo
2011-10-30 4:48 ` hiberante hangs TCP " David Fries
2011-10-30 20:16 ` Tejun Heo [this message]
2011-10-30 20:43 ` David Fries
2011-11-02 9:44 ` MyungJoo Ham
2011-11-02 15:10 ` Tejun Heo
2012-02-17 19:28 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111030201618.GA7696@google.com \
--to=tj@kernel.org \
--cc=david@fries.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).