From: Christoph Paasch <cpaasch@apple.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>,
netdev@vger.kernel.org, David Miller <davem@davemloft.net>
Subject: Re: [PATCH net] Revert "tcp: switch tcp_fastopen key generation to net_get_random_once"
Date: Thu, 18 Jun 2015 08:45:29 -0700 [thread overview]
Message-ID: <20150618154529.GG33243@Chimay.local> (raw)
In-Reply-To: <1434626053.27504.206.camel@edumazet-glaptop2.roam.corp.google.com>
On 18/06/15 - 04:14:13, Eric Dumazet wrote:
> On Thu, 2015-06-18 at 11:32 +0200, Hannes Frederic Sowa wrote:
> > > There does not seem to be a better way to handle this. We could try
> > > to make the call to kmalloc and crypto_alloc_cipher during bootup, and
> > > then generate the random value only on-the-fly (when the first TFO-SYN
> > > comes in) with net_get_random_once in order to have the better entropy
> > > that comes with doing the late initialisation of the random value. But
> > > that's probably net-next material.
> >
> > can't we simply move the net_get_random_once to the TCP_FASTOPEN setsockopt and
> > sendmsg(MSG_FASTOPEN) path, so those allocations still happen in process context
> > but we still defer the extraction of entropy as long as posible?
>
> Yes, I do not think this would be hard. This bug is old (3.13) and does
> not seem very urgent to expedite a revert.
True, it would be simpler to call tcp_fastopen_init_key_once to the
setsocketopt() and inet_listen().
I will resubmit.
Christoph
prev parent reply other threads:[~2015-06-18 15:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 0:28 [PATCH net] Revert "tcp: switch tcp_fastopen key generation to net_get_random_once" Christoph Paasch
2015-06-18 9:32 ` Hannes Frederic Sowa
2015-06-18 11:14 ` Eric Dumazet
2015-06-18 15:45 ` Christoph Paasch [this message]
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=20150618154529.GG33243@Chimay.local \
--to=cpaasch@apple.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hannes@stressinduktion.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.