From: Michal Kubecek <mkubecek@suse.cz> To: netdev@vger.kernel.org Cc: linux-sctp@vger.kernel.org, linux-kernel@vger.kernel.org, Vlad Yasevich <vyasevich@gmail.com>, Neil Horman <nhorman@tuxdriver.com>, Gang He <ghe@suse.com>, GuoQing Jiang <gqjiang@suse.com> Subject: non-blocking connect for kernel SCTP sockets Date: Wed, 2 May 2018 11:06:39 +0200 [thread overview] Message-ID: <20180502090639.j55mnclmkzdts6xb@unicorn.suse.cz> (raw) Hello, while investigating a bug, we noticed that DLM tries to connect an SCTP socket in non-blocking mode using result = sock->ops->connect(sock, (struct sockaddr *)&daddr, addr_len, O_NONBLOCK); which does not work. The reason is that inet_dgram_connect() cannot pass its flags argument to sctp_connect() so that __sctp_connect() which does the actual waiting resorts to checking sk->sk_socket->file->f_flags instead. As the socket used by DLM is a kernel socket with no associated file, it ends up blocking. TCP doesn't suffer from this problem as for TCP, the waiting is done in inet_stream_connect() which has the flags argument. I also checked other proto::connect handlers and sctp_connect() seems to be the only one with this kind of problem. This could be worked around in DLM and further experiments indicate current DLM code wouldn't actually handle the non-blocking connect properly. But I still feel ignoring the flags argument is rather a trap that should be fixed. I have prepared a series adding flags argument to proto::connect and using it in sctp_connect() and __sctp_connect(). But I'm not sure if it's not too big hammer to address issue only affecting one handler. So my question is: would such generic approach be preferred or should we rather make SCTP work the way TCP does, i.e. move the waiting from proto::connect() to proto_ops::connect()? This would require introducing inet_seqpacket_connect() as inet_dgram_connect() is primarily intended for use with UDP.) Michal Kubecek
WARNING: multiple messages have this Message-ID (diff)
From: Michal Kubecek <mkubecek@suse.cz> To: netdev@vger.kernel.org Cc: linux-sctp@vger.kernel.org, linux-kernel@vger.kernel.org, Vlad Yasevich <vyasevich@gmail.com>, Neil Horman <nhorman@tuxdriver.com>, Gang He <ghe@suse.com>, GuoQing Jiang <gqjiang@suse.com> Subject: non-blocking connect for kernel SCTP sockets Date: Wed, 02 May 2018 09:06:39 +0000 [thread overview] Message-ID: <20180502090639.j55mnclmkzdts6xb@unicorn.suse.cz> (raw) Hello, while investigating a bug, we noticed that DLM tries to connect an SCTP socket in non-blocking mode using result = sock->ops->connect(sock, (struct sockaddr *)&daddr, addr_len, O_NONBLOCK); which does not work. The reason is that inet_dgram_connect() cannot pass its flags argument to sctp_connect() so that __sctp_connect() which does the actual waiting resorts to checking sk->sk_socket->file->f_flags instead. As the socket used by DLM is a kernel socket with no associated file, it ends up blocking. TCP doesn't suffer from this problem as for TCP, the waiting is done in inet_stream_connect() which has the flags argument. I also checked other proto::connect handlers and sctp_connect() seems to be the only one with this kind of problem. This could be worked around in DLM and further experiments indicate current DLM code wouldn't actually handle the non-blocking connect properly. But I still feel ignoring the flags argument is rather a trap that should be fixed. I have prepared a series adding flags argument to proto::connect and using it in sctp_connect() and __sctp_connect(). But I'm not sure if it's not too big hammer to address issue only affecting one handler. So my question is: would such generic approach be preferred or should we rather make SCTP work the way TCP does, i.e. move the waiting from proto::connect() to proto_ops::connect()? This would require introducing inet_seqpacket_connect() as inet_dgram_connect() is primarily intended for use with UDP.) Michal Kubecek
next reply other threads:[~2018-05-02 9:06 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-02 9:06 Michal Kubecek [this message] 2018-05-02 9:06 ` non-blocking connect for kernel SCTP sockets Michal Kubecek 2018-05-02 9:46 ` Xin Long 2018-05-02 9:46 ` Xin Long 2018-05-02 12:32 ` Michal Kubecek 2018-05-02 12:32 ` Michal Kubecek 2018-05-02 13:36 ` Marcelo Ricardo Leitner 2018-05-02 13:36 ` Marcelo Ricardo Leitner
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=20180502090639.j55mnclmkzdts6xb@unicorn.suse.cz \ --to=mkubecek@suse.cz \ --cc=ghe@suse.com \ --cc=gqjiang@suse.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sctp@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=nhorman@tuxdriver.com \ --cc=vyasevich@gmail.com \ /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: linkBe 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.