>>> Guoqing Jiang <gqji...@suse.com> schrieb am 13.03.2018 um 08:42 in Nachricht

> On 03/13/2018 03:09 PM, Ulrich Windl wrote:
>>>>> Guoqing Jiang <gqji...@suse.com> schrieb am 13.03.2018 um 05:00 in 
>>>>> Nachricht
>> <87a8e0e7-63f3-2329-6598-1fa80b1b1...@suse.com>:
>>> On 03/08/2018 07:24 PM, Ulrich Windl wrote:
>>>> Hi!
>>>> What surprises me most is that a connect(...O_NONBLOCK) actually blocks:
>>>>                 The  socket  is  non-blocking  and the connection cannot be
>>> com-
>>>>                 pleted immediately.
>>> Maybe it is because that the socket is created by sock_create_kern, and
>>> O_NONBLOCK flag is not worked  since __sctp_connect has the following
>>> description.
>>>          /* in-kernel sockets don't generally have a file allocated to them
>>>            * if all they do is call sock_create_kern().
>>>            */
>>>           if (sk->sk_socket->file)
>>>                   f_flags = sk->sk_socket->file->f_flags;
>>>           timeo = sock_sndtimeo(sk, f_flags & O_NONBLOCK);
>> But O_NONBLOCK is still passed to sock_sndtimeo() (unless the intention was 
> "f_flags & ~O_NONBLOCK").
> If I am not reading wrong, the O_NONBLOCK doesn't have effective above
> since f_flags is still 0.

OK; I didn't look close enough; you are right.

> So, in this case, timeo is set to sk->sk_sndtimeo. In sctp_wait_for_connect
> you also can see nonblock is only work when timeo is set to 0.
>              if (!*timeo_p)
>                          goto do_nonblock;

Another point would be to signal an error for a socket operation with 
unsupported flags, like O_NONBLOCK here. In the end it's probably better to 
remove O_NONBLOCK from the call reather than assuming it would have an effect 
in this case.

The other question (for the kernel developers) is whether the file structure is 
the best place to pass flags like O_NONBLOCK then.


Users mailing list: Users@clusterlabs.org

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Reply via email to