From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: David Miller <davem@davemloft.net>
Cc: simon@fire.lp0.eu, john@screen.lv, netdev@vger.kernel.org
Subject: Re: strange tcp behavior
Date: Fri, 3 Aug 2007 12:22:42 +0400 [thread overview]
Message-ID: <20070803082242.GA25582@2ka.mipt.ru> (raw)
In-Reply-To: <20070802.192134.107254907.davem@davemloft.net>
On Thu, Aug 02, 2007 at 07:21:34PM -0700, David Miller (davem@davemloft.net) wrote:
> > On Thu, Aug 02, 2007 at 10:08:42PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> > > So, following patch fixes problem for me.
> >
> > Or this one. Essentially the same though.
> >
> > Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
>
> So, this bug got introduced partly in 2.3.15, which is when
> we SMP threaded the networking stack.
>
> The error check was present in inet_sendmsg() previously, it
> looked like this:
>
> int inet_sendmsg(struct socket *sock, struct msghdr *msg, int size,
> struct scm_cookie *scm)
> {
> struct sock *sk = sock->sk;
>
> if (sk->shutdown & SEND_SHUTDOWN) {
> if (!(msg->msg_flags&MSG_NOSIGNAL))
> send_sig(SIGPIPE, current, 1);
> return(-EPIPE);
> }
This one would caught our problem.
> if (sk->prot->sendmsg == NULL)
> return(-EOPNOTSUPP);
> if(sk->err)
> return sock_error(sk);
And this one too.
> /* We may need to bind the socket. */
> if (inet_autobind(sk) != 0)
> return -EAGAIN;
>
> return sk->prot->sendmsg(sk, msg, size);
> }
>
> I believe the idea was to move the sk->err check down into
> tcp_sendmsg().
>
> But this raises a major issue.
>
> What in the world are we doing allowing stream sockets to autobind?
> That is totally bogus. Even if we autobind, that won't make a connect
> happen.
For accepted socket it is perfectly valid assumption - we could autobind
it during the first send. Or may bind it during accept. Its a matter of
taste I think. Autobinding during first sending can end up being a
protection against DoS in some obscure rare case...
> There is logic down in TCP to handle all of these details properly
> as long as we don't do this bogus autobind stuff.
Yes, TCP sending function will catch this problems.
> do_tcp_sendpages() and tcp_sendmsg() both invoke sk_stream_wait_connect()
> if TCP is in a state where data sending is not possible. Inside of
> sk_stream_wait_connect() it handles socket errors as first priority,
> then if no socket errors are pending it checks if we are trying to
> connect currently and if not returns -EPIPE. It is exactly what we
> want under these circumstances.
>
> So the bug is purely that autobind is attempted for TCP sockets at
> all.
>
> TCP's sendpage handles this correctly already, it calls directly down
> into tcp_sendpage(), inet_sendpage() is not used at all.
>
> So the fix is to make tcp_sendmsg() direct as well, that bypasses all
> of this autobind madness. The error checking and state verification
> in TCP's sendmsg() and sendpage() implementations will do the right
> thing.
>
> Comments?
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index c209361..185c7ec 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -281,7 +281,7 @@ extern int tcp_v4_remember_stamp(struct sock *sk);
>
> extern int tcp_v4_tw_remember_stamp(struct inet_timewait_sock *tw);
>
> -extern int tcp_sendmsg(struct kiocb *iocb, struct sock *sk,
> +extern int tcp_sendmsg(struct kiocb *iocb, struct socket *sock,
> struct msghdr *msg, size_t size);
Maybe recvmsg should be changed too for symmetry?
--
Evgeniy Polyakov
next prev parent reply other threads:[~2007-08-03 8:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-02 6:19 strange tcp behavior john
2007-08-02 9:55 ` Evgeniy Polyakov
2007-08-02 10:16 ` Evgeniy Polyakov
2007-08-02 11:38 ` Simon Arlott
2007-08-02 12:04 ` Evgeniy Polyakov
2007-08-02 12:28 ` Evgeniy Polyakov
[not found] ` <46860.212.93.96.73.1186055105.squirrel@mail.screen.lv>
2007-08-02 12:15 ` Simon Arlott
2007-08-02 17:15 ` Simon Arlott
2007-08-02 18:08 ` Evgeniy Polyakov
2007-08-02 18:48 ` Evgeniy Polyakov
2007-08-02 22:02 ` David Miller
2007-08-03 2:21 ` David Miller
2007-08-03 8:22 ` Evgeniy Polyakov [this message]
2007-08-03 20:04 ` David Miller
2007-08-04 16:49 ` Evgeniy Polyakov
2007-08-03 21:17 ` David Miller
2007-08-04 16:51 ` Evgeniy Polyakov
2007-08-05 3:21 ` David Miller
2007-08-02 18:58 ` Simon Arlott
2007-08-03 8:25 ` Evgeniy Polyakov
2007-08-03 11:21 ` Simon Arlott
2007-08-03 11:56 ` Evgeniy Polyakov
2007-08-03 12:03 ` Simon Arlott
2007-08-03 12:09 ` Evgeniy Polyakov
2007-08-03 16:51 ` Simon Arlott
2007-08-03 17:39 ` Evgeniy Polyakov
2007-08-03 18:29 ` Simon Arlott
2007-08-04 16:03 ` Evgeniy Polyakov
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=20070803082242.GA25582@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=davem@davemloft.net \
--cc=john@screen.lv \
--cc=netdev@vger.kernel.org \
--cc=simon@fire.lp0.eu \
/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).